Shadowrocket Complete User Guide

02 / FIRST LAUNCH

First launch: VPN configuration and connection permissions

Learn the interface before granting system permissions

First, prepare valid server details; handle system authorization when you start a connection. Home shows servers and connection controls, Config manages routing rules, Data shows traffic information, and Settings contains common options. Layouts can vary between devices, so look for the item name rather than relying on fixed button coordinates. An empty list on first launch just means no connection details have been added yet.

The first time you connect, the system may ask to add a VPN configuration and confirm the action using your device passcode or another authentication method provided by the device. This grants the app permission to create a network extension. It is not a subscription sign-in page or a service provider password field. Confirm that the prompt follows an action you initiated and names the correct app before allowing it. If you cancel, return to the app and check your server details first.

Allowing a VPN configuration grants connection permission on the device; it does not verify that the remote server is available. Even after authorization succeeds, a connection can fail because of an incorrect address, port, credentials, or network conditions. Don’t treat authorization as proof that the connection works. You still need to test the server connection, domain resolution, and access to your destination separately; none of these checks replaces the others.

Troubleshoot permission issues

If you denied authorization earlier, check whether the system prompt appears again the next time you connect. If there’s no prompt and the connection fails immediately, look for the VPN configuration in system settings and check whether the Shadowrocket entry exists or the device is subject to management restrictions. The names and locations of system settings vary by version; follow what your device shows instead of repeatedly changing unrelated permissions to find a fixed path.

If the device already has another VPN configuration, first check which one is actually connected. Disconnect any other active VPN before testing Shadowrocket, so a system-level connection switch isn’t mistaken for a server failure. Keeping a configuration is not the same as keeping it connected; you usually don’t need to delete every configuration to test. Disconnect, verify the state, then make one deliberate connection attempt to pinpoint the failing step.

Camera access is only needed for scanning. If you use Scan QR Code to import existing server details, allow camera access when prompted. If you don’t scan a code, use another import method available in the app. Denying camera access does not deny VPN access or mean the server can’t connect. For each permission, first check whether the current feature needs it, then decide whether to grant it.

Keep a rollback point before your first connection

Before configuring anything, confirm that the device can already reach the ordinary pages you plan to test. Note whether you’re on Wi-Fi or cellular, and whether the network requires a web sign-in. Complete any required sign-in before connecting Shadowrocket. Otherwise, the app may have permission but still fail because the underlying network hasn’t granted access. Repeatedly changing protocol settings would only hide the real cause.

For your first setup, connect manually and leave complex On Demand conditions disabled for now. Complete the flow—select a server, choose a routing mode, connect, visit your destination, then disconnect—and note what happens at each step. Automatic connection depends on a working base configuration. Enabling it too early can cause the app to reconnect after you disconnect, making it hard to tell whether the cause is permissions, a triggering condition, or an unstable server connection.

If you need screenshots to review your settings or troubleshoot, hide passwords, subscription links, authentication identifiers, and QR codes that could reveal recoverable sensitive information. System prompts and app settings can help document the steps, but review every detail before sharing. To troubleshoot permissions, it’s enough to say whether the prompt appeared, whether you allowed it, and where the failure occurred. Never share service credentials. Once you’ve prepared, move on to importing server details.

04 / GLOBAL ROUTING

Routing: understand Config, Proxy, and Direct

Choose one of three modes based on how requests should be handled

For everyday rule-based routing, use Config. To test the selected server as a whole, use Proxy. To compare with a direct local connection, use Direct. Global Routing is the app’s overall routing mode—not a service provider protocol or a system permission switch. Check the current mode before investigating why a request went through a server or connected directly. The server name alone doesn’t show which path was used.

In Config, rules are generally checked in order, and the first matching rule determines how a request is handled. Put specific exceptions before broader rules that could override them. FINAL is the fallback when no earlier rule matches. The example below illustrates matching behavior; it is not a complete configuration you can safely use to replace your existing settings. Before making changes, copy the current working file and preserve its server and policy definitions.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Understand rule types, policies, and order separately

DOMAIN matches a complete domain, DOMAIN-SUFFIX matches a domain suffix, and DOMAIN-KEYWORD matches a keyword in a domain. A suffix rule suits a domain and its subdomains; keyword rules have a wider scope and can match unrelated domains containing the same text. Before adding a rule, define exactly what it should cover. Don’t use an overly broad rule in place of checking the target domains individually.

