WinMTR
说明
WinMTR是 Linux mtr的Windows 移植简化版（GUI 工具），命令参数不如Linux mtr丰富，它把 ping 和 tracert 合二为一：像tracert一样逐跳追踪路径，同时像ping一样对每一跳持续探测，实时刷新丢包率、延迟统计。
用途与 Linux mtr 完全相同：定位丢包/延迟发生在路径上的哪一跳。
- 下载：White-Tiger/WinMTR（维护中的 fork，修复了中文编码/高 DPI 问题），解压即用，32/64位两个 exe
- 探测协议为 ICMP Echo；对不回包的沉默跳只标注不中断，继续探测后续跳，这正是它比pathping实用的关键。
基操
Host填目标（IP 或域名）→Start→ 表格实时滚动累计统计 →Stop停止；- 运行没有自动结束，人工 Stop；建议跑 2~5 分钟、每跳几百个包后再下结论（样本太少丢包率没意义）；
Copy HTML to clipboard导出 HTML 表格。Copy Text to clipboard：导出纯文本报告（mtr 风格），贴工单/笔记用；
Copy HTML to clipboard效果：
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| 192.168.16.3 - 0 | 10 | 10 | 0 | 0 | 0 | 0 |
| 110.80.172.1 - 0 | 10 | 10 | 2 | 5 | 11 | 2 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| 202.97.111.62 - 0 | 10 | 10 | 33 | 35 | 40 | 36 |
| 203.22.178.189 - 0 | 10 | 10 | 47 | 50 | 57 | 51 |
| 203.22.178.22 - 0 | 10 | 10 | 190 | 194 | 206 | 190 |
| 108.170.231.21 - 15 | 7 | 6 | 0 | 194 | 203 | 201 |
| 142.251.253.113 - 0 | 10 | 10 | 174 | 177 | 182 | 178 |
| 8.8.8.8 - 0 | 10 | 10 | 180 | 186 | 192 | 180 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider参数
四个参数
| 选项 | 说明 |
|---|---|
| Interval (sec) | 探测间隔，默认 1 秒（可调小加快采样，如 0.3） |
| Ping size (bytes) | 探测包大小，默认 64（调到 1472 可测满包/MTU 问题） |
| Max hosts in LRU list | 目标历史记录缓存上限（默认 100），一般不用改 |
| Resolve names | 是否解析主机名；取消勾选只显示 IP（等价 mtr 的 -n） |
输出 & 怎么读结果
| 列 | 说明 |
|---|---|
| Hostname | 节点主机名/IP（取决于 Resolve names 勾选） |
| Nr | 跳数（Number），从 1 开始。WinMTR 不显示本机行。 Nr 从 1 起算（第 1 跳 = 网关），本机只出现在表头；Linux mtr 同样从 1 起算、不列本机。"0 = 本机" 是 pathping 的行为（跃点 0 即源机） |
| Loss % | 该跳丢包率；文本导出无此独立列，拼在 Host 后面（如 192.168.16.3 - 0） |
| Sent / Recv | 已发送 / 已收到回复的探测包数 |
| Best / Avrg / Wrst / Last | 最低/平均/最高/最近一次延迟（ms）；GUI中Wrst拼写为Worst，文本导出为 Wrst |
判断逻辑与 mtr 类似
- 沉默跳
No response from host（全超时）- 延迟列全 0，是占位数据，读表时忽略；
- 只是该设备不回 ICMP，只要后续跳正常显示，链路就是通的------WinMTR 会越过它继续探测，不影响整体；
- 真假丢包
- 中间跳丢包高、后续跳恢复正常：该路由器 ICMP 限速，属于假丢包；
- 某一跳起持续丢包一直到目标：该跳之后的链路存在真实丢包；
- 网络质量
- 重点看最后几跳和目标的 Loss%，那才反映端到端真实质量。
- WinMTR 没有Linux mtr 的 StDev（标准差）列，判断抖动只能对比 Best 和 Wrst 的差值。
局限
- 仅 ICMP 探测，不能像Linux mtr 那样换 TCP/UDP（
-T/-u）模拟业务流量； - 只有 GUI + 剪贴板导出，无命令行/JSON，不便脚本化（脚本化需求用 WSL2 里的原生
mtr，注意路径从 WSL 虚拟网卡起算，前几跳与宿主机不同）； - 参数比Linux mtr 少（无 AS 号
-z、MPLS-e等高级功能）。
Pathping（现代网络不合适）
说明
Windows自带的tracert+ping二合一，但与mtr思路不同，是两阶段静态报告：（阶段1）先整段发现路径，（阶段2）再对已发现节点逐跳ping统计，默认100包/跳、250ms间隔 ≈ 25 秒/跳），最后一次性输出文本报告。慢是它的固有特点。
基操
参数
| 参数 | 说明 |
|---|---|
-n |
不解析主机名（建议始终加） |
-h 跳数 |
最大跃点数（默认 30） |
-q 次数 |
每跳探测包数（默认 100） |
-p 毫秒 |
探测间隔（默认 250） |
-w 毫秒 |
回复超时（默认 3000） |
-i 地址 |
指定本机源地址；-4/-6 强制 IPv4/IPv6 |
官网示例：正常情况
我本机就测试没成功过，这是来自官网的示例：
D:\>pathping /n contoso1
Tracing route to contoso1 [10.54.1.196]
over a maximum of 30 hops:
0 172.16.87.35
1 172.16.87.218
2 192.168.52.1
3 192.168.80.1
4 10.54.247.14
5 10.54.1.196
computing statistics for 125 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct address
0 172.16.87.35
0/ 100 = 0% |
1 41ms 0/ 100 = 0% 0/ 100 = 0% 172.16.87.218
13/ 100 = 13% |
2 22ms 16/ 100 = 16% 3/ 100 = 3% 192.168.52.1
0/ 100 = 0% |
3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.168.80.1
0/ 100 = 0% |
4 21ms 14/ 100 = 14% 1/ 100 = 1% 10.54.247.14
0/ 100 = 0% |
5 24ms 13/ 100 = 13% 0/ 100 = 0% 10.54.1.196
Trace complete.分析
0 172.16.87.35
1 172.16.87.218
2 192.168.52.1
3 192.168.80.1
4 10.54.247.14
5 10.54.1.196
computing statistics for 125 seconds...-
第一阶段得到6条，其中第0条是自己。
-
第二阶段逐跳进行：先对Hop1发100个探测（默认 -q 100、-p 250ms ≈ 25 秒），测完再测Hop2 ...
-
5跳 × 25秒 = 125秒，和输出的
computing statistics for 125 seconds正好吻合。Hop RTT Source to Here This Node/Link 地址
1 41ms 0/100 = 0% 0/100 = 0% 172.16.87.218 ← 节点行（路由器本身）
13/100 = 13% | ← 链路行（1→2 之间的链路）
2 22ms 16/100 = 16% 3/100 = 3% 192.168.52.1 ← 节点行
0/100 = 0% | ← 链路行（2→3）
... -
节点行（带 RTT 和地址）的This Node/Link： 这个路由器本身的丢包率；
-
链路行（只有数字 + |）的This Node/Link： 上一跳地址到下一跳地址之间那条链路的丢包率（| 就是表示"链路"的示意）；
-
Source to Here：从源主机到该节点为止的累计丢包率。
Hop: 1 2 3 4 5
S2H: 0% → 16% → 13% → 14% → 13%
↑
唯一一次抬升 -
Hop1 下面那行 13/100 = 13% |：172.16.87.218 → 192.168.52.1 这条链路丢了13%
-
Hop2 节点3%：192.168.52.1 这个路由器自己丢3%；
-
Hop2 的 Source to Here = 16% ≈ 13%（前面链路）+ 3%（本节点），就是"从源到这里累计丢了多少"；
-
再往后：链路行全是 0%，Source to Here 在 13%~14% 徘徊------没有新增丢包，到目标（Hop 5）仍是 13%。
说明：端到端真实丢包 ≈ 13%，全部发生在链路 1→2这一段。
致命弱点：对沉默跳零容忍（实测）
本机示例1：异常情况
shell
pathping -n 8.8.8.8 # -n 不解析主机名
通过最多 30 个跃点跟踪到 8.8.8.8 的路由
0 192.168.52.28
1 * * *
正在计算统计信息，已耗时 0 秒...
指向此处的源 此节点/链接
跃点 RTT 已丢失/已发送 = Pct 已丢失/已发送 = Pct 地址
0 192.168.52.28
跟踪完成。本机示例2：tracert
同一环境下tracert能一路探到目标，WinMTR也能越过沉默跳正常统计（前面WinMTR截图就是在同一环境下测试的）。
tracert -d 8.8.8.8
通过最多 30 个跃点跟踪到 8.8.8.8 的路由
1 * * * 请求超时。
2 <1 毫秒 <1 毫秒 <1 毫秒 192.168.16.3
3 3 ms 3 ms 3 ms 110.80.172.1
4 * * 2 ms 220.160.92.57
5 * * * 请求超时。
6 21 ms * * 202.97.28.221
7 * * * 请求超时。
8 * * * 请求超时。
9 34 ms 33 ms 33 ms 202.97.111.62
10 48 ms 48 ms 47 ms 203.22.178.189
11 193 ms 267 ms 195 ms 203.22.178.22
12 184 ms 193 ms 192 ms 108.170.231.21
13 177 ms 176 ms 176 ms 142.251.253.113
14 180 ms 180 ms 182 ms 8.8.8.8
跟踪完成。差异
tracert和pathping两者的路径发现机制相同：TTL递增 + 中间路由器返回 ICMP Time Exceeded，逐跳发现路径（Windows tracert 默认以 ICMP Echo 作探测包）。差异在于对单跳无响应的容错性：
- pathping：第一阶段先建立路径，第二阶段对这条路径做统计；当某跳拿不到 hop 信息时，路径可能无法继续建立，后续节点不会进入统计阶段（示例1第1跳
* * *后即终止） - tracert：某跳全部超时（显示
*）只是该跳信息缺失，不影响继续递增TTL探测后续跳，路由表仍然完整（示例2第 1/5/7/8 跳*，仍一路探到第 14 跳目标）
实际公网中间路由沉默/限速非常普遍，所以pathping对公网目标大概率显示不完整。尤其在公司网关禁用 ICMP 时甚至只剩一行。
为什么这样
这个差异是历史产物：pathping 是 NT 时代工具，面向当年 ICMP 相对开放的企业内网，"先建拓扑再统计"在那种环境合理；现代公网路由器的主职是转发业务包，回应 ICMP Time Exceeded 是次要工作（普遍限速/丢弃/不生成），中间路由沉默是常态而非异常，两阶段架构因此水土不服。
结论
pathping
- 追求"先把拓扑搞清楚，再做统计"。它的核心卖点是丢包归因（节点 vs 链路），必须先有一份完整明确的路径模型；拓扑发现失败 → 统计基础不存在 → 后面全部无法进行。
- 系统自带、无需安装；在网关友好环境（如内网排查、网关开了 ICMP）能用它独有的链路级丢包分析（同时给出节点丢包和链路丢包，这点 mtr 也没有）；
Linux mtr/WinMTR/tracert
- 追求"只要最终目标可达，就尽量继续递增 TTL"。沉默跳标记
?（或*）跳过，后面的路径照常探出。天然适应沉默跳普遍的公网。 - WinMTR自动越过沉默跳，实时刷新，逐跳丢包统计；
ICMP本身弱可靠，测试可以依赖业务流量
路由器对各类ICMP（Echo / Time Exceeded / Unreachable）都可能限速，而TCP 443、UDP 等业务流量正常转发。所以ICMP探测工具测的是"路径上设备对 ICMP 探测的响应行为"，不等于"业务流量的实际质量"。判断线路质量不能只凭 tracert/pathping，
- 在windows中，可以组合：WinMTR长时间统计 + 长时间ping + 实际业务流量（如 scp）。
- 在linux中，可以用mtr，换探测协议模拟业务：
mtr -T -P 443 8.8.8.8（TCP SYN）或mtr -u（UDP）。
注意：探测包变了，但中间跳的响应仍是ICMP Time Exceeded（TTL 耗尽的路由器行为，与探测协议无关），中间跳照旧受 ICMP 限速影响；换协议的意义在于让目标端探测与业务同类，目标丢包/可达性的测量更有业务参考价值，还能发现中间防火墙对特定端口的拦截。