ShadowrocketProtocol Guide

1. Choosing a protocol: understand the four layers

The protocol must match the server

Choosing a protocol in Shadowrocket isn’t about picking the “fastest” name from a list. The client must use the protocol that the server is configured to accept; the same address and port usually won’t work just by changing the protocol name. If your subscription specifies a protocol, keep that setting. When adding a server manually with Add Server, first gather its address, port, authentication details, and any required transport or encryption settings. If information is missing, check the existing service’s configuration rather than repeatedly trying different options.

It helps to think of a configuration in four layers. First, the address and port determine where to connect. Second, the protocol and authentication determine how the two sides identify each other and exchange requests. Third, the transport determines how those requests are carried. Fourth, settings such as TLS determine how the connection verifies identity and protects data in transit. Some protocols combine several layers, so not every add-server screen shows every field. A missing field does not necessarily mean a feature is unavailable, and fields from another protocol should not be copied over by default.

Speed, battery life, and security are different measures

Speed involves at least three stages: establishing a connection, receiving the first response, and maintaining throughput. Fewer handshake steps may reduce the wait before a page first opens. Suitable congestion control may help during longer transfers, while a less busy server can make any protocol feel more consistent. Battery use also depends on signal strength, retransmissions, background wake-ups, and how often the connection is kept alive. You can’t predict a fixed battery-use ranking from protocol names alone. On a weak cellular connection, repeated reconnects may use more power than differences between encryption algorithms.

Authentication and encryption are separate. A password or UUID identifies a user; it does not automatically encrypt every part of the connection. TLS encrypts the channel between the client and server, but that does not mean the protocol protects every connection from the server to the destination website. Pay attention to the website’s own secure connection as well. A useful starting point is to understand which parts of the full connection are covered, rather than looking for a name that supposedly describes every security property.

Protocols and routing solve different problems

Global Routing determines whether rules select a path for traffic; the protocol determines how a connection sent to a server is carried. Config mode follows the current configuration. Proxy mode sends eligible traffic through the selected proxy. Direct mode connects without a proxy. Switching between these modes won’t fix an incorrect password or port; changing protocols won’t correct a misconfigured DIRECT or REJECT rule. When troubleshooting, check separately whether traffic is routed through a server and whether it can communicate once it gets there.

Save a copy of the configuration that reproduces the problem before making changes, then adjust one setting at a time. A server name can help you identify an entry, but it doesn’t prove which protocol it uses; a region label doesn’t tell you the physical distance or actual route either. If entries with the same name differ before and after importing, compare their fields rather than just their names. The available protocol options depend on what the app currently shows. This guide explains what fields mean; it doesn’t recommend a particular server setup as the default for everyone.

2. Shadowsocks: lightweight forwarding and encryption methods

Designed for a lightweight proxy wrapper

Shadowsocks is designed for encrypted proxy forwarding: it wraps the destination address and app data, then passes them to the server. It is not a full device-networking protocol and does not require an internal tunnel address for the device. For users, the key details are usually the server address, port, password, and encryption method. Fewer fields can make manual entry simpler, but none can be skipped. In particular, the encryption method must match the server’s actual configuration.

Earlier stream ciphers and later AEAD methods differ in how they handle integrity and messages. AEAD provides both data confidentiality and integrity checks; methods with similar names are not necessarily interchangeable. Protocol generations may also differ in key length, encoding, and authentication structure. If the configuration specifies a key in a particular format, don’t replace it with an ordinary short password. If the app doesn’t recognize the combination, first check that both sides support it rather than picking a similar-looking option.

Check Password and encryption method together

Password is sensitive authentication data. When copying it, watch for leading or trailing spaces, line breaks, and full-width characters. The encryption method determines how the corresponding key material is used, so both must match the server. Being able to save an entry only means the form accepted it; it doesn’t confirm remote authentication. A latency test result doesn’t prove the password is correct if webpages still won’t load: different tests may check only part of the connection. Check an actual request and the app’s logs.

