Shadowrocket
Proxy Modes and Common Settings

Choose Config for everyday rule-based routing, Proxy to temporarily check the proxy route, or Direct to check direct connectivity. These options do not add servers or update subscriptions. On Home, open Global Routing and select a mode, then return to Home to check the default server and connection toggle. After switching modes, retry the target request rather than treating an existing long-lived connection as a result of the new mode.

The interface labels for the three modes are Config, Proxy, and Direct. Config mode is related to the Config tab at the bottom of the screen, but they are different actions: the mode controls how traffic is handled, while the tab is for managing configuration files. Importing a configuration file does not mean it is active or that Global Routing is set to Config.

A mode does not guarantee a successful connection

Proxy still requires valid server details and network reachability; Config still depends on correct rules; Direct is also affected by the current network and the destination service. When troubleshooting, note the original mode and change one variable at a time. If Proxy works but Config does not, check rule matches and DNS before reimporting all your servers.

After comparing modes, switch back to the one that fits your everyday use. Leaving a temporary test mode active can make Data traffic totals, local network access, and later troubleshooting results differ from what you expect.

Rule-based routing uses the configuration actually selected on the Config screen. Before editing, keep a recoverable copy, inspect the configuration’s [Rule] section, and confirm that Global Routing on Home is set to Config. In general, put narrowly scoped rules earlier so the final rule handles requests that did not match anything above it.

DOMAIN matches an exact domain name, DOMAIN-SUFFIX matches a specified domain suffix and its subdomains, and DOMAIN-KEYWORD matches a keyword in the domain name. Address rules include IP-CIDR and IP-CIDR6 for their respective address ranges. GEOIP matches based on IP geolocation data; results depend on the database and resolved address and do not conclusively establish where a destination service is hosted.

In a policy, PROXY means use the proxy route, DIRECT means connect directly, and REJECT means reject the request. These are rule actions, not protocol names. If a configuration uses custom policy groups, a rule may point to a group name instead; check the group’s selection too, rather than relying only on whether PROXY appears in the rule.

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

Narrow the Match Before Changing the Final Policy

When testing a rule, first identify whether the target is an exact domain, a subdomain, or an IP address. Keyword rules can match a broad range and catch domains you did not intend to include; address rules may require DNS resolution first. Avoid adding multiple overlapping rules at once, or it will be difficult to tell which one fixed the issue.

USER-AGENT depends on the relevant request information being available, so it is not a reliable general-purpose way to cover all app traffic. If you cannot confirm the request information, check domain- or address-based matches first. For more rule keywords, see the Quick Reference; for the complete configuration process, see the Full Manual.

On Home, use Add Server to enter your own server details. If you have a subscription link from a provider, select Subscribe in the interface and enter the link. Before importing, identify the type of information you have: a single server’s sharing details, a subscription link, and a full configuration file are different things and cannot be entered in the same field just because they are all text.

When entering details manually, select the matching protocol first, then check the address, port, authentication details, and transport fields. Shadowsocks, VMess, VLESS, Trojan, WireGuard, Hysteria2, HTTP, and SOCKS5 do not all use the same parameters. Do not apply one protocol’s setup fields to another. If details are missing, ask the original provider rather than guessing.

Importing, Updating, and Selecting Are Separate Steps

After importing, check that the expected entry appears on Home, then select the default server you want to use and confirm the selection indicator. Updating a subscription refreshes its server list; it does not verify that every entry works or necessarily change the current default server. Check the selected entry again after an update, especially if names or the number of entries have changed.

If an update fails, check whether the current network can reach the subscription URL, whether the link is complete, and whether the service is still active. Subscription links may contain access credentials, so do not share the full URL in public screenshots, logs, or comments. Before deleting an old subscription, confirm which entries belong to it so you do not lose configuration details you still need.

A server test reflects only the method used and the network conditions at that time. A lower number does not mean every destination will be faster, and a test response does not confirm that authentication, transport, and the full route to the destination service are working. After selecting an entry, connect and test access to the actual destination.

On Demand triggers connection behavior under configured conditions; it does not choose correct server details or routing rules for you. In Settings, open On Demand and review the existing conditions before configuring Wi-Fi, cellular, or domain-related conditions for your needs. Available fields depend on the current in-app interface.

Before configuring On Demand, use the connection toggle on Home to verify the setup manually: the default server is valid, Global Routing is set as intended, and the target is reachable. Then add one condition at a time. For example, check the exact Wi-Fi network name when setting a Wi-Fi condition. For a domain condition, be clear about what triggers it; do not confuse an automatic connection condition with a routing rule in [Rule].

Check Automatic Connections Separately from Traffic Routing

On Demand controls when a connection is established or triggered. Global Routing and configuration rules determine how traffic is handled after the connection is established. A successful automatic connection does not prove that a domain is routed through PROXY; likewise, an existing working connection does not confirm that automatic triggers have been tested.

For testing, switch to the relevant network, observe the connection status, then make a request related to the condition. If several conditions are set, check their order and actions so a broad condition does not override a more specific one. If the connection turns back on after you switch it off, temporarily disable On Demand for comparison and check the system VPN status. Repeatedly changing server details will not fix an automatic trigger issue.

