traceroute笔记

本文最后更新于 2026年8月29日 下午

Traceroute 核心定义

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

核心目的：

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

底层机制：TTL 逐跳递减

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

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

traceroute 就是利用「TTL 超时 ICMP 回包」拿到每一跳设备 IP。

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

  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 回包和自己的探测包一一对应起来。

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

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

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

意义：

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

探测模式：UDP、TCP 与 ICMP

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 443 目标地址
  • -T：使用 TCP SYN 探测
  • -p：指定目标端口，可任意指定业务端口（80、443、22）

探测特征：

  • 探测包：TCP SYN 包
  • 可手动指定任意端口（80、443、22）

两种终点收尾逻辑：

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

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

ICMP 模式（Windows tracert 默认）

探测特征：

  • 探测包：ICMP Echo Request（就是 ping 包）
  • Linux 下用 traceroute -I，需要 root 权限；Windows 的 tracert 默认就是这种模式

收尾逻辑：

  1. 中间路径：TTL 不足 → 设备回 ICMP 超时
  2. 报文抵达目标主机 → 目标主机回复 Echo Reply（回显应答，即 ping 的正常应答）
  3. 收到 Echo Reply → 判定抵达终点 → 终止探测

ICMP 模式终止标志：收到目标主机的 Echo Reply。注意和 UDP/TCP 模式不同，它靠的是「正常应答」而不是「差错报文」。

弱点：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 三种即可。

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 = 真正抵达终点

星号 * * * 的常见原因

当某一跳显示 * * *，代表：本跳 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 设备之后的链路

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

Traceroute 的终止条件（核心考点）

只有两种合法终止条件。

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

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

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

误区纠正：目标主机返回的 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 环境、快速验证连通性

易错点汇总

  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日
许可协议