单流 3.12MB/s,是这台自建节点当前跨不过去的坎:VLESS 走 TCP,受单连接吞吐与拥塞窗口塌陷双重压制。初版提案是直接给 sing-box 加 HY2 入站;本文更新记录了实地复核的转折——入站 UDP 在云防火墙就被丢弃,原方案执行不了,但复核同时发现 Tailscale 已经打通一条 123Mbps 的 UDP 直连,新方案围绕它重新设计。现有 VLESS 双路一行不动,留作回滚线。

卡顿现场:一条 3.12MB/s 的线索

上一轮体检(东京/首尔 VPS 网络体检实录)留下三组数字:VPS 单连接下载 3.12MB/s,4 并发加总 12.7MB/s(约 100Mbps),本地宽带 210Mbps。两端水管都够粗,最细的一段在中间。

iPad Pro 用 Clash 类客户端接东京/首尔节点看 YouTube 1080p,有时画面卡住不动。1080p 码率按 YouTube 官方编码规范在 5-8Mbps 区间,25Mbps 的单流理论上够。为什么还卡?

先把症状形态记下来,后面风险段会用到:同类 UDP 方案的报告里有一个很典型的故障形态,白天正常、晚高峰(20:00-23:00)断崖降速,通常指向运营商 QoS。再用已有数字拼一遍机制:101-108ms 的握手时延意味着一次丢包引发的窗口恢复动辄几百毫秒,期间单流有效吞吐可能只剩一半;YouTube 播放器的预载缓冲只有几十秒,反复的瞬时断流会直接吃空它,表现就是画面停住、转圈,十几秒后自己恢复。

视频卡顿的真正约束是短时间窗里的分片拉取速度,平均带宽仅供参考。跨境 100ms RTT 加的丢包,会让 TCP 拥塞窗口反复塌陷再爬坡,单流平均 3.12MB/s 的链路,瞬时吞吐跌到 1MB/s 以下是常态。YouTube 客户端预载缓冲耗尽,画面就停住了。4 并发能到 12.7MB/s 说明总带宽充足,缺的是把单流天花板掀掉的手段。

HY2 与 VLESS:传输层决定上限

两系协议的分野在第一层:HY2 跑 QUIC(UDP),VLESS 系跑 TCP。

HY2 的官方定位是"为劣质链路设计":QUIC 伪装成标准 HTTP/3 流量,Brutal 拥塞控制忽略丢包信号、按配置带宽强行发送。官方文档同时给了警告:带宽值填超实际值只会适得其反,导致拥塞和连接不稳,正确做法是填实测值的 80-90%。要温和可以切 BBR 或 Reno;要躲 QoS 可以叠 Salamander 混淆(把每个包打成无特征随机字节)加端口跳跃(默认 30 秒一跳,切换对上层透明)。

两系的差距可以落到一个具体参数上:100ms 往返时延。TCP 的吞吐上限约等于窗口大小除以往返时延,跨境链路丢一次包,窗口砍半再线性爬坡,恢复一圈就是几百毫秒,期间带宽空转。HY2 走 QUIC,在独立流上做多路复用,一条流丢包不牵连别的流;Brutal 再把发送节奏固定成配置带宽对应的匀速发包,丢包时还有一个可关闭的补偿机制,按丢包率略微加码来维持目标速度。翻译成使用场景:TCP 像在国道上频繁让行的货车,平均速度尚可,瞬时速度断崖;QUIC 走了专用道,按固定速度巡航。

此处可插入「Brutal 匀速发包 vs TCP 窗口塌陷」对比示意图,由发布管线生成。

VLESS 的两副面孔都建立在 TCP 上:WS 形态多套一层 Cloudflare 隧道,流量混进 CDN;REALITY 形态借真实站点的证书完成 TLS 握手,主动探测的检出率按第三方 2026 年 2 月的口径低于 0.1%。隐蔽性拉满,代价是吞吐永远受 TCP 单流窗口约束。

主对比表:

iPad 侧的客户端支持单独核对过,结论先放这里:

