Shadowrocket
Settings and How to Choose Values

01 / Scope and Defaults

Settings: Baseline and Change Order

Distinguish App Settings, Config, and Server Parameters

Settings contains options that control client behavior, but a connection is not governed by Settings alone. The selected server on Home, the Global Routing mode, the active file in Config, and the VPN permission granted by the system all affect how requests are handled. Before troubleshooting, identify which layer the problem belongs to. Otherwise, you may look for an authentication issue in DNS settings or mask a rule-matching problem by switching servers.

Server addresses, ports, authentication details, and transport parameters belong to your connection details and should be checked against the information you already have. Rule order, target policies, and some DNS behavior may come from a Config file. Widget and Log are for actions and diagnostics; they do not fix server details. Keeping notes for each category helps you see whether a change addressed the cause and makes it easier to revert only what you changed.

This guide does not treat the switches shown on one device as universal defaults for every installation. A fresh install, restored data, imported Config, or sync between devices can each result in a different starting state. Check defaults on a device that has not been manually changed; on a device with existing data, refer to the displayed value as the current value. If an option is not shown, do not create a menu or parameter just to match this guide.

The Three Global Routing Modes

These modes are not speed settings and do not change what a remote service can do. For everyday rule-based routing, you need to understand and maintain your Config. Proxy and Direct can help with short-term comparisons, but restore your usual mode when testing is done. Direct describes a routing mode; it does not mean the system VPN is off. To determine whether the connection has ended, check both the app’s connection status and the VPN status in system settings.

Keep a Reversible Change Log

1. Record the network type, connection status, server label, Global Routing mode, and active Config name. Do not include the full subscription URL.
2. Note the setting you plan to change, its current value, why you are changing it, and what you expect to observe. Then change that setting alone.
3. End existing requests. If the setting requires a new connection, disconnect and reconnect before testing the same target again.
4. If the result does not improve, restore the original value before moving on. Do not permanently stack several unverified changes.

Choose settings to meet a specific need, not to turn on every option. If you have no particular DNS requirement, keep the DNS settings you have verified. If you do not understand the automatic connection conditions, connect manually for now. After troubleshooting, return detailed logging to the level you need for everyday use. These are principles for making changes, not claims about the current interface’s defaults, and stable setups do not need to be reconfigured.

If you have not completed the initial system authorization, return to the getting started steps instead of fine-tuning advanced options. If one target is affected, keep the current connection and start with the request log. If all targets fail, check the basic network and server connection first. For more symptom-based guidance, see Troubleshooting, then continue with the relevant section.

03 / Automatic Connections and System Permissions

When On Demand Starts and Stops Connections

On-demand connections do not continuously generate traffic

On Demand lets the system manage when to trigger a connection based on configured conditions. It controls when to try connecting, not which routing policy is used for a target. Even when enabled, it still requires valid server details, a working network, and the necessary system permissions. If authentication details are no longer valid, automatic retries will hit the same error; they will not fix server parameters or restore subscription content.

When reviewing this option, distinguish the in-app setting, the VPN configuration stored by the system, and the current connection state. Leaving the app in the background does not necessarily end the system connection. Likewise, manually disconnecting does not necessarily prevent a matching condition from triggering another connection. To assess what is happening, specify whether you disconnected before or after disabling automatic triggers; the troubleshooting steps differ.

The first connection may prompt you to add a VPN configuration. This is the Apple system’s authorization flow for allowing an app to establish the relevant network connection. Confirm that the prompt appears while you are using Shadowrocket, then follow the system instructions. If you deny permission, a connection may still fail even when all other settings are correct. You can check for the relevant entry under “Settings › General › VPN & Device Management”; the exact path depends on what your device shows.

Verify Manually Before Enabling Conditions

1. For now, do not rely on automatic triggers. Connect manually with the current server and Config, then confirm that a fixed target is accessible.
2. In Settings, find On Demand and note its current state and any existing conditions. Condition names and available options depend on what the interface shows.
3. Enable only the conditions you need. Disconnect, return to the relevant network scenario, and check whether the system triggers a connection as expected.
4. Then enter a scenario where the connection should not trigger and check that it stays in the expected state. Finally, verify the complete manual stop process.

