Clash 已连接，为什么 ChatGPT 或 Claude 还是打不开？

很多人判断 Clash 是否正常，只看两个地方：客户端有没有显示“已连接”，以及浏览器能不能打开国外网站。

但这两个结果只能证明：Clash 内核大概率已经启动，而且至少有一部分流量可以通过代理。它们不能证明 ChatGPT、Claude 或其他 App 的所有请求，都进入了 Clash、命中了正确规则，并从合适的节点出去。

我之前在 iPhone 上使用 Clash Mi 时，就遇到过一个很典型的情况：同一台手机、同一个节点，ChatGPT 可以正常使用，Claude 却无法登录。切换节点甚至临时改成全局模式，也不一定马上恢复。

排查过程中还有一个很容易被忽略的细节：只是打开 ChatGPT，并不一定能在 Clash Mi 里看到完整连接。只有真正发送一条消息、等待内容返回时，与接口有关的连接才陆续出现，并命中对应的“专线”策略。

这说明问题通常不只是“节点好不好”，而是下面这条链路中的某一环出了错：

App 发出请求 → 系统把流量交给 Clash → Clash 匹配规则 → 策略组选择节点 → DNS 解析 → 服务端判断出口地区与会话状态

这篇文章不提供订阅，也不堆一长串所谓“万能规则”。我想讲的是一套新手也能照着操作的排查顺序。

如果你还分不清 Rule、Global、进程分流、系统代理和 TUN，可以先看上一篇：Clash Verge Rev 与 Clash Mi：规则模式、进程分流和全局模式有什么区别？

先说结论：连接成功，不等于目标 App 一定可用

遇到“ChatGPT 能用，Claude 不能用”时，先不要连续更换十几个节点，也不要急着重装客户端。

先判断问题属于哪一层：

1. 入口问题：目标 App 的流量根本没有进入 Clash；
2. 规则问题：连接进入了 Clash，却被分给了错误的策略；
3. 出口问题：策略组选择了 DIRECT、失效节点或不合适的地区；
4. DNS 问题：域名解析结果不正确，或者 DNS 请求没有按预期进入 Mihomo；
5. 服务问题：服务本身故障，或者账号、出口地区、缓存会话存在限制。

只要按顺序判断，问题就不会再像玄学。

第一步：操作 App 时，Clash 里有没有出现连接？

这是整个排查流程里最重要的一步。

打开 Clash Mi 或 Clash Verge Rev 的“连接”页面，然后切回出问题的 App，执行一次真正的联网操作：

• 在 ChatGPT 或 Claude 中发送一条新消息；
• 刷新登录页面；
• 打开一个此前没有加载过的对话；
• 触发一次文件、图片或语音加载。

随后立即回到 Clash，观察是否出现新的域名、目标 IP、规则和策略记录。

完全看不到新连接

这通常说明问题发生在入口：App 的流量没有被 Clash 接管。

手机上的 Clash Mi 依赖系统提供的 VPN/TUN 能力接管流量。此时应检查：

• Clash Mi 顶部是否真的处于已启动状态；
• iOS 或 Android 是否显示 VPN 已连接；
• 系统有没有撤销 Clash Mi 的 VPN 权限；
• App 是否仍保留着启动 Clash 之前建立的旧连接；
• 切换网络后，VPN/TUN 是否已经断开但界面没有及时刷新。

最简单的处理顺序是：完全退出目标 App，断开 Clash Mi，再重新连接，最后重新打开 App 测试。

电脑上的 Clash Verge Rev 则要继续区分“系统代理”和“TUN 模式”。系统代理依赖软件主动读取系统的代理设置，浏览器通常会遵守，但某些游戏、命令行工具和独立客户端可能完全绕过它。TUN 会通过虚拟网卡接管更多 TCP、UDP 流量，更适合排查“浏览器能用，桌面 App 不能用”的情况。

因此：

Clash 连接页面没有记录时，先解决“流量怎么进来”；不要先折腾分流规则。

能看到连接

说明入口基本正常，下一步就看它去了哪里。

第二步：这条连接命中了什么规则和策略？

在连接详情中，重点找下面几项：

