Hysteria2 is a QUIC-based proxy protocol for users who already have a server configuration and want to check whether their UDP path is usable. This guide covers how it works, when it may help, and which settings to verify—in order to distinguish network blocking, authentication failures, and routing-rule issues without switching protocols based on a single speed test.
How Hysteria2, QUIC, and UDP Fit Together
Shadowrocket can use an existing Hysteria2 server configuration. Hysteria2 is the proxy protocol, QUIC is its underlying transport, and UDP carries the outer datagrams. These terms refer to different layers: choosing Hysteria2 does not simply turn on a generic UDP forwarding switch, nor does it automatically convert every browser connection to HTTP/3.
UDP alone does not guarantee delivery, ordering, or retransmission. QUIC adds connection management, reliable streams, loss recovery, and encryption on top of UDP. When an app accesses a TCP service through a proxy, the outer transport can still use QUIC—so “UDP on the outside” does not mean lost webpage data will never be retransmitted. Hysteria2 can also carry UDP traffic, but its handling varies by traffic type.
The port number alone does not tell you whether two connections use the same transport. A network that allows TCP 443 may not allow UDP 443, and a server may use a different port. Hysteria2 and older Hysteria configurations are not interchangeable: after importing, verify the Type instead of keeping the old type and changing only the address and password.
Why It Can Be Faster: Loss Recovery and Congestion Control
High latency increases round-trip and loss-recovery times. After repeated packet loss, a traditional TCP connection may reduce its congestion window, slowing throughput recovery. Actual behavior depends on the congestion-control algorithm and network conditions, so the name “TCP” alone says nothing conclusive about speed. Hysteria2 builds on QUIC and offers congestion-control mechanisms, including Brutal, with the goal of maintaining throughput on links that have available bandwidth but also experience packet loss.
QUIC’s independent streams can reduce transport-layer head-of-line blocking between streams: packet loss in one stream does not necessarily make another wait for the missing data. Data within a reliable stream must still be delivered in order. QUIC also cannot eliminate server processing time, DNS lookup time, or physical network latency, so “QUIC is faster” is not something you will necessarily notice every time a webpage loads.
| Network conditions | What you may notice | What to check first |
|---|---|---|
| High latency, occasional packet loss | Sustained downloads may be more stable, but page load times are still affected by round-trip latency | Repeat tests on the same network; record time to first byte and sustained throughput separately |
| Low latency, little packet loss | The difference between protocols may be hard to notice; the bottleneck may be the server or destination site | Use the same destination, similar test times, and the same routing path |
| UDP blocked or heavily rate-limited | Connections may time out repeatedly or show significantly limited throughput | The target UDP port and current network policy |
| Upstream congestion | Check packet delay; downloads and interactive traffic may also be affected | Pause other uploads and compare again |
Bottom line: Check UDP reachability first
Confirm that the handshake completes before comparing sustained throughput. If the connection keeps timing out, increasing bandwidth settings will not replace checks of the port, address, and network policy.
A higher bandwidth setting is not always better. With a Brutal configuration, setting a value well above the bandwidth actually available may increase packet loss, crowd out other traffic, or make interactive use worse. Start with the values specified by your existing service configuration and adjust only after observing stable performance. This guide does not promise a fixed speed increase: results depend on the route, load, and test conditions.
Fields to Check Before Adding Hysteria2 to Shadowrocket
Use configuration details from a service you already have. Hysteria2 is not a generic way to log in to a server: an address that opens a webpage does not necessarily host a working Hysteria2 service. Before adding a server manually, confirm the service type, complete authentication value, UDP port, and TLS settings. Prefer the combination of fields provided in your existing configuration.
| Field or setting | What to verify | Common mistake |
|---|---|---|
| Type | Select Hysteria2 to match the server protocol | Choosing Hysteria and assuming the same address is enough to connect |
| Address / Port | The server hostname or IP address, and the actual open UDP port | Copying spaces along with the address, or using the website port as the proxy port |
| Password | The complete authentication value from the service configuration; it is case-sensitive | Splitting the authentication value or leaving out a symbol |
| SNI / TLS | Use the name required for the handshake and certificate, as specified in your configuration | Leaving out the certificate’s matching name when connecting by IP |
| Obfuscation | If required by the server, the type and password must match | Using the obfuscation password as the authentication password, or vice versa |
| Bandwidth settings | Follow the configuration instructions and the capabilities of the actual network path | Treating the service plan’s advertised speed as the bandwidth currently available on your network |
Field labels may vary by app language and configuration type; use the current edit screen as your reference. SNI selects a name during the TLS handshake, while certificate validation checks the server’s identity. Neither replaces Password. If Address is an IP but the certificate was issued for a domain, enter the corresponding name as specified in the configuration. Do not disable certificate validation to conceal a name mismatch.
Add and Test the Server: Connect First, Then Check Routing
In Shadowrocket, Home is where you view and select connections, Config manages rule configurations, and Settings contains app settings. The first connection also requires approval for the system VPN configuration. Follow these steps to add an existing Hysteria2 configuration manually. If you import it from an existing subscription, open the entry’s edit screen and check the same fields.
-
Check your server details
Have your own Address, Port, authentication value, and TLS instructions ready. For example, enter Port 443 only if your details explicitly specify UDP 443. Do not infer the port from another entry.
-
Choose the protocol
Go to Home → tap “+” in the upper-right corner → Add Server, then select Hysteria2 under Type. Enter the address, port, and Password manually, and compare each value with the original details.
-
Check the encryption settings
On the entry’s edit screen, check TLS, SNI, and any optional Obfuscation settings. Enter the name and password required by the server, leave certificate validation enabled, and save the entry.
-
Test the connection
Return to Home, select the saved entry, temporarily set Global Routing to Proxy, turn on the connection, and approve the system prompt. Test the same destination page, then observe a longer download.
-
Restore your usual settings
When testing is complete, set Global Routing back to Config and check the rules and policy references in Config. If automatic connections interfere, check the enabled status and trigger conditions under Settings → On Demand.
To add an existing subscription, go to Home → “+” → Type → Subscribe, enter your own complete URL, and save it. Then update the subscription group. A successful update only means its contents were fetched and parsed; it does not mean every server in it is reachable. Manually edited fields may be overwritten by the next update. For a lasting correction, address the source configuration of the existing subscription.
Do not post subscription tokens, Password values, or full configuration screenshots publicly. When recording troubleshooting details, keep the error type, network conditions, and time range; hide authentication values before sharing fields for review. Connection tests also have distinct stages: successful address resolution, a successful handshake, and access to the destination webpage are not the same thing.
Using Config, Proxy, and Direct to Troubleshoot
Selecting a Hysteria2 entry does not determine how traffic is routed; Global Routing still applies. Config follows the active configuration’s rules, Proxy routes eligible traffic through the selected proxy path, and Direct connects without a proxy. Global Routing may also use Scene, which handles traffic according to its configured behavior. Do not assume traffic uses Hysteria2 just because its entry is selected.
Config
RecommendedRoutes connections according to the active configuration’s rules and policies. A policy referenced by a proxy rule must have an available Hysteria2 entry selected. Traffic matching a DIRECT rule still connects directly.
Best for: everyday rule-based routing after testing
Proxy
Temporarily sends traffic through a single proxy path to reduce interference from routing rules. Check the selected server or policy; this does not bypass incorrect authentication or TLS settings.
Best for: checking whether a problem comes from a rule or policy in Config
Direct
Use this to check how the current network connects directly. A page loading successfully in this mode does not prove that the Hysteria2 connection works.
Best for: establishing a direct-connection baseline and separating destination-site issues from proxy-path issues
The rule below demonstrates syntax only; it is not a complete configuration. DOMAIN-SUFFIX matches domain suffixes, and FINAL is the fallback action when no earlier rule matches. PROXY must point to a policy that exists and is available in the active configuration. If that policy selects a different entry, the test results cannot be attributed to Hysteria2.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTGEOIP and IP-CIDR match IP addresses; DOMAIN-SUFFIX matches domain names. When troubleshooting, check rule order, match results, and policy selection—not just whether a keyword appears in the configuration. If Proxy works but Config fails, check these items first. If both modes time out during the handshake, investigate UDP reachability and server fields next.
Common Questions: Timeouts, Speed-Test Variations, and Subscription Updates
Why does the same configuration work on Wi-Fi but keep timing out on cellular?
Keep the same entry and destination, and test each network separately. First check Address, Port, and the server’s UDP status, then find out whether the current network restricts UDP. If only one network fails, note the difference. Do not change the password, SNI, and bandwidth settings all at once, or you will not be able to isolate the cause.
Why won’t webpages load even though the app says it’s connected?
An enabled system VPN switch does not mean the remote proxy handshake succeeded. On Home, check the selected entry, then temporarily test the same page with Global Routing → Proxy. Check the connection log for handshake, authentication, or DNS errors, then verify the relevant fields on the entry’s edit screen.
Why do webpages still feel slow when the speed test is fast?
Speed tests usually emphasize sustained throughput, while page loads also depend on DNS, connection setup, and the destination server’s response. Record first-load and subsequent-load performance separately, keeping the destination and network the same. Do not judge the entire interactive experience from a single large-file download.
Why did my manual settings change after a subscription update?
An update may recreate entries. In the relevant subscription group on Home, check Type, Port, SNI, and authentication fields against the existing subscription instructions. A failed subscription fetch and a failed Hysteria2 handshake are different problems; check URL reachability and server connectivity separately.
When comparing settings, change one variable at a time. Record the network, Global Routing mode, selected entry, destination address, and specific symptoms such as “handshake timed out,” “authentication failed,” or “download interrupted.” If needed, pause other uploads and downloads before testing again. These notes are more useful for diagnosing a network path than a single latency reading.
Limitations and App Store Availability
Hysteria2 is worth testing when your existing service supports it and UDP is reachable, especially on high-latency links with packet loss but enough available bandwidth. If the network consistently blocks UDP, use another transport supported by your own configuration instead of repeatedly increasing the bandwidth setting. A protocol cannot overcome server load, limited outbound bandwidth, or restrictions at the destination site.
- Check Type, UDP port, authentication, and TLS before investigating speed.
- Temporarily use Proxy to reduce routing-rule interference. Restore Config after testing and check the policy references.
- Keep certificate validation enabled; lowering identity checks is not a routine troubleshooting step.
- Users provide their own subscriptions and service configurations. The app purchase and network service are separate.
Shadowrocket is a closed-source commercial app available only on Apple platforms, primarily for iPhone and iPad. Compatibility with Mac, Apple TV, and Apple Vision, along with system requirements, is as listed on the App Store page. The App Store is the only place to get the app. Verify the developer, Shadow Launch Technology Limited, and app ID 932747118 before making the one-time purchase. Buying the app does not include a network service plan. This guide does not provide, sell, or recommend proxy servers or subscriptions.