FUNCTIONS & SETTINGS
Choose Global Routing first, then check rules, servers and connection triggers.
This page is a feature reference in the Shadowrocket manual, focusing on common tasks on iPhone and iPad. Before changing settings, note the current state. Change one variable at a time, then retest the same destination. Changing the server, DNS and config file all at once makes it difficult to identify what affected the result.
Get the app and verify its authenticity → First connection steps →
ROUTING MODE
Global Routing determines how traffic is handled when the connection is active. Open it from Home, then choose Config, Proxy or Direct based on what you need. These options correspond to configuration-based routing, proxy routing and direct routing, but check the English labels in the app. This is separate from the connection toggle on Home: after selecting a mode, make sure the connection is turned on.
| Option | How it works | When to use it | Important |
|---|---|---|---|
| Config | Applies the policies matched by rules in the current config file. | For everyday rule-based routing; check domain and IP range rules. | First confirm the expected file is enabled in Config. |
| Proxy | Routes requests through the proxy by default. | Temporarily check whether the selected server can handle a request to the destination. | Success in this mode does not prove that the rules are correct. |
| Direct | Routes requests directly by default. | Check direct access from the current network to the destination. | This does not turn off the connection or verify server credentials. |
Use Config when you need rule-based routing. In Config, confirm which file is enabled, then return to Home and check the selected server. Importing a file into the list does not make it the active config. Likewise, a PROXY entry in a file does not mean the server settings are ready to use.
If a destination is unreachable, temporarily switch to Proxy for comparison. If it works in Proxy but not Config, check the matched rule, policy and DNS next rather than rebuilding every server. When testing with Direct, keep the destination and network conditions unchanged. After comparing, restore the original mode so you don't leave a troubleshooting setting in place.
RULE MATCHING
Rule routing connects request conditions to handling policies. Rules are in the [Rule] section of the active config file in Config. They are generally checked from top to bottom, and the first match determines the policy. Put specific domains before broader conditions and place FINAL at the end. Don't just check whether a rule exists; check whether an earlier rule already matches the request.
In this example, example.com matches DOMAIN first and uses DIRECT. Its subdomains can then match DOMAIN-SUFFIX and use PROXY. IP-CIDR specifies an address range, while FINAL catches requests not handled by earlier rules. This example illustrates rule order; don't replace an entire config without checking it first.
| Keyword | What it matches | Notes |
|---|---|---|
| DOMAIN | An exact domain. | Use for one specific destination; it does not automatically include subdomains. |
| DOMAIN-SUFFIX | A domain and its subdomains. | Check the suffix scope to avoid matching more requests than intended. |
| DOMAIN-KEYWORD | A keyword in a domain. | This can match broadly; make sure the keyword won't trigger unintended matches. |
| IP-CIDR / IP-CIDR6 | IPv4 / IPv6 address ranges. | Check the address family and prefix length. |
| GEOIP | Geographic classification of an IP address. | Depends on the IP database and DNS results. |
| USER-AGENT | Available User-Agent information. | Not all traffic exposes information that can be matched. |
| FINAL | Requests not matched by earlier rules. | Put this last to define the fallback policy. |
PROXY, DIRECT and REJECT are policies, not rule conditions. PROXY routes a request through a proxy, DIRECT uses a direct connection, and REJECT blocks a matched request. Troubleshooting comes down to two questions: which condition matched the request, and which policy did that condition specify? If the config uses a custom policy name, also check that it is valid and which server it points to.
Keep a copy of the original config before editing. After making changes, confirm the file is still active and test with a new request. Existing connections may continue using the previous route, so ongoing playback or transfers alone don't show whether a new rule is working. See Config Reference for syntax, config sections and rule-order examples.
SERVER MANAGEMENT
Server details describe the connection endpoint, protocol and authentication parameters. A subscription provides and updates multiple existing server entries. Server subscriptions and rule config files serve different purposes; don't import them through the same entry just because both are provided as text links. Before importing, identify whether you have a server subscription, a single server share link or a config file.
To add a server manually, open Add Server from Home, choose the protocol, then enter the address, port and authentication details. Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard and Hysteria2 use different fields. Enter the details from your existing server information. TLS, transport and server name settings must also match the server; don't guess based on the protocol name alone.
Use Scan QR Code if you already have a QR code. Existing share links can be handled with the relevant import option. When using Subscribe, check whether the current entry manages server subscriptions or config subscriptions in Config. Confirm the content type before importing, then check which list it appears in. Don't use a rule file URL as a server subscription URL.
After updating a subscription, check whether its entries changed, then return to Home and confirm the selected server is still the one you expect. A successful update only means the content was fetched and processed; it doesn't mean every server in it can connect. Follow up with a Connectivity Test and a real request. If an update fails, first check that the link is complete, the current network can reach it and the subscription is still valid.
Before editing entries created by a subscription, consider whether the next update might recreate or overwrite them. Record important local changes separately. Before removing a subscription, check whether it includes a server you're using. Subscription links, QR codes and authentication fields may contain credentials; don't share the original content when reporting an issue.
CONNECTION TRIGGER
On Demand starts a connection when configured network conditions are met. It controls when a connection starts, not which policy applies to a domain. Open On Demand from Home, configure the network conditions available in the current interface, then enable it. Because it relies on a working system VPN configuration, verify a manual connection first.
Decide what you expect before configuring it: connect on a specified network, or trigger again when network conditions change. Check the available Wi-Fi, cellular and network-matching options one by one; don't enable everything without understanding how the conditions interact. To test, stay on one stable network, then switch to another and observe the result. Reopening a page repeatedly on the same network won't verify a network-change condition.
After On Demand connects, requests are still handled by Global Routing and the current config. It can't fix an unavailable server or replace rule selection. If the connection starts again after you disconnect manually, check whether On Demand is enabled and whether the current network meets its conditions. For troubleshooting, turn it off temporarily and compare with a manual connection, then restore the conditions you need.
TRAFFIC OBSERVATION
Data shows traffic recorded by the app. Open Data and check the current statistic, time range and categories shown in the interface, then watch upload and download changes. Note the values before testing, make one clearly defined request, and compare the difference. This makes it easier to tell whether that action generated traffic than looking at the cumulative total alone.
App traffic statistics are not the same as your provider's billing records. They may use different periods, boundaries and calculation methods. Don't treat the total in Data as your remaining account allowance, or assume a page loaded fully just because the download count increased. Background requests, app retries and connection overhead can all affect the statistics.
To start a fresh observation baseline, note any necessary information first, then use the reset option in the interface. Resetting statistics won't fix a connection and shouldn't be done alongside changing rules. If a page fails but Data changes, keep checking the request result, matched policy and destination status. If nothing changes, first check the connection toggle, current mode and whether the test request was actually sent again.
COMMON SETTINGS
Settings includes testing, utilities, sync and diagnostics. DNS behavior may also be defined in the current config file. The sections below explain where to check each feature; exact menu locations and available options depend on the current app interface. Similar names don't necessarily mean a global option in Settings and a file-level option in Config have the same scope.
DNS resolves domain names to addresses, which can affect connections and decisions made by some IP rules. To check DNS, open the active file in Config and look for dns-server in [General], along with any DNS-related options in the current interface. The system example below means using the system DNS; it is not a universal recommendation for every network.
If you suspect a DNS issue, compare a new request to the same domain before and after making a change. Don't change the server at the same time. Confirm the chosen resolver is reachable on the current network, then check whether any rules depend on the resolved address. Changing DNS won't update server authentication, destination certificates or existing connections. When an error occurs, distinguish a DNS failure from a connection failure.
Test Method is in Settings and selects how servers are tested. Check the current method and any available parameters before running a Connectivity Test. Different methods measure different stages: opening a port doesn't mean a request to the destination page completed, and passing a test request through a proxy doesn't mean every destination is reachable.
When comparing servers, keep Test Method, test destination and network conditions the same. Don't rank results from different methods directly or treat a shorter test time as a guarantee of long-term speed. If a test fails, check endpoint reachability, authentication details, transport settings and the test destination separately, then check the destination you actually want to use.
Today Widget provides a system widget entry point. Check the related options offered in Settings, then add or manage it using the methods supported by your system. Available locations and controls depend on the device and system; refer to the current system interface. Select a server and verify the connection in the app before setting up the widget, so initial configuration issues aren't mistaken for widget problems.
Widgets provide supplementary information, and system updates may not be immediate. If the status is unclear, open Home and check the actual connection toggle, Global Routing mode and selected server. Don't rely on a single widget display to determine the current route. Removing the widget does not turn off On Demand in the app.
Before using iCloud features, check that iCloud is available in the system and that Shadowrocket has permission to access it. Then check the sync options in the app's Settings. Sync only what the current feature supports; don't assume servers, configs, statistics and system permissions are all copied together. Keep a recoverable copy of important configs before the first sync.
When editing the same content on multiple devices, wait for sync to finish before continuing to avoid uncertainty about which version is current. After switching devices, check the active config, selected server and system VPN permission. Restoring an App Store purchase and syncing iCloud content are separate processes: redownloading the app doesn't mean all app data has been restored.
Diagnostics helps check app status and connection issues. Open the diagnostics section in Settings to see the available tools. Before troubleshooting, note the network type, Global Routing mode, active config and steps that trigger the issue, then reproduce it once. Diagnostic information should correspond to the time of the failure; records saved too early may not include the request you need to analyze.
Before sharing diagnostic results, remove subscription links, passwords, authentication fields and unnecessary personal information. Keep only details that help identify the failure stage, such as whether DNS resolution completed, where the connection failed and which policy matched. Once you've collected enough to diagnose the issue, restore your usual logging settings to avoid keeping detailed request records longer than necessary.
A connection involves system permissions, server settings, DNS resolution, rule policies and the destination's response. Use the sequence below to narrow down the issue. Retest the same destination after each step and record the result.
On Home, check the connection toggle and selected server, and confirm the system has allowed the VPN configuration. Then verify that the server protocol, address, port and authentication details match the information you have. If this step hasn't passed, there's no need to adjust complex domain rules yet.
Check Global Routing. If using Config, confirm the active file and review which rules might match and what their final policies are. To compare, temporarily switch to Proxy or Direct, then restore the original mode after testing.
Run a Connectivity Test without changing Test Method, then make a request to the actual destination. Use Data and Diagnostics to check whether traffic was generated and whether DNS resolution and the connection completed. Don't use a single test result as a substitute for checking the full request.
Check On Demand conditions, the active config and sync status, then restore any options changed temporarily during troubleshooting. Keep necessary notes, but remove sensitive information so you can compare future issues using the same method.