Shadowrocket Protocol Guide

Four layers to consider when choosing a protocol

Separate protocol, transport, encryption, and routing

Choosing a protocol in Shadowrocket determines how the client communicates with a server you already have; it does not select a speed tier. A connection has at least four layers: the protocol defines request and authentication formats, transport carries data to the other end, encryption protects data in transit, and routing determines which requests use that connection. These layers are related but not interchangeable. After selecting the correct protocol type, make sure the server address, port, credentials, and transport settings all match. Matching names alone do not prove that the two ends can communicate.

For example, VLESS defines a request and authentication format, WebSocket is a transport, TLS encrypts the relevant connection and verifies identity, and DOMAIN-SUFFIX determines whether a domain uses a proxy policy. A protocol can use different transports, and a transport can carry different protocols. Treat the complete set of server-provided settings as one configuration: do not combine authentication details from one configuration with transport settings from another. If imported settings show several names, first identify which layer each one describes.

Define what you want to compare

Web browsing often involves many short requests, so connection setup time, DNS resolution, and connection reuse can affect how responsive it feels. Large file transfers are more likely to reveal sustained throughput, congestion control, and server egress limits. Voice and interactive apps are more sensitive to latency variation, packet loss, and UDP availability. So “web pages load quickly” and “large transfers are fast” are different findings. Extrapolating from one download to every app can send troubleshooting in the wrong direction. Define your goal first, then choose a test that reflects it.

On iPhone and iPad, also record when and under what network conditions you use each configuration. Stationary Wi-Fi and cellular use while moving can involve different address changes, wireless retransmissions, and background scheduling. Protocol encapsulation, encryption, and keepalives add overhead, but screen brightness, wireless signal strength, and transfer volume also affect battery use significantly. Without controlling these factors, a comparison describes only one use session; it cannot establish a definitive ranking of protocol power consumption, let alone prove that a newer-sounding protocol uses less battery.

Choose in an order that makes it easy to roll back

Your choice is first constrained by the capabilities of the server you already have. If you have just one complete configuration, use the type specified in its details; there is no need to change protocols just to compare them. If you have several usable configurations, first confirm that each connects on its own, then compare first visits, repeat visits, and sustained use against the same target. Keep a copy of the original configuration, change only one variable per test, and record the network used. That way, if an adjustment does not help, you can return to a known state instead of losing your baseline after a series of changes.

Then consider ongoing maintenance. Connections with more settings require more complete records, and certificates, domains, and transport paths may each change over time. A configuration that seems faster for now but lacks a clear source for its settings may not be suitable for long-term use. Prefer a complete, verifiable configuration that fits your needs. This guide explains differences and limitations; it does not replace server settings or claim that one protocol is best on every network.

Shadowsocks, HTTP, and SOCKS5

Shadowsocks: a straightforward encrypted proxy

Shadowsocks is designed to carry proxy traffic with a relatively simple protocol, using an agreed encryption method and key material for communication between the two ends. It generally requires fewer layered transport settings than more complex combinations, but that does not make all configurations interchangeable. Encryption methods have different key requirements and ways of handling data, and server support can vary. First confirm that the method in your existing details matches an option in the client, then check the server, port, and authentication material.

Treat the password and encryption method as a pair. Some configurations use a plain-text password; others require a specific key encoding and length. Treating encoded material as an ordinary password—or changing the encryption method just because one option “looks stronger”—can cause authentication to fail. When importing a subscription, keep the imported values. When adding a configuration manually, enter each value as provided and do not add unspecified options. If the configuration uses an additional transport, check its separate settings too; do not assume the server will accept defaults.

On iOS, fewer encapsulation layers can reduce additional processing, but actual speed still depends on server resources, connection quality, and the destination site. Modern devices' encryption performance is usually not the only bottleneck, and an algorithm name alone does not determine battery use. If the device heats up only during sustained transfers, compare sessions with similar transfer volumes. If battery use is high even when idle, check reconnects, signal strength, and keepalives instead of immediately changing the encryption method. Incorrect protocol settings generally will not fix themselves if you wait longer.

HTTP: distinguish the proxy connection from the destination connection

