如果 Shadowrocket 显示 Connected，但 ChatGPT App 或网页版仍无法使用，先不要急着改 DNS 或替换整份配置。本文按 iPhone 系统 VPN 状态、Home → Global Routing、域名规则、DNS 与 Data 中的请求记录逐项排查，帮助区分直连误判、解析失败、连接错误和服务端限制。适用于已经有自己的连接配置、需要检查 ChatGPT 访问问题的用户。
一、先分清连接状态与 ChatGPT 访问结果
Home 显示 Connected，表示 Shadowrocket 已建立系统 VPN 连接；它不能单独证明 ChatGPT 的每个请求都经过了预期路径，也不代表目标服务已经接受请求。浏览器或 App 最终能否正常工作，还受到 Global Routing、规则命中、DNS 解析、网络连接和服务端响应等环节影响。
先记录一个明确的复现方式，例如“ChatGPT App 一直转圈”或“Safari 打开网页版后提示连接失败”，并记下发生时间。测试时尽量保持同一 Wi-Fi 或蜂窝网络、同一服务器条目和同一访问入口。不要同时切换网络、改 DNS、换规则和更换服务器，否则即使结果变化，也难以判断是哪项设置起了作用。
如果 Home 显示 Not Connected，先处理隧道未启动的问题，不要跳到 DNS 规则排查。如果显示 Connected，则继续检查流量实际采用的路由。iPhone 状态栏中的 VPN 标记可以作为系统连接状态的参考，但同样不能代替对 ChatGPT 请求路径和页面响应的检查。
另一个重要区分是“网络请求失败”和“服务拒绝请求”。页面能显示登录提示、错误代码或明确的服务端消息，说明至少有请求到达某个服务端；这与 DNS 解析失败或连接超时并非一回事。记录完整错误文字有助于确定下一步方向，但分享日志前应遮盖账号、令牌、订阅地址和其他个人信息。
二、检查 Global Routing 与域名规则
进入 Home，确认当前所选服务器条目与连接状态，再查看 Home → Global Routing。若选中了 Direct，请求会按直连方式处理；这时即使顶部已经显示 Connected，ChatGPT 流量也可能没有按预期走代理。若使用 Config，则需要核对当前配置文件中的规则和命中结果；若使用 Scene，还要确认当前场景实际采用的路由方式。
按当前配置中的规则处理请求。排查日常分流问题时，应检查 ChatGPT 相关请求实际命中了哪条规则。
适合：日常使用与定位规则误判
可作为短时对照，观察按代理方式处理时同一入口是否有不同表现。对照完成后恢复原有设置。
适合：临时判断问题是否与 Config 规则有关
按直连方式处理流量。如果当前目标是通过自己的代理配置访问，Direct 并不能验证代理路径是否正常。
适合：确认直连时的基线表现
不要只看配置里有没有写一条看起来相关的规则。请求可能涉及多个主机名，登录、页面、接口和静态资源也未必使用同一个域名。ChatGPT 服务端使用的域名与请求可能随产品变化，单凭一份静态域名清单不能保证覆盖全部流量。更可靠的做法是观察 Data 中实际出现的请求记录，再检查它们对应的规则与策略。
如果正在使用 Config，先确认当前选用的配置确实是你要检查的那份。检查规则顺序时，留意较宽泛的 DOMAIN-KEYWORD、GEOIP 或 FINAL 是否先于预期规则命中。规则按配置顺序匹配；若请求已被前面的规则处理，后面新增的例外规则可能不会生效。修改前保存原配置或复制一份用于测试，避免一次重排多条规则。
判断：Proxy 对照成功，优先查 Config 规则
在网络、服务器条目和访问入口都不变的情况下，若临时使用 Proxy 时 ChatGPT 能打开、恢复 Config 后又失败，优先检查实际请求命中的规则与策略；不要据此直接认定 DNS 一定有问题。
三、按顺序复测，并查看请求记录
以下步骤用于缩小问题范围。操作时记下每一步的原状态与结果；如果对照后没有改善，及时恢复刚才临时改动。排查需要以你已有的配置为前提，不要把规则示例或未经核实的地址直接加入正在使用的配置。
- 确认系统网络：在 iPhone 上先确认 Wi-Fi 或蜂窝网络本身可用；若 Wi-Fi 需要网页登录，先完成网络认证。记录当前网络类型，避免复测时无意切换。
- 核对 Home 状态：查看 Home 是否为
Connected，并确认实际选中的是预期的服务器条目。若连接开关开启后立即断开，先记录提示文字，再处理连接建立问题。 - 检查路由姿态：进入
Home → Global Routing，记录当前选项。使用Config时检查规则；为了短时对照，可临时切换到Proxy，只测试一次后恢复。 - 分别测试入口：在同一网络下分别打开 ChatGPT App 与 Safari 中的网页版。记录哪个入口失败、失败发生在哪个阶段，以及是否出现明确的错误信息。
- 查看请求记录：打开 Shadowrocket 的
Data页面，查看复现时段附近的请求记录或日志。关注目标主机名、连接结果、命中策略和错误类型；界面栏目名称可能因应用界面版本或语言设置不同而略有差异。
日志里若能看到 ChatGPT 相关请求，但策略显示为 DIRECT，先检查 Global Routing 是否为 Direct，或配置中是否有规则将请求分到了直连。若显示为代理策略但连接失败，则继续核对目标连接、解析与服务端响应，不要单凭策略名称判断请求已经成功到达目标。
日志：DNS lookup failed
原因与解法：目标主机名未能得到可用解析结果。先确认失败的是哪个主机名，再检查 Settings → DNS 与当前配置中的 DNS 设置；一次只调整一项，并用原入口复测。
日志：Connection timed out
原因与解法：在等待时间内没有建立连接，可能涉及当前网络、所选连接目标或目标服务响应。对照同一网络下的其他访问结果，并核对请求所用策略；不要把超时直接当成规则语法错误。
日志：TLS handshake failed
原因与解法：TLS 会话未能完成，可能与连接中断、目标名称或服务端协商有关。记录对应主机名和发生时间，先排除直连误判与 DNS 异常，再检查已有配置中的相关连接参数。
页面：出现服务端错误代码
原因与解法：这通常不同于本地 DNS 解析错误，可能是服务端对请求、账号或当前访问环境作出响应。保留错误代码并检查账号状态、服务可用性和官方提示，不要仅靠更改 DNS 推断原因。
四、区分 DNS、网络与服务端限制
DNS 负责将主机名解析为 IP 地址，规则则决定请求采用何种处理策略。二者相互关联，但不是同一设置。若日志明确指向解析失败，先核对 Settings → DNS 以及当前配置文件中已有的 DNS 参数；如果原配置包含自定义解析方式，记录原值后再做单项对照。不要为了排查一个服务而同时添加多组未经确认的 DNS 地址。
如果 DNS 已返回地址，但随后出现连接超时或 TLS 错误，故障阶段已经向后移动，应继续检查请求的路由策略、当前网络可达性和已有连接参数。获得地址不等于目标服务器可达；看到 Connected 也不等于每个目标连接都建立成功。将日志中同一请求的主机名、策略和错误对应起来，比反复运行延迟测试更有帮助。
若请求能够到达服务端，并返回登录失败、访问受限、频率限制或其他明确的产品提示，应按 ChatGPT 官方页面提供的信息检查账号状态、服务状态和适用条件。此类响应不一定由 Shadowrocket 设置错误造成；修改客户端规则也不能保证改变服务端的判定。尤其不要把服务端错误代码简单解释为 DNS 故障。
App 与网页版的表现也可能不同。网页版会经过浏览器的缓存、Cookie 和登录会话；App 则可能在后台请求不同的服务接口。若只有一个入口失败，可先在不改变网络和 Shadowrocket 设置的前提下，重新打开该入口并确认账号登录状态；若两者都失败，再结合同一时段的请求记录判断是否属于共同的网络路径问题。
- 仅网页版失败：记录浏览器给出的错误，并检查该浏览器的登录状态；不要先清除所有配置或重置 Shadowrocket。
- 仅 App 失败：确认 App 已更新至可用状态并检查登录提示，同时观察对应请求是否出现在 Data 记录中。
- 多个网站同时出现解析失败：优先检查当前网络与 DNS 设置，而不是只添加 ChatGPT 域名规则。
- 请求已收到服务端错误：保留错误代码和时间，查看官方服务或账号提示，再决定是否需要继续排查本地设置。
五、常见问题
Shadowrocket 显示 Connected，为什么 ChatGPT 还是打不开？
Connected 只表示系统 VPN 连接已建立。进入 Home → Global Routing 确认当前不是不符合预期的 Direct，再查看 Data 中 ChatGPT 请求的目标、命中策略和错误记录。
延迟测试正常，能说明 ChatGPT 的连接没问题吗？
不能。延迟测试对应特定的探测目标和方式，不等于 ChatGPT 的域名解析、规则命中、TLS 建立与服务响应都正常。请用同一入口复现，并查看对应请求记录。
我应该先改 DNS 还是先改规则？
先看错误阶段：若记录明确为 DNS 解析失败，再检查 Settings → DNS；若请求已解析且策略显示为 DIRECT，先核对 Global Routing 和规则。每轮只改一个设置并复测。
App 能用，但网页版不行，是否需要重建配置？
通常不应一开始就重建配置。先记录浏览器的具体错误和登录状态，再检查失败请求是否出现在 Data 记录中；只有证据指向配置或规则时，才针对对应项修改。
排查完成后恢复临时对照时改动过的 Global Routing 或其他设置，再用原网络和入口复测一次。若问题仍在，整理复现时间、失败入口、日志中的主机名与错误类型，并遮盖账号及订阅等敏感信息。按请求实际失败的阶段处理，通常比反复切换服务器或同时重置多项设置更容易找到原因。