Shadowrocket Protocol Selection and Configuration Guide

01 / SELECTION

Choosing a protocol: confirm the server first, then compare transport requirements

Understand protocol, transport, security and routing separately

In Shadowrocket, choosing a protocol type tells the client which format to use when communicating with the server. It is not a speed setting that can be swapped at will. If your server provides Shadowsocks, use the corresponding Shadowsocks type and authentication details. A server configured for Trojan will not work by simply changing the type to VLESS. The same address and port only identify the same destination; they do not prove that the server accepts the same handshake, authentication or data encapsulation. Always start with the protocol explicitly specified in your existing details.

A working connection typically involves four layers of information. First, the address and port determine where data is sent. Second, the protocol and authentication determine whether the server accepts the request. Third, transport and security settings may include TLS, WebSocket or UDP. Finally, local routing determines which requests use the connection. Some protocols combine several layers; others allow different combinations. Troubleshoot each layer separately to avoid mistaking a DNS problem for an incorrect password, or a rule mismatch for an incompatible protocol.

There is no fixed ranking for speed or battery life

Actual speed depends on the access network, round-trip latency, packet loss, server load, outbound bandwidth and destination service. An extra layer of encapsulation usually adds bytes and processing, but that does not mean it is always slower: a transport better suited to the current network may reduce retransmissions enough to outweigh that overhead. Differences between two servers using the same protocol can also be much larger than differences between two protocols on the same server. For that reason, this guide does not rank protocols by speed.

Battery use on iPhone and iPad also depends on how the connection is used. Sustained high-volume traffic keeps the wireless link, encryption and app processing active; intermittent requests are more affected by connection setup, background keepalives and network wakeups. Frequent automatic tests, short update intervals and repeated failed reconnects can obscure differences between protocols. For a fair comparison, keep the device, network, server and destination consistent, and account for screen brightness and other background tasks. A single battery drop does not prove that a particular protocol is responsible.

Build a repeatable comparison

Save a known-working configuration as a baseline, then change one setting at a time. Test the same destination for the first visit, repeat visits, sustained transfers and recovery after sleep. Do not change DNS, protocol and server in the same test. Connectivity Test can help you check connection status, but it does not prove that every service works. Websites, video and real-time voice have different transport requirements, so test the service you actually need rather than comparing a single number.

If your existing details specify only one protocol, import and verify those details as provided rather than guessing another type based on its name. To switch protocols, first obtain the complete settings prepared for the new protocol on the server. If the list is empty after importing a subscription, that is a separate issue from protocol selection; see what to check when the list is empty after importing a subscription. The sections below assume you have at least one editable server entry. Available fields depend on the options shown in your current app.

03 / VMESS · VLESS

VMess and VLESS: similar identity fields do not make them the same protocol

Design trade-offs and protocol boundaries

VMess organizes identity authentication and data handling as a dedicated proxy protocol. Its settings typically include a UUID and parameters related to security and transport. VLESS uses a more lightweight protocol layer and does not encrypt content on its own, so the complete connection must be considered together with its security transport. Both can use a UUID and be combined with different outer transports, so the identity field in a link alone does not identify the protocol. Use the type specified in the original subscription or by the server administrator; a UUID is not a universal credential shared across protocols.

VLESS's lightweight design does not guarantee that the complete connection uses fewer resources, nor does it mean the security layer can be omitted. With TLS, WebSocket or another transport, actual overhead and handshake behavior depend on the full combination. VMess performance also depends on server configuration and network conditions, not just the protocol name. When comparing options, record protocol, transport and security layer as separate dimensions before assessing compatibility or use cases. Comparing only one dimension can lead to conclusions that do not reflect real-world behavior.

UUID, transport type and path

A UUID identifies a user authorized by the server. Copy it in full, preserving every character and separator; a profile label is not a substitute. Labels help you recognize entries but are not used for protocol authentication. Some VMess parameters also depend on the protocol implementation and legacy configuration formats, so do not make bulk changes based on a single screenshot found online. If authentication depends on time, a significantly incorrect device clock can cause failure. First confirm that the system date and time are correct, then check whether the server rejected the identity.

Transport fields determine how protocol data is carried. With WebSocket, Path is the request path used during the handshake, and Host relates to the HTTP-layer host information. Neither is a server label, and you should not split a full URL among these fields arbitrarily. Check the server details to see whether the leading slash, letter case and query string must be preserved. Other transports may use different fields; do not copy WebSocket settings into another transport type. A field that is not shown in the interface cannot be replaced by another field just because its name looks similar.

