“网站打不开”这句话背后可能是完全不同的问题：网络本身断了、中间某一跳路由出故障、域名解析错了，或者目标服务压根没在监听。不分层排查，只会对着一个打不开的页面反复刷新，猜半天猜不出所以然。

这是 Linux 命令系列的一篇，承接 Linux 常见命令与工具地图；跟之前写的 Linux 服务器问题排查 是互补关系——那篇讲的是端口、进程、日志（ss、lsof），这篇补上”网络本身通不通、DNS 解析对不对”这一层。

ping：先确认最基本的连通性

ping 基于 ICMP 协议，向目标主机发包并等待回应，用来测试连通性和延迟：

1
2
3
4
5
6
7
8
ping -c 3 baidu.com
#     -c 3：只发 3 个探测包就停止，不加这个参数会一直发，要手动 Ctrl-C 停止

64 bytes from 124.237.177.164: icmp_seq=0 ttl=54 time=124.8 ms
64 bytes from 124.237.177.164: icmp_seq=1 ttl=54 time=125.6 ms
64 bytes from 124.237.177.164: icmp_seq=2 ttl=54 time=127.1 ms
#     time：这一个包的往返延迟，数值越大网络越慢
#     ttl：包剩余的存活跳数，能大致反映经过了多少层网络设备（不用深究具体数值）

有个陷阱必须提前知道：ping 不通不等于网络真的不通。很多服务器和防火墙会主动屏蔽 ICMP 协议（出于安全考虑，避免被用来扫描存活主机），这种情况下 ping 完全无响应，但目标服务本身其实是正常的、能正常访问。遇到 ping 不通，不能直接下结论”网络挂了”，还得结合后面的手段继续排查。

traceroute：定位问题出在哪一跳

如果 ping 确实不通，下一步是 traceroute——它能显示数据包从本机到目标主机，中间经过的每一跳路由，帮你定位问题出在链路上的哪一环：

1
2
3
4
5
6
7
8
9
10
traceroute baidu.com

 1  192.168.1.1 (192.168.1.1)  2.336 ms  2.079 ms  2.250 ms
 2  10.169.144.154 (10.169.144.154)  31.583 ms
    10.169.144.158 (10.169.144.158)  13.839 ms
    10.169.144.186 (10.169.144.186)  7.618 ms
 3  10.185.174.254 (10.185.174.254)  10.458 ms  6.176 ms  6.550 ms
#     每一行是一跳，默认每跳发 3 个探测包（所以后面有 3 个时间值）
#     第 2 跳三次探测返回了不同的地址，说明这一跳背后是多条负载均衡的路径，属正常现象
#     某一跳如果显示 * * *，说明这一跳没有响应——可能是这个节点屏蔽了探测包，也可能是真的断在这里

traceroute 的原理并不复杂：它给数据包设置一个从 1 开始递增的 TTL（存活跳数），TTL 为 1 的包到第一跳路由器就会被丢弃，路由器同时会回一个”TTL 耗尽”的 ICMP 消息，traceroute 借此拿到第一跳的地址；接着发 TTL 为 2 的包获取第二跳，以此类推，直到包真正到达目标主机为止。

实战判断很直接：从某一跳开始持续超时或丢包，问题大概率就出在那一跳之后的链路上——如果那一跳是本地路由器，问题在本地网络；如果是运营商中间节点，问题可能不在你这边，得等或者换网络；如果一直跑到最后几跳才出问题，大概率是目标网络那边的事。

dig / nslookup：DNS 解析诊断

ping 能通、traceroute 也能跑到目标，网站却还是打不开？这时候该查的是域名解析对不对——域名解析错了，访问的可能压根不是你以为的那台服务器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
dig baidu.com

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

;; ANSWER SECTION:
baidu.com.		573	IN	A	124.237.177.164
baidu.com.		573	IN	A	111.63.65.103

;; Query time: 12 msec
;; SERVER: 100.100.100.100#53(100.100.100.100)
#     QUESTION SECTION：查询了什么，这里是查 baidu.com 的 A 记录（域名对应的 IPv4 地址）
#     ANSWER SECTION：解析结果，一个域名可能对应多个 IP（负载均衡的常见做法）
#     Query time：这次查询耗时多久
#     SERVER：这次查询实际使用的是哪个 DNS 服务器——如果解析结果不对，先看看是不是用错了 DNS 服务器

nslookup 也能查 DNS，输出比 dig 简洁很多：

1
2
3
4
5
6
7
8
9
10
nslookup baidu.com

Server:		100.100.100.100
Address:	100.100.100.100#53

Non-authoritative answer:
Name:	baidu.com
Address: 124.237.177.164
#     一样能看出用的哪个 DNS 服务器（Server）、解析出来的地址（Address）
#     但信息量明显没有 dig 详细——没有 TTL、没有查询耗时

日常排查优先用 dig，信息更全；nslookup 胜在几乎所有系统都自带，个别精简系统没装 dig 时可以顶上用。

综合排查流程

网站/服务连不上，按这个顺序排查效率最高：

  1. ping 测网络层连通性——通了，跳到第 3 步；不通，先确认目标是不是屏蔽了 ICMP（比如用 curl 试一下能不能正常拿到响应），排除这个可能之后再进第 2 步
  2. traceroute 定位断在哪一跳——找到持续超时/丢包开始的那一跳，判断问题出在本地网络、中间运营商还是目标网络
  3. dig 确认域名解析对不对——解析出来的 IP 跟预期不符，问题在 DNS 这一层，检查用的 DNS 服务器或者域名解析配置
  4. 解析也对、网络也通，但服务还是连不上——大概率是端口没监听或者防火墙拦截，这部分排查见 Linux 服务器问题排查 里 ss、lsof 的用法

这四步覆盖了从”网络本身”到”DNS”再到”目标服务”的完整链路，按顺序排查比凭感觉瞎试快得多。

写到这里

ping、traceroute、dig 这三个工具分别对应网络排查的三个不同层次——连通性、路径、解析。记住这个分层，遇到”连不上”这类模糊的问题，就能很快把它拆解成一个个具体的、可以验证的假设，而不是对着报错信息干瞪眼。