Some existing configurations also include transport extensions. These are part of the server setup, not switches that automatically make a standard entry faster. Don’t copy a Host, path, or extension option from another entry, and don’t enable one without instructions. If an imported subscription entry reverts after an update, the subscription likely still manages those fields. To compare changes, save a separate test entry so that updates don’t overwrite your edits and erase useful troubleshooting evidence.

TCP, UDP, and real-world performance

Shadowsocks can forward TCP and UDP traffic, but whether both work depends on server support and network conditions along the route. Loading a webpage doesn’t prove that apps relying on UDP will work; an app with no audio or a long delay doesn’t immediately point to the protocol either. First check which traffic types your existing service explicitly supports, then review the relevant app settings. To test, try a few requests from a real use case rather than running a large, continuous traffic test.

On iPhone, a lightweight wrapper may provide a direct path for common short connections, but the encryption algorithm, device hardware, server bandwidth, and packet loss all affect the result. A simple design is no guarantee of low battery use. During a long download, screen state and the wireless link can have a substantial impact; while idle, connection keep-alives and background network activity may matter more. Compare two existing entries on the same network, with the same content, at similar times so that differences in conditions aren’t mistaken for protocol differences.

A sensible troubleshooting order is to check the address and port, verify the encryption method and password character by character, then confirm any transport options and UDP support. If only some sites fail, check rules, DNS, and destination reachability instead of rebuilding the entry right away. If all requests fail while the direct connection works, note when the problem occurred and the error category, then check the remote listener and authentication status. For the difference between a server test and real-world browsing, see latency tests and real-world performance.

3. VMess and VLESS: authentication, transport, and TLS

Similar fields don’t make protocols interchangeable

VMess combines user authentication with data transport. It uses details such as a UUID to identify the user and handles security and data formatting at the protocol layer. VLESS uses a more streamlined design and relies more on outer mechanisms such as TLS for the secure channel. Both may show UUID, transport, and TLS fields, so their settings screens can look similar, but they are different protocols—not two names for the same one. If the server is configured for one, you can’t simply select the other and assume all the settings still apply.

Streamlined doesn’t mean faster in every situation, or that security settings can be skipped. VLESS does not provide the same data-encryption functions as VMess; actual protection depends on the entire transport setup. Read the protocol name, transport, and security settings together in the service details. “Use VLESS” is only part of a configuration: you still need to know the connection endpoint, authentication ID, outer security method, and any required transport options. The protocol name alone doesn’t tell you what values to use.

UUID, time, and legacy settings

A UUID is an authentication ID. Preserve its full format and characters; it isn’t a label you can make up. After importing a subscription, check that the protocol and ID were parsed correctly before reviewing additional options. VMess authentication is time-sensitive, so a device clock that is significantly off can cause a handshake to fail. Check that the system date and time are correct. Don’t add legacy fields to a current entry just because you found them in an older guide, or assume an old combination works with every server.

If an entry includes a field such as Encryption, interpret it in the context of the selected protocol. Don’t copy a value from one protocol into another. A field being available in the app doesn’t mean the server accepts every possible value. Before adding a server manually, list the fields that are explicitly specified and those that aren’t. Keep unspecified fields at the app’s applicable defaults, and check with your existing service if needed. Guessing at several fields at once makes it harder to identify the original cause of a failure.

WebSocket, gRPC, and certificate names

WebSocket is a transport that often uses a path and request Host; a gRPC setup may use settings such as a service name. Paths are usually case-sensitive, and a leading slash, trailing characters, or escaping can affect matching. The server address locates the endpoint. Host is used to handle the corresponding request, while SNI indicates a name during the TLS handshake. These values may be the same or different; use the existing configuration rather than filling every name field with a domain just because it resolves.

For TLS verification, the certificate must match the server name in use, and its certificate chain must validate. Don’t treat ignoring verification as the standard fix for a certificate error. Check the device time, SNI, address, and certificate validity first, then review the server configuration. ALPN negotiates the application-layer protocol, so its value must also match the transport setup. Adding names at random won’t improve compatibility; it may make the handshake conflict with the server’s requirements.

