连接开关开启只表示本地连接功能已启动，不等于远端服务器、域名解析和网页请求全部成功。本文以用户已有自己的服务商与订阅为前提，依次检查基础网络、服务器、Global Routing、DNS 和规则；步骤以 iPhone / iPad 的 Home、Config、Settings 为参照，Mac、Windows、安卓、Linux 可按相同判断顺序核对对应设置，具体界面位置以所在平台为准。
1. 先建立对照：基础网络是否能正常访问
Shadowrocket（小火箭）显示已连接，但浏览器持续转圈时，先不要同时更换服务器、DNS 和配置文件。一次只改变一个条件，并记录同一网页在修改前后的结果，才能区分故障来自当前网络，还是代理连接与分流设置。
测试时使用一个平时可直接访问的 HTTPS 网页，再使用一个原本需要经过已有服务器访问的网页。不要把单个站点的维护、账号状态或访问限制当作整个连接失效；也不要仅凭缓存页面仍能显示就判断网络正常。
-
暂停自动连接
进入 Settings → On Demand，记录当前条件后临时关闭自动触发，再回到 Home 关闭连接开关。这样可以避免手动断开后被网络切换条件重新连接。
-
检查基础网络
用浏览器重新加载可直接访问的网页。若关闭连接后也无法访问，先检查 Wi-Fi 登录认证、移动数据权限或当前网络本身，不必立即修改 Config。
-
更换网络复测
在条件允许时，用同一设备分别连接 Wi-Fi 与 Cellular，访问同一地址。只在某个网络失败，说明故障与网络条件有关，但仍需进一步区分服务器端口、DNS 和认证限制。
-
记录初始状态
记下 Home 当前服务器、Global Routing 当前姿态，以及 Config 当前启用文件。重新开启连接后再进行下一项，测试期间不同时更新整个配置。
2. 检查服务器：延迟结果不等于网页可用
在 Home 确认实际选中的服务器属于自己的有效订阅。列表中存在一条服务器记录，只能说明配置已导入；如果订阅内容已变更、账号到期或远端地址失效，本地仍可能显示旧记录。先更新自己的订阅，再核对选中项是否仍然有效。
核对服务器地址、端口、协议和认证字段是否与自己的服务商提供的信息一致。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的字段并不相同；不要把某种协议的密码、UUID 或密钥直接套入另一种协议。使用 TLS 的连接还需核对服务端要求的服务器名称与设备时间，不能用关闭证书验证替代排查。
服务器测试有延迟数值，并不能证明目标网页的完整请求成功。测试可能只覆盖特定探测方式与测试地址，实际浏览还涉及域名解析、握手、认证和目标站点响应。相反，探测超时也不能单独证明账号已失效，需要结合实际请求记录判断。
报错：Connection timed out
原因：连接在期限内未完成，可能涉及网络丢包、端口不可达或远端未响应。
解法：核对记录中的目标地址与端口，切换网络复测，再用自己的另一条有效服务器作对照；不要仅凭此报错修改认证字段。
报错：Connection refused
原因：目标端口明确拒绝连接，可能是端口填写错误、服务未监听或中间设备拒绝。
解法：对照自己的服务信息检查端口；配置一致仍出现此错误时，向自己的服务商确认该端口的服务状态。
以上是网络诊断中可能出现的英文错误文本，不同平台与日志来源的大小写、前后缀可能不同。判断时必须连同目标地址一起看：连接代理服务器失败与连接目标网站失败，不是同一个故障位置。
3. 核对 Global Routing：用 Proxy 与 Config 做单变量测试
在 Home → Global Routing 查看当前姿态。Direct 表示请求走直接连接，不是“自动选择可用服务器”；Config 才会根据当前配置文件的规则决定策略。Scene 则按已设置的场景条件工作，不能假定它一定等同于 Config。
| 姿态 | 排查时的作用 | 下一步 |
|---|---|---|
| Proxy | 将一般网页请求交给当前代理选择，减少普通分流规则对结果的影响。 | 核对 Home 当前选择；它可能是策略组，而不是固定服务器。 |
| Direct | 用直接连接作对照，不经代理服务器访问。 | 若目标原本无法直接访问，此姿态下失败并不说明服务器失效。 |
| Config | 按当前 Config 的规则匹配与策略执行。 | 查看失败请求实际命中的规则及最终策略。 |
| Scene | 依照已配置的场景条件选择相应行为。 | 检查当前网络对应的场景，不在排查中途新增条件。 |
临时切到 Proxy，保持服务器、网络与测试地址不变，然后重新发起网页请求。如果 Proxy 可以访问而 Config 不行，优先检查规则和策略组；如果二者都失败，应继续检查服务器与 DNS，而不是直接认定 FINAL 写错。测试完成后恢复原姿态，避免把临时诊断设置当作最终配置。
结论：先定位姿态差异
只有在同一网络、同一服务器和同一地址下，Proxy 成功而 Config 失败，才有充分理由把下一步重点放在规则命中与策略选择上。
4. 检查 DNS：先区分解析失败与连接失败
域名解析失败时，请求还没有获得可用于连接的目标地址；服务器连接失败则可能发生在解析成功之后。两者都可能让浏览器显示“无法打开网页”，所以需要查看具体请求记录，而不是只看浏览器提示或连接开关。
进入 Config，查看当前启用文件的 [General] 中与 DNS 有关的参数，并核对 Settings 中已有的 DNS 设置及其覆盖关系。先记录原值，不要同时替换配置文件和解析地址。自定义 DNS 本身也需要可达；使用加密 DNS 时，还需要考虑它的连接路径与初始解析。
- 只有域名相关请求失败：查看是否出现解析错误，并检查当前解析服务是否能在此网络中访问。直接访问 IP 只能作辅助判断，不能取代 HTTPS 域名测试。
- 解析已有结果，连接仍超时：继续检查目标 IP、命中策略及服务器连接，不要反复更换 DNS。
- 只在 Wi-Fi 出错：先确认网络认证已完成，再对比 Cellular；网络内的解析限制可能与服务器故障表现相似。
- 修改后结果未变：关闭旧网页连接，重新连接后再加载同一地址，避免把缓存结果或复用连接误判为新设置的效果。
报错：Could not resolve host
原因：发起请求的组件未能获得域名对应的地址，错误可能来自本地解析，也可能来自远端解析环节。
解法：先核对域名拼写和 DNS 可达性，再结合请求走向判断是哪一端解析失败；若错误来自测试工具，应以该工具的连接路径为准。
5. 检查规则：确认请求是否真的落到 FINAL
切回 Global Routing → Config，打开当前启用的配置文件，检查 [Rule]。规则通常按从上到下的顺序匹配；请求一旦命中前面的有效规则，就不会继续等待 FINAL。FINAL 是前面规则均未命中时的兜底策略，不是所有流量固定经过的一步。
下面仅演示规则结构，不是完整配置文件。example.com 与 192.0.2.0/24 是文档示例地址；不要用这段内容覆盖自己的整份 Config。策略名还必须与实际配置中可用的策略对应。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：匹配指定域名及其子域名。若失败网页的域名被前面的 DIRECT 规则命中，修改 FINAL 不会改变该请求。
- IP-CIDR：匹配目标 IP 网段。示例中的
no-resolve表示不为匹配这条规则而主动触发域名解析，不是关闭整个应用的 DNS。 - GEOIP：按目标 IP 的地理数据匹配，不按网页语言或域名后缀判断；域名解析结果变化可能影响后续匹配。
- FINAL：为未命中前面规则的请求提供最终策略。若它指向策略组，还要确认组内当前选中的服务器是否有效。
复现一次失败请求后，在连接记录中核对目标域名、命中规则与最终策略。一个网页可能请求多个域名：主文档成功、脚本或图片失败，会表现为空白或加载不完整。此时应分别检查失败的资源域名，而不是把主页域名整段改成另一策略。
如果记录显示命中 FINAL，但最终策略是失效服务器，应该修正服务器或策略组选择；如果命中了过宽的前置 DIRECT 规则，应先备份，再缩小那条规则的范围。每次仅改一条并重新测试，避免删除整段规则后失去故障依据。
6. 常见追问与排查结束后的恢复
为什么延迟有数字，网页还是一直转圈？
延迟测试没有覆盖所有网页请求环节。先保持同一服务器，在 Home → Global Routing 临时选择 Proxy，重新访问同一地址，再检查请求是否完成解析与远端连接。不要只凭延迟数值反复切换服务器。
切到 Proxy 就好了，要一直这样用吗？
这说明需要重点核对 Config 下的规则和策略，但不代表必须长期使用 Proxy。进入 Config 检查失败请求命中的规则，修正后恢复 Global Routing → Config，再复测同一网页及其资源。
订阅更新成功，为什么还是连接不上？
更新成功只说明订阅内容已取回并处理，不保证每条服务器当时都可用。回到 Home 核对当前选中项，检查地址、端口和服务有效期，再按自己的服务信息确认认证字段。
刚关闭连接，它又自己打开了怎么办？
先到 Settings → On Demand 检查自动触发条件，临时关闭后再手动测试。排查结束后恢复需要的条件，并在 Wi-Fi 与 Cellular 切换时确认行为符合预期。
完成排查后，恢复临时修改的 Global Routing、DNS 与 On Demand。保存能稳定复现问题的最小记录：设备平台、网络类型、失败时间、目标域名、错误文本、命中规则和最终策略。向自己的服务商反馈时，不要公开完整订阅链接、认证密码或密钥。
- 基础网络失败：先处理网络登录、路由或设备联网权限。
- Proxy 与 Config 都失败：优先核对服务器参数、远端可达性和解析环节。
- 只有 Config 失败：检查前置规则、FINAL 与策略组当前选择。
- 只有部分资源失败：逐个查看资源域名的请求结果，保留有效规则，仅修改已经定位的项目。
需要重新安装或查看平台安装说明时，使用本站全平台下载页。Shadowrocket 是闭源商业应用，客户端获取与线路服务是两件事：客户端买断 ≠ 线路套餐，导入与测试仍以用户已有自己的订阅为前提。iPhone / iPad 的系统要求以 App Store 页面标注为准；Mac 提供 Apple 芯片与 Intel 两种版本。