网络排查

源自我与 Claude 的对话

网络排查的核心思想

遇到网络问题，永远先问自己这一句话：

" 是根本不通，还是走错路了？"

所有网络问题本质上只有两类：

• 连通性问题：数据包发不出去，或者到不了目标
• 配置问题：数据包走了错误的路径，或者用了错误的信息（比如 DNS）

排查框架：从下往上，逐层排除

网络可以分成几层，排查时从最底层开始，确认每一层正常后再往上。

第四层：应用层   curl google.com 能不能通？
第三层：DNS      域名能解析成 IP 吗？
第二层：路由     数据包知道往哪走吗？
第一层：连通性   IP 直连能不能通？

从第一层开始排查，确认没问题再往上。 上层依赖下层，下层坏了上层必然坏。

每一层对应的命令和问题

第一层：连通性 —— " 能不能到达目标？"

# 测试能否到达某个 IP（发 ICMP 包）
ping 8.8.8.8

# 如果 ping 被禁，用 curl 直接访问 IP
curl https://1.1.1.1

看什么： 能通说明网卡、路由、物理链路都没问题。不通说明更底层有问题。

第二层：路由 —— " 数据包从哪个门出去？"

# 查看完整路由表
ip route

# 查询去往某个 IP 具体走哪条路
ip route get 8.8.8.8

# 查看所有网卡的 IP 地址
ip addr

看什么： 确认默认路由存在，确认目标 IP 会走你期望的网卡。

ip route get 特别好用，直接告诉你一个具体 IP 会走哪条路：

ip route get 8.8.8.8
# 输出：8.8.8.8 via 198.18.0.2 dev eth5  ← 走 eth5 出去

第三层：DNS —— " 域名能翻译成 IP 吗？"

# 最快的测试：用指定 DNS 解析域名
nslookup google.com 8.8.8.8

# 查看系统当前用哪个 DNS，各接口状态
resolvectl status

# 查看 resolv.conf 配置
cat /etc/resolv.conf

看什么： nslookup google.com 8.8.8.8 能成功但 curl google.com 失败，说明 DNS 配置有问题，不是连通性问题。

第四层：应用 —— " 整个链路通了吗？"

# 最终测试
curl google.com

# 看详细过程（连接哪个 IP、TLS 握手等）
curl -v google.com

实战思路：遇到问题怎么想

拿这次你的问题举例，演示一下思考过程：

现象： curl google.com 失败，报 " 无法解析域名 "

第一步，看报错信息定位层次。 " 无法解析域名 " 明确告诉你是 DNS 问题，直接跳到第三层。

第二步，区分 "DNS 坏了 " 还是 " 连通性顺带坏了 "。

bash

curl 1.1.1.1   # 直接用 IP 访问，绕过 DNS

能通 → 连通性没问题，问题就在 DNS 这一层。

第三步，DNS 问题细分：是 "DNS 服务器不可达 " 还是 " 没有配置 DNS 服务器 "？

bash

nslookup google.com 8.8.8.8   # 手动指定 DNS 试试

能解析 → DNS 服务器本身可达，是系统的 DNS 配置没指向它。

第四步，查系统 DNS 配置找根因。

bash

resolvectl status   # 发现所有接口 Scopes 都是 none

找到了：systemd-resolved 没有上游 DNS，修复即可。

一张速查卡

最重要的一个习惯

每次排查，先用最简单的命令缩小范围，不要上来就乱试。

报错信息本身往往已经告诉你在哪一层出了问题：

• Could not resolve host → DNS 层
• Connection refused → 应用层（服务没开）
• Connection timed out → 路由或连通性层
• Network unreachable → 路由层（没有路由规则）

养成 " 看报错 → 定位层次 → 针对性排查 " 的习惯，大多数网络问题都能很快找到根因。