本文以用户已有自己的服务商与订阅为前提，说明如何在 Shadowrocket 中建立一致的测试条件，再按可连接性、地区需求、协议条件和实际加载表现缩小候选范围。延迟数字用于初筛；是否适合日常使用，需要在相同网络下重复访问实际目标确认。
先确认节点来源与测试条件
Shadowrocket（小火箭）中的节点是连接配置，通常包含服务器地址、端口、协议和认证信息。订阅把这些配置集中导入，并可通过更新同步变化。节点名称是标签，不能单独证明服务器所在地、出口地址或当前负载；同名配置更新后也可能已经改变。
开始比较前，先在 Home 确认已有订阅已加载，且需要比较的节点仍在列表中。如果服务方明确通知配置变更，再更新对应订阅并核对结果。不要在一轮测试中途更新，否则前后测量可能对应不同的服务器参数。
-
核对配置
在 Home 查看已有节点；需要首次导入时，使用 Home 右上角「+」→ Type → Subscribe，填写自己的订阅地址并保存。导入后确认列表实际出现节点。
-
固定网络
先只用 Wi-Fi 或只用蜂窝网络，暂停大文件传输。打开 Settings → On Demand，记录现有状态，避免测试期间因网络条件变化自动切换连接状态。
-
统一测法
在 Home → Connectivity Test 确认当前测试方式。对所有候选使用同一种方式；若界面允许设置测试目标，也应保持目标一致。
-
重复记录
对少量候选逐个测试，每个至少记录三次结果与测试时间。保留超时记录，不要只抄一次最低数字。
测试节点不等于已把业务流量切换到该节点。完成测试后，需要在 Home 选中候选并核对连接状态；原先已建立的长连接也不一定立即改走新路径，实际验证时应重新打开目标应用或建立新的请求。
延迟数字测到了什么，没测到什么
延迟通常以 ms 表示，数字越小，表示这一次测试等待的时间越短。但不同测试方式覆盖的链路不同：TCP 握手主要检查到服务器端口的连接建立；通过代理访问测试目标，则还会受到协议握手、目标响应和相关解析过程影响。两种数字不能直接放在一起排序。
初筛记录
- 入口
- Home → Connectivity Test
- 单位
- ms，记录同一种测试方式
- 次数
- 每个候选至少三次
- 异常
- 超时、失败也纳入记录
先排除反复无法完成测试的配置，再比较成功结果的稳定程度。
业务验证
- 目标
- 自己实际使用的同一个页面或应用
- 条件
- 相同网络、相同 Global Routing 设置
- 观察
- 首次内容出现、连续加载与中断
- 复查
- 常用时段再次执行相同步骤
延迟测试通过后，仍需确认完整业务请求能够正常完成。
例如，一组示意结果是 42、190、超时，另一组是 86、89、91。前者有更低的单次数字，后者在这三次记录里更一致。这只是解释记录方法的假设数据，不代表任何线路实测，也不能据此推断长期质量。
延迟不等于吞吐量。短小的测试请求可能很快完成，但持续传输仍会受到带宽、拥塞、丢包和服务器处理能力影响。相反，延迟略高的路径可能持续加载更平稳。不要把 ms 当成下载速度，也不要用一次短测试推断视频能否持续播放。
按地区筛选：看实际目标，不只看距离
地区可以作为缩小候选范围的条件，但地理距离不是网络路径长度。设备到入口、服务内部转发、出口到目标网站是不同环节；节点名称里的地区也可能描述出口，而非设备首先连接到的服务器位置。
地区筛选：普通访问与指定地区需求
普通网页与日常应用
- 从已有订阅中选少量候选，不必一次测试全部地区。
- 用同一目标页面比较首次加载与连续操作。
- 优先保留多次结果稳定、失败少的候选。
目标有地区要求
- 先阅读目标服务本身的地区与账户要求。
- 核对实际访问结果，不把节点名称当成出口证明。
- 地区符合后，再比较延迟和持续加载表现。
先满足使用条件，再在符合条件的候选中比较；不要只按地图距离或名称排序。
目标服务还可能同时参考账户地区、设备定位、付款信息或既有会话。切换节点只改变其中一部分网络条件，不保证改变服务可用范围。若页面仍显示原状态，先确认请求确实经过新节点，再核对目标服务的规则，避免反复切换造成判断混乱。
按协议类型筛选：先看兼容条件
协议名说明连接如何建立，不是性能等级。同一个协议可以运行在不同服务器与网络路径上；同一个服务器也可能提供不同协议。比较时应尽量控制其他变量，不能把更换地区、服务器和协议后的整体变化全部归因于协议。
| 协议 | 需要核对的条件 | 不能直接推断的结论 |
|---|---|---|
| Shadowsocks | 地址、端口、密码与加密方法一致；UDP 转发还需服务端支持。 | 不能仅凭协议名判断速度或是否支持某个应用。 |
| VMess / VLESS | 认证信息、传输方式以及所配置的 TLS 参数相互对应。 | 不能把一个传输配置的表现套用到同协议全部节点。 |
| Trojan | 密码、TLS 服务器名称与证书验证条件正确。 | 端口可连接不等于 TLS 与认证已成功。 |
| Hysteria2 | 基于 QUIC，依赖 UDP 路径；核对认证与 TLS 参数。 | 不能因为使用 UDP 就认定任何网络下都会更快。 |
| WireGuard | 依赖 UDP；核对密钥、Peer 与路由相关配置。 | 不能由一次握手成功推断所有业务路由都正确。 |
端口号只是连接参数。例如配置中的 443 并不能独自证明节点采用哪种协议、是否启用 TLS，或能否通过当前网络。不要为让测试通过而随意把原端口改成 443；服务器必须确实在对应端口提供匹配服务。
延迟很低却打不开：检查 Global Routing
节点测试成功只说明对应测试能够完成。实际访问还受 Global Routing、当前配置规则、DNS 和目标服务状态影响。若业务请求走了 Direct，或者某条规则指定了其他策略，刚测出的节点延迟就不能解释这次访问的表现。
Config：按配置判断
推荐在 Home → Global Routing 选择 Config 后，流量按当前配置匹配策略。检查 Config 中启用的文件，不能假定未匹配流量一定直连；最终走向取决于 FINAL 等配置。
适合：已有明确规则、需要按规则日常使用的场景。
Proxy：缩小排障范围
将由 Shadowrocket 接管的流量按代理模式处理，可用于临时判断问题是否与规则选择有关。仍需确认当前选中的节点和完整连接结果。
适合：同一目标在 Config 下失败时，做一次受控对照。
Direct：建立直连基线
使用直连路径，而非通过所选代理节点访问。此时目标打开快慢反映的是直连条件，不是候选节点的质量。
适合：确认目标在当前网络下的直连表现。
如果使用 Scene，还需先核对对应场景的设置与实际生效状态，不要把场景切换误认为节点自身变化。做比较时固定一种 Global Routing 姿态，并记下测试结束后需要恢复的设置。
DOMAIN-SUFFIX,example.com,PROXY：示例域名后缀命中后使用 PROXY 策略。IP-CIDR,192.168.0.0/16,DIRECT：示例私有地址网段使用 DIRECT。GEOIP,CN,DIRECT：按 GEOIP 判断结果匹配，不等同于按节点名称判断地区。FINAL,PROXY：前面的规则未命中时使用 PROXY；规则应按顺序核对。
以上仅用于解释规则，不是要求替换现有配置。若只有某个域名失败，优先核对该请求的策略与解析结果；若所有候选都在同一个目标上失败，也应检查目标本身，而不是立即认定全部节点不可用。
把测试结果整理成主用与备用
初筛后保留少量候选，再按真实使用顺序验证：打开目标页面、进入下一层内容、连续操作数分钟。如果要比较视频或文件传输，应保持清晰度或文件条件一致，并留意测试会消耗流量。缓存命中可能让第二次打开明显变快，因此不能只凭第二次加载判断节点改善。
- 选主用：在常用网络和常用时段，优先保留目标访问完整、重复结果稳定的候选，不追逐单次最低 ms。
- 留备用：从已有订阅中保留另一个通过相同验证的候选。名称不同不一定代表底层路径不同，是否具备独立路径需以已有服务信息为准。
- 换网络重测：Wi-Fi 的排序不能直接套用到蜂窝网络；切换网络后重新做短测试与目标访问。
- 变更后复查：订阅更新、配置切换或服务参数变化后，再确认选中节点与 Global Routing 状态。
记录不必复杂：网络类型、时间、节点名称、协议、三次延迟、实际目标是否完整加载即可。若某个候选只有晚间频繁失败，把这一条件记下来比写“好用”或“不好用”更有助于下次判断。
测试超时，但网页可以打开，要删除节点吗？
先确认网页确实经过该节点，而不是走 Direct 或命中缓存。若路径确认无误，可能是测试方式或测试目标与实际业务不同。保留记录，换用一致的测试条件复查，不凭一次超时删除配置。
是否需要每天把全部节点测速一遍？
通常没有必要。对正在使用和准备备用的少量候选做针对性检查即可。频繁批量测试可能产生额外连接与流量，也不能替代实际访问验证。出现持续异常或网络条件变化时再扩大检查范围。