ChatGPT 用 Clash 无法访问？超时连接失败这样排查

先判断问题在哪一层

使用 Clash 访问 ChatGPT 时出现打不开、连接超时、页面一直转圈或对话内容加载缓慢，不一定都是节点失效。一次完整访问至少经过客户端、代理模式、规则匹配、DNS 解析、节点出口和目标连接六个环节，其中任何一环配置不当，都会表现为“ChatGPT 不能用”。先区分故障现象，再开始修改配置，通常比直接更换一堆参数更快。

如果 Clash 面板里的节点延迟测试全部失败，优先检查订阅、节点有效期和当前网络；如果节点延迟正常，但浏览器访问目标站点超时，重点看规则和代理模式；如果首页能打开、登录或对话阶段失败，可能是部分域名没有走代理，或者浏览器缓存了错误的连接状态；如果只有命令行、桌面应用或某个浏览器失败，则要检查系统代理、浏览器独立代理和 TUN 接管范围。

检查 Clash 客户端与代理模式

先确认客户端本身处于运行状态。Windows 查看系统托盘，macOS 查看菜单栏，安卓与 iOS 查看 VPN 或代理连接状态。客户端窗口显示“已启动”并不等于浏览器已经使用代理，还要确认系统代理开关、当前配置文件和当前策略组都处于生效状态。配置导入成功但没有选中配置文件，是新手经常忽略的一步。

日常排查建议暂时把模式切换为全局(Global)，再选择一个延迟较低且近期可用的节点测试。全局模式会把遵循系统代理的请求统一交给当前节点，可以快速排除规则匹配问题。测试完成后应切回规则(Rule)，不要长期使用全局模式，否则国内网站、系统服务和更新请求也会占用代理流量。

• 规则模式:由 rules 从上到下匹配请求，命中后交给 DIRECT、REJECT 或代理策略组。
• 全局模式:所有被 Clash 接管的请求都进入选定的代理策略组，适合临时诊断。
• 直连模式:请求不经过代理，只用于对照测试。若直连访问失败，不能据此判断 Clash 配置有问题。

接着检查系统代理地址。常见混合端口是 7890 或 7897，但应以客户端设置页显示的端口为准。手动为浏览器或应用填写代理时，地址通常是 127.0.0.1，端口填写 Clash 的 mixed-port。不要把远程节点端口、订阅地址端口或控制面板端口误填到这里。

检查目标域名是否命中代理规则

在规则模式下，最重要的是打开连接日志或请求日志，访问目标页面后观察相关请求最终落到哪个策略组。不要只看首页域名，登录、静态资源、验证、接口和媒体资源可能使用不同的主域名或子域名。只要其中关键请求被分到 DIRECT，页面就可能出现空白、登录失败或无限加载。

如果客户端支持“连接详情”或“规则匹配”页面，逐条查看请求的目标域名、解析地址、命中的规则和最终策略。理想结果是相关请求稳定命中同一个代理策略组，而不是一部分走节点、一部分直连。策略组本身还要确认已经选中可用节点；只命中一个名为 PROXY 的策略组，不代表该组里的具体节点一定可用。

配置中可以把需要代理的域名规则放在国内直连规则之前，并把兜底代理规则放在末尾。示例使用明显的占位策略组名称，实际使用时请替换为配置中已有的策略组：

rules:
  - DOMAIN-SUFFIX,example-chat.invalid,PROXY
  - DOMAIN-SUFFIX,example-login.invalid,PROXY
  - DOMAIN-SUFFIX,example-static.invalid,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上面的域名只是示例占位符，不能直接当作真实目标规则使用。实际排查时应以连接日志显示的目标域名为准，并优先使用客户端或服务商提供的维护中规则集。不要随意添加大量关键词规则，因为 DOMAIN-KEYWORD 会匹配包含该字符串的域名，短关键词很容易误伤国内网站和本地服务。

动手排查：从节点到页面逐步验证

下面这组步骤适合 Windows、macOS 和 mihomo 客户端。每完成一步就记录结果，不要同时修改节点、DNS、规则和浏览器设置，否则无法知道哪项改动真正解决了问题。

1. 更新一次订阅，确认配置文件更新时间正常，节点列表不是空白，也没有全部显示过期或不可用。
2. 在客户端的代理页选择一个延迟较低的节点，先进行 TCP 延迟或连通性测试；测试全部失败时，暂不修改 DNS，先处理节点与网络。
3. 开启系统代理，把模式切换为全局，使用浏览器的隐私窗口重新访问目标站点，排除旧 Cookie、扩展和缓存影响。
4. 若全局模式可以访问，切回规则模式，打开连接日志，刷新页面并记录被判定为 DIRECT 的目标域名，再为这些域名补充代理规则。
5. 若规则模式和全局模式都失败，暂时换一个节点；若换节点后恢复，说明原节点线路、出口地址或节点负载存在问题。
6. 若浏览器成功而桌面应用失败，开启 TUN 模式并允许系统权限；没有 TUN 时，为该应用单独填写 127.0.0.1 与 mixed-port。
7. 清理浏览器的 DNS 缓存和连接池后再次测试。Windows 可执行 ipconfig /flushdns，Chromium 系浏览器可在内部网络页面清理 DNS 与 socket 缓存。

