先判断故障发生在哪一层
Clash 客户端显示已连接，只能说明内核可能已经启动，不能证明浏览器访问 ChatGPT 的请求确实经过代理。排查时把问题拆成四层：应用有没有把请求交给本地代理、mihomo 是否为请求匹配到代理规则、策略组最终选中了什么出站，以及该节点能否完成到目标站点的连接。只看系统代理开关或节点延迟，容易把规则走直连、浏览器覆盖代理设置和节点连接失败混为一谈。
先记录当前使用的客户端、操作系统、接管方式、代理模式和报错现象。若只有 ChatGPT 网页失败，而其他网站正常，优先检查 ChatGPT 相关域名的规则命中和节点可达性；若所有境外网站都打不开，则先检查内核、端口、节点和网络本身。若桌面网页能打开、手机应用仍失败，还要考虑应用是否使用了不同的网络路径。
- 页面一直转圈或连接超时：查看连接记录中是否出现目标域名，以及该连接最终使用的策略组和出站。
- 页面显示区域不可用：这不一定是代理故障；先确认服务在当前地区是否可用，并检查账户与服务状态。
- 能打开登录页但登录失败：进一步观察认证跳转、验证码或登录域名是否被规则送到不同出站。
- 偶尔成功、随后失败：固定一个节点复测，排除自动选择组切换、网络波动和浏览器旧连接的影响。
检查模式、策略组和节点
在 Clash Verge、Clash Verge Rev、Clash for Windows、ClashX 或其他 mihomo 客户端中，先确认当前启用的是预期配置，再查看运行模式。规则模式下，访问 ChatGPT 是否走代理取决于规则匹配结果；全局模式通常会把连接统一交给全局策略组，但也可能改变其他应用的流量行为。排障时不必长期切换全局模式，可以短暂用于比较，完成测试后恢复原来的模式。
- 确认配置已启用：在配置列表中确认选中的订阅或本地配置是当前运行配置，并查看内核日志是否有解析失败、规则集下载失败或策略组为空等错误。
- 确认工作模式：在代理设置中查看是否为“规则”或
rule。记录原有模式，不要把切换到全局后暂时能访问误当成规则已修复。 - 找到实际策略组：在代理页面查看 ChatGPT 请求命中的组，再展开组内选择。组名由配置作者决定，可能叫“节点选择”“国际流量”或其他名称。
- 固定一个具体节点：临时选择一个已完成延迟测试的节点，避免自动测速组或故障转移组在复测期间更换出站。
- 确认不是直连或拒绝：检查最终选择是否为具体代理节点，而不是
DIRECT、REJECT或一个没有有效成员的空策略组。
延迟测试成功只代表内核能够通过该节点完成测试地址的探测，不等于 ChatGPT 所需的所有连接都可达。节点标签中的地区名称也不是出口归属的可靠证明。对同一个目标反复超时，而其他网站请求正常时，优先在连接记录中查看该目标对应的出站，并用另一个稳定节点进行对照。
| 现象 | 优先检查 | 下一步验证 |
|---|---|---|
| ChatGPT 请求命中 DIRECT | 规则顺序、规则集和策略组映射 | 固定一个代理节点后重新查看连接记录 |
| 请求命中代理组但出站超时 | 当前节点、节点协议及网络质量 | 更换一个节点，保持其他设置不变 |
| 连接记录中没有相关请求 | 浏览器是否使用系统代理、是否启用 TUN | 使用显式代理请求或检查 TUN 接管状态 |
| 请求成功但网页仍报错 | 登录跳转、浏览器缓存、服务端响应 | 新建浏览器会话，并查看具体 HTTP 状态 |
规则模式下检查域名命中
mihomo 按 rules 从上到下检查连接，命中规则后就使用该规则指定的策略，不会继续尝试后面的规则。若 ChatGPT 相关请求被前面的通用规则送到 DIRECT，在末尾添加代理规则不会改变结果。先从客户端连接记录查看实际请求域名和命中规则，再决定是否需要覆写配置；不要仅凭首页打不开就猜测某个域名被漏掉。
以下是规则写法示意，展示如何把两个主域名交给已有的代理策略组。它不是完整配置，也不包含节点、策略组定义或所有服务依赖域名：
rules:
- DOMAIN-SUFFIX,chatgpt.com,PROXY
- DOMAIN-SUFFIX,openai.com,PROXY
# 保留现有规则，并确保对应规则位于可能将这些请求设为 DIRECT 的宽泛规则之前
- MATCH,其他策略组DOMAIN-SUFFIX,openai.com 和 DOMAIN-SUFFIX,chatgpt.com 能覆盖各自主域及其子域，但不代表所有登录、静态资源、验证或第三方服务都使用这两个后缀。连接记录中若显示其他相关域名，先核实它是否属于本次访问流程，再按需处理。规则过宽可能改变同一域名下其他服务的路由；修改后应检查规则命中、策略组和实际出站，而不是只看网页能否刷新。
动手验证系统代理与 TUN
这一轮测试的目标是确定浏览器请求有没有到达 mihomo。桌面浏览器通常可以先使用系统代理；不读取系统代理的应用，或需要接管更多应用流量时，再单独检查 TUN。系统代理与 TUN 是不同的流量入口，开启其中一种不代表规则会自动把 ChatGPT 送到代理节点。
先用显式代理测试本地入口
先在客户端设置或当前生效配置中读取 HTTP 或混合代理端口。下面以 7890 为示例；实际端口可能不同。Windows PowerShell 使用 curl.exe，避免命令名称被旧版环境解释成其他程序。
# macOS / Linux
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://chatgpt.com
# Windows PowerShell
curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://chatgpt.com如果本地连接被拒绝，先核对内核是否运行、监听端口是否正确，以及是否有其他程序占用端口；如果命令已经连到本地代理，但后续超时，就查看 Clash 的连接记录和节点出站。返回 200、301、302 或其他 HTTP 状态，只说明这次请求收到了响应，不等于账户一定能登录或服务端一定接受后续请求。状态码 403 也不能单独证明本地规则错误。
浏览器仍失败时核对接管方式
- 确认客户端的系统代理开关已开启，并核对系统代理地址与客户端实际 HTTP 代理端口一致。
- 检查浏览器是否使用系统代理；Firefox 可查看「设置」→「常规」→「网络设置」，确认没有独立的手动代理或自动配置脚本覆盖设置。
- 暂时停用会控制代理的浏览器扩展，完全退出并重新打开浏览器，再发起一次新的访问请求。
- 若使用 TUN，确认客户端已取得所需系统权限，TUN 接口和路由确实建立，并在连接记录中看到浏览器请求；仅开关显示开启并不足以证明流量已接管。
系统代理通常只影响遵循操作系统代理设置的应用；TUN 通过虚拟网卡接收符合路由条件的 IP 流量，但仍然受规则、路由排除项和其他 VPN 影响。排障时不要同时开启多个代理客户端，也不要把控制接口端口当作浏览器代理端口。若显式代理测试成功而浏览器请求没有出现在连接记录中，问题更可能在浏览器代理设置或流量接管，而不是节点本身。
按报错现象收尾并恢复设置
完成前面的检查后，尽量在相同浏览器、相同网络和固定节点下复测。记录时间、访问的主机名、命中的规则、策略组、实际节点和错误信息；这些信息比“Clash 已连接”更能说明故障位置。遇到验证码或登录循环时，可先用新的浏览器会话测试，并确认认证跳转期间的相关请求没有被分配到不同出站。清除站点数据可能导致重新登录，操作前确认已保存必要的账户恢复方式。
- 显式代理也无法连接其他网站：检查本地监听、内核日志、网络连通性和节点状态。
- 其他网站可用，但 ChatGPT 命中直连：修正规则顺序或策略组映射，然后重新查看命中结果。
- ChatGPT 命中代理但持续超时：固定另一个节点对照测试，检查相关域名连接是否都走预期出站。
- 命令行成功而浏览器失败：检查浏览器独立代理、扩展、PAC 脚本和旧连接，并重新启动浏览器。
- 网络请求成功但服务提示地区或账户限制：检查服务当前可用地区、账户状态和官方服务提示，不要把此类限制简单归因于 DNS 或端口。
若问题在切换全局模式后消失，回到规则模式并检查具体命中项，再决定是否调整自定义规则；不要为了临时访问而永久保留未经验证的全局设置。若启用 TUN 后问题加重，先关闭 TUN、恢复原有系统代理状态并重新测试，避免把两个接管方案叠加。完成排障后恢复此前暂停的浏览器扩展、规则或网络设置，只保留已经验证有效且理解其影响的改动。