k2v5 协议架构
k2v5 是 k2 协议族的当前版本，采用客户端-服务端架构。URL 格式、三层身份体系、ECH 配置派生、证书固定、TLS 记录填充、QUIC+TCP-WS 双栈传输、端口跳跃、服务端 ECH 路由。
k2v5 协议架构
k2v5 是 k2 协议族的当前版本，采用客户端-服务端架构。所有 Kaitu 客户端和 k2 命令行工具默认使用 k2v5——连接 URL 以 k2v5:// 开头。
k2v5 使用 k2cc 作为拥塞控制层。未来的 k2v6 将采用 P2P 架构，同样使用 k2cc。关于 k2cc 自适应速率控制算法的详细介绍，请参阅 k2cc 自适应速率控制。
关于隐身伪装机制的详细分析，请参阅 隐身伪装技术。
k2v5 URL 格式
k2v5 将所有连接参数编码到单个 URL 中：
k2v5://USERNAME:PASSWORD@HOST:PORT?ech=ECH_CONFIG&pin=sha256:CERT_HASH&fp=FINGERPRINT&hop=PORT_RANGE
| 参数 | 说明 | 示例 |
|---|---|---|
USERNAME | 用户名 | abc123 |
PASSWORD | 认证密码 | tok456 |
HOST | 服务端 IP 或域名 | 203.0.113.5 |
PORT | 服务端端口（通常 443） | 443 |
ech | Base64 编码的 ECH 配置 | AEX0... |
pin | 服务端证书的 SHA-256 哈希 | sha256:abc... |
fp | TLS 指纹类型（chrome/firefox/safari/random） | chrome |
hop | UDP 端口跳跃范围（可选） | 10000-20000 |
三层身份体系
k2v5 连接过程中存在三层可观测的身份信息：
层级 明文可见 内容
─────────────────────────────────────────────────────────
1. TCP 目标 是 服务端真实 IP 地址
2. 外层 SNI 是 某主流 CDN 公共域名（ECH public_name）
3. 内层 SNI 否 k2 服务端域名（被 ECH 加密）
网络旁观者（ISP、GFW）只能看到第 1 层和第 2 层。第 3 层被 ECH 完整加密，无法在不持有 ECH 私钥的情况下解密。
ECH 配置派生
k2s 生成的 ECH 配置从某主流 CDN 的真实 ECH 配置派生：
- 查询该 CDN 公共域名的 DNS HTTPS 记录，获取 ECH 配置模板
- 复制
cipher_suites、kem_id、public_name等字段 - 递增
config_id（避免与真实配置冲突） - 替换 HPKE 公钥为 k2s 自己的公钥
结果：k2 流量的 ECH 配置与该 CDN 的真实流量在结构上无法区分。
证书与固定
k2s 使用自签名证书，不依赖任何 CA。
- 双证书设计：EC 证书 + RSA 证书，与真实 CDN 的证书多样性匹配
- 证书固定：URL 中的
pin=sha256:HASH是证书公钥的 SHA-256 哈希，客户端直接比对 - 自签名证书不出现在 Certificate Transparency（CT）日志中，避免被 CT 扫描检测
TLS 记录填充
k2s 定期（每 24 小时）从 ECH 伪装目标域名下载真实证书链，测量其 TLS Record 大小分布，并用相同的填充长度发送 TLS 握手记录。k2 握手的流量特征（数据包大小分布）与真实 CDN 的 HTTPS 流量匹配。
传输层
QUIC/H3（主传输）：基于 QUIC 的 HTTP/3 传输，原生多路复用、无队头阻塞。k2cc 算法直接控制 QUIC 的发送速率。
TCP-WebSocket（回退传输）：当 QUIC 被 UDP 封锁时自动切换。使用 smux 在单个 WebSocket 连接上实现多路复用。切换过程对应用层透明。
TransportManager 封装统一的 Dialer 接口：优先 QUIC → QUIC 失败回退 TCP-WS → 连接状态监控与自动重连。
UDP 端口跳跃
当 URL 包含 hop=START-END 参数时，k2 客户端在 QUIC 传输中随机选择端口范围内的 UDP 端口，定期更换，对抗基于固定端口的 UDP QoS 限速。
服务端 ECH 路由
k2s 在接收 TLS 连接时检查 ClientHello：
- 有 ECH 扩展：解密 ECH，验证身份，进入 k2v5 隧道处理
- 无 ECH 扩展：将原始 TCP 连接透明转发到
public_name对应的真实 CDN 服务器
非 ECH 连接收到的是真实 CDN 响应，探测脚本无法区分 k2s 与真实 CDN 服务器。
常见问题
什么是 ECH？为什么 k2v5 需要它？
ECH（Encrypted Client Hello）加密 TLS 握手中的 SNI 字段，让 DPI 无法看到你连接的真实目标。这是 k2v5 隐身能力的核心——没有 ECH，GFW 可以通过明文 SNI 识别并封锁代理连接。VLESS+Reality 不支持 ECH，依赖借用真实网站证书伪装，已被学术研究证明存在可检测特征（USENIX Security 2025）。
k2v5 的"三层身份"是什么意思？
第 1 层是 TCP 目标 IP（明文，无法隐藏），第 2 层是外层 SNI（明文，伪装成主流 CDN 域名），第 3 层是内层 SNI（被 ECH 完全加密）。DPI 只能看到前两层，第 3 层需要 ECH 私钥才能解密。这意味着即使 GFW 捕获了完整的 TLS 握手，也无法得知你连接的真实服务端。
k2v5 和 k2v6 有什么区别？
k2v5 是客户端-服务端架构（当前版本），k2v6 是规划中的 P2P 架构。两者都使用 k2cc 作为拥塞控制层——k2cc 是独立算法，不绑定特定协议版本。
QUIC 被封锁了怎么办？
k2v5 内置自动回退：QUIC 被 UDP 封锁时，自动切换到 TCP-WebSocket 传输，对应用层完全透明。切换过程无需用户干预。这比 Hysteria2 更可靠——Hysteria2 只支持 QUIC，UDP 被封锁时完全无法连接。
接下来阅读：k2cc 自适应速率控制 了解拥塞控制算法，隐身伪装技术 从威胁模型角度分析对抗能力。