Shadowrocket Protocol Guide

Before You Choose: Protocol, Transport and Routing Layers

Choosing a protocol in Shadowrocket means matching the communication method used by your server—not adding a speed label to the same connection. If the server accepts only one protocol, the client must use that type. Changing the type in Add Server does not give the server new capabilities. Imported subscription entries usually include these details already. Before editing one manually, keep the original so a problem you could have checked does not turn into several changing settings at once.

A Connection Has Several Distinct Layers

Read connection details in four layers: the address and port specify where to connect; the protocol and authentication specify how the other end identifies the connection; transport and encryption specify how data is delivered; routing rules determine which requests use that entry. These layers are related but not interchangeable. A correct password does not mean the certificate is valid; a valid certificate does not mean the server accepts the account; and a rule pointing to PROXY does not mean the selected server is available. This layered view explains why “connected, but webpages won't load” can have several causes.

A protocol name does not always describe the full transport. VMess and VLESS can use different transport configurations; Trojan is commonly used with TLS; Hysteria2 uses QUIC-based transport; WireGuard creates a network-layer tunnel. If fields such as WebSocket, Host, Path or SNI appear, check the outer transport settings too. Do not infer these values from the protocol name or copy them from another entry just because they look similar.

Check the Conditions Before Comparing Performance

Your options are limited to configurations that both your existing server provides and the client supports. If you have only one working entry, focus on entering its details correctly and verifying it—not on finding a newer-sounding protocol. If several entries are available, keep the local network, destination and test method constant, then compare connection success, time to first content, sustained transfer and background behavior. Server location, load, bandwidth and intermediary networks can outweigh protocol differences, so tests across different servers cannot isolate the protocol's effect.

Security also needs to be assessed layer by layer. An encrypted protocol connection does not mean every destination app can ignore its own security requirements; HTTPS on the destination site still provides end-to-end authentication. Conversely, a plain HTTP or SOCKS5 connection does not automatically encrypt the client-to-proxy link. Distinguish the proxy connection, destination website and domain resolution, and check what protects each leg instead of relying on a lock icon or protocol name.

Global Routing Does Not Change the Protocol

In Global Routing, Config, Proxy and Direct are traffic policies. Config processes requests according to configuration rules; Proxy handles traffic in proxy mode; Direct connects directly. Changing these options will not turn Shadowsocks into Trojan or fix missing authentication fields. For troubleshooting, use an appropriate mode to isolate rule-related issues, then restore your usual configuration so temporary settings are not left in place. See the guide to routing rules for the steps.

This reference covers compatibility and design trade-offs; it does not rank protocols universally. A protocol may improve how data travels under certain network conditions, but it cannot increase the server's actual bandwidth or fix a weak wireless signal or invalid account. Treat “Can the connection be established correctly?” and “Does it meet the needs of this task?” as separate questions. That distinction gives the settings in each chapter a clear purpose.

Shadowsocks: Encryption and Configuration Limits

Shadowsocks is designed as a relatively lightweight proxy protocol. It uses shared authentication and encryption details to handle data between the client and server. It is not a remote network interface, nor does it require the client to route all traffic through the server's network. The key details are usually the server address, port, encryption method and password. Each must match exactly; having the right address and password does not mean you can choose a different encryption method.

The Encryption Method Is Not a Preference to Change

Different methods use different data formats and key-handling schemes. Common authenticated encryption designs also check that data has not been tampered with, rather than merely hiding its contents. Use the method specified by the server. Some newer methods require a particular key format and cannot be treated like ordinary short passwords. If the original details provide an encoded string, preserve it exactly, including capitalization, symbols and the final character. Do not rewrite it for convenience or add spaces or quotation marks.

Importing from a link can reduce typing errors, but the link's appearance is no substitute for checking the imported details. Verify the protocol type, address, port and method against your existing information. If a link cannot be recognized, first check that it is complete and whether it uses an extension requiring additional support. Do not copy only the portion visible in a browser or mistake the display name for an authentication field. An entry name is just a label and usually does not affect server authentication.