Start with the fewest conditions needed instead of covering every network at once. If you want to connect only under specific network conditions, first check whether the interface offers a suitable condition and how it handles matches and exceptions. Similar network names do not guarantee that they are the same network, and blank names, capitalization, or renaming can affect identification. Use labels you can recognize, but do not share the full identifying details of your home network.

Do not equate “On Demand is enabled” with “the connection is always on.” Network changes, system scheduling, an unreachable server, device sleep, and permission changes can all affect the actual state. To check whether it is working, look at the connection indicator and test a real request—not just the On Demand switch. If the device has no traffic for a while, the lack of new Log entries does not necessarily mean automatic triggering has failed.

Troubleshooting Repeated Connections and Network Changes

If the connection keeps coming back after you disconnect, turn off On Demand first, then disconnect manually and check the system state. If the issue continues, check for other automation you configured or duplicate VPN entries. Identify what each one does before changing it. Do not start by deleting every network configuration: that can remove unrelated information and make it harder to trace a reproducible trigger.

On Wi-Fi networks that require a web sign-in before access, complete the network’s sign-in process first. If automatic connection makes the sign-in page hard to open, temporarily disable On Demand and disconnect, then sign in as required by the network. Restore your original settings afterward and test again. This addresses a network that does not yet allow access; it is not a reason to permanently relax certificate validation or change proxy parameters.

After switching from Wi-Fi to cellular, the existing connection may need to be re-established. Check the new connection’s Log entries rather than relying on a successful result from before the switch. If the issue occurs only on one type of network, test each one manually and record the results before changing any trigger conditions. Automatic connections should be configured only after both networks work independently; otherwise, automation will simply repeat the underlying failure.

If authorization was accidentally removed or denied, first confirm that the app is still installed from the App Store, then try connecting again and check whether the system requests permission. For help identifying and restoring the system entry, see the guide to the Add VPN Configuration prompt. A system configuration and a subscription are separate kinds of data; do not treat deleting one as deleting the other.

05 / What Is Measured and How to Compare

Ping and Connectivity Test

First Identify What the Test Measures

Ping reports a response under specific test conditions; it is not a complete verdict on connection quality. Seeing “Ping” in the interface does not prove that the underlying probe uses a particular method. If the current version lets you choose a test method, read its description and determine whether it tests the server address, connection setup, or a target request before interpreting the result.

Connectivity Test results also need to be distinguished from real-world app access. A successful test may only show that the test target responded; an app request can still be affected by DNS, rules, authentication, target restrictions, or connection reuse. A failed test may use a probe that is unsuitable for the current network even when the server works for actual traffic. Treat the result as one piece of evidence, not the sole measure of availability.

Latency figures are comparable only when measurement conditions match. Results for the same server on different networks, at different times, or against different test targets cannot be ranked directly. A lower figure does not guarantee better sustained throughput, packet loss, or long-connection stability. Choose a connection based on your actual usage and repeatable results, not the lowest number from a single test.

Choosing a Test Target, Timeout, and Concurrency

If Settings offers options such as a test target or timeout, use the values shown in the current interface as your baseline. If you have no troubleshooting need, keep settings you have verified. When changing the target, choose one you are authorized to access, that behaves consistently, and whose response you can interpret. Do not choose an address that only works on a particular network, redirects frequently, or requires a sign-in just to get a better-looking result, then treat it as representative of all traffic.

A timeout that is too short can mark a slow but working connection as failed; one that is too long delays detection. Choose a value to suit the test, rather than assuming lower is always better. If the current interface has no such option, do not search for a field with the same name in other references. After changing a test setting, verify it against a known working connection before testing a suspect one, so a bad measurement setup does not distort every result.

Running many tests at once adds temporary connection and network load, and the results can affect one another. If you manage several existing subscriptions, narrow the list by group first, then test the entries you need to compare. Avoid testing repeatedly while updating subscriptions, switching networks, and reconnecting: changing several inputs at once makes it hard to tell whether a difference comes from the test target or the device’s state.

A Repeatable Test Record

1. Keep the network and Global Routing mode fixed. Record the server label and test method, but not authentication details.
2. First access a known working target to confirm that the device’s basic network and the test target are available.
3. Run the test on the same entry more than once, with a pause between attempts. Check for consistent success instead of keeping only the lowest result.
4. Then make a new request in a real app, check the policy and connection result in Log, and restore any temporary test settings.

