Linux 网络故障排查：从网卡到路由的完整思路

2026年8月26日 LOG admin

服务器无法连通时，盲目重启或乱改配置只会让问题更复杂。本文提供一套生产环境可复用的 Linux 网络故障排查思路：先判断是本机问题还是网络设备问题，再按"网线网卡 → SELinux/防火墙 → IP 网关 → ping → 路由 → DNS → 数据包追踪"逐层缩小范围，附 ethtool、ping、tracepath 等命令的详细参数说明。

一、排查总原则：先分层，再动手

网络上有一个通用模型，排查故障时同样适用：物理层、数据链路层、网络层、传输层、应用层，自下而上逐层验证。绝大多数"网络不通"最终都被证明是物理层或配置层的问题，而不是内核 bug。

动手之前先问自己三个问题：

范围：只有这一台机器不通，还是同网段多台机器都不通？单机问题看本机配置，多机问题看交换机、网关或上游链路。
方向：别人 ping 不通我，还是我 ping 不通别人？方向不同，需要检查的环节完全不同。
时间点：故障是突然出现的，还是从来就没通过？突然出现多半是配置变更或硬件老化，从来没有通过则多半是规划或配置错误。

回答完这三个问题，排查范围通常能压缩到一两个层级。下面按顺序给出每一层的具体命令和判断依据。

二、网线和网卡检查

先看网卡灯：服务器网卡绿灯常亮正常，交换机绿灯闪烁表示在传数据。用 ethtool 检查链路是否物理连通：

ethtool ens33                  # 查看链路状态（Link detected: yes）
ethtool -i ens33               # 驱动信息
ethtool -p ens33 10            # 让网卡 LED 闪烁定位物理位置
ethtool -S ens33               # 收发包统计
ethtool -s ens33 speed 1000 duplex full autoneg on port tp   # 修改速率/双工/自协商

几个关键判读点：

Speed 与 Duplex：如果千兆链路协商成了 100Mbps 或半双工，说明线缆质量差、水晶头接触不良或对端端口有问题。半双工几乎必然带来冲突和丢包。
Link detected：为 no 时说明物理链路根本没建立，先换线、换端口，再怀疑网卡。
ethtool -S 中的 rx_crc_errors、rx_errors、tx_errors、rx_missed_errors：CRC 错误持续增长说明线缆或光模块有问题；rx_missed_errors 增长则说明环形缓冲区被打满，需要调大中断合并或接收队列。

如果网卡是 bonding 或 team 成员，还要用 cat /proc/net/bonding/bond0 确认当前活动网卡和 LACP 协商状态，避免只检查了一块从卡。

三、SELinux 与防火墙

SELinux 与 iptables/firewalld 是最容易产生干扰的两项，先确认服务端口是否被防火墙拦截、SELinux 是否 enforcing。

getenforce                      # Enforcing / Permissive / Disabled
sestatus                        # 详细状态
iptables -L -n -v --line-numbers
firewall-cmd --list-all
firewall-cmd --add-port=8080/tcp --permanent && firewall-cmd --reload
ss -lntp                        # 确认服务确实在监听

排查时先把 SELinux 临时设为 setenforce 0 验证，确认是它导致的问题后，不要长期关闭，而是用 ausearch -m avc -ts recent 找到被拒绝的操作并用 semanage 修正端口标签：

semanage port -a -t http_port_t -p tcp 8080

防火墙方面，注意 CentOS 7/8 的 firewalld 与 iptables 服务不能同时启用；如果用了 Docker，Docker 会自行插入 FORWARD 链规则，容易与宿主防火墙策略冲突，表现为"本机能访问、外部不能访问"。

四、IP 地址与网关

用 ip addr / ifconfig 查看网卡地址，nmcli 管理网络连接，确认默认网关配置正确。

ip addr show
ip -br addr                     # 简洁输出
ip route show
nmcli connection show
nmcli device status
nmcli con mod ens33 ipv4.addresses 192.168.2.220/24 ipv4.gateway 192.168.2.1 ipv4.method manual
nmcli con up ens33

常见错误有：网卡没 UP、掩码写错（例如把 /24 写成 /16 导致跨网段判断错误）、配了 IP 但没配网关、同一网卡配了多个不同网段的地址造成源地址选择异常。双网卡服务器尤其要注意：默认路由只能有一条，多余的默认路由会导致回包走错出口。

五、ping 连通性测试

ping -c 3 -i 0.5 -n -s 1024 -I 192.168.2.220 192.168.2.220
# -c 次数 -i 间隔 -n 不解析主机名 -s 包大小 -I 源地址

