Hysteria2 uses QUIC over UDP. It may deliver higher throughput on some high-latency links with random packet loss, provided UDP is reachable, bandwidth settings are reasonable, and the server has enough capacity. This guide is for users who already have their own provider and subscription and want to use Hysteria2 in Shadowrocket. It covers how the protocol works, where it may help, connection checks, and troubleshooting—without treating the protocol name as a speed guarantee.
What Hysteria2, QUIC, and UDP do
In Shadowrocket, Hysteria2 is an optional connection protocol. It uses QUIC as its transport, and QUIC typically sends packets over UDP. So even if the destination website uses HTTPS, the connection between your device and the Hysteria2 server may still use UDP rather than TCP. When troubleshooting, distinguish the proxy transport from the connection to the destination website.
UDP does not guarantee that data arrives in order, and it does not handle retransmissions. QUIC adds encrypted handshakes, reliable streams, loss recovery, and flow control on top of UDP. Hysteria2 uses these capabilities to carry proxy traffic, with its own authentication, forwarding, and congestion-control design. It is inaccurate to assume that “UDP is faster because it does not retransmit.”
The port must match your server configuration. For example, if the server is configured for 443/UDP, that UDP port must be reachable. A successful connection to 443/TCP alone does not show that Hysteria2 will work. The same port number does not mean the same protocol, and a regular HTTPS service cannot act as a Hysteria2 server.
Why high packet loss can sometimes mean higher speeds: identify the cause first
Traditional loss-based congestion control treats packet loss as a sign of network congestion and reduces the sending rate to ease queue pressure. But random packet loss from wireless interference or fluctuating link quality does not necessarily mean the available bandwidth is exhausted. On high-round-trip-time links, reducing the rate and then gradually increasing it can leave available bandwidth underused for a long time.
Hysteria2's bandwidth settings and congestion-control mode affect how it performs. With bandwidth-estimation-based Brutal mode, its sending strategy does not simply back off in the traditional way each time a packet is lost; it takes the configured bandwidth and packet loss into account. This can improve throughput on some links with random packet loss, but it cannot create physical bandwidth. The actual control behavior also depends on the client implementation, parameters, and server settings.
- Random packet loss: Scattered packet loss caused by signal interference or link errors, while capacity remains available. This is a scenario that may benefit.
- Congestion-related packet loss: The upstream or downstream link is already saturated. Sending more data can further increase latency and affect other traffic.
- UDP throttling or blocking: The network applies separate restrictions to UDP. Using a QUIC-based protocol does not remove those restrictions.
- Server bottlenecks: Insufficient egress bandwidth, processing capacity, or destination-side limits need to be checked separately; changing local settings alone will not solve them.
What to check: verify UDP first, then monitor latency under load
If the connection comes up but large web pages slow down as soon as data starts transferring, lower the bandwidth setting and test again. If the handshake cannot complete, check whether UDP is reachable before increasing the bandwidth setting.
QUIC's multiple streams can also reduce transport-level head-of-line blocking between independent reliable streams: if one stream is missing data, other streams do not have to wait for the same TCP byte stream to recover. However, the streams still share the same path and congestion state. This does not mean every website will load faster or that high latency will disappear.
Networks worth testing—and issues to rule out first
Choose a protocol based on current network conditions. Keep the server location, test destination, time of day, and Global Routing mode consistent, then compare connection success and sustained transfer performance. Comparing Hysteria2 on one server with another protocol at a different location does not isolate the effect of QUIC.
| Network scenario | What to expect | What to check first |
|---|---|---|
| High latency with random packet loss | Sustained transfers may make better use of available bandwidth | Verify UDP reachability and record latency at idle and under load |
| Stable Wi-Fi with little packet loss | There may be no noticeable benefit | Compare load times and stability for the same destination |
| Network that restricts UDP | Handshake timeouts or repeated disconnections | Cross-check over Wi-Fi and cellular |
| Upstream bandwidth saturated by other traffic | Requests slow down and interactions become sluggish | Pause background uploads and repeat the same test |
Fluctuations on cellular networks can also result from cell-site load and changing signal strength. A single speed test is not enough to establish a protocol advantage. Repeat the test three times under similar conditions, recording whether the connection succeeds, the page loads fully, and large transfers continue without interruption. This guide does not give a fixed percentage improvement; that would require measurements on a specific link.
Test a Hysteria2 connection in Shadowrocket
These steps assume you already have your own provider and subscription. Start with the complete parameters from your provider or an imported entry, and avoid changing the server address, authentication details, and bandwidth settings at the same time. Hysteria and Hysteria2 are not interchangeable by simply renaming an entry; make sure it is configured for Hysteria2.
-
Check the entry
Go to Home, open the edit screen for an existing server entry, and confirm that Type is set to Hysteria2. Check the server address, port, and authentication details against your configuration. Keep any SNI or obfuscation settings consistent as well.
-
Select the server
Return to Home and select the server. Make sure the selection indicator is on the entry you intend to test. If your subscription contains multiple entries, note the selected name so you can tell which connection produced the results.
-
Set a consistent routing mode
Go to Home → Global Routing and temporarily select Proxy for a controlled test, so test requests use the proxy. Do not switch back and forth between Config and Proxy during a single test.
-
Connect
Turn on the connection switch on Home. If prompted the first time, allow the system to add a VPN configuration, then run Home → Connectivity Test. If it fails, start by checking the handshake, authentication, and UDP path.
-
Test real-world traffic
Open the same website and run one sustained transfer. Note any timeouts or interruptions, and how interactions change under load. When finished, go to Home → Global Routing and restore Config or your usual routing mode.
Connectivity Test provides a clue about reachability; it is not a full throughput test. A successful test only shows that the relevant probe completed at that moment. It does not prove that every domain, UDP service, or high-volume transfer will work. If the test succeeds but a particular website fails, continue by checking rules, DNS, and the destination itself.
Use Global Routing to distinguish protocol issues from rule issues
Hysteria2 determines how the proxy connection transports data; Global Routing determines which path a request takes. They operate at different layers. Under Config, the rule DOMAIN-SUFFIX,example.com,DIRECT sends matching requests directly. Selecting a Hysteria2 server does not mean that this request will use it.
Everyday use: Config
RecommendedRules in the current configuration determine the policy, which may be DIRECT, REJECT, or a proxy policy. To explain the connection behavior, first check which rule matched the test destination.
Best for: Everyday use with existing rules and destination-based routing
Temporary troubleshooting: Proxy
Routes traffic through the proxy to reduce interference from rule-based routing during a test. If the destination opens in Proxy but not in Config, focus on the matching rule and selected policy.
Best for: Briefly verifying the proxy path and isolating the effects of Config rules
Direct connection baseline: Direct
Connects directly to the destination and does not test Hysteria2 tunnel performance. Use it to record how the destination behaves on your local network and help identify destination-side issues.
Best for: Checking whether the local network can reach the destination directly
Global Routing also includes Scene, which can apply behavior based on your existing Scene settings. Avoid introducing extra scene changes during protocol benchmarks. To troubleshoot rules, check the order of DOMAIN-SUFFIX, IP-CIDR, and GEOIP, along with the final FINAL policy. See the rule manual for more on rule behavior.
Common issues: connection timeouts, inconsistent speeds, and bandwidth settings
The same entry works on cellular but keeps timing out on Wi-Fi. What should I check?
Keep the server and Global Routing mode unchanged, then run Home → Connectivity Test on both networks. If the difference is reproducible, first check UDP restrictions on the Wi-Fi network, router policies, and any captive portal sign-in status. This behavior alone does not prove that the authentication details are incorrect.
Will a higher bandwidth setting always make the connection faster?
No. The bandwidth setting affects transport control; it does not buy more bandwidth or remove throttling. Check the field's units first and distinguish Mbps from MB/s, which differ by a factor of eight. Then set a conservative value based on the capacity you can sustain, changing only one direction at a time and monitoring latency under load and interruptions.
The connection fails after switching networks and only recovers when toggled off and on. Why?
On Home, turn the connection off and back on, then run Connectivity Test again. QUIC supports connection migration, but recovery still depends on the implementation, network address changes, and timeouts. Also check whether Settings → On Demand is enabled. It manages on-demand connections; it cannot make a restricted UDP path reachable.
Can I bypass verification when a certificate error appears?
First check the device's clock, server domain, SNI, and whether the server certificate matches. Confirm the details with your configuration provider. Skipping certificate verification weakens identity checks and should not be a routine speed or troubleshooting fix. Certificate errors and congestion control are separate issues.
If the cause is still unclear, note the network in use, Type, server port, Global Routing mode, and whether the failure occurs during connection setup or sustained transfer. Before sharing troubleshooting notes, remove passwords, subscription tokens, and full subscription URLs. Keep only the details needed to reproduce the issue.