TCP and UDP Must Be Checked Separately

Web connections usually rely on reliable transport, while real-time communication and some apps may also use UDP. Whether Shadowsocks can handle the relevant traffic depends on the client settings, server support and intermediate networks. If webpages work but a real-time feature does not, do not immediately assume the password is wrong. Check which transport the feature uses, whether the server enables the relevant forwarding, and whether the local network permits that traffic. A successful webpage visit proves only that the path used for that visit worked.

Some configurations include additional transport or plugin parameters. These are part of a particular server deployment, not requirements for every Shadowsocks entry. An address, port and password alone may not be enough to reproduce a connection that uses an extension. If the current interface has no matching field, check compatibility with the configuration source instead of forcing the value into a similarly named field. Protocol support and extension support are separate; a successful import does not guarantee that every extension is being used.

Understanding Efficiency on iPhone

A streamlined protocol can reduce processing overhead, but that does not mean it is always faster or more battery-efficient. The efficiency of the encryption algorithm, server capacity, connection count and wireless retransmissions all affect results. Browsing pages and transferring files continuously are different workloads: the former depends more on connection setup and small-request response times; the latter depends more on sustained throughput. A single large-file test can miss how repeated connections in everyday apps actually feel.

For battery use, a small number of stable connections can make a bigger difference than the encryption overhead between two correctly configured protocols. If background usage changes noticeably, first check whether the entry keeps timing out, whether On Demand triggers it repeatedly, and whether the connection recovers after a network change. Few Shadowsocks settings do not mean background activity has no cost, and not all network activity recorded by the system is caused by the protocol itself.

Keep troubleshooting straightforward: check that the original entry has not expired, verify the method and password, then check the server endpoint and local network, and finally look at routing and resolution differences. Do not change the method, port and DNS all at once after a failed test. Even if the connection recovers, you will not know why. Keep a confirmed reference so you can tell whether a later subscription update changed the server details or a local edit introduced a discrepancy.

VMess and VLESS: Separate Authentication from Transport

VMess and VLESS both appear in server configurations that combine different transport options, but they are not two names for the same protocol. VMess defines its own authentication and data-handling methods; VLESS focuses more narrowly on identity and request details, relying on the security layer configured alongside it. Both may use a UUID, but a matching UUID alone does not make them interchangeable. The server's protocol type, transport and security settings must all match the client.

Why Protocol and Transport Are Separate

These protocols emerged to support different transport combinations and deployment setups. An entry may describe not only who is connecting, but also how the connection reaches the server through the outer transport. Two entries labeled VLESS can use completely different outer transports. For WebSocket, check Host and Path as well; for TLS, check the certificate identity settings. A mismatch at any layer can end the connection before authentication even begins.

A UUID is an identity, not a website address or a device name to choose freely. Copy the existing value exactly; do not change its separators or replace it with the value from another entry. VMess authentication also depends on time, so if the device clock is clearly wrong, restore automatic time settings and test again. Clock errors can also affect TLS certificate validity checks, so this is not exclusive to VMess, but it is especially worth checking for these entries.

Handling VMess Compatibility Details

Older configurations may include additional authentication compatibility fields, while newer ones may use different authentication conventions. Do not treat a fixed value from an old guide as the default for every server, or modify a working entry to make it seem more modern. Prefer complete details from the current server. If imported and manually entered results differ, compare the actual fields, not their display names. Ask the configuration provider to explain any option you cannot verify.

Do not confuse VMess data protection with outer TLS. Whether an outer layer is present, how certificate verification works and whether traffic passes through an intermediary are separate deployment conditions. Some errors appear during authentication; others occur during the handshake or path matching. If diagnostics identify the failing stage, check the fields for that stage first. If not, narrow it down layer by layer—address, transport, certificate, authentication—instead of randomly switching encryption options.

What VLESS's Streamlined Design Means

