Shadowrocket
Protocol Types and Settings

01 · Distinguish Four Layers Before Choosing

A protocol name answers only one question

A server entry in Shadowrocket includes more than a protocol. The address and port determine where to connect. Types such as Shadowsocks, VMess, and VLESS define how the client and server exchange proxy requests. Transports such as TCP and WebSocket carry the data, while TLS covers encryption and certificate verification. Rules and policies form another layer, determining whether a request uses that entry. All four layers can affect the result, but none can replace another.

The same address does not mean you can switch between types at will. Changing VLESS to Trojan does not make the server understand a different request, even if the port and password look similar. The server must provide the corresponding endpoint, and the identity fields, transport, and security settings must match. In this guide, “choosing a protocol” means selecting from entries that your existing server information explicitly supports—not renaming one entry as another type.

Build a checklist from the information you have

After importing an existing subscription, check the entry in Home, then open its editing screen to verify the type and server address. To add an entry manually, choose the type that matches the server instructions in Add Server. Different types show different fields; their availability, options, and placement depend on the current app interface. Don’t put a value in a similarly named field just because another guide mentions it.

Use a consistent check order: address and port, identity credentials, transport, security settings, and only then rules. This follows the layers where failures occur: a wrong address cannot reach the destination; incorrect credentials fail identity checks; a mismatched transport prevents the request from being parsed; and failed certificate verification prevents a secure connection. Changing rules first usually won’t fix these problems and can make the test harder to interpret.

Check the client, service, and App Store details separately

Shadowrocket is a closed-source app. This guide focuses on iPhone and iPad, which are a one-time App Store purchase. Mac, Windows, Android, and Linux are free. A one-time app purchase is not a service plan: it covers use of the client, while connecting requires your own existing subscription or server details. We do not provide, sell, or recommend nodes or subscriptions. Check the relevant subscription documentation to confirm whether it is valid and which protocols the server supports; the types shown in the client don’t tell you what the server supports.

iPhone and iPad are purchased on the App Store. Mac, Windows, Android, and Linux are free from this site. To purchase or verify the product, see the App Store purchase and verification guide. Confirm the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. Check the App Store listing for system requirements and purchase availability. Connection failures and purchase status are separate issues: being able to open the app does not mean the server details are valid.

02 · Shadowsocks: Match the Encryption Method and Credentials

Understand settings in the context of a lightweight proxy

Shadowsocks was designed as a relatively simple way to carry proxy traffic, with the client and server exchanging data using a mutually agreed encryption method and password. It does not place the entire device on a remote local network, nor does it automatically route every website request through a proxy. Shadowrocket still uses the current Global Routing setting and configuration rules to decide where requests go. The protocol handles only the traffic routed to it.

This division keeps the core settings focused: start by checking the server address, port, encryption method, and password. Simplicity doesn’t mean you can guess the settings, and a correct password alone doesn’t guarantee that identity settings are complete. The encryption method defines how both ends interpret the data. If it’s wrong, the server may receive the connection but fail to parse its contents, which can look much like an incorrect password. Reconnecting repeatedly usually won’t fix it.

Why check Method and Password together?

Modern deployments often use authenticated encryption, which also checks whether data has been modified. Each method has its own requirements for key length, derivation, and data format. Use the complete method name provided by the server; don’t assume similar-looking names mean the same thing. Nor should you copy a password from another entry and assume the two are interchangeable. Credential formats can also differ between protocol variants.

Some newer Shadowsocks variants require a key with a specific encoding and length, not an arbitrary passphrase. Although the value in the password field may look like ordinary text, it represents key material in a required format. Don’t shorten, pad, or re-encode it yourself. If importing works but recreating the entry manually doesn’t, check for a missing final character, an added line break, or escaped text copied from a link instead of the original credentials.

Don’t infer UDP or extra transports from the protocol name

Some app traffic uses UDP. If a TCP webpage loads, that shows only that the relevant path for that entry works; it doesn’t prove UDP works too. Check whether the server allows the required forwarding, whether the current network can carry the traffic, and whether the entry’s settings match the existing instructions. Calling a UDP failure “protocol instability” may overlook server restrictions or differences in the network path.

Some existing entries also include extra transport settings. Check what each one does rather than assuming it doesn’t apply just because the entry uses Shadowsocks. An additional layer is a separate thing to verify: the core password can be correct while an extra setting is wrong, and deleting an unfamiliar parameter can break an otherwise valid endpoint. The original imported entry is a more reproducible baseline than a manually simplified one.

How to assess whether it suits your iPhone

