在相当长的一段时间内，Snell的V4和V5版本一直是Surge生态内部关于「最佳实践」的参考，但是在最近Snell V4和V5版本在mihomo中被接纳PR，社区本身也有很多争议。我想在这里聊聊为什么我觉得社区应该把协议本身被逆向和移植这件事所代表的情绪立场，应当同工程前瞻和技术思考分离。

Snell是什么（之后基本特别指代V4和V5）？Snell 的设计目标从一开始就不是一个广泛标准化的通用代理协议，而是高度绑定 Surge 使用体验的专用协议。从公开兼容实现看，Snell 与 Shadowsocks AEAD 的工程谱系有明显关系，但不能简单说它就是 SS。我们简单的举一个例子说明一下：mihomo 合并的 Snell 代码中，早期版本直接使用类似于 Shadowsocks AEAD 封装，而合并的代码中展示的 V4 则单独实现了 AES-GCM 分帧、salt、nonce、payload chunk、padding、payload interleave 等逻辑，也就是说，V4 可以理解为在 SS AEAD 风格的加密分帧基础上做了明显的 Snell 化改造。

Snell 真正相对传统 Shadowsocks 更有价值的地方在于对传输层行为的特性实现，这同Surge客户端一起在代理体验中做到了互配的效果。我们简单列举一下这些特性：服务端错误回报，V5 加入 Dynamic Record Sizing 和 QUIC Proxy Mode；支持了Surge 的 Smart 策略组则会收集握手延迟、丢包率、连通性、RTT 等维度，并在连接异常或变慢时做动态决策。这种思路与实践是开源社区中落地实现上缺少的一部分，也是Surge本身链接体验优秀的核心。

如此复杂的传输层特性也是很多粗糙逆向实现的问题所在。协议“能连通”和协议“完整复现工程规划”不是一回事。很多逆向可以说是可以完成基本 CONNECT 的，实现了可以访问网页，但是在阅读了他们的代码的时候，我发现在对于处理了长连接、复用、UDP 语义、服务端错误回报、早期包长度行为、padding 策略、连接关闭语义以及与上层策略系统的反馈关系来讲他们是不合格的。同时Snell本身对GFW的隐蔽性的核心在于单端方向的整流策略，这并不是完全依赖于协商双向验证的，很多逆向更是完全忽略了这一点，使得Snell成为了早期ss协议的再实现，尤其是某家机场所实现的版本，在流量特征分析中和Surge客户端构建的数据特征差距明显。当然，Snell的实现可以说是一种取巧的思路：padding 逻辑会根据 payload cipher 的比特分布生成 padding，并通过 padding 与 payload cipher 的字节交错改变可观测特征，老刘自己也讲希望 Snell 用户群体尽可能小，本身也是在间接承认“低普及度”是跨墙安全的一部分。

再谈这次 mihomo PR。公开时间线很清楚：MetaCubeX/mihomo 的 #2817 在 2026 年 5 月 21 日合并，标题为 “feat: add snell version 4/5 outbound and inbound”；随后 2026 年 5 月 22 日的 Prerelease-Alpha 也把 “feat: add snell version 4/5 outbound and inbound by @xream in #2817” 列入变更。但这并不意味着 #2817 是第一个公开逆向或第一个开源实现。winmin/snell-client 的公开仓库显示其 v0.1.1 release 时间为 2026 年 4 月 24 日，README 明确写有 reverse-engineered Snell v5 protocol support；pickrui/Clash.Meta 的 FlClash 分支在 2026 年 5 月 12 日已有 “feat: support snell v4”“feat(snell): support identity header”“feat(snell): support anytls obfs”等提交记录。至少从公开 GitHub 时间线看，5 月 21 日被合并进 mihomo 的 #2817 不能被称为第一次公开逆向，也不能被称为最早开源代码贡献。

我更想要聊聊的是#2816 与 #2817 的差异，尤其是实现行为和特性支持上。#2816 的描述集中在 Snell v5 outbound 支持，文件变化包括 transport/snell/v5.go、adapter/outbound/snell.go 和 transport/snell/snell.go；它列出的内容更像是一个针对 V5 wire format 的连通性实现。#2817 则是 outbound 与 inbound 同时支持，并且实际合并进 Alpha。从合并进来的代码看，mihomo 的实现还把配置中的 Snell V5 归一化为 V4，理由是 “Snell v5 servers are backward-compatible with v4 clients”；这与 Snell 官方文档中“V5 服务端向下兼容 V4 客户端，Dynamic Record Sizing 只与服务端有关，如果不使用 QUIC Proxy Mode，客户端设置为 V4 即可”的说明一致，其实合并的代码本身也难说 Snell V5 的所有新特性。所以我不赞成把 #2817 的意义粗暴概括为“破坏 Surge 社区”。它被提交只能说是贡献者希望为mihomo 这类代理基础设施做出贡献，目的是为了补齐协议兼容性、inbound/outbound 支持和更加合理的实现而做的一次取代性合并。它当然触碰了 Snell 官方不希望被逆向、不希望被兼容的明确意图应当被承认。但从现实角度看，当公开逆向实现已经存在，讨论重点就不应停留在道德立场了，吵架对任何社区都没意义，也无助于实现更好的技术目的，社区的关注点自始至终都应该在于更良好的工程实现和技术探索上。

Snell V5 并没有完全满足许多人对“新一代代理协议”的期待。它的 V5 更新主要是 Dynamic Record Sizing、QUIC Proxy Mode 和出口控制，这些是很好的传输层优化，但也只是在 V4 架构上的增量增强。对于一个现代代理协议，竞争已经不只是谁加密得快，而是谁能更系统地处理指纹、主动探测、复用、UDP、QUIC、服务端策略下发、错误恢复和可观测性以及对于传输层特性的良好支持。

我希望 Surge 社区不要把 Snell 的价值建立在封闭性本身上。小规模确实是一种现实策略，但它不是协议设计的充分答案。一个更理想的方向，是把 Snell 已经做得好的部分继续推进：更明确的连接状态反馈、更好的错误回报、更稳健的 UDP/QUIC 处理、更强的策略系统联动；同时补上现代协议可能应该也许大概需要支持的部分：可协商流量整形、深层语义伪装、版本协商、复用控制、主动探测防御和更透明的安全边界。

最终，我们所有人的目标其实很简单：让代理工具通过合适的代理协议承载真实流量，并在复杂网络环境中尽可能稳定、可分析、可恢复。促进社区对协议进行技术分析和公开讨论，对用户、开发者和维护者都有意义。GFW 不会在乎任何社区里的吹嘘；丢包、波动、封锁和识别也不会因为某个协议被说得神秘而消失。Snell 是一个好协议，但它不是神话。逆向实现也不是天然正义，但它可以成为技术生态互相推动的一部分。社区本身与其把争论停在“独占”或“背叛”上，不如把问题重新拉回工程本身：什么特性真正改善了用户体验，什么设计真正降低了可识别性，什么实现真正尊重了协议语义，什么社区文化真正鼓励了更好的协议出现。对于技术社区来说，这才是更值得讨论的方向。