Shadowrocket Settings Guide: Global Routing, On Demand & DNS | Shadowrocket Configuration Guide

Home / Global Routing

Global Routing: Config, Proxy, and Direct

Global Routing determines how traffic is routed after a connection is enabled. It does not import servers or replace the connection switch. Use Config for everyday routing based on domains or addresses, Proxy to temporarily test the selected server, and Direct to compare with your local network. These modes have different scopes. Before switching, decide what you want to test.

Where to find it and how to choose a mode

On Home, open Global Routing and select Config, Proxy, or Direct. Then return to Home to check the selected server and connection status. Config here is a routing mode; Config in the bottom navigation is where you manage configuration files. After selecting Config mode, confirm which file is active on the Config screen. The mode name alone does not confirm that the intended rules are in effect.

Global Routing modes: purpose and what to check
Mode	Routing behavior	When to use it	What to check
Config · Configuration	Routes requests according to the rules and policies in the active configuration file.	Everyday connections that need different policies for different domains or addresses.	Active file, Rule order, final rule, and policy targets.
Proxy · Proxy	Uses a proxy as the global routing direction, subject to system and configuration bypasses.	Temporarily check whether the selected server can reach a destination.	Selected server, connection parameters, destination, and network conditions.
Direct · Direct	Uses the local network for direct access as the global routing direction.	Compare local network access or check whether the issue is related to the proxy route.	Local network reachability and any other configuration that may affect requests.

What to keep in mind when switching modes

Proxy does not mean every system request from every app will take the same route, and Direct does not disable the system VPN configuration. When troubleshooting, record the routing mode and connection switch separately; they are not the same thing. If access fails in Config but works in Proxy, check the rules and policies first. If both fail, check the server parameters and network connectivity. Restore the original mode after testing; do not leave a temporary test setting in place as your everyday setup.

Config / Rule

Rule-based routing: match conditions, then apply a policy

Rule-based routing separates what a request is from how it is routed. DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD match domains at different scopes; IP-CIDR and IP-CIDR6 match address ranges; GEOIP uses address-location data; USER-AGENT depends on request information that is available to the app. The PROXY, DIRECT, and REJECT policies respectively proxy, connect directly, or reject a request. A protocol is not a policy: using Trojan or WireGuard does not determine which rule a domain matches.

Where to find rules and how to edit them

Open Config and confirm which configuration file is active, then open its editor and check the Rule section. Keep a working copy before making changes. Adjust one rule at a time, and confirm the edited file is still the active one. New rules generally belong before broader matches. Put FINAL at the end to handle requests that did not match any preceding rule.

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

DOMAIN,example.com,DIRECT: Matches example.com exactly and uses DIRECT. It does not also match all of its subdomains.
DOMAIN-SUFFIX,example.net,PROXY: Matches example.net and its subdomains, and routes them through PROXY.
IP-CIDR,192.168.0.0/16,DIRECT: Uses DIRECT when the destination falls within this private address range. Other private ranges are not included by this rule.
FINAL,PROXY: Routes requests that did not match earlier rules through PROXY. First confirm that the proxy target is available.

Rule order and limits on visible request information

Rules in the Rule section are checked from top to bottom; the first match determines the policy. A broad rule placed first may prevent a later, more specific rule from running. Address-based matching may also involve domain resolution, so DNS results matter as well as rule order. USER-AGENT is not directly available for every encrypted request and should not be treated as a universal way to identify apps.

These snippets illustrate rule syntax; they are not a complete configuration file. In an actual file, PROXY needs an available proxy target. If the file uses custom policy names, check that the names and references match. For more on General, Host, URL Rewrite, and rule priority, see Rules and configuration reference.

Home / Add Server / Subscribe

Subscriptions and server management: check parameters and rules separately

A server entry stores the address, port, protocol, and authentication parameters needed to connect to a server. A subscription lets you retrieve and update a set of entries in one place. Neither is the same as a rule-based configuration file. This guide assumes you already have your own subscription or server details. It explains how to import and manage them but does not provide, sell, or recommend servers or subscriptions.

Where to find the options and how to add a server

On Home, use the add option to open Add Server. If you already have a subscription, select the Subscribe type offered by the app, enter your own subscription URL, and choose a recognizable name. If you have details for a single server, select its protocol and enter each field. Before using Scan QR Code, make sure the code comes from your own configuration details. After importing, check the entry type, address, and port; a successful scan does not mean the connection works.

The fields differ across protocols such as Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard. Use your server details and the fields shown on the current screen; do not copy passwords, identifiers, or transport parameters from one protocol to another. Check TLS-related fields carefully, especially the server name and certificate settings. Do not change validation settings at random to work around an error.

Updating, testing, and deleting entries

After updating a subscription, check whether its entries have changed, then confirm which server is selected. A subscription source may change entry names or contents, so local edits to subscription-generated entries may be overwritten by the next update. Before deleting anything, distinguish between removing one server entry and removing an entire subscription group.

Connectivity Test checks for a response under the current test conditions. It does not prove that websites, video, or traffic over every protocol will work. If the test returns a result but access still fails, check the destination domain, Global Routing, DNS, and matching rules. If there is no result, consider the selected Test Method; one test alone cannot establish that an entry is invalid.

Settings / On Demand

On Demand: connect when conditions are met

On Demand can trigger a connection based on configured network conditions. It has a different role from Global Routing: On Demand controls when a connection is established, while Global Routing controls how traffic is routed after connection. Enabling On Demand will not fix server parameters or automatically replace invalid configuration details.

Where to find it and how to configure it

