网络故障排查实战指南：别一出问题就重启，按层查才靠谱

做运维时间久了就会发现，网络故障最怕的往往不是问题有多复杂，而是现场一乱，排查顺序先乱了。

一出问题，大家就容易开始靠猜：有人先重启设备，有人先改配置，还有人上来就怀疑防火墙。结果常常是，问题还没定位清楚，排查节奏已经被打散了，甚至越查越乱。

其实绝大多数网络问题，都有一条相对清晰的定位路径。只要别跳着查，从物理层、链路层、网络层，一层层往上看，很多问题并没有想象中那么难。

这篇文章，我不只从单一视角去讲，而是尽量把运维主机侧和网络设备侧两种排查方式放在一起。说白了，就是既告诉你服务器上怎么查，也告诉你交换机、路由器、防火墙那边通常该看什么。这样更贴近真实故障现场，也更适合日常排障落地。

网络故障最怕的，不是复杂，而是上来就查乱了

很多故障现场，真正的问题不是技术难，而是大家一着急就开始各查各的。

运维盯着服务日志，网工盯着接口状态，安全同学又在翻策略，谁都没错，但如果没有一条统一的排查主线，最后就很容易互相怀疑、互相打断，效率特别低。

所以我一直觉得，网络排障最重要的不是“谁命令背得多”，而是有没有一个大家都能对齐的排查顺序。

比较稳的思路其实很简单：

❝物理层 → 链路层 → 网络层 → 传输层 → 应用层 → 安全策略 → 性能与日志

顺着这个思路走，至少不会乱。

一、别一上来就看配置，先确认它到底“连上了没有”

很多人排障时最容易跳过的，就是物理层。

总觉得这层太基础，不像技术活。可现实往往正相反：越基础的地方，越容易出最耽误时间的问题。线松了、模块异常、端口抖动、电源不稳，这些一点都不高级，但足够把业务拖住。

所以第一步，先别急着翻配置。先确认设备、链路、接口是不是真的正常连着。

运维侧先看什么

先看服务器网卡状态、链路状态、错误统计。

查看网卡状态：

ip link
ethtool eth0

查看网卡统计信息：

ip -s link show eth0
ethtool -S eth0

查看系统日志里的链路异常：

dmesg | grep -Ei 'eth|link|nic|network'

重点看这些：

• Link detected 是否正常
• Speed / Duplex 是否异常
• 是否有 RX/TX errors
• 是否有 dropped / CRC / frame error

网工侧一般看什么

到了网络设备这边，重点通常是：

• 接口是否 up/down
• 端口是否有 flap
• 光模块收发光是否异常
• 端口错误包是否持续增加
• 设备是否有电源、风扇、温度告警

不同厂商命令不一样，但检查点基本差不多：接口状态、模块状态、硬件健康状态、错误统计。

这一层的经验判断

如果是下面这些场景，优先查物理层基本不会错：

• 突然不通
• 偶发中断
• 刚换过设备、模块、跳线
• 现场有人动过线缆

有些问题，真不是查出来的，是看出来、摸出来、换出来的。 换根线、换个模块、换个口，有时候比你坐那分析半小时还快。

二、链路亮着不代表真正常，二层问题最容易把人绕进去

物理层 OK，只能说明“接上了”，不代表业务就一定能正常跑。

二层最烦的地方就在这：表面上看没断，流量其实没正常走。端口亮着，接口 up 着，主机也在线，可就是不通，或者时通时不通。这类问题特别容易让人怀疑人生。

最常见的坑，一般集中在：

• VLAN 配错
• Trunk 没放通
• MAC 学习异常
• 生成树阻塞
• 广播风暴、二层环路
• 接口错误包持续上涨

运维侧可以怎么查

查看本机网卡和 MAC：

ip link show eth0

查看邻居表：

ip neigh

抓包看 ARP 和广播：

tcpdump -i eth0 arp
tcpdump -i eth0 broadcast
tcpdump -i eth0 -nn

如果服务器发出了 ARP 请求，但一直拿不到回应，或者广播流量明显异常，这时候就要开始怀疑二层了。

网工侧重点看什么

网络设备这边一般会看：

• MAC 地址表是否正常学习
• VLAN 是否存在、是否配对
• Trunk 是否放通目标 VLAN
• STP 状态是否异常
• 接口统计里是否有 CRC、丢包、广播异常

说白了，这一层核心不是“配了没配”，而是二层转发逻辑是不是通的。

典型现象

如果出现这些情况，优先怀疑链路层：

• 同 VLAN 主机互相不通
• 某个 VLAN 里的业务整体异常
• 网络突然变慢，交换机 CPU 飙高
• 插上一台设备后全网开始抖

这时候先别急着往三层想，很多问题根子就在二层。

三、IP、ARP、路由这三样不捋顺，后面查再多都白费

到三层之后，排查思路反而要更简单一点。

