Clash 已连接但打不开网页:系统代理、DNS 与规则的逐项排查清单

第一步:确认系统代理是否真的生效

客户端界面显示"已连接",只代表客户端与节点之间建立了代理隧道,并不代表系统的网络流量已经被引导进这条隧道。这是最容易被忽略的一层,也是排查的起点。

1. 打开系统的网络设置,查看代理配置项(Windows 在「设置 → 网络和 Internet → 代理」,macOS 在「系统设置 → 网络 → 高级 → 代理」),确认地址与端口是否指向客户端本地监听的端口(通常是 127.0.0.1:7890 一类的混合端口)。
2. 如果客户端开启了系统代理托管,该处应显示为客户端自动写入的状态,手动关闭再重新从客户端界面打开一次,观察设置是否被正确重写。
3. 若使用 TUN 模式(虚拟网卡接管全局流量),则不依赖系统代理设置,应改为检查网卡列表中是否出现客户端创建的虚拟网卡,并确认其状态为已启用。

如果系统代理字段是空的、端口不匹配,或者 TUN 模式下找不到对应虚拟网卡,说明流量根本没有进入客户端,后面所有排查都无意义,应先解决这一层。

第二步:节点连通性——代理开关之外的第一层

系统代理确认生效后,下一步要排除"隧道建立了,但节点本身连不出去"的情况。客户端里的"已连接"状态一般只反映握手成功,不代表该节点当前能正常转发流量。

• 在客户端的节点列表里对当前使用的节点执行一次延迟测试,如果显示超时或延迟异常飙高,先切换到同一订阅下的其他可用节点。
• 打开客户端自带的日志面板,查看是否有连接被拒绝、握手失败一类的记录,这类日志通常直接指向节点侧的问题而非本地配置问题。
• 如果所有节点都测试失败,大概率是订阅服务器异常或本地网络到出口协议的端口被拦截,这属于另一类问题,可参考站内关于节点全部超时的排查思路单独处理。

第三步:DNS 解析——域名能否被翻译成正确地址

代理链路通了、节点也可达,但网页仍然转圈,很大概率卡在域名解析这一步。DNS 请求如果没有走代理,或者被本地缓存了错误结果,浏览器会一直等待一个永远不会返回的连接。

1. 检查客户端配置中的 DNS 设置,确认启用了 fake-ip 或客户端内置的远程 DNS 转发,而不是直接沿用本机原有的 DNS 服务器。
2. 在系统命令行中对一个明确需要代理才能访问的域名执行解析测试,如果返回的是本地运营商 DNS 常见的错误地址或超时,说明解析请求没有被代理接管。
3. 如果客户端支持规则中单独配置 DNS 分流,检查是否存在把 DNS 查询误分配到"直连"策略组的规则,这种配置会导致代理链路正常但域名始终解析失败。
4. 清除本机的 DNS 缓存(Windows 下执行 ipconfig /flushdns,macOS 下执行 sudo killall -HUP mDNSResponder),再重新访问一次目标网站。

DNS 层的问题往往表现为"部分网站能开、部分不能开",且同一网站在不同时间表现不一致,如果观察到这类现象,应优先怀疑解析环节而不是节点本身。

第四步:规则命中——为什么明明连上了却还是打不开

Clash 与 Clash Meta(mihomo)内核都依赖规则(rules)决定每一条连接走哪个策略组。如果规则把目标网站错误分配到了"直连"或某个已失效的策略组,即便代理本身完全正常,该网站依然打不开。

• 打开客户端的连接面板或日志,查看目标网站的请求实际命中了哪一条规则、被分配到哪个策略组,而不是只看策略组本身是否显示"已连接"。
• 如果命中的策略组当前选中的落地节点本身不可用,即使规则匹配正确,连接依然会失败,需要单独检查该策略组内的节点状态。
• 自定义规则集较多、规则顺序混乱时,容易出现前面的宽泛规则先命中、后面精确规则不生效的情况,建议临时清空自定义规则、恢复订阅默认配置后重新测试,确认问题是否随之消失。
• 使用 TUN 模式时,还要检查是否存在把系统关键进程或浏览器进程排除在接管范围之外的规则,这类排除规则会让浏览器的请求完全绕开代理。

第五步:浏览器与本地缓存的最后一关

前四步都确认正常后,如果个别网页依然打不开,问题往往出在浏览器自身缓存的旧连接或旧证书信息上,而不是代理链路。

1. 换用浏览器的隐私/无痕窗口重新打开目标网站,排除浏览器扩展与本地缓存的干扰。
2. 如果浏览器提示证书错误或连接被重置,检查系统时间是否准确,时间偏差过大会导致 TLS 握手校验失败,表现上很像代理问题。
3. 部分浏览器会对同一域名保持长连接池,更换节点或策略组后旧连接未及时释放,重启浏览器进程通常能解决这类残留问题。

按以上五步从近到远逐一排除,大多数"已连接却打不开网页"的情况都能在十分钟内定位到具体断点。如果排查后确认是客户端版本本身的兼容性问题,可以考虑更新到最新版本重新测试。