On mobile networks, an extra transport layer adds some wrapping and handshake work, but the actual impact depends on connection reuse, server processing, and network quality. Frequent short requests and long file transfers may behave differently. First get one correctly configured entry connecting reliably, then compare other working setups. If the connection succeeds but pages don’t fully load, check DNS, rules, and destination connectivity rather than repeatedly changing the UUID.

4. Trojan: proxy requests over a TLS channel

TLS provides the secure channel

Trojan is designed to carry authentication and proxy requests inside a TLS connection, using established TLS mechanisms to protect communication between the client and server. It isn’t interchangeable with other protocols that also use TLS: TLS is the outer secure channel, while the data inside still needs to follow Trojan’s authentication and request format. A secure website port on a server isn’t necessarily a Trojan endpoint. Completing a TLS handshake also doesn’t mean proxy authentication has succeeded.

A typical setup requires an address, port, Password, and TLS name settings that match the server. Password is an authentication credential; the certificate confirms the identity of the server. They serve different purposes. A correct password won’t help if certificate verification fails, and a valid certificate won’t make an incorrect password work. This lets you separate errors into two stages: the secure channel didn’t come up, or authentication or the request failed after it did. There’s no need to change every field from scratch each time.

How the address, SNI, and certificate chain relate

The address can be a domain or a specified IP address. SNI is the name indication in the TLS handshake and should normally match the name required by the server. If you connect by IP but the certificate was issued for a domain, pay particular attention to name verification. Being able to connect to an IP doesn’t mean you can use any SNI. If several services share an endpoint, the name may also determine how the server handles the connection. A wrong value could return a different certificate or response.

Certificate-chain verification checks the trusted issuer chain, validity period, and name match. If there’s an error, check the system time first, then confirm the address and SNI have no extra characters and check the remote certificate status. Don’t recommend permanently disabling verification as a routine fix; it weakens server identity checks. If your existing service uses a special certificate setup, understand its trust requirements and risks, then follow its instructions. Don’t copy verification switches from an unrelated entry.

Handshake overhead and mobile performance

A TLS handshake adds negotiation and round-trip time when establishing a connection, but this isn’t a cost unique to Trojan; other TLS-based setups do the same. Connection reuse, session resumption, and network latency all affect the experience. Opening several pages in quick succession can behave differently from keeping one connection open for a long time. “TLS always makes it slower” and “this port always uses less battery” are both unreliable assumptions. Compare specific tasks under the same network conditions.

When an iPhone switches from Wi-Fi to cellular, an existing connection may need to be re-established. If the delay is brief, wait to see whether it recovers rather than assuming the password is invalid. If it fails every time you switch networks, check reachability on the current network, the DNS result, and the server endpoint separately. Too many reconnects increase wireless activity and processing. Confirm stable server settings and sensible connection behavior before repeatedly changing advanced fields.

Whether Trojan can forward UDP depends on the server implementation, client support, and actual settings; the protocol name alone doesn’t guarantee that every app will work. If webpages load but a real-time app fails, note the app’s network requirements, then check UDP and the routing path. If only one destination fails, see what to check when the switch is on but there’s no internet rather than attributing every problem to the certificate or protocol.

Trojan is a good fit when you already have a fully specified endpoint with valid certificate settings that works reliably in practice. If the information you have includes only a password but not the required name or transport settings, get those details first. Don’t change another working entry to Trojan just to try a protocol that sounds better. The choice should reflect server capabilities, your use case, and maintenance needs—not just one connection test result.

5. HTTP and SOCKS5: where general-purpose proxies fit

Connecting to a proxy and browsing a website are different layers

HTTP proxies were developed for common application-layer request forwarding. For a secure website, the client can use a CONNECT request to establish a tunnel to the destination, then the website’s own TLS connection protects the web traffic. These are two separate connections to consider: whether the connection from the device to the proxy is encrypted, and whether the website itself protects content between the device and the destination. A secure destination URL doesn’t prove that requests and authentication metadata sent to the proxy are equally protected.

If your existing endpoint explicitly uses TLS to protect the proxy connection, select the matching type and security settings in the app. Don’t enable them just because the destination website is secure. Standard HTTP proxy ports and secure proxy ports may differ, as may their authentication requirements. Check the server address, port, username, and password as a set. For an authentication error, check the credentials and server permissions. For a handshake error, first check whether you selected a standard endpoint instead of a TLS endpoint.

