OFFICIAL MANUAL · GLOSSARY

Shadowrocket
Terms & Rule Reference

First identify which layer a term belongs to, then adjust the corresponding setting. This page explains English interface labels, protocol names and rule keywords. For step-by-step instructions, see the Quick Start Guide.

UI · Interface layer RULE · Rule layer

Mind the capitalization: Proxy is an interface mode, while PROXY is a rule policy. They are not the same setting.

01 / INTERFACE & SWITCHES

Interface & Controls

Interface screens organize app operations; Global Routing determines the overall traffic mode. Check the screen and mode first, then investigate whether a specific rule matched.

UI

Home

Home is the starting point for viewing server entries and connection status. Before connecting, check the selected entry and then review Global Routing. An entry being visible does not mean it has authenticated successfully or is usable. To add details, use Add Server or the import flow for an existing subscription.

UI

Global Routing

Global Routing determines how traffic is handled overall. Its three modes are Config, Proxy and Direct. Config follows the active configuration; the other two select an overall proxy or direct route. Note the current mode before troubleshooting so a mode change is not mistaken for a rule change.

UI

Config

Config can refer either to the configuration management screen or to the mode in Global Routing that follows the configuration; use the context to tell which. In this mode, traffic routing is determined by the active configuration. Importing a file does not activate it, so check the selected configuration and its Rule contents.

UI

Proxy

Proxy is the Global Routing mode that uses the proxy route and can help test whether the current server connection works. If access works in Proxy but not Config, investigate rules and DNS settings. Proxy is not the uppercase PROXY in a rule. After testing, restore the mode you need.

UI

Direct

Direct is the Global Routing mode that uses a direct route, useful for checking how access behaves on the current network. It does not delete saved servers or configurations, and it is not the same as turning off the system VPN state. During diagnosis, note the routing mode, connection toggle and destination access result separately.

UI

On Demand

On Demand triggers connection behavior when specified conditions are met, which may include Wi-Fi, cellular networks or domain names. If the connection returns after you disconnect manually, first check whether a trigger condition is still met. Review each condition and its order, then verify the behavior after switching networks; do not rely on how the toggle looks.

UI

Settings

Settings is the entry point for managing app settings. Refer to the current wording in the app for the available options. When troubleshooting, note the original value and change one variable at a time to avoid losing track of what affected the result. Check equivalent settings in configuration files too; the section name alone does not determine the final behavior.

UI

Data

Data provides access to traffic and request records and is useful for checking activity after a test. An increase in traffic only shows that activity occurred; it does not prove that requests followed the intended policy. Check the destination domain, matched rule and connection result together. Remove sensitive information before sharing records.

02 / PROTOCOLS

Protocols

A protocol determines how both ends establish a connection and exchange data. Choose a type that matches your existing server details; similar names or fields do not mean their parameters are interchangeable.

PROTOCOL

Shadowsocks

Shadowsocks is a proxy protocol that requires both ends to use matching encryption methods and credentials. Check the address, port, password and any additional parameters required by the server—not just the password. If the connection fails after import, compare each field with the original details instead of changing the encryption method at random.

PROTOCOL

VMess

VMess authenticates using identity information; the transport method and TLS settings also affect connection setup. The server address, user ID, path and server name may each serve a different purpose and cannot substitute for one another. If authentication details are correct but the connection fails, also check the device time and transport parameters.

PROTOCOL

VLESS

VLESS handles identity authentication and transport security separately. A user ID alone does not mean the connection is fully protected. When adding an entry, check the transport type, TLS and any server-specific parameters. Do not reuse a configuration for another protocol, even if both use the same address and port.

PROTOCOL

Trojan

Trojan typically uses TLS and password authentication to establish a proxy connection. Certificate validation is an important part of verifying the connection’s identity. In addition to the address, port and password, check the server name and transport settings. If you see a certificate error, verify the name, device time and configuration source rather than routinely skipping validation.

PROTOCOL

HTTP

HTTP as a server type means an HTTP proxy; it does not mean entering a webpage URL in the address field. The server field usually takes a hostname or IP address, with the port and authentication details entered separately. Whether the proxy connection uses TLS is distinct from whether the destination website uses HTTPS; check each against your existing configuration.

PROTOCOL

SOCKS5

SOCKS5 forwards connections through a proxy server and can use username and password authentication, depending on the server settings. The protocol name alone does not mean the connection is encrypted, and UDP support depends on both ends and network conditions. Check the authentication requirements; an empty password is not a universal default.

PROTOCOL

Hysteria2

Hysteria2 is based on QUIC and carries connections over UDP, so UDP availability on the network affects the handshake and data transfer. First check the address, authentication and TLS parameters, then consider network conditions. A successful TCP test alone does not prove that this protocol’s connection route is working.

PROTOCOL

WireGuard

WireGuard establishes a tunnel using public and private keys and peer configuration rather than standard username and password fields. Check the interface address, private key, peer public key and related routing parameters together. The private key is sensitive: remove it from diagnostic reports and shared configurations, and never publish the full configuration.

03 / RULE KEYWORDS

Rule Keywords

A rule puts “what to match” and “what to do when it matches” on the same line. The examples below explain the syntax; they are not a complete configuration to replace your current settings.

RULE

Rule

Rule contains the matching rules that determine where traffic goes, typically evaluated from top to bottom. Put specific conditions before broader ones and place the fallback rule at the end. After adding a rule, check actual request logs to confirm the match; a rule that looks right still needs to be tested.

RULE

DOMAIN

DOMAIN matches an exact domain and is suitable for handling a specific hostname. It does not automatically include all subdomains. Do not include a URL scheme, path or query parameters in the domain field; the example below applies only to the specified domain.

