2026-09-28 · 故障排查 · 约 8 分钟

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

开关显示已连接但网页打不开时,依次检查服务器可用性、Global Routing 所处模式、DNS 设置和 FINAL 等规则的命中情况。

本文速览

Shadowrocket（小火箭）的连接开关表示本机隧道状态，不等于远端服务器、域名解析与目标网站均已连通。本文以用户已有自己的服务器与订阅为前提，按本地网络、服务器参数、Global Routing、DNS 和规则顺序定位故障；每次只改一个变量，并用同一目标重新请求，避免把偶然恢复当作修复结果。

1. 区分隧道连接与网页连通

iPhone 或 iPad 显示 VPN 标识，说明系统已建立相应的本地网络隧道。网页还需要经过解析、策略选择、远端连接与目标响应等环节，其中任意一环失败，都可能表现为开关打开但页面持续等待。只反复切换开关，无法判断故障发生在哪一层。

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

先记录失败的是全部应用、全部网页，还是某个域名；同时记录失败时使用 Wi-Fi 还是蜂窝网络。浏览器能打开一个页面，只能证明该次请求可完成，不能代表其他协议或其他目标也可用。以下对照应使用自己的固定测试页面，不必连续访问大量不同网站。

  1. 保留现场

    在 Home 记录选中的服务器、Global Routing 当前值及失败时间。在 Config 记录当前启用的配置名称，修改前保留副本，不直接覆盖原配置。

  2. 测试本地网络

    进入 Settings → On Demand，记录原状态并暂时关闭自动连接，再关闭 Home 的连接开关。访问原本无需代理即可访问的页面；如仍然失败，先处理 Wi-Fi 登录、信号或本地网络故障。

  3. 切换接入网络

    分别在 Wi-Fi 与蜂窝网络上测试同一页面，然后恢复 Shadowrocket 连接。若只有一种接入网络失败，保留服务器和配置不变，优先检查该网络的解析、访问限制与连通性。

  4. 重新发起请求

    每次更改设置后重新连接，再新开页面触发请求。已有长连接和页面缓存可能沿用旧结果，不能仅根据旧标签页的显示判断新设置是否生效。

2. 检查服务器参数与实际出站

在 Home 查看当前选中的服务器，打开该条目的编辑界面，对照自己服务的原始参数核对地址、端口、Type 与认证信息。服务器列表里存在条目，并不表示该条目仍然有效；延迟测试有结果，也不保证目标网页所需的完整连接能够成功。

核对对象具体检查判断边界
地址与端口与自己的服务参数逐项比对，检查地址是否过期、端口是否误填。远端可能使用 443，但不能因为网页打不开就把任何服务器端口改为 443。
Type 与认证按实际服务核对 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 所需字段。协议之间的密码、标识与密钥字段不能直接互换。
TLS 与传输服务使用 TLS 时核对服务名、证书要求；使用额外传输时核对路径等参数。不要以关闭证书验证代替修复服务名、证书或设备时间问题。
订阅状态在 Home 对自己的 Subscribe 条目执行更新，再确认当前选中的是更新后的有效服务器。更新成功只表示取得了条目，不保证每个远端都可连接。

如果已有多个有效服务器，可在不修改 Global Routing 与 DNS 的情况下，仅切换服务器进行对照。只有某一条目失败时，优先检查该条目的参数与远端状态；全部条目都失败时，再结合本地网络与共同使用的解析配置判断。本文不提供、不销售、不推荐服务器或订阅。

3. 用 Global Routing 缩小故障范围

从 Home → Global Routing 核对当前姿态。Proxy、Direct、Config 和 Scene 的作用不同，排错时应先确认流量实际交给哪种策略处理。Proxy 可以用作短暂对照，但它不是对所有网络问题都有效的修复开关。

姿态核对重点对照用途
Proxy请求按全局代理姿态处理，同时确认所用服务器或策略选择。若同一目标在 Proxy 可用、Config 失败，重点查看规则与策略引用。
Direct请求按直连姿态处理，目标必须在当前本地网络可直达。可辅助区分代理路径与直连路径，但不是关闭系统隧道的等价操作。
Config使用 Config 中当前启用配置的分流规则。检查命中规则、策略组及 FINAL，而不只检查 Home 选中的条目。
Scene检查自己设置的场景条件及其对应行为。若姿态随网络环境变化，先排除场景切换因素，再比较结果。