With other conditions held constant, fewer encapsulation layers may reduce some processing overhead, but that doesn’t guarantee higher speed or lower battery use. Real-world results also depend on encryption implementation, device performance, server load, packet loss, and round-trip time. A brief webpage test mainly reflects connection setup and a small data transfer; a sustained file transfer measures throughput. They can feel quite different, so record them separately.

If an existing Shadowsocks entry handles everyday requests reliably, there’s no need to replace it just because another protocol has a newer name. If it connects but a particular app fails, first distinguish DNS, TCP, and UDP paths, then check whether a rule sends that app through a different policy. If all requests fail, start with the address, port, encryption method, and password. Don’t begin by changing battery-related settings.

03 · VMess and VLESS: Identity, Transport, and TLS

Similar fields don’t mean the same protocol

VMess combines identity authentication with its own data-protection mechanism; UUID is a common identity field. VLESS uses a more streamlined identity and request format, relying more on an external security layer to protect the connection. Both can use different transports, so their editing screens may show similar fields. They aren’t interchangeable formats that you can convert by changing the type. The type must match the server’s actual endpoint.

Understanding these trade-offs helps avoid assuming that “fewer fields” means “more secure” or “faster.” VLESS doesn’t provide the same content encryption mechanism as VMess, so its deployment must specify how the outer layer protects the connection. VMess has its own security mechanism, but that doesn’t make its outer transport settings optional. Assess an entry as a complete combination of protocol, transport, and security settings—not by its name alone.

A UUID identifies a user; it isn’t a display name

Preserve the UUID exactly, character for character. An entry name can distinguish locations or purposes; changing it usually doesn’t affect authentication. A UUID is used directly to verify identity, so changing it arbitrarily can make the server reject the connection. Watch for hyphens, leading or trailing spaces, and automatic line breaks when copying. Even if multiple entries share a UUID, their addresses, ports, and other settings may differ; check each entry in full.

VMess authentication also involves time information. A significantly incorrect device clock can prevent authentication even when the settings look right. Check that the date and time are reasonable in system settings before troubleshooting server credentials. Don’t repeatedly change the UUID as a test. If the existing server details include other compatibility fields, follow the server instructions rather than mixing values from examples for different versions.

WebSocket Host and Path, and TLS SNI

WebSocket carries proxy data over the corresponding connection. Common settings to check include Host and Path. Path must match the server’s routing; the leading slash, letter case, and trailing path can all matter. Host provides the hostname for the relevant request, and the server may use it to route requests to different endpoints. If either is wrong, the protocol exchange may fail even when the destination port accepts a connection.

SNI is the server name sent during the TLS handshake; certificate verification checks that the expected name matches the certificate. The connection address, WebSocket Host, and SNI may be the same in some deployments and different in others. Don’t automatically enter the same value in all three fields. Even when the underlying connection uses an IP address, the server instructions may specify a domain name needed to establish the secure connection correctly.

Choose based on the complete endpoint configuration

Some VLESS combinations also require Flow or specific security settings. Enter them only when the server explicitly requires them and the current client offers the corresponding options. Don’t copy a value from another working entry into every VLESS entry. Requirements vary by combination, and leaving a field blank may be correct. Base your choice on the configuration for the server endpoint you’re using.

To compare the two on iOS, first control for differences in transport and security. A direct TCP entry and one with multiple encapsulation layers cannot be compared as if VMess or VLESS were the only variable. If the original subscription entry works but a manually created one doesn’t, compare UUID, transport, Host, Path, TLS, and SNI one by one. Comparing processing overhead is meaningful only after the full combination matches.

04 · Trojan, HTTP, and SOCKS5: Security Boundaries

TLS is central to Trojan

A common Trojan design carries proxy requests inside a TLS connection and identifies users with a password or similar credential. It uses a mature secure transport, but the client still needs the correct server address, port, password, and verification name. Reaching the port only shows that the underlying path exists; a correct password doesn’t bypass a certificate name mismatch. Treat handshake failures and authentication failures as separate problems when troubleshooting.

The relationship between the domain, SNI, and certificate is particularly important. The certificate should cover the expected service name and be valid and trusted. If the connection address differs from the verification name, enter each value as specified in the server details. For certificate errors, first check the device time, name, and server certificate chain. Don’t disable verification as a routine fix; it weakens your ability to identify the connection endpoint.

An HTTP proxy doesn’t mean all traffic is protected

HTTP proxies originated as application-layer intermediaries. They can forward requests and often use CONNECT to open a byte stream to the destination. Common entry fields include address, port, username, and password. Distinguish the two connections: device to proxy server, and app to destination site. A destination using HTTPS does not automatically protect credentials between the device and the proxy in the same way. Check separately whether the outer connection uses TLS.

