Shadowrocket（小火箭）显示超时，不等于所有连接参数都失效。本文以用户已有自己的服务商与订阅为前提，按基础网络、延迟测试、协议字段、系统时间、DNS 与分流的顺序定位问题。每次只改一个变量，并用同一目标复测，最后保留可复现的现象与错误记录。
一、先区分测试超时与实际连接失败
先给结论：延迟测试是诊断线索，不是连接成功证明。TCP 测试主要观察指定地址与端口能否建立 TCP 连接，不能确认密码、UUID 或后续 TLS 握手正确；通过代理访问测试 URL，则还会涉及协议协商、目标域名解析与目标站点响应。两种测试测量的范围不同，结果不能直接互换。
系统显示 VPN 已连接，也只说明系统隧道已经建立，不能据此判断远端服务、DNS 和每条分流规则都正常。应把“测试失败”“连接开关开启”“实际网页能否访问”分开记录。对于使用 UDP 的协议，单独一次 TCP 端口测试尤其不能作为有效性结论。
- 只有测试超时：先记录测试方式和测试目标，再实际访问一个已知可用的 HTTPS 页面，不立即删除节点。
- 测试有数值但访问失败：继续检查认证、TLS、DNS 和规则，不能只凭延迟数值跳过参数核对。
- 仅一个网站失败：优先确认目标网站、命中策略和域名解析，不先认定整个连接不可用。
二、建立可重复的排查基线
先保留当前选中的节点、Global Routing 姿态以及 Config 名称，避免排查结束后无法恢复。以下步骤使用同一节点、同一测试目标；切换 Wi-Fi 与蜂窝网络时，也不要同时更换协议或 DNS。蜂窝网络测试会消耗移动数据，可根据自己的套餐决定是否执行。
-
确认基础网络
先记录 Settings → On Demand 的当前设置，排查期间暂时关闭自动触发，再关闭 Home 的连接开关。访问已知可用的网站；公共 Wi-Fi 若有登录认证页，先完成认证。
-
固定测试对象
回到 Home，选择要检查的节点，记录延迟测试方式和目标。连续测试三次，分别记录成功、超时或具体错误；这三次用于复现现象，不据此推算长期可用率。
-
对照网络环境
在条件允许时，用同一节点分别在 Wi-Fi 与蜂窝网络复测。若只在一种网络失败，先检查该网络的认证、DNS 与传输限制，不同时重填全部节点参数。
-
验证实际请求
开启连接，在 Home → Global Routing 中临时选择 Proxy，再访问相同 HTTPS 目标。这样可减少 Config 分流的干扰；测试完恢复原姿态，避免将诊断设置长期保留。
三、逐项核对地址、端口与协议字段
在 Home 打开对应节点的编辑页面，以自己已有服务商给出的原始配置为准逐项比对。不要仅凭节点名称判断协议；名称可以保留旧信息，而实际字段已经变化。地址栏应填写要求的主机名或 IP，不把整段分享链接、订阅 URL 或带路径的网址当作服务器地址。
| 检查项 | 具体核对内容 | 常见误判 |
|---|---|---|
| Address / Port | 逐字比对服务器地址与端口。端口范围为 1–65535，实际值由原始配置指定。 | 把 443 当作所有节点的默认值；实际配置为 8443 却自行改成 443。 |
| Shadowsocks | 同时比对加密方法与密码；如有插件或额外传输参数，也需与服务端一致。 | 端口可达就认为密码正确，或自行替换加密方法。 |
| VMess / VLESS | 核对 UUID、传输类型、TLS，以及所选传输涉及的 Host、Path 或 Service Name。 | 只核对 UUID，遗漏 WebSocket 路径或 gRPC 的服务名称。 |
| Trojan | 核对密码、服务器地址、端口、TLS 与 SNI；附加传输设置按原始配置填写。 | 地址改成 IP 后同时把 SNI 清空，造成证书名称不匹配。 |
| Hysteria2 | 核对认证信息、TLS 与服务端要求的混淆参数，并确认网络允许相应 UDP 通信。 | 用 TCP 测试失败直接判定基于 QUIC 的连接不可用。 |
| WireGuard | 核对本地 PrivateKey、对端 PublicKey、Endpoint、Address 与路由范围。 | 混淆两类密钥，或把缺少 TLS 报错当作 WireGuard 已完成握手。 |
如果节点来自订阅，先核对订阅最近一次更新是否成功，再比较更新后的字段。更新订阅与连接节点是两个不同请求：订阅更新成功只说明取得了配置，不说明其中每个节点都能连接。手动修改前先保存必要信息，因为后续订阅更新可能覆盖本地调整。
结论：端口可达后继续查握手
若 TCP 测试能返回结果，而实际代理请求仍失败，下一步应核对认证、TLS 与传输字段，不要仅围绕端口反复修改。对于 UDP 协议，应结合实际协议请求判断。
四、按错误所在阶段缩小范围
查看应用内连接记录时，保留错误前后的上下文，尤其是错误涉及服务器地址、DNS 查询还是目标网站。下列是网络错误中可能出现的原文片段，具体大小写和完整措辞随错误来源而异；不能把任何一种英文片段当作 Shadowrocket 必然显示的固定提示。
报错：i/o timeout
原因与解法：某个网络读写阶段没有在期限内完成，单看这段文字无法区分端口、握手或目标响应问题。先确认上下文中的目标地址，再按基础网络、端口和协议字段的顺序检查。
报错：connection refused
原因与解法：连接收到了拒绝响应，可能是目标端口未监听或中间设备主动拒绝。先核对地址与端口，再向自己的服务商确认该入口是否仍在服务，不通过随机换端口排查。
报错：no such host
原因与解法：相关主机名解析失败，可能是地址拼写错误、记录不存在或当前解析路径异常。先确认报错中的域名属于节点还是目标网站，再核对该域名与 DNS 配置。
报错：certificate has expired or is not yet valid
原因与解法：证书有效期检查未通过，可能与设备时间或服务端证书有关。先校准 iPhone 时间；时间正确仍失败时，向自己的服务商确认服务端证书状态。
不要为消除证书错误而关闭证书校验。地址、SNI 与证书所覆盖的域名需要一致；即使通过某种设置绕过了错误，也没有修复名称或证书本身的问题。
五、确认 iPhone 系统时间与 TLS
在 iPhone 的“设置 → 通用 → 日期与时间”中检查“自动设置”。若因设备管理策略无法调整，应先确认设备实际时间是否准确。证书有效期通常按绝对时间判断，单纯显示为不同的时区，并不一定代表系统时钟错误。
- 时间明显偏差：恢复准确时间后，断开并重新建立 Shadowrocket 连接，再测试同一目标。
- 时间正确但证书失败：回到节点编辑页核对 TLS 与 SNI，尤其检查是否误把服务器 IP 当成证书域名。
- 只有某个目标失败：检查错误是否来自目标网站证书，而不是代理服务器握手，不把两者混为一谈。
- 参数近期变动：对照自己的服务商提供的当前配置，确认是否更换入口域名或证书相关要求。
部分认证机制也依赖合理的系统时间。时间校准应作为明确的检查项，而不是每次失败都重复执行的通用修复。校准后错误不变，就继续检查下一环节，避免在同一项上反复操作。
六、最后检查 DNS 与 Config 分流
当协议字段和时间均已核对，再区分“节点域名无法解析”与“连接建立后目标域名无法解析”。前者会阻止建立远端连接，后者可能表现为连接开关正常、部分网站仍打不开。直接打开某个 IP 并不能完整验证 HTTPS，因为证书名称和网站虚拟主机仍可能依赖域名。
若使用 Config，在 Config 中确认当前选中的配置，再查看编辑内容中的 [General] 与 dns-server 设置。不要把另一份未启用配置中的修改当成已经生效；也不要一次叠加多个陌生 DNS 地址。先保存原值，单独调整一项后复测同一域名。
- 检查规则顺序：
DOMAIN-SUFFIX匹配域名后缀，IP-CIDR匹配地址段，GEOIP涉及 IP 地理归属，不能把这些规则当作相同的判断条件。 - 检查最终策略：
FINAL是前面规则未匹配时的兜底；其策略若与预期不一致，可能让目标走不同出口。 - 比较姿态：同一节点在 Proxy 下可用、在 Config 下失败时，优先查看规则、策略引用与配置中的 DNS，而不是重新填写已经验证过的认证字段。
- 恢复现场：每次对照测试结束，恢复原来的 Global Routing 与 On Demand 设置，并记录最终保留的修改。
七、常见追问与排查结果整理
延迟有数值，为什么还是打不开网页？
先确认测试方式。TCP 连通不等于认证和 TLS 成功；在 Home → Global Routing 临时选择 Proxy，访问同一 HTTPS 目标，再核对握手错误。若 Proxy 可用而 Config 不可用，回到当前 Config 检查规则与 DNS。
订阅更新成功，节点为什么还会超时？
取得订阅内容与连接远端入口是两条链路。先打开节点编辑页，比对地址、端口与协议字段，再按同一测试方式在当前网络复测；不要把“更新成功”当作所有节点的连通证明。
Wi-Fi 不通，蜂窝网络正常，要重新添加吗？
先不删除。保持节点参数不变，检查 Wi-Fi 登录认证与 DNS；若使用 Hysteria2 或 WireGuard，还要确认该网络的 UDP 通信条件。向网络管理方或自己的服务商描述对照结果，比反复重新添加更利于定位。
给自己的服务商反馈时要发什么？
提供故障时间及所在时区、网络类型、协议类型、测试方式、完整错误片段，以及 Proxy 与 Config 的对照结果。隐藏密码、UUID、PrivateKey 和订阅 token；不直接发送未经检查的完整配置或截图。
排查完成后，留下“修改前现象、唯一修改项、修改后结果”三项记录。如果仍然失败，也应保留最后一次可复现的测试条件。这样下次检查能从明确的阶段继续，而不是重新随机调整所有设置。