Shadowrocket 开关已打开却无法上网:服务器、Global Routing、DNS 与规则逐项检查

本文速览

Shadowrocket（小火箭）开关开启，只说明系统隧道已启动，不代表服务器、域名解析和目标网站全部可用。本文面向已经持有自己服务商与订阅信息的用户：先建立本地网络基线，再核对服务器，随后用 Global Routing 做单变量对照，最后查看 DNS 与规则命中。每轮只改一项，记录同一目标的结果，避免把配置变化误判成网络恢复。

一、先确认故障范围，不急着重装

先区分“所有请求失败”“只有部分域名失败”和“切换网络后失败”。这三种现象对应的检查重点不同。系统显示 VPN 状态，不能证明远端代理已完成握手；Home 中出现测试延迟，也不能代替实际网页请求。

排查期间保留当前 Config 和服务器信息，不要先删除应用。删除后重新导入会同时改变配置、缓存和选择状态，反而丢失定位依据。若已启用按需连接，先到 Settings → On Demand 暂停它，再做手动开关测试；测试结束后恢复原来的设置。

建立网络基线

在 Home 关闭连接，打开一个平时可直连访问的 HTTPS 页面。若仍失败，先处理 Wi‑Fi 登录认证、蜂窝数据权限或路由器连接，不要把本地断网归因于规则。
固定测试目标

选择一个直连目标和一个需要通过已有代理访问的目标，每次使用相同域名、相同页面。页面完整加载才算该次成功，旧页面仍显示不代表新请求成功。
记录当前状态

在 Home 记录选中的服务器与 Global Routing 模式，到 Config 确认当前启用的配置。另记当前使用 Wi‑Fi 还是蜂窝网络，后续比较时不要同时更换这些条件。
重新发起请求

开启连接后，重新打开测试页面并查看新产生的请求记录。记录目标域名、时间、处理策略和错误信息；不要用几分钟前的旧记录判断本次结果。

二、服务器检查：能建立隧道不等于能到达远端

在 Home 确认实际选中的服务器，而不只是确认订阅列表中存在服务器。核对地址、端口、协议和认证字段是否与用户已有的服务信息一致。服务器使用域名时，建立代理连接之前通常还需要解析这个域名，因此服务器域名解析失败也会表现为连接不可用。

端口号本身不能说明协议。例如服务端使用 TCP 443，并不代表任意协议都能连接这个端口。Trojan 的认证与 TLS 参数、VMess 或 VLESS 的传输设置、Shadowsocks 的加密方法都需要与服务端匹配；不要为了试错只修改 Type，保留其余不兼容字段。

先测当前条目：在 Home 使用 Connectivity Test，并观察随后一次实际网页访问。测试失败说明需要继续检查；测试成功只说明该测试路径在当时可用。
再做同网络对照：若已有列表中还有其他有效条目，仅切换服务器，保持 Global Routing 与 Config 不变。只有一个条目失败时，优先检查该条目的参数、有效状态和远端服务。
最后换网络：保持服务器不变，从 Wi‑Fi 切换到蜂窝网络后重复测试。若只在其中一个网络失败，应检查该网络的认证状态、出口限制及所用传输的可达性。
核对已有订阅：服务参数发生变更时，更新用户自己的订阅后重新选中条目。订阅成功更新只证明配置内容可获取，不证明其中每个服务器当前可用。

报错：`connection refused`

原因：连接被目标端或中间设备明确拒绝，常见检查点是地址、端口与服务监听状态。

解法：对照已有服务信息核对端口；若信息一致，将发生时间、网络类型和错误交给自己的服务方核查，而不是连续更换 DNS。

报错：`i/o timeout`

原因：某个网络读写阶段未在期限内完成；只看这一句无法确定是服务器、传输路径还是上游目标的问题。

解法：查看同条记录附近的连接目标与阶段，再执行“同网络换服务器、同服务器换网络”的对照，缩小失败范围。

以上是网络日志中可能出现的底层错误原文，不是固定的界面提示模板。不同协议产生的上下文不同，提交问题时应保留前后文，同时隐去密码、认证信息与订阅令牌。

三、Global Routing：用 Proxy 与 Config 区分出口和规则

从 Home → Global Routing 查看当前模式。Proxy、Direct、Config、Scene 表示不同的处理姿态，不是服务器健康状态。排查时先记录原值，短时间对照后恢复；切换模式可能影响其他应用正在进行的请求。

模式	处理含义	本次排查用途
Proxy	以代理方式处理流量，不按 Config 的常规分流规则选择直连。	固定服务器，测试代理出口能否完成实际请求。
Direct	使用直连路径。	核对本地网络和目标的直连可达性；不能用来验证代理服务器。
Config	依据当前启用的配置及规则决定处理方式。	与 Proxy 对照，定位规则、策略或配置内 DNS 差异。
Scene	依据已设置的场景条件应用相应的路由安排。	先检查实际生效的场景；初次定位时改用明确模式，减少条件变化。

如果相同服务器和目标在 Proxy 下成功，在 Config 下失败，优先检查当前配置及命中策略，但不能直接断言“规则写错”。配置中的解析行为、策略组实际选择和拒绝规则，都可能造成这种差异。如果两种模式都失败，则应先回到服务器可达性与 DNS，而不是继续堆叠分流规则。

结论：先保存能复现的模式差异

出现“Proxy 成功、Config 失败”时，保留这一组对照结果，并查看失败请求实际命中的规则和出站。先找到差异所在，再修改配置；不要同时换服务器和 DNS。

四、DNS 检查：分别确认服务器域名与目标域名