• Stash(mihomo 内核):HY2 完整支持,含端口跳跃与跳变间隔配置,配置文件与桌面 Clash 系互通。
• Shadowrocket:HY2 完整支持,URI 参数支持 mport 跳端口格式与 Salamander。
• Clash Verge(桌面)/ mihomo(WSL 侧):同内核,完整支持。
• Surge 5:HY2 支持滞后,官方社区里为 Brutal 提的功能请求还在跟进,用它之前先核对当前版本支持列表。

我现在的链路,差在哪

此处可插入"当前三路线链路对比示意图",由发布管线生成。

两台 VPS 完全同构,sing-box 跑两路入站:一路 VLESS+WS,只听回环地址,由 cloudflared 命名隧道回源,客户端连的是 CF 优选 IP,真 VPS IP 藏在隧道后面;另一路 VLESS+REALITY 占 443 直连,SNI 伪装某消费电子大厂官网。客户端订阅是直连 profile 的静态节点。商业机场这两年的主流组合正是 HY2 加 VLESS(REALITY),差距可以拆成三条:

第一,没有 HY2 这条腿。单流天花板的问题在 TCP 系里无解,加并发、换优选 IP 都只是把平均往上抬,卡顿吃的是瞬时。

第二,主路穿免费的 CF 隧道。这多出的不是一跳那么简单:Cloudflare 官方 FAQ(2026-09-16 更新)写得很直白,免费/Pro/Business 计划里用 public hostname 路由"服务视频和其他大文件"受服务条款限制,需使用付费的 Stream 产品。隧道本来就是给网页和 API 设计的,视频长连接在里面属于边缘用途。

第三,iPad 上 YouTube 客户端优先用 QUIC/H3 拉流,这些包再被装进 VLESS 的 TCP 隧道出境。QUIC 自带拥塞控制,TCP 隧道再叠一层,丢包时两层同时反应、互相放大,这是 QUIC-over-TCP 的经典问题,实测表现就是"平均 25Mbps、瞬时不足 8Mbps"。

实地复核:原提案的两个前提不成立(2026-09-22 更新)

初版提案假设"在 443/UDP 加 HY2 入站即可用",执行前的链路复核推翻了两个前提。这一节的每个结论都有 tcpdump 抓包佐证,方法可以复现:在 VPS 上 tcpdump -i ens5 'udp and dst port <端口>',同时从国内和对端机器各发探测包,看包是否到达网卡。

前提一:入站 UDP 全部不可达。 从国内(本机)和墙外的首尔 VPS 分别向东京节点的 443/UDP、34567/UDP、45678/UDP 发探测包,东京侧抓包结果为零——注意首尔到东京这段不经过 GFW,包依然没到,责任方锁定为 Lightsail 云防火墙(有状态过滤,在 OS 之前丢包)。ufw 放行、随机换高位端口都无效,因为丢弃发生在云层。 lightsail-rotate 这个 IAM 用户的策略只授权停止/启动实例,没有 open-instance-public-ports 权限,想从 API 改也改不了,只能走 AWS 控制台(用户没有面板习惯,且改了规则等于把 UDP 端口暴露在公网扫描下,另算一笔风险账)。

前提二:REALITY 443 直连腿是死路,不在只是"慢"。 服务本身健康——VPS 本地 openssl s_client 握手正常、sing-box 监听 0.0.0.0:443、证书伪装完整。但从国内直连:v4 地址 SYN 都到不了(GFW 拦,2026-08-30 轮换 IP 后的老问题复发);v6 地址(家用宽带有原生 2401:ce00 出口)的 443 也不通,而 v6 的 22 端口可以通——说明 v6 路径本身活着,443 被丢同样指向云防火墙的 v6 规则(只放行了 22)。也就是说,订阅里的 REALITY 备胎节点,现在拨不通。

例外:Tailscale 的 41641 是唯一活的入站 UDP。 国内 WSL 到东京 VPS 的 tailscale ping 走 v6 直连(105ms),tcpdump 能看到 41641 双向流量。这个端口能通的原因是 Tailscale 的 NAT 打洞:出口方向先建立了会话,云防火墙的有状态规则放行了回程方向的包。在这条已建立的路径上实测单流 TCP 123Mbps、UDP 约 95Mbps(iperf3,10 秒)——都数倍于现有 CF 隧道的 6.1-8.6MB/s 单流,也远超 1080p 需要的 5-8Mbps。

