Shadowrocket Official Manual · Glossary
Identify which part of the app a term belongs to before changing a setting. This glossary covers five categories, and each entry has a link beside its heading for direct navigation.
Interface labels help you find controls, while Global Routing determines how requests are handled overall. Similar terms can serve different purposes in different places. In particular, distinguish the Config screen, Config mode, and a configuration file.
Home is the main screen for viewing server entries, selecting a connection, and controlling the connection toggle. A server in the list only means the client has saved its parameters; it does not mean a connection is established. For a first connection, check the selected entry, review the toggle and connection status, then verify with an actual request.
Global Routing determines how requests are handled overall. Its three common options are Config, Proxy, and Direct. These are routing modes, not server protocols or separate connection accounts. Before checking whether rules work, confirm that Config is selected.
In Global Routing, Config means handling requests according to the active configuration, where rules can send different destinations to different policies. As a screen name, Config opens configuration file management; it is not a routing mode toggle. When following instructions, check whether they mean “select Config mode” or “open the Config screen.”
Proxy is the proxy mode in Global Routing, which handles requests through a proxy. It does not specify the server protocol, and it is not the uppercase PROXY policy at the end of a rule. When troubleshooting how a website is routed, note both the current routing mode and selected server so you do not mistake a mode difference for a rule error.
Direct is the direct mode in Global Routing, which sends requests directly. It is related to the DIRECT policy in rules, but the two operate at different levels: the former is an overall mode, while the latter is the action taken when a rule matches. Switching to Direct can help show how requests behave without a proxy, but does not confirm whether server authentication details are correct.
On Demand starts the system VPN connection when configured conditions are met; it controls when a connection starts. It does not choose which rule applies to a domain or fix an incorrect server password or address. Confirm that manual connections work before configuring triggers. See On Demand settings for details.
Add Server is where you enter server details manually. Choose the type that matches the information you have, then enter the address, port, and authentication details. Required fields vary by protocol, so do not reuse one protocol's fields for another. Saving an entry only completes setup; select it and verify the connection separately.
A protocol determines how the client and server exchange data. The explanations below help identify parameters; they are not recommendations for choosing a service. Match each value to your existing server configuration. A protocol name alone says nothing about connection quality.
Shadowsocks encrypts proxy traffic between the client and server. Its core parameters typically include the address, port, password, and encryption method. The encryption method must match the server; similar names do not mean methods are interchangeable. Check any additional transport parameters in your existing configuration too—a correct password alone does not guarantee a complete setup.
VMess uses parameters such as a UUID for identification and authentication, and may use different transports and TLS settings. A correct UUID does not guarantee the rest of the configuration is correct. Check the address, port, transport path, and related hostnames as well. A significantly incorrect device clock may also affect authentication, so check the system time before reviewing the other fields.
VLESS is a lightweight proxy protocol that uses a UUID for identification but does not provide content encryption on its own. Connection security depends on the transport and security layer in use; a UUID is not an encryption method. Check the security options, transport, and related fields against your existing parameters. Do not copy VMess settings just because some fields look similar.
Trojan typically uses TLS and password authentication. The server address and the name used for certificate verification are separate settings. SNI specifies the server name in the TLS handshake and may differ from the connection address; follow your existing configuration. If a certificate error occurs, check the name, device time, and server certificate rather than routinely disabling certificate verification.
Hysteria2 is a QUIC-based proxy protocol that relies on UDP. Fill in authentication and TLS-related fields according to the server configuration. UDP support on the current network affects the handshake and data transfer; a result from a standard latency test does not prove the protocol will work. Check network transport conditions separately from authentication parameters.
WireGuard uses public and private keys for authentication and carries tunnel data over UDP. Its configuration also includes interface addresses, peer details, and routing ranges. A private key is sensitive and should not appear in public screenshots or support requests. When troubleshooting, check the key pair, peer address, and routing range rather than checking only one authentication field as you would with a password-based protocol.
In the server type list, HTTP means an HTTP proxy. The client sends forwarding requests to the proxy, and some connections use CONNECT to establish a tunnel. This is separate from the protocol used by the destination webpage; an HTTPS website does not mean you should change the server type. Check the server parameters to see whether the proxy connection itself uses TLS.
SOCKS5 is a general-purpose proxy protocol that supports TCP forwarding and may support UDP forwarding, depending on the implementation and server capabilities. The protocol itself does not provide encryption, and username and password authentication are not a substitute for transport encryption. Check whether the server requires authentication, and distinguish connecting to the proxy port from completing a request to its destination.
Rules describe which requests match a condition; policies describe how to handle matching requests. Rules are commonly evaluated in order, so place more specific conditions where they need to take priority and check the final policy at the end.
DOMAIN matches an exact domain. For example, DOMAIN,example.com,DIRECT applies to example.com. It does not automatically include subdomains such as www.example.com, or match webpage paths. To cover a domain and its subdomains, consider DOMAIN-SUFFIX instead of entering a full webpage address under DOMAIN.
DOMAIN-SUFFIX matches a domain and its subdomains, making it useful for applying the same policy to an entire domain. For example, DOMAIN-SUFFIX,example.com,PROXY matches example.com and its subdomains. A webpage may request resources from other domains, so matching the main domain does not mean every resource on the page will use the same policy.
DOMAIN-KEYWORD matches requests whose domain contains a specified string. Its scope is generally broader than an exact-domain or suffix match. It may also match unrelated domains containing the string, so short strings are not reliable boundaries for a website. Check actual matches in request logs and, if needed, use a more specific DOMAIN or DOMAIN-SUFFIX rule.
GEOIP matches according to the target IP's location in a geographic database; it does not determine location from a website's language, company name, or domain suffix. Changes in DNS results can change which IP rule matches, and database records may differ from actual deployments. When checking a GEOIP rule, review the resolved address, rule order, and resulting policy together.
IP-CIDR matches IPv4 address ranges using CIDR notation. The prefix length after the slash determines the subnet range, as in 192.0.2.0/24. Use IP-CIDR6 for IPv6 ranges; do not mix the two address types. Subnet rules match addresses, not webpage paths. If multiple domains share an address, consider which requests the rule may cover.
FINAL sets the policy for requests that did not match any preceding rule and should usually appear at the end. For example, FINAL,DIRECT sends requests with no specific match through DIRECT; it does not send every request directly. Changing the final policy affects many requests without individual rules. Set a clear goal first, then test specific rules and ordinary requests one by one.
PROXY, DIRECT, and REJECT are policies applied when a rule matches: send the request through a proxy, connect directly, or reject it. They serve a different purpose from match keywords such as DOMAIN-SUFFIX: policies determine the action, while keywords determine the condition. Rules may also refer to policy names defined in the configuration; use names that exist in the active configuration rather than assuming any label is a valid policy.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTThe first line lists the match keyword, domain condition, and policy in that order. The second line sets the final policy for other requests. example.com is used here only to illustrate the syntax; adapt your configuration to your own goals and existing parameters. For a complete walkthrough, see Configure DOMAIN-SUFFIX for selected websites.
Server entries, subscriptions, and configuration files each serve a different purpose. A successful import only means the data is in the client. Check the selected entry, active configuration file, and routing mode to understand how requests are actually handled.
Subscribe imports and updates server entries using a subscription URL you already have. You can refresh the corresponding list in the client when the subscription changes. Get the URL from your own service provider and store it securely; it may contain private access credentials. Hide the full URL in screenshots. Refreshing a list is separate from changing the active connection, so check the selected entry after updating.
Server refers to a set of connection parameters saved by the client, typically including an address, port, protocol, and authentication details. A “node” usually means this type of entry. The display name is only a label for identification; it does not indicate the server's location, performance, or availability. When adding a server manually, enter details for a server you are authorized to use and check that each value is in the right field.
A Config file stores rules and related settings. It is different from a subscription used to update the server list, and not every subscription URL can be imported as a rule configuration. After importing a file, confirm which one is active and check the policy names it references. Replacing a file may change routing and DNS behavior; keep a recoverable copy before making changes.
A diagnostic result reflects one observation under specific conditions. Recording the test method, time, destination, and error details is more useful than comparing a latency number alone. Change one setting at a time, then test again.
DNS resolves domain names to IP addresses. The result affects subsequent connections and some IP rule matches, so troubleshoot resolution failures separately from server authentication failures. When choosing a DNS method, consider how the request is handled rather than simply replacing one address. A successful lookup does not guarantee that the destination is reachable. See DNS settings for details.
Ping is related to latency testing. Results depend on the method, destination, and network conditions, and may not be equivalent to a traditional ICMP test. A lower number does not directly mean faster browsing or prove that authentication, TLS, and the destination request all succeeded. Keep test conditions consistent when comparing results, and see Ping settings to confirm the method in use.
Log is where you review requests, connections, and error details. When troubleshooting, match each action to the corresponding log entry and timestamp. First identify whether the issue occurred during DNS resolution, the handshake, authentication, or the destination response, then change the relevant setting. Logs may contain domains, addresses, or authentication details; remove sensitive information before sharing. See Log settings for logging details.
iCloud syncs related app data. The available sync options determine what is included; do not assume every record and credential will migrate automatically. Syncing configuration is separate from App Store purchase history: restoring an app purchase does not restore server parameters. Check sync status before changing devices and keep any necessary backups. See iCloud settings for details.
Connectivity Test checks whether a connection succeeds under specific test conditions. Passing once does not mean every destination and protocol will work. If a test fails, note the destination and error message, then check server parameters, the current network, and DNS results separately. If the test passes but a website still has problems, check which rule matched the request and how it was connected.
For a first-time setup, follow the tutorial to import and verify your configuration step by step. For specific options, see the Settings reference. The FAQ covers purchases, restoring purchases, and common connection issues. Identify which layer the issue belongs to before consulting the relevant guide; do not conflate purchase status, server availability, and rule behavior.