本文适合处理 Shadowrocket（小火箭）显示已连接、状态栏连接标记正常，但网页或应用仍无法访问网络的情况。排查顺序是先建立本地网络基线，再分别验证服务器、Global Routing、DNS 和 Config 规则；完成后可以根据对照现象确定故障位于哪一层，而不是同时修改多个设置。
先建立可重复的网络基线
“已连接”只说明 Shadowrocket 已在系统中建立网络通道，不等于通道内的每个环节都能正常传输。服务器不可达、认证信息失效、DNS 查询失败或 Config 中的规则选择了错误策略，都可能出现开关已打开但请求没有得到响应的现象。
开始排查前，先保存当前服务器名称、Global Routing 姿态和正在使用的 Config。一次只修改一个项目，每次修改后重新访问同一个测试页面。若同时更换服务器、DNS 与规则，即使网络恢复，也无法判断真正生效的是哪项改动。
验证原始网络
先关闭 Shadowrocket 连接开关，通过当前 Wi-Fi 或蜂窝网络打开两个此前未访问过的网页。若此时也无法访问，应先处理本地网络、路由器登录页或蜂窝数据权限。
记录当前设置
在 Home 记录已选服务器与 Global Routing，在 Config 记录已启用的配置名称，在 Settings → DNS 记录当前 DNS 项目，避免排查后无法恢复。
重新建立连接
返回 Home，关闭连接开关并等待数秒，再重新打开。系统若要求确认网络配置，应按系统提示完成授权，然后观察连接状态是否保持稳定。
执行对照测试
依次使用 Direct、Proxy 与 Config 进行测试，每次只切换 Global Routing，不更换服务器。三个结果的差异可以快速区分本地网络、服务器路径与规则问题。
第一层：确认服务器状态与参数
若关闭 Shadowrocket 后本地网络正常，而 Global Routing 设为 Proxy 后所有请求均失败，首先检查当前服务器。Home 中的延迟结果只能说明测试请求是否在限定时间内返回，不能单独证明实际业务流量一定可用；但持续超时、延迟空白或测试结果突然显著升高，仍是服务器路径异常的重要信号。
打开 Home 的服务器列表，对当前服务器执行可用性或延迟测试，再选择用户已有服务配置中的另一台服务器做对照。若同一网络下只有一台失败，问题通常集中在该服务器、端口或凭据；若全部失败，则继续检查订阅是否成功更新、本地网络是否限制了目标端口，以及 DNS 是否能解析服务器域名。
报错:Request timed out
原因与解法:请求在等待时间内没有收到响应，常见于服务器离线、线路丢包或目标端口不可达。先切换用户已有配置中的另一台服务器；若仅原服务器失败，向自己的服务商核对服务器状态与端口。
报错:Failed to resolve hostname
原因与解法:服务器地址使用域名，但当前 DNS 没有返回可用地址。进入 Settings → DNS 检查 DNS 设置，并确认服务器域名没有多余空格或拼写错误。
报错:Network is unreachable
原因与解法:设备当前没有可用的网络出口，或 Wi-Fi 尚未完成门户认证。关闭连接后访问普通网页验证原始网络，必要时先完成 Wi-Fi 登录，再重新打开 Shadowrocket。
报错:Failed to load subscription
原因与解法:订阅地址失效、访问超时或服务端没有返回有效内容。核对自己的链接，例如明显的格式示例 https://example.com/sub?token=xxxx，再向自己的服务商确认链接状态后回到 Home 下拉更新。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的参数结构不同，排查时不要把一种协议的端口、认证字段或传输设置套到另一种协议。订阅更新成功也不代表每个服务器都在线；它只表示 Shadowrocket 成功取得并解析了配置内容。
- 服务器地址使用域名时，先确认 DNS 能解析该域名。
- 服务器地址使用 IP 时，DNS 对建立服务器连接的影响较小，可优先检查端口和凭据。
- 同一服务器在 Wi-Fi 失败、蜂窝网络成功时，应检查当前 Wi-Fi 出口和路由器策略。
- 所有服务器在两种网络下都失败时，应核对订阅更新时间、账号状态和服务端状态。
第二层：用 Global Routing 定位流量去向
Global Routing 决定请求采用统一策略还是按 Config 匹配。Proxy 让请求统一采用代理策略，Direct 让请求直接连接，Config 按规则逐条判断，Scene 则依据预设场景选择行为。排障时最有价值的是 Proxy、Direct 与 Config 三组对照结果。
| 测试结果 | 优先判断 | 下一步 |
|---|---|---|
| Direct 成功，Proxy 失败 | 本地网络可用，服务器路径或服务器参数异常 | 测试其他已有服务器，核对服务器域名、端口与认证字段 |
| Proxy 成功，Config 失败 | 服务器可用，Config 规则或策略名称有误 | 检查规则顺序、策略组名称与 FINAL |
| Proxy 与 Config 成功，Direct 失败 | 目标在当前直连网络下不可达，或直连 DNS 结果异常 | 检查 DNS 返回结果以及 Config 中对应目标的策略 |
| 三种姿态全部失败 | 本地网络、系统网络权限或 DNS 基础设置更可疑 | 关闭连接验证原始网络，再检查 Settings → DNS |
| Scene 下失败，手动 Config 成功 | Scene 的触发条件或所选配置不符合当前网络 | 检查 Scene 对 Wi-Fi、网络状态和配置的判断条件 |
结论：先固定服务器，再比较姿态
同一台服务器下，Proxy 可访问而 Config 不可访问，已经能够把服务器故障的优先级降到较低；此时继续频繁换服务器只会增加变量，应直接检查规则命中与策略组名称。
若当前使用 Scene，排障阶段可暂时切换到手动的 Direct、Proxy 或 Config。待基本链路恢复后，再返回 Scene 检查触发条件。这样可以避免场景切换与规则匹配同时参与判断。
第三层：检查 DNS 解析是否中断
DNS 的任务是把域名转换为地址。DNS 失败时，常见现象是服务器延迟测试可能有结果，但输入域名后网页长时间停留；已经建立连接或命中缓存的少数应用可能暂时正常，因此“部分可用”不能排除 DNS 问题。
进入 Settings → DNS，先记录当前项目，再检查是否存在无法访问的 DNS 地址、错误的加密 DNS URL 或重复设置。传统 DNS 通常通过 UDP 或 TCP 53 端口工作，DNS over HTTPS 通常通过 HTTPS 443 端口工作；两者的网络路径不同，出现故障时应分开验证。
记录 DNS
打开 Settings → DNS，保存当前地址、协议方式及相关开关状态。若需要回退，应能恢复到排障前的配置。
检查格式
传统 DNS 应填写有效地址；DNS over HTTPS 应使用完整 HTTPS URL。删除行首行尾空格，并检查路径是否被截断。
减少变量
临时仅保留一个确认可访问的 DNS 项目进行测试，不要同时叠加多个未知结果。修改后重新连接，使新设置进入当前网络会话。
对比解析
分别测试此前从未访问过的域名与已访问域名。新域名失败而缓存页面可打开时，DNS 查询链路更值得优先检查。
查看请求结果
在 Shadowrocket 可见的请求或日志信息中查找 resolve、DNS、timeout 等提示，并记录失败域名，避免只依据浏览器的通用错误页面判断。
传统 DNS:
服务器地址 → UDP/TCP 53 → 返回 A 或 AAAA 记录
DNS over HTTPS:
HTTPS URL → TCP 443 → 加密查询 → 返回解析记录如果服务器本身使用域名，DNS 故障会发生在建立服务器连接之前；如果服务器使用 IP，但目标网站使用域名，则服务器连接可能成功，而网页请求仍因目标域名无法解析而失败。两种现象都可能显示连接开关已打开，但故障位置并不相同。
结论：区分服务器域名与目标域名
日志中若先出现服务器主机名解析失败，应处理建立连接前的 DNS；若服务器已经连通、只有访问目标域名时失败，则检查隧道内的目标解析路径与 Config 对 DNS 请求的处理。
第四层：检查 Config 规则顺序与 FINAL
当 Proxy 可以访问而 Config 无法访问时，重点转向规则。Shadowrocket 的 Config 通常按顺序匹配，先命中的规则先决定策略；FINAL 负责承接前面都没有匹配到的请求，因此它通常位于规则末尾。
以下片段表示指定域名后缀采用 PROXY，局域网地址与符合 GEOIP 条件的地址采用 DIRECT，其余请求由 FINAL 交给 PROXY。PROXY 必须对应当前 Config 中实际存在的策略或策略组名称；若配置使用了其他名称，应保持规则与策略名称完全一致。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：按域名后缀匹配，例如可覆盖主域名及其子域名。
- DOMAIN-KEYWORD：域名中包含指定关键字时匹配，范围通常比后缀规则更宽。
- IP-CIDR：按地址段匹配；附加 no-resolve 时，不为匹配动作额外发起域名解析。
- GEOIP：按目标 IP 的地理数据库结果匹配，因此通常需要先得到目标 IP。
- FINAL：处理此前未命中的剩余请求，缺失或策略错误可能造成未匹配流量行为不符合预期。
规则最常见的问题不是语法数量不足，而是顺序冲突。例如，宽泛的 DOMAIN-KEYWORD 位于精确的 DOMAIN-SUFFIX 之前，可能提前截获请求；覆盖范围较大的 IP-CIDR 位于目标规则之前，也可能让后续规则没有机会命中。
进入 Config，确认当前勾选的确实是正在编辑的配置。修改后保存并重新连接，再用 Config 姿态测试。若 Shadowrocket 的请求详情显示目标命中了 DIRECT，而预期应走 PROXY，应调整规则顺序或规则内容；若显示策略名称不存在，则应修正规则引用。
现象:Proxy 可用，Config 无法访问
原因与解法:服务器链路已经通过统一代理验证，Config 中可能存在错误的 DIRECT、REJECT 或策略引用。查看目标请求的命中结果，并从第一条相关规则开始检查顺序。
现象:只有部分域名无法打开
原因与解法:失败域名可能命中了范围过宽的 DOMAIN-KEYWORD，或没有被预期的 DOMAIN-SUFFIX 覆盖。记录完整主机名，增加精确规则并放到宽泛规则之前测试。
现象:配置修改后结果不变
原因与解法:可能编辑了未启用的 Config，或当前 Global Routing 仍停留在 Proxy、Direct、Scene。回到 Home 确认 Config 姿态与已选配置，再重新连接。
第五层：排除 On Demand、订阅与本地网络干扰
Settings → On Demand 可以根据网络条件触发连接。若手动关闭后立即再次连接，或切换 Wi-Fi 后姿态与预期不同，应暂时关闭 On Demand 做基线测试。确认手动连接正常后，再逐项恢复触发条件。
订阅更新也是独立环节。客户端能够打开不代表订阅地址当前有效，订阅成功更新也不代表其中每台服务器都可用。用户应以自己已有的服务商信息为准，核对订阅有效性、账号状态和服务器维护情况。
连接开关总会自动重新打开？
进入 Settings → On Demand，暂时关闭按需连接，再返回 Home 手动断开。若自动连接停止，说明触发来自 On Demand；随后检查 Wi-Fi、网络状态等条件，逐项恢复并测试。
Wi-Fi 下失败，蜂窝网络却正常？
先关闭 Shadowrocket，在该 Wi-Fi 下访问普通页面并确认是否需要完成门户登录。原始网络正常后，再固定同一服务器与同一 Global Routing 姿态测试，以判断当前 Wi-Fi 是否限制目标路径。
订阅更新成功，为什么仍然连不上？
更新成功只表示配置内容已被取得并解析。回到 Home 对具体服务器执行测试，并在 Proxy 姿态验证实际请求；若多台服务器结果不同，应分别记录，不要把订阅更新状态等同于服务器在线状态。
Direct 能用，Config 和 Proxy 都不能用？
本地网络基础连接大概率正常。先固定一台服务器，用 Proxy 验证服务器链路；若 Proxy 失败，检查服务器状态、域名、端口和认证信息，暂时不要修改 Config 规则。
只有一个应用无法联网怎么办？
先确认该应用在关闭 Shadowrocket 时能否联网，再查看其请求域名与规则命中结果。若其他应用在相同姿态下正常，应重点检查目标域名、IP-CIDR、REJECT 规则和该应用自身的网络权限。
还可以检查系统时间是否准确。部分协议依赖 TLS 或带有时间相关校验，设备时间偏差过大可能导致握手失败。应使用系统自动设置日期与时间，再重新建立连接。切换 Wi-Fi 与蜂窝网络后，也建议断开并重连，使路由与 DNS 会话重新建立。
按结果收束排查并恢复设置
完成上述测试后，应把结果写成“网络条件 + 服务器 + Global Routing + DNS + Config”的组合。例如：“同一 Wi-Fi 下，Direct 成功，固定服务器在 Proxy 超时，切换另一台已有服务器后恢复。”这种记录能明确指出问题位于服务器路径，而不是笼统描述为无法上网。
若需要向自己的服务商反馈，提供发生时间、网络类型、服务器名称、协议类型、端口、错误原文和对照结果即可。订阅链接中的 token、密码、Private Key 等认证信息不应出现在截图或公开记录中。
- 原始网络失败：先处理 Wi-Fi、蜂窝网络或门户认证。
- Direct 成功、Proxy 失败：检查服务器状态、端口、认证与服务器域名解析。
- Proxy 成功、Config 失败：检查规则顺序、策略名称、FINAL 与当前启用的 Config。
- 域名失败但已有连接仍工作：检查 Settings → DNS 及解析错误。
- 手动设置正常、自动场景失败：检查 Settings → On Demand 与 Scene 条件。
- 恢复后将临时姿态、DNS 与测试规则还原到经过确认的配置。
Shadowrocket 仅通过 App Store 提供，产品页开发者应显示为 Shadow Launch Technology Limited，应用 ID 为 932747118。iPhone 与 iPad 是主要使用设备，兼容范围及系统要求以 App Store 页面标注为准。重新安装前应先确认配置备份与已购恢复方式，避免把重装当作第一步排障操作。