- 遇到选择困难时的第一问：我需要什么样的“安全”？
- 加密算法的三条评判轴：安全、性能、兼容
- 安全性要点（重点关注）
- 性能与硬件加速
- 兼容性与未来可维护性
- 常见算法的优劣速览
- AEAD 类（推荐）
- 旧式流密码（不推荐，除特殊场景）
- 不加密 / 混淆类
- 实际案例：如何为典型部署选型
- 落地操作步骤（文字版）
- 容易忽略但很重要的几点
- 结论式建议（便于速查）
遇到选择困难时的第一问：我需要什么样的“安全”？
在部署 V2Ray 或者切换传输协议时，选择加密算法往往被当成一个技术细节忽略掉。但实际上，算法的不同直接影响到连接安全性、延迟/吞吐、以及在各种终端和中间设备上的兼容性。先明确三个核心需求：机密性（抗被动监听）、完整性与抗篡改、以及性能（CPU 与延迟），再去挑选算法会更高效。
加密算法的三条评判轴：安全、性能、兼容
把候选算法放到这三条轴上评估：安全——是否抵抗已知密码学攻击、是否支持 AEAD 和前向保密；性能——在无 AES-NI 的设备上是否友好、对多核的利用情况；兼容——客户端/服务端支持度、与中间设备（深度包检测、流量整形）发生冲突的概率。
安全性要点（重点关注）
优先选择支持 AEAD（Authenticated Encryption with Associated Data）的套件，例如 aes-128-gcm、aes-256-gcm、chacha20-poly1305。AEAD 能同时保证机密性和数据完整性，防止重放与篡改问题。另一个重要指标是前向保密（Forward Secrecy），这通常依赖于密钥协商协议（比如 TLS 的 ECDHE），而非对称或对称算法本身，但在评估整套方案时不可忽略。
性能与硬件加速
性能方面需要考虑服务端和客户端的 CPU 架构：在现代 x86（支持 AES-NI）服务器上，aes-*-gcm 系列通常速度很快；在 ARM 手机或一些 VPS（无 AES-NI）上，chacha20-poly1305 往往更高效且能耗更低。因此，推荐的选择并非单一最强算法，而是根据部署环境取舍。
兼容性与未来可维护性
如果你的用户来自多种设备（Windows、macOS、iOS、Android、路由器固件），优先选取主流实现都支持的算法，避免使用过时或仅少数客户端支持的模式。AEAD 已成为主流协议的默认选项，兼容性通常更好。
常见算法的优劣速览
下面按类目列出常见的几种选择，并给出实战建议。
AEAD 类（推荐）
chacha20-poly1305：在移动端和低功耗 CPU 上有优势，抗侧信道表现良好，且被现代客户端广泛支持。适合手机用户、树莓派或未开启 AES-NI 的 VPS。
aes-128-gcm / aes-256-gcm：在支持 AES-NI 的服务器上吞吐、延迟表现非常优异。安全性强，生态成熟。若服务端运行在大多数云主机（Intel/AMD）上优先使用 aes-gcm。
旧式流密码（不推荐，除特殊场景）
aes-128-cfb、aes-256-cfb 等模式属于传统流密码或分组模式，安全性和抗篡改性不如 AEAD，且容易因实现问题导致安全漏洞。仅在遗留客户端无法升级时作为临时方案。
不加密 / 混淆类
某些场景下会见到“none”或仅做混淆的实现。这类在对抗 DPI 或降低延迟时有特定用途，但不能替代加密，除非通道下方有其它安全层（如 TLS）。一般不建议用于承载敏感流量。
实际案例：如何为典型部署选型
案例一：商业 VPS（Intel CPU，用户多为桌面）——优先选择 aes-128-gcm，兼顾安全与性能，且多数客户端支持；如果追求更高安全边界，可选 aes-256-gcm，但 CPU 消耗会稍高。
案例二：移动用户或家庭低端路由器——选 chacha20-poly1305，在 ARM 架构上速度更稳定，电池与发热表现更好。
案例三：跨国中转或与审查环境对抗——在保证 AEAD 的前提下，搭配 WebSocket + TLS 或 HTTP/2 传输，利用 TLS 的协商和证书来增加隐蔽性；加密算法则跟随 TLS 的选择，客户端与服务端应优先 AEAD 和支持 ECDHE。
落地操作步骤（文字版）
1. 评估运行环境：确认服务端 CPU 是否支持 AES-NI，客户端主要设备型号。
2. 确认客户端/服务端实现支持的算法列表，避免使用彼此不兼容的选项。
3. 优先选择 AEAD 算法：在支持 AES-NI 的服务端选 aes-128-gcm；在多为移动或 ARM 设备的场景选 chacha20-poly1305。
4. 如果对抗检测是目标，优先结合 TLS 等传输层手段，而非仅靠加密算法本身。
5. 部署后进行压力与延迟测试：关注 CPU 使用率、单连接延迟和并发吞吐。根据结果调整算法或扩展资源。
容易忽略但很重要的几点
• 密钥管理和轮换：即便使用最好的算法，长期不轮换密钥会增加被暴露的风险。
• 实现漏洞高于算法弱点：许多泄露事件来自实现错误或配置不当（比如未启用 AEAD 或重复使用 IV），而非算法本身。
• 协商与降级攻击：确保客户端与服务端协商时不被强制降级到不安全的选项。
• 测试真实网络环境：本地基准测试可能误导，真实跨国连通性、抖动和包损会显著影响体验。
结论式建议（便于速查）
如果你只需一个推荐：服务端运行在现代 x86 云主机上选 aes-128-gcm；若大量移动端或 ARM 设备则选 chacha20-poly1305。始终优先 AEAD，结合 TLS 容易获得更好的隐蔽性和中间件兼容性。
选择算法不是一次性的“配置项打钩”，而是结合部署硬件、用户终端、对抗目标和运维能力的综合决策。按需取舍、持续测试与定期审计是长期稳定、安全运行的关键。
暂无评论内容