Hysteria2 & TUIC Protocols: Speed Boost for High-Packet-Loss Networks

If you've ever used Shadowsocks or VMess, you've probably hit this exact situation: the node reports just 80ms of latency, yet your actual download speed is only 2MB/s and videos buffer constantly. The problem usually isn't the node itself — it's the transport protocol. Traditional proxy protocols are built on TCP, whose performance falls off a cliff on high-packet-loss, high-latency networks. Hysteria2 and TUIC, a new generation of QUIC-based protocols, were created precisely to fix this pain point.

Why TCP Proxies Are Slow on High-Packet-Loss Networks

TCP is a reliable transport protocol, where every packet has to be acknowledged (ACK). When the network's packet-loss rate climbs, TCP's congestion-control algorithm lowers the send rate and triggers retransmissions, creating a vicious cycle. Worse still is TCP's "head-of-line blocking": when one packet is lost, every packet behind it has to wait for the retransmission to complete before it can be processed.

For proxy scenarios, TCP's drawbacks are even more pronounced:

Proxy traffic goes through extra encapsulation, so every TCP connection is "TCP over TCP," with the two layers of congestion control interfering with each other
International routes often have packet-loss rates of 5%–15%, where TCP throughput can drop below 30% of the available bandwidth
High latency magnifies the impact of packet loss — every retransmission has to wait a full RTT

That's why the same node might only manage 5MB/s on the SS protocol but break 50MB/s on Hysteria2.

QUIC: The Foundation of Modern Transport Protocols

QUIC (Quick UDP Internet Connections) is a UDP-based transport protocol proposed by Google, and it's now the standard transport layer for HTTP/3. Compared to TCP, QUIC's core advantages are:

0-RTT connection setup — reuses parameters from a previous connection, so reconnecting needs no handshake
No head-of-line blocking — each data stream is transmitted independently, so packet loss on one stream doesn't affect the others
User-space congestion control — not bound by the OS TCP stack, it can use bandwidth more aggressively
Connection migration — the connection stays alive across network switches (such as Wi-Fi to 4G)

Both Hysteria2 and TUIC are built on QUIC, but their design philosophies and optimization goals differ.

Hysteria2: Brute-Force Beauty

Hysteria2's core idea is to saturate the available bandwidth as much as possible. It uses the Brutal congestion-control algorithm — rather than relying on packet-loss signals to adjust the rate, it sends directly based on the bandwidth ceiling negotiated between client and server. This is extremely effective on high-packet-loss, high-latency routes.

Hysteria2's main characteristics:

Built on QUIC, with TLS 1.3 encryption and obfuscation built in
Brutal congestion control, maintaining high throughput even in high-packet-loss environments
Support for Port Hopping to counter UDP rate-limiting and blocking
Simple configuration, with both server and client easy to deploy
Relatively high demands on server bandwidth — it really will try to use up the bandwidth ceiling you set

An example Hysteria2 node config in Clash:

- name: "HY2-Node"
  type: hysteria2
  server: example.com
  port: 443
  password: your-password
  sni: example.com
  skip-cert-verify: false
  up: 50        # upload bandwidth, Mbps
  down: 200     # download bandwidth, Mbps

up and down are Hysteria2's key parameters, telling the Brutal algorithm your bandwidth ceiling. Set them too low and you waste performance; set them too high and you can make packet loss worse. We recommend starting at 70%–80% of your actual bandwidth and adjusting from there.

Hysteria2's up/down parameters are a client-side bandwidth declaration. They don't have to match the server config exactly, but they should be close to your actual network bandwidth.

TUIC: The Balanced Choice

TUIC (The Universal Implicit Congestion Control) is also built on QUIC, but it takes a different path. Developed by the author of the sing-box project, its design goal is to strike a balance between low latency and stability, rather than chasing maximum speed at all costs.

TUIC's main characteristics:

Built on QUIC, with native TLS 1.3 encryption
Uses standard QUIC congestion control (BBR/Cubic), behaving more "gently"
Supports UDP over Stream mode for better compatibility and stability
Supports 0-RTT handshakes for extremely fast connection setup
Relatively low server resource usage

An example TUIC node config in Clash:

