OFFICIAL MANUAL / SETTINGS

Shadowrocket Settings and Features Guide

First determine how requests are handled, then decide when the connection should start. Check Global Routing, rules, servers, system triggers, and diagnostics in that order. This makes it easier to troubleshoot without losing track of what changed.

Config / Proxy / Direct On Demand Data / Diagnostics

This guide is for iPhone and iPad. Interface labels remain in English. Options may vary; check the Shadowrocket app on your device. Refer to the App Store listing for system requirements.

01 / GLOBAL ROUTING

Config, Proxy, and Direct modes

What it does: Global Routing determines how the client handles requests within its scope. Config applies the rules in the active configuration; Proxy uses proxy mode; Direct connects directly. These are request-handling modes, not protocol selectors or speed settings. Switching to Proxy will not fix an incorrect server password, and switching to Direct does not prove that a proxy server is reachable.

Where to find it: On Home, locate Global Routing and check which mode is selected: Config, Proxy, or Direct. The connection toggle is separate from Global Routing. An enabled toggle only indicates a change in connection status; it does not confirm that a domain matched the expected policy.

Mode and interface label How requests are handled When to use it Keep in mind
Configuration · Config Handles requests according to the rules in the active configuration. For everyday rule-based routing or checking how a request is matched. Make sure the configuration is enabled and that rule order and fallback policy are as expected.
Proxy · Proxy Uses proxy mode for requests within its scope. For a brief check of whether an issue is related to routing rules in Config. Server settings and connectivity must still be valid. This does not mean all system traffic follows the same policy.
Direct · Direct Connects directly for requests within its scope. To check whether the current network works without a proxy. This does not test the proxy route or mean that all system network settings are disabled.

Compare modes with a consistent test

  1. Note the current Global Routing mode, selected server, and active configuration so you can restore the original state.
  2. Reproduce the issue under Config first. Record the target domain and request result rather than just saying “the internet isn’t working.”
  3. Switch to Proxy only and test the same target again. If the result changes, check which rule matched and where its policy points.
  4. To check the underlying network, compare with Direct. When finished, restore the original Config mode and test again.

Keep in mind: Don’t change servers, DNS, and the configuration at the same time. Even if the issue improves, you won’t know which change made the difference. Actual behavior can also depend on special handling in the configuration, system routing, and how the target connects. Use request records to investigate rather than treating mode names as guarantees of absolute routing.

02 / RULE MATCHING

Rule types, order, and policies

What they do: Rules connect matching conditions to handling policies. DOMAIN matches a specific domain; DOMAIN-SUFFIX matches a domain suffix and its related subdomains; DOMAIN-KEYWORD matches a keyword in a domain. IP-CIDR and IP-CIDR6 match address ranges, while GEOIP uses IP geolocation data. USER-AGENT depends on the relevant information being identifiable in a request; don’t assume every connection includes it.

Where to find them: In Config, confirm which configuration is active, then review its rules. Selecting a server on Home does not switch configuration files. Editing an inactive file will not change how current requests are handled. Before troubleshooting, check that the active file and Global Routing mode are the ones you expect.

Read the condition first, then the policy

PROXY sends a matching request to a proxy policy, DIRECT connects to the destination directly, and REJECT blocks the request. A rule may also point to a policy group defined in the configuration; check which option is selected within that group. A policy name does not guarantee a successful connection: a request matched to PROXY can still fail if the server is unreachable.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

This is an instructional example, not a complete configuration to replace your existing settings. The first domain rule applies to example.com and its subdomains. The GEOIP rule checks the corresponding IP geolocation, and FINAL handles requests that did not match earlier rules. example.com is shown only to explain the syntax; it is not a real target you need to change.

How to configure: Keep a copy of the configuration, put more specific exceptions before broader conditions, and check FINAL last. Add one rule at a time, with a clear purpose. Save it, confirm the configuration is active, then test the relevant target. If similar rules already exist, look for duplicates or an earlier match instead of continually adding rules at the end.

Keep in mind: Rules are usually evaluated in order. An earlier match can prevent later rules from being considered. Address-based rules may depend on domain resolution, and results can also vary with the data used. REJECT blocks requests; it does not edit page content. Blocking a login, resource, or API domain by mistake can leave a page blank, hide images, or prevent actions from working.