• 目标域名或目标 IP；
• 命中的规则；
• 使用的策略组；
• 最终节点或 DIRECT；
• 连接是否建立成功，是否反复超时。

不同版本的客户端名称可能略有差异，但判断逻辑相同。

例如，同一个手机上的 ChatGPT 和 Claude，可能分别出现下面的结果：

这时节点本身可能完全没有问题，真正的问题是 Claude 使用的某个登录域名、接口域名或静态资源域名没有被规则覆盖，最后落到了错误的兜底策略。

很多 App 都不只访问一个主域名。登录、验证码、接口、图片、文件和风控检查，可能由不同域名承担。只添加一条主域名规则，主页或许能打开，登录和发送消息仍可能失败。

所以不要凭感觉猜域名。正确方法是：实际操作 App，再从连接记录中找出走错策略的请求。

第三步：临时切换 Global，做一次对照测试

全局模式最适合用来诊断，而不是长期使用。

保持同一个节点不变，临时从 Rule 切换到 Global，重新打开目标 App：

• Global 可以使用，Rule 不可以：节点大概率正常，优先检查规则、规则顺序和兜底策略；
• Global 和 Rule 都不可以，但 Clash 里有连接：继续检查节点地区、DNS、服务状态和登录会话；
• Global 下仍然没有连接记录：问题仍在入口，Global 无法替代 TUN；
• 切换 Global 后国内应用也明显变慢：这是正常现象，测试完成后应切回 Rule。

还有一个很常见的坑：切换到 Global 以后，GLOBAL 策略组内部可能仍选择了 DIRECT。

在 Clash Mi 中，应进入“代理”，找到 GLOBAL 组，确认里面选中的是具体节点或正确的节点选择组。仅仅切换模式，不等于已经选好了代理出口。

第四步：同一个节点，为什么两个 App 的出口还能不同？

因为界面上选中的“节点”，未必控制所有策略组。

一份订阅通常包含多个组，例如：

• 节点选择；
• 自动选择；
• AI 专线；
• 流媒体；
• 漏网之鱼；
• GLOBAL。

你在“节点选择”里选了美国节点，不代表“AI 专线”或“漏网之鱼”也会跟着切换。有些策略组引用“节点选择”，有些则独立选择节点，还有些可能仍然是 DIRECT。

因此，排查时不要只看首页显示的节点名称，而要顺着连接详情确认：

当前域名 → 命中规则 → 策略组 → 最终节点

这也是为什么“我明明选了同一个节点”经常会成为误判。

第五步：规则没错，再检查 DNS

DNS 的作用，是把域名转换成程序实际连接的 IP 地址。如果这一环出现问题，常见表现包括：

• 网页偶尔能开，App 却持续转圈；
• 一个网络能用，切换 Wi-Fi 或移动数据后立刻失效；
• 规则看起来命中了代理，但连接仍然超时；
• 域名规则没有生效，只剩下目标 IP；
• 切换配置或节点后，旧结果持续存在。

Mihomo 支持 fake-ip、redir-host、nameserver-policy、respect-rules 等 DNS 选项。它们能解决复杂场景，但也意味着随意复制一段“优化配置”，很可能让问题变得更难判断。

对于使用订阅的新手，我更建议：

1. 先保留订阅提供方原本的 DNS 设置；
2. 检查配置中 DNS 是否启用；
3. 使用 TUN 时确认 DNS 劫持配置没有被覆盖；
4. 切换配置后重新连接 Clash，并彻底重启目标 App；
5. 只有确认是 DNS 问题后，再逐项修改，而不是同时更换 DNS、TUN 堆栈和节点。

一次只改一个变量，才能知道究竟是哪项设置起作用。

第六步：确认节点地区和服务支持范围

如果连接已经进入 Clash、规则和 DNS 也没有明显异常，接下来要看最终出口地区。

ChatGPT 与 Claude 的可用地区并不完全相同，而且服务范围会变化。账号注册、手机号码、付款资料、当前出口 IP 和此前的登录会话，也可能共同影响结果。

因此，不能因为 ChatGPT 在某个节点上可用，就认定 Claude 也一定可用。应分别查看 OpenAI 和 Anthropic 的官方支持地区说明，并遵守服务条款及所在地规定。

