Shadowrocket Official Manual · Features

Shadowrocket Features and Settings

First choose how requests should be routed, then adjust rules, connection conditions, and diagnostic options. Whether a setup is appropriate depends on your existing servers, current network, and actual access results.

  • Global Routing
  • Config / Proxy / Direct
  • Settings / Data
Start with the Getting Started Guide Browse the complete user manual →

Five key capabilities, with distinct roles

These are feature descriptions, not app screenshots. Select a category to learn what it does; see the following sections for steps and important notes.

Rules determine where requests go

Rules compare a request’s domain or destination address with configured conditions, then apply the corresponding policy. Find them in Config. Before they take effect, set Global Routing on Home to Config. Check which configuration is active before editing rules; changes to an inactive file won’t affect connections. When troubleshooting, check request records to see which rule matched rather than relying on server latency alone.

DOMAIN-SUFFIX,example.com,PROXY
Home

Global Routing: Config / Proxy / Direct

Global Routing controls how traffic is routed overall. Use Config for day-to-day routing by domain and address; switch to Proxy temporarily to check the proxy path, or use Direct to check direct access. These are routing modes, not speed settings.

Mode and interface labelHow it handles trafficCommon usesWhat to check
Configuration · ConfigHandles requests according to the rules and policies in the active configuration.Everyday routing; testing custom rules.Whether the configuration is active, rule order, and policy targets.
Proxy · ProxyRoutes traffic through the proxy overall, subject to system and app handling limits.Temporarily checking the proxy connection path for the selected server.Whether the selected server is valid; switch back to your usual mode after testing.
Direct · DirectHandles traffic as direct connections overall.Checking the local network or direct access.Direct does not mean the system VPN connection is turned off.

Setup order and how to retest

On Home, open Global Routing, select the mode you need, then return and confirm the displayed value. If you’re using Config, check the active indicator in Config; if you’re using Proxy, check which server is selected. Then make the request again. If needed, end the existing connection first, since connections already in progress may not immediately use the new settings.

If a target works in Proxy but fails in Config, start by checking the matched rule, policy group, and DNS path. This helps narrow down the issue; it doesn’t prove what caused it. If both modes fail, also check the server parameters, authentication status, and current network.

Config

Rule types, policies, and match order

Rules determine how specific requests are handled. In Config, open the active configuration and find the rule editor. Review the existing entries before adding exceptions. Rules are generally checked from top to bottom, and the matching policy is applied. Put more specific conditions before broader ones, and place FINAL at the end as the fallback for requests that don’t match another rule.

Choose a match type for the target

  • DOMAIN: Matches a specific domain, useful when a rule should apply to one exact hostname.
  • DOMAIN-SUFFIX: Matches a domain and its subdomains, useful for routing requests by domain range.
  • DOMAIN-KEYWORD: Matches a keyword in the domain. This can match broadly, so assess the risk of false matches before adding it.
  • IP-CIDR and IP-CIDR6: Match IPv4 or IPv6 address ranges. Check whether DNS resolution is involved and whether the destination uses dynamic addresses.
  • GEOIP: Matches against an IP geolocation database. Database results don’t replace checking a service’s actual location and purpose.
  • USER-AGENT: Relies on visible request information and isn’t a reliable way to identify every app.

Distinguish policy names from routing modes

DIRECT means a direct connection, REJECT rejects matching requests, and PROXY routes them through a proxy; check the configuration to see what each one targets. Uppercase policies in rules are a different layer from Config / Proxy / Direct in Global Routing. Custom policy group names may also be used, so references must match the configuration exactly.

DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
FINAL,PROXY

These are rule syntax examples, not a complete file to replace your current configuration. Keep a copy of the original before editing, then confirm the edited file is still active and check request records to see which rule matched. Avoid routing every issue through a broad keyword rule; it makes it harder to track which domains were affected together.

Home / Add Server

Server management and protocol settings

Server entries store the details needed to connect to a remote server. The name is just a label for identification; it doesn’t determine the protocol. Using server details you already have, tap Add Server on Home, choose the matching protocol, and enter the address, port, and authentication fields. Fields differ between protocols, so don’t enter a Shadowsocks password in a field that expects different credentials.

