Shadowrocket（小火箭）的连接开关打开，表示系统网络隧道已启用，不等于服务器、DNS 和目标网站都已连通。本文适用于已有自己的服务商与订阅、已完成导入但访问失败的用户。按“基础网络 → 服务器 → Global Routing → DNS → Rule”的顺序，每次只改一个设置，可把问题缩小到具体环节；排查结束后恢复原配置，不把临时测试设置长期保留。
开始前：固定测试条件，确认基础网络
先区分“所有网页打不开”和“只有一个域名失败”。前者需要先检查基础网络与服务器，后者还可能涉及目标网站、域名解析或某条规则。不要只凭系统 VPN 标记判断网络正常，也不要把一次延迟测试成功当成全部请求成功。
-
记录当前状态
在 Home 记录当前选中的服务器与 Global Routing 值，再到 Config 记录当前启用的配置文件。保留原配置副本，记下失败域名、发生时间，以及使用 Wi-Fi 还是蜂窝网络；分享记录前遮住密码、订阅地址和身份凭据。
-
暂停自动连接
进入 Settings → On Demand，记录原设置后暂时关闭按需连接，再关闭 Home 的连接开关。这样可避免测试基础网络时，网络条件变化又触发隧道连接。
-
测试基础网络
在连接关闭时，打开平时能够直接访问的网页。若仍失败，先完成 Wi-Fi 登录认证、检查蜂窝数据权限或更换网络；此时不应先修改 Rule 或 DNS。
-
固定测试请求
基础网络正常后重新连接，每轮测试使用相同的完整网页地址。分别记录是否出现解析错误、连接超时或证书错误，而不是只记录“打不开”。切换 Wi-Fi 与蜂窝网络时，单独记为另一轮测试。
关闭隧道后能够访问，只能说明直接访问路径在当时可用；它不能证明原服务器正常。相反，某个目标在直接访问时失败，也不能单独证明基础网络断开，应另选一个已知可直接访问的目标作对照。
第一步：Home 核对服务器与连接参数
在 Home 确认当前选中的是预期服务器，再打开该条目的编辑页面，逐项对照自己的服务商提供的资料。地址、端口、Type 和认证信息必须成套匹配。端口为 443 并不自动代表参数正确，协议也不能仅凭端口推断。
- 地址与端口：检查多余空格、拼写以及端口是否被误填。服务器地址使用域名时，建立连接前还需要先解析这个域名。
- 协议与认证：Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的参数结构不同，应使用对应 Type，并按已有资料填写，不把一种协议的字段直接套到另一种协议。
- TLS 相关字段：对使用 TLS 的连接，核对服务商给出的 SNI、证书名称与传输参数。连接地址与证书名称可能不同，不应擅自把两者改成同一个值。
- 订阅状态：若条目来自订阅，先在 Home 更新自己的订阅，再核对当前选中的条目是否仍有效。更新订阅与启用 Config 中的配置文件是两件事，不能互相替代。
执行 Home 中的连通性或延迟测试时，要同时看所用测试方式和结果。TCP 建连成功只能说明相应地址与端口在测试时可建立连接，不会完整验证认证、TLS、转发和目标网站响应。已有多个服务器时，可在其他设置不变的前提下换一个已有条目做对照。
报错：connection refused
原因与解法：连接被目标主机或中间设备明确拒绝，可能是端口未监听或连接被拒绝。先核对地址与端口，再向自己的服务商确认该入口状态；不要先改 DNS 或规则来处理端口拒绝。
报错：i/o timeout
原因与解法：某项网络操作未在规定时间内完成，原因可能在解析、建连或后续读写阶段。结合报错附近的地址与操作判断位置，再用另一种网络测试同一条目；超时本身不能直接证明密码错误。
报错：no such host
原因与解法：域名解析未得到可用结果。先辨认报错指向服务器域名还是目标网站域名，再核对拼写与 DNS 设置；不要在未识别域名的情况下同时修改服务器和配置文件。
以上是网络日志中可能出现的错误原文，不保证每个界面都显示相同文字。检查时应保留实际错误和上下文；只截取一个“timeout”，容易把服务器连接失败与网站响应缓慢混为一谈。
第二步：Global Routing 区分 Proxy、Direct、Config、Scene
在 Home → Global Routing 核对当前模式。服务器选对了，但请求没有走预期路径，同样会出现开关已开却访问失败。测试时先固定服务器，再逐个比较模式，不要同时切换服务器、DNS 与配置文件。
| 模式 | 排查时怎样理解 | 需要核对什么 |
|---|---|---|
Proxy | 以代理路由作对照，减少 Rule 分流对测试的影响。 | 选中服务器、连接参数与目标响应；它不是“所有其他设置都被清空”。 |
Direct | 以直接访问路径作对照，不通过代理服务器转发请求。 | 本地网络能否访问测试目标；它不完全等同于关闭系统隧道。 |
Config | 按当前配置文件中的规则决定请求策略。 | Config 中启用的文件、Rule 顺序以及命中后的策略。 |
Scene | 按已设置的场景条件切换路由行为。 | 当前网络对应的场景设置；排查时暂时使用明确的固定模式。 |
结论：同一请求只比较一个变量
同一服务器下，Proxy 能打开而 Config 失败时，下一步优先检查当前配置的规则与策略；若两者都失败，则继续核对服务器和 DNS。这是缩小范围的方法，不是对故障原因的最终判定。
Direct 能访问、Proxy 失败，也不能仅凭这一组结果认定服务器宕机：代理路径上的解析、认证、TLS 或目标网站限制都可能影响结果。测试完成后恢复原先的 Global Routing；使用 Scene 的用户还要恢复场景条件，避免下次换网络时得到不同结果。
第三步：DNS 区分服务器解析与网站解析
DNS 问题可能发生在两个位置：先解析服务器域名，或在访问时解析目标网站域名。前者失败会使代理连接本身无法建立，后者失败则可能表现为服务器测试有响应但网页打不开。应先读清错误中的域名，再决定修改哪一项。
- 在 Config 打开当前启用文件的编辑视图，检查
[General]中的dns-server，并记录原值。不要编辑一个未启用的同名副本。 - 若原配置使用自定义 DNS，核对地址、格式与当前网络可达性。使用 DNS over HTTPS 时，还需要检查 HTTPS 端点是否可访问，以及端点域名的解析和证书是否正常。
- 可在配置副本中临时改为系统 DNS 作对照，保存并启用该副本，再重新建立连接。只改 DNS，保持服务器与 Global Routing 不变。
- 重复打开相同域名。若结果改善，继续核对原 DNS 路径；若结果不变，恢复原值，再检查规则，不要持续叠加未经验证的改动。
[General]
dns-server = system[General] 是配置文件的通用设置段；dns-server = system 表示使用系统 DNS 作为该项设置。这是对照测试片段，不是完整配置文件，也不应拿它覆盖已有配置的其他段落。使用系统 DNS 后，结果仍取决于当前网络提供的解析服务。
DNS over HTTPS 使用 HTTPS 传输解析请求，但并不保证任何网络下都可达。解析端点、服务器地址与目标网站是不同对象；只改成另一种 DNS 传输方式，不能修复服务器端口拒绝或认证参数错误。
第四步：Config 核对 Rule 顺序与实际策略
回到 Config，确认测试时启用的文件。Global Routing 为 Config 时，规则通常按顺序匹配，前面已经匹配的请求不会继续等后面的同类规则来覆盖。先查目标域名对应的规则，再查 IP 规则和最终策略；“配置里写了 PROXY”并不表示该请求一定命中了它。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY[Rule]：开始规则段。这个片段只用于说明语法，example.com是示例域名，不是连通性检测地址，也不代表适合所有用户的分流方案。DOMAIN-SUFFIX,example.com,PROXY：匹配example.com及其子域名，并使用PROXY策略。匹配的是请求域名后缀，不是网页路径中的某个词。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：匹配该 IPv4 网段并使用DIRECT。no-resolve表示不为匹配此规则主动发起域名解析；它不是全局关闭 DNS。GEOIP,CN,DIRECT：按 IP 地理数据库中的国家代码匹配并直接访问。它依据 IP 数据，不依据网页语言、域名后缀或服务商名称，数据库结果也可能与实际部署位置不同。FINAL,PROXY：前面的规则都未匹配时使用PROXY。最终策略不能覆盖已经命中的DIRECT或REJECT规则。
若目标在 Proxy 下正常、在 Config 下失败，检查是否被更靠前的 DIRECT 或 REJECT 命中，以及自定义策略组是否选择了有效成员。需要临时验证时，在副本中加入针对单个目标的 DOMAIN 或 DOMAIN-SUFFIX 规则，并放在可能冲突的规则之前；不要为了一个域名删掉整个 Rule 段。
结论：验证命中，而不是只看规则存在
保存并启用修改后的配置，重新发起同一个请求，结合应用内连接记录或日志核对目标与策略。只有“当前文件已启用、请求命中预期规则、对应策略可用”同时成立，才完成这一轮规则验证。
收尾：按测试结果定位，恢复原设置
四步排查的目的不是把所有设置改一遍，而是得到可以复现的对照结果。记录成功与失败发生在哪一轮，下一次复测保持相同条件；若只有某个网站失败，也要检查该网站自身是否可用，不能把单站故障等同于全部代理连接故障。
| 对照结果 | 下一步核对 |
|---|---|
| 关闭连接后，已知可直接访问的网页仍失败 | 先处理 Wi-Fi 认证、蜂窝网络权限与基础网络。 |
| 同一条目在 Wi-Fi 失败、蜂窝网络成功 | 检查 Wi-Fi 网络上的 DNS、端口与传输可达性，保留两轮错误记录。 |
| Proxy 成功、Config 失败 | 检查启用文件、规则顺序、命中策略与策略组成员。 |
| 仅更改 dns-server 后结果发生变化 | 复测原 DNS 的可达性与解析结果，确认不是短暂网络波动。 |
| 所有模式下只有同一个目标失败 | 核对目标服务状态、解析结果与证书错误，不继续盲目更换全局设置。 |
- 恢复原 Global Routing、DNS 和 Settings → On Demand 设置；删除只用于验证的临时规则，或保留清楚标记的配置副本。
- 向自己的服务商反馈时提供协议类型、服务器地址与端口、网络类型、失败时间和脱敏后的错误信息，不发送完整密码或订阅凭据。
- 订阅更新后重新检查当前选中条目；配置文件修改后重新检查 Config 中启用的文件，避免实际使用对象与记录不一致。
Shadowrocket 是 Apple 平台的付费客户端，以 iPhone、iPad 使用为主，唯一获取入口是 App Store。系统要求、设备兼容性与是否通用购买以 App Store 页面标注为准。客户端购买与线路服务是不同事项；本站不提供、不销售、不推荐节点或订阅。