先判断：是节点问题、规则问题还是网页问题

第一步不要立即修改 DNS 或重写整份配置。先记录具体表现。若 Clash 面板中的请求记录完全没有变化，通常是浏览器没有使用系统代理、系统代理开关未生效，或者浏览器启用了独立代理设置。若请求已经出现在面板里，但状态显示超时或连接被重置，重点应放在节点、远端出口和 TLS 连接。若请求显示成功而网页仍然空白，则要检查浏览器缓存、扩展、脚本加载和登录状态。

测试时建议使用无痕窗口，并暂时关闭广告拦截、隐私防护、脚本管理和代理切换类扩展。这样可以避免扩展修改请求头、阻止第三方资源或覆盖系统代理，导致排查结果失真。不要同时运行多个 Clash 类客户端、VPN 或系统级网络过滤器，否则请求记录和路由结果很难判断。

确认节点、配置和本地代理端口有效

打开 Clash 客户端的配置页面，确认当前启用的配置文件确实是刚更新的那一份。很多“节点明明可用但 ChatGPT 打不开”的案例，实际使用的是旧配置：订阅更新成功，但客户端仍然选中了旧配置；或者节点列表刷新了，却没有切换到新节点组。先查看当前代理组名称、当前选中的节点和核心运行状态，再开始网页测试。

1. 确认订阅没有过期、流量没有耗尽，节点列表能够正常刷新。
2. 从代理组中选择一个近期测速正常的节点，不要使用延迟显示为 N/A、超时或明显失效的节点。
3. 确认 Clash 核心处于运行状态，HTTP、混合端口或 SOCKS5 端口没有被其他程序占用。
4. 开启系统代理，然后重新打开浏览器无痕窗口访问 ChatGPT。
5. 回到 Clash 的连接记录，搜索 chatgpt、openai 或相关域名，确认请求确实进入了 Clash。

如果所有节点测速都失败，先不要把问题归结为 ChatGPT。断开 Clash 后访问普通网站，确认本机宽带或 Wi-Fi 正常；再检查订阅链接是否还能获取配置。若只有某个节点失败，直接换节点更有效。若全部节点都失败，可能是订阅失效、服务商线路故障、本机时间错误，或者局域网封锁了代理服务器的连接。

本地监听端口也需要核对。系统代理设置里的地址通常应指向 127.0.0.1 或 localhost，端口则必须与 Clash 当前的 HTTP 或 Mixed Port 一致。端口填错时，浏览器可能提示代理服务器拒绝连接；而 Clash 面板不会出现对应的网页请求。

Windows 命令提示符:
netstat -ano | findstr "7890"

macOS / Linux:
lsof -i :7890

上面的端口只是示例，实际端口以客户端设置为准。若端口被其他进程占用，可以在 Clash 设置中换成空闲端口，并重新开启系统代理。不要只修改 Clash 监听端口而忘记同步系统代理，否则界面显示“已开启”，浏览器仍会连接旧端口。

用全局模式验证规则是否误判

规则模式下，Clash 会按 rules 从上到下匹配请求，命中第一条后停止。如果 ChatGPT 相关域名被某条宽泛的域名规则、地区规则或订阅规则集提前匹配到 DIRECT，浏览器就可能出现部分页面能开、登录请求超时的情况。规则模式本身没有问题，关键是要查看实际命中结果，而不是凭感觉修改规则。

在 Clash 的连接记录中找到失败请求，查看它对应的域名、策略组和最终动作。若显示为 DIRECT，而你希望该请求经过代理，可以检查是否存在类似下面的规则：

rules:
  - DOMAIN-SUFFIX,chatgpt.com,DIRECT
  - DOMAIN-SUFFIX,openai.com,DIRECT
  - MATCH,Proxy

这只是说明规则优先级的示例，不代表应当照抄固定的策略组名称。实际配置中的代理组可能叫“Proxy”“节点选择”或其他名称，第三列必须填写当前配置中真实存在的策略组。修改前先备份原配置，并确认订阅更新不会覆盖手工修改。

排查时可以暂时把模式切换到全局模式，再选择一个确定可用的节点。如果全局模式下 ChatGPT 能打开，而规则模式下打不开，基本可以把范围缩小到规则命中、规则集更新或 DNS 分流。全局模式仍然失败，则优先回到节点、端口、DNS 和浏览器环境检查。测试完成后应切回规则模式，避免所有本地网站和内网请求长期绕行代理。

处理 DNS、IPv6 与连接握手异常

DNS 异常通常有两种表现：域名完全无法解析，或者解析结果可以返回但连接被送到不可用的地址。ChatGPT 页面涉及多个域名，主站能打开并不代表登录域名和静态资源域名都解析正常。若 Clash 使用 fake-ip 模式，DNS 配置、增强模式和 TUN 设置之间还必须保持一致；如果只修改了其中一项，可能出现浏览器能访问部分站点、特定域名持续超时的情况。