如果你本人位于官方支持地区，却仍收到地区错误，可以尝试：

• 确认连接详情中的最终节点确实位于该地区；
• 完全退出 App 后重新打开；
• 清理网页端的站点数据或使用无痕窗口做对照；
• 暂时关闭其他会改变出口的 VPN、代理或隐私工具；
• 查看服务官方状态页，排除平台故障。

不要把“更换节点”当成无限循环。连续切换大量出口，反而可能让登录会话和风险判断更加混乱。

手机 Clash Mi 的推荐排查顺序

以后在 iPhone 或 Android 上遇到类似问题，可以直接照这个顺序检查：

1. 保持 Rule，打开 Clash Mi 的连接页面；
2. 回到目标 App，发送一条消息或刷新登录；
3. 没有新连接：重连 VPN/TUN，并彻底重启目标 App；
4. 有连接：查看域名命中的规则、策略组和最终节点；
5. 如果走到 DIRECT 或错误策略，先调整对应策略组或规则；
6. 临时切换 Global，并确认 GLOBAL 组没有选中 DIRECT；
7. Global 恢复：回到 Rule，修正规则，而不是长期使用 Global；
8. Global 仍失败：再检查 DNS、节点地区、服务状态和账号会话；
9. 每次只修改一项，修改后关闭旧连接并重新测试。

电脑 Clash Verge Rev 的推荐排查顺序

电脑端多一步“系统代理还是 TUN”的判断：

1. 浏览器和目标程序都不能用：先检查配置、节点和 Clash 内核；
2. 浏览器能用，独立程序不能用：优先尝试 TUN，并确认服务模式正常；
3. 开启 TUN 后仍没有连接记录：检查系统防火墙是否拦截 Mihomo 内核；
4. 能看到连接但策略错误：查看域名规则或 Windows 进程规则；
5. 临时使用 Global 做对照，再回到 Rule 修复；
6. 命令行、游戏和虚拟机还可能有独立网络栈，需要分别观察连接记录。

Clash Verge Rev 官方文档把系统代理/TUN称为“入站”，把规则/全局/直连称为“出站”。用这个思路判断，很多设置就不会混在一起了。

最容易浪费时间的五种操作

1. 只会不停换节点

如果流量没有进入 Clash，或者域名命中了 DIRECT，换再多节点也没有意义。

2. 把 Global 当成永久修复

Global 适合做对照测试。长期使用会让国内流量也绕到海外，还可能影响局域网、支付和本地服务。

3. 一次粘贴几十条陌生规则

规则从上到下匹配。来源不明的大段规则可能覆盖原有逻辑，导致新的冲突。先从连接记录中找到真正走错的域名，再做最小修改。

4. 同时修改节点、DNS、TUN 和规则

如果一次改四项，即使恢复了，你也不知道哪项才是原因。下次遇到同类问题仍然不会排查。

5. 只测试“打开 App”

App 首页可能来自缓存。一定要触发一次新的登录、刷新或消息请求，Clash 里才会出现有价值的连接记录。

一张表判断问题在哪

最后总结

以后再遇到“Clash 明明连上了，为什么这个 App 还是打不开”，不要先问哪个节点最好。

先问四个问题：

1. 操作 App 时，Clash 里有没有出现连接？
2. 这条连接命中了哪条规则和哪个策略组？
3. 策略组最后选择了节点，还是 DIRECT？
4. 如果出口正确，DNS、服务地区和登录会话是否正常？

只要能回答这四个问题，绝大多数“一个 App 能用、另一个 App 不能用”的情况，都能被缩小到明确的一层。

Clash 真正有用的地方，不只是让网络“连上”，而是让你看到每一条请求究竟从哪里进来、经过什么规则，又从哪里出去。

参考资料

• Clash Verge Rev：名词解释
• Clash Verge Rev：配置与 TUN/DNS 示例
• Mihomo：DNS 配置
• Mihomo：DNS 解析流程
• Mihomo：TUN 配置
• OpenAI：不支持地区的 ChatGPT 与 API 说明
• Anthropic：Claude 支持地区