IP-CIDR and IP-CIDR6 match their respective address ranges. GEOIP uses the location associated with an address in the database. Domain requests may involve DNS resolution, and IP rules may also depend on how resolution works. In the example, no-resolve prevents the rule from triggering an additional lookup; it is not a general speed boost. Whether a rule matches depends on the actual request, not just the name shown on a webpage.

PROXY, DIRECT, and REJECT are handling policies, not the modes shown in Global Routing. If a Config rule matches DIRECT, that doesn’t switch the entire app to Direct. If it matches PROXY, check the policy reference and selected server in the current configuration. When a file uses a custom policy group name, the rule must reference an existing name with the exact same spelling.

Make the smallest change needed to check a rule

Before editing a configuration, make sure you’re changing the selected file, not a copy with the same name. After saving, follow the app’s prompt to reconnect or reload the configuration, then send a new test request. Existing long-lived connections and webpage or app caches may retain previous behavior, so don’t rely on a page that was already open. Make one clear new request and check its record to confirm which policy matched.

If a destination works in Proxy but not Config, first compare the matching rule, policy group reference, and DNS result; don’t rebuild the server immediately. If it works in Direct but not Proxy, check the server and protocol settings. These three modes help narrow down the cause; they are not interchangeable repair switches. When testing is complete, restore the mode you normally need so a temporary test setting doesn’t become permanent.

A rules file may also include DNS settings, policy groups, or remote rule references, so a single FINAL line doesn’t tell you how the whole file behaves. Start with a few clear rules to establish a testable baseline, then add exceptions gradually. After each addition, note the target, expected policy, and actual match. For further troubleshooting, bring these three details to Troubleshooting; they’re more useful than saying only that routing is wrong.

06 / DATA

Data: distinguish traffic stats, request logs, and service usage

Check what a number measures before judging its size

Data traffic information helps you see how the client is handling traffic; it is not the final usage figure for a service you already have. Before interpreting a number, check its label, reporting period, and connection status to see whether it describes uploads, downloads, the current connection, or a cumulative record. Numbers with different scopes aren’t directly comparable. A discrepancy alone doesn’t prove the client or server is counting incorrectly.

Upload and download describe data direction from the device’s perspective. Opening a page can generate upload requests, and downloading content also involves protocol exchanges, so uploads don’t necessarily mean you sent a file. Traffic figures show data transfer, not whether every item displayed successfully. Retries, background refreshes, and failed requests may also use data; interpret the figures in context.

Local statistics may differ from server records because of reporting periods, protocol overhead, retry handling, or the server’s own calculation method. Some requests may connect directly according to the rules, so the server will show only the portion that passed through it. To compare usage, align the time period and connection scope, then check the documentation for your existing service. Don’t treat Data as a billing statement.

Use request details to troubleshoot rules and resolution

When checking request records, first find the action you just initiated and verify its time, destination, and policy. The device makes other background connections, so the top entry isn’t necessarily the webpage you’re troubleshooting. Stop unrelated activity and run one clear test to narrow down the records. For repeat tests, keep the destination the same so you don’t mistake different requests for changing results from the same one.

If a record shows a matching rule, read both the rule type and the final policy. A domain rule match only tells you which part of the matching process applied; also check whether its referenced policy is what you expect. A DIRECT record doesn’t mean the server failed, and a REJECT record isn’t necessarily a connection error; either may be exactly what the configuration specifies. Compare the result with your expectation before deciding it’s a problem.

Interpret domain and address records separately. A webpage may contact several domains, and a domain may resolve to different addresses. Results can also change when you switch networks. The location of one address doesn’t determine how the whole webpage should be routed. When troubleshooting DNS, consider the resolution result, matching policy, and destination access together. Don’t change a broad GEOIP or IP-CIDR rule based on a single address.

Unexpected traffic, clearing records, and privacy

If traffic keeps increasing while you’re not actively using the device, first check background sync, media playback, system updates, and other running network tasks. Then see whether they’re related to your test. Reduce background activity during a clearly defined short observation and compare results before and after connecting or switching routing modes. Don’t assume a rising figure means your subscription has a problem; background requests handled by the client also appear in its statistics.

If the app offers an option to clear statistics or records, first save any details and observations you need for troubleshooting. Clearing local displays usually does not clear server-side usage or change the connection state. It won’t restore service capacity. After resetting, run a short test under the same conditions to observe changes. Note the new starting point; don’t compare the new total directly with the old cumulative figure.

