Shadowrocket（小火箭）显示超时，不等于密码一定错误，也不等于远端一定停止服务。本文面向已有自己服务商与订阅的用户，适用于 iPhone、iPad、Mac（Apple 芯片与 Intel）、Windows、安卓及 Linux；界面路径以 iPhone / iPad 为操作参照，其他平台按对应设置项核对。先保留原始配置与测试结果，再依次检查测试方式、协议参数、系统时间和网络出口，每次只改变一个变量。
一、先区分延迟测试失败与实际连接失败
延迟数字只能说明某种测试在当时的网络中完成了，不能单独证明所有应用都能正常访问。TCP 测试主要观察端口连接，经过代理的 HTTP 测试还涉及协议握手和测试目标的响应；ICMP Ping 则可能被远端或中间网络丢弃。三者测量的对象不同，不能把一个结果当成另一个结果。
在 Home 确认当前选中的条目，记录所用测试方式，再对同一个条目连续测试三次。若仅一次成功或数值波动明显，先保留结果，不要立即改协议。随后启用连接，用浏览器访问自己有权访问、平时稳定可用的 HTTPS 页面，观察是否只有某个目标失败。不要同时切换条目、修改 DNS 和更换网络，否则无法判断是哪项改变起效。
| 观察现象 | 可以得出的结论 | 下一步 |
|---|---|---|
| TCP 测试成功，实际访问失败 | 端口可能可达，但认证、TLS 或目标请求仍可能失败 | 核对协议字段，并检查请求是否经过所选条目 |
| ICMP 无响应，实际访问正常 | ICMP 结果不能代表代理协议不可用 | 保持配置，以实际访问和协议测试为准 |
| 同一订阅全部条目超时 | 存在共同原因的可能，不能直接判定所有服务器故障 | 检查网络、订阅状态、域名解析和设备时间 |
| 仅一个条目持续失败 | 故障范围更接近该条目或其远端服务 | 核对该条目的地址、端口及服务状态 |
结论：先固定测试对象
选择一个条目、一个测试方式和一个目标页面建立基线；只有基线固定后，切换网络或修正参数的结果才具有对照意义。
二、按编号核对地址、端口与订阅内容
配置检查应从最基础的连接信息开始。地址少一个字符、端口填成其他服务的监听端口，都可能表现为超时。端口并非协议名称的固定附属值：使用 TLS 不代表端口一定是 443，也不能因为 443 常见就擅自把原端口改成 443。
-
保留原配置
在 Home 记录当前条目名称、Type 和报错发生时间；修改 Config 前先保存原配置副本。含密码、UUID、私钥的内容只在自己的设备上保存，不上传到公开讨论区。
-
核对地址
从 Home 打开当前条目的编辑界面，将 Address 与自己服务商提供的原始参数逐字符比较。地址字段通常填写域名或 IP，不要把完整网页地址、路径或前后空格一起粘入。
-
核对端口
检查 Port 是否与远端监听端口一致。合法端口范围为 1–65535；例如远端给出 8443，就不能因浏览器常用 HTTPS 而改成 443。端口可连接也不代表该端口上运行了正确的代理服务。
-
核对认证
对照原始信息检查 Password、UUID 或对应密钥字段，注意复制时的换行与首尾空格。不要把订阅链接中的访问令牌填进节点密码字段，两者用途不同。
-
更新再复测
如果条目由订阅生成，在 Home 对对应订阅执行更新或下拉刷新，确认操作完成后重新选择条目。更新可能覆盖订阅生成的字段；临时修改应先记录，更新失败时不要删除仍可使用的旧配置。
订阅更新成功只表示订阅内容能够被获取和解析，不代表其中每个地址都在线。相反，更新失败也不必然导致已保存的条目失效。如果服务商调整了端口、认证信息或传输设置，旧条目仍会显示在列表里，但它未必继续适用；这时应向自己的服务商确认变更，而不是反复导入同一份旧内容。
三、按协议核对握手与传输参数
Address、Port 正确后，再检查 Type 及其关联字段。不同协议不能靠更换名称互相兼容；同样的服务器地址也可能对应多组不同服务。下表用于确定检查方向，字段是否出现取决于具体协议与配置，不能把某一行的设置机械套到所有条目上。
| 协议 | 重点核对 | 常见判断边界 |
|---|---|---|
| Shadowsocks | 加密方法、Password、Address、Port | 密码和加密方法必须同时一致；端口可达不足以证明解密成功 |
| VMess | UUID、加密设置、传输方式及服务端指定的附加参数 | 系统时间明显偏差可能影响认证，不能只检查 UUID |
| VLESS | UUID、传输方式、TLS 及服务端要求的安全参数 | 仅复制 UUID 不等于完整复制了一条可用配置 |
| Trojan | Password、TLS、Server Name 和证书信任状态 | 连接 IP 与 TLS 验证使用的域名可能不同，必须按原配置填写 |
| Hysteria2 | 认证信息、TLS、服务端指定参数及 UDP 可达性 | 基于 QUIC；TCP 测试成功不能证明其 UDP 通道可用 |
| WireGuard | 本地私钥、对端公钥、Endpoint、隧道地址与 Allowed IPs | 依赖 UDP；握手成功后仍需检查路由与 DNS |
采用 WebSocket 传输时，应核对 Path 与 Host。Path 中的斜杠、大小写或末尾字符不同，都可能让请求落到错误的服务路径。Host 用于 HTTP 请求，Server Name 用于 TLS 握手中的服务器名称，两者不是可以随意互换的同一个字段。只有原始配置要求一致时，才填写相同值。
- TLS 名称：若 Address 使用 IP，但证书签发给域名，应保留服务商指定的 Server Name，不能把所有名称字段都替换成 IP。
- 传输方式：远端要求 WebSocket 时，不能改成普通 TCP 后期待自动兼容；gRPC 等传输同样需要对应的服务端配置。
- 证书验证：出现证书错误时先检查时间、域名和证书有效期，不以长期关闭证书验证作为修复。
四、根据报错定位，不把所有失败都当作超时
在对应请求的日志或诊断结果中记录完整错误文本。下列是常见底层错误片段，不保证每个平台显示完全相同的措辞；如果只看到笼统的连接失败，应结合发生阶段判断，不要凭一个词直接认定责任在本地或远端。
报错：i/o timeout
原因与解法：某个操作在等待期限内没有完成，可能发生在解析、连接或握手阶段——先看前后日志确认目标地址和阶段，再用同一条目切换网络对照，不能仅凭这条信息断言密码错误。
报错：connection refused
原因与解法：连接请求被明确拒绝，常见于端口没有服务监听或被主动拒绝——核对 Port，并向自己的服务商确认该端口的监听状态，不要靠增加等待时间处理。
报错：no such host
原因与解法：域名解析未取得可用结果，可能涉及拼写、解析配置或域名记录——先逐字符核对 Address，再检查当前网络的 DNS；不要直接把它归类为认证失败。
报错：x509: certificate has expired or is not yet valid
原因与解法：证书有效期与当前设备时间不匹配——先校准设备日期、时间与时区；时间正确仍报错时，由服务端维护者检查证书有效期和证书链。
如果日志显示连接已建立，随后才出现目标站点的 HTTP 错误，应区分代理链路与目标响应。单个页面返回 403 或 429，可能是目标站点的访问策略或频率限制，不等同于节点端口不可达。保留响应发生的时间和目标域名，避免把目标页面拒绝访问误判成整个客户端失效。
五、校准系统时间，再检查网络出口
TLS 会检查证书有效期，一些认证机制也依赖时间窗口。日期错误到过去或未来、设备长期离线后时间未同步，都可能让正确参数无法完成握手。iPhone / iPad 可在系统 Settings → General → Date & Time 中检查 Set Automatically；其他平台在系统的日期与时间设置中启用自动同步，确认显示的实际时间正确后再复测。
- 先做直连基线：暂停 Shadowrocket 连接，用浏览器确认当前 Wi-Fi 或移动网络本身可访问正常页面。酒店、校园等网络若要求网页认证，应先完成网络认证。
- 做跨网络对照：同一设备、同一条目、同一目标，在 Wi-Fi 与移动网络之间各测试一次。只有某个网络失败时，优先检查该网络的出口策略，而不是修改所有协议字段。
- 检查 UDP 限制：Hysteria2 与 WireGuard 依赖 UDP。若它们在某网络失败，而已有的 TCP 类连接可用，只能说明值得检查 UDP 通道，尚不能直接证明协议实现有问题。
- 排除隧道冲突：检查系统中是否有其他 VPN 或网络过滤设置正在接管连接，暂时停用冲突项后复测。受管理设备应遵循管理员策略，不绕过组织限制。
若关闭连接后又自动恢复，检查 Shadowrocket 的 Settings → On Demand，并在记录原设置后临时停用自动触发条件。On Demand 决定何时发起连接，不负责修正地址、密码或远端服务状态。排错完成后，应按原用途恢复，而不是把持续关闭自动连接当成通用修复。
DNS 调整的边界：只有出现解析失败或明显错误的解析结果时，才有针对性地检查 DNS。不要一次替换所有 DNS 项，也不要随意用 IP 覆盖域名；这样可能同时破坏 TLS 名称验证，并使原始故障更难复现。
六、延迟正常但打不开时，检查 Global Routing 与 Rule
节点测试和应用请求可能走不同的处理路径。进入 Home → Global Routing，先记录当前选择。Proxy 用于代理路由，Direct 用于直连路由，Config 按当前配置处理，Scene 按已配置场景处理。它们不是四种连接协议，也不能仅凭名称判断当前网页究竟走了哪个出口；仍应检查匹配结果与实际使用的条目。
- 短时对照：在了解网络影响的前提下，用 Proxy 对照 Config 的访问结果，测试后恢复原设置。如果 Proxy 可用而 Config 不可用，下一步应检查规则与策略，而不是先改认证字段。
- 检查顺序：在 Config 打开当前生效配置，检查 Rule 自上向下的匹配顺序。前面的规则命中后，后面的规则通常不再参与该请求的选路。
- 检查对象：DOMAIN-SUFFIX 针对域名后缀，IP-CIDR 针对 IP 网段，GEOIP 按 IP 地理数据库匹配，FINAL 处理此前未命中的请求。匹配对象不同，不能用同一条判断覆盖所有连接。
- 检查策略：确认命中的 PROXY、DIRECT、REJECT 或自定义策略组指向预期行为；组名存在也不代表组内当前选择的条目可用。
下面只演示规则顺序与语法，不是需要整体覆盖现有 Config 的推荐配置。example.com 是文档示例域名，192.0.2.0/24 是文档示例网段；应结合自己的访问目标理解，不应把示例误当成真实服务参数。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY结论：按故障阶段修改设置
端口尚未连通时先查地址和网络；握手失败时查认证、TLS 与时间；只有握手和实际代理访问已成功，才重点检查规则是否把特定请求送到了错误策略。
七、保留可复现记录，再向自己的服务商反馈
经过以上检查仍失败时，提交能定位问题的记录，比只描述“全部超时”更有效。记录中应区分测试结果与推测：例如“同一条目在 Wi-Fi 失败、移动网络成功”是可复核的现象；“服务器被限制”只是需要继续验证的解释。不要填入没有测试过的结论，也不要为了补全记录而公开凭据。
- 设备与环境：设备平台、当前网络类型，以及是否存在网络认证或组织管理策略。
- 复现时间：故障发生的时间与时区、系统时间是否已同步，便于对照远端日志。
- 配置范围：协议 Type、传输方式、是否使用 TLS，以及一个条目失败还是同组全部失败。
- 对照结果：测试方式、连续三次结果、跨网络结果，以及 Global Routing 的选择。
- 错误片段：保留必要的阶段信息，遮盖 Password、UUID、私钥、订阅令牌与个人信息。
本站不提供、不销售、不推荐节点或订阅；线路状态、凭据有效性与远端配置需由用户自己的服务商确认。客户端获取与线路服务是两件事，不应通过重复安装来代替参数核对。需要安装或更换设备时，使用本站全平台下载指南，按设备选择对应入口。