• Official User Manual
  • Features & Common Settings

Shadowrocket Features
Routing & Settings Guide

Start by choosing Global Routing, then check your servers and Config. The connection toggle, routing rules, DNS, and traffic statistics each cover a different part of the setup; one test result cannot confirm that the entire connection is working.

For iPhone and iPad. See the App Store listing for system requirements and compatibility.

Three Global Routing Modes

Global Routing determines how requests are routed. Check the current mode on Home, then choose Config, Proxy, or Direct. These modes correspond to configuration-based routing, proxy routing, and direct connections. Identify them by their English labels in the app. The selected mode and the connection toggle are separate: choosing Proxy does not establish a connection, and choosing Config does not confirm that a configuration file is enabled or working correctly.

Use Config for everyday rule-based routing. To check whether the selected server can handle a request, temporarily use Proxy for comparison. To see whether the current network can reach a destination directly, compare with Direct. Change one setting at a time and repeat the test with the same destination on the same network to identify whether the difference comes from the mode, rules, or server.

App label How it works and when to use it What to check
Config Routes requests according to the rules in the active Config. Use it when requests need to be routed directly, through a proxy, or rejected based on matching rules. Confirm the intended Config is selected, the rule order is correct, and matching rules point to the expected route.
Proxy Routes requests through the proxy. Use it to compare how the selected server handles a connection. Check the selected server, authentication, and transport settings. Don’t use this result to conclude that Config rules are working.
Direct Routes requests directly. Use it to check access over the current local network. Check the local network and DNS. A failed direct connection does not, by itself, indicate a server problem.

After comparing modes, restore your usual setting. Network behavior can also depend on the system, DNS, and connection state. Direct does not mean that every setting is disabled, and Proxy does not guarantee that every app request will succeed. A routing mode determines the route; it cannot fix incorrect credentials or an unavailable destination service.

Rule Types and Policies

In Config mode, routing rules use a request’s domain, address, or other available attributes to determine how it should be handled. In Config, check the active file and its rules. Read the matching conditions first, then the policy at the end: conditions specify which requests match, while policies specify what happens to them. Keep more specific rules above broader ones to prevent a broad condition from matching first.

Match by Domain or Address

DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain suffix; DOMAIN-KEYWORD matches a keyword in a domain. IP-CIDR and IP-CIDR6 specify address ranges, while GEOIP matches against address-location data. USER-AGENT depends on the corresponding information being present in a request, which cannot be assumed for every request. Choose rule types based on the request attributes actually available.

DIRECT, PROXY, and REJECT

DIRECT means connect directly, PROXY routes through a proxy, and REJECT blocks the request. If a Config uses custom policy names, check which server or policy group each one points to. FINAL handles requests that did not match any preceding rule; it is not the highest-priority rule. Changing FINAL can affect many requests that aren’t covered by a more specific rule.

DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT

These examples show syntax and rule order only; they are not a complete configuration suitable for every network. After adding a rule, test it against a specific destination and check whether it matched. If a domain rule does not work as expected, check whether the request uses an IP address, whether DNS returns the expected result, and whether an earlier rule matches first. See the DNS troubleshooting guide for details.

Subscribe and Server Management

Subscribe loads subscription details you already have; Add Server adds an individual server. Both options require valid information that you already hold. Get your subscription link from your service provider. When adding a server manually, the address, port, password, protocol, and transport settings must match the server configuration—don’t guess based on a name or common defaults.

On Home, open the add menu and select Add Server, then choose the matching Type based on the details you have. To import a subscription, select Subscribe, fill in the corresponding fields, check that the link is complete, then save and update. You can scan a code using Scan QR Code, but first verify its source and contents. After importing, return to Home, expand the relevant group, select a server, then run Connectivity Test and verify access to the services you need.

A server appearing in the list only means the client has loaded its details; it does not guarantee that the server can connect. If a subscription update fails, check whether the link has expired or been truncated, and whether the current network can reach its address. Avoid creating duplicate groups while trying different settings. Keeping existing entries can help with comparisons, but note which server you actually select so test results stay clear.

Importing a subscription is different from importing a Config file. A subscription is generally used to manage server entries, while a Config file contains rules and other settings. Confirm which type of information you have before choosing the corresponding import option. For update issues, see Troubleshooting Subscribe failures.

Protocols and Settings to Check

Shadowrocket supports multiple protocols, including Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. A protocol defines how the client and server exchange data; it is not a speed tier to choose by name. In Add Server, select the Type that matches the server, then fill in the required fields. Available options are shown in the app.

For TLS connections, check the server name, certificate, and related settings. SNI may differ from the connection address, so use the values in your existing configuration. Match identifiers and transport settings for protocols such as VMess and VLESS field by field. WireGuard has its own key and address format; don’t enter a password from another protocol in those fields. Two entries that look similar after import may still differ in transport or authentication settings.

