插图来源：Storyset
如果你用过 Shadowsocks，一定在配置里见过"加密方式"这一栏：一串像 aes-256-gcm、chacha20-ietf-poly1305 的字符。新手往往是随便选一个能连上的，但这串字符背后是一段 SS 协议的安全演变史，理解它能帮你避开很多坑。
起点：简单直接的流加密#
早期的 SS 用的主要是流加密（stream cipher），比如 rc4、aes-256-cfb。思路很朴素：拿密码生成一串密钥流，和数据做异或，完事。优点是快、实现简单，在当年够用。
但流加密有个致命弱点：没有完整性校验。攻击者可以篡改加密后的数据，接收方解密出来是错的，但发现不了被改过。更严重的是，某些流加密模式下，通过观察和重放流量能逐步推导出信息。这在今天看是不可接受的。
转折：AEAD 登场#
AEAD（带关联数据的认证加密）一次性解决两个问题：加密 + 防篡改。每个数据包都带一个"认证标签"，收到后先验货：被改过的包直接丢弃，根本不解密。
SS 生态现在主流的 AEAD 加密：
- aes-256-gcm：有硬件加速（AES-NI）的设备上最快，电脑、VPS 首选。
- chacha20-ietf-poly1305：没有硬件加速的设备（很多手机、路由器）上表现更好，纯软件实现也很快。
- aes-128-gcm：128 位版本，速度和安全性平衡，日常够用。
选择逻辑很简单：设备支持硬件加速用 aes 系列，否则用 chacha20。选错了也能连，只是 CPU 占用高一点、速度打点折。
为什么旧加密方式被淘汰了#
三句话总结：
- 安全上不够：流加密无完整性校验，在主动探测面前很脆弱。
- 特征明显：旧加密的流量模式更容易被识别和针对。
- 生态已迁移：主流客户端的新版本默认只提供 AEAD 选项，老加密方式逐渐被移除，继续用旧的会遇到兼容问题。
如果你还在用很老的 SS 订阅（加密方式是 aes-256-cfb 之类），建议联系机场问问有没有 AEAD 的节点，或者考虑换到更现代的协议。SS 协议本身的现状分析见Shadowsocks 协议详解。
现在订阅里看到加密方式，怎么看#
- 看到
*-gcm或*poly1305结尾：这是 AEAD，放心用。 - 看到
cfb、ctr结尾或 rc4：这是老旧流加密，能换就换。 - 看到完全没听过的名字：先别用，去官方文档查一下，警惕山寨加密。
一点历史注脚#
SS 的作者当年设计时就强调"轻量"，AEAD 化是社区在实践中打磨出来的。它的兄弟 SSR（ShadowsocksR）走了另一条路——加混淆插件对抗识别，但协议本身停滞，最终被时代淘汰，这段历史见SSR 的兴衰。而 SS 本体靠着 AEAD 化，至今仍在很多轻量场景活着，也算是一种生命力。
同样在聊"老协议现在怎么样"的，还有OpenVPN 的现状，可以对照看。