Linux 网络诊断工具实战：ping、curl、tcpdump、mtr、dig 用法详解

网络诊断工具实战：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：路径与丢包

ping -c3 192.168.1.1 # 基本连通：3 个包，看丢包率与 RTT
ping -c3 -i 0.2 8.8.8.8 # -i 间隔 0.2 秒，快速探测

ping 的局限：只知道两端，看不见中间。中间哪一跳丢包？上 mtr：

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 排错三板斧

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 # 发 POST

3.2 🌟 -w 拆解耗时（"慢"的定位神器）

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 常见状态码速判

四、dig：DNS 专项

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 过滤语法三板斧

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 直接复现上面三个现场。

六、综合实战：一次"接口偶发超时"的完整排查

# ① 拆解耗时
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 三种抓包形态分别指向什么问题。

七、🚨 避坑清单

八、一句话总结

"慢"必须拆开看：-w 分段计时，mtr 分层定位，tcpdump 对抗狡辩——工具的顺序就是排查的顺序。

💬 互动

你抓过最有成就感的包是什么？靠 Wireshark 定位过什么奇葩故障？评论区晒案例。

下一篇预告：《S2-03 防火墙从入门到会配：firewalld、iptables 与云安全组》——“安全组放行了还是不通”？端口放行的规则链比你想的长。