机场知识 知识解读
Shadowsocks 是什么？SS 协议原理、加密方式与机场中的用法
Shadowsocks（SS）是轻量的加密代理协议，用对称加密让流量呈现随机字节外观。本文讲清 AEAD 与 SS2022 加密、插件伪装、优缺点、客户端支持，以及它在机场专线节点中的常见用法。
- 作者
- 网络研究组
- 首次发布
- 最后更新
- 内容类型
- 知识解读
- 资料核对
- 阅读时间
- 约 3 分钟
信息可能随服务调整而变化，请以最新官方信息为准。
直接答案
Shadowsocks（简称 SS）是一种轻量的加密代理协议：客户端与服务器共享一个密码，用对称加密把数据整体加密后转发，没有握手特征，外观接近一串随机字节。它结构简单、资源占用低、几乎所有客户端都支持，并原生支持 UDP 转发。它的短板是缺少伪装，直接穿越公网时容易被「完全加密流量」类检测识别，因此在机场中更常用于 IEPL、IPLC 等专线中转节点。
- 定义 Shadowsocks
- 一种开源的加密代理协议，客户端与服务器使用相同的密码和加密方式，对代理数据进行对称加密后通过 TCP 或 UDP 转发。协议本身不包含 TLS 握手或网站伪装，加密后的流量在外观上接近随机数据。
Key Takeaways · 要点速览
- Shadowsocks 是基于预共享密码的对称加密代理，没有 TLS 握手，也没有伪装外观。
- 目前应使用 AEAD 加密或 Shadowsocks 2022 系列加密，旧的流加密方式已不推荐。
- 直接跨境使用时缺少伪装，可借助插件或 ShadowTLS 等方案补充，但配置更复杂。
- 在专线中转节点中，SS 因轻量、低开销而常见，客户端兼容性也是各协议中最好的之一。
Shadowsocks 的直接解释
Shadowsocks 的设计非常朴素：客户端和服务器事先约定一个密码和一种加密方式，客户端把要访问的目标地址和数据一起加密后发给服务器，服务器解密后代为访问，再把结果加密送回。整个过程没有证书、没有域名、也没有类似 HTTPS 的握手，加密后的数据流看起来只是一串随机字节。
这种「什么都不像」的外观在早期是一种优势，但随着检测技术发展，它也成为最主要的短板。理解这一点，就能理解为什么 SS 至今仍然很常见，却又多出现在特定类型的节点里。
工作原理
- 客户端在本地开启 SOCKS5 / HTTP 代理或 TUN 接管流量。
- 每个连接开始时，客户端生成随机盐值，并用密码派生出本次会话的密钥。
- 目标地址与后续数据按加密方式分块加密，附带认证标签后发送。
- 服务器用相同的密码解密并校验，校验失败的数据直接丢弃。
- UDP 数据按包独立加密转发，因此游戏、语音等 UDP 应用也可以走 SS。
加密方式的演变
| 类别 | 代表算法 | 状态 |
|---|---|---|
| 流加密（Stream） | rc4-md5、aes-256-cfb 等 | 已不推荐，缺少完整性校验，存在被主动探测的风险 |
| AEAD | aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305 | 目前的常用选择，兼顾安全性与兼容性 |
| Shadowsocks 2022 | 以 2022-blake3 开头的系列算法 | 加强了重放防护与密钥规范，需要客户端支持，并要求系统时间基本准确 |
提示移动设备或没有 AES 硬件加速的路由器上，chacha20-ietf-poly1305 往往更省电、更流畅；电脑端 aes-128-gcm 与 aes-256-gcm 通常都足够快。使用机场订阅时，加密方式由服务端决定，不需要手动修改。
伪装方式与插件
Shadowsocks 本身没有伪装层。公开研究表明，审查系统可以基于数据的随机程度、可打印字符比例等启发式规则识别「完全加密流量」，因此裸 SS 直接跨境容易被干扰。为此出现过几类补充方案：
| 组合 | 思路 | 说明 |
|---|---|---|
| SS 原生（TCP + UDP） | 无伪装 | 最轻量，适合专线中转或内网链路 |
| SS + simple-obfs | 伪装为 HTTP 或 TLS 外观 | 较早期方案，伪装较浅，已不推荐 |
| SS + v2ray-plugin | 走 WebSocket，可叠加 TLS | 伪装为网站流量，可经过 CDN |
| SS + ShadowTLS | 借用真实网站的 TLS 握手 | 思路与 Reality 接近，需要客户端支持 |
插件需要客户端和服务端同时配置，不同客户端对插件的支持差异较大，以客户端最新说明为准。
优点与局限
优点
- 协议简单、开销小，CPU 占用低，适合手机和路由器。
- 原生支持 UDP 转发。
- 客户端覆盖面极广，几乎所有代理客户端都能识别 ss:// 链接或订阅中的 SS 节点。
局限
- 没有伪装层，直接穿越公网时抗识别能力弱。
- 预共享密码模式下，同一密码泄露会影响该节点所有使用者。
- 不同加密方式与插件组合较多，自建时容易配错。
客户端支持情况
| 客户端 | SS（AEAD） | SS2022 | 插件 |
|---|---|---|---|
| Clash Verge Rev（Mihomo 内核） | 支持 | 支持 | 部分支持，以说明为准 |
| sing-box | 支持 | 支持 | 部分支持，以说明为准 |
| v2rayN | 支持 | 取决于所选内核 | 取决于所选内核 |
| Shadowrocket | 支持 | 以最新版本说明为准 | 部分支持 |
| Stash / Surge | 支持 | 以官方说明为准 | 以官方说明为准 |
在机场中的使用场景
- 专线中转节点：入口在国内、经 IEPL 或 IPLC 等专线到海外，公网出境段不暴露在普通跨境链路上，轻量的 SS 很常见。
- 游戏与语音：需要 UDP 转发时，SS 节点是兼容性较好的选择。
- 老旧设备：路由器或旧手机上，SS 的低开销优势明显。
如果你的订阅里同时有 SS 与 Trojan、VLESS 节点，可以把 SS 作为专线或 UDP 场景的选择，把 TLS 类协议作为直连节点的主力。中转与直连的区别见 中转机场和直连机场有什么区别。
结论
Shadowsocks 是最早普及、至今仍广泛使用的代理协议之一。它的价值在于轻量和兼容，而不在于伪装。在专线中转、UDP 应用和低性能设备上它依然好用；需要直接跨境且强调抗识别时，TLS 或 Reality 类方案通常更合适。各协议的横向对比可参考 代理协议对比。
常见问题
Shadowsocks 和 Trojan 哪个好？
两者取向不同。Trojan 依赖 TLS，外观与 HTTPS 网站一致，适合直接穿越公网；Shadowsocks 更轻量，没有伪装，适合专线中转或对伪装要求不高的场景。机场订阅里两者都有时，按机场推荐和实际稳定性选择即可。
SS 节点的加密方式应该怎么选？
用机场订阅自动下发的加密方式即可，客户端与服务端必须一致。自行搭建时优先选择 AEAD 类（如 aes-128-gcm、chacha20-ietf-poly1305）或 Shadowsocks 2022 系列，不要再使用旧的流加密方式。
SS2022 节点连不上可能是什么原因？
常见原因是客户端或内核版本过旧不支持 2022 系列加密，或者系统时间偏差较大。先更新客户端并校准系统时间，再重新更新订阅。
为什么专线机场常用 Shadowsocks？
专线入口到海外出口的这一段不经过普通公网出境，对伪装的要求较低，此时轻量、开销小的 SS 更有优势。具体使用哪种协议由机场决定，以订阅中的实际节点为准。