让难走的跨境链路"感觉像本地"

做过国内直连海外（尤其中美）的人都懂这种痛：明明带宽够，跑起来却总有一股说不出的卡顿。作者在微软亚洲研究院实习时体验过专线级别的中国直连 Google/YouTube，回国后又搭过香港绕行网关——绕行虽然改善，代价是双倍带宽成本 + 更高延迟。于是他想：能不能不绕路，直接让"难走的链路"本身变快？

Queqiao（鹊桥） 就是答案——一个把"已知的 WAN 瓶颈段"单独拿出来优化的自托管代理。

核心思路：别把每个丢包都当拥塞

传统传输协议让每条连接各自学习、各自退避，这在通用互联网是合理的，但当大量应用流共享同一条难走的客户端到网关链路时，各自的"自动退避"反而互相拖累，白白浪费性能。

Queqiao 的几个关键观察：

• 共享瓶颈就该共享模型——不同目标的流共享同一条路径，就把它们的状态（投递、丢包、RTT、步调、延迟储备）统一建模，而不是各管各的
• 不是所有丢包都是拥塞——精确测量出一个"擦除底数"（erasure floor），把独立的链路擦除和真的拥塞区分开
• 按路径选恢复策略——长 RTT 路径用前向纠错（FEC）比再等一个 RTT 更快恢复；流量上来后，重传又会更高效
• 保护交互流量——批量传输不能拖住控制面和交互请求：聚合步调、优先级、响应式隔离来保延迟
• 上下行分开管——两条方向的容量与丢包行为往往大不相同，独立测量、独立控制

怎么用？

Queqiao 在你本机呈现一个普通 SOCKS5 代理（含 UDP ASSOCIATE），客户端与网关之间是一条端到端认证的传输会话；可用时走 QUIC 流，受限网络自动回退到 TLS/TCP。应用不需要选"短流/交互/批量"协议，Queqiao 观察流量行为后在同一套架构里自适应调整。

与同类工具的对比

（六轮真实路径测试的代表性结果：大流量上 Queqiao 明显领先，但交互链路尾延迟不占优——所以它不是万能的，关键看路径。）

适合谁？

• 国内直连海外长链路（美/欧）被卡顿困扰的用户
• 已有自建网关、想进一步压榨跨境带宽的玩家
• 想把手头 Clash / mihomo 链路升级成共享路径模型的折腾党（项目带 Clash 配置示例）

适用前提：客户端与网关是已知可信端点，且共享的那段 WAN 是主要瓶颈。如果瓶颈不在这段，先测量再决定——别指望它万能。

▶ 前往 GitHub 仓库 · 133 ★