SOCKS5 focuses on forwarding destination connections

SOCKS5 provides general-purpose proxy negotiation and a way to specify destination addresses; it doesn’t need to understand webpage content. It supports different authentication methods and defines UDP forwarding, but the protocol itself doesn’t automatically encrypt all traffic. A username and password authenticate you; they don’t mean a secure channel has been established. If your existing service requires extra protection, check its actual setup. A Password field alone says nothing about the connection’s confidentiality.

SOCKS5 UDP forwarding requires server support and a network that can carry the traffic. It’s possible for TCP to work while UDP requests fail. If a task depends on real-time data or app-specific traffic, check what your existing service says about UDP and test an actual request. Don’t guess at capabilities by repeatedly changing ports, and don’t treat one successful webpage test as proof that every type of traffic works.

Where DNS resolution happens affects the result

A proxy request may include the destination domain, or the domain may already have been resolved to an IP address at an earlier stage. The actual DNS path depends on the app, Shadowrocket configuration, and server behavior. It’s too simplistic to say that a general-purpose proxy always resolves names locally or always does so remotely. If an IP address works but a domain doesn’t, check the DNS result, rule matching, and address format in the proxy request rather than only re-entering the authentication password.

Proxies on a corporate or private network may also restrict destination ports, addresses, or request methods. Authentication is only one step in gaining the required access; it doesn’t grant access to every destination. A rejected HTTP CONNECT request may mean the destination port isn’t allowed. A rejected SOCKS5 request may reflect a remote policy or an unreachable destination. Troubleshoot by the stage of failure: endpoint unreachable, authentication failed, destination rejected, or connection to the destination failed. Each points to a different check.

On iPhone, these endpoints suit setups that already provide the corresponding proxy. Their familiar fields don’t make them inherently faster or more power-efficient than other protocols. If the remote server has restrictive settings, repeated retries may increase wait times and network activity. Test one real destination you’re authorized to access, then check the app type you need. Don’t convert an existing encrypted protocol to HTTP or SOCKS5 just to make entries look consistent; the server needs a matching endpoint for each protocol.

6. WireGuard: keys, tunnel addresses, and routing scope

From proxy connections to network-layer tunneling

WireGuard is designed as a network-layer tunnel, using a fixed set of modern cryptographic primitives and public-key peer identities. Unlike protocols that handle individual proxy requests, it centers on peers, tunnel addresses, and the network ranges allowed through the tunnel. Configuration may therefore include a local private key, peer public key, tunnel address, and routing details in addition to the endpoint. More fields don’t mean you need to decide each one yourself; check them against the complete configuration from your existing server.

WireGuard primarily uses UDP. Being able to browse the web doesn’t prove the network allows UDP traffic to the specified endpoint. Likewise, a TCP test on a port doesn’t show that UDP is available on the same port number. If the tunnel never completes a valid handshake, first check the address, port, network conditions, and peer key—not website rules. Reaching the server endpoint and accessing a destination through the tunnel are separate stages.

Private Key, Public Key, and addresses have different roles

The Private Key is sensitive identity material for your device. Don’t share it publicly or use the peer’s public key in its place. The Public Key identifies the peer, and the server also needs the public key of any client it permits to connect. If the configuration includes a preshared key, use the value agreed by both sides rather than generating one for local use only. A key that fits the expected format may be validly encoded, but that doesn’t mean the server has granted that identity access.

The tunnel address is not the same as the endpoint address. The endpoint address lets the device reach the server over the current network; the tunnel address is used for network communication after the tunnel is established. Putting the server’s public address in the local tunnel address field usually won’t work. Also check whether a DNS address is reachable only through the tunnel. If the configuration requires an internal resolver and the tunnel isn’t up yet, domain lookup failures may be a follow-on symptom; don’t start by replacing every DNS setting.

Allowed IPs, MTU, and keep-alives