So if existing instructions specify HTTP, don’t assume it means a proxy endpoint with TLS. If they require secure transport, don’t enter only the ordinary proxy fields. A handshake can fail when the two ends support different methods. Incorrect credentials, whether the proxy allows CONNECT, and restrictions on destination ports can all explain why some sites work while others fail.

SOCKS5 supports general negotiation but has no built-in encryption

SOCKS5 negotiates the destination address and connection requirements, can use username and password authentication, and defines mechanisms related to UDP. It doesn’t encrypt all carried data by itself. Authentication and content confidentiality are different capabilities; a password requirement doesn’t prove the connection is encrypted. The actual security boundary also depends on the network, any external security layer, and the app’s own connection protection.

A working SOCKS5 connection doesn’t guarantee that UDP works. The server may allow TCP only, or the network may not carry the data needed for UDP associations. Also check where domain names are resolved: the app, client configuration, and proxy request format all affect the path. If domains fail while tests using direct addresses differ, check DNS and rules instead of repeatedly changing the proxy password.

Choose for the existing environment, not by ranking names for security

If your existing environment provides only one type of proxy endpoint, first check its transport protection and access permissions, then decide whether it fits your needs. A client type option can’t add TLS to the server, and changing HTTP to SOCKS5 won’t fix authentication failures. For endpoints managed by an organization, follow its access scope and device-use policies; don’t mistake a limited-purpose proxy for a general-purpose connection.

On iPhone, network conditions often mask speed differences between these types. Handshake count, connection reuse, server response, and wireless conditions can matter more than protocol parsing overhead. For a fair comparison, use the same task in similar conditions and first ensure each entry’s security settings are complete. If an entry works only with certificate verification disabled, correct the server details rather than treating that as a performance advantage.

05 · WireGuard: Keys, Addresses, and Tunnel Scope

Understand how a network-layer tunnel differs

WireGuard is designed to establish a network-layer tunnel using a relatively lean protocol and a fixed set of modern cryptographic primitives. Unlike protocols that describe destinations as proxy requests, it handles IP packets inside the tunnel. Its configuration reflects that difference: in addition to the remote endpoint, you need to understand the local tunnel address, both parties’ keys, and the address ranges allowed through the peer. Don’t apply the password conventions of an ordinary proxy to these fields.

When using WireGuard in Shadowrocket, keep the tunnel settings for the entry separate from the client’s routing decisions. The entry defines how to communicate with the peer; Global Routing and the configuration determine which requests use it. A tunnel address doesn’t mean every device request follows the tunnel as expected. Nor does an enabled connection switch prove the remote end allows access to the required destinations.

Private Key, Public Key, and Endpoint

The Private Key is local identity material and must be kept secret; the peer’s Public Key identifies the remote side. They are not two labels for the same string and must not be swapped. If the existing configuration also includes a Preshared Key, both sides must use the same additional key. When troubleshooting, record only whether the fields are present and match. Don’t include full keys in public screenshots, logs, or support posts.

Endpoint specifies a reachable remote address and port; it is not the address inside the tunnel. The local address in the configuration is used for communication within the tunnel, and can’t be chosen arbitrarily just because it is a private address. The server must know the corresponding client and address relationship. Reusing an unsuitable address or identity can cause conflicts. Check the server configuration rules before reusing the same details on a new device.

Allowed IPs and routing aren’t the same table

Allowed IPs define the address ranges a peer can carry and help determine routing and source-address constraints inside the tunnel. They are at a different layer from Shadowrocket rules such as DOMAIN-SUFFIX. Even if an outer rule sends a request to WireGuard, traffic may still fail if the tunnel or remote end doesn’t allow the relevant address range. Conversely, allowing a range in the tunnel doesn’t mean the client will automatically send every matching request through it.

To access existing internal resources, also check remote forwarding, the destination’s return path, and name resolution. A tunnel handshake can succeed while the target device has no route back, causing requests to time out. If only domain names fail while the corresponding internal address is reachable, check internal DNS reachability and configuration first. If no internal addresses are reachable, check address ranges, remote permissions, and routing.

Trade-offs for MTU and Persistent Keepalive

MTU limits how much data a single tunnel packet can carry. Encapsulation adds bytes, and the network path has its own limits, so an unsuitable setting can let small requests succeed while larger transfers stall. Don’t keep lowering the value whenever something hangs. First check whether packet size is related to the failure and keep the original value. After a change, retest with the same destination and transfer task so a brief network fluctuation isn’t mistaken for an MTU fix.

