本文适用于已经在 Shadowrocket（小火箭）中导入自己已有配置，却遇到延迟测试超时、连接开关已打开但请求失败的用户。按测试含义、本地网络、协议字段、系统时间与 TLS 的顺序核对，每次只改变一个条件；最后用相同请求复测，区分服务器不可达、参数不匹配与规则未命中。
一、先区分延迟测试与实际连接
“超时”只说明某一步没有在等待期限内完成，不直接等于密码错误或服务器停机。延迟测试使用的探测方式不同，覆盖的链路也不同：TCP 握手成功，只能说明当时可以建立到目标地址与端口的 TCP 连接；通过代理执行的 HTTP 请求，还会涉及协议协商、目标站访问与响应返回。两者不能相互替代。
先在 Home 记录选中的配置名称、测试方式和结果，再用浏览器访问一个自己平常能够访问的 HTTPS 页面。这里的访问是诊断动作，不需要提供任何账号信息。不要把一次测试结果当作长期状态，也不要只凭 VPN 标识判断代理链路已经可用：系统隧道建立与远端认证成功是不同环节。
| 观察结果 | 可以判断什么 | 下一步 |
|---|---|---|
| TCP 测试成功，网页失败 | 端口可建立连接，不代表协议认证或 TLS 成功 | 核对 Type、凭据与 TLS 字段 |
| 延迟测试超时，网页能打开 | 测试方式、测试目标或探测路径可能有差异 | 记录测试方式，重复同一实际请求 |
| Wi-Fi 失败，蜂窝网络成功 | 故障与接入网络相关，但尚不能定位具体设备 | 检查 Wi-Fi 登录、DNS 与网络限制 |
| 只有一个网站失败 | 不宜直接归因于整条连接不可用 | 查看该请求的规则命中与目标响应 |
结论：保留一项实际访问验证
如果延迟数字与网页结果冲突，先保留当前配置，记录测试方式和实际请求结果，再按失败环节排查，不要立即批量替换协议或重置所有设置。
二、用六步固定测试条件
排查期间使用一个已有配置和同一个测试页面。切换网络、更新订阅、改变路由模式都可能影响结果；一次同时修改多个条件，会丢失因果关系。以下步骤用于建立可重复的基线，不是建议长期保持某一种路由姿态。
-
记录原设置
在 Home 记下选中的配置与 Global Routing 当前姿态；到 Settings → On Demand 查看按需连接状态。若它在测试期间自动重连，先记录原条件，再暂时停用，结束后恢复。
-
验证本地网
暂时关闭连接，确认当前 Wi-Fi 或蜂窝网络可以正常访问日常页面。公共 Wi-Fi 若有网页登录认证，先完成认证，再打开 Shadowrocket 的连接开关。
-
固定配置
回到 Home 选择需要检查的配置，确认不是同名的另一条记录。暂时不要反复更新订阅，以免地址、端口或凭据在测试中途发生变化。
-
隔离规则
在 Home → Global Routing 临时选择 Proxy，使用同一测试页面验证代理路径。Proxy 用于隔离规则影响，不保证任意页面都可访问；Direct 会直接连接，不能用于证明所选代理可用。
-
切换网络
保持配置与页面不变，分别在 Wi-Fi、蜂窝网络重复测试。可各测试三次，记下成功或超时及发生时间；这是建议的记录方法，不是预设的测试结论。
-
恢复姿态
测试结束后把 Global Routing 恢复为原来的 Config、Scene 或其他姿态，并恢复 On Demand 条件。若 Proxy 可用而 Config 不可用，再检查 Config 中的活动配置与规则。
如果切换到蜂窝网络后恢复，优先检查原 Wi-Fi，而不是马上修改密码。反过来，两个网络都在同一个阶段失败，也只说明需要继续查共享条件，例如地址、端口、认证参数或服务器状态，并不能单凭这一点断定是哪一项错误。
三、逐项核对地址、端口与协议字段
在 Home 打开该配置的编辑页面，与自己的服务商提供的原始资料逐项比对。Type 决定客户端使用的协议，不能只因地址相同就随意改选。地址字段通常填写主机名或 IP，不应把整段订阅 URL 当成服务器地址，也不要把网页路径填进主机名字段。
| 设置项或协议 | 核对内容 | 常见误判 |
|---|---|---|
| 地址与端口 | 检查主机名拼写、端口数字及首尾空格；以原始配置为准 | 443 只是常见端口示例，不代表任何服务都应改成 443 |
| Shadowsocks | 加密方法、密码与服务端一致；有插件时同时核对插件配置 | 只验证端口可达，忽略加密方法不匹配 |
| VMess / VLESS | 核对 UUID、传输方式，以及配置使用的 TLS、Host、Path 等参数 | 把 UUID 当成普通密码，或遗漏传输层字段 |
| Trojan | 核对密码、TLS 与 SNI，确认与服务端证书和配置相符 | 认为端口通畅就说明 TLS 和密码都正确 |
| Hysteria2 | 核对认证信息、TLS 及已有配置中的混淆参数，并确认网络允许所需 UDP 通信 | 使用 TCP 探测结果判断基于 QUIC 的连接状态 |
| WireGuard | 核对密钥、Endpoint、隧道地址和路由范围，检查 UDP 可达性 | 把没有 TLS 证书的协议也按 SNI 问题处理 |
例如，原资料明确写明端口为 8443 时，就应检查编辑页是否仍为 8443，而不是因为它使用 TLS 就改成 443。类似地，TLS 的 SNI 用于握手中的服务器名称，传输层的 Host 用于对应传输的主机信息；即使两者在某份配置中相同，也不能推定所有配置都必须相同。
- 复制凭据时检查首尾空格、换行和全角符号，避免手工重输长字符串。
- 不要通过“依次尝试所有加密方法”排查；先取得原始字段，再逐项比对。
- 更新订阅后，重新确认 Home 当前选中的记录；新增或改名的记录不一定就是此前选中的那一条。
- 提交问题时遮盖密码、UUID、私钥和订阅 token。保留协议类型及错误阶段通常已足够开始定位。
四、检查 iPhone 系统时间与 TLS 证书
TLS 校验不仅检查证书对应的名称，还会检查有效期。iPhone 的时间明显偏离实际时间，可能让尚未生效或已经过期的判断出现偏差。进入 iPhone 的“设置 → 通用 → 日期与时间”，检查“自动设置”以及当前显示时间；如果选项受管理策略限制，应先确认设备管理要求。
时间修正后，重新建立连接再测试。若仍出现证书错误，需要区分是设备时间问题、服务端证书过期，还是 SNI 与证书名称不符。设备时间正确，并不能修复服务端已经过期的证书；把连接地址改成 IP，也不会自动解决证书名称匹配问题。
不要用 Allow Insecure 掩盖证书问题
Allow Insecure（允许不安全）会削弱证书验证，不应作为常规修复办法。保留验证，核对 SNI 与原始资料，并让自己的服务商确认服务端证书。不要为消除一条报错随意开启它。
- 检查时间：确认日期、时间和时区设置合理，尤其是在手工改过时间之后。
- 检查名称：SNI 使用已有配置要求的名称，不填写带
https://的完整 URL，也不附加路径。 - 检查有效期：设备时间正确仍提示证书过期时，记录原始错误并联系自己的服务商核实。
- 区分协议：只有实际使用 TLS 的连接才按本节检查；WireGuard 的密钥和握手问题不通过调整 SNI 解决。
五、按日志报错定位失败阶段
同样是“网页打不开”，底层可能分别发生在名称解析、连接建立、TLS 握手或认证阶段。复现一次后，在应用可用的诊断日志中查找对应时间的记录，保留完整错误文本。下面列出的是常见底层错误片段；具体大小写、前缀及展示位置可能随协议实现而不同，不代表每次都会出现同一文案。
报错：i/o timeout
原因与解法：某次读写操作超过等待期限，单独这一句不能确定是哪一层失败；结合前后日志确认目标地址和阶段，再保持配置不变切换 Wi-Fi 与蜂窝网络复测。
报错：connection refused
原因与解法：目标或中间设备明确拒绝了连接，可能与端口未监听或访问策略有关；先核对端口及协议，仍一致则让自己的服务商确认该端口的服务状态。
报错：no such host
原因与解法：解析阶段未能取得可用主机地址，可能是拼写或 DNS 响应问题；核对服务器主机名，并在另一接入网络复测，不要直接改动认证参数。
报错：x509: certificate has expired or is not yet valid
原因与解法：证书有效期与当前时间不匹配；先检查 iPhone 自动时间，时间正确则向自己的服务商确认服务端证书，不以关闭验证作为长期处理方式。
记录时应写清“哪个请求、哪个网络、何时失败”，而不是只提交一张红色超时截图。日志如果只显示连接被关闭，也不能直接推断密码错误：服务端策略、传输参数不匹配或网络中断都可能提前关闭连接，需要结合前面的字段核对。
结论：围绕最早失败环节修改
若同一次请求最早失败在主机名解析，就先处理地址与 DNS；只有连接已经进入 TLS 或认证阶段，才继续核对相应字段，避免在尚未到达的环节反复改参数。
六、连接恢复后的规则与订阅复查
如果 Proxy 姿态下可以访问，而恢复 Config 后失败，应检查活动配置的规则和策略目标。DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按 IP 网段匹配，GEOIP 使用地理 IP 条件，FINAL 负责最终兜底；不能把这些条件当作完全相同的域名判断。规则顺序、实际请求域名及最终命中的策略都需要一起看。
例如，用户已有配置中的 FINAL,DIRECT 表示未匹配前面规则的连接直接出站；某个页面能打开，不足以证明它通过代理。反过来，站点主页面与资源域名可能不同，仅匹配主域名也不代表所有资源走相同路径。先看请求记录中的实际域名与命中规则，再决定是否修改 Config。
为什么延迟测试有数字，网页还是打不开？
先确认测试方式。TCP 可达不等于协议认证成功；在 Home 核对选中的记录与 Global Routing，临时用 Proxy 复测，再检查协议字段和 TLS 日志。测试结束恢复原姿态。
订阅更新超时，是所有配置都失效了吗？
不是。订阅更新访问的是订阅地址，与已保存配置的连接是两条不同请求。在 Home 核对订阅记录，确认自己的订阅仍有效，并检查 Settings → Subscribe → Update via Proxy 是否符合当前可用路径；不要在代理本身不可用时反复依赖它更新。
切到 Direct 后网页能打开，算修好了吗？
只能证明该页面可以直接访问，不能证明代理配置恢复。回到 Home → Global Routing，以 Proxy 验证所选配置，再恢复 Config 检查规则；如果原来使用 Scene，还需检查对应场景的实际路由设置。
为什么手动断开后又自动连上？
到 Settings → On Demand 检查按需连接条件。为了固定测试环境，可记录条件后暂时停用，完成排查再恢复；自动重新建立系统连接不代表远端认证已经成功。
七、整理可复现记录再提交问题
完成上述检查后，仍然失败就把结果整理成最小记录，向自己的服务商确认服务端状态。不要在公开反馈中粘贴完整订阅地址；订阅链接中的 token 通常具有访问权限，截图也应遮盖二维码和凭据。客户端购买信息与连接服务配置分开处理，购买应用不会补齐缺失的服务器参数。
- 环境：iPhone 或 iPad、实际系统信息、Wi-Fi 或蜂窝网络；系统兼容要求以 App Store 页面标注为准。
- 配置：协议 Type、端口、是否使用 TLS 与传输方式，不附密码、私钥或完整订阅链接。
- 姿态：Global Routing 使用 Proxy、Direct、Config 还是 Scene，On Demand 是否在测试中启用。
- 结果：同一页面在两种网络下各三次的成功或失败记录，以及所用延迟测试方式。
- 日志：一次复现的时间点和最早错误原文，删除敏感字段后保留必要上下文。
当地址与端口、协议字段、设备时间均已核对，且不同网络仍在同一阶段稳定失败时，再让自己的服务商检查监听状态、认证资料和证书，通常比继续随机修改本地设置更有针对性。最后恢复原来的规则与 On Demand 条件，确认日常访问也按预期运行。