执行对照时，保持服务器与目标域名一致，先在原姿态下复现，再短暂切换到 Proxy 重新连接测试，最后恢复原姿态。Proxy 也失败，并不能直接排除 DNS；Config 失败而 Proxy 成功，也不能仅凭这一项断定是 FINAL 写错，还要检查命中的具体策略是否指向了另一个不可用服务器。

4. 检查 DNS：解析成功不等于连接成功

服务器地址本身若使用域名，也需要先被解析；目标网站的域名解析又是另一项请求。因此，“服务器能测到延迟”和“网页域名能解析”不是同一结论。检查 DNS 时，应先分清失败的是服务器域名还是目标域名，再检查相应解析路径。

53
传统 DNS 通常使用 UDP 或 TCP 的此端口
443
DoH 通常通过 HTTPS 使用此端口
1 项
每轮只修改一个 DNS 设置并重新测试
  1. 进入 Config，打开当前启用的配置检查 DNS 项；同时检查 Settings → DNS 中的相关设置，确认没有把另一份未启用配置的值当作当前结果。
  2. 核对解析器地址、使用方式及可达性。加密解析也依赖网络连接，填写一个 HTTPS 解析地址，并不表示它在当前路由下必然可访问。
  3. 若此前修改过 DNS，记录原值，暂时恢复为自己已验证可用的设置，再对同一目标发起新请求。不要同时替换服务器、解析器和规则。
  4. 若日志显示已获得目标 IP，而后续连接超时，继续查出站路径与目标服务；若明确停在解析阶段，则检查解析器连接和域名本身。

不要用“直接在浏览器输入目标 IP”作为唯一验证方法。HTTPS 服务通常依赖域名、TLS 服务名及虚拟主机配置，直接访问 IP 可能产生证书错误或访问到不同内容。IPv4 与 IPv6 也可能具有不同的可达性，应依据日志中的地址类型定位，而不是长期关闭某一地址族来掩盖网络问题。

5. 按规则顺序核对 FINAL 与策略引用

在 Global Routing 为 Config 时，打开 Config 中实际启用的配置，检查规则顺序。常规分流规则按顺序匹配，前面的匹配可能让后面的规则没有机会生效。FINAL 是兜底规则，不能代替前面所有规则，也不能修复服务器认证失败。

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

以上仅用于说明语法，不是建议直接替换的完整配置。example.com 是示例域名；PROXY 必须对应当前配置中有效的代理策略或策略组。若该名称在配置中指向其他对象，应按实际定义检查，不应仅凭英文名称猜测最终出站。

修改前复制配置，随后只调整与失败目标相关的一处规则或策略，再重新启用并连接测试。若调整后恢复，仍需核对请求记录是否确实命中了预期规则；不要因为网页偶然打开，就将整套规则全部替换或永久改成 Proxy。

6. 根据错误记录复测并恢复设置

在应用内的连接记录或日志中，找到与复现时间、目标域名对应的请求，查看解析结果、策略和错误信息。下列是网络日志中可能出现的错误片段，实际文字可能带有地址或额外上下文；它们用于判断失败阶段，不是某个设置错误的一对一证明。

报错：connection refused

原因与解法：常见于目标端口拒绝连接，也可能由中间设备主动拒绝；先确认记录指向代理服务器还是目标站点，再核对对应地址、端口及服务监听状态。

报错：i/o timeout

原因与解法：某个网络操作在期限内没有完成，不能仅据此判断密码错误；根据同条记录中的连接阶段，分别对照接入网络、服务器或解析器，并重新测试。

报错：no such host

原因与解法：域名解析未取得可用结果，可能涉及域名拼写、记录状态或解析路径；先识别失败的域名，再核对地址与 DNS 设置，不要直接改动无关的规则。

如果没有清晰报错，可把“接入网络、服务器、Global Routing、目标域名、发生时间、现象”整理成一条记录。例如“Wi-Fi 下 Config 等待超时，保持服务器不变切到 Proxy 后同一页面可打开”比“已经连接但不能用”更有助于继续排查。这是记录格式，不是本文的实测结果。

  1. 恢复测试时临时改变的 Global Routing、DNS 与配置，只保留已通过对照确认必要的修改。
  2. 确认手动连接稳定后，再按原需求恢复 Settings → On Demand，并验证网络切换后的行为。
  3. 分别测试一个原本可直达页面与原先失败的页面，检查页面内的接口和资源是否也正常。
  4. 需要联系自己的服务提供方时，提供协议、端口、时间和脱敏错误记录；隐藏订阅完整地址、密码、密钥与账户标识。
App Store 正版核对