VLESS should not be understood as providing complete link encryption by itself. It leaves some responsibilities to other layers, making the outer security configuration especially important. If the server details specify TLS or another supported security method, configure that combination in the client. Keeping only the UUID and port does not recreate the full connection. If additional fields such as Flow are present, confirm that both the current client and server support the same combination; similar names do not prove compatibility.

Host, SNI and the server address may all contain the same domain, but they serve different purposes. The server address determines where the network connection goes; SNI identifies the requested service during the TLS handshake; Host may route an outer request. Path may determine which handler receives a WebSocket request. In a multi-layer forwarding setup, these values do not have to match. Do not make them all equal to the server domain; follow the purpose of each field in the original configuration.

Performance Depends on the Full Configuration

Direct transport, WebSocket and additional security handshakes can have different connection setup costs, but a stable connection amortizes one-time overhead. Tasks with many small requests may therefore behave differently from long transfers. VLESS's streamlined design does not guarantee it will be faster end to end than VMess; server load, outer forwarding and the destination site may remain the main constraints. On iOS, compare the complete entries you actually use rather than estimating a fixed speed from protocol design.

If your existing details specify a transport combination, verify that combination before trying to optimize performance. Once connected, compare first access, repeat access and behavior after changing networks. Keep the original entry before adjusting security settings, and never disable certificate checks as a speed tweak. See the Glossary for related terms, but use your server's documentation and the options available in the current app as the authority for actual field values.

Trojan, HTTP and SOCKS5: Security Differences at the Proxy Endpoint

These protocols can all provide proxy access, but they handle security and authentication differently. Trojan carries proxy requests over a TLS connection and uses a corresponding password for authentication; HTTP proxy uses HTTP semantics to establish or forward connections; SOCKS5 provides a more general proxy request negotiation. First check which endpoint the server actually provides, then confirm whether the client-to-server connection is encrypted. The fact that all three can forward webpages does not make them interchangeable.

Trojan: Certificate Verification Is Part of the Connection

For Trojan, the address, port and password are only the basics; the TLS service name matters too. The server address may be a domain or IP, while the certificate is usually issued for a specific name. SNI indicates the requested service name during the TLS handshake; certificate verification then checks whether the peer's identity is as expected. They are related but not the same. Setting SNI does not automatically make a certificate trustworthy, and an arbitrary domain is not a universal value. Use the name specified in the server details.

An expired certificate, incorrect device time, name mismatch or incomplete intermediate certificate chain can all prevent a connection. Check the system time and original server details, and ask the server administrator to fix the certificate if needed. Options such as allowing insecure connections change the identity-verification boundary; they are not general compatibility or speed features. If disabling verification allows a connection, that only helps locate the verification stage. It does not resolve the underlying issue, and should not become a permanent setting.

Copy the password exactly as provided, checking for trailing line breaks or spaces. If the server also uses an additional transport wrapper, match its path and request parameters too; not every Trojan server uses the same connection setup. For a field-by-field explanation, see Trojan Password, SNI and TLS Settings. That article explains how to enter the values; it does not provide server details or replace the specific values in your configuration.

HTTP: Distinguish Proxy Access from Destination HTTPS

HTTP proxies are common in managed network environments. For an HTTPS destination, a proxy usually uses CONNECT to establish a tunnel to the destination, while the destination app still performs its own TLS verification. But a destination website using HTTPS does not automatically mean the client-to-proxy control connection is separately protected by TLS. If the server provides a TLS-enabled proxy endpoint, confirm that the entry type or security settings match it; do not assume that changing the port to a commonly used number is enough.

Proxy credentials are not the same as website login details. If authentication fails, first check whether a username is required, whether the password is correct and whether the account allows connections from the current source. Do not use credentials from a browser login page for proxy authentication unless the administrator explicitly says to. The capabilities of a plain HTTP proxy depend on its deployment; access to one webpage does not prove that it can handle all app traffic. Confirm separately if your task requires UDP.

SOCKS5: General-Purpose Forwarding Is Not Encryption by Default