先在客户端查看 DNS 设置是否启用，确认 nameserver 至少有可用地址，不要把不可访问的内网 DNS、已经失效的服务器或只支持 IPv6 的地址单独作为唯一解析源。修改 DNS 后清理系统和浏览器缓存，再完全退出并重新启动 Clash 核心。若启用了 TUN 的 DNS 劫持，需要确认没有同时运行另一个 VPN 或 DNS 过滤器争抢 53 端口。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

以上仅展示字段关系，具体 DNS 地址应结合所在网络、客户端支持情况和订阅配置决定，不建议机械覆盖服务商提供的完整 DNS 段。若配置使用了 fake-ip-filter，不要随意把 ChatGPT 相关域名加入过滤列表；改动后应观察连接记录和解析结果是否变化。

IPv6 也是常见干扰源。部分网络会优先返回 IPv6 地址，但本地 IPv6 出口并不稳定，浏览器会等待 IPv6 连接超时后才回退 IPv4，表现为页面加载极慢。可以临时关闭系统 IPv6、关闭客户端的 IPv6 解析或在同一网络下使用只返回 IPv4 的测试环境进行对比。若关闭 IPv6 后恢复，应进一步检查路由器、运营商 IPv6 连接和 Clash 核心版本，而不是长期忽略网络配置。

按顺序执行一次完整修复流程

下面的流程用于把变量逐项归零，适合已经尝试多种设置、但仍无法确定故障点的情况。每完成一步都重新测试一次，不要一次性修改节点、模式、DNS 和浏览器设置，否则无法知道哪项改变产生了效果。

1. 完全退出其他代理软件和 VPN，只保留一个 Clash 客户端运行，避免端口、路由和 DNS 相互覆盖。
2. 更新订阅并确认当前配置生效，选择一个测速正常的节点。若订阅无法更新，先处理订阅链接或服务商问题。
3. 确认 Clash 的核心已启动，记录 HTTP 或 Mixed Port，在系统代理中设置为同一个本地地址和端口。
4. 暂时关闭浏览器扩展，使用无痕窗口访问 https://chatgpt.com，同时观察 Clash 连接记录。
5. 在规则模式下检查失败请求的策略。若被判定为 DIRECT，临时切换全局模式进行对照，不要立即删除整份规则。
6. 全局模式仍然失败时，更换一个节点，并检查系统时间是否自动同步。时间偏差可能影响 HTTPS 证书校验和登录会话。
7. 仍然超时时，再处理 DNS 与 IPv6：重启 Clash 核心、清理 DNS 缓存，并分别测试启用或关闭 IPv6 的差异。
8. 恢复规则模式，清除 ChatGPT 站点 Cookie 后重新登录。清理范围尽量限定在相关站点，不必删除整个浏览器的所有数据。

Windows 可以在命令提示符中执行 ipconfig /flushdns 清理系统 DNS 缓存；macOS 可使用系统网络设置或重启网络接口完成刷新。不同版本 macOS 的刷新命令可能不同，优先使用系统设置和重启客户端的方式，避免复制不适用的命令。浏览器缓存清理完成后，必须关闭旧标签页再重新打开，否则旧页面仍可能继续使用失效的连接。

登录失败、页面空白与加载缓慢的专项处理

登录流程通常不只访问主站域名。打开首页后点击登录，浏览器可能跳转到认证相关域名，再返回 ChatGPT 页面。如果主站走代理而认证域名走直连，或者中途切换了节点，登录会话就可能失效，表现为反复跳转、按钮无响应或提示网络错误。因此登录排查期间不要频繁切换节点，最好从打开登录页到回到主页面都保持同一个代理出口。

• 登录按钮无反应：检查脚本拦截扩展、浏览器隐私防护和第三方 Cookie 设置，先用无痕窗口或另一款浏览器对比。
• 登录循环：清理相关站点 Cookie，确认系统时间准确，并保持认证域名与主站使用同一代理策略。
• 页面空白：打开浏览器开发者工具查看 Network 请求是否大量失败，再在 Clash 连接记录中核对失败域名和策略。
• 文字能显示但资源很慢：查看是否只有静态资源或接口请求超时，换用延迟更低、丢包更少的节点，不要仅以测速延迟一个数字判断质量。
• 对话发送失败：确认当前节点没有频繁重连，检查浏览器是否设置了独立代理，并观察长连接请求是否被网络设备中断。

如果同一节点在多个浏览器中都无法使用，而其他普通网站正常，可能是该出口线路或目标服务之间的连接质量问题。更换节点并保持配置不变是最有效的对照测试。若所有节点都出现同样错误，记录错误时间、请求域名、Clash 日志中的错误类型，再向订阅服务商反馈；只提供“打不开”通常不足以定位线路故障。