Shadowrocket Features and Settings
Make sure you already have usable server details or a subscription before deciding how to route requests. This guide follows the app’s screens, including Home, Config, Data, and Settings, to explain what each feature does, where to configure it, and what to check afterward.
Global Routing: Choose a Routing Mode
Global Routing determines whether traffic is evaluated against your configuration rules or handled uniformly when the connection is active.
Open Global Routing from Home to view Config, Proxy, and Direct. Before choosing a mode, make sure your own usable server is listed under SERVER on Home and that the active Config contains the rules you expect. Changing the routing mode does not add servers or edit existing rules; it changes how requests are handled. For ongoing routing by domain or address, start with Config and then check which rules actually match.
| Mode | How it works | When to use it | What to check |
|---|---|---|---|
| Config | Handles requests according to the rules and final policy in the active Config. | When different destinations need to use PROXY, DIRECT, or REJECT. | Check rule order, policy names, and FINAL. |
| Proxy | Routes connection requests through the selected server instead of evaluating each against your usual routing rules. | For a quick check of whether a problem is caused by rule matching. | First confirm that the selected server is reachable. A successful test does not prove your rules are configured correctly. |
| Direct | Connects requests directly without using the selected server. | To check whether your local network can reach the destination service directly. | Results in Direct mode do not prove that a server or subscription is working. |
Change one variable at a time when troubleshooting. Note the current mode, switch to Proxy or Direct for comparison, then return to Config. If Config and Proxy produce different results, check whether a rule sends the destination to DIRECT or REJECT, or selects an unexpected policy. If neither connects, check the server details, current network, and connection status first. A connected status means the system connection is established; it does not mean every destination follows the same route.
Rule-Based Routing: Match Conditions and Policies
Rule-based routing is configured in Config: the condition specifies which requests to match, and the policy at the end specifies what happens to matching requests. Common policies include PROXY (use the selected proxy server), DIRECT (connect directly), and REJECT (reject the request). Use these rules to evaluate results when Global Routing is set to Config. Before editing, confirm which configuration is active; changes to an inactive Config do not affect how the current connection handles traffic.
For domain rules, DOMAIN matches an exact domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword in the domain. For address rules, IP-CIDR and IP-CIDR6 match their respective address ranges. GEOIP uses IP geolocation data, so results depend on address resolution and available location data. USER-AGENT matches a request identifier, but not every request provides a suitable one. Choose a rule type based on the information you can actually observe; a domain is not an IP address.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY
These examples explain the syntax and are not recommendations to replace your existing configuration. Rules follow the matching logic in your Config, so check specific conditions alongside the fallback policy. FINAL is applied when no earlier rule matches. If you change FINAL to DIRECT, unmatched requests connect directly; if you set it to PROXY, make sure the selected server is usable. After editing, test a few known destinations before expanding use. If a destination behaves unexpectedly, check the matching condition and policy first. Avoid making major changes to rules, DNS, and server settings all at once.
Existing Subscriptions and Server Management
A server entry stores connection details such as type, address, and authentication parameters. A subscription imports and updates a set of server details provided by your service provider. These are separate from routing rules: without a usable server, the PROXY policy cannot work as expected; with a server selected, choosing Direct still does not verify that the server works. Check the selected entry under SERVER on Home, then decide whether to add a server manually or import a subscription using the information you already have.
To add a server manually, open Add Server, choose the type that matches your details, and check the address, port, and authentication fields. The app may offer types such as Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. The protocol must match the information from your service provider; changing the type cannot make one set of parameters work with a different protocol. After saving, return to SERVER, select the entry you want to use, and then test the connection.
If you already have a subscription URL, enter the address provided by your service provider in the relevant Subscribe import screen. Updating a subscription reloads the provider’s content; it does not guarantee that every entry will connect. Before and after an update, check the entry names and selected server so you do not mistake a changed list for automatic server selection. If importing fails, check that the URL is complete, your network can reach it, and the provider’s link is still valid. Do not post a full URL containing access credentials publicly.
When managing multiple servers, use recognizable names for your own records and distinguish between an entry being present, selected, and actually receiving requests under your rules. Connectivity Test can help assess connection behavior, but results depend on the current network, test destination, and test method. When troubleshooting, record the selected entry, routing mode, and test method together; this is more useful than repeatedly changing many settings.
On Demand: Connect Based on Network Conditions
On Demand uses configured network conditions to decide when to establish a connection. It is useful when switching between different network environments. It controls when to connect, not how each request is routed after connecting; check Global Routing and Config for that. Find the On Demand settings in the app, review the available conditions shown on screen, and configure them for the networks you actually use. Options may vary; follow what is shown in your installed version.
Before setting this up, connect manually once to confirm that the selected server and current rules work on a network you use regularly. Then add only conditions you can verify, such as connection behavior for a familiar network. Afterward, check the connection status on Home in each relevant network environment and confirm that requests are still routed as expected. If a condition does not trigger, first check whether the device’s current network actually meets it, then review system VPN permissions and the On Demand switch in the app.
To troubleshoot a connection, temporarily turn off On Demand and reproduce the issue using the manual switch on Home. This helps separate automatic triggers from server or rule problems. After restoring automatic connections, test a network change rather than relying on an earlier manual connection to confirm that the condition works. Whether to use a persistent or on-demand connection depends on your needs. Interpret changes in Data in the context of when the connection was active.
Data: Understand Usage Statistics
Data shows connection-related traffic recorded by Shadowrocket. On the Data screen, first identify whether the figures cover the current connection, a time period, or another summary, then check the corresponding upload and download values. These figures can help you see whether traffic handled by the app changed after an action, but they are not a substitute for your service provider’s billing records. The coverage, time window, and calculation method may differ.
To compare usage before and after an action, note the current values, perform one action such as opening a known destination, then return to Data and check the increase. If the figures do not change as expected, check the connection status on Home, confirm that Global Routing is set to Config, and see whether the destination matched DIRECT or REJECT. Requests sent through DIRECT are not equivalent to those handled by the selected server. After switching servers or networks, check the time period and connection scope for the statistics again. Do not use figures from different conditions to infer whether a rule took effect.
Data is useful for observing usage, but not for diagnosing protocol parameters on its own. To check server reachability, use Connectivity Test alongside Diagnostics. To confirm the routing path, return to Config and review the rules and policies. Looking at all of these together can help explain issues such as traffic being recorded while a destination remains inaccessible, or a connection appearing normal while usage barely changes.
Settings: Check Common Options One by One
DNS: Identify Where Name Resolution Happens
DNS resolves domain names to addresses. Related options are available in Settings or in the corresponding section of the active Config. System DNS, custom DNS, and DNS over HTTPS differ in their resolver and transport method. Before changing anything, check whether the current Config already specifies DNS settings so you can identify which change affects the result. When editing DNS in Config, use the configuration format supported by the app. After making a change, test a known domain. If domain access behaves differently from access by a known address, DNS is worth checking first. Not every connection failure is a DNS issue.
Test Method: Understand What the Results Show
Test Method determines how connectivity checks are performed. Check the current selection in Settings and use it with Connectivity Test on Home. A successful test means that the selected method received a response; it does not guarantee the same result for every destination or protocol. A failed test also needs to be considered alongside the network, destination, and server details. When comparing two servers, keep Test Method the same so a change in testing procedure is not mistaken for a difference in server performance. Then test the rules using the destination you actually need to reach.
Today Widget: A Quick Access Point, Not a Status Check
Today Widget is a system-provided shortcut. After checking the related app settings in Settings, manage the widget as directed by the device’s system interface. It can help you view or control the connection, but confirm the final state on Home and with an actual connection test. If the widget does not show what you expect, open the app and check the selected SERVER, Global Routing, and connection switch rather than assuming a rule took effect based on a single widget view. System interfaces and available actions may vary by device; follow what appears on your device.
iCloud Sync: Check Synced Data and the Active Configuration
Find iCloud sync options in Settings to manage app-supported data across eligible Apple devices. Before enabling sync, confirm which configurations you need to keep on the original device. Subscription URLs and server authentication details are sensitive. After syncing, check each configuration on the destination device, confirm which Config is active, and verify which server is selected under SERVER. Data appearing on the device does not mean the current connection is using it. Sync scope, availability, and system requirements are listed in the app and on the App Store page.
Diagnostics: Narrow Down the Problem
Diagnostics can help investigate connection issues; look for the relevant option in Settings. Before reviewing diagnostic information, note the network, selected server, Global Routing mode, and destination where the issue occurred. If Home cannot establish a connection, check the server parameters and system VPN permissions first. If the connection is established but a particular domain fails, check DNS, rule matching, and FINAL. If the issue occurs only with On Demand, try a manual connection first to rule out server problems. Diagnostic information may include addresses or configuration details; remove personal credentials before sharing it.
A Checklist for Changes to Settings
When using several features together, checking them in dependency order is more effective than repeatedly toggling options across screens. First make sure server or subscription details have been imported correctly and select the intended entry under SERVER on Home. Then confirm whether Global Routing should use Config for rule-based routing or Proxy or Direct for a brief comparison. Observations are meaningful only when these two prerequisites are clear.
- On Home, check the connection status and selected SERVER entry. If the connection cannot be established, first check the server details and system VPN permissions.
- For rule-based routing, set Global Routing to Config, check the conditions and policies of the relevant rules and FINAL, then test a few known destinations.
- For issues with a particular domain, check DNS and rule matching. When testing servers, keep Test Method fixed and compare the Connectivity Test results.
- After manual connections work as expected, test the On Demand conditions. When reviewing Data, keep the measurement scope and test period consistent.
- After using iCloud sync or Today Widget, return to Home to verify the active configuration and actual connection status. Check Diagnostics if needed.
Verify each change as you make it and note the original settings so you can revert them. If you have not completed the initial import and connection, follow the tutorial to create a minimal working configuration. To verify the app’s source, developer, and app ID, see the App Store purchase verification guide. Screen names and options described here reflect the wording shown in the app.