Hello everyone.
Today we are excited to introduce a new protocol added to Chute: AnyTLS. This is an entire new proxy protocol designed for simplicity, performance, and flexibility.
What is AnyTLS?
AnyTLS is a lightweight proxy protocol that uses TLS as its transport layer. Unlike VMess or VLESS — which define complex handshake and authentication flows inside the TLS tunnel — AnyTLS keeps things minimal: establish a TLS connection, send an optional padding payload to obscure the traffic pattern, and then proxy TCP or UDP data directly through the encrypted channel.
The key insight behind AnyTLS is that TLS already handles encryption and server authentication. Instead of layering another cryptographic protocol on top, AnyTLS relies on the TLS layer for security and focuses on what matters: reliable, multiplexed data forwarding with minimal overhead.
Protocol Design
Handshake
- The client establishes a standard TLS connection to the server (TLS 1.2 or 1.3)
- After the TLS handshake completes, the client sends a brief authentication header containing:
- Protocol version
- A pre-shared key or user/password credential
- The target destination (host and port)
- The server validates the credential and connects to the destination
- After that, bidirectional data flows transparently
Padding
To make AnyTLS traffic harder to identify, we implemented a padding calculator that works at two levels:
- Handshake padding: After the TLS handshake, the first data packet includes random-length padding to obscure the authentication header size
- Stream padding: During data transfer, optional padding frames can be inserted to smooth out traffic patterns
The padding scheme uses a configurable random range. The actual padding length is unpredictable to observers, making traffic analysis more difficult.
UDP Support
AnyTLS supports UDP proxying through a feature called UoT (UDP over TCP). UDP datagrams are wrapped in a lightweight header and multiplexed over the existing TLS connection alongside TCP streams. Each UDP session gets its own session ID, and the server separates and forwards them independently.
Connection Multiplexing
Multiple TCP streams and UDP sessions share a single AnyTLS connection. We assign each stream a unique session ID, and a simple multiplexing header separates the data on the wire. This avoids the overhead of establishing a new TLS handshake for each connection — especially valuable for applications that open many short-lived connections.
Keep-Alive
Since AnyTLS runs over TCP, connections can be silently dropped by intermediate firewalls or NAT gateways. We implement a periodic ping/pong mechanism at the protocol level to keep idle connections alive. The interval is configurable; if a ping goes unanswered, the connection is marked as dead and re-established.
Implementation
The AnyTLS protocol is built into Chute’s core proxy engine. It handles the full lifecycle:
- TCP path: TLS connection establishment, authentication, and bidirectional data forwarding
- UDP path (UoT): UDP session management, fragment reassembly, and upstream forwarding
- Padding engine: Random-length padding generation for both the handshake and data phases, making traffic patterns harder to fingerprint
- Session pooling: Connections are reused across multiple streams and UDP sessions to avoid repeated TLS handshakes
The protocol parser for AnyTLS supports the standard URI scheme format:
1 | anytls://username:password@server:port#fragment |
This can be used directly in policy configuration:
1 | - name: my-anytls-server |
Configuration in Chute
Both Chute iOS and Chute Mac now support AnyTLS as a first-class protocol. You can add AnyTLS policies through the configuration editor, and they appear alongside other protocol types in policy groups.
AnyTLS fills an important gap in Chute’s protocol lineup. It is simpler than VMess/VLESS, more modern than legacy protocols, and provides both TCP and UDP proxying with anti-censorship padding over standard TLS.
Give it a try and let us know what you think at Support.
Thanks.
Chute Devs