Clash 连接成功却无法上网:按顺序排查的九项检查清单

为什么"连接成功"不等于"能上网"

客户端界面里的绿色圆点或"已连接"提示,通常只代表 Clash 与代理服务器之间完成了一次握手测试,或者当前选中的节点延迟测试有返回值。这个状态与"浏览器能否正常加载网页"是两件不同的事——中间还隔着系统代理是否生效、DNS 解析是否正确、规则是否把流量导向了错误的出口等多个环节。任何一个环节出问题,都会呈现出"连接成功但无法上网"的表现,而这些环节的报错信息往往不会直接显示在主界面上,需要逐项排查才能定位。

下面九个检查点按照"先确认本机设置,再验证节点本身,最后排查规则与远端"的顺序排列,建议按顺序走一遍,而不是跳着试——很多时候问题出在第一步,却被误认为是节点失效。

检查点一至三:先看本机与客户端设置

1. 系统代理是否真的开启

这是最容易被忽略的一步。部分客户端在切换配置文件或重启后,系统代理开关会被重置为关闭状态,但节点连接状态依然显示正常,造成"看起来在连着,其实流量根本没走代理"的假象。

• 验证方法:打开系统的网络设置面板,查看代理地址是否为 127.0.0.1 加对应端口(通常是 7890 左右),而不是空白或系统默认设置。
• 修复动作:在客户端主界面手动打开"系统代理"开关,再刷新一次网络设置面板确认写入成功。

2. 代理模式是否选错

Clash 通常提供三种代理模式:规则模式(Rule)、全局模式(Global)、直连模式(Direct)。如果模式被误设为直连,所有流量都会绕过代理直接发出,节点状态可以显示正常,但实际不会有任何流量经过代理服务器。

• 验证方法:查看客户端设置区的模式选择,确认当前选中项不是"直连"。如果日常使用规则模式却发现无法访问的站点异常多,也可临时切到全局模式做对比测试。
• 修复动作:切换回规则模式或全局模式,观察问题是否随即消失。

3. 局域网连接与端口冲突

如果通过路由器或其他设备转发流量到运行 Clash 的主机,需要额外打开"允许局域网连接"选项;同时确认代理端口没有被其他正在运行的程序占用——例如同时开着另一款代理工具,双方抢占同一端口会导致代理请求被静默丢弃。

• 验证方法:检查客户端设置中"允许局域网连接"开关状态;用命令行工具查看端口占用情况。
• 修复动作:关闭冲突程序或修改 Clash 监听端口,重启客户端使配置生效。

检查点四至六:验证节点本身是否可用

4. 节点延迟测试结果

客户端里显示的延迟数值(ms)通常是对节点服务器做的一次连通性测试,数值正常说明服务器在线且网络可达;如果显示超时或极高延迟,说明节点本身有问题,与本地设置无关。

• 验证方法:在代理组列表里手动触发一次延迟测速,重点关注当前选中的那个节点是否显示超时(通常标红或显示 timeout)。
• 修复动作:如果当前节点超时,切换到延迟正常的其他节点;如果订阅下所有节点全部超时,问题可能出在订阅本身或本机网络环境,需回到检查点一二重新确认。

5. 代理组的自动选择逻辑

很多订阅配置里的"自动选择"代理组,会基于延迟或存活状态自动切换实际使用的节点。如果这个自动选择组当前指向的落地节点恰好失效,即便组内还有其他健康节点,当前会话也可能因为切换延迟而短暂无法上网。

• 验证方法:展开自动选择组,查看当前实际生效的子节点是否延迟异常。
• 修复动作:手动强制切换到一个已验证可用的具体节点,而不是依赖自动选择组,排除自动切换逻辑带来的干扰。

6. 节点协议与服务器端配置是否匹配

如果是手动添加或修改过的节点(而非直接使用订阅生成的配置),协议类型、加密方式、传输层设置等参数如果与服务器端不一致,会出现"能连接但无法建立有效会话"的情况,表现同样是延迟正常但打不开网页。

• 验证方法:核对节点参数与服务器提供方给出的原始配置是否完全一致,特别注意传输协议和加密方式两项。
• 修复动作:重新从订阅链接生成配置,避免手动填写导致的参数错漏。

检查点七至九:DNS 与规则层面的排查

7. DNS 解析是否被污染

部分网络环境会对 DNS 查询做劫持或篡改,即便代理本身工作正常,如果域名解析阶段已经被返回了错误的 IP 地址,后续请求依然会失败或被导向错误的服务器。这种情况下代理测速可能完全正常,但网页始终无法打开。

• 验证方法:对比在开启代理和关闭代理两种状态下,同一个域名解析出的 IP 地址是否不同;也可以直接查看客户端日志中的 DNS 查询记录。
• 修复动作:在配置文件中启用 Clash 自带的 DNS 模块,将域名解析交由 Clash 处理而不是走系统默认 DNS,必要时开启 fake-ip 模式,从根源上避免解析结果被本地网络环境篡改。

8. 规则是否把流量错误地判定为 DIRECT

规则模式下,配置文件里的规则集会逐条匹配请求的域名或 IP,一旦命中某条 DIRECT 规则,流量就会直连而不经过代理。如果规则集版本较旧或规则顺序有误,原本应该走代理的域名可能被提前匹配到了直连规则,尤其是使用了自定义规则或多个规则集叠加的配置。

• 验证方法:查看客户端的连接日志或规则匹配记录,确认目标域名实际命中了哪一条规则、走的是哪个出口策略组。
• 修复动作:调整规则顺序,把更精确的代理规则放在宽泛的直连规则之前,或者更新到规则集的最新版本;临时验证时也可以切到全局模式排除规则干扰。

9. 出站策略组指向的节点组是否为空或已全部失效

有些配置会为不同流量类型(如流媒体、社交应用、国内直连)设置独立的策略组,策略组内部再引用具体节点。如果某个策略组因为筛选条件过严导致组内没有可用节点,匹配到该策略组的流量会直接失败,即便主用的默认代理组一切正常。

• 验证方法:逐个检查配置文件中定义的策略组,确认每个组内至少包含一个当前可用的节点。
• 修复动作:补充策略组的节点来源,或将空策略组临时指向主用代理组,避免特定类型的流量无处可去。

把九项检查串成一条排查路径

实际操作时不需要死板地按序号一条条走完再下结论,更高效的方式是先做两次快速判断缩小范围:第一次判断"是不是本地设置问题"——临时切换到全局模式,如果问题消失,说明大概率是规则或 DNS 层面的问题(检查点七到九);如果切换后依然无法上网,再重点排查系统代理开关、端口冲突和节点本身状态(检查点一到六)。

如果九项检查完都正常,但问题依然存在,建议保留客户端日志截图,重新导入一份订阅生成全新配置文件做对比测试——有时候问题出在本地长期修改累积的配置文件本身,一份干净的配置往往比继续深挖旧配置更省时间。

# 快速验证代理是否生效的命令行方法(Windows / macOS 均适用类似语法)
curl -x http://127.0.0.1:7890 https://www.google.com -I

# 如果返回 HTTP 状态码而非超时或连接拒绝,说明代理链路本身是通的
# 此时问题大概率出在 DNS 解析或规则匹配层面