Persistent Keepalive can maintain a mapping in some network address translation environments, but periodic packets also increase wireless activity. A shorter interval isn’t always more stable, and many networks don’t need it. Consider changing this setting only if the return path stops working after idle time and the existing configuration allows it. Account for the cost of waking an iPhone’s radio on cellular networks; one faster reconnect isn’t enough to judge the trade-off.

06 · Hysteria2: UDP Paths and Bandwidth Estimates

Designed for transport behavior on lossy paths

Hysteria2 uses QUIC for proxy transport, and QUIC typically runs over UDP. Its design focuses on transport efficiency over paths with packet loss and high round-trip times. “Lossy” describes network conditions; it doesn’t mean all cellular networks behave the same way. To assess whether it suits your current environment, first confirm that the UDP path works, then test real tasks instead of predicting speed from the protocol name.

QUIC combines security handshakes with transport and can carry multiple streams over one connection. Separate streams can reduce some of the waiting caused by a single ordered byte stream, but they still share link congestion and are subject to wireless packet loss and server resource limits. QUIC can’t increase available bandwidth or make the remote server respond faster. A slow-loading site could still point to DNS, rules, or the destination itself.

Check authentication and certificates before performance settings

Core fields typically include the server address, port, authentication details, and TLS settings. Use the existing authentication value exactly; don’t substitute a UUID or password from another protocol just because it looks similar. SNI and certificate verification still matter. Using UDP for QUIC doesn’t remove the need to verify the server’s identity. Certificate errors and UDP reachability failures may look different, so track them separately during troubleshooting.

If the existing server requires a particular Obfuscation method or password, the client and server must match. This is part of configuring the correct endpoint, not a switch that automatically improves performance. Don’t add it without explicit settings or casually remove it when it is already configured. Port ranges and port switching also require explicit support from the remote end; changing a port number on one side doesn’t create a reachable endpoint.

Bandwidth fields are estimates, not speed guarantees

Some transport modes use the user-entered upload and download bandwidth values for sending controls. Interpret direction from the client’s point of view and check the units carefully. A larger number won’t increase the physical capacity of the link. It may instead mismatch the actual path and cause queuing, packet loss, and fluctuations. A value that’s too low can limit effective throughput; assess it in the context of the current mode.

Available bandwidth varies by network. Results on home Wi-Fi don’t necessarily represent cellular performance. Start with the baseline from the existing configuration, and don’t change upload, download, and other transport settings at the same time. If the current interface or server uses automatic estimation, follow its instructions rather than applying required fields from another mode. Understanding what a setting means matters more than chasing a large number.

Recognize when the UDP path may be restricted

If ordinary webpages work when this entry isn’t in use but Hysteria2 never connects, check whether the current network supports UDP, as well as the server port and remote service status. A timeout alone doesn’t prove UDP is restricted; address resolution, authentication, or security settings could also be wrong. Retest the same original entry on another trusted network to narrow down the role of the network path.

If a connection is established but sustained transfers fluctuate considerably, first check for changes in wireless signal, saturated upload bandwidth, or device heat. More aggressive sending may improve throughput on some paths, but can also increase retransmissions, wireless activity, and battery use. On mobile devices, record both the time to complete a task and the energy used. A brief peak alone can’t show whether a setting suits long-term use.

07 · Assess Speed and Battery Use Separately on iOS

Break “fast” into three observable outcomes

Time to open a page the first time, sustained transfer throughput, and long-connection stability are three different metrics. Waiting time includes DNS, establishing the underlying connection, protocol and security handshakes, and the destination’s response. Sustained throughput depends more on bottleneck bandwidth, congestion control, and server load. Long connections are affected by network changes, idle timeouts, and background state. One latency figure can’t summarize all three.

Connectivity Test results depend on the test method and destination. They can help assess a particular kind of reachability or relative change, but they don’t represent an app’s complete network path. If the test succeeds but a page still fails, continue by checking DNS, rules, and the destination request. See the guide to latency tests and real-world loading to avoid judging reachability by the lowest number alone.

Variables to control when comparing protocols

Where possible, use the same device, network, approximate time, and destination. If two entries use different remote locations, routes, or server loads, the results primarily reflect two complete paths—not a pure protocol difference. If you can’t control those factors, record the actual experience but frame the conclusion as “how this entry performs on this network,” not as a claim that one protocol is always faster.

Change one factor per round, and assess short requests and sustained tasks separately. The first round may be affected by caching, handshakes, and wireless conditions; leave an interval between repeat tests. Running at full bandwidth continuously changes device temperature and network congestion, which can skew results. If you switch Wi-Fi, enter a weak-signal area, or start another high-traffic task during a test, treat that as a different set of conditions rather than combining the results.

Battery use comes from data and wireless activity

