先判断是哪一段出了问题
ChatGPT 经 Clash 或 mihomo 访问时打不开、登录失败、页面一直转圈，表面现象相似，故障位置却可能完全不同：请求没有进入代理、规则把请求送到了直连或拒绝策略、节点连不上目标站点，或者浏览器与服务端之间的连接在加载过程中中断。先别同时改 DNS、切模式、换客户端；一次只验证一层，才能知道哪项设置确实解决了问题。
还要区分“客户端已启动”和“目标网站可用”。Clash Verge、Clash Verge Rev、ClashX 等客户端显示运行中，通常只表示内核或代理入口已启动；节点延迟测试有结果，也不代表 ChatGPT 的登录、页面资源和持续连接都能正常完成。若只有 ChatGPT 出问题而其他常用网站正常，优先检查目标域名的分流规则、节点出口以及浏览器会话，而不是立即重装客户端。
| 现象 | 优先检查 | 先不要做的事 |
|---|---|---|
| 页面完全打不开 | 代理入口、策略组、节点连通性 | 直接修改一整套 DNS 配置 |
| 登录页反复跳转或登录失败 | 节点出口稳定性、浏览器 Cookie、系统时间 | 反复提交密码或验证码 |
| 页面能打开但一直转圈 | 目标请求实际命中的规则、连接日志、节点稳定性 | 仅凭首页能显示就认定代理正常 |
| 换节点后仍无法使用 | 是否仍走同一错误规则、其他代理或 VPN 是否冲突 | 同时开启多个代理接管工具 |
先确认代理入口与节点确实可用
在客户端“配置”或“订阅”页面确认当前使用的是已成功加载的配置，而不只是列表中存在一份订阅。再进入“代理”页面，检查实际生效模式及策略组成员。规则模式下，只有命中代理策略的请求才会使用节点；选中了某个节点，不等于所有网站请求都自动经过它。首次排查可在支持的情况下暂时选择一个明确的手动节点，避免自动选择组在测试期间切换成员。
- 确认客户端没有显示内核启动失败、配置解析错误或端口占用提示。
- 在策略组中选一个延迟测试有响应的节点。若只有一两个候选项，先分别测试，不要连续多次触发整组测试。
- 用浏览器打开一个常见 HTTPS 网站，再尝试 ChatGPT；若前者也失败，优先排查本机代理、节点或网络。
- 在客户端“连接”或“日志”页面发起一次新的 ChatGPT 请求，观察目标域名、匹配规则、策略组和最终出站。
如需把“应用是否使用系统代理”与“代理本身是否能请求网站”分开，可用显式代理请求进行对照。以下命令中的 7890 只是示例端口，必须替换为客户端设置中显示的实际 HTTP 或混合代理端口；部分客户端默认值不同。
curl --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 -I https://chatgpt.com/命令收到 HTTP 响应，只能说明这次请求有响应，不能证明登录、页面脚本、图片资源和后续连接都正常。若本地提示无法连接代理端口，检查内核是否运行、监听地址是否为本机地址，以及端口是否抄错；若端口可连接但请求超时，则继续查策略组、命中规则、节点和内核日志。不要把测试命令中的端口照抄进 YAML 后就认为客户端设置一定随之改变，客户端覆写配置可能会使用另一端口。
中部实操：检查目标请求有没有命中代理规则
如果一般网站能打开，ChatGPT 却打不开或页面资源加载不全，下一步不是先换 DNS，而是确认相关请求到底走了什么规则。打开客户端的“连接”页面，在浏览器重新加载一次目标网页，筛选新出现的连接记录。不同客户端的列名可能是“规则”“策略”“链路”或“出站”；重点是确认目标域名、规则类型和最终代理成员。
- 清理观察范围：先关闭旧标签页，再只打开一个 ChatGPT 标签，避免把其他网站的连接记录混在一起。
- 触发新请求：刷新页面，等十几秒后查看连接记录。连接可能由页面、登录服务或静态资源域名分别发起。
- 核对命中结果：如果相关请求显示
DIRECT、REJECT，或落入非预期策略组，记录具体域名与规则，不要只看顶层组名。 - 做一次受控对照：暂时让相关请求走一个已确认可用的策略组，再刷新验证。仅改一项，确认结果后恢复或按需保存。
- 检查规则顺序：Clash 风格规则通常按配置顺序匹配。若更宽泛的规则已先匹配，后面的域名规则可能根本不会执行。
ChatGPT 访问涉及的域名可能随产品页面、登录流程和静态资源调整，不能只盯着一个首页域名。连接记录中若出现 chatgpt.com、openai.com 或其子域名，先以当前实际记录为准；不要把未经观察的域名列表整段照抄到配置里。若服务方文档或当前连接日志明确指出其他相关域名，再按客户端支持的规则格式添加。
下面是规则写法的示意，不能直接替换整个订阅配置。实际规则应放在正确的 rules 段，并使用配置中真实存在的策略组名称；域名规则要位于可能提前匹配的宽泛规则之前。
rules:
- DOMAIN-SUFFIX,chatgpt.com,Proxy
- DOMAIN-SUFFIX,openai.com,Proxy
- MATCH,其他策略这里的 Proxy 和 其他策略 都是示例名称，必须改成当前配置中的有效策略组。若使用客户端的覆写、规则集或订阅转换功能，修改来源和更新行为也要一并确认：远程订阅更新可能覆盖直接编辑的内容。不要为了单个网站把所有流量永久改成同一出口。
DNS、TUN 与浏览器：按症状选择处理方式
只有域名解析异常时再查 DNS
DNS 问题常见表现包括连接日志出现解析错误、域名无法解析，或同一网络下域名解析结果反复变化。可先在系统终端执行 nslookup chatgpt.com，观察是否返回解析结果；该命令通常查看系统当前使用的解析路径，不能单独证明 Clash 内核使用的是同一解析器。Clash 或 mihomo 配置可能包含独立的 DNS 设置、远程解析和缓存行为，最终应结合客户端日志判断。
如果只有某个域名解析失败，先核对该域名的 DNS 请求是否进入预期的代理或解析流程，并检查客户端日志中的错误信息。不要同时更换多个公共 DNS、关闭加密解析、清空系统网络设置；这些操作会改变多项条件，也可能引入新的解析差异。若近期修改过 DNS 配置，先恢复最近一次确认可用的设置，再重新加载配置验证。
应用不读系统代理时再测试 TUN
系统代理主要服务于遵循系统代理设置的浏览器和应用，并不等于全设备流量接管。如果浏览器显式指定代理时可访问，但某个桌面应用仍失败，先检查该应用是否有独立代理选项、是否启用了自己的 VPN 或网络过滤工具。确实需要接管不读取系统代理的流量时，再考虑启用 TUN。
TUN 需要客户端、内核、系统权限和路由共同配合。开启前先关闭其他 VPN 或代理客户端，确认客户端运行日志没有权限错误，再按客户端提示授权或安装所需服务。启用后只验证一个应用，并检查连接记录及路由结果；若网络整体断开，先关闭 TUN 恢复原状态，再检查权限、虚拟网卡、排除路由和冲突软件。TUN 能改变流量进入内核的方式，但不会修复失效节点、错误规则或不可用的账户。
登录循环时排除浏览器会话问题
如果登录页面能显示，但不断跳回登录页、验证码重复出现或页面状态无法保持，可用无痕窗口作一次对照。若无痕窗口正常，优先检查浏览器扩展、站点 Cookie 和缓存；清理前确认不会丢失重要的本地登录状态。核对设备日期与时间是否自动同步，错误的系统时间可能影响安全连接或验证流程。不要在排查过程中反复更改账户密码、频繁触发验证码，也不要把包含登录令牌的地址或完整日志公开。
按验证结果修复，并逐项恢复配置
| 验证结果 | 更可能的问题层 | 建议下一步 |
|---|---|---|
| 本地代理端口无法连接 | 内核未运行、端口不符或监听失败 | 查看启动日志与客户端实际端口 |
| 普通网站和 ChatGPT 都失败 | 代理入口、节点或本地网络 | 选一个已测通节点，先验证其他 HTTPS 请求 |
| 普通网站成功，目标连接显示直连 | 规则顺序或策略组选择 | 依据连接记录修正目标规则并重测 |
| 浏览器可用，单个应用失败 | 应用未使用系统代理或路由未接管 | 检查应用代理设置，必要时单独测试 TUN |
| 页面与登录均可打开，但加载间歇中断 | 节点稳定性、连接链路或服务端响应 | 换一个稳定节点并观察新连接日志 |
更换节点时优先选择测试结果稳定、且能实际打开目标页面的线路，而不是只看某次最低延迟。连续重测时若一会儿成功、一会儿超时，应记录时间、网络类型和所选节点；Wi-Fi、移动网络与高峰时段可能得到不同结果。若同一节点的普通 HTTPS 请求也频繁中断，先换一个候选节点做对照，不要把故障直接归结为 DNS。
完成修复后，按“目标页面能打开 → 登录状态能保持 → 页面内容能够持续加载”的顺序验证。再检查一次连接记录，确认相关请求落入预期规则和策略组。最后恢复不需要的全局模式、临时规则和测试设置，只保留验证有效且有明确用途的改动。若问题仍在，提供脱敏后的客户端与内核版本、操作系统、报错文字、发生时间及相关连接规则；务必遮住订阅地址、节点密码、账户信息和控制接口密钥。