Clash能连上但打不开网页的三条排查线索

有一种故障最消耗耐心:客户端界面一切正常,节点列表满满当当,延迟测试也返回了数字,开关是绿的,可浏览器就是一直转圈,最后弹出连接超时。这时候大多数人的第一反应是换节点,换完还是不行就换机场——两个动作都白费,因为问题根本不在那里。

关键在于理解「已连接」这三个字到底证明了什么。它只说明客户端进程在运行、代理端口在监听、对某个节点的探测请求得到过回应。它不证明浏览器的请求交给了这个端口,不证明请求对应的域名被正确解析,也不证明分流规则把这个域名指向了节点而不是直连。中间任何一环断掉,现象都长成一模一样。

所以排查的第一原则是别碰节点。把注意力放在流量走向、域名解析、代理端口这三条线索上,每一条都能独立验证,顺序也不能乱。

先分清:是全部网站打不开,还是只有个别站点#

这一步不到十秒,却直接决定后面往哪查。随手打开三四个不同类型的站点——一个国内的、一个国外常用的、一个此刻打不开的。

「关掉代理之后国内网站也打不开」是一个特殊信号,它说明客户端退出时没有还原系统的代理设置,和节点毫无关系,后文有单独处理。

切到全局模式一试,能排除掉什么#

全局模式的作用是绕过所有分流规则,把流量无差别地丢给当前节点。这让它成为最有效的二分工具。

切过去之后重新访问那个打不开的网站:

• 能打开了——节点、端口、解析这三样全是通的,唯一的问题是规则模式下没有一条规则把该域名交给节点。线索到此结束,去看规则。
• 还是打不开——分流被排除了,问题在更底层,继续往解析和端口查。

切完记得切回规则模式。长期挂在全局模式上会把国内流量也绕出去,访问速度反而变慢,还可能触发部分网站的风控。

规则没覆盖的处理办法是在配置里补一条,或者换用规则集更完整的订阅。规则的写法与优先级属于配置层的内容,可以对照Clash 专题里的分流部分理解匹配顺序。

线索二:DNS 与 fake-ip 冲突长什么样#

域名解析是这三条线索里最不直观的一条。简单说,浏览器要先把域名换成 IP 才能发起连接,而 Clash 为了让规则匹配更准,通常会启用 fake-ip 模式——给域名分配一个假的内部 IP,等流量真正进来时再按域名做决策。

冲突出在系统或浏览器缓存了旧的解析结果。缓存里可能是上一次直连时拿到的真实 IP,也可能是上一次 fake-ip 分配的地址,两者都会让请求走错方向。典型表现是:某个网站昨天还好好的,今天怎么都打不开,而同一台机器上换个浏览器又正常。

两层缓存要分别清:

ipconfig /flushdns

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

浏览器那一层只关标签页没用,要完整退出进程再启动。两处都清完再测,结果才有参考价值。

还有一种情况值得注意:解析请求本身绕过了客户端,直接发给了运营商的 DNS。这时打开的很可能是被污染后的地址,表现为页面加载到一半卡住或者跳转到无关内容。判断方法是看客户端的连接日志里有没有对应的解析记录,一条都没有就说明流量压根没经过它。

线索三:系统代理端口是不是被改写了#

系统代理的原理是把客户端的本地端口写进操作系统的代理设置,遵守这项设置的程序才会走代理。问题在于这个设置是全局共享的——安全软件、公司管控策略、其他代理工具、甚至某些游戏平台都可能改写它。

改写之后的现象很典型:所有网站都打不开,包括国内的,因为系统把流量送去了一个根本没有程序监听的端口。

命令行验证最直接:

curl -x http://127.0.0.1:7897 -I https://www.example.com

把 7897 换成客户端里显示的混合端口。返回状态码说明端口本身工作正常,问题在系统设置那一层;连接被拒绝则说明端口对不上,或者客户端根本没在监听。

对应的修复动作有两个方向:在客户端里关掉再打开一次系统代理开关,让它重写系统设置;或者去操作系统的代理设置页面,确认那里填的端口和客户端显示的一致。端口被别的软件长期占用时,直接在客户端里改一个不常用的端口号更省事。

浏览器插件和 IPv6 这两个隐藏变量#

浏览器自带的代理插件是最容易被忽略的干扰源。插件工作在浏览器内部,优先级高于系统代理,它可能把请求送去一个已经失效的规则,而系统层看起来一切正常。判断方法是换一个没装插件的浏览器测同一个网站,或者临时停用插件。

IPv6 的角色更隐蔽一些。当本地网络有 IPv6 而节点只支持 IPv4 时,系统可能优先尝试 IPv6 通道,请求既没走代理也到不了目的地,表现就是长时间转圈后超时。同一个网站在手机热点下正常、在家里宽带下不正常,常常是这个原因。可以在客户端里关掉 IPv6 相关选项做一次对照测试。

这两项都属于「对照实验」型的排查:换一个环境、关一个开关,看现象是否消失。不要同时改两处,否则改好了也不知道是哪一处起的作用。

三条线索都排完仍然无解,该收集什么#

到这一步就该停止试错了,继续乱调只会引入新变量。求助时把下面四项一次说清楚,别人才有可能给出有用的判断:

1. 全局模式下是否正常——这一项直接把问题范围砍掉一半。
2. 具体是哪个域名打不开——「所有网站」和「某个网站」是两类完全不同的故障。
3. 客户端连接日志里这条请求命中了哪条规则、走了哪个出口——这是唯一能证明流量走向的证据。
4. 系统代理关闭状态下能否正常访问国内网站——用来排除本机网络本身的问题。

如果这四项都正常,而故障依旧,那大概率已经超出客户端范围了,可能是线路当前不可用或者被目标站点针对性拦截。换个节点或换个出口地区试一次,能确认的话就属于服务层面的问题,而不是配置问题。同类现象的其他排查路径整理在故障排查栏目。

小结#

「已连接却打不开网页」是一个中间状态,它证明客户端在跑,但不证明流量走对了路。排查顺序固定为:先用全局模式做二分判断分流是否失效,再清两层 DNS 缓存排除解析冲突,最后用命令行验证代理端口是否被改写。浏览器插件和 IPv6 是两个高频隐藏变量,用对照实验单独确认。三条线索都通过还是不行,就收集好四项证据再求助,不要靠反复换节点碰运气。