HTTP proxies were originally designed to forward web requests. They can forward ordinary HTTP requests and use CONNECT to create a tunnel to a destination. Keep the two connections distinct: from your device to the proxy server, and from the proxy server to the destination site. A website using HTTPS does not automatically mean the connection from your device to the HTTP proxy also uses TLS. If the server explicitly provides an encrypted proxy endpoint, configure that connection as specified; do not infer the security of the entire route just because the destination URL starts with HTTPS.

Common HTTP proxy fields include an address, port, and optional username and password. Authentication depends on the server settings, and blank credentials may produce a different result from incorrect ones. Whether CONNECT allows a destination port depends on server policy. If ordinary websites work but a particular service does not, the client’s protocol implementation may not be at fault. Troubleshoot with a known-permitted destination first, then check the port and transport the service actually uses. This avoids mistaking an access restriction for a lack of speed.

SOCKS5: general-purpose forwarding does not provide encryption

SOCKS5 supports general-purpose connection forwarding, with mechanisms for authentication negotiation, connection requests, and UDP associations. The protocol itself does not provide general-purpose encryption for the connection. A username and password do not mean that data is traveling through an encrypted channel. SOCKS5 can be used within an existing trusted network or alongside a separately provided secure transport. Before choosing it, understand the server’s access scope and how traffic is protected. Do not equate SOCKS5 with protocols that include encryption simply by comparing the number of fields.

For SOCKS5 to carry UDP, both ends must support it, the server must allow it, and the intervening network must be reachable. A successful TCP connection does not prove that a UDP association works. If web browsing is fine but a real-time service fails, test that service’s path separately. Which end resolves domain names can also affect results and access behavior; the server address field alone does not tell you. When maintaining an existing configuration, preserve the original authentication, DNS, and UDP settings, then test them against your actual needs. This is more effective than toggling options at random.

VMess and VLESS: design trade-offs

VMess: check authentication and protocol settings together

VMess includes user authentication and protocol-level data handling, and commonly uses a UUID to identify user information. It is often combined with other transports, so a configuration may include a UUID, protocol security options, transport type, and outer TLS settings. A UUID alone does not make a complete connection: the address and port determine where to connect, authentication determines whether the server accepts the client, and outer settings determine how the request reaches the service. A mismatch at any layer can result in a timeout or a closed connection.

When checking settings manually, first make sure the UUID is complete, paying particular attention to spaces, line breaks, or missing characters introduced during copying. Then check the security options required by the server, followed by the transport fields. Older configurations may include additional settings; do not copy values from one set of details into another. Follow the instructions for the service you already use. If authentication depends on time, a significantly inaccurate device clock can also affect the connection. Set the correct time before deciding whether credentials need updating.

VLESS: a streamlined protocol still needs a security layer

VLESS focuses on streamlined authentication and request encapsulation. It typically uses a UUID, but its design does not center on providing a general-purpose data encryption layer within the protocol itself. Understand it alongside the security and transport mechanisms in use; fewer fields do not mean you can skip verifying the remote identity. A UUID is authentication material, not a substitute for certificate validation. Transport, TLS settings, and other server-specified fields remain part of the complete connection and should be kept together.

Some existing configurations also specify particular flow settings. These depend on server behavior and the available transport; they are not general-purpose speed boosts. If the details do not specify them, do not copy them from another configuration found online. If a required setting does not match an option currently available in the client, do not substitute a similarly named value. Confirm the app’s capabilities and server requirements first. This is more reliable than repeatedly trying combinations that may lead you to incorrect assumptions.

Match WebSocket and other transports as a set

For WebSocket, common settings to check include the request path and Host. The path may be used for server-side routing; capitalization, the leading slash, and other components can all matter, so do not remove them arbitrarily. Host is used for routing the relevant request; it is not necessarily the address used to establish the network connection, nor is it necessarily the TLS Server Name. If the server distinguishes requests at different layers, each value may serve a different purpose. Replacing every domain with the same address can break an otherwise correct configuration.

For other transports, check the fields specified for that transport. For example, when a service name is involved, do not treat it as interchangeable with a path just because both are text values. If the outer connection is established but the request still fails, the request may have reached the entry point without being forwarded to the correct backend. Check transport settings alongside server routing conditions instead of generating a new UUID. Changing authentication material will not fix an incorrect path, and vice versa.

