Shadowrocket
Features and Settings Guide

Global Routing determines how the client handles requests within its scope. Config uses Config, proxy mode uses Proxy, and direct mode uses Direct. Config is generally used for rule-based routing. To check whether a rule is affecting a request, temporarily switch to Proxy or Direct for comparison. Changing modes does not switch servers or automatically fix account, port, or protocol settings.

Open Global Routing in Home, select a mode, then return and make a new request to the same website or app. Existing long-lived connections may continue using their original route; if needed, close and reopen the app. If the destination works in Proxy but not Config, check the rules and policies. If both modes fail, check the server, network, and destination service before broadening rule coverage.

Rule-based routing separates the conditions a request matches from the action taken when it matches. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domain names; IP-CIDR and IP-CIDR6 match address ranges; GEOIP checks the region associated with an address. USER-AGENT matches request headers and is useful only when the client can access that information. It does not identify apps across all encrypted traffic.

Common policies include DIRECT, PROXY, and REJECT. DIRECT connects without a proxy, PROXY sends the request to a proxy policy, and REJECT blocks matching requests. A configuration may also use custom policy names. Before changing one, confirm it is defined in the active configuration and points to the intended server or policy group. Similar names do not necessarily mean the same thing.

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

This is a syntax example, not a complete configuration to replace your existing one. DOMAIN matches the exact domain; DOMAIN-SUFFIX also matches its subdomains; DOMAIN-KEYWORD covers a broader range and may catch domains you did not intend to include. Rules are generally checked in order, with the first match taking precedence. Put specific rules before broader ones and place FINAL at the end to handle remaining requests.

Before making changes, back up the active Config. Add one narrowly scoped rule, confirm Global Routing is set to Config, then make a new request and check the match in the logs. If the rule does not match, compare the domain actually accessed with any domain reached after redirects. If it matches but takes the wrong route, check the policy target instead of adding the same condition again. For rules that depend on IP addresses, also consider DNS results and the configuration’s DNS options.

A subscription fetches and updates server entries in batches. Each server entry stores the address, port, protocol, and authentication details needed to connect. These instructions assume you already have a subscription or server details; get subscription links from your provider. Buying or installing the client does not automatically provide a working connection.

If you have a subscription link, add it through Subscribe in Config, save it, refresh it, then check the entries in Home. If you have details for a single server, select its type with Add Server and fill in each field. Protocols such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard require different fields. Use the details supplied by your provider; entering only an address and port is not enough.

Scan QR Code and clipboard import are useful when you already have server sharing details. Before importing, check whether the content is server information or a complete configuration so you do not paste a configuration URL into a server address field. Subscription URLs often contain access credentials. Do not include them in public screenshots, chat logs, or diagnostic attachments. If a link is exposed, contact your provider to replace it.

Before refreshing, note the currently selected server and any important comments. A subscription refresh may replace entries, and manual edits to subscription entries may be overwritten. Keep manually maintained servers organized separately. If you have multiple subscriptions, name them by purpose and confirm their source and group before deleting anything; do not assume entries with similar display names are duplicates.

See the guide to refreshing, sorting, and backing up subscriptions →

On Demand triggers connections based on configured network conditions. It serves a different purpose from Global Routing: On Demand controls when to connect, while Global Routing controls how requests are handled after connecting. It relies on the platform’s network extension and current permissions, so its behavior may vary across apps and network conditions.

First connect manually in Home and make sure the server works. Then open On Demand in Settings and configure the network types, Wi-Fi conditions, and other options available in the current interface. Start with one easy-to-test condition. Change networks and check the connection status before adding exceptions. If your platform does not have this menu, use the features available on that platform rather than copying settings from another device.

To temporarily stop automatic connections, check On Demand as well as the Home switch. If the connection keeps coming back, disable the On Demand conditions first and observe what happens. Do not delete all servers to solve the problem. If you briefly lose connectivity when switching between Wi-Fi and mobile data, distinguish a network reconnection from an On Demand condition being matched.

