· 故障排查 · 约 8 分钟

Shadowrocket 已连接却上不了网:服务器、模式、DNS 与规则逐项排查

开关已经打开,网页却打不开。本文按服务器状态、Global Routing 模式、DNS 设置、规则命中四个环节,逐项定位断点。

本文速览

连接开关开启只表示本地连接已启动，不能单独证明服务器、域名解析和目标网站均可用。本文适用于已经持有自己的服务器信息或订阅的用户：先确认基础网络，再对照测试服务器、Global Routing、DNS 和规则，每次只改变一个变量，最后恢复日常配置。

01 先分清“已连接”和“请求成功”

Shadowrocket（小火箭）的连接状态、服务器延迟测试与网页实际加载，是三个不同的观察点。状态栏出现 VPN 标记，不等于远端服务器已经完成认证；延迟测试出现数值，也不等于网页所需的 DNS、TLS 和后续资源请求全部成功。先记录现象，比反复切换连接开关更容易缩小范围。

开始前记下当前服务器、Global Routing 选项、正在使用的 Config，以及失败网页的域名。选一个日常能够直接访问的网页作为对照，再选一个当前失败的网页。不要把单一网站的故障直接判断为所有网络都不可用。

  1. 确认基础网络

    先在 Settings → On Demand 中检查并暂时关闭按需自动连接，再回到 Home 关闭连接开关。用 Safari 打开日常可直接访问的网页；若仍失败，先处理 Wi-Fi 登录认证、蜂窝数据权限或网络本身的问题。

  2. 固定测试条件

    保持同一个网络、同一个网页和同一台设备，回到 Home 选择自己的服务器并开启连接。测试期间不要同时切换 Wi-Fi、服务器与 Config，否则无法判断是哪项改变带来差异。

  3. 记录失败范围

    分别记录“所有网页失败”“部分域名失败”“网页能开但图片失败”或“只有某个 App 失败”。记录发生时间及当时的 Global Routing 选项，供后续与请求记录对照。

  4. 单项修改复测

    每次只改一个设置，重新发起相同请求；必要时关闭后重新开启连接。若没有改善，恢复该项原值，再继续下一步，避免多个临时设置叠加。

02 检查服务器可达性与已有订阅

在 Home 使用 Connectivity Test 检查已有服务器，并确认当前选中的条目就是要测试的条目。测试结果受测试方法和测试目标影响：端口可以建立连接，不代表协议认证成功；测试目标可达，也不代表其他网站同样可达。因此需要把测试结果和浏览器实际请求一起看。

打开当前条目的编辑页，逐项核对 Type、服务器地址、端口和认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的参数并不通用，不能因为某个条目超时就随意改成另一种协议。涉及 TLS 时，还应核对服务方给出的服务器名称及相关参数，不要通过关闭证书验证掩盖配置错误。

03 用 Global Routing 做对照测试

服务器初步可用后，在 Home → Global Routing 核对当前选项。Proxy、Direct、Config 和 Scene 代表不同的路由方式，不应只凭连接开关判断流量去了哪里。排查时先记录原选项，再短暂对照 Proxy 与 Config，结束后恢复日常设置。

选项排查时关注什么结果怎样解释
Proxy让普通请求走代理路径，核对当前代理选择。同一网页在此可用而在 Config 失败时，优先检查规则与策略选择；仍需留意 DNS 差异。
Direct请求走直接连接路径。选中服务器不代表请求使用该服务器；只能用可直接访问的网页进行基础对照。
Config按当前配置中的规则处理请求。确认启用的是预期配置，再查看失败请求命中的规则及最终策略。
Scene核对当前场景及其关联设置。场景可能改变实际使用的路由设置，不能仅凭手动选过某个服务器推断最终路径。

如果 Proxy 与 Config 都失败，应继续检查服务器和 DNS，而不是立即添加规则。如果 Proxy 可用、Config 不可用，重点检查 Config 中是否把目标域名交给了 DIRECT、REJECT 或不可用的策略组。这个对照是定位线索，不是证明服务器完全正常的唯一依据。

04 延迟正常但网页打不开时检查 DNS

网页首先需要把域名解析为地址。延迟测试若只验证服务器端口，或者使用了与网页不同的测试目标，就可能出现“延迟正常，网页打不开”。进入 Settings → DNS 查看当前设置，同时检查启用的 Config 是否包含自己的 DNS 配置，避免只修改一处却遗漏另一处。

