Official Guide / Features and Common Settings
Shadowrocket Settings Guide
Start by choosing how Global Routing should work, then check the rules and policies in Config. Finally, adjust On Demand, DNS, and testing options. Change one setting at a time and test the same destination so you can tell what caused the result.
- Routing: Global Routing
- Configuration: Config
- Usage statistics: Data
Find Settings by Feature
These links jump to sections on this page; they don’t switch or hide content. Labels may vary by app version, so check the names shown on your device. If an option is in a different place, search for its English name rather than substituting another setting.
Global Routing: Config, Proxy, and Direct
What it does: Global Routing determines how the client routes requests. The three common modes are Config, Proxy, and Direct. They aren’t speed settings; they determine whether requests are routed according to configuration rules.
Where to find it and how to set it: Open Global Routing from Home, choose a mode, then return to check which mode is displayed. Use Config for everyday routing based on domains, addresses, and other rules. Use Proxy to temporarily check whether the selected proxy works. Use Direct to compare access over your local network.
| Mode | How it works | When to use it | What to check first |
|---|---|---|---|
| Config | Routes requests according to the rules and policies in the active configuration. | Everyday use when traffic needs to be routed direct, through a proxy, or blocked. | Active configuration file, rule order, and policy names. |
| Proxy | Routes requests handled by the client through a proxy, subject to the relevant app and system conditions. | Isolating rule-related issues while checking whether the selected proxy works. | Selected server, connection parameters, and test destination. |
| Direct | Routes requests handled by the client directly. | Comparing access over your local network to check whether the proxy route is the issue. | Whether the same destination is accessible on the current network. |
Keep in mind: Direct does not turn off the client connection, and Proxy does not mean every kind of system communication must follow the same route. Existing long-lived connections may retain their previous state after you switch modes. Start a new request to test the change; if needed, close the relevant connection before testing again. If you switched to Proxy for troubleshooting, remember to restore Config if that’s your usual mode.
Routing Rules: Match Conditions and Policies
What they do: A rule consists of a match condition and an action. The condition identifies the request; the action determines where it goes. In Config mode, rules are commonly evaluated in order. An earlier match can prevent later rules from applying, so put specific exceptions before broader conditions.
Where to find them and how to set them: In Config, check which file is active, then open its rule editor. Decide whether the destination should match an exact domain, a domain suffix, or an IP range, then enter the rule value and policy. After saving, make sure the edited file is active and send a new request to the same destination.
| Rule keyword | What it matches | What to check |
|---|---|---|
DOMAIN | An exact domain. | Enter the domain only; don’t include a path or protocol prefix. |
DOMAIN-SUFFIX | A domain suffix and its subdomains. | A suffix can cover multiple services. |
DOMAIN-KEYWORD | A keyword contained in the domain. | This can match broadly; check for unintended matches first. |
IP-CIDR / IP-CIDR6 | An IPv4 or IPv6 address range. | Check the address family, prefix length, and resolution conditions. |
GEOIP | IP geolocation data. | Geolocation data doesn’t necessarily reflect where a service is actually hosted. |
FINAL | The final action when no earlier rule matches. | Use as a fallback at the end of the rules. |
DIRECT, PROXY, and REJECT
DIRECT means a direct connection, PROXY applies a proxy policy, and REJECT blocks the request. A configuration may also refer to custom policy group names; each name must be defined in that configuration. Don’t infer its actual destination from the name alone. Keep rule keyword capitalization and separators in the correct format.
The following is a rule syntax example, not an app screen or a complete configuration you can use to replace an existing file. example.com is shown only to illustrate suffix matching.
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYKeep in mind: If a rule doesn’t work as expected, check whether an earlier rule matched, then verify the actual domain and IP in the request record. A webpage may contact multiple domains, so a rule for its main domain may not cover every resource. Don’t try to mask a matching issue by repeatedly adding broad keyword rules.
Subscribe: Manage Existing Subscriptions and Servers
What it does: Subscribe imports and updates server details using a subscription URL you already have. A subscription typically manages a group of servers; servers added individually require you to maintain their parameters yourself. Updating a subscription and updating the app through the App Store are separate processes—one does not replace the other.
Where to find it and how to set it: From Home, open the add menu and go to Add Server. Choose Subscribe if that option appears, enter your own subscription URL and a label, save, then update and check that the groups and entries appear. You can import an existing QR code with Scan QR Code. After importing, check the type, address, and port rather than relying on the label alone.
To add a server manually, choose the correct protocol in Add Server, then enter its address, port, and credentials. The label is for identification only; it doesn’t affect how the connection works. Use clear names or purpose-based labels to distinguish entries and avoid choosing the wrong one when several have similar names.
Keep in mind: Subscription URLs may contain personal access credentials. Don’t include them in public screenshots, logs, or feedback. Entry names, groups, and counts may change when the source updates. Local edits to subscription entries may also be affected by later updates, so keep any necessary notes before changing them. If an update fails, distinguish an invalid URL from a timeout or a parsing error; don’t immediately delete a group that may still work.
This site explains how to import and manage content you already have. Check the terms of your existing service for subscription validity, multi-device use, and service duration; none of these can be inferred from your app purchase history.
Protocols: Choose the Type Before Entering Parameters
What they do: A protocol defines how the client connects to a server and exchanges data. Shadowrocket supports multiple protocols, including Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. Available types and fields may vary; check Add Server in the app.
Where to find them and how to set them: In Add Server, choose the protocol that matches your existing server details. Then check the address, port, authentication details, and any TLS or transport fields required by that protocol. An import link must also specify the correct type; don’t copy fields from one protocol into another.
Keep in mind: The same server address doesn’t make different protocols interchangeable, and a display name doesn’t confirm that the parameters are correct. Domains, TLS verification names, and transport paths serve different purposes; check your connection details before entering them. If a connection fails, check for missing or mistyped fields first. Disabling certificate verification is not a routine troubleshooting step. A protocol name alone does not guarantee speed or stability on a particular network.
Config: Activate and Edit Configuration Files
What it does: Config is where you manage configuration files. A configuration can contain rules, policies, and other options; server subscriptions mainly import and update connection entries. They serve different purposes, so importing a subscription doesn’t mean your routing rules are already set up for your needs.
Where to find it and how to set it: In Config, review the file list and note which file is active before opening one to edit. Keep a copy of the original, then review the existing rules and how policy groups refer to one another. After saving, select the intended file and confirm that it’s active. For a remote source, check its purpose and trustworthiness before updating it.
Keep in mind: Later updates to a remote file may change local behavior, especially rule order, policy group names, or parsing settings. Don’t combine rule snippets from different sources without checking their references. If something goes wrong, restoring the last verified working file is usually easier to troubleshoot than layering on more edits. Treat configuration files containing private addresses or credentials as sensitive when backing them up or syncing them.
On Demand: Trigger Connections by Condition
What it does: On Demand triggers or maintains the system VPN connection based on conditions. It’s a separate layer from rule-based routing: On Demand controls when to connect, while rules in Config control where requests go after connecting. Enabling On Demand won’t fix server parameters or add missing rules.
Where to find it and how to set it: Open On Demand in the app and check the existing conditions before adding rules based on the network conditions currently available. You can build behavior around Wi-Fi, cellular networks, or domain-related conditions; available actions and fields depend on what the app displays. Start with one clear condition, verify that it works, then add more.
- First, confirm that your existing server and configuration work with a manual connection.
- Note the network used for testing, add the relevant condition and action, and check the rule order.
- Switch to a network that meets the condition and check the system VPN status and actual requests.
- Then test a scenario that doesn’t meet the condition to check for unexpected reconnects or disconnections.
Keep in mind: Check Wi-Fi names carefully, and review rule order when conditions overlap. With On Demand enabled, manually disconnecting may trigger a reconnect if a condition is still met. Check this first when troubleshooting. Temporarily disable On Demand rules to prevent automatic behavior from affecting your comparison, then restore your settings when testing is complete. On Demand doesn’t stop background traffic; battery use still depends on actual requests, network conditions, and how often the connection reconnects.
Data: Usage Statistics and Request Checks
What it does: Data shows traffic recorded by the client, including upload, download, and related request activity. Use it to see when data was transferred and which requests may need a closer look. It does not replace cellular billing records or usage figures from a service you already have.
Where to find it and how to use it: Open Data, check the reporting period and what the figures include, then review the relevant records. To test a destination, note the start time, send a small number of new requests, and compare the traffic figures afterward. To confirm routing, check the destination and route in any connection records available in the app. Save figures you need before resetting statistics.
Keep in mind: App records, system statistics, and remote usage figures may differ because of billing periods, protocol overhead, or reporting scope. A large download figure alone doesn’t mean a rule is wrong, and background traffic from other apps shouldn’t be counted as a test request. Keep test conditions consistent and avoid parallel transfers, such as syncing or media playback, that could skew results.
Settings: DNS, Tests, Components, and Sync
Settings options affect different aspects of behavior. Identify the issue you want to solve before changing the relevant option. Names, availability, and locations depend on what the current app version and system display.
DNS: Distinguish Resolution Issues from Connection Issues
What it does and where to find it: DNS resolves domain names to IP addresses. When checking DNS options in Settings, also check whether the active Config includes DNS settings so you don’t change an option that isn’t in use.
How to set it and what to watch for: Keep the original value, then use the same domain to check whether resolution succeeds. Choose system DNS or a custom resolver based on your existing network requirements. With DNS over HTTPS, consider whether the resolver itself is reachable; if DNS requests depend on a connection that hasn’t been established yet, startup may fail. A webpage that won’t load isn’t necessarily a DNS issue—check the address, server authentication, and routing separately. For details, see the DNS settings guide.
Test Method: Use the Same Test Method for Comparisons
What it does and where to find it: Test Method in Settings affects how Connectivity Test runs. Results reflect the selected method, target, and network conditions at the time; they don’t guarantee the overall experience when using a server.
How to set it and what to watch for: Choose one of the available methods, then compare existing entries using the same test target and network. Don’t directly rank results from different methods. A timeout doesn’t necessarily mean that all app requests will fail. Verify access to a destination you actually need, and distinguish handshake failures from DNS resolution failures and slow destination responses. Repeated tests shouldn’t be used to treat a momentary low result as typical performance.
Today Widget: Check Status After Using a Shortcut
What it does and where to find it: Today Widget provides shortcuts through a system widget. Check its related options in Settings, then add the widget through the system’s widget editor. Available formats depend on what your device and system support.
How to set it and what to watch for: Set up your server and routing in the main app first, then add the widget you need. After using a widget action, return to Home to check the connection status and selected server. System widgets may refresh with a delay, so don’t rely on stale widget text to confirm the current connection. If an action doesn’t work, open the main app and check its permissions and status.
iCloud: Sync Scope and Device Differences
What it does and where to find it: iCloud options sync data supported by the app. Check the app’s sync options in Settings and confirm that it has iCloud access in system settings. App purchase history and configuration sync use separate mechanisms and should not be confused.
How to set it and what to watch for: Check sync status on the original device, then verify which items arrive on the other device. Keep a restorable copy of your configuration before making changes. Don’t assume that all local history, system VPN permissions, and device state will transfer. Synced data may include private server details, so manage account and device access carefully. On a new device, complete any required system authorization before connecting.
Diagnostics: Use Comparisons to Isolate Issues
What it does: Diagnostics provides tools for viewing or collecting information needed for troubleshooting. The goal isn’t to change every option at once, but to isolate whether a failure involves the local network, server connection, DNS resolution, or rule handling.
Where to find it and how to use it: Look for Diagnostics in Settings and use the tools available in the current app version to check connections or records. Before reproducing an issue, note the destination, network type, Global Routing mode, and active Config. If diagnostics require temporary logging, turn it off after reproducing the issue and check exported data for sensitive information.
- Check the network. Confirm that the device’s current network works; distinguish a network-wide outage from an issue with a single destination.
- Check the server. Verify your existing connection details and run Connectivity Test. Note the test method, not just the result.
- Check the mode and rules. Temporarily compare Proxy with Config. If the results differ, check rule matches and policy references.
- Check DNS. Check DNS only when domain resolution is failing; don’t mistake server authentication failures for DNS issues.
- Undo test changes. Restore the original mode, On Demand conditions, and logging settings. Keep track of what you learned by changing one setting at a time.
Keep in mind: Diagnostic records may expose domains, server addresses, subscription details, or authentication information. When reporting an issue, include the error type and necessary context, but redact private fields. Don’t publish a complete configuration or an original subscription URL. Tool output is only part of the evidence; assess it alongside actual requests and current settings.