Shadowrocket Protocol Guide

01 / FOUNDATIONS

Protocol layers and iOS performance

Break the connection into layers you can check separately

Choosing a type in Add Server determines only part of how a connection works. A proxied request also depends on the server address, port, authentication, transport, encryption, destination resolution, and traffic routing. Think of a protocol as the message format agreed on by the client and server, and transport as the channel that carries those messages. The same protocol over different transports can have different connection setup, overhead, and failure points. Likewise, using the same transport with different protocols does not make their authentication fields interchangeable.

For example, VLESS can be combined with TLS, WebSocket, and other settings, but choosing VLESS does not enable those settings automatically. If the server requires a specific path, the client cannot infer it from the protocol name. If the server accepts only plain TCP, enabling another transport in the client will not make the connection compatible. Before entering details, group what you have into four categories: where to connect, how to authenticate, which transport to use, and how to verify the peer. If a required item is missing, check the original configuration.

Throughput, response time, and stability are different measures

Speed has at least three dimensions: how long a page takes to open the first time, throughput during a sustained download, and jitter during calls or interactive use. A setup with more handshakes may take longer to connect initially while remaining stable for long transfers. A high-bandwidth connection can still feel sluggish if packets queue up. Connectivity Test can reveal obvious reachability issues, but its results depend on the test target, connection reuse, and DNS caching, so it is not a substitute for testing the actual task.

On iOS, app traffic is handled by the system network extension. Performance depends not only on the protocol but also on wireless signal strength, server distance and load, and the destination website. With a weak Wi-Fi signal, retransmissions may affect speed more than encryption does. When the mobile network switches frequently, the delay from reconnecting may matter more than sustained throughput. There is no repeatable basis for claiming that one protocol is always fastest; compare them on the same device, network, and task.

Battery use depends mainly on how the connection is used

Battery use cannot be ranked by protocol name alone. Cellular radio wake-ups, repeated retries on a weak signal, many short connections, overly frequent keepalives, and continuous background transfers can all increase power use. A connection with a heavier handshake but reliable reuse may use less power than a lightweight connection that repeatedly fails and reconnects. Device heat should also be assessed alongside screen brightness, app workload, and charging status; timing alone does not prove the client caused it.

To compare battery use, start with a representative task, such as playing the same length of video or browsing the same documents, then check activity time and background behavior in the system battery settings. Do not run Connectivity Test continuously in one trial while leaving the other idle. Results from different signal conditions are hard to compare. If power use seems unusually high, first check for repeated failed connections, subscription update retries, and On Demand repeatedly triggering connections.

Check protocol capabilities across the entire path

A protocol that supports UDP does not guarantee that the current server, transport setup, and destination can carry UDP. The client entry, server settings, UDP reachability on the network, and outbound policy must all allow it. Conversely, opening a website does not prove UDP works; the site may use only TCP. When reporting a problem, specify the transport used by the affected task rather than simply saying “the network works” or “the protocol is broken.”

The iOS discussion here describes trade-offs on mobile devices; it does not mean other platforms lack these protocol capabilities. Use the current Shadowrocket interface and server configuration as the source of truth for specific fields. Installation and download options for all platforms are on the Download Shadowrocket page. This guide does not repeat installation steps or infer unverified compatibility from a device model.

02 / SHADOWSOCKS

Shadowsocks: shared credentials and encryption methods

Design and limits

Shadowsocks uses credentials and an agreed encryption method to exchange proxied data between the client and server. Its core design is relatively straightforward, but it is not a general-purpose container whose underlying fields can be swapped at will. Both sides must use the same protocol format and encryption method. The key is not memorizing the name: make sure the type, server, port, password, and encryption method in your subscription all belong to the same entry.

Newer authenticated encryption designs protect both confidentiality and integrity, addressing the risks of encryption without reliable authentication. Key formats can vary between generations and extensions, so an ordinary password cannot be pasted into every method. Seeing a method in the client list means the client offers that option; it does not mean your server has enabled it. Use the complete combination provided by your service provider, and do not change the encryption method just to use a newer-sounding option.

How Server, Port, Password, and Method fit together

