线路慢在哪一跳：用 mtr 诊断三网回程

前置条件

开始之前，先确认这些都具备

• 能 SSH 登录服务器
• 一台在中国大陆的电脑（用于测去程），并知道它的公网 IP
• 知道自己宽带是电信、联通还是移动

操作步骤

共 8 步

1. 步骤 01 / 08

   先排除应用层的问题 #

   「网站慢」不一定是线路慢。curl 的分段计时会告诉你时间花在了哪里：DNS 解析、TCP 握手、TLS 协商，还是服务器生成响应（TTFB）。如果 connect 很快而 TTFB 很慢，那是应用或数据库的问题，跟机房线路无关。

   curl -o /dev/null -s -w 'dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n' https://example.com

2. 步骤 02 / 08

   量一次基础延迟与丢包 #

   一两个包看不出问题，跨境链路要打够数量才有统计意义。重点看最后一行的丢包率与延迟波动（mdev），抖动大比平均值高更影响体感。

   ping -c 100 203.0.113.10 | tail -n 3
   
   # 关注：
   #   packet loss  丢包率
   #   rtt min/avg/max/mdev  最后一个数值是抖动

3. 步骤 03 / 08

   测回程：从服务器打向中国大陆 #

   回程质量决定你在国内打开网站的体感，也是三网差异最大的地方。目标 IP 要用你自己宽带的公网出口地址（在家里的电脑上查出来），这样测的才是你真实会走的那条路。-z 打印 AS 号，-b 同时显示主机名与 IP，-w 宽格式，-c 100 打一百个包。

   # 在家里的电脑上先查出自己的公网 IP
   curl -4 -s ifconfig.me; echo
   
   # 在服务器上执行（把 IP 换成上一步得到的地址）
   sudo apt install -y mtr-tiny
   sudo mtr -zbrw -c 100 198.51.100.42

4. 步骤 04 / 08

   测去程：从大陆打向服务器 #

   在家里的电脑上跑同样的测试，方向相反。Windows 可以用 tracert 或图形化的路由测试工具，但要注意去程和回程的路径经常不对称 —— 只看一个方向就下结论，是这类排查里最常见的错误。

   # macOS / Linux
   sudo mtr -zbrw -c 100 203.0.113.10
   
   # Windows（信息较少，但足以看出在哪一跳延迟跳变）
   tracert 203.0.113.10

5. 步骤 05 / 08

   读懂输出里的 AS 号 #

   -z 打印的 AS 号能告诉你流量交给了谁。电信的精品线路（CN2 GIA）、联通的 AS9929、移动的 CMI 各自对应不同的骨干网，这也是 locations.ts 里每个机房都分三网标注延迟的原因。具体的 AS 号可以在 RIPE 或 RADb 上查证，不要凭记忆认定。

   # 判断回程线路类型的思路（AS 号请以 RIPE/RADb 查询结果为准）：
   #   · 出现电信 CN2 骨干的网段  -> 精品或优化线路
   #   · 出现联通 AS9929 的网段   -> 联通精品线路
   #   · 出现移动 CMI 的网段      -> 移动国际出口
   # 用 whois 逐跳确认，比任何记忆都可靠
   sudo apt install -y whois
   whois -h whois.radb.net 203.0.113.1 | grep -i origin

6. 步骤 06 / 08

   正确解读中间跳的丢包 #

   这是最容易误判的一点：中间某一跳显示 30% 丢包，而后续各跳都是 0%，说明那台路由器只是对 ICMP 做了限速，转发本身没有问题。只有当丢包从某一跳开始、并且一直延续到最后一跳，才是真正的链路问题。

   # 判定规则：
   #   中间跳丢包、末跳不丢  -> ICMP 限速，正常现象，不用管
   #   从某跳开始一路丢到末跳 -> 该跳之后的链路有问题
   #   末跳丢包、前面都正常   -> 目标主机自身或其防火墙策略

7. 步骤 07 / 08

   分时段测量，晚高峰才是真考验 #

   跨太平洋链路在北京时间晚上八点到十二点之间普遍变差，这是共性而非某一家机房的问题（locations.ts 里洛杉矶节点的说明就写了这一点）。凌晨测出的漂亮数字没有参考价值，要在自己业务真正的高峰时段测。

   # 把定时测量结果留档，对比不同时段
   mkdir -p ~/nettest
   ( date -Is; sudo mtr -zbrw -c 100 198.51.100.42 ) >> ~/nettest/backhaul.log 2>&1
   
   # 加进 crontab，每小时记一次（crontab -e）
   # 0 * * * * ( date -Is; /usr/bin/mtr -zbrw -c 50 198.51.100.42 ) >> /home/deploy/nettest/backhaul.log 2>&1

8. 步骤 08 / 08

   整理成一份能提交的工单 #

   写「很卡」的工单只能得到「已重启网络设备」的回复。附上双向 mtr 的完整输出、测试时间（含时区）、你的宽带运营商与所在省份，才可能定位到具体的骨干链路。这套材料也让你自己在换机房前先确认问题是否真在网络。

   # 工单里应当包含：
   #   1. 双向 mtr 完整输出（各 100 包）
   #   2. 测试时间与时区、持续了多久
   #   3. 本地运营商、所在省份、宽带类型
   #   4. 对比数据：另一个机房或另一条线路的同时段结果

相关教程

接下来通常会看这几篇