本文面向已经在 Shadowrocket（小火箭）中导入自有配置、但不知道如何从现有节点列表中选择的人。判断顺序是先排除不可连接项，再比较多轮延迟与波动，随后按地区、协议和实际用途做短时复测，最终保留少量表现稳定的候选项。
先理解延迟数字测到了什么
Shadowrocket 节点列表中的延迟数字主要用于快速判断连接是否能够建立，以及一次测试往返大致需要多长时间。它适合做第一轮筛选，但不能单独代表下载速率、视频缓冲、页面加载完整耗时或长连接稳定性。测试目标、当前网络、DNS 解析、协议握手和服务器当时的负载都会影响结果。
延迟通常以 ms 表示，数字越小，代表该次测试完成得越快。例如，40 ms 表示约 0.04 秒，180 ms 表示约 0.18 秒。但实际打开一个页面并不是只完成一次往返：DNS 查询、TCP 建连、TLS 握手、请求发送和资源下载可能形成多次交互，因此两项节点相差十几毫秒时，体感未必存在稳定差异。
更有价值的数据不是某一次最低值，而是多次结果是否接近。假设节点 A 三次显示 42、47、190 ms，节点 B 三次显示 71、74、79 ms；A 的最低值更低，但波动明显，B 在交互操作中反而更容易保持一致。这组数字只是判断方法示例，不代表任何地区或协议的固定表现。
按固定步骤筛选已有节点
筛选时应控制变量。测试过程中保持同一台设备、同一个 Wi-Fi 或蜂窝网络，并尽量在相近时间完成。若一半数据来自家庭 Wi-Fi，另一半来自蜂窝网络，结果会混入接入方式、信号强度和运营网络路径差异，无法公平比较。
确认配置来源
在 Home 检查已有节点是否来自用户自己的配置。通过订阅维护时，使用 Home 右上角「+」→ Type → Subscribe，示例地址可写为 https://example.com/sub?token=xxxx，保存后按配置方式更新。
固定本地网络
关闭正在进行的大文件传输，让设备保持在同一 Wi-Fi 接入点或同一蜂窝网络状态，避免在测试中途切换连接。
完成三轮测试
在 Home 的节点列表使用延迟测试功能，对候选项连续测试至少三轮，记录成功、timeout、最低值和最高值。
排除明显异常
先移除连续无法完成测试的候选项，再标记波动超过数倍、频繁从几十毫秒跳到数百毫秒的项目。
切换实际验证
逐个选中剩余候选项，连接后使用同一网页、同一段视频或同一受控文件进行短时验证，不要同时改变 Global Routing。
分时段复测
在实际常用时段重新测试一次。白天稳定不等于晚间稳定，跨时段结果比单次最低延迟更有参考价值。
记录时不必追求复杂工具。一张包含“节点名称、地区、协议、三轮延迟、是否 timeout、网页首开、持续传输”几列的表格就足够。延迟相近时，优先保留多轮结果稳定、实际任务中错误更少的项目。
| 候选项 | 三轮延迟示例 | 观察结果 | 处理方式 |
|---|---|---|---|
| A | 42 / 47 / 190 ms | 最低值较低，第三轮突增 | 保留复测，不直接定为首选 |
| B | 71 / 74 / 79 ms | 数字稍高，三轮接近 | 进入实际使用验证 |
| C | timeout / 128 / timeout | 测试成功率较低 | 检查配置或暂时排除 |
地区距离只是一项变量
在其他条件接近时，地理距离较短通常意味着传播路径可能更短，但节点名称中的地区标签并不能完整描述真实路由。数据包可能经过不同的国际出口、中转网络和拥塞点，标注相邻地区的两个节点也可能走完全不同的路径。
选择地区时，应先看用途是否对响应时间敏感。浏览网页、远程交互和即时请求更关注往返延迟与抖动；连续观看内容或传输较大文件更关注持续吞吐、丢包恢复和长连接稳定性。前者常能感知较大的延迟差，后者则可能在“延迟不最低但持续速度稳定”的节点上表现更好。
推荐方案：把交互与持续传输分开测试
交互测试
- 连续打开同一组页面
- 观察首次响应与图片加载
- 重复操作三次，排除缓存偶然性
- 记录连接是否出现间歇停顿
持续传输测试
- 使用同一受控资源验证
- 保持测试时长与文件一致
- 观察速度是否大幅起伏
- 检查数分钟连接是否中断
地区标签用于缩小候选范围，最终选择仍以相同条件下的实际任务结果为准。
如果主要任务需要访问特定地区提供的内容，还要考虑服务本身的区域策略。延迟最低的地区不一定满足目标服务的访问条件，而满足地区条件的节点也不一定具有最低延迟。因此应先确定必要地区，再在该地区的已有候选项中比较稳定性。
- 相邻地区：适合作为低延迟候选，但仍需检查晚间波动。
- 较远地区：基础延迟通常可能更高，应重点观察稳定性和实际用途是否匹配。
- 同一地区多个节点：不要只留最低值，应分别记录三轮波动与实际成功率。
- 名称相似的节点：名称不能证明底层线路一致，测试结果应分别记录。
协议类型会改变测试表现
Shadowrocket 支持多种协议与传输组合。协议名称能够说明封装和连接方式的一部分，但不能单独决定速度。同一种协议部署在不同服务器、不同端口和不同网络路径上，表现可能相差很大；不同协议在同一条质量良好的路径上，也可能都能满足日常使用。
Shadowsocks 的结构相对直接；VMess 与 VLESS 的实际表现还会受底层传输与加密配置影响；Trojan 通常结合 TLS；Hysteria2 侧重基于 UDP 的传输特性；WireGuard 也是基于 UDP 的隧道协议。UDP 在部分网络中表现良好，但在限制或丢包明显的环境中可能受到影响。HTTPS 流量常见于 TCP 443，HTTP/3 与部分 UDP 方案则常涉及 UDP 443，但实际端口由用户已有配置决定。
传统连接组
- Shadowsocks
- 结构直接，表现取决于加密方式与线路
- VMess
- 需结合实际传输设置判断
- VLESS
- 协议名称之外还要核对底层传输
不能仅凭协议名推断延迟或吞吐。
TLS 与 UDP 组
- Trojan
- 常结合 TLS，握手与路径都会影响首连
- Hysteria2
- 基于 UDP，需观察当前网络的 UDP 质量
- WireGuard
- 基于 UDP，适合用持续连接验证稳定性
同一网络下分别测试，避免跨网络直接比较。
协议筛选不能采用“某一种一定最快”的固定结论。正确做法是从用户现有配置中挑出地区相近、负载条件相近的候选项，再分别完成延迟和实际任务测试。如果某个 UDP 协议在 Wi-Fi 下稳定、在蜂窝网络下频繁失败，应把它记录为网络环境差异，而不是把一次结果扩展成普遍结论。
测试记录示例
网络：同一 Wi-Fi
Global Routing：Config
候选 A：VLESS，68 / 72 / 70 ms，网页首开稳定
候选 B：Trojan，55 / 160 / 59 ms，偶发停顿
候选 C：Hysteria2，83 / 81 / 85 ms，持续传输稳定
结论：按用途保留 A 与 C，B 留待其他时段复测。Global Routing 不一致会让结果失真
测试节点时，Global Routing 必须保持一致。Config 会按规则逐条匹配，Proxy 会让流量统一经过当前代理，Direct 会直接连接，Scene 则按已设置的场景执行。如果测试 A 时使用 Config、测试 B 时切到 Proxy，两个结果可能经过不同处理路径，无法直接对照。
Config
推荐按当前配置中的规则自上而下匹配，更接近日常分流状态。测试前应确认目标请求实际命中预期策略。
适合：日常选择与长期使用验证
Proxy
让流量统一通过当前代理，可减少规则差异对节点对比的干扰。
适合：排查规则命中问题与短时对照
Direct
流量直接连接，不用于判断当前代理节点的实际传输表现。
适合：建立本地网络基线
Scene
按用户已经设置的场景切换处理方式，结果取决于场景条件与动作。
适合：验证固定网络场景下的自动策略
使用 Config 时，还要检查规则是否把测试目标分配到 DIRECT。典型规则会按配置顺序匹配，DOMAIN-SUFFIX 针对域名后缀，GEOIP 针对 IP 所属地区，IP-CIDR 针对网段，FINAL 处理前面均未命中的流量。若测试资源被 DIRECT 命中，观察到的并不是所选节点表现。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY上例中，example.com 会优先命中 PROXY；局域网网段会走 DIRECT；随后由 GEOIP 处理符合条件的地址；其余流量交给 FINAL。规则从上到下匹配，因此更具体的规则通常应放在可能覆盖它的宽泛规则之前。
为什么低延迟仍可能不流畅
延迟测试只覆盖连接体验的一部分。真实访问还受带宽上限、服务器并发负载、路径丢包、抖动、重传、DNS 响应和目标服务处理时间影响。一个节点可以在短测试中很快返回，却在持续传输时因为拥塞而速度下降；另一个节点的基础延迟较高，但吞吐更平稳。
常见现象包括：节点列表显示 50 ms，但视频开始播放后频繁缓冲；延迟显示 100 ms 左右，网页却能持续稳定加载；第一次测试正常，晚间同一候选项出现数百毫秒波动；Wi-Fi 下正常，切换蜂窝网络后 UDP 连接表现改变。这些现象都说明需要分层判断。
| 现象 | 优先检查 | 验证动作 |
|---|---|---|
| 延迟低但持续速度不稳 | 负载、丢包、时段拥塞 | 换时段并用同一资源复测数分钟 |
| 三轮数字差异很大 | 本地信号、路径抖动 | 停止后台传输，固定网络后重测五轮 |
| 只有部分应用异常 | Config 规则与 DNS | 临时用 Proxy 对照，检查规则命中 |
| Wi-Fi 正常，蜂窝异常 | 接入网络与 UDP 条件 | 分别记录 TCP 与 UDP 协议候选表现 |
| 连接后完全无法访问 | 配置有效性、系统 VPN 状态 | 检查 Home 状态并重新选择已验证候选项 |
DNS 也会制造“节点慢”的错觉。域名解析等待发生在内容传输之前，如果解析超时或返回路径不合适，页面首开会变慢，但延迟数字可能仍然正常。排查时应保持 DNS 设置不变，先对比多个候选项；如果所有候选项都同时出现相似的域名首开问题，再单独检查配置中的 DNS 项。
本地网络是另一项基础变量。Wi-Fi 信号弱、接入点繁忙、蜂窝信号来回切换或后台同步占用带宽，都会让所有节点一起变慢。当多个地区、多个协议在同一时刻都出现高延迟时，应先测试 Direct 基线和本地网络，而不是逐个修改节点参数。
- 单次最低延迟只用于初筛，不作为最终结论。
- 三轮至五轮波动比一轮结果更重要。
- 网页、视频和持续传输需要分别验证。
- 所有候选项同时异常时，先检查本地网络与 DNS。
- 仅某一协议在特定网络异常时，再检查 TCP、UDP 与端口条件。
On Demand 与订阅更新后的复核
Settings → On Demand 用于根据网络条件决定连接行为。启用后，Wi-Fi 名称、网络类型或其他条件可能触发连接或断开。若测试过程中网络状态变化并触发 On Demand，当前连接可能被重新建立，导致前后数据不在同一条件下。
正式测试前，可以先查看 Settings → On Demand 中已有规则，确认当前 Wi-Fi 与蜂窝网络分别会触发什么动作。测试时要么保持条件完全不变，要么暂时采用一组明确的固定条件。完成选择后，再恢复并验证自动连接是否符合预期。
测试前检查
- 入口
- Settings → On Demand
- 网络
- 固定 Wi-Fi 或固定蜂窝状态
- 触发
- 确认不会在测试中重建连接
- 路由
- 保持同一 Global Routing
条件变化后产生的数据应单独记录。
更新后检查
- 入口
- Home 中的已有 Subscribe 配置
- 动作
- 按原配置方式更新
- 变化
- 检查名称、地区、协议与可用性
- 复测
- 重新完成至少三轮延迟测试
订阅内容变化后，旧记录不能直接代表新项目。
订阅更新可能新增、移除或调整节点，也可能改变名称和底层参数。更新后即使名称看起来相同，也应重新完成可连接性与延迟测试。若用户自行维护多个配置，还要确认当前激活的是哪一份 Config，避免在错误配置中选择节点。
Shadowrocket 是 Apple 平台的付费商业应用，iPhone 与 iPad 是主要使用设备，商店兼容性栏也可能列出 Mac、Apple TV 与 Apple Vision；系统要求以 App Store 页面标注为准。正版入口为 App Store，开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118，一次性买断得到的是客户端本身。
形成可重复的选择结论
一次测试只能说明当时的状态。更可靠的方法是保留少量候选项，并按“常用地区、备用地区、TCP 候选、UDP 候选”做简单备注。当网络环境或使用地点改变时，从对应候选组中复测，而不是重新遍历整个列表。
如果两个节点在三轮延迟、网页首开和持续传输上都接近，不必继续追求几毫秒差异。选择名称清楚、表现稳定、更新后容易辨认的一项即可。过度频繁切换会让 DNS 缓存、连接复用和测试时段不断变化，反而降低比较质量。
- 固定设备、网络、Global Routing 与测试资源。
- 对已有候选项完成至少三轮延迟测试。
- 排除连续 timeout 和明显不稳定项。
- 按必要地区与协议条件缩小范围。
- 用网页交互和持续传输分别复测。
- 在常用时段再验证一次，并记录备用项。
完成上述流程后，得到的不是一个永久不变的“最快节点”，而是一组在当前网络与当前用途下更合适的选择。网络路径和负载会变化，因此当体验明显改变时，应从本地网络基线开始复核，再依次检查规则、DNS、协议与节点状态。