Distinguish interface options, protocol parameters, and rule policies before checking your configuration. Terms are grouped by use case; select a category or term link to jump to its explanation.
Modes determine how requests are handled, toggles control connection behavior, and tests help verify results. These serve different purposes.
This option determines how requests are handled overall: Config, Proxy, or Direct. To apply rules in Rule, first make sure Config is selected. Changing modes does not change server parameters or make invalid authentication details valid again.
In Global Routing, Config processes requests using the current configuration, including policies selected by Rule. In the page navigation, Config is also where you manage configuration files. Use the context to tell these meanings apart. When troubleshooting rules that do not take effect, check both the mode and the configuration file currently in use.
This is the proxy mode in Global Routing. It sends requests through the proxy rather than applying everyday rules one by one. It is distinct from the uppercase PROXY at the end of a rule; do not treat them as interchangeable based on their similar meaning. After a temporary test, switch back to Config and check the results again to resume rule-based routing.
This is the direct mode in Global Routing. Requests access destinations over the current network. It can help test direct access, but results still depend on the network, destination service, and DNS resolution. The interface option Direct differs in capitalization and scope from the DIRECT rule keyword: the former is an overall mode, while the latter is a policy for a single rule.
On Demand controls connection behavior according to conditions set in the app. Available conditions and options depend on the current app interface. It determines when a connection is established; Rule determines how requests are handled. If the connection starts automatically or its status changes, check these conditions before adjusting rules.
Use this entry point to add your existing server details. Select the protocol type, then enter the address, port, and authentication parameters from your existing information. Required fields vary by protocol; changing Type alone does not convert a configuration. After saving, check key fields for accidental spaces or missing transport settings.
This feature checks connection reachability. Results depend on the test method, target, and current network. The displayed latency is not available bandwidth, nor does it mean every website will work. When troubleshooting, compare the test result with an actual request to distinguish server reachability, successful authentication, and successful access to the destination.
DNS resolves domain names to IP addresses, a step required before many connections can begin. A resolution failure is different from a proxy connection failure; changing routing policies will not necessarily fix DNS. If a domain cannot be reached, check the DNS settings and returned address first, then see which rule matched the request.
A protocol name describes how a connection works, not the quality of the service. Use the details provided for your existing server when entering parameters.
Shadowsocks establishes a proxy connection using parameters such as the server address, port, encryption method, and password. The encryption method must match the server; do not substitute options just because their names look similar. If your existing details include additional transport parameters, check each one rather than testing with only the address and password.
VMess is a proxy protocol with user authentication. The user ID must match the server's authentication settings. Connections may also involve transport type, TLS, path, and Host parameters, each of which serves a different purpose from authentication. Seeing a server entry after importing only confirms that the details were saved; it does not mean every field is correct.
VLESS uses a user ID for authentication, and its transport and connection security settings must be checked separately. It is a different protocol from VMess; do not switch the Type just because both may use a UUID. Keep all parameters required by the server and use the fields available in the app to determine how to enter them.
Trojan typically protects connections with TLS and uses a password for authentication. In addition to the address, port, and password, check the server name and certificate-related settings required by TLS. A connection may still fail if TLS verification fails, even when the authentication details are correct. Check both stages separately.
Hysteria2 is based on QUIC and uses UDP for transport. Its authentication, TLS, and other settings must match the server. Being able to establish a regular TCP connection on the current network does not guarantee that the UDP path is available. Check both protocol parameters and network reachability; do not diagnose a failure based on a single latency reading.
WireGuard uses keys for authentication. A typical configuration includes keys, a tunnel address, an Endpoint, and allowed address ranges. These key and address fields are not substitutes for the password and server address used by conventional proxy protocols. Hide private keys and other authentication details when sharing diagnostic information; retain only the field names needed for troubleshooting.
HTTP and SOCKS5 are different proxy protocols. Choose the one used by your existing server, not based on the type of website you plan to visit. Check whether the server requires a username and password or provides a protected connection. The same address and port do not make the protocols interchangeable.
The rule type determines which field is checked; the policy determines what happens after a match. The domains below are examples of syntax only.
DOMAIN matches an exact domain and does not automatically include its subdomains. For example, DOMAIN,example.com,PROXY matches example.com; do not assume it also matches api.example.com. To cover an entire domain suffix, check the matching scope of DOMAIN-SUFFIX before choosing a rule.
DOMAIN-SUFFIX matches a specified domain and its subdomains, making it suitable for requests under the same domain suffix. DOMAIN-SUFFIX,example.com,PROXY can match both example.com and api.example.com. If a subdomain needs a different policy, put its more specific rule before this broader rule.
DOMAIN-KEYWORD matches a keyword in a domain; it does not match a specific complete domain suffix. A keyword that is too short or common may match domains you did not intend to include. Consider its scope before adding the rule and check matches against actual requests to prevent a broad rule from deciding the policy too early.
GEOIP matches a destination address using IP geolocation data, for example, GEOIP,CN,DIRECT. This classification relies on an address database; it does not directly identify webpage content, domain suffix, or actual service location. Also consider the address returned by DNS and whether an earlier domain rule has already matched.
IP-CIDR matches a specified IPv4 subnet. The number after the slash indicates the network prefix length. IP-CIDR,192.168.0.0/16,DIRECT applies a direct policy to that address range. A broader subnet covers more destinations. Confirm the target range before writing the rule, then choose its position in the list.
IP-CIDR6 matches IPv6 subnets and is written separately from the IPv4 IP-CIDR rule. For example, IP-CIDR6,2001:db8::/32,DIRECT demonstrates the syntax using a documentation address. IPv4 rules alone do not mean IPv6 requests use the same policy; check the addresses actually returned.
USER-AGENT matches the User-Agent field when it can be read from a request; it does not automatically identify all traffic by app name. Relevant fields in encrypted requests are not always directly readable, so do not assume this rule applies to every request. Before adding it, confirm the app can access the required field and that the matching condition is appropriate.
FINAL handles requests that did not match any earlier rules and is usually placed at the end of the Rule section. It does not require a domain or subnet match value. Common forms include FINAL,PROXY and FINAL,DIRECT. If placed too early, it takes over requests before later rules can handle them.
Capitalization helps distinguish levels: the Proxy interface option and the PROXY rule keyword are not interchangeable.
The [Rule] section in a configuration file organizes matching conditions and handling policies. A typical rule consists of a type, a match value, and a policy. Rule is not a server list and does not supply missing authentication details. When troubleshooting, first confirm that Global Routing is set to Config, then check the rules in the active file.
PROXY is the proxy policy keyword in a rule. It sends matching requests through the proxy. The connection still depends on the current proxy selection and valid server parameters; writing PROXY does not establish a working connection. It determines the policy for matching requests and is not another way to set Global Routing to Proxy.
DIRECT applies a direct policy to matching requests, often to specify how certain domains or addresses should be handled. Direct access still depends on the current network being able to reach the destination and on successful DNS resolution. This applies to requests matched by the rule; it does not switch the entire client to Direct mode in Global Routing.
REJECT denies matching requests and is used to explicitly block access within a match range. If a page that should work cannot be opened, check whether an overly broad reject rule covers one of its required domains. Prefer narrowing the match or adding a more specific exception instead of rewriting the entire configuration before identifying the cause.
In rule mode, rules are evaluated from top to bottom, and the first match determines the request policy. More specific rules do not automatically move to the top. A common approach is to put explicit exceptions first, broader rules next, and FINAL last. After changing the order, send another request and check which rule now matches.
In the example below, api.example.com uses DIRECT, other requests under the same domain suffix use PROXY, and FINAL handles the rest. This example illustrates matching order only; check it against your own goals and existing connection details before applying it.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTIf DOMAIN-SUFFIX is moved to the first line, api.example.com matches it first. The later DOMAIN rule cannot override a policy that has already been applied. See the configuration field reference for field details and rule examples.
Server entries, rule files, and purchase history are three different things. Importing or restoring one does not automatically take care of the others.
Subscribe imports and updates your existing server list; its contents are maintained by the corresponding subscription source. Updating a subscription does not switch the active configuration file or change rule policies. A subscription URL may contain access credentials, so hide the full URL and any authentication parameters in screenshots, logs, and support materials.
Server details are the parameters needed to connect, such as the address, port, protocol, and authentication. They are also commonly called node details. A server's display name is just a label for identification and does not determine how the connection works. Enter and check the key fields using your existing details. See the quick-start guide for import steps.
A configuration file organizes settings into sections such as General, Rule, Host, and URL Rewrite, each with a different purpose. A server subscription mainly provides connection details, while a configuration file describes how requests are resolved, matched, and handled. They are not interchangeable. Save a copy before editing, then check which file is active and the Global Routing option after switching.
The [Host] section maps specified domains to addresses. It changes the address associated with a domain; it does not directly specify PROXY or DIRECT. An incorrect or outdated mapping can point a request to the wrong destination, even if the Rule syntax is correct. When troubleshooting resolution issues, check these mappings alongside DNS settings.
The [URL Rewrite] section processes request URLs according to matching conditions. Its purpose differs from Rule connection policies. A rewrite may change the request path or result, so do not use rewrite rules as ordinary domain-routing rules. Before making changes, identify the original URL, match scope, and expected result, and confirm that the required request content can be processed.
iCloud sync works with the relevant settings in the app. Check the app to see which data syncs and which options are enabled. Syncing data does not restore App Store purchase history or replace connection checks after migration. After moving to a new device, check your server list, active configuration, routing mode, and any system permissions needed for the first connection.
Purchased Items is the App Store entry point for finding purchases made with the original account and redownloading the app. It does not restore rules or server details. Shadowrocket is primarily for iPhone and iPad; check the App Store listing for compatibility with other Apple devices, system requirements, and whether the purchase is universal. See how to restore a purchase when moving to a new device.