Shadowrocket Protocol Guide
Choosing a Type and Checking Settings

Start by identifying both ends of the connection

Choosing a protocol in Shadowrocket means telling the client to use a communication format the server understands. Type is not a speed setting. If the server offers Shadowsocks, changing the client to Trojan will not create a different working connection. The server address, port, credentials, encryption method, and transport requirements all contribute to a usable configuration. Missing any essential detail can prevent the connection from being established. An existing subscription may include these details, but a successful import only means the information was parsed; it does not confirm that the server is currently reachable.

A connection involves three separate things: the destination an app wants to reach, the server Shadowrocket connects to, and the local network path used to reach that server. HTTPS at the destination is not the same layer as TLS between the client and server. A secure-connection indicator in a browser only reports certificate validation for the connection to the destination; it does not show whether the outer proxy connection is encrypted. Likewise, TLS on the outer connection does not replace the app's checks of the destination certificate.

Protocol type is not the same as transport

Shadowsocks, VMess, VLESS, and Trojan use different core mechanisms. TCP and UDP are underlying transport protocols, while WebSocket, HTTP/2, and QUIC each have their own session and encapsulation methods. Support for a transport in a given protocol does not mean the server has enabled it, or that every client combination is compatible. When reviewing configuration details, record the protocol, transport, and TLS requirements separately. A list of names is not a set of interchangeable options.

Measure speed and battery use across a complete task

Speed includes the time to establish a connection, the time to the first response, sustained throughput, and recovery after an interruption. A quick probe tests only some of these. A fast TCP handshake does not guarantee fast large-file transfers, and high download throughput does not guarantee quick responses to frequent small requests. Mobile performance also depends on wireless signal, carrier scheduling, server load, and the destination site. This guide does not rank protocols by name or treat a single test result as a lasting performance measure.

Battery use depends on the total work required to complete the same task. Encryption, encapsulation, retransmissions, keepalives, and waking the wireless radio all use resources. With a weak signal, radio overhead may outweigh differences between protocols. For a fair comparison, keep the device, network, server, and test task consistent, and observe results over time rather than checking the battery immediately after connecting. Keepalives can reduce some recovery delays but may also trigger more background activity. The right trade-off depends on how you use the connection.

Routing follows a separate decision path. Even with correct server details, a request may go directly through Direct. Before troubleshooting the protocol, check the Global Routing mode and which rule the request matches. Config, Proxy, and Direct refer to configuration, proxy, and direct paths in the interface. They determine how requests are routed; they do not change the server to a different protocol.

Design and trade-offs

Shadowsocks is designed as a relatively lightweight encrypted proxy. The client wraps a request to the destination and sends it to the server, which then connects to the destination. It is not a full virtual network interface protocol and does not assign the device a complete identity on a remote local network. A typical configuration requires the server address, port, encryption method, and password. The short list of fields does not mean the encryption method can be omitted, or that similarly named implementations are all compatible.

Encryption methods from different generations handle keys and data formats differently. AEAD methods provide confidentiality and message integrity, while newer methods may also have different key material formats and length requirements. The method name in your configuration must match an option supported by the client and server. Do not substitute a method just because its name contains the same term, such as AES, and do not switch to a method the server has not configured in search of stronger encryption. If the formats differ, the two ends generally cannot interpret each other's data.

How to check the four core fields

Server can be a domain name or IP address; enter the proxy server, not the website you want to visit. Port must match the listening port provided by the server, not one guessed from the protocol name. Method specifies the encryption method agreed by both ends, and Password must be entered exactly as provided. When copying a password, watch for leading or trailing spaces, line breaks, and lookalike characters. Some methods require key material in a specific format; do not encode it yourself before entering it.

Encoding in a share link is just a way to represent configuration data; it does not change the underlying protocol. A link may encode the method and credentials together, and may also include additional parameters. Parsing a name from the clipboard does not guarantee that every extension parameter was restored correctly. After importing, open the entry and check Type, Server, Port, Method, and Password. If the configuration specifies a plugin or special transport requirements, confirm that both ends support them. The four basic fields alone may not be enough to reproduce the original setup.

