4. 网络层排查：IP地址配置、子网掩码、网关、路由表、ICMP（Ping/Traceroute）
网络层出问题，说白了就是数据包找不到路，或者根本没人认领。很多朋友一遇到连不上，就跑去抓包、看应用日志，其实大部分时候问题就卡在IP、掩码、网关这三件套上。我个人习惯，排查链路层没问题之后，第一件事就是敲 ipconfig 或 ifconfig，看看地址对不对。
4.1 IP地址配置：你的设备有没有“身份证”？
IP地址配错了，就像寄快递写错了门牌号。你想想看，数据包发出去，对方要么收不到，要么回不来。
核心检查点：
- 是否获取到有效IP？ 如果是
169.254.x.x（Windows）或0.0.0.0，说明DHCP失败了。这时候先检查DHCP服务器是否活着，或者手动配一个静态IP试试。 - IP是否冲突？ 同一个局域网里，两台设备用了同一个IP，后启动的那台会提示冲突。我在项目现场遇到过，新装了一台打印机，结果整个办公室断断续续掉线，查了半天发现打印机IP和领导电脑的IP撞了。
- 是否配了正确的子网？ 这个下面细说。
我的小技巧： 排查DHCP问题时，我习惯在客户端抓个DHCP交互包（Wireshark过滤 bootp），看看是服务器没回包，还是客户端没发请求。前者查服务器，后者查客户端防火墙或网卡驱动。
4.2 子网掩码：划清“邻里”边界
子网掩码决定了哪些IP算“邻居”，哪些算“外地”。很多人觉得掩码就是 255.255.255.0，其实不然。掩码配错了，设备会认为目标IP不在同一网段，然后一股脑把包扔给网关——如果网关没配或者配错了，就彻底断了。
举个例子：
- 设备A：IP
192.168.1.10，掩码255.255.255.0（/24） - 设备B：IP
192.168.2.20，掩码255.255.255.0（/24）
这俩不在一个网段，通信必须经过网关。但如果A的掩码错配成 255.255.0.0（/16），A就会认为B是邻居，直接发ARP请求——结果B不理它，因为B的掩码还是/24，它觉得A是外地人。这就是典型的“单通”问题。
| 掩码长度 | 子网掩码 | 可用主机数 | 常见场景 |
|---|---|---|---|
| /24 | 255.255.255.0 | 254 | 小型办公网络 |
| /16 | 255.255.0.0 | 65534 | 大型园区网 |
| /30 | 255.255.255.252 | 2 | 点对点链路 |
避坑指南： 我曾经在配置VPN隧道时，把对端掩码写成了/32，结果路由一直不通。后来发现/32表示只有这一个IP，没有广播地址，ARP根本发不出去。记住：点对点链路用/30或/31，别乱用/32。
4.3 网关：通往外部世界的“大门”
网关就是默认路由。设备要访问非本网段的地址，必须把包交给网关。网关配错了，或者网关设备本身没开路由转发，那你就只能跟局域网里的设备玩，上不了外网。
排查步骤：
- 确认网关IP是否正确。 用
ip route（Linux）或route print（Windows）查看默认网关。 - 测试网关是否可达。
ping 网关IP，如果不通，检查网关设备是否开机、端口是否up、有没有ACL拦截。 - 检查网关设备的路由表。 登录网关，看看它有没有到目标网络的路由。很多家用路由器默认只有一条默认路由到运营商，如果你内部有多个VLAN，需要配静态路由或启用动态路由协议。
我的经验： 有一次客户说“能上QQ但打不开网页”，我第一反应是DNS问题，但查了一圈发现网关配错了——网关指向了一台已经关机的服务器。QQ用的是UDP直连，不受影响；HTTP请求需要TCP三次握手，包发到错误的网关就石沉大海了。所以，“能上QQ不能上网”不一定是DNS，先查网关。
4.4 路由表：数据包的“导航地图”
路由表决定了数据包下一步往哪走。每台设备（包括PC、服务器、路由器）都有自己的路由表。排查路由问题，核心就是看“目标IP匹配了哪条路由”。
路由匹配原则：最长前缀匹配。说白了，就是看路由表里哪条路由的掩码最长，就优先走那条。如果都没有，就走默认路由（0.0.0.0/0）。
常用命令：
# Linux
ip route show
# 或者
route -n
# Windows
route print
# 路由器（Cisco）
show ip route
举个例子，假设路由表如下：
目标网络 掩码 下一跳
192.168.1.0 255.255.255.0 10.0.0.1
192.168.0.0 255.255.0.0 10.0.0.2
0.0.0.0 0.0.0.0 10.0.0.254
如果目标IP是 192.168.1.100，匹配第一条（/24），走 10.0.0.1。如果目标IP是 192.168.2.100，匹配第二条（/16），走 10.0.0.2。如果目标IP是 8.8.8.8，匹配默认路由，走 10.0.0.254。
避坑指南： 我曾经在配置多出口时，忘了加一条回程路由。结果数据包能出去，但回不来——因为网关设备不知道目标网络在哪。记住：路由是双向的，去程和回程都要配。
4.5 ICMP：网络层的“听诊器”
ICMP（Internet Control Message Protocol）是网络层的诊断协议。最常用的两个工具就是 ping 和 traceroute。
4.5.1 Ping：连通性测试
ping 发送ICMP Echo Request，对方回复Echo Reply。如果ping不通，可能的原因：
- 目标设备禁用了ICMP（很多服务器出于安全考虑会关掉）
- 中间防火墙拦截了ICMP
- 路由不可达（上面说的那些问题）
- ARP解析失败
但要注意：ping不通不代表网络不通。我遇到过一台Linux服务器，iptables规则把ICMP全丢了，但TCP 80端口是正常的。所以，ping不通的时候，换个端口试试，比如 telnet IP 80 或 curl -I http://IP。
我的习惯： 我会先ping网关，通了说明链路层和IP层没问题；再ping外网（比如114.114.114.114），通了说明网关有路由；最后ping域名（比如baidu.com），通了说明DNS也正常。这样一层层剥开，问题出在哪一目了然。
4.5.2 Traceroute：路径探测
traceroute（Windows下是 tracert）利用TTL（Time To Live）字段，逐跳探测数据包经过的路径。它能告诉你：
- 数据包在哪一跳丢了
- 哪一跳延迟高
- 有没有路由环路
举个例子：
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 1.234 ms 1.123 ms 1.098 ms
2 10.0.0.1 (10.0.0.1) 5.678 ms 5.543 ms 5.432 ms
3 * * *
4 172.16.0.1 (172.16.0.1) 20.123 ms 19.876 ms 19.654 ms
5 8.8.8.8 (8.8.8.8) 30.456 ms 30.321 ms 30.210 ms
第3跳全是 *，说明那台设备没回ICMP超时消息，或者防火墙拦了。但只要第4跳能继续，就说明路径还是通的。如果某跳之后全断了，那问题就出在那跳。
避坑指南： 我曾经遇到一个路由环路问题，traceroute显示某几跳在反复循环（比如A->B->C->A->B->C...）。这是因为路由表配错了，导致数据包在两个路由器之间来回跳，直到TTL耗尽。这时候登录路由器看路由表，找到那条错误的路由删掉就行。
4.6 网络层排查流程图
下面这张图总结了我排查网络层问题的基本思路。你可以把它当成一个检查清单，按顺序走一遍，大部分问题都能定位到。
嗯，网络层排查其实没那么玄乎。记住一个原则：从近到远，从简单到复杂。先看自己，再看邻居，最后看远方。配好IP、掩码、网关，路由表别乱写，ICMP工具用起来，大部分连接断开问题都能在十分钟内搞定。