If every test times out, check the test target and basic network before deleting an entire subscription. If only one entry fails, check its server details and whether the latest update completed. If the test succeeds but real traffic fails, check whether the app used the same server and whether Config routes the target to a different policy. This layered approach avoids unnecessary global changes.

If testing fails only on Wi-Fi or only on cellular, keep separate records for each network. Do not treat results saved before a network switch as results from the new network or rely on an old ranking to pick the best current entry. If needed, wait for the basic network to stabilize, reconnect, and test again. In environments that change frequently, focus on failure patterns rather than maintaining a static ranking.

If the interface shows a blank, untested, or failed status, record it as displayed instead of converting it into a latency figure. Distinguishing “no measurement completed” from “a slow result was measured” prevents misleading comparisons. If results remain inconsistent, pause bulk testing and use one fixed target and one connection. Then use the Log method in the next section to create a minimal reproducible test.

07 / Quick Actions and Cross-Device Data

Widget and iCloud Sync: What They Do

Widget Is a Shortcut, Not a Separate Connection Setup

Widget provides system-approved shortcuts for viewing or controlling the app; the available options depend on what your device lets you add. A Widget generally relies on settings already configured in the app and cannot replace initial import, VPN authorization, or a manual connection test. Before adding one, confirm that the selected server and Config work in Shadowrocket, then check whether the status shown in Widget matches the app.

The system may refresh Widget on its own schedule, so a screen that has not updated is not proof of the current connection state. To confirm whether an action worked, open the app, check the connection, and make a new request to a target. If Widget does not have the expected effect, first check whether the app needs authorization, the connection details are valid, and the system allows the action. Do not immediately change DNS or server parameters.

Use Widget for familiar, routine actions rather than repeatedly tapping it when the connection state is unclear. Rapid repeated actions can leave a connection in the middle of starting or stopping, so the display and actual state may briefly differ. Wait for one action to finish before starting another. To stop automatic reconnection, follow the steps in the On Demand section instead of relying on a single disconnect action in Widget.

iCloud Sync Is Not a Full Device Copy

If Settings offers iCloud Sync or a related option, first confirm that you are signed in and have allowed the app to use iCloud as required by the system. Check the current interface for which data can sync, whether syncing must be started manually, and whether separate import or export options are available. Do not assume that every server, Config, switch, Log entry, and system permission syncs automatically, or that one successful sync is a long-term backup.

The App Store purchase account and the iCloud account used on a device serve different purposes. Restoring a purchase confirms your eligibility to get the app; iCloud Sync transfers supported data. Neither replaces the other. Being able to download the app on a new device does not mean all connection details from the old device are there. Likewise, seeing synced data does not mean the new device has the VPN permission it needs.

Before enabling sync, keep a recoverable copy of your data and identify anything stored only on the device. If the current interface offers export, check what it includes and protect any credentials it may contain. Store backups somewhere you control and can restore from; do not put complete connection details in a public document. As with default settings, check the state on the current device rather than inferring it from another one.

When Two Devices Differ

1. On each device, note the active Config, server labels, and most recent manual changes. Do not edit the same data on both devices at once.
2. Check the system’s iCloud requirements and the sync scope offered by the app. Confirm that you are comparing the same type of data on both devices.
3. Decide which copy you want to keep, then use the available sync or import option only when you can recover the data if needed.
4. Verify the server list, selected Config, and actual connection on each device. Matching filenames do not prove the contents match.

If the same content has been changed on both devices, do not assume that the device most recently opened will overwrite the other one correctly, or that repeated syncing will merge everything. Save both sets of changes first, then choose what to keep based on the conflict handling shown in the app. If the interface does not explain how changes are merged, make changes on one device and verify them on the other; this is usually easier to track than editing both at once.

A Config can look different on iPhone and iPad because of the layout without containing different data. Compare specific fields and active states, not list widths or button positions. For iPad purchase restoration and layout information, see the iPad purchase and interface guide. Refer to the App Store page for shared purchases, device compatibility, and system requirements; do not infer compatibility from sync results.

If an old server or duplicate entry appears after syncing, first identify whether it came from a subscription update, a manual import, or synced data, then decide what to remove. Before deleting anything, save labels and local changes you still need; do not remove a source that is still in use. Widget is only a shortcut, and sync only transfers supported data. Verify the active Config on the device and test real access to confirm the setup.