Official GuideQuick Reference
Shadowrocket
Shadowrocket
Interface & Rule Terms
Identify the interface controls, connection protocols, match conditions, and policies before changing settings. App interface labels remain in English; use the anchor beside any heading to jump directly to a term.
01 / Interface & Controls
Screens, Modes & Connections
When you see a familiar label, first check whether it names a screen, a mode, or an action. The connection toggle, overall mode, and rules file address different things and cannot replace one another.
- Home
- The main screen shows connection status, Global Routing, and the SERVER list. Not Connected describes the current connection state; the toggle starts or ends a connection. Even if the status changes, test an actual destination to confirm access. The toggle alone cannot confirm that everything works.
- Global Routing
- The control for choosing how traffic is handled overall: Config, Proxy, and Direct. To check how the current rules file routes traffic, first confirm that Config is selected. Record the current mode before troubleshooting; otherwise, a mode change may be mistaken for the effect of a rule.
- Config
- As a screen name, Config opens configuration management; as a Global Routing option, it means handling requests according to the current configuration. Importing a file into Config does not mean it is selected or that the overall mode has changed to Config. Check both when verifying whether rules are active.
- Proxy / Direct
- These are overall modes in Global Routing: Proxy handles traffic through a proxy, while Direct connects directly. Do not confuse the capitalized interface labels with rule keywords: policies in the Rule section are written PROXY and DIRECT. Overall modes can help narrow down an issue; restore your preferred mode after testing.
- On Demand
- On Demand starts a VPN connection when configured conditions are met; available conditions and options are shown in the app. It answers “when to connect,” while Rule determines “how to handle a request.” If connection behavior is unexpected, check both the system VPN status and On Demand conditions instead of changing domain rules alone.
- Connectivity Test
- Use this option to check whether the selected server responds under the current test conditions. The displayed time reflects that particular test; it is not a sustained transfer speed or a measure of every app's performance. If the result is unexpected, check the test method, destination, and network conditions. Even a normal result should be followed by a test of actual requests and rule matches.
- Settings
- The central place to manage app settings; available options depend on the current app screen. App settings and .conf parameters come from different places, so note where each change is made when troubleshooting. Change one relevant option at a time and keep its original value to make the cause easier to identify.
02 / Protocols
Protocol Types & Parameters
A protocol defines how the client communicates with a server; do not infer its parameters from the name alone. The descriptions below explain technical terms only. When adding a server, use your existing server details and the fields shown in Add Server.
- Shadowsocks
- A proxy protocol. Connection details commonly include a server address, port, encryption method, and password. The encryption method must match the server; do not change it just because the address and password are the same. If authentication or connection fails after import, check each item against your existing details and watch for spaces copied along with the values.
- VMess
- A proxy protocol that uses an identifier and other parameters; UUID is one key detail to verify. Transport, TLS, Host, and path settings may also affect the connection, so checking only the address and port is not enough. Follow the actual server configuration, and do not use tutorial example values for your own connection.
- VLESS
- A proxy protocol with separate identity, transport, and transport security settings. VLESS and VMess have similar names but are different protocols; switching the type does not make all fields interchangeable. Available combinations depend on the client options and server configuration. After importing, check that all required parameters are present.
- Trojan
- A proxy protocol commonly used with TLS. Connection details include an address, port, password, and related TLS information. The server address and the name associated with its certificate may serve different purposes, so check each against your existing details. For certificate errors, check the name, system time, and server certificate; ignoring verification is not a routine fix.
- HTTP / SOCKS5
- Two distinct proxy protocol types. Connection details commonly include an address and port, and may include a username and password. Choose the type provided by the server; the names are not interchangeable. UDP support depends on the protocol, server, and actual configuration.
- WireGuard
- A key-based tunneling protocol. Understand the difference between the private key, public key, peer address, tunnel address, and routing scope. Keys are not ordinary display names; keep the private key especially secure. After importing a configuration, check its addresses and routing scope against the details you have, rather than relying only on the connection status.
- Hysteria2
- A QUIC-based proxy protocol that uses UDP. Its performance depends on the network path, server, and configuration. A successful TCP test does not prove that the UDP path required by this protocol works. Check authentication details, TLS information, and UDP connectivity; do not assume performance based on the protocol name.
03 / Rule Keywords
Match Conditions & Scope
The keyword specifies what kind of information to check; the value that follows defines the specific match. Domain rules do not take full web addresses. For address ranges, check the address family and prefix length.
- DOMAIN
- Matches an exact domain. For example,
DOMAIN,example.com,PROXYmatches example.com itself, not subdomains such as www.example.com. To change handling for one specific domain, start with an exact match and add other domains only if actual requests require them.
- DOMAIN-SUFFIX
- Matches a domain suffix. Entering example.com includes that domain and its subdomains, but not every domain that happens to contain the same text. Do not include https://, a web path, or a port. If you only want to affect one subdomain, consider DOMAIN to avoid widening the rule's scope.
- DOMAIN-KEYWORD
- Checks whether a domain contains a specified keyword. For example, example may appear in several unrelated domains. This is broader than an exact domain match and does not require the keyword to form a domain level. Consider possible false matches; a keyword rule is not a reliable list of every domain used by a service.
- GEOIP
- Matches based on IP geolocation data, for example,
GEOIP,CN,DIRECT. Results depend on the database and the destination IP, not the domain suffix, or user's location. A domain may resolve to multiple addresses, so its page content alone cannot tell you whether GEOIP will match.
- IP-CIDR / IP-CIDR6
- Matches IPv4 and IPv6 address ranges; the prefix length after the slash defines the range. The example
IP-CIDR,192.168.0.0/16,DIRECT,no-resolvespecifies an IPv4 network. no-resolve prevents an extra DNS lookup for this rule; it does not disable DNS for the whole app.
- USER-AGENT
- Matches a readable HTTP User-Agent field, for example,
USER-AGENT,ExampleApp*,PROXY. This does not identify traffic by the name of an installed app, and not every connection exposes a readable field. Do not assume that all HTTPS requests can be evaluated directly with this type of rule.
- FINAL
- Catches requests not matched by earlier rules and is usually placed at the end of the Rule section.
FINAL,PROXYandFINAL,DIRECThave different fallback behavior; choose one to suit the configuration. FINAL does not override earlier decisions—it handles only requests that no earlier rule matched.
04 / Policies & Matching Order
What Happens When a Rule Matches
The rule type answers “does it match?”; the policy answers “how should it be handled?” The uppercase keywords below are used in rule text and should not be confused with overall modes in Global Routing.
- PROXY
- A policy keyword that sends matching requests through the proxy route. Check the current configuration to see which server or policy selection will be used. A PROXY match only means that the proxy route is selected; it does not guarantee successful authentication or a connection to the destination. Troubleshoot rule matching and proxy availability as separate steps.
- DIRECT
- Sends matching requests to their destinations over the current network, without forwarding them through a proxy server. This describes the routing policy; it does not mean the app plays no part in handling the request or guarantee that the destination is reachable. If a direct connection still fails, check the current network, DNS resolution, and destination service rather than just switching proxy servers.
- REJECT
- A policy keyword that rejects matching requests. A rejection rule placed too broadly or too early may prevent later, more specific allow rules from taking effect. If a destination is consistently unreachable, check whether an earlier REJECT rule matched before troubleshooting the proxy route.
- Matching order
- The Rule section is generally checked from top to bottom, and the first matching rule determines the policy; the app does not automatically choose the rule that “looks most specific.” Place precise exceptions before broader rules, then put FINAL last. After adding a rule, check its position too: correct syntax in the wrong order can still produce unexpected results.
Order at a Glance
Handle Exceptions Before Broader Matches
In this example, api.example.com matches DOMAIN first and uses DIRECT. Other example.com subdomains are then handled by DOMAIN-SUFFIX. If you swap the lines, the broader suffix rule matches first and the exact exception never takes effect.
This example illustrates matching behavior only. Users must provide and verify the connection details for PROXY themselves.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT05 / Subscriptions & Configuration Files
Connection Details & Configuration Structure
Server entries store connection parameters, subscriptions import and update entries in batches, and configuration files define behavior such as rules. Identify what you are importing before choosing an entry point, so each type of information is handled correctly.
- Subscribe
- A way to import and update server entries using a subscription URL you already have; the returned content depends on the information provided by that URL. Subscription links often contain access credentials. Hide the full link before sharing screenshots, logs, or help requests. A successful subscription update does not mean every entry can connect or that the current rules configuration has changed.
- SERVER / Add Server
- SERVER is the list of server entries; Add Server is where you enter or import connection details. An entry is also commonly called a node. It usually contains a protocol type, address, port, and authentication parameters, and is not the same as a subscription that manages multiple entries. A display name helps identify an entry but does not verify its address, protocol, or availability.
- .conf
- A common configuration file extension. Parameters and rules are organized into sections. General, Rule, Host, and URL Rewrite cover global parameters, traffic rules, domain mappings, and URL rewrites, respectively; a file does not need to contain every section. The extension alone does not guarantee valid contents. After importing, check the text, selected file, and Global Routing mode.
- DNS / Host
- DNS resolves domain names, and the Host section can map domains to addresses; both affect the destination address the app ultimately gets. Changing Host does not automatically route a request through PROXY or fix an incorrect server password or identifier. Check DNS issues separately from rule policies and destination reachability, rather than repeatedly changing unrelated parameters.
- URL Rewrite
- A section that processes request URLs according to configured conditions; its behavior depends on the match expression and corresponding action. It differs from Rule, which selects a traffic policy, and Host, which maps domains to addresses. Before using it, check the match scope, whether the request information is visible, and the required conditions. Do not copy snippets when their source and purpose are unclear.
Explore Further
From Concepts to Tasks
Glossary entries clarify terminology; actual setup requires step-by-step instructions and context. Start with the tutorial for your first configuration, use the full configuration guide for existing rule issues, and see the App Store verification guide for purchase or device-transfer questions.
Getting Started
Import, Connect & Verify
Check your existing details, Global Routing, and connection results in order. A test response alone does not prove that all requests are working.
View the tutorial → Rules & ConfigRule Structure & Complete Examples
Learn how sections, match scope, policies, and rule order work, then compare them with your configuration and make changes one at a time.
View the full configuration guide → Verify the Official AppCheck the App Store listing
Verify the developer, Shadow Launch Technology Limited, the official icon, and app ID 932747118. Check the App Store listing for system requirements.
View purchase information →