Hysteria2 is a proxy protocol supported by Shadowrocket. It may help on connections with random packet loss or variable latency, provided UDP is allowed and the server settings match. This guide covers how the transport works, which settings to check, how to add a configuration, and how to diagnose common symptoms. It is for users who already have a configuration or subscription from their own provider. This site does not provide, sell, or recommend servers or subscriptions.
What Hysteria2, QUIC, and UDP each do
In short: Hysteria2 uses QUIC to establish a transport channel between the client and server, and QUIC packets are sent over UDP. UDP is the underlying transport; that does not mean all application data is sent unreliably. QUIC can provide encryption, acknowledgments, loss recovery, and reliable streams over UDP.
The connection to a website and the proxy transport channel are separate layers. For example, a website request may use TCP while the outer connection from Shadowrocket to a Hysteria2 server uses QUIC. When troubleshooting a firewall or server port, check the UDP transport—not just whether the TCP port with the same number is open.
QUIC streams can progress independently: a lost packet on one stream usually does not block data already received on other streams. This reduces cross-stream head-of-line blocking, but missing data within a reliable stream still needs to be recovered, and all streams still share the same network link. This does not mean video, web browsing, and file transfers can never affect one another.
If the configuration specifies 443/UDP, confirming that 443/TCP is reachable is not enough to show that Hysteria2 will work. Check that the server is listening, the server-side firewall allows the traffic, and the current network permits the corresponding UDP traffic.
Why it may be faster: congestion control, not UDP alone
In short: Hysteria2's advantage on some high-loss links comes from its congestion control and sending strategy—not because “UDP is inherently faster than TCP.” Packet loss may result from congestion, wireless interference, or other random loss. If all loss is treated as congestion and the sending rate is cut sharply, available bandwidth may go unused.
Hysteria2's Brutal congestion control adjusts sending behavior based on the configured bandwidth target and observed loss. It may trade more data sent over the network for higher useful throughput. In configurations that support bandwidth negotiation, results depend on the client's declared receive capacity, server limits, and the path's actual capacity. Some setups may also use congestion control such as BBR, so the protocol name alone does not tell you which mode a connection is using.
- Noticeable random packet loss, with capacity still available: A sending strategy that compensates for loss may help maintain throughput, but confirm this with repeated tests using the same task.
- Actual outbound congestion: Sending more data may worsen queueing, making web pages respond more slowly during file transfers.
- Low packet loss and stable latency: Protocol differences may not be the main bottleneck; server load, available bandwidth, and the destination website can still determine speed.
- UDP is blocked or heavily rate-limited: The transport may fail to establish or may only sustain very low throughput. Changing the bandwidth value cannot remove network restrictions.
Bandwidth settings also involve units. Mbps means megabits per second, while MB/s means megabytes per second. In decimal units, 80 Mbps has a theoretical maximum of about 10 MB/s; actual application data rates are lower because of protocol overhead and retransmissions. Follow the units shown by the app, and don't copy a number from a file transfer tool without checking its units.
In short: Set the bandwidth target to a sustainable level first
If the configuration exposes bandwidth settings, start with the values provided by your service provider. If you need to adjust them, use the upload and download rates your current network can sustain. Don't use a short-lived peak or your plan's advertised speed as a long-term sending target just to enter a higher number.
Hysteria2 settings to check in Shadowrocket
In short: Map all the information from your server to the app before changing performance settings. Hysteria2 and the older Hysteria protocol are not interchangeable by simply changing the name; after importing, confirm that Type is set to Hysteria2. The table below explains the settings—it is not configuration syntax to paste into Config.
| Setting | What to check | Common mistakes and symptoms |
|---|---|---|
| Server address | Use the domain name or IP address provided by your service provider. hy2.example.com is an example domain for illustration only. | A mistyped address or a DNS resolution issue can prevent the connection from reaching the right server. |
| Port | Check the exact port provided. For example, if your service provider specifies 443, check the outer connection on 443/UDP. | Assuming a common port is the default can send traffic to the wrong listener. |
| Authentication | Enter the complete authentication string provided by your service provider, preserving capitalization and symbols. | A missing character, copied whitespace, or credentials from another configuration can cause authentication to fail. |
| TLS / SNI | Enter the server name as required and keep certificate verification enabled. The connection address and certificate name may differ. | Using an IP address as the certificate name, or entering a domain not covered by the certificate. |
| Obfuscation | Configure this only if the server requires it. For example, both sides must use the same Salamander setting and password. | If one side enables it and the other does not, or the passwords differ, the handshake may time out. |
| Bandwidth settings | If the current editing screen includes these fields, check upload and download direction, units, and your service provider's requirements. | Reversed upload and download values, misread units, or an excessively high target can cause instability and extra queueing. |
The connection address routes data to the server. SNI supplies the server name during the TLS handshake and is commonly used when checking the certificate name. They can differ, but both must come from trusted configuration instructions. If you see a certificate error, check the name, device time, and server certificate status rather than disabling verification.
- Field names, available options, and advanced settings depend on what the app currently displays. If your subscription does not include an optional setting, that does not mean you should add a value yourself.
- For an existing subscription, update it first to get corrected settings. Before making manual changes, note the original values so you can distinguish them from settings applied by the next update.
- When sharing troubleshooting details, include the error type and setting names only. Redact authentication strings, tokens in subscription URLs, and related passwords.
Import and first test: confirm the connection before checking rules
In short: Import and select the server in Home, then verify the connection with a single test request. Home manages servers and connection status, Config manages rule sets, and Settings manages app preferences. Separating transport failures from rule-selection issues helps narrow down the cause.
-
Gather the settings
Check the server address, port, authentication details, and TLS requirements with your own service provider. If you use a subscription, make sure it actually contains a Hysteria2 entry; don't rely on its label alone to identify the protocol.
-
Import a subscription
In Home, tap “+” in the upper-right corner, then go to Type → Subscribe. Enter your own subscription URL and save it, then update the subscription in Home. Treat any authentication token in the URL like a password.
-
Check the type
Open the imported entry for editing and confirm Type is Hysteria2, then check the settings against the table above. To add a server manually, go to Home → “+” → Type → Hysteria2 and enter each value from your existing configuration.
-
Test the connection
Return to Home, select the entry, and connect. Follow the system prompt to allow adding a VPN configuration. Note what happens after connecting: does it keep waiting, show a specific error, or open the test page you selected?
-
Check routing
In Home → Global Routing, check the current mode. To temporarily isolate the effect of rules, use Proxy to test the same request, then restore the Config you normally use and check which policy the destination domain actually matches.
During the first test, also check Settings → On Demand. If On Demand is enabled, note its status. When testing disconnections or network changes, you can temporarily turn it off and restore it afterward to prevent automatic connection behavior from affecting the results. On Demand controls connection triggers; it does not fix Hysteria2 authentication, TLS, or UDP connectivity.
A subscription update may change server settings or the list of entries. After the update, confirm that the intended entry is still selected, then test the same destination. Don't update the subscription, change bandwidth, edit rules, and switch networks all at once, or you won't know which change affected the result.
Use Global Routing to tell protocol issues from rule issues
In short: If the same Hysteria2 entry works in Proxy but not in Config, check rule matches and the selected policy first instead of immediately changing transport settings. The comparison below covers three modes in Global Routing for this test. Use Direct only as a baseline when the destination is normally reachable directly.
Config
RecommendedThe active Config rules determine how a connection is handled. A destination may match DIRECT, REJECT, or a proxy policy, so confirm that the request actually uses the Hysteria2 entry being tested.
Best for: Everyday rule-based routing and checking traffic splits after confirming the connection.
Proxy
Routes connections handled by the app through the current proxy policy. This can temporarily reduce interference from Config rules during a test. It does not guarantee that all system traffic is routed through the app, nor can it bypass server authentication or network restrictions.
Best for: Isolating rule selection when the same request fails in Config.
Direct
Sends connections handled by the app directly to the destination without using the Hysteria2 channel being tested. A successful direct connection shows only that the direct route works; it does not prove that the proxy server is working.
Best for: Establishing a local network baseline for destinations that are normally reachable directly.
When checking rules, note that DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, GEOIP uses an IP geolocation database, and FINAL determines the policy when no earlier rule matches. Rules are processed in order: once an earlier DIRECT or REJECT rule matches, a later proxy policy cannot change that result. DNS resolution can also affect IP-based matches.
In short: Confirm the request uses the channel being tested
Web load times and transfer speeds are useful for evaluating a connection only after you confirm that the destination request actually uses the selected Hysteria2 entry. If the request matches DIRECT, correct the test rules first; don't record a direct connection's results as protocol performance.
How to troubleshoot connection failures, slow tests, and drops
In short: Check in this order: can the request reach the server, does the handshake and authentication complete, is routing correct, and is throughput limited? A single latency reading describes one kind of probe; it does not prove that UDP is reachable, authentication works, or sustained transfers are stable. Interpret a timed-out probe alongside the actual connection result.
| What you observe | Check first | What to try next |
|---|---|---|
| Times out on Wi-Fi but connects over cellular | Differences in UDP handling, routing, and address resolution between the two networks. | Keep the entry unchanged, switch networks, and repeat the test. Then check for restrictions on the Wi-Fi network. |
| TLS or certificate error | SNI, the name covered by the certificate, device time, and certificate validity. | Correct the settings using your existing provider information and keep certificate verification enabled. Don't use throughput settings to address a handshake error. |
| Authentication fails after connecting | Whether the authentication string is complete and whether the server-side credentials have been updated. | Update your own subscription or check the original settings; repeated retries won't fix the cause. |
| Web pages load, but large files are slow | Server egress capacity, destination limits, local bandwidth, bandwidth settings, and sustained packet loss. | Keep the network and entry fixed. Compare a small request with a sustained transfer, and note how performance changes after the task starts. |
| Works in Proxy but fails in Config | Rule order, the policy matched by the destination, and DNS results. | Check the relevant rules in Config without changing protocol settings at the same time. |
| First request fails after being idle | Network changes, UDP mapping timeouts, connection re-establishment, and On Demand status. | Note how long the connection was idle and how it recovers. Reconnect and test again, then distinguish an access network issue from a server issue. |
These are troubleshooting criteria, not results from tests conducted by this site. For your own comparison, test the same file three times on the same network, observing each run for 30 seconds. Record whether it succeeds, the speed once stable, and how quickly web pages respond at the same time. Keep the test time and destination consistent to reduce misjudgments caused by caching, destination rate limits, or short-term network fluctuations.
- Change one variable per round: For example, switch between Wi-Fi and cellular in the first round, then check bandwidth settings in the next.
- Watch latency and throughput together: Higher speeds alongside noticeably slower interactions may indicate more queueing—not better settings.
- Keep an eye on data usage: Sustained transfers and retransmissions to compensate for packet loss can both use extra data. Check your plan's billing terms before testing.
- Keep reproducible notes: Record the network, selected entry, Global Routing mode, test destination, and error text. Don't share authentication details.
When Hysteria2 may help and what you need
Hysteria2 is worth testing with an existing configuration on networks where UDP is available and random packet loss or variable latency is present. If UDP is restricted, the server's outbound capacity is saturated, or the destination is rate-limited, the protocol name won't resolve the bottleneck. For regular use, consider success rate, sustained throughput, responsiveness, and data usage together—not just the single result with the lowest latency.
- Settings look complete, but the handshake fails: check UDP, TLS, and authentication before changing bandwidth values.
- The handshake succeeds, but the destination behaves unexpectedly: check Global Routing and Config rules first.
- The connection works, but speeds fluctuate: repeat the test with a fixed task and network, then assess whether congestion control fits the conditions of the link.
Shadowrocket is a closed-source commercial app primarily used on iPhone and iPad. Check the App Store product page for compatibility with Mac, Apple TV, and Apple Vision. System requirements, compatibility, and whether purchases are universal are as listed on the App Store page. The App Store is the only place to get the app. The developer is Shadow Launch Technology Limited, and the app ID is 932747118. Shadowrocket is a one-time purchase; check the store for the current price.
Buying Shadowrocket gets you the app; it does not include a server, bandwidth, or a subscription. The import, settings, and connection tests in this guide assume that you already have a configuration from your own service provider.