How to compare actual overhead on iPhone

You cannot assess the perceived difference between VMess and VLESS without considering their transport and server. TLS handshakes, connection reuse, extra encapsulation, and server load may affect first visits more than the protocol format itself. If one configuration uses a direct connection while another passes through an additional forwarding layer, any speed difference cannot be attributed entirely to the protocol name. Keep the network, destination, transport conditions, and test time as similar as possible. Record initial connections separately from subsequent requests.

For long-term use, also observe recovery after a network change rather than recording only the initial connection. When a device switches from Wi-Fi to cellular, existing connections may need to be re-established; the result depends on both the transport mechanism and system scheduling. If failures occur only during a network switch, first test whether disconnecting and reconnecting restores service, and note whether all apps are affected. This helps distinguish a connection-recovery issue from incorrect static settings and avoids mistaking a reproducible network condition for a protocol that is always unavailable.

Checking Trojan and TLS settings

Trojan’s secure outer connection

Trojan carries proxy requests and authentication within a TLS connection, using an established secure transport mechanism. For the connection to work, the password, server address, and TLS identity checks must all be correct; they are not alternatives. Even with the right password, a mismatched server name, an untrusted certificate, or an incorrect port can prevent a valid connection. Troubleshoot in order, from the outer connection to inner authentication.

TLS does more than encrypt traffic: certificate chains and name matching also help verify the remote identity. A handshake failure occurs before business data is forwarded. So “the page won’t open” is only the final symptom; it does not tell you that the password is wrong. First confirm that the network can reach the endpoint, then check certificate requirements. Only after the secure connection is established should you investigate inner authentication and the destination request. This order reduces repeated work caused by changing several fields at once.

Connection address, Server Name, and Host

The server address answers “where should the network connection go?” Server Name is used for the server name indication in the TLS handshake and related identity checks; the exact field name depends on the current interface. An existing configuration may connect to one network address while using a different, explicitly specified domain for name verification. Do not assume that this difference is a mistake based on appearance alone. Changing Server Name to the connection address may cause the certificate to stop matching; changing only the address without checking the server endpoint could connect to an entirely different service.

Host serves a different purpose from Server Name when it is part of the relevant application-layer request. Enter it as specified only when the transport in use includes that field; do not invent a meaning for connections that do not use it. If a configuration lists multiple domains, record which layer each belongs to. Troubleshooting is easier when your notes distinguish the connection address, TLS name, and request-routing value—and state which fields remain at their defaults—rather than listing a single “server domain.”

Do not bypass verification to work around certificate errors

Check certificate issues against three factors: whether the device time is correct, whether the configured name matches the certificate’s coverage, and whether the server provides a complete, trusted certificate chain. Expiration, an incomplete chain, and a name mismatch are different problems with different remedies. The client can check local settings and time; a certificate deployment problem on the server must be handled by the administrator of the service you use. Repeatedly changing the password will not fix a certificate chain or identify the cause.

Skipping certificate verification changes how the remote identity is checked and should not be the default troubleshooting step. If a connection works only after verification is disabled, that shows there is an issue with the original identity check; it does not prove the server is trustworthy. Keep the original settings, identify the mismatch, and then restore normal verification. If the service requires additional trust material, first confirm its source and scope. Do not apply certificate settings copied from another connection to the current configuration without checking them.

TLS overhead and persistent connections

Establishing a TLS connection involves extra round trips and computation, but later requests may reuse that connection. The actual impact depends on app behavior and network conditions. A scenario with frequent reconnects and small transfers is not directly comparable to one with a persistent, high-volume connection, based on a single first-load time. Retries on a weak signal can also increase handshake costs and make battery use seem like a fixed protocol characteristic. Separate first connection, continued use, and recovery after idle periods in your tests.

Do not assume Trojan supports UDP just because the outer TLS connection works. Check server support and test the actual app or service. If web browsing works but a real-time service does not, check routing first, then test the UDP path separately. These checks for certificates, domains, and transport can also apply to other TLS-based protocols, but that does not make their passwords or request formats interchangeable. You can use the same troubleshooting approach for shared layers while keeping each protocol’s own settings consistent.

WireGuard keys and routing

