Shadowrocket Protocol Guide

A connection involves more than a protocol name

A proxy connection typically involves a destination, proxy protocol, transport, authentication details, and security settings. The destination identifies the server to connect to. The proxy protocol defines how the destination is specified and how the user is authenticated. The transport carries the messages, while security settings determine whether TLS is used and which certificate is verified. Understanding these layers explains why two connections using VLESS can behave differently: the same protocol name does not mean they share a port, transport, or authentication details.

TCP provides an ordered, reliable byte stream. UDP sends datagrams without guaranteeing delivery. WebSocket encapsulates messages over an established connection; it is not a proxy authentication protocol on the same level as Shadowsocks. TLS establishes a protected channel, but does not replace a proxy account. If a subscription lists a protocol, WebSocket, and TLS, treat them as a combination of settings, not competing alternatives. The available fields depend on the current client interface and your connection details.

Check the address, hostname, and port separately

A server address can be a domain name or an IP address. The port is the specific listening entry on the server; do not copy a familiar port just because it is commonly used by a particular protocol. With TLS, the connection address may differ from the name used for certificate verification: the address locates the server, while the name verifies its identity. If your details specify an SNI or Server Name, use it as provided. Replacing the server address with an IP does not necessarily preserve the original certificate verification behavior.

Authentication details come in different forms: passwords, UUIDs, and key pairs are not interchangeable. A UUID may look like a random string, but it is not an arbitrary password. A public key can be shared with the party that needs to verify an identity; a private key must remain secret on your device. When copying details, check for leading or trailing spaces, line breaks, letter case, and complete QR code contents. Identify which layer a setting belongs to before deciding whether to contact the server administrator, check the system clock, or verify the certificate name. This avoids repeatedly changing unrelated options.

Global Routing does not change the server protocol

In Global Routing, Config, Proxy, and Direct refer to different routing modes. Config uses rules in the active configuration file to select a policy; Proxy routes requests handled by the client through a proxy; Direct connects without a proxy. These modes describe routing decisions, not a way to turn a server into another protocol. Switching to Proxy can help rule out requests using an unexpected policy, but it cannot fix a wrong password, an invalid certificate, or UDP forwarding that is not enabled on the server.

PROXY, DIRECT, and REJECT in rules are policy keywords; their capitalization differs from the interface labels. Rules are checked from top to bottom, and processing stops at the first match. Put FINAL at the end as a fallback. The example domain example.com is for illustration only and cannot test your server. For a real test, choose a known destination and check which policy appears in the connection log. Policy names in the configuration must also match those actually defined in the file; an example is not a complete, ready-to-use configuration.

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

The location of DNS resolution also matters when troubleshooting. A client-side lookup failure, a server-side lookup failure, and proxy authentication failure can all look like a page loading timeout, but they occur at different stages. Keep the original configuration, confirm the endpoint is reachable, verify authentication, then check destination resolution and rules. Change one setting at a time so you can connect each result to its cause. For a full explanation of rule order, see Custom Rules and the FINAL Fallback.

Design goals and evolution

Shadowsocks is designed to wrap proxy requests in an encrypted connection, using a relatively simple exchange to pass the destination and forward data. It is not a full network-layer tunnel; it typically provides proxy capabilities for TCP connections and UDP datagrams. This distinction matters: which apps the client handles, how domains are resolved, and whether local network addresses connect directly still depend on the system integration and Shadowrocket configuration. The protocol name alone does not determine where all traffic goes.

Shadowsocks encryption methods have evolved over time. Modern methods commonly use AEAD, combining confidentiality with integrity checks so the receiver can detect modified data. Methods from different generations may also use different key formats and message structures. Always choose the Method specified by the server, not one that merely looks similar. A method appearing in the client list does not mean your server has enabled it. Changing it to another option will usually cause authentication or decryption to fail.

Method, Password, and additional settings

The basic settings to check are Address, Port, Method, and Password. Match Method exactly and preserve every character in Password. Some newer encryption methods require an encoded key of a specific length; an arbitrary short phrase will not work. Do not decode an encoded key before pasting it unless your connection details explicitly say to. If an import link includes additional options, import it in full first, then compare its settings with the fields available when adding a server manually. This helps avoid missing a setting the server requires.

