This page focuses on how Shadowrocket works on iPhone and iPad. Navigation may vary by device and app version; use the names and options shown in the app. For system requirements, refer to the App Store listing. Before changing settings, import your existing server details and authorize the connection.
The app is a one-time purchase; it does not include a service plan. Shadowrocket is a paid, closed-source app available exclusively on the App Store. This guide assumes you already have your own subscription or server details; get subscription links from your provider. This site does not provide, sell, or recommend servers or subscriptions.
01 / ROUTING
Global Routing: Config, Proxy, and Direct
Global Routing determines how requests are handled overall. In Home, open Global Routing and choose Config, Proxy, or Direct. This choice is neither a server protocol nor a substitute for the connection switch: server parameters determine how to connect, while Global Routing determines how traffic is handled.
| Mode | How it works | When to use it | What to check |
|---|---|---|---|
| Config | Handles requests according to the rules and policies in the active configuration. | Everyday routing based on domains, addresses, and other conditions. | Active configuration, rule order, matching policies, and FINAL. |
| Proxy | Routes requests handled by the app through a proxy, subject to any applicable exclusions. | Briefly check whether the selected server can handle a target request. | Selected server, protocol parameters, and proxy-related settings. |
| Direct | Handles requests managed by the app using a direct connection. | Compare direct access on the current network to narrow down the cause of an issue. | Local network, DNS results, and target service status. |
For everyday use, check Config first
If you already have a trusted configuration file, open Config to confirm which file is in use, then return to Home and select Global Routing → Config. Importing a file into the list does not make it active. PROXY in a rule does not always refer to the same server: if the configuration uses a policy group, check which server is selected in that group.
Use Proxy and Direct for comparison
If a website will not load, keep other conditions unchanged and compare the results with Proxy and Direct. If Proxy works but Config does not, first check whether a rule sends the request to the wrong policy. If both modes fail, check DNS, the current network, and the target service. After testing, restore your previous mode so temporary troubleshooting settings do not become your everyday setup. No mode guarantees that all system traffic follows the same route; check the actual connection records.
02 / RULE
Rule routing: match conditions and policies
Rules are a list of conditions in Config that describe how requests are handled. With Global Routing → Config selected, rules are typically matched from top to bottom, and the corresponding policy applies when a rule matches. Both the rule content and its position matter. Review the active rules in Config or check the entries in the [Rule] section of the configuration text. Keep a copy of the original file before editing.
| Keyword | What it matches | Notes |
|---|---|---|
DOMAIN | A complete domain name. | Use to specify a single hostname exactly. |
DOMAIN-SUFFIX | A domain and its subdomains. | Useful for covering a domain and its subdomains without listing each one separately. |
DOMAIN-KEYWORD | A keyword in a domain name. | Can match broadly; avoid short or ambiguous terms. |
IP-CIDR / IP-CIDR6 | An IPv4 or IPv6 address range. | DNS results and when a lookup occurs can affect how address-based rules are evaluated. |
GEOIP | The region assigned to an address in the database. | Database geolocation does not indicate where a service's content is hosted, and edge addresses can change. |
USER-AGENT | Available User-Agent information. | Depends on traffic type and visible information; it is not a general-purpose way to identify apps. |
FINAL | Requests that did not match an earlier rule. | Usually placed at the end of the rule list as a fallback. |
What PROXY, DIRECT, and REJECT mean
PROXY routes a request through a proxy policy, DIRECT connects directly, and REJECT denies the request. These are actions, not domains or server protocols. The example below illustrates rule order and syntax; its example domains are not service endpoints. Before copying a rule, make sure you understand its target and scope.
[Rule]
DOMAIN,ads.example.net,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYPut specific exception rules before broader rules. If a domain matches an earlier DOMAIN-SUFFIX rule, a later DOMAIN rule may never be reached. After editing, check the actual request records to see which rule matched; a website loading successfully does not prove the entire configuration is correct. Remote configuration updates may overwrite local edits, so keep your own rules separate from the remote file.
03 / SERVER
Subscribe and Add Server: managing subscriptions and servers
Server entries store the parameters needed to connect; subscriptions let you retrieve and update multiple entries. Neither is the same as a Config rule file. The server list in Home is where you choose a connection. Use Add Server to add an individual server, or use the Subscribe option provided by the app to import an existing subscription. Navigation may vary by layout; follow the labels shown in the app.
Know the difference between a subscription link and a single server
Get a subscription link from your provider, paste the full URL into the relevant Subscribe or URL field, save it, and update the subscription. Then check that the expected entries appear. If you have parameters for a single server, choose the appropriate Type in Add Server and enter the address, port, and authentication details. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, and WireGuard use different fields; changing only the protocol name while keeping all the previous protocol's parameters will not work.
TLS, SNI, and transport settings must match the server requirements. WireGuard's Address, Endpoint, and key fields each serve a different purpose. If you do not know a field's value, keep the existing value rather than guessing. For the full import process, see the first connection guide; for WireGuard fields, see WireGuard parameter guide.
An update does not replace every setting
A subscription update usually refreshes the server list it manages. It does not necessarily update the active Config, change Global Routing, or select the best server. After updating, check the entry names, current selection, and test results. Subscription-managed entries may be regenerated during the next update, so back up any local edits first. Before deleting a subscription, confirm whether you still need its server entries.
04 / ON DEMAND
On Demand: connect based on network conditions
On Demand triggers VPN connection behavior based on network conditions you define. It controls when a connection is attempted, not which policy handles a request. Review the conditions and actions on the app's On Demand screen. Routing is still controlled by Global Routing and the active configuration.
First confirm that a manual connection works, then add On Demand conditions one at a time. For example, if you want different behavior on different Wi-Fi networks, check the network name, match scope, and associated action. Test on networks that do and do not match the condition. A condition's name may look right even when the current network does not meet it; avoid stacking several similar conditions at the outset.
When enabled, the system may start a connection again whenever the conditions are met, so a connection that resumes after you disconnect manually is not necessarily a problem. For a complete test with On Demand disabled, first confirm it is turned off, then check the system VPN status. Network changes, system scheduling, and device permissions can affect when it triggers; On Demand does not guarantee an immediate connection after every network change. If the device has other VPN configurations, confirm which one is active.
05 / DATA
Data: traffic stats and request clues
Data displays traffic statistics recorded by the app and can provide clues during troubleshooting. Open Data and check what is being counted, the time range, and the units before comparing upload and download changes. Different screens may show data for the connection period or another time range. A figure should not be treated as billing usage or as all traffic from a particular app.
To check a specific request, note the counters in Data, perform that action once, then return and check for a change. If the counters do not change, check the connection switch, Global Routing, and whether the request falls within the app's handling scope. If the counters increase but the request fails, that does not prove the server is working; check DNS, connection, and response stages as well.
The app's counters may include connection overhead and may use different accounting from your provider's totals by account, billing period, or traffic direction. Data is not a substitute for your provider's usage records. Before clearing or resetting counters, read the confirmation prompt and keep any data you need for troubleshooting. Traffic volume and request success are separate measures; an increase in the counters does not prove that a page loaded completely.
06 / SETTINGS
Common Settings: DNS, tests, and sync
Settings can have different scopes, and some options work together with the active Config to determine behavior. The sections below explain what each option does without prescribing one set of values for every network. Use the defaults and options shown in the app. Record the original value before making a change, and change one factor at a time.
DNS: check the resolution path first
DNS translates domain names into addresses. A lookup failure may appear as a connection timeout or cause address-based rules to behave unexpectedly. Check the DNS-related options shown in Settings and review any DNS settings in the active Config. Do not assume that changing one option in Settings overrides every behavior specified in the configuration file.
Before changing DNS, identify your goal: resolving lookup timeouts, checking returned addresses, or changing the path DNS requests take. Follow your provider's requirements if it has any; otherwise, keep the current working setup and test changes one at a time. Encrypted DNS describes how lookup requests are transmitted; it does not automatically change the routing of all app traffic. If a page fails, distinguish between a domain that did not resolve and an address that resolved but could not connect. This helps avoid masking the actual problem by repeatedly changing DNS settings.
Test Method: compare results on the same basis
Test Method selects how connection tests are performed. Check it in Settings, then use Connectivity Test in Home to test your existing servers. Test methods can cover different stages: some focus on transport connectivity, while others also depend on a response from the test target. Use the methods and targets available in your current app version.
When comparing servers, keep the test method, target, and local network the same. A lower latency figure does not mean higher throughput or guarantee a stable long-lived connection. A timeout may also mean the test target is temporarily unreachable. Test a few entries first, then verify with the services you actually need; do not treat one result as a permanent ranking.
Today Widget: a shortcut, not a substitute for checking the app
Today Widget provides the quick view or actions supported by the system. Check the related settings in the app, then add an available widget from the corresponding system editing screen. Widget layouts and actions depend on the system version and app support; do not assume they match across devices.
After using a widget, return to Home to confirm the selected server, connection status, and Global Routing mode. The widget may not refresh immediately. If its display has not changed, check the main screen and system VPN status rather than repeatedly toggling the connection. To pause automatic connections, also check On Demand.
iCloud sync: keep a local copy before syncing
iCloud sync transfers app content supported for syncing between compatible devices. Confirm that each device is signed in to the intended Apple Account and allows the app to use iCloud, then check the sync options in Settings. See the app's guidance for which items sync and when. Do not assume that servers, configurations, statistics, and every setting are all copied.
Back up any configurations you want to keep before enabling sync for the first time or switching devices. If you have made changes on both devices, avoid repeatedly saving on both at once. Decide which copy to keep, then check the result on the other device. A completed sync does not establish a connection: on the new device, check the active configuration, selected server, and system VPN authorization. Purchase history and configuration data are separate; restoring the purchased app does not restore all local settings.
Diagnostics: gather clues by failure stage
Diagnostics helps check stages such as DNS resolution, connection, and request handling. Look for Diagnostics or the corresponding diagnostic option in Settings, choose what to check, and run a relevant test. Option names may vary by app version. A successful diagnostic confirms only the stage it tests; it does not mean every target request will succeed.
Record the network type, Global Routing mode, selected server, and error message at the time of the issue. Use available Log information to identify the stage where it failed. If you need more detail, enable it briefly and reproduce the issue once, then restore a suitable logging level for everyday use. Logs may contain domains, addresses, and connection parameters; redact them before sharing. Do not send a screenshot of your full configuration for troubleshooting.
07 / CHECK
What to check after changing settings
Changing rules, servers, DNS, and the test method at the same time makes results hard to compare. Follow the steps below and record the result after each one. If a change does not help, restore the original value before moving on.
- Check the connection basics.Check the connection status in Home and system VPN authorization. Confirm that the selected server is a valid entry from your existing subscription or your own configuration.
- Check Global Routing.Briefly compare Config, Proxy, and Direct to distinguish rule issues from connection-path issues, then restore the original mode.
- Check the active Config.Verify the active file, rule order, policy group selection, and FINAL to avoid editing a file that is not in use.
- Check DNS and test conditions.Review DNS results, keep Test Method and the test target consistent, then compare Connectivity Test results with real requests.
- Check automation and sync.See whether On Demand restarted the connection and whether iCloud brought in changes from another device, then check Data and Diagnostics again.
For details on what each setting affects, see the Settings reference. If a single server cannot connect, use the server timeout checklist to review protocol parameters and system time. Reproducible test steps are more useful for finding the cause than repeatedly replacing the entire configuration.