Shadowrocket Features
and Common Settings Checklist
First check how traffic is routed, then adjust connection conditions and diagnostic options. Change one setting at a time and verify it against the same target.
This page focuses on using Shadowrocket on iPhone and iPad. Shadowrocket is a paid client for Apple platforms and is available exclusively on the App Store. Check the App Store listing for system requirements.
View the first connection steps →Global Routing: Config, Proxy, and Direct
Global Routing is on Home. It determines whether connections follow the current configuration or use a single routing path. The three options are Config, Proxy, and Direct. These are routing modes, not server protocols or network quality levels. Before switching modes, check the selected server on Home and the configuration file currently in use under Config.
| Mode | How It Works | When to Use It | What to Check |
|---|---|---|---|
| Config | Selects a policy according to the rules in the current configuration file. | When traffic needs to be routed by domain or destination address. | Current configuration, rule order, and final policy. |
| Proxy | Routes connections normally controlled by this mode through the proxy path. | To check temporarily whether the selected server can handle a connection to a destination. | Server availability, access to the destination, and logs. |
| Direct | Routes connections directly through the local network. | To check whether the local network can reach the same destination. | Local network status; this does not disable the system VPN configuration. |
For everyday rule-based routing, select Config. If a website will not load, note the current mode, switch temporarily to Proxy, and test the same site again. If it works with Proxy but not Config, check the matching rule and policy. To see whether the local network itself is causing the problem, compare with Direct. Restore the original mode when testing is complete; do not treat a temporary test as a permanent setting.
Switching modes does not fill in incorrect server fields or fix expired connection details. A connected indicator only means the connection has reached the corresponding state; it does not guarantee that every destination is reachable. When testing, check the website, request logs, and error messages rather than relying on the toggle color alone.
Rule-Based Routing: Match Conditions and Policies
Rule-based routing separates “which destination to access” from “which path to use.” Open Config, confirm the selected file, then review or edit its [Rule] section. These rules are the main reference when troubleshooting routing behavior with Global Routing set to Config. Save a copy of the original file before making changes, and do not confuse subscriptions, servers, and configuration files with one another.
DOMAIN matches an exact domain; DOMAIN-SUFFIX matches a domain suffix and its subdomains; DOMAIN-KEYWORD matches a keyword in the domain. IP-CIDR and IP-CIDR6 specify IPv4 and IPv6 ranges, respectively; GEOIP uses IP geolocation data. USER-AGENT relies on available request information, so do not assume it covers every encrypted connection.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,ads.example.net,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYThese are syntax examples, not a complete configuration for every network. PROXY routes matching traffic through a proxy, DIRECT routes it directly, and REJECT blocks matching connections. A configuration may also reference custom policy groups; check that each group exists and which option is selected within it. Rule policies and Global Routing options are separate layers, so similar names do not mean they are the same setting.
Rules are usually evaluated in order. Put more specific conditions before broader ones, and place the fallback FINAL rule at the end. After adding a rule, test only the relevant destination and check which rule matched. If many websites stop working after a change, restore the backup first, then check whether the fallback policy or a referenced name was changed by mistake. For rule keywords, see the Quick Reference.
Manage Subscriptions and Servers
The SERVER list on Home lets you select an existing server. Each server entry stores a protocol and connection details; a subscription imports and updates server information in bulk. A successful subscription update only means the list was retrieved and parsed. It does not confirm that every entry is reachable or that the correct rules file is selected.
Add Server and Importing Existing Details
Open Add Server from the add option on Home. Select Type, then enter the address, port, and authentication details from your own server information. Fields differ across Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. If your details include a transport method, TLS, server name, or path, enter them exactly as provided; do not fill them in based on assumptions from another protocol.
When importing with Scan QR Code or the clipboard, open the entry afterward and check its type, address, and port. QR codes may contain sensitive authentication details, so do not share them in public screenshots. Import is complete when the expected entry appears in the list with all fields present; test the connection separately to confirm access to a destination.
Update Subscriptions and Organize the List
If you already have a subscription, select Subscribe in Add Server and enter your own subscription URL. Before updating, check that the address is complete, including for spaces, line breaks, or expired parameters introduced during copying. Afterward, check that the groups and entries look as expected, then select the server you want to use. Before deleting a subscription group, make sure you have kept its original URL and any manual entries you need.
A server test result is not the same as real-world browsing speed or reachability to every destination. Compare results using the same network and Test Method, then verify with an actual connection. Subscription URLs may grant access to an account; do not include them in public logs or support messages. If an update fails, check the error and local network first, then verify the address for your existing service.
On Demand: Connect on Demand
On Demand triggers VPN connection behavior according to configured network conditions. It has a different role from Global Routing: On Demand determines when to connect, while Global Routing determines how traffic is handled once connected. Find On Demand in Settings, then check the master switch and the available network conditions and rules.
When setting it up for the first time, turn off automatic triggers and complete a manual connection test. Once the server and configuration are confirmed to work, enable the conditions you need. If behavior depends on a Wi-Fi network, verify the network name; if it applies to cellular, test that separately too. Available conditions depend on the current app interface. Do not assume a result on one network applies to another.
After configuring On Demand, disconnect, switch to a network that should trigger it, and check whether Home shows the expected status. Then switch to a network that should not trigger it and test again. If the connection starts automatically after you turn it off manually, check On Demand and the system VPN settings for on-demand behavior; do not repeatedly delete the configuration. On Demand can act only on existing conditions and cannot tell whether server details are still valid.
Data: Traffic Statistics and What They Show
Data shows traffic recorded by the client. Open Data and first check the time range, upload and download directions, and whether figures are grouped by server or another category. Different statistics may use different start times and measurement methods. Follow the labels in the interface; do not assume the total represents traffic from a single website visit.
To monitor an action, note the current readings, perform one specific task—for example, open a known webpage—then return to Data and compare. Background sync, media preloading, and requests from other apps may also use traffic. Changes in the readings can help identify ongoing transfers, but cannot by themselves prove the exact usage of a particular app.
Before clearing or resetting statistics, record any data you need to keep and confirm what the action affects. Client statistics may differ from usage records for your existing service because of different time periods, transmission overhead, and calculation methods. Refer to your service records for quota usage. Data is not a speed test: high cumulative traffic does not mean the current connection is fast.
Settings: DNS, Testing, and Sync
Settings contains app-level options, but not every network parameter is controlled there. Some are set by files in Config. Before troubleshooting, identify where a setting comes from and what it affects. After switching configuration files, check the relevant parameters again instead of assuming earlier changes still apply.
DNS: Check Resolution, Then the Route
DNS resolves domain names to destination addresses. If a server test succeeds but a webpage will not load, first check DNS-related entries in the current configuration, then review the DNS options actually available in Settings. Check whether the DNS server is reachable over the current network and whether the configuration overrides it. Avoid replacing all DNS settings at once, or it will be hard to identify the cause.
After saving the original settings, retest a domain that was failing and check whether the resolution error persists. Successful DNS resolution does not guarantee that the subsequent connection will work. If an address is returned but the connection times out, continue by checking the server route and rules. For IPv6, also consider local network support; do not attribute every domain issue to the same toggle.
Test Method: Know What the Test Measures
Check Test Method in Settings and note the selected method and any related parameters shown in the interface. Different methods measure different stages, so results for the same server cannot be ranked directly across methods. After changing the method, run Connectivity Test again from Home and record the network conditions.
Test results help identify which stage of a connection may be failing. A successful test does not guarantee that authentication, DNS, the destination website, or sustained transfers will work. A timeout may also be caused by the test destination itself. To compare servers, keep the method and network consistent, then verify with actual browsing.
Today Widget: Check Display and Available Options
Today Widget settings control display or quick actions related to system widgets. First check the options available in Settings, then look in the system widget manager to see whether the widget can be added and displayed. Available options depend on the device's system and current app support; check the actual interface.
If the widget status does not update promptly, open the app and check the actual status on Home, then review the system widget configuration. Do not assume a connection is active based only on the widget text, or treat a stale widget as evidence of a server problem.
iCloud Sync: Check What Is Included
Review iCloud options in Settings and confirm that the corresponding iCloud permissions are enabled on the device. Before enabling sync, save your local configuration and read the interface descriptions to see which data is included. Do not assume the sync toggle automatically transfers all server credentials, historical statistics, or system VPN permissions.
After opening the app on another device, check which entries appear, the selected configuration, and the server, then run a manual connection test. If information does not match, stop editing on multiple devices at once. Keep the content you need from each device, then check the sync status. Continue to treat sensitive subscription URLs and authentication details as private.
Diagnostics: Record Symptoms and Retest Results
Diagnostics provides access to diagnostic information. Open the relevant option in Settings and use the tools shown in the current interface to inspect or record the issue. Start with a reproducible problem rather than changing many settings at once. Note the network, Global Routing mode, selected server, current configuration, and destination where the failure occurs.
- Keep reproduction conditions consistent. Use the same network and destination, and record whether the error is a DNS resolution failure, connection timeout, or interruption after connecting.
- Narrow down the cause. Check Connectivity Test, then review DNS resolution and rule matches. If only one destination is affected, start with the rules and route for that destination.
- Change one setting at a time. Repeat the same action after each change and compare the result. If it does not help, restore the original value before checking the next setting.
- Keep relevant evidence. Record when the failure occurred, related errors, and what changed. Do not share a complete configuration containing authentication details.
Before sharing diagnostic text, remove access parameters from subscription URLs, passwords, UUIDs, keys, and any other identifying private information. A single error in the logs does not mean the entire connection is unusable; consider when it occurred and what actually happened. Once the issue is reproducible, continue with the Troubleshooting Manual rather than repeatedly reinstalling or overwriting all settings.