How it differs from request-based proxies

WireGuard is designed as an IP-layer tunnel. It uses public-key cryptography to identify peers and carries encrypted data over UDP. Its configuration and troubleshooting layers differ from those of protocols that create proxy connections for individual destination requests. In Shadowrocket, also consider how the client routes traffic into the connection and how the remote end forwards it. Establishing a tunnel does not mean destination routing, DNS resolution, and return paths are all correct; test the actual service as well.

WireGuard uses a defined cryptographic suite and a relatively streamlined protocol state, leaving less room for users to assemble their own algorithm combinations. But streamlined does not mean every field can be left blank: the local address, keys, remote endpoint, and allowed address ranges each have a distinct purpose. The server must recognize the client’s public key and provide compatible network settings. Replacing a private key without updating the corresponding server-side details will usually break the existing identity relationship.

Private Key, Public Key, and Endpoint

The Private Key is a local secret and should be used only in trusted configuration storage. The Public Key identifies a peer; it does not have the same confidentiality requirements. When entering a remote Public Key, use the peer key explicitly listed in your details, not your own public key. Some configurations also include a pre-shared key, which is additional security material, not a free-form note. These fields are not interchangeable or safely simplified by deleting one just because their names all include “Key.”

Endpoint specifies the remote entry address and port; it is not the same as the local address used inside the tunnel. The Endpoint finds the server on the current network, while the local address is used for communication within the tunnel. Address prefix lengths have a specific networking meaning and should not be removed as decoration. If an imported configuration reports missing fields, check the original details rather than substituting your device’s current Wi-Fi address. Physical network addresses and tunnel addresses belong to different layers; mixing them makes troubleshooting harder.

Allowed IPs, DNS, and MTU

In WireGuard, Allowed IPs relate to the destination ranges a peer can receive and to checks on incoming sources. The options available in the client and how they interact with routing depend on the current interface and your existing configuration. Do not treat Allowed IPs as another way to write Shadowrocket rules and change them arbitrarily. A tunnel limited to a particular private subnet will not automatically provide full internet access just because it is selected. Remote forwarding, egress, and return routing must also support the destinations you need.

DNS determines how names resolve to addresses; tunnel routing determines how traffic reaches those addresses. Check them separately. If a known address is reachable but a domain is not, check the DNS path first. If the name resolves but the connection fails, check destination ranges and remote forwarding. MTU affects packet size after encapsulation; an MTU that is too large can cause small requests to work while larger responses stall. Do not respond by entering a generic value at random. Keep the original setting, confirm the symptom, and then test one change at a time based on server guidance.

Keepalives and recovery on mobile networks

Persistent keepalives can maintain network mappings in specific environments, but more frequent is not necessarily better. They may help in scenarios that need to receive incoming data after idle periods, but they also add periodic traffic and wake the wireless radio. Whether to use them, and how often, depends on the server’s role, network mapping timeouts, and actual usage—not on whether the interface appears continuously active. If you only initiate ordinary requests, shortening the keepalive interval is not a universal way to make everything faster.

WireGuard’s peer identification can handle changes to the endpoint address under certain conditions, but recovery after a network switch still depends on the system, server, and current UDP reachability. A continuous connection cannot be guaranteed. Test the first request after an idle period and actual requests after switching networks, and confirm that the destination uses the tunnel. When sharing diagnostics, hide the Private Key, pre-shared key, and internal network details. Include only the necessary symptoms, field names, and error category; do not share the full configuration just to make troubleshooting easier.

When Hysteria2 may suit your network

Understanding its design in relation to loss and congestion

Hysteria2 builds proxy communication on QUIC, which runs over UDP and includes mechanisms for secure handshakes, stream management, and congestion control. One design goal is to adapt transport behavior to network paths of varying quality. That does not remove physical network limitations: poor wireless signal, insufficient server egress, or a network that blocks the relevant UDP traffic can still cause failures or reduce throughput. Confirm the transport is available before evaluating its performance on your network.

QUIC’s multiple streams can reduce some kinds of blocking between streams caused by in-order delivery at the transport layer. But link capacity, congestion, and shared server resources remain common constraints. This does not mean every request will proceed without waiting, nor does it guarantee lower latency for games or voice calls. Interactive apps are sensitive to queuing and packet loss; sustained transfers depend more on stable throughput. The same settings may improve one without improving the other, so record the results separately.