When importing existing details with Scan QR Code, camera access is used only to scan the code. After importing, open the entry and check its type and address. A QR code may contain one server or point to a subscription, so its appearance alone doesn’t tell you what’s inside. When importing from the clipboard, also make sure you haven’t copied surrounding explanatory text.

Keep a way to roll back before editing an entry

Record the original settings or keep a separate copy of the entry before changing fields you want to test. TLS, server name, and transport parameters should match your existing service details. If the connection fails, don’t guess ports repeatedly or treat weaker verification as a general fix. For HTTP, SOCKS5, WireGuard, Hysteria2, and other types, follow the relevant field descriptions instead of applying settings from one protocol to another.

After saving, select the server on Home, run Connectivity Test, and try an actual request. Seeing an entry in the list only confirms it was saved; the test method, remote reachability, and access to a service are separate things. Before deleting an entry, check whether a policy group or active configuration refers to it.

Subscribe

Importing, updating, and maintaining existing subscriptions

Subscribe retrieves and updates a server list; it isn’t a rule configuration. Enter a subscription URL you already have in the appropriate field and save it, then update and check that the expected entries appear. Use a URL from your own service details. An account dashboard URL, payment page URL, and subscription URL serve different purposes and aren’t interchangeable.

After an update, check three things

  1. Check whether the update succeeded, and distinguish a network access failure from content that couldn’t be parsed. Don’t keep adding the same URL.
  2. Check that the currently selected server still exists, and make sure changes to entry names or groups haven’t caused a different server to be selected.
  3. Test actual access again and confirm that policy groups in your rules still reference the correct servers.

A subscription update may overwrite entries managed by the subscription. If you need to maintain a parameter independently, understand how updates work before deciding whether to keep a separate manual entry. Don’t delete the whole group only to discover that you no longer have the original URL. Before cleanup, make sure you can import it again and keep any necessary details safe.

A one-time purchase of the app is not a service plan. Buying Shadowrocket and having access to an existing service are separate matters. This site doesn’t provide, sell, or recommend servers or subscriptions; it explains how to use details you already have.

Subscription URLs often contain credentials. Hide the full URL and authentication fields in screenshots, and don’t post the link in public documents. If retrieval fails, first check that the URL is still valid, that your current network can reach it, and that the returned content is correct. Then consider changing the app settings.

On Demand

On Demand: connection conditions

On Demand sets conditions for automatic connections; it isn’t another name for rules-based routing. Open On Demand in the app and review the available conditions and actions before configuring it for your network. The current in-app wording determines the available options and where to find them; don’t assume they’re in the same place on other devices.

Test one condition at a time

To distinguish Wi-Fi networks, check the SSID spelling and the action that applies to it. If you need cellular coverage, check that condition separately; Wi-Fi conditions don’t automatically apply to every network. Domain-based connection triggers and domain rules in a configuration file serve different purposes: one controls connection triggers, the other handles requests.

Start with one easy-to-test condition. Switch to the target network and check the system VPN status, then leave that network and test again. If there are multiple conditions, check their order and actions in the app for overlap or conflicts. Test both entering and leaving each condition as you add it; this makes issues easier to isolate than adding everything at once.

If the system reconnects after you disconnect manually, temporarily turn off On Demand and test again to see whether a condition is triggering the connection. To stay disconnected during everyday use, check both the app’s connection status and On Demand settings. Before normal use, also complete the system’s VPN configuration authorization. Authorization to connect doesn’t mean a usable server is available.

Data

Data: traffic changes and statistics

Data shows traffic information the app can measure. Open Data and check the current page’s scope, direction, and time range before comparing values around a specific request. Upload and download indicate data transfer direction; they don’t show whether a webpage loaded fully and can’t, on their own, tell you whether a rule or server is at fault.

For troubleshooting, pause other noticeable network activity if possible, note the displayed value before testing, then visit a known destination and compare. If the figures change but the page still fails, check DNS, the handshake, and app-level errors. If there’s little change, check the connection status, routing mode, and whether the request followed the expected path.

App statistics are not a service usage statement

The app, system, and your existing service may measure different things. Connection overhead, reporting periods, and billing rules may also differ. Use Data to observe trends and help troubleshoot, not as a substitute for remaining service allowance or usage records. To compare figures, first align the time range and units instead of simply subtracting totals.

