ChatGPT 无法访问?Shadowrocket 排查与解决方法
使用 Shadowrocket 后 ChatGPT 仍然打不开,可能不是节点失效,而是分流规则、DNS、节点协议或 iOS VPN 配置造成的。本文从快速测试开始,逐步定位并修复 ChatGPT 连接失败、加载缓慢和频繁断线问题。
为什么这件事总被焊成一件
先判断问题出在哪里
使用 Shadowrocket 后 ChatGPT 仍然打不开,先不要急着删除订阅或反复切换节点。连接失败至少可能发生在四个位置:当前出口本身不可用,Config 没有把 ChatGPT 的请求送进 Proxy,DNS 没有正确解析域名,或者 iOS 的 VPN 配置没有真正接管流量。它们在浏览器里往往只表现为白屏、加载转圈、提示网络错误或登录页面反复刷新。
最有价值的第一步,是做一个简单的对照。先保持 Shadowrocket 关闭,用 Safari 打开几个你平时能正常访问的普通网站,再打开 Shadowrocket,只测试 ChatGPT 相关页面。不要在同一时间修改订阅、规则和 DNS,否则即使问题暂时消失,也无法知道是哪一项起了作用。
- 所有网站都打不开:优先检查节点、VPN 授权、网络环境和当前出口。
- 普通网站正常,只有 ChatGPT 失败:优先检查域名分流、DNS、规则集和出口对该服务的支持情况。
- 网页能开,App 不能用:检查 App 使用的域名范围、登录状态以及是否存在旧的网络配置。
- 偶尔能开但频繁断线:重点观察节点丢包、出口稳定性、DNS 超时和规则是否在多个出口之间来回切换。
这里的「打开」也要分清。首页能显示,不代表登录、发送消息和加载历史记录都正常。ChatGPT 通常会继续请求多个接口和静态资源,只放行其中一个域名,页面可能看起来已经加载,实际却无法发送内容。
先验证节点和 VPN 通道
Shadowrocket 不是线路提供商。Home 里的 SERVER 只是你自行准备的出口记录,能否连接、延迟是否稳定、是否允许目标服务访问,都取决于这条出口及其网络路径。ChatGPT 打不开时,先确认当前 SERVER 不是空记录、失效记录或刚好拥塞的出口。
可以先做两个不涉及规则大改的对照。第一,在 Home 确认已经选中一个可用的 SERVER,并观察连接后是否出现 VPN 标志。第二,临时把 Global Routing 切到 Proxy,再重新打开一个普通 HTTPS 网站和 ChatGPT。这个测试的意义不是把 Proxy 当成永久配置,而是暂时减少分流变量。
- 普通网站和 ChatGPT 都失败,说明问题更接近出口、VPN 授权或网络本身。
- 普通网站成功、ChatGPT 仍失败,继续检查域名规则和 DNS,不要立刻判定节点完全失效。
- 切换另一个已准备好的 SERVER 后恢复,说明原出口需要暂时停用或联系其提供方确认。
- 所有 SERVER 都表现相同,优先回到 Config、DNS 和 iOS 网络设置排查。
如果 Shadowrocket 的开关显示为开启,但 iOS 顶部没有 VPN 标志,或者系统提示 VPN 配置不可用,先关闭其他 VPN、网络过滤器和同类客户端,再到系统设置中确认 Shadowrocket 的 VPN 配置仍然存在。Quantumult X、Loon、Stash、Surge 或 sing-box(SFI) 同时保留接管权限时,可能造成判断混乱;排错期间只保留一个客户端运行。
检查 Config 和 Global Routing
ChatGPT 访问失败最容易被忽略的原因,是当前启用的 Config 把请求判成了 DIRECT。Home 里有可用 SERVER,不代表每个请求都会走它。真正决定请求去向的是 Config 中的规则,以及 Home 里的 Global Routing 选择。配置文件不是订阅,订阅也不是规则文件,三者的职责需要分开看。可以先阅读配置文件不是订阅和Global Routing 怎么读。
在 Config 中确认当前启用的是你预期的文件,而不是一个旧文件、空文件或临时测试文件。然后检查与 ChatGPT 相关的域名是否有明确的代理判定。常见目标包括主站域名、登录域名、接口域名和静态资源域名。不要只根据首页能否打开来判断,因为登录和发送消息时可能会访问不同的主机。
排错时可以暂时使用较简单的测试方式:让更多请求通过当前 Proxy,以便确认是不是分流造成的。测试完成后再恢复按规则分流,避免把所有流量长期交给代理。若 Proxy 模式下 ChatGPT 正常,而 Config 模式下失败,基本可以把范围缩小到规则匹配、规则集更新或最终落点。
- 确认当前 Config 的文件名和启用状态。
- 确认 ChatGPT 相关域名没有被提前匹配到 DIRECT、REJECT 或错误的策略组。
- 确认规则的最终落点不是一个已经失效的 SERVER。
- 保存修改后重新连接 VPN,再测试登录和发送消息,不要只刷新已经打开的页面。
如果配置来自远程地址,更新后规则可能发生变化。不要在没有备份的情况下连续覆盖多个文件;先记下当前文件名和 Global Routing 状态,再一次只改一个变量。这样即使结果变差,也能回到上一个可验证的状态。
动手做一次最小化测试
下面是一套适合 iPhone 或 iPadOS 的最小化测试。它的目标不是重新搭建整套配置,而是用尽量少的变化判断故障层级。开始前关闭其他代理客户端,并记住当前使用的 Config 和 SERVER。
- 打开 Shadowrocket,在 Home 确认一个已经准备好的 SERVER 处于选中状态。
- 确认 iOS 已允许 Shadowrocket 添加 VPN 配置,并等待系统状态显示 VPN 已连接。
- 暂时将 Global Routing 设为 Proxy,只用于测试,不要先编辑大量规则。
- 先打开普通网站,再打开 ChatGPT 页面,分别记录是 DNS 错误、连接超时、登录失败还是页面部分加载。
- 如果仍然失败,只切换到另一个已有 SERVER,重复同样的测试。
- 如果 Proxy 模式成功,再恢复 Config,逐步检查 ChatGPT 相关域名的匹配结果。
这个过程中不要同时更换 DNS、导入新订阅、升级多个客户端或清除全部数据。一次只做一项改变,结果才有对照意义。测试完成后,把 Global Routing 恢复到日常使用的模式,并确认普通网站没有被无意中全部送入 Proxy。
如果切换 SERVER 后仍然只有 ChatGPT 失败,可以用 Safari 的无痕页面重新测试,排除旧 Cookie、缓存或登录会话影响。网页和 App 的会话并不完全相同,重新登录时也要确认系统时间、Apple ID 状态和 ChatGPT 账号本身没有异常。
排查 DNS、加载缓慢与频繁断线
DNS 的问题不一定表现为完全打不开。有时主页面可以载入,但登录接口或资源域名解析很慢;也有时 DNS 返回的地址在当前网络环境下不可达,结果就是页面长时间转圈。若 Shadowrocket 中设置了自定义 DNS、加密 DNS 或远程解析方式,先确认它与当前网络和 Config 的预期一致。
最稳妥的排查方式是记录现象,而不是盲目填写网上看到的 DNS 地址。比较使用当前 DNS 与系统默认 DNS 时的结果,观察是否只有某个网络环境失败。例如 Wi-Fi 能打开、蜂窝数据失败,可能是网络侧的 DNS 或策略差异;两者都失败,则更应该检查规则、出口和 VPN 通道。
- 连接立即失败:检查域名是否被 REJECT、DNS 是否返回失败,以及规则是否指向不存在的策略。
- 页面长期转圈:检查 DNS 响应时间、出口丢包和登录接口是否走了不同路径。
- 发送消息后断线:检查长连接稳定性,不要只看一次测速或短时间延迟。
- 切换网络才恢复:分别记录 Wi-Fi 与蜂窝数据的结果,再决定是否需要调整 DNS。
不要把测速延迟当成 ChatGPT 可用性的充分证明。测速只说明某个测试地址的响应速度,不能证明目标服务的登录接口、长连接和所有资源都能稳定通过。同样,频繁切换 DNS 也可能清掉已有连接,让问题看起来忽好忽坏。
检查 iOS 设置与缓存状态
iOS 同一时间可能存在多个网络接管来源,例如另一个 VPN、DNS 过滤器、企业网络配置或安全软件。它们与 Shadowrocket 叠加后,可能出现开关显示正常但流量没有按预期经过当前 SERVER 的情况。排错时先暂时停用同类网络工具,并在系统设置中查看 VPN 配置名称是否对应 Shadowrocket。
如果只是 ChatGPT App 失败,而 Safari 正常,先完全退出 App,再重新打开;必要时退出账号后重新登录。不要一开始就删除 Shadowrocket,因为删除客户端会同时影响现有的 VPN 授权和本地配置,反而会增加变量。若网页缓存或 Cookie 状态明显异常,可以使用 Safari 的私密浏览窗口做一次干净测试。
还要确认 iOS 日期和时间设为自动、系统版本没有处在异常测试状态,并检查是否开启了会改变网络行为的内容过滤功能。企业或学校网络可能限制长连接、登录接口或特定域名,这类限制不是通过修改 Shadowrocket 规则就一定能解决的。
常见问题
为什么节点测速正常,但 ChatGPT 还是打不开?
测速地址和 ChatGPT 使用的域名、接口及连接类型不同。测速正常只能说明测试目标有响应,不能证明目标服务全部可达。先确认 ChatGPT 相关请求没有被 Config 判为 DIRECT 或 REJECT,再比较另一个已有 SERVER。
把 Global Routing 切到 Proxy 就能解决吗?
它只能作为排错手段。若切到 Proxy 后恢复,说明分流规则很可能需要检查;但长期使用 Proxy 会让更多流量进入当前出口,也可能带来速度、隐私和稳定性方面的额外影响。测试后应恢复合适的 Config。
需要重新购买订阅吗?
不能仅凭 ChatGPT 失败就得出这个结论。先区分客户端、出口、配置和 DNS 四层问题。Shadowrocket 本身不提供节点或订阅,线路需要自行准备;本站也不提供节点、邀请码或套餐推荐。
什么时候应该重装 Shadowrocket?
只有在确认 VPN 配置损坏、应用持续异常且备份了必要配置后,才考虑重装。多数 ChatGPT 访问问题首先应检查 SERVER、Config、Global Routing、DNS 和 iOS 中的其他 VPN,而不是直接清空应用。
第一层:你买到的只是客户端
App Store 卖给你的是一份客户端许可。它会解析链接、保存节点、测延迟、切换 Global Routing、读写配置文件,并向系统申请 VPN。这些能力买一次就在,更新也走商店。它不会在你点「+」之后凭空生成可用主机,也不会在你打开开关之后补上流量和有效期。
所以「我都买了怎么还不能用」通常不是应用欺诈,而是第二层还没接。Home 的 SERVER 里只有 Add Server,正是这一层已经装好、下一层还空着的正常状态。此时反复拨开关、重装、改地区,都修不好空列表。
第一层也会单独出问题。买错近似名称、装到非商店来源、后来在系统设置里关掉了 VPN,表现都是「应用在,可是连不上」。这类故障不该用换订阅来修。核对名称、图标和 App ID,见 为什么只从 App Store 获取。
第二层:出口来自订阅或手填节点
主机在哪、端口是多少、协议对不对、流量有没有剩、链接会不会过期,都由服务商或你自己的服务器决定。应用只是把这些记录存下来,并在你选中某一条时去连接。列表空、更新失败、延迟全超时,优先怀疑这一层。
第二层有两种接法。服务商给订阅 URL,走 Type 里的 Subscribe,以后可以再更新。服务商只给主机、端口和密码,走 Add Server。把订阅地址贴进 Host,或把配置文件地址当成订阅,都不会展开成可用节点。这一步的误读单独写成了 Subscribe 不是 Add Server。
有列表仍可能等于没有出口。节点名字在,延迟全是超时,说明清单拉下来了,对端不可用。延迟数字很小,网页仍打不开,说明测速地址通了,代理握手不一定通。不要被数字安慰,也不要因此重装应用。更新订阅,或换一条,仍全军覆没就回到服务商侧。
第三层:配置决定什么流量走出口
配置回答的不是「有没有节点」,而是「这个请求直连还是进隧道」。默认的 default.conf 已经带分流。服务商也可能另给一份远程文件。换订阅不一定要换配置,改配置也不等于换了一批节点。两份地址都可能以 https 开头,进的却不是同一个底栏。
Global Routing 停在 Config 时,真正生效的是当前启用的那份文件。节点再多,规则把请求判去 DIRECT,隧道也不会帮你打开那个站点。反过来,规则把国内站也送进隧道,你会觉得「开了代理反而更卡」。这不是第一层坏了,也往往不是第二层没流量,而是第三层和你的预期不一致。
配置和订阅为什么必须分开看,见 配置文件不是订阅。三种观察口径怎么用来对照,见 Config、Proxy、Direct 各自在看什么。
同一句「打不开」,指向不同层
三层里任何一层出问题,表面都可能是网页打不开。同时改三处,只会更难判断。先用症状定位,再动手。
| 你看到的 | 先怀疑 | 先不要做 |
|---|---|---|
| 商店里找不到,或图标不对 | 应用这一层:地区、条目、仿冒 | 去下安装包 |
| Home 的 SERVER 只有 Add Server | 订阅还没导入,或 Type 选错 | 改规则、开 Proxy |
| 列表有节点,延迟全超时 | 出口本身不可用 | 重装应用 |
| 有 VPN,国内站也变慢或打不开 | 配置把不该代理的请求送进了隧道 | 继续加节点 |
| 开关开着,状态栏没有 VPN | 系统没有放行这条配置 | 换订阅链接 |
| 直连也打不开同一个站点 | 本机网络或目标本身不可达 | 继续调 Shadowrocket |
系统 VPN 不属于第四层,但常被漏看
连接写在 iOS 的 VPN 配置上。应用发起,系统放行。第一次接通时,系统会问是否允许添加配置。拒绝之后,Home 里的开关无法单独生效。后来在「设置」里关掉这一条,结果同样是开关开着、状态栏没有 VPN。
卸载应用不一定立刻删掉系统里的配置。重装后若不再次允许,或系统里残留的是另一来源的同名配置,也会出现「我装好了,可是连不上」。这仍然该先回到第一层和系统授权,而不是怀疑订阅过期。
Settings 里的 On Demand 会在离开某些网络时自动断开。这不是节点突然没了。有人以为「晚上自己断了就是订阅失效」,先看这一项,再去更新第二层。
建议的检查顺序
先确认应用是官方那一份,并且系统里的 VPN 配置还在。再确认 Home 里有能选中的节点,更新后不是空清单。最后才问规则是不是把请求判去了直连,或误送进隧道。一次只动一层。同一分钟里更新订阅、改 Global Routing、换 Config、再开关 VPN,最后你不知道哪一步生效。
卸载重装只会清掉应用里的本地状态。订阅会不会还在、配置会不会还在,取决于你有没有在 Data 里备份,以及系统是否仍保留 VPN 配置。重装不是修理第二层的方法,也不是业务恢复键。
若已经分清这三层,再去教程里按顺序接上它们。还没购买,或还没核对比图标,先走下载页,不要从别的站点找安装包。