本文适用于已经安装 Shadowrocket（小火箭）、持有自己的服务商配置或订阅、能够打开连接开关但访问失败的用户。排查从关闭连接后的基础网络开始，再依次核对 Home 中的服务器、Global Routing、DNS 与 Config 中的 Rule。每次只改变一项，使用同一个目标复测，最终把问题定位到基础网络、代理连接、域名解析或分流策略，而不是反复重装应用。
一、区分 VPN 已启动与目标已连通
连接开关开启、系统显示 VPN，说明系统已经建立供应用处理流量的通道，并不证明远端服务器已完成认证，也不证明目标网站能够访问。服务器地址无法解析、端口不通、认证参数失效或请求被规则拒绝，都可能发生在开关开启之后。
先选两个平时能够访问、用途不同的网页作为测试目标，记录是全部打不开、只有某个域名打不开，还是网页能打开但部分资源加载失败。不要把单个网站的故障直接判断为所有网络都不可用，也不要同时切换服务器、DNS 和配置文件，否则无法知道哪一项改变了结果。
-
关闭连接
回到 Home，关闭连接开关，用浏览器访问选定的两个目标。如果仍失败，先处理 Wi-Fi 登录、蜂窝数据权限或当前网络本身的问题。
-
暂停自动连接
进入 Settings → On Demand，记录原有设置后暂时关闭自动触发，避免手动关闭后又被系统重新连接。排查结束再恢复原设置。
-
固定测试条件
先固定一种网络与一台用户已有的服务器，记录 Home → Global Routing 当前选项，以及 Config 中实际启用的配置文件。
-
连接后复测
重新开启连接，以相同浏览器访问相同目标。需要比较 Wi-Fi 与蜂窝数据时，将网络切换作为单独的一轮测试，不同时修改其他设置。
二、核对 Home 服务器与实际连接错误
在 Home 中确认当前选中的条目确实是准备测试的服务器，而不是仅看订阅分组名称。打开该条目的编辑页面，对照用户已有的服务商资料检查地址、端口、协议与认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的参数结构不同，不能把一个协议的字段直接套给另一个协议。
端口必须与服务端配置一致。使用 TLS 的服务还要核对服务商给出的 Server Name 等参数；不要通过关闭证书验证来掩盖错误。设备日期与时间不正确也可能影响证书验证，应先恢复正确时间。订阅更新后条目可能变化，需再次确认当前选择，不要仅凭旧条目的名称判断配置仍然有效。
- 可以先使用 Home 的 Connectivity Test 收集线索，但测试结果取决于测试方式和测试目标，不能把延迟数值当作网页一定可用的证明。
- 如果 TCP 连接可建立但真实请求失败，继续核对认证与 TLS 参数；能接通端口和能成功传输应用流量是两个阶段。
- 仅 Hysteria2 或 WireGuard 条目在某个网络失败时，要检查该网络及服务端的 UDP 可达性；这些协议不能只用 TCP 测试结果判断。
- 若已有订阅内容发生变更，使用原订阅的更新功能获取最新参数。不要自行猜测端口或密码，也不要公开订阅 URL、密钥和完整日志。
以下是网络日志中可能出现的错误字符串示例，不是固定弹窗标题；具体措辞会随协议与底层错误变化。只有实际记录出现相应信息时，才按该分支处理。
报错: connection refused
原因与解法:目标端口的连接被拒绝，可能是服务未监听或网络设备主动拒绝；先核对服务器地址与端口，再向自己的服务商确认服务状态，不要先调整域名规则。
报错: i/o timeout
原因与解法:某个读写阶段在限定时间内未完成，错误本身不说明是 DNS 还是服务器；结合前后日志确认超时目标，并在另一种基础网络上用同一配置复测。
报错: no such host
原因与解法:所查询的主机名未能得到可用解析结果；先辨认这是服务器域名还是网页域名，检查拼写和解析路径，避免把服务器域名解析失败误当成 Rule 故障。
三、用 Global Routing 隔离分流问题
进入 Home → Global Routing，记录当前的 Proxy、Direct、Config 或 Scene。Proxy 用于按代理姿态处理流量，Direct 用于直接连接，Config 按启用的配置进行分流，Scene 按所选场景设置工作。排查时必须知道当前处于哪一种姿态；只在 Config 中修改 Rule，却一直使用其他姿态，可能看不到预期变化。
| 选项 | 本轮用途 | 观察后的下一步 |
|---|---|---|
| Direct | 比较直接连接路径是否可用 | 若失败，与关闭连接的结果对照，检查基础网络及解析设置。 |
| Proxy | 在同一服务器下测试代理路径 | 若两个目标都失败，优先检查服务器、认证与解析，不急着重排 Rule。 |
| Config | 测试当前配置的分流结果 | 若 Proxy 可用而 Config 对同一目标失败，查看命中规则与最终策略。 |
| Scene | 核对场景实际采用的设置 | 先确认当前场景；隔离问题时暂时使用明确的 Proxy 或 Config 进行比较。 |
结论:先固定代理路径再查规则
同一网络、同一服务器、同一目标在 Proxy 下成功而在 Config 下失败时，下一轮只检查 Config 的命中策略与相关解析设置，不要同时换服务器。这个对照缩小了范围，但仍需结合请求记录确认原因。
Global Routing 的切换是诊断手段，不是永久解决方案。测试时已有长连接可能继续沿用旧连接，切换后应重新发起请求，必要时关闭并重新打开连接。结束后恢复原来的姿态，尤其不要把临时使用的 Proxy 当作已修复原有分流配置。
四、辨认 DNS 故障发生在哪一层
DNS 排查先回答“哪个域名解析失败”。服务器地址若是域名，需要先获得服务器 IP 才能建立代理连接；网页域名则可能在后续请求阶段解析。两个阶段都可能显示超时，但处理顺序不同。先让服务器地址可解析，再检查目标域名，不要期待一条尚未建立的代理连接替自己完成所有前置解析。
这些是解析方式的常用端口，不是让用户把服务器端口改成其中之一。使用加密 DNS 仍需要解析服务器可达；若解析端点只有代理建立后才能访问，又用它解析代理服务器域名，就可能形成依赖循环。DNS 地址写对了，也不等于当前网络一定允许访问。
- 记录 Settings → DNS 中现有设置，并核对 Config 中当前配置是否包含
[General]的dns-server项。若有多个配置来源，先确认实际生效来源，不要只改一个未启用的文件。 - 查看失败请求是否已有目标 IP、是否出现解析错误，以及失败发生在服务器连接前还是目标请求阶段。已有 IP 后才出现连接超时，不能仅凭网页打不开就判定 DNS 失败。
- 如曾手动设置 DNS，保存原值后，仅对这一项恢复原先可用的设置进行对照。保持服务器和 Global Routing 不变，重新建立连接后复测。
- 如果仅在某个 Wi-Fi 下解析失败，换到蜂窝数据做单变量对照；结果不同说明网络环境参与了故障，但还不能直接推断是哪一台设备阻断。
五、检查 Config 中 Rule 的命中顺序
当代理路径可用、Config 下却有特定目标失败时，打开 Config 中实际启用的文件，检查 [Rule]。规则按顺序检查，先命中的规则决定相应策略；具体域名规则通常放在宽泛规则前，FINAL 放在末尾。修改前先保存原文件副本，修改后确认应用的仍是这个文件。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY上例只展示语法与顺序，不是建议直接替换现有配置。example.com 是示例域名；DOMAIN-SUFFIX 匹配该域及子域，IP-CIDR 匹配地址段，GEOIP 依据 IP 的地域信息，FINAL 接住此前未命中的请求。no-resolve 表示该 IP 规则不为匹配而主动进行域名解析，不代表所有 DNS 都被关闭。
- 检查先后:目标若已经命中前面的 DIRECT，末尾的 FINAL 不会再把它改成 PROXY。新增例外时，要放到造成覆盖的规则之前。
- 检查策略:如果规则指向自定义策略名称，确认对应策略存在，且最终选择的服务器可用。组名看起来正确并不证明组选中的条目可用。
- 检查拒绝:命中 REJECT 的请求会被拒绝；若网页主体正常而某个必要资源失败，应核对该资源自身的域名和策略，不只检查地址栏域名。
- 检查 IP 规则:GEOIP 与 IP-CIDR 依赖请求可用的 IP 信息。域名解析结果变化会影响命中，不要把一次观察当作永久固定结果。
定位规则后，只修改与失败目标有关的最小范围，再重复原来的测试。不要为了让一个网页打开就删除全部规则；这样可能暂时改变访问结果，却失去判断原始故障的依据。规则字段的完整说明可对照配置字段手册。
六、常见现象与恢复操作
有延迟数值，为什么网页还是打不开？
延迟测试只反映特定测试的响应，不覆盖全部认证、TLS、DNS 与目标请求。保持同一服务器，在 Home → Global Routing 切到 Proxy 后访问原目标，再结合请求错误判断是握手失败还是目标连接失败。
Wi-Fi 能用，蜂窝数据不能用，先改什么？
先关闭连接确认蜂窝网络自身可访问，再检查系统对 Shadowrocket 的蜂窝数据权限。之后使用同一服务器与模式复测；若只有依赖 UDP 的配置失败，向自己的服务商核对该网络下的连接条件，不随意修改协议字段。
只有某个网站打不开，要重新安装吗？
先比较该目标在 Proxy 与 Config 下的表现，并检查失败资源的域名、命中规则与最终策略。若两个姿态都失败而其他网站正常，还需考虑目标服务状态、远端出口到目标的路径及该网站自身的访问条件。
关闭开关后又自动连接，怎么排查？
到 Settings → On Demand 暂时关闭自动触发，再做关闭连接的基线测试。完成排查后恢复原设置；不要把自动连接行为误判为开关失效，也不要为此先删除系统 VPN 配置。
最后恢复临时修改的 Global Routing、DNS 与 On Demand，仅保留已经通过对照验证的修正。如果仍失败，向自己的服务商提供发生时间、网络类型、协议、脱敏后的错误原文，以及 Direct、Proxy、Config 三轮测试的差异。隐去密码、UUID、密钥与订阅 token；这些信息比“开关已打开”更能帮助定位连接阶段。