Shadowrocket Settings Guide

Shadowrocket’s commonly used settings can be understood in four layers. The first is Global Routing, which determines whether traffic uses Config, Proxy, or Direct overall. The second is the rules and policies in Config, which evaluate requests one by one when Config is active. The third includes the user’s existing subscriptions or server details, DNS, and On Demand connection conditions. The fourth is Data, Connectivity Test, and Diagnostics, which help review actual results. Following this order avoids repeatedly changing DNS or server settings while the overall mode is incorrect.

For most daily use, start with Config and let the rules choose PROXY, DIRECT, or REJECT. To briefly verify whether a server can establish a connection, switch to Proxy for a short test so rules have less influence. To check whether the local network itself is working, use Direct as a comparison. After testing, return to the mode required for normal use and check page access, rule matches, and DNS resolution again.

What it is: Global Routing is the main entry point before connecting. It determines whether traffic is evaluated by Config rules, sent through the selected server, or sent directly over the local network. The three modes are Config, Proxy, and Direct.

Where to find it: Open Home and locate Global Routing. After switching modes, subsequent requests are handled according to the new mode. When troubleshooting, reopen the test page after changing modes so browser caching or existing connections do not affect the result.

How to configure it: For daily use, select Config and confirm that the active Config is the intended file. If a page will not open, note the current mode, then compare the result with Direct and Proxy in that order. If Direct also fails, check the local network or target address first. If Proxy works but Config does not, focus on rule order, policy mapping, and FINAL. If Proxy also fails, check the current server details and DNS.

What to watch for: Global Routing describes the overall handling mode; it does not guarantee that a specific server is available or that a particular rule will match. After each switch, review the result with Data, logs, or Diagnostics. When troubleshooting is complete, restore the original settings so the app is not left in test-only Proxy or Direct mode.

What it is: When Global Routing is set to Config, rules determine whether a request uses PROXY, DIRECT, REJECT, or a custom policy based on its domain, IP address, or other characteristics. Rules are checked in order and usually stop at the first applicable match. Therefore, not only must the rule content be correct—the rule’s position matters too.

Where to find it: Open the current configuration file from Config and view Rules or the corresponding rule editor. Config files from different sources may have different structures, but rule keywords and target policies should still be checked individually. Before editing, keep the original Config so it can be restored if the result is unexpected.

How to configure it: Put the most specific and narrowly scoped rules first, followed by broader rules, and use FINAL for traffic that matches nothing else. For example, if one full domain should use DIRECT while its overall domain suffix uses PROXY, place the full DOMAIN rule before DOMAIN-SUFFIX. Policy names must match policies already defined in Config; capitalization, punctuation, and comma placement must also follow the expected syntax.

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

What to watch for: The addresses above are examples of syntax only. If a rule appears not to work, first check that Global Routing is set to Config, then check whether an earlier rule has already matched. After DNS resolution, a domain may also be evaluated by IP-based rules. On networks with IPv6 enabled, check IP-CIDR6 as well. REJECT actively blocks matching traffic, so define its target carefully before adding it to avoid blocking required page resources.

What it is: Shadowrocket can store the user’s existing subscriptions or individual server details. Subscribe is suited to multiple server records maintained by one source; Add Server is for entering one known configuration manually; Scan QR Code and Import from Cloud JSON import existing data. Supported configurations may include Shadowsocks, VMess, VLESS, Trojan, HTTP, SOCKS5, WireGuard, and Hysteria2. Actual connectivity depends on matching protocol parameters and server-side settings.

Where to find it: Open the add menu in the server list area of Home to find Add Server, Subscribe, Scan QR Code, or Import from Cloud JSON. Existing entries can usually be opened for editing so you can review SERVER, port, password, protocol-specific parameters, and notes. Use only information that the user owns or is authorized to use.

How to configure it: Confirm the data type before importing. Put a subscription URL in Subscribe rather than treating it as an individual SERVER address. For a single server, choose the appropriate protocol and fill in SERVER, port, and authentication fields one by one. After importing, do not change several parameters at once. Select one entry, run Connectivity Test, and then try to connect. If it fails, compare the entry with the original data character by character, paying particular attention to the protocol, port, transport, TLS-related names, and authentication details.

What to watch for: Subscription updates generally refresh entries according to the source content, so manual changes to subscription-managed records may be overwritten during the next update. Before deleting an old entry, confirm that no Config or policy group still references its name. Connectivity Test is only one part of connection checking; reachability does not mean every destination is routed as expected. Verify the result with Global Routing, Rules, and DNS as well.