复核还带出一个对原文的修正:CF 隧道路径单流下载实测 6.1-8.6MB/s(50MB 文件两次),并非此前推断的 3.12MB/s——3.12 是苹果 CDN 场景的数字,场景不同。瞬时塌陷的机制判断仍然成立,但"CF 隧道单流上限 3.12"的表述下修为"场景化波动 3-8MB/s"。

证据链缩成一张表:

提案修订:HY2 藏进 Tailscale,别的全不动

原提案(HY2 直挂 443/UDP)在云防火墙面前不成立,修订后的方案分两层:传输层用 Tailscale 打好的 41641 通道,协议层仍然上 HY2。

第一层(基础,十分钟级):Tailscale exit node。 东京节点执行 tailscale up --advertise-exit-node,Tailscale 管理面板批准该节点作为 exit node;iPad 从 App Store 装 Tailscale、登同一账号、开启"Use exit node"。此后 iPad 的全部流量(含 YouTube 的 QUIC/H3 原生包)走 tailnet 到东京出网。注意两点:exit node 模式下流量是 WireGuard 加密,不叠 HY2,但实测 TCP 123Mbps 的通道对 1080p 绰绰有余;Tailscale 的 ACL 默认放行同账号设备,免费版 3 用户 100 设备的额度对个人自用无压力。风险是出口 IP 归属 AWS,高流量跑法同样受 AWS 条款约束,和现有 VLESS 一致,不是新增风险。

第二层(进阶,若第一层晚高峰被 QoS):HY2 内嵌。 在 VPS 的 sing-box 上加 HY2 入站,但不监听公网——监听 tailscale0 接口的 100.74.231.93:8443(UDP),口令与 Salamander 混淆照原提案配置。iPad 的 Stash/Shadowrocket 节点写 server: 100.74.231.93,流量先经 Tailscale 子网到达,再由 HY2 协议出境。这一层把 QUIC 的弱网吞吐优势和 Tailscale 的已验证通道叠在一起,且云防火墙完全看不到新的入站端口。前提是 Tailscale ACL 放行该端口的 tailnet 内 UDP(默认同账号全放行)。配置示意(占位符):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# VPS sing-box 新增 inbound
- type: hysteria2
  tag: hy2-in
  listen: 100.74.231.93      # tailscale0 接口,非公网
  listen_port: 8443
  users: [{ name: u0, password: <强口令> }]
  obfs: { type: salamander, password: <混淆口令> }

# iPad 客户端节点
- name: tokyo-hy2-ts
  type: hysteria2
  server: 100.74.231.93      # Tailscale IP
  port: 8443
  password: <强口令>
  obfs: salamander
  obfs-password: <混淆口令>
  up: <本地上行实测×0.85>
  down: 170 mbps

iPad 侧操作:第一层只需装 Tailscale、选 exit node;第二层在 Stash 导入更新后的订阅,策略组里把新节点排到最前。

验收标准不变:同一台 iPad、同一时段,A 路线走 Tailscale(直连或叠 HY2)、B 路线走现状 CF 隧道,各放 30 分钟同一条 1080p 视频,数转圈次数与缓冲时长。A 侧无转圈、B 侧复现卡顿,升级就算成立;两边都卡,回到上一节的判定实验,查整条链路。

预期收益:用户到 VPS 这段从"CF 边缘 TCP 隧道,单流 3-8MB/s 波动"转入"WireGuard 直连,实测 123Mbps TCP / 95Mbps UDP"。1080p 需要的 5-8Mbps 瞬时流量,余量从约 3 倍拉到 15 倍以上(基于实测,非推断)。内存省着用:tailscaled 已经在跑,sing-box 本来就常驻,新增入站估计几十 MB 量级(估计),两台机器合计仍远低于 2GB 上限。

