事件背景

校园网环境下遇到一个看起来很奇怪、但实际很典型的网络问题：能连上网，不代表能正常访问互联网。
我把整个过程按时间拆成了三个阶段，下面从头到尾梳理现象和原因。

阶段一：连接校园网成功，但无法正常上网

现象

  • 设备能正常连接校园网
  • 系统自动分配的 DNS 是 114.114.114.114
  • 浏览器和应用无法正常访问网站

原因分析

这一阶段最可能的问题是 DNS 可达性或 DNS 结果不可用，而不是“网络完全断开”。

可能的具体原因：

  1. 校园网对外部公共 DNS（如 114.114.114.114）做了限制，导致查询超时或响应异常。
  2. 网络认证/准入策略未完全放行时，DNS 请求虽然被配置成功，但实际不稳定。
  3. 返回了错误或被污染的解析结果，导致后续 TCP/HTTPS 连接都失败。

核心理解：
这时设备“拿到了 IP 和 DNS 配置”，但域名解析链路不通，所以表现为“像连上了网，但就是打不开网页”。

阶段二：打开 Clash 后恢复上网

现象

  • 打开 Clash 后，访问恢复正常

原因分析

Clash 介入后，通常会接管流量路径（包括 DNS 解析路径），所以即使系统 DNS 存在问题，也可能绕过它：

  1. DNS 请求改由 Clash 的 DNS 模块或上游代理完成，不再依赖系统里那个异常的 114.114.114.114。
  2. 即使系统层 DNS 不稳定，代理通道仍可通过远端节点完成解析和访问。
  3. 因为代理链路可用，用户体感就是“开代理就好”。

核心理解：
Clash 并不是“修好了校园网”，而是绕过了本地 DNS/直连路径中的故障点。

阶段三：关闭 Clash，删除 114.114.114.114，系统重新分配 210.32.32.1 后恢复正常

现象

  • 关闭 Clash 后再次无法访问
  • 删除校园网分配的 114.114.114.114
  • 系统立刻重新分配 210.32.32.1
  • 之后无需 Clash 也可正常上网

原因分析

这一步基本验证了前面的判断：问题关键在 DNS。

210.32.32.1 很可能是校园网内部 DNS（或其推荐解析服务器），相较公共 DNS 更适配当前网络策略，因此：

  1. 在校园网内部可达性更高，DNS 查询稳定。
  2. 对校内认证、路由策略、本地缓存更友好。
  3. 能返回该网络环境下真正可用的解析结果。

核心理解：
不是“网络突然好了”，而是换成了当前网络可用、可信任的 DNS 服务器。

结论：真正的问题点

这次故障的主因大概率是：

  • 校园网环境下，114.114.114.114 在当时不可用或不适配
  • 导致直连场景下 DNS 解析失败
  • Clash 因为绕过本地 DNS，所以临时恢复
  • 改用 210.32.32.1 后，直连路径恢复正常

这次学到的排障方法

以后遇到“能连 Wi-Fi 但打不开网页”的问题，可以按下面顺序排查：

1) 看当前 DNS 是否正确

1
2
scutil --dns | rg "nameserver\[[0-9]+\]"   # 作用：查看系统当前实际生效的 DNS
networksetup -getdnsservers Wi-Fi          # 作用：查看 Wi-Fi 网卡配置的 DNS
  • 成功信号：能看到合理 DNS（如校园网推荐 DNS），且两者结果基本一致。
  • 失败信号：没有 DNS、DNS 异常，或系统生效 DNS 与网卡配置明显不一致。

2) 看基础网络通不通（先排除断网）

1
ping -c 4 198.18.0.84   # 作用：用 IP 直测百度网址链路连通性，不依赖 DNS
  • 成功信号：有回复且丢包低。
  • 失败信号：持续超时或 100% 丢包，说明基础网络就有问题。

3) 对比 DNS 能不能解析

1
2
dig @114.114.114.114 www.baidu.com +time=2 +tries=1   # 作用：强制用 114 做 DNS 查询
dig @210.32.32.1 www.baidu.com +time=2 +tries=1       # 作用：强制用校园网 DNS 查询做对比
  • 成功信号：有 status: NOERROR 且有 ANSWER SECTION。
  • 失败信号：超时、无法连接 DNS，或没有有效回答。

4) 验证“能解析”是否等于“能访问”

1
2
nslookup www.baidu.com                      # 作用：用系统默认 DNS 查域名
curl -I --max-time 5 https://www.baidu.com # 作用：验证实际 HTTPS 访问是否可达
  • 成功信号：nslookup 返回 IP，curl 返回 HTTP 状态码（如 200/302）。
  • 失败信号：Could not resolve host、超时，或无有效 HTTP 响应。

给自己的实践建议

  • 在校园网、酒店网、公司网等受策略管控的环境，优先使用网络侧推荐 DNS。
  • 代理可作为“绕过验证手段”，但不要把它当作根因修复。
  • 记录“现象-操作-结果”的时间线，能大幅提高排障效率。

这次看似是一个小问题，本质上是一次很好的网络基础复盘：
很多“上不了网”的问题，不在链路本身，而在 DNS 这一层。