加密算法怎么选：AES-GCM 与 ChaCha20 的适用差异
💡 声明：本文部分链接可能包含推广代码，通过这些链接注册不会增加您的成本，但能支持我们产出更多独立评测。
发布于: 2026年 | 分类: 软件下载 | 作者: Clash冲突编辑部
客户端配置里的加密算法选项常被忽略，多数人保持默认。其实这个选择对移动设备的功耗和速度有实际影响，判断依据也很明确。
一、两种算法的设计取向不同
AES-256-GCM 是目前的行业标准，绝大多数现代 CPU 都内置了 AES 硬件加速指令（Intel/AMD 的 AES-NI，ARMv8 的加密扩展）。在有硬件支持的设备上，加密开销极低。
ChaCha20-Poly1305 由 Daniel J. Bernstein 设计，特点是纯软件实现下依然很快。它使用简单的加法、循环移位、异或运算，不依赖专用指令集。
两者的安全强度在实际使用中没有区别，都是经过充分审查的 AEAD 算法。选择依据是硬件，不是安全性。
二、判断标准：设备有没有 AES 硬件加速
规则很简单：有 AES 硬件加速就用 AES-GCM，没有就用 ChaCha20。
几乎所有 2015 年后的桌面 CPU、以及主流的 ARMv8 手机芯片都支持 AES 加速。真正需要 ChaCha20 的是：部分低端或较老的路由器 SoC、一些嵌入式设备、以及少数不带加密扩展的低功耗芯片。
在 Linux 上可以直接查看：
# x86：输出中含 aes 即支持
grep -o 'aes' /proc/cpuinfo | head -1
# ARM：查看 Features 行是否含 aes
grep Features /proc/cpuinfo | head -1OpenWrt 软路由是最需要注意的场景——不少型号的 SoC 没有 AES 加速，此时选 AES 会让 CPU 成为吞吐瓶颈。
三、其他相关提示
避免使用非 AEAD 的老算法。Shadowsocks 早期的流加密模式（如 rc4-md5、aes-256-cfb）缺少完整性校验，存在已知的主动探测与重放风险，应当避免。现在的实现基本都已默认 AEAD。
服务端与客户端必须一致。算法不匹配会直接连不上，这是配置报错的常见原因之一。
不必迷信「更高位数更安全」。AES-128-GCM 在当前和可预见的未来都是安全的，选 256 位带来的是额外开销而非实质提升。多数场景下两者都可以。