先确认是 ChatGPT 问题，还是代理链路问题
ChatGPT 在 Clash 下打不开、页面一直转圈或请求频繁超时，不能一开始就认定是节点失效。一次完整访问至少经过客户端运行、配置载入、策略组选择、代理接管、DNS 解析和目标站点连接六个环节。任意环节出错，浏览器最后都可能只显示“无法连接”“网络错误”或空白页面。
先观察故障范围：如果所有网站都打不开，应优先检查 Clash 是否启动、系统代理是否开启以及本地端口是否正确；如果普通网站可以访问，只有 ChatGPT、登录页面或接口请求失败，重点应转向规则匹配、节点出口、DNS 和浏览器缓存。不要反复点击刷新，也不要在没有记录当前设置的情况下同时修改模式、端口和 DNS，否则很难判断哪一步真正解决了问题。
| 现象 | 优先检查 | 常见原因 |
|---|---|---|
| 所有外部网站都打不开 | 客户端状态、系统代理、监听端口 | 内核未启动、端口填错或系统代理未生效 |
| 普通网站正常，ChatGPT 超时 | 策略组、规则命中和节点出口 | ChatGPT 流量走了直连或当前节点质量不佳 |
| 登录页能打开，聊天发送失败 | 相关域名、WebSocket 和浏览器扩展 | 接口域名未代理、连接被扩展拦截或长连接不稳定 |
| 网页能开但桌面应用失败 | 应用是否读取系统代理，是否需要 TUN | 应用不遵循系统代理，或虚拟网卡路由未接管 |
| 偶尔成功，刷新后又失败 | 节点稳定性、DNS、IPv6 和自动策略组 | 出口抖动、解析结果变化或自动测速选中不稳定节点 |
打开 Clash 的连接日志或请求日志，然后在浏览器访问 ChatGPT。正常情况下，应能看到相关域名的请求记录，并且请求最终被转发到某个代理策略组。如果日志完全没有新记录，说明流量没有进入 Clash；如果记录显示 DIRECT，说明规则把它判定为直连；如果显示代理节点后又出现 timeout、connection reset 或 dial failed，则应测试节点本身。
切换代理模式并固定一个可用节点
首次排查时建议使用“规则”模式，而不是直接使用“全局”或“直连”模式。规则模式可以保留国内或局域网流量的原有路径，同时让匹配到代理规则的请求进入策略组。全局模式适合短时间验证，但它会改变更多流量，可能引入额外的 DNS、登录和访问变量。
进入客户端的「代理」页面，找到主策略组或负责外部网站的策略组。不要先使用 url-test、fallback 或负载均衡组作为唯一测试对象，而是进入其中的节点列表，手动固定一个节点。自动测速的延迟通常只代表测试地址的响应时间，不等于 ChatGPT 页面、接口和长连接的实际表现。
| 模式或策略 | 排查用途 | 需要注意 |
|---|---|---|
| 规则 | 确认指定域名能按规则进入代理 | 必须检查具体规则命中结果 |
| 全局 | 快速判断是否为分流规则问题 | 所有流量可能经过代理，验证后应恢复合适模式 |
| 直连 | 仅用于对比本地网络行为 | 不能用来验证代理是否正常 |
| 手动选择节点 | 减少自动测速带来的变量 | 应连续测试数次，不要只看一次延迟 |
| 自动测速 | 适合日常自动选择线路 | 测试 URL 与实际目标可能使用不同路径 |
固定节点后，先打开一个确认可以通过代理访问的 HTTPS 网站，再访问 ChatGPT。随后更换两个不同地区或不同线路的节点进行对比。如果只有某一个节点失败，问题大概率在节点出口、上游线路、连接数限制或目标站点对该出口的限制；如果所有节点都失败，则应继续检查规则和 DNS，而不是不停更换同一订阅中的节点。
节点名称中的“低延迟”“专线”或地区标签只能作为筛选参考。ChatGPT 页面不仅需要加载静态资源，还可能持续建立接口请求或长连接，因此稳定的丢包率、TLS 建连时间和持续传输能力，往往比测速页面显示的几十毫秒延迟更重要。
动手执行一次完整的五分钟测试
下面的流程适合 Windows、macOS 和 Linux 上的大多数 Clash Verge、Clash Verge Rev 或其他 Mihomo 图形客户端。每完成一步就测试一次，不要同时打开多个客户端。若 Clash for Windows、ClashX 或 Clash for Android 的菜单名称不同，请寻找含义对应的“配置、代理、系统代理、日志和 TUN”入口。
- 完全退出其他代理软件，只保留一个 Clash 客户端运行。检查当前 Profile 已成功载入，内核状态显示正在运行。
- 进入「配置」或「订阅」页面，手动更新一次配置。确认更新时间改变，并检查节点列表不是空白或全部显示错误。
- 进入「设置」→「端口」或「Mihomo 配置」，记下
mixed-port的实际值。常见值为7890，但不能假定所有客户端都使用这个端口。 - 打开「设置」→「系统代理」，关闭后等待几秒，再重新开启。这样可以重新写入系统代理地址，避免系统仍保留旧客户端的端口。
- 把运行模式设为「规则」，在主策略组中手动选择一个节点。暂时不要使用自动选择组，也不要同时启用多个代理客户端。
- 打开日志页面，在新的浏览器隐私窗口中访问 ChatGPT。观察请求是
PROXY、具体策略组、DIRECT还是错误状态。 - 如果规则模式失败，短时间切换到「全局」模式再次测试。全局模式成功而规则模式失败，说明重点应放在规则集、规则顺序或策略组映射。
- 如果网页仍然超时，更换一个节点，并分别测试首页加载、登录和发送一条短消息。不要只以首页能否打开作为最终结论。
mixed-port: 7890
mode: rule
log-level: info这段配置只用于说明常见字段，不是完整可直接运行的订阅。修改 YAML 前应先复制原文件，并通过客户端的配置校验功能检查缩进和字段格式。尤其不要把 external-controller 的端口误填到浏览器代理设置中；控制端口用于管理 API，不承载普通网页代理流量。
检查规则是否把 ChatGPT 请求送进代理
ChatGPT 的页面访问不是只有一个域名。网页、登录、静态资源、接口和身份验证可能分别请求不同的主机名；具体域名也可能随产品版本和网络环境变化。因此不要只凭一个页面地址判断规则是否完整，应该以日志中实际出现的域名为准。
在日志中找到失败请求，重点看请求域名右侧的策略结果。如果目标域名被标记为 DIRECT，而本地网络无法直连，就需要检查规则集是否已更新、规则顺序是否正确，以及目标域名是否被某条更早的直连规则匹配。Clash 规则通常按从上到下的顺序处理，前面已经命中的规则不会再继续寻找后面的代理规则。
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- GEOIP,private,DIRECT
- MATCH,DIRECT上面的片段仅展示规则从上到下匹配的形式。实际使用时，应使用订阅提供方或自己的合法配置中已经定义的策略组名称，不要直接把不存在的 PROXY 组写进配置。若策略组名称包含中文、空格或特殊符号，规则中的名称必须与组名完全一致。
用全局模式区分规则问题
将模式临时设为全局后，如果 ChatGPT 立刻恢复，而规则模式仍然超时，可以回到日志页面逐条核对。常见错误包括规则集下载失败、规则提供方地址过期、目标域名被自定义规则提前匹配为直连，以及主策略组实际指向了一个空组。更新规则集后，通常还需要重新载入配置或重启内核，旧规则不会因为文件内容改变而自动全部刷新。
如果规则显示已经进入代理，但仍然连接失败，则规则本身可能没有问题。继续更换节点并观察失败类型：connect timeout 多与网络路径或节点不可达有关，tls handshake timeout 常见于 TLS 建连慢或线路丢包，connection reset 则可能是中间设备、出口线路或服务端主动断开。错误信息只能帮助缩小范围，不能单独证明某一个原因。
处理 DNS、TUN 与 IPv6 带来的额外变量
DNS 设置会影响“域名解析到哪里”，代理设置则决定“连接通过哪条路径出去”。如果 DNS 请求在本地网络完成，而目标域名解析结果受到污染、劫持或区域性差异影响，Clash 可能拿到不可用地址，表现为页面加载很慢或连接超时。此时应在日志中区分 DNS 错误和代理连接错误，不要只盲目更换节点。
使用 Mihomo 配置时，常见 DNS 相关字段包括 dns.enable、nameserver、fallback、enhanced-mode 和 fake-ip-range。不同订阅的 DNS 设计可能完全不同，修改前应先确认客户端是否支持对应字段。若启用了 Fake-IP，部分应用、局域网域名或安全软件可能表现异常；若使用 Redir-Host，也要注意本地 DNS 解析结果是否可靠。
| 设置项 | 适合排查的情况 | 风险或注意点 |
|---|---|---|
| 系统代理 | 浏览器和遵循系统代理的桌面程序 | 不一定接管不读取系统设置的应用 |
| TUN 模式 | 需要接管更多 TCP、UDP 流量的应用 | 通常需要管理员权限，并可能与其他虚拟网卡冲突 |
| Fake-IP | 按域名进行透明接管和分流 | 部分局域网应用、杀毒软件或固定 IP 应用需要额外处理 |
| IPv6 | 用于判断是否存在 IPv4、IPv6 路径差异 | 系统可能优先使用一条质量较差的 IPv6 路径 |
如果浏览器在系统代理下可以访问，但 ChatGPT 桌面应用或其他不遵循系统代理的程序失败，可以在确认节点可用后再启用 TUN。启用前关闭其他 VPN、虚拟网卡工具和网络加速器，检查系统是否允许 Clash 创建虚拟接口。TUN 只负责接管流量，不会自动修复失效节点、错误规则或不兼容的 DNS 配置。
IPv6 也值得单独验证。部分网络会优先返回 IPv6 地址，但代理链路对 IPv6 支持不完整，导致浏览器等待较长时间后才回退到 IPv4。可以暂时关闭客户端的 IPv6 相关选项或系统 IPv6 进行对比测试；如果关闭后明显恢复，再根据实际网络和客户端支持情况决定是否长期调整，而不是直接修改所有 DNS 字段。
清理浏览器状态并确认问题已经解决
代理配置修复后，浏览器仍可能保留失败的连接、Service Worker、旧 DNS 缓存或扩展注入结果。建议先使用隐私窗口测试，再暂时禁用代理切换、广告拦截、脚本管理和安全防护类扩展。如果隐私窗口正常，而普通窗口失败，优先清理目标站点的 Cookie、站点数据和缓存，不要继续修改 Clash 配置。
登录页面和聊天页面的测试结果也可能不同。登录成功只能说明部分页面请求完成，不能证明接口请求、持续连接和消息发送全部正常。恢复后至少进行三项验证：刷新页面后仍能加载；切换一次对话并发送短消息；保持连接数分钟，确认不会频繁出现网络错误。随后更换一次节点或等待自动策略组完成一轮选择，观察故障是否会复现。
- 确认只有一个 Clash 或 Mihomo 客户端在监听代理端口。
- 确认系统代理地址和端口与客户端当前监听值一致。
- 确认运行模式不是误设为“直连”，主策略组也不是空组。
- 在日志中确认实际域名进入了代理策略，而不是被提前判定为
DIRECT。 - 至少用两个节点对比，区分节点出口问题和本地规则问题。
- 启用 TUN 后重新检查权限、虚拟网卡和其他 VPN 的冲突。
- 修改 DNS、规则或 YAML 后重新载入配置，并确认内核没有校验错误。
如果完成上述步骤后仍然无法访问，可以保存故障发生时间、使用的节点、运行模式、日志中的错误类型和是否开启 TUN，再向订阅服务提供方或客户端项目反馈。清晰的最小复现信息比“ChatGPT 打不开”更容易定位问题：例如“规则模式下某节点对接口请求出现 TLS 超时，全局模式同样失败，另外两个节点正常”。这样可以快速判断是配置、客户端、节点线路还是目标服务端状态。