Shadowrocket Features and Common Settings

Global Routing: Config, Proxy, and Direct

Global Routing controls how the current connection is handled overall. Open Global Routing from Home and choose Config, Proxy, or Direct for the task at hand. These options determine whether traffic follows the configuration, uses a proxy, or connects directly. They are not servers and cannot fill in missing server details.

For everyday use, check Config first

To send some destinations through PROXY and others through DIRECT, select Config and confirm that the correct file is active under Config. Importing a file does not automatically make it the active configuration; selecting a server does not mean every request will use it. Check the active Config, Global Routing mode, and server selection together.

For troubleshooting, temporarily switch to Proxy and check whether the same destination becomes reachable. If Proxy works but Config does not, check rule matches, policy references, and DNS before changing all the protocol settings. Direct provides a baseline for direct connections. Compare the same destination on the same network, and make a fresh request each time so an existing connection does not skew the results.

Proxy does not guarantee a successful connection, and Direct does not disable every system network setting. After testing, switch back to your intended mode. Leaving Shadowrocket in a troubleshooting mode may route traffic differently than expected.

Rules: Match Conditions and Policies

Rules are an ordered list of conditions and the policies to apply when they match. Find them in the active Config. Before editing, save a copy of the original and review the rules section. Rules are generally evaluated from top to bottom, so put more specific conditions before broader ones. FINAL handles connections that did not match an earlier rule.

Common Rule Types

• DOMAIN: Matches an exact domain name, useful for routing a single, specific hostname.
• DOMAIN-SUFFIX: Matches a domain and its subdomains, useful for applying the same policy across a domain and its subdomains.
• DOMAIN-KEYWORD: Matches a keyword in a domain name. This can match broadly, so check that it will not include unrelated destinations.
• IP-CIDR and IP-CIDR6: Match IPv4 and IPv6 address ranges, respectively—not text in a URL.
• GEOIP: Matches based on the destination IP’s geographic assignment. Results depend on the IP database and the actual DNS resolution.
• FINAL: Handles connections that did not match earlier rules. Check that it routes them as intended.

What PROXY, DIRECT, and REJECT Do

A match type determines which connections are selected; a policy determines what happens to them. PROXY routes traffic through a proxy, DIRECT connects directly, and REJECT blocks the connection. A configuration may also reference a named policy. Check what that policy points to rather than assuming the configuration is complete just because the rule exists.

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

These standalone snippets explain the syntax; they are not a complete configuration or usable server details. The first line matches only example.com and does not automatically include its subdomains. The second rule also matches example.net and its subdomains. The final rule, FINAL,DIRECT, sends connections not matched earlier through a direct connection—not through PROXY by default.

After editing, save the file, confirm that the modified Config is active, and check the results against actual request records. A single page may request several domains, so a rule matching the page’s main domain does not mean its images, login, or other resources use the same route. For more on rule syntax and examples, see Rule Keywords: A Beginner’s Guide.

Subscribe and Server Management

A server entry stores the protocol, address, port, and authentication details needed to connect to a remote server. Subscribe updates these entries from a subscription URL you already have. Home is where you view and select servers; to enter details manually, start with Add Server. Before importing, check whether you have a subscription URL, a single server link, or a complete configuration file. Use the correct import option for each; they are not interchangeable just because each can be copied as text.

Check the Import, Then Test

1. Import using the option that matches the information you have. Add an individual server through Add Server by selecting its protocol; scan a QR code with Scan QR Code.
2. Open the imported entry and check its protocol, address, and port, along with any required authentication and transport settings.
3. Select the server you want to use in Home. Run Connectivity Test, then try accessing a destination you know should be reachable.
4. If you use Config, also check that the policies referenced by its rules point to the selected server or another valid policy.

A subscription update fetches entries again from its remote source. If you edit a server managed by a subscription, a later update may overwrite your changes. Back up any edits you need to keep. Similarly named entries from different subscriptions may have different addresses or settings; use local notes to distinguish their source and purpose.

