< 返回
Linux 服务器网络基础与常见故障排查
2026-02-08 20:56
作者：技术部
阅读量：4
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 时代的新特性等。
网站资讯
关于我们
