Shadowrocket
Features and Settings
Set Global Routing first, then check your servers and rules. Find settings by screen, follow the steps, and change one variable at a time.
Three Global Routing modes
Config, Proxy, and Direct are the three routing modes. Check this setting first, then see whether your rules are taking effect.
What it does: Global Routing determines how traffic handled by the client is routed. It is separate from the connection toggle at the top of Home: the toggle enables or disables the connection, while Global Routing sets the routing mode when connected. An enabled toggle does not mean every request goes through the selected server.
Where to find it: Open Home, find Global Routing, then choose Config, Proxy, or Direct. Config is typically used for routing by domain, IP, and region. To temporarily check whether a server's route works, compare with Proxy. To check your local network, briefly compare with Direct.
| Mode / interface label | How it works | When to use it | Keep in mind |
|---|---|---|---|
| Config | Applies the policies in the currently active configuration rules. | Everyday routing by domain or IP. | Make sure the intended configuration is active and check the rule order. |
| Proxy | Routes intercepted traffic through the proxy. | Temporarily test the current server while bypassing some rule effects. | It cannot fix server timeouts, and it does not mean every system connection is intercepted. |
| Direct | Connects directly to the destination. | Compare the local network path with the proxy path. | A successful direct connection does not prove the server is working. |
How to set it: Note the current selection, choose a mode, then test the same destination on the same network. If Proxy works but Config does not, check the configuration's rules and policies first. If both fail, check the server connection and DNS. Change only one of the server, network, or mode at a time so you can identify the cause.
Keep in mind: Restore your intended mode after testing. If you leave Proxy selected after troubleshooting, requests that should go direct may take a different route. Leaving Direct selected for everyday use may make it seem as though your rules have stopped working.
Rule types and policy selection
What they are: A rule consists of a match condition and an action. Keywords such as DOMAIN and DOMAIN-SUFFIX determine what matches; PROXY, DIRECT, and REJECT determine what happens to a match. These parts are not interchangeable. Rule-based routing also requires Global Routing to be set to Config and the intended configuration file to be active.
Where to find them: Open Config and check the active configuration's [Rule] section. Rules are generally evaluated in order: once an earlier rule matches, later fallback rules are not used. Put specific domain rules before broader rules that could catch them, and usually place FINAL last.
| Keyword | What it matches | What to check |
|---|---|---|
DOMAIN | The exact domain. | Check whether matching this domain alone is sufficient. |
DOMAIN-SUFFIX | The domain and its subdomains. | Check whether the match covers more than intended. |
DOMAIN-KEYWORD | A keyword in the domain. | Check whether the keyword is too short and may match unintended domains. |
GEOIP | The region associated with an IP address. | The IP geolocation database may differ from the actual network exit location. |
IP-CIDR / IP-CIDR6 | An IPv4 or IPv6 address range. | Check the address family and subnet range. |
FINAL | Requests not matched by earlier rules. | Check that the fallback policy is what you expect. |
How to set it: Save a copy of the current configuration, then add a rule for one specific destination. These are syntax examples only; example.com is a placeholder domain, not a server or subscription address. The example sends the domain and its subdomains through PROXY, sets requests matching GEOIP CN to DIRECT, and applies the policy specified by FINAL to everything else.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYKeep in mind: PROXY requires an available server or matching policy. DIRECT bypasses that proxy route, while REJECT denies matching requests. REJECT is not an automatic fallback when a connection fails. After editing, check which rule actually matches—not just whether the line is present. DNS-resolved addresses, IPv6 connections, and earlier rules can all affect the result.
Conditions such as USER-AGENT depend on what request data is visible, so they cannot identify apps across all encrypted connections. If a destination uses multiple domains, a single domain rule cannot tell you how all of the app's traffic is routed.
Subscriptions and server management
Server details, subscription lists, and rule configurations serve different purposes. A successful import does not confirm that a connection works.
What they are: An individual server entry stores details such as its address, port, protocol, and authentication. Subscribe updates the server list in an existing subscription. Config stores rules and global settings. Updating a server list does not necessarily update the active rules file, and switching configurations does not necessarily change the default server.
Where to find them: Check the server list on Home. Use Add Server to enter your own server details, or Scan QR Code to import information you already have. To add a subscription, choose Subscribe in the current interface and enter your own subscription URL. Menus vary by platform; after adding anything, return to Home and check the list.
How to set it up: When entering details manually, choose the protocol specified by your server provider, then check the address, port, and authentication fields one by one. The fields for Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2 are not interchangeable. Match TLS, transport, and server name settings to your existing details; do not guess the protocol from the port alone.
- Make sure the subscription URL is complete. Check for spaces, line breaks, or missing query parameters when copying it.
- After importing, update the list and check that the expected servers appear. If the update fails, note the error before deleting the old list.
- Choose the default server on Home, check its selection mark, then run Connectivity Test.
- Keep one verified server as a baseline. Compare other servers one at a time so you can undo changes if needed.
Keep in mind: Subscription URLs may contain account-identifying information. Redact them from screenshots and logs, and never post the full URL in a public comment. An update may overwrite entries in that subscription group, so check whether manual changes will be replaced next time. Connectivity Test results only indicate reachability under that test method; verify by opening the destination itself.
On Demand connections
What it does: On Demand triggers connection behavior based on network conditions supported by the system. It controls when to connect; Global Routing controls how traffic is routed after connecting. It does not repair an unavailable server or an expired subscription.
Where to find it: Look for On Demand and its conditions in Settings. Available conditions vary by system. Review the options shown before enabling them; do not assume another platform offers the same conditions.
How to set it up: First confirm that the server and rules work with a manual connection. Then add the network condition you want to trigger a connection. Add one condition at a time, then switch between Wi-Fi and cellular to check whether the connection starts or ends as expected. If the interface supports exceptions for specific networks, check those alongside the general conditions to avoid conflicts.
Keep in mind: If the connection comes back after you turn it off manually, an On Demand condition may still be active; the toggle may be working normally. To temporarily stop automatic connections, check On Demand rather than repeatedly switching the Home toggle. If the network changes frequently, watch for repeated reconnects and distinguish On Demand triggers from system sleep or server disconnections. The status bar icon alone may not explain the cause.
Data usage statistics
Use these figures to observe connection changes and traffic trends; they are not a substitute for measurements from your network provider or server.
What it shows: Data displays traffic and connection details within the range the client can record. It can help show when data was transferred and whether uploads or downloads occurred after connecting. Treat it as a diagnostic aid, not a complete usage statement for every device. Traffic bypassing the system proxy and differences in measurement methods can affect the figures.
Where to find it: Open Data and check the displayed range and time period before viewing the available details. Items vary by platform and version. When comparing figures, use the same range; do not compare a single connection's count with a cumulative total.
How to use it: To investigate a destination, note the current figures, visit it once, and check the increase. If the interface offers a reset, save any records you need first; reconnecting may not clear all accumulated data. Check request logs alongside the matching policy to determine whether traffic took the expected route.
Keep in mind: Changes in upload and download counts show that data was transferred, not that a page loaded completely. Tests, background sync, and retries also use traffic. If requests keep retrying but the page does not load, check DNS, connection errors, and rules as well. For unexpected battery or data use, compare results with background tasks disabled, then identify the specific connections rather than blaming a single toggle.
Common Settings
Note the original value before changing one setting at a time. Check related parameters in the active configuration too.
DNS: Check for resolution failures first
What it is and where to find it: DNS resolves domain names to addresses needed for connections. Look for DNS options in Settings, and check whether Config's [General] section includes parameters such as dns-server. If DNS options appear in both Settings and the configuration file, confirm which settings are active; changing one place may not cover every case.
How to set it: Note the current value, test several specific domains, then decide whether to change the resolution method. If all servers fail only when accessed by domain name, DNS is a key area to check. If only one destination fails, also check its rule and service status. Retest the same destination after changing a setting, keeping in mind that cached results may affect the outcome.
Keep in mind: The resolver itself must be reachable. Do not add an address found at random to your configuration, or treat DNS as a general fix for authentication errors or port timeouts. For IPv6, check both the address returned and whether IPv6 is reachable on the current network.
Test Method: Keep comparisons consistent
What it is and where to find it: Test Method in Settings determines how connectivity tests are run. Different methods examine different parts of the route, so results cannot be compared without accounting for the method used. A failure with one method alone does not prove that all real requests will fail.
How to set it: Choose a method supported by the current interface that suits your troubleshooting goal, then run Connectivity Test on Home. When comparing servers, keep the method, network, and test destination the same. Repeat if needed, then verify with an actual connection.
Keep in mind: Test duration is not download speed, and a single result does not prove long-term reliability. Do not keep changing methods just to get a lower number while ignoring whether the connection actually works.
Today Widget: Quick access and status checks
What it is and where to find it: Today Widget provides quick controls when supported by the system. Look for the relevant option in Settings, then check the system's widget screen to see whether it can be added. Widget formats and background behavior vary across system versions.
How to set it up and what to keep in mind: Add the widget only if the current system provides the option, then return to Home to confirm the actual status. Widgets may take time to refresh, so their displayed state may not reflect the current connection. If the option is unavailable, follow the system's capabilities; there is no need to repeatedly reset your configuration.
iCloud: Protect local configurations before syncing
What it is and where to find it: On Apple devices that support iCloud, the related options in Settings manage cloud sync for the data supported by the app. This does not mean every setting, connection status, and log is copied in full to another device.
How to set it up: Save important configurations first. Confirm that you are signed in to the intended account, iCloud is available, and the app has permission. When using another device for the first time, wait for sync to finish and check the file contents, active settings, and default server before replacing any local files.
Keep in mind: Sync is not a separate backup; deletions and replacements may sync too. If the devices show different contents, keep a copy from each before comparing them. Avoid editing the same file on both devices at once. Configuration migration between platforms is not necessarily handled automatically by iCloud.
Diagnostics: Capture a reproducible error
What it is and where to find it: Look for Diagnostics and available diagnostic tools in Settings to collect information about connection issues. Review logs around a specific, repeatable issue; long, mixed logs can make it hard to identify which error relates to the problem.
How to use it: Note the network type, Global Routing mode, current server, and destination. Reproduce the issue once, then review DNS, connection, or rule entries from around that time. Identify whether the problem is DNS resolution, a connection timeout, an authentication error, or an unexpected rule match before following the relevant troubleshooting steps.
Keep in mind: Redact subscription URLs, authentication details, and other personal information before sharing diagnostics. When finished, restore the logging level you normally need to avoid accumulating unnecessary logs. For symptom-based steps, see the Troubleshooting guide.
Troubleshooting order after changing settings
Features depend on one another. Changing rules usually will not fix an unreachable server; if Global Routing is not set to Config, editing [Rule] alone may not produce the expected result. Verify settings in this order so you can connect each result to a specific change.
- Check the network. Note whether you are on Wi-Fi or cellular, and confirm the network itself works. Do not switch networks while comparing results.
- Check the server. On Home, verify the selected default server and its settings. Run Connectivity Test to establish a baseline, then try the destination itself.
- Check the routing mode. Review Global Routing. If using Config, verify which configuration file is active—not just whether a file with the expected name exists.
- Check DNS and rule matches. Review DNS results, rule order, and the final policy. Change one relevant rule at a time, save, and retest.
- Check automatic behavior. Once manual connections work, test On Demand, sync, and quick-access controls to avoid confusing results from multiple automatic actions.
- Keep changes that work. Note exactly what resolved the issue. If a change does not help, revert it before testing the next option instead of stacking uncertain settings.
For your first setup, follow the setup guide to import details and connect. If an error can be reproduced consistently, use the Troubleshooting guide to check the symptoms. Common settings questions are covered in the FAQ; there is no need to reconfigure every feature to investigate one destination.