Allowed IPs help define the address ranges associated with a peer and how routes are selected; they aren’t a general website allowlist. A range that’s too narrow may keep expected traffic from using the intended path. One that’s too broad may divert connections that should use another path. In Shadowrocket, interpret this alongside the current Global Routing mode and configuration behavior. The server’s address-range guidance isn’t the same thing as every routing rule in the app. Before changing it, decide whether you need access to an internal resource or a regular internet destination.

MTU determines the maximum size of an individual network packet. Encapsulation reduces the space available for payload. Fragmentation or path-discovery issues may cause small requests to work while large pages or long transfers stall. A lower MTU can sometimes help isolate the cause, but setting it too low increases packet count and processing overhead. There’s no single “best number” for everyone. Start with the existing setting, change only a little at a time, and record whether the same reproducible request actually improves.

Keep-alives can maintain mappings in some network equipment, but periodic traffic also uses power and wakes the device. On cellular networks, don’t keep shortening the interval just to make the connection “stable.” If the connection is already reliable, extra background traffic has no clear benefit. When comparing battery use, also account for repeated connections triggered by On Demand conditions. WireGuard’s streamlined design can reduce implementation complexity, but battery use still depends on the network, traffic volume, and connection maintenance frequency.

This setup suits users with a defined peer and network scope, especially when accessing their own network resources. Troubleshoot in order: confirm the handshake, test a tunnel address, then check domains and app requests. Reversing that order can make a routing or DNS issue look like a key error. Keep a copy of the original configuration before restoring settings. Don’t expand the entire address range to fix access to one destination, and never share a screenshot or full configuration containing a private key.

7. Hysteria2: QUIC, bandwidth, and unreliable networks

Transport designed for unstable connections

Hysteria2 uses QUIC for proxy transport and is designed with conditions such as high latency and packet loss in mind. QUIC typically runs over UDP and integrates secure connections with multiplexed streams. Keep two things in mind: a protocol designed to handle certain network problems won’t be faster on every network, and support for this type in the client doesn’t guarantee that your current network allows access to the UDP endpoint. Before choosing it, confirm that your existing server actually offers Hysteria2, not a similarly named endpoint.

QUIC-based transport avoids some problems that arise when multiple logical streams share a single reliable byte stream, but the streams still share the underlying route and available bandwidth. Severe packet loss, an overloaded server, or a network that handles UDP poorly can still hurt performance. Multiplexing doesn’t mean packet loss can’t affect speed. Nor should you apply the result of one large file test to short requests, real-time communication, or background sync.

Match authentication and TLS settings individually

A typical setup includes the endpoint address, port, authentication details, and TLS name settings. Authentication identifies the user; TLS provides the secure channel and verifies identity. As with other protocols, understand these roles separately. For an authentication error, check the credentials from your existing service. For a certificate or name error, check SNI, system time, and the remote certificate. QUIC doesn’t mean you can skip certificate verification or choose a name at random.

Some existing setups require specific obfuscation parameters or port settings. Both sides need to use compatible settings; enabling an option only on the client may prevent communication. After importing, keep the combination provided by the subscription. When adding a server manually, follow its explicit instructions. If the details don’t mention an extension, don’t add one just to make the setup more complex. An advanced option in the app is available for configuration, not required for everyone.

A bandwidth setting isn’t a measured speed

Some configuration modes use upstream and downstream bandwidth values to control sending behavior. Interpret these values according to the field’s description, actual network conditions, and your service’s requirements—not the theoretical speed implied by a cellular signal icon. A higher number doesn’t create more capacity. An estimate that’s too high may cause more queuing or packet loss, affecting webpage response and other apps. An estimate that’s too low may limit available throughput; adjust gradually and observe a reproducible task.

Pay attention to units. Bits per second and bytes per second aren’t the same, and advertised broadband speeds can’t be compared directly with download speeds shown by an app. If an existing setup uses automatic adjustment, don’t switch to manual bandwidth just to “optimize” it. If you do need to set values manually, consider upload capacity too: downloads still need acknowledgments and control traffic, and a saturated upload can also slow downloads. Pause unrelated heavy transfers during testing to avoid drawing the wrong conclusion.

