Linux 服务器的网络问题在生产环境中出现频率极高，且往往是“看起来没问题但就是连不上”的类型。网络故障的排查核心在于分层和逐层验证，而不是盲目重启网络服务或改配置。
现代 Linux（systemd + NetworkManager / systemd-networkd / ifcfg / netplan）网络栈主要基于内核的 netdevice + iproute2 工具族。本文按 OSI 模型的简化版（物理 → 链路 → 网络 → 传输 → 应用）组织内容，重点放在服务器最常见的 80% 场景。
1. 网络分层排查框架（推荐的思考顺序）
| 层级 | 关注点 | 核心命令 / 检查点 | 常见症状 | 成功标准 |
|---|---|---|---|---|
| 1. 物理/链路 | 网卡是否 up、链路是否 up、有无 carrier | ip link show、ethtool eth0 | no carrier、link down | STATE UP + carrier detected |
| 2. 接口配置 | IP、掩码、网关、MTU 是否正确 | ip addr show、ip route show | IP 丢失、配置不对 | 看到正确的 inet / default via |
| 3. 本地网络 | ARP 是否正常、能否 ping 同网段 | ping 网关 IP、arp -n | 同网段不通 | ARP 表有对应 MAC |
| 4. 路由与转发 | 默认路由是否存在、策略路由是否干扰 | ip route get 8.8.8.8、ip rule show | 能 ping 网关但上不了外网 | route get 显示正确 nexthop |
| 5. 防火墙 | iptables/nftables/firewalld/ufw 是否阻断 | iptables -L -n -v、nft list ruleset、firewall-cmd --list-all | 能本地连但外部连不上 | 允许预期端口/流量 |
| 6. DNS | 域名解析是否正常 | dig/nslookup/resolvectl query、cat /etc/resolv.conf | ping IP 通但域名不通 | 能正确解析出 IP |
| 7. 传输层 | TCP/UDP 连接建立、超时、重传 | ss -ltnp、ss -antip、tcpdump | 连接建立慢、SYN_SENT 堆积、RST | ESTABLISHED 状态正常 |
| 8. 应用层 | 服务监听端口、进程是否绑定正确 | ss -ltnp、netstat -ltnp、lsof -i | 外部 curl/telnet 失败但本地可以 | LISTEN 在 0.0.0.0 或 :: |
2. 快速网络健康检查清单（一分钟诊断）
执行以下命令组合，几乎能覆盖 70% 的网络问题：
- 接口状态ip -c link show（看是否有 UP 和 carrier）
- IP 与路由ip -c addrip -c route
- 默认网关连通性ping -c 4 -W 2 $(ip route show default | awk '{print $3}')
- 外网连通性ping -c 4 8.8.8.8 或 ping -c 4 1.1.1.1
- DNS 解析dig +short google.com 或 nslookup baidu.com 8.8.8.8
- 端口监听ss -ltnp | grep :80 或 :443
- 当前连接ss -antip | grep ESTAB | wc -l（连接数是否异常高）
如果以上任意一步失败，从该层开始深入。
3. 常见故障场景与标准排查路径
场景 A：服务器完全失联（SSH 连不上）
- 物理层：机房/云厂商控制台 → 网卡是否 up？是否有 carrier？
- 控制台登录 → ip link set eth0 up
- 检查是否有 DHCP client 运行（systemctl status systemd-networkd-dispatcher 或 dhclient）
- 手动加 IP（临时）：ip addr add 192.168.1.100/24 dev eth0
- 加默认路由：ip route add default via 192.168.1.1
场景 B：能 ping 网关但上不了外网
- 确认默认路由：ip route get 8.8.8.8
- 检查防火墙：iptables -L -n | grep DROP 或 firewall-cmd --list-all
- 检查 NAT/转发（如果做 NAT）：sysctl net.ipv4.ip_forward
- 检查 MTU 不一致：ping -M do -s 1472 8.8.8.8（若不通逐步减小）
场景 C：DNS 解析失败或极慢
- 查看配置：cat /etc/resolv.conf（注意 systemd-resolved 会覆盖它）
- 测试上游：dig @8.8.8.8 google.com
- 检查本地缓存：systemd-resolve --statistics 或 resolvectl status
- 常见问题：resolv.conf 被 NetworkManager 覆盖、search 域导致解析慢
场景 D：服务启动了但外部访问不到
- 确认监听地址：ss -ltnp | grep :80（必须是 0.0.0.0 或 ::）
- 本地 curl 测试：curl -v http://localhost、curl -v http://127.0.0.1
- 检查 SELinux/AppArmor：ausearch -m avc -ts recent、aa-status
- 检查防火墙：ufw status、firewall-cmd --list-all、iptables -L -n
- 检查端口冲突：ss -ltn | grep :80
场景 E：连接数异常高 / TIME_WAIT 堆积
- 查看统计：ss -s
- TIME_WAIT 过多：sysctl net.ipv4.tcp_fin_timeout、net.ipv4.tcp_tw_reuse
- SYN 队列溢出：netstat -s | grep -i listen 或 ss -ltn state syn-recv
- 调优：增大 somaxconn、tcp_max_syn_backlog
4. 网络抓包与高级诊断工具
- tcpdump（最通用） 抓取特定端口：tcpdump -i eth0 port 80 -nn 抓取 SYN：tcpdump 'tcp[tcpflags] & tcp-syn != 0'
- ss（比 netstat 快得多） ss -o state established（显示 timer 信息） ss -K dst 1.2.3.4（杀掉特定连接）
- mtr（结合 ping + traceroute） 实时路径延迟与丢包：mtr 8.8.8.8
- nload / iftop / iptraf（流量监控）
5. 现代 Linux 网络管理工具对比（2026 年现状）
| 管理方式 | 配置文件位置 | 重启网络命令 | 云厂商默认推荐 | 特点 |
|---|---|---|---|---|
| NetworkManager | /etc/NetworkManager/ | nmcli con reload / nmcli con up | AWS Lightsail、Azure | 图形化友好、动态性强 |
| systemd-networkd | /etc/systemd/network/ | networkctl reload / systemctl restart systemd-networkd | Ubuntu Server 20.04+、Fedora | 轻量、无额外依赖 |
| ifcfg（传统 RHEL） | /etc/sysconfig/network-scripts/ | nmcli 或 ifup/ifdown | 老 Rocky/Alma 部分镜像 | 正在逐步被淘汰 |
| netplan | /etc/netplan/ | netplan apply | Ubuntu Desktop/Server | 声明式 YAML 配置 |
总结：网络故障排查口诀
“从下往上，一层不通就别往上查”
- 链路 up 了吗？（ip link / ethtool）
- IP 配置对了？（ip addr / ip route）
- 网关 ping 通？（ping 默认网关）
- 外网 IP ping 通？（8.8.8.8）
- 域名解析正常？（dig）
- 服务端口在监听？（ss -ltnp）
- 防火墙放行了吗？（iptables/firewalld/ufw）
- 有没有抓包确认？（tcpdump）
建立这个逐层验证的习惯后，90% 的网络问题都能在 10–30 分钟内定位到具体原因，而不是反复重启网络服务或盲目修改配置。
后续可以深入的方向：eBPF 网络观测（bpftrace、cilium）、nftables 取代 iptables、SR-IOV/VFIO 虚拟化网络、QUIC/HTTP3 时代的新特性等。