ping 的排查顺序建议是：先 ping 本机回环 127.0.0.1，再 ping 本机业务地址，然后 ping 网关，最后 ping 外网地址。每一步都能定位到不同的故障层：

127.0.0.1 不通：TCP/IP 协议栈或 lo 接口被关闭，问题在系统本身。
本机地址不通：网卡未 UP 或路由表异常。
网关不通：二层链路、VLAN 或网关设备问题。
网关通、外网不通：路由、NAT 或上游链路问题。
IP 能通、域名不通：DNS 问题，见第七节。

用 -s 逐渐加大包大小（1472、1473、8000、8972）可以判断 MTU 是否匹配；如果需要固定源地址测试策略路由，用 -I 指定源地址。注意防火墙丢弃 ICMP 时 ping 不通不代表业务不通，此时应改用 telnet 或 nc 测试具体端口：

nc -vz -w 3 192.168.2.220 22
timeout 3 bash -c 'cat < /dev/null > /dev/tcp/192.168.2.220/22' && echo open

六、路由检查

route -n          # 查看路由表与网关
ip route          # 现代推荐用法
ip route get 8.8.8.8    # 查看某目的地实际会选择哪条路由

ip route get 是排查中最好用的命令之一，它直接告诉内核会走哪块网卡、用哪个源地址、走哪条下一跳，比反复对照路由表快得多。如果存在多条相同前缀的路由，注意度量和策略路由表；多网卡场景下还要检查 ip rule show，确认没有把流量引向错误的表。

七、DNS 检查

检查 /etc/hosts 与 /etc/resolv.conf，用 nslookup、dig、host 验证域名解析是否正常。

cat /etc/resolv.conf
getent hosts www.baidu.com      # 按 nsswitch.conf 的真实顺序解析，最贴近应用行为
dig www.baidu.com +short
dig @8.8.8.8 www.baidu.com
systemd-resolve --status | head -30

几个容易忽略的点：/etc/nsswitch.conf 中 hosts 行的顺序决定了先查文件还是先查 DNS；NetworkManager 或 cloud-init 会重写 /etc/resolv.conf，手工修改可能被覆盖；如果 resolv.conf 里是 127.0.0.53，说明系统由 systemd-resolved 接管，此时应该用 resolvectl 排查而不是直接改文件。

八、数据包追踪

tracepath -b www.baidu.com -l 1000 -m 5
# -4/-6 协议版本 -l 初始包大小 -m 最大 TTL -n 不查主机名
mtr -rwzc 20 8.8.8.8

tracepath 已替代旧 traceroute，可逐跳显示路径与 PMTU 发现结果；配合 mtr 可观察每跳丢包率。判读要点：中间某一跳开始丢包但后续跳恢复，通常是该设备对 ICMP 限速，不是真丢包；如果从某一跳开始丢包率一路保持到最后，说明该跳之后存在真实丢包或链路拥塞。

九、抓包定位

当 ping 通但业务不通时，抓包是最直接的证据。在服务器上同时观察请求与响应，可以快速区分"包没到"和"到了但没回"：

tcpdump -i ens33 -nn -c 50 host 192.168.2.100 and port 3306
tcpdump -i any -nn 'tcp[tcpflags] & tcp-syn != 0'
tcpdump -i ens33 -nn -w /tmp/cap.pcap host 10.0.0.5

典型结论：只看到 SYN 没有 SYN-ACK，说明对端没监听或被中间设备拦截；看到 SYN-ACK 但客户端没有 ACK，说明客户端回程路由或防火墙有问题；数据包到达但校验和错误，回到物理层排查。

十、硬件故障

以上都正常仍不通时，考虑网卡/交换机端口/线缆等硬件故障，必要时更换硬件验证。

dmesg -T | grep -i -E 'eth|link|nic'
ip -s link show ens33            # 查看 RX/TX 错误与丢包计数
journalctl -k | tail -50

如果 ip -s link 中 errors 或 dropped 持续增长，而速率又协商不正常，基本可以断定是网卡、光模块或线缆问题，直接更换部件验证即可，不必再在内核参数上浪费时间。

十一、排查顺序速查表

网卡灯不亮 → 换线 / 换端口 / 换网卡。
Link 为 no → 物理层；Link 为 yes 但 ping 网关不通 → VLAN 或二层。
ping 通网关不通外网 → 路由 / NAT。
IP 通域名不通 → DNS / nsswitch.conf。
ping 通端口不通 → 防火墙 / SELinux / 服务未监听。
间歇性丢包 → mtr 定位跳数，再看光功率与 CRC 计数。