Why TCP may work while UDP fails

Shadowsocks can forward TCP and, with a compatible implementation and configuration, UDP. Test the two paths separately: a server with a TCP port open does not necessarily accept UDP on the same port, and a network that allows web requests may still block some UDP traffic. If websites work but certain real-time tasks fail, first check which transport the task uses, then verify UDP support rather than changing the password immediately. DNS may also follow a different path and should be checked separately.

On iOS, Shadowsocks resource use depends on the encryption method, data volume, and processor. Hardware acceleration may reduce the compute cost of some algorithms, but that is not true for every device or method. Lightweight encapsulation can reduce some processing overhead, but it cannot prevent retransmissions on a weak signal or server congestion. For sustained transfers, compare how long the same file takes and how consistently it completes; do not assume that fewer layers always mean better battery life.

Troubleshoot by checking address resolution and port reachability first, then verify the method and credentials. If basic communication works but a particular app still has problems, check rules, DNS, and UDP instead of repeatedly changing encryption settings. Change one condition at a time and keep the working entry intact so routing and authentication issues do not get mixed together.

The two protocols have different roles

VMess includes authentication and data-protection mechanisms, uses a UUID and related information to identify the client, and has different generations of authentication methods. VLESS has a simpler protocol structure and does not provide the same built-in data encryption as VMess. It usually relies on a security transport to protect communication between client and server. Both may use a UUID, but matching UUIDs do not make the protocols interchangeable. Type must match the server.

VLESS's simpler design does not mean it is always faster than VMess. A real connection may include TLS, different transports, multiplexing, and server-side forwarding; overall overhead depends on the entire combination. Some older VMess configurations also use additional compatibility parameters. Check them against the server's requirements rather than applying a single assumed value. If you encounter an unfamiliar field, confirm which generation it applies to instead of forcing an old parameter into a newer authentication method.

UUID, time, and security layers

A UUID is an authentication credential, not a server address or a free-form label. Preserve every character and hyphen when pasting it. If the client normalizes letter case, that does not mean it can repair missing characters. VMess authentication that depends on a time window may fail if the device clock is significantly off, so enable automatic date and time first. If authentication still fails, check the UUID, protocol generation, and server status. Not every authentication error means the network is unreachable.

If the configuration specifies none for VLESS Encryption, that does not necessarily mean the entire connection is unprotected, nor does it mean you can ignore outer TLS. Check protocol fields and security transport separately. Conversely, if no secure channel is established, the protocol name alone does not guarantee equivalent protection. TLS use, server identity verification, and any specific Flow are all conditions to check against the original configuration.

How WebSocket, Host, and Path fit together

When the existing configuration uses WebSocket, the client first establishes a connection using the corresponding HTTP upgrade process, then carries protocol data over it. Path is the path used by the server or reverse proxy to identify a request; preserve its leading slash and capitalization. Host is the host information in the HTTP request and may be used to select a virtual host. It can differ from the actual connection address, but only when the server is configured that way. Do not fill it with a familiar domain just to see if the connection works.

SNI is used during the TLS handshake to help the server select a certificate and site configuration. It belongs to a different layer from WebSocket Host. Common configurations may use the same domain for both, but one field does not automatically set the other. If Server is an IP address and the certificate is issued to a domain, the correct server name is usually still needed for identity verification. Changing Host without checking SNI may fix the HTTP layer while leaving TLS broken.

On iOS, outer TLS and the transport layer may add handshake steps, which are more noticeable as delays when short-lived connections are repeatedly re-established. Connection reuse can avoid some repeated setup costs, but it may also make multiple requests share a transport connection, increasing the impact of some congestion. There is no universally best setting. Start with what the existing server supports and observe real app behavior rather than enabling every option that appears to improve speed.

After importing a long link, record the field values in text as well as keeping a screenshot. In particular, preserve the original relationships between Transport, TLS, Host, Path, SNI, and Flow. Subscription updates may regenerate entries, so changes to an entry derived from a subscription may not persist. For testing, copy it to a separate entry and label its purpose clearly to avoid mistaking an update for a setting that reset itself.