For further troubleshooting, separate three possibilities: “the rule didn’t match,” “the wrong policy matched,” and “the right policy matched, but the connection failed.” Each points to different settings; adding more domain rules is not a universal fix. See the Troubleshooting Guide to check the request path based on the symptoms.

03 / SERVERS & SUBSCRIBE

Managing existing subscriptions and servers

What they are: Server entries store settings such as protocol, address, port, authentication, and transport. Subscribe updates entries from a subscription you already have. Subscriptions manage the source and updates of server entries; Config manages rules and related settings. They are not interchangeable. Importing servers does not change your active rules or mean every server can connect.

Where to find them: View the server list on Home. Use Add Server to enter server details you already have; use the relevant Subscribe option to import an existing subscription. Before using Scan QR Code, make sure you trust its source. Available fields vary by protocol. Fill in only what the selected protocol requires; don’t copy parameters from a different protocol into the same form.

Check these four items after importing

  1. Check the protocol and server address. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields. Similar names do not mean their settings are interchangeable.
  2. Check the port, authentication details, and transport settings. If the server requires TLS or a specific name, enter the values from the configuration you already have.
  3. Run Connectivity Test on one entry, then verify it with a real request. A name appearing in the list confirms only that it was imported, not that it can connect.
  4. Record where the entry came from and how it is updated. Back up any manual changes you want to keep so you can restore them if a later Subscribe update overwrites them.

How to proceed: Import, select, test, and only then adjust rules. If a subscription update fails, check that the link is complete, the source is reachable on your current network, and the subscription is still active on the account side. After a successful update, check which entries actually changed rather than assuming everything is set based on a single confirmation. When sharing troubleshooting details, redact subscription credentials, passwords, and personal addresses.

Keep in mind: A subscription refresh is not a fix for every connection problem. A server timeout could be caused by its settings, the network, or server status. Repeatedly deleting and reimporting entries can erase useful information for comparison. See the Getting Started Guide for the import sequence, and the App Store purchase guide for the official listing and purchase verification.

04 / ON DEMAND

On Demand: connect on demand

What it does: On Demand lets the system start a connection when specified conditions are met. It controls when a connection starts; Global Routing and rules control how requests are handled. On Demand does not create routing rules or fix server settings, so configure it only after a manual connection works as expected.

Where to find it: Look for On Demand in Settings and review the network conditions and actions available on your device. Setup may require authorization to add a system VPN configuration. A system prompt confirms that the configuration will be added; it does not verify server connectivity. If other system VPN configurations are present, confirm that the expected one is active.

Start with a single trigger condition

  1. Temporarily turn off on-demand triggers. Connect manually and verify that the current server and Config work as expected.
  2. Note the existing On Demand settings and change only one network condition and action. If you use a Wi-Fi condition, check the network name carefully.
  3. If possible, switch between Wi-Fi and cellular and observe when the connection starts. Then check whether requests are handled by the rules you expect.
  4. After testing, note which conditions worked. Avoid stacking overlapping conditions that make the behavior difficult to explain.

Keep in mind: If the connection starts again after you disconnect manually, the system may have met an on-demand condition again; the toggle may not be malfunctioning. To stop automatic triggers, review the relevant settings in On Demand instead of repeatedly tapping the Home toggle. On Wi-Fi networks that require web authentication, complete the network login first, then troubleshoot the connection. Device state, system policies, and network changes all affect when a trigger runs. On-demand connections are not separate proxy switches for individual apps.

05 / DATA

Data: traffic statistics and scope

What it does: Data shows traffic recorded by the client. Use it to check whether communication occurred during a test and whether upload or download activity changed. It is not a network-service account balance and cannot replace the provider’s billing records. Statistics cover only what the client can record; they should not be treated as the device’s total network usage.

Where to find it: Open Data and check what is being counted and over what scope. Available details may vary by device, so refer to the labels and options shown on yours. If the interface offers a reset, save any records you need before using it. Resetting local statistics does not change an external service’s billing period.

How to use it: Before testing a fixed target, note the starting values in Data. Open only the page or app you need to check, wait for its requests to finish, then compare the figures. Pause background downloads and system updates where possible; otherwise, other activity may account for the increase. To find out which policy handled a target, check request records too. An increase in total traffic alone does not prove it went through PROXY.

Keep in mind: The upload-to-download ratio depends on what you’re doing; a short-term change does not indicate consistent server speed. Protocol overhead, retries, and differences in how traffic is counted can also affect the numbers. To troubleshoot battery drain, compare Data with system battery and cellular usage records, but don’t assume the client is at fault just because traffic is high. Sustained transfers naturally increase network activity.

