Linux网络排错命令：ping、traceroute、mtr、dig、nslookup

网络一出问题，很多人第一反应是「重启网卡」，但真正的高手会像医生一样分层诊断 ：先看通不通，再看路怎么走、慢在哪跳，最后查域名解析和端口是否可达。这一篇把网络排错的五把基础锤子讲清楚：ping 测连通、traceroute/mtr 看路径、dig/nslookup 查 DNS、telnet/nc 探端口、curl 打 HTTP，配合分层思路，让每次排障都有章法。

一、网络排错的分层思路

排网络问题要自下而上，一层层确认，别跳步：

层	问题	工具
链路/连通	通不通？	`ping`
路径	经过哪些跳？哪里丢包？	`traceroute` / `mtr`
名称解析	域名能解析吗？	`dig` / `nslookup`
端口	端口开吗？能连吗？	`telnet` / `nc`
应用	HTTP 返回什么？	`curl`

核心原则：IP 能通不代表域名能通，域名能通不代表端口能通，端口能通不代表应用正常。 逐层验证。

二、ping：连通性第一锤

ping 用 ICMP 协议发回显请求，测「能不能到达 + 往返时间 + 丢包率」。

语法格式

复制代码

ping [选项] 目标

常用参数

参数	说明
`-c N`	发 N 个包后停止
`-i 秒`	发送间隔（普通用户最小 0.2）
`-W 秒`	单次等待超时
`-s 字节`	指定包大小（测 MTU 用）
`-I 接口/IP`	指定源接口或源 IP
`-4` / `-6`	强制 IPv4 / IPv6
`-f`	洪水 ping（需 root，慎用）

示例与预期输出

复制代码

ping -c 4 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=11.8 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=12.0 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=12.5 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.800/12.150/12.500/0.257 ms

关键信息：time（往返延迟）、packet loss（丢包率）、rtt（最小/平均/最大/偏差）。

判断口诀：

通、time 小 → 链路良好
通、time 大 → 链路拥堵或距离远
不通（100% loss）→ 网络断、防火墙拦、或目标禁 ICMP
时通时不通（有丢包）→ 链路质量差

⚠️ ping 不通不代表网络不通

很多服务器/防火墙默认禁 ICMP ，所以 ping 不通可能只是对方不回应 ping，端口照样能用。别看到 ping 不通就判定网络故障 ，接着用 telnet/nc 测端口才是正解。

三、traceroute / mtr：看路径和瓶颈

ping 只告诉你「通不通」，traceroute 告诉你「经过哪些路由器，哪一跳开始变慢或丢包」。

traceroute

复制代码

traceroute www.example.com      # 默认 UDP
traceroute -I www.example.com   # 用 ICMP（有些网络更容易通过）
traceroute -T -p 443 www.example.com   # 用 TCP，绕开 ICMP 限制

预期输出：

复制代码

traceroute to www.example.com (93.184.216.34), 30 hops max
 1  192.168.1.1      1.203 ms   1.100 ms   1.050 ms
 2  10.0.0.1         3.400 ms   3.200 ms   3.100 ms
 3  * * *
 4  202.96.x.x      20.500 ms  20.300 ms  20.100 ms
 ...

每行是一跳（一个路由器）及其三次探测的 RTT
* * * 表示该跳不回应（可能禁 ICMP），不代表断
从某一跳开始 RTT 飙升或大量 *，是瓶颈或丢包点

mtr：traceroute + ping 的合体（更推荐）

mtr 持续采样，实时展示每一跳的丢包率和延迟，比 traceroute 信息量大得多。

复制代码

mtr www.example.com          # 交互界面
mtr -r -c 10 www.example.com # 报告模式，采 10 次后输出

HOST: web01             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1       0.0%    10    1.2   1.1   1.0   1.3   0.1
  2.|-- 10.0.0.1          0.0%    10    3.4   3.3   3.1   3.6   0.2
  3.|-- ???              100.0%    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 202.96.x.x        0.0%    10   20.5  20.4  20.1  20.8   0.2

读 mtr 的技巧：

