本文适用于已经导入自己服务商配置、但在 Shadowrocket 中遇到超时的用户。先区分测试失败与实际请求失败，再通过网络对照、协议参数核对和系统时间检查缩小范围。每次只改一项，并保留原始配置；排查结束后恢复原来的路由与 On Demand 设置。
一、区分延迟超时与请求失败
Shadowrocket（小火箭）中的延迟数值只代表对应测试方式的结果，不是完整的可用性证明。TCP 握手成功，不代表代理认证、TLS 握手和目标访问都成功；基于其他方式的测试超时，也不能直接证明所有实际请求都会失败。记录测试方式，比只记录一个数值更有用。
排查前先关闭连接开关，确认当前 Wi-Fi 或蜂窝网络能完成普通网页访问。如果 Wi-Fi 需要登录认证页，应先完成认证。基础网络本身不可用时，反复编辑服务器参数不会解决问题。
- 单条超时：其他已有服务器在同一网络下可用，优先核对该条目的地址、端口与服务状态。
- 全部超时：优先检查基础网络、域名解析、测试方式与订阅状态，不要立即逐条重填参数。
- 延迟正常但网页失败：继续检查认证、TLS、Global Routing 与目标请求命中的规则。
- 只有某个网站失败：记录目标域名与错误，不把目标站点问题等同于整个代理连接失效。
二、先做一次可复现的连接测试
在 Home 中确认 SERVER 列表的默认服务器标记。不要仅凭展开了某个分组或看到了某条记录，就认为实际连接使用了它。测试期间避免同时切换服务器、网络和路由模式，否则无法判断是哪项变化带来了结果。
-
记录现状
在 Home 记录默认服务器、Global Routing 当前值和连接开关状态。到 Settings → On Demand 查看是否启用了按需连接；若它会自动重连，可在记录原值后暂时关闭。
-
执行延迟测试
使用 Home → Connectivity Test，记录所用测试方式与结果。对同一条目重复测试两到三次，区分持续超时与偶发失败，不要只依据一次结果删除配置。
-
验证实际请求
选定默认服务器并打开连接开关。必要时暂将 Global Routing 设为 Proxy，再访问一个已知可用的 HTTPS 页面，以减少 Config 中分流规则带来的干扰。
-
更换基础网络
保持同一服务器与同一路由模式，仅在 Wi-Fi 和蜂窝网络之间切换。每次切换后等待网络稳定，再重新连接并访问同一个页面。
-
保存对照结果
分别记录网络类型、测试结果、实际访问结果和错误原文。测试完成后恢复原来的 Global Routing 与 On Demand 状态，避免临时设置影响日常使用。
Proxy 用于验证代理路径；Direct 让请求直接访问，不能据此证明服务器可用。Config 按当前配置处理请求；如果当前使用 Scene，还要核对相应场景的生效条件。短时切换模式属于定位手段，不应当作长期修复方案。
三、逐项核对协议参数
从 Home 打开对应服务器的编辑详情，与从你的服务商处获取的原始信息逐项对照。先核对 Type、地址和端口，再核对认证与传输选项。不要把域名、SNI、Host 当成同一个字段，也不要因为常见示例使用 443，就把自己的端口改成 443。
| Type | 优先核对 | 容易混淆的条件 |
|---|---|---|
| Shadowsocks | 地址、端口、加密方法、密码 | 加密方法必须与服务端一致；插件参数仅在服务端要求时配置。 |
| VMess | UUID、传输方式及服务端要求的认证选项 | 使用 WebSocket 时继续核对 Path 与 Host；TLS 设置须与服务端一致。 |
| VLESS | UUID、传输方式及 Flow（如适用） | 不要将另一条配置的 TLS 或传输参数直接套用。 |
| Trojan | 密码、端口、TLS 与服务端名称 | 地址可达仍可能因密码或证书名称不匹配而失败。 |
| Hysteria2 | 认证信息、TLS、混淆设置（如适用） | 依赖 UDP 路径；单纯 TCP 端口测试不能验证其完整可用性。 |
| WireGuard | 密钥、Endpoint、接口地址与 Allowed IPs | 使用 UDP；密钥不匹配或路由范围错误也会导致无法传输数据。 |
判断：跨网络复现后再改参数
同一配置只在一种网络失败时，先向服务商确认该网络下的端口和 UDP 可达性；在两种网络都失败时，再集中核对服务状态与协议字段。不要同时修改端口、密码和 TLS 选项。
如果使用订阅管理服务器，手动修改导入条目后，后续更新可能重新写入服务商配置。先保存脱敏记录，再更新对应订阅，确认更新成功且条目确实发生了预期变化。订阅获取成功只说明订阅地址可访问，不代表其中每个服务器都可用；订阅失败也不等于已保存的服务器立即失效。
四、按错误原文定位失败阶段
错误日志可能来自不同网络层，具体措辞会随连接类型变化。以下是常见错误片段，只有实际出现时才据此判断。记录完整错误及发生时间，不要把所有失败统一写成“超时”。
报错：i/o timeout
原因与解法：某阶段在等待期限内未收到预期响应，单凭这段文本不能确定是认证还是网络问题——结合前后日志确认失败阶段，再用同一配置切换基础网络验证。
报错：connection refused
原因与解法：连接被目标主机或中间设备主动拒绝，常见于端口未监听或访问被拒绝——先核对端口，再请服务商检查监听服务与访问策略。
报错：no such host
原因与解法：域名解析未能得到所需结果，可能是地址拼写或解析路径异常——对照原始服务器域名，并检查当前网络的解析情况，不随意用未知 IP 替换。
报错：certificate has expired or is not yet valid
原因与解法：证书有效期与当前校验时间不匹配，可能来自设备时钟或服务端证书——先校准设备时间，若仍复现，再由服务商核对证书有效期。
TLS 证书名称错误与证书有效期错误不是一回事。前者应核对服务端名称、SNI 和证书覆盖的域名，后者才重点检查时间及证书续期。不要通过关闭证书校验掩盖错误；这会移除身份验证，也不能修复服务端配置本身。
五、检查 iPhone 系统时间
TLS 会检查证书的生效与到期时间，VMess 的认证也涉及时间因素。设备日期偏离真实时间时，即使地址、端口和密码正确，仍可能失败。屏幕上显示的时区差异不一定代表系统时钟错误，应同时确认日期和实际时间。
- 打开 iPhone 系统的“设置”→“通用”→“日期与时间”，检查“自动设置”。这是系统设置，不是 Shadowrocket 的 Settings。
- 在网络可用的情况下启用“自动设置”，确认年份、日期与时间合理。若开关受管理策略限制，先联系设备管理人员处理。
- 返回 Shadowrocket，关闭连接开关，再重新连接同一服务器。复测同一页面，避免同时更新订阅或修改参数。
- 若时间已正确但仍提示证书过期，将错误交给服务商核对服务端证书；反复调整时区不会延长证书有效期。
六、延迟恢复后检查实际分流
如果 Proxy 下访问正常，而恢复 Config 后失败，排查重点应转向 Config 中当前生效的配置和请求命中的规则。规则按顺序匹配，具体条件的位置与 FINAL 的策略都会影响出站选择。不要把“规则走了 Direct”误判成默认服务器无法连接。
DOMAIN-SUFFIX匹配域名后缀；检查目标域名是否命中了预期策略。GEOIP按 IP 地理归属匹配；它不是域名后缀规则。IP-CIDR匹配地址网段；检查网段范围是否过宽。FINAL处理前面未命中的请求；确认其最终策略符合预期。
配置规则修改前先备份，保留原有策略名称。若仅一个目标失败，应结合该请求记录核对域名解析与实际出站，不要为了单一目标清空整个配置。若连接关闭后又自动恢复，回到 Settings → On Demand 检查按需连接条件，避免把自动重连误认为开关失效。
七、整理可供服务商复核的信息
完成以上检查后仍失败，应提交能复现问题的记录，而不是只发“不能用”。无需公开密码、UUID、私钥或完整订阅链接；这些内容可能用于访问你的服务。截图和日志发送前也应检查是否包含敏感字段。
- 发生时间：记录日期、时间和时区，便于对照服务端日志。
- 连接条件：说明 Wi-Fi 或蜂窝网络、协议 Type、端口以及脱敏后的服务器标识。
- 对照结果：分别写出两种网络下的测试方式、是否超时和实际页面是否可访问。
- 错误证据：提供错误原文和前后关联信息，注明系统时间已检查。
- 已做变更：列出更新订阅、核对字段和切换路由的结果，说明当前是否已恢复原设置。
Shadowrocket 是闭源商业应用，在 Apple 平台通过 App Store 获取，以 iPhone / iPad 使用为主；系统要求以 App Store 页面标注为准。客户端买断 ≠ 线路套餐。已有订阅从你的服务商处获取，线路状态、凭据有效性与服务端证书问题应由对应服务商核对，重新购买客户端不是这类故障的排查步骤。