Hysteria2 uses QUIC over UDP and may be worth evaluating on high-latency, lossy links when your service provider supports it. This guide explains when it can improve throughput, how to check bandwidth and certificate settings, and how to distinguish protocol failures from routing issues or battery changes in Shadowrocket. The protocol name alone does not guarantee faster speeds.
How Hysteria2 and QUIC work together
Hysteria2 is a proxy protocol, while QUIC is the underlying transport it uses. Selecting Hysteria2 in Shadowrocket means the client must connect to a server that supports the protocol, with matching authentication and transport settings on both sides. Changing Type to Hysteria2 in an existing configuration does not make the server support it.
QUIC runs over UDP, but that does not mean reliability is left entirely to the application. QUIC provides its own encryption handshake, reliable streams, loss detection, and retransmission. Hysteria2 uses these features to carry proxy traffic. Even if the destination website uses TCP, the connection between your client and the proxy server can still use QUIC; keep these two transport layers distinct.
QUIC is not the same as HTTP/3. HTTP/3 maps HTTP onto QUIC, while Hysteria2 has its own authentication and proxy data transport. Being able to open an HTTPS page in a browser only shows that the page’s route works; it does not confirm that Hysteria2 authentication, the UDP port, or traffic forwarding at the same address is working.
Why it may be faster on lossy links
Speed differences mainly come from the combined effects of congestion control, loss recovery, and multiplexing. Traditional TCP congestion control generally treats packet loss as a sign of network congestion and reduces the sending window. If loss is mainly caused by wireless interference or link quality rather than a congested uplink, backing off may leave available bandwidth underused. Hysteria2 uses bandwidth settings and congestion control mechanisms to take a different approach on these paths.
QUIC’s independent streams can also reduce head-of-line blocking between streams: losing a segment in one stream does not require all other streams to wait for that segment to be retransmitted. However, streams on the same connection still share link capacity and may be affected by the same congestion control; data within a reliable stream must still be delivered in order. Packet loss still has a cost.
- High latency with random packet loss: Delays from recovery and changes to the sending window have a greater impact, so Hysteria2 may deliver more consistent sustained throughput.
- Low latency and little packet loss: The link may already use available bandwidth efficiently, so switching protocols may offer little benefit. Server load and path quality may matter more.
- UDP is blocked or continuously throttled: The handshake may time out, or a connection may start but fail to sustain throughput. Increasing the bandwidth setting cannot remove network restrictions.
- The uplink is already congested: An overly high sending target may cause more queueing, packet loss, and retransmissions, slowing responses to other requests.
Bottom line: compare repeated tests on the same path
Keep the server, destination, and routing mode constant, then compare initial response time, sustained throughput, and connection stability. Don’t attribute speed changes to Hysteria2 if you also changed the exit route, and don’t assume a fixed percentage improvement.
Enter and check settings in Home
These steps assume you already have connection details from your service provider. Get subscription details from your provider. Importing a subscription and entering settings manually are separate configuration paths: check the imported values for the first, and enter each field individually for the second. During troubleshooting, don’t update a subscription, change authentication, and adjust bandwidth at the same time, or it will be difficult to tell which change made a difference.
-
Get the connection details
Note the server address, port, authentication details, certificate name to verify, and whether obfuscation is enabled. Your service provider should also specify bandwidth values and units. Don’t infer other settings from the domain name or port.
-
Choose the protocol type
Home → “+” in the top-right corner → Add Server → Type → Hysteria2. Enter the address and port. If you imported a subscription, open the relevant entry for editing and first confirm that Type is set to Hysteria2.
-
Check authentication
Enter the complete Password value supplied by your service provider, preserving capitalization and symbols. If the credentials use a combined username-and-password format, enter it exactly as provided; don’t split it, remove separators, or add spaces.
-
Check TLS
Check that the SNI matches the name on the server certificate. The connection address can be an IP address while certificate validation uses a domain name; these values serve different purposes. The obfuscation type and key must also match the server settings.
-
Save and test
Save and return to Home, select the entry, check Global Routing, and enable the connection. For the first setup, follow the system prompts to authorize the VPN configuration. Then visit a consistent test destination and note whether the result is a success, timeout, or certificate error.
Bandwidth units are especially easy to mix up. If the field is in Mbps, 20 Mbps converts to about 2.5 MB/s before protocol overhead. Don’t enter 20 Mbps when you mean 20 MB/s. Check upload and download values separately. Entering a value far above the link’s actual capacity does not reserve extra performance. The server limits, settings on both sides, and implementation determine the outcome; an input value alone cannot tell you the actual sending rate.
Global Routing: distinguish protocol settings from rules
A successful connection shown in Home only confirms the connection status; it does not prove that a particular request used the selected Hysteria2 entry. Global Routing sets the routing mode, while rules in Config determine the policy for each request. When investigating why changing protocols made no difference, first confirm which route the test request actually took.
Config
Rule-basedThe active Config determines the policy. Rules are evaluated from top to bottom, and the first match determines how a request is handled; unmatched requests fall through to FINAL. Before everyday use, confirm that the relevant policy points to the intended connection entry.
Best for: everyday use with a defined rule set
Proxy
Routes traffic handled by the client using the proxy mode, which is useful for temporarily ruling out the effect of normal routing rules. This does not prove that all system traffic uses the same connection, and it won’t fix server authentication or UDP connectivity issues.
Best for: briefly checking the proxy route and protocol connectivity
Direct
Routes traffic handled by the client using a direct connection. Successful access in this mode does not prove that the Hysteria2 server is working. Use it to establish a direct-route comparison, then restore the original mode after testing.
Best for: checking whether the local network and destination service are reachable
Scene in Global Routing lets you set routing behavior for different situations; it is not a transport protocol. During troubleshooting, check whether the current scene affects the selection. If you use Config, confirm which file is active and check whether rules such as DOMAIN-SUFFIX or IP-CIDR match DIRECT or another policy first. Correct protocol settings and correct rule selection are separate requirements.
Troubleshooting connection failures and unstable speeds
Classify the symptoms first, then change the relevant settings. A successful TCP port test does not mean that the UDP port with the same number is reachable. Conversely, no response to a generic UDP probe alone does not prove the port is closed; the server may not respond to invalid packets. Make a judgment based on the client’s actual handshake result, network-switching tests, and details confirmed by your service provider.
| Symptom | Check first | Next step |
|---|---|---|
| Connection keeps timing out | Address resolution, the actual UDP port, and reachability on the current network | Test once on Wi-Fi and once on cellular, keeping the same configuration and authentication. |
| Authentication failure message | The full Password value, capitalization, and server authorization status | Check the original connection details again and make sure no leading or trailing spaces were copied. |
| Certificate error message | SNI, certificate name, validity period, and device date and time | Confirm the server certificate configuration; don’t hide the error by disabling validation. |
| Connects, but throughput fluctuates | Bandwidth units, packet loss, network throttling, and server load | Keep the destination the same, reduce concurrent requests, and record results at different times. |
| Some destinations behave unexpectedly | The active Config, matched routing policy, and DNS results | Briefly test using Proxy as a comparison. If the behavior changes, check routing rules first rather than re-entering authentication details. |
If small requests work but sustained transfers frequently stall, ask your service provider to check the path MTU, UDP datagram handling, and throttling policy. Don’t change low-level settings based on a single stall. If the issue occurs only on one Wi-Fi network and goes away on cellular, that points to a path difference; repeat the test before drawing conclusions, so a temporary increase in server load isn’t mistaken for a network issue.
iPhone battery use and practical testing
Hysteria2 does not have a fixed battery impact. Encryption, data throughput, retransmissions, connection maintenance, and the time the cellular radio stays active all affect power use. A faster download may finish sooner and reduce radio activity, while sustained high throughput, a weak signal, or repeated reconnects may use more power. The protocol name alone doesn’t tell you which settings will use less battery.
- Keep test conditions consistent: Use the same iPhone, network, and resource. Keep screen brightness, charging status, and background activity as consistent as possible.
- Test two types of workload: Observe short web requests and sustained downloads separately. Don’t use battery changes during a long full-speed download as a measure of idle drain.
- Record a defined time window: For example, run each test for 10 minutes and note the amount of data transferred, heat, reconnects, and battery change. Repeat at least three times. This is a test plan, not a measured performance result.
- Check connection triggers: In Settings → On Demand, check whether the connection starts based on network conditions. Observe its status before and after switching Wi-Fi to avoid mistaking changes in connection time caused by automatic connection for protocol differences.
- Review battery use separately: Check battery usage in iPhone system settings, taking the screen and cellular signal into account. VPN forwarding activity cannot simply be equated with the total energy use of a foreground app.
Bottom line: prioritize stability over peak speed
If raising the bandwidth target only boosts speed momentarily but causes noticeable heat, slower interaction, or reconnects, restore the previous value and test again. For everyday use, a configuration that reliably completes real tasks is more useful than the highest result from a single speed test.
Hysteria2 is worth evaluating when the server supports it, the UDP path is available, and all settings are correct. Shadowrocket is a paid client for Apple devices, primarily used on iPhone and iPad; buying the client is separate from obtaining a connection service. Get subscription details from your service provider. Check the App Store listing for purchase availability and system requirements. For help with the basics, follow the setup guide to check Home, Config, and first-time VPN configuration authorization before testing the protocol.