Shadowrocket（小火箭）显示超时，不等于所有请求都无法连接；显示延迟，也不等于协议认证与网页访问已经成功。本文适合已持有自己服务器或订阅、但遇到连接失败的用户：先区分基础网络、服务器测试与实际请求，再核对协议参数、TLS 和系统时间，最后用同一目标复测，每次只改变一个条件。
一、先区分延迟测试、VPN 状态与实际请求
先保留当前服务器与配置，不要同时改端口、DNS 和规则。Home 中的服务器延迟、系统的 VPN 状态、Connectivity Test 与浏览器实际访问，反映的是不同环节。系统显示 VPN 已连接，只能说明设备侧隧道已经建立，不能单独证明远端服务器已完成认证，也不能证明目标网站可达。
从前往后排查能减少误判。例如，服务器端口可建立 TCP 连接，仍可能因密码错误在后续握手阶段失败；某个测试目标未响应，也不能据此判断所有网站都不可用。不同测试方法覆盖的环节不一样，记录结果时应同时记录测试方法与目标。
| 观察位置 | 能说明什么 | 下一项核对 |
|---|---|---|
| Home 服务器延迟 | 当前测试方法下的响应情况 | 协议参数与真实请求是否成功 |
| 系统 VPN 状态 | 设备侧隧道状态 | 默认服务器与 Global Routing |
| Connectivity Test | 测试目标在当时条件下的可达情况 | 其他目标与应用实际访问 |
| 浏览器访问结果 | 该目标的端到端请求结果 | 是否仅单个域名或应用失败 |
二、按固定步骤复现超时，不同时改变多个选项
先确认基础网络可用，再检查 Shadowrocket 的连接。排查期间若 Settings → On Demand 已启用，手动断开后可能再次触发连接；可临时关闭 On Demand，完成基线测试后恢复原设置。测试要使用你已知可正常访问的目标，而不是随意更换多个陌生地址。
-
检查基础网络
断开 Shadowrocket 后，用浏览器访问已知可用的网页。若 Wi-Fi 需要登录认证，先完成认证。基础网络本身不可用时，先处理网络接入问题。
-
确认默认项
回到 Home，点选要测试的服务器，确认选中标记落在该项。不要仅打开编辑页就认为默认项已经切换；同时记录 Global Routing 当前选项。
-
记录延迟
在 Home 运行服务器延迟测试，记录成功或超时，以及所选测试方法。连续测试三次看是否稳定；一次响应不能代表持续可用。
-
验证实际连接
打开连接开关，按系统提示完成 VPN 配置授权，再在 Home 运行 Connectivity Test。随后访问同一已知目标，分别记录测试结果与网页结果。
-
切换接入网
在条件允许时，仅将 Wi-Fi 换为蜂窝网络，保持服务器、配置与目标不变后重测。若结果随接入网络变化，优先核查网络限制、域名解析及相应传输的可达性。
三、逐项核对地址、端口、认证与传输参数
基础网络正常而某台服务器持续失败时，打开 Home 中该服务器的编辑页，对照自己的服务商或服务器端原始配置。先看 Type 是否一致，再核对地址与端口，最后检查认证、传输及 TLS。显示名称只是标签，不参与协议认证；名称相同不代表内部参数相同。
| 核对项目 | 具体检查内容 | 容易混淆的情况 |
|---|---|---|
| 地址与端口 | 地址不得多出空格；端口须与服务端监听端口一致 | 端口 443 不自动代表 TLS，也不自动代表服务可用 |
| Shadowsocks | 核对加密方法、密码及服务端要求的插件参数 | 不能用其他加密方法替代原配置来试错 |
| VMess / VLESS | 核对 UUID、传输类型及服务端要求的其他字段 | 相同 UUID 不代表两种协议可以互换 |
| Trojan | 核对密码与 TLS 相关配置 | 地址能够连接不代表密码或证书校验已通过 |
| Hysteria2 | 核对认证、TLS 与服务端指定参数，并检查 UDP 可达性 | 普通 TCP 端口测试不能验证其完整连接链路 |
| WireGuard | 核对密钥、对端、Endpoint 与地址等配置 | 它不使用 TLS 证书，不能套用 TLS 排错流程 |
若原配置使用 WebSocket，还需核对 Path 与 Host：例如服务端配置要求 /ws，客户端不能擅自改为 /。这里的路径只说明字段需要逐字一致，并非可直接套用的服务器参数。若使用其他传输，同样应按原配置核对对应字段，不要把 WebSocket 的字段复制过去。
- 端口是服务端配置的一部分。不能因为 443 常见，就把原来的 8443 改为 443。
- 密码、UUID、密钥应检查复制时是否截断、是否带入换行；不要把这些值发到公开讨论区。
- 使用订阅时，先确认更新是否成功，再看当前选中项是否仍是预期服务器。更新列表与成功连接是两件事。
- 订阅管理的条目可能在下次更新时覆盖手动编辑。需要对照测试时先保存原参数，并避免把临时修改当作永久修复。
四、按错误原文定位，保留错误发生的阶段
下列是网络连接中常见的错误片段，不保证每个界面都会显示相同文字。只有在实际错误详情或连接记录出现相应原文时，才按该方向继续排查；仅看到“超时”不能推断认证失败。记录错误时也要记下它发生于订阅更新、服务器测试还是网页请求。
报错：i/o timeout
原因：某一步操作未在期限内完成，单凭这段文字无法确定是解析、连接还是后续读取超时。
解法：查看相邻记录中的目标与操作阶段，先复测同一地址和端口，再用另一接入网络对照，不要直接更换所有参数。
报错：connection refused
原因：连接被明确拒绝，常见于目标端口未监听或网络设备主动拒绝。
解法：先核对端口与协议，再向自己的服务商确认对应服务是否运行；此时反复修改密码通常不能解决端口拒绝问题。
报错：certificate has expired or is not yet valid
原因：证书有效期与校验时刻不匹配，可能是证书确实过期，也可能是设备时间错误。
解法：先检查系统日期与时间，再重新连接；时间正确仍报错时，交由自己的服务商核查证书有效期。
提交排查信息时，保留错误原文比只写“不能用”更有价值。可提供接入网络类型、测试时间、协议类型、出错阶段及已尝试的单项改动；订阅完整地址、密码、UUID 和私钥不属于公开诊断材料。
五、核对 TLS 与系统时间，不跳过证书校验
TLS 需要同时满足服务端配置、证书身份与设备时间等条件。服务器地址、TLS 的 Server Name（SNI）以及 WebSocket 的 Host 属于不同用途的字段；它们有时相同，但不能自行认定必须相同。使用 IP 地址连接时，也不能据此把服务端要求的 Server Name 改成 IP。
- 在 Home 打开服务器编辑页，按服务端配置检查 TLS 是否启用及 Server Name。只有该协议和传输实际使用 TLS 时，才进行这项检查。
- 在 iPhone 或 iPad 的系统“设置 → 通用 → 日期与时间”中检查“自动设置”，核对当前日期、时区与时间。此处是系统设置，不是 Shadowrocket 的 Settings。
- 若“自动设置”不可用，先核查设备管理或系统限制，确保时间准确后再复测。不要通过把系统日期调回过去来掩盖证书过期。
- 时间正确而证书错误持续出现时，向自己的服务商核实证书是否到期、域名是否匹配及证书链是否完整，不以跳过证书校验作为常规修复。
六、延迟正常仍打不开：检查 Global Routing 与规则
延迟正常后，若真实请求仍失败，应检查请求是否经过预期路径。Home → Global Routing 中，Proxy、Direct、Config、Scene 代表不同路由姿态：Proxy 使用代理路径，Direct 使用直接连接路径，Config 依据当前配置分流，Scene 按所选场景配置工作。选项改变的是路径，不会修复错误的协议凭据。
- 使用 Config 时，确认 Config 中当前选用的配置，再查看命中规则与出站策略；不要只根据服务器列表的延迟判断分流结果。
DOMAIN-SUFFIX按域名后缀匹配；IP-CIDR按 IP 网段匹配；GEOIP使用 IP 地理分类。域名规则与 IP 规则不是同一匹配条件。FINAL用于此前规则均未命中时的兜底。检查规则顺序与最终策略，避免目标意外落到 Direct 或其他不符合预期的路径。- 临时使用 Proxy 对同一目标进行对照后，应恢复原来的路由姿态。若仅 Config 下失败，再检查规则与解析，而非继续修改已经验证可用的密码。
域名解析也是实际请求的一环：服务器地址域名无法解析，与服务器已经连接但目标域名解析失败，属于不同阶段。不要一次性更改所有 DNS 相关设置；先确定失败的是哪个域名、发生在哪条路径，再比较单项修改前后的结果。
七、常见追问与排查结束条件
有延迟数字，为什么连接还是失败？
延迟数字只覆盖所用测试方法的环节。回到 Home 确认默认服务器，连接后运行 Connectivity Test，再核对认证和传输参数。不要把端口响应直接视为完整协议握手成功。
只有 Wi-Fi 超时，蜂窝网络正常怎么办？
保持同一服务器与目标，先完成 Wi-Fi 登录认证，再检查该网络的解析、端口及 UDP 可达性。向自己的服务商报告“同配置、不同接入网络”的对照结果，而不是直接要求更换协议。
订阅能更新，为什么服务器连不上？
订阅更新只说明列表获取成功，不代表列表内每台服务器都能完成认证。更新后在 Home 重新确认默认项，并对该项单独测试；向自己的服务商确认服务状态和凭据是否仍有效。
VPN 显示连接，但只有一个网站打不开？
先用另一已知目标对照，再检查 Home → Global Routing 与 Config 的命中规则。若其他目标正常，继续调查该域名的解析、规则和目标响应，不要马上重建全部配置。
排查结束应同时满足：预期服务器已被选中、协议参数与原配置一致、系统时间正确、目标请求走预期路径，并且相同条件下多次复测结果稳定。保留修改前后的记录，恢复临时关闭的 On Demand 与临时改变的 Global Routing；若问题仍在，将最小复现步骤交给自己的服务商继续核查。