Shadowrocket（小火箭）选节点，应先确认可连接，再比较多次测试的稳定性，最后用实际网页或视频验证。本文面向已有服务商与订阅的用户，说明 Home → Connectivity Test 的结果能代表什么、地区和协议该怎么看，以及如何在不改动订阅参数的前提下，保留一个日常选择和一个备用选择。
一、先区分延迟、吞吐量与实际可用性
延迟低，表示某次测试较快得到响应；不表示持续传输一定快。吞吐量描述单位时间传送的数据量。可用性还包括连接是否成功、目标服务能否访问、长连接会不会中断。三者有关联，但不是同一个指标。选择节点时，不能只把 SERVER 列表里最小的数字当作最终答案。
从 Home 进入 Connectivity Test 查看测试入口。读结果前，先确认当前使用的测试方式与目标。TCP 建连测试主要观察到服务器指定端口的连接建立过程；经代理访问 HTTP 或 HTTPS 目标的测试，还可能涉及代理握手、名称解析和目标站响应。不同方式覆盖的链路不同，结果不适合直接混排。具体可选项以应用内英文界面为准。
服务器端口必须与服务商提供的参数一致。例如原始条目使用端口 8443，不能为了“更快”自行改成 443。端口号不是速度档位。测试成功也只说明本次探测覆盖的环节成功，不足以证明视频播放、上传或所有网站都正常。
结论：先保留能稳定完成测试的候选
固定测试方式与目标，连续观察三轮；先排除反复超时的候选，再让剩余候选访问同一个实际目标，不按单次最小值直接定案。
二、按固定顺序测试，避免把网络变化当成节点差异
一次只改变一个条件。先固定设备、当前网络、测试方式和目标，再切换节点。不要把 Wi-Fi 下的结果与蜂窝网络下的结果直接比较，也不要一边下载大文件、一边用测试数字判断线路质量。批量测试可以初筛；确定候选后，逐个复测更容易分辨偶发波动。
- 确认列表来源。在 Home 的 SERVER 区找到已有订阅中的条目，核对名称与所属分组。若服务商已经变更参数，先更新对应订阅，再开始对比。
- 固定测试条件。在 Home → Connectivity Test 使用同一种测试方式。测试期间保持同一 Wi-Fi 或同一蜂窝网络，暂停其他设备上的大流量传输。
- 做三轮记录。每轮记录响应值、是否超时、测试时间及网络类型。轮次之间留一点间隔，不要只保存表现最好的一轮。
- 选中候选再连接。确认当前选中的条目，再检查 Home → Global Routing。若使用策略组，还要核对组内实际选择，避免只改了列表选择，目标流量却仍使用另一出口。
- 验证真实任务。用同一网页查看首次加载与刷新，用同一视频的固定画质观察起播、拖动和连续播放。先断开旧的测试连接，避免连接复用干扰判断。
以下是记录方法的假设示例，不是线路实测或性能承诺：候选 A 三轮为 42 / 260 / 超时，候选 B 为 88 / 91 / 89 ms。A 的最低值更小，但波动明显；B 更值得进入实际任务验证。三轮样本只能做初筛，不能据此计算长期丢包率，也不能保证其他时段表现相同。
三、地区名称只是线索，要看完整访问路径
地区距离会影响传播时延，但设备到入口服务器、入口到出口、出口到目标网站，是不同的路径。节点名称中的地区文字通常是来源方的标记，不能单凭名称确定实际入口位置、出口位置或中间路由。物理距离近，也可能因为绕行、互联拥塞或服务器负载而慢。
比较地区时应先明确任务。网页操作和远程交互通常更容易感受到响应等待；长视频更依赖持续供给数据的能力。目标服务还可能按出口地址选择内容分发节点，因此同一个候选访问两个网站，体验也可能不同。不要把“到服务器快”直接等同于“到目标网站快”。
验证方案：按实际任务保留不同候选
网页与交互任务
- 固定同一目标页面，比较首次打开与重复操作。
- 优先观察响应是否稳定，而不是只看最低延迟。
- 留意登录跳转、图片加载与提交请求是否完整。
视频与持续传输
- 固定视频与画质，避免自动降画质掩盖差异。
- 分别观察起播、拖动和连续播放是否停顿。
- 在常用时段复测，记录拥塞是否反复出现。
地区用于缩小候选范围；最终选择取决于当前网络到实际目标的完整路径。
更换 Wi-Fi、蜂窝网络或所在城市后，原来的排序可能改变。已有候选不必每天全部重选；只有持续出现体验变化时，再按相同流程复测。保留一个经过验证的备用条目，比频繁追逐瞬时最低数字更便于排查。
四、协议类型看适配条件，不按名称排速度榜
Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的连接机制和参数不同。协议能否正常工作，首先取决于服务端与客户端配置匹配，其次取决于当前网络对相关传输的支持。不能把某个名称直接当成“高速”或“低延迟”的保证，更不能把已有条目的 Type 改一下就当成另一种协议使用。
| 协议 | 需要理解的特性 | 对比前先核对 |
|---|---|---|
| Shadowsocks | 使用配置约定的加密方式与凭据。 | 服务器地址、端口、加密方式和密码是否对应。 |
| VMess / VLESS | 可搭配不同传输与安全设置，协议名不能完整描述连接路径。 | 身份参数、传输方式，以及服务端要求的 TLS 等设置。 |
| Trojan | 通常结合 TLS 建立连接。 | 密码、服务器名称与证书验证是否符合原始配置。 |
| Hysteria2 | 基于 QUIC，依赖 UDP 可达性。 | 当前网络是否允许相关 UDP 流量，认证参数是否一致。 |
| WireGuard | 使用 UDP，依靠密钥与隧道参数建立通信。 | 密钥、对端地址及隧道参数是否完整匹配。 |
例如，某个 Wi-Fi 对 UDP 有限制时，依赖 UDP 的候选可能无法正常连接，但这不代表该协议在所有网络中都慢。反过来，TCP 建连测试成功，也不能证明 UDP 业务正常。应结合目标业务验证，而不是只用一种探测结果评价所有协议。
- 比较协议前，尽量保持出口地区、测试目标与时间接近；服务器不同带来的差异，可能比协议差异更大。
- 保留订阅给出的原始参数，不通过关闭证书验证来追求测试通过。
- 分享排查记录时隐藏密码、密钥、身份参数及完整订阅地址，只记录必要的协议名和现象。
五、确认 Global Routing，避免测到的不是所选节点
节点已经切换，网页表现却完全不变，先检查路由。Home → Global Routing 决定整体流量处理方式；它不是速度等级。Config 页面中的规则与策略，也会决定目标请求实际使用哪个出口。只有确认目标确实经过候选，测试比较才成立。
Config
推荐按当前启用配置中的规则处理流量。命中后的动作取决于规则指定的策略，未提前命中的请求仍由后续规则或 FINAL 决定，不应一概理解为直连。
适合:已经核对规则与策略指向后的日常使用
Proxy
整体采用代理处理方式。可用于临时缩小规则分流带来的变量，但仍应确认实际代理选择，以及连接是否成功。
适合:短时排查目标是否因规则而走了不同路径
Direct
整体采用直连处理方式。此时目标的访问表现不能用来评价所选代理节点，可用于判断当前网络直连该目标的情况。
适合:建立直连对照，不适合作为节点测速结果
如果使用 Scene，应检查实际场景对应的设置，不要把场景名称当作固定出口。若启用了 Settings → On Demand，测试时还要留意按需连接是否改变了连接状态。这里的重点是保持条件一致，不是为了测速永久改变日常配置。
结论：切换节点后，先核对路径再解释差异
确认 Global Routing、规则策略和当前代理选择，再重新建立目标连接。若临时改用 Proxy 做对照，完成后恢复原来的日常设置。
六、延迟低但网页或视频慢，按现象逐项排查
测试数字与实际体验不一致时，先区分“从一开始就慢”与“传输一段时间后变慢”。前者可能涉及名称解析、握手、目标站响应或路由选择；后者更值得检查持续吞吐、拥塞和连接稳定性。以下顺序有助于减少无效改动。
- 测试快，所有实际目标都慢：先确认测试方式是否只覆盖了到服务器的建连，再核对 Global Routing 与实际出口。暂停后台传输，用另一个已验证候选作对照。
- 只有一个网站慢：换另一个目标测试，排除该站自身响应、内容分发路径或访问限制。单站问题不能直接推断整个节点不可用。
- 视频起播快，随后反复缓冲：固定画质后继续观察。短时握手快并不代表持续吞吐足够；在相近时间对比备用候选更有意义。
- 晚间慢，其他时段正常：记录相同目标在不同时段的表现，考虑共享链路拥塞与负载变化。不要因为一次高峰结果就修改协议参数。
- 所有候选同时超时：先检查设备当前网络是否正常，再确认订阅是否更新、服务参数是否变化。批量失效更应优先寻找共同原因。
提交问题时，记录设备网络类型、协议名、测试方式、发生时段、是否只有一个目标异常，以及换候选后的结果。不要公开真实凭据。这样的记录比单独提供一张最低延迟截图，更容易区分本地网络、服务参数与目标站问题。