Hysteria2 is a TCP and UDP proxy protocol built on QUIC, a secure transport that normally runs over UDP. It carries application requests to a remote forwarding server; its transport choice does not automatically capture all device traffic or guarantee faster connections on every network.［1］［4］

Key Takeaways:

A proxied TCP application stream can travel inside an outer QUIC/UDP connection.

Authentication precedes proxy requests; an ordinary HTTP/3 response is not proxy success.

Congestion control depends on direction, bandwidth information, and implementation settings.

A failure can belong to transport, identity, authentication, forwarding, or local integration.

How does a Hysteria2 QUIC proxy carry traffic?

The client takes an application's proxy request and sends it through a QUIC connection to a Hysteria server. After authentication, the server handles the requested onward connection and returns the response through the protected link. The destination does not need to implement Hysteria simply because the client uses it.［1］

The two inner paths in the figure describe application traffic. The enclosing path describes the client-to-server transport. This distinction prevents a common mistake: a TCP website request can still depend on UDP being usable between the proxy client and server.

The application and outer transport are separate layers

QUIC supplies streams within a connection and has its own loss recovery and connection management. A reliable stream and an unreliable datagram do not provide the same delivery behavior. These properties belong to QUIC; the meaning of a Hysteria authentication or proxy request belongs to the protocol above it.［1］［4］

The protocol and transport layer guide separates those names, while the VPN fundamentals overview explains why forwarding and device-wide traffic capture are different responsibilities. Neither the use of QUIC nor the word “proxy” answers whether all your applications enter the client.

What does authentication establish?

The protocol uses an HTTP/3 authentication exchange before allowing proxy requests. Its specified success response is status 233; the server also reports whether it supports UDP relay and communicates receive-rate information. A client must treat any other status as authentication failure and disconnect.［1］

A web response is not an accepted proxy session

Without accepted credentials, the server is supposed to handle the request as ordinary web traffic or forward it to a configured upstream web service. This gives unauthenticated traffic a web-facing behavior. It does not grant forwarding permission, and a normal page or HTTP response is not evidence that proxy authentication succeeded.［1］

TLS peer verification within the QUIC connection and proxy authorization are also different checks. Reaching an address, establishing a protected connection to the expected peer, receiving an accepted authentication response, and successfully contacting a destination are distinct milestones. A screenshot of a connect button cannot replace evidence of which milestone was reached.

Treat credentials and client profiles as sensitive. An endpoint needs enough destination information to forward the request, and transport encryption does not remove that endpoint from the trust model. Avoid publishing complete profiles or logs with passwords, account identifiers, and private destinations when explaining a failure to someone else.

How are TCP streams and UDP datagrams forwarded?

For a TCP request, the client opens a bidirectional QUIC stream, supplies the target address, and awaits the server's proxy response. If forwarding succeeds, that stream carries application bytes; a proxy error closes that stream. Multiple application streams can therefore have distinct outcomes within the same outer connection.［1］

Datagram delivery keeps a different contract

For UDP relay, the protocol uses QUIC's unreliable datagram extension and adds destination and session information. Oversized application datagrams must be fragmented or discarded; incomplete fragment sets cannot yield a complete application packet. An idle relay session can be retired by the server, so keeping an identifier locally does not guarantee its remote state persists forever.［1］

Loss on a datagram path is not automatically repaired by the same stream delivery semantics used for proxied TCP. A call, game, or DNS request may therefore expose a different failure from a large TCP download. Also, a server may decline UDP relay even though QUIC transport itself uses UDP.

These distinctions are especially useful when someone says “UDP works.” They might mean the network admits outer QUIC packets, the server accepts relay datagrams, or the destination application receives them. Record which meaning was tested; success at one layer cannot certify all three.

How does Hysteria2 congestion control affect speed?

Hysteria2 congestion control governs how an endpoint sends data over the client-to-server path. The current official server documentation describes adaptive BBR and Reno modes, alongside the rate-driven Brutal mode. Selection depends on bandwidth information and server policy, and upload and download need not use the same controller. These are implementation details that can change with releases.［3］

A rate target does not create capacity

Brutal relies on a specified rate and compensates for observed loss; a target beyond what the connection can actually carry can waste traffic and cause instability. An adaptive controller instead adjusts using its observations. Neither approach is evidence that a remote server, access network, or device can deliver a promised speed.［3］

Consider a shared connection during a video call and a background download. The useful outcome is responsive foreground traffic and a sustainable transfer rate, not the largest configured number. A preset copied from another network gives you no measurement of spare capacity on this one, and a controller choice cannot remove a CPU bottleneck.

The official performance guidance identifies endpoint processing, network quality, socket buffers, flow-control windows, and scheduling as possible bottlenecks. QUIC processing in userspace can matter on low-power devices. Those are reasons to identify the constrained resource before attributing a result to the protocol name.［2］

When assessing an AethoVPN connection on the same device, compare the actual application outcome with a controlled baseline through the connection testing guide; a Hysteria bandwidth hint is not a measurement of that managed service's capacity. Keep network, device, time, and workload comparable so a change in conditions does not masquerade as a protocol result.