TLS name and other extension settings

The connection address is used to reach the server. The TLS Server Name provides the name during the handshake and is relevant to certificate name verification; the two may match, or the server may specify different values. Host belongs to another layer and must not be substituted just because it also looks like a domain name. If your details include other security extensions or special handshake settings, confirm that the current app supports the combination. The presence of an input field does not prove that any combination will work with the server.

Optional settings such as Flow in an existing configuration apply to specific protocol combinations; they are not general-purpose speed switches. Enable them only when the server requires them and the client offers a compatible option. Do not try security settings at random instead of checking the original details; changing several handshake conditions at once makes it harder to identify the cause. For an imported subscription entry, keep the original and create a separate test copy. This makes it easier to tell whether the imported details were incomplete or later edits changed the connection.

How to compare behavior on mobile networks

When comparing these connections on iPhone or iPad, distinguish the initial handshake from data transfer over an established connection. Multiple handshake steps make short requests more sensitive to round-trip latency, while long transfers may depend more on bandwidth and congestion. After a network change, an existing connection may stop working while the app reconnects, causing a brief delay. If one transport takes longer to recover, note whether it happens after waking the screen, switching networks or during normal continuous use. Do not attribute the result to an overall difference between VMess and VLESS without checking the circumstances.

When a connection fails, check the address and port, protocol and UUID, outer transport, security layer, and destination access—in that order. If the connection log shows that the request did not select this server, check Global Routing and the active configuration first. For more general issues, see Troubleshooting. Avoid repeatedly changing identity fields before confirming the route.

05 / HTTP · SOCKS5

HTTP and SOCKS5: identify the proxy entry point and its protection

The purpose of two general-purpose proxy interfaces

HTTP proxying developed around forwarding HTTP requests. For web requests, the request target can use proxy form; for HTTPS and similar traffic, a CONNECT request is commonly used to create a tunnel to the destination. SOCKS5 provides a more general proxy session negotiation for specifying a destination address, port and connection request. These protocols define proxy entry points; they do not imply the same encryption, authentication or UDP capabilities. If your server specifies HTTP, do not switch to SOCKS5 just because the address is unchanged.

In particular, distinguish an HTTPS destination website from TLS between the client and the proxy entry point. HTTPS generally protects content through to the destination website, but a connection to an HTTP proxy without TLS has a different protection scope for proxy negotiation and some authentication details. A secure destination website does not mean every part of the outer proxy connection is protected in the same way. Assess each segment of the connection rather than relying on the browser address bar or a word in the server label.

Address, port and authentication mode

Basic HTTP and SOCKS5 settings usually include a server address, port and, when required, Username and Password. The server determines whether authentication is needed. Do not assume that leaving the fields blank will work, or that entering another protocol's UUID as a username will make it compatible. Authentication failures and network reachability problems can look similar, so compare the error with your existing details. When entering credentials, check for a domain or other prefix in the account name; preserve the complete format provided by the server.

If the proxy entry point requires TLS, select the corresponding security setting and check the certificate name. A port number alone does not show whether the entry point is encrypted or accepts CONNECT. Some servers restrict destination hosts, ports or authentication methods. Even if the client connects to the entry point, subsequent requests may still be rejected. If certain destination ports fail, first check the authorized scope and server policy instead of repeatedly changing local DNS or assuming that HTTP proxies can only access websites.

DNS resolution and UDP requirements

SOCKS5 can express a destination address as a domain name, but whether a request sends that domain to the proxy for resolution still depends on client behavior, DNS policy and whether the destination has already been converted to an IP address. Selecting SOCKS5 does not prove that all DNS requests are resolved remotely. An HTTP proxy may also receive the destination hostname in a request, but other DNS queries made by an app need to be considered separately. To troubleshoot domain resolution, check the actual connection destination and DNS result rather than only the server type.

The SOCKS5 specification includes UDP ASSOCIATE, but that does not mean every server, access network and client combination can forward UDP successfully. Negotiation may involve both a control connection and a forwarding address, and the network may restrict either one. If TCP services work but UDP services fail, check separately whether the server has UDP enabled, the returned address is reachable and the rules select the same entry. A successful website test does not prove that voice, games or other UDP services will work.

Use cases and mobile considerations

