2026-10-15 · 故障排查 · 约 9 分钟

Shadowrocket 开关已打开却无法上网:服务器、模式、DNS 与规则逐项排查

连接开关已打开但网页打不开时,建议依次检查服务器是否可用、Global Routing 模式是否合适、DNS 设置是否异常,以及 FINAL 与 REJECT 规则是否误伤,逐步缩小故障范围。

本文速览

Shadowrocket(小火箭)的开关表示本机连接状态,不等于服务器、DNS 与目标网站都已可用。本文以用户已有自己的服务与配置为前提,按基础网络、服务器参数、Global Routing、DNS、规则顺序检查;每次只改一个变量,用同一地址复测,最后恢复日常配置。

一、先区分本机隧道与实际请求

系统显示 VPN 状态,说明设备已建立相应的本机网络通道;远端服务器是否接受连接、域名能否解析、规则最终走向哪里,仍需分别验证。不要仅凭开关保持打开,就判定故障一定发生在浏览器,也不要把所有打不开的网页都归为 DNS 问题。

应用请求 本机隧道 解析与分流 出站连接 目标响应

这条链用于划分检查范围,不表示所有请求都严格按同一顺序完成解析与分流:域名规则可以先匹配,部分 IP 规则则可能需要解析结果。先做以下对照,确认是否连基础网络也不可用。

  1. 记录当前 Home 所选服务器、Global Routing 模式和 Config 中启用的配置;修改前保留可恢复的副本。
  2. 暂时关闭 Shadowrocket,用 Safari 打开一个平时可直接访问的网页。如果仍失败,先完成 Wi-Fi 的认证页面,或检查蜂窝数据权限与当前网络状态。
  3. 基础网络恢复后再打开连接,访问同一网页,并记录是全部失败、部分域名失败,还是只有某个应用失败。
  4. 在条件允许时用 Wi-Fi 与蜂窝数据各复测一次。切换网络后重新发起请求,不把旧页面的缓存结果当作新结果。

二、核对 Home 服务器与已有订阅

在 Home 确认当前选中的服务器确实来自自己的有效配置,而不是已经失效的旧条目。运行 Connectivity Test 可以作为可达性线索,但测试目标、测试方式与实际访问的网站不完全相同:有延迟数字不代表所有网页都能访问,测试超时也需要结合实际连接记录判断。

如果条目来自订阅,核对订阅是否成功更新、列表是否仍保留旧信息。需要更新时在 Home 对已有订阅执行更新,并到 Settings → Subscribe 核对相关设置。订阅更新属于获取配置,服务器连接属于实际出站,两者不是同一个请求;更新成功不能证明条目可用,更新失败也不能直接证明已有条目全部失效。

报错:connection refused

原因与解法:通常表示连接被目标地址或中间设备明确拒绝——先核对该条连接记录指向的是服务器还是目标网站,再检查地址、端口与远端监听状态,不要直接修改 DNS。

报错:i/o timeout

原因与解法:表示某一步 I/O 等待超时,单独这一行不能确定故障位置——结合前后记录判断发生在解析、服务器连接还是目标访问,再用另一种基础网络对照。

以上是连接记录中可能出现的错误片段,不是每台设备都会显示相同提示。提供排查信息时保留错误原文和发生阶段,隐藏密码、UUID、私钥与订阅 token;不要公开完整配置。

三、用 Global Routing 对照模式与规则

在 Home → Global Routing 先确认当前模式。Proxy、Direct、Config、Scene 的用途不同,不能把“已开启连接”理解为“所有请求都使用所选服务器”。尤其是 Direct,即便开关打开,请求也不会因此自动改走远端代理。

4 种
Global Routing 模式:Proxy / Direct / Config / Scene
53
传统 DNS 常用端口,通常使用 UDP,也可使用 TCP
443
HTTPS 与 DoH 通常使用的端口,不代表连接必然可达
模式含义排查用途
Proxy以代理方式处理请求短时验证所选代理路径,排除 Config 规则分流的影响
Direct以直连方式处理请求对照当前网络直连情况,不用于证明远端服务器可用
Config按当前配置的规则决定策略检查命中规则、策略组与最终出站
Scene依照已设置的场景处理路由选择核对当前网络对应的场景及其实际生效设置