别一上来就把所有配置翻一遍，先抓主线。网络层最关键的，其实就是三样东西：

❝IP 配对没？ARP 正常吗？路由走偏了吗？

只要这三样有一样出问题，业务表现就会很怪。

运维侧怎么查

查看 IP 地址：

ip addr

查看路由表：

ip route
route -n

查看 ARP / 邻居表：

ip neigh
arp -n

分段 Ping：

ping -c 4 127.0.0.1
ping -c 4 网关IP
ping -c 4 同网段主机
ping -c 4 目标业务IP
ping -c 4 8.8.8.8

看路径：

traceroute 8.8.8.8
tracepath 8.8.8.8

Windows 下可以用：

tracert 8.8.8.8

网工侧怎么查

网络设备侧通常会重点确认：

• 三层接口 IP 是否正确
• 网关配置是否匹配
• ARP 学习是否正常
• 路由表里有没有目标网段
• 默认路由或动态路由是否异常
• 上下游路由通告是否正常

这里很容易出现一种情况：运维这边看到“我能 ping 通网关”，就觉得网络应该没问题；但网工那边一查，默认路由可能早就写偏了。

这一层最容易踩的坑

• 默认网关写错
• 静态路由写偏
• ARP 表异常
• IP 地址冲突
• 本地通、出网不通
• IP 能通，域名不通

网络层最怕的不是复杂，而是方向搞错。 方向一错，后面查再多都容易白费。

四、Ping 通，不等于业务就能正常跑起来

这个误区太常见了。

很多人看到 Ping 有回包，就默认“网络没问题”。其实 Ping 只能说明 ICMP 这条路能走，不代表 TCP 正常，也不代表应用端口一定可用。

真正到了传输层，你要看的已经不是“通不通”，而是：

• 端口有没有监听
• 连接能不能建立
• 三次握手是否完整
• 有没有重传、超时、RST
• NAT 或防火墙会不会影响会话

运维侧常用命令

查看监听端口：

ss -lntp
netstat -lntp

查看连接状态：

ss -ant

测试端口是否可达：

nc -zv 目标IP 端口
telnet 目标IP 端口

测试 HTTP / HTTPS：

curl -I http://example.com
curl -kI https://example.com
curl -v http://目标地址

抓包：

tcpdump -i eth0 host 目标IP and tcp
tcpdump -i eth0 port 443 -nn

网工侧这时候看什么

网络设备侧通常会关注：

• 会话表是否正常
• NAT 转换是否正常
• 防火墙策略是否命中
• 是否存在大量会话堆积
• 是否有丢包、重传、RST 异常
• 必要时做镜像抓包

如果运维侧抓到大量重传，而网络设备侧又发现会话表异常、NAT 打满，那这时候问题基本就很清楚了。

适合重点看传输层的场景

• Ping 正常，但网页打不开
• 服务偶发超时
• 某些端口能通，某些端口不通
• 连接建立慢，或者连得上但很卡

这种时候，别再只盯着 Ping 了。Ping 能通，不等于业务真的正常。

五、底层都正常，业务还是挂？那就别再死盯着网络了

有一类问题特别像“网络故障”，但查到最后会发现，根本不是网络层出了问题，而是应用层本身有毛病。

链路正常，路由正常，端口也通，可业务就是不对。 这时候就别再死盯着底层了，直接把注意力拉到应用层。

运维侧重点查这些

• DNS 解析是否正确
• 服务进程是否还活着
• 监听端口是否正确
• 反向代理、网关、负载均衡配置是否异常
• HTTP 状态码是否异常
• 应用日志里有没有报错

常用命令：

nslookup www.example.com
dig www.example.com
dig @8.8.8.8 www.example.com

ps -ef | grep 服务名
systemctl status nginx
systemctl status docker

ss -lntp | grep 80
ss -lntp | grep 443

curl -v http://127.0.0.1:8080
curl -vk https://域名

tail -f /var/log/nginx/error.log
journalctl -u nginx -f
tail -f /var/log/messages

网工侧这时候怎么配合看

网工这边虽然不直接排应用，但一般会配合确认：

• VIP / 负载均衡转发是否正常
• SLB / 反向代理链路是否健康
• DNS 解析链路是否异常
• 出入口是否存在策略干扰
• 应用访问流量是否真正到达后端

有时候运维会说“服务是好的”，网工会说“链路是通的”，但一对起来才发现，问题其实卡在负载均衡、网关或者 DNS 这一跳。

典型表现

• IP 能通，但域名访问不通
• 端口通，但接口报错
• 业务偶发 502 / 504
• 服务重启后恢复，过一会又异常

这类问题，很多时候已经不是“网络断了”，而是应用自己没稳住，或者应用链路中间件出了问题。

六、很多“不通”根本不是故障，而是被规则拦住了

现场排障时，还有一类问题特别容易误判： 看起来像网络故障，实际上是安全策略把流量挡住了。