These proxy entry points are commonly used with an existing organizational proxy, authorized network access or an environment that explicitly provides a general-purpose proxy protocol. Configure them according to the type and security requirements specified by the administrator; fewer settings do not necessarily make a protocol better for long-term use. On iPhone and iPad, connection stability still depends on network changes, credential validity and server restrictions. If a proxy repeatedly reports authentication failures, check the credential status and authorized scope rather than relying on repeated reconnects.

If your work requires low latency or UDP, first confirm that the entry point supports those requirements. If you only need access to specific authorized resources, pay particular attention to destination routing and authentication scope. Protocol selection works within the connection conditions you already have; it cannot add capabilities the server does not provide. You can note the purpose and network conditions in an entry's label, but do not include a password. This helps distinguish entries without exposing credentials in list screenshots.

07 / HYSTERIA2

Hysteria2: confirm UDP availability before using this QUIC-based transport

Design goals and network requirements

Hysteria2 uses QUIC as the basis for proxy transport, with a focus on data delivery and congestion handling under challenging network conditions. QUIC runs over UDP and uses TLS for its security handshake. It can organize multiple data streams within one connection, unlike a single TCP byte stream, but those streams still share the overall bandwidth, congestion conditions and server resources. Multiple streams do not mean an individual request is entirely unaffected by other traffic, and the protocol name alone cannot predict actual throughput.

The most important requirement is a working UDP path. Some networks allow normal web browsing but restrict or handle UDP entry points differently. A working TCP-based entry therefore does not prove that a Hysteria2 entry should work. If it fails, first check DNS resolution, the port and UDP reachability, then check authentication and TLS. If the underlying path is unavailable, changing bandwidth settings or adding keepalives will not make up for the missing network conditions.

Authentication, TLS and obfuscation settings

Existing Hysteria2 details typically include a server address, port, authentication information and TLS settings. Preserve the authentication field exactly as required by the server; do not try a password from another protocol. TLS follows the same principles described above: the connection destination, Server Name and certificate name must be correctly related. Even though the transport uses UDP, certificate validity dates, names and trust chains still matter. Not every handshake failure is caused by UDP restrictions.

If the server uses obfuscation, the client needs the corresponding type, password and other settings. Obfuscation, authentication and TLS are separate layers with different roles; getting one right does not remove the need to check the others. Do not add unknown settings if the entry point does not use obfuscation. If an imported entry works but a manually recreated one does not, compare the fields one by one, especially optional settings that may be omitted from abbreviated details.

Bandwidth fields are not speed test results

Some configurations include upload and download bandwidth fields that may affect how a particular congestion-control mode behaves. The values are not speeds measured by the client in real time and do not represent guaranteed server throughput. Server policy and negotiation may determine whether they take effect; entering a larger number cannot increase physical bandwidth. Check the units used by the app, avoid confusing bytes per second with bits per second, and do not put your download capacity in the upload field.

A value far above the actual access capacity may cause queuing, packet loss and instability in some modes; a value that is too low may limit available throughput. Use real network conditions and the server's instructions as your guide, and keep the original configuration as a baseline. During testing, observe sustained downloads, responsiveness of interactive requests and whether other apps experience queuing. A brief speed peak does not prove that the settings are appropriate; assess stability over a longer period.

Resource use on iPhone and iPad

QUIC processing, encryption and data transfer all use device resources. Actual battery use depends on the implementation, traffic, packet loss and wireless signal strength; there is no fixed conclusion that applies to every device. During high-volume testing, both app processing and wireless transfer are active, so a warmer device does not by itself prove a configuration error. More useful indicators include sustained performance under the same workload, repeated background reconnects, and problems on weak signals or after waking from sleep.

If the connection fails only on a particular Wi-Fi network, test the path on another authorized network. If it fails on every network, check the original authentication details, TLS and server status. If the connection establishes but stalls during high-volume transfers, check packet loss, packet size, bandwidth settings and remote resources instead of immediately switching protocol types. A switch only helps if the server actually provides the new protocol. Record the stage at which the failure occurs and a concise error message; this is more useful than simply noting that it does not work.

After testing, stop repeated speed tests and unnecessary sustained transfers, restore your normal configuration and observe battery use. If the problem started after a subscription update, compare the entry settings first to distinguish a server-side change from a local network change. Manual edits to a subscription entry may be overwritten by a later update, so keep test copies separate and understand how they relate to the subscription entry to avoid the same issue recurring after an update.