Server is the proxy server address, which can be a domain name or IP address. Port is the port the server listens on, not the destination website's port. Password is used with the selected encryption method to determine authentication or key material. It is case-sensitive, and trailing spaces can affect the result. Method must match the server. A mismatch may allow the underlying connection to establish but produce no valid response, rather than showing a clear “method mismatch” error.

If an imported entry is present but cannot connect, compare these four fields against the original details one by one. Watch for full-width punctuation, line breaks, truncation, or using an admin page port instead of the proxy port. If the configuration requires an encoded key, preserve its original encoding; do not recalculate it or remove characters. The subscription display name is only a label: a region or protocol in the name does not prove the underlying fields are correct.

Additional settings are not required by default

Some Shadowsocks entries include additional transport or extension settings. These are not performance enhancements to enable just because a toggle is available; they may be required by the server. If the original subscription does not include them, do not copy them from another entry. Paths, host names, and extra authentication details are often specific to a particular deployment. An incorrect value can make an entry fail even when the server and password are correct.

When creating an entry manually, start with the minimum fields explicitly required by the server and test the connection. Add extensions only when needed, following the original details field by field. If an existing subscription works, there is no need to re-enter it manually to “optimize” it. If an update restores a field, the subscription still manages that entry; check the source configuration instead of repeatedly editing an auto-updating entry. Keeping a separate, clearly labeled test entry makes comparison and rollback easier.

Assessing whether it fits on iOS

With a stable signal and sufficient server capacity, Shadowsocks' relatively direct data path can help limit overhead, but that does not guarantee faster downloads. Consider whether the existing service is stable, whether UDP is needed, whether the workload uses many short connections, and how much packet loss the network has. Encryption methods can have different computational costs, but for most everyday tasks, network latency and server load are more useful things to check first.

If standby battery use increases, first check for repeated reconnects, background app sync, or UDP keepalives rather than immediately changing the encryption method. If one task fails while others work, investigate the destination and transport: the cause may be a routing rule, destination resolution, or a server-side egress restriction, not Shadowsocks itself. For a working configuration, keeping its complete settings is usually more reliable than assembling a different transport combination yourself.

03 / VMESS & VLESS

VMess and VLESS: authentication and transport are separate

Similar fields do not mean the protocols are interchangeable

VMess combines user authentication with proxy message framing and has its own data protection mechanisms. VLESS focuses on lightweight authentication and forwarding, and typically relies on an external security layer to protect transport. Both may use a UUID and similar transport options, but their on-the-wire message formats are different. Copying a UUID from a VMess entry into a VLESS entry will not make the server compatible; the client Type must match the server's actual configuration.

This evolution reflects an important trade-off: separating authentication, encryption, and transport can avoid some duplicated work, but it also makes correct combination settings your responsibility. VLESS's lightweight design does not mean an unprotected connection is confidential. VMess's built-in protection does not mean an outer TLS layer can go unchecked. To assess the security boundaries, ask separately who authenticates the user, who verifies the server, and which layer protects the data. A protocol name alone is not the whole answer.

UUID, Security, and time requirements

The UUID identifies the user and must match exactly. Similar-looking values are not interchangeable; preserve every character and separator when copying. Set VMess fields such as Security according to the server details. Some older configurations include legacy compatibility fields, so do not fill every entry with the same value based on habit. Options related to data encryption in VLESS should not be interpreted as if they were VMess settings; the same English term can refer to different layers in different protocols.

Some parts of VMess authentication are sensitive to clock differences between the client and server. If the settings appear correct but authentication fails, check that automatic date and time are enabled on the device, and ask your provider to check the server clock. Changing the displayed time zone does not correct the actual time, and there is no need to change the device's region to connect. If the time is correct and the failure persists, check the protocol, credentials, and transport rather than repeatedly changing time settings.

WebSocket, gRPC, and TCP compared

TCP provides a reliable byte stream that protocol messages can use directly. WebSocket adds a message channel established through an HTTP handshake. gRPC usually runs on HTTP/2 and has its own service and stream semantics. The choice is not simply a client-side performance preference; it depends on how the server listens and what intermediate forwarding supports. If the server accepts only WebSocket, changing the client to TCP will not let you keep using the service with less overhead.

