Hysteria2 is a QUIC-based proxy protocol worth testing on networks with available UDP, high round-trip latency, or random packet loss—but it is not guaranteed to be faster than other transports. This guide is for iPhone and iPad users of Shadowrocket who already have their own provider and configuration. It covers transport basics, parameter checks, routing checks, and comparison tests. Users on other platforms can apply the same principles; exact steps depend on the client.
1. How Hysteria2, QUIC, and UDP fit together
In Shadowrocket, Hysteria2 is a connection protocol option—not a speed boost switch or a service plan. Connecting requires a server that supports the protocol, along with the correct address, port, authentication details, and certificate settings. Changing the Type of an existing connection that uses another protocol does not convert it to Hysteria2.
At the transport layer, Hysteria2 uses QUIC, which runs over UDP. UDP itself does not provide in-order delivery or retransmission. QUIC builds on it to provide encryption, acknowledgments, loss detection, reliable streams, and congestion control. So “runs over UDP” does not mean lost web content will never be retransmitted, nor that every application request becomes unreliable.
Hysteria2 can carry both TCP and UDP proxy traffic, but they have different application semantics. Reliable byte streams, such as web traffic, travel over QUIC streams; UDP forwarding typically uses QUIC DATAGRAM, which does not provide the same retransmission guarantees as reliable streams. Judge reliability by the traffic being carried—not just by whether “UDP” appears in the connection name.
2. Why it can be faster: independent streams and congestion control
Assess speed in terms of handshake time, time to first byte, and sustained throughput. QUIC combines transport and encryption handshakes, which can reduce some connection setup round trips. DNS lookup, certificate verification, server processing, and the destination site's response still take time. A fast connection setup does not guarantee faster large-file downloads.
- Less cross-stream blocking: With multiplexing over a shared TCP connection, packet loss can block delivery of subsequent bytes. QUIC streams can make progress independently, so while one stream waits for retransmission, others do not have to wait for the same in-order delivery requirement.
- Data within a stream still has to arrive: Missing data in a download still needs to be retransmitted. QUIC does not remove the ordering requirements of reliable transport or make lost data reappear.
- Sending strategy affects throughput: Hysteria2 bandwidth settings can affect the congestion control behavior used. Brutal sends toward a target bandwidth and compensates for packet loss. It may sustain higher throughput on links with random packet loss, but can also increase traffic overhead and queueing pressure.
- Link capacity remains the limit: Home broadband upload capacity, wireless signal quality, server egress, or destination-side throttling can all become bottlenecks. A transport protocol cannot overcome these physical or policy limits.
A higher bandwidth value does not simply mean “faster.” For example, if actual stable download capacity is about 50 Mbps but the sending target is set to 500 Mbps, this may cause queueing, extra packet loss, and higher latency. These numbers illustrate how settings relate; they are not test results from this site. Check the current client and server documentation for field names, units, and automatic negotiation behavior.
Bottom line: consider throughput and latency together
If increasing the bandwidth setting barely changes download speed but noticeably worsens page load times, voice latency, or network responsiveness on other devices, revert the setting and remeasure the link's stable usable bandwidth.
3. Which networks may benefit, and what to check first
High latency extends feedback cycles, while random packet loss may cause some congestion control strategies to reduce their sending rate. That makes Hysteria2 worth testing on long-distance links with some random packet loss and a working UDP path. But the cause of packet loss matters: random loss from wireless interference calls for a different assessment than loss caused by congestion at the network's egress.
| Network conditions | What you may notice | What to check first |
|---|---|---|
| Long distance, random packet loss | Sustained transfers may be steadier, while short requests are still affected by round-trip latency | Compare time to first byte and sustained throughput on the same network and at the same time |
| Low latency, low packet loss | The difference may be small; server egress could also be the bottleneck | Keep stable settings; don't infer speed from the protocol name |
| UDP blocked | Handshake times out; TCP websites work, but Hysteria2 cannot connect | Check that UDP is allowed on the server, then test again on another network |
| UDP throttled | Connection succeeds but sustained transfers are very slow, or slow down after a while | Distinguish network-operator policies, server limits, and wireless congestion |
| Path MTU issue | Small requests work, but large transfers stall or time out repeatedly | Ask the network administrator to check large UDP packets and path MTU; don't change multiple settings blindly |
QUIC Initial datagrams must be at least 1,200 bytes. If the path cannot carry UDP datagrams of that size, the handshake may be affected. A successful ping alone does not rule this out: the protocol, packet size, and path policies used by ping are not equivalent to those of an actual QUIC connection.
UDP 443 and TCP 443 are separate traffic types that may be allowed or blocked independently. If a website opens over HTTPS, that only suggests the relevant TCP service may be reachable; it does not prove UDP 443 is open. If the server actually uses UDP 8443, enter 8443 in the client. Changing the port to 443 will not make the connection work by itself.
4. Check and test an existing configuration in Shadowrocket
The steps below use the Home screen on iPhone and iPad. Save your current working configuration first, then add the Hysteria2 settings you already have. If a subscription you already use manages the configuration, check the imported settings first to avoid mistaking a temporary manual change for a persistent one after an update. This guide does not provide, sell, or recommend connection services or subscriptions.
-
Check the parameters
Have the server address, UDP port, authentication password, and any required SNI and optional obfuscation parameters ready. Use the port configured on the server. The certificate domain can differ from the connection address, but it must meet certificate verification requirements.
-
Add a connection
Go to Home → tap “+” in the upper-right corner → Type, select Hysteria2, enter your existing settings, and save. If you already use a subscription, go to Home → “+” → Type → Subscribe to import it, then check the protocol and port on the generated entry.
-
Check the certificate
Check the SNI and certificate domain against the values provided by the server, and make sure the device clock is correct. If certificate verification fails, check the domain, validity period, and certificate chain first; disabling verification is not a routine fix.
-
Isolate routing
On Home, select the connection you want to test, temporarily set Global Routing to Proxy, then turn on the connection toggle at the top. Send a request to a fixed destination that you are allowed to test. Restore the previous Global Routing setting when you are done.
-
Keep conditions consistent
Note the Wi-Fi or cellular network in use, test time, and observed behavior. If Settings → On Demand is enabled, make sure automatic connections won't interfere with manual disconnects or switching. Restore the original setting after testing.
Connectivity Test on Home can give you an initial indication of reachability and latency, but it cannot replace a sustained download, time-to-first-byte check, or real-time application test. A low latency reading only reflects the response on that test path. It does not show that every website uses the same connection or prove that throughput is higher.
5. How Global Routing and rules affect tests
Hysteria2 determines how the selected proxy connection transports traffic; Global Routing determines how requests are routed. If a rule sends a test request to DIRECT, selecting a Hysteria2 entry on Home does not mean that request's speed measures Hysteria2. Confirm which route the request uses before comparing protocol behavior.
Config
RecommendedLet the rules in your current configuration determine the request path. After checking the configuration, use it for everyday connections and verify with rule matching that the request under test goes through PROXY.
Best for: everyday rule-based routing and verifying a specific rule match
Proxy
Route requests handled by the client through the proxy to temporarily reduce interference from routing rules. If the connection fails, still check the protocol settings and network reachability.
Best for: temporarily isolating rule effects and checking the selected connection
Direct
Use a direct path without the selected proxy connection. This can establish a baseline when the destination allows direct access, but the result says nothing about the quality of the route from the proxy server to the destination.
Best for: checking the direct connection baseline between your local network and the destination
For example, in the active configuration under Config, the Rule snippet below routes example.com and its subdomains through PROXY, sends the specified private IP ranges through DIRECT, and handles all other requests with FINAL. This is only a rule syntax example; it does not include a working server. Check the selected connection to confirm the actual egress used by PROXY.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECTRules are matched in order, so keep FINAL at the end. The example uses example.com to illustrate suffix matching; do not use it as a speed test destination. To check your own business domain, understand the existing rules before editing the relevant conditions, then save and enable the correct configuration. If the configuration is not enabled or Global Routing is still set to Direct, editing rules will not produce the expected result.
6. How to run a repeatable comparison test
A reliable comparison changes as few variables as possible. Servers may differ completely in location, egress, load, and route, so you cannot attribute the difference between downloads from two different servers to the protocol alone. When possible, compare the same server, similar times, the same destination, and the same device. If these conditions cannot be controlled, limit your conclusion to “the performance of these two connections under current conditions.”
- Use the same test file: Use the same download resource you are authorized to access. Compare time to first byte, sustained throughput, and failure count; avoid unknown speed-test links.
- Repeat and record: Run each set three times, with each transfer lasting about 30 seconds. Record every result instead of keeping only the highest. This is a testing suggestion, not a performance guarantee.
- Check the impact on other traffic: While downloading, also check a lightweight webpage or real-time application. Note whether higher throughput comes with noticeable queueing or increased interaction latency.
- Keep failure details: Distinguish handshake timeouts, authentication failures, certificate errors, and disconnects after connecting. Record the full error category, but remove passwords, subscription URLs, and authentication details before sharing the results.
- Test on another network: If Wi-Fi fails but cellular works, first check the Wi-Fi network's UDP policies. If both networks fail, continue by checking the server listener, firewall, and authentication settings.
Bottom line: connect first, then compare speed
For a handshake timeout, check UDP reachability first. For a certificate error, check SNI and the certificate. Once connected, evaluate sustained throughput and latency. Keep the current Hysteria2 settings only if repeated tests show a consistent improvement for your actual use.
Hysteria2 is most suitable when the server is configured correctly, the UDP path is available, and the sending strategy matches link capacity. It can improve some transfers affected by packet loss and latency, but it cannot fix an incorrect password, an invalid certificate, or a blocked network path. For more configuration syntax, see the Rules Reference. For your first connection and VPN configuration permissions, follow the Getting Started Guide step by step.