Some connection details also specify additional encapsulation or extensions. These are not automatically part of Shadowsocks, and different client interfaces may not present them in the same way. Confirm the actual server configuration and whether the current Shadowrocket interface supports the relevant options. If the details only say “Shadowsocks” and omit the method and authentication information, they are not enough to connect. Ask the administrator of your existing server rather than guessing common values.

Understanding speed and battery use on iOS

Shadowsocks has a relatively compact exchange, but that does not make it the fastest choice in every situation. Modern devices accelerate some encryption algorithms in hardware, while the efficiency of others varies by chip. Packet sizes, connection counts, and wireless signal quality also affect overhead. Short web requests are influenced mainly by DNS and connection setup time; sustained downloads depend more on link capacity and server load. Without the same device, destination, and comparable network conditions, you cannot attribute all differences between speed tests to the encryption method.

Test UDP separately. A server may only allow TCP, a firewall may block UDP, or the network in between may handle UDP differently. A webpage loading while a real-time app fails is not a contradiction. Do not immediately change the password because a UDP test failed. If TCP already authenticates reliably, check UDP forwarding, the relevant port, and server policy before editing authentication settings you have already verified. Protocol support for datagrams does not guarantee that an app will use that endpoint as expected.

On iOS, common factors affecting battery use include the amount of data handled by the network extension, reconnections, wireless network quality, and background wakeups. Frequent short connections may expose handshake overhead more than a few stable, long-lived connections; retransmissions on a weak signal can also mask differences between encryption methods. Evaluate Shadowsocks as a lightweight proxy option offered by your existing server, not as a fixed place in a battery-saving ranking. Save a working configuration and verify its stability before comparing performance to keep troubleshooting separate from speed testing.

Why VMess handles more within the protocol

VMess incorporates user authentication, request information, and data protection into its protocol design. The client must construct requests as specified so the server can identify the user and forward traffic to its destination. VMess can use different transports, so a configuration may include a server address and UUID as well as security options, a transport type, and TLS. Do not add or remove legacy compatibility settings arbitrarily; use the current server configuration and a valid import source as your reference.

VMess authentication requires the system clock to be synchronized. If the endpoint is reachable but authentication keeps failing after you change devices, check the date, time, and time zone, and prefer automatic time settings. Do not assume that connecting to the port means authentication succeeded: establishing a network connection is only the first step; the server may still reject the protocol header or credentials. Repeatedly running a test will not fix a clock mismatch and can make an authentication issue look like an intermittent network problem.

What VLESS simplifies—and what it relies on

VLESS focuses on lightweight authentication and request forwarding, relying more on external security mechanisms to protect data. It still uses a UUID for identity, but does not include general-purpose data encryption at the protocol layer. That does not mean the entire connection is necessarily unprotected: correctly configured TLS on the outer layer can protect the transport. Conversely, selecting VLESS does not mean data is encrypted if no suitable outer security mechanism is in place. Assess security across the complete configuration.

You cannot convert VMess to VLESS, or vice versa, by keeping the UUID and changing Type. The server must listen for the corresponding protocol, and the outer transport must match. Some connection details may include additional flow control or security options that do not apply to every transport combination. If the client does not show a setting, first check the selected type, server requirements, and supported options. Do not switch protocols just to make a field appear; that may break the link to an otherwise valid endpoint.

How WebSocket, Host, and Path work together

With WebSocket, Path is the route the server uses to handle the request. It usually must retain its leading slash and every character. Host is the hostname in the HTTP request; SNI is used during the TLS handshake and for certificate selection. They are often the same, but belong to different layers and are not interchangeable in every case. If the server uses a reverse proxy, a mismatched Path or Host can trigger an HTTP error before proxy authentication begins. Changing the UUID will not fix that kind of failure.

When using a domain certificate, keep certificate verification enabled and check that Server Name matches a name covered by the certificate. For a certificate error, first check the system clock, spelling, certificate validity, and server certificate chain. Disabling certificate verification weakens confirmation of the connection's identity and is not a suitable routine fix. If the administrator provides an IP endpoint and a separate verification domain, keep those roles separate instead of replacing every name with the IP.

