本文速览

Shadowrocket（小火箭）的连接开关表示本机隧道已启动，不等于目标网站已经可达。本文面向已导入自己服务配置的用户，按服务器、Global Routing、DNS、规则的顺序建立对照测试，区分本地网络、远端连接、域名解析与分流问题；每次只修改一项，测试后恢复原设置。

开始前：固定测试条件，确认本地网络可用

先记录当前 Home 中选中的服务器、Global Routing 状态，以及 Config 中正在使用的配置。排查期间使用同一台设备、同一个网络和同一个目标域名，避免同时更换 Wi-Fi、服务器与配置，否则无法判断是哪一项改变了结果。本文以用户已有自己的服务商与订阅为前提，本站不提供、不销售、不推荐节点或订阅。

关闭 Shadowrocket 连接开关后，先访问一个平时可以直接打开的网站。如果仍无法访问，优先检查 Wi-Fi 是否需要网页登录、蜂窝数据是否可用，以及设备是否处于受限网络中。此时修改代理规则没有排查价值；先恢复基础联网，再打开连接开关复测。

  1. 记录原状态

    在 Home 记录选中的服务器与 Global Routing，在 Config 记录当前配置名称。编辑前保留配置副本，原文件与订阅中的凭据只保存在自己的设备上。

  2. 检查自动连接

    打开 Settings → On Demand，记录原设置。若关闭开关后连接又自动建立，可在测试期间暂时关闭 On Demand，避免自动连接影响对照结果。

  3. 建立联网基线

    关闭连接开关，测试一个已知可直接访问的网站。若网络需要认证，先完成网络提供的登录流程；不要把认证未完成误判为服务器故障。

  4. 固定复测对象

    选定一个直接访问正常的域名和一个出现问题的域名，分别记录开关关闭、开关打开后的表现。后续每改一项，都重新访问这两个目标。

第一项：检查 Home 选中的服务器是否能承载请求

回到 Home，确认选中的是准备测试的服务器，而不是名称相近的旧条目。进入该条目的编辑界面，核对服务器地址、端口、协议与认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的字段并不相同；应逐项对照自己服务商提供的参数，不能只修改 Type 后保留其他字段。

执行 Home 中的 Connectivity Test 时，要区分“测试有延迟数值”和“浏览请求成功”。不同测试方式检查的环节不同；TCP 建连成功只能说明相应端口可达，不能独立证明认证、TLS 握手、UDP 通路或目标网站访问正常。继续使用浏览器发起真实请求，才能验证后续链路。

  • 地址与端口：核对服务器域名或 IP、服务端口是否与原始资料一致。端口 443 只是常见的 HTTPS 端口，不代表所有服务都使用它，也不代表填入后就能连接。
  • 认证与传输：密码、UUID、TLS Server Name 等字段仅在对应协议使用时核对；不要为消除错误而随意关闭证书验证，应先确认服务器名称、设备时间和服务端证书。
  • 已有订阅：若配置来自自己的订阅，在 Home 对相应订阅执行更新，再重新选择更新后的条目。更新成功只代表列表取得成功，不代表其中每个服务器都能访问目标网站。
  • 网络差异：同一条目在蜂窝数据正常、Wi-Fi 失败时，优先检查该 Wi-Fi 的端口或 UDP 限制。切换网络只用于对照，不要同时更换协议与 DNS。

下面是网络日志中可能出现的通用错误字符串，不是所有协议都会显示相同文本。应结合完整上下文判断出错对象：报错地址究竟是服务器、DNS 解析器，还是目标网站。

报错：connection refused

原因：对应连接收到了拒绝响应，常见于目标端口没有服务监听或被主动拒绝。

解法：先核对日志中的地址与端口；若对象是自己的服务器，向自己的服务商确认服务状态和正确端口。

报错：i/o timeout

原因：某个读写阶段在期限内没有完成，可能涉及网络丢包、端口不可达或远端未响应。

解法：保持条目参数不变，换一个可用网络复测，再按错误发生阶段检查服务器连接或 DNS 请求。

报错：no such host

原因：相关主机名没有得到可用解析结果，出错名称可能是服务器域名，也可能是目标网站域名。

解法：先确认域名拼写与有效性，再进入 DNS 排查；若服务器域名本身无法解析，单纯切换代理策略不能解决它。

第二项：用 Global Routing 区分代理链路与配置问题

在 Home → Global Routing 查看当前选择。Proxy 用于将可代理的请求交给代理路径；Direct 使用直连路径；Config 按当前配置处理；Scene 使用场景设置决定实际行为。Scene 并不等于固定的 Proxy 或 Config，排查时需要确认当前场景采用的设置。

先在同一服务器、同一网络下临时选择 Proxy，重试问题域名；随后切回 Config 再试。如果 Proxy 可访问而 Config 不可访问，问题更可能位于规则、策略指向或配置中的其他处理，而不是服务器完全不可用。测试结束后恢复原模式，避免把临时对照设置当成长久修复。

姿态排查用途结果如何解释
Proxy测试所选代理路径能访问说明该请求在当前条件下可经代理完成，不代表所有域名均可用。
Direct建立直连对照仅用已知能直接访问的网站测试；目标自身不支持当前直连环境时，失败不足以定位故障。
Config验证当前配置与 Proxy 结果不同，应继续检查规则命中、策略目标及 DNS 等配置差异。
Scene检查场景选择先确认当前场景的实际设置，再与固定姿态对照，避免场景变化引入额外变量。

