2026-04-04 05:30:41 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文系统介绍网络故障分层排查方法论，强调从物理层到应用层的顺序检查原则。提供运维侧与网络设备侧的双视角排查指南，涵盖链路状态、路由验证、端口检测等实操命令，并指出常见误区如过度依赖ping测试。核心建议是建立标准化排查流程以避免现场混乱。 综合评分： 85 文章分类： 安全运营,实战经验,解决方案,网络安全,其他

cover_image

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

原创

释然释然

释然IT杂谈

2026年4月3日 08:18 上海

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

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

其实绝大多数网络问题，都有一条相对清晰的定位路径。只要别跳着查，从物理层、链路层、网络层，一层层往上看，很多问题并没有想象中那么难。这篇文章，我不只从单一视角去讲，而是尽量把运维主机侧和网络设备侧两种排查方式放在一起。说白了，就是既告诉你服务器上怎么查，也告诉你交换机、路由器、防火墙那边通常该看什么。这样更贴近真实故障现场，也更适合日常排障落地。

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

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

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

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

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

❝

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

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

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

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

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

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

运维侧先看什么

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

查看网卡状态：

ip link
ethtool eth0

查看网卡统计信息：

ip -s link show eth0
ethtool -S eth0

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

dmesg | grep -Ei&nbsp;'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 是否误拦截
安全域划分是否影响流量
VPN / IPS / IDS 是否误杀
是否有黑白名单或策略路由影响

这类问题的典型特征

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

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

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

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

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

运维侧重点看什么

查看网卡流量：

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、路由；然后测端口、看连接、抓包；最后把应用、日志、安全策略一起对上。

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

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

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

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

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

另外我给大家整理了一些技术资料，有需要可以直接下载：

链接：https://pan.quark.cn/s/7063628fb0be

需要什么资料，也可以在评论区留言，或者联系小编咨询。

EOF –

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：释然IT杂谈释然释然《网络故障排查实战指南：别一出问题就重启，按层查才靠谱》