Why Trojan depends on TLS configuration

Trojan is designed to authenticate and carry proxy requests over a secure TLS connection. TLS encrypts the client-to-server link and verifies the server's identity; Password is used for protocol authentication. They do not replace each other. A correct password will not prevent the connection from stopping at TLS if the certificate name does not match. A valid certificate will not prevent authentication from failing if the password is wrong. Check the secure channel first, then verify the protocol credentials.

Server specifies where to connect, SNI provides the server name for the TLS handshake, and the certificate proves the peer's identity. If your configuration uses a domain, keep it rather than replacing it with an IP address obtained through DNS. A domain may be used for address routing and certificate verification. An IP address that works temporarily may stop working after the server moves. For a private test environment using a special certificate, configure trust based on an explicit relationship instead of routinely disabling verification when troubleshooting.

An HTTP proxy is not the same thing as an HTTPS destination

An HTTP proxy generally forwards HTTP traffic according to the request destination, and can also use CONNECT to establish a byte tunnel to a destination. For an HTTPS site, the usual approach is to request CONNECT from the proxy, then establish TLS to the destination through the tunnel. TLS to the destination is separate from whether the client-to-proxy connection uses TLS. If the proxy connection itself is unencrypted, an HTTPS destination URL does not protect the outer connection carrying proxy authentication details.

In a Shadowrocket entry, check Type, TLS, and any authentication fields against the existing configuration separately. Username and Password may authenticate to the proxy; they are not the destination website's login credentials. Traditional HTTP CONNECT is mainly for TCP and does not guarantee that arbitrary UDP traffic will be proxied. Some extensions support a wider range of traffic, but only when the client, server, and configuration explicitly support them. Do not assume a standard HTTP proxy has these capabilities.

What SOCKS5 does and does not provide

SOCKS5 is a negotiation protocol for general-purpose proxy requests. It can specify a destination, an authentication method, and operations such as UDP association. The base protocol does not encrypt data. Username and password authentication are not the same as encrypted transport, so consider the network and any outer security layer. SOCKS5 can suit a managed network or a proxy with a clearly defined purpose, but “general-purpose” does not mean it automatically works with any server or secures every link.

SOCKS5 UDP forwarding also involves UDP ASSOCIATE, relay information returned by the server, and the subsequent data path. A successful TCP control connection alone does not prove that the UDP relay works. Server permissions, network address translation, and open ports can all affect the result. Also distinguish where a domain is resolved: sending a domain in the request differs from resolving it locally first and sending an IP address. Actual behavior depends on client routing, DNS settings, and request type.

TLS handshakes on mobile devices require network round trips and certificate processing. Reusing existing connections can reduce repeated overhead, but weak signals, frequent network changes, or a server closing the connection can still require a new handshake. A protocol that “looks like regular HTTPS” does not necessarily use less battery. Compare connection success, background recovery time, and device temperature for the same tasks, and account for screen brightness and app activity.

There is no need to rank these three protocols from best to worst. If your server explicitly provides Trojan, check the TLS and password settings together. If you have a managed HTTP or SOCKS5 proxy, first confirm permissions, outer security, and the traffic it is meant to handle. Matching the server correctly matters more than choosing a more complex combination based on the protocol name alone.

From proxy requests to IP packets

WireGuard is based on an encrypted IP tunnel, using a fixed set of modern cryptographic algorithms and public-key identities rather than asking users to choose from a list of encryption methods. Unlike proxy protocols centered on requests to specific destinations, it is closer to handing IP packets to a designated peer. This model suits networks already configured with the required addresses and routes. The configuration must account for the local tunnel address, peer identity, and which destinations should go through the tunnel; a server address alone is not enough.