On iPhone, high throughput over a weak signal can involve more radio activity, processing, and retransmissions. Heat or battery drain can’t be attributed to the protocol name alone. Short tests may also be affected by screen brightness, charging status, and background tasks. For everyday browsing and messaging, prioritize consistent response and recovery after switching networks over a single peak-speed result. For sustained transfers, also monitor long-term throughput, destination server limits, and battery use.

For a connection timeout, first check whether the current network can reach the UDP endpoint, then check the address, port, and authentication. If the connection comes up but some content stalls, check the bandwidth estimate, packet size, DNS, and rules. Switching networks may change the route conditions; even a protocol designed to handle such changes can’t guarantee that every active request will continue uninterrupted. Note whether the failure happens during connection setup, a network switch, or a long transfer, and troubleshoot the specific symptom instead of continually raising the bandwidth value.

8. Choose by use case and troubleshoot by layer

Narrow your options using what you already have

If you have only one complete, working endpoint, the task is to import and verify it—not to choose again from every protocol. If your service offers several setups, rule out those the current network can’t carry, then compare them for your actual use. If you often switch between Wi-Fi and cellular, focus on recovery time and failures. For your own network resources, check address ranges, DNS, and permissions. For frequent short requests, look at connection setup and the first response; for sustained transfers, focus on steady throughput.

Keep the device, network, and destination content the same during tests. Compare the first connection, repeat visits, and performance over time. Change one entry or one setting at a time; don’t change the protocol, DNS, and Global Routing together. Connectivity Test can help check endpoint status, but its result isn’t the same as full webpage load time and doesn’t represent every destination. See latency, region, and protocol trade-offs for more detail.

Use a minimal rule to confirm the traffic path

When Global Routing is set to Config, rule order affects where requests go. The following explains the syntax; it isn’t a complete replacement for your current configuration. example.com is only an example, and the actual policy behind PROXY must match your configuration. Rules are generally evaluated in order; FINAL handles traffic that hasn’t matched an earlier rule. Even with correct server settings, traffic may behave unexpectedly if an earlier rule sends it DIRECT or REJECT.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX matches domain suffixes, IP-CIDR matches address ranges, and GEOIP uses the relevant geographic IP database—not the language of a website. DNS results, whether the destination appears as a domain, and earlier rules can all affect the final match. Don’t treat an example region rule as the right choice for everyone. Before testing a protocol, decide which route the test destination should use, then check what the log shows. Otherwise, you may test a direct connection and mistake it for a comparison between protocols.

Troubleshoot from endpoint to destination

First check that the device’s current network works, then verify the endpoint domain, address, and port. Next confirm the protocol, authentication, and transport settings. Then check the TLS name, certificate, and time. After that, review Global Routing, rules, and DNS. Finally, check the destination and remote access permissions. If the problem occurs only on one network, start with its reachability and transport conditions. If all networks fail, focus on the endpoint and shared settings rather than changing each device setting separately.

If an entry disappears or its fields change after a subscription update, first determine whether the issue is with importing and parsing or with a connection from an existing entry. An empty list is not typical evidence of an incorrect encryption method, and changing TLS settings won’t fix it. See how to troubleshoot a failed subscription import or empty list and check the link, service status, and update timing. Subscription URLs may contain sensitive credentials; don’t share them publicly.

Keep a recoverable configuration and useful test notes

For each test, record the network type, protocol setup, fields changed, and result. You don’t need to share full authentication details. Don’t include private keys, passwords, UUIDs, or full subscription URLs in screenshots; check error messages for sensitive information too. Revert changes that don’t help so that settings don’t accumulate. For the step-by-step workflow, see the quick-start guide. For help by issue, visit Troubleshooting. Look up interface terms and keywords in the glossary.

The final choice should match your existing server, work reliably on the current network, handle the traffic your apps need, and be straightforward to maintain. Don’t sacrifice certificate verification to win a single test, and don’t assume a more complex setup is automatically an upgrade. Establish a correct baseline that you can reproduce and restore, then address specific bottlenecks. This is the best way to distinguish protocol trade-offs from differences caused by the network.