What does Hysteria2 UDP transport require?

The ordinary Hysteria2 UDP transport needs a usable UDP path between client and server for its QUIC connection. If that path cannot carry the required packets, putting a TCP application inside the proxy does not make the outer connection TCP. Do not assume automatic TCP fallback from the name of the application being forwarded.［1］［4］

Filtering is only one possible cause

A timeout can result from routing, a firewall, endpoint unavailability, loss, or a mismatch between the expected and actual configuration. A reduced transfer rate can also reflect queueing or resource limits. These symptoms do not, by themselves, establish deliberate filtering or a defect in QUIC.

Optional packet camouflage changes packet presentation; it is separate from transport reachability and from the encrypted connection's trust properties. It does not guarantee that a network which rejects all relevant UDP packets will allow them. Network-specific claims still require bounded, dated observations rather than universal language.

The explanation of QUIC blocking and its evidence limits addresses that narrower diagnostic question. This definition does not prescribe camouflage settings, deployment parameters, or methods for circumventing an organization's restrictions.

Which failure layer should you name?

A useful report identifies the last established stage and the first missing result. This table maps symptoms to possible layers rather than asserting a single cause. The categories come from the connection flow, so they apply even when a client uses its own wording for status messages.

Failure layer	Possible explanation	Conclusion you cannot draw from it alone
Outer connection times out	UDP reachability, server availability, routing, loss, or settings mismatch	QUIC is deliberately blocked everywhere
Peer identity verification fails	Unexpected certificate identity, trust policy, clock, or endpoint	Authentication credentials are necessarily wrong
Protected connection succeeds but authentication is rejected	Credential or authorization mismatch	The destination website is unavailable
Authentication succeeds but one TCP request fails	Target reachability, name resolution, or forwarding policy	The entire outer connection is unusable
TCP works but application UDP does not	Missing client integration, disabled relay, or datagram-path problem	QUIC's underlying UDP is completely unavailable
Transfer is slow	Network, CPU, buffers, flow control, scheduling, or rate assumptions	Hysteria2 is universally faster or slower than another protocol

A definition is not a benchmark

The Hysteria2 and VLESS/REALITY comparison develops the separate choice between connection models. The broader protocol overview places that choice alongside coverage, trust, and client support. Neither turns an isolated successful transfer into a universal ranking.

For a meaningful comparison, disclose the date, access network, endpoint, client build, traffic type, direction, and measurement method. Separate connection setup from sustained throughput and application responsiveness. Without those conditions, a speed number lacks enough context to tell another reader what to expect.

Summary

Hysteria2 forwards TCP and UDP application traffic over a protected QUIC connection.
Outer UDP reachability, authentication, and application forwarding have independent failure boundaries.
Brutal is one controller choice, not a property of every deployment or a speed guarantee.
Use layered observations to explain a failure; client coverage and endpoint trust still need checking.

FAQ

Is Hysteria2 a VPN protocol?

Hysteria2 specifies a proxy exchange over QUIC, rather than automatic device-wide IP routing. A client can add capture and routing features around it. Those integration choices determine coverage, so the protocol label alone does not establish a whole-device VPN connection.

Why can a TCP application need UDP?

The application's TCP stream travels through the proxy's outer QUIC connection, which ordinarily runs over UDP. Application traffic type and proxy transport are separate layers. A network that prevents that outer path can disrupt a TCP request carried inside it.

Does Hysteria2 always use Brutal?

Hysteria2 does not necessarily use Brutal in every deployment or both directions. Bandwidth information, server policy, and implementation settings determine controller selection. Check the documentation for the actual release instead of assuming an old preset describes the current connection.

Does a larger bandwidth value make it faster?

A larger rate target does not increase the physical capacity of a path. An unrealistic Brutal target can waste traffic and destabilize the connection. Compare sustained application behavior under controlled conditions rather than treating a configured value as measured throughput.

Does QUIC mean the server supports application UDP?

Using UDP for the outer QUIC connection does not establish that the server permits UDP relay for applications. The authentication response advertises relay support, and client integration must carry the application's datagrams. Test that application path separately from a TCP request.

Does an HTTP/3 webpage prove authentication succeeded?

An ordinary HTTP/3 page can be the server's unauthenticated web behavior. Hysteria specifies its own authentication success response before proxy requests are accepted. A reachable webpage therefore does not establish proxy authorization or destination forwarding.

Can a timeout prove Hysteria2 is blocked?

A timeout alone does not identify deliberate blocking. Routing, loss, an unavailable endpoint, or configuration mismatches can produce the same symptom. You need evidence that distinguishes the outer transport from identity, authentication, and destination failures before naming a cause.

Disclaimer: This explanation uses public protocol and implementation documentation, not a speed test or deployment prescription. Follow applicable laws and network policies; confirm behavior against the documentation for your actual release.

Sources

Sources checked 5 October 2026.

What Is Hysteria2? The QUIC-Based Proxy Explained