- name: "TUIC-Node"
  type: tuic
  server: example.com
  port: 443
  uuid: your-uuid-here
  password: your-password
  sni: example.com
  alpn: [h3]
  skip-cert-verify: false
  congestion-controller: bbr
  udp-relay-mode: native

congestion-controller can be bbr or cubic. BBR performs better on high-latency routes, while Cubic is more conservative and stable. As a rule of thumb, start with BBR and switch to Cubic if you run into instability.

Hysteria2 vs. TUIC: How to Choose

Neither protocol is absolutely better — it comes down to your network environment and use case:

High-packet-loss, high-latency international routes → Hysteria2. The Brutal algorithm forces bandwidth utilization, with the most noticeable speed gains
Mid-quality networks where you want stability → TUIC. Standard congestion control is more predictable and less prone to issues over long sessions
Streaming and large downloads → Hysteria2. Higher peak throughput
Everyday browsing, social, and work → TUIC. Low-latency connection setup for a smoother experience
Limited server bandwidth → TUIC. It won't try to saturate your bandwidth the way Hysteria2 does
Ample server bandwidth → Hysteria2. It can turn that big-bandwidth advantage into real-world speed

In practice, many users keep nodes for both protocols in their subscription and switch flexibly based on current network conditions. Clash's url-test proxy group can automatically pick the lowest-latency node, but it can't automatically judge which protocol is faster on your current network — that takes a few manual tests to build up a feel for.

Optimizing QUIC Protocols in Clash

Make Sure Your Core Is New Enough

Both Hysteria2 and TUIC require Mihomo core support. Check the core version in your client settings; we recommend v1.18 or above for the best compatibility and performance.

UDP Connectivity

QUIC is built on UDP, so if your network blocks or rate-limits UDP traffic, both protocols will fail. Hysteria2's Port Hopping can mitigate blocking to some extent — by rotating among multiple ports, it lowers the chance of any single port being blocked:

- name: "HY2-Hopping"
  type: hysteria2
  server: example.com
  port: 443
  ports: 443,8443,2053,2083,2087,2096
  password: your-password

Pairing with TUN Mode

QUIC protocols work well under TUN mode, but you need to make sure DNS is configured correctly. We recommend using fake-ip mode and enabling udp support; otherwise some QUIC connections may fail due to DNS resolution issues.

Don't Over-Stack Obfuscation

QUIC already has TLS encryption built in, so there's no need to wrap another layer of obfs on top. An extra encapsulation layer only adds overhead and hurts performance. If you're worried about traffic fingerprinting, Hysteria2's Salamander obfuscation is already enough.

Common Troubleshooting

Node shows a timeout or won't connect

First, confirm whether UDP is getting through — run nc -u example.com 443 on the command line to test UDP connectivity. If UDP is blocked, contact your service provider to confirm whether TCP fallback is supported, or switch to a node using a TCP-based protocol.

Hysteria2 isn't reaching the speed you expected

Check whether the up/down parameters are set too low. Also note that the Brutal algorithm slows down significantly once the packet-loss rate exceeds 20% — that's not a flaw in the protocol but the physical limit of the route. Try comparing nodes on different routes.

TUIC disconnects frequently

Try changing congestion-controller from BBR to Cubic. If you're using udp-relay-mode: native, switching it to quic may also improve stability. Check whether the server limits the number of connections per IP.

Both protocols are slower than SS/VMess

This indicates your network environment isn't UDP-friendly, or the node server is simply too far away. QUIC's advantage only shows on medium-to-high-packet-loss routes — if your packet-loss rate is below 1% and latency is below 50ms, traditional TCP protocols may actually be more stable. Use a speed-test tool to compare different protocols on the same node and pick whichever is fastest in practice.

Conclusion

Hysteria2 and TUIC represent the shift in proxy protocols from TCP toward QUIC. Hysteria2 uses Brutal congestion control to chase maximum speed, making it ideal for high-packet-loss, high-bandwidth scenarios; TUIC uses standard QUIC congestion control to prioritize balance and stability, making it ideal for everyday use. Both require Mihomo core support, are simple to configure in Clash, and only need the corresponding node added to your subscription or config file.

We recommend keeping nodes for multiple protocols in your subscription and comparing them in your real network environment to find the protocol mix that suits you best. And don't forget to download the latest Clash client from our site to make sure your core version supports these new protocols.