本文速览

Shadowrocket（小火箭）的连接开关打开，只能说明本地连接状态，不能证明远端服务器、域名解析与目标网站全部可用。本文适合已经持有自己的服务信息与订阅、但遇到网页打不开的用户：先建立基础网络对照，再按服务器、模式、DNS、规则逐项缩小范围，每次只修改一个变量，最后恢复日常配置。

一、先区分基础网络与代理链路故障

不要立即删除订阅或重置全部设置。先记录 Home 当前选中的服务器、Global Routing 的模式，以及 Config 中正在使用的配置文件。相同的“打不开网页”可能来自不同环节，保留这些信息，才能知道后续哪一次改动真正起作用。

系统显示连接已建立，通常表示本地 VPN 隧道已启动。远端服务器是否接受连接、认证信息是否有效、DNS 是否得到响应，仍需要单独验证。测试应使用自己平时可访问、无需登录的普通网页，并记录具体时间与错误表现。

  1. 记录现状

    在 Home 记下所选服务器与 Global Routing，在 Config 记下当前配置。保存原有设置后再修改，避免把原始问题与新改动混在一起。

  2. 关闭连接

    关闭 Home 的连接开关；若连接自动恢复，检查 Settings → On Demand，暂时停用触发条件，再确认连接确实关闭。

  3. 验证直连

    在 Safari 打开已知可直连的网页。如果仍打不开，先检查当前 Wi-Fi 的登录认证、蜂窝数据权限与基础网络，不要先改规则。

  4. 恢复测试

    重新打开连接，用同一网页复测。测试时保持同一网络、同一服务器与同一目标，每轮只改变一个设置。

  5. 换网对照

    在条件允许时切换 Wi-Fi 与蜂窝网络，再测试相同目标。若只在其中一种网络失败，优先检查该网络的解析、端口或传输限制。

二、核对服务器地址、端口与协议参数

在 Home 确认实际选中的服务器，不要只看订阅分组名称。进入该服务器的编辑页面，与自己已有的服务信息逐项核对 Address、Port、Type 及认证字段。订阅更新成功，只证明订阅内容可以获取并解析，并不证明其中每个服务器当前都能通信。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的参数不能互换。服务器使用什么协议，就按对应协议核对字段；涉及 TLS 时还要确认服务器名称与证书要求，涉及传输层设置时则检查其路径、主机名等参数。不要通过随意更换 Type 来尝试“修复”。

若连接日志包含以下原文，可按所处阶段分流排查。不同协议和错误来源的显示可能带有前缀或附加信息，应保留完整日志，而不是只凭其中一个词下结论。

报错：connection refused

原因：目标地址或中间设备拒绝了这次连接，常见于端口不匹配或服务未监听。

解法：核对 Address 与 Port，并向自己的服务提供方确认该端口当前的监听状态。

报错：i/o timeout

原因：某次网络读写在规定时间内未完成，仅凭此项不能区分网络丢弃、服务器无响应或后续握手停滞。

解法：记录超时对应的目标与阶段，保持配置不变换网复测，再与同一订阅中自己已有的另一台服务器对照。

报错：no such host

原因：本次解析未得到可用的主机地址，可能是服务器域名写错，也可能是解析链路异常。

解法：先核对报错中的域名；如果是服务器地址本身，先解决该地址的解析，再测试网页域名。

三、用 Global Routing 缩小故障范围

进入 Home → Global Routing，确认当前模式。Direct、Proxy、Config 与 Scene 是不同的处理姿态，不是连接成功程度的四个等级。测试时先记住原模式，再临时切换，完成后恢复。

模式主要含义排查用途
Direct采用直连处理检查基础直连路径；不能用它验证代理服务器是否可用。
Proxy采用代理处理临时检查当前代理路径，减少配置规则分流对结果的影响。
Config按当前配置文件中的规则处理适合检查规则顺序、策略名称与最终兜底。
Scene依据已设置的场景条件处理检查当前网络触发了什么场景，以及该场景实际采用的设置。

使用同一服务器与同一网址做对照：如果 Proxy 可以打开、Config 无法打开，优先查看规则和策略，但也要注意模式切换可能改变请求路径及解析行为。如果 Proxy 同样失败，应先回到服务器参数与 DNS，不要仅通过添加域名规则反复试错。

结论：先固定路径，再改规则

只有当相同目标在固定代理路径下可用、在 Config 下稳定失败时，才优先定位分流规则；若两种模式都失败，先保留规则原样，排查共同使用的服务器与解析链路。

四、检查 DNS：先分清哪个域名解析失败

DNS 问题至少有两层：连接远端服务器时需要解析它的域名，访问网页时又需要解析网页域名。前者失败会导致代理路径根本无法建立，后者失败则可能表现为已经连接、但网页长时间等待。查看错误信息中的实际域名，比反复更换解析地址更有效。

在 Settings → DNS 核对应用侧的解析设置，同时检查当前 Config 文件是否包含 DNS 相关设置。记录现值与配置来源，避免只改了 Settings，却忽略正在使用的配置仍带有其他解析要求。不同配置的实际生效关系应结合请求记录确认。

53
传统 DNS 通常使用的 UDP / TCP 端口
853
DNS over TLS 的标准默认端口
443
DNS over HTTPS 通常使用的 HTTPS 端口

五、检查规则顺序、策略与 FINAL

在 Config 中确认选中的配置文件，然后检查其中的规则。规则一般按顺序匹配，前面的命中会影响后续规则是否还有机会处理请求。只在文件末尾添加一条域名规则，可能完全改变不了已经被前面规则接走的流量。

以下片段仅用于识别语法，不是建议直接替换当前配置的通用方案。example.com 是示例域名，192.0.2.0/24 是文档示例网段；真实排查时应以实际失败域名、请求记录与自己的策略为依据。

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

如果配置引用自定义策略组，要继续检查组内当前选择。规则命中某个组名，并不保证该组最终走代理；组内可能选中了直连或一个当前不可用的服务器。结合请求记录核对“目标域名 → 命中规则 → 策略组 → 实际出口”，比仅检查规则文本更可靠。

六、常见追问与排查收尾

为什么显示延迟，网页还是打不开？

先确认 Connectivity Test 采用的测试方式。一次 TCP 建连或测试地址响应，只覆盖部分链路；继续用实际失败的网站复测，并检查认证、DNS 与规则命中，不能把延迟数值视为所有网站可用的证明。

只有一个网站打不开，要重导订阅吗？

先在同一服务器下比较其他网页，再查看该站失败请求的域名和策略。如果 Proxy 可用而 Config 失败，优先检查该域名的规则及关联资源；重导订阅通常不能修正配置文件中的域名分流错误。

关闭后又自动连上，怎么做直连测试？

到 Settings → On Demand 暂时停用相应触发设置，再回到 Home 关闭连接并观察状态。完成对照测试后恢复原设置，避免把 On Demand 的重新触发误认为手动切换没有生效。

订阅已更新，为什么原服务器仍不能用？

更新只刷新列表内容。回到 Home 核对当前实际选中的条目，并检查它的地址、端口与认证信息是否发生变化；如列表内容与自己的有效服务信息不符，向已有服务提供方核实，不要反复导入同一链接制造重复条目。

恢复正常后，撤回只为测试而做的临时修改：恢复日常 Global Routing、确认 Config 选中正确文件，并恢复所需的 On Demand 条件。随后重新测试直连网页、需要代理处理的网页以及此前失败的具体功能，防止只验证首页而遗漏登录或图片请求。