Authentication, names, and obfuscation settings

First check the server address, port, and authentication details, then verify the TLS name and certificate validation. Preserve the full authentication value; do not truncate it because it looks like a note. As with other TLS-based connections, the actual connection address and the name used to verify identity may serve different purposes; follow the details you have. If the client has not completed a secure connection, check outer reachability and name matching before concluding that the authentication material is invalid.

Some services provide additional obfuscation settings. Use them only when the server explicitly specifies the same mechanism and values. Obfuscation does not replace authentication or serve as a standalone speed boost. If the client and server disagree on whether it is enabled, or use different passwords, they may fail to recognize the data before normal protocol processing begins. Keep imported settings together. Save a copy before manual changes, and do not fill in missing information by copying options that merely look similar from another configuration.

Bandwidth settings are inputs, not speed guarantees

If your existing configuration includes upload and download bandwidth fields, first confirm which direction and units they use, and understand that they may affect congestion control. Setting values far above the current link capacity will not increase available bandwidth; it may instead cause queuing, packet loss, or competition with other traffic. Mobile network capacity changes with location and time, so a fixed estimate may not always apply. Keep the server’s recommendation or a reasonable client default, then use sustained tests to determine whether an adjustment is needed.

If web pages load normally but large transfers fluctuate, compare results on different networks and check whether other apps are affected too. If voice calls become choppy when a transfer starts, queuing or resource contention may be the cause—not an authentication or TLS setting. Reduce concurrent tests, pause other high-volume tasks, and retest the same destination to see whether load is the main factor. Do not try to cover up an unconfirmed bottleneck by repeatedly increasing bandwidth values.

UDP reachability and battery trade-offs

A network that allows web browsing does not necessarily allow connections to the required UDP port. If Hysteria2 works on one network but fails on another, preserve the configuration and first check whether the underlying reachability differs. Repeatedly changing the password can break a correct configuration without addressing a transport restriction. If you already have another complete, working configuration, you can cross-check it on the same network. Keep your conclusions specific to that network rather than generalizing them into a ranking for every situation.

On iPhone, higher throughput can mean more data processed in less time, and may also increase wireless and processor load. Battery use depends on how long you run the connection, total data transferred, and reconnects while idle; an instantaneous speed reading is not enough to judge it. After switching networks, verify that your apps work again rather than just checking the connection toggle. If failures are frequent, reduce test intensity, record what happens, return to a known configuration, and isolate transport, settings, or server conditions one at a time.

Checking Settings and Routing Rules

A successful import does not verify the service

Importing an existing subscription with Subscribe first shows that the client can read and parse its details. It does not mean every connection has passed authentication or offers the same capabilities. After importing, review a target configuration’s type, address, port, and required transport fields to confirm they match the details provided. A name is just a label for identification, not proof of protocol type. If the label names one protocol but the actual type differs, check the original details instead of guessing and changing it manually.

QR codes and share text are also configuration formats; encoding, escaping, and field mapping can affect parsing. Missing characters, selecting explanatory text along with the configuration, or reading incomplete content can all cause problems. Check that the original details are complete before filling in fields manually. A subscription update may overwrite local changes, so keep a separate copy and record its source before testing adjustments. That way, a temporary fix is not mistaken for a change that will persist after future updates.

Global Routing determines whether rules apply

In Global Routing, Config, Proxy, and Direct respectively mean handling traffic according to the configuration, using a proxy, or connecting directly. For everyday routing by website, first confirm that Config is selected, then check the currently enabled configuration file. Proxy can help test a proxy path when you understand its scope, but it does not replace checking the rules. Direct cannot prove that a proxy protocol is working. Record the routing mode, current server, and active configuration as separate states.

Rules are generally checked from top to bottom. An earlier match may prevent a more specific rule below it from running. DOMAIN matches a full domain; DOMAIN-SUFFIX matches a domain and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain. IP-CIDR matches an address range, GEOIP applies a geographic classification to an address, and FINAL is the fallback when no earlier rule matches. These rules match different kinds of targets, so they are not interchangeable just because they can refer to domains or addresses. DNS behavior can also affect some address-based matches.

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

