Hysteria2 is a QUIC-based proxy protocol, not a speed-boost switch. For iPhone and iPad users who already have a provider, server, or subscription, this guide explains the transport and its performance, reviews the connection fields in Shadowrocket, and troubleshoots issues across UDP, TLS, and routing.
How Hysteria2, QUIC, and UDP fit together
In Shadowrocket, Hysteria2 is a server connection type. QUIC is the underlying transport it uses, and UDP carries QUIC packets. “Using UDP” refers to the outer connection between the client and server; it does not mean every browser request becomes unreliable or that apps can only access UDP services.
QUIC runs connection management, reliable streams, loss recovery, and congestion control over UDP, and uses TLS 1.3 for handshakes and encryption. Hysteria2 adds authentication and proxy forwarding on top of this transport. The server must support Hysteria2; you cannot connect to a server running another protocol by changing only the Type.
A port number alone does not identify a protocol. Working 443/TCP does not mean 443/UDP is available at the same address. The server's listening settings, firewall, and current access network may handle the two transports differently. example.com is a non-clickable example domain for illustration only, not a working service.
Why it may be faster: stream independence and congestion control
First, distinguish throughput from latency. Throughput is the amount of data transferred over time; latency is how long an interaction takes. A higher file transfer rate does not mean every webpage will load sooner. DNS lookups, the destination site's response, server load, and wireless signal quality also affect page load times.
QUIC's multiple streams reduce transport-level head-of-line blocking between separate streams when a packet is lost. While missing data in one stream is being recovered, data already received on other streams can still be delivered. Data within a single reliable stream must still arrive in order, and packet loss still uses retransmission bandwidth. QUIC does not mean “no waiting when packets are lost.”
- Stream independence: Limits how much separate streams have to wait on each other; it does not eliminate gaps within a stream.
- Loss recovery: The transport still has to detect packet loss and retransmit reliable data; this does not increase link capacity.
- Congestion control: Determines how the sender uses available bandwidth; the actual approach depends on client and server settings.
- Shared bottlenecks: Multiple streams still share the access link; wireless interference or upstream congestion can slow them all down.
Hysteria2's performance also depends on congestion control. Its Brutal congestion control is designed around a bandwidth target and may use available capacity more fully on links with random packet loss and spare capacity than approaches that sharply reduce sending rates when loss occurs. Servers may also use other congestion control methods, so using Hysteria2 does not mean the same sending strategy is always in effect.
Suitable networks and what to expect when UDP is restricted
Cross-region connections, long round-trip times, and links with some random packet loss are worth testing with Hysteria2. UDP must be consistently reachable, and both the server and access network need sufficient capacity. On low-loss, low-latency networks, performance differences may be small; the protocol name alone cannot tell you which connection will be faster.
| Network condition | What you may observe | What to check |
|---|---|---|
| UDP works, with random packet loss | Long transfers may remain stable, but retransmissions can still occur | Keep the server and destination fixed; measure throughput and interaction latency repeatedly |
| UDP is blocked | The handshake times out, and the server connection cannot be established | Check the UDP listener and firewall, then retest on another access network |
| UDP is throttled | The connection works, but sustained transfer stops increasing beyond a certain rate | Compare Wi-Fi and cellular networks; check capacity and throttling conditions |
| Network congestion or weak wireless signal | Latency rises during transfers, and page interactions become sluggish | Stop concurrent transfers, lower the bandwidth target, and test again |
Hysteria2 does not automatically switch to TCP when UDP is unavailable. Obfuscation in an existing configuration cannot create a UDP path that a firewall completely blocks. If the current network restricts UDP, ask your provider whether they have another existing connection configuration suited to that network. Repeatedly changing the password or disabling certificate verification will not help.
Bottom line: verify UDP connectivity first
If the same configuration connects over cellular but repeatedly times out on a particular Wi-Fi network, check that network's UDP conditions first. Keep the existing authentication and TLS settings unchanged so you can isolate the cause.
Import and verify Hysteria2 settings in Shadowrocket
Start with an existing subscription from your provider. Subscriptions typically include the protocol, port, authentication, and TLS settings, so entering everything manually makes it easier to miss a field. After updating a subscription, still verify the server type. A refreshed list does not confirm the server is reachable or selected as the current default.
-
Import a subscription
Open Home → “+” in the top-right corner → Type → Subscribe, then enter your existing subscription URL and save. Return to Home and pull down to refresh the list. Don't share your subscription URL with anyone.
-
Confirm the type
On Home, find the imported server, tap the info button on its row, and check that Type is set to Hysteria2. To add a server manually, go to Home → “+” → Type, select Hysteria2, then enter the details from your provider.
-
Check the connection details
Check Address, Port, and Password one by one. Enter only the server's domain name or IP address in Address—not a subscription URL, webpage path, or full share link.
-
Check encryption settings
Check SNI and certificate requirements against the existing configuration. If obfuscation is used, verify its type and password. Don't confuse the authentication password with the obfuscation password, and don't add values that aren't in the configuration.
-
Select the server and connect
Save, return to Home, and tap the circle beside the server to set it as the default. Then check Global Routing and turn on the connection. If the system prompts you to authorize a VPN configuration for the first time, follow the prompt, then run Connectivity Test.
| Field or setting | What to verify | Common mistakes |
|---|---|---|
| Address | Use example.com as a teaching example; enter your own server address in practice | Entering a subscription URL or an address with a webpage path |
| Port | Use 443 as a teaching example; in practice, it must match the server's UDP listening port | Guessing a common port without checking the server |
| Password | Enter the complete authentication string provided by your provider | Missing a separator or including spaces when copying |
| SNI (Server Name Indication) | Use the TLS name specified by the existing configuration and check that the certificate covers it | Changing the certificate domain to the IP address when connecting by IP |
| Obfuscation settings | Set these only if enabled on the server; both sides must use the same type and password | Enabling obfuscation on one side only or reusing the wrong password |
SNI and Address can differ: SNI is used during TLS name negotiation, while Address determines where the connection goes. If certificate verification fails, first check the system time, certificate name, and provider configuration. Allow Insecure is not a routine fix; disabling verification changes how the server's identity is checked and is no substitute for correct settings.
Distinguish the protocol connection from Global Routing
A successful server connection only shows that the proxy tunnel can be established. Whether a particular website uses it also depends on Global Routing, the current Config, and the selected policy. When troubleshooting, keep the routing setup fixed; don't change servers, rules, and bandwidth settings all at once.
Config
RecommendedRoutes traffic according to the current configuration's rules. For everyday use, check which rule matches the destination and which policy it selects, then confirm that policy points to the Hysteria2 server you're testing. The default server may not override a policy group's selection.
Best for: everyday connections with established routing rules
Proxy
Routes intercepted traffic through the proxy. After confirming the default server, you can use this temporarily to rule out routing rules as the cause. It does not change the server protocol or fix a failed UDP handshake.
Best for: briefly testing the server connection while ruling out routing issues
Direct
Connects directly without using the selected proxy server. If a website opens in this mode, that does not prove the Hysteria2 configuration works.
Best for: checking whether a website is reachable directly on the current network
Scene under Global Routing selects routing behavior based on the configured scene conditions; before testing, check which settings the current scene actually applies. Settings → On Demand controls when the system starts a connection based on conditions. It is not a protocol speed feature and does not replace server authentication or rule matching.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThis example routes example.com and its subdomains through PROXY; FINAL,DIRECT sends all other traffic directly as a fallback. Rules are evaluated from top to bottom and apply only when the relevant Config is in use. Here, PROXY is a routing policy, not another name for Hysteria2.
Troubleshoot by symptom and record comparable results
Break testing into three parts: “handshake succeeds,” “destination is reachable,” and “sustained transfer performance.” The latency result on Home does not replace webpage and file transfer tests, and a successful Connectivity Test does not prove that every destination is reachable at all times. The following are ways to interpret results, not test results for any particular connection.
- Handshake timeout: Check the address and UDP port first, then the access network and server firewall. Resolving an IP address does not mean the port is reachable.
- Authentication failed: Check the complete Password and the server account status. Repeatedly changing DNS usually won't fix an incorrect authentication string.
- Certificate error: Check SNI, the system time, and certificate validity. Don't loosen verification to hide the cause.
- Connected, but websites fail: Check Global Routing, the current Config, destination DNS resolution, and the matching policy. Determine whether the failure is with direct or proxy connections.
- Fast at first, then stalls: Stop other transfers and check the bandwidth target and wireless signal. Don't mistake a short-lived peak for sustained capacity.
For a comparison, keep the device, server, destination, and routing settings fixed. Repeat the test three times on the same access network, then repeat the same steps on another network. Record whether the handshake succeeds, whether the page loads completely, whether sustained transfers remain stable, and whether latency during transfers rises noticeably. Change one variable at a time to identify what caused any difference.