遇到从内地到香港使用专线或运营商的中继出现不稳定时,快速定位问题来源关键在于选择合适的探测方式、对比多协议结果并保留可复现的证据。本文按步骤介绍必用的网络诊断工具与常用命令、如何判断是链路、路由还是业务层问题,以及向供应商提交故障单时需准备的关键信息。
首选应使用最简单的ICMP/TCP连通性检测:Linux 下用 ping、Windows 下用 ping 和 tracert。建议先对目标IP做若干次连续探测:Linux 示例 ping -c 10 目标IP,可以快速看到丢包与平均时延。注意很多运营商会对ICMP限速或过滤,所以在ICMP异常时要使用TCP探测继续排查。
使用 traceroute(或Windows 的 tracert)查看路径中的每一跳延迟与丢包。推荐设置为TCP探测端口以绕过ICMP过滤:Linux 示例 traceroute -T -p 80 -n 目标IP。更强的实时统计工具是 mtr:mtr -rwzbc 100 目标IP 会展示每跳的丢包率与延迟分布,便于判断是“中间某跳持续丢包”还是“终端丢包”。若某一跳出现明显丢包但下一跳恢复,通常说明对方路由器对ICMP响应有策略限制;若丢包在多跳持续且最终端也丢包,通常为真实链路问题。
当怀疑ICMP被限流时,用 TCP 探测更可靠。Linux 可用 tcptraceroute 或 traceroute -T -p 443,Windows 可用 tcping.exe 对 80/443/22 等端口做探测。示例:tcptraceroute 目标IP 443,或 tcping -t 目标IP 443。若TCP探测延迟/丢包正常而ICMP异常,说明只是ICMP策略,业务层可能正常;相反若TCP也异常,说明业务通路确实存在问题。
CN2线路多涉及运营商间的策略路由与BGP公告,路由策略变动、邻居断链或社区操作都会影响路径。通过查看目标IP的AS路径和BGP公告(可用 bgp.he.net、RIPEstat、RouteViews)可以确认当前路由到达是否走的是预期的CN2出口,是否出现AS跳变或不正常的转发链。如果AS路径突然改变或通告被撤回,很可能是路由层面问题而非物理链路。
通常关注“本地至出口”(前3~6跳)与“互联网出口至目的地”(最后5~8跳)。如果前几跳就高延迟或丢包,问题常在本地机房或接入链路;若前半段稳定而后段问题集中在运营商网络或对方网关,那么问题在上游。用 mtr 长跑(例如 5~10 分钟)可观察抖动模式,结合不同时间点的多次测试判断是否属于短时拥塞、周期性故障或持续问题。
当怀疑业务层面(例如TLS握手失败、重传)时,需在客户端或服务端抓包(tcpdump/tshark)并记录三次握手和重传信息:tcpdump -i eth0 host 目标IP and port 443 -w capture.pcap。分析SYN/ACK是否被对端正常回应、是否有RST或ICMP不可达,能判断是会话级被丢弃还是链路层丢包。抓包配合 ss/netstat 查看连接状态更全面。
提交工单时请准备:1) 多点 mtr 或 traceroute 输出(最好包含TCP模式);2) ping 的时间序列(带时间戳);3) 抓包文件(.pcap)和关键筛选片段;4) BGP AS 路径截图或查询结果;5) 发生时间、持续时长、业务影响范围与复现步骤。清晰的证据能显著加快定位与响应。
常用命令集合:Linux:ping -c 10、traceroute -T -p 443 -n、mtr -rwzbc 100、tcpdump -w、tcptraceroute;Windows:ping -n 10、tracert -d -h 30、pathping、第三方 tcping.exe。在云或多节点场景下,建议在不同地域或VPS上并行测试以排除单点环境影响。
网络故障可能具有时变性与路径依赖性,仅一次检测可能误导结论。建议至少在不同时间点各做 3~5 次、每次 1~5 分钟的 mtr 或连续 ping,并在不同出口(内网、IDC、云节点)做对比。样本量取决于故障频率,短时突发故障可增加采样频率以捕获抖动。
整理成清晰的工单正文:时间窗口、影响范围、关键证据(附件:mtr/traceroute文本、pcap、BGP查询截图)、期望恢复时间和联系方式。标注“业务影响”和重现步骤,若涉及香港端或特定CN2出口,明确指出可疑AS或跳点编号,这样对方能直接在其网内进一步追踪。