SOCKS5 negotiates the destination address and request type, can support domain-name destinations, and defines authentication and UDP forwarding mechanisms. The protocol itself should not be treated as an encrypted tunnel. A particular deployment may restrict authentication methods, reachable destinations or UDP support; a feature works only when both client and server support it. The name SOCKS5 alone tells you neither which traffic the server permits nor what protection the connection uses.

Where a domain is resolved matters too. Even if the protocol can carry a domain name, the app or a local resolver may first translate it into an address. When troubleshooting, consider Shadowrocket's DNS and routing settings rather than assuming from the protocol description that every lookup happens remotely. If a site fails by name but responds by direct address, check the resolution result and which policy matched before replacing proxy credentials or treating everything as an authentication failure.

Choose based on the environment you already have. If your server provides Trojan, carefully check the certificate and password. If a managed network provides HTTP or SOCKS5, confirm its requirements and security boundaries first. Do not drop required TLS just to simplify the setup, or rewrite working entries in bulk to try more protocol names. On iPhone and iPad, a correct, stable connection is generally better for speed and battery use than repeatedly retrying a mismatched type.

WireGuard: Network Tunnels and Key Settings

WireGuard differs from the proxy-request protocols above: it carries network-layer data through an encrypted tunnel. Its relatively streamlined protocol uses a fixed cryptographic suite, reducing the number of negotiable options. You do not need to choose from many encryption methods, but you do need to handle the local interface, peer identity and routing scope correctly. Fewer fields do not eliminate the need for network planning; the addresses, keys and allowed ranges together determine what the tunnel can do.

The Roles of Private Key and Public Key

The local Private Key identifies and protects your device's identity; the Public Key identifies the corresponding peer. These values are related but cannot be swapped. When copying a configuration, do not put your Public Key in the peer identity field or use the peer's Public Key as your local Private Key. If the original details include an additional pre-shared key, both sides must use the same value. It is not a comment field or something to remove when the connection is unstable.

Your local private key is sensitive. When troubleshooting, you can note that it matches the original configuration without posting the complete value in a public discussion or screenshot. Changing the local private key usually requires the server to update the corresponding identity too; generating a new key only on the client will not make the original server accept it. If a device is lost or a configuration must be revoked, ask the existing server administrator to update peer authorization rather than simply changing the display name.

Endpoint, Address and Allowed IPs

Endpoint specifies the peer's reachable address and port; local Address specifies the address used inside the tunnel. They serve different purposes. Putting a public endpoint in the tunnel address field—or an internal tunnel address in the external server field—breaks the expected connection. The address family must also match the configuration: do not invent another address type when the supplied details include only one. The DNS field usually describes resolution settings; it does not replace the local interface address or server endpoint.

Allowed IPs defines the address ranges a peer can carry and also plays a part in WireGuard routing and source validation. In Shadowrocket's overall traffic flow, actual destinations must also be understood in conjunction with the app's traffic policies; Allowed IPs is not simply a website-domain rule. A range that is too narrow may keep some destinations out of the tunnel, while one that is too broad may conflict with the original network plan. Keep the ranges specified by the administrator; do not expand them arbitrarily to make everything work.

Keepalives and Recovery on Mobile Networks

WireGuard uses UDP, and network mappings may change when a mobile device switches between Wi-Fi and cellular. The protocol is designed to adapt to peer address changes, but recovery still depends on new traffic reaching the peer, the server accepting it and the local network permitting it. Persistent Keepalive can maintain certain network mappings when needed, but adds periodic traffic. No interval suits every network; follow the existing deployment requirements, then observe background activity and behavior after network changes.

Do not shorten the keepalive interval indefinitely in pursuit of stability. Even small periodic transfers can affect device sleep on a wireless network. If the connection is stable and does not need its mapping maintained, more keepalives may not help. Conversely, removing a keepalive required by the existing setup may cause the first request after a long idle period to fail. Test the setting against a specific problem, note whether recovery improves after idle periods, and weigh the cost against system battery usage.

