Shadowrocket
Protocol Types and Settings
Choose Type based on the server’s capabilities, then check authentication, transport, and routing. A protocol name alone does not determine speed or replace connection testing.
- 7 protocols
- Settings checklist
- Speed and battery use
- Connection troubleshooting
What do protocols, transport, and rules each control?
Confirm the server’s protocol before choosing Type
The protocol type must match the server. You cannot switch the same address and password to another type at will. In the server editor from Home or in Add Server, Type determines how the client formats authentication and data. The server must support the same format for a connection to work. Existing subscriptions usually include these settings, so keep their original values after import. Manually create an entry only if you know the server’s actual configuration; a protocol name alone does not confirm all required settings.
Think of a connection in layers. Address and Port determine where to connect; protocol authentication determines whether the server accepts the request; transport determines how data is carried; TLS provides authentication and encryption for the relevant channel; and Global Routing determines which requests use that path. The same VLESS setup can use different transports, and two TLS connections can use different authentication methods. Mixing up these layers can lead to mistakes—for example, changing a password when the actual issue is a certificate mismatch.
Seven protocols, not a speed ranking
A protocol’s history reflects its design goals, not guaranteed performance on every network. Shadowsocks focuses on lightweight proxy forwarding; VMess includes its own authentication and data protection; VLESS delegates more protection to an outer layer; and Trojan carries proxy requests over TLS. HTTP and SOCKS5 are general-purpose proxy interfaces, WireGuard handles IP-layer tunneling, and Hysteria2 uses QUIC-based transport. They solve different problems, so don’t rank them from old to new by name alone.
Speed is usually limited first by the server’s outbound capacity, round-trip time, congestion, and wireless signal—not protocol overhead. Opening a webpage may involve DNS lookups, handshakes, and many short requests, while sustained downloads depend more on throughput; the results can differ. On iPhone, cellular signal, Low Power Mode, and app backgrounding also matter. A single top speed test result is not a reliable measure of everyday performance. For a fair comparison, keep the device, network, server conditions, and test target constant, and change only one variable at a time.
| Layer | What to check | Common mistake |
|---|---|---|
| Protocol authentication | Type, Password, UUID, or key | Using credentials for a different protocol |
| Transport and protection | TLS, SNI, Path, UDP reachability | Outer connection works, but requests fail |
| Request routing | Global Routing, Config, rule order | Requests don’t reach the server being tested |
Assess battery use and compatibility by workload
Battery use depends on the amount of data transferred, how connections are maintained, and how long the wireless radio is active—not on a permanent property of a particular protocol. Repeated TLS handshakes can add short bursts of overhead; frequent keepalive packets can wake the network more often; and retransmissions after packet loss also use power. Evaluate long video sessions, occasional messages, and standby separately. If the device gets warm, first check traffic changes in Data and background activity instead of assuming the protocol implementation is at fault.
Check TCP and UDP support separately. A webpage loading only confirms that requests on that path succeeded; it does not prove that voice or other UDP traffic can pass. Some protocols support UDP, but the server, current transport, or upstream network may not allow it. Conversely, a protocol using UDP as its outer transport may still forward an app’s TCP requests. Application traffic type and outer connection type are different concepts; seeing “UDP” does not tell you how all app traffic behaves.
For an initial choice, answer three questions: What does the server actually support? What does the current network allow? What kind of traffic needs to pass through? Then check whether the authentication details are complete, the certificate can be verified, and failures will be easy to diagnose. If only one type is available, configure it correctly rather than looking for settings the server cannot support. To learn about sharing formats, read Share Links vs. Subscription Links, then return to the relevant protocol section.
Shadowsocks: Match the authentication method and encryption settings
Designed for proxying app traffic, not as a full IP tunnel
Shadowsocks creates protected proxy forwarding between the client and server, carrying the destination address and subsequent data. It does not simply send every IP packet from the device to a remote server, nor is it equivalent to setting a system-wide proxy address. Shadowrocket receives requests that need handling, then uses rules to decide whether to send them through that entry. Using Shadowsocks does not mean all websites go through that server; that also depends on Global Routing and Config.
Its relatively lightweight structure suits setups with clear server details where an additional transport layer is unnecessary. Actual performance still depends on the encryption implementation, server load, and network conditions. Modern authenticated encryption methods also verify data integrity, so the client and server must use the same method and key format. Options that share an algorithm name are not necessarily interchangeable; mode, key length, and protocol generation can all affect the data format.
Check Method and Password first, then any additional transport
When adding a server manually, check Address, Port, Method, and Password against your existing server details. Address may be a domain or an IP; Port is the port the protocol actually listens on; Method must match the exact encryption method; and Password must be copied in full, including letter case. Punctuation in a password does not mean you should escape or remove it. After importing a share link, inspect the parsed fields instead of pasting the entire link into the password field.
Some methods require a specific key format, so don’t treat every value as an ordinary password. For example, certain methods require a key of a particular length and encoding. A field labeled Password does not mean any text will work. The safest approach is to keep the imported value and compare it with the server’s actual configuration. If an import immediately reports a settings error, first check that the format matches the method. If it connects but receives no data, distinguish network reachability from authentication failure.
Additional plugins or encapsulation add separate matching requirements. If the server requires a specific plugin, Host, or Path, the main protocol password alone will not establish a working channel. Don’t enable an extra layer on the client if the server does not use it. Available options and their names depend on the current app interface and server details. If a setting is unclear, check the source of your existing configuration instead of copying a “common setting” from another server; otherwise, you may make the problem worse.
Verify UDP support and encryption separately
Shadowsocks can carry UDP requests, but availability depends on server support and the current entry’s settings. If TCP webpages work but UDP requests fail, first check whether the server supports UDP and whether the network path allows it. Then inspect the app’s actual destination and port. Some additional transports work only with certain traffic types, so don’t assume the protocol’s general capabilities apply to every combination. Keep the basic TCP connection stable, then test UDP separately to avoid repeatedly changing a password that is already correct.
On iPhone and iPad, a lightweight connection does not guarantee lower battery use in standby. Repeated failed UDP requests or an unstable server that keeps rebuilding the connection may use more power than a complex connection that works properly. Compare under the same workload and observe a full usage session. A short download test can reveal an obvious bottleneck, but it cannot predict all-day battery life. Recheck connectivity after switching from Wi-Fi to cellular.
This protocol suits setups where you have complete server details and the server explicitly uses Shadowsocks. If a problem occurs, check DNS resolution, listening port, encryption method, password, and additional transport in order instead of replacing the entire entry. Change one setting at a time, retest, and keep the last working configuration. If a subscription update changes the settings for an entry with the same name, compare the actual fields before and after the update. The same display name does not guarantee that the address, Method, or authentication details stayed the same.
VMess and VLESS: Separate protocol authentication from outer protection
A similar UUID does not mean the connection works the same way
VMess includes user authentication and its own data protection mechanism. VLESS uses a more lightweight identity structure and relies more on an outer layer such as TLS for channel protection. Both may use a UUID, but the server handles them differently. Changing Type from VMess to VLESS and keeping all other fields does not convert the entry. Use the type specified by your existing connection details. To compare them, the server must have both corresponding entries configured.
A UUID is an identity, not a server address or an arbitrary query parameter in a subscription link. When copying it, check for spaces, line breaks, or quotation marks, and preserve the full value. VMess may also use security options or legacy compatibility fields; follow the server details rather than assuming every server needs the same number from an old tutorial. VLESS’s simpler authentication does not mean you can ignore outer protection. If an entry requires TLS, disabling it will usually prevent the connection from working as expected.
Treat transport options as a group
Transports such as TCP and WebSocket describe how proxy data is carried; they do not replace VMess or VLESS identity authentication. The same address may provide different entry points, with one requiring WebSocket and another accepting only a direct TCP connection. If the transport is wrong, the port may still appear reachable while subsequent data cannot be handled correctly. When adding a server, check the transport together with its Host, Path, and related settings instead of changing only the top-level option.
The WebSocket Path is the request path accepted by the server and usually must match exactly, including the leading slash and letter case. It is not an arbitrary website directory. Host is the hostname information in the relevant request; SNI is used during the TLS handshake. They may be the same value, but serve different purposes. Address can point to the connection endpoint, while Host and SNI may use names required by the configuration. Don’t make them identical just because the three values differ; verify each one against your existing details.
Certificate verification in TLS confirms the identity of the connection endpoint. “It connects” is not a reason to disable verification. A mismatch between the certificate name and expected name, an incomplete certificate chain, or a device clock that is significantly wrong can all cause a handshake failure. Check SNI, the certificate, and the device time instead of skipping verification. For an entry requiring a different handshake or specific combination of settings, preserve the imported values. An option being available in the interface does not mean every server supports it.
Include transport overhead when comparing performance
Extra encapsulation and handshakes add work before the first request, but whether you notice depends on connection reuse, round-trip time, and workload. When consecutive requests reuse an existing connection, the initial cost may be spread out; with repeated short connections, handshake time is more noticeable. A speed comparison on a stable network also cannot predict performance under a weak signal. Everyday iPhone use includes background recovery and network switching, so test those situations before deciding which combination works best for your conditions.
If a server test returns a result but webpages will not load, distinguish port reachability from a successful end-to-end request. First confirm that Global Routing sends the target through this entry, then check the UUID and Type, followed by TLS and transport settings. If the browser shows a certificate error, determine whether it came from the proxy endpoint or the destination website; these are different certificates. Recording the specific error and the stage where it occurred is more useful than simply noting “connection failed.”
| Setting group | Purpose | How to check |
|---|---|---|
| Type / UUID | Select the protocol and identify the user | Match the server protocol and identity details |
| TLS / SNI | Channel protection and identity verification | Check the entry requirements and certificate name |
| Host / Path | Match the additional transport entry | Compare each field separately; they are not interchangeable |
If you have several protocol entries available, start with one that has complete settings and passes certificate verification, then compare how it performs for your workload. Don’t assume VLESS’s simpler structure must use less power, or that VMess’s built-in protection makes outer settings irrelevant. For a quick overview of protocol names, read Supported Protocols at a Glance. This chapter covers dependencies between settings and where failures can occur.
Trojan, HTTP, and SOCKS5: Check the channel after authentication
Trojan Password and TLS serve different purposes
Trojan carries proxy requests over a TLS channel. The client first establishes the required protected layer, then submits authentication and destination details according to the protocol. Password authenticates the proxy request; the certificate verifies the connection endpoint. Neither replaces the other. The connection may fail before authentication if the password is correct but SNI is wrong. A verified certificate does not provide proxy forwarding if the password is incorrect. Troubleshoot in stages: network connection, TLS handshake, protocol authentication, and destination access.
Start by checking Address, Port, Password, TLS, and SNI, then verify any additional transport against your existing details. Address is not necessarily the source of the certificate name, especially when connecting to an IP; the certificate may still need to be validated against a domain. If the interface offers an option to skip certificate verification, don’t treat it as a routine fix. Match the server certificate and name to what the client expects so a successful connection actually verifies identity.
Trojan and other TLS combinations can both incur handshake delays when first opening a webpage; this does not establish a fixed speed ranking. Connection reuse, server response times, and packet loss on the current network may matter more than the size of a protocol header. When a mobile device resumes from the background, the old connection may no longer be valid. A brief reconnection does not necessarily mean the authentication details are wrong. Check whether requests resume normally instead of treating every new connection as a failure.
HTTP and SOCKS5 are interface specifications; they do not automatically encrypt the connection
An HTTP proxy forwards requests using HTTP mechanisms. For an HTTPS destination, it typically uses CONNECT to establish a tunnel to the target. Distinguish HTTPS between you and the website from TLS between the client and the proxy endpoint: the former protects the website session, while the latter protects the connection to the proxy. An HTTP proxy that allows CONNECT may still restrict which ports can be accessed; the server’s access policy may limit destinations.
SOCKS5 negotiates connections to destinations and can support usernames, passwords, and different address types. The specification also defines UDP-related mechanisms, but a server may not implement or enable them. SOCKS5 does not automatically encrypt all traffic on the proxy connection, and username/password authentication is not an encryption layer. For an existing entry, first confirm whether it provides an additional protected channel and consider the trust boundaries of the current network before choosing it for a particular workload.
Which side resolves a domain can affect how the proxy interface behaves. The request path may change depending on whether the destination is sent to the proxy as a domain or an IP, how client DNS settings work, and whether rules trigger a lookup first. Don’t assume from the protocol name alone that every DNS query is resolved remotely. If only some domains fail, check their resolution results, destination reachability, and proxy access restrictions separately. If every destination fails, start with authentication and the connection endpoint.
Choose based on the intended use; general-purpose does not mean full-featured
HTTP and SOCKS5 suit setups with an existing general-purpose proxy interface and clearly defined settings and access limits. Type must match the entry; the same port does not necessarily accept both protocols. Check the server details to see whether a username can be empty, whether the password contains special characters, and which authentication method is required. A connection test that opens a socket only confirms part of the path. Make an actual request to a known accessible destination to verify authentication and forwarding end to end.
For real-time voice or other UDP traffic, don’t stop testing just because an HTTP or SOCKS5 entry can load webpages. Confirm that the entry can carry the required traffic type and test it over the same network. If the entry is explicitly limited to certain destinations, respect that access scope instead of trying to change the server’s policy by repeatedly switching client settings. Choose based on your existing needs, not on which protocol name looks most versatile.
WireGuard: Check keys, tunnel addresses, and allowed ranges together
Carries IP packets rather than just specifying proxy destinations
WireGuard is a lightweight encrypted IP-layer tunnel. It identifies peers with public keys and carries data over UDP. Unlike an app proxy protocol that submits destination addresses, it also requires the client and server to know how tunnel addresses are assigned and how to route destination traffic to the right peer. When using WireGuard in Shadowrocket, the app’s overall traffic handling and routing still apply. The meaning of a tunnel configuration is not identical to a Global Routing mode.
Key relationships are the starting point for troubleshooting. Keep the client Private Key secret, and register its corresponding public key on the server. The client’s Peer Public Key should be the server peer’s public key. Reversed fields, incomplete copies, or an outdated public key can prevent the handshake. If the details include a pre-shared key, both ends must use the same value. Never put the server’s public key in the client private-key field, and never include a real private key in a feedback screenshot or public report to fix a connection.
Keep Endpoint, Address, and Allowed IPs separate
Endpoint is the server’s location on the external network, usually a domain or IP plus a UDP port. Address is used inside the tunnel; it is not the device’s current Wi-Fi LAN address or the server’s public address. Keep the address and prefix from your existing configuration. Replacing them with a private address that merely looks unused can conflict with the server’s routing or address allocation. A successful handshake shows that the keys and endpoint basically work; it does not prove that the internal address is correct.
Allowed IPs specifies destination address ranges associated with the peer and also participates in routing decisions; it is not an app-level domain rule. If the range is missing, the handshake may succeed while application traffic fails to reach the intended peer. A broad range does not mean every Shadowrocket request will bypass Config. Check the tunnel settings in the server entry separately from app-level policies, and verify with an actual destination. For IPv6, confirm that the tunnel address, destination range, and server forwarding all support it.
DNS is a separate setting. If an IP is reachable through the tunnel but its domain is not, the issue may be whether the DNS server is reachable—not WireGuard encryption. A DNS address in the existing configuration may only be accessible through the tunnel, so the path and rules must allow those requests. To troubleshoot, compare access by IP with access by domain, then check DNS results. Don’t change keys to fix a resolution failure, and don’t rule out routing issues just because the handshake succeeds.
Tune MTU and keepalive for the path
Encapsulation takes up additional space, and MTU limits packet size. An MTU that is too high can cause large requests to hang, some webpages to load incompletely, or sustained transfers to fail on certain paths, even when small requests work. Too small an MTU can reduce throughput. Adjust it cautiously only when there is evidence of a packet-size issue. Keep the original value and compare the same task each time; don’t copy a number from a different network as a universal setting.
Persistent Keepalive can maintain a network mapping when needed, but it is not a speed boost. Cellular networks and some router setups may need periodic traffic to keep the return path open, while overly frequent keepalives can wake the wireless radio and use more power. Base the setting on whether an idle connection fails to resume, rather than defaulting to a very short interval. On iPhone, check behavior with the screen off and after network changes separately from sustained foreground downloads.
| Setting | Layer | Possible issue |
|---|---|---|
| Endpoint | External connection endpoint | UDP path or port is unreachable |
| Private Key / Peer Public Key | Identity and handshake | Keys do not match or server registration is out of date |
| Address / Allowed IPs | Tunnel address and range | Traffic fails to reach its destination after handshake |
| MTU / Persistent Keepalive | Path adaptation and connection maintenance | Large requests fail or connection does not resume after idle |
WireGuard suits setups with complete tunnel details and a need for a defined IP-layer access range. Its lightweight structure does not remove the need for server forwarding, firewall rules, or address planning. If you only have an Endpoint and one public key, that is usually not enough to rebuild the full configuration; check with the source of your existing configuration. When reporting a problem, note the failure stage, network type, and destination range, but keep keys and internal access details in a controlled environment.
Hysteria2: Confirm UDP reachability before adjusting bandwidth
QUIC-based does not mean faster on every network
Hysteria2 uses QUIC-based transport, relies on UDP for the outer connection, and uses TLS-related mechanisms to establish a protected channel. Its design addresses data transfer under varying network conditions, but that does not mean every UDP network will deliver the same performance. Some Wi-Fi and cellular paths handle UDP differently from TCP and may throttle it, drop packets, or change mappings. If even the basic handshake fails, check outer-layer reachability before raising bandwidth settings.
QUIC’s multi-stream design can reduce certain forms of transport-layer blocking between streams, but packet loss still consumes bandwidth, congestion still needs handling, and client and server processing capacity still matters. Whether an app request gets faster depends on how the transport fits the actual workload. Better performance on one large download does not mean lower standby battery use for messages. Maintaining a high send rate on a weak signal can also increase retransmissions and heat; assess a complete session.
Match authentication, certificates, and optional settings separately
Check Address, Port, authentication details, and SNI. Keep the authentication format required by the server; don’t reuse a UUID or Password from another protocol type. If your existing details include extra obfuscation settings, the client and server must match; neither side can enable them unilaterally. Hysteria2 and similarly named protocol generations are not interchangeable based on the address alone. Type must match the existing server entry.
Certificate verification remains essential. When the connection uses an IP address, SNI may still need to contain the domain on the certificate. A mismatched domain certificate, an incomplete chain, or an incorrect device clock can all cause a failure before authentication. Check against your existing server details instead of skipping verification by default. If the error concerns a certificate, note the error type and expected domain. Avoid changing the password, port, and certificate settings at the same time, or you won’t know which change mattered.
Interpret upload and download bandwidth fields using the units shown in the current interface, and consider whether the server supports the relevant congestion-control mode. Entering a larger number does not create more bandwidth; in some combinations it can increase queuing, packet loss, or contention. Available network capacity also changes over time. A home broadband plan’s advertised rate does not equal sustainable throughput on a cellular network right now. Without a clear reason to change settings, keep the imported value or current defaults and use repeatable tests to decide whether an adjustment helps.
Separate “can’t connect” from “connects but is unstable”
If the connection cannot be established at all, check domain resolution, UDP port reachability, and whether the current network permits the path, then check authentication and TLS. If switching networks fixes it, that only shows the two paths have different conditions; it does not prove the original password was wrong. You can retest on another known-good network with the same device, but keep the server settings unchanged. A network switch is useful diagnostics only when the variables are clear, not as an undocumented one-off attempt.
If data passes but performance varies, check packet loss, whether sustained uploads are crowding out downloads, and changes in device temperature or wireless signal. When uploads approach available capacity, queueing can increase latency and degrade webpages or real-time traffic. That is different from insufficient peak download speed. Pause other high-traffic tasks and test short requests, sustained transfers, and real-time use separately. Change only one setting at a time and keep a record of the original value.
Hysteria2 suits setups with a corresponding server, a network that allows UDP, and a willingness to test against actual workloads. It is not a universally better choice for every Wi-Fi, cellular, or standby scenario. If it works well only during foreground downloads, also test screen-lock recovery, network switching, and low-traffic use; these better reflect everyday conditions. Keep a configuration only if you understand its settings, certificate verification works, and repeated tests are stable—not just because it produced the highest one-off result.
Check imported settings and understand Global Routing’s role
A successful import only means the content was recognized
Shadowrocket accepting a subscription or share link does not mean the server is currently available or every field matches its existing entry. After import, check Type, Address, Port, identity fields, and transport settings before selecting the server to test. For an existing subscription, get updates from your own configuration source and note that an update may overwrite manual changes. Before keeping local adjustments, identify which settings are managed by the subscription so you know what may change on the next update.
Share links and Subscribe subscriptions serve different purposes. A share link usually describes one entry; a subscription may return multiple entries and update over time. They may also use different encodings or formats. A QR code is just another way to carry content; it does not make incorrect settings valid. After importing with Scan QR Code, check the result, especially authentication details with special characters, paths, and extra parameters. A subscription URL may contain access credentials, so don’t include it in public screenshots, records, or shareable troubleshooting reports.
Use a mode to check the path, then rules to control routing details
In Global Routing, Config, Proxy, and Direct represent configuration-based routing, proxy routing, and direct connections. Config processes requests using the currently enabled configuration rules; Proxy generally sends requests through the proxy path; Direct connects without the proxy. These determine where requests go, not how the server protocol authenticates them. To troubleshoot a server entry, first verify it in a clearly defined proxy mode, then return to Config and check the rules. Restore the mode that suits everyday use when testing is complete.
| Mode | Primary use | What it does not prove |
|---|---|---|
| Config | Route requests using the active configuration rules | That a specific destination uses the current server |
| Proxy | Check proxy routing and server performance | That protocol alone controls all app behavior |
| Direct | Compare against a direct-connection baseline on the current network | That proxy authentication or transport settings are correct |
Rules are usually matched in order, so a specific condition near the top may take precedence over a broader one below it. DOMAIN-SUFFIX matches domain suffixes; IP-CIDR matches IPv4 address ranges; and FINAL is the policy used when no earlier rule matches. Rules can route requests through PROXY or DIRECT, but they cannot fix an incorrect Password, UUID, or certificate. If a domain works directly but fails under Config, first check which policy matched, then determine whether the failure is at the proxy endpoint or destination service.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYThis is a .conf snippet to illustrate rule order, not a complete everyday configuration. example.com is a documentation domain; the private address range is shown only as a rule example; and GEOIP results depend on the data used and the actual destination address. Interpret the snippet in the correct [Rule] section; don’t paste it into an Add Server authentication field. For more on how sections fit together, see Config File Sections: General, Rule, Host, and URL Rewrite.
DNS and On Demand are not protocol authentication
DNS determines how domains are resolved, while rules determine where requests go. They can affect each other, but neither is the server Type. If a domain resolves to multiple addresses, their reachability may differ; changing the proxy protocol name alone will not fix an incorrect DNS result. Consider IPv6 separately: a device having an IPv6 address does not mean the existing server can forward all IPv6 destinations. Check the actual address type and request path to identify whether DNS, routing, or server capabilities need attention.
On Demand controls when a connection is triggered under specified conditions. It does not convert VMess to VLESS or replace Config rules. If enabling it starts a connection when the network changes, check the trigger conditions first. If the connection is established but some destinations fail, revisit the rules, DNS, and protocol settings. Track “when to connect” separately from “how to route traffic once connected” to avoid repeatedly changing automatic connection settings to fix one website.
Before making manual changes, keep a recoverable copy of the configuration and make sure it contains no sensitive information that should not be shared. Data in the app can help show whether traffic is flowing; connection logs, if available, can help identify the policy and failure stage. Increased traffic does not mean the request ultimately succeeded. A useful troubleshooting sequence is: complete settings, matching protocol, reachable outer endpoint, successful authentication, matching rule, and destination response. Confirm each step before moving to the next; don’t change multiple layers at once.
Compare speed, battery use, and connection stability by use case
Use repeatable tests, not just a single number
For a useful comparison, keep the device, network, test target, and workload constant, and record the server entry and Global Routing mode. If two protocols use different servers, the results also reflect differences in server load, outbound capacity, and network path—not just protocol. Pause obvious background transfers, confirm the subscription did not change entries during the test, then repeat the same steps several times. Recording when a problem occurs is usually more informative than noting the highest speed.
Interpret Connectivity Test results according to the method used. The test may not cover every stage, including DNS, full protocol authentication, TLS, and the final website request. A low test time does not guarantee smooth video playback, and no response does not by itself prove that every type of traffic is unavailable. Treat it as an initial clue, then verify with a real request. If an entry passes the list test but a destination page fails, check routing, authentication, and the destination’s response instead of simply rerunning the test.
Assess three types of everyday use separately
For webpages and lightweight requests, focus on time to first response and consistency across repeat visits. Choose destinations you know work, then compare the first load, reopening the page, and visiting several pages in sequence. If the first load is slow but later requests work normally, DNS resolution, handshakes, or connection reuse may be involved. If only one destination consistently fails, check its route and rules. Prefer an existing configuration with clear settings, complete verification, and stable responses; peak sustained-download speed is not the priority here.
For sustained downloads and video, check steady throughput, variation, and retries. A fast start followed by a slowdown may reflect congestion, server load, or wireless conditions; don’t judge by the first few seconds alone. Real-time traffic depends more on latency variation, packet loss, and UDP support, so even high average throughput can come with audio dropouts. To compare Hysteria2 with another existing entry, use the same workload and confirm the current network allows each one’s outer transport. Otherwise, the comparison is not fair.
For standby and mobile use, check screen-lock recovery, Wi-Fi-to-cellular switching, and long periods of low traffic. Observe battery statistics over a period that reflects your usual routine, taking screen use, signal, and other app activity into account. A short test cannot reliably isolate protocol power use. If the device gets warm and shows significant uploads or repeated retries, identify the traffic and failure cause first. If there is no unusual traffic, check keepalive and recovery behavior without disrupting an otherwise stable connection.
Use the failure stage to narrow down what to change
If the connection cannot be established at all, check whether the device has internet access, whether Address resolves, and whether Port and the outer transport are reachable; then check authentication and certificates. If the connection is on but no destinations work, check Global Routing, the current SERVER selection, DNS, and rules. If only some destinations fail, start with their resolution results, address type, matching policy, and server access. For more detailed steps, read Connected but No Internet: Step-by-Step Troubleshooting.
| Current need | Check first | What justifies keeping the setup |
|---|---|---|
| Everyday web browsing | DNS, handshakes, rules, and short requests | Consistent repeat visits and explainable errors |
| Sustained transfers | Steady throughput, congestion, and temperature | Performance over the full task, not a momentary peak |
| Real-time traffic | UDP, packet loss, and latency variation | Continuity in the actual workload |
| Access to internal IPs | Tunnel addresses, destination ranges, and return routing | Required addresses are reachable and ranges match expectations |
If you have several entries to choose from, first rule out combinations with incomplete details or failed identity verification, then compare them against your actual workload. For internal address access, check that a complete WireGuard configuration has the required tunnel ranges. Use HTTP or SOCKS5 according to the capabilities of an existing general-purpose proxy interface. Choose other protocols based on server support and the current network path. These use-case notes are not a fixed ranking; results vary by network and server configuration.
Your final setup should answer four questions: Why did you choose this Type? Where did each authentication field come from? Which requests will use it? Which layer should you check if something fails? After consulting this reference, return to the user guide and review the import and connection steps. To verify the app’s source, visit the App Store authenticity checklist and check the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. Clear reasons for each setting and a recoverable configuration are more useful than repeatedly trying unverified combinations.