本文适用于已在 Shadowrocket（小火箭）中导入自己已有服务商配置的用户。先分清延迟、吞吐量与稳定性，再控制网络、测试方式和路由姿态，最后比较已有连接配置的地区与协议。选择依据应是实际目标应用的可用性与重复测试结果，而不是列表中最小的一个数字；本文不提供、不销售、不推荐任何节点或订阅。
一、延迟数字测到了哪一段连接
延迟通常以毫秒（ms）显示，表示某种探测完成所花的时间。它描述的是一次短交互，不是每秒能够传送多少数据。Shadowrocket 的测试结果必须结合所用测试方式理解：同一条连接配置，在不同测试方式、测试目标或当前网络下，可能得到不同数字，不能把所有结果直接放进同一张排名表。
例如，TCP 探测主要反映到指定服务器端口建立 TCP 连接的耗时。端口能建立连接，并不等于协议认证成功，更不等于远端可以正常访问目标网站。通过代理发起的 HTTP 探测覆盖范围更广，但其耗时也会受探测网址、DNS、TLS 握手及响应方式影响。不要仅凭测试项名称，假定它一定覆盖了实际业务的完整链路。
| 观察方式 | 主要能说明什么 | 不能直接证明什么 |
|---|---|---|
| ICMP 探测 | 目标主机对 ICMP 的可达性与往返时间 | 代理端口、认证和目标网站均正常；服务器也可能限制 ICMP |
| TCP 探测 | 指定主机与端口的 TCP 建连情况 | 代理协议可用、持续传输速度高，或 UDP 路径正常 |
| 经代理的 HTTP 探测 | 到指定测试网址的一次请求能否完成及其耗时 | 其他域名、其他地区内容及长时间连接都能正常使用 |
| 实际应用操作 | 目标页面、视频或通话在当前配置下的表现 | 不同时间、不同网络下也会保持同样表现 |
超时也不是“服务器一定离线”的同义词。测试目标不可达、端口填写错误、当前网络限制某种传输，或者测试方式与协议不适配，都可能造成超时。相反，显示很小的延迟也只是说明该次探测完成较快，不能替代连接后对实际应用的验证。
二、先固定测试条件，再比较已有配置
先确认已有订阅已经成功导入 Home，服务器地址、端口和协议字段没有缺失。订阅更新负责同步配置记录，不会提高服务器带宽，也不会自动解决目标网站限制。若服务商调整过地址或认证信息，应先完成更新，再做比较；不要在每轮测试之间同时更新订阅、切换网络和修改规则。
-
固定网络
选定同一处 Wi-Fi 或蜂窝网络，暂停会占用带宽的同步任务。测试期间不要在两种网络间切换，并记录测试时段。
-
确认配置
在 Home 选中一条已有配置，进入其编辑信息核对 Type、地址与端口。例如服务端要求 TCP 443 时，不能凭猜测改成 8443；端口必须以自己的服务端参数为准。
-
固定路由
进入 Home → Global Routing，记录当前为 Config 还是 Proxy。需要隔离规则影响时可临时用 Proxy 对照，完成后恢复原设置；同时检查 Settings → On Demand，避免自动连接条件改变测试状态。
-
重复探测
在 Home 使用 Connectivity Test，保持测试方式与目标一致，对每个候选重复三至五次。记录超时次数、典型耗时与最高耗时，不只抄最低的一次。
-
验证业务
打开连接后，访问同一实际目标，依次检查首次打开、持续加载和短暂空闲后的恢复。每个候选采用同样的观察时长，例如持续五分钟，再切换下一条。
下面是演示记录格式的假设数据，不是产品实测，也不对应任何可获取的服务。五次中出现超时应单独计数，不能把它当成 0 ms 纳入平均值。成功样本的中位数能减少单次异常值影响，但仍需同时保留失败记录。
候选 A：假设记录
- 测试网络
- 同一 Wi-Fi，同一位置
- 五次结果
- 38、41、超时、210、43 ms
- 成功中位数
- 42 ms，另记 1 次超时
- 业务观察
- 五分钟内发生两次加载停顿
38 ms 是最低值，不能掩盖超时和明显波动。
候选 B：假设记录
- 测试网络
- 与候选 A 保持一致
- 五次结果
- 72、75、73、74、76 ms
- 成功中位数
- 74 ms，未出现超时
- 业务观察
- 五分钟内持续加载正常
对持续交互任务，较稳定的结果可能比单次低延迟更有参考价值。
三、地区标签不等于实际路径与出口能力
连接名称里的地区通常由配置提供方填写，它可能指入口、出口或服务分组，不是客户端对物理位置的独立证明。访问路径可能包含本地网络、接入运营商、入口服务器、中转、出口和目标站点。某个地区地理距离较近，并不意味着路径一定更短；路由绕行和跨网拥塞都可能抵消距离优势。
如果目标应用按出口 IP 判断地区，应以该应用实际看到的出口及其服务规则为准，而不是仅看 Home 列表名称。网站还可能结合账号地区、定位权限、历史会话等信息作出判断。切换配置后依旧显示旧地区，也不能立即认定是延迟测试失准，因为这两项观察根本不是同一件事。
- 交互操作：优先观察首屏、搜索、提交和连续点击的响应，不以地理名称作唯一依据。
- 持续传输：观察传输能否维持、是否频繁停顿。短探测响应快，不代表长连接具有足够吞吐量。
- 实时业务：除往返耗时外，还要检查抖动、丢包及 UDP 可达性；UDP 不通时，TCP 探测成功也不足以说明业务可用。
- 特定地区服务：核对目标服务的可用范围和账号条件，并确认请求确实经过预期出口。
四、协议类型影响连接条件，不构成速度排名
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的连接机制不同，但不能仅按协议名断言哪条配置更快。服务端位置、负载、传输参数、本地网络和目标路径通常共同决定结果。先保证导入字段与服务端一致，再讨论表现；不要只修改 Type，试图把现有服务器直接变成另一种协议。
| 协议 | 需要重点核对的条件 | 测试时的边界 |
|---|---|---|
| Shadowsocks | 服务端支持的加密方法、密码、端口与 UDP 配置 | TCP 正常不能单独证明 UDP 转发正常 |
| VMess / VLESS | 身份字段、传输方式及对应 TLS、Host、路径等参数 | 端口可达不代表认证和应用层传输参数正确 |
| Trojan | 密码、服务端端口、TLS 与服务器名称等参数 | TCP 建连成功后仍可能因 TLS 或认证失败而不可用 |
| Hysteria2 | UDP 可达性、认证、TLS 及服务端约定参数 | 基于 QUIC；仅做 TCP 端口探测不能据此判断其完整连接状态 |
| WireGuard | 密钥、Endpoint、隧道地址及 AllowedIPs 等配置 | 基于 UDP；需要结合握手与隧道内实际通信判断 |
端口号也不是协议能力标签。TCP 443 与 UDP 443 使用不同的传输协议，即使数字相同，也不是同一个连通性条件。网络允许 TCP 443，不代表 UDP 443 同样可达。遇到某条配置在 Wi-Fi 可用、蜂窝不可用时，应保留原参数，分别检查网络与传输条件，而不是随机更换端口或关闭 TLS 验证。
五、先排除 Global Routing 与规则造成的误判
选中一条配置，并不等于每个请求都使用它。Global Routing 决定总体路由姿态；Config 下还需要看当前启用的配置文件、规则命中以及规则指定的策略。如果某个域名命中 DIRECT，继续更换代理配置，往往不会改变这个域名的实际路径。
Config
推荐按照当前配置中的规则决定策略。适用于已有规则正确、希望保持日常分流的场景；不保证所有目标都经过当前所选代理。
适合:日常使用，以及确认规则命中后的真实业务测试
Proxy
以代理作为总体路由方向，可用于对照 Config 的规则影响。系统、路由排除项或未被接管的流量仍需单独考虑，不能据此断言整台设备的一切通信都经过代理。
适合:临时隔离规则因素，完成后恢复原姿态
Direct
以直接连接作为总体路由方向，用来观察本地网络访问目标的情况。此时实际页面表现不能作为所选代理配置的性能结论。
适合:建立本地网络基线，区分目标本身与代理路径的问题
Scene
按已设置的场景条件使用相应路由安排。测试前应核对当前场景实际采用的设置，避免环境变化后两轮比较走了不同路径。
适合:已经明确配置场景条件的使用环境
例如下面的教学片段中，example.com 及其子域名会先命中 DIRECT；其余请求才落到 FINAL 指定的 PROXY。示例域名仅用于解释语法，不是测试服务，也不是可用连接配置。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY在 Config 中核对当前启用的文件，并结合请求记录确认策略。规则按顺序匹配，除 DOMAIN-SUFFIX 外，GEOIP、IP-CIDR 等条件也可能影响路径；FINAL 是未命中前面规则时的兜底。还应检查策略是否引用了其他指定配置或策略组，避免以为请求一定使用 Home 当前选中的项目。
六、常见现象与下一步检查
延迟只有几十毫秒，为什么视频仍然转圈？
先在 Home → Global Routing 确认测试姿态，并检查目标请求的策略。随后对同一视频连续观察五分钟，区分首次等待与播放中停顿。前者可能涉及 DNS、握手或目标响应，后者更需要检查持续吞吐量、丢包及拥塞。单次短探测无法覆盖这些条件。
列表测试超时，但实际网页能打开，要删掉配置吗？
先不要删除。在 Home 核对 Connectivity Test 的测试方式与目标，再确认网页确实经该配置访问。若是 UDP 协议却只检查 TCP 端口，或探测网址本身不可达，超时可能不代表业务失败。以同一条件重复探测，并保留实际请求结果。
换了地区，网站显示的位置怎么没变化？
先确认 Global Routing 未处于 Direct，再核对 Config 中该域名是否命中 DIRECT 或指定了其他策略。实际出口与列表地区标签可能不同；即使出口已经改变，网站还可能使用账号地区和历史会话判断。应按目标服务的规则检查，而不是只反复切换连接。
每次切换网络后结果都变了，怎样留一个备用？
在常用 Wi-Fi 和蜂窝网络下分别重复同一套测试，记录成功率、波动和实际应用表现。检查 Settings → On Demand 的条件是否改变了连接状态。从自己已有配置中保留在备用网络上验证可用的一条，并在使用时确认已经切换成功；不需要为追逐最低数字频繁改动协议参数。
最终可以按“目标业务能正常使用 → 常用网络下稳定 → 常用时段可重复 → 延迟与吞吐量满足需求”的顺序筛选。出现故障时保留网络类型、时间、协议、路由姿态、测试方式和错误现象，再向自己的服务提供方核对服务端状态。记录时隐去密码、密钥、身份字段和完整订阅地址，避免把认证信息作为排查截图公开。