Set WebSocket Path and Host using the details you were given. Path is the channel path, not the server address or subscription URL; its case, slashes, and suffixes can all affect matching. The gRPC service name must also match exactly; a website's home page path is not a substitute. With intermediate forwarding, the server address, HTTP Host, and TLS Server Name may serve different purposes. Check each one rather than forcing them all to the same value.

Handling TLS and special stream settings

In TLS, Server Name identifies the expected server and may affect which certificate the server presents. Certificate verification confirms that the peer matches that identity. This is a different stage from the HTTP Host field. If your provider gives you a separate Server Name, keep it even if Server is an IP address. ALPN is used to negotiate an application-layer protocol; change it only when the current transport and server requirements call for it.

Some VLESS combinations also require specific stream settings or additional handshake material. These are not universal speed-boost switches. Confirm that the current client interface supports the combination and that the original configuration includes all relevant fields. Do not fill in missing required values with those from another service entry. Successful import only means the text was recognized; it does not prove the server accepted the combination or that traffic is using the intended path.

Connection reuse and battery life on iOS

Additional HTTP channels and TLS handshakes add work when establishing a connection, but connection reuse can spread that cost across multiple requests. After a mobile network switch, an existing connection may fail and need to be re-established. If this happens often, pages may occasionally take longer to open even when sustained downloads are fast. Test new and long-lived connections separately instead of combining both experiences into a single speed score.

Multiplexing is not always beneficial. Sharing an outer connection can reduce repeated handshakes, but packet loss, queuing, or a reset on that connection can affect multiple tasks at once. Unless your server provider recommends otherwise, keep the imported settings and compare stability using the same task before making a change. For definitions of UUID and transport fields, see the Glossary. Similar interface labels do not prove compatibility.

04 / TLS & GENERAL PROXIES

Trojan, HTTP, and SOCKS5: where they differ

Trojan: password authentication over TLS

Trojan's typical design carries proxy authentication and forwarding over a TLS connection, using established TLS mechanisms to protect transport and verify server identity. Key client settings usually include server, port, password, and TLS details. The password checks whether the user is authorized to use the service; certificate verification checks whether the client connected to the intended server. They do different jobs, and a correct password cannot compensate for a certificate identity error.

If Server is an IP address but the certificate is issued to a domain, you will usually need to enter the correct Server Name from the original configuration. A reachable address does not mean identity verification should succeed. An expired certificate, an incomplete certificate chain, an incorrect device clock, or a certificate for a different site can all cause failures. Identify whether the error is authentication, TLS, or a network timeout, then check with your provider instead of changing ports at random.

An HTTP proxy is not the same as an HTTPS destination

HTTP proxies were originally designed to forward HTTP requests. When accessing an HTTPS destination, the client typically uses CONNECT to create a tunnel to the destination, then the app and website communicate over TLS. “The destination website uses HTTPS” and “the client-to-proxy connection uses TLS” are two different things. If the proxy endpoint itself uses plain HTTP, the fact that the destination uses HTTPS does not mean the proxy credentials and all metadata receive the same protection on the first leg.

If the current interface and server offer an HTTPS proxy endpoint, configure outer TLS using the corresponding type. Simply changing a plain HTTP port to a commonly used TLS port will not enable it. The username, password, authentication method, and server listener must match; some services also restrict which CONNECT destination ports are allowed. If some websites work and certain ports do not, check the server's permitted range before blaming DNS or rules. Record application-level denial responses separately from underlying connection timeouts.

SOCKS5: general-purpose proxy negotiation without built-in encryption

SOCKS5 provides a general-purpose way to negotiate a proxy connection and specify the destination. Depending on the server, it can use username and password authentication. The protocol itself does not provide transport encryption equivalent to TLS. Username and password authentication controls access; it does not create a confidential channel. Whether SOCKS5 fits your situation depends on the network, any external protection layer, and the server deployment. Fewer fields do not automatically mean simpler security boundaries.

SOCKS5 defines a UDP association mechanism, but using it also depends on client support, server configuration, and the network path. Opening a website through SOCKS5 mainly shows that a type of TCP request succeeded; it does not prove that games, voice calls, or other UDP traffic will work. If the server forwards TCP only, treat that as a service limitation rather than repeatedly changing the client's UDP options. A client switch cannot add capabilities the server does not have.

Where resolution happens must be assessed separately

