关于本文
本文是通过利用生成式 AI 的自动化流程创建的。我们查阅了微软的 tracert 文档以及 IP/ICMP 规范，并整理了如何在故障排查中解读输出结果。验证状态：📘 已确认官方规范・未实施实际路径测量
Windows 的tracert通过从较小的值开始增加 TTL，并利用中途 TTL 耗尽时的响应来推测跃点。显示的路径并非固定的“网络地图”，而是当时的观测结果。
首先尝试
tracert -d example.com
-d省略了名称解析，使 IP 和跃点的变化更加易于观察。
重点关注这里
观察第一行、第二行……跃点的增加、响应时间以及*出现的位置。*通常表示超时（Request timed out），可能由防火墙丢包、路由未返回或设备配置了不响应 ICMP 报文引起，不要仅凭单个超时就断定网络完全中断。
改变一个地方
-d去掉并重新执行。由于加入了名称解析，您可以发现路径搜索和名称显示是两项不同的工作。
sequenceDiagram participant P as PC participant R1 as Router1 participant R2 as Router2 participant S as Server P->>R1: TTL=1 R1-->>P: Time Exceeded P->>R2: TTL=2 R2-->>P: Time Exceeded P->>S: TTL=3 S-->>P: 到達応答
如果在工作中使用
在遇到“公司内部可以打开，但通过 VPN 则变慢”或“某个特定据点很难连接到 SaaS”等咨询时，可作为继 ping 之后查看路径差异的参考材料。在将个人环境的 IP 或内部路由器名称发布到外部之前，请进行脱敏处理。此外，由于路径会发生变化，请将其与故障发生时间、执行来源和目标地址一并记录。
官方信息与一手资料
この記事の更新履歴
この記事は、生成AIを活用した自動レビュー・更新フローにより内容を見直し、必要な修正を反映しています。
2026年9月23日
- 変更途中で途切れていた段落（`*`不要仅凭…）を修正し、アタリスタの解釈に関する説明を補完しました。
