适用于已经有自己的服务商与订阅、但在 Shadowrocket 中遇到节点超时或连接后无法访问的用户。先区分测试失败、协议握手失败与规则未走预期路径，再核对已有连接资料和设备时间。每轮只改变一个条件，保留测试结果，便于判断故障发生在本地网络、远端入口还是应用配置。
一、先区分连接开关、节点测试与网页访问
Shadowrocket（小火箭）的连接开关打开，表示系统 VPN 隧道已经建立，不等于远端节点已经通过认证，也不保证每个网站都能访问。节点旁出现延迟数值，同样只代表该次测试在指定条件下完成，不能据此推断所有目标、所有传输方式都正常。
从 Home 开始记录当前选中的节点、Global Routing 状态和所用网络。排查期间进入 Settings → On Demand，先关闭 On Demand，避免网络切换时自动连接行为改变测试条件；测试结束后再恢复原来的设置。不要同时更换节点、更新配置和修改 DNS，否则即使恢复访问，也无法知道是哪一项起作用。
- 本地网络检查：暂时关闭连接开关，确认当前 Wi-Fi 或蜂窝网络可以正常联网；公共 Wi-Fi 如有登录页面，先完成认证。
- 测试条件记录：写下网络类型、节点名称、测试方式、成功或超时，以及报错原文。分享记录前隐藏服务器地址、账号和凭据。
- 复现范围：确认是所有已有节点都失败、只有一个节点失败，还是只有某个网站打不开。这三种范围对应的检查重点不同。
二、先做延迟测试，再判断结果的边界
在 Home 使用 Connectivity Test 检查已有节点，并记录当前测试方式。不同方式检查的层次不同：TCP 建连成功只能说明指定入口接受了 TCP 连接；通过代理请求测试地址，则还涉及认证、代理出站、DNS 和测试目标本身。两种结果不能直接混作同一项指标。
-
固定条件
在 Home 选中一个已有节点，保持同一网络与同一测试方式，连续测试三次。记录每次结果，不用单次最小延迟代表稳定性。
-
核对模式
查看 Home → Global Routing。排查代理路径时可临时选择 Proxy，并确认选中的节点正确；记下原来的 Config、Direct 或 Scene 状态，结束后恢复。
-
验证访问
打开连接开关，访问两个自己平时使用且可确认状态的 HTTPS 页面。不要只依赖测试地址，单个目标故障也会表现为测试超时。
-
切换网络
保持节点与参数不变，在 Wi-Fi 和蜂窝网络之间切换，再重复同一测试。留意蜂窝数据权限和当前网络是否允许所需传输。
| 观察到的结果 | 能够说明什么 | 下一步 |
|---|---|---|
| 同一节点三次均超时 | 当前测试条件下未在限时内完成，尚不能断定凭据错误 | 换网络复测，再检查地址、端口与传输类型 |
| TCP 测试成功，代理请求失败 | 入口可能可达，但认证、TLS 或后续请求仍可能失败 | 逐项核对协议参数与错误记录 |
| Wi-Fi 失败，蜂窝网络成功 | 问题与网络路径、解析或网络限制有关的可能性较高 | 检查 Wi-Fi 认证、DNS 与 UDP 可用性 |
| Proxy 可访问，Config 不可访问 | 优先检查规则、策略选择及 DNS 路径 | 查看 Config 当前启用配置和命中规则 |
结论：先用对照结果缩小范围
如果同一节点只在一种网络下失败，先保留协议参数不动，检查该网络路径；如果两种网络都失败，再进入地址、端口和握手参数核对，避免反复修改正确配置。
三、按地址、端口、认证、传输的顺序核对
在 Home 打开对应节点的编辑页，按用户已有的原始资料逐项比对。服务器地址不能混入链接协议头、路径或末尾空格；Port 必须对应远端实际监听端口。例如资料写的是 443，不能因为连接失败就自行换成 8443。端口数字相同，也不意味着 TCP 与 UDP 都可用。
订阅更新与节点连接是两条不同的请求链路：订阅更新成功，只能证明配置资料被取回；节点能用，也不保证订阅地址当前可访问。若自己的服务商明确通知连接参数变更，先更新已有订阅，再重新检查选中的条目，避免继续测试旧地址。手动编辑前记录原值，后续订阅更新可能替换条目中的改动。
| 协议 | 优先核对项 | 常见判断误区 |
|---|---|---|
| Shadowsocks | 地址、端口、加密方法、密码，以及原资料要求的插件参数 | 端口能连接不代表加密方法与密码匹配 |
| VMess | UUID、加密设置、传输方式、TLS 与设备时间 | 只核对 UUID，遗漏传输或时间偏差 |
| VLESS | UUID、传输方式、TLS，以及原资料指定的 flow 等参数 | 把同一地址的另一种传输配置直接套用 |
| Trojan | 密码、TLS、服务器名称与端口 | 把连接地址与 TLS 服务器名称视为必然相同 |
| Hysteria2 | 认证信息、TLS、UDP 路径与原资料中的混淆参数 | 用 TCP 测试结果证明基于 QUIC 的连接正常 |
| WireGuard | 本地私钥、对端公钥、Endpoint、隧道地址与 Allowed IPs | 只看开关状态，不检查是否有有效握手和流量 |
启用 TLS 的连接还要核对服务器名称；使用 WebSocket 的连接还应核对 Host 和 Path。Path 中的大小写与斜杠可能影响路由，不能按习惯改写。不同协议的参数不能互相替代，是否填写某项应以自己的原始连接资料为依据，不要为了消除报错而关闭证书验证。
四、把报错对应到失败阶段
错误记录比“连不上”更有定位价值。下面列出底层连接中可能出现的典型英文错误片段；实际显示可能带有地址、协议前缀或更详细的上下文。应同时保留错误前后的阶段信息，不能只凭一个关键词判断远端状态。
报错：i/o timeout
原因：连接、读取或握手等某个操作未在限定时间内完成，并不直接等同于密码错误。
解法：先用相同节点切换网络复测，再核对地址、端口与 TCP 或 UDP 传输条件。
报错：connection refused
原因：连接请求收到拒绝响应，可能是目标端口没有服务监听，也可能是中间设备主动拒绝。
解法：确认原始资料中的端口未变更；仍复现时，将脱敏后的时间和错误交给自己的服务商核对入口状态。
报错：no such host
原因：域名解析未得到可用结果，可能涉及地址拼写、解析服务或域名本身。
解法：先检查节点地址中的拼写与空格，再切换网络对照解析情况，不要随意替换 TLS 服务器名称。
报错：x509: certificate has expired or is not yet valid
原因：证书有效期与当前校验时间不符，可能是设备时间错误，也可能是远端证书确已过期。
解法：先校准系统时间；时间正确后仍出现同样错误，应由自己的服务商检查证书，而不是跳过验证。
五、检查系统时间与时区，避免认证和证书误判
设备时间会参与 TLS 证书有效期判断，也会影响 VMess 等协议的时间相关认证。不要只看状态栏的小时数：日期、年份或绝对时间错误，都可能造成握手失败。时区主要影响本地显示；单纯显示时区不同，不一定意味着设备的绝对时间错误。
- 在 iPhone 或 iPad 打开系统设置 → 通用 → 日期与时间，检查“自动设置”。如该项可用，启用后等待系统同步。
- 核对显示的日期、年份与时区，确认当前网络可用。不要用手动更改日期的方式绕过证书错误。
- 回到 Shadowrocket，关闭连接开关后重新连接，再对原来的同一个节点执行 Connectivity Test，保持其他参数不变。
- 如自动设置不可修改，检查设备管理限制；如时间正确但证书错误持续，记录错误并联系自己的服务商核对远端证书。
六、测试通过但网页失败，回到 Global Routing 与 Config
Global Routing 的 Direct 将请求按直连路径处理，Proxy 用于代理路径，Config 按当前配置规则决定处理方式，Scene 按所配置场景处理。测试节点本身与实际应用请求不一定经过相同的决策路径，因此“延迟正常、网页打不开”需要检查路由和目标，不应立刻重建节点。
- 先做模式对照：临时用 Proxy 验证同一网页，再恢复原模式。如果只有 Config 下失败，到 Config 检查当前启用的配置，而不是只检查某个未启用文件。
- 再查规则顺序：规则通常按顺序匹配；
DOMAIN-SUFFIX根据域名后缀匹配，IP-CIDR根据地址网段匹配，GEOIP根据地址归属数据库匹配，FINAL承接前面未命中的请求。 - 检查 DNS 线索：域名请求失败而入口连接正常时，核对当前配置的 DNS 设置与错误记录。不要简单用 IP 地址访问 HTTPS 页面代替域名测试，证书和虚拟主机可能需要原域名。
- 区分单一目标故障：若其他常用页面正常，只有一个目标失败，记录该目标和时间，再判断是否是目标自身、解析或相应规则的问题。
例如，配置末尾为 FINAL,DIRECT 时，前面没有命中代理策略的请求会走 Direct。这是配置行为，不是节点超时的证据。修改前先备份当前配置，确认目标应走的策略，再调整具体规则；不要把整份规则清空作为常规排查步骤。
七、常见问题与提交记录
延迟有数字，为什么连接后还是打不开？
先确认 Connectivity Test 使用的方式，再在 Home → Global Routing 临时选择 Proxy 测试同一网页。入口可达不等于认证、DNS、规则与目标访问全部通过。
所有节点一起超时，要逐个重新添加吗？
先关闭连接确认本地网络正常，再保持一个已有节点不变，切换 Wi-Fi 与蜂窝网络复测。共同的网络路径、解析或时间问题，比同时重新添加所有条目更值得先查。
只有 Hysteria2 失败，TCP 测试却成功？
Hysteria2 基于 QUIC，依赖 UDP。先核对原资料中的端口与认证信息，再换网络测试；TCP 端口测试不能代替 UDP 和完整协议握手验证。
订阅更新成功，旧节点为什么还是失败？
更新成功仅说明订阅内容已取回。回到 Home 确认当前选中的条目是否仍是旧条目，并核对最新资料中的地址、端口和协议；不要把订阅请求成功当作节点健康检查。
需要向自己的服务商提供哪些信息？
提供失败时间及所在时区、Wi-Fi 或蜂窝网络、协议类型、测试方式、三次测试结果和脱敏错误。不要发送完整订阅链接、密码、UUID、私钥或包含凭据的截图。
完成排查后恢复原来的 Global Routing 与 On Demand 设置，再验证常用应用。保留“改动前条件、唯一改动项、改动后结果”三项记录；下次遇到相同现象，可以直接复用已经验证有效的检查顺序，而不必重复修改全部配置。