Hysteria2 is worth testing on networks where UDP is reachable, round-trip latency is high, or packet loss is sporadic—but the protocol name alone says nothing about speed. For users with their own provider configuration and subscription, this guide explains QUIC’s transport model, then walks through importing the configuration into Shadowrocket, checking routing, and retesting to distinguish incorrect settings, UDP restrictions, and rule mismatches.
1. Hysteria2 and QUIC: Where the Benefits Come From
Hysteria2 in Shadowrocket is a proxy protocol option. It uses QUIC as its transport, which runs over UDP and uses TLS 1.3 to establish a secure connection. Keep two points in mind: using UDP underneath does not mean all application data is sent unreliably; QUIC can provide ordered delivery, loss recovery, and flow control for streams over UDP.
When multiple application requests share one ordered byte stream over a traditional TCP connection, packet loss in one place can hold up delivery of subsequent data. QUIC manages delivery for separate streams independently, so a missing packet on one stream does not necessarily make other streams wait. Streams may still share congestion control and link capacity, though, so “less blocking between streams” does not mean “packet loss has no impact.”
- UDP: Carries datagrams but does not guarantee reliable delivery or automatically bypass network throttling.
- QUIC: Handles connection management, secure handshakes, and multiple streams at the transport layer; data within each stream is still delivered in order.
- Hysteria2: Uses QUIC to carry proxy traffic, with throughput-oriented congestion control and bandwidth configuration mechanisms.
- Real-world performance: Also depends on wireless signal, link congestion, server load, the destination, and configuration settings.
Hysteria2’s throughput advantage on some links with sporadic packet loss is also related to its bandwidth-driven congestion control; not every QUIC connection will produce the same results. Client bandwidth settings, server limits, and negotiated parameters all affect behavior. “Uses QUIC” cannot be translated into a fixed percentage speed increase.
2. High Latency and Packet Loss: Identify the Bottleneck First
High latency means it takes longer for a request to reach its destination and for a response to return. Hysteria2 cannot eliminate round-trip time caused by physical distance, but it may sustain higher throughput on suitable links. Packet loss also needs context: random loss caused by wireless interference and loss caused by persistent queue congestion do not call for exactly the same response. When a network is already congested, simply sending more data can make calls, browsing, and other devices’ connections worse.
| What you observe | What it may indicate | How to test |
|---|---|---|
| Small pages load normally, but large downloads are slow | Could be packet loss, congestion, or limited bandwidth at the other end; latency alone won’t tell you. | Use the same file, server, and network; repeat the transfer and record how long it takes. |
| Latency is normal when idle but spikes during downloads | Queues may be building up on the link; aggressive sending settings can make it worse. | Pause other high-bandwidth activity, lower the bandwidth setting, and compare again. |
| Wi-Fi fails, but cellular works | The Wi-Fi network may restrict UDP, or use different DNS or egress policies. | Keep the configuration unchanged, switch networks, and compare DNS resolution and handshake results. |
| The first request is slow, but sustained transfers are normal | Check DNS, connection setup, and the destination’s response separately. | Record the time to the first page load separately from subsequent transfer performance. |
Takeaway: Change One Variable at a Time
Differences are meaningful only when the server, destination, and routing path stay the same and you change just one setting or network. Don’t change the subscription, DNS, and Global Routing all at once, then attribute the improvement to Hysteria2.
Use a consistent test plan: on each network, transfer the same resource three times for about 60 seconds each. Record the data transferred, duration, interruptions, and time of day. This is a retesting method, not product performance data. A single peak result or latency reading cannot show that a protocol is better suited to your network.
3. Import and Check Hysteria2 in Shadowrocket
Start with a subscription or complete configuration you already have. Hysteria2 requires server support; changing an existing server’s Type to Hysteria2 is not enough. After importing, check Address, Port, authentication details, and TLS settings. When the subscription includes all the necessary fields, keeping them unchanged is usually more reliable than filling them in from guesswork.
-
Import an existing subscription
Open Home → tap “+” in the upper-right corner → Type → Subscribe, then paste and save your existing subscription URL. Subscription URLs contain access credentials; don’t post them in screenshots or troubleshooting notes.
-
Check the protocol type
Return to Home, open the imported server’s edit screen, and confirm that Type is Hysteria2. If the subscription does not include this type, check with the provider of your existing configuration instead of changing the type yourself.
-
Check connection details
Check Address, Port, authentication details, and SNI one by one. Port must match the remote listening port; enter 443, for example, only when the remote server specifically uses it. It is not a universal default.
-
Keep the test path consistent
In Home, select the server you want to test, then open Global Routing → Proxy. Connect and test the same destination. If you use a policy group, confirm which member is actually selected so you don’t end up testing a different server.
-
Restore your usual settings
After testing, restore Global Routing to the Config setting you normally use and revisit the destination. If Proxy works but Config does not, check rules and policy groups before changing transport settings.
SNI specifies the server name during the TLS handshake and should match the original configuration. When the connection address is an IP, you may still need to specify the domain name used by the certificate separately. If you see a certificate error, check the server name, certificate validity, and device time rather than weakening certificate verification. If the configuration includes obfuscation parameters, they must match on both client and server; enabling them on one side alone will not fix an unreachable UDP path.
4. Global Routing: Separate Transport Issues from Routing Issues
Global Routing determines how requests select an outbound path; it does not make a protocol faster. A common troubleshooting mistake is to select a Hysteria2 server without confirming that the request actually uses it. The options below describe routing behavior in Shadowrocket. Config is recommended for everyday use when its rules are correct, but that does not mean it is the only option for troubleshooting.
Config: Route by configuration rules
RecommendedRequests are handled according to the rules in the active configuration. A destination may go DIRECT, through a proxy, or to a policy group; selecting a server does not mean every request will use it.
Best for: Everyday connections with verified rules.
Proxy: Test the proxy path
Routes requests controlled by this mode through the proxy, temporarily reducing rule matching as a variable. Still check which server or policy group member is actually selected.
Best for: Checking whether the server connects and ruling out a mismatched rule.
Direct: Establish a direct-connection baseline
Uses a direct path without the selected proxy server. This can help determine whether the local network itself is having problems, but a direct connection does not show that the Hysteria2 UDP handshake works.
Best for: Comparing the local network with the proxy path.
When troubleshooting in Config, first confirm which configuration is active, then check the rule order. DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP uses IP geolocation data, and FINAL handles requests that did not match earlier rules. Don’t focus on the proxy policy at the end and overlook a DIRECT rule that matched earlier.
- Proxy works, but Config does not: Check the matched rule, policy name, and policy group members first.
- Neither mode can establish a connection: Check address resolution, UDP reachability, authentication, and TLS settings first.
- The connection keeps reconnecting automatically: Check any configured On Demand conditions under Settings → On Demand, and distinguish connection management behavior from transport failures.
5. When UDP Is Restricted: Ports, Handshakes, and MTU Limits
Hysteria2 relies on UDP for its outer transport. A network allowing TCP 443 does not necessarily allow UDP 443, and a webpage loading does not prove that QUIC is available. The port number may be the same, but different transport protocols can be handled differently by firewalls and traffic policies.
If a connection times out, first check whether the remote server listens on UDP and whether the network allows it. Changing Port to 443 helps only if the server actually listens on UDP 443; changing the port at random is more likely to introduce a configuration error. Port hopping also requires the server’s port range and the client configuration to work together. It cannot fix networks that block UDP altogether.
- Authentication error returned immediately: Check the authentication string, whether the subscription is up to date, and whether the correct entry is selected.
- Certificate error returned: Check SNI, the certificate name, and device time; this is not a bandwidth issue.
- Times out after waiting: Check Address, Port, DNS results, and the UDP path; a timeout alone does not identify where packets are being lost.
- Handshake succeeds, but transfers stall: Then check link congestion, path MTU, remote server load, and the destination’s response.
QUIC’s initial datagrams require a UDP payload of at least 1,200 bytes. If the path cannot carry these packets correctly, the handshake or subsequent transfers may fail. But changing MTU whenever a connection stalls is not a universal fix: path MTU, tunnel overhead, and adjustable settings in the interface are not interchangeable. Don’t copy an MTU value from a WireGuard configuration directly into Hysteria2. Keep the defaults and original settings unless you have a clear diagnostic reason to change them.
6. FAQs and Making the Final Choice
Does a lower latency reading always mean a faster connection?
Not necessarily. Keep the server selected in Home and the Global Routing mode unchanged, then test initial webpage response and sustained transfers separately. Latency is just one type of measurement; it cannot replace throughput, stability, or real-world performance.
Why does it work on cellular but not Wi-Fi?
Keep the server, port, and authentication details the same, then compare Wi-Fi and cellular. If only Wi-Fi fails, check that network’s UDP policy, DNS, and egress conditions first. Don’t keep changing correct authentication details to accommodate one network.
Why can the subscription update, but the server still won’t connect?
Subscription retrieval and Hysteria2 transport are separate paths to verify. A successful update only confirms that the configuration was retrieved. In Home, check the imported entry’s Type, Address, and Port, then test the connection separately using Global Routing → Proxy.
Should I switch to Hysteria2 on every network?
No. On networks that restrict UDP, or where your current connection is already stable, keeping a working configuration makes more sense. If your existing configuration includes other transports, compare them using the same destination and time window. Don’t replace a verified path just because a protocol name is newer.
Choose based on repeatable connection results: Hysteria2 is worth adding to your everyday configuration only when UDP is reachable, the settings are correct, and sustained transfers are stable. High latency and sporadic packet loss are reasons to test it, not a performance guarantee. What matters is whether your current network is more stable and your specific tasks work better—not a speed ranking detached from test conditions.