一次访问可能涉及两类解析：代理服务器地址的解析，以及目标网站域名的解析。前者失败时，代理连接尚未建立；后者失败时，服务器可能可达，但目标请求仍无法继续。具体解析发生在本地还是远端，取决于协议与配置，不能只凭网页转圈作判断。

目标域名解析结果规则判断出站连接目标响应

这条流程用于理解检查点，不代表所有协议都在同一位置执行解析。打开 Config 中当前配置的编辑视图，查看 [General] 内的 dns-server 等解析设置，并确认请求记录中是否出现解析失败、空结果或异常地址。若配置使用自定义解析服务，还要检查访问该解析服务本身所需的网络路径。

只改一个来源：先保存配置副本，再把当前自定义解析设置临时恢复为已知可用的系统解析方式。重新连接后重试同一域名，避免同时替换整份 Config。
分开观察地址族：若记录中有 A 与 AAAA 结果，分别观察最终连接的 IPv4 或 IPv6 地址。收到 AAAA 记录并不等于当前网络具备可用的 IPv6 出口。
正确理解端口：传统 DNS 通常使用 UDP 或 TCP 53，DoH 使用 HTTPS，通常涉及 TCP 443。端口可达也不等于解析请求一定成功，仍要看实际响应。
不要直接用 IP 代替验证：HTTPS 站点常依赖域名进行证书校验和虚拟主机选择。把地址栏换成 IP 后失败，不能单独证明 DNS 有问题。

五、规则检查：看首个命中，不只看规则是否存在

在 Config 确认真正启用的配置后，检查失败域名对应的请求记录。重点记录命中规则、最终策略及实际服务器。规则按顺序匹配，前面已经匹配的请求不会因为后面还有一条更符合预期的规则就自动改道。

下面只是说明顺序与语法的示例，不是可直接覆盖现有配置的通用方案。example.com 是示例域名，192.168.0.0/16 是私有地址范围；其中 PROXY 与 DIRECT 是规则策略关键字，和 Global Routing 菜单中的显示文案不要混淆。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

DOMAIN-SUFFIX：示例中匹配 example.com 及其子域名。实际页面可能另外请求登录、图片和接口域名，主页面命中不代表所有依赖请求都命中。
IP-CIDR：按目标 IP 网段匹配。示例中的 no-resolve 表示不为匹配这条 IP 规则额外发起域名解析，并不是关闭整份配置的 DNS。
GEOIP：例如 GEOIP,CN,DIRECT 按地址所属地区判断，结果依赖地址与所用数据库；不能把它当作域名后缀规则使用。
FINAL：前面规则未匹配时的最终处理。示例使用 FINAL,DIRECT，所以没有命中前两条的请求会直连；若目标需要代理，这种兜底就可能与预期不符。

发现规则命中不符时，先确认是否启用了预期的 Config，再检查规则顺序、域名拼写及引用策略。若命中的是策略组，还应核对组内实际选中的服务器。不要仅因看到 PROXY 字样，就认定请求经过了原本想用的出口。

结论：只修正已经证实的错误分流

当失败记录明确显示目标被错误直连时，先在配置副本中添加范围准确的域名规则，并放在会提前匹配的宽泛规则之前。验证页面及其依赖请求后，再决定是否保留修改。

六、常见追问：部分可用、自动重连与订阅更新

为什么有延迟数字，网页还是打不开？

延迟数字对应一次特定测试，不覆盖所有目标、所有 DNS 路径和网页依赖请求。保持同一服务器，在 Proxy 下访问实际目标，再检查失败发生于解析、连接还是响应阶段。

只有一个网站打不开，需要换整个配置吗？

先看该网站主域名及接口域名的请求记录。若其他目标正常，优先核对该目标的规则、解析结果与远端响应。HTTP 403、429 等响应说明请求已到达某个 HTTP 服务，应继续检查响应来源与访问条件，而不是直接重装。

开关关掉后又自动开启，怎么做对照？

进入 Settings → On Demand，暂时关闭按需连接，再手动断开测试。若设备还有管理策略，也应核对其连接要求。完成本轮排查后恢复原设置，避免把测试状态长期保留。

订阅更新失败和网页打不开是一回事吗？

不是。订阅更新访问的是配置地址，网页请求访问的是目标网站，两条路径可能不同。先核对自己的订阅链接是否完整、是否仍有效，再检查该地址的解析和访问路径；更新成功后，还要重新确认 Home 中选中的服务器。

换到蜂窝网络就恢复，可以认定是 Wi‑Fi 的问题吗？

这说明故障与网络条件相关，但还需要控制变量。保持服务器、Config 和目标不变，检查 Wi‑Fi 是否完成认证、能否直连，以及该网络是否允许当前传输。不要一次同时更换协议、服务器与解析设置。

七、恢复设置并整理可复现记录

定位后恢复原来的 Global Routing 与 On Demand，保留经过验证的必要修改。一次成功不等于问题永久消失，应在原来失败的网络上重新发起请求，并确认关闭、再开启连接后结果仍然一致。

环境：设备类型、网络类型、发生时间，以及关闭连接后直连是否可用。
对照：同一目标在 Proxy 与 Config 下的结果，切换网络或已有服务器后是否变化。
证据：失败请求的域名、命中策略、错误原文及相邻上下文，说明测试的是网页还是 Connectivity Test。
隐私：发送记录前删除订阅完整地址、令牌、密码及其他认证字段；只保留定位所需信息。

这份记录能把“开关开了不能用”转化为明确问题：是连接不到服务器、解析没有结果、规则选错出站，还是目标已经返回错误。按顺序验证比反复重置更容易保留证据，也更便于自己的服务方核对远端状态。