丢包测试：ping、mtr、traceroute 怎么配合

丢包定位的关键是双向取证：本地往服务器跑一遍，再登录服务器往回跑一遍。单方向的结果只能说明一半问题，去程丢和回程丢，责任段经常不同。 准备条件 两端都要能跑命令。本地和服务器各装一套工具：CentOS 用 yum install -y mtr traceroute，Ubuntu 用 apt install -y mtr traceroute。mtr 需要 root 权限，直接加 sudo 跑最省事。记下服务器 IP，并在服务器上用 curl ifconfig.me 查到自己的公网出口备用。报告模式的输出是纯文本，直接贴进工单或存档都方便。 第一步：ping 概览 先 ping 网关排除自家路由器，再 ping -c 20 服务器IP 看丢包率和延迟的稳定性。0% 丢包就不必折腾；丢包率超过 1% 或延迟忽高忽低，进入下一步。ping 不通也别急着下结论，有的服务器禁了 ICMP，直接进 mtr 看更实际。 第二步：traceroute 看路径 traceroute -n 服务器IP -n 参数跳过反向解析，输出更快。记录完整路径和总跳数，后面的 mtr 报告要对着这份路径读，每一跳的归属（本地、运营商、机房）心里先有个数。 第三步：mtr 双向各跑十分钟 本地执行： mtr -rw -c 600 服务器IP > 去程.txt 再登录服务器，对本地的公网出口 IP 跑同样命令，得到回程报告。-rw 是报告模式，-c 600 即发 600 个包，几分钟跑完，样本量足够说明问题。跑的时段要避开自己同时在下载或备份，自己制造的流量会污染结果。 第四步：读报告 判读规则的核心只有一条：中间某跳丢包、但其后各跳和终点恢复正常，多半是该节点的 ICMP 限速，不算真丢包；丢包从某一跳出现并一直延续到最后，那一段才是真凶。举个例子：第 4 跳 Loss 60%、第 5 跳起恢复 0%，是限速假象；第 3 跳起持续 Loss 20% 直到终点，问题就在第 3 跳之后。把去程和回程报告并排放，责任段通常一目了然。两份报告都留档，报障时一并附上，处理的人不用再猜方向，能快一半。报告里 Host 列显示 ??? 是反向解析失败，加 -n 全部用 IP 显示更清爽。 常见报错与处理：mtr 提示 Operation not permitted 是权限不足，加 sudo；traceroute 某跳显示 * * * 是该节点不响应探测，看后续跳即可，不必纠结。