HTTP CONNECT and SOCKS5 can both represent a destination as a domain name, but where that name is ultimately resolved depends on client behavior, routing requirements, and server implementation. If the client resolves locally to match an IP-based rule, handing the domain to the proxy afterward does not mean all resolution happened remotely. Consider server address resolution, destination resolution, and rule-triggered resolution separately; do not reduce the whole process to a single “remote DNS” label.

On iOS, perceived differences among these protocols often come down to whether they add a TLS handshake, whether connections are reused, server distance, and actual load. HTTP and SOCKS5 having fewer fields does not mean they necessarily use less battery; Trojan using TLS does not mean it necessarily uses significantly more. When the connection is stable, the workload may matter more than the protocol. Check that identity verification is correct during testing; do not weaken the required protection just to avoid a handshake.

Choose based on the actual type of service you have. If your provider offers Trojan, keep its authentication and TLS settings. If it offers HTTP or SOCKS5 on a controlled network, first confirm the endpoint's trust boundary and purpose. Do not treat the three as interchangeable options for the same server entry. For basic setup questions, see Frequently Asked Questions. For a specific certificate or authentication failure, share the error details after removing credentials.

05 / WIREGUARD

WireGuard: key-based identity and IP tunnels

A different model from application proxies

WireGuard is designed as an encrypted IP tunnel. It identifies peers using public keys and primarily uses UDP for transport. It handles IP packets inside the tunnel rather than negotiating only a particular destination connection like a general-purpose application proxy. Addresses, routing ranges, and peer keys are therefore central to its configuration. Applying the proxy model of “password, server, port” directly can leave out the local tunnel address and the destination ranges permitted through the peer.

When using a WireGuard entry in Shadowrocket, distinguish client traffic selection from the routes allowed by the WireGuard peer. The first determines which traffic uses the entry; the second determines whether packets sent through the tunnel fall within the peer's permitted range. Both layers must be correct for traffic to work. A WireGuard entry that completes a handshake does not guarantee that every destination is reachable, nor does it automatically replace existing routing rules.

Private Key, Public Key, and pre-shared keys

Private Key is the secret for the local identity; Public Key identifies the peer. The peer Public Key entered in the client must come from the server, not from the client's own key pair. The server must also know the client's public key. If the configuration includes a pre-shared key, it is additional material agreed on by both sides and must not be used in place of Private Key. Keys can look similar, but their roles differ. Use the original field names, not string length, to identify them when copying.

Do not post a complete configuration containing Private Key in screenshots, logs, or public discussions. For troubleshooting, you can say whether both sides used the same configuration and whether the peer has the client's public key registered; you do not need to share the actual values. Generating a new local key changes the client's identity. Unless the server registers the new key, it will not grant access automatically. Check the key pairing first instead of treating repeated key generation as a general fix.

Endpoint, Address, and Allowed IPs

Endpoint is the peer's externally reachable address and port. Address is the local address assigned inside the tunnel; the two are not interchangeable. Allowed IPs describes the address ranges routed through that peer and, in common implementations, also helps select peers and constrain incoming addresses. A range that is too narrow may leave some internal resources unreachable. A range that is too broad does not mean the server can forward traffic to every destination. Keep the values from the provided configuration rather than broadening them based on an assumption about global connectivity.

If the handshake succeeds but traffic does not, check for a conflicting tunnel address, whether the destination falls within the allowed range, and whether the server has forwarding and return routes. If internal IP addresses work but domain names fail, check DNS next. If only one subnet fails, the cause may be routing or permissions on the destination side. A connected status confirms only one layer; it does not replace checking addresses and server egress. Separating the layers is more useful than looking only at whether a switch is on.

MTU, keepalives, and mobile network changes

MTU sets the maximum packet size inside the tunnel. Encapsulation adds overhead. If the actual path cannot carry packets of that size and path feedback does not work correctly, small requests may succeed while large pages or transfers stall. Do not treat an arbitrary smaller value as universally optimal. Adjust it based on server recommendations and observed symptoms, and record the original value. If lowering the MTU fixes only one type of problem, investigate the bottleneck further rather than assuming every connection needs the same setting.

