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

本文速览

本文适用于 Shadowrocket（小火箭）已开启连接、但浏览器或部分应用无法访问的情况。以用户已有自己的服务商与配置为前提，依次建立直连基线、核对服务器、切换 Global Routing 做对照，再检查 DNS 与规则命中。每次只改一项，记录同一网页的结果，最后恢复原有设置。

一、先区分 VPN 已启动与目标网页可达

Home 的连接开关打开，说明本机 VPN 连接已启动，不等于远端服务器认证成功，也不等于目标网站可以访问。系统中的 VPN 标识同样不能证明 DNS、服务器出口和规则策略都正常。不要只凭开关状态判断故障位置。

先选一个平时在当前网络能够直接打开的网页作为对照，再选一个出现故障的网页。后续始终测试这两个目标。测试时重新加载页面，必要时关闭原标签页后重新打开，避免把已经显示的缓存页面当作本次连接成功。

4 项

固定顺序：服务器 → 模式 → DNS → 规则

1 项

每轮只修改一个变量，测试后记录结果

2 个

固定测试目标：直连对照页与故障页

记录现状

在 Home 记下已选服务器与 Global Routing 模式；在 Config 记下当前选中的配置文件。修改配置前保留副本，记录原有 DNS 设置。
检查自动连接

进入 Settings → On Demand，记录当前设置。若它会在测试期间重新触发连接，可暂时关闭，完成排查后恢复。
建立直连基线

回到 Home 关闭连接开关，确认连接确实停止，再打开直连对照页。若仍失败，先检查当前 Wi-Fi 是否需要登录，以及蜂窝数据是否可用。
重现故障

重新开启连接，保持原服务器、原模式和原配置，再访问两个测试目标。记录是全部失败，还是只有某个域名或应用失败。
固定测试条件

先在同一个网络完成服务器与模式检查。需要切换 Wi-Fi 和蜂窝数据时，把它作为单独一轮测试，不要同时更新配置或更换服务器。

二、服务器检查：先看可达性，再核对认证字段

在 Home → SERVER 核对当前选中项，再运行 Connectivity Test。延迟结果只能说明该测试方式下收到了响应。不同测试方式覆盖的链路不同，一次数值不能证明所有域名、所有传输方式或完整业务请求都正常。

如果全部服务器都超时，先回看直连基线与当前网络；如果仅一个服务器失败，再核对该项的地址、端口与协议字段。地址可以是域名，域名本身也需要解析，因此服务器连接超时并不一定是远端停止服务。

地址与端口：打开所选服务器的编辑页，与自己的服务商提供的信息逐项比对。端口 443 常用于 HTTPS，但服务器是否使用它必须以实际配置为准，不能看到 TLS 就把端口改成 443。
认证字段：Shadowsocks 的密码与加密方式、VMess 和 VLESS 的 UUID、Trojan 的密码应分别核对。不能只保留地址与端口就认为导入完整。
传输字段：使用 TLS、WebSocket 等配置时，核对 TLS 服务名、Host 与 Path。它们可以与服务器地址不同，应按原始配置填写，而不是自行统一。
订阅内容：如果服务商明确说明配置已变更，再更新自己已有的订阅。更新后重新核对选中项；更新成功只说明取得配置，不代表其中每个服务器均可用。

日志原文可以辅助定位失败阶段。下面列出常见网络错误片段；不同协议和系统环境可能在片段前后附加地址或错误域。只在实际日志出现相应文本时使用对应判断，不要把浏览器的空白页直接归类为某一种错误。

报错：connection refused

原因与解法：连接被目标或中间设备明确拒绝，常见于端口未监听或地址、端口不符。先核对服务器地址与端口，再向自己的服务商确认该入口状态；此报错不能单独证明密码错误。

报错：connection timed out

原因与解法：连接在等待时间内未完成，可能涉及网络路径、端口过滤或服务器无响应。先测试同一配置在另一网络下的表现，再与已有的另一可用服务器做单变量对照。

报错：certificate verify failed

原因与解法：TLS 证书校验未通过，可能涉及设备时间、服务名不匹配或证书链异常。检查系统日期与配置中的 TLS 服务名，再由服务商核对证书；不要把关闭校验当作常规修复。

三、Global Routing：用模式对照缩小范围

在 Home → Global Routing 查看当前模式。排查时，Proxy 与 Direct 可以帮助区分代理路径和直连路径；日常配置使用 Config 时，还需要检查配置中的具体规则。Scene 则要结合选中的场景设置判断，不能只看名称推断流量去向。

模式	检查用途	结果如何理解
Proxy	让普通目标请求走当前代理策略，作为短时对照。	Proxy 可用而 Config 失败时，优先检查规则与策略选择，但仍需核对 DNS 路径差异。
Direct	让目标连接直接访问，观察当前网络能否直达。	Direct 可用而 Proxy 失败时，优先检查服务器与代理链路；不能据此认定所有目标都应直连。
Config	依据当前选中配置的规则分流。	核对 Config 中的选中文件、规则顺序，以及规则指向的策略是否可用。
Scene	依据当前场景设置处理路由。	检查场景实际选择及其配置；需要排除场景影响时，记录原值后临时使用明确的对照模式。

判断：Proxy 成功后回查 Config

同一服务器、同一网络、同一目标在 Proxy 下成功而 Config 下失败时，先回到 Config 查实际命中规则与策略，不要立即重建全部服务器；对照完成后恢复原模式。

