主题
Shadowsocks 协议详解：轻量加密代理的原理、历史与现状
Shadowsocks（常简称 SS）是一种轻量级的加密代理协议：它在你的设备与远端服务器之间建立一条加密通道，网络请求先加密发给服务器，再由服务器代为访问目标网站并把结果传回。对普通用户而言，它就是订阅列表里最常见的「SS 节点」——诞生早、客户端支持广的一类协议，也是理解各类代理协议的合适起点。
工作原理
Shadowsocks 于 2012 年由网名 clowwindy 的开发者开源发布，2015 年作者宣布停止维护后由社区接手，衍生出多个实现并延续至今。它的设计目标非常直接：用尽量少的环节完成「加密——转发——解密」。
具体来说，客户端和服务器事先约定同一个密码与加密方式。你的设备把要访问的地址和数据用这份密钥加密后发出，服务器收到后解密、代为访问，再把结果加密传回。协议层没有复杂的握手协商，这也是它轻量的来源。
早期 Shadowsocks 使用流加密，后来被更安全的 AEAD 加密取代。AEAD（带关联数据的认证加密）可以通俗理解为「加密的同时自带防伪校验」：每段密文都附带校验信息，传输中被篡改或伪造都会被发现。目前主流的 AES-GCM、ChaCha20-Poly1305 都属于这一类；2022 年发布的新版规范（节点参数常标注为 2022-blake3 系列）进一步改进了抗重放与抗探测设计。
主要特点
- 性能：协议开销很小，没有多余的握手环节，对设备性能要求低，旧手机、路由器也能流畅运行，速度上限主要取决于线路本身。
- 伪装性：Shadowsocks 不模仿任何常见协议，密文在外界看来是一段高熵的随机数据流。围绕这一点存在长期讨论：一种观点认为随机流没有明显指纹，另一种观点指出「完全随机」本身在统计上就可能成为特征，配合主动探测存在被识别的可能。新版规范针对主动探测做了改进，但在网络环境敏感的时期，它的稳定性通常不如带 TLS 伪装的协议，例如 Trojan。
- 生态支持：作为资历最老的主流协议之一，它的客户端覆盖面广，各平台都有成熟实现，机场普遍把 SS 作为基础节点类型提供。
适用场景与不适用场景
适合：日常浏览、视频等常规使用；需要在路由器、旧设备等性能有限的环境运行；希望配置尽量简单、兼容面尽量广的用户。
不太适合：所在网络对代理流量干扰较强、SS 节点频繁异常的时期——此时可优先尝试同一订阅里的 Trojan 或 VLESS 节点；以及对流量伪装有较高要求的场景。
客户端支持情况
Shadowsocks 是兼容性包袱最小的协议之一：Clash/Mihomo 内核完整支持包括 2022 系列在内的主流加密方式，Windows 用户可参考 Clash Verge 教程上手；iOS 的 Shadowrocket 以 SS 客户端起家，支持自然完善；sing-box、v2rayN 也都内置支持。如果一家机场的订阅连 SS 节点都无法正常使用，问题多半出在订阅环节，可按订阅导入失败排查处理。挑选兼容 Clash 生态的服务可参考这份指南。
常见误区
- 「Shadowsocks 就是 VPN」：两者目标相近但机制不同。VPN 通常在系统层接管全部流量，SS 本质是加密代理，配合客户端规则按需分流，更灵活，但也意味着不走代理设置的个别软件流量不会经过它。
- 「SS 已经过时，不能再用了」：它仍是机场提供最普遍的协议之一，在多数网络环境下表现正常。所谓「过时」主要指伪装能力弱于新协议，而不是无法使用。
- 「加密方式越复杂越安全，也越慢」：在现代设备上，AEAD 加密的性能开销可以忽略，速度瓶颈通常在线路而非加密算法，为「快」刻意选弱加密没有意义。
FAQ
SS 和 SSR 是什么关系？ SSR（ShadowsocksR）是 2015 年前后出现的社区分支，增加了混淆功能，但项目早已停止维护，加密设计也落后于现行 AEAD 标准。目前生态已回归 Shadowsocks 本体与更新的协议，新订阅里 SSR 节点已不多见。
加密方式和密码需要自己设置吗？ 不需要。机场订阅里已包含每个节点的完整参数，客户端导入后自动应用，用户无需手动干预。
用 SS 节点，运营商能看到我访问了什么吗？ 传输内容经过加密，中间网络无法直接看到你访问的具体网站与内容；但代理服务器的运营方在技术上可以看到流量去向，因此服务商的隐私政策值得关注，详见无日志与隐私政策辨析。
节点名带「2022」是什么意思？ 指该节点使用 Shadowsocks 2022 版规范（如 2022-blake3-aes-128-gcm），需要较新的客户端内核；老版本客户端导入失败时，升级客户端通常即可解决。