真正的网络高手，不是 tcpdump 用得多熟，而是知道什么时候不该 tcpdump。
网络问题之所以难排，不是因为工具不够，而是因为排障顺序错了。
这篇文章不堆命令，而是用一条自顶向下（Top-Down）的工程路径，带你把 Linux 网络问题一层一层剥开。
一、为什么要「自顶向下」排网络问题？
现实中的网络问题，往往是这样出现的：
“接口超时了”
“偶发 502”
“高峰期连不上”
“Pod 能 ping，但服务不通”
👉 这些都是应用层症状，而不是根因。
如果一上来就：
tcpdump 抓全流量
怀疑内核参数
怀疑云厂商网络
大概率会越查越乱。
✅ 工程上更可靠的方法是：自顶向下，逐层证伪
应用层（L7） ↓传输层（L4） ↓网络层（L3） ↓链路 / 物理层（L2 / L1） ↓内核与资源约束
每一层只回答一个问题：
“在这一层，问题是否真实存在？”
二、第一层：应用层（L7）
“服务真的不可用吗？”
1️⃣ curl —— 应用层排障的起点
curl -v https://example.com
重点不是看返回内容，而是看：
DNS 是否成功
TCP / TLS 是否建立
HTTP 状态码
📌 curl 失败 ≠ 网络失败很多问题在这一层就已经暴露了（证书、SNI、代理）。
2️⃣ DNS：最容易被忽略的“隐形层”
dig example.comdig +trace example.com
常见坑：
内外网 DNS 不一致
权威 DNS 超时
Pod / Node DNS 配置不同
👉 DNS 问题 100% 会被误判成网络问题
3️⃣ TLS：端口通，但就是连不上
openssl s_client -connect host:443 -servername host
你能直接看到：
三、第二层：传输层（L4）
“TCP / UDP 是否真的建立成功？”
4️⃣ ss —— 比 netstat 更接近事实
重点观察：
SYN-RECV 是否堆积（半连接）
TIME-WAIT 是否异常
orphaned socket
📌 大量连接失败，往往不是网络断，而是队列满了
5️⃣nc —— 最直接的端口验证
一句话判断：
6️⃣ tcpdump —— 在 L4 才登场
你要回答的问题只有三个：
SYN 有没有发出去？
SYN-ACK 有没有回来？
是谁先放弃的？
👉 tcpdump 是证据工具，不是搜索工具
四、第三层：网络层（L3）
“包到底走没走？走哪条路？”
7️⃣ 路由是所有问题的放大器
ip routeip route get 8.8.8.8
典型事故现场：
多网卡选错出口
容器网络和宿主路由冲突
policy routing 被忽略
8️⃣ ping & tracepath —— 不只是连通性
重点看：
RTT 抖动
MTU 是否被卡死
是否在某一跳开始异常
📌 能 ping 通，不代表服务一定能用
9️⃣ ARP / 邻居问题
如果你看到：
👉 问题已经在二层以下了。
五、第四层：链路层 / 物理层（L2 / L1）
“问题是不是一开始就存在？”
🔟 ethtool —— 网卡体检报告
ethtool eth0ethtool -S eth0
重点：
📌 很多“网络抖动”，其实是物理层在慢慢坏
1️⃣1️⃣ ip link —— 最真实的接口统计
如果这里已经在丢包：
上面的所有分析都可以推翻重来
六、最后一层：内核与系统资源
“网络没问题，是系统扛不住”
1️⃣2️⃣ 内核 TCP 行为
关注：
1️⃣3️⃣ 连接队列 & 参数
sysctl net.core.somaxconnsysctl net.ipv4.tcp_max_syn_backlog
📌 默认值几乎不适合任何高并发服务
1️⃣4️⃣ conntrack —— 云原生时代的雷区
典型表现：
七、一套可以“照着走”的排障路径
curl / dig / openssl ↓ss / nc ↓tcpdump ↓ip route / ping / tracepath ↓ip link / ethtool ↓sysctl / conntrack
永远从“用户感知的失败”开始，一路向下找事实。
八、结语
Linux 网络诊断，本质是一种工程思维训练。
真正的高手：
当你能自顶向下，一层层把问题压扁，网络故障就只是一道流程题。
SSH 常用命令行参数详解：从能连上到玩出花
Ralph Loop不是产品，而是一种软件工程方法论