第二条:客户端做成多路 fallback。Tailscale 直连(或 HY2)首选,CF 隧道次之,REALITY 兜底,url-test 自动切换。健康检查的 URL 选一个几 KB 的小接口就行,别拿大文件测速,否则探针自己就在抖动。REALITY 的定位需要重写:复核证明它现在拨不通,严格说连兜底都算不上——修复它要么走 AWS 控制台把 v6 的 443 放进云防火墙,要么等下一次 IP 轮换后 v4 复活再验证。在这之前,fallback 链实际是两层:第一层 Tailscale,第二层 CF 隧道。

第三条:CF 隧道侧到此为止。优选 IP 已经省了约 52ms,继续在隧道上优化边际收益很小,何况官方条款已把视频用途排除在免费 scope 之外。把隧道 transport 换成 gRPC 或 http2 能小幅改善多路复用,但改不动单流上限,CF 也从不承诺免费隧道的带宽,这条线到此为止。

第四条(观察项):播放器与客户端并发设置。YouTube 分片多请求,适当调高客户端单节点连接数能改善瞬时吞吐,收益小,列为上线后的观察项。

风险与回滚

风险一是 Tailscale 直连依赖 NAT 打洞。WSL 到东京的直连是 v6 路径建立的;iPad 在同样的家庭网络下大概率能复现,但若打洞失败会落到 DERP 中继(东京有节点,延迟可控但吞吐打折),fallback 就是 CF 隧道老路。iPad 侧验证方式:装好后看 Tailscale 连接详情是"direct connection"还是"relayed"。

风险二是晚高峰 UDP QoS。判断方法有标准 A/B:同时测 TCP 路线与 Tailscale/WireGuard 路线,若 TCP 正常而 WireGuard 降速,就是运营商 UDP QoS。命中后启用第二层 HY2(QUIC 伪装 HTTP/3 形态)再观察,仍不行就回 CF 隧道。

风险三是 Brutal 带宽填超(若启用第二层),人为制造拥塞,官方原话是宁可填低不要填高。

风险四是合规底线:AWS 条款禁止规避流量费的代理用途,自用、低调、只挂自己的设备,这是老规矩,新路线同样适用。Tailscale 的 WireGuard 加密流量形态与常见 VPN 客户端一致,不引入新的可识别特征,但这只降低被动识别的概率,使用性质不变。

回滚路径很短:Tailscale 关掉 exit node 开关(客户端一秒切回),sing-box 删掉 HY2 inbound 重启,客户端删掉对应节点,现有两路 VLESS 自始至终没有动过。

局限

Tailscale 直连 123Mbps 是 WSL 到东京的实测,iPad 的打洞形态和 WiFi 环境不同,真实数字要上机验证;晚高峰 UDP 行为因省而异,只能按上面的 A/B 当场上;REALITY 备胎的修复路径(云防火墙放行 v6:443 或等 v4 复活)没有执行,它现在是死路而非慢路;DERP 中继的吞吐上限没有实测。另外两条腿没有被替换:CF 隧道继续承担隐藏真实 IP 的职能,Tailscale 路线的出口也仍是 VPS 本身——但注意 Tailscale 客户端会暴露 tailnet 拓扑给管理面板,这不是匿名工具,自用场景无碍,介意的话把 HY2 内嵌层当主路。

最后一个数字留在原处:东京节点 4 条并发拉满时,单条下载曲线平得像是刻度尺印出来的(3,116,975 B/s)。曲线越平,说明前面排队的闸口越具体,HY2 要试的就是绕过它。

来源

• Cloudflare Tunnels FAQ(2026-09-16 更新):developers.cloudflare.com/cloudflare-one/faq/cloudflare-tunnels-faq/
• Hysteria 官方文档:完整客户端配置、端口跳跃两页(HyNetworks/hysteria)
• 《Hysteria2 自建服务器与高级配置完全指南(2026 版)》:ygjc.cc
• mihomo 官方文档 Hysteria2 配置页:wiki.metacubex.one
• VLESS-Reality vs Hysteria2 对比:greatfirewallguide.com/lab/vless-reality-vision
• 《2026 科学上网协议深度解析》:babeedu.net
• Shadowrocket vs Surge 5 对比:chonglangbiji.com