Device sleep, network changes, and system scheduling can affect observed connection behavior. Record the trigger condition, network type, and result, then reproduce the issue one step at a time. For more on Wi-Fi, cellular, and domain conditions, see Setting Up On Demand.

The Data screen shows traffic statistics and related connection information provided by the app. Before troubleshooting, note the displayed time range, categories, and entries, then make a specific test request and check for a corresponding change. Different statistics may cover different accumulation periods; follow the labels in the interface rather than assuming a total represents the traffic from one request.

To compare Config and Proxy, note the current mode and statistics first, then make the same request in each mode. If an entry includes the destination, policy, or server, compare it with the expected rule. An increase in total traffic alone does not confirm that a particular rule matched; background tasks may also generate requests.

Use Statistics to Troubleshoot, Not Estimate Plan Balance

App records and provider billing can differ in reporting periods, protocol overhead, and billing methods. Data figures should not be treated as a subscription balance, nor do they prove that all traffic to a destination used the same route. Check your provider’s own records for account usage.

Before clearing records or resetting statistics, save any information needed for troubleshooting. When sharing records, redact server addresses, account details, and other sensitive fields. The time of the issue, current mode, protocol, and symptoms are usually enough to help narrow down the cause.

DNS: Check Where It Takes Effect

DNS resolves domain names to addresses and can affect how some address-based rules are evaluated. When checking DNS options in Settings, also check whether the active Config specifies DNS parameters; changing one screen alone does not guarantee that all resolution behavior has changed. A configuration can use system resolution with dns-server = system.

For custom resolution, use a format supported by the current app and confirm that the DNS service is reachable on your network. DNS over HTTPS changes how DNS requests are transported; it does not fix server authentication errors. After making changes, reconnect and visit the target, checking resolution and connection separately. For details, see the DNS Settings Guide.

Test Method: Know What the Latency Test Measures

Check the current test method under Test Method in Settings, then test an existing server from Home. Different methods measure different connection stages, so compare results only with the same method, at roughly the same time, and on the same network. After changing Test Method, do not directly rank the new result against one from a different method.

If the test responds but a webpage will not load, continue by checking authentication details, destination rules, DNS, and the actual request result. If there is no response, distinguish between a restricted test destination and an entirely unavailable server. Ultimately, judge the connection by whether it can reach the destination you need.

Today Widget: Check the Connection Status

Check the Today Widget options in Settings and configure the corresponding widget entry using the method provided by your device’s operating system. It offers quick access to connection features provided by the app; available functions depend on the current app and system interface. Before using it for the first time, select a server on Home and authorize the connection.

After using the widget, return to the app and check the connection toggle and current server. The widget is not a separate connection configuration and does not replace the Global Routing selection. If the expected widget entry is missing, check the system’s widget list and the app’s settings; this does not indicate that a subscription import failed.

iCloud Sync: Syncing Is Not Verification or a Full Backup

Check the iCloud sync options in Settings, and make sure you are signed in to your own Apple Account and have allowed the relevant iCloud access. Sync coverage depends on the items listed in the current app; do not assume connection status, diagnostic records, or all local data will transfer.

After opening the app on another device, check each server, configuration file, and current selection before testing the connection. Keep a copy before deleting or changing configurations in bulk, as sync may carry those changes to other devices. Restoring an app purchase and syncing configuration data are separate processes. For purchase issues, see How to Restore Purchases.

Diagnostics: Gather Information About One Failure

Open Diagnostics in Settings and review the available checks for your current connection environment. Before you begin, note the network type, Global Routing mode, selected server, and destination that failed. Reproduce one specific issue, then review the diagnostic results for that time period. Avoid mixing large amounts of unrelated history into a single troubleshooting session.

Cross-check diagnostics against Connectivity Test on Home, the actual destination request, and records in Data. A single failed log entry does not necessarily mean all connections are failing; likewise, one successful test does not mean every app can connect. Before exporting or sharing diagnostic material, check for subscription links, authentication details, and personal browsing records.

1. Record the current state. Note Global Routing, the selected server, the active configuration, and On Demand conditions. Keep a copy before editing the configuration.
2. Test a manual connection first. Temporarily rule out automatic triggers. On Home, select the default server, turn on the connection, and grant VPN configuration permission when prompted by the system.
3. Then test actual access. Run Connectivity Test and visit the destination you need. Distinguish a test failure from a DNS resolution failure or an unresponsive destination service.
4. Compare modes and rules. If needed, temporarily compare Proxy and Config, checking rule order, the final policy, and DNS. Change one setting at a time.
5. Restore automatic conditions last. Once manual connection and routing work as expected, restore On Demand and verify its triggers by switching networks.

If you still cannot identify the issue, keep the steps needed to reproduce it to a minimum and check each stage in the Full Manual. For first-time setup, start with the Connection Guide. For purchases, system requirements, and compatibility, see the App Store Listing Verification page. System requirements and device compatibility are as listed on the App Store page.