ChatGPT 用 Clash 无法访问？超时排查与修复方法

先判断是 ChatGPT 超时,还是 Clash 根本没有接管请求

使用 Clash 访问 ChatGPT 时,常见表现包括页面一直转圈、提示连接超时、打开后只有空白页面、登录按钮没有反应,或者登录完成后又回到登录页。这些现象看起来相似,但故障位置可能完全不同:有时是系统代理没有打开,有时是规则把请求错误地走了直连,也可能是当前节点无法稳定连接目标服务。

ChatGPT 的网页访问通常不只涉及一个域名。主页面、登录认证、静态资源、接口请求以及安全验证可能分别来自 chatgpt.com、openai.com、auth.openai.com、api.openai.com 或相关验证域名。如果只让主站域名走代理,其他认证或接口请求仍然直连,就可能出现页面能打开但无法登录、输入框加载不出来、发送消息后立即报错等半通不通的状态。

排查时不要一上来就改一大段 YAML。先做三个快速判断:第一,Clash 内核是否处于运行状态;第二,浏览器流量是否真的经过 Clash;第三,当前节点是否能稳定完成 HTTPS 连接。只要其中一项答案是否定的,继续调整 DNS 或规则组通常都只是拧错了零件。

现象	优先怀疑的位置	第一步动作
所有海外网站都打不开	内核、端口或系统代理	检查 Clash 运行状态与混合端口
其他海外站点正常,ChatGPT 超时	节点、规则组或目标域名规则	手动切换节点并查看连接日志
首页能开,登录或发送消息失败	认证域名、接口域名未代理	检查相关域名是否命中代理策略
浏览器显示 DNS_PROBE 或解析失败	DNS 模式、系统 DNS 或 fake-ip	清理 DNS 缓存并检查 Clash DNS 设置

第一步:检查代理模式、内核和系统代理

在 Clash Verge Rev 或其他 mihomo 客户端中,先确认配置文件已经成功加载,并且 mihomo 内核没有显示停止、崩溃或配置解析失败。客户端界面能打开不代表内核正在工作:面板只是前端,真正负责监听端口、处理规则和转发流量的是后端核心。

接着查看代理模式。排查 ChatGPT 时,建议先暂时切换到规则模式并确保代理策略组选择了一个明确可用的节点。如果当前处于直连模式,所有请求都会绕过代理;如果处于全局模式却仍然超时,则更应该怀疑节点或本地网络。不要把“全局模式能打开”当作最终配置,它只能用于确认问题是否来自规则匹配。

规则模式:根据 rules 和策略组决定每个请求的出口,适合日常使用。
全局模式:除必要的本地连接外,大多数请求都交给同一个代理组,适合临时验证规则是否写错。
直连模式:请求不经过代理,如果用它测试 ChatGPT,结果不能说明节点是否可用。

如果开启了系统代理,检查系统代理地址是否与 Clash 当前的混合端口一致。mihomo 常见配置如下:

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 同时接受 HTTP 和 SOCKS5 请求,但浏览器或系统代理设置里的端口必须与它完全一致。如果 Clash 改成了 7891,系统代理仍然指向 7890,浏览器就会表现为连接失败或直接回退到直连。还要留意 VPN、其他代理客户端、浏览器代理扩展是否同时运行,多个工具争抢系统代理设置,很容易出现界面显示“已开启”但请求实际没有经过 Clash 的情况。

第二步:用多个节点确认是不是节点服务问题

如果连接日志里能看到请求,但 ChatGPT 仍然超时,下一步要把节点因素单独拿出来验证。节点列表中的延迟数字只能说明探测地址的响应时间,不能保证它一定能稳定访问 ChatGPT。某个节点可能测速很快,但出口 IP 被目标服务限制、线路在建立 TLS 连接时丢包,或者高峰期连接数过多。

建议选三个不同地区或不同线路的节点进行交叉测试,每次切换后等待十几秒,再完整刷新页面。不要只在同一个地区连续切换几个编号相近的节点,因为它们可能共享同一台服务器或同一条出口线路。测试时记录三项结果:首页是否能打开、登录页面是否能完成加载、发送一条短消息是否能得到响应。

测试结果	可能结论	处理方式
只有一个节点失败	该节点负载高、出口受限或线路异常	移出自动选择组,换其他节点
同地区节点都失败,其他地区正常	地区出口或线路存在共同问题	暂时改用其他地区节点
所有节点都失败,其他海外网站也异常	本地网络、订阅或代理核心故障	回到端口、模式和 DNS 继续排查
网页能开但消息发送失败	接口域名或长连接请求未正常代理	查看日志中的接口请求与规则命中

