tracert

逐跳显示到目标经过的路由器，定位路径中断和绕路。

补充说明

tracert 从 TTL=1 开始发 ICMP Echo Request，每经过一跳 TTL 减一，路由器回 ICMP Time Exceeded，从而暴露路径上的每一跳；到达目标后回 Echo Reply。默认最多 30 跳、每跳探测 3 次、等待 4000 毫秒，输出每跳的三次时延和解析出的名称。

边界：它只发 ICMP，很多防火墙和路由器对 ICMP 限速或不回复，星号不代表该跳一定故障。路径可能不对称，tracert 只显示去程；它也不能测 TCP/UDP 端口、应用层状态或二层设备。逐跳丢包统计用 pathping，端口连通用 Test-NetConnection 或 curl。

Windows 10/11 都自带该命令；Linux 的 traceroute 默认常用 UDP 探测，行为不同。-d 关闭反向解析能显著加快输出，-4/-6 明确协议栈，-h 限制跳数。目标只接受主机名或 IP，不能直接粘贴 URL。

常用示例

# 1. 默认跟踪到目标，最多 30 跳
C:\> tracert example.com

# 2. 关名称解析、限制 15 跳、每跳等 1 秒，快速看路径
C:\> tracert -d -h 15 -w 1000 example.com

# 3. 强制走 IPv4，避免名称优先解析到 IPv6
C:\> tracert -4 example.com

# 4. 强制走 IPv6，排查双栈环境下的另一条路径
C:\> tracert -6 example.com

# 5. 松散源路由只适合受控实验，多数网络会丢弃
C:\> tracert -j 192.168.1.1 10.0.0.1

易错点与排错

• 中间跳全是 * 但目标能 ping 通，通常是路由器不回复 ICMP 或做了限速；不要据此判断链路断开。用 pathping 看后续跳的统计，或直接测目标端口。
• 第一跳就是 * 不一定是网关故障，可能是本机防火墙拦 ICMP 或网关禁用了 TTL 超时回复；先 ping 网关，再看邻居和交换机端口。
• 把 https://example.com/path 直接交给 tracert 会解析失败；只保留主机名 example.com，端口和路径不属于 tracert 的范围。
• 路径每次运行可能变化，且去程和回程常不对称；tracert 只反映去程，不能拿它证明回程也走同一路径。
• 反向解析慢会让命令看起来“卡住”；生产排障先加 -d，确认路径后再决定是否解析名称。
• VPN、NAT、云负载均衡会隐藏真实路径，只显示隧道端点或公网边缘；要定位底层链路需在两端分别抓包或查云厂商探测工具。
• -w 设得太小会把正常的高时延跳显示成 *；默认 4000 毫秒是有原因的，跨洲链路不要盲目降到 200。

相关命令

• traceroute — Linux 的路径跟踪，默认探测方式与 Windows 不同
• mtr — 持续跟踪并统计逐跳丢包
• ping — 先确认目标是否可达
• nc — 测试路径终点的 TCP/UDP 端口

参考链接

• Microsoft Learn: tracert
• Microsoft Learn: pathping

读完自测

合上页面，先回答，再展开对照。

1. tracert 输出的 * 一定表示该跳故障吗？为什么？
2. 为什么 tracert 不能直接测 https://example.com/path？应该输入什么？
3. 去程 tracert 正常、回程却不通，可能吗？tracert 能证明什么？