Hysteria2 is a QUIC-based proxy protocol, not a speed boost switch. This guide is for Shadowrocket users who already have subscription or node details from their provider. Learn how UDP, QUIC, and congestion control differ, check the import fields, then compare repeated tests on the same network and destination to see whether it suits your setup. This helps distinguish configuration errors and UDP restrictions from client issues.
What UDP, QUIC, and Hysteria2 each do
Hysteria2 in Shadowrocket is a connection protocol option. It carries proxy traffic between the client and server over a QUIC connection based on UDP. It does not provide a route, or change the server location, available outbound bandwidth, or how the destination site handles traffic. Get subscriptions and node details from your provider.
UDP carries datagrams but does not guarantee that they arrive in order or get retransmitted if lost. QUIC runs over UDP and provides features such as encrypted connections, reliable streams, loss recovery, and congestion control. So “runs over UDP” does not mean that lost web content is never retransmitted. The transport mechanism still ensures the reliable byte stream required by an application.
This flow also clarifies what to check when troubleshooting: only traffic that matches a proxy policy and is routed through a Hysteria2 node uses this path. If Global Routing is set to Direct, browsing results cannot tell you how that node performs. In Config mode, check which rule actually matches the destination.
Can be more stable on poor networks, but not always faster
QUIC can deliver data on multiple streams independently. If one stream is waiting for lost data to be recovered, other streams do not have to wait for the same ordered byte stream to be restored at the transport layer. This can reduce head-of-line blocking across streams. Ordering still applies within each stream, and all streams share the same network capacity and congestion state. Multiple streams do not increase available bandwidth.
Hysteria2 throughput also depends on congestion control. Its protocol supports Brutal congestion control based on bandwidth parameters, as well as an adaptive control path. Actual behavior depends on the client implementation, server configuration, and negotiation results. A bandwidth value set too high can cause persistent packet loss and queueing; one set too low can limit throughput. Do not copy values that do not reflect your local connection capacity.
| Network condition | Possible result | What to check first |
|---|---|---|
| Random packet loss; UDP is reachable | Throughput may be more stable than with a more conservative transport, but improvement is not guaranteed. | Completion time, pauses, and sustained throughput across repeated tests. |
| Local connection is saturated | Increasing the send rate may add queueing delay and slow interactive requests. | Check for uploads, cloud backups, or other heavy traffic during the test. |
| Server outbound capacity is limited | QUIC cannot exceed the capacity limits of the server or destination. | Check whether the same limit persists at the same time of day and for the same destination. |
| UDP is dropped or throttled | The handshake may time out, or throughput may remain low after connecting. | Check whether the same configuration works on another network that allows UDP. |
Bottom line: confirm UDP is reachable before comparing throughput
If the same configuration times out on only one network, compare it with another network first. Do not immediately increase the bandwidth parameter or conclude that the protocol is faster based on a single latency reading.
Check the address, port, authentication, and TLS before importing
If you already have a subscription, import the complete parameters from your provider whenever possible to avoid missing authentication details. After importing, find the node in Home, open its edit screen, and check the protocol, server address, port, and authentication fields one by one. Hysteria and Hysteria2 are not interchangeable just because their names are similar; the imported type must match the server requirements.
Check the connection and authentication details
- Protocol
- Hysteria2; must match the server protocol.
- Server address
- Enter the supplied domain name or IP address exactly as provided.
- Server port
- Use the supplied value. If it is 443, UDP 443 must still be allowed.
- Authentication
- Preserve capitalization and symbols; remove any spaces included during copying.
443 is an example port, not a fixed port for every Hysteria2 node.
Check TLS and additional parameters
- TLS
- Check certificate verification requirements. Disabling verification is not a routine fix.
- SNI
- If a specific name was provided, enter it as instructed; do not replace it with an IP address.
- Obfuscation parameters
- Enter these only if required by the server. The type and password must match.
- Bandwidth parameters
- Keep the imported values initially. Before changing them, confirm the units and what each field means.
The fields on the node editing screen may be arranged differently. Check what each field means rather than guessing based on its position in a screenshot.
Being able to access TCP 443 does not mean UDP 443 is also allowed. They use the same number but are different transport protocols and may be handled by different firewall rules. Company, campus, and hotel networks may allow only some UDP traffic. Being able to make DNS queries does not prove that every UDP port is reachable.
Subscription updates and node connections use separate paths. A successful update only means that the subscription data was retrieved; it does not prove that a Hysteria2 server in the subscription is reachable. If an update fails, first check whether the current network can access the subscription URL and whether the link from your provider is still valid. Do not share a full subscription URL that contains authentication details.
Test under consistent conditions to distinguish handshake, routing, and throughput issues
Change only one variable at a time. If the network, node, destination content, and test time all change, you cannot tell what caused the result. The steps below are a way to record your tests, not performance claims. Actual results depend on your device and current connection.
- Keep the network consistent: Start on the same Wi-Fi network, pause large uploads and backups, and note whether other devices are using bandwidth. Then test cellular data separately; do not combine the results.
- Check routing: In Home, temporarily set Global Routing to Proxy and select the node you want to test. This affects traffic handling during the test. When you are done, restore your usual Config setting.
- Verify real-world access: Open the same HTTPS page and record whether it loads completely. A node showing as available or a latency reading from a single test does not prove that the full proxy connection can transfer data continuously.
- Repeat the transfer: Test the same trusted large file 3 times in a row. Observe each test for at least 30 seconds and note the average speed, noticeable pauses, and failures. Do not rely only on a brief peak reading.
- Test on another network: Keep the node and parameters unchanged, switch to a different network, and repeat the test. If it fails on only one network, first check how that network handles UDP.
Mind the units: Mbps means megabits per second, while MB/s means megabytes per second. Using decimal units, 80 Mbps is about 10 MB/s; protocol overhead also affects real-world throughput. This is a unit conversion example, not a speed guarantee. Convert to the same units before comparing test results with a bandwidth field in the configuration.
Config and On Demand do not change the underlying protocol
Global Routing determines how traffic is handled; the node protocol determines how the client connects to the server once a proxy is selected. In everyday Config use, rules send different requests to their assigned policies. Proxy can help narrow the scope of a test, while Direct connects without a proxy. Scene is a context-based handling option, not another form of Hysteria2 congestion control.
- Home: Check the selected node and Global Routing to make sure the test is not using a different node or Direct.
- Config: Check the active configuration and rule order.
DOMAIN-SUFFIXmatches domain suffixes,IP-CIDRmatches address ranges,GEOIPuses geographic IP classifications, andFINALhandles requests that do not match earlier rules. - Settings → On Demand: Check whether automatic connection conditions are affecting the test. After switching between Wi-Fi and cellular, check the current connection status again.
On Demand connects automatically based on conditions. It cannot make a network that restricts UDP allow it, and it does not replace node authentication. During troubleshooting, note the current conditions and, if needed, temporarily disable automatic triggers and connect manually. Restore them after troubleshooting. Keep a record of the original settings so you can return to your usual connection behavior.
Common Hysteria2 connection issues
Wi-Fi keeps timing out, but cellular works. What should I check?
Keep the address, port, authentication, and TLS parameters unchanged and try connecting on each network several times. If the difference is consistent, check whether the Wi-Fi network requires a login or restricts the destination UDP port. On a managed network, ask the administrator about its rules instead of changing ports at random; a new port will not work unless the server is listening on it.
Why won't a web page open even though I see a latency reading?
Go to Home and check the node and Global Routing. Use Proxy for a controlled access test, then restore Config. If Proxy works but Config does not, check the rule and policy that match the destination. If both fail, check authentication, TLS, and server status. A latency reading alone does not prove that a request reached its destination through the proxy.
Does a higher bandwidth parameter mean faster speeds?
No. Keep the imported values at first, stop other heavy traffic, and record 3 test results. Adjust values one at a time only after confirming the field units, server requirements, and available local capacity. If pauses, packet loss, or interactive latency increase, restore the original value instead of raising it further.
The connection still fails after updating the subscription. Do I need to buy the app again?
In Home, first check whether a node from the updated subscription is actually selected. Then check whether the protocol or port changed, and ask your provider to confirm that the parameters are valid. Buying the app and paying for a network service are separate things; buying the client again cannot fix a server issue or a UDP restriction on your current network.
Base your conclusion on repeatable results: under the same conditions, are there fewer pauses, do requests complete, and is interactive latency acceptable? Hysteria2 is worth comparing when UDP is reachable, but the protocol name alone is not a reason to replace every connection. Keep a verified configuration so you can roll back and troubleshoot when network conditions change.