路由和丢包测试：Ping、MTR 与 Traceroute

1. 每种工具回答一个问题#

Ping 看往返延迟和是否收到应答，Traceroute 展示探测经过的节点，MTR 连续探测这些节点，方便观察丢包是否一直延续到终点。它们测的是特定时间、来源、目标和协议下的表现，不能直接代表所有用户的下载速度。

读图时先看目标地址、测量时间和测试次数，再看 Loss（未收到应答的比例）、Avg（平均延迟）、Best/Worst（最好/最差）以及 StDev（波动）。不同地区的物理距离不同，不要把美国本地的 1 毫秒和跨洋的 180 毫秒直接判成好坏。

2. 先做一组短 Ping，记录网络和时间#

在自己的电脑上测试服务器地址；Windows 的次数参数是 -n，Linux/macOS 是 -c。示例地址需要替换。

ping -c 20 203.0.113.10

记录“家用电信宽带、北京时间 21:00、20 次探测”。如果换手机热点后结果不同，说明差异与访问路径有关。一次探测超时并不能证明故障；重复短测试仍持续丢包，才值得进一步追踪。

3. 用 MTR 看丢包从哪里开始延续#

Ubuntu/Debian 可从系统软件源安装 mtr-tiny。在自己的终端或服务器运行，目标换成允许测试的地址。-r 输出报告，-w 展开名称，-c 50 限制次数，-n 使用数字地址减少 DNS 干扰。

sudo apt update
sudo apt install mtr-tiny
mtr -rw -c 50 -n 203.0.113.10

如需贴近 HTTPS 流量，可使用 TCP 探测；部分系统需要 root 权限，端口也必须是目标实际开放的服务。

sudo mtr --tcp --port 443 -rw -c 50 -n example.com

某个中间节点 80% 丢包，后面节点和目的节点却是 0%，通常表示该节点限制探测应答，不代表转发了 80% 的业务丢包。更值得关注的是：某一跳开始丢包，后续各跳直到目标也出现相近丢包，并且实际应用同时受影响。路由不对称、负载均衡和 ICMP 限速仍可能影响解释，不能据此精确断定某台路由器损坏。

4. 分开看去程和回程#

本地电脑到 VPS 的测试是去程；从 VPS 到本地可达测试点的测试是反方向。两条路径可能完全不同。家庭网络在 NAT 后面时，服务器未必能直接探测家中设备，可以使用自己控制的另一个测试节点，或服务商提供的 Looking Glass。

Traceroute 中出现星号只是未在等待时间内收到该跳应答。如果后续跳和终点仍能到达，不要把星号当作链路中断。IP 的地理数据库与运营商标注也可能不准，应结合 ASN、官方线路说明和实际体验。

5. 把报告变成可处理的故障信息#

至少保留一次正常和一次异常测试，尽量使用相同目标、协议、次数和网络。报告应包含开始时间与时区、源网络、目的 IP/端口、MTR 文本以及真实业务现象，例如视频卡顿、文件传输断开或 SSH 停顿。

向公开论坛发帖时隐藏自己的地址和账户信息；给服务商工单可以提供处理所需的实例编号。不要连续长时间运行几十个测速任务，它们会占用带宽和流量。下一步按连通性排障定位服务，或按下载与带宽测试测实际吞吐。