WireGuard usually carries traffic over UDP rather than wrapping the entire IP tunnel in a reliable byte stream. Its compact design can reduce implementation complexity, but performance in Shadowrocket also depends on client integration, the system network extension, server capacity, and the network path. Results from another operating environment cannot be directly applied to iPhone, and fixed cryptographic algorithms do not mean every task will use less battery than other protocols.

How Private Key and Public Key work together

Private Key is a local identity secret. Never include it in public screenshots, logs, or support messages. Public Key identifies the peer, and the two ends must have the correct corresponding keys: the client stores the server's public key, and the server registers the client's public key. Reversing the keys or using credentials for another device will prevent the handshake. Preshared Key is an optional additional shared secret; use it only when both ends have the same value, not as a one-sided addition.

Address is assigned to the tunnel interface. Endpoint is the reachable address and port used to contact the peer; the two fields serve entirely different purposes. Putting the internal tunnel address in Endpoint will usually prevent the initial connection from being established over the external network. Check IPv4 and IPv6 separately. If your configuration provides only one address family, do not invent another set of addresses to fill in missing fields. DNS determines how domain names are resolved; it does not replace Endpoint.

Allowed IPs do not replace global rules

In the WireGuard model, Allowed IPs help determine which packet ranges belong to a peer and are often used to decide which destinations should be sent to that peer. They are not the entirety of Shadowrocket's rules. Whether an app request reaches this entry also depends on Global Routing and the selected policy. If the tunnel handshake succeeds but an internal destination is unreachable, check whether the destination is in the allowed range, whether the remote end can forward traffic, and whether the return route leads back to the client's tunnel address.

An MTU that is too large can prevent some larger packets from passing through the network path, causing small requests to work while pages with more content stall. Lowering the MTU can help diagnose the issue, but smaller is not always better; it can increase fragmentation and processing overhead. Start with the existing configuration, then make small changes if you can reproduce a large-packet problem. Record the results. If the actual issue is DNS or remote routing, changing the MTU is unlikely to help consistently.

Persistent Keepalive can maintain a network address translation mapping when needed, often when the client is behind NAT and the remote peer needs to initiate contact. More frequent keepalives increase wireless activity and may reduce standby battery life; disabling them entirely can make the first connection after idle take longer. Whether to use keepalives depends on the network topology and your needs. No single interval is right for every device.

When troubleshooting WireGuard, check the handshake and usable data separately. A handshake shows that the keys and some parts of the network path are working, but it does not confirm that DNS, Allowed IPs, remote forwarding, or the destination's return path are correct. If recovery is slow after switching between Wi-Fi and cellular, first check peer updates and UDP reachability, then review the keepalive setting. Do not change addresses, routes, and MTU all at once before confirming the identity fields.

Why use QUIC

Hysteria2 uses QUIC-based transport. QUIC runs over UDP and provides secure connections and multiple streams. Its design focuses on network conditions with latency, packet loss, or changing bandwidth, using corresponding congestion-control strategies. UDP does not mean users have to handle all reliability themselves: QUIC performs the necessary acknowledgments, loss detection, and retransmissions. “Uses UDP” does not mean data can be dropped freely or that it is always faster than TCP.

QUIC's independent streams can reduce some blocking between streams caused by ordered delivery over a reliable byte stream. Each stream still has ordering requirements, and all streams are still subject to available bandwidth and congestion. If the local network restricts UDP or enforces strict rate limits and mapping rules, the protocol's advantages may not be realized. A server offering Hysteria2 does not guarantee that the current network can connect to it. Check the port, UDP path, and authentication settings first.

Authentication, security, and additional requirements

Server and Port must point to the actual server, and authentication fields must match the existing configuration. Configure the TLS server name and certificate verification correctly; QUIC does not remove the need to verify identity. If the configuration includes obfuscation requirements, check that obfuscation is enabled and that the secret matches. A mismatch can cause an early connection failure. Do not use an obfuscation password, authentication password, and certificate name interchangeably; each serves a different purpose.

Do not mix Hysteria2 with an older protocol generation just because the names look similar. After importing, check that Type is correct and that the share link was parsed as the protocol in your configuration. If the server requires ALPN, specific certificate settings, or other extensions, a failed handshake may mean they were not restored correctly. For an unrecognized link, check the source's field documentation first instead of deleting unfamiliar parameters and repeatedly importing it.