DOMAIN,example.com,PROXY
RULE

DOMAIN-SUFFIX

DOMAIN-SUFFIX matches a domain suffix, covering the specified domain and its subdomains. It has broader coverage than a single DOMAIN condition and is useful when related domains need the same policy. Before making changes, check whether subdomains should also match so that exceptions are not caught unintentionally.

DOMAIN-SUFFIX,example.com,PROXY
RULE

DOMAIN-KEYWORD

DOMAIN-KEYWORD matches a keyword anywhere in a domain name; the keyword does not need to appear in a fixed suffix position. It may also match unrelated domains with similar names, so use it sparingly. When possible, an exact domain or suffix makes the matching scope easier to review.

DOMAIN-KEYWORD,adservice,REJECT
RULE

IP-CIDR

IP-CIDR matches an IPv4 address range; the prefix length after the slash determines its size. The example shows a direct-routing rule for a private network range and should not be copied as a universal setting. For IPv6 addresses, use the corresponding IP-CIDR6 rule; confirm the address type before making changes.

IP-CIDR,192.168.0.0/16,DIRECT
RULE

GEOIP

GEOIP matches a destination based on its classification in an IP geolocation database, not the webpage language or the user’s location. Database classifications may differ from where a service is actually hosted, so they do not prove a website’s identity. If traffic is routed unexpectedly, check the resolved address and rule order.

RULE

FINAL

FINAL handles traffic that has not matched any preceding rule and serves as the configuration’s fallback. It is typically placed at the end of the rule list, and its policy affects every request not matched earlier. If a large amount of traffic reaches FINAL, check whether preceding conditions are too narrow or missing before changing servers.

FINAL,PROXY
POLICY

PROXY / DIRECT / REJECT

These three uppercase names are policies applied when a rule matches: PROXY routes through the proxy, DIRECT connects directly, and REJECT blocks the request. They do not define matching conditions and are distinct from the Global Routing interface modes. To understand a rule, read its keyword, match value and final policy together.

04 / SUBSCRIPTION & CONFIGURATION

Subscriptions & Configuration

Server entries store connection parameters, configuration files organize traffic rules, and purchase records confirm app eligibility. Manage these separately; none replaces the others.

INPUT

Add Server

Add Server lets you manually enter server details you already have. First choose the protocol that matches those details, then enter the address, port, authentication and transport parameters separately. Watch for extra spaces and capitalization. Test the connection after saving: a successful save only means the entry was recorded, not that the remote server was verified.

INPUT

Subscribe

Subscribe imports and updates server entries you already have. Get the subscription link from your service provider. Updating entries does not automatically select one or guarantee that every entry works. The link may contain credentials, so do not share it publicly. If an update fails, keep any working information and check the original link.

CONFIG

.conf

.conf is a configuration file format that can contain sections such as General, Rule and Host. Each section handles different aspects, including global behavior, rules and mappings; a configuration file is not the same as a server subscription. Review the contents and keep your existing configuration before importing, then confirm which configuration is active. For the full structure, see the Configuration Guide.

CONFIG

URL Rewrite

URL Rewrite modifies or processes request URLs according to matching conditions. It operates at a different level from Rule, which determines the connection route. If a destination address changes unexpectedly, check for relevant rewrite conditions. This is not a general fix for every access problem; check what an unfamiliar rule does before enabling it.

SYNC

iCloud Sync

iCloud Sync transfers relevant app data through iCloud when the required settings and permissions are in place; check the in-app options for the exact scope. Syncing is not purchase restoration and does not affect whether a server service is valid. Before switching devices, confirm that sync has finished and keep a separate copy of important configuration. Do not treat a single sync as a complete backup.

APP STORE

Purchased Items

Purchased Items is where you find apps you have purchased in the App Store. When changing or restoring a device, first check that you are using the original purchasing account. Restoring the app does not restore all local configuration, and server details need to be checked separately. System requirements and purchase eligibility are as shown on the App Store page. For steps, see Restore a Previous Purchase.

05 / CONNECTION & DIAGNOSTICS

Connections & Diagnostics

Break a problem into stages: DNS resolution, connection, authentication, rule matching and actual access. Success at one stage is only partial evidence; it does not verify the entire connection path.

DIAGNOSTICS

DNS

DNS resolves domain names to IP addresses and is often involved before a connection is established. If a domain resolves but access fails, the issue may be in a later connection or authentication stage; a resolution failure does not by itself mean the server is unavailable. Before changing DNS settings, note the original values and check request logs. Avoid changing rules and server settings at the same time.

DIAGNOSTICS

Connectivity Test

Connectivity Test checks whether an entry can reach a specified target using a particular test method. The result applies only to those test conditions. A successful test does not guarantee access to every destination, and a failure must be considered in light of the protocol and network environment. Test the actual destination too, then check Global Routing and the matched policy.

DIAGNOSTICS

Latency

Latency is the response time measured by a particular test. It is not download bandwidth and does not directly indicate the stability of a long-running connection. Results vary by test target, network and time, so do not rank unlike measurements together. Keep test conditions consistent when comparing entries, and consider whether actual requests succeed.

SYSTEM

VPN Configuration Permission

VPN configuration permission allows the system to create the relevant network configuration for the app. The first connection may require confirmation and device authentication. A connected status after authorization does not guarantee that the remote server is reachable. If a connection will not start, check system permission first; if it connects but access fails, investigate the server, DNS and rules.

CONNECTION

Server

A server entry stores a remote address, protocol and authentication parameters; a single connection entry is also commonly called a node. Its name is just a label for identification and does not prove its address, capabilities or status. Check its parameters against the original details, then test reachability, authentication and access to the destination separately. Do not rely on the name or a single latency result.