Data shows upload, download, and related usage recorded by the client. Before interpreting the numbers, check the reporting period: current connection totals, accumulated records, and per-server figures may cover different time spans. These figures are not the same as your system’s cellular data statistics or your provider’s billing records.

To see whether an action used data, note the current totals, pause other background transfers, perform one specific action, and compare the results. If the interface lets you clear statistics, save any records you need first. Resetting these figures does not restore your provider account’s allowance.

An increase only shows that data passed through the relevant reporting scope; it does not prove that the destination finished loading. Retries, protocol overhead, and background sync can also use data. If usage rises unexpectedly, narrow it down by checking connection records, the selected server, and the destination app. If usage is low but a page will not load, check DNS, connection setup, and the destination’s response.

Global Settings and options in Config may both affect connections. If options have similar names, first confirm which configuration is active and read the description for each setting. Do not assume all platforms apply settings in the same way. The sections below explain settings by use case; available choices depend on the current interface.

DNS: check name resolution before routing

DNS translates domain names into addresses and is a separate step in the connection path. Check DNS-related items in Settings and see whether the active Config also contains DNS settings. Use a known-working setup suited to your network, and change one option at a time. After saving, reconnect and test the same domain to avoid cached results masking the change.

Do not replace every DNS setting at once while troubleshooting. Successful name resolution does not guarantee that a proxy connection will work. Check separately which route DNS requests take and which policy handles the destination connection. If only some domains fail, check spelling, DNS records, and rule matching first. If several destinations fail, compare the local network with the selected DNS method.

Test Method: a test is not the whole experience

Test Method controls how server checks are performed. Check the current method in Settings, then run Connectivity Test from Home. Results show reachability or response time under specific test conditions. They do not represent how every website will perform or prove that authentication, transport, and access to the destination are all working.

When comparing servers, keep the test method, network, and destination consistent. If a probe fails, first check whether the server responds to that type of probe, then compare with an actual request. Do not keep switching away from a server that works reliably just because one test reports a lower number.

Today Widget: quick access and status checks

Today Widget provides quick access or status information on platforms that support it. Check the relevant options in Settings, then add it using the method provided by the system. Availability and placement depend on the system version. If your device does not offer the widget, use Home to connect and switch servers.

After using the widget, return to Home to confirm the selected server and connection status. The widget may take time to refresh, so do not rely on an old status to confirm that a connection has stopped. It is not a full interface for managing rules or subscriptions.

iCloud sync: back up before syncing

iCloud sync covers only the content supported by the current platform and interface; it is not a complete, real-time mirror across all devices. First check system iCloud permissions, then review the sync options in Settings and which items they cover. Back up local data before enabling sync for the first time. Decide which device is the source of truth, then check the results on another device.

Syncing configurations does not sync app purchases or provider accounts, and does not ensure that connection status matches across devices. Editing on multiple devices at once may overwrite changes. For major updates, finish and verify the changes on one device before working on others. Synced files may contain sensitive connection details, so protect access to your devices and cloud account.

Diagnostics helps distinguish DNS failures, server connection failures, authentication issues, and request handling problems. Enable the diagnostic or logging options available in the current interface. Note the time of the error, network, Global Routing mode, and selected server, then reproduce the issue once. This makes it easier to match log entries to a specific action instead of guessing from a long-running log.

First identify where the failure occurs. If no DNS result is returned, check DNS. If the server cannot be reached, check the address, port, and network. If the connection is established but the destination is still inaccessible, check the policy, protocol-specific fields, and destination response. Different errors can look alike; do not assume every timeout is a rule problem.

If you need to report the issue to your provider, include the error text, steps to reproduce, and network type. Before sharing, remove subscription URLs, passwords, authentication identifiers, and unnecessary browsing records. Review screenshots too. After troubleshooting, restore your usual logging settings and delete diagnostic files you no longer need to avoid keeping sensitive connection details.