MTU and Intermittent Failures

Tunnel encapsulation takes up space, so the maximum packet size supported along the path matters. An unsuitable MTU may let small requests through while larger transfers stall, or allow some sites to load while others keep waiting. These symptoms can also have other causes, so do not change the MTU at the first sign of a slowdown. Check the original value and server recommendations, rule out routing, resolution and signal issues, then change only this setting and keep a way to restore the original.

Verification should go beyond checking whether a handshake occurred. A handshake confirms that the peers completed one stage of communication; also check the destination networks, DNS and actual app requests. If there is a handshake but no working traffic, check the tunnel address, allowed ranges and server-side forwarding before rebuilding keys. This separates identity issues from network planning problems and avoids changing parts that are already correct.

Hysteria2: QUIC Transport and Bandwidth Settings

One design goal of Hysteria2 is to maintain useful transport performance on paths with packet loss, latency or fluctuations. It uses QUIC-based transport over UDP, together with corresponding authentication and security mechanisms. Handling variable conditions is a design goal, not a guarantee for every network. If the local network blocks the required UDP traffic or the server endpoint cannot be reached, changing the protocol name cannot bypass those basic reachability requirements.

Why UDP Does Not Mean Faster by Default

UDP itself does not provide reliable, ordered delivery, but higher-level protocols can implement reliable streams, retransmission and congestion control on top of it. Hysteria2's performance comes from its complete transport design, not from omitting all reliability mechanisms. Packet loss still needs handling, and servers still have bandwidth and processing limits. Higher throughput may also mean more data is actually sent. Compare both the time needed to complete a task and whether it noticeably affects other activity on the same network.

QUIC can provide multiple streams and reduce some forms of cross-stream blocking, but poor wireless signal, upstream congestion and changing paths still leave streams sharing limited network resources. Multiple streams do not mean an individual request is completely unaffected by others. Everyday browsing and continuous downloads also depend on different metrics: browsing may depend more on resolution and handshake time, while downloads rely more on sustained bandwidth. A single sustained-download speed does not tell you which configuration suits every task.

Check Authentication, SNI and Certificates

The address, port and authentication details determine whether a basic connection can be established; TLS settings determine whether the peer's identity is verified as expected. Keep the specified SNI value. For certificate problems, check the name, validity period and trust chain in order. QUIC does not remove the need to verify certificates. If another protocol works at the same server address, that proves only that a different endpoint is reachable—not that this UDP endpoint or its authentication is configured correctly.

Some servers also require additional obfuscation settings. These must match the server; enabling more is not inherently better. A connection failure alone does not show that an option is missing. Check your existing details for an explicit requirement. If the current client interface has no setting for an extension, confirm its support or use a configuration explicitly known to be compatible. Do not put an extension password in the regular authentication field or try combinations of similar-looking switches.

Bandwidth Fields Describe Conditions, Not Wishes

Upload and download bandwidth settings may affect transfer rates and congestion control; the result also depends on both sides' configuration and actual negotiation. Check the direction and units: upload is generally data sent from the client to the network, while download is the reverse. Bits and bytes are not the same unit. Use the server's instructions and your actual connection capacity rather than entering the largest possible value. An unrealistically high estimate can increase queueing and packet loss, slowing other interactive requests.

Available cellular bandwidth varies with signal, location and network load. Wi-Fi internet access also differs from the wireless link speed shown for a router. Do not use a single peak measurement as a long-term setting. If your existing details do not require a manual value, keep a reasonable default and first check how bandwidth is negotiated. After adjusting it, test both sustained and interactive tasks rather than relying on a momentary speed. Treat an improvement as meaningful only if it can be repeated under similar conditions.

Battery Use and Use Cases on iOS

If a task finishes sooner, the device may return to a lower activity state earlier. But sustained high traffic, retransmissions and connection maintenance also add processing and wireless costs. Both effects matter, so Hysteria2 cannot be classified as inherently battery-saving or battery-draining. For long transfers, note total completion time and temperature; for idle background use, watch for ongoing traffic or reconnects. Test each scenario separately to avoid conflating their results.

