Hysteria2 uses QUIC over UDP and is worth testing on high-latency or randomly lossy connections where UDP is available. It does not guarantee higher speeds or bypass every UDP restriction. For Shadowrocket users who already have a provider and subscription, this guide explains the transport, bandwidth settings, how to verify an imported configuration, and how to distinguish routing issues, authentication failures, and network restrictions.
How Hysteria2, QUIC, and UDP fit together
Hysteria2 is a proxy protocol, QUIC is its transport foundation, and UDP carries QUIC packets. They operate at different layers: proxy-wrapped application traffic is sent to the server over a QUIC connection. The use of UDP does not mean Hysteria2 ignores packet loss or simply sends data without handling it.
UDP alone does not guarantee packet order or reliable delivery. QUIC adds connection management, reliable streams, loss recovery, and congestion control. Traffic such as web browsing, which normally uses TCP, can also be forwarded through QUIC streams. Whether an application uses UDP and whether the client-to-server connection uses UDP are separate questions.
QUIC is closely related to HTTP/3, but the two are not interchangeable. Using QUIC does not turn all proxy traffic into ordinary web requests or guarantee that network controls will allow it. A website loading over TCP 443 in a browser does not prove that UDP 443 to the same address can establish a Hysteria2 connection.
Why it can be faster: recovery and congestion control
“Fast” can refer to handshake time, time to first response, sustained throughput, or interactive stability. QUIC integrates a secure handshake and supports multiple independent streams. If one stream is waiting for lost data, other streams do not have to wait for the same in-order byte stream at the transport layer. However, all streams still share the connection's congestion control and the available link capacity, so they can affect one another.
Hysteria2 throughput also depends on congestion control. Its protocol ecosystem supports the bandwidth-target-driven Brutal approach and can use BBR-style congestion control. The behavior in practice depends on the client implementation, bandwidth parameters, and server limits. The protocol name alone does not tell you which algorithm an active connection uses. Nor should you assume an option available in one implementation is necessarily a setting in Shadowrocket.
- Random packet loss: If the link still has available capacity, more aggressive sending and recovery may sustain higher throughput. That does not eliminate retransmissions.
- Actual congestion: Once a bottleneck is saturated, sending more data can build queues, increase packet loss, and add latency, affecting calls and web interactions.
- High round-trip latency: Handshakes and loss recovery can involve more noticeable waits. Protocol features may improve the experience, but cannot remove latency caused by physical distance or routing detours.
- Server-side limits: Server bandwidth, load, and egress capacity remain the ceiling. Raising the value on the client does not increase the server's actual capacity.
When to test Hysteria2—and when to check the network first
High latency, random packet loss, and UDP reachability are reasons to test Hysteria2, not guarantees of speed. Home broadband, public Wi-Fi, and cellular networks may handle UDP differently. The same server connection may be stable on one network, connect only briefly on another, or time out repeatedly.
| Network condition | What to check first | What to do |
|---|---|---|
| High latency with occasional packet loss | May be worth testing for comparison, but first confirm UDP is available | Keep the server and test content the same; record time to first response, throughput, and interruptions |
| Websites load, but Hysteria2 keeps timing out | TCP reachability does not prove UDP reachability | Check the actual UDP port, then retest on Wi-Fi and cellular |
| Downloads start fast, then slow down noticeably | Possible queue buildup, rate limiting, or server load | Pause other downloads, check the bandwidth settings, then retest with the same file |
| Low latency, little packet loss, and a stable current connection | Switching protocols may not help | Compare stability first, not just a single peak-speed result |
| Connection drops after switching networks | A change of address, NAT state, or network policy may affect the connection | Reconnect and check the logs. Do not treat QUIC connection migration as a guarantee of uninterrupted service |
Bottom line: confirm UDP reachability before comparing throughput
If the same configuration works on cellular but keeps timing out on your current Wi-Fi, note the network differences and check whether UDP is allowed. Repeatedly raising the bandwidth setting will not fix a failure to establish a connection.
Import and verify Hysteria2 in Shadowrocket
Get subscription details and connection parameters from your provider. Import an existing configuration from them where possible to reduce manual entry errors. Updating a subscription fetches the configuration again; it does not guarantee that the server is reachable. After updating, confirm that the selected entry, protocol, and authentication details have not changed.
-
Import a subscription
On Home, tap “+” in the top-right corner and select Add Server. Set Type to Subscribe, enter your subscription URL, and save. Return to Home, update the subscription, and check the entries it creates.
-
Verify the protocol
On Home, open the target entry for editing. Confirm that Type is set to Hysteria2, then check the server address, port, and authentication details one by one. Do not reuse the password or port from an older protocol entry.
-
Verify security settings
Check TLS, SNI, and any optional obfuscation parameters against the details from your provider. The connection address may differ from the domain used for the certificate; set SNI as required by the server. If you see a certificate error, first check the domain, device time, and certificate chain.
-
Keep the test route consistent
Go to Home → Global Routing, temporarily select Proxy, and choose the Hysteria2 entry you want to test. This helps prevent Config rules from sending test requests through DIRECT. Restore your previous routing setup when the test is done.
-
Record the connection results
After connecting, visit the same test destination each time and record whether the connection establishes, whether the first response is delayed, and whether the transfer is interrupted. If the connection reconnects automatically, also check Settings → On Demand so that an on-demand trigger is not mistaken for a failed manual action.
The port must match the server configuration. For example, if the server specifically uses UDP 443, confirm that the entry uses port 443 and that the server allows that UDP port. An obfuscation password and a connection authentication password may serve different purposes; do not swap them. Do not leave certificate verification disabled as a troubleshooting measure. Correct any mismatched settings instead.
Separate Global Routing behavior from protocol performance
The protocol determines how traffic travels between the client and server; Global Routing determines whether requests use the proxy route. Proxy, Direct, Config, and Scene under Home → Global Routing are not four different protocols. Scene behavior depends on its existing configuration. When troubleshooting, check which settings it actually applies so the route does not change during a test.
Config
RecommendedRoutes requests according to the rules in the current configuration. If a destination matches DIRECT, selecting a Hysteria2 entry will not automatically send it through that connection. Suitable for everyday use once you have checked the rules.
Best for: everyday routing by destination after verifying your rules
Proxy
Sends requests through the current proxy route, which can help reduce the effect of Config rules during a temporary test. You still need to check the selected entry and any other settings that may affect traffic routing.
Best for: short tests with a fixed proxy entry to check protocol connectivity
Direct
Uses a direct connection, so it cannot measure Hysteria2 server throughput. It can provide a baseline for your local network, but the destination's own reachability also affects the result.
Best for: checking your local network and direct access to a destination
In Config, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP matches using an IP geolocation database, and FINAL handles requests that did not match earlier rules. Rule order and the associated policy together determine the route. If a test destination matches DIRECT, check the rule first rather than attributing the direct-connection speed to Hysteria2.
Common issues: timeouts, certificates, and bandwidth settings
Why does the same entry time out on one Wi-Fi network but not another?
Keep the entry settings unchanged and reconnect on both Wi-Fi and cellular. If it fails on only one network, note when it happened, the server port, and the error message, then check whether that network restricts UDP. A website loading successfully does not prove UDP is reachable.
Can I ignore a certificate error?
First check the device's time, then compare the SNI and certificate domain provided by your provider. If the connection address is an IP, do not assume the certificate should match that IP. If they still do not match, ask your provider to confirm the settings rather than routinely skipping verification.
Will a higher bandwidth setting make downloads faster?
No. First check the input units and whether upload and download are entered from the client's perspective. Test using the value provided by your provider or a conservative value suited to the actual link. Change one setting at a time and observe both web response times and sustained downloads, not just momentary peaks.
Why won't a website load even though the latency test shows a result?
A test result may not cover the complete request to the destination website. Return to Home and confirm the selected entry, then check Global Routing. To rule out the effect of rules, temporarily use Proxy. Next, distinguish between a DNS resolution error, TLS error, and connection timeout, and check the relevant settings for each.
Run a repeatable comparison test
When comparing protocols, change only one variable at a time wherever possible. Speed differences measured with different servers, egress routes, or at different times cannot be attributed to QUIC alone. Even if your provider offers multiple protocol endpoints, first check whether they use the same route and bandwidth limits. Without that, the test only shows the overall difference between two connections.
- Keep conditions consistent: Use the same device, network, and test destination. Pause background updates and other bandwidth-heavy tasks.
- Repeat the tests: Run each test at least three times and note the date and time, time to first response, sustained speed, and number of failures. These are suggested data points, not test results reported here.
- Watch latency under load: Open a regular webpage while a download is in progress. If throughput improves but interactions become noticeably slower, check the bandwidth target and queue buildup on the link.
- Record the type of error: Log timeouts, authentication failures, certificate errors, and interrupted transfers separately. Do not label every failure as “slow speed.”
- Protect credentials: Before sharing test notes, remove tokens from subscription URLs, authentication passwords, and obfuscation passwords. Include only the network and error details needed for troubleshooting.
Choose based on repeatable results on your current network: UDP must be reachable, settings must be correct, and transfers must remain stable before throughput advantages are worth discussing. Hysteria2 is one transport option for an existing service configuration. High packet loss or latency is a reason to test it, not proof that it will be faster.