本文用于排查 Shadowrocket（小火箭）已有连接条目的超时、握手失败及连接后无法访问问题，前提是用户已有自己的服务商与订阅。按基础网络、测试类型、服务端参数、系统时间和规则路由逐项验证，每次只改一个变量，最后用同一目标复测。下文菜单操作以 iPhone / iPad 界面为参照，其他平台的系统授权与菜单位置可能不同。
一、先分清超时发生在哪一层
Home 显示测试超时，并不等于已经确定服务端离线。一次访问通常需要经过系统隧道、规则匹配、地址解析、代理连接和目标响应；其中任意环节未在时限内完成，都可能表现为等待后失败。先记录“测试失败”还是“实际网页失败”，不要直接删除全部配置。
在同一台设备上暂停 Shadowrocket 连接，访问平时能够直连的网站。若此时也失败，先处理 Wi-Fi 认证、移动数据权限或网络本身的问题。公共 Wi-Fi 尚未完成网页认证时，反复更换节点通常不能解决问题。
- 全部条目同时失败：优先检查当前网络、系统时间、订阅是否有效，以及是否存在共同的解析问题。
- 只有一个条目失败：先核对该条目的地址、端口和协议字段，再向自己的服务商确认对应服务状态。
- 测试有数值但网站失败：继续检查 Global Routing、实际命中的动作、DNS 和目标站点，不把延迟数值当成完整可用证明。
- 前台可用，切换网络后失败：记录 Wi-Fi 与移动数据的差异，并检查 Settings → On Demand 中是否有自动连接条件影响复测。
二、用固定条件做延迟与访问测试
不同测试验证的范围不同。TCP 连接测试通常只能说明指定地址与端口能够建立连接，不能证明凭据正确、TLS 握手成功或目标网页可访问。Home 中的 Connectivity Test 则需要结合所选测试方式和目标理解结果，不能直接拿不同测试方式的数值比较。
-
保存现场
记录当前条目名称、测试方式、Global Routing 状态与失败时间；在 Config 中保留当前配置副本。截图或抄录结果时遮住凭据和订阅地址。
-
固定条目
在 Home 选定一个已有条目，避免让自动选择策略在测试期间切换出站。记录当前使用 Wi-Fi 还是移动数据。
-
重复测试
使用同一种 Connectivity Test 连续测试三次，分别记录成功、失败及显示的耗时。不要把偶尔一次成功视为问题已经消失。
-
访问目标
打开连接开关，在浏览器访问同一个已知可用的 HTTPS 页面。将“测试有结果”和“页面实际打开”分开记录。
-
更换网络
保持条目和目标不变，只在 Wi-Fi 与移动数据之间切换，再重复上述测试；留意移动数据可能产生的流量费用。
结论：先确定差异发生在网络还是条目
若同一条目只在某个网络失败，先查该网络的解析与传输限制；若不同网络下都只有同一条目失败，转向地址、端口和协议参数核对，不继续随机调整所有设置。
三、逐字段核对地址、端口与协议参数
在 Home 打开对应条目的编辑页，与自己的服务商提供的原始参数逐项比对。服务器地址字段应是主机名或 IP，不应混入网页路径、空格或协议前缀；端口应是对方明确提供的数值。例如对方给出端口 443，不能因为常见示例使用 8443 就自行替换。端口号本身也不能证明服务使用了哪种协议。
| 协议或层次 | 重点核对 | 容易漏掉的差异 |
|---|---|---|
| Shadowsocks | 地址、端口、Password、加密方法 | 加密方法必须与服务端一致，密码正确也不能补偿方法不匹配。 |
| VMess / VLESS | UUID、传输方式、TLS 及服务端指定的附加参数 | 不能只复制 UUID；WebSocket 路径、Host 等字段也需要按原配置填写。 |
| Trojan | Password、TLS、Server Name | 连接地址与证书对应名称可能不同，应保留服务端要求的名称。 |
| Hysteria2 | 认证信息、TLS、服务端指定的端口与附加设置 | 依赖 UDP 传输，TCP 端口探测结果不能代替实际协议测试。 |
| WireGuard | 密钥、Peer 公钥、Endpoint、隧道地址与路由范围 | 需要检查握手及数据收发，不能按密码式代理的字段进行排查。 |
对于使用 TLS 的连接，还要区分服务器地址、Server Name 与 HTTP Host：它们处在不同层次，不能因为看起来都像域名就互相替换。WebSocket 的路径也可能区分大小写，漏掉开头的斜线或多出空格都可能导致失败。
四、按报错原文缩小范围，再检查系统时间
日志中的错误比“连不上”更有定位价值。以下是可能出现的底层错误片段，大小写、前缀和具体措辞可能因平台及连接阶段而不同；应以设备实际记录为准。保存故障发生时的原文，不把所有错误都统称为节点超时。
报错：i/o timeout
原因与解法：某次网络读写未在时限内完成，但单凭这句话无法确定阻塞位置；结合前后日志确认是解析、连接还是读取响应，再用同一条目切换网络复测。
报错：connection refused
原因与解法：连接请求被明确拒绝，常见于端口未监听或设备主动拒绝；先比对地址和端口，再向自己的服务商确认该端口上的服务状态。
报错：TLS handshake timeout
原因与解法：TLS 握手阶段未及时完成，可能涉及传输受阻或服务端无响应；先核对 TLS 开关、Server Name 与端口，再通过另一网络验证是否为路径问题。
报错：certificate has expired or is not yet valid
原因与解法：证书有效时间与当前系统时间不匹配；先校准设备时间，若仍失败，则由服务端管理方检查证书有效期。
iPhone / iPad 可在系统设置 → 通用 → 日期与时间中检查“自动设置”，确认日期、时区与当前时间一致。Windows、Mac、安卓和 Linux 则使用各自系统的日期与时间设置完成同步。修正后重新建立连接，再观察是否仍出现同一错误。
- 时钟偏差既可能影响 TLS 证书时间检查，也可能影响依赖时间窗口的协议认证。
- 系统时间正确不代表证书必然正确；证书过期、名称不匹配和证书链问题仍需分别处理。
- 只有某个目标网站出现证书问题时，应先区分是代理握手失败，还是目标网站本身的证书失败。
五、连接成功后，核对路由、DNS 与订阅状态
连接开关开启，仅说明系统隧道处于工作状态，不代表每个请求都经过选中的代理。到 Home → Global Routing 核对当前姿态：Proxy 用于全局代理路径，Direct 用于直连，Config 按当前配置分流，Scene 按场景配置工作。排查时可临时使用 Proxy 对同一目标复测，测试后恢复原有姿态。
- Proxy 可用而 Config 失败：检查 Config 中的规则顺序及实际命中结果。
DOMAIN-SUFFIX按域名后缀匹配，IP-CIDR按地址段匹配，GEOIP按地址归属匹配，FINAL处理此前未命中的连接。 - 命中 DIRECT：该请求未按预期走代理，应查前面是否有更早命中的规则，而不是继续修改节点密码。
- 命中 REJECT：请求被规则拒绝，优先核对规则目的与范围，不把它当成服务端无响应。
- 日志出现解析失败：检查配置中的 DNS 设置、服务器域名拼写及当前网络的解析可达性；不要随意把服务器域名替换成 IP，以免破坏 TLS 名称或连接到错误地址。
订阅更新属于另一条请求链路。更新成功只证明本次订阅内容能够下载和解析，并不证明每个条目都能使用；已有条目可连接，也不保证订阅链接仍然有效。若自己的服务商已更改参数，先在 Home 更新对应订阅，再核对条目是否实际变化。
结论：更新失败与连接失败分开记录
保留“订阅更新结果、选中条目、Global Routing 姿态、实际访问结果”四项记录。只有更新链路受阻且已有可用代理时，才考虑在 Settings → Subscribe 中检查 Update via Proxy；无法连接的代理不能为更新请求提供有效通路。
为避免自动连接干扰，复测前记录 Settings → On Demand 中的现有状态，必要时临时停用，再手动建立连接。完成测试后恢复原设置；不要把排查时的临时姿态长期留作日常配置。
六、常见追问与提交故障信息
延迟显示几十毫秒，为什么网页还是打不开？
先确认显示的是哪一种测试。TCP 建连快不等于协议认证和目标访问成功。在 Home 核对所选条目与 Global Routing，再访问同一个 HTTPS 页面，结合失败时的日志区分握手错误和规则分流问题。
Wi-Fi 超时，移动数据正常，要重新导入吗？
先不要删除订阅。保持同一条目和协议参数，检查 Wi-Fi 是否完成认证、解析是否成功；若使用 Hysteria2 或 WireGuard，还要考虑该网络对 UDP 的限制。将网络差异交给自己的服务商或网络管理方核实。
订阅更新后仍有一个条目超时，怎么办？
确认该条目的参数确实已更新，再对照原始参数核对地址、端口与认证字段。若其他条目在同一网络可用，提供这个条目的脱敏名称、失败时间和报错原文，请自己的服务商检查对应服务。
需要把完整配置发给别人检查吗？
通常先提供系统平台、使用的协议、网络类型、Global Routing 状态、测试方式和脱敏报错即可。不要公开订阅完整 URL、Password、UUID、私钥或包含认证信息的二维码；分享日志前检查其中的域名和个人信息。
完成一轮排查后，用原来的网络、条目和目标重新测试，并恢复为排查而临时修改的设置。若仍不能定位，将复现步骤写成“在哪个网络、选择哪个脱敏条目、使用哪种姿态、出现什么原文错误”，比仅发送一张超时截图更便于核查。