If your existing server provides Hysteria2 and the current network permits the required UDP traffic, include it in tests of your actual tasks. If it fails only on a particular network, check that network's conditions first; if it fails everywhere, revisit authentication, certificates and the server endpoint. See How to Troubleshoot Slow Speeds by Layer for more ways to isolate speed issues. Do not tune bandwidth settings before establishing a correct connection.

Speed and Battery Use: Make Comparisons Repeatable

Protocol design can explain potential overhead, but it cannot rank the experience on a particular iPhone. A single visit involves the local wireless network, domain resolution, proxy endpoint, server forwarding and destination service. Any one of these may be the bottleneck, and a connection test covers only its specific measurement path. Break speed issues down into connection setup, first response, sustained throughput and recovery after failure. Then choose what to measure based on the task instead of using one result to judge the entire path.

Hold Variables Constant to Make Comparisons Meaningful

Use the same device, network and destination, and compare confirmed working entries under similar conditions. Before testing, pause unrelated large transfers to avoid bandwidth use by photo sync, system updates or other apps. If two entries use different servers, record that difference: you are comparing two connection setups, not protocols in isolation. If the destination content may be cached, note that too; a later visit might be served from a different cache.

Do not run every diagnostic repeatedly at high frequency just to produce tidy data. Testing itself uses data, adds server load and changes the device's activity state. Reproduce the task first, then run a small number of targeted tests to fill in the gaps. If the first result looks unusual, repeat it under the same conditions, but do not keep only the best result. Successes, failures and network-change conditions are usually more useful for troubleshooting than a single peak value.

What a Connectivity Test Can Tell You

What a Connectivity Test tells you depends on its method and target. A normal result means the test path completed its intended steps at that time; it does not guarantee every site will work or that sustained bandwidth is sufficient. A timeout does not necessarily mean the server is completely unavailable: the test target, resolution, authentication or local network may be involved. Read test results alongside actual webpage or app requests instead of ranking protocols by the list alone.

If a page takes a long time to begin showing content, check resolution and the handshake first. If it starts quickly but stays slow, look at bandwidth, congestion and server load. If only one destination fails, check the matched rule, the destination's status and resolution differences. For a full elimination checklist, see Server Timeout and Connection Failure Checklist. The same symptom can originate at different layers; use tests to narrow the scope.

Interpret Battery Usage Alongside Activity

The iOS Battery Usage page records app-related activity over a period of time, and the percentage is affected by usage from other apps. It is not a power meter for an individual protocol. Higher client usage is unsurprising after substantial downloads, connection tests or background transfers. For a comparison, keep the task, duration, screen state and network conditions as similar as possible. Also note whether the device gets warm, whether repeated failures occur, and whether battery use happens during foreground activity or while idle in the background.

Wireless communication costs can change significantly with a weak signal; results on stable Wi-Fi and unreliable cellular networks are not directly comparable. Encryption has a cost, but wireless communication, sustained transfers and repeated wake-ups matter too in many mobile tasks. Preventing pointless reconnect loops often helps more than changing an algorithm field that already matches. Do not infer battery impact from the number of protocol settings, or promise a fixed improvement in battery life.

On Demand and Keepalives Are Not the Same

On Demand controls when a connection is triggered under certain conditions. Protocol keepalives are generally used to maintain an existing communication relationship or network mapping. On Demand cannot fix a server authentication error, and keepalives cannot replace correct on-demand rules. A failed entry repeatedly triggered by conditions may keep reconnecting; overly frequent keepalives may generate traffic while idle. Check the trigger conditions and post-connection behavior separately, without changing both sets of settings at once.

For background issues, see Troubleshooting On Demand and Background Battery Use. Choose based on your usual tasks: reliable access, recovery after network changes and reasonable idle behavior, then consider sustained speed. A configuration that excels at an occasional large transfer is not necessarily the best for everyday browsing. Keeping verified entries for different scenarios is more practical than insisting on one universal ranking.

