Shadowrocket（小火箭）的延迟数字适合筛选候选连接，不适合直接充当网速排名。本文以用户已有自己的服务商与订阅为前提，说明如何固定测试条件、区分地区与协议、验证网页和视频表现，并排查“延迟很低却打不开”的情况。操作路径以 iPhone / iPad 界面为例，其他平台按对应功能核对。
一、先区分延迟、吞吐量与可用性
延迟通常以 ms 表示，反映某个测试请求在指定路径上的耗时；吞吐量表示单位时间内实际传输的数据量。小请求很快返回，只能说明当时这条路径响应较快，不能证明连续下载时仍有足够带宽。视频播放还取决于目标站点、缓存位置、出口拥塞和一段时间内的稳定性。
不同测试方式覆盖的链路并不相同。TCP 建连测试主要观察建立到目标端口连接的耗时，不一定完成代理认证或访问目标网站；通过代理发出 HTTP 请求的测试覆盖环节更多，但也只代表那个测试地址。比较之前先核对测试方式与目标，不能把不同方法得出的数字放在同一排名里。
二、在 Home 完成一轮可重复的筛选
先确认订阅已经成功导入，Home 中能够看到用户已有的节点列表。若服务商通知参数变更，应先更新对应订阅，再开始比较；不要一边使用旧参数，一边判断协议质量。订阅地址包含访问凭据，截图或记录结果时应隐藏完整链接、密码和 token。
-
固定网络
保持同一个 Wi-Fi 或蜂窝网络，暂停大文件下载和系统更新。打开 Settings → On Demand，记录现有状态；测试期间若会自动切换连接，可暂时关闭，完成后恢复。
-
核对参数
在 Home 打开候选节点的编辑页，检查 Type、服务器地址和端口与用户已有服务商提供的信息一致。不要为了得到更低数字而修改端口、TLS 或认证字段。
-
重复测试
在 Home 使用 Connectivity Test，对候选项按相同方式连续测试三轮，每轮之间留出短暂间隔。记录成功次数、典型耗时与明显的超时，不只抄下最小值。
-
验证业务
在 Home → Global Routing 暂选 Proxy，选中一个候选节点并启用连接，用同一浏览器打开同一目标页面。换节点后新建连接再测，避免复用已有会话。
-
恢复配置
比较结束后，将 Home → Global Routing 恢复为原来的 Config 或其他既有姿态，并恢复 On Demand。重新访问目标，确认日常规则下仍然命中预期策略。
Proxy 适合短时排除分流差异，并不意味着所有系统流量都必然经过同一路径。浏览器缓存、已有长连接、配置中的排除项都可能影响观察。每次只改一个条件，才能区分“换节点有效”与“刚好刷新后恢复”。测试也会产生流量，应遵守已有服务的使用限制。
三、地区标签用于定位候选，不等于完整路由
节点名称里的地区通常是服务商提供的标签，可能描述出口地区，也可能只是线路名称。入口地址、实际出口和目标网站看到的 IP 归属不一定相同。地理距离较近只是一个参考，运营商之间的互联、绕路和出口负载可能比直线距离更重要。
按当前网络分别保留测试结论
固定 Wi-Fi
- 在相同路由器和相近信号条件下测试。
- 记录白天与常用晚间时段的差别。
- 优先确认目标网站的响应与持续传输。
蜂窝网络
- 关闭 Wi-Fi 后重新测试，不沿用上次排序。
- 保持位置相对固定，避开移动中的基站切换。
- 留意 UDP 路径和网络切换后的重连表现。
同一节点在 Wi-Fi 与蜂窝下可能表现不同，应分别记录候选项，而不是给地区贴上永久的快慢标签。
如果目标业务对出口地区有明确要求，先确认已有连接的实际出口是否符合要求，再比较性能。地区符合也不代表目标网站一定允许访问；账号地区、网站规则、IP 识别结果均可能影响响应。不要把访问限制、登录失败或验证码增多直接归因于延迟。
四、协议选择先看参数兼容，再看网络表现
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 不能只按名称排列速度。实际开销与传输方式、加密、TLS、服务器实现以及网络环境有关。用户应选择自己已有服务明确支持的协议，并完整保留所需字段；把 Type 换成另一个名字不会让原来的服务端自动兼容。
TCP 类连接检查
- 涉及配置
- 采用 TCP 传输的 Shadowsocks、VMess、VLESS，以及常见 Trojan 配置。
- 端口示例
- 443 只是常见 TLS 端口示例，实际值必须以已有服务端参数为准。
- 认证字段
- 按协议核对密码、UUID、加密方式等，不能互相替代。
- TLS 参数
- 需要 TLS 时核对服务器名称与证书要求，端口连通不等于 TLS 成功。
仅测 TCP 建连成功，仍不能证明代理认证和后续目标访问成功。
UDP 路径检查
- Hysteria2
- 基于 QUIC，依赖 UDP 路径可用，同时需要正确的认证与 TLS 参数。
- WireGuard
- 使用 UDP，需要核对密钥、端点和隧道地址等配置。
- 网络限制
- 当前 Wi-Fi 或运营商可能限制、丢弃或降低 UDP 流量的稳定性。
- 测试依据
- 以实际握手和业务流量为准，不能用同端口的 TCP 测试代替。
UDP 不等于必然更快，协议特性需要结合当前网络与服务端实现验证。
如果某协议在家中正常、换到另一网络后持续超时，先检查网络差异和已有服务端状态，再考虑其他已配置的兼容候选项。不要直接关闭证书验证来消除错误；证书问题应核对服务器名称、设备时间和服务端证书，而不是用降低验证要求掩盖。
五、用目标业务判断“低延迟但不好用”
网页打开并不是单次往返：通常还包含 DNS、连接建立、TLS 协商和多个资源请求。测试地址正常，不能保证网页引用的所有域名都正常。视频则更依赖持续吞吐和波动，启动快但不断缓冲，与首个请求就超时是两类问题，应分别记录。
- 网页场景：比较同一页面首次出现正文的时间，以及图片、脚本是否完整加载。缓存会改变结果，可使用新的隐私浏览会话辅助比较，但仍需保持其他条件一致。
- 视频场景：使用同一内容、同一清晰度观察数分钟，记录启动、拖动进度后的恢复和缓冲情况。自动清晰度会掩盖带宽不足，不能只凭“能播放”判断。
- 下载场景：比较同一来源的持续传输，不把起始几秒的峰值当成长期速度。服务端限速和来源站点负载也会成为瓶颈。
- 稳定性场景：记录多轮中成功与超时的分布。偶尔很快、经常失败的候选项，不应仅凭最低一次延迟排在前面。
排查分流时，Home → Global Routing 中的 Direct 表示直连姿态，不能用它验证所选代理的实际业务表现；Config 按当前配置处理，Scene 按所选场景处理。Config 下还需检查 Config 中正在使用的配置：前面的 DOMAIN-SUFFIX、GEOIP 或 IP-CIDR 规则可能已经匹配，FINAL 仅在此前规则没有命中时兜底。先确定实际策略，再解释速度差异。
六、常见问题与最终保留标准
延迟最低的那个，为什么网页反而打不开？
先确认 Connectivity Test 的测试方式，再到 Home → Global Routing 暂选 Proxy，选中该节点后重新建立浏览器连接。如果仍失败，核对认证、TLS 与目标域名解析；如果 Proxy 正常而 Config 异常，返回 Config 检查目标匹配到的规则和策略。
列表显示超时，是不是必须删除这个节点？
不必立即删除。先用同一网络测试其他已有候选项，再核对当前测试是否适用于该协议。尤其是基于 UDP 的配置，TCP 探测失败不能单独证明服务不可用。更新对应订阅、确认端点参数后，以实际连接和目标访问复测。
Wi-Fi 很快，出门以后要重新选吗？
切换到蜂窝后应重新做一轮相同条件的测试。先在 Settings → On Demand 检查自动连接设置是否改变了连接状态，再到 Home 核对当前选中项与 Global Routing。不要只看列表上一次留下的延迟数字。
订阅更新后，原来的选择不见了怎么办？
先确认更新的是原有订阅分组，而不是误删后重新导入。节点可能被服务商改名或移除，应按新的地址、地区说明与协议字段重新核对，无法确认时向已有服务商核实。不要根据相似名称手工拼接密码或其他认证字段。
最终可保留一个日常使用候选项和一个已经验证过的备用项，分别记录适用网络、测试方式及目标业务表现。选择顺序应是：参数正确且能建立连接、目标业务可用、持续传输稳定，最后再比较延迟数字。网络条件或订阅内容变化后重新验证，不需要为了追求一次更小的 ms 数值而频繁改动整套配置。
本文不提供、不销售、不推荐节点或订阅；所有比较都针对用户自己已有的连接服务。首次配置可先阅读快速上手，确认导入、连接和 Global Routing 的基本关系，再按上述流程筛选。