Hysteria2 is a QUIC-based proxy protocol, not a switch that speeds up every network. This guide is for people using Shadowrocket on iPhone, iPad, or another platform with their own provider and subscription. First check whether UDP is reachable, then verify the connection settings, and finally test how packet loss, bandwidth, and routing rules affect performance.
How Hysteria2, QUIC, and UDP work together
Hysteria2 uses QUIC to establish a transport connection between the client and server, and QUIC runs over UDP. UDP describes the outer transport between the two endpoints; it does not mean web requests themselves are sent unreliably. QUIC provides streams with acknowledgments, retransmission, flow control, and encryption. Hysteria2 then carries proxy traffic over that connection.
Ordinary web traffic often uses TCP. When forwarded through Hysteria2, these application connections can travel in QUIC streams; application-generated UDP traffic can also be forwarded where the protocol supports it. So “the server accepts TCP connections” and “Hysteria2 can connect” are not the same thing: the outer UDP path must work independently.
If the server you already use listens on port 443, the firewall must allow the corresponding 443/UDP. Allowing only 443/TCP is not enough. Use the port provided by your service provider; do not change other ports in a subscription to 443 just because websites commonly use it.
Why Hysteria2 can perform better on lossy connections
When packets are lost, more data may need retransmission and recovery takes longer, which can cause downloads to stall. Traditional TCP congestion control adjusts the sending rate based on network feedback. Packet loss can result from actual congestion or from link conditions such as wireless interference. In either case, lowering the sending rate may not make full use of the available bandwidth.
Hysteria2’s transport design can maintain a more aggressive sending pace on some paths with non-congestion-related packet loss and high round-trip latency. QUIC’s independent streams also reduce the blocking between streams that can result from reliable, in-order delivery. However, streams still share the same path and connection resources. Retransmissions, server load, and available egress capacity remain factors—more packet loss does not mean more speed.
- Occasional packet loss from wireless interference: When UDP is reachable and the link has spare capacity, throughput may be more consistent than with the previous transport.
- High latency on cross-region routes: Bandwidth utilization may improve, but the baseline latency caused by fiber distance and routing detours will remain.
- Congestion on the access link: Sending more data can increase queuing and packet loss, making web responses and calls worse.
- Ongoing deterioration in local signal quality: Retransmissions still consume wireless capacity; switching protocols cannot fix poor Wi-Fi coverage.
Bottom line: distinguish packet loss from congestion
If even directly accessed websites slow down noticeably during downloads, first reduce concurrency and check the local link and bandwidth settings. Do not assume that increasing the sending bandwidth is the right fix.
When Hysteria2 may not be suitable
The first thing to check is not a speed test result, but whether UDP can reliably travel both ways. Some guest networks, workplace networks, and public hotspots restrict UDP. Others allow only certain UDP traffic or throttle sustained, high-volume UDP. Resolving a domain, opening an HTTPS website, or even getting a low ping does not prove that UDP is available on the target port.
| What you observe | Possible cause | What to check next |
|---|---|---|
| Connection times out on Wi-Fi but works on cellular | The Wi-Fi network blocks UDP, or the two networks use different routes | Keep the same configuration and retry after switching networks |
| Short requests work, but download speeds drop over time | UDP throttling, server congestion, or changes in device temperature or signal | Note when the slowdown starts and check direct-connection performance at the same time |
| Small requests work, but large requests often stall | Path MTU, packet fragmentation handling, or packet loss | First verify the settings provided by your service provider, then check the route and logs |
| A TCP port test succeeds, but Hysteria2 still times out | The test did not check the target UDP port | Verify that the server is listening on UDP and check the firewall rules |
Do not conclude that MTU is the problem based on a single stall. A network segment that cannot handle larger datagrams properly can cause some requests to hang, but certificate errors, authentication failures, and DNS issues can also be described as “the site won’t open.” Use the logs to distinguish a failed handshake from an interrupted transfer before asking your service provider to check the route.
Check and test Hysteria2 in Shadowrocket
The steps below refer to the Home, Config, and Settings screens on iPhone and iPad. Mac, Windows, Android, and Linux users can follow the same approach to checking settings and comparing networks; exact control locations vary by platform. Keep your working configuration before testing, and use only server details you already have permission to use.
-
Update an existing subscription
On Home, find your existing subscription and update it. To add one, go to Home → “+” → Type → Subscribe, enter your own subscription URL, and save. Do not post subscription contents or access credentials in public screenshots or discussions.
-
Verify the protocol settings
On Home, open the edit screen for the connection and confirm that Type is set to Hysteria2. Check the server address, port, authentication details, and TLS settings one by one. Hysteria and Hysteria2 are distinct types and cannot be freely interchanged.
-
Check the certificate name
If the connection address is an IP but the certificate was issued to a domain, verify the SNI provided by your service provider. If obfuscation is configured, the type and password must match on both ends. Do not turn off certificate verification at random instead of correcting the settings.
-
Isolate the effect of routing rules
Select the connection and temporarily set Home → Global Routing to Proxy. Connect and visit a fixed test resource. This reduces interference from routing rules, but check whether any setting in the configuration overrides the behavior.
-
Restore your usual settings
After testing, restore Global Routing to your usual Config and confirm that the original configuration is enabled in Config. If you changed automatic connection behavior under Settings → On Demand while troubleshooting, restore that as well.
A successful subscription update means the client fetched and parsed the subscription contents; it does not mean every server in it is reachable. If your service provider changes authentication details or certificates, manually copied entries may not update with the subscription. If authentication fails, first compare where the entry came from with the update results instead of changing unrelated rules.
Choosing Global Routing to avoid misreading protocol test results
Hysteria2 determines how a connection transports data; Global Routing determines how requests are routed. They operate at different layers. Proxy, Direct, Config, and Scene in Global Routing are not four proxy protocols. If a test request actually goes Direct, a fast-loading website is not evidence of Hysteria2 performance.
Config: follow the configuration
RecommendedRouting is determined by the rules and policies in the current configuration. Requests matching DIRECT connect directly; requests matching a proxy policy use the corresponding connection. What happens to unmatched requests depends on settings such as FINAL—they do not necessarily connect directly.
Best for: everyday split routing with an existing rules configuration.
Proxy: remove routing rules from the test
Use the proxy as the primary routing mode to briefly check whether the selected connection works. Confirm where requests actually go during the test so that policy selection or other settings do not skew the result.
Best for: testing a connection or finding out why a rule match is unexpected.
Direct: establish a direct-connection baseline
Check whether the local network is already congested by testing direct connections. Compare only the same resource that is normally accessible directly; a resource that requires a proxy cannot be used to diagnose the local network as a whole.
Best for: comparing Wi-Fi performance and checking whether the issue is with the proxy route.
Scene applies routing behavior according to configured scenarios, so avoid adding it as an unknown variable during initial troubleshooting. At the rules level, DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches IP ranges, GEOIP checks an IP against a geolocation database, and FINAL handles unmatched requests. Checking rule order and target policies is more useful than simply changing protocols when some websites work and others do not.
How to compare speeds without focusing on a single peak
Hysteria2 performance depends on congestion control, available bandwidth, and server-side limits. If the connection settings include upload and download bandwidth, set them according to your current network and service provider’s requirements. Upload is data sent from your device to the server; download is data sent back. Also distinguish Mbps from MB/s: converting MB/s to Mbps requires multiplying by 8.
Do not use your home broadband’s advertised download speed as the sending target for every network. Available upload bandwidth may differ on cellular. Setting the target too high can consume bandwidth needed for acknowledgments and other apps; setting it too low can limit throughput. Check the current connection settings and server requirements to see whether a value is needed and how it applies.
- Keep conditions consistent: Use the same device, network, and test resource. If two connections use different server locations or egress routes, do not attribute the difference to protocol alone.
- Repeat measurements: Run three consecutive tests per setup, each lasting 60 seconds. Record throughput during the steady state and the number of interruptions, not just the highest instantaneous speed.
- Check responsiveness at the same time: During downloads, open a website that is normally accessible directly and look for noticeable queuing. A speed increase that leaves other requests persistently stalled is not an overall improvement.
- Log each network separately: Record Wi-Fi and cellular results in separate groups. Reconnect after switching networks so that connection migration does not skew the results.
- Record the actual error: Note whether the message indicates a timeout, authentication failure, or certificate verification failure. Redact server credentials and subscription URLs before sharing logs.
Bottom line: reachability matters more than peak speed
If the same configuration repeatedly times out during the UDP handshake on one network but works reliably after switching networks, address the network restriction first or use another connection you already have that suits that network. Do not keep changing bandwidth values at random.
Common questions and troubleshooting limits
Will Hysteria2 always lower gaming latency?
No. Gaming latency also depends on the game server’s location, the proxy egress location, routing detours, and queuing. More consistent downloads do not mean faster round trips for small packets. Check latency variation and packet loss while the game is running instead of judging by download speed.
Should I disable TLS verification if the connection fails?
Do not treat disabling verification as a routine fix. First check the device time, server address, SNI, and the name covered by the certificate, then confirm that the server certificate is valid. Certificate verification checks the server’s identity. Bypassing an error can hide a configuration problem and weaken connection security.
Can turning on On Demand get around UDP restrictions?
No. Settings → On Demand controls the conditions that trigger an on-demand connection; it does not change how the network operator handles UDP. Automatic reconnection can try again, but it cannot make a blocked transport path reachable.
Choose a protocol based on reachability, stability, and acceptable resource use on the current network. Shadowrocket is a client, and connection settings come from services the user already has. This site only explains how to configure subscriptions you already own; it does not supply connection services. If your existing settings are incomplete, check with your original service provider. Do not guess passwords, subscription tokens, or authentication fields.