A keepalive such as Persistent Keepalive can help maintain certain NAT mappings; it is not a bandwidth-boosting option. Mobile networks may reclaim idle mappings quickly, but more frequent keepalives also increase transmissions and radio activity. Decide whether one is needed based on how the server is accessed, what happens after idle time, and the original configuration. If idle connections do not drop, there is no need to shorten the interval just to “stay online,” and continuous handshake tests are not a battery-saving setting.

WireGuard's handling of address changes can help in some mobile scenarios, but it cannot guarantee uninterrupted service when switching between Wi-Fi and cellular. The UDP path, system network extension state, and destination session may still change. Test whether new requests recover and whether existing tasks need to reconnect. If an existing call drops but a new webpage loads, record it as a session continuity issue rather than concluding that the whole tunnel is unusable.

06 / HYSTERIA2

Hysteria2: UDP paths and congestion control

Why use QUIC-based transport

Hysteria2 uses a transport design based on QUIC, which usually runs over UDP and integrates reliable streams, encrypted handshakes, and connection management. One design goal is to manage transport across networks of varying quality; it is not simply a matter of replacing TCP packets with UDP to get an automatic speed boost. UDP provides the underlying transport, while reliability, congestion control, and mapping application traffic are handled by the upper layer. “Uses UDP” does not mean there are no retransmissions or no impact from packet loss.

Compared with multiplexing over a single TCP connection, QUIC can maintain more independent delivery state for different streams at the transport layer, reducing direct blocking of other streams when one loses packets. However, they still share link bandwidth, congestion, and device resources, so heavy traffic on one connection can affect other tasks. The actual benefit depends on network conditions, server settings, and workload; not every webpage, download, or interactive task will improve by the same amount.

Server, authentication, and TLS identity

The Hysteria2 server address, port, authentication details, and TLS settings must all come from the same configuration. The authentication string proves user access; TLS identity verification confirms the peer. Neither can replace the other. If Server is an IP address and Server Name is a domain, preserve that distinction as provided. For certificate errors, check the domain, validity period, and device time. Do not leave verification disabled just to measure throughput; that would compare different security conditions.

Some deployments also require additional transport settings or obfuscation-related fields. Both sides must use matching values, and a missing value may not be equivalent to an empty string. Do not assume Hysteria2 and similarly named protocol generations are interchangeable because their fields look alike; confirm the imported type matches the protocol actually used by the server. If manual entry gets no response at all, check whether the current network can reach the required UDP port as well as verifying the password.

Bandwidth settings are not speed guarantees

Some configurations provide upload and download bandwidth settings to estimate or constrain a congestion control mode. Higher values are not automatically better, and they do not represent a fixed rate the server will allocate to you. Entering values far above your actual connection capacity can cause queuing, packet loss, and contention. A download may briefly appear faster while interactive tasks feel worse. Understand how the current mode uses these settings and follow the server's recommendations rather than copying values from someone with a faster network.

Check the units, too. Bandwidth is not the same as bytes transferred per second; do not guess the required unit based on how a download app displays speed. Upload congestion can also affect downloads because requests, acknowledgements, and control messages need to be sent. If a download starts fast and latency then rises noticeably, check for persistent queuing on the local link as well as server load. Do not respond by only increasing the download setting.

Balancing speed and battery life on iOS

On a link with some packet loss or latency variation, suitable congestion control may improve sustained transfers; on a high-quality, low-latency network, the benefit may be small. A transport that actively uses the link can also increase data processing and radio activity, so high throughput does not automatically mean good energy efficiency. If battery life matters, compare the total time to complete the same task, background transfers, and device temperature rather than a momentary peak speed.

For voice, interactive apps, or remote access, focus on jitter, dropouts, and queuing rather than download speed alone. Do not let a large file transfer interfere with an interactive test unless you are specifically testing that concurrent workload. After switching between Wi-Fi and cellular, check UDP reachability again. Good results on one network do not prove that another has the same packet size limits, NAT behavior, or idle connection lifetime.

Fit the conditions you have; do not replace every protocol

Hysteria2 is worth comparing when the server explicitly offers it, the current path allows UDP, and the problem is genuinely related to link quality or congestion. If an existing TCP-based connection is already stable, switching is not necessary. If a task fails because a rule sends it to the wrong policy or DNS returns an unreachable address, changing to Hysteria2 will not fix the rules automatically. First establish that the problem is at the transport layer, then assess the protocol's actual benefits.