保持服务器和访问地址不变,短时切换 Proxy 与 Config 进行对照。如果 Proxy 能访问而 Config 失败,重点转向规则与策略组,但仍需注意两种模式下 DNS 或请求路径可能不同。如果两种模式都失败,优先继续核对服务器、基础网络和 DNS,不必立刻删除整份配置。

Scene 需要结合已有场景判断,不能假定它等同于 Config。完成测试后恢复原模式;用于对照的 Proxy 不是日常配置的通用替代方案。

四、DNS 只在有证据时调整

DNS 将域名解析为地址。服务器地址本身如果也是域名,连接远端之前就可能需要解析;网页请求的域名还可能涉及另一段解析过程。因此,“服务器域名无法解析”和“目标网页域名无法解析”应分开记录。

  1. 确认范围:分别测试两个自己常用的域名。只有单个域名失败时,先检查该域名及其解析记录,不马上更换全局设置。
  2. 查看生效配置:在 Config 确认正在使用的文件,检查其中 DNS 相关设置,并与 Settings 中实际启用的 DNS 选项交叉核对。只看一个未启用的配置文件没有诊断意义。
  3. 确认上游可达:自定义 DNS 地址必须能通过当前路径访问。使用 DoH 时,HTTPS 连接、证书验证及其服务域名解析也都可能成为前置条件。
  4. 单项回退:若故障发生在修改 DNS 之后,先恢复修改前的设置,再重新连接并发起请求。不要同时改 DNS、服务器和规则,否则无法识别是哪项变化产生影响。

如果记录显示证书名称不匹配或证书过期,先检查设备日期与时间、服务参数中的服务器名称以及远端证书。不要用关闭证书验证来掩盖问题,也不要把 TLS 错误当作普通 DNS 超时处理。

五、检查 FINAL、REJECT 与规则顺序

当问题主要出现在 Config 模式时,打开当前 Config,沿规则顺序检查目标域名会命中哪一项。规则通常自上而下匹配,前面已经命中就不会继续交给后面的例外处理。仅仅在末尾添加一条允许规则,不能覆盖更前面的 REJECT。

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

这段内容仅用于说明语法,example.com 与 192.0.2.0/24 是示例对象,不应整段替换现用配置。示例中的 FINAL,DIRECT 意味着未命中前序规则的请求最终直连,并不表示所有用户都应采用这一策略。

页面能打开但图片、登录或接口失败时,要检查失败资源自己的域名,而不只检查地址栏中的主域名。若确认某条规则误伤,先备份,再调整该条的范围、顺序或策略;复测通过后保留最小修改,不应为解决一个页面就删除全部拒绝规则。

六、按现象复测并保存最小记录

完成一项修改后,用原来的访问地址重新测试。建议记录网络类型、服务器条目名称、Global Routing 模式、失败域名、错误原文与测试时间,便于区分偶发失败和可重复问题。以下问答用于收束常见分支。

“延迟测试有数字,为什么网页还是打不开?”

测试成功只覆盖它所测试的目标与路径。在 Home 确认所选条目,再用同一网页分别对照 Proxy 与 Config;若只在 Config 失败,查看对应域名的规则与最终策略。

“只有 Wi-Fi 不行,切到蜂窝数据就正常?”

先关闭连接确认 Wi-Fi 已完成认证,再保持服务器与配置不变复测。若仍仅在该 Wi-Fi 失败,检查其 DNS 与相关端口、UDP 路径可达性,不据此直接认定配置整体错误。

“网页正常,但某个应用一直转圈怎么办?”

重新打开该应用并观察它实际请求的域名,检查接口、媒体或登录请求是否被 REJECT,或被分到不同策略。主网页可用不能证明应用依赖的每个域名都可用。

“订阅更新失败,需要把所有服务器删掉吗?”

不必先清空列表。先保留当前条目,核对订阅链接状态,再到 Settings → Subscribe 检查更新相关设置;只有确认已有参数失效后,才按自己的有效服务资料更新。

如果仍无法定位,向自己的服务支持方提供经过脱敏的错误片段和上述对照结果。Shadowrocket 的客户端购买与远端服务状态是两件事;重复获取应用不会修复失效服务器或错误规则。本站不提供、不销售、不推荐任何节点或订阅。

下载 Shadowrocket