订阅里第一次见到 type: anytls 的人，多半是因为节点导不进来才去查它。这个协议 2025 年 2 月才公开，比订阅里其他几种年轻得多。
proxies:
- name: "香港 AnyTLS"
type: anytls
server: hk01.example.com
port: 443
password: "your-password-here"
sni: hk01.example.com
client-fingerprint: chrome
udp: true
idle-session-check-interval: 30
idle-session-timeout: 30
min-idle-session: 0认证只要一个 password，这一点和 Trojan 一样。别处见不到的是底下那三行。
那三个 idle-session 字段在管连接复用
Mihomo 文档给的默认值是，检查空闲会话的间隔 30 秒，闲置超过 30 秒的会话关掉，检查时至少留 0 个空闲会话开着。sing-box 的字段名把下划线换成了驼峰式的写法，含义一样。
这三栏存在，是因为 AnyTLS 把会话复用写进了协议本身。协议文档要求客户端必须实现会话层多路复用，新请求优先复用最新的那个会话，具体做法是从空闲池里取序号最大的一个，没有空闲的才新建。文档给的建议是每 30 秒清理一次，超过 60 秒没用过的会话回收掉。
对用户的意义在于开销。每新建一条 TLS 连接都要完整握手一次，复用已有连接可以省掉这一趟。把 min-idle-session 设成大于 0 的数，等于让客户端常备几条热连接，代价是空着也占资源。这几栏机场一般会在订阅里写好，不用自己调。
它盯的是 TLS 里再套一层 TLS
仓库首页对这个协议的定位只有一句，一个试图缓解嵌套的 TLS 握手指纹问题的代理协议。
这件事的现场是这样。用代理访问一个 HTTPS 网站，外层是你到节点的 TLS，里层是你到目标网站的 TLS。里层那次握手的包有固定的长度模式和先后节奏，这套形状会原封不动地印在外层的加密流量上，因为加密不改变包的大小和时序。看不到内容的观察者照样能看出「这里面又在握一次手」。
AnyTLS 的办法是在会话层上加一套分包和填充规则。协议的帧格式很简单，一个字节的命令、四个字节的流 ID、两个字节的数据长度，后面跟数据。认证也短，TLS 握手完成后客户端立刻发过去密码的 SHA256 值，32 字节，后面跟一段填充，总开销 34 字节。
协议里最费心思的一块是填充方案。它长这样。
stop=8
0=30-30
1=100-400
2=400-500,c,500-1000,c,500-1000,c,500-1000,c,500-1000
3=9-9,500-1000
4=500-1000
5=500-1000
6=500-1000
7=500-1000每一行管一个包，等号后面是这个包要被填充到多长，单一固定值或者一个随机区间。stop=8 表示处理到第 8 个包为止，后面的原样发。c 是检查点，用户数据不够时就停在那里。
方案由服务端说了算。客户端在 cmdSettings 里报上自己手里那份方案的 MD5，服务端对不上就用 cmdUpdatePaddingScheme 下发新的。仓库里那份默认方案只是示例，作者写得很坦白，本项目无法确保默认参数不会被墙，因此设计了更新参数改变流量特征的机制。
顺带说，anytls-go 自己只是参考实现。仓库里写明它的核心目标是演示协议细节、交互流程与边界场景，日常使用推荐第三方兼容软件。截至本站核对，它最新的版本是 2026 年 6 月 27 日的 v0.0.13。
client 那个字段引起过一场争论
cmdSettings 里除了版本和填充方案的 MD5，还有一项 client，内容形如 anytls-go/0.0.1，报的是客户端软件名和版本。
2026 年 8 月 3 日，仓库里多了一篇专门说明这个字段的文档。它把 client 比作 HTTP 里的 User-Agent，说服务端可以据此排查故障、统计实现分布，也承认这类信息由客户端自行声明、用户可以修改，服务端不能据此可靠确认客户端实际用的是哪个实现。文档同时修正了之前的措辞，承认协议文档里「伪装没有任何意义」的说法过于绝对。
内核这边的反应能查到。Mihomo 的 AnyTLS 页面上挂着一条警告，说由于 client-metadata 可能被用于统计客户端信息并区别对待，从 v1.19.30 开始默认不再发送这一项，需要的人自己填。v1.19.30 发布于 2026 年 8 月 16 日，在那篇说明之后两周。
用户这边不用做什么。知道有这么一栏就够了，它在加密连接内部，普通的网络观察者读不到。
哪些内核和客户端认得它
仓库列的兼容软件是这几个。
| 软件 | 情况 |
|---|---|
| sing-box | 服务端和客户端都有，从 1.12.0 版起支持 |
| mihomo | 服务端和客户端都有 |
| Shadowrocket | iOS 客户端，2.2.65 版起实现 |
| Stash、Loon | 已跟进适配 |
sing-box 的 1.12.0 发布于 2025 年 8 月 4 日。用 sing-box 官方客户端或 Clash Verge Rev 这类 Mihomo 系客户端的人，把版本升到最近的一年内基本都能用。仓库另外提醒过一句，这些第三方客户端的实现细节与协议规范的契合度由各自维护团队负责，anytls-go 没有验证。
有一个组合是明确不行的。Mihomo 文档写着它不支持 AnyTLS 加 Reality，未来也不会支持，想隐藏 SNI 请改用 ECH 或者搭配 ShadowTLS 这类方案。想用 REALITY 就得换协议。
作者自己列了九条弱点
FAQ 末尾有一节叫已知弱点，列了九条，前面写明这些问题目前可能不会轻易引发被墙，而修复会破坏兼容性，所以 v1 没有处理。
挑三条和使用体验有关的。TLS 套 TLS 需要比普通 h2 请求更多的握手往返，这一点除非做中间人代理否则绕不开。AnyTLS 没有处理下行流量的包特征，作者认为这一点容易修但会损失性能。握手后的第一个往返里它会几乎同时发出三个以上的包，即使单包长度合规，包数和到达时间仍可能被拿去做统计。
这种把自己短处写清楚的做法在这类项目里不常见，读一遍比看任何第三方评测都实在。
本站收录的 28 家机场里，资料写明用 AnyTLS 的有 2 家，飞猫云和星岛梦。数据来自机场自述与站长资料，核对日 2026-08-09。站长 2026-06-27 测星岛梦那一轮覆盖 70 个节点，其中 10 个是 AnyTLS，结果是 4 个没测出延迟，Disney+ 和 OpenAI 两列全部为空，同一份订阅里的 60 个 VLESS 节点表现要好得多。一次测试说明不了协议本身的优劣，只能说明那家当时把主力放在 VLESS 上。要看六种协议的横向对照，按字段认协议那篇里有一张表。