How the TUIC Proxy Protocol Relays TCP and UDP Over QUIC
Of 543 consumer VPNs in our data, 74 say they do not offer it. Below: the services that rank highest for it.
TUIC is a proxy protocol that relays TCP and UDP traffic through one TLS-encrypted QUIC connection; the current version is v5 (0x05). It is a protocol, not a VPN company: you meet it as an option inside a client app, a provider's setup or a server on your own VPS, while the official repository holds only the specification.
How a TUIC session carries traffic
QUIC runs over UDP, and TLS 1.3 is folded into its handshake, which means the server must present a certificate. The client then speaks five commands: Authenticate proves who it is, Connect opens a TCP relay, Packet carries a UDP packet or a piece of one, Dissociate ends a UDP session, and Heartbeat keeps the link alive (sing-box sends one every 10 seconds by default). Each TCP connection rides its own stream, and the server never answers relay commands: after a Connect, data simply starts flowing.
What 0-RTT means in TUIC
The zero round trip is about the relay commands themselves: the client names the target address and pushes data immediately, because nothing is coming back to wait for, and UDP sessions behave the same way. A separate switch, the QUIC 0-RTT handshake (zero_rtt_handshake in sing-box, reduce-rtt in mihomo), stays off by default. It brings little performance benefit, since the protocol is fully multiplexed anyway, and it is vulnerable to replay attacks. Keep it disabled.
UDP relay: native or quic mode
| Mode | Carried as | Loss behaviour | Fits |
|---|---|---|---|
| native | QUIC datagrams | lost packets stay lost, like plain UDP | games, voice calls, DNS |
| quic | QUIC one-way streams | resent until delivered, extra overhead | paths where every packet must land |
| udp_over_stream (sing-box add-on) | UDP-over-TCP style mode on QUIC streams | lossless | relaying streaming UDP such as QUIC itself; needs a sing-box-compatible server |
Each UDP flow carries a 16-bit associate ID, and the server maps every ID to a single UDP socket, accepting replies on it from any address: Full Cone NAT, the behaviour consoles and peer-to-peer apps expect. Oversized packets are split into fragments marked by packet ID and fragment number, then reassembled on the far side. The server answers a session in the mode it was opened with, and udp_over_stream conflicts with udp_relay_mode.
Congestion control and why BBR is the usual choice
The options are cubic, new_reno and bbr. Cubic and new_reno are loss-based: they both slow down when packets drop, which hurts on mobile links and long routes where loss is random. BBR instead estimates bottleneck bandwidth and round-trip time and paces traffic accordingly, which is why most guides recommend it for lossy paths. sing-box defaults to cubic, and mihomo offers three BBR profiles: standard, conservative and aggressive.
Logging in with a UUID and a password
A v5 account is a UUID with a password. The raw password never crosses the wire: both ends derive a 256-bit token from the TLS keying material exporter of the current session (UUID as label, password as context), so the token is tied to that one TLS session. Authentication runs on a one-way stream while relaying may already begin; the server holds commands that arrive before the check passes (sing-box gives it 3 seconds). The v4-style single token field must not be set for v5, since the versions are incompatible.
How TUIC differs from Hysteria2
Both ride QUIC. TUIC keeps standard congestion control and asks for no bandwidth figure, while Hysteria2 adds its own aggressive mode (Brutal) plus a website disguise and optional packet scrambling that TUIC lacks; the Hysteria2 glossary entry covers those.
Where TUIC runs
Cores include sing-box, mihomo, shoes and the tuic (Itsusinn fork) server; the list of implementations also names dae for Linux, the cross-platform ClashRS and closed-source Apple apps such as Surge. Of 377 services surveyed by VPNRadarLab, 2 say they support TUIC, 64 state they do not, and 311 say nothing, which means it is not published, not that it is absent. The list sits in the TUIC providers, clients and panels ranking.
Weak spots
Networks that drop UDP or throttle QUIC, such as hotel Wi-Fi, campus firewalls and some carriers, stop TUIC entirely; there is no TCP fallback, so configure one next to it. Failures are silent: the spec has no replies to commands, and how a server treats a failed authentication or an unreachable address is up to each implementation, so a broken profile often just hangs. The TUIC specification is worth reading before you debug anything.
TUIC FAQ
Is TUIC a VPN?
No, it is a relay protocol. A client in TUN mode can still route the whole device through it.
Is TUIC faster than Hysteria2?
On a clean line, comparable. When packets drop, Hysteria2 pushes harder by design.
Does TUIC need a domain?
A valid TLS certificate is required, and a domain is the easiest route to one.
TUIC in brief
TUIC v5 relays TCP and UDP through one encrypted QUIC connection using reply-free commands, two UDP relay modes (native and quic) with Full Cone NAT, a UUID-and-password login bound to each TLS session, and BBR as the go-to algorithm for lossy paths. It has no Brutal, no masquerade and no TCP mode: it dies wherever UDP is blocked.
Top services: TUIC
- StelsVPN4.79
- L×Box4.38
- Hiddify4.18
- 3X-UI4.09
- Hiddify Manager4.02