Shadowrocket（小火箭）的连接开关开启，只表示本机连接流程已启动，不代表远端服务器、域名解析和每条请求的策略都正常。本文以用户已有自己的服务商与订阅为前提，从基础网络开始，逐项隔离服务器、Global Routing、DNS 与规则问题；每次只改一个变量，并用同一网页和请求记录复核结果。
先建立基线：关闭连接后能否上网
不要先删除订阅或重装应用。先判断故障是否只在 Shadowrocket 连接开启时出现：如果关闭连接后，当前 Wi-Fi 或蜂窝网络仍无法打开平时可直连的网页，应先处理基础网络、Wi-Fi 登录认证或系统网络权限。连接图标不能替代这一步检查。
-
保存现状
记录 Home 当前选中的服务器、Global Routing 的选项，以及 Config 中正在使用的配置。保留现有配置副本；记录中不要包含密码、完整订阅链接或认证参数。
-
关闭连接
在 Home 关闭连接，用 Safari 打开一个平时可直连的 HTTPS 网页。若仍失败，先确认 Wi-Fi 是否需要登录、蜂窝数据是否可用，再继续应用内排查。
-
固定测试对象
选定一个可直连网页和一个原本需要代理才能访问的网页。后续保持网址不变，每次修改后重新发起请求，避免用不同网站的结果互相比较。
-
暂停自动触发
若手动断开后连接又自动开启，检查 Settings → On Demand，记录原有状态后暂时关闭 On Demand。完成测试后恢复，避免自动触发干扰对照。
测试时也要区分“网页打不开”与“某个 App 的某项功能失败”。单个站点可能有自身故障；网页可以打开而视频或通话失败，则还需要检查相关流量是否使用 UDP，不能直接认定整个连接不可用。
第一处：服务器连通性与认证参数
回到 Home，确认选中的确实是准备测试的服务器，再执行 Connectivity Test。先看是否持续超时，再看响应是否稳定。测试成功只能证明测试采用的路径或目标可达，不能保证所有网站、UDP 流量和服务端认证都正常；延迟数值较低也不等于实际网页一定能打开。
打开当前服务器的编辑页面，将地址、端口和认证信息与用户已有服务商提供的原始资料逐项核对。Shadowsocks 的加密方法与密码、VMess 或 VLESS 的身份参数、Trojan 的密码，以及需要 TLS 时的服务器名称和传输参数，不能互相替代。不要因为网页通常使用 443，就擅自把服务器端口改成 443。
- 全部服务器测试失败：先对照关闭连接时的网络基线，再核对订阅状态、账号有效期与服务器地址是否发生变化。
- 只有一个服务器失败：在用户已有列表中换一个已知可用项复测；如果恢复，优先检查原服务器，而不是重写所有规则。
- 测试成功但业务失败：继续检查 Global Routing 与 DNS；同时确认测试是否只覆盖 TCP，而实际业务依赖 UDP。
- 更新订阅后出现故障：对照更新前后的地址与协议参数；订阅刷新成功只说明数据取得成功，不说明其中每个服务器都可用。
结论：先隔离单个服务器
同一网络、同一网页、同一 Global Routing 选项下，更换用户已有的服务器后恢复访问，优先核对原服务器的服务状态和参数；此时不要同时改 DNS 与 FINAL。
第二处：用 Global Routing 区分模式与规则问题
在 Home → Global Routing 核对当前选项。Proxy、Direct、Config、Scene 不是四种协议，而是不同的流量决策方式。临时切换用于诊断，测试完成后应恢复原有使用方式，尤其不要把一次 Proxy 测试成功当作所有分流规则都正确的证据。
| 选项 | 主要含义 | 排查时核对什么 |
|---|---|---|
| Proxy | 以代理方式处理流量，绕过项等设置仍需另行核对 | 当前选中的服务器能否承载目标请求 |
| Direct | 以直接连接方式处理流量 | 目标是否本来就能通过当前基础网络访问 |
| Config | 由当前配置中的规则决定请求策略 | 命中了哪条规则、最终使用哪项策略 |
| Scene | 按已配置的场景设置应用相应路由方式 | 当前场景实际采用什么设置，而非只看选项名称 |
先记录原选项，再临时选 Proxy，重新访问原本失败的同一网页。如果 Proxy 可用而 Config 不可用，说明应优先检查当前配置及规则命中，但仍要考虑两种模式下 DNS 路径可能不同。如果两种方式都失败，先回到服务器和 DNS 检查，不要只盯着规则。
第三处：DNS 是否完成解析且路径可达
域名解析发生在请求链路中，DNS 失败与服务器连接失败可能表现为同样的“网页一直加载”。打开请求记录，区分失败发生在域名解析阶段，还是已经获得地址后连接目标失败。不要仅凭 Safari 的通用提示认定是 DNS 问题。
在 Config 中打开当前正在使用的配置，检查文本里的 [General] 与 dns-server。如果曾手动填写解析器，核对地址是否正确、当前网络能否访问，以及是否依赖尚未建立的代理路径。不要同时叠加多个陌生 DNS 设置；先恢复到此前可用的配置副本，再做单项对照。
- 域名没有得到地址：优先检查 DNS 可达性、地址拼写和当前配置中的解析设置。
- 已得到地址但连接超时：继续检查目标连接路径、服务器状态和规则策略，不能只更换解析器。
- 仅一个域名失败：核对域名本身、相关规则，以及该站点是否依赖其他资源域名。
- 更换网络后才失败：在 Wi-Fi 与蜂窝网络分别复测，判断是否是当前网络限制了解析器或服务器的访问。
报错：Could not resolve host
原因与解法：这是常见的域名解析失败信息，具体措辞取决于诊断工具。先核对目标域名与 DNS 配置，再检查解析器在当前网络下是否可达；不要立即修改服务器认证参数。
报错：Connection timed out
原因与解法：连接在规定时间内未完成，可能发生在服务器或目标路径。先定位记录中的失败目标和端口，再用同一网络测试用户已有的另一个服务器，区分单点故障与整体网络问题。
报错：Connection refused
原因与解法：通常表示连接被目标或中间设备主动拒绝。核对记录指向的是代理服务器还是目标网站，检查对应端口和服务状态；反复刷新网页不能修复错误端口。
第四处：规则顺序、策略引用与 FINAL
在 Global Routing 使用 Config 时，请求由当前配置的规则决定走向。先在 Config 确认选中的文件，再检查 [Rule]。规则通常从上到下匹配，前面已经命中的请求不会等待后面更具体的规则；因此，规则内容正确但位置错误，同样可能导致访问失败。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以上片段仅说明语法，不是可直接替换现有配置的通用方案。example.com 是示例域名；PROXY 必须对应当前配置中存在且可用的策略或策略组，不能只复制名称而没有定义。FINAL,PROXY 的实际效果还取决于该策略最终选择的服务器。
| 关键字 | 匹配依据 | 常见检查点 |
|---|---|---|
| DOMAIN-SUFFIX | 域名及其子域名 | 是否被前面的宽泛规则覆盖，是否遗漏资源域名 |
| IP-CIDR | 目标 IP 地址段 | 网段与掩码是否正确，no-resolve 是否符合预期 |
| GEOIP | 目标 IP 的地理数据库归属 | 以实际解析出的 IP 查询结果为准，不按品牌所在地推断 |
| FINAL | 此前规则均未命中时兜底 | 是否位于末尾，引用的策略是否存在且可用 |
no-resolve 用于避免为了匹配该 IP 规则而额外触发域名解析，不是关闭整个应用的 DNS。REJECT 则会阻止相应请求；若主页面可打开、图片或登录接口失败，应检查这些资源域名是否命中了拒绝规则，而不是直接删掉全部规则。
结论：根据命中记录调整规则
只有确认失败请求命中了错误策略后，再移动或修改对应规则。若请求根本没有走到 FINAL，修改 FINAL 不会修复它；若已经命中预期代理策略，则应继续追踪该策略实际选择的服务器。
常见追问：测试成功后仍有局部故障
Connectivity Test 有结果，为什么网页还是打不开？
测试目标与网页目标可能不同，测试也未必覆盖认证、TLS、DNS 和网页所需的全部连接。先在 Home → Global Routing 临时选择 Proxy 复测，再查看失败请求停在解析、连接还是策略选择阶段。
Proxy 能上网，换成 Config 就失败，先改哪里？
先确认 Config 中当前文件，再查看失败请求的规则命中和策略组选择。检查是否误走 DIRECT、命中 REJECT 或引用了不可用策略；保留 DNS 路径不同的可能性，不要直接将所有请求改为同一策略。
Wi-Fi 正常，蜂窝网络失败，是协议不支持吗？
先使用同一服务器和同一网址复测，核对蜂窝数据权限、Settings → On Demand 及 Scene 的设置。不同网络可能对端口或 UDP 采用不同处理；仅凭一次失败不能判断协议本身不受支持。
网页正常，通话或视频异常怎么办？
查看业务是否涉及 UDP，再核对当前协议、服务器端与服务权限是否支持所需转发。Hysteria2 的传输依赖 UDP；其他协议的 UDP 能力也要结合服务端配置判断，不能只看协议名称。
订阅更新成功，是否就能排除服务问题？
不能。更新成功只证明订阅内容能够取得并被处理。回到 Home 检查当前服务器的地址、认证参数和连通性；如需向自己的服务商反馈，提供脱敏后的错误阶段、网络类型和复现步骤。
收尾：恢复设置并保留可复现记录
找到问题后，只保留经过验证的必要修改。恢复临时关闭的 On Demand，确认 Global Routing 回到日常选项，再分别测试基础网页与原先失败的目标。如果只能在某一种网络或某一个服务器上复现，应把这个条件写入记录，而不是将结论扩大到整个应用。
- 记录环境：Wi-Fi 或蜂窝网络、是否完成网络登录，以及关闭连接时能否访问基础网页。
- 记录选择：当前服务器的自定义名称、Global Routing 选项、Config 文件名称，不记录密码或订阅凭据。
- 记录阶段：解析失败、连接超时、认证失败，或命中了非预期策略，并保留脱敏后的原始报错。
- 记录改动：本次只改了哪一项、同一目标是否恢复、恢复原设置后能否再次复现。
需要逐项对照字段时，可查看配置字段说明；首次导入或不确定当前配置来源时，先按入门指南确认操作顺序。客户端买断不等于线路套餐，应用购买状态与用户已有服务的有效状态需要分别核对。