打开呀 .co

海外网站与 AI 访问解决方案
客户端配置教程 • • 更新：2026-09-25 • 实操配置指南

小火箭节点测速与全局路由配置

如何科学测试小火箭节点的真实可用性？打开呀深入讲解 Shadowrocket 的 TCP/ICMP/HTTPS 测速机制、自动负载均衡与按域名/按场景自定义分流规则实操。

Shadowrocket 进阶指南：节点延迟测试、智能分组与场景路由配置

小火箭节点测速与全局路由配置

Answer Block

小火箭（Shadowrocket）的“延迟”数字来自一次 TCP 握手往返时间（RTT），并非 ICMP Ping，也不代表真实吞吐或可用性。 它只测量“从本机到代理服务器端口能否在 N 毫秒内完成三次握手”，因此 50ms 的节点仍可能打不开网页——原因可能是：握手后 TLS 被中间设备重置、节点出口到目标网站的路由绕远、带宽被占满、DNS 污染、或目标站点对该出口 IP 做了风控。要判断节点是否“真能用”，应使用 https://www.google.com/generate_204 或 Cloudflare 的 https://cp.cloudflare.com/generate_204 作为测试 URL，让客户端在握手后真正发起一次 HTTPS 请求并校验返回码。路由层面，Shadowrocket 的策略组支持 url-test（按测试 URL 的实测延迟自动选优）、fallback（按顺序回退，前一个不可用才用下一个）、load-balance（按权重/轮询分摊流量）三种核心逻辑；分流规则按 DOMAIN → DOMAIN-SUFFIX → DOMAIN-KEYWORD → IP-CIDR → GEOIP → USER-AGENT 的优先级自上而下匹配，命中即停。

一、小火箭“测速”到底测了什么

Shadowrocket 主界面那个绿色毫秒数，很多人误以为是 Ping。实际链路是这样的：

  1. 客户端读取节点配置里的 server:port；
  2. 通过底层 NetworkExtension（iOS）或 VpnService（Android）建立到该 server:port 的 TCP 连接；
  3. 记录 SYN 发出到 SYN-ACK 返回的时间差；
  4. 立即 FIN 关闭，不发送任何应用层数据。

所以它本质是 TCP Handshake RTT，不是 ICMP Echo，也不是 HTTP 首字节时间（TTFB）。这带来三个后果：

  • 握手快 ≠ 能上网：TCP 握手只验证“端口开着”。如果节点后面是坏的（出口被封、TLS 被 SNI 阻断、上游限速），握手照样 30ms。
  • 握手快 ≠ 带宽大：RTT 与吞吐无必然关系。一条 50ms 的线路可能只有 1Mbps，一条 200ms 的线路可能跑满 500Mbps。
  • 握手快 ≠ 目标可达：节点到 google.com 的路径可能绕地球一圈，而你测的只是“本机→节点”。

为什么 50ms 节点打不开网页？ 常见真实原因：

现象底层原因
握手 50ms，网页转圈节点出口到目标站点路由劣化，或出口 IP 被目标风控
握手 50ms，TLS 卡住中间设备对 ClientHello 的 SNI 做阻断/重置
握手 50ms，DNS 超时节点未开启远程 DNS，本地 DNS 被污染
握手 50ms，速度极慢节点带宽被其他用户占满，或 QoS 限速
握手 50ms，部分站点正常分流规则把目标域名走了 DIRECT，而直连被墙

结论：把“延迟”当作唯一指标是错的。真正要测的是“通过该节点访问真实目标”的端到端可用性与速度。

二、科学的测试 URL 配置

Shadowrocket 的 url-test 策略组、节点测速按钮都允许自定义测试 URL。选择原则：小体积、可预期状态码、全球可达、不被缓存干扰。