On iOS, you cannot predict battery use for VMess and VLESS from protocol header size alone. Outer TLS handshakes, WebSocket encapsulation, connection reuse, and server distance all affect results. With frequent reconnects, connection setup may matter more than protocol differences during stable transfer. If your existing server offers only one protocol, use that combination correctly. If it offers both, keep the destination and test conditions fixed and compare first load, continuous transfer, and recovery after a network change—not just one peak speed reading.

Trojan puts the secure channel first

A typical Trojan setup uses a TLS connection for password authentication and proxy requests, making certificate verification central to understanding how it connects. The client first connects to the server and establishes TLS, then sends the protocol authentication details. If the handshake fails, the password has not yet entered the authentication process. If TLS succeeds but authentication fails, check the password and server protocol configuration. Distinguishing these errors avoids repeatedly changing the password to fix a certificate issue.

Check Address, Port, Password, and the TLS name together. SNI helps the server select the right certificate and endpoint; it is not a decorative field to fill in arbitrarily. If the connection details specify a domain, keep it unchanged for the initial test. Adjust the address or verification name only when you understand the server setup. The use of TLS does not make every TLS-enabled server a Trojan endpoint; the server must actually provide the corresponding proxy service and authentication account.

An HTTP proxy is not the same as visiting an HTTP website

An HTTP proxy uses HTTP semantics to receive and forward requests. When accessing an HTTPS destination, it commonly uses CONNECT to establish a byte tunnel. Distinguish the two connections: from the client to the proxy server, and from the proxy server to the destination website. An HTTPS destination does not automatically encrypt the first connection. The connection from client to proxy is protected only if the proxy endpoint itself uses supported TLS or another security mechanism. Do not judge the privacy boundary solely by the lock icon in a browser's address bar.

An HTTP proxy may require a Username and Password, or use another access control method provided by the server. Use authentication details from your existing server information; do not enter a website account in the proxy authentication fields. If the details specify an HTTP proxy protected by TLS, check the relevant type and certificate name. Do not test it as a plain HTTP port and conclude that the server is broken. An accepted HTTP request also does not guarantee that the server allows every CONNECT destination or port.

SOCKS5: general-purpose use and clear limits

SOCKS5 negotiates an authentication method and destination address as a general-purpose proxy protocol. It can specify a domain or IP destination and defines mechanisms related to UDP, but the base protocol does not provide general transport encryption. A username and password authenticate the user; they do not automatically create an encrypted channel for subsequent data. If the connection from client to server needs protection, assess the actual outer mechanism and the trustworthiness of the network. A password does not mean the entire connection is encrypted.

SOCKS5 UDP works only when the client, server, and intervening network all support it. The server may only forward TCP, and the address returned for a UDP association may not be reachable across the network. Where domain resolution happens also depends on the request form and client settings. If an IP works but a domain does not, check the DNS resolution path. If TCP works but a real-time app fails, check UDP. Do not treat every failure as an account issue.

Choose among these protocols based on the endpoint you already have. If your workplace provides an HTTP proxy, configure its authentication and access scope. If an existing lab or local network provides SOCKS5, understand its protection limits. If you have Trojan details, retain the complete TLS settings. Do not change the type just because another name sounds more advanced. On iOS, request patterns, handshake frequency, and network quality often explain speed and battery differences better than an isolated protocol label.

How it differs from an application-layer proxy

WireGuard creates an encrypted tunnel for IP packets, using a compact protocol and a fixed set of modern cryptographic algorithms to reduce configuration complexity. Unlike proxy protocols that mainly forward connection requests, it needs to specify the local interface address, the peer's identity, and the address ranges routed through that peer. A WireGuard configuration is therefore usually more than a server address and password: it includes a local private key, peer public key, tunnel address, and routing settings. Understanding how these relate is more useful than memorizing field names.

WireGuard uses UDP as its outer transport, so a network that can reliably carry UDP is a basic requirement. A webpage working over a direct connection does not prove that a UDP tunnel endpoint is reachable. Endpoint DNS resolution, an open port, and a working server return path are all necessary. After a successful handshake, verify that destination traffic is routed correctly and that the server allows the required forwarding. “Handshake received” and “all destinations are reachable” are two different conclusions.