在 Clash Verge Rev 的代理页面中,可以先手动选择节点,再刷新连接日志。若策略组使用了 url-test 或 fallback,自动选择结果可能在测试期间频繁变化,不利于判断。排障完成前,先固定一个节点,把变量减少到最少。确认节点正常后,再恢复自动测速策略组。

还要检查订阅是否过期。订阅过期、节点列表为空、节点参数被服务商更新后未重新拉取,都会导致看起来“有节点”但实际上无法建立连接。更新订阅后观察 mihomo 日志是否出现解析失败、证书错误或代理协议握手失败。不要只看节点名称是否存在,真正有用的是连接测试和日志结果。

第三步:检查规则组是否把 ChatGPT 请求送错出口

在规则模式下,ChatGPT 能否访问取决于域名最终命中了哪个策略组。很多订阅的规则集已经包含常见 AI 服务,但不同订阅的规则名称、规则顺序和覆盖范围并不相同。自定义规则如果放在规则集前面,也可能把请求提前匹配成 DIRECT 或某个不可用的策略组。

排查时打开连接日志,依次刷新首页、打开登录页、发送消息,观察每个请求的域名、匹配规则和最终出口。重点关注以下几类域名:

chatgpt.com 和旧版服务可能使用的 chat.openai.com;
openai.com、auth.openai.com 等登录与认证域名;
api.openai.com 等接口域名;
页面加载过程中出现的验证、静态资源或内容分发域名。

不能简单地认为“看到一个域名就全部手写进规则”。更稳妥的方式是先使用订阅提供的 AI、国外或代理策略组,确认请求是否能正常完成;只有在日志明确显示某个相关域名命中了直连,才增加针对性的规则。示例结构如下,其中策略组名称必须替换成当前配置中真实存在的名称:

rules:
  - DOMAIN-SUFFIX,chatgpt.com,AI
  - DOMAIN-SUFFIX,openai.com,AI
  - DOMAIN-SUFFIX,auth.openai.com,AI
  - DOMAIN-SUFFIX,api.openai.com,AI
  - MATCH,PROXY

规则从上到下匹配,越具体的规则越应该放在前面。若配置中没有名为 AI 的代理组,直接复制这段内容会造成策略组不存在或加载失败,因此不要机械粘贴。可以先把最后的出口改成现有的代理组名称,再通过日志确认是否命中。

如果使用 TUN 模式,规则接管范围会比浏览器系统代理更广,但也更容易受到系统路由、IPv6、虚拟网卡权限和其他 VPN 软件影响。为了定位问题,可以先关闭 TUN,仅开启系统代理测试浏览器;如果系统代理模式正常而 TUN 模式失败,问题就集中在 TUN 路由或 DNS 接管,节点本身通常没有问题。

动手操作:用最小配置逐项恢复访问

下面用“先固定变量,再逐步加回功能”的方法排查。它适用于 Clash Verge Rev 与直接运行 mihomo 的配置,不会要求一次性重写整份订阅文件。

备份当前配置。先复制一份正在使用的 YAML 文件,保留原来的规则、代理组和 DNS 设置。订阅生成的配置可能会被更新覆盖,因此不要只在临时页面里修改而不保存记录。
固定一个已测速成功的节点。暂时不要使用自动测速、负载均衡或故障转移组,在代理页面手动选定一个节点,避免节点变化干扰判断。
使用规则模式测试。确认系统代理已开启,浏览器关闭其他代理扩展,先访问普通网页,再打开 ChatGPT。若普通网页也不通,先修复端口或内核;若普通网页正常而 ChatGPT 不通,继续检查规则。
临时使用全局模式对照。切换全局模式并刷新页面。如果全局模式可以访问、规则模式不行,说明节点基本可用,故障点在规则组或域名匹配。此时回到连接日志,查找被送往直连的相关请求。
检查 DNS。如果日志显示域名解析失败,或者浏览器提示 DNS 错误,再处理 DNS 模式和缓存。不要在没有 DNS 症状时反复更换解析服务器。
逐步恢复设置。确认最小链路可用后,依次恢复 TUN、自动测速、IPv6 和自定义规则。每恢复一项就刷新一次页面,哪一步重新出现超时,故障范围就锁定在哪一项。

Windows 下可以先清理系统 DNS 缓存,再完全退出并重新打开浏览器:

ipconfig /flushdns

如果使用了浏览器的“安全 DNS”或独立代理扩展,它可能绕过系统 DNS 和 Clash 的部分接管逻辑。排查期间可以暂时关闭浏览器独立代理和安全 DNS,只保留 Clash 的系统代理,这样更容易从连接日志判断请求路径。

第四步:处理 DNS、IPv6 与 fake-ip 引起的异常

