Shadowsocks 协议是什么？工作原理、优缺点与适用场景
Shadowsocks（简称 SS）是最早流行、也是目前兼容性最好的应用层代理协议：它用一段预共享密码把你的流量加密成”没有明显特征的数据流”，服务器收到后解密，再转发到你要访问的网站。
快速结论：Shadowsocks 属于应用层的代理协议，负责”客户端和服务器之间怎么加密、怎么对话”；它和传输层的 TCP/UDP、加密层的 TLS 不在同一层，别混为一谈。它默认走 TCP、自带 AEAD 加密、默认不额外套 TLS，优点是轻量、成熟、延迟低、客户端支持最广；短板是伪装性不如 Trojan、VLESS 这类基于 TLS 的协议。不熟悉”协议”这个概念，可以先读什么是代理协议。
Shadowsocks 是什么
Shadowsocks 由开发者 clowwindy 在 2012 年前后发布，设计目标是用一种”看起来普通”的加密代理绕过审查。它是一个应用层的代理协议——规定的是客户端与代理服务器之间如何加密、如何封装数据，而不管底层网络怎么传输数据包。传输那一层由 TCP、UDP 负责，两层的分工可以参考TCP、UDP 与 QUIC 的区别。正因为分工清晰、实现简单，十几年下来它几乎被所有代理客户端支持，成了机场订阅里的”标配”。
工作原理：一条自带加密的数据流
Shadowsocks 的核心可以概括成一句话：**用预共享密码派生出密钥，对流量做 AEAD 加密，形成一条没有握手特征的数据流。**具体过程是：
- 你在客户端填入服务器地址、端口和密码，密码经过密钥派生得到对称加密密钥；
- 客户端把”目标网站地址 + 你的真实数据”用 AEAD 算法（如 AES-GCM、ChaCha20-Poly1305）加密后发给服务器；
- 服务器用同一把密钥解密，读出目标地址，把数据转发出去，再把响应加密回传。
和 Trojan、VLESS 不同，Shadowsocks 没有独立的 TLS 握手，整条连接从第一个字节起就是加密的随机数据——这既是它轻量的原因，也是它伪装思路的核心：不模仿任何协议，而是”什么特征都不露”。
走 TCP 还是 UDP
默认情况下，Shadowsocks 的代理流量走 TCP；同时它支持可选的 UDP relay，用来转发游戏、部分语音以及基于 UDP 的应用流量。是否开启 UDP 转发，由机场服务端和你的客户端设置共同决定。这里要分清层次：TCP、UDP 是传输层协议，Shadowsocks 只是”跑在它们上面”的应用层协议，本身并不改变传输层的行为。
默认不依赖 TLS，这是和 Trojan 的关键区别
很多新手会问：Shadowsocks 要不要配 TLS？答案是默认不需要。它自带 AEAD 加密流，本身就不可读，不像 Trojan 协议 那样把安全完全交给 TLS 加密层。对比一下就清楚了：
Trojan／VLESS：本体几乎不加密或直接明文，必须套一层 TLS 才安全，伪装成”标准 HTTPS”；Shadowsocks：自带加密，不套 TLS，流量是”无特征随机流”。
两种思路各有取舍：TLS 系伪装成正常网站、在深度检测下更隐蔽；Shadowsocks 则胜在没有证书、域名负担，部署简单、延迟更低。
Shadowsocks 2022：把老协议补齐短板
早期的 plain SS 以及部分旧版 AEAD 加密存在**主动探测（active probing）**弱点：审查方可以主动向可疑服务器发包，通过服务器的反应判断它是不是 SS 节点。为此社区推出了 Shadowsocks 2022（SS2022），用一套更严谨的加密构造（如 2022-blake3-aes-128-gcm、2022-blake3-chacha20-poly1305）修复了这些问题：引入更强的密钥派生、会话 salt 与防重放（replay）机制，让主动探测难以奏效。截至 2026 年，shadowsocks-rust、sing-box、mihomo（Clash.Meta） 等主流实现都已支持 SS2022，机场新开的 SS 节点也大多默认用它。
加密方式怎么选
机场给你的 SS 节点会指定一种加密方式（cipher）。截至 2026 年，最推荐的是 SS2022 系列（如 2022-blake3-aes-128-gcm）；其次是传统 AEAD 里的 aes-256-gcm 与 chacha20-ietf-poly1305——手机等没有 AES 硬件加速的设备用 ChaCha20 更省电、更快，桌面等有硬件加速的设备用 AES-GCM 更快。真正要避开的是 rc4、aes-256-cfb 这类老式非 AEAD 加密，它们既不安全也容易被识别，正规机场早已不再提供。好在客户端导入订阅后一般会自动匹配加密方式，普通用户无需手动更改。
优点与局限
| 维度 | 表现 |
|---|---|
| 兼容性 | 极好，几乎所有客户端支持 |
| 延迟与开销 | 低，无 TLS 握手负担 |
| 部署成本 | 低，不需要域名和证书 |
| 抗主动探测 | 旧版弱，SS2022 已修复 |
| 深度伪装 | 一般，不如 TLS 系协议 |
一句话：Shadowsocks 是稳妥的基本盘，适合日常，但在高压封锁期不一定是最隐蔽的选择。
常见客户端与适用场景
支持 Shadowsocks 的客户端非常多：桌面端的 Clash Verge Rev、跨平台的 sing-box，以及各类基于 mihomo 内核的工具都能直接导入 SS 节点。它适合这些场景：日常刷网页、看视频、网络环境相对宽松的时段，以及追求低延迟、不想折腾证书的用户。反过来，在封锁明显加剧、需要极强伪装时，可以改用 TLS 系或 VLESS + REALITY 类节点。
机场用户该怎么理解，以及常见误区
对普通用户来说，只要记住一句话：SS 节点等于轻量稳妥的默认选项。另有两个常见误区要澄清：
- 误区一：SS 就是 VPN。 不是。VPN 在系统层接管全部流量，
Shadowsocks是应用层代理，可以按规则分流，只让部分流量走代理。 - 误区二：所有 SS 都一样。 旧版 plain SS 和
SS2022的安全性差距很大，选机场时能用 SS2022 更好。
想横向了解其他协议的思路，可以接着看 VMess 协议，了解 V2Ray 系的做法。
下一步：想知道 SS 和伪装成 HTTPS 的 Trojan 到底该怎么选，读Shadowsocks 与 Trojan 对比；想按自己的网络环境系统地挑协议，读如何选择代理协议。