This snippet shows rule order, not server details or a complete configuration that can establish a connection. Place the specific REJECT rule before the broader DOMAIN-SUFFIX rule to prevent it from being matched by the latter first. PROXY should be understood in the context of a currently usable proxy connection. FINAL,DIRECT sends requests that match no earlier rule directly. The example domains are for illustrating syntax only. If your existing configuration uses custom policy names, check their definitions; do not replace an unfamiliar name with PROXY by default.

Verify the result with actual connection records

A service may use separate domains for its page, static resources, authentication, and real-time communication. Loading the main page does not mean every request matched the same policy, and a failure in one component does not prove the protocol as a whole is broken. Check the destination and policy used by actual connections. Distinguish a rule that did not match from a connection that could not be established or an error returned by the destination. Do not delete every rule to fix a single resource; that removes the original configuration’s purpose and makes it harder to tell what actually helped.

For more on match types, see a guide to rule keywords. For routing only selected websites through a proxy, see how to route selected sites. For REJECT, read when and how to use REJECT. Protocols determine how connections are established; rules determine when they are used. Verify each separately before combining them, so troubleshooting results remain meaningful.

Speed, battery use, and troubleshooting

Start with tests under consistent conditions

When comparing existing configurations, keep the device, network, destination, and Global Routing mode the same. Pause other high-volume tasks and test at roughly similar times. Record the initial connection, repeat visits, and sustained transfers separately. Connectivity Test can help check reachability, but its target and connection method may differ from those of your actual app; one result cannot replace testing the service itself. After testing, restore the original routing mode so temporary settings do not affect everyday connections.

For battery comparisons, use similar test durations and total data volumes, and control for screen use, signal strength, and background activity. The system’s battery page reflects app activity and system-level statistics; it is not an independent measurement of protocol power use. A short test is especially vulnerable to differences in startup, caching, and wireless conditions. If the device keeps heating up, stop the high-load test and check for large transfers or repeated reconnects. Adding more concurrent tests before identifying the cause only makes conditions less consistent.

Troubleshoot by failure stage, not by changing settings at random

If a connection cannot be established at all, first confirm the network is working and the endpoint address and port are correct, then verify the protocol type. For connections using UDP, check that the path is reachable. For TLS connections, check the name, device time, and certificate requirements. If the outer connection is established but authentication is rejected, check the password, UUID, or key. Change one setting at a time and keep the original value; if it does not help, revert it immediately to avoid introducing new problems in fields that were correct.

If the connection appears normal but an app does not work, first check whether its traffic is using the expected policy, then distinguish DNS resolution, destination connectivity, and the app’s response. If a known address is reachable but its domain is not, check DNS first. If only one destination fails, check the destination or server access requirements. If only large responses stall, investigate MTU, packet loss, and connection quality. These are clues, not conclusions; further tests are needed to rule out other causes.

If failures occur only after a network switch or idle period, record the conditions, wait time, and what changes after reconnecting. If a manual reconnect restores service, the static settings have worked at least once. Focus on connection recovery, network mappings, and server session handling instead of immediately re-entering all credentials. Include On Demand settings in your notes because they affect connection behavior, but they will not fix incorrect authentication or missing server capabilities. First establish repeatable results with a manual connection, then adjust the on-demand conditions.

Narrow your choices to the use case

For everyday web browsing, start with a stable existing configuration whose settings are clear and that performs consistently on first and repeat visits. For real-time communication, first verify UDP and latency variation. For a restricted internal subnet, focus on route ranges, address conflicts, and DNS. For sustained high-volume transfers, check throughput stability and the effect on other apps. These recommendations describe a testing order, not a ranking of protocols. Only capabilities the server actually supports should be considered for a given use case.

Keep records of the protocol type, outer transport, network, Global Routing mode, category of failed destination, and reproducible steps. Before sharing details with the administrator of a service you already use, hide subscription URLs, authentication material, private keys, and other sensitive values; include only the areas needed for troubleshooting in screenshots. For the system permission prompt on first connection, see the VPN configuration prompt guide. Look up common field meanings in the glossary, and return to the Quick Start Guide for the full setup steps.