DNS 问题经常表现为 ChatGPT 页面空白或连接超时,因为浏览器可能成功打开了缓存中的部分资源,但新域名无法解析。mihomo 的 DNS 配置需要与代理模式配合,尤其是开启 TUN 时,系统 DNS、Clash DNS 和浏览器 DNS 可能同时存在,形成“看起来都开启,实际请求路径不一致”的情况。

可以先使用一份相对简单的 DNS 结构进行测试:

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

这只是排查用的示例,实际使用时要结合当前网络环境和订阅模板调整。fake-ip 模式会给域名返回虚拟地址,由 Clash 在后续连接中还原域名并执行规则。它配合 TUN 通常比较完整,但依赖真实 IP 的局域网设备、部分系统服务或特殊应用可能需要加入 fake-ip-filter。如果只有 ChatGPT 异常,不要为了尝试而随意关闭 fake-ip,先从连接日志确认是否存在解析错误。

fallback 也不是“加得越多越好”。DNS 服务器过多会增加响应路径和判断复杂度,某些网络还会限制 DoH 或 UDP DNS。若配置了域名形式的 DoH 地址,需要保证 default-nameserver 能先解析这些服务器域名;写成 IP 地址的 DoH 地址则少一层依赖。修改 DNS 后要清理浏览器缓存、重启 Clash 内核,否则旧解析结果可能继续保留。

IPv6 也是常见干扰源。如果本地网络发布了 IPv6 地址,但节点或 TUN 路由没有正确处理 IPv6,浏览器可能优先尝试 IPv6,等待失败后才回退到 IPv4,最终表现为加载缓慢或超时。排查阶段可以暂时设置 ipv6: false,同时关闭客户端中的 IPv6 相关选项进行对照。恢复 IPv6 前,先确认网络、DNS 和代理链路都支持它。

登录失败、页面空白和验证码循环怎么处理

如果 ChatGPT 首页能打开,但登录按钮无响应、登录后反复跳转,先不要立即更换所有节点。此类问题常见原因是认证域名没有走同一代理出口、浏览器缓存了旧的会话信息、第三方 Cookie 被拦截,或者当前出口 IP 的稳定性不够。

在无痕窗口中重新测试,排除旧 Cookie、缓存和扩展脚本影响。
暂时停用广告拦截、脚本管理、浏览器代理切换等扩展。
确认登录页面涉及的认证域名没有命中 DIRECT。
固定一个节点完成登录,不要在登录过程中让自动策略组切换出口。
如果验证码反复出现,先更换一个稳定节点并等待一段时间,不要连续刷新造成更多验证。

不同节点之间频繁切换出口 IP,可能让登录会话失效,这不是 Clash 端口故障。登录成功后,再恢复自动选择组并观察是否会重新触发认证。如果一换回自动组就失败,说明自动组里包含不稳定节点,可以把测试正常的节点固定下来,或者调整策略组的健康检查地址和切换条件。

最后如何定位责任环节,以及哪些设置值得保留

完成上述测试后,基本可以按结果归类。若全局模式和多个节点都无法访问,但普通网站也异常,重点检查本地网络、系统代理端口、内核启动状态和订阅有效期。若全局模式正常而规则模式异常,重点检查规则顺序、策略组名称和相关域名是否误走直连。若只有某个节点失败,直接更换节点即可,不必为了一个坏节点重写 DNS。若系统代理正常而 TUN 失败,则检查虚拟网卡权限、路由表、IPv6 和其他 VPN 软件冲突。

长期使用时,建议保留一套简单、可回退的配置:规则组中有一个明确的代理出口,关键域名由稳定的规则集处理,系统代理和混合端口保持一致,DNS 不堆叠过多实验参数,自动测速组不要包含长期超时的节点。每次更新订阅后,先查看策略组和规则是否仍然存在,再测试 ChatGPT,避免订阅模板变化后悄悄删除了原来的策略组。

日常使用规则模式,全局模式只作为临时诊断工具。
为关键代理组保留一个手动可选节点,自动组异常时可以快速回退。
改动 YAML 前先备份,一次只调整一个变量。
遇到超时时优先看连接日志,日志比浏览器的“无法访问”提示更接近真实故障点。
不要同时运行多个会修改系统代理、DNS 或虚拟网卡的工具。

ChatGPT 无法访问通常不是某一个神秘开关造成的,而是“请求有没有进入 Clash、进入后命中了什么规则、节点能不能完成连接、DNS 是否返回了可用结果”这条链路中的某一环出了问题。按照代理模式、节点、规则组、DNS 和 TUN 的顺序逐项缩小范围,大多数超时、空白页和登录失败都能定位到具体零件,修复时也不需要把整份配置拆成一地 YAML。