模式切换后重新发起请求。浏览器或应用可能保留原有连接，只刷新界面不一定建立新连接。若仅某个应用异常，可先完全退出该应用再重新打开，并对照浏览器中的同一服务，区分应用缓存与连接路径问题。

四、DNS 检查：有延迟不等于域名能解析

DNS 负责把域名解析成地址。服务器可连接、Connectivity Test 有结果，与目标域名解析成功是不同的事实。即使取得地址，返回了不可达的 IPv6 地址、错误地址或不符合当前网络的结果，也可能继续表现为网页超时。

进入 Config，打开当前选中的配置并查看 DNS 相关设置。先记录解析器地址、是否使用加密 DNS，以及解析请求所依赖的网络路径。不要只检查一个未被选中的配置文件，也不要同时改 DNS 与服务器，否则无法判断哪一步起作用。

检查地址格式：普通 DNS 通常使用端口 53；DoH 通常通过 HTTPS 的 443 端口访问。配置了不同端口时以实际服务要求为准。端口正常也不代表协议与地址格式正确。
检查解析器可达性：解析器若只能经某条代理路径访问，而代理服务器的域名又依赖该解析器才能解析，就可能出现启动依赖问题。应对照配置原始说明检查解析路径，不要反复开关连接。
检查失败范围：多个无关域名都出现解析错误，优先检查解析器；只有一个域名失败，记录完整域名与返回现象，再检查该域名的规则和目标服务。
检查变更是否生效：保存配置后重新连接，并重新打开测试应用。DNS 缓存会影响观察，不要把旧连接仍能访问当作新设置已通过验证。

五、规则检查：确认实际命中，而不是只搜索 REJECT

回到 Home 将 Global Routing 恢复为 Config，再在 Config 核对当前选中的文件。规则通常按顺序检查，先命中的规则决定该连接的处理策略。文件里出现 REJECT 不代表所有请求都会被拒绝；只有目标实际命中相关规则时才构成解释。

下面是语法教学片段，不是完整配置，也不建议直接替换现有规则。示例域名与文档示例地址仅用于说明字段：第一列是规则类型，第二列通常是匹配条件，最后一列是策略；FINAL 没有匹配条件字段。

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

DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,REJECT 会匹配 example.com 及其子域名。若真实业务域名命中同类规则，单独更换服务器通常不会改变被拒绝的结果。
IP-CIDR：按目标 IP 网段匹配。示例中的 192.0.2.0/24 是文档示例网段；no-resolve 表示不为了这一条匹配主动进行域名解析，不能解释为“整份配置关闭 DNS”。
GEOIP：依据目标 IP 的地理归属数据匹配，不是按网页语言或域名后缀判断。解析结果变化可能影响后续 IP 类规则的匹配。
FINAL：处理前面未命中的连接。示例指向 PROXY；实际配置若使用自定义策略组，还要检查该组当前选择，而不只是规则末尾的名字。

通过应用的请求记录或日志核对故障域名、命中规则和最终策略。网页常同时访问主域名、登录域名与静态资源域名；主页面可以打开而登录按钮无响应时，要检查失败的具体请求，不能只查地址栏中的主域名。

六、常见追问：局部失败、自动连接与恢复设置

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

延迟测试与网页访问不一定使用同一目标和完整路径。先在 Home 核对已选服务器，再用 Proxy 测试故障网页；若仍失败，检查服务器认证与 DNS。不要把延迟数值当作网页可用性证明。

只有一个网站打不开，还要换服务器吗？

先记录该网站的具体失败域名，并对照 Proxy 与 Config。只有 Config 失败时，优先检查该域名的命中规则；两种模式都失败时，再检查解析结果、目标服务状态与代理出口路径。

关闭开关后为什么又自动连上了？

进入 Settings → On Demand 检查是否配置了自动触发条件。排查时记录原值后暂时关闭，再回到 Home 确认连接停止；测试结束恢复原有设置，避免把自动重连误判成开关失效。

换成蜂窝数据就正常，说明服务器没问题吗？

这说明同一配置至少在另一网络下可用，故障范围更接近原网络路径。回到原 Wi-Fi 检查联网认证、解析器可达性与端口限制；保持相同服务器和模式复测，不能据此保证所有网络都能连接。

七、验证恢复：留下可复查的结果

成功标准不是开关重新变亮，而是原先失败的目标能在预期模式下完成请求。恢复日常使用的 Global Routing、配置文件与 On Demand 设置后，再测一次直连对照页和故障页。若恢复原设置后问题重现，说明临时对照绕过了问题，并未完成修复。

记录最终可用的网络类型、选中服务器、配置文件和 Global Routing 模式。
重新打开发生故障的应用，验证页面加载、登录或资源请求，而不只验证首页标题出现。
确认临时 DNS 改动、规则例外和自动连接设置均符合日常需求，保留修改前的配置副本。
仍需向自己的服务商反馈时，提供失败时间、协议类型、错误片段与模式对照结果；隐藏密码、UUID、订阅令牌等敏感字段。

Shadowrocket 是 Apple 平台的付费客户端，唯一获取入口为 App Store，开发者为 Shadow Launch Technology Limited。客户端买断 ≠ 线路套餐。本文排查以用户已有配置为基础，不提供、不销售、不推荐节点、订阅或服务商。系统要求以 App Store 页面标注为准。