A subscription containing a server list does not necessarily include Rules or DNS settings suited to your needs. If an update fails, check that the URL is complete and still valid, then confirm that your current network can reach it. Do not expose authentication details from subscription URLs in screenshots, logs, or public discussions. Remove credentials and personal identifiers before asking for help.

Before deleting a subscription or clearing multiple entries, check whether any Config still references its servers. A server being selectable does not mean it is reachable; Connectivity Test results also depend on the test method, as explained below. For full instructions on adding and importing, see the beginner’s guide.

On Demand: Connect Automatically Based on Conditions

On Demand lets the system establish a connection when specified conditions are met, reducing the need to connect manually. On iPhone and iPad, open On Demand settings, review the existing conditions, and decide whether to enable them. Available conditions and their locations depend on the app and system interface. On Demand controls when to connect, not which rule handles a request.

Verify Manual Connections Before Enabling Automatic Conditions

Turn off On Demand first. Confirm that the server, Config, and DNS work with a manual connection, then add only one necessary set of conditions at a time. If conditions depend on the network, test connecting and disconnecting on each relevant network. Success on one Wi-Fi network does not mean behavior will be as expected on mobile data or other Wi-Fi networks.

On Demand may reconnect after you disconnect manually if the system still meets the connection conditions. This does not necessarily mean the toggle is broken. To stop it temporarily, adjust or turn off On Demand before disconnecting. Changing Global Routing alone may not prevent the system from connecting based on conditions; these settings control different things.

Automatic connections cannot fix an expired subscription, an incorrect password, or an unreachable server. Enable On Demand after the rules and server are working reliably. This makes it easier to tell reconnection behavior from configuration errors. Assess battery use based on network switching, connection duration, and actual traffic—not the toggle state alone.

Data: Traffic Statistics and Their Limits

Data shows traffic recorded by the app. Use it to check whether data is being transferred, whether an action generated traffic, and how usage changes over time. Check the reporting range and time period before reading the figures. The level of detail may vary by platform and interface; do not assume every device shows the same statistics.

Run a Small, Repeatable Test

To monitor a task, note the current statistics, open a destination, perform one specific action, then return to Data and check what changed. If the current interface offers a reset, save any records you want to keep before resetting and starting a new test. Resetting statistics clears only the local baseline; it does not reset usage tracked by a service you already have.

Data is not your carrier bill or the usage record for a service you already have. Tunnel overhead, retransmissions, background requests, and differences in how traffic is counted can all cause discrepancies. An increase only shows that traffic was recorded within the displayed scope. It does not prove that a webpage loaded completely or that its content came from the expected server.

If traffic continues while the device is idle, check system background activity, On Demand conditions, and request records to identify the source. Do not disable several system features just to lower one statistic. Identify the connection first, then decide whether to change anything so you can compare results meaningfully.

Settings: Common Options and How to Adjust Them

Settings brings together options for testing, system integration, and diagnostics. Some network behavior may also be controlled by the active Config. Before making a change, check its scope: a global option, the current configuration, or an individual server setting. Record the original value, change one variable at a time, and retest the same destination.

DNS: Check Resolution Before the Route

DNS resolves domain names to addresses. DNS settings may be available in a related section of Settings or defined in the active Config. Check whether the current configuration already includes DNS settings, then confirm that the specified address is reachable and appropriate. Do not keep changing DNS just because a webpage will not load, and do not assume changing DNS also changes Global Routing.

Domain rules and IP address rules match different things. A domain may match the right rule while the resolved address remains unreachable; a server may connect successfully while domain resolution fails. During troubleshooting, note the domain, resolution result, and stage of the error to distinguish DNS, routing, and server issues. Make a fresh request after changing settings and, if needed, handle the cache as the current interface allows so you are not testing against an old result.

Test Method: What the Results Mean

Choosing a method under Test Method in Settings affects how connection tests are run. Read what the selected method tests and how it determines success before comparing servers. Results from different methods are not directly comparable, and a test result is not the same as a browser download speed.

