Ubuntu 服务器网络故障排查
Ubuntu Server 的网络子系统在 2026 年已经高度模块化，主要由以下几个独立但紧密协作的组件构成：
- 内核网络栈（netdev + tc + nftables/iptables）
- 用户空间配置工具（iproute2 家族：ip、ss、tc 等）
- 配置管理层（Netplan + systemd-networkd 或 NetworkManager）
- 本地解析与缓存（systemd-resolved）
- 安全与过滤（nftables + ufw + 云厂商安全组）
理解这些组件的职责边界、分层关系和常见冲突点，是高效排查网络问题的关键。
1. 现代 Linux 网络分层模型
现代 Linux 网络栈大致遵循以下分层（从下到上）：
| 层级 | 主要组件 | 常见故障表现 | 优先检查点 |
|---|---|---|---|
| 物理/链路层 | 网卡驱动、ethtool、phy | Link down、Speed/Duplex 错配、rx/tx error | ethtool Link detected、dmesg 驱动日志 |
| 接口层 | netdev（内核设备）、ip link | 接口不存在、DOWN 状态、MTU 不匹配 | ip link show、dmesg | grep eth |
| 地址层 | ip addr、ARP、ND | 无 IP、IP 冲突、ARP 缓存问题 | ip addr、arp -a、ip neigh |
| 路由层 | ip route、policy routing、rp_filter | 默认路由缺失、多路由冲突、strict rp_filter | ip route、ip rule、sysctl net.ipv4.conf |
| 传输层 | TCP/UDP 拥塞控制、socket buffer | 连接超时、重传率高、SYN flood | ss -m、tcpdump、nstat |
| 应用层 | DNS、HTTP、TLS | 域名解析失败、证书问题、SNI 过滤 | systemd-resolved、dig @8.8.8.8、curl -v |
| 安全/策略层 | nftables、ufw、fail2ban、云安全组 | 端口不通、出站被阻、conntrack 满 | nft list ruleset、ufw status、conntrack |
排查原则：从下往上逐层验证，每通过一层就基本可以排除下面所有问题。
2. 2025–2026 年 Ubuntu Server 最常见的网络故障根因排序
- Realtek / Intel / Broadcom 网卡驱动兼容性问题 内核 6.8–6.11 系列对部分 Realtek r8125/r8168 芯片支持不完善，高负载下容易出现 tx buffer overflow 或间歇性丢包。 典型表现：iperf3 测试初期正常，跑几分钟后吞吐暴跌甚至断连。
- Netplan 与 systemd-networkd 配置冲突 YAML 缩进错误、renderer 不匹配（networkd vs NetworkManager）、gateway4 已弃用但仍在使用、静态 IP 与 DHCP 同时存在。
- systemd-resolved 被意外覆盖或停止 Docker、VPN 客户端、手动写入 /etc/resolv.conf 后，resolved 缓存失效或 symlink 断开，导致“能 ping IP 不能 ping 域名”。
- 云厂商安全组 / 网络 ACL 出站规则缺失 只配置了 inbound 22 端口，忘记出站 ALL 或特定端口，导致 apt update、curl 等全部失败。
- MTU 不匹配（尤其是隧道、VXLAN、WireGuard、Docker overlay） 默认 1500，隧道封装后有效 MTU 降到 1420–1450，未调整导致碎片丢失。
- conntrack 表溢出（高并发 NAT / 负载均衡场景） nf_conntrack_count 接近 nf_conntrack_max，表现为新连接建立失败。
- 电源管理导致网卡低功耗掉线 部分 PCIe 网卡在 ASPM L1 状态下高负载不稳定。
- phased updates 延迟关键网络包 linux-firmware、linux-modules-extra 等包被分阶段推送，导致新内核启动后缺少固件或模块。
3. 核心排查思维模型
- 链路是否真的 up？ 物理灯亮 ≠ 内核识别成功。必须看到 “Link detected: yes” + carrier。
- IP 是否真的配置成功？ ip addr show 看到 secondary IP 或 scope global ≠ 能正常通信（可能被 policy routing 绕走）。
- 路由是否正确？ 默认路由不止一条时，内核按最长前缀 + metric 选择，不是按出现顺序。
- DNS 是否真的坏了？ 能用 IP 访问但域名不行 ≠ DNS 服务器坏了，可能只是本地 stub-resolver 或缓存问题。
- 防火墙是否真的挡了？ ufw inactive ≠ 没有防火墙（nft list ruleset 可能还有规则，conntrack 也可能满）。
4. 推荐的标准化诊断路径
- 确认物理链路 → ethtool + dmesg
- 确认接口状态 → ip -c link + ip -c addr
- 确认路由表完整性 → ip route + ip rule
- 确认 DNS 解析链路 → dig @8.8.8.8 + dig @本地resolved IP
- 确认本地监听与连接 → ss -ltnp + ss -ant
- 确认出站过滤 → curl -v https://1.1.1.1 + tcpdump icmp
- 确认性能瓶颈 → mtr + iperf3 + nstat -az
5. 预防性配置建议（减少 70% 以上网络故障）
- 网卡驱动：对 Realtek 芯片统一使用 vendor DKMS 驱动而非内核内置 r8169
- Netplan：强制使用 routes 而非 gateway4，启用 optional: true 避免启动卡住
- DNS：永远保留 systemd-resolved，禁止直接写入 /etc/resolv.conf
- 防火墙：ufw 只做简单端口管理，复杂规则统一写 nftables
- MTU：隧道场景统一设置为 1420 或 1450
- conntrack：生产环境建议 nf_conntrack_max ≥ 262144
- 监控：启用 Netdata 或 node_exporter + prometheus，关注 net.iface、conntrack、ethtool 指标
掌握这些理论框架后，即使面对全新的故障场景，你也能通过“排除法 + 分层验证”在 5–15 分钟内定位 90% 的问题根因。
