小火箭节点怎么选:延迟测试、地区与协议类型,延迟数字为何不等于体验

介绍如何在已有订阅里按延迟、地区和协议类型挑选节点,并解释 Ping 测得的数字和实际加载速度、稳定性之间的差别。

本文速览

本文适用于已在 Shadowrocket(小火箭)中导入自己订阅的用户。筛选顺序是先确认连接与规则实际生效,再比较同一网络下的延迟波动、目标服务所需地区和协议适配情况。读完可建立一套可重复的对照方法,而不是只保留延迟数字最小的一项。订阅链接请从你的服务商处获取。

一、先固定测试条件,再筛选已有节点

节点名称通常包含地区、协议或服务商自定义标记,但名称不是性能证明。第一次筛选时,先确认订阅已更新、所选条目的参数完整,再固定网络和目标网站。不要一边切换 Wi-Fi 与蜂窝网络,一边用不同网页比较结果,否则无法判断差异来自节点还是本地网络。

  1. 核对订阅

    在 Home 找到已有订阅,核对条目与有效期。需要重新添加时,使用 Home → + → Type → Subscribe,填写从你的服务商处获取的链接并保存;更新后再进行筛选,不要把已失效的条目混入比较。

  2. 固定网络

    保持同一 Wi-Fi 或同一蜂窝网络,暂停其他设备的大流量传输。到 Settings → On Demand 核对按需连接条件,避免测试过程中网络条件变化触发连接状态变化。

  3. 确认路由

    在 Home → Global Routing 核对当前使用的 Proxy、Direct、Config 或 Scene。记录原设置;若用 Proxy 做临时对照,结束后恢复原设置,避免把日常分流行为一并改变。

  4. 逐项复测

    在 Home 选择一个候选条目,开启连接后执行 Connectivity Test,再访问同一目标页面。每个候选连续观察三次,记录能否连接、首屏等待和中途停顿,不只记录一个毫秒数。

已有订阅更新会改变条目数量、地址或参数。更新前后应分别记录所选条目,防止实际选择已变化却仍沿用旧结论。订阅地址中的 token 属于访问凭据,不应出现在公开截图、日志分享或测试记录里。

二、Ping、连接延迟与实际加载不是同一个指标

日常所说的“Ping”常被用来泛指延迟,但不同测试测量的路径并不相同。ICMP 探测、TCP 建连和经代理访问测试地址,各自覆盖的环节不同。比较前应核对当前测试方法与目标地址;同一个列表里的数字只有在测试条件一致时才有直接比较意义。

ms
延迟的时间单位,不是下载速率单位
3 次
本文建议的同条件复测次数,不是应用固定要求
443
HTTPS 常用端口,不代表节点必须使用此端口

延迟描述一次探测往返或一次连接过程所花的时间;吞吐量描述持续传输能力。网页还涉及 DNS、连接建立、TLS 握手、服务器响应和多个资源请求。延迟较低可以缩短部分等待,但无法单独证明大文件传输更快,也不能证明目标网站会接受该出口地址。

观察结果能说明什么下一步验证
探测返回低延迟本次测试路径响应较快打开实际使用的网站,观察首屏与连续加载
探测超时但网页可用探测方式或测试目标可能不适用核对测试方法,保持同一目标重新比较
连接成功但持续停顿建连完成不代表后续传输稳定排除本地网络拥塞,再比较丢包和服务端负载
普通网页正常、单站失败故障可能与目标站点、DNS 或规则有关查看请求命中的规则和实际出口

例如,假设候选 A 三次为 45、260、超时,候选 B 为 85、88、91 毫秒,这组演示数据里 B 的波动更小,但仍需访问目标服务验证。它不是实测性能排名,也不表示某个地区或协议固定更快。实际选择应优先关注重复结果,而不是偶然出现的最低值。

三、地区选择要区分入口、出口与目标服务

节点标注的地区可能描述出口,也可能只是服务商的命名方式。设备先到达入口,流量再经过服务商网络到出口,最后访问目标服务;地理距离只解释其中一部分。地图上更近不保证网络路由更短,名称中的地区也不能替代服务商对实际出口的说明。

地区筛选:普通浏览与指定地区服务

普通浏览
  • 从已有订阅中选两个不同出口作为候选。
  • 在同一网络、相近时间访问同一组页面。
  • 优先记录持续可用性与延迟波动,不只看地图距离。
指定地区服务
  • 先核对目标服务的地区要求与使用条款。
  • 从你的服务商处确认条目的实际出口地区。
  • 检查目标请求是否确实走该出口,并以目标服务的实际响应为准。

地区是筛选条件,不是可用性承诺;同地区不同线路也需要分别验证。

地区判断还可能受到账户资料、设备定位、已有会话及服务自身策略影响。因此“切换地区后仍显示原地区”不能直接归因于 Shadowrocket 未连接。先核对路由和出口,再按目标服务的正常流程重新建立会话;不要通过频繁切换条目代替定位原因。

