Linux 网络故障排查：从网卡到路由的定位思路

服务器无法访问时，盲目重启服务或更换网线往往解决不了问题，正确的做法是按照"层层筛选"的思路缩小故障范围。本文分享生产环境 Linux 网络故障排查的整体方法论：先判断是本机问题还是网络上其他设备的问题，如果同一网络环境中的其他主机正常，就去路由器等网络设备上检查是否有限制，否则问题就在本机。接下来用 ethtool、ping、route、nslookup、tracepath 等命令逐层定位，覆盖网卡、防火墙、IP 配置、路由、DNS、数据包路径六大环节。

一、网线和网卡设置检查

ethtool ens33
ethtool -i ens33
ethtool -p ens33 10
ethtool -S ens33

先看网卡灯是否亮起，再用 ethtool 查看链路是否物理连通（重点看 Speed、Duplex、Link detected 字段）。-i 查看驱动信息，-p 让网卡 LED 闪烁以区分物理位置，-S 查看收发字节、广播包等统计参数，-s 可修改速率与双工模式。

读 ethtool 输出要抓三个关键字段：Link detected 决定物理层是否连通；Speed 与 Duplex 不匹配时表现为"能 ping 通但传输极慢"，典型是千兆协商成百兆、全双工协商成半双工；rx_crc_errors、rx_errors、tx_errors 持续增长，基本可判定网线、光模块或对端端口存在硬件问题。同一条链路上还要看 collisions，只有半双工链路才会出现明显的碰撞计数。

如果链路状态在 up/down 之间反复跳变（link flapping），用 dmesg -T | grep -iE "link|carrier" 与 journalctl -k 对照时间点，原因多是网线水晶头氧化、光纤端面未清洁或收光功率不足。ethtool -S 里 rx_missed_errors 偏高说明收包队列溢出，需要在驱动层调大 ring buffer 而不是换线。

ip -br link                       # 一次看到所有网卡的 state 与 MAC
ip -br addr                       # 一次看到所有网卡的 IP 状态
cat /sys/class/net/ens33/carrier  # 1=物理链路已建立，0=已断开
dmesg -T | grep -i ens33 | tail -20

二、SELinux 与防火墙排查

这两个是最容易产生干扰的项目。排查网络故障时务必确认 selinux 状态与防火墙规则是否放行所需端口，避免在错误的方向上浪费时间。

getenforce                    # Enforcing / Permissive / Disabled
sestatus                      # 查看当前策略与模式
iptables -S                   # 以规则形式列出 filter 表
iptables -t nat -L -n -v      # 看 NAT 规则与命中计数
firewall-cmd --list-all       # firewalld 当前 zone 与放行端口
nft list ruleset              # nftables 规则一览

排查时最有效的动作是"临时全放行再看现象"：执行 setenforce 0 并临时停掉 firewalld，问题消失就说明是策略阻断，再按最小化原则逐条放行端口。注意 iptables -L 默认不显示端口与命中计数，加 -n -v 才能看到命中数，命中数为 0 的规则往往说明流量根本没走到这条链。另外要留意 INPUT DROP 与 FORWARD DROP 这两条默认策略，容器与转发类业务最容易被 FORWARD 链拦住。

三、IP 与网关配置

使用 ifconfig 或 nmcli 查看/设置 IP 地址和网关，确认 IP 配置与局域网其他计算机没有冲突。

ip -br addr; ip -br link
nmcli connection show
nmcli dev status
arping -I ens33 -c 3 192.168.2.1   # 探测该 IP 是否被其他主机占用

IP 冲突的典型特征是"时通时断、偶发丢包"，用 arping 探测会收到两个不同 MAC 的应答，此时应先在交换机上查该 IP 的 MAC 表，把冲突主机下线后再恢复。多网卡服务器还要确认默认网关只保留一个，否则会出现"从哪块网卡回包"的选路歧义；同时检查网卡上是否有残留的第二个 IP，避免业务监听地址漂移。

四、ping 连通性测试

ping -c 3 -i 0.5 -n -s 1024 -I 192.168.2.220 192.168.2.220

-c 指定次数、-i 间隔、-s 数据包大小、-I 指定源地址（源地址必须是本地网卡上存在的配置）。先 ping 局域网主机，再 ping 网关，判断主机到网关的通信是否正常。

ping 的返回信息本身就能区分故障层次：Destination Host Unreachable 说明本机或网关没有到达目标的路由（三层问题）；Request timeout 说明路由存在但对端不回包，可能是对端防火墙丢包或链路中断；Network is unreachable 说明本机根本没有匹配的路由条目；丢包率在 20%-50% 之间波动，则优先怀疑双工不匹配或链路质量。注意 -I 指定的源地址必须是本机已配置的地址，否则命令直接报错而不是提示。

五、路由表检查

很多时候 IP 没配错、网卡也正常，但路由配置不正确导致网络问题。用 route 命令查看路由表，多网卡服务器尤其要注意各网卡不同网段时的路由走向，必要时修改静态路由配置。

ip route show
ip route get 8.8.8.8        # 直接问内核：会选哪条路由、用哪个源地址
ip route show table all     # 多路由表（策略路由）场景
ip rule show

