这篇笔记关注的重点，不是“怎么配置”，而是 2012–2026 年代理工具与协议的演进脉络：从早期 VPN / SSH Tunnel，到 Shadowsocks、SSR、V2Ray / VMess、VLESS / Xray、Trojan，再到 Clash / Mihomo、sing-box、Hysteria2、TUIC 等生态。
本文定位为技术编年整理，重点是理解演进逻辑，不提供具体操作指南。
一、核心问题
这条技术线索主要围绕三个问题展开：
- 协议为什么会一代代演进。
- 每一代主要在解决什么问题。
- 为什么后期竞争重心从“单协议”转向“客户端与平台生态”。
一个简化的阶段划分是：
Shadowsocks 时代 → SSR / V2Ray 分叉扩展 → VLESS / Xray 轻量化 → Trojan / REALITY / XHTTP 的流量表征优化 → Clash / Mihomo / sing-box 的平台化。
二、演进时间线（2012–2026）
1. 2012–2015：Shadowsocks 开启轻量代理时代
- 2012 年，Shadowsocks Python 版发布，确立了
SOCKS5 + 自定义加密的轻量架构。 - 与传统 VPN 相比，Shadowsocks 更轻、更易跨平台实现，随后出现 Windows、Android、Go、Node.js 等版本，JSON 配置与 PAC 分流逐步普及。
- 2015 年原项目归档后，社区维护延续，
shadowsocks-libev、后来的shadowsocks-rust成为主线。
这一阶段的历史意义在于：代理从重型 VPN 方案走向轻量化、低门槛和快速传播。
2. 2016–2018：SSR 对识别与主动探测压力的回应
- SSR 作为 SS 分支，引入混淆（Obfs）与协议（Protocol）插件，尝试让流量更接近 HTTP/TLS。
- 在部分复杂环境中，连通性一度有所改善；后续主项目停更，出现 SSRR 等延续分支。
这一阶段反映了一个关键转向： 当“高熵加密流量”更容易被识别时，开始追求“看起来像正常流量”。
3. 2015–2019：V2Ray / VMess 走向模块化协议平台
- V2Ray 在 2015 年发布测试版，推出 VMess、UUID 鉴权与路由能力。
- 它的突破不只是“加密转发”，而是把认证、路由、多路复用、传输封装组合成可拼装协议栈。
- TLS、WebSocket、HTTP/2 等标准传输层被广泛作为承载层，用于提升与常规 HTTPS 的一致性。
- 2017 年 VMess 增强防重放；后续 AEAD 落地，
alterId逐步退出主流。
V2Ray 的核心价值是： 代理可以是“系统化能力组合”，而非单一协议。
4. 2020 起：VLESS / Xray 的轻量化路线
- VLESS 在 2020 年提出，核心思路是“协议本身只做必要鉴权，加密尽量交给 TLS”。
- 同期 Project X / Xray-core 分化并持续发展，推进了 uTLS、FakeDNS、Fallback 等能力。
- 文脉中也常提到 Shadowsocks-2022，可视为对 SS 路线的一次现代化更新。
这一阶段的方向变化很明确： 协议本身“少做事”，更多依赖成熟标准层。
5. Trojan 路线：直接贴近 HTTPS
- Trojan 的设计哲学是：与其做复杂混淆，不如直接让流量行为更接近真实 HTTPS。
- 认证失败时可回落到正常网站，降低主动探测时的异常特征。
- 2020 年 Trojan-Go 加入多路复用、WebSocket、API 管理等增强能力。
这代表了另一种工程思路： 减少自定义特征，尽量复用大众协议外观。
6. 2022–2024：Xray 的“流量表征”优化阶段
- XTLS Vision、REALITY、SplitHTTP / XHTTP 可视为连续演进。
- 优化重点从“再加一层加密”转向握手长度、时序特征、HTTP 行为、QUIC / HTTP3 表征。
竞争维度也随之改变： 从“能不能连”走向“对外看起来像不像正常业务流量”。
7. Clash → Mihomo：客户端生态崛起
- 相比 V2Ray / Xray 对协议核心的关注，Clash 更强调用户侧体验与配置管理。
- YAML 配置、规则分流、GUI、TUN、Rule Provider、Fake-IP 等能力，塑造了现代代理客户端的常见范式。
- 2023 年 Clash / CFW 归档后，Mihomo 接续维护，Clash Verge Rev、Clash Nyanpasu 等客户端继续演进。
这一阶段说明： 多数用户最终长期使用的是“生态完整的客户端”，而非单一协议名称。
8. 2022–2025：sing-box 走向多协议统一平台
- sing-box 更像通用平台层，而不只是“另一个客户端”。
- 它原生支持 VLESS、Trojan、SS-2022、Hysteria2、TUIC、WireGuard 等多协议。
可将其理解为： 面向统一承载与多协议组合的基础驱动层。
三、四个关键结论
1. 本质是“识别与适应”的持续博弈
早期重点是可用性；中期关注高熵流量识别；后期关注握手、时序、TLS 指纹、HTTP 行为等外部表征。
2. 从单协议走向组合式系统
SS 更接近单一方案；V2Ray / Xray 走向协议系统化；Clash / Mihomo / sing-box 进一步把协议、路由、DNS、TUN、GUI、配置管理组合成平台。
3. 竞争重心从协议扩展到生态
客户端体验、跨平台能力、规则系统与维护活跃度，逐渐成为事实标准形成的关键因素。
4. 更复杂不一定更先进
一条路线是不断叠加功能；另一条路线是持续简化分工（如 VLESS 让 TLS 负责加密、Trojan 尽量贴近原生 HTTPS）。
四、简版脉络
- Shadowsocks：轻量代理开端
- SSR：应对识别与主动探测的分支尝试
- V2Ray / VMess：模块化协议平台
- VLESS / Xray：轻量化，更多依赖 TLS
- Trojan：直接贴近真实 HTTPS
- Vision / REALITY / XHTTP：更重视握手、时序、HTTP/3 等表征
- Clash / Mihomo：规则分流与客户端生态成熟
- sing-box：多协议统一平台化
五、总结
网络代理工具的演进史，本质上是：
从“加密转发”，走向“协议栈设计”；再从“协议能力”，走向“客户端与平台生态竞争”。
可以用三句话收束这段历史：
- 前期比“能不能连”，中期比“像不像正常流量”，后期比“生态是否完整”。
- V2Ray / Xray 更偏协议演进史，Clash / Mihomo / sing-box 更偏工具平台史。
- 现实选型不能只看协议名，还要看客户端体验、维护活跃度、规则系统与 TUN / DNS 体验。