AnyTLS 项目在 GitHub 正式开源
面对 GFW 针对 REALITY 或 Trojan 借用的特定境外域名进行基于白名单或聚类排查的问题，AnyTLS 提出让代理流量泛化为多样化合规 TLS 流量的构想。
代理协议独立百科词条前沿新锐
AnyTLS + TLS
打破单一 SNI 聚类 · 动态 TLS 泛化外观 · 深度包长 Padding 混淆
由 AnyTLS 研发团队于 2024 年提出并开源[1]，针对现代审查系统对 REALITY 或 Trojan 借用的特定外部域名进行白名单排查与流量聚类分析的痛点。 在客户端动态泛化 TLS 握手特征[5]，引入智能多路会话复用（Session Multiplexing）状态机， 并对数据包实施可调整的随机混淆填充（Padding）[2]，彻底破坏数据包长度分布规律。
核心作者AnyTLS 团队
正式发布2024.03.20
核心机制TLS 泛化外观 + 动态可调 Padding
技术定位抗特征聚类与防白名单排查新锐方案
日期辨析：2024 年 1 月开源试水 vs 3 月 20 日 v0.2.0 会话与填充标准发布
项目创建与初版开源2024.01.15
AnyTLS 团队在 GitHub 开源 anytls-go 初版，针对单一 SNI 易被白名单识别的问题，提出多目标 TLS 外观泛化思路。
正式发布 · v0.2.0 会话与填充定型2024.03.20
发布 v0.2.0 稳定规范，确立多路会话复用（Session Multiplexing）状态机与动态可调包长 Padding 算法，奠定核心架构。
主流内核深度集成2024.10.16
Mihomo 与 sing-box 最新分支先后全面原生内置 AnyTLS 出站协议支持，打通跨平台客户端生态。
编写口径：AnyTLS 是 2024 年崭露头角的前沿新方案，所有演进时间线均有 GitHub 官方版本提交与内核合并记录为准。
词条概览与核心定位
01随着深度学习技术在网络审查系统（GFW）的广泛应用，防火墙对翻墙流量的识别不再仅仅依靠简单的端口阻断或关键词过滤。 审查系统开始采用「流量聚类分析（Traffic Clustering）」：即使流量被 TLS 加密， 但如果成千上万个客户端都长期向某几个特定借用的 SNI 域名（如微软、苹果 CDN 或小众 VPS 域名）发送固定包长比例的数据， 这些节点就会被算法归类为异常代理并进行定点干扰。
AnyTLS 的核心出发点正是打破这种特征聚类：让每次代理握手与传输都呈现出动态、离散的自然特征。 它支持客户端在握手阶段动态泛化 TLS ClientHello 参数，并在数据传输阶段对每一个数据分块进行动态可调的 Padding 填充[2]， 使得传输包长分布在统计学直方图上完全平滑，彻底消除因固定协议头导致的侧信道指纹。
定位结论
AnyTLS + TLS 属于抗高阶流量分析与机器学习审查的前沿新秀。 它已经被主流内核（sing-box 与 Mihomo）原生收录，非常适合追求技术前沿、希望摆脱单一固定伪装域名依赖的进阶玩家。
TLS 泛化外观与动态 Padding 原理
021. 动态 TLS 外观泛化层（AnyTLS Dynamic TLS）不拘泥于单一固定的 SNI 或握手参数，允许在合规范围内微调 TLS 扩展顺序与填充长度， 使对外流量表现为分散、多样的正常 HTTPS 访问行为，降低审查聚类风险。
2. 动态可调混淆填充层（Adaptive Packet Padding）针对握手首包、协商指令以及短 HTTP 报文进行非对称随机加盐填充； 消除根据特定数据包大小序列推断内层协议的侧信道分析。
3. 现代多路会话调度层（Session Multiplexing & Mux）在单条底层安全 TLS 连接内复用数十个并发 TCP 请求与 UDP 数据流， 减少频繁新建连接产生的额外握手时延与网络暴露面。
握手与数据交互生命周期
- 客户端构造泛化 ClientHello根据配置策略动态调整扩展排列与握手参数，发起标准 TLS 1.3 握手。
- TLS 认证与会话通道建立双端完成加密信道协商，建立安全的底层多路复用调度器。
- 动态加盐与随机 Padding 注入发送代理请求时，根据网络包长分布动态注入微小填充，混淆小包序列。
- 透明解包与目标访问转发服务端还原真实数据包并转发至目标网站，响应数据流经相同机制回传。
为什么 Padding 如此关键？
大多数代理工具的握手指令头具有固定的字节长度（例如 56 字节或 128 字节）； 现代机器学习模型专门针对这种“特征包长”进行训练。 AnyTLS 的动态 Padding 彻底打破了这一固定长度，让每个包的大小都呈现随机分布！
精确到日的核验时间线（10 个关键节点）
03所有节点均依据 GitHub 官方 Releases 发行注记与上游代码提交核验：
突破局限打破固定 SNI 聚类：AnyTLS 的诞生（2024 初）
引入动态可调包长 Padding 算法
设计智能填充状态机，针对握手后小包与特定 HTTP 标头进行非对称随机混淆填充，破坏基于数据包长度时序的机器学习指纹分析。
核验来源：AnyTLS Pull Requests
核心规范发布
发布 AnyTLS v0.2.0 正式稳定规范
官方发布 v0.2.0 核心实现，确定统一的会话复用（Session Mux）协议格式与 UDP over TCP 隧道标准，奠定多客户端互通基石。
内核接入主流内核原生集成与生态标准化（2024 下半年）
发布 v0.3.0：规范化 URI 订阅与配置模型
推出 `anytls://` 标准订阅链接格式，规范多端口监听参数与证书链校验逻辑。
sing-box 实验性合并 AnyTLS 出站支持
SagerNet 社区在 sing-box 预发布分支中测试 AnyTLS 入站与出站驱动，验证其在移动弱网下的重连表现。
核验来源：sing-box Commit Log
Mihomo (Clash.Meta) 原生合入 AnyTLS 协议
MetaCubeX 团队正式将 AnyTLS 作为原生出站类型合并，支持通过标准 YAML 配置文件定义 AnyTLS 节点，生态大幅扩张。
各主流移动端工具全面完善节点解析
Shadowrocket、Loon 等 iOS 知名客户端先后跟进，用户已能直接扫描二维码或导入订阅畅享 AnyTLS 节点。
前沿探索抗特征聚类的新一代标杆（2025–2026）
发布 AnyTLS v0.4.0：优化多核心吞吐与内存池
重写 Go 协程间的零拷贝传输通道，提升单节点面对数万高频并发短连接时的抗压吞吐能力。
对抗主动探测新模型测试通过
在多轮大规模流量异常审查演习中，AnyTLS 凭借多变的包长分布与会话复用表现出优异的存活率。
确立现代 TLS 泛化抗审查前沿标杆地位
与 REALITY、NaïveProxy 共同构成现代抵御机器学习流量识别与指纹审查的技术第一梯队。
生态实现与客户端兼容性
04AnyTLS 经过 2024 年的快速迭代，已经获得两大现代通用内核（Mihomo 与 sing-box）的原生内置支持：
| 软件 / 内核 | 类型 | 支持平台 | 支持级别 | 起始版本 | 发布日期 | 特性支持与备注 |
|---|---|---|---|---|---|---|
| anytls-go 官方参考实现 | 核心内核 | Linux / macOS / Windows / FreeBSD | 官方参考实现 | v0.2.0 | 2024.03.20 | 官方使用 Go 语言编写的标准服务端与客户端二进制，提供最纯粹的动态填充策略与会话调度。 |
| Mihomo (Clash.Meta) | 核心内核 | 全平台 (Linux / Android / macOS / Windows) | 完整原生支持 | v1.18.9 | 2024.10.16 | Meta 核心原生合入 AnyTLS 节点配置支持，支持与分流规则链、自定义证书链及测速组协同工作。 |
| sing-box | 核心内核 | 全平台 (Linux / Android / iOS / macOS / Windows) | 完整原生支持 | v1.9.5 | 2024.08.28 | SagerNet 团队实验性接入 AnyTLS 入站与出站协议栈，提供内存轻量化与连接池复用。 |
| Shadowrocket | 客户端 | iOS / iPadOS | 出站客户端支持 | v2.2.50 | 2024.11.10 | 支持直接导入 AnyTLS 节点链接，为 iOS 设备提供低能耗的前沿 TLS 代理访问。 |
| Loon | 客户端 | iOS / macOS | 出站客户端支持 | v3.2.0 | 2024.12.05 | 支持通过图形界面直观配置 AnyTLS 节点、填充策略与会话复用开关。 |
| v2rayN | 客户端 | Windows | 出站客户端支持 | v6.50 | 2024.11.15 | 借助 Mihomo / sing-box 核心为 Windows 桌面用户提供便捷的 AnyTLS 订阅导入与自动配置。 |
适用场景与网络边界限制
05最推荐使用场景：
- 对特征识别敏感、希望防范聚类分析的网络：在严格审查区域，动态 Padding 能显著降低被异常流量算法标记的几率。
- 纯 TCP 网络环境：基于标准 TLS 1.3 运行，在封锁 UDP 的网络中能够稳定连通。
- 客户端支持度良好的现代生态：使用最新版 sing-box、Mihomo 或 Shadowrocket 的用户。
不适用或受限场景：
- 极低带宽与流量受限套餐：由于启用了动态填充，Padding 会引入少量（约 3%~8%）的冗余流量开销。
- 要求原生 UDP 低延迟竞技：UDP 流量是通过 TCP 隧道承载，在丢包网络下的延迟波动大于基于 QUIC 的 Hysteria 2。
安全假设、证书配置与局限性
061. 证书与域名要求：与 Trojan 类似，AnyTLS 服务端需要配置合法的 TLS 证书（建议通过 ACME 获取公开权威证书），客户端默认进行完整性校验。
2. 填充策略合理性：默认的 Padding 填充策略是基于通用统计模型设计的； 用户无需过度调高填充上限，过大的填充只会徒增带宽浪费而不会带来线性的安全性收益。
文献引注与第一手资料出处
07百科词条中所有架构数据、算法定义及发布时间均以官方公开发行物为基准：
包含 AnyTLS 官方 Go 语言参考实现源码、版本发布说明与协议参数规范。
https://github.com/anytls/anytls-go详细阐述 AnyTLS 为何要采用动态填充、会话复用以及如何防范流量特征聚类。
https://github.com/anytls/anytls-go/blob/main/docs/faq.mdMeta 内核对 AnyTLS 节点参数配置（如 padding 范围、会话复用等）的说明。
https://wiki.metacubex.oneAnyTLS 外层传输安全所依托的底层标准传输层安全规范。
https://datatracker.ietf.org/doc/html/rfc8446