四、协议类型按服务端参数与网络条件选择

Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 是不同的协议选项,不是速度等级。只有服务端确实提供相应协议及完整参数时,客户端配置才有意义。把 Type 改成另一个名称不会让原服务器自动支持新协议,也不能仅凭端口号判断协议。

协议优先核对的参数筛选时的注意点
Shadowsocks服务器、端口、加密方法、密码参数需与服务端一致,不能只确认地址能解析
VMess / VLESSUUID、传输方式、TLS 及相关传输参数两者认证机制不同,不能直接互换 Type
Trojan密码、端口、TLS、SNISNI 与证书及服务端配置应匹配,不能用关闭验证替代修正参数
Hysteria2认证信息、TLS、服务端要求的其他参数使用基于 UDP 的 QUIC,网络对 UDP 的限制会影响连接
WireGuardPrivateKey、PublicKey、Endpoint、Address、MTU依赖 UDP;密钥、地址和路由条件均需正确

例如,某条目的服务端口被配置为 8443,应填写服务商给出的 8443,不能因为 HTTPS 常见端口是 443 就自行替换。Hysteria2 与 WireGuard 都使用 UDP,也不意味着它们在同一网络里必定得到相同结果:服务端位置、实现方式、线路负载及参数仍然不同。

五、先确认 Global Routing,避免选中节点却没有使用

在 Home 点选条目,并不代表所有请求都会经过该条目。Global Routing 决定请求如何处理;Config 下还可能由规则指定策略或策略组。排查节点差异之前,必须确认目标请求的实际去向,否则测到的可能一直是直连路径。

Config

推荐

依据当前配置的规则决定请求走向。先在 Config 核对生效配置,再检查目标域名命中的规则与策略;并不是所有未匹配请求都必然直连。

适合:已有正确分流配置的日常使用

Proxy

将进入代理处理范围的请求按代理模式处理,可用于缩小规则分流带来的变量;仍需考虑系统与配置中的排除范围,不能当作所有设备流量都经过代理的证明。

适合:临时比较代理路径,完成后恢复原设置

Direct

使用直连路径。即使 Home 中已有选中的节点,也不能据此评价该节点的访问效果;可用作本地网络的对照条件。

适合:确认不经代理时目标是否可达

Scene

按所配置的场景条件应用相应设置。测试前核对当前匹配的场景,不要假定切换网络后仍使用同一组路由条件。

适合:已明确设置场景、需要按环境切换的使用方式

规则通常自上而下匹配,FINAL 处理没有命中前序规则的请求。下面仅用于解释语法,不应整段覆盖现有配置;其中 PROXY 的实际目标需结合当前配置确认。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

此例中,example.com 及其子域名先由 DOMAIN-SUFFIX 命中;IP-CIDR 匹配指定地址段,no-resolve 表示不为该条规则主动执行域名解析。之后才判断 GEOIP,最后由 FINAL 兜底。若目标被前面的 DIRECT 规则命中,仅切换 Home 中的节点通常不会改变它的访问路径。

六、常见现象与复测方法

为什么最低延迟的节点看视频反而停顿?

低延迟只反映测试环节的响应时间。保持同一视频、相同清晰度与同一网络,对两个候选分别观察持续播放和缓冲恢复;同时暂停后台大流量任务。若只在高峰时段停顿,应记录时段后再比较,不能用一次探测替代持续传输验证。

Home 显示超时,是不是节点已经失效?

先检查测试方法和测试目标,再选中该条目开启连接,执行 Home → Connectivity Test,并访问实际目标。如果测试失败但业务正常,应排查探测条件;如果两者都失败,再核对订阅更新、地址、端口和认证参数。

换了节点,网页速度和地区都没变化?

先检查 Home → Global Routing 是否为 Direct;若为 Config,到 Config 核对目标是否命中 DIRECT 或固定策略组。让目标重新建立连接后再观察,已有长连接未必随条目选择立即重建。不要仅凭列表高亮判断实际出口。

Wi-Fi 正常,蜂窝网络下同一条目失败怎么办?

先确认蜂窝数据本身可用,再到 Settings → On Demand 检查网络条件,随后核对当前 Global Routing 与场景。参数不变而网络一换就失败时,记录协议、发生时间和错误现象,向你的服务商确认该网络下的可达性,不要反复改动密码或密钥。

七、保留复测记录,而不是固定追逐最低数字

最终可保留一个常用条目和一个已验证的备用条目;这只是对已有订阅的整理方法,不涉及任何服务来源推荐。记录应包含网络、测试时间、协议、出口说明、连续测试结果与实际应用表现。不要记录完整订阅链接、密码、PrivateKey 或其他认证信息。

判断顺序应保持为“可连接 → 路由正确 → 目标可用 → 持续稳定 → 比较延迟”。这样可以把参数错误、规则问题与线路表现分开,避免把所有访问异常都归结为节点速度。

App Store 正版下载核对开发者与应用 ID