网络层故障排查实战技巧分享

从一次断网经历说起

上周三下午，公司突然全员上不了网页，钉钉也连不上。运维小李接到报修后没慌，先问了一句：是所有人还是个别机器？得到“全部”的答复后，他直接上了核心交换机机房。这其实是个典型网络层故障的起点——问题不在电脑，也不在应用，而是在中间那层看不见的数据通路上。

第一步：确认故障范围

很多人一断网就重启路由器，其实应该先判断影响范围。如果是单台设备上不了网，大概率是终端配置或硬件问题；如果整个局域网都瘫了，才要往网络层深挖。这时候可以快速 ping 网关，比如你的路由器 IP 是 192.168.1.1：

ping 192.168.1.1

如果通，说明本地链路正常；如果不通，就得查物理连接、ARP 表、VLAN 划分这些基础项。

用 traceroute 找卡点

能到网关，但打不开网页？这时候 traceroute 就派上用场了。它能显示数据包经过的每一跳。比如你发现卡在第三跳，那问题很可能出在运营商接入段或者防火墙策略上。

traceroute www.baidu.com

Windows 下对应的是 tracert 命令，效果一样。看到某跳开始全是星号（*），基本就能锁定故障节点。

别忽略 ARP 和 VLAN

有次客户说“办公室一半人上不了网”，现场一看，交换机灯都正常。查 VLAN 配置才发现，新接的 AP 被自动划进了隔离区，导致部分终端拿不到正确网段地址。还有 ARP 欺骗的情况，会看到同一 IP 多个 MAC 绑定，这时候得清 ARP 缓存或者启用端口安全。

防火墙和 ACL 也要查

某企业专线突然无法访问云服务器，查路由表没问题，ping 通但端口不通。最后发现是边界防火墙上一条 ACL 规则误删了回程策略。这类问题光看连通性不够，得用 telnet 或 nc 测试具体端口：

telnet cloud.example.com 443

如果连接超时，可能是中间设备做了拦截。

抓包不是高手专属

实在搞不定，就上 tcpdump 或 Wireshark。比如怀疑 DNS 被劫持，抓一下 53 端口流量：

tcpdump -i eth0 port 53

看请求发出去有没有收到响应。没有响应，可能是上游问题；有响应但内容异常，就得查本地解析设置。

网络层的问题不像蓝屏那么直观，但它就像城市道路系统，一个红绿灯失灵就可能堵死一片区域。平时多留意日志，关键时候才能快速定位卡点。