This guide is for users who already have a service provider and subscription and are preparing to use Hysteria2. First, distinguish QUIC's transport capabilities from the role of congestion control. Then check the connection settings in Shadowrocket and assess network suitability under consistent test conditions. You'll learn which fields must match and where to investigate connection timeouts, certificate errors, and inconsistent throughput.
First, understand the roles of the client, protocol, and network path
Shadowrocket is a paid client for Apple platforms, primarily used on iPhone and iPad. It is available exclusively through the App Store. Check the App Store listing for the developer, Shadow Launch Technology Limited, and app ID 932747118. The app is a one-time purchase. Check the App Store listing for system requirements, compatible devices, and Universal Purchase availability.
A one-time client purchase is not a network service plan. This guide assumes you already have your own service provider and subscription. Hysteria2 is a connection protocol, not a subscription. A subscription may include entries for different protocols; it can update successfully even when some entries cannot connect on your current network. Shadowrocket is a closed-source commercial app. App installation, subscription updates, and server maintenance are separate processes.
- Client: Reads connection settings, establishes connections, and handles requests according to routing settings.
- Hysteria2: Defines how the client and server communicate. Both ends need compatible protocol support and settings.
- Network path: Includes your local connection, the carrier route, server capacity, and the path from the server to the destination.
- Routing rules: Determine whether a request uses this connection. Changing the protocol alone won't fix incorrect routing rules.
Why QUIC can be faster: connection reuse and loss recovery
Hysteria2 is based on QUIC, which uses UDP for transport and integrates a TLS 1.3 handshake. UDP doesn't mean web data is sent without any safeguards: QUIC can provide reliable, ordered delivery within its streams, including acknowledgments, retransmissions, and flow control. Hysteria2 can carry both TCP and UDP requests from applications.
A key feature of QUIC is isolation between streams. When data is lost on a traditional TCP connection, later bytes must wait for the missing data to be retransmitted. If multiple requests share that byte stream, they may all be held up. QUIC streams can deliver data independently, so a gap in one stream doesn't necessarily block another stream whose data has arrived. Delivery within each individual stream is still ordered, and all streams still share the same network capacity and congestion conditions.
Connection reuse can reduce the overhead of establishing connections repeatedly, but it doesn't eliminate waiting in every situation. First visits, certificate checks, DNS lookups, and destination response times still take time. Whether an existing connection is reused depends on its state and implementation. A slow-loading webpage doesn't necessarily mean the transport protocol is slow.
Check UDP reachability before investigating throughput
If your current network can't reach the server's UDP listening port, changing bandwidth settings won't help. First verify the connection using the port actually configured on the server, then check whether sustained transfers improve.
What congestion control can—and can't—do
High latency means it takes longer to receive feedback. Packet loss can result from wireless interference, congestion, overflowing device queues, and other causes. Many traditional congestion control strategies treat packet loss as a signal to reduce the sending rate. On paths with noticeable random loss but usable bandwidth, a continuously shrinking sending window can lead to underused capacity.
Hysteria2's performance isn't due to QUIC alone; congestion control also plays a role. Brutal uses a target bandwidth and loss-compensation approach to try to maintain target throughput. It doesn't create extra network capacity: setting the target too high can increase queuing, packet loss, and unnecessary traffic, affecting other users on the same network. The strategy used and whether bandwidth negotiation is supported depend on the client and server configuration. A server name alone isn't enough to tell.
| Network condition | Potential effect | What to check |
|---|---|---|
| High latency with random packet loss | Suitable congestion control may improve sustained throughput | Whether loss is caused by congestion and whether available bandwidth is stable |
| Low latency and little packet loss | May work normally without a noticeable advantage | Server load and destination rate limits |
| UDP is restricted | May time out or disconnect frequently | Access network policies and server firewall settings |
| Upload bandwidth is consistently saturated | Downloads and interactive traffic may still slow down due to queuing | Upstream usage, device queues, and bandwidth targets |
If the interface offers upload or download bandwidth settings, use the units shown for each field. Don't confuse Mbps with MB/s: 80 Mbps is theoretically equivalent to 10 MB/s, before accounting for protocol overhead. This is a unit conversion, not a speed guarantee. Base the settings on your connection's stable usable bandwidth, not the advertised peak speed of your plan.
Add Hysteria2 in Shadowrocket: check the fields first
Use a complete entry from your existing subscription whenever possible to avoid errors from manual entry. If you need to add one manually, check the protocol type, server address, port, authentication password, and TLS settings against your existing service details. Hysteria and Hysteria2 aren't interchangeable just because their names are similar. Don't reuse passwords or ports from a different protocol.
-
Import an entry
Go to Home → tap “+” in the upper-right corner → Type → Subscribe, enter your own subscription URL, and save. After updating, check that the entries appear. To add a server manually, go to Home → “+” → Type and select Hysteria2.
-
Check the address
Check the server address and Port. Enter only the hostname or IP provided by the server; don't add a webpage path. For example, enter
443as the Port only if the server is explicitly listening on443/UDP. Don't guess the port based on common values. -
Check authentication
Enter the authentication details provided by the server in Password. Subscription access credentials and server authentication passwords serve different purposes; don't use one in place of the other. When copying, check for trailing spaces, letter case, and special characters.
-
Check TLS
Enter the SNI required by the server and keep certificate verification enabled. If the connection address is an IP, you may still need to enter the domain associated with the certificate as the SNI. Don't enable Allow Insecure to hide a hostname mismatch or expired certificate.
-
Check optional settings
If the server uses obfuscation, select the matching type and enter the matching obfuscation password. If it isn't enabled, don't fill these in. Use the actual interface and server instructions for upload, download, and other extended settings, and verify they were imported correctly.
-
Test the connection
After saving, return to Home and select the entry, then check Global Routing. Before testing, decide which path the target request should take. Enable the connection and visit a fixed destination. Don't treat the latency shown in the list as a full download speed test.
Check routing: separate protocol issues from rule issues
Selecting an entry doesn't mean every request will use it. Proxy, Direct, Config, and Scene under Home → Global Routing select different routing behaviors. When troubleshooting, note the original setting, change only one thing briefly, and restore it afterward. Don't change the protocol, rules, and DNS at the same time, or you won't know what made a difference.
Config
RecommendedRoutes requests according to the currently enabled configuration. To confirm whether Hysteria2 is being used, check which rule and policy actually match the target. Config alone doesn't guarantee that a particular domain will use a proxy.
Best for: everyday use with existing rules and checking where specific requests are routed.
Proxy
Use the proxy path as a troubleshooting baseline to reduce interference from standard routing rules. Also confirm which entry is selected; system-level excluded traffic may need separate consideration.
Best for: briefly testing the connection itself and checking whether routing rules are causing the issue.
Direct
Uses a direct connection and isn't suitable for testing Hysteria2 proxy throughput. It can help you check direct access from your local network to the destination, but this isn't a performance comparison over the same server path.
Best for: checking basic network connectivity or troubleshooting problems with direct access.
Scene organizes routing choices according to configured scenario conditions; it isn't simply a fixed equivalent of Proxy. If Settings → On Demand is enabled, note its current state too, so condition-triggered connections don't affect your test results. On Demand controls when a connection is triggered; it doesn't directly improve Hysteria2 throughput.
DOMAIN-SUFFIX: Matches domain suffixes. Use it to check whether a test domain is routed through the intended policy.IP-CIDR: Matches an IP range. Check the rule options and request details to determine whether DNS resolution is involved.GEOIP: Matches against an IP geolocation database; results depend on the database contents.FINAL: Handles requests that don't match earlier rules. Check which policy it points to.
Troubleshoot timeouts, slow speeds, and interruptions
Keep the device, destination, and time of day consistent, and change only one condition per test. We recommend transferring the same resource three times over Wi-Fi and three times over cellular. Record whether the connection succeeds, the sustained throughput range, any interruptions, and the routing mode used. This is a test procedure, not a prediction of performance; don't use a single peak result to represent an entire day.
| Observed issue | Check first | Next step |
|---|---|---|
| Connection always times out | Address, UDP port, server listener, and network restrictions | Keep the entry unchanged, switch access networks, and compare whether the connection succeeds |
| Authentication failure message | Password and server authentication requirements | Check the original details, update the existing subscription, and check the entry again |
| Certificate error message | SNI, device time, certificate hostname, and validity | Correct the relevant field or ask the server administrator to fix the certificate |
| Light traffic works, but large transfers stall | Packet loss, path MTU, bandwidth targets, and congestion | First lower any unreasonable bandwidth target, record the result, then investigate the network path |
| Connection works, but one website is slow | Matched rules, DNS, destination site, and server egress | Retest with another fixed destination to distinguish a site-specific issue from a connection-wide issue |
| Wi-Fi fails, but cellular works | Local router and UDP policies on the access network | Check network policies before re-entering all authentication settings |
Path MTU issues are only one possible lead; a slow large file alone isn't enough to draw a conclusion. If the connection works under light load but latency rises significantly during sustained transfers, also check whether upstream bandwidth is saturated and whether the bandwidth target is too high. Keep the original value, change only one setting at a time, and retest with the same resource.
Conclusion: choose based on stability, not the protocol name
If UDP is reachable and the settings are correct, and repeated tests show steadier sustained throughput with fewer interruptions, you can continue using your existing Hysteria2 entry. If your current access network consistently restricts UDP, address the network conditions first or use another available connection entry you already have.
When keeping troubleshooting notes, record only the error type, test conditions, and descriptions of settings with sensitive values removed. Subscription URLs, Password values, and obfuscation passwords are connection credentials and shouldn't appear in public screenshots or logs. To review the basics, start with the site's Getting Started guide, then return to Home to check your entry and Global Routing.