结论：Proxy 正常后再查规则

同一目标在 Proxy 下正常、Config 下失败时，保留可用服务器，转去核对当前配置与命中策略；不要同时重建服务器条目，否则会丢失已经建立的有效对照。

第三项：区分服务器域名解析与网站域名解析

DNS 至少可能出现在两个位置：先把服务器域名解析为地址，再为访问目标取得地址。前者失败会阻断服务器连接，后者失败可能表现为连接已建立但网页无法加载。检查日志时先找出发生解析错误的完整域名，不要只看到 DNS 字样就替换所有解析设置。

在 Config 打开当前配置，检查 [General] 中的 dns-server，同时检查是否存在影响目标域名的 [Host] 映射。配置中保留了旧的内网 DNS、不可达的解析器，或将域名映射到过期地址，都可能影响结果。若存在多处 DNS 设置，应结合当前生效配置检查，避免修改了未使用的文件。

2 处
分别检查服务器域名与目标域名的解析
53
传统 DNS 常用 UDP 或 TCP 端口
443
DoH 通常使用 HTTPS 端口，并非所有 DNS 的端口
  1. 先核对报错域名是否拼写正确，确认问题不是已失效的服务器域名或错误的网页地址。
  2. 保留配置副本后，可临时用 dns-server = system 做系统解析对照；这不是通用推荐值，系统 DNS 也可能受当前网络影响。
  3. 检查 [Host] 中是否为问题域名写入了旧地址。只撤销已确认有问题的映射，不要整段删除其他用途的记录。
  4. 保存并确认该配置处于选中状态，重新建立连接后再次请求同一域名，记录与修改前的差别。

第四项：检查 Config 中的规则顺序与实际策略

当 Proxy 可用而 Config 失败时，在 Config 确认选中的文件，再检查其中的 [Rule]。规则通常从上到下匹配，命中后采用对应策略；排在前面的宽泛规则可能覆盖后面的精确规则。修改另一个未启用的文件，不会改变当前连接使用的规则。

DOMAIN-SUFFIX 匹配指定域名及其子域名；IP-CIDR 匹配地址网段；GEOIP 依据 IP 地理数据库分类；FINAL 处理此前没有命中的请求。域名规则与 IP 规则匹配对象不同，涉及 IP 分类时还需要考虑地址是否已经取得，不能把规则顺序当成与 DNS 完全无关的步骤。

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

这段配置仅用于说明语法：example.com 是示例域名，192.0.2.0/24 是文档示例网段。不要用它们判断真实服务是否可达，也不要整段覆盖自己的生产配置。no-resolve 表示该条 IP 规则不主动触发解析；它不是关闭全局 DNS 的开关。

  • 命中 DIRECT：请求采用直连路径；若目标在当前网络直连不可达，检查是否被过宽的域名规则或地址规则提前匹配。
  • 命中 REJECT：请求被规则拒绝。应定位具体规则及其用途，确认误伤后再作精确调整，而不是把所有拒绝规则一并删除。
  • 命中 PROXY：继续核对当前使用的代理目标；若规则指向自定义策略组，还要确认该组实际选中的成员，不能只看 Home 的选中标记。
  • 落到 FINAL：说明此前规则未命中。检查末尾策略是否符合预期，并把确有需要的精确规则放到可能覆盖它的宽泛规则之前。

复测时在 Shadowrocket 的请求记录或日志中查找同一个目标域名，核对命中规则与最终策略。一个网页可能还请求图片、脚本和登录接口；主域名成功但页面空白时，应检查失败的资源域名，而不是反复给主域名添加重复规则。

常见追问：按现象决定下一步

延迟有数值，为什么浏览器仍打不开？

先确认 Connectivity Test 使用的测试方式，再用真实网页请求验证。若只是端口连通而认证失败，仍会出现此现象；在 Home 核对协议与认证参数，并查看失败发生在连接、握手还是请求阶段。

只有 Wi-Fi 不行，蜂窝数据正常，先改什么？

保持服务器和 Global Routing 不变，先检查 Wi-Fi 的基础联网与认证页面，再比较 DNS 和端口可达性。若服务依赖 UDP，还要核实该网络是否限制 UDP；不要仅凭网络差异就判定账号失效。

只有一个网站打不开，要重置全部设置吗？

先在 Proxy 与 Config 之间做对照，再查该域名的解析和命中策略。其他网站正常说明链路至少部分可用；如果两种姿态都只在同一目标失败，还需要考虑目标站点响应与访问限制。

改完配置没有变化，应该检查哪里？

在 Config 确认修改后的文件确实被选中，回 Home 确认 Global Routing 为 Config，再重新建立连接复测。若正在使用 Scene，先检查场景实际配置；测试结束后恢复 Settings → On Demand 的原设置。

仍未定位时，整理故障发生时间、网络类型、协议名称、Global Routing 状态、失败域名及脱敏后的错误片段，交给自己的服务商核对。不要公开完整订阅链接、密码、UUID、私钥或包含访问令牌的截图；这些内容与定位问题所需的现象记录应分开保存。