iPhone 上已经开启 Shadowrocket（小火箭），ChatGPT 仍然无法打开或登录，不一定代表代理节点失效。请求可能被规则分到 DIRECT，域名也可能解析异常；即使代理连接成功，目标服务仍可能因出口网络、服务可用性或账户状态而拒绝请求。排查时先区分“整个网络不通”和“只有 ChatGPT 不通”，再一次只调整一个条件，避免同时改规则、DNS 和节点后无法定位原因。
本文适用于 iPhone 已配置 Shadowrocket、但访问 ChatGPT 失败的用户。依次检查基础网络、Global Routing、请求命中的规则、DNS 结果和节点连接，再通过固定网络与目标页面复测判断故障范围。请使用自己已有的服务商配置；订阅链接请从你的服务商处获取。
一、先区分故障范围：只有 ChatGPT 失败，还是全部代理都异常
先不要删除配置或连续切换多个节点。记录当前网络类型、Home 中选中的连接条目，以及 Home → Global Routing 当前显示的模式。关闭 Shadowrocket 后，确认 iPhone 的 Wi-Fi 或蜂窝网络本身可用；如果公共 Wi-Fi 需要登录认证，先完成认证再测试。随后开启连接，访问一个平时可用的网站，再尝试打开 ChatGPT。两类结果的处理方向不同：所有网站都打不开，应先检查基础网络和代理连接；只有 ChatGPT 失败，则优先检查相关请求的路由、解析和目标服务响应。
VPN 状态显示已连接，只能说明系统隧道已建立，不能证明 ChatGPT 的每个请求都走了预期代理，也不能证明远端连接一定成功。ChatGPT 页面可能请求多个域名：网页主体、登录验证、静态资源和接口请求未必使用同一个域名。只测试首页能否加载，可能漏掉登录停滞、对话发送失败或页面资源不完整等情况。
| 现象 | 优先怀疑 | 下一步 |
|---|---|---|
| 所有网站都打不开 | 基础网络、所选条目或远端连接 | 先验证网络，再检查连接测试与节点参数 |
| 普通网站可用，ChatGPT 不可用 | ChatGPT 请求的规则、DNS 或目标服务响应 | 查看相关请求记录及其策略结果 |
| 页面能开，登录或对话卡住 | 部分接口请求、登录验证或资源域名走了不同路径 | 重现问题时检查新增请求，勿只看首页请求 |
| 仅在一个 Wi-Fi 下失败 | 该网络的 DNS、认证或连接限制 | 保持条目不变，改用蜂窝网络做一次对照 |
二、检查 Global Routing 与 ChatGPT 请求实际命中的规则
在 Home → Global Routing 查看当前模式。若使用 Config，请求会依照当前配置中的规则处理；若是 Direct，请求可能绕过代理；若是 Proxy，则用于临时验证全局代理路径。请先记下原设置。可以短暂切换到 Proxy 进行对照：如果 ChatGPT 随即恢复，而原来的 Config 模式下失败，问题更可能在规则匹配或当前配置，而不是单纯的系统隧道状态。测试完成后恢复原模式，不要把临时对照当作永久修复。
请求记录的入口和呈现方式可能因应用界面而异。重现故障时打开 Shadowrocket 的请求记录或日志视图，留意访问 ChatGPT 页面、登录以及发送消息的时间点。检查相关域名对应的策略结果是 PROXY、DIRECT 还是被拒绝；同时查看是否出现解析失败、连接超时或 TLS 错误。不要只凭域名名称猜测路由结果，也不要把完整订阅链接、密码、密钥或带个人信息的日志截图公开。
路由状态
- Global Routing
- 记录当前是 Config、Proxy、Direct 还是 Scene。
- Config
- 确认选中的配置文件与需要检查的规则一致。
- 策略结果
- 查看请求实际命中 PROXY、DIRECT 或其他策略。
- 对照方法
- 临时使用 Proxy 后复测，再恢复原模式。
只有实际请求记录才能帮助判断该请求走了哪条路径。
规则与域名
- DOMAIN
- 匹配一个完整域名，可用于精确例外。
- DOMAIN-SUFFIX
- 匹配指定域名及其子域名，作用范围更广。
- 规则顺序
- 按配置从上到下检查，先命中的规则先处理。
- FINAL
- 处理没有命中前序规则的请求。
不要只添加一个主页域名；以请求记录中实际出现的域名为依据。
在 Config 中核对规则时，先确认当前使用的配置确实包含你正在编辑的规则。若发现 ChatGPT 相关请求命中 DIRECT，再检查是哪条规则先匹配；较宽泛的 DOMAIN-SUFFIX 或其他规则可能覆盖预期行为。若要增加例外，应只针对日志中确认需要处理的域名，并放在会覆盖它的宽范围规则之前。不要将不确定的域名一概加入代理，也不要随意删掉 FINAL 或整份规则列表。
三、按步骤复测：先固定变量，再检查 DNS 与连接
完成路由检查后，按以下顺序做一次小范围对照。每一步都保留原配置；一次只改一个项目，并记录修改前后的页面表现。这样可以区分规则问题、DNS 问题与代理连接问题，而不是靠不断换设置碰运气。
-
确认基础网络
关闭 Shadowrocket 连接，确认当前 Wi-Fi 或蜂窝网络可正常访问其他已知可用的网站。公共 Wi-Fi 先完成认证；若基础网络本身不可用，暂不修改规则或 DNS。
-
记录当前设置
回到 Home，记下选中的条目和
Home → Global Routing模式。确认配置来源及条目仍有效；需要更新订阅时，使用自己的订阅链接，并从你的服务商处获取。 -
做路由对照
开启连接后，短暂将 Global Routing 设为
Proxy，再打开 ChatGPT 并尝试完成同一项操作。记录页面是否恢复、登录是否完成、对话是否能发送；随后恢复原来的路由模式。 -
核对请求与规则
重现故障时查看请求记录，找出失败时出现的相关域名、策略和错误。若在
Config下命中DIRECT或拒绝策略，先确认具体规则及其顺序，再只调整有记录支持的域名规则。 -
检查解析与网络
若记录显示 DNS 解析失败，先核对当前配置与 Shadowrocket 的 DNS 设置，避免同时启用多个来源不明的解析设置。保持所选条目不变，分别在 Wi-Fi 与蜂窝网络复测；仅一个网络失败时，优先处理该网络的连接或 DNS 条件。
-
验证恢复并回滚
恢复日常使用的 Global Routing 模式，再依次测试页面加载、登录和发送消息。若调整规则或 DNS 后没有改善，撤销该项改动并记录结果，不要叠加多个未经验证的设置。
DNS 解析把域名转换为连接所需的地址。解析结果异常可能造成页面无法建立连接，但更换 DNS 并不能修复所有问题：如果请求已经成功解析，却在连接阶段超时，或者服务器返回拒绝响应，就应继续检查网络路径、节点状态或目标服务本身。不要把解析器地址、域名规则和节点服务器地址混为一谈，也不要把网上找到的 DNS 数值直接当成通用修复方案。
报错示例：DNS lookup failed
原因与解法：目标域名未能解析，可能与当前网络或 DNS 设置有关。先确认基础网络可用，再固定条目分别测试 Wi-Fi 与蜂窝网络；只在一个网络失败时，优先检查该网络的 DNS 条件。
报错示例：Connection timed out
原因与解法：连接未在等待时间内完成，不能据此直接认定规则或密码错误。检查请求是否走预期策略，并在不改其他参数的情况下对照另一种网络；若所有网络都失败，再向自己的服务商核对连接状态。
报错示例：TLS handshake failed
原因与解法：TLS 握手阶段未能完成，可能涉及目标服务、系统时间或连接路径。确认 iPhone 日期与时间设置正确，查看是否只有该服务失败；不要把关闭证书验证作为常规处理方式。
四、根据复测结果判断：规则、节点还是服务响应
当其他网站都能正常使用，只有 ChatGPT 失败时，按请求记录定位比反复换节点更有效。若 Config 下显示相关请求走 DIRECT，但临时 Proxy 对照成功，应回到规则列表检查命中顺序。若两种模式均出现解析错误，先核对 DNS 与当前网络；若请求走了代理但出现超时，可保持配置不变，用同一网络与另一条自己已有的连接条目做对照，并把时间、错误阶段及脱敏后的结果反馈给服务商。
若页面能打开但登录或发送消息失败，查看这些操作发生时新增的请求记录。不同功能可能调用不同域名，主页成功并不等于所有接口都可达。不要把单个静态资源失败直接解释为整个代理无效，也不要通过扩大规则范围掩盖具体问题。若请求已成功发出但目标服务返回限制或拒绝提示，应检查服务当前可用性、账户状态和适用条款；Shadowrocket 的路由设置不能保证目标服务接受某个网络出口。
开启 Shadowrocket 后，ChatGPT 首页还是打不开怎么办？
先确认 Home 中有已选中的有效条目，再检查 Global Routing。临时切到 Proxy 做一次对照；若其他网站也失败，先检查基础网络与连接状态，若只有 ChatGPT 失败，再查请求记录中的策略和错误。
切到 Proxy 后能打开，Config 下却不行？
这提示问题可能与当前配置的规则或命中顺序有关。回到 Config，确认正在使用的配置文件，再从请求记录找出 ChatGPT 相关请求实际命中的规则；修正已确认的规则后恢复日常模式复测。
要不要把所有 OpenAI 相关域名都加到代理规则？
不建议仅凭名称批量添加。先在请求记录中确认失败操作涉及哪些域名及其策略，再为确有需要的域名设置有限范围的规则，并把更具体的例外放在覆盖范围更大的规则之前。
换 DNS 或节点后还是无法登录，怎么办？
先回滚最近一次无效改动，检查同一请求是否仍能解析、是否建立连接，以及目标服务返回什么结果。若问题跨 Wi-Fi 与蜂窝网络复现，可整理脱敏后的错误阶段和发生时间，联系自己的服务商核对连接状态；不要发送密码、密钥或完整订阅链接。
排查完成后保留一份简短记录：网络类型、Global Routing 模式、失败请求的策略与错误，以及哪一项改动改变了结果。连接恢复后回到原定日常路由设置，并再次测试页面、登录和对话发送。这样既能确认修复确实生效，也能避免临时测试设置残留影响其他流量。