traceroute笔记

本文最后更新于 2026年10月16日 上午

Traceroute 核心定义

traceroute 是用于逐跳探测数据包从本机到目标 IP 完整三层转发路径的诊断工具。

核心目的：

  • 定位丢包节点
  • 定位延迟突增节点
  • 判断路由转发路径
  • 判断中间防火墙/ACL/ICMP 管控策略

底层机制：TTL 逐跳递减（与上层协议无关）

TTL 转发规则（所有三层设备通用）

  1. IP 报文每经过一台三层设备（路由器/防火墙三层口），TTL 自动 -1
  2. 若 TTL 减完 > 0：正常查路由继续转发
  3. 若 TTL 减完 = 0：直接丢弃报文，并回复 ICMP 超时（Time Exceeded）

核心触发逻辑与上层协议无关

只要 IP 包的 TTL 减为 0，三层设备就会强制丢包并回复 ICMP Time Exceeded——无论包里封装的是 UDP、TCP 还是 ICMP。

这是 traceroute 能拿到每一跳 IP 的根本原因。三种探测模式（UDP/TCP/ICMP）只是改变了「探测包类型」和「终点判定方式」，逐跳发现的触发机制完全一致。

标准探测流程（通用逻辑）

  1. 第一组包：TTL=1 → 第一跳设备 TTL 归 0 → 回 ICMP 超时 → 记录第一跳 IP
  2. 第二组包：TTL=2 → 第二跳设备 TTL 归 0 → 回 ICMP 超时 → 记录第二跳 IP
  3. 持续 TTL+1 递增探测
  4. 直到抵达目标主机并收到终点合法回包 → 终止探测
  5. 若达到最大跳数上限仍无终点回包 → 强制终止

关键 ICMP 报文类型

ICMP 报文头部只有 Type 和 Code 两个数字字段，「超时」「端口不可达」是 Type+Code 组合的名字，不是报文里的文字内容。traceroute 全程依赖三种关键报文：

报文 Type Code 发出者 触发时机
超时 Time Exceeded 11 0 中间三层设备 TTL 减为 0，丢弃报文时
端口不可达 Port Unreachable 3 3 目标主机传输层 UDP 报文到达无进程监听的端口时
回显应答 Echo Reply 0 — 被 ping 的目标主机 收到 Echo Request 时

「端口不可达」的含义：目标主机传输层收到 UDP 报文后查找监听端口，发现没有任何程序监听，协议栈就回一个 Type 3 / Code 3 的 ICMP 差错报文，意思是「报文送到了，但你指定的端口没人接收」。

另一个关键细节：ICMP 差错报文的数据部分会附带「引发差错的原始 IP 头 + 原始报文前 8 字节」（对 UDP 探测包来说正好是完整 UDP 头部：源端口+目的端口+长度+校验和）。traceroute 就是靠这段附带的原始报文，把每个 ICMP 回包和自己的探测包一一对应起来。

三种探测模式：UDP、TCP 与 ICMP

三种模式的逐跳回包机制相同（TTL 耗尽，中间设备回 ICMP 超时提供跳 IP），差别只在于三点：探测包类型、终点判定方式、防火墙穿透能力。

UDP 模式（Linux 默认）

探测特征：

  • 探测包：UDP 报文
  • 目标端口：从 33434 开始逐包递增

完整收尾逻辑：

  1. 中间路径：TTL 不足 → 设备回 ICMP 超时
  2. 当 TTL 足够大，报文成功抵达目标主机传输层
  3. 33434~33534 区间端口系统默认无程序监听
  4. 目标主机返回 ICMP 端口不可达
  5. traceroute 识别到这是终点主机发来的报错 → 判定抵达终点 → 终止探测

UDP 模式终止标志：收到目标主机的 ICMP 端口不可达。

核心总结：UDP 靠「目标端口必然不通」的特性，用端口不可达包告诉程序：你已经走到头了。

TCP 模式（生产排障最实用）

命令示例（需要 root 权限）：

1
traceroute -T 目标地址 -p 目标端口
  • -T：使用 TCP SYN 探测
  • -p：指定目标端口，可任意指定业务端口（80、443、22）

探测特征：

  • 探测包：TCP SYN 包
  • 逐跳触发逻辑不变：TTL 耗尽仍由中间设备回 ICMP 超时报文获取跳 IP

两种终点收尾逻辑：

  1. 目标端口开放
    • 目标主机回复 SYN+ACK
    • 工具识别成功握手包 → 判断抵达终点 → 终止
  2. 目标端口关闭
    • 目标主机回复 RST
    • 同样判定抵达终点 → 终止