Bandwidth settings are not speed promises

Some configurations include upstream and downstream bandwidth hints that affect the behavior of specific congestion-control modes. These are reference values for the algorithm, not requests for bandwidth from the network; increasing them does not deliver the corresponding throughput. Values far above the actual link capacity can increase queuing, packet loss, and retransmissions, making interactive requests slower. Values that are too low can also limit available throughput. Check what the client and server's modes expect rather than copying values from a different network.

Units matter. Megabits per second and megabytes per second are not the same; carrier access rates, system download displays, and configuration fields may use different units. Also distinguish upstream from downstream, since mobile connections are often asymmetric. A single peak download test cannot show sustained upload capacity. For tasks such as video calls or file uploads, upstream queueing may affect other requests. Save the original values before making changes so you can return to a known baseline.

Sustained high throughput on iOS keeps the wireless radio and processor active. UDP-based transport, user-space processing, and loss recovery also add workload. But completing the same task faster can sometimes shorten radio activity, so instantaneous power use alone does not determine total energy consumption. Observe short tasks, continuous downloads, and background standby separately. Do not compare full-speed transfers directly with idle and use that alone to judge a protocol's battery use.

If UDP support is unreliable on your network, keep another known-working combination for comparison instead of repeatedly increasing bandwidth settings. An unreachable network path, a certificate mismatch, and unsuitable algorithm parameters are different issues that require separate checks. Establish a correct connection first, then consider throughput optimization to avoid unproductive changes.

Check imported settings by field purpose

Importing a subscription reduces manual entry, but does not remove the need to check the result. Review four groups: Server and Port for the address; Password, UUID, or keys for identity; Transport, Host, and Path for transport; and TLS, SNI, and certificate verification for security. Not every protocol uses every field. Do not add missing fields just to make the configuration look complete. Fields with the same name can also mean different things in context; in particular, do not confuse Password with other secrets.

A server domain may be resolved by local DNS or affected by the client's DNS policy. The destination website's domain may follow a separate resolution path. If the server domain cannot be resolved, the proxy cannot be reached at all. If the destination domain has a resolution problem, the proxy may connect while a particular site remains unavailable. These are different issues. Identify which domain is failing, then check its resolution path instead of changing every DNS setting at once.

Three modes determine whether requests use an entry

Global Routing's Config mode handles requests according to the rules in the current configuration. Proxy sends eligible requests through the proxy path, while Direct uses a direct connection. In Chinese-language descriptions, these correspond to configuration, proxy, and direct connection. The proxy path still requires a valid entry and policy selection; switching to Proxy does not automatically find a server. Under Config, requests may be routed through Direct, so a website loading does not by itself prove that the selected protocol handled the connection.

Rules generally match in order, so put more specific conditions where they express the intended behavior correctly. DOMAIN-SUFFIX matches domain suffixes; GEOIP checks an address against a location database; IP-CIDR matches an address range; and FINAL handles requests that did not match earlier rules. Domain rules and address rules use different information, and some address checks require a resolved address. Database coverage, IPv6, the actual destination address, and resolution timing can all affect a match. Rule keywords are not protocol fields.

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

This example shows the structure of rule lines in a Shadowrocket configuration; it is not a complete configuration you can use as a replacement. PROXY and DIRECT are policy labels used here; a real configuration also needs a valid proxy selection and other required parts. The first line routes the example domain suffix through the proxy policy, the second sends the specified private address range directly, the third makes a decision based on address location, and the last provides a fallback. Do not overwrite an unbacked-up personal configuration with a snippet intended only to demonstrate rule order.

Configuration files and subscriptions serve different purposes

Subscriptions typically update server entries, while configuration files can contain rules and other settings. They are not the same kind of object. A subscription update may leave the server entry working while Config still points to an outdated policy, producing results that differ from what you expect. Conversely, correct rules cannot proxy requests if the entry's credentials have expired. During troubleshooting, record both the entry in use and the configuration in use. Do not rely on a displayed name alone, since updates may reuse the same name for different contents.

