Shadowrocket（小火箭）的连接开关打开，表示本机连接功能已经启动，不等于远端服务器、DNS 和目标网站都已正常工作。本文面向已经拥有自己的服务商与配置、但连接后无法访问的用户：先固定测试条件，再依次检查服务器、Global Routing、DNS 和规则，每次只改一个变量，用同一个目标复测并保留结果。
排查前：区分本地连接与远端可用性
状态栏显示 VPN，不能单独证明代理服务器已经完成认证，也不能证明网页请求走到了预期出口。一次网页访问还涉及域名解析、路由选择、远端连接和网站响应；其中任一环节失败，都可能表现为浏览器一直等待。因此，不要在第一次超时后同时更新订阅、替换 DNS 和重写 Config，否则很难判断究竟哪项修改起了作用。
先选择一个平时能够正常打开的普通 HTTPS 网页作为对照，再选择当前失败的网页。测试时记录完整域名、当前网络是 Wi-Fi 还是蜂窝网络、选中的服务器，以及 Global Routing 的模式。本文不提供连接服务；以下操作均以用户已有的服务器或订阅为前提。
- 关闭连接后也失败：先检查设备基础网络。需要登录认证的 Wi-Fi 应先完成网络登录，再进行代理测试。
- 关闭连接正常、打开后全部失败：优先检查服务器可达性、认证参数与当前路由模式。
- 只有少数域名失败：保留具体域名，后续重点核对 DNS 结果与该请求的规则命中。
- 开关关闭后又自动打开：检查
Settings → On Demand。排查期间可暂时关闭 On Demand，完成后恢复原设置，避免自动连接干扰对照。
第一步：检查服务器连通性与连接参数
在 Home 确认实际选中的服务器，然后使用 Home 的 Connectivity Test 检查连通性。测试结果只能反映测试目标和测试方式下的可达情况：显示延迟不代表所有网站都可访问，出现超时也不必然代表账户失效。应把测试结果与实际网页请求一起判断，尤其不要把单纯的延迟结果当作认证、TLS 和业务访问全部成功的证明。
-
确认选中项
打开 Home，核对当前选中的服务器名称；进入该项编辑页面，检查地址、端口、协议及认证信息是否与自己的服务商提供的内容一致。备注相似的条目可能对应不同地址，不要只看显示名称。
-
执行测试
在 Home 使用 Connectivity Test，记录所选服务器的测试结果，再打开固定的测试网页。把“测试有响应但网页失败”和“测试与网页都失败”分开记录，后续处理方向不同。
-
切换网络
保持服务器及配置不变，仅在 Wi-Fi 与蜂窝网络之间切换后重复测试。若只有一种网络失败，优先检查该网络的登录认证、出口限制和 UDP 可达性，而不是直接修改全部协议参数。
-
核对原配置
若服务商已通知地址或凭据变更，更新自己的原订阅后重新选择服务器。确认更新是否成功；订阅更新失败与现有服务器连接失败是两个问题，不要通过反复删除配置来代替核对。
不同协议的必要字段并不相同。Shadowsocks 需要匹配加密方式与密码；VMess、VLESS 的身份字段、传输设置需与服务端一致；Trojan 的密码及 TLS 设置也必须匹配。使用 Hysteria2、WireGuard 时，还需要注意所在网络对 UDP 的支持情况。不要因为某条连接失败就任意更换协议名称，服务器必须支持相应配置。
报错：connection refused
原因：连接被目标端或中间设备明确拒绝，常见于端口没有服务监听或访问被拒绝。
解法：核对服务器地址、端口及传输类型；若与原配置一致，向自己的服务商确认该入口是否仍在运行，不要盲目更换本机 DNS。
报错：i/o timeout
原因：某个网络读写阶段超过等待时间，可能涉及本地网络、远端可达性或协议握手，单凭这条信息无法确定责任环节。
解法：保留报错前后的上下文，使用同一服务器切换网络复测，再结合具体失败阶段排查；不要将超时直接解释为密码错误。
报错：no such host
原因：当前解析过程未取得对应主机的地址；需要先辨认报错中的主机是服务器域名，还是正在访问的网站域名。
解法：检查域名拼写及 DNS 可用性。若是服务器域名解析失败，应先恢复这一基础解析，不能依赖尚未连通的代理来完成全部前置操作。
以上为网络错误中常见的原文片段，实际显示可能包含地址、端口或更完整的系统提示。排查时以完整错误上下文为准。遇到证书验证错误，应检查设备日期、服务器域名与 TLS 配置，不要把关闭证书验证当作常规解决办法。
第二步：用 Global Routing 分离代理与规则问题
进入 Home → Global Routing，先记录当前模式。Proxy、Direct、Config、Scene 不是连接质量等级，而是不同的路由选择方式。Proxy 用于代理方向的对照，Direct 用于直连方向的对照，Config 按当前配置规则处理，Scene 则按已设置的场景工作。排错时不要停留在 Scene 下猜测结果，应明确当前生效的场景和配置，或暂时切换到可直接对照的模式。
| 测试模式 | 观察结果 | 下一步 |
|---|---|---|
| Proxy | 同一网页仍然失败 | 继续检查服务器、DNS 或网站自身，不急于重写规则。 |
| Direct | 普通网页正常，Proxy 下失败 | 重点检查代理路径；直连成功不代表服务器可用。 |
| Config | Proxy 正常，Config 下失败 | 检查生效配置、规则顺序和请求最终策略。 |
| Scene | 切换网络后表现不同 | 核对场景实际选择的路由设置，先固定模式再复测。 |
结论：Proxy 成功后再查 Config
如果同一网络、同一服务器和同一网页在 Proxy 下成功，在 Config 下失败，保留服务器设置不动，转查当前配置与请求记录；这样可以避免把规则问题误处理成服务器故障。
每次切换模式后重新发起网页请求，必要时断开再连接，以减少旧连接复用的影响。完成测试应恢复日常使用的模式；Proxy 只是对照工具，不是所有“打不开网页”问题的最终设置。
第三步：区分 DNS 失败与后续连接失败
DNS 负责把域名转换为地址。若解析没有完成，后续连接通常无法开始；但拿到了地址，也只证明解析阶段有结果，不证明该地址能连通或证书有效。进入 Settings 中的 DNS 设置，先记下现有配置，区分当前使用的是系统 DNS、自定义 DNS 还是 DNS over HTTPS，再按现有配置逐项核对。
这些端口是协议常见默认值，不是要求把自己的服务器端口改成 53 或 443。自定义 DNS 要求设备能够到达指定解析服务器；DNS over HTTPS 还依赖对应 HTTPS 服务可达。若 DNS 服务自身使用域名，也可能需要先完成该域名的解析，不能假定换成加密 DNS 就自动解决所有前置连接问题。
- 所有域名都无法解析：先核对 DNS 地址是否输入正确，恢复修改前的可用设置做对照；同时确认设备基础网络正常。
- 只有一个域名失败：检查该域名是否拼写错误、是否仅某个子域失败，保留具体查询结果，不要立即替换整套 DNS。
- 取得地址后连接超时：继续检查该地址对应的路由与远端连接；这已不只是“有没有解析结果”的问题。
- 修改后看起来没变化：保存设置，重新建立连接并重新发起请求；已有连接或应用缓存可能继续使用旧结果。
第四步：核对 Config 与规则实际命中
确认服务器和 DNS 基本正常后，再进入 Config 检查当前实际生效的配置。仅仅编辑了某个文件，不代表连接正在使用它；应先核对选中的配置，再检查 [Rule] 中的顺序。规则通常自上而下匹配，命中后采用对应策略，FINAL 应放在具体规则之后。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT这段最小示例把 example.com 及其子域交给 PROXY，其余请求交给 DIRECT。它只用于说明匹配逻辑，不是适合所有用户的完整配置，也不会创建可用服务器。若目标页面还请求了其他域名，那些请求未必命中第一条规则；主页面打开而图片、登录或接口失败时，应检查具体失败请求，而不是只看地址栏的主域名。
- DOMAIN-SUFFIX：匹配域名本身及其子域，不是任意字符串包含。先核对实际请求域名是否属于所写后缀。
- IP-CIDR：按地址网段匹配，例如
IP-CIDR,192.168.0.0/16,DIRECT；这是地址条件，不是域名后缀条件。 - GEOIP：按地址的地理数据库归属匹配，例如
GEOIP,CN,DIRECT。结果受解析地址与数据库影响，不能据此推断网站内容的语言或运营所在地。 - FINAL：承接此前未命中的请求。若把
FINAL,DIRECT提前，后面的具体代理规则将失去被检查的机会。
在 Data 中结合可用的请求或连接记录核对时间、目标域名、目标地址及最终策略；具体字段以当前界面实际显示为准。若界面未直接给出命中规则，就用同一请求在 Proxy 与 Config 下的结果作为辅助证据。检查时也要留意比目标规则更靠前的规则，以及策略组是否仍指向预期服务器。
如果命中了 DIRECT 而预期应走代理，先调整目标规则及其顺序；如果已经命中 PROXY 却仍失败，应回到服务器和目标连接阶段，而不是继续叠加相同规则。修改一条后保存，确认该 Config 正在使用，再重连复测。不要在没有记录的情况下批量替换配置。
常见追问：部分网页、订阅与自动重连
测试有延迟，为什么浏览器还是转圈？
Connectivity Test 的结果不等于整条网页访问链路成功。保持同一服务器，先在 Global Routing 选择 Proxy 重试原网页，再检查 DNS 和连接错误；若只有一个网站失败，还应检查该网站及其附属域名，不要仅凭延迟判断一切正常。
Wi-Fi 不行，切到蜂窝网络就好了？
先保持其他设置不变，确认差异可重复。检查 Wi-Fi 是否需要登录、是否限制目标端口或 UDP；同时核对 Scene 与 Settings → On Demand 是否因网络变化改变了连接行为。不要把只在一个网络出现的故障直接归因于订阅失效。
订阅刷新失败，要先删掉所有条目吗？
不需要先删除。保留现有配置，确认自己服务商提供的订阅地址仍然有效，再在 Home 对相应订阅执行更新。订阅地址的可达性和现有服务器的可用性应分别测试；提交问题时遮住链接中的 token，避免泄露访问凭据。
关掉开关后又自动连上，怎么做对照？
进入 Settings → On Demand，记录原设置后暂时关闭自动连接，再测试关闭连接时的基础网络。完成排查后恢复原设置。若开关行为仍不符合预期，再检查设备中是否有其他自动连接管理设置，不要反复重装应用。
仍然无法定位时，整理一份最小排查记录：发生时间、网络类型、所选服务器的脱敏名称、Global Routing 模式、Proxy 与 Config 的对照结果、失败域名、DNS 是否取得地址，以及完整错误上下文。向自己的服务商确认服务器状态时，这些证据比“开关已经打开”更能说明故障位置。
排查完成后恢复 On Demand、日常路由模式和需要保留的配置，移除临时测试规则。最终以实际网页访问、预期策略和连续几次新请求的结果共同确认恢复，而不是只看一次延迟测试或状态栏标识。