Encryption and encapsulation take processing time, but mobile battery use is also affected by signal strength, radio wakeups, retransmissions, the screen, and background tasks. Lower protocol processing overhead doesn’t guarantee lower total power use. Frequent connection failures and retries, or keepalive packets that keep the radio active, can cost more than differences between protocol algorithms. Assess the overall result after completing the task.

When assessing battery use, distinguish sustained video playback, active transfers, and idle connections. For sustained tasks, compare the time and battery change needed to complete the same work. For idle use, look for unnecessary scheduled tests, keepalives, and reconnects. System battery statistics offer clues about activity over time, not a controlled protocol power test. No visible percentage change over a short period doesn’t prove there was no extra cost.

On Demand and the limits of connection reuse

On Demand triggers connections based on network conditions; it won’t make the server protocol adapt to incorrect settings. First establish a stable baseline with a manual connection, then add trigger conditions. This helps distinguish a protocol failure from a trigger that never fired. For condition settings, see the guide to On Demand network conditions. Record network changes and connection status during testing.

Connection reuse can reduce repeated handshakes, but it can also cause multiple requests to share the same congestion or failure state. Follow the existing server’s support and the current interface instructions when deciding whether to use it. If a few requests stall, don’t rule out reuse just because it is “usually faster.” Keep the original entry and compare one variable at a time using the same task; check that the result is repeatable.

08 · Choose by Use Case, Then Troubleshoot by Layer

Choose from the entries you already have

For everyday browsing, start with an existing working entry that provides stable short requests, reliable name resolution, and complete security settings. For sustained transfers, assess stable throughput and device temperature rather than only the first test. For access to existing internal networks, WireGuard address ranges and return paths may be key. On lossy paths, you can evaluate an existing Hysteria2 entry, provided UDP works. These are things to check, not a ranking of protocols.

If your existing information provides only one protocol, configure that one correctly; you don’t need to seek out another endpoint for comparison. If it provides several complete entries, keep each original configuration and test them for their intended uses. Don’t combine TLS from one entry, Path from another, and credentials from a third. A failure caused by mixed settings can’t tell you whether any protocol is suitable.

Check the Global Routing mode before testing

Config mode selects policies according to the configuration file’s rules. Proxy mode sends relevant traffic through the proxy path, while Direct mode handles it through a direct path. Changing modes changes where the test goes, so record the current selection each round. Proxy mode is still constrained by the entry and request capabilities; it can’t fix incorrect credentials. Direct mode provides a path comparison but doesn’t guarantee every request will succeed.

After verifying the protocol entry, return to Config and check the rule order. The .conf snippet below illustrates matching logic; it isn’t a universal configuration. The PROXY policy must resolve correctly in the actual configuration. Rules are generally matched in order, with FINAL handling requests that haven’t matched earlier. Domain and IP rules rely on different information, and DNS resolution may also affect the final match.

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

This example sends example.com and its subdomains to PROXY, and the specified private address range and GEOIP matches to DIRECT. It doesn’t mean every environment should use the same policies; GEOIP results also depend on the address and data source. To understand section names and configuration boundaries, read the guide to .conf sections. Don’t change protocols to work around a rule that matches incorrectly.

Narrow down the problem by where it occurs

If nothing connects, first check the current network, address resolution, port, and server status, then verify identity fields. For a clear certificate error, check the device time, SNI, name, and certificate chain. If the connection succeeds but fails afterward, check the transport endpoint, destination permissions, and forwarding capabilities. If only some domains are affected, start with DNS, rule matches, and destination status rather than rebuilding every entry.

If webpages work but a real-time app fails, check TCP and UDP separately. If small requests work but larger transfers stall, look at MTU, retransmissions, and congestion. If the connection fails after idle time, check mapping timeouts and keepalive requirements. If it happens only after a network switch, record the addresses before and after and whether the connection recovers. Change only relevant settings for each case and retest the same task; restore other automation conditions only after confirming the fix.

Record findings without exposing credentials

A useful troubleshooting record includes the protocol type, transport, network conditions, failure stage, current Global Routing mode, and a repeatable description of the issue. Don’t include Password, UUID, Private Key, or the full subscription URL in public records. App logs and screenshots may contain these details, so inspect them carefully before sharing rather than only hiding the entry name. The name is usually not the most sensitive field.

Keep the conclusion specific: which complete entry worked for which task, and under what network conditions. For first-time setup, return to the main tutorial; for common issues, see Troubleshooting; for purchases and recovery, see the App Store verification guide. Handle purchases, imports, protocol connections, and rule matches separately so the next troubleshooting session can build on what you’ve confirmed instead of starting from guesses.