Linux 网络问题的系统化排错模型

网络故障排查应先 ping 127.0.0.1 和本机 IP 定位本地协议栈问题，再 ping 网关判断二层连通性，继而检查路由、ARP、防火墙、端口监听及 dns 解析各环节。

从 ping 失败开始，先确认是本机问题还是路径问题

很多网络故障一上来就怀疑远程服务或防火墙，其实 ping 127.0.0.1 和 ping 能快速定位是否是本地协议栈异常。如果前者通、后者不通，大概率是网卡 down、IP 配置丢失或 net.ipv4.conf..disable_policy 类内核参数被误设。

接着试 ping ：通则说明二层可达，问题在三层及以上；不通则要查 ip link show 看接口状态、ip addr show 看地址是否生效、arp -n 看网关 mac 是否可解析。常见坑包括：

• ip link set dev eth0 up 执行后没配 IP，接口“up”但无地址，ping 仍失败
• 多网卡环境里，默认路由指向了错误接口，ip route show 必须逐行核对
• 某些云平台（如 AWS）禁用 ICMP，ping 不通不等于网络不通，得换 telnet 或 curl -v

连接超时或拒绝，重点查 iptables、nftables 和 socket 绑定

能 ping 通但 curl 或 telnet 超时，通常卡在传输层。先运行 ss -tlnp 确认目标端口是否真在监听，注意看 State 列是否为 LISTEN，以及 Addr:Port 是 *:80 还是 127.0.0.1:80 —— 后者只响应本地连接。

若服务确实在监听，再查包过滤规则：

• iptables -L -n -v 和 nft list ruleset 二者可能共存，旧系统常残留 iptables 规则，而 nft 已接管，需都检查
• iptables -I input -j LOG --log-prefix "DROP:" 可临时加日志，配合 dmesg -w 实时观察丢包原因
• 容器环境里，宿主机 FORWARD 链默认常为 DROP，必须显式放行或启用 net.bridge.bridge-nf-call-iptables=1

tcpdump 抓不到包？先排除接口、过滤和权限问题

tcpdump -i eth0 port 80 没输出，不等于没流量。先确认：

• 接口名是否正确：ip link show 查真实名称（如 ens3、enp0s3），别凭经验写 eth0
• 是否抓错方向：客户端发请求时，在服务端抓 tcpdump -i any port 80 and src host 更可靠
• 是否被 offload 干扰：某些网卡开启 TSO/GSO，导致 tcpdump 看到的包大小异常甚至为空，可临时关掉：ethtool -K eth0 tso off gso off
• 普通用户无法抓包？不是权限问题就是 cap_net_raw 缺失，sudo getcap /usr/sbin/tcpdump 查，必要时补：sudo setcap cap_net_raw+ep /usr/sbin/tcpdump

DNS 解析失败，分清是 resolver 还是 upstream 问题

nslookup example.com 失败，不能直接断定 DNS 服务器挂了。先用 dig @8.8.8.8 example.com 绕过本机配置直连上游，若成功，说明问题出在本地 /etc/resolv.conf 或 systemd-resolved。

常见混淆点：

• systemd-resolved 默认监听 127.0.0.53，但 /etc/resolv.conf 可能软链到它，也可能被 NetworkManager 覆盖成其他地址，resolvectl status 才是唯一可信来源
• 使用 dnsmasq 时，cat /var/run/dnsmasq/resolv.conf 才是它实际转发的目标，不是 /etc/resolv.conf
• ipv6 DNS 查询失败却影响 IPv4？因为 glibc 默认启用 AF_INET6 查询优先，可通过 echo 'options inet6' > /etc/resolv.conf 临时禁用验证

真正难缠的是那些看似解析成功、但返回 NOERROR + 空应答的场景——往往意味着上游 DNS 拒绝递归或域名未配置，这时候 dig +trace 比任何工具都管用。