PrivateKey, PublicKey, and address assignment

PrivateKey is a secret belonging to the local device. PublicKey lets the peer identify that device. The server's public key is not the client's public key; do not swap the fields. If the configuration also includes a preshared key, both sides must use the same value. It is a separate setting, not a generic password that replaces the public and private keys. Never share a private key in screenshots or troubleshooting logs. Even if an imported configuration has no familiar Password field, it may contain sensitive identity information that can establish a connection.

Address is the local address on the tunnel interface, not the server's public IP or an arbitrary local network address. It is usually assigned by the server administrator and must match the peer configuration. Endpoint identifies the externally reachable server. Changing Address to the server IP confuses the internal tunnel network with the external network. Reusing another device's interface address and identity can also cause address conflicts or change the peer association. Use the details assigned to your device by the existing server.

AllowedIPs, MTU, and keepalive

AllowedIPs helps determine which destination addresses are routed to a peer and checks address ownership for received data. It is not a list of websites organized by domain. Whether it works with Shadowrocket policy routing depends on the import method and interface capabilities. If the supplied details cover only specific subnets, do not change them to all address ranges to “improve compatibility”; that can change which traffic is routed through the tunnel. If an internal network is unreachable, check the tunnel address, peer ranges, and server return routes together.

MTU sets the maximum packet size carried by the tunnel interface. Outer encapsulation uses some of that space, and the path may handle fragmentation or large UDP packets differently. This can make small requests work while larger responses stall. First check whether only large transfers are affected, then adjust the value as recommended by the server. There is no universally correct low value. A lower MTU requires more packets for the same amount of data, and excessive adjustment adds overhead. Record the effect of each change.

PersistentKeepalive can help maintain a network address translation mapping on some networks, but sending packets continuously may keep the wireless connection active for longer. On iOS, use it as required by the server and in response to actual idle disconnects, rather than shortening the interval without reason. WireGuard's processing efficiency does not automatically mean lower overall battery use: tunnel traffic, keepalives, signal strength, and network changes all play a role. It suits existing environments that need defined network-layer addresses and subnet access, provided you have complete peer settings that match the server.

Start with the transport trade-offs

Hysteria2 uses QUIC for proxy transport and focuses on data delivery over networks with latency and packet loss. QUIC runs over UDP and provides connection management, reliable delivery, and congestion control, so “uses UDP” does not mean the application data has no reliability mechanisms. It still requires a working UDP path: if the network continually drops the relevant packets, protocol mechanisms cannot create reachability. Check this prerequisite before repeatedly changing bandwidth settings.

QUIC streams can reduce some forms of cross-stream blocking, but cannot overcome weak wireless signal, congestion at a shared gateway, or insufficient server capacity. Performance on a single connection also depends on the client implementation, destination response, and path changes. A similar protocol name across different generations does not mean their connection details are interchangeable. Type, authentication, and additional settings must match the actual server. A successful import only means the details could be parsed; you still need to verify the handshake and access.

Authentication, TLS, and optional encapsulation

Start by checking Address, Port, authentication details, and the TLS name. The authentication string comes from your existing server and may contain separators that must be preserved in full; do not copy only the part that looks like a password. The TLS certificate chain, validity, and name must still be verified. If the client reports a certificate problem, check the system clock and name settings first, then check the server certificate. Do not mask a configuration error by leaving verification disabled; that prevents reliable confirmation of the connection's identity.

Connection details may also include optional obfuscation settings. These belong to a different layer from user authentication and TLS certificates, and both sides must use compatible settings. An extra option the server does not expect can make the message unreadable to it. Leave unspecified settings at their defaults; check each one that is explicitly provided. If a connection fails only on one network, test the same configuration on another network. That is easier to diagnose than changing authentication, obfuscation, and bandwidth together without knowing the cause.

Why you should not enter an arbitrarily high bandwidth value