如果某一步恢复正常，就先保留这一步的最小改动。例如全局模式有效而规则模式无效，问题大概率在规则，不要马上更换内核；更换节点有效而所有其他设置不变，问题大概率在原节点，不要反复修改 DNS。

浏览器之外的应用：使用 TUN 接管流量

系统代理只对遵循 HTTP、HTTPS 或 SOCKS 设置的应用有效。部分桌面应用、命令行工具、基于 UDP 的连接和带有独立网络栈的程序不会读取系统代理，因此浏览器能访问并不能证明整台设备都已接管。mihomo 的 TUN 模式通过虚拟网卡接管更广泛的流量，适合解决“只有某个应用无法访问”的情况。

在 Clash Verge Rev、Mihomo Party 等客户端中，通常需要先安装服务模式或授权特权服务，再开启 TUN、自动路由和自动选择网卡。Windows 可能需要管理员权限，macOS 需要允许系统扩展或帮助程序，安卓则会弹出 VPN 连接请求。权限没有完成时，TUN 开关即使显示打开，也可能没有实际接管流量。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

• enable 开启 TUN；如果客户端界面另有开关，配置文件和界面状态都要确认。
• stack: mixed 兼顾 system 与 gVisor 的兼容性，遇到特定应用异常时可对比其他 stack。
• auto-route 自动写入路由，减少手动配置错误；多网卡设备建议保留 auto-detect-interface。
• dns-hijack 把发往 53 端口的 DNS 查询交给 Clash，避免应用绕过代理直接使用系统解析。

开启 TUN 后，如果局域网设备、打印机或企业内网无法访问，不要立刻关闭所有功能。先检查是否需要把局域网网段加入直连规则，或把 *.lan、*.local 等本地域名加入 fake-ip 过滤列表。TUN 的目标是扩大接管范围，不是让所有地址都走代理。

DNS 与 IPv6：页面能开但内容加载失败

DNS 错误会让域名解析到错误地址、返回不可达地址，或让同一页面的不同资源落到不一致的出口。尤其在规则模式和 fake-ip 模式下，DNS 不只是“把域名翻译成 IP”，还会影响域名规则能否匹配、请求是否能被正确还原。开启 TUN 后，建议同时确认 Clash DNS 模块已经启用，并检查日志里是否能看到相关查询。

常见的 mihomo DNS 配置可以从下面的结构开始，再根据网络环境调整上游地址。示例中的保留地址仅用于说明格式，不能作为真实公共 DNS 使用：

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

fake-ip 会先为域名分配 198.18.0.0/16 网段中的虚拟地址，Clash 根据保存的域名映射继续执行分流。它通常更适合需要域名规则和 TUN 接管的场景，但局域网、本地发现和部分特殊应用可能需要加入过滤列表。若 fake-ip 导致某个应用异常，可暂时切换为 redir-host 做对照，确认问题是否来自增强模式兼容性。

如果网络同时启用了 IPv4 和 IPv6，而节点或规则只处理 IPv4，浏览器可能优先尝试 IPv6，随后等待超时。排查阶段可以将 ipv6 设为 false，或者确认 TUN 已正确接管 IPv6 路由。关闭 IPv6 是定位手段，不是所有网络环境下的永久最佳方案；确认节点和系统支持完整 IPv6 后再决定是否恢复。

浏览器与登录状态的最后检查

当连接日志显示请求已经走代理，但页面仍然卡在登录或验证阶段，可以进行浏览器侧对照。先打开隐私窗口测试；如果隐私窗口正常，通常是扩展、Cookie、站点存储或缓存连接导致。再暂时关闭浏览器内置的“安全 DNS”，避免浏览器通过自己的 DoH 通道绕过 Clash DNS。测试完成后是否重新开启，应根据隐私需求和 Clash 的 DNS 接管方案决定，重点是不要让两套解析链路互相冲突。

同时检查系统时间是否准确。TLS 证书验证依赖本机时间，时间偏差过大时会出现安全连接失败、登录重定向异常或页面资源加载失败。企业网络、校园网络和公共 Wi-Fi 还可能要求先完成门户认证；在这种网络中，先用直连打开认证页面，再恢复 Clash 代理进行测试。

最后回到客户端日志确认三个事实：目标域名是否进入 Clash、命中了哪条规则、实际使用了哪个节点。如果三项都正确但连接仍频繁超时，继续更换节点或线路比继续堆叠规则更有效。节点质量、出口可达性和服务端限制都属于客户端配置无法修复的问题。

按最小改动顺序恢复访问

这类问题最稳妥的处理顺序是：确认订阅和节点可用，开启系统代理，使用全局模式做一次对照，再在规则日志中确认目标请求，随后检查 DNS 和 IPv6，最后才启用 TUN 处理不遵循系统代理的应用。每次只改变一个变量，并在成功后把配置恢复为日常需要的规则模式。

如果仍然失败，可以把结果整理成一份清单：客户端名称与内核版本、操作系统、模式、节点测试结果、目标请求的命中规则、DNS 模式、是否启用 TUN，以及更换节点后的现象。这样的信息比单独描述“ChatGPT 打不开”更容易定位，也能避免重复修改已经正常的部分。