Hysteria2 Protocol Explained: QUIC Congestion Control and Network Compatibility

1. How Hysteria2 Relates to QUIC and UDP

Hysteria2 is a proxy protocol, QUIC is its underlying transport, and UDP carries QUIC packets. These terms describe different layers; Hysteria2 does not simply “switch all requests to UDP.” TCP connections from apps can be forwarded through Hysteria2 QUIC streams, while app UDP traffic is forwarded using the corresponding datagram mechanism.

QUIC uses TLS 1.3 to establish an encrypted connection and provides independent streams. If data is lost on one stream, other streams do not have to wait for the same missing byte as they might when multiple requests share a single TCP byte stream. However, data within each stream must still be delivered in order, and streams share path capacity and congestion control. Packet loss can therefore still affect other requests.

Hysteria2 relies on UDP for its outer connection. Using HTTPS for web traffic does not mean the network will allow this proxy connection. A network may allow TCP 443 but restrict UDP 443; reachability must be checked separately, even when the port number is the same.

2. How Congestion Control Affects High-Loss Links

Congestion control determines when and how fast a sender transmits data. Traditional loss-based algorithms often treat packet loss as a sign of congestion and reduce the sending rate. But wireless interference and fluctuating links can also cause packet loss. If loss does not mean the path has run out of capacity, an overly cautious rate reduction may leave available bandwidth unused.

Hysteria2 can use Brutal congestion control, adjusting its sending rate based on the configured bandwidth target and observed packet loss. It does not ignore packet loss; instead, it attempts to compensate for lost data to keep effective throughput near the target. QUIC streams still rely on acknowledgments, retransmissions, and other mechanisms for reliability, so “congestion-control compensation” does not mean lost data never needs to be recovered.

• Random loss with capacity still available: With a reasonable bandwidth target, Brutal may sustain higher throughput than algorithms that sharply reduce their rate in response to packet loss.
• Actual congestion: If the bottleneck link is saturated, raising the target rate further may increase queuing, packet loss, and interactive latency.
• Changing capacity: Available capacity on cellular networks varies with signal strength and network load. A fixed target may be reasonable at one time and too high at another.
• Algorithm negotiation: Hysteria2 also has operating modes that use BBR. The exact behavior depends on the client implementation, bandwidth settings, and server negotiation; the protocol name alone does not tell you which algorithm is currently in use.

Also distinguish Mbps from MB/s: Mbps usually means megabits per second, while MB/s means megabytes per second. Using decimal units, 80 Mbps is about 10 MB/s, before protocol overhead. Check what the field expects; do not enter the MB/s figure shown by a download manager as though it were Mbps.

3. Check an Existing Configuration in Shadowrocket

Your Hysteria2 configuration in Shadowrocket should come from connection details you already have. In Home, open the relevant entry for editing and check the protocol type and server parameters. If the entry was created from a subscription, note the original values before making manual changes; a later update may overwrite them. The interface may change, and the English labels below identify parameter meanings, not a guaranteed field layout across versions.

Server and SNI can serve different purposes: Server determines where to connect, while SNI indicates the server name during the TLS handshake and is usually checked against the certificate name. If you use an IP address as the connection destination, you may still need to set the domain name that matches the certificate. For certificate errors, first check the device clock and domain name rather than repeatedly changing ports.

1. In Home, make sure the selected entry is the Hysteria2 configuration you intend to test. This avoids editing one entry and connecting through another.
2. Temporarily select Proxy under Global Routing to reduce interference from routing rules. Note the original setting and restore it after testing.
3. Connect and visit the same test destination each time. Record whether it opens, the time to first response, and sustained transfer performance.
4. If you update a subscription, recheck the protocol type, port, and bandwidth fields afterward to make sure the test uses the intended configuration.

4. Check Routing Before Deciding Whether the Protocol Is Working

An entry supporting Hysteria2 does not mean every request uses it. Direct under Global Routing bypasses the proxy; Config routes requests according to the current rules; Proxy is useful for proxy-routing tests; and Scene must be checked against the active scene settings. Fix the routing mode first when troubleshooting. Otherwise, “switching protocols made no difference” may simply mean the request is still going direct.

The minimal rule snippets below illustrate matching order; they are not a complete connection configuration. PROXY is a policy target, not a Hysteria2 rule keyword. Check the current selection and configuration to see which outbound connection it uses.

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

• DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains. The reserved example domain is used here only to explain the syntax.
• An IP-CIDR rule sends the specified private address range directly; no-resolve prevents DNS resolution solely for matching this rule.
• GEOIP,CN,DIRECT matches against an IP geolocation database. The result depends on the destination IP and database contents; it does not indicate where a domain is registered.
• FINAL,PROXY is the fallback when none of the preceding rules match. Rules are evaluated from top to bottom, so put more specific exceptions before the fallback.

Settings → On Demand controls when automatic connections are triggered. It does not select Hysteria2 for a domain or change the order of the rules above. To observe a repeatable connection, note your On Demand settings, then run the test manually. This helps keep automatic reconnects triggered by network changes from getting mixed up with configuration issues.

5. Networks Worth Testing and Factors That Limit Performance

To test Hysteria2, the target UDP port must be reachable and you must already have a matching server configuration. High-latency links with non-congestion-related packet loss and spare bandwidth are worth testing for throughput. If the bottleneck is local Wi-Fi, server egress, or a speed limit on the destination website, the protocol cannot remove that limit.

1. Keep comparison conditions consistent: Use the same device, network, and destination file, and test at roughly the same time. Do not update a subscription or change several parameters at once.
2. Separate connection setup from sustained transfer: Record whether the handshake completes, then measure sustained downloads. A connectivity test only shows that a particular probe succeeded; it does not replace a full throughput measurement.
3. Check latency under load: Check web response times while downloading. If throughput improves slightly but interactions become noticeably sluggish, the bandwidth target may be too high or queues may be congested.
4. Retest on another access network: If the same configuration fails on Wi-Fi but works on cellular, the difference may point to UDP policies, NAT, or path quality on the access network. It does not prove the configuration is correct.
5. Change one setting at a time: Check reachability first, then authentication and certificates, and adjust bandwidth last. Restore the same test conditions after each change.

6. Common Questions and What to Check

Start by verifying UDP reachability, then check authentication, certificates, and routing. Only after that should you assess congestion control and bandwidth targets. Record throughput, latency, and failures under consistent test conditions to determine whether Hysteria2 suits the current path. Shadowrocket is a closed-source commercial app; purchasing the app does not include a network service plan. This site does not provide, sell, or recommend nodes or subscriptions.