Some configurations let you set upload and download bandwidth for rate estimation or limit negotiation in certain congestion control modes. The effect depends on both client and server settings; entering a large number does not guarantee higher throughput. A value far above the actual available capacity can lead to growing queues, packet loss, or competition with other traffic. A value that is too low can limit throughput. Check the units, distinguish bits from bytes, and use a reasonable estimate based on the current connection and server recommendations—not someone else's speed test screenshot.

Mobile network capacity varies with signal, location, and cell tower load, so one fixed estimate may not suit every time of day. If performance becomes erratic when switching from stable Wi-Fi to cellular, first compare the available capacity of the networks, then check whether the bandwidth setting is too aggressive. Even when using defaults or negotiated settings, test both short requests and sustained transfers; fewer settings do not automatically make a configuration better. Every performance adjustment should address a specific symptom, change one variable, and have a documented way to revert it.

On iOS, more aggressive data sending, packet loss recovery, and sustained heavy traffic can increase wireless activity and heat. A faster single download does not mean lower battery use over a full day. On the other hand, finishing the same task sooner could reduce total active time; measure the result. Compare task duration, failure rate, and battery use over similar periods instead of relying on any single observation. Turn off unrelated high-bandwidth tasks during testing so background downloads are not attributed to the protocol.

A suitable use case is: “An existing server provides Hysteria2, UDP is available on the current network, and its behavior under packet loss needs to be evaluated.” It is not a blanket replacement for every TCP option. If other endpoints on the same server work but this one fails on a particular network, first consider how that network handles UDP. If it fails on every network, check the server listener, authentication, and certificate. Narrowing the problem by conditions is more useful than continually increasing the bandwidth setting.

Break “fast” into measurable steps

Loading a webpage involves DNS resolution, connection setup, proxy handshake, destination handshake, and content transfer. A slow first load may be caused by any of the earlier steps; a slow large download may be limited by sustained throughput. Connectivity Test results reflect the test method and destination, not the overall speed of every app, and not necessarily the underlying network's round-trip time. Before comparing protocols, decide what question the test should answer and what to measure.

For a fair comparison, keep the device, network, server region, destination service, and test period as consistent as possible. Servers with the same name may use different egress routes, and load changes over time. The device can also heat up during repeated tests, affecting later results. Alternate between two working configurations and repeat short requests and sustained transfers rather than running one until the device is warm before testing the other. If the difference is small, report the range of variation instead of forcing a conclusion that one protocol is always faster.

Battery use depends on more than encryption

Proxy use on iOS typically involves the network extension, packet processing, and the system's wireless connection management. Cryptographic operations use resources, but screen activity, cellular signal, retransmissions, background tasks, and keepalive traffic can also account for a significant share. The battery usage shown by iOS is a combined result; it cannot isolate the cost of each operation for a particular protocol. If you watch video, download files, or keep the screen on throughout a test, do not attribute all battery use during that period to Shadowrocket's protocol overhead.

Observe idle and active use separately. An idle test looks for frequent wakeups, reconnections, or keepalive packets. An active test measures how long the same task takes, heat, and retries. On Demand triggers connections based on conditions; it is not a button for reducing protocol overhead. A configuration that repeatedly reconnects when the network changes may work worse than one that stays connected. First decide whether you need automatic connections, then check that the trigger conditions fit your everyday networks. Otherwise, attempts to save battery could cause more network transitions.

Real-world effects of TCP, UDP, and network changes

When packet loss occurs, TCP has to restore an ordered byte stream, which can extend delays on a poor connection. Protocols carried over UDP also need their own recovery and congestion management; UDP does not eliminate waiting. Real-time apps care more about sustained jitter and packet delivery, while webpages care more about the completion time of short transactions. A large-file throughput test does not represent call or interactive performance. Similarly, a problem in one real-time app does not prove that the proxy's TCP forwarding is broken. Choose a task that matches your actual use.

Switching between Wi-Fi and cellular changes the external address, available bandwidth, and path MTU, and can interrupt existing connections. Even if a transport supports migration, recovery still depends on the client, server, and destination app. Record whether new requests work after the switch and whether existing requests continue; these are different measures. For interactive tasks that must remain available, predictable recovery is often more important than a momentary peak speed.

