4. 网络连通性故障排查归纳总结
网络出问题了，第一反应是什么？
我反正先 ping。别笑，这招真管用。
干了这么多年运维，80%的连通性问题，用最基础的工具就能定位。真正复杂的场景不多，但你需要一套清晰的排查思路。
今天聊聊我自己的排查习惯。
4.1 先确认：到底是哪不通？
一上来就敲命令，容易吃瘪。你得先问清楚。
- 是 全部网站 都打不开？还是某个特定的不行？
- 是 内网 有问题，还是 外网 断了？
- 只有 一台机器 上不了？还是整个网段都瘫痪了？
举个例子。有一次半夜接到电话，说财务系统登不上了。
我问：是所有人都登不上？
答：财务部三个人都登不上。
我又问：那你们能上外网吗？能内网 ping 通服务器吗？
答：能上百度，也能 ping 通服务器 IP。
嗯……问题大概率出在应用层或者端口上。如果直接去修网线，那就白费功夫了。
4.2 基本工具三板斧
工具不用多，会用就行。我常用的就三个。
4.2.1 ping —— 最快的心跳检测
说白了就是发个包看看对方回不回。
- ping 127.0.0.1 —— 先确认本机协议栈是好的。如果这个都 ping 不通……重装系统吧。
- ping 网关 IP —— 判断本机到路由器这一段通不通。不通一般就两个原因：网线松了，或者 IP 配错了。
- ping 远端服务器 IP —— 如果通，说明三层没什么大问题。不通，可能是路由出故障了。
4.2.2 traceroute —— 看看数据包走到哪了
ping 不通的时候，traceroute 帮你定位断点在哪一跳。
# Linux / MacOS
traceroute -n 10.0.0.100
# Windows
tracert 10.0.0.100返回的每一行代表一跳。卡在哪一跳，问题基本就在那一跳附近。
我记得有一次排查跨机房访问慢的问题。ping 延时正常，但业务超时。traceroute 一看，中间某一跳延时飙到 200ms。原来是那台老交换机 CPU 满载了。
4.2.3 telnet / nc —— 测端口通不通
三层通不代表端口通。防火墙一拦，啥都白搭。
# 测试 192.168.1.10 的 3306 端口
telnet 192.168.1.10 3306
# 或者用 netcat
nc -zv 192.168.1.10 3306通则弹出空窗口或返回成功，不通则一直卡住或报错。
4.3 排查清单：按步骤走，少踩坑
我把排查过程整理成了一张清单。按这个顺序来，基本不会漏。
| 排查步骤 | 执行操作 | 可能的结果 / 结论 |
|---|---|---|
| 1. 物理层 |
|
灯不亮 -> 换线；端口 err-disable -> 重启端口 |
| 2. 链路层 |
|
无 ARP 条目 -> VLAN 不对；MAC 地址冲突 -> 查网络环路 |
| 3. 网络层 |
|
网关不通 -> IP 配错；中间断 -> 路由问题 |
| 4. 传输层 |
|
端口不通 -> 防火墙拦截或服务未启动 |
| 5. 应用层 |
|
解析失败 -> DNS 问题；HTTP 返回非 200 -> 应用层故障 |
核心思路：逐层排查，不要跳步。先通物理，再看三层，最后查应用。
我曾经见过一个新同事，防火墙策略配错了，他愣是去重装了三次系统……就因为跳过了第四步。
4.4 实战场景：换个角度想一想
理论说完了，聊几个我印象比较深的场景。
场景 A：能 ping 通 IP，但打不开网页
原因太多了。DNS 挂了、代理配错了、或者对端 80 端口被防火墙挡住了。
我的排查顺序：
nslookup baidu.com—— 先确认能不能把域名解析成 IP。telnet 目标IP 80—— 看看 TCP 端口通不通。curl -v http://目标IP—— 如果端口通但 curl 卡住，看看是不是返回了 302，或者直接被重定向了。
有一次这么查下来，发现是本地 hosts 文件被人改了……
场景 B：同一个网段，有的机器能上网，有的不能
一般就三种可能：
- IP 地址冲突了。改个静态 IP 试试。
- 交换机端口做了 MAC 绑定。看看 MAC 地址有没有注册。
- 接入交换机的端口被限速或 shutdown 了。
我个人习惯先查 ARP 表。如果某台机器的 MAC 不在表里，大概率 VLAN 配错了，或者端口被隔离了。
场景 C：网络一会儿通一会儿断（间歇性故障）
这种最折磨人。你一去看，它好了；你一走，它又断了。
排查要点：
- 看日志，看日志，看日志。 系统日志和交换机日志是关键。
- 检查网线质量。我见过一根被门夹过的网线，接触不良，动一动就断。
- 检查交换机端口。
show interface看看有没有 CRC 错误、runts 或者 collisions。
还有一次，是电源适配器老化导致的电压不稳，交换机间歇性重启……找了三天。
4.5 抓包才是最终武器
前面的工具都失灵了怎么办？
上 tcpdump 或 Wireshark。抓包再看，没有抓包解决不了的问题。
# 抓传输到 10.0.0.100 的包
tcpdump -i eth0 host 10.0.0.100
# 抓特定端口
tcpdump -i eth0 port 80
# 保存成文件，回头用 Wireshark 分析
tcpdump -i eth0 -w capture.pcap抓包能让你看到“事实”，而不是你“以为”的事实。
我记得有一次排查 DNS 超时问题。业务方说偶尔解析失败，但我查配置、查服务器都正常。最后抓包发现，DNS 请求发了两个，第一个被中间的防火墙丢弃了，第二个过去了，但延时增加了。加了一条 iptables 规则才解决。
4.6 总结一下经验
排查网络连通性，说白了就两个字：拆解。
- 把大问题拆成小问题（整体断 vs 单个不通）。
- 把小问题拆成协议层（物理 -> 链路 -> 网络 -> 传输 -> 应用）。
- 然后用工具一个个验证。
别慌，按步骤来。实在不行就抓包。记住：网络不会说谎，错的往往是配置或错觉。