AnyTLS 协议详解：它到底解决了什么问题，怎么配，值不值得用
订阅里突然多了一串 anytls://，机场把它标成"新协议、更稳"。它到底新在哪、值不值得切过去？这篇把 AnyTLS 一次讲透。
先给结论：AnyTLS 是一个专门针对"TLS 套 TLS"指纹做流量整形的协议，2026 年已经是直连机场里 Reality、Hysteria2 之外的第三条主力腿。但它不是魔法——它抬高的是被动识别的成本，不是让你"理论上不可检测"。
30秒先看完
- 要解决的问题：VLESS / Trojan 走 WS+TLS 时会"真 TLS 里再套一层 TLS"，这个嵌套握手是个跨协议通用指纹，能被被动识别。
- 怎么解决：灵活的随机分片 + 填充打散包长，再加连接复用减少握手次数。
- 真实定位：提高被动指纹的成本，不是不可检测。连协议作者和 USENIX 论文都承认"多路复用 + 随机填充本质有局限"。
- 怎么用：sing-box 1.12+、mihomo、Shadowrocket 2.2.65+ 都支持，机场配好了你直接订阅即可。
一、它要解决什么：TLS 套 TLS 的指纹
理解 AnyTLS，得先理解它针对的痛点。
代理的本质是"协议套娃"：你的真实流量（比如浏览一个 HTTPS 网站，本身已经是一层 TLS）被塞进代理协议的载荷里再发出去。当代理协议也用 TLS 时——比如常见的 VLESS / Trojan over WebSocket + TLS——就形成了"真 TLS 里再套一层 TLS"。
问题就在这：外层 TLS 握手完成后，紧接着会在加密信道里冒出一次"内层 TLS 握手"。正常用户直连网站几乎不会出现这种模式，于是它成了一个跨协议通用的指纹——不管你外层是 VLESS 还是 Trojan，只要是"TLS 套 TLS"，就可能一起被抓。
这不是危言耸听。USENIX Security 2024 有一篇专门的论文《Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes》，做法是"协议无关"的：它不针对某个具体协议，而是直接检测"封装的 TLS 握手"这一共性特征。关键点在于——它靠的是包方向、到达时间、包长序列这些统计特征，而不是去解密看内容。
论文实测了 23 种混淆代理配置（涵盖 Shadowsocks、VMess、VLESS、Trojan、obfs4，连 Reality 也在内），所有标准配置的检出真正例率都超过 70%；在一个百万级用户的中型 ISP 上跑了 1.1 亿条流，误报率上界低到 0.0544%。
这篇论文的结论，正好戳到 AnyTLS 的命门
论文原话：混淆代理的流量"即便加了随机填充和多层封装，也能被可靠检测"；"仅靠多路复用和随机填充本质上是有局限的，因为它们没法减少流量突发(burst)的大小或往返次数"。
而 AnyTLS 的两大武器，恰恰就是多路复用 + 填充/分片。所以诚实地说：AnyTLS 是在提高被动识别的成本，不是把检测变成不可能。
二、AnyTLS 怎么做的
AnyTLS 的设计哲学很明确：TLS 本身的握手指纹（ClientHello 长什么样）不是重点——那个早就能用 uTLS 改；真正难缠的是"TLS 套 TLS"的流量形态。所以它把火力集中在整形流量形态上。
1. 灵活的随机分片 + 填充
这是核心。AnyTLS 在 TLS 明文层、加密之前对数据做填充和切分，从而控制最终密文的包长模式。它有一套可配置的 padding_scheme，默认方案大致是：对握手后的前几个包按固定或区间随机的长度切分、填充，让包长不再有规律。
更重要的是它的态度：默认填充方案只是示例，作者明说"无法保证默认参数不被墙，所以设计了可以随时改参数、改变流量特征的机制"。换句话说，它要的是"特征廉价、易改"——你这套被针对了，换一套参数就行，逼审查方不断更新特征库。
2. 连接复用（多路复用）
AnyTLS 在一条已认证的 TLS 隧道（Session）里跑多条数据流（Stream），多个应用连接共享同一条隧道。好处是减少"每个请求都来一次 TLS 握手"所暴露的特征——握手少了，可抓的把柄就少了。
它还维护一个空闲会话池：复用最新的空闲会话、清理最老的（sing-box / mihomo 里默认空闲超时 30 秒）。
3. 传输层与加密
- 传输层是 TCP over TLS；UDP 通过 udp-over-tcp 承载。
- 加密完全交给外层 TLS——这正是 "AnyTLS"（Any in TLS）名字的由来：协议自己只管①合理的连接复用与性能、②整形包长缓解 TLS-in-TLS 指纹，加密这些事交给 TLS。
参考实现是 anytls/anytls-go（最新约 v0.0.12 / 2026-01），它明确声明自己只是个"简洁示例"，不打算做成通用代理工具——真正落地是靠 sing-box、mihomo 这些客户端内置实现。
三、客户端支持与配置要点
机场用户其实不用手写配置——机场把节点配好，你订阅导入即可。但了解字段有助于排错。
| 客户端 | 支持情况 |
|---|---|
| sing-box | inbound / outbound 均自 v1.12.0 起内置 |
| mihomo / Clash.Meta | 内置，v1.19.x 持续迭代（含协议 v2、ECH 等） |
| Shadowrocket（iOS） | 2.2.65+ 实现 AnyTLS 客户端 |
sing-box 配置要点（outbound）
关键字段：server / server_port / password（必填）、tls（必填）、以及会话池三件套 idle_session_check_interval（默认 30s）、idle_session_timeout（默认 30s）、min_idle_session（默认 0）。
{
"type": "anytls",
"tag": "anytls-out",
"server": "你的服务器",
"server_port": 443,
"password": "你的密码",
"idle_session_check_interval": "30s",
"idle_session_timeout": "30s",
"min_idle_session": 5,
"tls": {}
}注意：会话池三字段只在 outbound 有；
padding_scheme是 inbound（服务端） 字段，普通用户留空用服务器默认即可，别瞎改。
mihomo 配置要点
字段是 kebab-case：type: anytls、server、port、password、client-fingerprint（uTLS 浏览器指纹，如 chrome）、udp、idle-session-timeout（默认 30）、sni、alpn、skip-cert-verify 等。
mihomo 明确不支持 AnyTLS + Reality
mihomo 官方原话："Mihomo 不支持 AnyTLS+Reality，未来也不会支持。"想隐藏 SNI 用 ECH；非要用 Reality 就改 VMess / VLESS / Trojan。这俩传输层定位本来就冲突，别折腾。
anytls:// 分享链接格式
参考了 Hysteria2 的写法，刻意只放连接必需信息：
anytls://[密码@]主机名[:端口]/?sni=xxx&insecure=0- 密码放在"用户名"位置，含特殊字符要百分号编码。
- 省略端口默认 443。
sni：TLS 的 SNI；当sni取值是 IP 时，客户端必须不发送 SNI。insecure：1允许不安全 TLS，0不允许。
官方示例：anytls://[email protected]/?sni=real.example.com
mihomo 等在订阅转换时会附加
client-fingerprint之类参数，但那些不是官方 URI 规范字段，跨客户端兼容性不保证。
四、它的能力边界（这部分最该看）
吹归吹，AnyTLS 有几个连作者自己都列出来的弱点，机场不会告诉你：
- TLS 套 TLS 多出来的往返次数，消不掉——除非有人 MITM 破坏端到端加密，否则这个"多余往返"的特征一直在。这正好对应 USENIX 论文说的"减不掉往返次数"。
- 握手后第一个往返内会几乎同时发 ≥3 个包，即便单包长度合规，仍可能被"到达时间 + 包长 + 包数量"的统计特征利用。
- 当前参考实现只整形上行流量，下行没处理。
- TLS-over-TLS 开销会让可见包长增大、小包变少，甚至持续超过 MTU——这本身也不太像正常用户。
关于威胁模型，作者说得很清楚：TLS 中间人攻击"偶尔发生在网络接入层，在骨干网上几乎不可能"。意思是——接入层（受控网络、企业网、恶意热点）有被 MITM 的风险，所以生产环境一定要配真实证书并校验（别用示例的自签 + insecure）；而骨干网难以对海量 TLS 做 MITM，所以骨干侧主要是被动指纹威胁，这才是 AnyTLS 的主战场。
五、和 Reality、Hysteria2 怎么选
| 协议 | 路线 | 强项 | 适合 |
|---|---|---|---|
| VLESS + Reality | 偷真站 TLS 指纹 + 抗主动探测 | 免证书免域名、抗主动探测 | 强审查、要最稳隐蔽 |
| Hysteria2 | QUIC/UDP + 激进拥塞控制 | 弱网抢速、看 4K | 线路丢包高、玩游戏 |
| AnyTLS | 整形 TLS-in-TLS 流量形态 + 复用 | 走 TCP/443 穿透稳、特征易换 | Reality 与 Hysteria2 之间的第三条腿 |
几个实在的判断：
- 作者自己拒绝拿 AnyTLS 跟 Hysteria 比速度——"底层拥塞控制和运营商 QoS 策略不同，没法比"。速度主要看线路。
- UDP/QUIC（Hysteria2）在一些网络会被 QoS 限速甚至阻断，这时走 TCP/443 的 AnyTLS 穿透更稳。
- 极致抗主动探测仍首选 Reality；AnyTLS 的价值是"针对 TLS-in-TLS 被动指纹做整形 + 特征可换 + TCP/443 稳"。
各协议的全景对比，可以配合这篇看：2026 主流翻墙协议横评。想在客户端里跑通 AnyTLS，参考：sing-box 多协议订阅使用教程。
小结
- AnyTLS 解决的是真问题（TLS-in-TLS 指纹），手段是随机分片 + 填充 + 会话复用，主打"特征廉价可换"。
- 它提高被动识别成本，但不是不可检测——作者和学术论文在这点上互相印证，别信"绝对安全"的机场话术。
- 机场已经替你配好，用 sing-box（1.12+）/ mihomo / Shadowrocket（2.2.65+）订阅导入即可；导不进来先升级客户端。
- 选型上把它当 Reality 和 Hysteria2 之间的第三选择：TCP/443 穿透稳、特征好换。
免责声明
本文基于 anytls-go 官方文档、USENIX Security 学术论文与各客户端官方文档整理，技术细节可能随版本更新变化，请以各项目官方文档为准。文中工具仅用于技术学习与合法合规的网络访问，使用风险自负。