Features and Common Settings
From Global Routing to Diagnostics, understand what each setting does and where to find it.
This page covers commonly used Shadowrocket features on iPhone and iPad, explaining in order what each option is, where to find it, how to configure it, and what to watch for. Before making changes, confirm that your server details or subscription have already been imported, and keep a copy of the current Config so you can roll back individual changes if connectivity differs.
How to Read This Guide
Shadowrocket settings do not work as isolated switches. The selected server determines the connection endpoint, Global Routing determines how traffic chooses a policy, rules in Config determine which requests use PROXY, DIRECT, or REJECT, and DNS and On Demand affect resolution and triggering. Understanding them in this order makes it easier to identify what actually changed during troubleshooting.
Layer 1
Confirm that your own server entry is selected in Home, then check that the address, port, protocol, and authentication details are complete. Subscribe updates existing subscription content; it does not change the Global Routing selection.
Layer 2
Config stores rules and related settings. When using the Config mode, requests are matched against DOMAIN, GEOIP, IP-CIDR, and other rules from top to bottom; the first match determines the policy.
Layer 3
DNS, Test Method, On Demand, and Diagnostics control resolution, testing, automatic triggering, and issue isolation. After a change, verify one variable at a time.
Global Routing
Global Routing is one of the first overall controls to check in Home. Chinese-language guides often describe its three modes as configuration, proxy, and direct; the interface labels are Config, Proxy, and Direct. These modes control the overall routing method, not the server protocol.
Config matches requests against the rules in the current configuration file, allowing different requests to receive different policies; Proxy sends connections through the currently selected proxy policy, which is useful for briefly checking whether the server itself works; Direct connects directly, which is useful for pausing rule processing and checking local network behavior. Switching modes affects new connections; existing connections may require reopening the relevant app or page before the change is visible.
Open Home and locate the Global Routing selector. The exact layout may vary with device size, but the labels remain Config, Proxy, and Direct. Before selecting a mode, also confirm the current server entry in Home so that a wrong server is not confused with a wrong routing mode.
For everyday routing by domain, IP address, or geographic condition, Config is usually appropriate. After importing a server, briefly switch to Proxy to rule out the effects of the rules and verify connectivity. To check whether the current Wi-Fi or cellular network works normally, switch to Direct for comparison. After testing, return to the mode that matches your actual use case.
| Chinese description | Interface label | How it works | Best for | Important notes |
|---|---|---|---|---|
| Configuration | Config |
Matches rules in the current configuration file from top to bottom | Everyday rule-based routing and choosing policies by domain or IP conditions | Rule order, the final rule, and policy names all affect the result |
| Proxy | Proxy |
Uses the current proxy policy for new connections | Checking server availability and temporarily excluding rule effects | Not intended to determine whether a specific Config rule is correct |
| Direct | Direct |
Connects directly to the destination for new connections | Checking the local network and comparing connection behavior | After switching, make a new request before evaluating the result |
Config
Rule-based routing consists of match conditions and execution policies. Conditions identify requests; policies determine what happens after a match. Shadowrocket checks rules in the order listed in the Config, so more specific conditions generally belong before broader ones.
DOMAIN matches a complete domain name and is suitable for targeting a single host; DOMAIN-SUFFIX matches a domain suffix and can cover a domain and its subdomains; DOMAIN-KEYWORD matches when a keyword appears in the domain name, so its broader scope requires care to avoid unintended matches. GEOIP matches according to the geographic database result for the destination IP. IP-CIDR and IP-CIDR6 match IPv4 and IPv6 address ranges respectively, while USER-AGENT applies conditions based on the request’s User-Agent.
Open Config, select the current configuration, and review its rules. A rule usually consists of a keyword, a match value, and a policy, for example:
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYThe first line uses PROXY when the domain suffix is example.com; the second uses DIRECT when the corresponding GEOIP condition is met; FINAL handles requests that matched none of the preceding rules. This example illustrates syntax only and should not be applied unchanged to every network environment.
Write precise rules first, broader rules later, and keep a clear final policy at the end. For example, a DOMAIN rule for one host should come before a DOMAIN-SUFFIX or DOMAIN-KEYWORD rule that could also cover it. For IP rules, check whether the destination is IPv4 or IPv6. If the actual connection resolves a domain to different addresses, looking at the domain alone is not enough to explain which rule matched.
Common policies include PROXY, DIRECT, and REJECT. PROXY passes the request to the proxy policy, DIRECT connects directly, and REJECT denies the request. A Config may also reference custom policy-group names; those names must match definitions already present in the Config. Preserve capitalization, punctuation, and comma placement, and avoid introducing extra spaces or full-width symbols when editing manually.
More rules are not necessarily better. When two rules overlap, the earlier rule matches first and later rules do not participate in that decision. If a domain is not handled as expected, check in order: the domain actually requested, the address returned by DNS, rule order, the policy name, and whether Global Routing is really set to Config. After troubleshooting, merge duplicate entries and keep the Config readable.
DOMAIN matches a complete domain exactly; DOMAIN-SUFFIX covers a specified suffix. For finer control, put DOMAIN first.
Handle IPv4 and IPv6 address ranges separately. The range format and prefix length must be accurate to avoid covering more than intended.
The corresponding policy runs when a condition matches. Custom policy groups must use names that already exist in the Config.
Handles requests that matched no earlier rule. The FINAL policy strongly affects overall behavior, so confirm the intended use before changing it.
Add Server · Subscribe
Shadowrocket lets you enter server details manually through Add Server or update your existing subscription through Subscribe. Both methods create server entries that can be selected in Home, but they are maintained differently.
Add Server is suitable for entering one known server. Common protocols include Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. Each protocol requires different fields, typically including Address, Port, Password, or other authentication parameters. Subscribe is suited to a set of entries provided and maintained by your own service provider; when updated, the client reads the subscription content again.
In Home, open the server-add entry point and choose Add Server, Scan QR Code, or Import from Cloud JSON; the subscription entry is usually labeled Subscribe. The protocol type, fields, and transport parameters shown in the interface should correspond to the existing server details one by one. Do not enter parameters for one protocol on another protocol’s page.
When adding a server manually, select the protocol first, enter Address and Port, complete the authentication and transport fields, save, and return to Home to select the entry. To import through Subscribe, paste your existing subscription URL, save it, update the subscription, and then choose the server to use from the returned entries. Before using Scan QR Code, confirm that the QR code comes from your own server details. Import from Cloud JSON is suitable for an already prepared JSON configuration.
If entries change after a subscription update, use the provider’s current returned content as the reference. Manual changes to entries managed by Subscribe may be replaced during the next update. If you need to preserve separate parameters long term, record the original details first, then decide whether to use a manual entry or subscription-based maintenance.
A server name is only a label for identification and does not prove connection quality. During testing, check separately whether the entry completes Connectivity Test, whether the target webpage opens, whether Global Routing is correct, and whether DNS resolves successfully. A latency result reflects the response under one testing condition and is not the same as full browsing speed. Authentication details are sensitive and should be stored only on your own devices and in trusted backups.
On Demand
On Demand triggers or stops connections based on current network conditions. It is useful when you need automatic switching for specific Wi-Fi, cellular, or domain-access conditions. It controls when a connection starts, not the Global Routing or Config rules.
A manual connection requires you to operate the switch in Home; On Demand evaluates preset conditions when the network environment changes and decides whether to trigger. Common criteria include network type, Wi-Fi information, and domain conditions. After a connection is triggered, requests are still handled according to the selected server, Global Routing mode, and Config rules at that time.
Open Settings and find the On Demand options. When enabling the connection feature for the first time, the system may ask you to approve VPN configuration permissions. On Demand rules are evaluated from top to bottom, so keep condition names clear and avoid creating overlapping conditions with opposite meanings.
Start with one condition, such as enabling it for only one network environment, and observe what happens when switching between Wi-Fi and cellular. Once triggering is stable, add domain or network exceptions. After each change, locking and unlocking the device, switching networks, or making a new request may help the system reevaluate the conditions. Record the current network name, Global Routing mode, and selected server during testing.
If the connection switches frequently after On Demand is enabled, first check whether a condition is too broad, whether multiple conditions overlap, and whether the network is repeatedly moving between Wi-Fi and cellular. To determine whether automatic triggering is the cause, temporarily turn off On Demand and compare with a manual connection from Home. After verification, restore the simplified rules.
Establish an observable baseline first.
Observe Wi-Fi and cellular separately.
Add one condition at a time.
Data
Data lets you review traffic handled by Shadowrocket and compare usage across apps or connection stages. It is a client-side statistics view, so interpret it together with the reporting period and current connection status.
Data summarizes upload and download activity observed by the client while it is running. It can show how traffic changed during a period and help confirm whether an action generated substantial transfer or whether a request passed through the client. It does not identify the exact rule matched or independently prove server speed.
Open Data from the bottom navigation. List density may vary by device size; focus on the reporting range, app or connection item, and upload and download directions. If you just changed the Config, start observing from new requests after the change so previously accumulated data does not affect the comparison.
Data is mainly for viewing and does not require frequent adjustment. For a comparison test, note the current values or reset the statistics, perform one clear action such as opening a page, playing content, or running an update, then return to Data to check the increase. Repeat tests under the same network, server, and Global Routing mode whenever possible.
Client, system, and provider-side statistics may use different calculation methods and refresh schedules, so their values may not match exactly. Traffic shown in Data only means that the request passed through the relevant processing path; use Log or Diagnostics to confirm the policy. If usage suddenly increases, first check which foreground and background apps are transferring data, then determine whether it relates to the current test.
Settings
Settings brings together options for resolution, testing, widgets, and synchronization. Changes here may affect every Config, so use the approach of recording the original value, changing one item, and verifying immediately.
What it is: DNS converts domain names into the addresses required for connections. A server test may succeed while webpages still fail to open if resolution fails.
Where to find it: Open the DNS-related item in Settings to review the current resolution settings and available options.
How to configure it: Keep the current working setting whenever possible. If a change is necessary, replace one option at a time and test both domain access and direct IP access to determine whether the issue is in the resolution stage.
What to watch for: DNS and rules can affect each other, especially when GEOIP, IP-CIDR, or IP-CIDR6 depends on the resolved address. After a change, make a new connection instead of relying only on an old page cache.
What it is: Test Method determines how the client tests the server response. Different methods observe different parts of the network path, so their results may differ.
Where to find it: Open Settings, locate Test Method, and review the testing methods available in the current interface.
How to configure it: Use the same method for everyday comparisons. Switch methods only when investigating a specific network restriction, then run Connectivity Test again.
What to watch for: A lower test value does not necessarily mean faster real-world transfer. Webpage loading is also affected by DNS, the route, the destination server, and transport parameters; judge it together with actual access results.
What it is: Today Widget provides a system widget entry for viewing status or performing shortcuts supported by the client.
Where to find it: First review the relevant options in Shadowrocket’s Settings, then add the widget through the system’s widget editor.
How to configure it: After adding it, check that the Config shown by the widget matches the current connection. If the system does not refresh immediately, open Shadowrocket to confirm the status and then check the widget again.
What to watch for: Widget display depends on the system’s refresh schedule and may lag behind the in-app status briefly. Return to Home to verify important operations.
What it is: iCloud syncs data items supported by the client across the same user’s Apple devices.
Where to find it: Open Settings to review the iCloud-related switch, and also confirm the iCloud status in the device’s system settings.
How to configure it: Save the current working Config before enabling sync. Then wait for synchronization on the other device and compare items individually; do not make large changes on both devices at once.
What to watch for: Sync is not an instant mirror. Network conditions, system scheduling, and item types all affect when changes appear. Important authentication details should still be managed carefully by the user.
| Setting | Primary purpose | How to verify after changing it |
|---|---|---|
| DNS | Controls domain-resolution behavior | Visit the domain again and compare it with a direct IP connection |
| Test Method | Determines the Connectivity Test method | Keep the server fixed and repeat the test with the same method |
| Today Widget | Provides status or a shortcut entry in the system widget | Return to Home and compare the widget display with the actual status |
| iCloud | Syncs data items supported by the client | Wait for sync, then compare the contents of both devices item by item |
Diagnostics · Connectivity Test
Diagnostics breaks “cannot access” into more specific questions: Is the local network working? Is the server responding? Did DNS finish resolving? Which policy did the rules select? At what step did the destination connection stop?
Connectivity Test is geared toward quickly confirming a server response; Log records events while the client handles requests; Diagnostics summarizes or performs more targeted checks. Use them together: run a quick test first, reproduce the issue once, then review entries whose timestamps match that request.
Connectivity Test can usually be run from the server list or a related action entry; Log and Diagnostics are found on the relevant client page or in the diagnostic area of Settings. The layout may vary by device, so use the English names when searching.
Before sharing diagnostic content, check whether it includes a server address, authentication details, subscription URL, or personal network name. For self-troubleshooting, keep only the time, target domain, current mode, and change made. If Proxy works but Config does not, focus on the rules; if neither works while Direct does, focus on the server and protocol parameters; if the server test responds but domain access fails, check DNS and the target domain records first.
Check rule order, the FINAL policy, custom policy-group names, and whether the correct Config is selected.
Check the current server, protocol fields, authentication parameters, and Connectivity Test result.
Check DNS, the domain’s actual resolution result, and whether DOMAIN rules match the intended destination.
Recommended Order
When something goes wrong, following a fixed order is more effective than repeatedly toggling switches. The workflow below works for both initial setup and regression checks after updating a Config.
Select a server with complete parameters in Home and run Connectivity Test first. If it was imported through Subscribe, confirm that the update has finished.
Temporarily switch Global Routing to Proxy and make one clear request. This step verifies the connection path only and is not necessarily the final mode.
Confirm which DOMAIN, DOMAIN-SUFFIX, or other condition matches the target domain, and check that the final policy is the expected PROXY, DIRECT, or REJECT.
Handle resolution issues only after the server and rules are clear. After changing DNS, establish a new request and observe both IPv4 and IPv6 conditions.
Make sure manual connections are stable before adding automatic triggers. This separates connection problems from triggering-timing problems.
App and Devices
Shadowrocket is primarily used on iPhone and iPad. Compatibility for Mac, Apple TV, and Apple Vision can be checked on the same App Store product page; system requirements are as listed on the App Store page. Layouts and visible options may vary by device, so this page consistently identifies features by their English interface labels.