Configuration and Verification: From Source Details to Everyday Config

Put the principles above into practice in five stages: save the original details, confirm the type, check the fields, verify the connection, and restore your routing rules. This chapter does not repeat every step in the initial setup; for the exact taps, see the Quick Start Guide. Use this section if you can already add an entry but are unsure whether an import is complete, whether a field can be left blank, or why the proxy connects while everyday routing still fails.

Check Imported Details Before Making Bulk Changes

When using your own Subscribe details, keep the original source and check that updated entries appear in the expected group. A display name does not confirm that the protocol or server is the same. Manually editing an entry generated by a subscription may also mean your changes are overwritten on the next update, so understand how it is managed. For tests, keep the original entry and create a clearly labeled test copy. Do not change addresses, ports or security options across an entire subscription group at once.

A subscription URL may contain access credentials. Treat it as sensitive even if it looks like an ordinary link. Do not include the full URL in public screenshots or error reports; use clearly fictional example values when describing its structure. You do not need to submit any real configuration for this guide. When checking details, verify the protocol type, authentication, outer transport and security fields, then look for copied line breaks, spaces or truncated values.

Choose a Troubleshooting Branch by Failure Stage

If the server endpoint cannot be reached, check the address, port and current network first. For a TLS or certificate error, check the time, name and trust chain. If the connection fails during authentication, check the password, UUID or key. If the connection is established but the destination will not load, look at DNS, routing rules, server forwarding and the destination's own status. Not every diagnostic will show a clear stage; this order helps prevent repeatedly changing a password when the error is plainly about a certificate.

If a problem occurs only on one network, use the same entry to test both networks. If it occurs only for one destination, keep the network fixed and test other destinations. Change one condition at a time so results can be checked. If system prompts and app logs conflict, first confirm the test time and which entry is currently selected. After several edits, similar-looking duplicate entries are easy to confuse; identify the entry by its fields and group, not by its position in the list.

Test Routing with a Short Rule, Not a Pile of Configuration

Once the protocol connection works, restore Global Routing to Config for everyday use. The short rules below are examples from a Shadowrocket configuration, included only to explain rule order and policy; they are not a complete configuration. The example domain is not a service recommendation. The effects of PROXY and DIRECT depend on the selected entry and current configuration. Do not append these lines to an unknown location and assume they are active; confirm in Config that the intended file is in use.

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

The first rule matches a domain suffix, the second matches a geographic IP condition, and the last provides a final policy for requests that did not match earlier rules. Rules are generally processed in order, so place more specific conditions where they will take effect as intended. FINAL,PROXY here illustrates the syntax; it does not mean every user should proxy all remaining traffic. If you want to handle only selected sites, define the final policy accordingly. See DOMAIN-SUFFIX Rules for Selected Sites.

Confirm when testing ends and how to restore settings

A complete verification should cover at least a real task, the matched rule, recovery after idle time and network changes you encounter regularly. You do not need to visit lots of unrelated destinations or run continuous tests just to prove a configuration is correct. Once your tasks work reliably, stop experimental changes, restore the necessary everyday policies and record the settings you kept. If a test fails, undo the last change and check the next likely cause instead of stacking temporary fixes.

When contacting your existing service provider or server administrator, share the protocol type, failure stage, network conditions and a redacted description of the error. Remove real passwords, private keys, complete subscription URLs and personal browsing details. For purchase, restoring a previous purchase or App Store compatibility, see the Restore a Previous Purchase Guide and its FAQ. Keep purchase-account questions separate from protocol authentication. Check the App Store page for system requirements and purchase availability.

This protocol reference helps identify the right layer to investigate; it is not an invitation to keep switching protocol names. Address and authentication establish access, the security layer verifies the peer, transport determines how data travels, and Config determines where requests go. Check each layer in that order to turn vague connection failures into specific, testable problems—and keep a clear, recoverable setup when a subscription updates or you change devices.