In Settings, find the On Demand options and review the available network conditions and actions before enabling them for your use case. If you want different behavior on Wi-Fi and cellular, check each condition separately. If a setting refers to a specific Wi-Fi network name, make sure the name is correct. Available options may vary; use what is shown in the app rather than copying choices from another device without checking.

Before setting this up, verify that the same server details work with a manual connection. Then enable On Demand and test both the network conditions where you expect it to connect and those where you expect it not to. This helps distinguish a condition that did not trigger from a connection that triggered but could not use the server.

If the connection comes back after you disconnect manually

If the connection starts again after you disconnect manually, check On Demand and its conditions first, then check the system VPN status. Recheck the settings when switching from Wi-Fi to cellular; a single status shown on Home may not reflect the whole transition. To stop On Demand for an extended period, explicitly disable the relevant setting and confirm its status instead of repeatedly toggling the connection switch.

Data

Data: client statistics are not server-side billing

Data shows traffic recorded by the app, including upload and download activity within the displayed statistics range. It can help indicate whether traffic passed after connecting, but the numbers alone do not prove that a webpage loaded fully or that a request used the intended policy.

Where to find it and how to read it

Open Data and check which statistics and time range the page currently displays, then distinguish upload from download. For a short test, note the current readings, perform one clearly defined action, and compare the values afterward. If the page offers a reset option, check whether you need to keep the existing records before using it. Once reset, those readings can no longer show what happened before.

How to interpret differences in traffic totals

The client and server may use different measurement scopes, time boundaries, and accounting for protocol overhead. Do not treat the Data reading as equivalent to the quota shown in your subscription details. A subscription quota is also not the same as the device's cumulative usage. To check server-side accounting, consult your existing service information. To assess the route taken by client requests, consider the mode, rules, and diagnostic records rather than cumulative traffic alone.

Settings / Config

Common Settings: adjust options by purpose

Settings brings together app preferences, test methods, and related tools, but it does not control every behavior on its own. The General section in a configuration file can also affect connections and resolution. When checking settings, note which configuration file is active. If options or their locations differ, use what is shown in the current app.

DNS: check the configuration before changing resolution

DNS resolves domain names to addresses, affecting domain access and the evaluation of some address-based rules. In Config, first check the General section and DNS settings in the active file. If Settings also has related options, check those too; changing one location does not necessarily apply every setting.

[General]
dns-server = system

dns-server = system means to use system DNS. This is an example for understanding the source of resolution, not a universal recommendation for every network. Before using custom DNS or DNS over HTTPS, confirm that the resolver is reachable on your current network, then update the configuration and test the same domain again. Avoid changing DNS, the server, and Global Routing at the same time, or it will be difficult to tell which change had an effect.

Test Method: interpret results in context

In Settings, find Test Method and choose from the available options, then return to Home and run Connectivity Test. Different methods may check different kinds of responses, so do not compare results directly after switching methods. When comparing multiple entries, keep the test method, network, and time window as consistent as possible. After testing, verify access in practice; a lower response time does not mean higher throughput.

Today Widget: quick status and actions

Today Widget settings work with the system widget interface, making it easier to check status or use the available shortcuts. Check the Today Widget options in Settings, then add the widget in a location supported by the system. Its availability and actions depend on the device system and app support; check the actual interface.

Widgets may refresh at intervals. To confirm connection status, return to Home and check the system VPN status. A shortcut does not bypass the system authorization required for the first connection. If an entry does not appear in the widget, check the widget configuration and app status instead of importing the same details again.

iCloud: distinguish local and cloud data before syncing

Before using iCloud sync, confirm that the required account is signed in and the system allows the app to use iCloud. Check the relevant Settings options to see what can actually be synced. Keep a working copy of your configuration before enabling or restoring sync, then check whether the expected data appears on another device. Do not assume that all preferences and runtime states will transfer.

Subscription URLs, authentication fields, and configuration files may contain sensitive information. Check what will be stored before syncing. iCloud sync does not restore app purchases and does not transfer system VPN authorization from the old device. After moving to a new device, check the servers, configuration files, and first-connection authorization individually.

Diagnostics: gather information about a single failure

When an issue occurs, check the diagnostic tools currently available under Diagnostics in Settings. Record the network, Global Routing mode, server, and configuration file in use, then reproduce the failure once. Keep the diagnostic information tied to that same attempt; combining results from different networks can lead to incorrect conclusions.

Before sharing diagnostic material, check whether it contains subscription URLs, authentication details, domains you accessed, or other personal information, and remove sensitive details as needed. If diagnostics do not match what happens in practice, return to Home to check the current selection and connection status, then inspect DNS and Rule. Repeatedly importing the same details is not a substitute for identifying the cause.

Settings checklist

Setup checklist: connect first, route traffic next, automate last

Check your details. On Home, check your existing server or subscription entry. Confirm that the protocol and required parameters are complete, then select the server you want to test.
Check the mode. In Global Routing, see whether Config, Proxy, or Direct is selected. Be clear about whether you are testing the proxy route or rule behavior.
Check the file. In Config mode, open Config and check the active file, Rule order, and FINAL. Pay particular attention to references to custom policies.
Verify a real request. Run Connectivity Test, then access a specific destination. If needed, use Data and Diagnostics to check whether the corresponding request appears.
Enable automation last. Once manual connections and rules work as expected, configure On Demand, Today Widget, or iCloud and verify each one separately.

If you cannot tell what caused a problem after making changes, return to the working configuration you saved and restore settings one at a time instead of enabling more options. For the complete first-import and connection process, see the getting started guide. For terminology, consult the quick reference. For specific issues, work through the troubleshooting guide.