TCP 与 ICMP 探测的根本区别：很多设备会拦截 ICMP，但放行业务 TCP 端口。ICMP 探测包被拦就寸步难行，而 TCP 探测借助业务端口可以探得更远：

  • 绕开仅拦截 ICMP 的设备，看到被 ICMP 探测隐藏的后续链路
  • 反向利用：如果 ICMP 探测能通、TCP 探测从某一跳开始不通，即可精准定位拦截 TCP 流量的 ACL 或防火墙节点

一句话：企业网、防火墙普遍拦截 UDP 探测、拦截 ICMP 超时，但不会拦截业务 TCP 端口，所以生产排障优先 TCP traceroute。

Windows 下怎么做 TCP 探测？ 系统自带的 tracert 只支持 ICMP 模式，没有 traceroute -T。可以用我写的开源工具 TCPTrace：基于 nexttrace 封装的图形化 TCP SYN 路径追踪工具，单文件免安装、双击即用（自动请求管理员权限），输入目标 IP/域名和端口即可实时看到逐跳时延与应答率，追踪结束后还会对目标端口做 TCP 握手测试，给出「通 / 半通 / 不通」判定，并可一键复制纯文本报告贴工单。

另一个方法是 WSL：装好 WSL（如 Ubuntu）后，可以直接使用 Linux 原生的 traceroute -T（需要 sudo/root 权限）：

1
sudo traceroute -T 目标地址 -p 目标端口

网络模式说明：WSL2 配置为**镜像模式（mirrored）**时，WSL 直接共用 Windows 宿主机的网络栈，探测路径与宿主机真实路径一致，可以放心用；若是默认的 NAT 模式，探测包要先经过 WSL 虚拟网关、再由宿主机 NAT 转发出去，第一跳显示的是 WSL 内部网关 IP，比宿主机直发多出一跳虚拟网关。

ICMP 模式（Windows tracert 默认）

探测特征：

  • 探测包：ICMP Echo Request（就是 ping 包）
  • 逐跳逻辑：中间设备 TTL 耗尽回 ICMP 超时报文提供跳 IP，目标主机回复 Echo Reply（回显应答）判定终点
  • Linux 下用 traceroute -I，需要 root 权限；Windows 的 tracert 默认就是这种模式

终点收尾：报文抵达目标主机 → 回 Echo Reply → 判定抵达终点 → 终止探测。注意和 UDP/TCP 模式不同，它靠的是「正常应答」而不是「差错报文」。

中间设备对 ICMP 探测的两种典型行为（直接决定 trace 结果形态）：

  1. 禁 ICMP 响应，但放行转发
    • 设备不回 ICMP 超时，但探测包继续被转发到下一跳
    • 表现：中间若干跳显示星号 * * *，后续跳恢复正常，最终仍能 trace 通到目标
  2. 直接丢弃 ICMP 包
    • 探测包根本过不了这一跳
    • 表现：从拦截跳开始，整条路径全部超时，看不到后续任何链路

弱点：ICMP 报文在公网被拦截最普遍，很多防火墙整体丢弃 ICMP，所以 tracert 的星号往往比 UDP/TCP 探测更多。

Windows tracert 常用用法：

1
2
3
4
tracert www.baidu.com         # 默认：ICMP Echo Request，最大 30 跳，每跳发 3 个探测包
tracert -d www.baidu.com      # 不做反向域名解析，每跳只显示 IP，速度更快
tracert -h 15 www.baidu.com   # 最大跳数改为 15（默认 30）
tracert -w 1000 www.baidu.com # 每个回包的超时改为 1000ms（默认 4000ms）

其他探测方式：现代 traceroute 还支持一些冷门变体（如 UDP-Lite -UL、-M tcpconn、-P 指定其他 IP 协议），衍生工具有 mtr（traceroute+ping 实时刷新）、tcptraceroute（老牌 TCP 探测工具）。日常排障掌握 UDP/TCP/ICMP 三种即可。

三种模式对比表

维度 UDP Traceroute TCP Traceroute ICMP Traceroute（tracert）
探测报文 UDP TCP SYN ICMP Echo Request
默认端口 33434 起逐包递增 自定义业务端口 无端口概念
中间回包 ICMP 超时 ICMP 超时 ICMP 超时
终点成功标识 ICMP 端口不可达 SYN+ACK（端口开放）/ RST（端口关闭） Echo Reply
Linux 权限 普通用户 root root
穿透防火墙 差 极强 最差（ICMP 常被整体拦截）
适用场景 公网通用测试 企业内网、防火墙环境 Windows 环境、快速验证连通性

