Linux 网络故障排查完全指南：从 ping 不通到 TCP 握手失败，一次讲透排查思路

写在前头：上周三凌晨两点，我正改代码改到入神，突然居家 Ollama 集群全部断联——Dify 前端报 502，Proxmox 面板打不开，连路由器管理页面都进不去。当时脑子里闪过的第一个念头是：完蛋，又被黑了。但冷静下来按照排障流程走一遍才发现，真相远比我以为的简单得多。

这篇文章就把我十年运维生涯里沉淀下来的那套可复用的排查方法论整理出来——不管你是刚买第一台 VPS 的站长，还是在家折腾 Homelab 的玩家，下次网络出问题的时候，照着这篇一步步查，大概率能自己搞定。

---

一、排障第一步：建立分层思维

很多新手遇到网络故障的第一反应是——重启。这其实是最大的错误。重启确实能解决一部分问题，但永远不告诉你”为什么”。

我的建议：永远按照 OSI 模型从底往上排查。

应用层（第7层）← 先检查这里是不是应用本身的问题

传输层（第4层）← 端口通不通？TCP握手有没有完成？
网络层（第3层）← 路由可达吗？ICMP通不通？
链路层（第2层）← ARP能解析吗？MAC地址对吗？
物理层（第1层）← 网线插好没？光模块亮不亮？

关键词：从底往上，逐层排除。 物理层没通就去抓应用层日志，纯属浪费时间。

---

二、物理层+链路层：先确认”路没断”

别笑，我遇到过太多次”专家级”排查半天，最后发现网线水晶头松了。先排除最简单的原因，再碰复杂的。

# 检查网卡链路状态（物理层）

ip link show
# 看输出中的 state UP/DOWN/LOWER_UP
# LOWER_UP 表示物理层已建立连接
# 检查网卡错误计数
ip -s link show eth0
# 重点关注：errors, dropped, overruns 数字是不是持续增长

如果 ip link show 显示 state DOWN，先检查网线、交换机端口、光模块。如果显示 state UP 但 LOWER_LAYERDOWN，说明物理层有问题但驱动加载了——查光模块兼容性或协商模式。

# 检查ARP表（链路层）

ip neigh show
# STALE/REACHABLE 是正常的
# FAILED/INCOMPLETE 说明ARP解析失败

ARP解析失败意味着二层链路不通——查VLAN配置、查交换机端口是否在正确的Access/Trunk口上。

---

三、网络层：ping 不通到底是谁的锅？

ping 是最基础但也最容易被误解的工具。ICMP不通不等于TCP不通——很多云服务商默认禁ICMP。

# 基础连通性测试

ping -c 5 192.168.1.1      # 测到网关
ping -c 5 8.8.8.8          # 测到外网
# 如果ping不通，用traceroute找断点
mtr -r 8.8.8.8
# -r 表示report模式，连续发探测包统计丢包率

mtr 的输出怎么读？ 看两点：

1. 最后一跳之前的某个节点 Loss% 从0%跳到100% → 断点大概率就是这一跳

2. 所有节点都0%丢包但到不了目标 → 目标节点禁ICMP或防火墙拦截

# 检查路由表

ip route show
# default via ... 这条在不在？
# 目标子网有没有正确的路由条目？

排障场景： 能ping通外网IP但无法访问某个域名？直奔 DNS：

# 测试DNS解析

nslookup www.vpnt.top
dig www.vpnt.top +short
# 如果DNS超时或返回错误IP
# 检查 /etc/resolv.conf 看DNS服务器配置
cat /etc/resolv.conf

---

四、传输层：TCP 握手失败的经典对决

网络层通了但应用还是连不上？问题大概率在传输层。 端口没开、防火墙拦截、半连接队列满了，都是常见原因。

# 检查端口是否在监听（ss比netstat快10倍）

ss -tlnp
# -t TCP -l 监听态 -n 不解析服务名 -p 显示进程
# 检查所有TCP连接状态
ss -tan | head -30
# ESTAB    正常连接
# LISTEN   在监听
# TIME_WAIT 正常关闭后的等待
# SYN_RECV 握手进行中（大量SYN_RECV=疑似SYN Flood攻击）
# CLOSE_WAIT 对方已关闭但本机没关（内存泄漏的经典症状）

三次握手失败怎么查？ 直接抓包，不用猜：

# 在服务器上抓传入的流量

tcpdump -i eth0 port 443 -nn -c 20
# -nn 不解析主机名和服务名，更快更清晰
# 如果是握手失败，应该能看到 SYN → SYN-ACK 之后没有 ACK
# 或者服务器直接回了 RST（reset）

两个最坑的排障案例分享：

案例一：conntrack 表满了。 服务器跑了半年，突然新连接全部超时。dmesg 里看到 nf_conntrack: table full, dropping packets。解决方法：

# 当前连接跟踪数

sysctl net.netfilter.nf_conntrack_count
# 最大限制
sysctl net.netfilter.nf_conntrack_max
# 临时调大
sysctl -w net.netfilter.nf_conntrack_max=524288
# 永久生效：写 /etc/sysctl.conf