运维侧先看什么

先确认主机上的防火墙、规则、云安全组。

查看 iptables：

iptables -L -n -v
iptables -t nat -L -n -v

查看 firewalld：

firewall-cmd --list-all

查看 nftables：

nft list ruleset

网工侧重点看什么

网络设备这边通常会看：

• 防火墙策略是否命中
• ACL 是否误拦截
• 安全域划分是否影响流量
• V**/ IPS / IDS 是否误杀
• 是否有黑白名单或策略路由影响

这类问题的典型特征

• 某个源地址能访问，另一个不行
• 某个端口不通，其他端口正常
• 新业务不通，老业务正常
• V** 内能访问，外网不行

这些一看就不能只往链路上想，很可能就是规则问题。

七、最烦的不是彻底不通，而是能用、但特别难受

彻底不通，反而有时候好查。 最烦的是那种：能访问、但很慢；不算挂、但用起来特别难受。

这类问题最折磨人，因为它不是“有没有”的问题，而是“好不好用”的问题。

运维侧重点看什么

查看网卡流量：

sar -n DEV 1 5
iftop -i eth0

查看连接统计：

ss -s

查看系统负载：

top
htop
uptime

查看延迟和丢包：

ping -c 20 目标IP
mtr 目标IP

测试带宽：

iperf3 -s
iperf3 -c 目标IP

网工侧会重点关注什么

• 接口带宽是否打满
• 丢包、延迟、抖动是否异常
• 设备 CPU、内存是否飙高
• 会话数、新建连接数是否异常
• 是否有广播风暴、大流量任务、异常流量

排查时先分清几件事

• 是全网都慢，还是单个业务慢
• 是持续慢，还是高峰期慢
• 是上传慢，还是下载慢
• 是高延迟，还是高丢包

别一说“卡”就默认是带宽不够。 很多时候，不是资源少，而是资源被抢了，或者分配得不合理。

八、别等出事了才翻日志，很多答案其实早就写在里面了

很多人平时不爱看日志，觉得枯燥、杂、信息太多。可真到了故障现场，日志和监控往往是最接近真相的东西。

运维侧常看这些

journalctl -xe
journalctl -f
dmesg | tail -n 50
grep -i error /var/log/messages
grep -i denied /var/log/secure

重点看：

• 服务报错
• 内核网络异常
• 拒绝访问
• 资源耗尽
• 时间点是否和故障一致

网工侧一般看这些

• 设备日志
• 接口告警
• 链路 flap 记录
• CPU / 内存变化
• 丢包、延迟趋势
• 配置变更记录
• 安全策略命中日志

经验之谈

很多故障不是突然发生的，而是早就有征兆：

• 接口错误包慢慢上涨
• 延迟长期抖动
• 高峰期资源持续打满
• 某次变更后开始异常

所以排障别只看“现在”，前后时间线也很重要。

九、真正拉开差距的，不是会多少命令，而是排查顺序

做网络排障时间长了，你会慢慢发现，真正厉害的人，不一定是背命令背得最多的人，而是脑子里一直有一条很清晰的线。

我自己更习惯按这个顺序来：

第一步：先判断范围

• 是单台机器？
• 一个网段？
• 某个业务？
• 还是全网？

第二步：运维先测基础连通，网工同步看接口和路径

ip addr
ip route
ping -c 4 网关
ping -c 4 目标IP

第三步：运维看端口和服务，网工看转发和策略

ss -lntp
nc -zv 目标IP 端口
curl -v http://目标地址

第四步：必要时两边一起抓包、对日志

tcpdump -i eth0 host 目标IP -nn
journalctl -f
iptables -L -n -v

第五步：把现象对齐，再缩范围

这个步骤特别重要。 真实现场最怕的不是查不到，而是信息没对齐。运维说“服务没问题”，网工说“链路没问题”，安全说“策略也没问题”，结果大家说的根本不是同一个点。

所以排障一定要对齐：

• 哪个 IP 不通
• 哪个端口不通
• 是源到目的不通，还是某一跳不通
• 是偶发，还是持续
• 是单点问题，还是范围性问题

把这些对齐，效率会高很多。

写在最后

网络故障排查，最怕的不是问题复杂，而是没顺序、靠猜、乱改、乱重启。

真正靠谱的办法，其实一直都很朴素：

❝先看物理层，再看链路层；再查 IP、ARP、路由；然后测端口、看连接、抓包；最后把应用、日志、安全策略一起对上。

而且真实现场里，最有效的排障，往往不是某一方单打独斗，而是运维和网工把信息拼起来一起看。

命令当然重要。 但比命令更重要的，是你知道：

• 为什么查
• 先查什么
• 查到什么算异常
• 下一步该往哪层收

说到底，排障不是拼手速，而是拼思路。

你遇到过最离谱的网络故障是什么？欢迎在评论区聊聊。