每一跳显示的 IP 到底是什么（高频误区）

所有跳数展示的 IP，都是该设备的「入三层接口 IP」：

  • 是数据包进入设备的接口 IP
  • 不是出接口 IP

意义：

  • 同一台路由器多链路组网时，不同路径探测会显示不同 IP
  • 可以精准判断流量从哪个接口进入上行设备

终点判定与终止条件

TTL=0 抵达目标主机的特殊场景

严格区分两种完全不同的情况：

情况 A：包到达目标主机时，TTL 刚好减为 0

  • 目标主机直接丢包
  • 返回 ICMP 超时
  • traceroute 不认为到达终点！继续 TTL+1 探测

情况 B：包到达目标主机时，TTL ≥ 1

  • 报文正常进入传输层
  • UDP：返回 ICMP 端口不可达；TCP：返回 SYN+ACK 或 RST；ICMP：返回 Echo Reply
  • 判定终点，探测结束

一句话核心真理：

  • ICMP 超时 = 中途设备/终点 TTL 耗尽（不算到终点）
  • ICMP 端口不可达 / TCP 握手包 / Echo Reply = 真正抵达终点

两种合法终止条件

条件 1：正常终止（探测成功），收到目标主机返回的任意一种：

  • UDP 模式：ICMP 端口不可达
  • TCP 模式：SYN+ACK / RST
  • ICMP 模式：Echo Reply

条件 2：异常终止（探测失败）：跳数递增至工具上限（默认最大 30 跳），全程未收到终点响应，自动结束。

误区纠正：目标主机返回的 ICMP 超时，不做终止条件！只会继续探测。

异常现象解读

星号 * * * 的常见原因

当某一跳显示 * * *，代表：本跳 TTL 对应的 ICMP 回包，本机没有收到。

常见原因：

  1. 中间设备禁止发送 ICMP Time-Exceeded 超时报文（运营商/防火墙默认策略）
  2. 中间防火墙策略拦截 ICMP 回包
  3. 回程链路拥塞、丢包
  4. 设备 CPU 负载高，丢弃低优先级 ICMP

关键特性：出现 * * * 不会终止探测！程序继续 TTL+1 往后探测，直到终点或跳数上限。

NAT 场景异常：多跳显示同一个 IP

现象：经过防火墙/出口 NAT 设备后，第 8、9、10 跳……全部显示同一个 IP。

原因：

  1. 状态化防火墙/NAT 设备对 TTL 超时的探测包统一以自身接口 IP 代为回应（如 Cisco ASA 的典型行为）
  2. ICMP 超时回包经过 NAT 时，源 IP 被统一转换为设备公网/出口 IP
  3. 导致 traceroute 无法识别后续真实设备 IP

排障判断技巧（非常实用）——看跳数，不看 IP：

  • IP 重复，但跳数一直在递增
  • 说明：流量已经走出内网，进入 NAT 后的公网链路
  • 故障点大概率在：该 NAT 设备之后的链路

这是企业网、专线、金融专网排障的高频判断手段。

易错点汇总

  1. 不是所有 ICMP 包都代表终点，只有终点主机发出的端口不可达（UDP）、Echo Reply（ICMP 模式）或 SYN+ACK/RST（TCP）才算终点
  2. TTL=0 落在目标主机，只会超时，不会结束探测
  3. 星号不中断探测，TTL 持续往后走
  4. 展示 IP 永远是入接口 IP，不是出接口
  5. NAT 后多跳同 IP 是正常现象，靠跳数判断故障位置
  6. UDP 靠端口不通收尾，TCP 靠握手包或 RST 收尾
  7. 中间路由器只回 ICMP 超时，永远不会回端口不可达 / Echo Reply / SYN+ACK
  8. 端口不可达只有「目标主机传输层」能发出，本质是 Type 3 / Code 3 的编码组合，不是报文文字内容

生产排障最佳实践

  1. 公网普通测试：默认 UDP（Windows 下用 tracert，即 ICMP 模式）
  2. 企业内网、有防火墙、有 ACL：必用 TCP traceroute
  3. 出现大量星号：直接换 TCP 指定 80/443
  4. 出现连续同 IP：锁定 NAT 出口后故障
  5. 超时多但端口可达：链路质量问题
  6. 全程星号：链路拦截 ICMP 严重，网络安全策略严格
网工
traceroute笔记
https://xinhaojin.github.io/2026/08/29/traceroute笔记/
作者
xinhaojin
发布于
2026年8月29日
许可协议