Run Connectivity Test after setup, then check the services you actually need. If the test fails, compare the settings field by field instead of switching between multiple protocols. Don’t treat relaxed certificate checks as a general fix. If the certificate or server name does not match, verify the supplied details and server configuration first. Protocol settings can contain sensitive information; share only the error details needed for troubleshooting and redact authentication fields.

Config Files

Config organizes rules and related settings. Open Config to view local or remote configurations, select the file you want to use, then return to Home and set Global Routing to Config. Saving a file without enabling it—or leaving Global Routing in Proxy mode—does not test the file’s routing rules.

Before making changes, keep a copy of the current working configuration and note what you plan to adjust. If you only want to change how one domain is handled, edit only its rule and position; don’t change DNS, servers, and FINAL at the same time. Save and retest the same destination before moving on. This makes it easier to connect each change to its result and revert if needed.

A remote Config update may change rules or other settings. Whether manual changes are retained depends on the configuration source and update method. Don’t post a complete file containing private authentication details in a public discussion, and don’t judge its contents by the filename alone. Read configurations whose source or purpose is unclear before enabling them. A rule syntax example is not a complete, ready-to-use configuration.

On Demand Connections

On Demand triggers connection behavior based on configured network conditions. It is separate from Config rules, which route individual requests. On Demand determines when to attempt a connection; Config determines how requests are handled once connected. To manage connections based on Wi-Fi, cellular, or other network conditions, check the available options under On Demand in Settings.

First confirm that a manually started connection works, then configure On Demand. Set the network conditions you need using the options available in the app, save, and test on the corresponding network. Start with one reproducible condition, such as a specific network change, and check the result before adding others. Don’t rely on automatic triggers to troubleshoot a connection that has not yet worked manually.

If a connection starts again after you turn it off manually, check the On Demand conditions instead of repeatedly restarting the app. When testing is complete and you want to stop on-demand connections, check both the relevant settings and the current connection state. Behavior during network changes can also depend on system scheduling and network availability; a configured condition does not guarantee an immediate connection in every environment. If the connection keeps changing, temporarily disable the conditions and use a manual connection for a stable comparison.

Data and Traffic Statistics

Data shows traffic and connection activity recorded by the client. In Data, first check the current view, statistics range, and categories, then review uploads, downloads, and related entries. Server- or app-based categories depend on the options shown in the current interface. Use these figures to compare changes before and after an action; they are not a copy of your service provider’s billing records or all device traffic.

To verify routing, note the current readings and selected server, perform one specific request, then check Data again. Background activity, connection overhead, cache hits, and the statistics range can all affect the results. No noticeable increase for one entry does not, on its own, prove that a rule failed. Consider the current Global Routing mode, rule matches, and actual access together.

Cumulative figures in Data are not a real-time speed test. To troubleshoot slow speeds, keep the network and destination consistent while comparing server tests, actual request times, and traffic changes. Before clearing statistics, record any readings you need for comparison and check what the reset will affect. Redact server addresses, request domains, and other private details before sharing a screenshot. See the technical notes for more on interpreting the figures.

Common Settings

Settings contains app-wide options, though some behavior may also depend on the active Config. Before making a change, note the original value and check what it affects. Change one setting at a time and retest on the same network and destination. The sections below outline what to check for common tasks; available options and their locations are shown in the current app.

DNS: Check the Resolution Path

DNS resolves domain names to addresses and is an important step before a connection. Check DNS options in Settings, and look for related settings in the active Config. If access by domain fails but a test using a known address behaves differently, focus on the DNS response and request path rather than changing the protocol password. Don’t add DNS addresses at random; decide which resolver to use, confirm it is reachable and appropriate for your setup, then test the same domain.

Test Method: Understand Test Results

Test Method determines how Connectivity Test runs. In Settings, check the current option and test target, and make sure they fit the scenario you want to compare. Different methods measure different parts of a connection, so their results are not directly comparable. Passing a test also does not guarantee that every service will work. To compare servers, keep Test Method, target, and local network the same, then compare repeated results. This avoids mistaking a change in test conditions for a change in server performance.

Today Widget: Check the Quick Access Option

Today Widget works with the corresponding system widget entry. Check the related options in Settings, then open the system’s widget manager to see what can be added. Availability and interactions depend on the system and the app’s current support; use the options available on your device. A shortcut does not change what Global Routing or Config means. After using the widget, return to Home to check the selected server and connection status.

iCloud: Check What Will Sync

To sync across your own devices, check the iCloud options in Settings and confirm that the system allows the app to use iCloud. Review what can currently be synced before enabling it; syncing does not restore a purchase or replace a backup. Before using another device, keep a copy of your working configuration. Confirm the sync results before deleting old entries to avoid mixing changes made on different devices.

Diagnostics: Keep Reproducible Details

Diagnostics helps investigate connection issues. Open the relevant option, reproduce one specific problem, and note the network type, Global Routing mode, selected server, and error message. Diagnostic details may include addresses, domains, or authentication information; review them and redact private data before sharing. If you need help, provide the steps to reproduce the issue and only the necessary details. Don’t share a complete subscription link or full configuration.