When recording test results, note the network, task, whether the bandwidth settings were left unchanged, and any reconnects or background activity. A note that says only “fast” or “slow” cannot be reproduced when conditions change. Keep the original entry and give test entries separate names. When the subscription updates, check what changed so you do not mistake updated settings for a sudden change in protocol performance.

07 / ROUTING & DNS

Where Global Routing, DNS, and protocols meet

First verify that traffic is using the selected protocol

Global Routing controls how traffic is routed overall; it does not turn one protocol into another. Config applies rules from the current configuration. Proxy routes eligible traffic through a proxy path. Direct connects without a proxy. Distinguish interface labels from rule policies: Proxy is an interface mode, while PROXY can be a policy name in a rule. They are related but not the same field; similar spelling alone does not reveal the path a request actually takes.

Before testing a protocol, confirm that the intended entry is selected, then check which rule matches the relevant request and its final policy. A website opening directly under Config does not prove that the selected proxy entry works. A failure under Proxy does not immediately prove the protocol settings are wrong; the server's egress or the destination may be at fault. Direct can help determine whether the destination is reachable on the local network, but that result applies only to current network conditions and is not a permanent verdict on every connection.

Keep the three types of DNS resolution separate

First, the proxy server address may need to be resolved. If Server is a domain name, the client must know how to find it before connecting to the proxy. Second, the destination domain may be resolved locally or passed to the remote side as a domain, depending on the protocol and settings. Third, rule matching may require resolution: some IP-based rules need an address first. These happen at different times and do not necessarily use the same path.

So when saying “DNS works,” specify which kind. Resolving the server domain does not mean the destination website can be resolved, and resolving the destination does not mean its address is reachable from the current egress. If only IPv6 destinations fail, check IPv6 support on the current network and egress instead of immediately disabling all DNS features. If an IP address works but a domain does not, focus first on resolution and identity settings. Also remember that an HTTPS destination may rely on its domain identity, so entering its IP is not an equivalent test of the full service.

Rule order changes what you observe

Rules are generally processed from top to bottom, and the first match determines the policy. DOMAIN-SUFFIX matches domain suffixes; GEOIP checks an address against a location database; FINAL handles requests that did not match earlier rules. The snippet below illustrates order; it is not a recommendation to replace your current configuration. PROXY must have a valid meaning in the actual configuration, and the example domain is for illustration only, not a service you need to visit.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

This snippet checks the domain suffix first, then the address location, and finally uses the fallback. Moving FINAL earlier prevents later rules from having the intended effect. If a destination that should use a proxy matches DIRECT first, the protocol test will bypass the proxy. DOMAIN and DOMAIN-SUFFIX are not interchangeable: the former matches an exact domain, while the latter covers a suffix range. For more detail on rule syntax and order, see Custom rule order and FINAL.

A config file is not a subscription entry

A subscription mainly provides server entries and their settings; a config file can affect rules, DNS, and other handling. Importing a new entry does not rewrite rules just because the protocol name changed if you are still using the old config. Conversely, replacing the config can change the connection path even if the server stays the same. Before recording a problem, check whether each part was updated so you do not mistakenly attribute a rule change made that day to a protocol.

After editing a .conf file, make sure it is saved, select the intended config, and reapply the relevant state as prompted by the interface. Keep the original config while testing so production use does not get mixed up with experimental changes. For file structure, see General, Rule, Host, and URL Rewrite sections explained. For subscription import options, see Subscribe and other import options.

Check On Demand separately from protocol connection status

On Demand uses system conditions to decide when to attempt a connection; it does not fix authentication, certificates, or server reachability. If connection attempts keep occurring during network changes, check the trigger conditions separately from the protocol's reconnect results. Temporarily disabling the trigger and testing manually can help distinguish repeated system-initiated attempts from a failure in an individual connection. Restore the original setting after testing so required connection conditions are not forgotten.

A useful final record includes the current Global Routing mode, config name, selected entry, destination and matching policy, and whether DNS or UDP was involved. This helps explain why the same entry behaves differently on two devices. An enabled client switch indicates only that the network extension is in some running state. The route, resolution location, and protocol for a request still depend on the current config and connection.