06 / SETTINGS

Common Settings

Settings manages some app preferences, but it is not the only place where configuration is defined. DNS settings, for example, may also come from the active Config. Check both the active configuration and the relevant screen. Use the options shown on your device; don’t substitute a similarly named option that isn’t available, or guess at configuration fields.

DNS: check resolution separately from routing

What it does and where to find it: DNS resolves domain names to addresses. Check the relevant entry in Settings alongside the active Config. Successful resolution does not guarantee a successful proxy connection, and a resolution failure does not necessarily mean server authentication is wrong. Domain rules and address rules use different information, so changing DNS can affect rule matching.

How to configure: Record the original settings first. Determine whether the issue affects all domains or just some, then check DNS settings and whether the resolver is reachable. Change one thing at a time, save, and retest the same target. If needed, reconnect to reduce interference from existing connections. Note: Don’t combine multiple DNS changes from unknown sources or assume one resolver will fix every problem.

Test Method: understanding test results

What it does and where to find it: Find Test Method in Settings. It determines how connectivity tests are performed; you can then return to Home and run Connectivity Test. Different methods may check different parts of the network. A probe that receives no response does not necessarily mean real-world requests will all fail.

How to configure: When comparing servers, use the same Test Method, network, and similar testing times, then verify with a real target. Note: A test result is not a throughput guarantee, and the lowest test value does not guarantee the fastest experience on every site. Changing the method changes how you measure connectivity; it won’t fix a server’s port, password, or transport settings.

Today Widget: quick access and connection status

What it does and where to find it: Today Widget settings relate to quick access. Whether you can add the widget and how it appears depend on system support on your device. Check the relevant option in Settings, then use the widget management controls provided by the system. The widget does not replace a full configuration check on Home.

How to configure: After adding the widget, return to the app and confirm the selected server and Global Routing mode. Then test whether the quick action starts the expected connection. Note: Widget status may refresh with a delay. If it differs from the actual state, trust the in-app status and real requests. If you don’t see the option, don’t change unrelated network settings just to get a similar appearance.

iCloud: handle sync and recovery separately

What it does and where to find it: iCloud options support data syncing or backup where available. Check the relevant entry in Settings as well as the system’s iCloud settings. App purchases are associated with the App Store account; that does not mean configuration data has synced. Check each separately.

How to configure: Check the iCloud account signed in on the device, system permissions, and available storage. Then review the sync scope shown in the app. Keep a local copy before migrating, and verify servers, Config, and selection state one by one on the new device. Note: Don’t assume all data will be overwritten automatically or arrive immediately. Subscriptions and authentication details are sensitive, so restrict access to synced files as well.

07 / DIAGNOSTICS

Diagnostics and settings verification

What it does: Diagnostics helps collect and review troubleshooting information to narrow an issue down to resolution, rules, server connectivity, or the request itself. Diagnostic information supports investigation; it does not fix problems automatically. Start with a specific symptom and use the relevant tools available on your device instead of enabling everything at once.

Where to find it: Look for Diagnostics or the relevant diagnostic tool in Settings. Also check Connectivity Test on Home, Data, and any available request records. Tools and output vary by device; use what the current interface provides. If you enable extra logging, use it only while troubleshooting and restore the previous settings when finished to avoid keeping unnecessary detailed data.

Keep one comparable set of evidence for each issue

  1. Record the conditions: Note whether you’re on Wi-Fi or cellular, the Global Routing mode, selected server, and Config. Don’t record passwords or other credentials.
  2. Check the underlying network: Confirm that the network itself can communicate. If needed, verify that you’ve completed web authentication on Wi-Fi.
  3. Check the server: Run Connectivity Test. If it fails, verify the protocol, address, port, authentication, transport settings, and system time.
  4. Reproduce a single target: Request a specific domain. Check whether it resolves, which rule matches, and which policy is actually used.
  5. Change one variable: Retest the same target after each change. If it doesn’t help, restore the original setting so leftover changes don’t affect the next check.

Keep in mind: A timeout means a request did not complete within the wait period; it does not identify which part failed. If only a few targets fail, check those targets and their rules first. If all targets fail, investigate the underlying connection and shared settings. Before sharing diagnostics, redact credentials in subscription links, server authentication details, personal domains, and activity that could identify you. Include only what is relevant to the issue.