推荐端点：

  • https://www.google.com/generate_204 —— 返回 204 No Content，无 body，Google 全球 Anycast，能同时验证 DNS、TLS、HTTP 三层。
  • https://cp.cloudflare.com/generate_204 —— Cloudflare 版本，对大陆出口更友好，适合测“到国际骨干”的质量。
  • http://www.gstatic.com/generate_204 —— 纯 HTTP，排除 TLS 干扰，用于定位“是 TLS 问题还是链路问题”。

不要用：

  • https://www.baidu.com（国内直连，测不出代理质量）；
  • 大文件 URL（测速慢、耗流量）；
  • 带重定向的 URL（状态码不确定，客户端判定混乱）。

配置方法（Shadowrocket）：配置 → 策略组 → 编辑 → 测试 URL，填入上述地址；设置 → 延迟测试方法 可选 TCP 或 HTTP，建议选 HTTP，这样测速结果才包含 TLS 与首字节时间，更接近真实体验。

三、策略组：url-test / fallback / load-balance 的工作逻辑

Shadowrocket 的策略组（Policy Group）是路由决策的核心。三种类型语义完全不同：

url-test（自动测速选优）

  • 每隔 interval 秒（默认 600s）对所有成员节点用测试 URL 发起请求；
  • 选 延迟最低 的节点作为当前出口；
  • 只有当前节点失败或新一轮测试出现更优者才切换。
  • 适用：日常主力，节点质量相近、想始终用最快的那条。
  • 陷阱：如果测试 URL 走的是 DIRECT 或被规则改写，测速结果无意义；节点抖动会导致频繁切换，可调大 interval。

fallback（故障回退）

  • 按列表 顺序 尝试，第一个可用就用第一个，不可用才用第二个；
  • 不做延迟比较，只做可用性判断。
  • 适用：主备线路，比如“专线优先，专线挂了走备用”。
  • 陷阱：如果第一个节点“能握手但打不开网页”，fallback 可能仍认为它可用。

load-balance（负载均衡）

  • 按 轮询 或 权重 把不同连接分到不同节点；
  • 同一时刻不同 TCP 连接可能走不同出口。
  • 适用：多节点带宽叠加、规避单 IP 风控。
  • 陷阱：需要登录态/会话保持的网站（银行、部分后台）会因出口 IP 跳变而掉线；DNS 解析结果也可能不一致。

组合建议：外层用 url-test 选一组，组内用 fallback 做冗余；或对下载类流量单独建 load-balance 组，对登录类流量建固定节点组。

四、自定义分流规则与匹配优先级

Shadowrocket 规则自上而下匹配，命中即停。典型优先级（从高到低）：

  1. DOMAIN —— 精确域名，如 DOMAIN,api.example.com,Proxy
  2. DOMAIN-SUFFIX —— 后缀匹配，如 DOMAIN-SUFFIX,google.com,Proxy 命中 www.google.com、mail.google.com
  3. DOMAIN-KEYWORD —— 关键词，如 DOMAIN-KEYWORD,google,Proxy，最宽松也最易误伤
  4. IP-CIDR / IP-CIDR6 —— 目标 IP 段，如 IP-CIDR,8.8.8.8/32,Proxy；可加 no-resolve 避免触发 DNS
  5. GEOIP —— 国家/地区码，如 GEOIP,CN,DIRECT
  6. USER-AGENT —— 按 HTTP UA 匹配，如 USER-AGENT,Telegram*,Proxy
  7. FINAL / MATCH —— 兜底

实操要点：

  • 域名规则必须放在 IP 规则之前，否则 DNS 解析后 IP 先命中，域名规则永远不生效。
  • IP-CIDR 默认会触发 DNS 解析；若只想按 IP 匹配且不想泄漏 DNS，加 no-resolve。
  • USER-AGENT 只在明文 HTTP 可见，HTTPS 流量看不到 UA，别指望它管住加密流量。
  • 国内直连 + 国外代理的经典写法： 
    DOMAIN-SUFFIX,cn,DIRECT
GEOIP,CN,DIRECT
FINAL,Proxy
    但 GEOIP,CN 依赖 IP 库准确性，且会触发解析，建议配合 no-resolve 或改用 RULE-SET 订阅规则集。

