先判断超时发生在哪一步
ChatGPT 打不开，不一定是代理节点失效。浏览器可能在域名解析、连接代理、TLS 握手或等待网页响应时卡住；客户端里显示节点延迟正常，也不能证明访问 ChatGPT 所需的域名都走了正确策略。先记录具体表现：页面一直转圈、提示网络错误、登录页打不开，还是页面能打开但提交消息后超时。不同现象对应的检查方向并不相同。
排查时固定一台设备和一个网络，每次只改变一个条件。记录测试时间、客户端与内核版本、代理模式、当前节点和报错文字。不要一开始就同时换 DNS、切 TUN、改规则和重装客户端，否则即使恢复，也难以知道真正原因。
- 只有 ChatGPT 异常：优先检查相关域名的规则命中、登录流程和节点出口。
- 多个国外网站都打不开：优先检查节点连接、系统代理状态、本地网络和客户端日志。
- 浏览器可用，桌面应用或其他浏览器不行：检查应用是否读取系统代理，或是否需要 TUN 接管。
- 页面能加载，登录或发送消息超时：检查相关请求是否使用同一策略、DNS 是否稳定，以及连接是否被中途重置。
检查代理模式、代理组与节点
先在 Clash Verge、Clash Verge Rev 或其他客户端中确认内核正在运行，配置没有报错，代理端口也处于监听状态。常见的 HTTP 或混合代理端口可能是 7890，但端口由配置决定，不要把示例值当作所有客户端的固定设置。若客户端显示内核未启动或配置加载失败，先处理日志中的启动错误。
将模式暂时设为“规则”或“全局”进行对照。规则模式会根据规则把不同请求送到不同策略；全局模式通常会把匹配到的代理流量交给所选代理策略，但具体行为仍取决于客户端和内核。若规则模式下 ChatGPT 超时、全局模式下恢复，问题更可能与规则或策略组有关；这只是定位线索，测试后应恢复日常使用的模式。
- 打开代理页面，找到实际承载网页请求的策略组，暂时手动选定一个节点，避免自动测速组在测试过程中切换。
- 打开 ChatGPT 页面，同时查看客户端的连接列表，筛选目标域名或浏览器进程。
- 检查连接显示的匹配规则、策略组和最终出口。若连接命中
DIRECT，而你预期它使用代理，就需要检查规则顺序、规则集更新状态和域名匹配范围。 - 用同一节点测试另一个正常的 HTTPS 网站，再换一个节点重复 ChatGPT 测试。每轮只更换节点，不要同时更改 DNS 或 TUN。
列表中的延迟只是指定测试请求的响应时间，不是目标网站的完整连通性测试。节点能通过延迟测试，仍可能在访问特定站点时遇到出口路由、连接重置或目标服务拒绝。反过来，ChatGPT 的网页超时也不等于节点整体不可用。
核对域名规则是否命中预期策略
ChatGPT 网页并非只请求一个主机名。打开页面、登录、加载静态资源、发送消息和建立实时连接，可能涉及不同域名或连接类型。规则只覆盖某个主域名时，其他请求仍可能命中默认规则、直连规则或不同代理组。因此，不能只看主页能否打开，也不能只通过给某一个域名加规则就断定问题已解决。
在客户端连接列表中观察实际出现的域名和规则结果。常见的相关域名可能包括 chatgpt.com、openai.com 及其子域名；实际请求会随页面和服务调整，不能把这份示例当作永久完整清单。登录、验证或静态资源还可能由其他服务域名承载，应以当前连接记录为准。
- 连接显示 DIRECT：查看规则顺序、规则集是否成功载入，以及域名是否被更靠前的规则提前匹配。不要为了方便直接删除全部本地规则。
- 连接进入错误的代理组：检查规则对应的策略组是否存在、是否选中可用节点，以及嵌套策略组最终指向哪个节点。
- 连接列表没有相关记录：确认页面请求是否发出、客户端是否正在接管该应用流量，以及连接列表是否应用了过滤条件。
- 只在登录或发送消息时失败：观察失败时新增的连接记录，区分页面静态资源、认证请求与长连接，不要只凭首页加载结果判断。
编辑自定义规则前，先备份配置，并确认客户端使用的是订阅原配置还是覆写配置。订阅更新可能覆盖直接修改的内容；如果客户端提供合并配置或规则覆写功能，应按客户端实际机制操作。修改后重新加载配置，在连接列表中确认新规则已生效，再进行同一页面的对照测试。
动手操作：按固定顺序复现并定位
下面流程适合桌面浏览器。示例中的本地端口使用 7890，只有在客户端确认该端口是 HTTP 或混合代理入口时才能照用。测试时不要公开订阅链接、访问令牌、节点密码或包含个人信息的日志。
- 先确认客户端内核已启动，记下规则模式、代理组、手动选择的节点和实际本地代理端口。
- 在规则模式下打开 ChatGPT，等待出现明确错误后记录时间，并在连接列表中查看域名、匹配规则、策略组和错误信息。
- 保持节点不变，临时切换到全局模式再测试。如果恢复，回到规则模式检查命中结果；如果仍失败，继续下一步。
- 保持模式不变，改选另一个节点再测试。如果只有一个节点失败，问题更可能落在节点或其出口路径；如果多个节点都失败，检查 DNS、本机流量接管和网络路径。
- 保持客户端设置不变，将设备切换到手机热点或另一条可信网络再测试。网络变化后结果不同，说明原网络路径值得继续调查，但不能单凭这一步断定是运营商限制。
- 最后检查浏览器代理设置、客户端系统代理开关和 TUN 状态。需要启用 TUN 时，先确认客户端和内核支持，并留意系统权限提示、虚拟网卡及路由日志。
如果系统安装了 curl，可以在终端通过已确认的 HTTP 代理端口测试 HTTPS 连接。它验证的是从本机到目标站点的一次 HTTP 请求，不等同于完整浏览器登录或账号可用性测试。
curl -I --proxy http://127.0.0.1:7890 \
--connect-timeout 10 --max-time 20 \
https://chatgpt.com/若本地端口并非 7890，请替换为客户端实际显示的端口。收到 HTTP 状态码只能说明请求得到了某种 HTTP 响应；重定向、访问拒绝或验证页面都不代表登录流程正常。若出现“无法连接代理”，先核对端口、代理类型和内核监听状态；若连接成功但浏览器仍超时，则继续检查浏览器代理、规则命中与页面中其他请求。
检查 DNS、系统代理与 TUN 接管
DNS 解析异常可能让页面连接到错误地址、等待解析超时，或出现浏览器能打开部分页面但登录资源失败的情况。mihomo 等内核可以使用不同 DNS 模式，客户端也可能通过配置覆写 DNS。若开启 Fake-IP，客户端会给域名分配映射地址，再由内核关联域名和连接；此时不要随意清空系统 DNS、同时更改多个 DNS 字段或把其他版本的配置片段直接粘贴进来。
先比较同一网络下的表现：重新加载配置后是否恢复、换用另一网络是否恢复、连接列表中是否能看到实际域名。若只在某个 DNS 模式下异常，检查配置语法、上游 DNS 可达性、日志中的解析错误，以及客户端对 DNS 设置的覆写。更换上游解析器并非通用修复，某些网络中的 DNS 请求也可能被系统或 TUN 另行处理。
系统代理与 TUN 的覆盖范围不同。系统代理通常只对读取系统代理设置的应用生效；命令行工具、部分桌面应用或独立网络组件可能忽略它。TUN 通过虚拟接口和路由捕获更多系统流量，但会增加权限、路由、DNS 和防火墙等变量。浏览器不走代理时，可先检查系统代理开关和浏览器自己的代理设置；只有确认应用不读取系统代理时，才考虑测试 TUN。
- 启用 TUN 前，确认客户端使用的内核支持该功能，并按系统提示授予必要权限。
- 检查 TUN 是否成功创建虚拟接口、路由是否生效，以及日志中是否有权限或设备初始化错误。
- 一次只启用或关闭一个流量接管方式；系统代理和 TUN 同时改变会让结果难以解释。
- 测试后恢复原有设置，并确认局域网、公司 VPN 或其他网络软件没有与新增路由冲突。
如果只有一个应用无法连接，而浏览器和其他代理应用正常，应优先查该应用是否使用独立网络栈、是否配置了自己的代理，或是否受到本机防火墙策略影响。不要仅因某个应用失败就把所有流量永久切换到 TUN。
根据错误信息收尾：配置、网络还是线路
查看客户端日志时，记录失败发生的准确时间，并关注该时刻附近的 DNS、连接建立、TLS 和超时信息。诸如 connection refused 常提示本地端口未监听或目标连接被拒绝；i/o timeout 表示等待超时，但不能单独指出是哪一段网络造成；DNS 相关报错则应先核对解析流程。不同内核的日志文字可能不同，结合连接列表和实际测试结果判断。
- 全局模式可用，规则模式不可用：复查规则命中、规则集状态和目标策略组，保持其他设置不变。
- 更换节点后恢复：保留失败节点名称、测试时间和对应日志，问题可能与该节点负载、出口或目标路径有关。
- 换网络后恢复：对照原网络的路由器、DNS、安全软件和网络限制；只凭一次测试不要直接认定某一方限速。
- 所有节点与网络都失败：核对配置是否加载成功、内核版本是否支持相关功能，以及服务端或目标服务是否正在发生异常。
- 网页能打开但登录或请求失败：记录失败时连接列表中的域名和策略，检查认证流程及浏览器扩展，不要把问题简单归因于首页规则。
最后恢复正常使用所需的规则模式、节点选择和 TUN 状态，删除临时测试文件，保留一份不含秘密信息的排查记录。向客户端或网络服务提供方求助时，提供客户端与内核版本、系统版本、复现时间、连接错误类型和已完成的对照测试即可；订阅地址、令牌、节点密码与个人账号信息应先遮盖。