Shadowrocket 节点超时、连接失败:延迟测试、协议参数与系统时间的排查顺序

一、先确认故障范围，保留可对照的现场

先区分三件事：订阅更新失败、节点测试失败，以及连接后某个网页打不开。这三类现象可能发生在不同环节。订阅更新是在获取配置数据；节点测试是在执行所选测试方式；网页访问还涉及路由、DNS、协议握手与目标网站。不能仅凭一个“超时”把这些环节归为同一个问题。

开始前在 Home 记下当前选中的节点名称、Global Routing 的选项以及错误出现的操作。保留 Config 中原有配置，不要先清空规则。如果 Settings → On Demand 已启用，也记录这一状态；在需要手动断开作对照时，先确认它没有按既有条件重新触发连接。

1. 检查基础网络：暂时断开连接，确认当前 Wi-Fi 或蜂窝网络能打开一个平时可直连的页面。若 Wi-Fi 需要网页登录认证，先完成认证。
2. 固定测试对象：选定自己已有的一个节点，后续核对与测试围绕同一个节点进行，避免把不同配置的结果混在一起。
3. 记录原始结果：写明是测试超时、连接开关无法维持，还是仅某个应用请求失败，并保留完整错误文本。
4. 一次只改一项：修改后用相同操作复测；没有改善时恢复该项，再继续下一步。

二、看懂延迟测试：有数值与可用连接不是同一件事

先确认测试方式，再解释测试结果。TCP 握手侧重检查地址与端口的可达性，不会验证完整代理协议的认证过程；通过节点发起的 HTTP 请求测试，会涉及更多环节，包括测试目标本身。两种方式得到的时间含义不同，不宜直接比较，更不能把数值当作下载速度。

在 Home 对同一节点重复执行当前测试，记录结果是否稳定。若应用中选择了不同测试方式，把方式一并记下。下面的三次测试是排查记录建议，不是应用规定的次数；目的是区分持续失败与偶发抖动。

如果同一配置在 Wi-Fi 下失败、蜂窝网络下成功，差异首先指向网络路径或该网络的限制，但还不足以确认具体原因。若两种网络都失败，也不能直接断言服务端停机；地址错误、过期凭据、DNS 解析异常和协议不匹配仍需逐项排除。

三、核对地址、端口和协议参数，不用猜测值替换

从 Home 打开当前节点的编辑页，与自己的服务商提供的原始配置逐项对照。先看类型是否一致，再看地址和端口，最后看认证、TLS 与传输字段。订阅导入成功只表示客户端获得并解析了数据，不代表其中每个节点都能完成连接。

使用域名时，还需要考虑解析得到的地址是否正确。不要为了绕过解析而随意把域名换成 IP：这可能改变服务端入口选择，并影响 TLS 主机名校验。对于使用 WebSocket 的配置，路径、Host 与 TLS 的 SNI 各有作用，不能因为看起来都是域名就互相替换。

• 复制密码、UUID 或密钥时，检查前后空格、换行和截断；不要靠截图手工猜字符。
• 若自己的服务商确认参数已变更，先保留现有配置，再更新对应订阅；更新后重新确认实际选中的节点。
• 订阅更新失败时，先确认链接有效与当前网络可达，不要先删除唯一的一份可用配置。
• 不要通过关闭证书校验来掩盖 TLS 错误；先检查系统时间、SNI 和证书状态。

四、检查 iPhone 系统时间，再分析 TLS 错误

iPhone 的日期、时间或时区明显不正确，可能影响证书有效期判断，也可能影响需要时间校验的认证过程。证书包含生效与到期时间；设备时钟偏差过大时，即使地址和密码正确，也可能在握手阶段失败。这不是所有超时的共同原因，但属于成本较低、应当核对的项目。

1. 打开 iPhone 系统“设置”→“通用”→“日期与时间”，检查“自动设置”是否开启。
2. 确认显示的日期、当地时间与时区合理。若开关不可更改，检查设备管理或使用限制，不要随意移除管理配置。
3. 返回 Shadowrocket，断开后重新连接同一节点，再执行相同测试。
4. 若仍是 TLS 相关错误，把错误原文与发生时间交给自己的服务商，确认服务端证书、证书链及域名配置。

正确的系统时间只是必要检查之一，不会自动修复证书过期、证书名称不匹配或服务端配置异常。下面列出常见网络错误原文的判读方向；只有实际日志出现相应文本时才按该项分析，具体措辞可能随系统与失败阶段变化。

五、连接后仍打不开：核对 Global Routing 与规则命中

连接开关处于开启状态，不代表每个请求都经过当前节点。Home → Global Routing 决定整体路由方式：Proxy 用于代理路由，Direct 用于直连，Config 按当前配置处理，Scene 按已设置的场景选择相应路由方式。排查时先记下当前选项，不要只检查节点名称。

如果需要隔离规则影响，可以在确认测试范围后，短暂用 Proxy 对同一个目标发起请求，再恢复原来的选项。这会改变测试期间其他请求的路由，操作前应了解影响。若 Proxy 下成功而 Config 下失败，再检查 Config 中当前启用的配置及请求实际命中的策略，而不是继续更换密码。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

这段内容仅说明匹配顺序，不是完整配置。DOMAIN-SUFFIX 匹配域名后缀，GEOIP 根据 IP 地理归属判断，IP-CIDR 匹配地址段，FINAL 接住前面没有匹配的请求。规则按顺序判断；示例中的 192.0.2.0/24 是文档示例网段，不应据此修改真实业务路由。使用时还需确认策略名称在自己的配置中有效。

• 仅一个域名失败：对照该请求的域名、解析结果和命中策略，排除目标站点自身异常。
• 所有经节点请求失败：回到协议参数与握手检查，不用扩大修改规则的范围。
• 网页可用但特定业务失败：区分该业务是否依赖 UDP、额外域名或不同端口；普通网页测试不能覆盖全部传输条件。

六、常见追问与提交故障记录

提交问题时，提供能区分失败阶段的信息，比只写“不能用”更有效。记录可以按下面的顺序整理；其中节点名称可自行匿名处理，认证字段不属于排查公开材料。

• 环境：设备类型、系统信息、Wi-Fi 或蜂窝网络，以及故障开始的当地时间与时区。
• 测试：测试方式、同一节点三次结果、切换接入网络后是否变化。
• 配置：协议类型、端口、Global Routing 当前选项，以及是否启用 On Demand。
• 现象：完整错误原文、失败发生的步骤、是全部请求失败还是单个目标失败。
• 隐私：遮盖订阅链接中的 token、密码、UUID、私钥及其他认证信息，不公开完整配置。

按这个顺序完成检查后，应能把问题收敛到基础网络、服务端可达性、协议握手、设备时间或请求路由中的某一环节。确认故障所在层级后再修改对应设置，复测成功后恢复临时改动，避免把用于诊断的路由状态留作日常配置。