五、FAQ

H3：为什么小火箭显示节点延迟只有 30ms，但打开 YouTube 却一直缓冲？

因为 30ms 是 TCP 握手 RTT，只证明“你的设备到节点端口”这一段快。YouTube 缓冲慢通常卡在更后面的环节：节点出口到 Google 边缘节点的国际链路拥塞、节点带宽被多用户共享、或该出口 IP 被 Google 限速。判断方法：把测试 URL 改成 https://www.google.com/generate_204 并选 HTTP 测速，如果这个数字远大于 TCP 延迟，说明瓶颈在节点之后；再用 https://speed.cloudflare.com 做一次实际下载测速，看吞吐是否只有几百 Kbps。若吞吐低而握手快，换节点即可，与你的本地网络无关。

H3：url-test 的 interval 设多少合适？设太短会有什么问题？

默认 600 秒（10 分钟）是合理起点。设太短（如 30 秒）有三个副作用：一是每次测试都要对所有节点发起 HTTPS 请求，节点多时产生可观流量与电量消耗；二是网络抖动会让策略组频繁切换出口，导致正在进行的连接（尤其是长连接、登录态）中断；三是部分节点会对高频探测做限流甚至封禁。建议：节点数 < 10 用 300s，节点数多或按流量计费用 900–1800s。真正需要快速故障切换的场景，应该用 fallback 而不是缩短 url-test 的 interval。

H3：fallback 和 url-test 能嵌套使用吗？嵌套后决策顺序是怎样的？

可以，Shadowrocket 支持策略组引用策略组。典型嵌套：外层 url-test 组 A，成员是 fallback 组 B 和单节点 C。决策顺序是：A 先对 B、C 分别测速，选出延迟低者；若选中 B，B 内部再按顺序找第一个可用节点。注意两点：一是嵌套层数越多，测速耗时越长，因为每层都要独立发起测试；二是内层组的测试 URL 与外层可以不同，建议内层用 generate_204 判可用性，外层用同 URL 判延迟，避免语义混乱。嵌套适合“多机房 + 每机房多线路”的结构，普通用户一层足够。

H3：DOMAIN-SUFFIX 和 IP-CIDR 同时命中一个请求时，谁生效？

先出现的规则生效，与规则类型无关。Shadowrocket 是顺序匹配，从上往下扫，第一条命中的规则决定该连接的走向，后面的规则不再评估。所以如果你把 IP-CIDR,1.2.3.0/24,DIRECT 写在 DOMAIN-SUFFIX,example.com,Proxy 之前，而 example.com 解析出的 IP 落在该段内，请求会走 DIRECT。正确做法是把精确的域名规则放在文件顶部，宽泛的 IP/GEOIP 规则放在底部。另外，IP-CIDR 默认需要先解析域名才能匹配，这个解析动作本身可能走错路径或泄漏 DNS，必要时加 no-resolve 强制只对已是 IP 的连接生效。

H3：分应用代理（Android VpnService）和全局路由是什么关系？会不会互相冲突？

Android 上 Shadowrocket 类客户端通过 VpnService 建立虚拟网卡，addAllowedApplication / addDisallowedApplication 决定哪些 App 的流量进 VPN。这是 进程级 的开关，发生在流量进入代理栈之前；而全局路由（规则分流）是 连接级 的决策，发生在流量进入代理栈之后。两者是串联关系，不冲突：一个 App 若被排除在 VPN 外，它的流量根本不经过规则引擎；若被包含，则再按 DOMAIN/IP 规则决定走代理还是直连。常见误区是“我在分应用里选了某 App，又在规则里给它写了 DIRECT”，结果该 App 流量进了 VPN 又被判直连，多绕一层虚拟网卡，反而增加延迟。正确做法是：要么在分应用层排除，要么在规则层直连，二选一。iOS 的 NetworkExtension 不提供同等粒度的分应用控制，只能靠规则分流近似实现。