小火箭延迟测试超时：四格判断与排查顺序

小火箭延迟测试超时，先别急着删除节点或重装。先用当前设置访问一个你常用的公开页面，把“测试显示什么”和“页面能否正常使用”分别记下来。测试超时但能访问、测试有数值却打不开网页，需要的后续检查并不相同。下面先用四格表判断该收集哪些线索，再按网络、配置与节点状态逐项检查。

小火箭延迟测试超时：先看真实访问，再理解测试提示

看到超时提示时，先保留界面上的完整文字；如果显示了数值，也把单位一起记录，不要凭印象补单位。此时先保持配置、节点和网络不变，访问同一个常用公开页面，写清是完全打不开、打开后内容加载不全，还是可以完成原本的操作。

把测试提示和访问结果放在相近时间记录，才方便对照。早上测出的数值和晚上遇到的加载失败，不能直接当成同一组现象。页面可用也只说明这次访问成功，不代表所有业务都正常，更不能据此确认它经过了哪个节点。

如果没有清楚的测试结果或实际访问情况，先补齐这一项。不要为了填表，把仍在等待的状态写成超时，也不要把只打开了页面标题写成整个页面正常。

延迟、速度、可用性是三个问题

日常说的“小火箭测速超时”，可能把几种不同观察混在了一起。先分清你需要解决的是哪一个问题：

• 延迟关注等待时间。往返时延的一般含义，是数据从发送端出发，到对应响应返回所经历的时间；它描述一次往返，不等于完整网页的加载时间。
• 速度或吞吐量关注单位时间完成的数据传输量。一次响应很快，不能单凭这一点判断后续大文件会持续传得快。
• 可用性关注你想做的事是否完成。能打开首页与能否加载其中的图片、完成一次实际操作，需要分别观察。

理解“超时”时，还要区分等待结束和获得了有效时延数值：RFC 2681 的第 2.4—2.6 节介绍了往返时延的定义及测量等待条件。它帮助理解一般概念，不说明 Shadowrocket 的测试实现。记录应用实际提示即可，不把超时当成一个很大的延迟数值去排名，也不据此猜测探测协议、目标地址或固定等待阈值。

例如，你遇到的是页面文字出现后图片迟迟不完整，就应记录“内容加载不全”，而不是只写“延迟高”。这是描述问题的方法示例，不是一次实测结论。

用测试结果与实际访问组成四格表

下表中的“有结果”指界面给出了可记录的测试数值或明确的成功提示，不表示已经证明全部连接正常；“能访问”则按你刚才选定的页面与操作判断。还在等待、没有结果或提示含义不明时，先记录原文，不强行归入四格。

四格表用于决定检查顺序，不是故障原因对照表。无论落在哪一格，都不能直接得出“节点已失效”“规则一定错误”或“设备网络有问题”的结论。

按网络、配置、节点状态依次检查

第一步：保留现状，比较设备网络。 记下当前网络、配置名称、节点名称和测试提示。如果手头有另一个本人可用的 Wi-Fi 或蜂窝网络，可以保持应用设置不变，只切换网络，再访问同一页面并记录测试显示。若结果改变，反馈时说明两种网络下的差异；这能增加线索，但还不能把原网络定为唯一原因。

第二步：核对正在使用的配置及其来源。 查看当前选择的配置是否正是你打算使用的那份，把已有信息与配置提供方的说明对照。订阅是否更新成功、是否出现明确报错，要分开记录，不要把“点过更新”当成已经成功。若更新或导入本身有问题，可先看订阅导入失败排查；不清楚节点信息是否添加正确时，可按核对节点添加方式逐项比较。

第三步：核对节点或服务状态。 查看你已有配置来源提供的服务通知、使用条件和相关说明。遇到明确的维护或有效期提示时，保留原文，并向提供方确认是否涉及当前使用的节点；不要仅凭一次超时自行判定服务已停用。如果已经有另一项获准使用、来源明确的配置需要比较，先保存原设置，比较时保持网络和访问页面一致。

每完成一项检查就记录结果，再决定是否继续。下一项比较开始前，先按记录核对网络、配置与节点，避免把上一轮的改动带进新的对照。不要同时换网络、换节点、改规则；这样即使访问恢复，也很难说明哪个条件发生了影响。看不懂的配置字段先交给维护者核对，不必为了一个超时提示去猜参数或关闭设备保护。

为什么延迟低也可能加载慢

一次测试和完整网页加载是不同任务。网页可能包含文字、图片等多项内容，你等待的是整组内容完成，而不是单次往返结束。因此，“有一个较低的数字”和“页面加载得顺畅”可以同时记录，却不能互相替代。

