MTR 网络诊断教程：双向路径、丢包误判与报告
MTR 把 traceroute 的路径发现与持续探测结合起来，用于观察每一跳的往返延迟和响应情况。 它能帮助缩小故障范围，但不能仅凭某个中间节点显示 100% 丢包，就断定该节点故障或 IP 被封锁。
MTR 官方仓库明确提醒：中间路由器可能不回应或限制 ICMP 响应。只要后续节点和最终目标正常，中间一跳的高丢包往往只是控制面限速，不代表转发流量真的丢失。
安装 MTR
Debian 或 Ubuntu：
sudo apt update
sudo apt install -y mtr-tinyRocky Linux、AlmaLinux 或当前 RHEL 系列：
sudo dnf install -y mtrmacOS 可以通过 Homebrew 安装：
brew install mtrWindows 用户可使用 WinMTR 官方项目，或在 WSL 中运行 Linux 版。下载网络诊断工具时优先使用项目官方仓库和系统包管理器。
生成一份可分享的报告
把 example.com 替换为你有权测试的域名或 IP：
sudo mtr --report --report-wide --report-cycles 100 example.com参数含义：
--report：完成指定次数后退出，不进入交互界面--report-wide：保留较完整的主机名，方便工单分析--report-cycles 100：每一跳发送一百轮探测，减少少量样本的偶然性
需要排除 DNS 解析时间和名称变化时，加 --no-dns：
sudo mtr --report --report-wide --report-cycles 100 --no-dns 198.51.100.5用接近业务的协议测试
默认探测与真实 HTTPS 请求可能经过不同策略。网站访问异常时，可以补一组 TCP 443 路径报告：
sudo mtr --tcp --port 443 --report --report-wide --report-cycles 100 example.com这仍不是完整的网页性能测试。DNS、TLS、应用和数据库耗时要用真实 HTTP 请求另行测量。
一定要采集双向路径
互联网路由常常不对称。本地到 VPS 的路径，与 VPS 返回本地的路径可能不同。
采集两份报告：
- 在用户网络运行 MTR，目标填写 VPS 地址。
- 在 VPS 运行 MTR，目标填写用户网络的可探测地址。
家庭宽带地址可能不响应探测，此时可选择同运营商、同地区且你有权测试的稳定目标。报告中注明替代目标，不能把它当成完全相同的回程路径。
怎样判断丢包是否真实
| 报告现象 | 更合理的解释 |
|---|---|
| 中间一跳高丢包，后续和目标正常 | 该路由器可能限制探测响应，不能据此判故障 |
| 某一跳开始丢包，后续每跳和目标持续相近丢包 | 这一段或之后可能存在转发问题，需要更多时段和协议复测 |
| 最终目标不响应，但网站正常 | 目标可能禁止探测，应用可用性应以真实请求为准 |
| 延迟从某一跳升高，之后一直保持 | 可能跨越长距离、换运营商或出现拥塞，需要结合节点位置判断 |
| 只有高峰时延迟和目标丢包升高 | 更像容量或拥塞问题，应保留高峰与低峰对照 |
不要用单次十轮报告给线路下结论。故障如果是间歇性的，应在异常窗口持续采集，并同时记录真实业务请求失败率。
提交工单时附上什么
- 问题开始和结束时间，写明时区
- 来源网络、来源地区和目标 IP
- 正向与反向 MTR 原始文本
- 高峰与低峰对照报告
- ICMP 与 TCP 443 的差异
- 真实业务的错误码、超时或请求耗时
- 是否只有一个运营商、地区或协议受影响
隐藏与你的故障无关的内部地址和账号信息，但不要截图裁掉跳数、时间和列名。纯文本比模糊截图更便于比较。
MTR、ping 和 iPerf3 怎样配合
ping 用于持续观察目标往返延迟，MTR 用于检查路径，iPerf3用于两台自有主机之间的吞吐测试。三者都不能单独代表网站用户体验。
选择 VPS 机房时，先从当前机房目录建立候选，再用同一来源网络、同一时段和同一测试方法比较。节点名称或一次测试结果都不是长期可达性承诺。