Shadowrocket（小火箭）的延迟数字适合初筛已有服务器，不能单独代表带宽或完整访问体验。本文以用户已有自己的服务商与订阅为前提，按固定测试条件、核对地区和协议、重复测量、实际访问验证的顺序操作，帮助区分响应快、连接稳定与下载快这三件事。
延迟数字代表什么：先看测量对象
延迟通常以毫秒（ms）显示，数值越小，表示该次测试所包含的交互耗时越短。但必须先确认测试方式：TCP 建连耗时与通过代理发起 HTTP 请求的耗时，测量范围不同；ICMP 往返时间也不能直接当成代理请求耗时。未确认测试方式时，不应把列表里的所有数字统称为 Ping。
TCP 建连成功只能说明相应地址和端口在当时能够建立连接，不能保证协议认证、TLS 握手及目标网页请求全部成功。HTTP 测试还受到测试地址、DNS、TLS 与服务器响应影响。测试范围越接近实际请求，越有参考意义，但仍然只代表那次请求。
- 延迟：关注一次交互需要等待多久，适合观察初次响应。
- 吞吐量：关注持续传输的数据量，通常用 Mbps 或 MB/s 表示，不能从 ms 直接换算。
- 波动：关注相同条件下结果是否稳定，连续测量比单次最低值更有用。
- 超时：表示测试未在限定时间内完成，可能涉及网络、端口、协议参数或测试目标，并非唯一指向服务器故障。
先固定条件，再在 Home 测试已有服务器
一次有效比较应尽量只改变服务器这一项。先固定同一台 iPhone 或 iPad、同一种接入网络、同一个测试目标与测试方式，再进行测量。Wi-Fi 与蜂窝网络的出口可能完全不同，切换网络后应重新测试，不能继续沿用上一组排名。
-
核对已有配置
在 Home 查看已有服务器；需要手动添加时，从 Home 右上角“+”进入 Add Server，按自己已有资料填写 Type、地址与端口。已有订阅先完成更新，再开始比较，避免测到已变更的地址。
-
固定连接环境
选择 Wi-Fi 或蜂窝网络中的一种，暂停其他大流量任务。检查 Settings → On Demand，记录当前状态；若需要临时关闭以避免自动重连改变实验条件，先记录原设置，测试结束后恢复。
-
逐个选中测试
回到 Home，逐个选择候选服务器，并使用 Connectivity Test 做连通性检查。记录界面显示的结果、所用测试方式和时间；不要把一次连通性通过当作全部网站均可访问的证明。
-
重复三次
每个候选使用相同测试方式测三次，例如间隔约 10 秒。保留全部结果而非只记最小值；出现超时也要记录，不能从平均值中直接删去而不说明。
-
验证实际请求
在 Home → Global Routing 核对姿态。为了临时隔离规则影响，可以使用 Proxy 验证选中服务器，再访问同一个目标页面；结束后恢复原来的 Config 或其他原设置，并确认实际请求确实走过该服务器。
Global Routing 的 Direct 不适合用来验证代理服务器的实际访问能力，因为请求采用直接连接。Config 按当前配置处理请求，可能命中 DIRECT；Scene 按所设场景处理，也需要先核对当前生效条件。因此，“网页很快”与“选中服务器很快”不是天然等价关系。
地区与协议怎么选：先确认路径，再比较结果
地区名称可以作为候选分类，但它通常是服务资料中的标注，不等于已经核验的物理机房位置，也不直接说明入口到出口之间的路径。地理距离较近往往有利于减少传播时间，但运营商互联、绕路与拥塞可能抵消这项优势。应比较自己当前网络上的结果，而不是只按地区名称排序。
两种接入环境分别保留测试记录
固定 Wi-Fi
- 在同一位置、同一 Wi-Fi 下测试，减少无线信号变化。
- 先挑已有列表中两到三个不同地区的候选，使用同一测试目标。
- 晚间与白天各测一组，观察拥塞时段是否发生明显波动。
蜂窝网络
- 先在静止、信号稳定的位置比较，避免移动途中同时改变基站。
- 重新测试已有候选，不直接照搬 Wi-Fi 的第一名。
- 记录测试时的网络环境；信号或位置变化后重新验证。
分别记录两种环境的候选顺序，比试图用一台服务器覆盖所有网络更便于定位问题。
协议名说明连接机制，不是固定的速度等级。Shadowsocks、VMess、VLESS、Trojan 的实际表现还取决于传输方式、加密、TLS 与服务端设置；不能仅凭名称推断哪一种更快。Hysteria2 基于 QUIC，涉及 UDP 可达性；WireGuard 同样使用 UDP，但隧道机制不同，不能把它们当成相同测试对象。
- 先核对类型：Add Server 中的 Type 必须与已有服务资料一致，不要为了追求更低数字擅自改协议。
- 再核对参数：端口、认证资料与 TLS 参数要匹配。端口 443 是具体端口号，不能据此认定协议一定是 Trojan，也不能据此保证连接成功。
- 区分传输：对以 UDP 工作的配置，单独探测同地址的 TCP 端口不足以证明实际协议可用，应结合协议连接和实际请求判断。
- 保留变量：两个不同地区、不同协议的结果可以用于选择，但不足以得出“协议本身更快”的结论。
如何读三次结果：稳定性比最低值更重要
以下数字是演示记录方法的假设数据，不是本站实测，也不代表任何地区或协议的性能。比较时先看是否成功，再看中位数和波动；最后仍要验证实际页面与持续传输。
| 已有候选 | 三次结果 | 判断方式 |
|---|---|---|
| A，同一测试方式 | 72 / 180 / 95 ms | 中位数 95 ms，波动较大，需关注繁忙时段。 |
| B，同一测试方式 | 104 / 108 / 106 ms | 中位数 106 ms，三次较接近，可继续验证实际访问。 |
| C，同一测试方式 | 60 ms / 超时 / 65 ms | 虽然最低值小，但出现一次失败，不能仅凭 60 ms 排第一。 |
三次采样只是初筛，不足以计算可靠的长期丢包率。若 A 偶尔很快、B 一直稳定，交互式网页可能在 B 上更连贯；如果实际访问表现相反，就以可重复的实际任务结果为准。不要把某一个固定毫秒阈值当成所有网络的合格线。
延迟记录卡
- 接入网络
- 同一 Wi-Fi，测试期间不切换
- 测量条件
- 相同测试方式、相同测试目标
- 重复次数
- 每个候选 3 次，间隔约 10 秒
- 保留结果
- 全部 ms 数值、超时与测试时间
先保证条件可比，再讨论排名；测试方式不同的数字分开记录。
实际访问卡
- 连接姿态
- Home → Global Routing → Proxy，临时验证后恢复
- 页面任务
- 同一页面重复打开 3 次，区分首次与缓存加载
- 持续传输
- 使用自己有权访问的同一文件，观察稳定速率
- 最终依据
- 成功率、等待时间与持续传输表现共同判断
实际请求必须经过待测服务器，才有资格用于评价这条连接。
低延迟但网页慢：按请求链路排查
打开一个网页不只发生一次往返。DNS 查询、连接建立、TLS 握手、主文档与多个子资源请求都会增加等待；有些资源还来自不同域名。延迟探测目标很快，不代表业务网站的解析、出口路径与服务器响应同样快。大文件下载则更容易受到持续带宽、拥塞与丢包影响。
- 确认请求走向。在 Home → Global Routing 检查当前姿态；使用 Config 时，在 Config 中核对当前启用文件，而不是只看 Home 选中了哪台服务器。
- 检查规则命中。例如
DOMAIN-SUFFIX,example.com,DIRECT会使相应域名走 DIRECT；FINAL,PROXY只处理前面未命中的请求。规则自上而下匹配，切换选中服务器不会改写已命中的 DIRECT 策略。 - 区分首开和缓存。首次加载可能包含 DNS 与 TLS 成本，再次打开可能使用缓存或复用连接。比较时分别记录，避免拿一条连接的首开去比较另一条连接的缓存命中。
- 换任务而不乱改配置。先检查同一页面，再检查另一个自己有权访问的目标。只有单个站点异常时，应优先考虑该目标路径与站点响应，不要同时改端口、DNS 和协议。
- 复查网络时段。短测正常但持续传输逐渐下降时，在同一环境隔一段时间重测，并记录是否只在繁忙时段出现。
规则中的 GEOIP 与 IP-CIDR 用于按 IP 条件分流，并不测量服务器距离或速度。配置里出现某个地区条件，也不能用来证明所选服务器的出口所在地。诊断时应把“规则如何决定走向”与“链路实际质量如何”分开处理。
常见问题：超时、更新与自动切换
显示超时，是不是服务器一定不能用了？
先确认当前 Wi-Fi 或蜂窝网络本身可用，再在 Home 重新测试一次。核对 Add Server 内已有配置的类型、地址和端口，随后验证实际连接。若仅一个测试目标失败而实际页面正常，应继续检查测试方式与目标，不能仅凭超时下结论。
订阅更新后，为什么原来的低延迟记录不准了？
更新可能改变地址、端口或服务器条目，同名不等于同一条路径。回到 Home 核对更新后的候选，重新按相同网络、相同测试目标测三次。不要把更新前的排名直接套到新条目上，也不要仅为保留低数字而改回失效参数。
测试时连接自己又打开了，怎么固定条件？
进入 Settings → On Demand 检查已有按需连接设置，先记录原状态，再视需要临时关闭并回到 Home 确认连接状态。测试完成后恢复原设置。On Demand 处理按条件连接，不等于按照最低延迟自动选择服务器。
数字最低的一台，要一直作为首选吗？
先验证实际页面和持续传输，再决定首选；同时保留另一台已验证的候选。Wi-Fi 换成蜂窝、订阅更新或体验明显变化时重新测试。若配置使用自动策略组，还要检查组的选择条件，手动选中条目与组最终选用的服务器可能不是同一项。
最终选择顺序可以概括为：参数正确、实际可用、重复测试稳定、目标任务表现合适，最后才比较几毫秒的差距。本文只说明用户已有配置的测试与使用方法；客户端购买与已有服务的使用条件需要分别核对。