网络故障排查（上）：Ping不通怎么办？DNS解析失败、TCP连接超时、路由追踪实战
大家好，我是老张。干运维这些年，最常被问到的问题就是：「网络不通了，怎么办？」
说实话，网络故障排查是运维的基本功，也是最能体现经验的地方。今天咱们就聊聊Ping不通这个经典场景。别小看它，背后能牵扯出一整套排查思路。
核心思路：网络不通，先别慌。按照「本地→网关→DNS→路由→目标」的链路，一层层剥开看。
一、Ping不通，先别急着甩锅
很多人一遇到Ping不通，第一反应就是「网络坏了」。其实不一定。我见过太多案例，最后发现是防火墙策略、或者目标主机禁Ping了。
先问自己三个问题：
- 是全部不通，还是个别不通？
- 是Ping IP不通，还是Ping域名不通？
- 是第一次不通，还是以前通现在不通？
这三个问题能帮你快速缩小范围。我个人习惯，先Ping一下127.0.0.1，确认本机协议栈没问题。
# 测试本地回环
ping 127.0.0.1
# 如果通，说明本机TCP/IP协议栈正常
# 如果不通，检查网卡驱动或协议栈配置小技巧：Windows上可以用 ping -n 4 127.0.0.1，Linux用 ping -c 4 127.0.0.1，发4个包就够了，别一直Ping着玩。
二、DNS解析失败：域名转IP卡住了
Ping域名不通，但Ping IP通，十有八九是DNS的问题。说白了，就是你的电脑不知道这个域名对应哪个IP地址。
我在项目中遇到过好几次，开发说「网站打不开」，我一查，DNS服务器挂了。嗯，这种问题其实很好定位。
2.1 先确认DNS配置
# Linux 查看DNS配置
cat /etc/resolv.conf
# Windows 查看DNS
ipconfig /all | findstr "DNS"看看里面有没有DNS服务器地址。如果没有，或者指向了一个错误的地址，那肯定解析不了。
2.2 手动测试DNS解析
# 使用 nslookup（Windows/Linux通用）
nslookup www.example.com
# 使用 dig（Linux更推荐）
dig www.example.com
# 指定DNS服务器测试
nslookup www.example.com 8.8.8.8如果指定了8.8.8.8能解析，说明你本地的DNS服务器有问题。我曾经遇到过一个奇葩案例——公司自建的DNS服务器缓存了一个错误的A记录，导致所有员工都访问不了某个重要系统。清掉缓存就好了。
避坑指南：我曾经遇到过，Ping域名显示「unknown host」，但nslookup却能解析出IP。这是因为系统用了nscd（Name Service Cache Daemon）缓存，缓存过期了但没刷新。重启nscd服务或者清一下DNS缓存就好。
# 清DNS缓存（Linux）
sudo systemctl restart nscd
# 或者
sudo nscd -i hosts
# Windows清缓存
ipconfig /flushdns三、TCP连接超时：端口通不通才是关键
Ping通了，但业务还是连不上？这时候别纠结Ping了，该测TCP连接了。
Ping用的是ICMP协议，而你的业务（比如HTTP、MySQL、SSH）用的是TCP。ICMP通，不代表TCP端口通。反过来也一样，TCP端口通，ICMP可能被防火墙拦截了。
3.1 用telnet测端口
# 测试目标IP的80端口是否开放
telnet 192.168.1.100 80
# 如果出现连接成功，说明端口通
# 如果卡住不动或提示连接失败，说明端口不通telnet是最简单粗暴的方式。但有些系统没装telnet客户端，可以用其他工具替代。
3.2 用nc（netcat）更灵活
# 测试端口连通性
nc -zv 192.168.1.100 80
# -z 表示只扫描不发送数据
# -v 表示显示详细信息
# 也可以测试端口范围
nc -zv 192.168.1.100 80-100我个人更喜欢用nc，因为它可以写脚本批量检测。有一次线上故障，我用一个for循环配合nc，5分钟扫完了100台服务器的端口状态，快速定位到了问题节点。
3.3 用curl测试HTTP服务
# 测试HTTP服务是否正常响应
curl -I http://192.168.1.100:8080
# -I 表示只获取响应头
# 如果返回HTTP状态码，说明服务正常重要提醒：TCP连接超时，常见原因有：
- 目标端口没监听（服务没启动）
- 防火墙拦截了端口
- 中间网络设备（如负载均衡）配置错误
- 目标主机负载过高，来不及响应
四、路由追踪实战：看数据包走到哪丢了
如果Ping不通，而且确认了DNS没问题、本地配置没问题，那就要看看数据包到底丢在哪了。路由追踪就是干这个的。
说白了，就是让每个路由器都告诉你一声：「嘿，我收到你的包了」。这样你就能看到数据包从你电脑到目标服务器，经过了哪些节点，哪个节点丢了包。
4.1 Linux用traceroute
# 基本用法
traceroute www.example.com
# 指定最大跳数（默认30）
traceroute -m 15 www.example.com
# 使用ICMP模式（有些防火墙会拦截UDP）
traceroute -I www.example.com4.2 Windows用tracert
# 基本用法
tracert www.example.com
# 不解析域名，只显示IP（速度更快）
tracert -d www.example.com4.3 怎么看结果？
输出结果一般长这样：
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.123 ms 1.456 ms
2 10.0.0.1 (10.0.0.1) 5.678 ms 5.901 ms 6.123 ms
3 * * * ← 这里超时了
4 203.0.113.1 (203.0.113.1) 20.345 ms 21.001 ms 19.876 ms看到第3跳全是星号，说明数据包到那个节点就丢了。可能是那个路由器配置了不响应traceroute，也可能是真的网络中断。
实战经验：我曾经排查过一个跨地域的网络问题，traceroute发现数据包在某个运营商的骨干节点上丢了50%的包。后来联系运营商，发现是那个节点的光模块故障。换了个模块，问题解决。没有traceroute，你根本不知道问题出在谁家地盘上。
4.4 路由追踪的注意事项
- 星号不一定代表故障：很多路由器出于安全考虑，不响应traceroute的探测包。如果只有一两跳星号，后面又通了，那问题不大。
- 延迟突然飙升要警惕：如果某跳的延迟从5ms突然跳到200ms，说明那个节点可能负载很高，或者链路质量差。
- 丢包率是关键指标：如果某跳连续丢包超过20%，基本可以判定有问题。
五、综合排查流程总结
好了，咱们把今天的内容串起来。遇到Ping不通，按这个顺序查：
- 查本地：Ping 127.0.0.1，确认本机协议栈正常
- 查网关：Ping网关IP，确认能出局域网
- 查DNS：nslookup域名，确认能解析到IP
- 查路由：traceroute目标，看数据包丢在哪
- 查端口：telnet/nc测目标端口，确认服务可达
这个流程我用了十年，基本覆盖了90%的网络故障场景。你想想看，每次出问题都从头到尾查一遍，慢慢就形成肌肉记忆了。
一句话总结：网络排查不是玄学，是科学。按链路一层层剥，总能找到根因。