Clash 已连接但网页打不开:从节点延迟到 DNS 的逐项排查清单

代理开关是绿的,浏览器却一直转圈,问题可能出在节点、规则、DNS 或系统代理任何一环。本文按从易到难的顺序列出九个检查点,每一步都给出判断依据和对应的修复动作。

先确认问题范围,再决定往哪查

"连接显示正常但打不开网页"这句话背后可能对应完全不同的故障。动手排查前先花一分钟缩小范围,能省掉后面大半时间。

• 只有部分网站打不开,其余正常:大概率是规则分流或单个节点的问题,不是整体网络故障。
• 所有网站(包括国内站)都打不开:先怀疑系统代理、TUN 网卡或本机网络本身,和 Clash 节点关系不大。
• 能打开网页但速度极慢、图片加载不全:多半是节点延迟或带宽问题,不是"连不上"。
• 刚换过订阅或改过配置后才出现:优先怀疑配置文件里的规则或 DNS 段,回滚一次配置能快速验证。

把现象归到上面某一类后,再对照下面的检查点顺序往下走,不需要逐条全过一遍。

检查点一到三:节点本身有没有问题

1. 当前选中的节点是否真的连得通

代理页显示的"已连接"通常只表示客户端和内核之间的控制连接正常,不代表选中的节点本身能访问外网。打开代理页,对当前策略组里的节点点一次延迟测试。如果显示超时或延迟数字是三位数以上还伴随打不开,先换一个延迟更低的节点验证,能打开就说明是节点侧问题,继续往下看第 2、3 点;换节点后仍打不开,跳到规则和 DNS 部分。

2. 策略组是否选中了失效节点

使用 select 或 url-test 策略组时,如果订阅商侧临时下线了某个节点,客户端不会主动提示,策略组会一直停留在那个失效条目上。进日志页看有没有大量 dial tcp: connection refused 或 i/o timeout,如果集中出现在同一个节点名上,手动切换到组内其他节点,或者把策略组类型改成 url-test 让内核自动跳过延迟异常的节点。

3. 订阅是否临近或已经到期

部分订阅在流量或时间到期后不会直接报错拉取失败,而是把所有节点都换成无法连通的占位节点,表现上就是"连接正常但打不开任何网站"。回订阅商后台确认到期时间和剩余流量是最快的排除方式,比反复重启客户端有效。

检查点四到六:规则有没有把流量导错方向

4. 该走代理的域名被规则判成了直连

Clash 按规则从上到下逐条匹配,一旦某条规则先命中就不再往下看。如果自定义规则里存在写得过宽的 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD,可能会把本该走代理的域名提前匹配成 DIRECT。日志页把日志级别调到 debug,打开打不开的网站,观察对应域名匹配到了哪条规则、落到了哪个策略组,直接定位问题规则。

5. 规则集(rule-provider)没有正常拉取

使用远程规则集时,如果拉取失败,内核通常会静默使用空规则集或上一次缓存,并不会中断代理连接。配置页检查规则集的更新时间,或在配置文件里给规则集加一条兜底:

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "https://example.com/reject.txt"
    path: ./ruleset/reject.txt
    interval: 86400
rules:
  - RULE-SET,reject,REJECT
  - MATCH,PROXY

末尾这条 MATCH,PROXY 保证任何没被规则集覆盖到的流量都有明确去向,避免落入未定义行为。

6. FINAL / MATCH 规则指向了错误策略组

配置文件末尾的兜底规则(旧版语法 FINAL,新版语法 MATCH)如果被误写成 DIRECT,所有没匹配到前面规则的域名都会直连,在没有落地节点的网络环境下就是大面积打不开。检查配置文件最后一行,确认它指向的是代理策略组而不是直连。

检查点七到九:DNS 与系统层的隐藏坑

7. DNS 解析被污染或返回了错误 IP

即使流量走了代理,如果域名解析这一步用的是本机运营商 DNS 而不是 Clash 接管的 DNS,解析结果依然可能被污染,拿到错误 IP 之后代理再快也打不开。检查配置文件里的 dns段是否启用,以及 enhanced-mode 是否设置为 fake-ip 或 redir-host:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853
  fallback-filter:
    geoip: true
    geoip-code: CN

fake-ip 模式下客户端会给域名分配一个虚拟 IP 再在内核层还原真实请求,能绕开大部分本地 DNS 污染,是目前默认推荐的模式。

8. 系统代理没有真正生效

有些应用(尤其是命令行工具、部分游戏客户端、老版本浏览器)不读取系统代理设置,即使 Clash 界面显示已连接,这些程序依然直连,自然打不开需要代理才能访问的站点。用浏览器换成明确支持系统代理的应用(如 Chrome、Edge)重新测试,能打开就说明是应用不吃系统代理,不是 Clash 故障,需要给这类应用单独配置代理地址或改用 TUN 模式接管。

9. TUN 模式和系统代理同时开启导致冲突

TUN 模式在网络层接管全部流量,如果同时又手动设置了系统代理,两套接管路径叠加,容易出现路由环路或流量被重复处理,表现为间歇性打不开、时好时坏。确认只保留一种接管方式:开启 TUN 就关掉系统代理,反之亦然,不要同时启用。

把九个检查点串成一次完整排查

如果不确定问题出在哪一层,按下面顺序走一遍通常能在五分钟内定位:

1. 换节点测试,排除节点本身失效(检查点 1~3)。
2. 把日志级别调到 debug,重现问题,看域名命中的规则(检查点 4~6)。
3. 确认 enhanced-mode 是否为 fake-ip,排查 DNS 污染(检查点 7)。
4. 换一个明确支持系统代理的应用做对照测试(检查点 8)。
5. 检查 TUN 与系统代理是否同时开启(检查点 9)。

走完这五步,九成以上的"连接正常但打不开"问题都能定位到具体环节。如果所有检查点都排除了问题依然存在,大概率是配置文件本身写法有误,建议先用一份来源明确、结构简单的示例配置替换测试,确认客户端本身没有异常后再逐项加回自定义规则。