Check that routing is consistent as well. If one configuration sends most requests direct while another sends the same requests to a remote server, differences in speed and battery use are not just protocol differences. When testing with Config, keep the same rules and policies. You can temporarily use the Proxy mode under Global Routing for a controlled test, then restore the original mode. Server statistics in Data can help confirm whether traffic went through the expected endpoint, but the count is not a success rate and cannot by itself prove that every domain rule took effect.

For details on reading the figures, see the Data Traffic Statistics guide. When recording a test, note the task, network, routing mode, and whether you changed connections. Keep account details private. A useful conclusion should be something like “under these conditions, this configuration completed the task more reliably,” not “this protocol is always faster.” When two options perform similarly, complete settings, easier maintenance, and clear recovery steps are often more useful than chasing a small difference.

Choose in order: check server support before performance preferences

If you have an existing subscription, first import it in full and check the protocol type. You do not need to decide which protocol you prefer in advance. A client cannot enable a protocol the server does not offer. For manual setup, gather the endpoint, authentication, transport, security, and additional settings before opening Add Server and choosing the matching type. For the differences between subscriptions and manual entries, see Subscribe, QR Code, and Manual Import. For everyday setup, start with the setup guide.

If the same existing environment provides multiple complete endpoints, choose according to the task. For regular browsing, check the stability of short requests. For sustained downloads, look at throughput and heat. For real-time apps, verify UDP support and jitter. For access to a specific internal network, check whether WireGuard tunnel addresses and subnet settings are required. Protocol names offer design clues but cannot replace end-to-end testing. Also consider certificate renewal, key management, and configuration updates. Choose a combination you can keep accurate, not the one with the most settings.

Build a minimal working configuration, then restore routing rules

Keep the original connection and make a copy for testing. First confirm that the device has a working internet connection. Then check the endpoint address and port, verify authentication and TLS, and finally access a known destination. To rule out routing rules, you can temporarily use the Proxy mode in Global Routing, but restore the expected settings when testing is done. Once the connection is stable, enable Config and check the active file, rule order, and FINAL. Do not change DNS, protocol, transport, and policy all at once; even if you get the connection working again, you will not know which change helped.

If only one website fails, first check whether it is accessible at all, then identify the matching rule and policy and verify DNS resolution. If all destinations fail, return to the endpoint and authentication. If small requests work but large responses stall, check the path, MTU, and transport. If the connection fails after a network change, check reachability on the new network and whether the connection was re-established. Narrow the search based on symptoms instead of assuming every failure means the protocol is unsuitable.

Subscription updates, sensitive details, and download sources

A Subscribe update may change addresses, ports, or the list of entries. It can also overwrite manual changes. If an entry worked before an update but now fails, compare the changes and confirm that you are still using the intended entry before changing global settings. When reporting an issue to the administrator of your existing server, include the protocol type, stage of failure, network, and whether the problem can be reproduced. Hide subscription links, UUIDs, passwords, private keys, and QR codes containing authentication details. Do not share full access credentials in logs.

If the issue occurs while getting or opening the client for the first time, see installation and launch guidance rather than mixing installation problems into protocol tests. On Mac, distinguish Apple silicon from Intel. If the first launch is blocked, verify the source and use Privacy & Security in system settings. Follow the download page guidance for Windows SmartScreen, Android installation permissions, and Linux execution permissions too. Installation packages for other platforms are provided at /dl on this site; do not look for alternative download addresses in protocol documentation.

On the iPhone / iPad App Store product page, check that the developer is Shadow Launch Technology Limited and confirm the official icon and app ID 932747118. System requirements are as listed on the App Store page. There are two pricing tiers: the iPhone / iPad version is a one-time $2.99 App Store purchase; the Mac / Windows / Android / Linux versions are free. Buying the app does not include server connection details. Getting the app and importing an existing subscription are separate steps. If a connection fails, buying the app again will not fix it.

Keep a verified configuration and note which networks and tasks it works for. Change one variable at a time, then check access, rules, and recovery before making another change. If the problem persists, return to the relevant protocol section on this page and see Download and Installation FAQ to distinguish acquisition issues from connection issues. The right protocol is not the newest one; it is the one supported by your server, correctly configured, clearly verified, and reliable on the networks you use.