clash-verge-rev/docs/cvd-protocol-introduction.md

CVD 订阅设备绑定：让订阅链接从“拿到就能用”升级为“登记设备后才能持续更新”

CVD（Clash Verge Device-binding Protocol）是一套面向订阅服务的设备绑定与加密下发方案。

过去，一条订阅链接一旦泄露，第三方可能直接把链接粘贴到浏览器或脚本中，持续拉取最新节点。CVD 在原有订阅流程上增加了设备公钥、加密响应和设备槽位管理：服务提供方可以识别设备、限制数量、解绑旧设备，并为每台设备单独加密订阅内容。

对于普通用户，它几乎不改变使用习惯；对于服务提供方，它提供了一条可以逐步上线的安全加固路径。

这不是给订阅链接换一个外壳，也不是再增加一组所有设备共享的验证密码。简单的链接变形、固定密码或单层加密，可以增加一点复制步骤，却很难回答更关键的问题：到底是哪台设备在持续拉取订阅？已经登记了多少台设备？某一台设备是否应该被限制或解绑？

CVD 直接把这些问题纳入协议流程。每个订阅 profile 使用独立设备密钥，服务端可以按公钥识别设备，并结合槽位上限、新设备注册频率限制、解绑和过期回收进行治理。它不是让订阅“看起来更难复制”，而是从技术实现上把持续获取订阅的门槛，从“拿到链接即可请求”提高到“登记设备后才能持续更新”。

一句话理解

传统订阅链接像一把可以反复复制的门禁卡。CVD 为它增加了“设备登记”：

1. Clash Verge 为订阅生成一对设备密钥。
2. 公钥随订阅请求发送给服务端，私钥只保存在本机系统钥匙串。
3. 服务端用公钥加密订阅内容，并按设备公钥记录槽位。
4. 只有持有本机私钥的设备才能解密本次订阅响应。

服务端还可以限制每个账号允许登记的设备数，并允许用户在控制台解绑旧设备。

CVD 带来的价值

1. 提高订阅链接泄露后的滥用成本

仅拿到订阅 URL，不再等于可以用浏览器或通用 curl 持续复制明文节点。第三方必须实现 CVD 协议、登记设备并占用可见槽位，服务端也可以据此限制新设备注册频率、限制数量和吊销设备。

相比之下，共享密码只能证明“请求者知道密码”，无法区分不同设备；单纯加密订阅内容，如果缺少设备身份和服务端策略，也难以阻止泄露者反复请求。CVD 的重点不是堆叠一道验证，而是让每次持续访问都进入可识别、可计量、可治理的设备流程。

2. 每台设备独立加密下发

CVD 使用标准 HPKE（RFC 9180）方案。服务端针对设备公钥加密订阅内容，不同设备拿到的密文不同。协议采用 X25519、HKDF-SHA256，以及 ChaCha20-Poly1305 或 AES-256-GCM 等成熟算法组合。

3. 私钥留在系统钥匙串

设备私钥不会写入普通配置文件，也不会随应用备份导出。它由 macOS Keychain、Windows Credential Manager 或 Linux Secret Service 等系统能力保存。服务端只接收公钥，不接触用户私钥。

4. 平滑兼容现有订阅生态

CVD 采用渐进启用方式：

• 服务端尚未支持 CVD 时，仍可按原有明文订阅流程工作。
• 服务端支持 CVD 后，可以先灰度测试，再按套餐或用户组启用设备限制。
• 新建、导入订阅和手动更新会自动尝试登记；已登记订阅会在后续更新中复用同一设备公钥。
• 尚未登记的旧订阅不会在静默自动更新时主动创建密钥，避免系统启动时出现不必要的钥匙串授权弹窗。

5. 面向真实使用场景的自恢复设计

用户换机、重装系统或清理钥匙串后，本机私钥可能丢失。客户端会识别这种情况，并准备新的设备密钥用于后续更新。服务提供方配合提供设备解绑和过期回收后，用户可以恢复正常使用。

为什么说它更先进

CVD 没有重新发明一套私有加密算法，而是组合成熟标准与实际运营能力：

能力	CVD 的做法
设备身份	直接使用 X25519 公钥，无需额外 device_id
订阅加密	使用 RFC 9180 HPKE 标准方案
私钥保护	仅保存在操作系统钥匙串
风险控制	服务端设备槽位、新设备注册频率限制、解绑和过期回收
上线方式	兼容未改造服务端，支持灰度启用
用户体验	自动协商、复用公钥、按需访问钥匙串

它与常见轻量方案的差异，不只体现在“有没有加密”，而在于是否形成完整闭环：

方案	能解决什么	仍然缺少什么
更换或隐藏订阅链接	降低链接被随手发现的概率	链接一旦泄露，仍可持续复制和请求
增加共享验证密码	增加一道访问门槛	所有设备共享凭据，难以单独识别、限制或吊销
仅对订阅内容加密	避免直接看到明文	如果没有设备身份和槽位策略，仍难治理持续滥用
CVD 设备绑定	设备独立密钥、标准加密下发、槽位计量、新设备注册频率限制、解绑和回收	需要服务端按建议策略接入，才能发挥完整价值

这使 CVD 不只是“加一层加密”，而是把订阅分发升级为可识别、可计量、可限制、可吊销的设备级流程。它把安全能力落实到协议、客户端密钥管理和服务端运营策略三个层面，而不是停留在表面上的访问障碍。

服务提供方如何获得完整防护价值

仅返回加密响应还不够。服务端应同时实施以下策略：

1. 对受保护订阅拒绝不带 CVD 公钥的明文请求。
2. 按账号或套餐设置设备槽位上限。
3. 按账号和来源 IP 限制新公钥注册频率，防止攻击者刷满设备槽位。
4. 提供设备查看、解绑和长期未使用设备回收能力。
5. 保留 HTTPS，并确保 CDN、WAF 和反向代理透传 X-CVD-* 请求头。

完整的服务端字段、响应格式、测试向量和接入示例，请阅读 CVD 服务端集成技术文档。

需要诚实说明的边界

CVD 是安全加固方案，不是 DRM，也不承诺“订阅永远无法泄露”：

• 合法设备解密后仍能看到节点信息。
• 愿意专门开发工具的第三方仍可尝试登记设备。
• CVD 不能替代 HTTPS，也不负责解决中间人攻击、服务端投毒等问题。
• 真正的治理效果来自加密下发与服务端设备槽位、新设备注册频率限制、解绑策略的组合。

CVD 的目标很明确：让低成本、批量化、长期持续的订阅滥用变得更难，让服务提供方获得可执行的治理手段。