Take particular care with IPv6. A server domain may return both IPv4 and IPv6 addresses, and a destination site may be reachable over both. If the local network has incomplete support for one address family, connections may work intermittently or some destinations may take a long time to load. Do not assume the protocol is unsupported; check which address was used and test each path separately. Use IP-CIDR and IP-CIDR6 for their respective address families. An IPv4 range rule does not also cover IPv6.

To verify a protocol, send a test request that you know will use the policy in question, then check the connection record to confirm its path. Afterward, restore your usual Config mode and retest the apps you normally use. Do not mistake a temporary test mode for your final setup. Protocol connectivity is only the first step; routing and name resolution must also work for the setup to be complete.

List your requirements before comparing combinations

The first question is not “Which protocol is fastest?” but which complete combinations your existing server actually provides. List the supported protocols, UDP requirements, certificate conditions, and intended use, then rule out incompatible options. If only one configuration is explicitly supported, get it working correctly first. If several are available, compare them using the same server region, time period, and task as much as possible to avoid confusing server performance with protocol performance.

For web browsing over stable Wi-Fi, short requests, DNS, and connection setup often matter most. Long file transfers put more emphasis on sustained throughput and congestion. When switching frequently between Wi-Fi and cellular, check recovery time and whether apps reconnect successfully. Accessing an existing internal network also depends on address planning, return routes, and permissions. WireGuard's IP tunnel, general-purpose proxies' request model, and QUIC's transport features suit different conditions; do not rank them all by name alone.

Narrow down the problem in six stages

Stage 1: Check the local network. Under Direct, confirm that the network itself can make the required connections and check whether a network sign-in is needed. Stage 2: Check the Server domain resolution and port requirements, especially the difference between TCP and UDP. If the server cannot be reached at all, changing UUID, Password, or rule order will usually not help. Record the error and compare with another known-working network rather than trying a long series of field combinations.

Stage 3: Check TLS and certificates, including system time, SNI, certificate domain, and certificate chain. Stage 4: Check protocol authentication, verifying the method, password, UUID, or key pair for the selected Type. Handshake and authentication errors may both appear as connection failures in the interface, so use any specific stage information in the logs. If the logs do not provide enough evidence, state what remains uncertain. A timeout alone does not prove that the password is right or wrong.

Stage 5: Check routing and DNS. Confirm that the test request uses the selected policy, that the destination domain resolves as expected, and that the relevant address family works. Stage 6: Investigate sustained transfer problems such as MTU, UDP relays, congestion settings, server load, or large-traffic limits. Performance tuning is meaningful only after the earlier stages pass. If small requests work but large ones fail, use a reproducible test task rather than relying on a single Connectivity Test.

How to compare battery use and speed meaningfully

Use the same device under similar signal conditions, close unrelated high-traffic apps, and run the same set of web pages or transfer a file of the same size. Record how long the task takes, how many times it fails, how well it recovers after a network switch, and battery changes over a period in system battery statistics. Do not compare protocols using results from different screen brightness, signal strength, or foreground apps. A brief temperature change or one battery percentage jump can have other causes; repeat the test before drawing conclusions.

Treat On Demand as a way to trigger a connection under certain conditions, not a guarantee that every app session stays connected at all times. A network switch, an app being suspended, or the remote server closing a connection may require a new connection. More frequent keepalives can improve recovery after idle in some cases but may increase standby activity. Reusing long-lived connections avoids some handshakes but can make multiple requests share a congested path. Start with the original settings and change them only when you can reproduce a specific problem.

Keep a verified working configuration as your baseline, then try optimizations one at a time. Check the corresponding section on this page for protocol settings, the user guide for the first connection workflow, the troubleshooting guide for recurring issues, and the installation and launch guide for download and first-install questions. A useful conclusion is usually “this configuration completed this task on this network,” not a claim that one protocol is permanently best for every device and network.