2026-10-16 · 故障排查 · 约 10 分钟

小火箭开关打开却上不了网:服务器、模式、DNS、规则逐项排查

连接开关已开但网页打不开时,依次检查服务器状态与参数、Global Routing 姿态、DNS 设置和规则命中,逐步缩小故障范围。

本文速览

本文适合已在 Shadowrocket（小火箭）导入自己的服务器或订阅、但打开连接开关后仍无法访问网页的用户。排查顺序是确认基础网络、验证选中的服务器、对照 Global Routing、检查 DNS，最后核对规则与自动连接条件。每次只改一个变量，用同一个目标复测，区分“隧道已启动”和“目标请求已成功”。

一、先确认故障范围，不把连接开关当成连通结果

Home 的连接开关和系统 VPN 状态表示隧道已启动，并不证明远端服务器能够连接、凭据有效，或每个网站都能正常响应。浏览器一直等待、立即提示找不到服务器、只有某个网站失败，是不同层面的现象，不能都归为服务器故障。

先暂停自动连接干扰，再比较关闭与开启连接时的表现。若关闭后普通网页同样无法访问，应先解决 Wi-Fi、蜂窝数据或当前网络的登录认证问题；此时反复更新规则通常没有帮助。公共 Wi-Fi 如需完成网络登录，应先完成认证再测试。

  1. 暂停自动连接

    进入 Settings → On Demand，记录原设置并暂时关闭按需连接，返回 Home 关闭连接开关。避免手动断开后又被自动连接，使对照结果失真。

  2. 验证基础网络

    在浏览器打开平时能够访问的网页，确认当前 Wi-Fi 或蜂窝数据本身可用。不要用一个本来就无法直连的目标作为唯一判断依据。

  3. 确认选中项目

    在 Home 核对选中圆点所在的服务器，记下名称与协议。列表中存在服务器，不等于当前实际选中的就是该服务器。

  4. 执行连接测试

    打开连接，使用 Home → Connectivity Test，并记录所用测试方式及结果。测试成功后，再访问原来失败的网页；测试请求与目标网页不是同一个请求。

  5. 固定复测条件

    记录网络类型、Global Routing 当前姿态、测试目标及错误文本。之后每次只改一项，复测同一地址，再决定是否保留修改。

二、核对服务器参数与订阅状态

服务器地址、端口、协议与认证参数必须组成同一套有效配置。先在 Home 打开当前服务器的编辑界面，对照从你的服务商处获取的原始信息，逐项检查。不要为了尝试连通，把所有端口统一改成 443，或把不同协议的字段互相套用。

443
常见 HTTPS 端口；代理端口仍以服务商参数为准
53
传统 DNS 常用端口；不能据此判断 DNS 一定可达
1 项
每轮只修改一个变量，保留可比较的测试结果

如果项目由订阅生成，先更新对应订阅，再核对服务器是否被删除、改名或替换。订阅从你的服务商处获取。更新失败只能说明本次获取订阅内容没有成功，不能直接推断已经导入的所有服务器都失效；更新成功也不等于每个服务器都通过了连接验证。

客户端买断 ≠ 线路套餐。Shadowrocket 是闭源商业应用，购买客户端不会自动建立服务商账户、补充服务额度或延长订阅有效期。账户状态与服务器维护情况，需要向自己的服务商确认。

三、用 Global Routing 对照区分模式与规则问题

在 Home → Global Routing 核对当前姿态。Config 使用当前启用的配置进行规则分流；Proxy 用于统一走代理的对照；Direct 用于统一直连的对照。若当前使用 Scene，还要检查所选场景的设置，不能仅凭场景名称判断最终走向。以下三项是本次排错的对照条件，不是全部姿态清单。

对照设置观察现象下一步检查
Direct原本可直连的网页也打不开基础网络、DNS，以及隧道内仍生效的相关设置
Proxy多个测试目标均失败选中的服务器、认证、传输参数及网络可达性
Proxy 与 Config同一目标在 Proxy 成功，在 Config 失败规则命中、策略指向、当前启用的配置及 DNS 差异
Config只有少数域名失败具体域名及其依赖域名的匹配结果，不先替换全部配置

做对照时必须保留相同的服务器、网络和目标地址。若切换模式的同时又更换服务器，即使网页恢复，也无法确定是哪一项起作用。切换后重新发起请求；已有长连接可能继续沿用旧路径，必要时关闭并重新打开测试页面。