If the current interface offers a way to reset statistics, decide whether you need to keep the troubleshooting record before resetting. Resetting the displayed history doesn’t change service usage that has already occurred. Don’t assume all historical statistics will return after changing devices or reinstalling the app.

Settings

Common Settings: adjust by issue

Keep a working baseline, then change one setting at a time. Some settings may be controlled by the active Config, so check the configuration file for related options as well as the app settings. The sections below explain settings by purpose; you don’t need to change every option.

DNS: domain resolution path

DNS resolves domain names to addresses. Check the related options in Settings and the active Config, first identifying the source used for resolution and then looking for overrides. If a webpage won’t load but Connectivity Test succeeds, start by checking whether the target domain resolves.

Record the original value before making a change. Change one related option at a time and create a new request to test it. Don’t layer multiple DNS settings whose purpose you don’t understand; successful resolution doesn’t guarantee that the connection will succeed.

Test Method: how tests run

Check Test Method in Settings and understand which part of the connection the selected method actually tests. Different methods may use different requests and targets, so results for the same server may not be directly comparable.

When comparing existing servers, use the same network and test method, and test at roughly the same time. Even if the test succeeds, try the actual destination. If it fails, check the error type rather than assuming all services are unavailable.

Today Widget: quick access and controls

Today Widget provides quick views or controls where supported by the system. Check the relevant settings in the app, then add the widget through the system’s widget management interface. Available formats and actions depend on the current system and the in-app guidance.

If the displayed status doesn’t match what you expect, check the actual connection on Home first, then review On Demand. A widget is a shortcut, not a substitute for server configuration, system authorization, or a full connection test.

iCloud: check what syncs first

Check the iCloud options in Settings and the corresponding iCloud permissions in the system. Follow the current in-app guidance to confirm what syncs; don’t assume servers, configurations, statistics, and system authorization all sync together.

Keep important configurations before enabling sync for the first time or changing devices. If content differs across devices, pause before editing on both. App purchase records and configuration sync are separate processes; system VPN authorization still needs to be confirmed on each relevant device.

Diagnostics

Diagnostics: record, reproduce, verify

Diagnostics provides clues for troubleshooting and is usually available from a related option in Settings. Note the network, selected server, Global Routing mode, and destination when the issue occurs, then enable the diagnostics you need using the current in-app guidance. Not every issue requires a long recording; collecting information around one reproducible request is usually easier to review.

Narrow down the issue in a consistent order

  1. Check the connection basics. Confirm the system network works, the app connection status is as expected, and the existing server parameters haven’t been changed by mistake.
  2. Check DNS resolution. Look for resolution failures or timeouts. If connecting by IP address works but requests by domain name fail, check the DNS path.
  3. Check which rule matched. In Config mode, confirm which policy the request uses, then check which server is selected in the policy group.
  4. Check connection errors. Troubleshoot timeouts, authentication failures, and TLS issues separately; don’t apply the same setting change to every error.
  5. Change one thing, then test again. Recreate the request to the same destination and decide whether to keep or revert the change based on the result.

When you’ve finished troubleshooting, stop any extra recording and keep only the smallest useful excerpt. Before sharing a report, check for server addresses, credentials, subscription URLs, and visited domains. Remove sensitive details, then describe how to reproduce the issue and what you’ve already tried.

Why does Proxy work but Config fail?

Check the active configuration, the rule matched by the destination, the policy group target, and DNS. The two modes may use different paths, so this alone doesn’t prove the server is at fault. Create a new request after making changes so an existing connection doesn’t affect the result.

What should I check if the latency test succeeds?

A test only reports the result for the selected Test Method. Also check DNS resolution for the actual destination, the matched rule, the TLS connection, and access results. Make sure the selected server is the same entry you just tested.

How can I make an increasingly complex setup easier to troubleshoot?

Keep a copy of the current configuration, then return to a known-working baseline. Temporarily simplify On Demand conditions and choose one existing server and one test destination. Restore settings one at a time; don’t clear everything without a backup.

For the complete setup sequence, read the Getting Started Guide. To browse by first launch, configuration management, and everyday maintenance, use the complete guide from beginner to advanced.