Shadowrocket 节点延迟测试怎么看:按地区与协议类型挑选已有节点

一、延迟数字测到了什么

延迟通常以 ms（毫秒）显示，但数字的含义取决于测试方法。对服务器进行 TCP 连接测试，主要反映到该地址、该端口建立连接的耗时；通过代理访问 HTTP 或 HTTPS 测试目标，则还涉及代理协商、目标连接及响应等待。两种测量覆盖的路径不同，不能把结果当成同一种指标排序。

先核对应用中当前使用的测试方法和测试目标，再比较节点。若测试只覆盖服务器端口，数字较低只能说明这一段响应较快，不能证明目标网站已经可用。即使测试经过代理访问指定目标，也只能反映该目标在当时的表现，不能代表所有网站、所有时段。

出现超时也不等于节点一定失效。测试目标不可达、解析失败、服务器端口受限、协议握手失败，都可能使测试无法完成。应把“端口能否连接”“代理能否建立”“目标能否返回内容”分开确认，避免用一个红色结果概括所有故障。

二、先固定条件，再测试已有订阅

比较前先完成一次订阅更新，并记录当前网络。更新可能改变地址、端口或节点列表；如果一部分结果来自更新前，另一部分来自更新后，就不再是同一组配置。订阅链接属于访问凭据，不应放进截图、公开笔记或求助内容中。

1. 核对订阅

   在 Home（首页）找到自己的订阅分组。需要首次导入时，使用 Home → “+” → Type（类型）→ Subscribe（订阅），填写用户已有链接并保存；已经导入的内容不必重复添加。

2. 完成更新

   在 Home 对已有订阅执行更新，确认列表已刷新。若更新失败，先处理链接访问或凭据问题，不要把旧列表的测试结果当成最新状态。

3. 固定环境

   选定同一个 Wi-Fi 或蜂窝网络，暂停正在进行的大流量传输。通过 Settings（设置）→ On Demand（按需连接）核对自动连接条件，避免测试过程中因网络切换改变连接状态。

4. 重复测量

   在 Home 对候选节点执行延迟测试，保持测试方法与目标一致。每项间隔片刻测三次，记录超时情况；批量结果用于初筛，少量候选再单独复测。

5. 实际验证

   选中候选节点并连接，确认 Global Routing（全局路由）采用的模式，然后打开同一目标页面。分别观察首次显示、连续浏览及较长请求是否正常。

三次记录不是统计学保证，只是比单次读数更容易识别偶发波动。例如一项结果为 48 / 51 / 49 ms，另一项为 25 / 超时 / 180 ms，前者更值得进入后续验证。这里的数字仅为判读示例，不是任何节点的实测数据，也不是合格阈值。

三、按地区筛选：名称只是线索

地区筛选应先服务于目标需求。若目标内容要求某个地区的出口，应先确认出口地区，再比较同组候选；若没有地区限制，则优先比较稳定性和实际访问情况。节点名称中的地区、旗帜或缩写由订阅内容提供，不能单独证明服务器位置或最终出口位置。

同一地区的两个节点也可能走不同入口、不同中转路径或不同出口。反过来，名称中写着不同地区的节点，可能共享一段相同路径。因此“离得近就一定快”与“地区相同就表现相同”都不适合作为操作依据。应记录具体节点、所在网络和测试时间，而不只记录地区名称。

四、按协议类型筛选：先确认连接条件

Shadowrocket 中已有节点可能使用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard。协议名称说明连接机制，不直接给出延迟和带宽排名。同一种协议在不同服务器、端口与网络路径上的表现可以明显不同；不要为了追求一个协议名称而改写现有订阅参数。

以 Hysteria2 为例，它基于 QUIC 工作；若当前网络限制 UDP，换一个相同地区但不同名称的同类节点，未必能解决问题。WireGuard 同样依赖 UDP，但其握手与隧道机制不同，也不能套用 TCP 建连耗时解释连接状态。对于 VMess 或 VLESS，仅比较 Type 仍不充分，还需考虑传输方式及服务器配置。

• 同地区比较协议时，尽量选择测试时段接近、目标一致的候选，减少环境变化。
• 协议连接失败时，先核对订阅更新、地址、端口和认证参数，不通过降低验证要求换取一次成功。
• 若某类连接只在一个 Wi-Fi 下失败、蜂窝网络下正常，优先检查该网络的传输限制。
• 不要批量手改订阅节点的端口、TLS 或传输参数；这些设置需要服务器端配合。

五、低延迟却打不开：检查 Global Routing 与规则

延迟测试通过，不代表浏览请求正在使用刚刚测试的节点。Home → Global Routing 中的 Proxy（代理）、Direct（直连）、Config（配置）与 Scene（场景）决定路由方式。日常使用可依据现有 Config 分流；排查时则应明确请求到底走哪条路径。

Scene 用于场景化路由，实际行为取决于已有场景设置，不能只看名称判断正在采用哪条路径。测试前若启用了 Scene，应先核对对应配置，或在明确记录原设置后切换到适合排查的模式。

• 在 Config（配置）确认当前启用的配置，而不是只查看某个未启用文件。
• DOMAIN-SUFFIX 按域名后缀匹配；GEOIP 按 IP 地理数据匹配；IP-CIDR 按 IP 网段匹配。
• FINAL 是前面规则均未命中时的最终去向；规则顺序及其引用的策略都会影响结果。
• 结合连接记录核对目标、命中规则及去向。若目标被分到 DIRECT，就不能用本次页面表现评价代理节点。

六、用实际请求区分“响应快”与“传输稳”

低延迟主要有利于频繁的小请求，但持续传输还受可用带宽、丢包、拥塞及目标服务器负载影响。一个节点可能很快完成握手，却在传输内容时反复等待；另一个节点初始响应稍慢，却能稳定完成后续请求。应根据实际用途分别观察，不把两个维度合成一个数字。

浏览器缓存和连接复用也会影响体感。第二次打开同一页面更快，可能是缓存命中，而不是节点改善。比较时尽量使用相同内容与相近的请求条件；不要一边播放视频或同步大量文件，一边据延迟变化判断节点优劣。测试本身会产生网络流量，已有服务的流量限制也需要计入。

七、保留可复现的选择结果

最终保留的应是“在某种网络和用途下经过验证的选择”，不是永久排名。订阅更新、服务器调整、本地网络变化都可能让旧结论失效。无需频繁测试全部列表；在出现异常、切换网络或订阅发生变化后，复核少量常用候选即可。

1. 记录条件：写下 Wi-Fi 或蜂窝、测试方法、目标及测试时间，不公开订阅凭据。
2. 记录候选：保留节点名称、地区标签、Type 与更新状态，避免混淆名称相近的条目。
3. 记录结果：分别写延迟、超时次数与实际请求表现，不只截取最小值。
4. 记录路由：写明 Global Routing 模式及实际命中的策略，保证下一次能重复验证。
5. 保留备用：在自己的已有内容中留一项经过测试的替代选择，切换后重新确认访问结果。