遇到加载慢时，把现象拆开更容易反馈：是第一屏迟迟不出现，还是文字已经出现但图片不完整？是一个页面慢，还是尝试过的几个常用页面都慢？把这些现象分别记下，比只提交“小火箭延迟高”更有帮助。

网络状态、服务端处理或持续传输条件都可能参与影响，但不要先选定其中一个作结论。先用相近条件检查同一个页面，保留加载过程中实际看到的提示。比较两次测试数值时，也要核对网络和配置是否改变；条件不同，不能只把数字排大小就判断哪次使用体验更好。

测试超时但能访问，要不要重装

如果实际使用仍然正常，先保存这组现象，不必把重装当作第一步。考虑重装前，还要准备好应用重新获取与配置恢复所需的信息；在还没保存配置来源前进行这一步，会增加后续核对的工作。

可以先记下应用版本、当前选项、配置和节点，并确认订阅或配置来源仍可获取。截图方便对照，但不等于完整配置备份。把敏感链接保存在自己可控的位置，不要为了让别人排查而发到公开评论区。

之后若问题持续影响实际使用，把记录交给配置提供方核对。需要处理客户端本身的异常时，再根据开发者支持说明决定后续操作。没有明确处理理由时，先保留可用状态，不要反复删除、导入和重装。

向配置提供方反馈哪些脱敏信息

反馈的重点是让对方看懂“什么条件下发生了什么”，而不是直接发送全部配置。下面这份空白清单可以按实际情况填写：

App Store 开发者说明列有 HTTP、HTTPS、DNS 请求的记录和显示能力；如果你已经能查看到与问题相关的记录，可以补充必要的脱敏片段。不要假定每次访问都有完整记录，也不必为了反馈去寻找某个未显示的字段。

发送前移除完整订阅链接、密码、令牌、账户信息、私人访问内容和地址中的敏感参数。节点可以用“节点甲”这样的自定义代号，不需要贴出登录资料。若记录无法对应这次访问，直接写明未能对应，比猜测路径更有用。

整理时可以填这句话：“在〔时间与时区〕，使用〔网络类型〕、〔配置代号〕和〔节点代号〕；测试显示〔原文〕，访问〔公开目标〕时出现〔现象〕；只改变〔一项条件〕后，结果为〔实际结果／未比较〕。” 测试功能本身的含义或异常交开发者支持核对；节点、订阅和配置使用条件交相应提供方核对。

客户端获取与网络诊断的边界

Shadowrocket 是需要自行提供配置的客户端，应用本身不附带代理服务或服务器资源。下载用的 Apple ID 负责客户端获取或更新，不能代替节点与订阅排查。已经安装应用并遇到测试超时的读者，可以直接按前面的四格表和记录清单处理。

只有尚未获取客户端时，才需要了解下载账号：24 小时共享小火箭 ID用于 App Store 下载或更新，有效期为 24 小时，用完退出 App Store，不登录系统设置或 iCloud，不改密码、不绑定个人信息、不开启双重认证；苹果 ID 小火箭独享商品页列有账号、密码、密保及生日字段，标明 24 小时质保，不应理解为永久使用或必然解锁。这些是商店的商品及使用条款，不是 Apple 的可用性保证。两款商品均不包含节点、订阅或测试超时修复服务。尚未安装时可参考小火箭下载与安装。

FAQ

问：小火箭延迟测试超时，就说明节点失效了吗？

答：不能这样判断。先补上实际访问结果：若能正常使用，保留当前设置和超时提示；若也无法访问，再按网络、配置来源和节点状态检查。两项都失败，也仍需进一步核对原因。

问：小火箭延迟低，为什么用起来还是慢？

答：延迟、持续传输速度与页面是否可用是不同观察。请记录慢在第一屏、图片加载还是具体操作，并在相近条件下比较同一个页面。一个较低的数值不能代表整段使用过程都会快。

问：换一个 Apple ID 能解决 Shadowrocket 测试超时吗？

答：不要把更换下载账号当作修复办法。下载账号用于获取或更新应用；请先核对网络、配置与节点状态。若另有 App Store 下载或更新报错，应单独记录处理，不要和测试超时混为一个问题。

问：出现超时后，要一直重复测试吗？

答：先记录当前提示和实际访问，再决定是否需要复查。要比较时，只改变一个条件，并保留前后结果；不必连续点击直到出现满意的数值。重复得到同一提示，也不能代替原因排查。

下一步：保留一组可对照的记录

现在先保持设置不变，选一个常用公开页面，记录一次测试显示和一次实际访问，把结果放进四格表。需要继续检查时，只比较一个条件，再把变化填入反馈清单。若仍无法正常使用，将脱敏记录交给配置提供方核对；已经满足使用需求时，先保留可用设置。