Hysteria2 is worth testing on high-latency, lossy links where UDP is reachable; it is not faster on every network. For users who already have their own service details or subscription, this guide explains how QUIC, congestion control, and bandwidth settings relate. It then walks through the address, authentication, TLS, and optional obfuscation fields in Shadowrocket, followed by a step-by-step way to distinguish transport failures from routing-rule issues.
How Hysteria2 Relates to QUIC and UDP
In Shadowrocket, Hysteria2 is a proxy protocol. The client and server exchange data over a UDP-based QUIC connection, and the server then connects to the destination. UDP here describes the outer transport between the client and server. It does not mean every website you visit uses UDP, or that an app's TCP data can be discarded without reliable delivery.
QUIC combines reliable delivery, stream management, and the TLS handshake. Data that requires reliable delivery still needs to be recovered if lost; UDP itself does not retransmit packets—QUIC handles that. Hysteria2 can carry TCP connections and UDP traffic, but the two are carried differently. Using UDP for the outer transport does not guarantee delivery of all traffic.
QUIC multiplexing can prevent the loss of data on one stream from directly blocking ordered delivery on other streams, but all streams still share the connection's congestion and bandwidth conditions. Severe congestion can affect all traffic. QUIC is also not the same as HTTP/3: HTTP/3 is an application protocol built on QUIC, and sharing QUIC as a transport does not make them interchangeable.
Why It May Be Faster: Congestion Control and Bandwidth Estimates
Long-distance links have higher round-trip times, so the sender needs enough data in flight to make use of the available bandwidth. Packet loss triggers recovery in reliable transport; some congestion-control algorithms also respond by reducing the sending rate. If loss is caused mainly by wireless interference rather than congestion, backing off too much can reduce throughput. One focus of Hysteria2's design is adapting sending behavior under these conditions.
Brutal, the congestion-control method in the Hysteria2 ecosystem, uses a bandwidth target as a key input and adjusts sending in response to feedback to try to compensate for packet loss. The method actually used also depends on both implementations, negotiation, and bandwidth settings. Seeing Type set to Hysteria2 does not prove that a particular method is enabled, and QUIC itself does not guarantee a fixed speed increase.
- Bandwidth target too low: The configured rate may limit sending even when the link has spare capacity, causing sustained downloads to plateau early.
- Bandwidth target too high: Sending beyond the link's actual capacity can build queues, increase latency and packet loss, and make web browsing or real-time traffic perform worse.
- Asymmetric upload and download: A home connection's upload capacity may be much lower than its download capacity. Do not copy a download speed-test result directly into the upload target.
- Different units:
Mbpsmeans megabits per second, whileMB/smeans megabytes per second. For example,80 Mbpsis about10 MB/sbefore overhead. This is a unit conversion, not a speed promise.
Bottom line: Set bandwidth based on the link you measure
Adjust bandwidth only if the current settings expose a bandwidth input and the service documentation clearly explains what it means. Use sustained transfer performance on the same network as your guide—not the peak speed in your broadband plan or an arbitrary large number.
“Fast” can mean different things: the time it takes a page to start loading, sustained download throughput, and latency variation during real-time use are separate metrics. Higher sustained throughput does not necessarily mean faster DNS lookups or a quicker response from the destination website. Detours in cross-region routing, server load, and destination-side rate limits can also be bottlenecks.
Which Networks Suit Hysteria2? Check UDP Before Comparing Performance
Links with high latency and random packet loss, where stable UDP communication is allowed, are worth testing with Hysteria2. Fluctuating cellular signals or busy Wi-Fi can cause packet loss, but cellular service alone is not a reason to recommend a protocol. UDP handling can vary by location, time, and access network, so repeat tests where you actually use the connection.
| Network conditions | What to expect | What to check |
|---|---|---|
| High latency, random packet loss | Sustained throughput may remain good, but bandwidth and load still matter. | Use the same destination each time and record load time, throughput, and the number of stalls. |
| UDP blocked | The handshake times out or no usable connection can be established. | Check the server's UDP listener, firewall, and current access network. |
| UDP throttled | The connection works, but sustained transfers quickly hit a speed limit. | Compare your own Wi-Fi and cellular connections, changing only one variable. |
| Low latency, low packet loss | There may be no noticeable benefit. | Compare stability, application response, and changes in device battery use first. |
For each test, use the same observation window—for example, transfer data continuously for 60 seconds and repeat three times. Record the network type and any interruptions. This is a suggested testing method, not a result measured for this article. Do not change servers, DNS, and rules at the same time; otherwise, you will not know which change caused the difference.
Add Hysteria2 in Shadowrocket: Steps and Field Checks
The steps below assume you already have your own service and subscription details. Importing a subscription can reduce manual entry errors, but you should still confirm that the imported protocol type and fields are complete. Fields may appear differently depending on the current app interface. Match each one to the connection details from your server; do not substitute settings for another protocol.
-
Check the type
Go to Home → tap “+” in the top-right corner → Type, then select Hysteria2 for manual setup. For an existing subscription, select Subscribe under Type, enter your own subscription URL, and save. Return to Home to update the subscription, then check that the imported entry has the correct type.
-
Enter the address
Fill in Address and Port using the details you already have. Address is the server hostname or IP, not the subscription URL. Use the server's actual UDP listening port. For example, if the server uses port 443, enter 443—do not choose that port just because websites commonly use it.
-
Check authentication
Enter Password and check capitalization, leading or trailing spaces, and whether the full value was copied. Hysteria2 credentials must come from the corresponding server. Do not use a token from a subscription URL as the connection password or reuse authentication fields from another protocol.
-
Check TLS
Open the current entry's TLS settings and check SNI and the name used for certificate verification against the details you have. If Address is an IP but the certificate was issued to a domain, pay particular attention to the name setting. For verification errors, check the certificate, name, and validity period.
-
Save and test
Save the entry, return to Home, select it, and check the current Global Routing mode before connecting. First open a known test destination and confirm it loads, then run a sustained transfer test. Record the original values before making changes, and avoid changing multiple settings at once.
If the server has enabled optional obfuscation such as Salamander, the corresponding client setting must match. The obfuscation password and connection password serve different purposes. Do not add obfuscation if the server has not enabled it. Obfuscation cannot make completely blocked UDP reachable.
- Address: Determines which server to connect to first. If you use a hostname, the local network must also be able to resolve it.
- SNI: Indicates the server name during the TLS handshake and should match the existing service configuration. It is not a general-purpose replacement for the server address.
- Certificate verification: Checks whether the peer's identity matches expectations. If the name does not match, correct the settings or certificate instead of routinely skipping verification.
- Optional settings: Enter bandwidth, obfuscation, port range, and other values only when the service documentation specifies them and the current interface supports them. Do not guess defaults or try ports in bulk.
After Connecting: Distinguish Protocol Issues from Routing Issues
Saving an entry successfully does not mean authentication succeeded; a successful connection does not mean a particular website is using it. Shadowrocket's Global Routing determines how traffic is routed. When troubleshooting, first check whether the current mode is Config, Proxy, Direct, or Scene, then identify which rule or scene setting the test request actually matched.
Config
RecommendedFor everyday use, let the rules in your current configuration select the policy. Before testing, check whether the destination matches DIRECT or a proxy policy so you do not mistake traffic that never passed through Hysteria2 for protocol performance.
Best for: Everyday use and long-term monitoring with an existing rules configuration
Proxy
Route traffic handled by the app through a proxy path. This can temporarily help isolate the effect of rules. Still confirm that the selected entry is reachable from the destination; this does not rule out DNS, network, or server issues.
Best for: Briefly checking whether the selected connection can reach a destination
Direct
Route traffic handled by the app directly. This can help check whether the local network can reach a destination that is normally accessible directly. Success here does not prove that Hysteria2 is working.
Best for: Comparing local network connectivity with direct access to a destination
With Scene, check the settings of the scene currently in effect; a scene name does not imply a fixed proxy behavior. With Config, rules are evaluated from top to bottom: put specific conditions first and FINAL at the end of the rules section. The example below illustrates rule syntax only; it is not a complete configuration to replace yours with, and it does not indicate whether these destinations are reachable on your network.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, and GEOIP matches against an IP geolocation database. If an earlier rule sends the destination domain through DIRECT, switching to a Hysteria2 entry will not change that request's direct route. Check which policy the request uses before comparing protocol speeds.
Troubleshooting by Symptom: Timeouts, Authentication, Stalls, and Changes After an Update
A latency test returning a value only shows that the test received a response at that moment; it is not a substitute for testing the full service. In particular, a TCP port check cannot confirm the UDP handshake Hysteria2 requires. Troubleshooting by the stage where the failure occurs is usually more effective than repeatedly changing bandwidth settings.
- Connection always times out: First check Address and Port, then confirm the server's UDP listener and firewall rules. If you use a hostname, check that it resolves. Then compare using another access network available to you.
- TLS error: Check the device's time, SNI, certificate name, and validity period. If Address is an IP, pay particular attention to whether the certificate covers the name used for verification.
- Authentication failed: Confirm that Password belongs to this Hysteria2 entry, check for spaces introduced during copying and whether the credentials have changed, and make sure optional obfuscation settings match the server.
- Connected, but websites will not load: Check Global Routing, matched rules, and DNS. If only some domains fail, investigate name resolution or destination reachability first rather than assuming the entire protocol is unavailable.
- Transfers stall after running for a while: Check for UDP throttling, weak wireless signal, server load, and path MTU issues. If you set a bandwidth target, record its current value, then lower it in a single-variable test.
- Behavior changed after a subscription update: Recheck the imported entry's type, port, authentication, and TLS settings. Manually edited values may have been replaced by the update. Check the saved entry itself, not just its name.
On Demand controls when connections are established based on conditions; it is not a Hysteria2 congestion-control switch. To troubleshoot automatic connections, go to Settings → On Demand and check the relevant conditions. To troubleshoot transfer speed, keep the connection state and access network stable so that delays from automatic reconnection are not mistaken for lower throughput.
Base your conclusion on actual usage: confirm UDP is reachable, settings match, and the correct rules are being applied before comparing repeated tests. If the current network consistently blocks or severely restricts UDP, changing the bandwidth value will not solve the underlying issue. If the connection is stable and works for your needs, there is no need to keep changing settings just to chase a one-off speed-test peak.