专线类报修里，“网络时好时坏”是一类难处理的问题——测试时正常、投诉时又出问题。有效的做法不是多测几次，而是把取证做完整：确定丢包发生在哪一段、抖动与什么时间相关、内网侧是否已经排除。拿着这套数据去提工单，运营商侧的定位效率会明显不同。在东创伟业处理过的山西本地专线报修里，这类“测着正常、用着掉线”的案例，根因大多卡在分段没做清。
一、先分清四段：定位的本质是分段
一次访问从终端到目标系统，大致经过四段：
终端到内网网关（内网无线、交换）；
内网网关到运营商接入设备（出口路由器与光猫、光端机之间的链路）；
运营商网络内部（城域、骨干、跨网互通）；
目标系统侧（对端服务器、云端业务、CDN 节点）。
排查原则：从近到远逐段测，先证明内网没问题，再谈运营商。
二、基础测试（Windows 环境）
内网网关测试，确认内网无丢包：
ping -n 100 192.168.1.1
关注丢包率、平均时延、峰值时延（抖动看峰值与平均值的差）。
带包长测试，发现 MTU 与分片问题：
ping -n 50 -l 1400 223.5.5.5
ping -n 50 -l 1472 -f 223.5.5.5
其中 -l 指定数据长度，-f 设置不分片；如果小包通、大包不通或者带 -f 不通，多与 MTU、PPPoE 封装有关。
路径测试：
tracert -d 目标地址
其中 -d 不解析域名，输出更快；看时延在哪一跳开始明显抬升。
综合统计：
pathping 目标地址
会给出逐跳的丢包统计，适合给不太熟悉命令行的人看结果。
三、MTR：定位效率较高的一步
MTR 把 ping 与 tracert 结合，能直接给出每一跳的丢包与时延，是定位运营商侧丢包的主要工具。
Linux 下：
mtr -rwzc 100 目标地址
参数含义：-r 报告模式、-w 宽输出、-z 显示 ASN、-c 包数。
Windows 可用 WinMTR 等图形化工具，输出列含义一致：
Loss%：该跳的丢包比例。
Avg / Best / Wrst：平均、低值、高值时延（Wrst 减 Avg 反映抖动）。
StDev：时延标准差，越大说明抖动越明显。
判读要点：
某一跳开始持续丢包且后续各跳同样丢包，故障点大概率在该跳或其上游；
中间某跳丢包但后续正常，多为该设备对探测报文限速（ICMP 限速），不能作为故障证据；
只有最后一跳丢包，多为对端限制 ICMP，应改用业务层测试（HTTP 请求、实际业务操作）确认。
四、内网侧自检（提工单前必须做）
出口设备负载：CPU、内存、会话数是否接近规格（会话数打满的问题可单篇另讲）；
内网是否有泛洪：二层广播风暴、组播泛洪都会表现为出口侧丢包（相关排查另篇展开）；
光模块与收发光功率（专线经光纤落地时）：
display transceiver interface GigabitEthernet 0/0/x
关注接收光功率是否在模块允许范围内；光衰过大、尾纤弯折、法兰头污染都会导致误码；
端口错误计数：
display interface GigabitEthernet 0/0/x
关注 CRC 错误、错包、up/down 次数，持续增长说明物理层有问题；
双线与主备切换：主备链路切换瞬间的丢包，应与切换日志时间对齐后再判断是否误报。
五、时间相关性分析
抖动类问题要和时间对上，建议记录：
故障发生的具体时段，用来判断是否为高峰拥塞；
影响范围（单业务、全网、单终端），用来判断是否链路问题；
当时的出口带宽利用率，用来判断是否容量问题；
当时的会话数与 CPU，用来判断是否设备规格问题。
如果丢包只出现在固定时段且与出口利用率曲线吻合，方向是容量而不是链路质量；如果全天随机出现且与利用率无关，方向是链路物理层或运营商侧。
六、处理动作与回退
内网泛洪：按二层广播风暴、组播泛洪的思路处理，验证内网侧丢包消失；
光衰、误码：清洁法兰头、更换尾纤或光模块，验证端口错误计数停止增长；
MTU 不匹配：调整出口 MSS、MTU（PPPoE 场景常见），验证大包带 -f 测试通过；
容量不足：按峰值复核带宽规格并扩容，验证高峰利用率留有余量；
双线切换：核对切换策略与告警阈值，验证切换时间与日志对齐；
运营商侧：提交工单并附完整取证，验证运营商回单后复测。
提工单材料清单：故障时段、源目 IP、MTR 报告（含 -c 100 以上包数）、ping 统计截图、内网侧自检结论（已排除内网的说明）、光模块收发光功率。
七、避坑小结
中间跳丢包不等于故障，要区分 ICMP 限速与真实丢包；
一次 ping 不能当结论，抖动的判据是多次采样的分布；
只测公网 DNS 不够，要测实际业务地址；
先排除内网再报障，否则工单会在来回确认中消耗时间；
取证要留原始数据，包括命令与时间戳，便于复现与对比。
速查：
ping 网关就丢包，优先查内网无线、交换侧；
大包不通小包通，优先查 MTU、分片与 MSS；
高峰时段抖动，优先看带宽利用率与容量；
全天随机丢包，优先查光模块、链路物理层；
仅最后一跳丢包，改用业务层测试确认；
切换瞬间丢包，核对主备切换日志。
常见问题（FAQ）
Q：ping 有丢包是不是一定线路有问题？
A：不一定。要分位置看：ping 内网网关就丢包，属于内网问题；中间跳丢包但后续跳正常，多为该设备对 ICMP 限速；只有最后一跳丢包，多为对端限制 ICMP，需要用实际业务（打开业务系统、发起请求）来验证。真正需要报障的判据是：从某一跳开始持续丢包，且之后各跳都受影响。
Q：MTR 报告要跑多少包才有说服力？
A：一般不少于 100 包，抖动类问题建议 200 包以上并分多个时段采样。包数太少时偶然丢包会被放大，无法区分随机丢包与持续丢包。提交运营商工单时，附上不同时段的两到三份报告更有说服力。
Q：视频会议卡顿但下载正常，是带宽不够吗？
A：不一定。视频会议对时延与抖动的敏感度高，对带宽的敏感度相对低。若下载能跑满带宽而会议卡顿，方向应是抖动与丢包，而不是总带宽。建议按本文做分段 MTR，并结合会议软件自带的网络质量统计（时延、抖动、丢包）一起判断。