Request records may contain domains, server addresses, timestamps, and other sensitive details. Review them before exporting or taking screenshots. When sharing a problem, you can include the rule type, policy name, and failure stage while hiding personal credentials and unrelated browsing details. Even a partially shown subscription link may contain authentication information. Don’t assume trimming its beginning makes it safe; review everything that remains visible.

Use Data as evidence, not as a conclusion on its own. Recording the network environment, routing mode, matching policy, and result for one request is usually more useful than collecting many screenshots. If the records don’t match what you observed, first confirm they refer to the same request, then check caches and long-lived connections. Once you’ve gathered the evidence, adjust relevant Settings; don’t make sweeping changes based only on a change in the traffic figures.

08 / MAINTENANCE

Maintenance: keep working configurations and manage updates and restores separately

The app, subscriptions, and rules have separate update paths

Handle App Store app updates, Subscribe list updates, and Config rule maintenance separately. An app update changes the client, a subscription update changes server details, and a rules update changes how requests are routed. They can happen at different times, so when something changes, first check which layer you updated most recently. A successful subscription refresh doesn’t mean the app was updated, and updating the app doesn’t validate expired details.

Before updating through the App Store, save your working configuration and make sure you can recover your subscription details. After updating, retest with the same server, routing mode, and destination. Don’t import new rules at the same time. If something changes, note the feature and failure stage before checking whether the cause is configuration compatibility, network conditions, or server status. You can check app update history in the store; there’s no need to keep your own version list.

After a subscription update, check for added or removed entries, name changes, and whether your current selection still works. Test at least one server you actively use; don’t rely only on a success message. If the list suddenly becomes empty, keep the existing details and check the link before repeatedly deleting and rebuilding. The validity and access period of an existing service depend on your service provider; app updates can’t extend or change them.

A backup is more than a saved file

Back up rule files, manually added server details, and subscription links separately. A Config file may not contain all server information, and a screenshot of the list can’t restore authentication fields. Before using an export or backup option in the app, check what it actually includes, then save the necessary details somewhere you control. Backup files may contain credentials; avoid public links, shared folders, or unchecked chat histories.

A backup is only useful if it can be restored. Without disturbing your working configuration, check the export contents and restore option to make sure the file opens, the rules are complete, and policy references still point to existing items. You don’t need to clear all your settings to test a backup. Keep the original and check a copy instead, so maintenance doesn’t turn into troubleshooting every connection again.

On a new device, restore Shadowrocket from the App Store first, then handle your server details and Config. Confirm purchase restoration and local data restoration separately; getting the app with the same account doesn’t guarantee that every setting will reappear automatically. For Family Sharing, use across devices, and compatibility, follow the details on the App Store page. After restoring, connect manually and verify it works before turning On Demand or other automatic behavior back on.

Remove obsolete entries and keep reusable notes

When organizing the server list, distinguish a temporary test failure from an entry you’ve confirmed you no longer use. A single timeout caused by network fluctuations isn’t enough reason to delete an entry. Update the subscription, verify the parameters, and retest under the same conditions. Keep source details for manually added entries, and remember that the next update may rebuild subscription entries. Organizing by source is safer than bulk cleanup based only on names or one test result.

Keep a clearly identified working baseline for configuration files. Before making a change, copy the file and state the goal—for example, adding an exception for one domain or adjusting the final policy. Once you’ve verified the result, decide whether to replace the original. Don’t let several copies with the same name all serve as the current configuration; it’s easy to select the wrong one next time. Reserved addresses and domains in examples are illustrative, not usable server details.

Keep troubleshooting notes concise but include the network type, source of the selected server, Global Routing mode, approximate time of the issue, failure stage, and most recent change. Don’t include full passwords or subscription credentials. If the issue recurs, compare it with the last known-working state, check recent changes, then review permissions, server settings, resolution, rules, and destination access in order. This is more effective than rebuilding everything from scratch each time.

For routine use, follow this order: confirm the underlying network works, verify your details are still valid, select the correct configuration, check that routing matches your expectations, and confirm access to the destination. Get this sequence working before adding automatic connections and complex rules. To repeat the shortest setup, read Getting Started. For purchase and restore checks, see the App Store guide. For a specific symptom, continue with the relevant steps in Troubleshooting.