What it is: On Demand uses network conditions to trigger connection behavior. It is useful for automatically applying preset rules when Wi-Fi or cellular connectivity changes. It answers “when should a connection be established,” while Global Routing and Config answer “how should traffic be handled after connecting.” They operate at different levels.

Where to find it: Open On Demand in Settings and configure its enabled state and network conditions. Before using it for the first time, confirm in manual mode that the current server, Global Routing, and Config work correctly. This separates basic configuration issues from trigger-condition issues.

How to configure it: Start with simple conditions, such as distinguishing cellular data from known Wi-Fi networks. After saving, switch networks one at a time and observe whether the system status and Shadowrocket connection status change as expected. When adding several conditions, add and verify one at a time. If multiple conditions overlap, confirm that their priority cannot produce the opposite of the intended result.

What to watch for: On Demand is triggered by changes in system network status, so do not mistake a brief network transition for a server failure. A changed Wi-Fi name, incomplete network authentication, or rapid switching between cellular and Wi-Fi can temporarily change the connection state. For troubleshooting, disable On Demand and connect manually first. Once manual connection works, restore the trigger conditions one by one.

What it is: Data shows traffic records and usage summaries handled by Shadowrocket. It can help determine whether sustained transfers occurred during a period, which connections used more traffic, and whether traffic behavior changed after switching rules or servers. It is a local observation tool and should not be used alone to infer server quality or billing results.

Where to find it: Open Data from the app’s bottom navigation or the relevant entry point. Before viewing statistics, note the current connection mode and test period. Then perform one clear action, such as opening a specified page or running a download, and return to Data to compare the change. This is easier to interpret than cumulative data mixed with extensive background activity.

How to configure it: To compare two configurations, let background activity settle first, then test under similar network conditions. Change only one variable per round: Global Routing, Config, or the server. Recording upload and download direction, start time, and the test action helps prevent system sync, media preloading, or background app requests from being mistaken for the target traffic.

What to watch for: Data may include background requests from the system and other apps, and its figures may use a different measurement basis from server-side statistics. No obvious change over a short period does not mean the rules are inactive; some connections reuse existing sessions. To assess a specific rule, use Data together with logs, Diagnostics, and the actual access result.

Options in Settings affect resolution, testing methods, shortcuts, and configuration sync. Note the original values before making changes, then retest the same target afterward. Changing several items at once may save steps, but makes the cause of a problem harder to identify.

What it is: Diagnostics checks clues from the current network, DNS, connections, and request handling. Connectivity Test is more focused on quickly checking reachability to a server or target. Both help narrow the scope of a fault, but the final assessment still requires actual access results.

Where to find it: Diagnostics is usually in Settings or a tools area, while Connectivity Test can be run from a server-management entry point. Before starting, record the current network type, Global Routing mode, Config name, and selected server so several conditions are not changed during testing.

How to configure it: First use Direct to confirm the local network, then use Proxy to check the current server, and finally return to Config to verify the rules. If the issue centers on domain resolution, review the DNS results. If it appears as a connection timeout, check SERVER, port, protocol, and authentication parameters. If only a specific site is affected, inspect matching DOMAIN, DOMAIN-SUFFIX, GEOIP, IP-CIDR, or FINAL rules.

What to watch for: Diagnostic information may contain server addresses, domain names, and network-environment details. Review it before saving or sharing, and keep only what is needed to solve the problem. Do not frequently switch networks, servers, and rules while troubleshooting. Change one variable at a time so each result can be associated with a specific setting.

1. Record the current environment.

   Write down the active Wi-Fi or cellular network, Global Routing mode, Config name, and current server. Without the initial state, it is difficult to tell which change caused an effect.

2. Confirm the local network.

   Temporarily select Direct and open a known working page. If Direct also fails, address basic network authentication, signal, or DNS issues first.

3. Check the server connection.

   Switch to Proxy, run Connectivity Test for the current entry, and try actual access. If it fails, check SERVER, port, protocol, and authentication details one by one.

4. Restore Config and check the rules.

   Review the first rule that the target domain may match, confirm that the policy exists, and check FINAL. Do not only look for the target domain in the rule file; also inspect the rules above it.

5. Check DNS and IPv6.

   If the domain is abnormal while other connections work, review DNS settings and caching. When IPv6 is enabled, also check IP-CIDR6 and the address type returned by the target.

6. Restore automatic features last.

   Once the basic connection is stable, enable On Demand, Today Widget, and iCloud sync. Restore and verify each item separately to prevent automatic triggers or sync changes from interfering with core connection troubleshooting.