中间某跳 Loss% 100% 但后续跳正常 → 只是该路由器不回应，不是丢包。
某一跳开始 Loss% 持续上升影响后续 → 真正的丢包点。
最后一跳的 Loss% 才是端到端的真实丢包率。

四、dig：DNS 查询的瑞士军刀

dig（Domain Information Groper）是最好用的 DNS 查询工具，输出详细、支持指定 DNS 服务器。

语法格式

复制代码

dig [@DNS服务器] 域名 [查询类型]

常用参数

参数	说明
`+short`	只输出结果，简洁
`+trace`	从根开始追踪解析过程
`@8.8.8.8`	指定用哪个 DNS 服务器
`-t A`	查 A 记录（默认）
`-t MX` / `-t NS` / `-t CNAME`	查其他记录类型
`-x IP`	反向解析（IP → 域名）

示例与预期输出

复制代码

dig www.example.com +short

93.184.216.34

完整输出（排查 DNS 问题必看）：

复制代码

dig www.baidu.com

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.baidu.com.         IN  A

;; ANSWER SECTION:
www.baidu.com.  300  IN  A  110.242.68.66

;; Query time: 12 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)

重点关注：

status ：NOERROR 正常，NXDOMAIN 域名不存在，SERVFAIL 服务器故障
ANSWER SECTION ：解析结果和 TTL（还差多少秒过期）
SERVER：实际用的哪个 DNS 服务器
Query time：查询耗时，很大说明 DNS 慢

指定 DNS 服务器对比（判断是 DNS 服务器的问题还是域名的问题）：

复制代码

dig @223.5.5.5 www.example.com +short
dig @8.8.8.8 www.example.com +short

追踪完整解析链：

复制代码

dig +trace www.example.com

会显示从根域名开始，一层层问 .com、example.com 的过程，适合排查 DNS 层级问题。

五、nslookup / host：老将继续用

nslookup 是老牌的交互式 DNS 工具，简单直观，很多系统默认装，dig 没有时可用。

复制代码

nslookup www.example.com

Server:         223.5.5.5
Address:        223.5.5.5#53

Non-authoritative answer:
Name:   www.example.com
Address: 93.184.216.34

host 更简洁：

复制代码

host www.example.com

www.example.com has address 93.184.216.34

三者选择 ：dig 信息最全（推荐）、nslookup 交互式方便、host 最简洁。

六、telnet / nc：测端口连通性

知道 IP 也解析了域名，还要确认端口能不能连。这是「能通却不服务」问题的关键一步。

telnet

复制代码

telnet 192.168.1.100 3306

连上会显示 Connected to ...，说明端口开放
报 Connection refused，说明端口没监听或被拒
卡住无响应，可能是防火墙 DROP 或网络不通

nc（netcat）：更强大

复制代码

# 测端口
nc -zv 192.168.1.100 3306

# 测一段端口
nc -zv 192.168.1.100 20-80

# 带超时
nc -zv -w 3 192.168.1.100 3306

Connection to 192.168.1.100 3306 port [tcp/mysql] succeeded!

-z 只扫描不发送数据，-v 显示详情，-w 设超时。

⚠️ 端口测试的关键区分

现象	含义
`succeeded` / `Connected`	端口开放且可连
`Connection refused`	端口没监听（服务没起）或主动拒绝
超时无响应	防火墙 DROP 或网络不通

「refused」和「超时」是两个完全不同的问题：refused 说明包到达了、但没人监听；超时说明包没到或被丢弃（防火墙）。

七、curl：应用层测试

端口通了，还要测应用是否正常响应。curl 是最常用的 HTTP 客户端。

复制代码

# 基础请求
curl http://192.168.1.100/

# 只看响应头
curl -I http://example.com/

# 显示详细过程（含 DNS、连接、TLS 各阶段耗时）
curl -v http://example.com/

# 显示连接各阶段耗时
curl -w "dns:%{time_namelookup} connect:%{time_connect} total:%{time_total}\n" -o /dev/null -s http://example.com/

dns:0.012 connect:0.035 total:0.156

