KLP 是 Kuaaaalian Link Protocol 的缩写。从 2024 年的 v1.0 到现在的 v3.0，经历了三次重大重构。每一代协议的核心目标都是同一个：让跨境长距离连接既快又稳。

v1.0 是单连接单通道，本质上跟 WireGuard / OpenVPN 没区别。v2.0 引入了多路并发，单连接拆 2-3 通道，已经能看出效果。v3.0 把通道数提升到 4-8 个，结合 BBR v3 拥塞控制算法与每 60 秒一次的智能路由测速，整体性能有了质变。

核心创新：单连接多路径并发

传统 VPN 协议（WireGuard、OpenVPN、IPSec）都是「单连接单通道」。一个 TCP/UDP 连接走一条路径，丢包就重传这条连接的全部数据。问题是跨境网络经常有局部丢包，但其它路径是好的，传统协议用不到那些好路径。

KLPv3 把单个逻辑连接在客户端拆成 4-8 个子通道，每个子通道走不同的物理路径（不同 ISP、不同骨干节点）。任意 1-2 个子通道丢包时，其它子通道不受影响。客户端按子通道的实时测速结果动态调整每个通道承载的流量比例。

举个具体例子：从上海到洛杉矶，传统协议只用一条太平洋海缆，假设丢包率 5%，重传率 5%，实际有效吞吐只有理论值的 90%。KLPv3 同时用太平洋海缆 A、B、C 三条 + 经东京中转的亚洲海缆 + 经新加坡中转的南中国海海缆，5 条路径中可能 3 条好 2 条差，动态把更多流量分配到好路径上，最终有效吞吐可以到理论值的 95%+。

BBR v3 拥塞控制

BBR（Bandwidth Bottleneck and Round-trip propagation time）是 Google 在 2016 年开源的拥塞控制算法，颠覆了传统「丢包即降速」的 cubic 算法。BBR 通过主动测量瓶颈带宽与往返延迟，估算最优发包速率，避免触发拥塞丢包。

v3 是 BBR 的最新修订版，主要改进是在高 RTT（往返延迟 > 200ms）场景下表现更稳定。我们的实测数据显示，跨境长距离（延迟 > 150ms）场景下，BBR v3 比 v2 平均再提速 12%-18%。

实测数据

测试环境：上海电信 1Gbps 家宽 → 快连香港节点 → 远端 AWS Tokyo 区域。远端服务器 8 核 16G，测试工具 iperf3，每个协议测 10 次取中位数。

WireGuard：吞吐 78Mbps，延迟 142ms，丢包 0.8%。
OpenVPN (UDP)：吞吐 65Mbps，延迟 168ms，丢包 1.2%。
KLPv3（v4.1.0）：吞吐 128Mbps，延迟 118ms，丢包 0.3%。
KLPv3（v4.2.1）：吞吐 142Mbps，延迟 105ms，丢包 0.2%。

对比结论：KLPv3 比 WireGuard 提速 64%，比 OpenVPN 提速 96%。延迟与丢包也更优。这只是其中一个测试场景，我们跑了 7 种不同网络环境，结论一致。

什么时候不该用 KLPv3？

KLPv3 不是万能的。在以下场景下表现不如 WireGuard：
第一，极短距离（延迟 < 30ms）场景，例如同城市内节点，KLPv3 多路并发的开销大于收益；
第二，对延迟极度敏感的游戏场景（FPS、格斗），KLPv3 额外的多通道调度会引入 5-10ms 抖动，WireGuard 的稳定低延迟更合适；
第三，被精准识别为 KLPv3 流量并被 QoS 限速时，需要切到 HTTP/2 伪装协议绕开识别。
快连客户端默认 KLPv3，但遇到上述场景会自动切到备用协议，无需手动干预。

手动切换与配置

设置 → 连接 → 传输协议，可以手动选择 KLPv3 / WireGuard / OpenVPN / HTTP/2 伪装中的任意一个。普通用户建议保持默认 KLPv3，遇到问题再切换。具体配置步骤见 安装使用教程 第三章「协议选择与切换」。

协议自适配机制

v4.2.0 之后引入了「协议自适配」：客户端会持续监测当前协议的可用性。当 KLPv3 在当前网络下出现连续失败（如精准 QoS 限速），客户端会自动切换到 HTTP/2 伪装，用户无感知。这是基于 KLPv3 失败时的错误码做判断的智能切换，比手动选择更及时。

详细技术细节可以参考 更新日志 中 v4.1.0 与 v4.2.0 的 changelog 条目。