Hysteria2 may improve connections with intermittent packet loss, provided UDP is allowed, server settings are correct, and bandwidth values reflect the actual link. This guide is for Shadowrocket users who already have a provider and subscription. It explains QUIC and congestion control, walks through the fields to check, and outlines a controlled test to see whether Hysteria2 suits your network. A protocol name alone is no guarantee of speed.
Hysteria2 and QUIC: Where the Benefits on Unstable Networks Come From
Hysteria2 is a proxy protocol built on QUIC. QUIC carries data over UDP and provides encryption, reliable delivery, loss recovery, and multiplexed streams. So using UDP does not mean lost data is simply ignored, nor does it mean every request inside the app uses unreliable transport. Hysteria2 can carry TCP connections and UDP traffic, while the underlying transport between the client and server relies on UDP.
To understand performance on an unstable network, distinguish latency, packet loss, and congestion. Latency is the time a round trip takes; packet loss means some data fails to arrive; congestion occurs when a link or queue cannot handle incoming traffic in time. Random packet loss from fluctuating wireless signals does not necessarily mean the link is saturated. If the sender sharply reduces its rate whenever it detects loss, throughput can fall even when the link still has spare capacity.
Hysteria2 supports Brutal congestion control, which uses bandwidth estimates, but behavior can also depend on negotiation and server-side limits. Its goal is to make use of available bandwidth despite some packet loss, rather than treating every lost packet as congestion. Actual behavior depends on client settings, implementation, and server configuration; the protocol name alone does not tell you what to expect.
Networks Worth Testing—and Issues to Check First
“Unstable network” can describe several different problems. Weak cellular reception, congested public Wi-Fi queues, and packet loss along an inter-network route can look similar but call for different troubleshooting steps. Hysteria2 is worth testing when UDP is reachable and bandwidth is available despite intermittent packet loss. If UDP is blocked, changing congestion settings usually will not fix a connection that cannot be established.
| Observed behavior | Possible cause | What to try next |
|---|---|---|
| Times out on Wi-Fi, but the same profile works on cellular | Different UDP policy or route on the current Wi-Fi network | Keep the profile unchanged, test on both networks, and ask the network administrator whether UDP is allowed. |
| Short requests complete, but long transfers fluctuate noticeably | Ongoing rate limits, congestion, or an overestimated bandwidth setting | Reduce concurrency, check the bandwidth settings, then test the same resource again. |
| Handshake fails on every network | Incorrect address or port, a TLS issue, or a server-side problem | Check each setting against the details from your provider; do not change routing first. |
| Web pages load, but video still buffers | Insufficient throughput, a problematic route to the destination, or limited server capacity | Track sustained transfer performance; latency alone is not enough to judge it. |
UDP 443 and TCP 443 are different transport endpoints. Being able to open a regular HTTPS page does not prove that a network allows UDP 443; entering port 443 does not make it accessible. The port must match the server's actual listening configuration. Do not change it just because a “common port” seems more reliable.
- If other apps on the local network are also slow, check signal strength, upstream saturation, and network congestion first.
- If only one Hysteria2 profile fails, check its credentials, port, and server status first.
- If switching networks fixes the issue, keep the original settings and focus on how each network handles UDP.
Add Hysteria2 in Shadowrocket: Check the Server Settings First
These steps assume you already have a working service. Get subscription links and manual settings from your provider. A server address alone is not enough to connect with Hysteria2, and changing another protocol profile's type to Hysteria2 will not make it work. Keep the complete settings from your provider; if entering them manually, check each field rather than guessing.
-
Keep the Existing Profile
On the Home screen, note the currently working profile and the Global Routing selection. Add a separate test profile instead of replacing the existing configuration, so you still have a baseline if the test fails.
-
Select the Protocol
Go to Home → “+” in the top-right corner → Add Server, then select Hysteria2 under Type. To import a subscription, select Subscribe under Type and enter the complete link from your provider.
-
Enter the Settings
Check Address, Port, and authentication details. The TLS server name, certificate validation requirements, and any optional obfuscation settings must match the server. Do not reuse a password from an older protocol profile.
-
Check the Connection
After saving, return to Home and select the profile. Make sure Global Routing is not set to Direct. Turn on the connection switch; if this is the first system VPN configuration, follow the system prompts to authorize it.
-
Test Under Consistent Conditions
On the same network, first open the same destination page, then run a sustained transfer test. If something fails, change only one setting at a time and record what changed and what happened. Avoid changing routing, DNS, and authentication details all at once.
Available fields may vary with the selected type and app interface. Do not invent advanced settings that are not shown. A successful import does not guarantee that the server is reachable. For subscription updates and profile management, see the Subscribe guide.
| Check | What to Verify | Common Mistake |
|---|---|---|
| Address / Port | The domain or address and UDP listening port match the server. | Assuming the example port 443 is required for every service. |
| Authentication details | Keep the complete authentication string, including special characters. | Including extra spaces when copying, or missing the end of the string. |
| TLS / SNI | The server name matches the certificate validation requirements. | Treating certificate verification bypass as a routine fix. |
| Obfuscation settings | Enable only if required by the server, using the matching type and password. | Enabling obfuscation unilaterally and assuming every server will recognize it. |
| Bandwidth settings | Check the units, upload and download directions, and your provider's requirements. | Assuming a larger setting gives you more actual bandwidth. |
Global Routing and Bandwidth: What Each Controls
Global Routing determines how traffic is routed; Hysteria2 determines the protocol used by the selected proxy connection. They operate at different levels. If the profile is selected but the request actually goes Direct, that page's performance cannot be used to evaluate Hysteria2. The three routing modes below are commonly useful for troubleshooting, but are not the only available options.
Config
RecommendedUses the rules in the active configuration to decide where requests go. Before everyday use, check the configuration. During testing, confirm that the request to your destination matches the intended proxy policy.
Best for: everyday use with an existing, clearly defined routing configuration
Proxy
Routes requests handled by this mode through the proxy path, helping reduce interference from configuration rules during testing. This does not prove that all system traffic on the device goes through the proxy.
Best for: briefly checking whether a routing rule is bypassing the proxy for a particular request
Direct
Uses a direct connection and is not suitable for testing the performance of the selected Hysteria2 proxy. It can provide a baseline for the same destination over the local network.
Best for: checking how a resource performs over a direct connection
Bottom Line: Check the Route Before Adjusting the Rate
First confirm that the test request goes through the selected Hysteria2 profile. Only after verifying the route and settings should you adjust the bandwidth estimate and compare throughput.
A manual bandwidth value is an input to the sending strategy, not a request for more network capacity. Setting it far above the available bandwidth can build up queues, making pages slower to respond, voice choppy, or throughput uneven. Set it according to the link's sustained capacity and your provider's requirements, rather than copying the advertised peak rate from a plan.
- Check the units: Mbps and MB/s are not the same. If a setting requires Mbps, 10 MB/s converts to about 80 Mbps. This is a unit conversion, not a recommended setting.
- Separate upload and download: A high download rate does not mean upload is equally fast. Upstream congestion can affect acknowledgments and interactive requests.
- Keep negotiated settings: If the imported configuration does not specify a manual bandwidth value, test the existing settings first. Do not add unverified values just to increase the number.
How to Retest: Separate Latency, Throughput, and Stability
A single latency test reflects one specific probe; it cannot fully describe web browsing, video, or file transfer. Hysteria2's benefits need to be verified under the network conditions in question. This guide does not invent speed-test results or claim that a particular packet-loss percentage guarantees higher speed.
- Keep conditions consistent: Test on the same device and network, at roughly the same time, and pause other high-traffic tasks. Use the same destination resource rather than comparing different websites.
- Observe each aspect: Note the initial page response, whether sustained transfers are interrupted, and whether other small requests slow down noticeably during a transfer. Do not record just one latency figure.
- Repeat three times: Follow the same steps each round and note whether the test succeeds, fails, or stalls. Three rounds are a practical way to check results, not a statistical conclusion.
- Change one variable at a time: Change only one factor per round, such as the network or bandwidth setting. If you change both the profile and the server, you cannot attribute the difference to the protocol.
- Restore your usual settings: Once troubleshooting is complete, restore your original routing and configuration. If sustained throughput improves but interactive response suffers noticeably, revert the settings instead of keeping only the higher peak result.
Frequently Asked Questions: UDP, Certificates, and Automatic Connections
Why does Hysteria2 keep timing out when regular websites load?
Regular websites may use TCP, while Hysteria2 relies on UDP underneath. Keep the profile unchanged and test on both Wi-Fi and cellular; then check the server's UDP port and authentication settings. If it fails on only one network, first check that network's UDP policy.
Can I just skip verification when I get a certificate error?
First check your device's date and time, then verify the Address, TLS server name, and certificate requirements provided by your provider. Do not bypass verification by default. If the error persists with the correct settings, ask your provider to confirm that the server certificate matches the server name.
Do I need to enable On Demand to use Hysteria2?
No. Settings → On Demand controls when a connection starts automatically; it does not fix protocol settings or UDP reachability. After confirming that a manual connection works, configure On Demand according to how you use your network.
If a profile appears after a subscription update, does that mean it will connect?
No. A successful Subscribe update only means that the relevant content was retrieved and parsed this time. Return to Home, select the profile, check Global Routing, and test an actual request. Expired profiles, changed authentication details, and server issues still need to be checked separately.
Choose Hysteria2 based on stability you can reproduce on your current network, not on the protocol name. If UDP remains restricted or careful retesting shows no improvement, keep the working configuration and ask your provider which connection settings and network requirements apply to your service.