Hysteria2 Protocol Guide: Why Is QUIC Fast, and Where Does It Work?

What QUIC changes

In Shadowrocket, Hysteria2 is a proxy protocol—not a routing mode or a speed-boost switch. It establishes an encrypted connection using QUIC over UDP, then carries requests for forwarding. UDP here describes the transport between the client and server; it does not make browser TCP requests unreliable.

QUIC handles acknowledgments, loss detection, and retransmission at its own protocol layer, and uses TLS 1.3 for the secure handshake. A single connection can carry multiple independent reliable streams. If data is missing from one stream, other streams generally do not have to wait for the same transport-layer byte sequence to be completed. This reduces head-of-line blocking across streams, though data within each stream must still be delivered in order, and congestion on the shared link can still affect every stream.

Use the port provided by your service provider. A network allowing access to HTTPS websites over 443/TCP does not necessarily allow 443/UDP. Firewalls can apply entirely different rules to these transport protocols, so there is no contradiction if websites work but the Hysteria2 handshake times out.

Why it may be faster with packet loss

Performance depends on more than QUIC: Hysteria2's congestion control and bandwidth negotiation also matter. Traditional loss-based congestion control may treat random packet loss as congestion and reduce the sending rate. In conditions such as wireless interference, where loss is not caused by congestion, Hysteria2's bandwidth estimation and sending controls may sustain higher throughput. Actual behavior depends on the client and server configurations and what the two sides negotiate.

This does not mean that Hysteria2 “ignores all packet loss.” If loss is caused by a saturated link, sending more data can increase queues, retransmissions, and latency. High-latency networks need more data in flight to fill the link, but no protocol can shorten the physical distance or exceed the server's egress capacity or plan limits. Faster downloads do not necessarily mean lower gaming latency.

• Random packet loss: Sporadic loss caused by factors such as wireless interference does not necessarily mean the path has reached capacity. This is a scenario worth testing against alternatives.
• Congestion-related packet loss: If latency keeps climbing during downloads and other devices slow down at the same time, reduce the load first instead of raising the sending target.
• UDP throttling: The connection may establish but remain throughput-limited over time. Changing ports may not help, and you should not bypass the network's policies.
• Server bottleneck: If egress capacity, CPU, or server-side policies are limiting performance, changing protocols on the client cannot create more resources.

Networks worth testing

To decide whether Hysteria2 is a good fit, consider connection success rate, sustained throughput, and interactive latency together. It may be worth testing on cross-region links, cellular networks, or wireless connections with random packet loss. Switching to it may offer little benefit on a low-latency, low-loss network where the egress link is already saturated. On guest networks that restrict UDP, check the network's policies first; repeated retries are not a solution.

Do not judge a protocol based on a single latency test. A short probe mainly reflects reachability and response time at that moment; it does not show how stable a sustained transfer will be. Pause other high-bandwidth tasks during testing and note the network type. Otherwise, differences between Wi-Fi and cellular may be wrongly attributed to the protocol.

Set up Hysteria2 in Shadowrocket

These steps use the Home screen on iPhone and iPad; screens may differ on other platforms. Get server details, ports, credentials, and subscription links from your service provider. Hysteria2 and Hysteria are different protocols with different settings. Make sure you select the correct Type.

1. Check the connection details

   First, confirm the protocol is Hysteria2. Have the Server, Port, and Password ready, along with any SNI, bandwidth, and obfuscation settings required by your service provider. The port might be 443, for example, but do not assume that is the port for your connection.

2. Select the protocol

   Go to Home → tap “+” in the top-right corner → Type → Hysteria2, then enter the connection details. Do not select Trojan or another protocol just because it also uses TLS.

3. Check authentication

   Enter the complete Password provided by your service provider. If the value contains a separator, keep its original format. Do not split it into a username and password, or use a token from a subscription link as the connection password.

4. Check security settings

   The SNI should match the server certificate and your service provider's instructions. If you use an IP address for Server, you may still need to enter a domain name for SNI. Keep certificate verification enabled. If you see a certificate error, check the domain, device time, and certificate chain first.

5. Save and test

   After saving, return to Home and select the entry. Run a brief comparison with Global Routing → Proxy. Once you confirm requests are using the selected connection, return to Global Routing → Config to check your usual rule-based routing.

If you already have a subscription, go to Home → “+” → Type → Subscribe and enter the subscription link from your service provider. Save it, update the subscription, and check the Type of the imported entries. A subscription distributes configuration; it does not guarantee that the server is online. A failed subscription update and a failed Hysteria2 connection are different issues—check the subscription URL and connection details separately.

How routing modes affect testing

Hysteria2 determines how a connection transports data; Global Routing determines which requests are sent through a proxy. These are separate layers. A working connection does not mean every website will use it. The comparison below describes Shadowrocket routing behavior, not protocol performance rankings.

Scene in Global Routing sets routing behavior for different scenarios; it is not a fourth proxy protocol. When troubleshooting, first check what the active scene actually does. Settings → On Demand manages connections triggered by conditions; it does not select Hysteria2 or replace routing rules. If the connection state changes on its own during testing, check for On Demand triggers as well.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

This is a rule syntax example, not a complete Config. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches by the region associated with an IP address, and FINAL is the fallback. Rules are generally checked in order. PROXY here is a policy, not the name of the Hysteria2 protocol; the connection ultimately used depends on the policy selection. Check the request log for the destination, matched rule, and selected policy so you do not mistake a direct-connection speed test for a protocol test.

Find the cause with repeatable tests

For a useful comparison, keep the client device, server, test resource, and testing time consistent. If your service provider offers comparable connection options, use the same exit where possible. Speed differences between different exits do not prove that one protocol is better. The suggested durations and number of runs below are testing tips, not performance guarantees or measured results.

• Establish a baseline: Pause background downloads and note whether you are on Wi-Fi or cellular, the current routing mode, the selected entry, and the test resource. First confirm the destination is reachable.
• Run three rounds: Transfer data continuously for about 60 seconds per round. Record the sustained rate, any interruptions, and how quickly web pages respond during the transfer—not just the initial peak.
• Change one setting at a time: Start with your service provider's default settings. If you need to make an adjustment, change just one upload or download target, then repeat the same test.
• Identify where the error occurs: For a handshake timeout, check UDP and the port. For an authentication failure, check Password. For a certificate error, check SNI, the certificate chain, and device time. If connected but experiencing slowdowns, check congestion and egress capacity.
• Restore your usual configuration: When testing is complete, return to Global Routing → Config, review your routed requests, and confirm that On Demand is set as before.

If you need to report an issue to your service provider, share the network type, where the failure occurs, when it happened, and redacted logs. Do not share a full subscription URL, Password, or a link containing a token publicly. If the same configuration only fails on one network, include a comparison with a network where it works. This is usually more helpful than repeatedly changing every field.