先保存原设置，再检查是否存在失效的自定义解析地址、只能在特定网络访问的解析器，或不完整的加密 DNS 地址。不要连续堆叠多个陌生地址：解析器本身不可达时，增加数量不一定能修复问题，还会增加对照难度。

53
普通 DNS 常用 UDP / TCP 端口
443
HTTPS 与 DoH 常用端口
853
DoT 常用端口

这些是协议常用端口，不是需要统一填入服务器条目的数值。服务端口应保持服务方给出的值。若使用 DoH，端点包含主机名时还涉及该主机名的初始解析；若解析器必须经过代理访问，代理不可用也可能导致解析失败。

05 检查规则顺序、策略与 FINAL

当问题只在 Config 下出现时，进入 Config 确认当前使用的配置，再检查其规则。规则通常按从上到下的顺序匹配，先命中的规则决定策略；FINAL 用于前面的规则均未命中时兜底。因此，添加一条正确的规则却放在过早的 FINAL 后面，并不能达到预期效果。

下面是语法说明，不是应当整段替换当前配置的方案。example.com 与 192.0.2.0/24 用作示例；实际规则必须与自己的目标和策略安排对应。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

复测时查看应用内的请求记录，按刚才的时间和域名定位请求，核对命中规则与实际策略。命中 PROXY 后仍失败，要继续检查它使用的服务器或策略组；命中 REJECT 则应先判断是否被过宽的规则拦截。不要为了让一个页面打开就删除全部规则，先备份并缩小改动范围。

06 根据错误文本确定下一步

错误文本要结合它出现的位置理解。下面列出连接或解析记录中常见的英文错误片段；具体大小写和附加信息可能不同。浏览器显示的笼统“无法打开网页”不足以区分阶段，应同时查看应用内相同时间的记录。

报错：Connection refused

原因与解法：目标地址或路径中的设备拒绝了连接，常见于端口未监听或访问被拒绝；核对自己的服务器地址与端口，再向服务方确认监听状态，不要直接归因为密码错误。

报错：Connection timed out

原因与解法：连接在限定时间内没有完成，可能涉及路径、服务器状态或防火墙；保持参数不变，换用自己可用的网络复测，并记录是否只有单个服务器出现此现象。

报错：NXDOMAIN

原因与解法：DNS 返回域名不存在，可能是域名写错或解析结果异常；先核对完整域名，再用此前正常的 DNS 配置复测，不能靠反复刷新服务器列表修复域名拼写。

若错误涉及 TLS 证书，还要核对设备日期与时间、服务器名称及服务方的证书配置。网页已经返回明确的 HTTP 状态码时，说明至少已获得一次 HTTP 响应；此时应结合状态码检查网站或访问策略，而不是把所有失败都当作 DNS 故障。

07 常见追问与恢复检查

Connectivity Test 有数值，为什么还是打不开？

先在 Home → Global Routing 记录当前选项，并用同一网页对照 Proxy 与 Config。延迟测试不能覆盖网页的全部请求，再依据失败时间检查 DNS 结果、命中策略及连接错误。

切到 Proxy 能用，是否一直这样就行？

这说明不同路由方式产生了差异，但不等于已经修复规则。回到 Config 检查目标域名的匹配位置、策略组和 FINAL；修正后恢复原路由方式，再用同一网页确认结果。

关掉连接后又自动打开，怎么做基础测试？

进入 Settings → On Demand，记录并暂时关闭按需自动连接，再回 Home 关闭连接。完成排查后恢复原来的 On Demand 设置，避免把测试状态留作日常配置。

更新订阅后是否还要重新选服务器？

需要回 Home 确认当前条目。更新可能改变条目内容或名称；核对选择后再做 Connectivity Test，并测试实际网页。订阅更新成功不能作为线路可用的证明。

要不要先删除应用再重新安装？

优先完成上述分层排查。重新安装不能修复远端服务器或网络路径，还可能丢失本地设置。确需重装前先备份配置，并妥善保存自己的订阅与认证信息。

排查结束后，用原网络、原目标网页再测一次，恢复临时调整过的 Global Routing、DNS 与 On Demand。保留一份简短记录：失败时间、网络类型、所用服务器、命中策略、错误文本及有效的改动。需要进一步咨询时，只提供脱敏记录；订阅中的 token、密码和私钥不应出现在截图或公开消息中。

App Store 正版核验