Shadowsocks 与 VMess 对比：两种设计哲学与各自的软肋
Shadowsocks 和 VMess 常被放在一起比较，但它们解决的其实不是同一个问题。前者追求极简与高性能，后者试图构建一套完整的传输框架。理解这个出发点的差异，比记住参数表更有用。
一、Shadowsocks：把加密做对就够了
Shadowsocks 的协议本身极其简单：建立 TCP 连接，用预共享密钥加密，前面带上目标地址，然后就是纯粹的数据转发。没有握手协商，没有版本字段，没有元数据。
早期的流加密（stream cipher）模式存在可被篡改和重放的问题，现代实现已统一到 AEAD 模式（如 AES-256-GCM、ChaCha20-Poly1305），在加密的同时提供完整性校验。SIP002 规范则统一了订阅链接的格式。
它的软肋恰恰来自简洁：流量呈现为「没有任何协议特征的随机字节」。在绝大多数正常流量都有明确特征的网络里，「完全没有特征」本身就是一种特征，容易被基于熵值的检测盯上。
二、VMess：完整框架带来的复杂度
VMess 用 UUID 作为用户标识，并把时间戳纳入认证——客户端与服务端的系统时间偏差通常需要控制在 90 秒以内，否则握手失败。这是新手部署时最常见的报错来源。
早期 VMess 的 alterId 机制用于生成额外的认证 ID，但它带来了内存开销且并未真正提升安全性，现已废弃，应统一设为 0 并使用 VMessAEAD。如果你还在用 alterId 非零的旧配置，属于该更新的范畴。
VMess 的价值在于它是一套框架：可以叠加 WebSocket、gRPC、HTTP/2 等传输层，配合 TLS 和 CDN 使用，灵活度远高于 Shadowsocks。代价是协议头本身有一定开销，且实现复杂意味着更多潜在的指纹面。
三、今天该怎么选
如果链路本身不受针对性干扰，只是需要一条稳定的加密通道，Shadowsocks + AEAD 依然是开销最低、实现最成熟的选择，移动端功耗表现尤其好。
如果需要借助 CDN 中转、或者要在 443 端口上伪装成正常 Web 流量，VMess + WebSocket + TLS 的组合更合适。但要注意：VLESS 已经在很大程度上取代了 VMess——它去掉了 VMess 中冗余的加密层（既然外层已有 TLS，内层再加密是重复劳动），头部更轻、性能更好，配合 Reality 还能解决证书来源问题。新部署没有特别理由的话，优先考虑 VLESS。