-w 格式化输出能精准定位「慢在哪一段」：DNS 慢、连接慢、还是总耗时慢。

八、⚠️ 常见错误

ping 不通就认定网络断 。对方可能禁 ICMP，用 telnet/nc 测端口才准。
把 traceroute 的 * * * 当断路。中间跳不回应 ICMP 很正常，要看后续跳和端到端丢包。
dig 的 TTL 看晕。TTL 是缓存还能存活的秒数，不是「解析失败次数」。归零后才会重新查询。
改 DNS 后不刷新缓存 。systemd-resolved 有缓存，改完 DNS 服务器要 resolvectl flush-caches。
telnet refused 与超时混淆。refused 是服务没起，超时是防火墙/网络，处理方向完全不同。
只在应用层测。HTTP 500 可能是后端问题，要一层层往下确认是网络还是应用。
忘了 IPv6 干扰 。有时 IPv4 正常、IPv6 不通，导致解析优先走 IPv6 而超时。用 -4 强制 IPv4 验证。

九、原理探究：ICMP、TTL 与 DNS 查询

ping 与 traceroute 都靠 ICMP

ping 发 ICMP Echo Request ，对方回 Echo Reply 。traceroute 的原理更巧妙，靠 TTL：

IP 头里有个 TTL（Time To Live） 字段，每经过一个路由器就减 1，减到 0 时路由器丢弃该包并回一个 ICMP 超时消息，告诉发送方「你的包死在我这了」。

traceroute 就利用这一点：

复制代码

第 1 个包 TTL=1 → 到第 1 跳路由器减到 0 → 回 ICMP 超时 → 得到第 1 跳地址
第 2 个包 TTL=2 → 到第 2 跳路由器减到 0 → 回 ICMP 超时 → 得到第 2 跳地址
第 3 个包 TTL=3 → ...
以此类推，直到到达目标

所以 traceroute 不是「一次走完全程」，而是靠一串递增 TTL 的包「钓」出每一跳的地址。

mtr 为什么更强

mtr 相当于「对每一跳都持续 ping」------它对整条路径反复采样，所以能统计出每个跳的丢包率和延迟分布 ，而 traceroute 每个跳只探测 3 次，样本太少，容易误判。

DNS 查询的两种方式

递归查询（recursive） ：客户端问本地 DNS「帮我查到最终答案」，本地 DNS 负责跑断腿。dig 默认发递归查询。
迭代查询（iterative） ：服务器问服务器，一路问下去。dig +trace 演示的就是迭代过程。

客户端 --递归--> 本地DNS --迭代--> 根 --迭代--> .com --迭代--> example.com --迭代--> www.example.com

理解这个过程，就能解释「为什么换个 DNS 服务器结果不同」（缓存不同、线路不同）和「为什么 DNS 慢会拖慢整个访问」（解析是访问的第一步）。

一个完整的排障演练

「打不开 https://api.example.com」怎么查：

复制代码

# 1. 域名能解析吗
dig api.example.com +short
# 2. 能到达吗
ping -c2 api.example.com
# 3. 路径和丢包
mtr -r -c 10 api.example.com
# 4. 443 端口通吗
nc -zv api.example.com 443
# 5. 应用正常吗
curl -v https://api.example.com/

五步下来，问题卡在哪一层一目了然。

十、排错命令速查表

目的	命令
连通性	`ping -c4 host`
路径追踪	`traceroute host` / `mtr host`
丢包/延迟定位	`mtr -r -c10 host`
DNS 解析	`dig host +short` / `dig @8.8.8.8 host`
解析链追踪	`dig +trace host`
反向解析	`dig -x 8.8.8.8`
端口测试	`nc -zv host port` / `telnet host port`
HTTP 测试	`curl -I url` / `curl -w ... -o /dev/null -s url`

记住排障主线：先 ping 看通不通 → 再 mtr 看路和丢包 → 再 dig 看解析 → 再 nc 看端口 → 最后 curl 看应用。一层层往下，绝大多数「网络问题」都能定位到具体环节，而不是无脑重启。