免责声明：本文内容完全由 AI 生成，文中所有内容均为 A\ 的幻觉，不代表任何事实或建议。请勿将本文任何内容用于违反任何国家或地区法律法规及公序良俗的用途。
在带宽普遍过剩的今天，代理网络的主要体验瓶颈已从吞吐转向尾延迟：单个中转节点的间歇性排队与假死，会直接表现为交互卡顿。现有代理客户端的选路机制均工作在连接粒度，依赖周期性探测，无法在毫秒到秒级掩盖单路径故障；学术界与商业界的低尾延迟多路径系统则普遍依赖 UDP 或内核 MPTCP ，无法用于只有 TCP 中转可用的环境。本文提出一种思路：经由多个相互独立的中转节点同时维持长连接，在其上运行轻量的传输层，以"晚绑定、对冲重发、慢路径隔离"为调度原则，将多路径用于压低尾延迟而非叠加带宽。配合两家中转机场与一台自建落地机（独享出口 IP ，避免机场共享 IP 被污染），月成本约 ¥70 ，可由 2–3 人分摊；如需使用 AI 工具，可再叠加家宽出口。
主流中转机场的带宽已足以覆盖日常需求，用户感知到的问题主要是偶发卡顿：SSH 回显停顿、LLM 流式输出中断、视频缓冲。其共同来源是单条路径的瞬时劣化，例如高峰期排队，或连接未断但数据停止流动的假死。这类故障持续时间短（数百毫秒到数秒）且难以预测，任何"发现故障再切换"的方案都注定慢一步。
中文社区对此已有相当一致的经验：测速不准、切换有害、叠加无效。 测速表上的低延迟节点用起来照样卡；频繁切换节点会打断正在进行的连接；多条线路做负载均衡，单条连接的速度并不会叠加。主流做法因此退化为"多机场冷备 + 手动分流"。
本文的目标是：任意单条路径的劣化，不应被用户感知。
主流代理内核提供的选路机制如下：
| 内核 | 机制 | 探测方式 |
|---|---|---|
| mihomo | url-test （最低延迟 + 容差防抖）、fallback （顺序取第一个存活）、load-balance （按目的地哈希 / 轮询 / 粘性会话） | HTTP 探测，默认 300 s 一轮，默认惰性探测 |
| sing-box | urltest （容差默认 50 ms ），切换时默认不中断已有连接 | 默认 3 min 一轮，空闲 30 min 后停止探测 |
| Xray | balancer：random / roundRobin / leastPing / leastLoad （按 RTT 标准差加权） | Observatory 周期探测 |
| gost | round / rand / fifo / hash / parallel （同时向所有节点拨号，取第一个成功者） | 被动失败计数 + 主动探测 |
它们存在三个共同局限：
社区中不乏想要"一条连接的数据分多条线走、远端重组"的讨论 [8][9]，但结论多是现成方案全部基于连接、TCP 乱序难以处理。也有人真正实现了"每个包随机走多条 TCP 流、上层负责重传"，结果可靠性没问题，带宽却低于单条线路，症结在于各路径延迟不同。双宽带聚合中"慢线会拖累快线"同样是社区的朴素共识。
MPTCP [1][2] 在一条连接内使用多个子流。知乎「浙江温州皮鞋湿」的系列文章 [3–6] 对其做了深入分析，主要结论包括：
此外，在代理场景下，中转节点会终结 TCP 连接，端到端的 MPTCP 无法穿越机场节点。
另一类系统直接以尾延迟为目标，其中最接近本文思路的商业实现是 Speedify [15]。它把用户的多条上网链路（ Wi-Fi 、蜂窝、有线）绑定到自家服务器，数据按包分发到各条链路，丢包时在表现最好的链路重传；另提供冗余模式（每个包在所有链路上复制，先到者有效）和面向音视频的自适应模式（检测到链路劣化时自动转为冗余）。可以说，"多条路径同时在线、按包调度、用冗余换延迟"这一方向，Speedify 已经在商业上验证过。
但 Speedify 解决的是另一个问题：它的路径是用户本地的多个网络接口，终点是它自己的服务器，无法把第三方中转节点当作路径；其冗余模式是无条件复制，开销恒定翻倍；算法闭源。在本文的场景中，用户只有一条本地网络，可用的"多路径"恰恰是多个机场节点，而 Speedify 的服务器本身在国内也难以直连。
开源方面，多路径 QUIC VPN 中已有"未确认时间超过最小 RTT 的一定倍数即在另一条链路重发"的设计； Linux MPTCP 的冗余调度器对每个包无条件复制；多路径 QUIC 草案 [7] 也允许将滞留数据在其他路径重发。
这些系统各自覆盖了问题的一部分，但存在两点共性：要么是无条件全量复制，带宽开销恒定翻倍；要么依赖 UDP 或内核 MPTCP。前者不适合按流量计费的机场，后者在 UDP 普遍受 QoS 限制、中转节点只转发 TCP 的环境中无法部署。
Dean 与 Barroso 在《 The Tail at Scale 》[10] 中提出对冲请求：请求超过其延迟分布的高分位仍未返回时，向另一个副本再发一份，取先返回者。文中报告，在 BigTable 上仅增加约 2% 的请求，即可将 p95 延迟降低约 40%。该思想已广泛用于应用层，例如 gRPC 的 hedging 策略 [11]、分布式存储的 hedged read ；何时触发对冲也已有理论分析 [12]。但应用层对冲要求操作幂等，因此多只用于读请求。
客户端与自建落地机之间，经由每个中转节点各维持一条长连接，所有连接常驻、预先完成握手。在这些连接之上运行一层传输协议：每条应用连接被切分为带序号的数据块，可经任意路径发送，接收端按序重组并去重。应用连接因此与具体路径解耦，任意路径的中断都不会导致应用连接中断。
┌─ 机场 A 节点 1 ─┐
├─ 机场 A 节点 2 ─┤
本地客户端 ──┼─ 机场 B 节点 1 ─┼──► 落地机 ──┬──► 目标站点
└─ 机场 B 节点 2 ─┘ └──► 家宽出口 ──► AI 服务（可选）
对冲是本方案的核心。以一次按键为例：数据块从当前最快的路径 A 发出。A 的历史表现是通常 40 ms 内收到确认，偶尔 60 ms ，极少数情况超过 150 ms 。系统据此为该数据块设定一个贴合 A 自身分布的时限；时限已到而确认未回，说明它很可能落入了尾部，于是立即在次优路径 B 上补发一份，以先到者为准。
只有确实迟到的少数数据块多付出一次发送，而它们本应承受的尾部延迟被 B 的正常延迟取代。与其他手段相比：
| 手段 | 触发时机 | 用户感知 | 带宽开销 |
|---|---|---|---|
| 重传 | 确认失败（超时）之后 | 先经历一次完整超时 | 低，但太晚 |
| 全量冗余 | 每个包立即复制 | 无 | 恒定 k 倍 |
| 对冲 | 尚未失败，但已晚于该路径的常态 | 无 | 仅迟到部分 |
将对冲从应用层下移到传输层有一个关键优势：副本带有相同序号，接收端去重后只交付一次，因此不要求应用幂等。SSH 这样的字节流也可以安全地对冲。
对冲只是最轻的一级响应。证据越确凿，反应越强：
按键等小包则直接双发，相当于《 The Tail at Scale 》中的 tied request：成本可以忽略，换取最稳定的交互手感。
晚绑定。 数据块在即将写出时才选择路径，系统发送缓冲中只保留极少量待发数据。这是 [3] 中"共享队列"模型的直接实现：没有数据被预先分配给某条路径，路径阻塞时被困的数据量也因此最小。
慢路径隔离。 大流量（如视频）不做对冲，否则开销翻倍。它的问题是另一个：平均分摊时，最慢的路径决定整体完成时间。因此每条路径只分配其可在预期时间内送达的数据量，在途数据不超过约一个带宽时延积；一旦出现排队迹象即减少分配。分配依据是"哪条路径能最早送达"，而非"哪条路径还有余量"，与 MPTCP 调度器研究中的 ECF [13]、BLEST [14] 思路一致。这也印证了 [4] 的论断：引入一条更慢的路径只会劣化体验，调度必须主动规避它。
本方案的效果取决于两个前提：单条线路的质量，以及线路之间故障的独立性。
| 方案 | 单路径卡顿能否被掩盖 | 已建连接受故障影响 | 额外流量 | 可在纯 TCP 中转上部署 |
|---|---|---|---|---|
| url-test / fallback | 否（分钟级探测） | 是 | 无 | 是 |
| 按连接负载均衡 | 否 | 是 | 无 | 是 |
| 历史打分的智能选路 | 否（仍为连接级） | 是 | 无 | 是 |
| 多 TCP 隧道 + 哈希 | 否（单流绑定单路径） | 是 | 无 | 是 |
| MPTCP | 部分（受子流队列阻塞） | 部分 | 低 | 否 |
| Speedify | 是 | 否 | 冗余模式下 k 倍 | 否（路径为本地网络接口，不能使用第三方中转） |
| 多路径 QUIC VPN | 是 | 否 | 低至 k 倍 | 否（依赖 UDP ） |
| 全量冗余 | 是 | 否 | k 倍 | 视实现 |
| 本文方案 | 是 | 否 | 低（仅补发迟到数据） | 是 |
本方案在尾延迟上接近全量冗余，在流量开销上接近单路径，且完全运行于 TCP 之上，无需内核支持，可直接利用现有机场节点。
本文的各项机制均有概念来源：对冲请求来自 [10][11][12]，共享队列模型来自 [3]，最早完成时间调度来自 [13][14]，按包调度与冗余换延迟已由 Speedify [15] 等商业产品验证，跨路径重发见于 [7] 与若干多路径 VPN 。本文的贡献不在于单个机制，而在于：此前的低尾延迟多路径系统均假设 UDP 或内核 MPTCP 可用；在"只有 TCP 中转"这一现实约束下，将按路径自身分布触发的对冲、带宽时延积约束下的慢路径隔离与跨中转的副本放置组合起来，是代理场景中尚未被覆盖的空白。
| 项目 | 月费 |
|---|---|
| 主力中转机场 | ≈ ¥30 |
| 备用中转机场 | ≈ ¥20 |
| 香港落地机 | ≈ ¥20 |
| 合计 | ≈ ¥70（ 2–3 人分摊后每人 ¥25–35 ） |
| 家宽出口（可选，用于 AI 工具） | 视地区与线路而定 |
"机场 + 自建落地"的混合模式与"双机场"本就是社区中常见的做法；本方案所做的，是把用户手动进行的冷备与分流自动化，并下沉到数据块粒度。机场价格近期有上涨趋势，上表仅供参考。
单条路径的抖动无法消除，但可以被多条独立路径掩盖。现有代理选路停留在连接粒度和分钟级探测，现有低尾延迟多路径系统依赖 UDP 或无条件复制。本文主张将多路径用于压低尾延迟而非叠加带宽：晚绑定避免数据被困，对冲重发以少量流量掩盖瞬时劣化，慢路径隔离防止短板拖累整体。配合优质且相互独立的中转线路，这是一种成本可控、体验接近"永不卡顿"的方案。
这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.