网络诊断工具实战：ping、curl、tcpdump、mtr、dig 分层抓真凶
运维学习路线系列 · 阶段二 系统进阶 · 第 2 篇
适用环境：Ubuntu 24.04 LTS，普通用户（有 sudo）
阅读前提：《S2-01》（会看路由表和监听端口）
前言："网站有点慢"，慢在哪？
用户反馈"网站有点慢"，你只知道从用户浏览器到你的数据库中间隔着：DNS → TCP 握手 → TLS → 服务端处理 → 后端/数据库 → 回程。"慢"是一堆环节的总和，报错的人永远不知道卡在哪------工具的意义就是把总耗时拆开。
这篇按"分层诊断"的思路过五件武器：连通性（ping/mtr）、应用层（curl）、域名（dig）、底层抓包（tcpdump）。每个工具只教排错真正用的那几个参数。
一、诊断总原则：自上而下问，自下而上查
用户："打不开/慢"
① DNS 解析对不对、快不快？ dig
② 目的端口通不通？ nc / curl
③ 网络路径哪里卡？ ping + mtr
④ 应用层握手/请求哪里慢？ curl -w 拆解
⑤ 都说不清？抓包看真相。 tcpdump二、ping 与 mtr：路径与丢包
bash
ping -c3 192.168.1.1 # 基本连通：3 个包，看丢包率与 RTT
ping -c3 -i 0.2 8.8.8.8 # -i 间隔 0.2 秒，快速探测ping 的局限：只知道两端，看不见中间。中间哪一跳丢包？上 mtr：
bash
sudo apt install mtr-tiny -y
sudo mtr -rwbzc 100 192.168.1.11 Loss% Snt Last Avg
1. 192.168.1.1 0.0% 100 0.4 0.4 ← 网关
2. 10.10.0.1 0.0% 100 1.2 1.3 ← 运营商入口
3. ......
5. 202.x.x.x 40.0% 100 ...... ← 中间某跳丢包 40%！读表要点：
- 看目的地那一行的 Loss% 才是真实丢包（中间某跳 Loss 高但目的地 0%，可能只是路由器"限速回应 ICMP"，不是真丢）；
- 目的地也丢包 = 路径真的有问题，从丢包开始的那一跳往下就是责任段；
-b显示 IP+域名、-c 100发 100 个包再退出（默认实时刷屏）。
三、curl：应用层的瑞士军刀
3.1 排错三板斧
bash
curl -v http://192.168.1.11:8080/ # -v 全过程：DNS、连接、请求、响应头
curl -sI http://192.168.1.11/ | head -1 # 只看状态行
curl -k https://192.168.1.11/ # -k 忽略证书错误（自签证书排错）
curl -u user:pass http://.../ # 带认证
curl -d '{"a":1}' -H "Content-Type: application/json" http://.../api # 发 POST3.2 🌟 -w 拆解耗时（"慢"的定位神器）
bash
curl -o /dev/null -s -w "\
DNS: %{time_namelookup}s\n\
Connect: %{time_connect}s\n\
TLS: %{time_appconnect}s\n\
TTFB: %{time_starttransfer}s\n\
Total: %{time_total}s\n" https://www.example.com/DNS: 0.013s ← 域名解析耗时（>1s = DNS 有问题）
Connect: 0.041s ← TCP 握手完成（含 DNS；高 = 路径远/丢包重传）
TLS: 0.152s ← TLS 完成时间（高 = 证书链/OCSP 问题）
TTFB: 1.803s ← 首字节时间（高 = 服务端处理慢！）
Total: 1.860s结论读法 ：TTFB - TLS ≈ 服务端处理时间。上面例子 1.6s 都花在服务端------别再赖网络了，去查应用和数据库（阶段三 MySQL 慢查询、阶段二性能篇的活）。
3.3 常见状态码速判
| 码 | 含义 | 排错方向 |
|---|---|---|
| 200 | 成功 | --- |
| 301/302 | 跳转 | 看 Location 头，是否跳错 |
| 403 | 禁止 | 权限/防火墙 WAF/nginx allow 列表 |
| 404 | 路径不存在 | root 目录、location 配置 |
| 499 | 客户端等不及断开（nginx 特有） | 后端太慢，结合 504 一起看 |
| 502 | 后端没响应 | 后端挂了或起在 127.0.0.1（S2-01 的坑） |
| 504 | 后端超时 | 后端慢，往应用/数据库查 |
四、dig：DNS 专项
bash
dig www.example.com +short # 只要结果 IP
dig www.example.com # 完整应答：看 ANSWER 段 TTL 与 CNAME 链
dig @223.5.5.5 www.example.com # 指定 DNS 服务器查（对比排查"劫持/缓存"）
dig -x 8.8.8.8 +short # 反查 PTR
dig www.example.com +trace # 从根域开始逐级追（看委派哪里断了）高频用法：
- A 记录与预期不符 →
dig @8.8.8.8对比本地 DNS，再查权威 NS：dig NS example.com - 刚改了解析还不生效 → 看 ANSWER 里的 TTL，没过期前全国 DNS 还存着旧缓存；
- 本机 hosts 劫持检查：
getent hosts www.example.com（curl 用的其实是系统解析顺序：hosts 优先）。
五、tcpdump：不听任何一方狡辩
5.1 过滤语法三板斧
bash
sudo tcpdump -i eth0 -nn host 192.168.1.11 # 某主机全部
sudo tcpdump -i eth0 -nn port 3306 # 某端口
sudo tcpdump -i eth0 -nn host 192.168.1.11 and port 3306 # 组合（and/or/not）
sudo tcpdump -i eth0 -nn -c 100 -w /tmp/mysql.pcap port 3306 # 存文件（-c 限定包数）-nn 双保险：不做域名和端口反解，输出快且纯。
5.2 三个经典现场
现场 1：SYN 没有回 ------curl 超时，抓包只看到 Flags [S] 没有 [S.]：包根本没到对端或被防火墙丢，问题在网络/防火墙层（去 S2-03）。
10:00:01.123 IP 192.168.1.10.45678 > 192.168.1.11.3306: Flags [S]
10:00:04.456 IP 192.168.1.10.45678 > 192.168.1.11.3306: Flags [S] ← 重试，没人理现场 2：握手成功但立刻 RST ------[S.] 回了，随后 Flags [R]：对端到了但应用拒绝（端口没监听/被安全策略 reset）。
现场 3：重传风暴 ------tcpdump 里大量 [S] retransmission 或 [.] 后跟重复包：链路丢包，上 mtr 定位段落。
💡 抓包文件用 Wireshark 打开分析（scp 拖回本地），过滤栏写
tcp.port==3306直接复现上面三个现场。
六、综合实战：一次"接口偶发超时"的完整排查
bash
# ① 拆解耗时
curl -o /dev/null -s -w "DNS:%{time_namelookup} CONN:%{time_connect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n" https://api.example.com/
# 发现 CONN 从 0.04s 抖到 2s+，TTFB 正常 → 问题在网络层
# ② mtr 定位
sudo mtr -rwbzc 200 api.example.com
# 目的地 Loss 5%，丢包从第 4 跳开始 → 运营商链路问题，工单证据就是这张表
# ③ tcpdump 抓证据
sudo tcpdump -i eth0 -nn host api.example.com and port 443 -c 2000 -w /tmp/latency.pcap
# Wireshark 打开：tcp.analysis.retransmission 过滤，重传集中出现 → 坐实
# ④ 短期兜底 + 长期根治
# 兜底：客户端加重试/超时；检查 MTU（ip link | grep mtu，偶发大包丢=MTU 黑洞）
# 根治：换线路/加节点，监控侧加拨测（阶段四 Prometheus blackbox_exporter）验收标准 ：能用 curl -w 说出一次请求"慢在网络还是慢在服务端"；能用 mtr 表格指出丢包责任段；能解释 SYN / SYN+ACK / RST 三种抓包形态分别指向什么问题。
七、🚨 避坑清单
| # | 坑 | 误判 | 正确姿势 |
|---|---|---|---|
| 1 | ping 不通就断定网络断 | 对方可能禁 ICMP | 端口层 nc -zv IP 端口 复核 |
| 2 | mtr 只看中间某跳丢包 | 把 ICMP 限速当故障 | 以目的地行的 Loss 为准 |
| 3 | curl 慢就赖网络 | 服务端处理占大头（看 TTFB） | -w 拆解后再下结论 |
| 4 | 刚改 DNS 不生效就怀疑"改错了" | TTL 缓存未过期 | dig 看 TTL，等或降 TTL |
| 5 | tcpdump 不加 -nn | 输出又慢又有误导性反解 | 永远 -nn |
| 6 | 生产长时间裸抓包 | pcap 撑爆磁盘/性能 | -c 限包数 + -w 存文件 |
| 7 | 忽略本机 hosts | "dig 是对的 curl 却连错 IP" | getent hosts 按系统解析顺序复核 |
八、一句话总结
"慢"必须拆开看：-w 分段计时，mtr 分层定位，tcpdump 对抗狡辩------工具的顺序就是排查的顺序。
💬 互动
你抓过最有成就感的包是什么？靠 Wireshark 定位过什么奇葩故障？评论区晒案例。
下一篇预告：《S2-03 防火墙从入门到会配：firewalld、iptables 与云安全组》------"安全组放行了还是不通"？端口放行的规则链比你想的长。