Hysteria2 Explained: QUIC Transport, Speed, and Network Conditions

What Hysteria2, QUIC, and UDP Each Do

In Shadowrocket, Hysteria2 is a protocol for connecting to a service you already have. It is not a network route or a subscription. A subscription supplies connection entries to the client; a protocol defines how the client and server authenticate and exchange data. Actual performance still depends on your network, server load, and the destination.

Think of the transport path in three layers: UDP carries datagrams; QUIC runs over UDP and provides encrypted connections, streams, and reliable transport; Hysteria2 defines proxy authentication and how application data is encapsulated. UDP itself does not guarantee delivery, but that does not mean reliable QUIC streams over UDP never retransmit. Applications such as web browsing still have to wait for lost data to be recovered.

For example, if your provider specifies port 443, check whether the corresponding UDP port is reachable. A successful connection to TCP on the same port number does not prove that UDP is available too. Use the port supplied for your existing service. Do not change a valid port to 443 just because it is a common example.

What “Faster” Really Means: Congestion Control and Stream Isolation

QUIC can carry multiple streams over a single connection. If one stream loses data, other streams usually do not have to wait for the missing bytes to be filled in before delivering their own data, as they would over a shared TCP byte stream. This reduces cross-stream head-of-line blocking, but gaps within a reliable stream still need to be recovered, and all streams still share the path's capacity and congestion limits.

Hysteria2 performance also depends on congestion control. Its bandwidth settings may influence the sending rate; bandwidth-driven Brutal and automatic path-capacity estimation work differently. Which approach is used depends on the client implementation, configuration, and server negotiation. The protocol name alone cannot tell you which algorithm the current connection uses.

• Random packet loss on the path: If loss is not caused by persistent congestion, suitable rate control may sustain higher throughput. Lost data still incurs recovery traffic and time.
• The path is already congested: Raising the target sending rate may increase queueing, jitter, and packet loss, making web pages respond more slowly.
• Multiple concurrent streams: Stream isolation may help some requests complete sooner, but it cannot remove bottlenecks on a shared wireless link.
• Short connections or small files: DNS, the handshake, and the destination's response time may dominate. Sustained download speed does not reflect how quickly a page opens the first time.

Pay attention to units when entering bandwidth: Mbps means megabits per second, while MB/s means megabytes per second—a factor of 8 difference. Even with a high advertised plan speed, your current wireless signal and shared uplink may offer much less usable capacity. Follow the unit shown in the client and the instructions for your existing service; do not treat the plan's maximum as your current measured speed.

Which Network Conditions Are Worth Testing—and What to Check First

High packet loss, long distances, and mobile networks are conditions to measure, not automatic reasons to use Hysteria2. First confirm that your local network allows UDP, then distinguish random loss, congestion-related loss, and server issues. All three can look like lag, but they call for different fixes.

QUIC includes mechanisms that support connection migration, but that does not mean every network switch in Shadowrocket will resume seamlessly. The result depends on the client implementation, server policy, address changes, and network intermediaries. On mobile networks, test staying on one network separately from switching networks. This helps avoid mistaking a failed transition for a general Hysteria2 connection failure.

Check Existing Hysteria2 Parameters in Shadowrocket

These steps assume you already have a service provider and connection parameters of your own. Keep your current working configuration, then check the protocol, address, port, authentication, and TLS details one by one. Connection parameters for different types cannot be converted just by changing Type; Hysteria and Hysteria2 must also be treated as different protocols.

1. Inspect the entry

   Go to Home, open the edit screen for an existing entry, and check that Type is set to Hysteria2. To add an entry manually, tap “+” in the upper-right corner of Home and choose Type according to your existing service instructions. Do not mistake the provider's name for the protocol type.

2. Check the connection details

   Check the service address, port, and authentication details character by character. The example address hy2.example.com and port 443 only illustrate how the fields relate; they are not a working service. Make sure authentication details do not contain leading or trailing spaces or line breaks.

3. Check TLS

   Check the TLS server name (SNI) and certificate requirements against your existing service instructions. The connection address and certificate name may differ. If you see a certificate error, first check the name and your device's date and time; do not routinely bypass certificate verification.

4. Check additional settings

   If the service uses obfuscation, confirm that the method and password were provided together; do not add them if the service does not use obfuscation. Enter bandwidth-related fields in the displayed units, and note the original values so you can restore them.

5. Connect and verify

   After saving, return to Home, select the entry, check Global Routing, enable the connection, and run Connectivity Test. Then visit a fixed test destination and record the test result separately from the actual request result.

How Global Routing Affects Protocol Tests

Selecting a Hysteria2 entry and having a request use that entry are not the same thing. Home → Global Routing determines the routing mode. In Config, a rule may send some requests through DIRECT, so successfully opening a web page does not by itself prove the Hysteria2 connection is working.

The minimal rule snippet below illustrates how matching works. It is not a complete configuration and does not point to a real test service. DOMAIN-SUFFIX matches a domain and its subdomains; FINAL handles requests that did not match an earlier rule. Put specific rules before the fallback rule.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

In this snippet, only requests to example.com and its subdomains match PROXY; all other requests go to DIRECT. If you tested a different domain, the result cannot be used to evaluate the proxy under test. On Demand controls when a VPN connection is established based on conditions; it is separate from the entry's protocol and a Rule's match scope. While troubleshooting, check the existing conditions under Settings → On Demand to make sure automatic connection behavior does not interfere with manual tests.

Track Consistent Test Conditions—Don't Judge by One Speed Test

Test connectivity, response time, and sustained transfers together. Connectivity Test is useful as an initial check, but its target and method may differ from your actual traffic, so its result is not a direct measure of download bandwidth. This guide gives no universal speed difference or packet-loss threshold because those figures only make sense when the test conditions are specified.

• Keep inputs consistent: Use the same device, network, server, and destination; pause other high-bandwidth tasks. Change one setting at a time.
• Repeat the test: Run each setup at least 3 times and record the number of successful runs, time to first response, and sustained transfer behavior. Do not keep only the best result.
• Record the route: Note Global Routing, the selected entry, the destination domain, and whether you switched networks, so you can confirm the result came from the path being tested.
• Keep a way back: If changing bandwidth or additional parameters increases failures, restore the previous values first, then check the network and server. Do not change several fields at once.

In your notes, record observable details such as “Wi-Fi, Config, destination matched PROXY, 3 successful tests, web response slowed after transfer began.” This is more useful for troubleshooting than “felt faster” and avoids mistaking a brief network fluctuation for a fixed protocol characteristic. When contacting your existing provider, share the necessary error details, but do not disclose authentication passwords or full subscription URLs.

FAQ: Handshakes, Certificates, and Network Switching