案例二：MTU 分片导致 SSH 能连但大包传不了。 症状很诡异——ping小包通，但拉文件、看网页都超时。因为小包不需要分片，大包被中间设备丢弃了：

# 检测路径MTU（不设置不分片标志）

ping -M do -s 1472 8.8.8.8
# -M do 不允许分片，-s 1472（1472+28=1500 MTU）
# 如果不通，逐步减小 -s 的值测试
# 找到能通的最大值，就是实际路径MTU
# 在服务器设置小MTU（治标但稳）
ip link set dev eth0 mtu 1450

---

五、防火墙与策略路由：你以为你配对了？

防火墙问题是运维中最常见也最隐蔽的网络故障源。iptables规则链执行顺序是个被无数人忽视的坑：

# 查看 iptables 规则（逐条数着看）

iptables -L -n -v --line-numbers
# -v 可以看每条规则的匹配字节数，据此判断哪条规则被命中了
# 查看 nat 表（端口转发、SNAT/DNAT）
iptables -t nat -L -n -v --line-numbers
# 清空规则做排障（⚠️ 生产环境慎用！先备份！）
iptables-save > /tmp/iptables-backup-$(date +%Y%m%d).txt
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F
# 如果清了规则后服务恢复正常 → 就是防火墙规则的问题

nftables 用户（现在大部分新发行版默认用这个）：

nft list ruleset

策略路由是另一个隐形炸弹。 如果服务器有多块网卡（比如内网+外网），默认路由可能不是你想的那样：

# 查看策略路由规则

ip rule show
# 查看所有路由表
ip route show table all

两个网卡时回包走错路由的经典场景： 内网发来的请求，服务器处理完后从外网网关回包了——对方收到SYN-ACK但跟预期来源IP不一致，直接RST。解决方案就是策略路由，让回包走原路。

---

六、eBPF 高级排障：当传统工具不够用时

这是我这几年用的最多的”核武器”级别排查手段。bpftrace 可以让你在内核层面看谁在丢包、哪里在延迟，并且对生产环境几乎零侵入。

# 安装 bpftrace

apt install bpftrace    # Ubuntu/Debian
yum install bpftrace    # CentOS/RHEL
# 追踪谁在丢包
bpftrace -e 'kprobe:kfree_skb { printf("skb dropped: %s (pid=%d)\\n", kstack, pid); }'
# 追踪TCP连接延迟（找出握手慢在哪一跳）
bpftrace -e 'kprobe:tcp_v4_connect { printf("connect to %s:%d\\n", ntop(6, arg1), arg2); }'

不过这玩意儿需要内核支持 BTF，如果你的内核版本低于 5.x，老老实实用前面的传统方法。不是每台机器都配得上 eBPF。

---

七、排障决策流程图（附mermaid源码）

用 mermaid 画了一个完整的排查路线图，可以直接拷贝到你的笔记里：

flowchart TD

A[网络故障] --> B{能ping通网关？}
B -- 否 --> C[检查网线/光模块/交换机口]
B -- 是 --> D{能ping通目标IP？}
D -- 否 --> E[mtr追踪路由断点]
D -- 是 --> F{能解析域名？}
F -- 否 --> G[检查DNS配置 /etc/resolv.conf]
F -- 是 --> H{目标端口开放？}
H -- 否 --> I[ss -tlnp检查监听+防火墙规则]
H -- 是 --> J{tcpdump抓包看握手}
J -- 三次握手异常 --> K[检查conntrack/syn backlog/MTU]
J -- 正常但数据传不了 --> L[检查防火墙策略路由/MTU]

---

写在最后

网络排障说到底没有什么黑魔法，核心就三件事：知道从哪开始查、会用对的工具、理解输出结果在说什么。

我把最常用的命令整理成一个速查清单，保存下来以后直接用：

诊断目标 命令 关键输出解读 链路状态 ip link show state UP/DOWN, LOWER_UP IP地址 ip addr show 地址/掩码是否正确 路由表 ip route show default gateway在不在 ARP解析 ip neigh show REACHABLE/FAILED 端口监听 ss -tlnp LISTEN的端口和进程 连接状态 ss -tan ESTAB/SYN_RECV/TIME_WAIT 防火墙 iptables -L -n -v 规则命中计数 抓包分析 tcpdump -i eth0 port 80 -nn 三次握手/重传/RST 路径追踪 mtr -r 8.8.8.8 每一跳的丢包率 DNS诊断 dig domain +short 解析结果是否正确 conntrack conntrack -L 连接跟踪表状态

下次你的服务器网络出问题，先别急着重启。打开终端，从这个清单第一行开始往下查，10分钟内大概率能定位到根因。有些坑踩过一遍，以后就再也不会掉进去了。

对了，开头说的那个凌晨断联事件，最后查出来是什么原因？ 不是黑客，不是路由坏，是 Proxmox 一块网卡的 RX FIFO 溢出——纯硬件层面的小概率故障，重启网卡驱动就恢复了。但如果不是按”从底往上”的流程查到物理层错误计数，我可能还在应用层翻日志翻到天亮。

排查框架永远不会背叛你，但直觉会。