Hysteria2 Protocol Guide: Why QUIC Is Fast and Where It Works

Hysteria2 and QUIC: The Transport Layer vs. the Proxy Protocol

Hysteria2 is a proxy protocol built on QUIC. QUIC typically runs over UDP and uses TLS 1.3 to establish an encrypted connection. UDP sends datagrams but does not guarantee delivery or ordering. QUIC adds connection management, reliable streams, loss detection, and congestion control. So using UDP does not mean that data is never retransmitted, nor does it bypass bandwidth limits.

For proxied TCP connections, Hysteria2 carries data over QUIC's reliable streams. UDP forwarding uses datagrams; reliable-stream retransmission behavior does not apply to all UDP traffic. Whether an application tolerates packet loss depends on its own protocol. Web traffic and real-time voice can behave differently even when they use the same server.

If the server is configured for UDP 443, allowing only TCP 443 is not enough to connect. The same port number does not mean the same transport protocol. Use the port specified in your existing configuration. Do not replace it just because 443 is common, and do not combine an address, password, or port from another protocol to create a Hysteria2 configuration.

Why It Can Be Faster: Independent Streams, Congestion Control, and Loss Recovery

One feature of QUIC is that its streams operate independently. If data is lost on one stream, other streams do not have to stop delivering data just because that stream is waiting for recovery. This reduces head-of-line blocking between streams, but not the ordering delay within a reliable stream. Streams still share link capacity and usually share connection-level congestion control. Packet loss can still slow things down.

Hysteria2 throughput also depends on its congestion control. Its Brutal mechanism adjusts sending behavior based on a target bandwidth and feedback. On links with random packet loss, it may sustain throughput better than a conservative rate reduction. Whether this mechanism is used, and how bandwidth settings factor into negotiation, depends on the client implementation, server policy, and configuration. Not all performance gains come from QUIC, and target bandwidth is not the same as the bandwidth actually available.

If the interface offers bandwidth fields such as Upload and Download, start with the values in your existing configuration or those explicitly provided by your service provider, and check the units. Mbps and MB/s are different: 8 Mbps is about 1 MB/s. Actual throughput is lower after protocol overhead. Setting values far above your connection's capacity may only increase router queueing, making calls noticeably lag while downloads are running.

Where It May Help: Random Packet Loss; Check UDP Reachability First

Wireless interference on mobile networks, jitter on long-distance links, and changing access-point load can all affect performance. Hysteria2 may be worth testing in some of these conditions, but a mobile network does not guarantee better performance. Server egress, the destination website, wireless signal, and local upload usage can all be bottlenecks unrelated to protocol choice.

• Random packet loss, with UDP reachable: Check whether sustained downloads repeatedly slow down and whether interactive requests remain responsive. Record latency both when idle and under load; do not judge by peak speed alone.
• High latency and ample link capacity: Sending control and loss recovery affect bandwidth utilization, but a slow link between the server and the destination can still limit results.
• Low latency and little packet loss: You may not notice a meaningful difference. Keeping the configuration simple and certificate verification enabled matters more than choosing a particular protocol name.
• UDP blocked or consistently rate-limited: You may see handshake timeouts or brief connections followed by stalls. Check network policy first; repeatedly increasing bandwidth settings will not fix reachability.
• Switching between Wi-Fi and cellular: Check the connection status again after switching. QUIC supports connection migration, but continuity depends on the implementation and network conditions; an uninterrupted session cannot be guaranteed.

Add Hysteria2 to Shadowrocket Using Existing Server Details

These steps cover manual setup in Home. Have the server address, port, authentication password, SNI required for TLS, and any other parameters specified by the server. Address and SNI can differ: Address determines where to connect, while SNI supplies the server name during the TLS handshake. Certificate name verification must also match the configuration requirements.

1. Check the source

   Open the server instructions you already have and confirm that the protocol is explicitly Hysteria2. Do not treat Hysteria and Hysteria2 as interchangeable Types or mix authentication fields from another protocol.

2. Choose the type

   In Home, tap “+” in the upper-right corner, then select Hysteria2 under Type. Return to the add-server screen. If the option is not shown in your client, check the download page on this site for the current platform's download options; do not choose a similarly named type instead.

3. Enter connection details

   Enter the existing Address, Port, and Password. Put only the server address requested by the field in Address, and use the specified port. Do not paste an entire share link into the address field or add extra spaces.

4. Check security settings

   Enter the configured SNI and keep certificate verification enabled. If your existing settings include obfuscation or bandwidth values, confirm the corresponding fields in the client before entering them. Do not guess values for optional fields that are not specified.

5. Save and test

   After saving, return to Home, select the server you added, and check the current Global Routing mode. Enable the connection and approve any system prompts. Test a known reachable destination first, then try a sustained transfer.

If you already have a subscription, go to Home → “+” → Type → Subscribe to import your own subscription URL. Save it, update the subscription, and confirm the protocol type of the imported entry. Subscription updates may overwrite ports, authentication details, or other parameters in managed entries. Before making changes you need to keep, check whether the entry is managed by the subscription; local edits may not persist.

For certificate errors, check the SNI, server certificate validity period and chain, and device time. Disabling verification changes the identity assurance provided by the connection and is not a routine fix. For authentication failures, first check that the Password was copied in full and that the server still accepts it. Do not attribute an authentication problem to QUIC packet loss.

Check Global Routing: Distinguish Protocol Problems from Unmatched Rules

Correct server details do not mean every request will use that server. Shadowrocket's Global Routing controls routing behavior: Config uses the rules in the active configuration, while Proxy can help narrow down troubleshooting temporarily. These modes affect traffic handled by the client; they do not prove that all system traffic on the device follows the same path.

Scene in Global Routing provides scenario-based routing settings; it is not a fixed equivalent of Config, Proxy, or Direct. Check which settings are actually active when troubleshooting. Also note the status of Settings → On Demand: an on-demand connection may be triggered again during testing, making it appear that the connection was disabled and then unexpectedly reconnected.

In Config, rules are usually checked in order, and the first match determines the policy. The example below shows only the syntax for DOMAIN-SUFFIX and FINAL; it is not a complete configuration to import. example.com is a documentation example, not a server provided by this guide. Policy names in your actual configuration must exist.

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

If the destination domain does not match the first rule, it falls through to FINAL,DIRECT. Whether the destination loads successfully does not by itself indicate the status of Hysteria2. Other configurations may use GEOIP or IP-CIDR for IP matching; DNS results can also affect decisions involving domain resolution. See the settings reference for details and proxy mode guide for routing behavior.

Troubleshooting and Comparison Notes: Change One Condition at a Time

Before testing, note the network type, selected server, Global Routing mode, destination, and test period. Keep the destination and server the same while testing over Wi-Fi and cellular. To compare protocols, use only configurations you already have with comparable server conditions. Speed differences between different servers cannot be attributed to protocol alone.

• Make tests repeatable: Run each condition three times in a row. Record whether the connection succeeds, how long it takes to respond, and whether sustained transfers are interrupted. Use the middle result as a reference rather than picking only the fastest run.
• Keep the load consistent: Pause system updates and other high-traffic tasks while comparing results. Speed tests can be limited by the destination server and are not the sole measure of link capacity.
• Separate failure types: Handshake failures, authentication failures, unmatched rules, and destination-site failures are different issues. Record them separately instead of labeling everything “slow protocol.”
• Protect configuration details: When contacting your existing service provider, describe the error category and network conditions. Redact passwords, subscription URLs, and identifiable server information from public reports.