ping 通但 tracert 不通？一个真实案例，教你用 8 种命令定位网络故障
ping 通但 tracert 不通？一个真实案例，教你用 8 种命令定位网络故障
大家好，我是老张。
📌 本文基于真实生产案例，为保护环境信息，文中 IP 地址已做脱敏替换。
前两天遇到一个经典的甩锅现场——安全厂商的人在客户群里说"tracert 不通，最后一条是云内地址，要问云老师"。
翻译一下就是：这锅是云平台的。
结果呢？20 分钟排查完，甩出去的锅自己飞回来了——防火墙 traceroute 功能没开。
今天把这个案例完整复盘，文末附上我用了 多年的网络诊断命令大全（Windows+Linux+交换机全覆盖），建议收藏。
📊 先看结果
| 测试方式 | 目标 | TCP tracert | UDP tracert | ICMP tracert | ping |
|---|---|---|---|---|---|
| 交换机 | 目标地址 | — | — | ❌ 全 * | ✅ 通 |
| 交换机 | 防火墙互联 | — | — | ❌ 全 * | ✅ 通 |
| 云主机 | 防火墙互联 | ✅ 7 跳直达 | — | ❌ 第 6 跳后 * | ✅ 通 |
| 云主机 | 目标地址 | ✅ 7 跳直达 | ❌ 第 6 跳后 * | — | — |
规律极度明确：TCP 全通、UDP/ICMP 全断。不是网络问题，是防火墙协议级拦截。
一、问题背景
项目组反馈：从堡垒机 tracert 目标地址（防火墙上配置的地址），在交换机网关处中断，后续路径未知。安全厂商判断"最后一条是云内地址，需要问云老师"。
网络链路：
堡垒机 → 交换机 → 防火墙(互联地址) → 目标地址
两个关键 IP：
- 交换机与防火墙互联地址
- 目标地址：配置在防火墙上
二、交换机侧验证——路由通，ping 通，tracert 全 *
2.1 先看路由
<交换机>dis ip routing-table protocol static
172.20.6.0/24 Static 60 0 172.20.21.1 RAGG13
✅ 静态路由正确：目标网段 → 下一跳 防火墙互联地址 → 出接口 RAGG13。
2.2 ping 测试
<交换机>ping 172.20.6.3
Ping 172.20.6.3: 56 data bytes, press CTRL+C to break
56 bytes from 172.20.6.3: icmp_seq=0 ttl=64 time=0.512 ms
56 bytes from 172.20.6.3: icmp_seq=1 ttl=64 time=0.962 ms
56 bytes from 172.20.6.3: icmp_seq=2 ttl=64 time=0.830 ms
56 bytes from 172.20.6.3: icmp_seq=3 ttl=64 time=0.878 ms
56 bytes from 172.20.6.3: icmp_seq=4 ttl=64 time=0.378 ms
--- Ping statistics ---
5 packet(s) transmitted, 5 received, 0.0% packet loss
round-trip min/avg/max = 0.378/0.712/0.962 ms
✅ 全通，0% 丢包，延迟 <1ms。
2.3 tracert——全部 *
<交换机>tracert 172.20.6.3
traceroute to 172.20.6.3, 30 hops max
1 * * *
2 * * *
3 * * *
...（全 *，超时）
<交换机>tracert 172.20.21.1
...（同样全 *，超时）
⚠️ 连第一跳都是 *——连交换机自己与防火墙直连的这一跳都追踪不到。
关键判断：ping 通 + tracert 全 * = 不是网络断，是中间设备不响应 traceroute。交换机与防火墙是直连的，第一跳就 *，说明问题在防火墙上。
三、云主机侧验证——TCP/UDP/ICMP 三协议对比
在云平台内找了台 VM，对同一目标做三种协议的 traceroute。
3.1 TCP traceroute（SYN 包，端口 443）
root@云主机:~# traceroute -T -p 443 172.20.6.3
traceroute to 172.20.6.3, 30 hops max, 60 byte packets
1 * * *
2 * * *
3 172.20.0.1 0.264 ms
4 172.20.16.207 0.393 ms
5 172.20.16.5 0.238 ms
6 172.20.16.99 0.237 ms ← 出口路由层
7 172.20.6.3 0.235 ms ← 🎯 目标地址！直达！
✅ 7 跳完美到达，延迟 <1ms。路径完整可见。
3.2 UDP traceroute（默认方式，同一端口 443）
root@云主机:~# traceroute -p 443 172.20.6.3
traceroute to 172.20.6.3, 30 hops max, 60 byte packets
1 * * *
2 * * *
3 172.20.0.1 0.261 ms
4 172.20.16.207 0.337 ms
5 172.20.16.5 0.212 ms
6 172.20.16.99 0.219 ms
7 * * * ← 断了！
...（之后全 *，30 跳超时）
❌ 同一个端口，UDP 方式第 7 跳后全 *。
3.3 铁证
| 协议 | 目标 | 结果 |
|---|---|---|
| TCP (-T -p 443) | 目标地址 | ✅ 7 跳直达 |
| UDP (-p 443) | 目标地址 | ❌ 第 7 跳断 |
| ICMP（默认） | 目标地址 | ❌ 第 7 跳断 |
同一目标、同一端口、同一路径，换了个协议，结果天差地别。这就钉死了：是防火墙协议级拦截，不是网络故障。
四、traceroute 为什么"断"了？（原理）
很多人不知道 traceroute 是怎么工作的，这里快速讲一下：
traceroute 原理：
1. 发送 TTL=1 的探测包 → 第一跳路由器 TTL 归零 → 回 ICMP Time Exceeded
2. 发送 TTL=2 的探测包 → 第二跳路由器 TTL 归零 → 回 ICMP Time Exceeded
3. ...
N. 直到到达目标，目标回 ICMP Port Unreachable（UDP 模式）或 TCP RST/SYN-ACK
所以 traceroute 依赖一个关键假设：中间设备愿意回 ICMP Time Exceeded 消息。
问题来了——安全设备（防火墙/IPS/WAF）的默认策略通常不回应 ICMP Time Exceeded，目的是减少信息泄露。你不回 → traceroute 看到 * * * → 误以为"断了"。
后面防火墙的人也确认了这一点：
"tracert 没回显是因为防火墙上的这个功能没开，后面启用一下就行了。"
五、网络诊断命令大全（建议收藏）
这次排查能快速定位，核心就一个技巧：换协议对比。 下面把工作中常用的网络诊断命令整理出来，覆盖 Windows、Linux、交换机三种环境。
⚠️ 以下示例中
<目标>代表目标 IP 或域名，生产环境请替换为实际值。
1. ping —— 最基础的连通性测试
原理：发送 ICMP Echo Request，目标回 ICMP Echo Reply。测的是三层（网络层）可达性。
返回值解读：
| 现象 | 含义 |
|---|---|
| Reply from ... time<1ms | 通，同网段或直连 |
| Reply from ... time=XXms | 通，延迟正常 |
| Request timed out | 不通或防火墙拦截 ICMP |
| TTL expired in transit | 路由环路 |
| Destination host unreachable | 无路由/ARP 失败 |
⚠️ 常见误区：ping 不通 ≠ 网络不通。很多安全设备禁 ping，但业务端口正常。
通用（所有设备）：
ping <目标>
Windows 指定次数：
ping -n 10 <目标>
Linux 指定次数：
ping -c 10 <目标>
交换机（华为/华三）：
ping -c 10 <目标>
本次排查中的使用：交换机 ping 目标地址全通 → 排除三层路由问题。
2. tracert / traceroute —— 路径追踪
原理：利用 IP 头中的 TTL 字段，逐跳发送 TTL=1,2,3... 的探测包，中间路由器 TTL 归零时回 ICMP Time Exceeded，从而拼出完整路径。
不同系统的默认协议：
| 系统 | 命令 | 默认协议 |
|---|---|---|
| Windows | tracert | ICMP Echo |
| Linux | traceroute | UDP（高端口） |
| 交换机 | tracert | UDP 或 ICMP（看厂商） |
返回值解读：
| 现象 | 含义 |
|---|---|
| 1 192.168.1.1 1ms | 正常，第一跳 |
| 5 * * * | 该跳不响应，可能是安全设备或丢包 |
| 5 * * * 之后全 * | 后面路径不可追踪，不一定是断了 |
| !H（Linux） | Host unreachable |
| !N（Linux） | Network unreachable |
| !X（Linux） | Communication administratively prohibited |
⚠️ 切记：tracert 全 * 不代表不通！ping 先确认三层可达性。
Windows：
tracert <目标>
tracert -d <目标> # 不做 DNS 解析，更快
Linux：
traceroute <目标> # 默认 UDP
traceroute -I <目标> # ICMP 方式
traceroute -T -p 80 <目标> # TCP SYN，指定端口
traceroute -n <目标> # 不解析 DNS
交换机（华为/华三）：
tracert <目标>
tracert -q 1 <目标> # 每跳只发 1 个包，更快
本次排查中的使用：ICMP/UDP tracert 全 * → 换 TCP tracert 正常 → 确认防火墙协议级拦截。
3. tcping —— 端口级连通性（TCP 握手）
原理：尝试 TCP 三次握手，能 SYN-ACK 回来就是通的。比 ping 更准确——ping 可能被禁，但业务端口必须通。
返回值解读：
| 现象 | 含义 |
|---|---|
| Port is open / Connected | 端口通 |
| Port is closed / Connection refused | 端口不通（目标回了 RST） |
| No response / timeout | 端口不通（无响应，可能被拦截） |
⚠️：Connection refused 和 timeout 有本质区别——前者是目标机器明确拒绝（RST），后者是包被丢弃（可能防火墙拦了）。
Windows（需安装 tcping.exe 或用 PowerShell）：
Test-NetConnection <目标> -Port 443
Linux（需安装 tcping）：
tcping <目标> 443
tcping -c 5 <目标> 443 # 5 次后停止
本次排查中的补充用法：如果 TCP tracert 正常但怀疑业务端口有问题，用 tcping 直接测。
4. telnet —— 最原始的端口探测
原理：主动发起 TCP 连接，能连上说明端口通。比 tcping 更直观——能看到应用层是否有响应。
返回值解读：
| 现象 | 含义 |
|---|---|
| 黑屏/光标闪烁 | 端口通，等待输入 |
| Connected to ... Escape character is '^]' | 端口通 |
| Connection refused | 端口不通（目标明确拒绝） |
| 长时间无响应后 timeout | 端口不通（被丢弃/拦截） |
| 看到乱码或字符 | 端口通，服务有响应（如 SSH banner） |
通用：
telnet <目标> <端口>
Windows：
telnet 172.20.6.3 443
⚠️ Windows 默认未安装 telnet 客户端：
# PowerShell 管理员
Enable-WindowsOptionalFeature -Online -FeatureName TelnetClient
本次排查中的补充用法：如果别人反馈"应用发布服务器端口不通"，telnet 是第一选择——快速判断是网络问题还是应用问题。
5. nc（netcat）—— 瑞士军刀
原理：TCP/UDP 通吃，能做端口扫描、数据传输、监听。排查时主要用 -z 模式测端口。
返回值解读：
| 现象 | 含义 |
|---|---|
| Connection to ... port [tcp/http] succeeded! | 端口通 |
| 无输出（-z 模式下连接成功） | 端口通 |
| Connection refused | 端口不通 |
| 无响应/超时 | 端口不通或被拦截 |
Linux：
nc -zv <目标> 443 # TCP 端口探测，verbose
nc -zv <目标> 22-25 # 端口范围扫描
nc -zuv <目标> 53 # UDP 端口探测
nc -zv -w 2 <目标> 443 # 超时 2 秒
Windows（需下载 nc.exe 或 ncat）：
nc -zv <目标> 443
本次排查中的补充用法：如果有多个目标需要批量测端口，nc 比 telnet 高效——一行命令出结果。
6. nmap —— 端口扫描 + 服务识别
原理：发送各种探测包（SYN/ACK/UDP/ICMP），根据响应判断端口状态和服务类型。比 nc 强大在能识别服务版本。
返回值解读：
| 状态 | 含义 |
|---|---|
| open | 端口开放，有服务在监听 |
| closed | 端口可达，但无服务监听（回了 RST） |
| filtered | 无法判断，可能被防火墙拦截 |
| unfiltered | 端口可达，但无法确定是否开放 |
| `open | filtered` |
Linux：
nmap -p 443 <目标> # 单端口扫描
nmap -p 22,80,443 <目标> # 多端口扫描
nmap -p 1-1000 <目标> # 端口范围扫描
nmap -sV -p 443 <目标> # 服务版本识别
nmap -Pn <目标> # 跳过 ping 探测（目标禁 ping 时用）
⚠️ Windows 和 Linux 都需要安装 nmap，非系统自带。
本次排查中的补充用法：如果怀疑多个端口被防火墙策略拦截，nmap 的 filtered 状态能直接指出来。
7. mtr —— ping + traceroute 二合一
原理：持续逐跳发送探测包，实时统计每跳的丢包率和延迟。比 traceroute 强在能看到每跳的持续性表现，而不是 3 个包的快照。
返回值解读：
| 列 | 含义 |
|---|---|
| Loss% | 该跳丢包率 |
| Snt | 已发送包数 |
| Last | 最后一个包的延迟 |
| Avg/Best/Wrst | 平均/最好/最差延迟 |
| StDev | 延迟抖动 |
⚠️ 关键判读技巧：某跳 Loss% 高但后续跳 Loss% 恢复 → 不是真丢包，是该跳不响应探测包（跟本次案例一样）。只有最后跳 Loss% 也高 → 才是真丢包。
Linux：
mtr <目标> # 交互式界面
mtr -r -c 10 <目标> # 报告模式，发 10 个包后退出
mtr -T -P 443 <目标> # TCP 模式，端口 443
mtr -n <目标> # 不解析 DNS
Windows：需下载 WinMTR（GUI 工具）。
本次排查中的补充用法：如果用 mtr 测这个案例，会看到第 7 跳 Loss% 高但后续没数据显示 → 一眼就能判断是安全设备不响应，不是网络丢包。
🧠 快速诊断决策树
遇到网络问题时，按这个顺序来：
ping <目标>
├─ 通 → 三层可达 ✅ → telnet/nc/tcping <目标> <端口>
│ ├─ 通 → 应用层可达 ✅ → 没问题
│ └─ 不通 → 检查防火墙策略/服务监听
│
└─ 不通 → traceroute <目标>
├─ 中间某跳断 → 定位故障设备
└─ 全程 `*` → 换 TCP traceroute
├─ TCP 通 → 防火墙拦截 ICMP/UDP TTL exceeded
└─ TCP 也不通 → 真网络故障
💡 老张的几点总结
- "tracert 不通"不等于"网络不通"：这次的教训——交换机 ping 全通、TCP tracert 全通，ICMP tracert 全
*。三个证据互相印证，才能下结论 - 换协议对比是最快的定位方法：ICMP 不通就换 TCP，TCP 不通就换 UDP。防火墙拦截通常是按协议策略的，换个协议大概率能绕过去
- mtr 比 tracert 更靠谱：tracert 只发 3 个包，mtr 持续发。遇到偶尔丢包或不稳定延迟的问题，mtr 是唯一选择
💬 互动话题
- 你遇到过类似"ping 通但 tracert 不通"的情况吗？最后怎么定位的？
- 日常排查你最喜欢用哪个命令？我投 mtr 一票
- 还有什么网络诊断工具你觉得好用但上面没列？欢迎评论区补充