ip route get 是排查"通与不通"最省时间的一条命令，它直接给出内核的实际选路结果，包含出口网卡与源 IP。多网卡服务器常见的故障是两条默认路由 metric 相同，导致回包从错误的网卡发出，表现为"请求能到、响应回不来"。策略路由场景要同时看 ip rule 与对应表 ip route show table 100，实践中遗漏规则比遗漏路由更常见。

六、DNS 解析验证

理解 /etc/hosts 与 /etc/resolv.conf 的解析顺序，用 nslookup、dig、host 验证域名解析是否正常——网页打不开但 IP 能通时，问题十有八九在 DNS。

grep hosts /etc/nsswitch.conf    # 确认 files 与 dns 的先后顺序
dig +short www.example.com
dig +trace www.example.com       # 从根开始逐级验证委派链
resolvectl status                # systemd-resolved 当前上游与生效 DNS
curl -v --resolve www.example.com:443:1.2.3.4 https://www.example.com

判断"是 DNS 还是服务"最快的办法就是 curl -v --resolve：手动指定 IP 能通说明域名解析环节有问题，仍然不通说明问题在 TCP 层以后。dig +trace 能定位到哪一级 NS 没有返回正确记录，适合排查域名迁移后缓存未生效；resolvectl status 能看到每个网卡实际生效的 DNS 服务器，避免改了 /etc/resolv.conf 又被 NetworkManager 覆盖回默认值。

七、追踪数据包路径

tracepath -b www.example.com -l 1000 -m 5

tracepath 替代了以前的 traceroute：-n 只显示 IP 不查主机名（DNS 失效时常用），-m 设置最大 TTL，-p 指定探测端口。通过逐跳输出可以定位网络中断的网关位置。最后，若所有检查都正常仍无法连通，就要考虑硬件故障，更换硬件验证。

实际排障中更推荐 mtr：它把 ping 与 traceroute 合二为一，能持续统计每一跳的丢包率、平均延迟与抖动，还能区分"中间节点丢包但末端正常"（多为 ICMP 限速而非真实故障）与"从某一跳开始持续丢包"（真实链路问题）。

mtr -rwzc 100 8.8.8.8              # -r 报告模式、-w 宽屏、-c 次数，便于留存
tracepath -n 8.8.8.8
ping -M do -s 1472 -c 3 目标IP     # 不分片探测 1500 字节载荷，验证 MTU 黑洞

若小包正常、大包不通，且 TCP 建连卡在 SYN 之后，基本就是 MTU/MSS 黑洞问题，需要检查隧道接口 MTU 与 MSS 钳制配置。再往后才是硬件层：交换机端口灯状态、光模块收发光功率、网线替换法，逐项排除即可锁定故障点。

八、抓包验证：让数据包自己说话

前面七步都是"从配置推断行为"，抓包则是直接观测。经验是把抓包放在"连通性明确有问题、但配置检查全部正常"的场景，避免一上来就陷入海量报文的分析。

tcpdump -i ens33 -nn host 192.168.2.100 and port 80 -c 20
tcpdump -i any -nn -e 'tcp[tcpflags] & tcp-syn != 0'    # 只看建连 SYN
tcpdump -i ens33 -nn -w /tmp/cap.pcap 'host 10.0.0.5'     # 落盘后用 Wireshark 看

看包要先看方向再看内容：请求发出去了但没有回应，问题在链路或对端；收到 SYN 但本机不回 SYN-ACK，问题在本机协议栈或防火墙；持续重复 SYN 而始终没有 ACK，说明握手被中间设备静默丢弃。把抓包结果与 ethtool -S 的收发计数、ss -s 的 socket 统计放在一起看，能快速区分是链路丢包还是应用没响应。

九、按报错信息反查故障

• Network is unreachable：本机没有匹配路由，检查 ip route 与默认网关。
• Connection refused：链路与路由都正常，但对端端口没有监听或主动拒绝，用 ss -lntp 核对监听地址是否为 0.0.0.0。
• Connection timed out：路由可达但握手被静默丢弃，优先怀疑中间防火墙与云安全组。
• No route to host：通常伴随 ARP 解析失败，检查同网段 IP 配置与 VLAN 划分。
• Temporary failure in name resolution：DNS 不可用，或 /etc/resolv.conf 被网络管理组件覆盖。

十、一页纸排查顺序

ethtool ens33 | grep -E "Speed|Duplex|Link detected"   # 物理与链路层
ip -br link; ip -br addr; ip route get 目标IP           # 三层配置与选路
ping -c 3 网关; ping -c 3 目标IP                        # 连通性
ss -lntp; ss -s                                         # 四层监听与连接数
dig +short 域名; curl -v --resolve 域名:443:IP https://域名
mtr -rwzc 50 目标IP; tcpdump -i ens33 -nn 目标IP        # 路径与报文

按这个顺序走一遍，绝大多数网络故障都会收敛到唯一一层，剩下的就是替换硬件或修正配置这类确定性操作。

更多参考：ethtool 网卡诊断完整指南、tcpdump 命令示例与过滤表达式、mtr 定位丢包与延迟、systemd-resolved 与 resolvectl 排障。

原文链接：https://www.cnblogs.com/yihr/p/17778962.html