Keep the method, network, and test destination the same when comparing results. If a server test fails but access works, first check whether the method suits that connection. If the test succeeds but a page does not work, check the destination service, DNS, and rules. Connectivity Test helps narrow down the cause; it does not guarantee that every app request will work.

Today Widget: System Shortcut

Today Widget is for widget features supported by the system. Check Settings for related options; whether you can add a widget and how it appears depend on the system and the options provided by the app. First select a server and verify a manual connection in the app, then add the widget through the system’s widget editor. If the system does not show the option, use the features actually available on your device.

Widgets are useful for checking status or performing quick actions; make complex edits in the app. If the widget and app briefly show different statuses, open the app to check the connection and then check whether the system has refreshed. Do not immediately delete your configuration or reimport a subscription.

iCloud: Sync Scope and Backup Steps

To troubleshoot iCloud sync, check your system account, iCloud availability, and app settings. Before enabling it, review the specific items under Settings that will sync. Do not assume that all servers, Config files, statistics, and connection status are synced. Local selections and system permissions may not carry over to another device either.

Before using another device for the first time, back up important configurations on both devices and decide which copy to keep as the primary one. If items are missing, wait for sync and check your account and network before importing multiple files with the same name. Sync transfers data; it does not verify connections. Afterward, check Global Routing, the active Config, and the server on each device.

Diagnostics: Gather Information by Failure Stage

Diagnostics lets you view or run the diagnostic checks available in the current version, usually from a related section of Settings. It helps break down “not working” into specific questions: can the server connect, can the domain resolve, which rule matches a request, and does the problem affect only one destination? Use the checks available in the interface. You do not need to leave every diagnostic option enabled.

Capture Four Details for Each Diagnostic

1. Network: Are you on Wi-Fi or mobile data? Does the issue occur on only one network?
2. Mode: Is Global Routing set to Config, Proxy, or Direct, and which configuration is active?
3. What failed: A subscription update, a server test, or an actual request to a particular destination?
4. Symptom: Note the exact error shown, when it occurred, and the steps that reproduce it.

If no destinations connect, first check the current network, server address and port, authentication settings, and system time. If only one destination fails, check its DNS resolution, matching rules, and service status. If Config fails but Proxy works, check configuration references and routing rules before considering a reinstall.

Before sharing diagnostic information, remove subscription credentials, passwords, personal access domains, and other sensitive details. When diagnostics are complete, turn off any detailed logging you no longer need and handle exported files carefully. For a step-by-step approach to timeouts and connection failures, see Troubleshooting Connection Timeouts. For differences in protocol fields, see the protocol reference.

Recommended Order for Checking Settings

Avoid changing everything at once. Start with a minimal connection you can verify, then add rules, automatic connections, and system shortcuts step by step. This order also works when reviewing an existing setup after a sudden problem.

1. Check the details: Identify whether you have server or subscription information, then verify that the protocol, address, port, and authentication details are complete.
2. Check the server: Select the expected entry in Home, run Connectivity Test with a consistent Test Method, and try an actual connection.
3. Check the mode: Verify Global Routing. To route traffic by rules, select Config and confirm the active file.
4. Check the match: Review Rule order, policy references, and FINAL, then use request records to see where traffic is routed.
5. Check DNS: Check where DNS settings come from and what they apply to. Distinguish resolution failures from server connection failures.
6. Add automation: Enable On Demand only after manual connections work reliably, then test each network condition.
7. Keep a baseline: Save a copy of the configuration and use Data and Diagnostics to compare changes. Then consider widgets and sync settings.

After each change, retest the same destination and record the results. If a change causes problems, undo that change before adding more fixes. This preserves a working configuration and gives you a clear starting point for further troubleshooting.

This page explains what features do and where settings apply. If you have not imported anything yet, follow the beginner’s guide. For download sources, platform installation, or restoring a purchase, see the download guide for all platforms. Browse the FAQ by topic for specific questions.