📋 阅读前说明（点击展开）
本文是对 AnyTLS 代理协议的深度技术解析，涵盖其工作机制、与 Trojan/VLESS 的对比、已知检测风险及当前客户端支持情况。内容来源于公开学术论文和开源项目文档，属于技术科普，不构成任何翻墙行为的指导建议。
🚫 免责声明：科学上网工具的使用需符合当地法律法规，请自行评估风险。本文为纯技术内容，不对任何工具的可用性或稳定性作出担保。
AnyTLS 是 sing-box 1.12 引入的新代理协议，核心目标是解决 Trojan/VLESS 的 TLS-in-TLS 指纹暴露问题。以下是本文的核心结论：
- 📌 AnyTLS 通过灵活填充（flexible padding）打散握手包大小分布，规避 DPI 指纹识别
- 📌 连接复用机制大幅降低握手暴露次数，同时改善延迟
- 📌 当前已有 arXiv 研究指出其潜在侧信道风险，但实战封锁尚未大规模出现
- 📌 支持 AnyTLS 的客户端目前只有 sing-box、Shadowrocket（iOS）和 anytls-rs（客户端 metadata 说明）
1、什么是 AnyTLS？为什么需要这个新协议？
先说一个让很多人困惑的问题：Trojan 不是已经把代理流量伪装成 HTTPS 了吗？为什么还不够？
问题出在嵌套 TLS 握手上。Trojan 的做法是在真实 TLS 连接里再跑一层 TLS，用来传输代理目标站点的流量。这就产生了一个特征——正常的 HTTPS 请求里只会有一次 TLS 握手，但 Trojan 流量在一个连接里会出现两次握手。GFW 的深度包检测（DPI）可以识别这个”握手嵌套”的模式，这就是 TLS-in-TLS 指纹。
因此，AnyTLS 从设计阶段就把消除这个指纹列为第一目标。具体来说，它的核心思路是：让外层 TLS 连接看起来和真正的 CDN 或反代流量没有区别，而不是硬塞一个第二次握手进去。
2、AnyTLS 的核心黑科技解析
灵活填充（Flexible Padding）：打散握手包特征
GFW 识别代理协议的方法之一，是看握手阶段每个数据包的字节长度分布。比如 Trojan 的 TLS ClientHello 加上内层的代理头，包大小会落在一个固定区间，和真实 CDN 流量不一样。
AnyTLS 引入了灵活填充（flexible padding）机制：
- 在握手阶段随机插入不同长度的填充字节，让每次连接的包大小分布都不一样
- 填充量不是固定值，而是基于当前会话状态动态调整
- 整体握手包大小的分布会更接近真实 TLS 流量的正态分布，而不是代理流量的尖峰分布
直观理解：就像你每次寄快递都随机塞一些填充物，让快递包的重量每次都不一样，快递公司就很难通过”每次重量都一样”这个特征识别出是同一个发货人。
连接复用：一条 TLS 链路跑多个请求
AnyTLS 的另一个核心设计是连接复用（connection multiplexing），和 HTTP/2 的复用逻辑类似。
传统 Trojan 每次建立新连接都要完整做一次 TLS 握手，在高延迟环境下成本很高。AnyTLS 允许在一条已建立的 TLS 连接上同时传输多个独立的代理请求，用虚拟信道（virtual stream）隔离彼此。这样：
- 握手次数大幅减少，抗指纹识别的暴露面缩小
- 延迟明显降低，特别是连续发起多个请求的场景（浏览、API 调用等）
- 服务端资源占用减少，适合高并发机场部署
UDP 传输方案：udp-over-tcp(v2)
TLS 是 TCP 层协议，但代理经常要处理 UDP 流量（DNS、游戏、视频流等）。AnyTLS 的 UDP 方案是用 udp-over-tcp(v2)：把 UDP 数据包封装成 TCP 流传输，目标地址用虚拟域名 sp.v2.udp-over-tcp.arpa 标识。
这个方案的优缺点都很明显：
优点：不依赖 QUIC，不会被 GFW 的 QUIC 识别和限速层命中（2024 年起 GFW 对 QUIC UDP 流量限速极为激进，尤其是电信线路）。
缺点：TCP 的 RTT 和阻塞控制特性会让 UDP 游戏延迟比原生 UDP 代理高一些。对延迟敏感的场景（实时对战游戏）Hysteria2 的原生 UDP 体验更好。
3. 横向对比：AnyTLS vs Trojan vs VLESS Reality
| 维度 | Trojan | VLESS + Reality | AnyTLS |
|---|---|---|---|
| TLS-in-TLS 指纹 | 有，明显 | 无（借用真站证书） | 缓解（灵活填充打散） |
| 抗主动探测 | 中等 | 极强（回退到真站） | 中等 |
| UDP 支持 | 需额外配置 | XUDP 原生 | udp-over-tcp(v2) |
| 连接复用 | 无 | 有（mux.cool） | 原生支持 |
| 客户端生态 | 极广 | 广 | 成长中 |
| sing-box 支持版本 | 1.0+ | 1.7+ | 1.12.0+ |
4. 当前支持 AnyTLS 的客户端生态（2026最新）
AnyTLS 的生态目前还在快速扩展期，以下是截至 2026 年 Q2 的主流支持情况：
- sing-box 1.12.0+：核心参考实现，服务端 / 客户端均支持，配置文档完整
- anytls-rs：Rust 语言编写的独立实现，性能优先，适合服务端部署
- Shadowrocket 2.2.65+（iOS）：目前 iOS 端支持最早的主流客户端
- Mihomo（原 clash-meta）：社区 PR 合并中，部分 nightly 版本已可用
- v2rayN / Hiddify：路线图中，尚未正式落地
然而，这个生态宽度是目前 AnyTLS 最大的限制。Trojan 和 VLESS 的客户端覆盖远比 AnyTLS 广，机场支持 AnyTLS 的前提是你用的客户端也支持。
5. 行业研究：AnyTLS 存在的潜在检测风险
没有任何协议是”永远检测不到”的，AnyTLS 也不例外。目前学术层面有两个可信来源：
USENIX/arXiv 的位置一元组字节模型：研究发现，嵌套 TLS 握手在字节流中有泛化的位置特征——即使每次包大小不同，特定字节偏移上的值分布依然具有统计规律。基于这个发现，位置一元组（positional unigram）字节模型理论上可以在大量流量中识别 AnyTLS 类协议的握手。
但有一个重要的”但是”：这类检测需要积累足够的流量样本来训练模型，对于使用量还不大的 AnyTLS，目前 GFW 主动针对它的可能性不高。更现实的风险来自同 IP 上的其他协议特征暴露，把整个 IP 拉入黑名单，而不是 AnyTLS 协议本身被精准识别。
简单说：AnyTLS 现在够用，但不是终极方案。就像所有代理协议的历史一样，它今天的优势会随着 GFW 能力提升而逐渐缩小。
6. AnyTLS 适合哪些用户与场景？
基于上面的分析，AnyTLS 当前最适合这几种场景：
- 已经在用 sing-box 或 Shadowrocket，想尝鲜更抗封协议的用户
- 用 Trojan 被封过，想在同一 IP 上换协议继续跑的用户
- 机场运营者想在 VLESS Reality 之外多一条备用线路
- 对延迟要求不极端、以稳定性为主要诉求的用户
如果你的主要需求是抗主动探测能力最强，VLESS + Reality + Vision 目前仍是最佳选择。如果对UDP 游戏延迟要求极高，Hysteria2 + OBFS 更适合。AnyTLS 的定位是介于两者之间的日常使用协议——比 Trojan 抗封，比 Reality 部署简单，比 Hysteria2 更省流量。
7. 总结与常见问题解答（FAQ）
AnyTLS 是 2025-2026 年代理协议演化里值得关注的一个方向：不走”借用真站证书”的 Reality 路线，也不走”UDP 加速”的 Hysteria 路线，而是专注于 TCP over TLS 场景下的流量伪装质量。
灵活填充和连接复用是它的两张牌，打掉了 Trojan 最明显的 TLS-in-TLS 指纹。代价是客户端生态还在追赶，UDP 性能不是最优，以及学术上已有理论检测路径（尽管实际部署还远）。
对普通用户来说，现在就可以用。对机场运营者来说，值得作为备用协议部署——但不要把它当成 VLESS Reality 的完全替代。
FAQ
Q：AnyTLS 和 Trojan 用同一个 TLS 证书，有什么区别？
A：两者都需要有效 TLS 证书，但 AnyTLS 通过灵活填充让握手包大小分布更随机，Trojan 没有这个机制，嵌套 TLS 握手特征更明显。
Q：sing-box 1.12 才支持 AnyTLS，旧版本能用吗？
A：不能直接用，需要升级到 1.12.0 及以上版本。Mihomo 目前部分 nightly 版本可用，稳定版尚未正式支持。
Q：AnyTLS 的服务端需要特殊配置吗？
A：用 sing-box 部署服务端配置与 Trojan 类似，主要差异在协议类型字段和填充策略参数。anytls-rs 提供的服务端更轻量，单独只跑 AnyTLS 性能更好。
Q：用了 AnyTLS 还会被封 IP 吗？
A：会。协议抗指纹不等于 IP 不会被封。如果 IP 被同机房其他用户暴露，或者流量量过大被限速，AnyTLS 也救不了。IP 质量依然是稳定性的核心。