08 / SELECTION & DIAGNOSIS

Choosing a protocol and troubleshooting layer by layer

Choose in order: check compatibility before performance preferences

First, list the protocols and complete settings the service actually provides; do not start by picking a name that sounds fast. Second, check whether the current network allows the required transport, such as whether UDP is reachable. Third, consider the task: for short browsing sessions, look at initial response time; for sustained downloads, look at stable throughput; for calls and interactive use, look at jitter and interruptions; for internal resources, check address and routing ranges. Comparing performance is meaningful only after the first two checks pass.

If the provider offers only one protocol, the client cannot turn it into another. If multiple entries are available, they may use different servers or have different loads, so their performance differences cannot all be attributed to the protocol. For a more reliable comparison, keep server location and network conditions as similar as possible and record any variables that could not be held constant. For most users, a complete, stable setup that meets the task's needs is easier to maintain than an unfamiliar transport combination.

Work from reachability up to the application layer; do not skip steps

If a connection cannot be established at all, first check Server, Port, the current network, and whether the server is listening. A domain resolution failure points to an endpoint issue; an underlying timeout points more toward the path or listener. Re-entering a UUID is unlikely to help. If the network connection is established but authentication fails, check the password, UUID, key pairing, and time conditions. If the error points to TLS, focus on Server Name, the certificate, and device time. Do not change DNS and routing at the same time to mask the problem.

If authentication succeeds but the task still fails, check the next layer: transport settings, destination address, and server forwarding. WebSocket Path, gRPC service name, special stream settings, or WireGuard routing ranges can block traffic even after the basic connection works. If only some destinations fail, check the matching rule, destination resolution, and server egress. If only UDP tasks fail, check UDP at the client, server, and network layers instead of using a website test to claim that “everything works.”

If it works briefly and then disconnects, focus on state changes

A connection that fails after being idle may involve NAT mappings, keepalives, or server idle policies. If it fails after switching from Wi-Fi to cellular, check whether the old connection was re-established, whether the UDP path changed, and whether On Demand triggered. If large requests stall while small ones work, consider MTU and path feedback. If failures occur only under heavy load, check queuing, bandwidth estimates, device resources, and server load. Specific symptoms are more useful for diagnosis than saying “it always disconnects.”

Do not change keepalive, MTU, multiplexing, and bandwidth settings all at once. Record the original values, change only the setting most relevant to the symptom, repeat the same task, and then revert or keep the change. If it does not help, undo it rather than layering on more experimental values. For subscription-managed entries, remember that updates may overwrite changes. You can duplicate an entry for testing and label its purpose clearly, so you can tell whether settings changed manually or at the source.

Compare tasks to diagnose battery use; do not guess from protocol names

If reducing battery use is the priority, first check continuous background activity, failed retries, keepalive frequency, and wireless signal before comparing protocols. Keep screen use, task duration, and network conditions as similar as possible; do not run one trial while charging and another at low battery. System battery statistics can offer clues, but short-term percentage changes are affected by temperature and estimation. Compare results across repeated tasks. A faster download that finishes sooner may use less total activity time than prolonged low-speed retries.

There is no need to send continuous probes during an idle battery test; doing so changes the state you are trying to observe. If background activity associated with the client increases, check whether another app is continuously transferring data over the connection and whether rules are sending frequently used tasks that could connect directly through a longer route. Correcting the traffic path may help more than changing protocols. Any rule change should still fit the actual use case; do not remove connections needed for work just to improve battery statistics.

Keep a configuration you can explain after testing

Your final choice should answer three questions: why it is compatible with the server, why it suits the current task, and how to recover if it fails. Keep a verified configuration and note where its required settings came from and which networks it suits. Remove test changes you have confirmed do not work. Do not leave certificate verification disabled, ranges temporarily broadened, or extreme bandwidth values in daily settings. If a setting must differ from the original configuration, record why and check its limits with your provider.

To return to the setup steps, continue with Getting Started with Shadowrocket. To check where to get the app, visit the Download Shadowrocket page. Mac has separate Apple Silicon and Intel versions; the download page also explains system requirements for other desktop and Android installations. This guide does not recommend one protocol as the default choice. It helps you make each choice against verifiable requirements and identify a clear next step when something fails.