四、检查 DNS：把解析失败与连接失败分开

DNS 负责把域名解析为地址。解析失败时，连接可能还没有到达目标服务器；解析成功后，仍可能在连接、TLS 或应用响应阶段失败。若服务器本身使用域名，其地址解析也属于连接链路的一部分，因此 DNS 故障有时会表现为代理服务器不可达。

发起域名请求 域名解析 规则与策略 出站连接 目标响应

这条流程用于划分检查环节，不代表所有请求的固定内部执行顺序：某些域名规则可以先匹配，地址类规则可能需要解析结果，而远端解析也会改变解析发生的位置。排错时应看实际请求记录，而不是仅凭流程图推定客户端行为。

不要把“直接在浏览器输入网站 IP”作为 HTTPS 是否正常的唯一测试。HTTPS 通常依赖域名对应的证书和服务器名称，直接访问 IP 可能触发证书错误或进入其他站点。更可靠的做法是保留原域名，分别观察解析结果、连接地址与握手结果。

五、核对 Config 规则顺序和实际策略

当 Proxy 可以访问、Config 不能访问时，优先检查 Config 中实际启用的规则，而不是只看保存了哪些文件。常规规则按顺序匹配，先命中的规则决定策略；范围过大的前置规则，可能使后面的精细规则没有机会生效。FINAL 是兜底规则，应检查它最终指向哪里。

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

上面是用于解释语法的片段，不是可直接覆盖现有配置的完整文件。example.com 和 192.0.2.0/24 是文档示例；PROXY 的有效指向需要在实际配置中核对。不要把片段中的策略名称当成已经验证可用的服务器。

复现一次失败请求后，查看可用的请求或日志记录，核对域名、命中规则、最终策略和错误。首页能打开但登录失败时，单独检查登录接口的域名；页面文字出现但图片不加载时，检查图片资源请求。一个网页包含多个连接，不能用其中一个请求成功代替整页验证。

六、按错误原文决定下一步，不凭一个词下结论

以下是网络日志中常见的错误片段，并非每次故障都会显示，也不是所有界面的固定提示。应保存实际出现的完整文本及其上下文，确认失败对象究竟是代理服务器、DNS 解析器还是目标网站，再采用对应检查方法。

报错：connection refused

原因：该次连接被明确拒绝，常见于端口未监听或访问被主动拒绝。解法：核对报错对应的地址和端口，再向自己的服务商确认监听状态；不要直接认定是密码错误。

报错：i/o timeout

原因：某一步操作在时限内未完成，可能涉及网络丢包、服务器无响应或后续连接停滞。解法：先确定超时发生的阶段，再用同一服务器和目标对照 Wi-Fi 与蜂窝数据。

报错：no such host

原因：相关域名没有获得可用解析结果，可能是地址填写错误或解析问题。解法：核对错误中提到的完整域名，确认它属于服务器、解析器还是目标网站，再检查对应 DNS 路径。

报错：certificate has expired or is not yet valid

原因：证书有效期与当前时间不符，可能是远端证书过期，也可能是设备时间异常。解法：核对设备日期时间和服务器名称；若远端证书异常，交由对应维护方处理，不以关闭证书验证作为常规修复。

如果没有明确错误文本，也可以提交最小复现记录：使用哪种网络、选中什么协议、Global Routing 是什么姿态、Connectivity Test 使用什么方式、哪个目标失败，以及关闭连接后是否恢复。分享记录前移除密码、UUID、私钥和订阅链接中的 token，不公开完整配置凭据。

七、复测并恢复 On Demand，保留有效结论

恢复访问后，先在当前网络下重新验证，再切换另一种网络验证。只在蜂窝数据成功、Wi-Fi 失败，通常需要进一步检查该 Wi-Fi 的访问条件；只在某一个服务器失败，则应继续聚焦该服务器参数或状态。两种结果都比“重开一次就好了”更适合后续定位。

若需要核对客户端来源，Shadowrocket 仅在 Apple 平台发行，以 iPhone / iPad 为主，唯一获取入口是 App Store。开发者为 Shadow Launch Technology Limited，采用一次性买断；系统要求以 App Store 页面标注为准。重新获取客户端不能替代服务器、DNS 和规则排查，操作前应妥善保留自己的配置。

App Store 正版核验