Find app terms, protocols, and configuration concepts by use case. First identify whether you’re changing the overall mode, a match condition, or an action policy, then go to the relevant screen. Names that include Proxy can refer to different layers.
The mode determines whether traffic is routed according to a config; the connection switch controls whether a connection is established. Check them separately.
The main screen for viewing server entries, the current selection, and the connection switch. Entries in the list mean the details have been saved; they do not confirm a successful connection. When getting started, check the selected server before using the connection switch, then review system prompts and test actual access.
A mode that controls how connections are handled overall. The options are Config / Proxy / Direct. If rules are not taking effect, first check whether Config is selected, then review the rule text. Changing the mode does not correct server settings or replace a connectivity test.
As a Global Routing mode, Config applies rules in the currently enabled configuration to choose a policy. This is distinct from the Config screen used to manage configuration files, even though they share a name. After selecting this mode, check which config is enabled and whether it contains the expected Rule.
The Proxy mode in Global Routing routes connections through the currently selected proxy and is useful for comparison with Config mode when troubleshooting. It is not a protocol and does not guarantee that the current server is available. If Proxy works but Config does not, check which rule matched and which policy it selected before re-entering all the server settings.
The Direct mode in Global Routing connects to destinations through the current network. It is a different layer from DIRECT in uppercase, which is an action policy in an individual rule. For a useful comparison, keep the destination and local network unchanged so you can identify which layer accounts for the difference.
A feature that triggers connection behavior based on configured network conditions, such as switching between Wi-Fi and cellular. It determines when to connect; it does not choose PROXY or DIRECT for each domain. If the connection comes back after you disconnect manually, check the On Demand conditions and the system’s current network instead of repeatedly toggling the switch.
A diagnostic tool for checking connectivity. Results vary with the test method, destination, and current network. Latency measures the response time of a single test; it is not sustained transfer speed, and a successful test does not mean every website is reachable. If a test times out, check the protocol settings, system time, and actual connection results.
A protocol is a communication method shared by the client and server. When using server details you already have, check the protocol, authentication, and transport settings together—not just the address and port.
A proxy protocol that uses a shared secret and encryption method. Both ends of the connection must use compatible settings. Check the server address, port, password, and encryption method; any additional transport settings must also match the original details. Don’t substitute an encryption method just because its name looks similar—a mismatch can prevent the connection.
A proxy protocol that authenticates with parameters such as a user ID and can use different transport methods. In addition to the address and port, check the user ID, transport type, and TLS settings. If an existing subscription imports successfully, compare the imported result with the original details before making manual changes, so related fields such as Host or the path aren’t missed.
A proxy protocol with a streamlined authentication design. Authentication and transport security are separate considerations. VLESS itself does not provide full transport encryption; the connection also depends on the accompanying security and transport settings. Don’t change a VMess entry to VLESS and reuse all its fields—use the server details you already have.
A protocol that typically carries proxy traffic over TLS and uses a password for authentication. Check the connection address, the server name used for TLS validation, and the password separately; each serves a different purpose. If certificate validation fails, first check the name, system time, and server certificate. Disabling validation should not be a routine fix.
A QUIC-based proxy protocol whose performance depends in part on the network’s UDP support. Enter authentication details, TLS settings, and any options provided by the server as a matching set. If results differ significantly after switching networks, note the network differences before troubleshooting; the protocol name alone does not predict speed or reliability.
A protocol that establishes an encrypted tunnel using public and private keys and peer configuration. Its settings differ from a server entry that only requires a password. Check the keys, endpoints, and tunnel settings together; a public key is not a regular password. A private key is sensitive information, so redact it before sharing configuration excerpts or diagnostic records.
A rule type specifies what to match; the policy at the end specifies what to do when a rule matches. The addresses and domains below illustrate syntax only—they are not server or subscription sources.
Matches an exact domain, for example DOMAIN,example.com,PROXY. This rule matches example.com; it does not automatically include all subdomains. To cover an entire domain hierarchy, consider DOMAIN-SUFFIX and check whether an earlier rule matches first.
Matches a domain and its subdomains, for example DOMAIN-SUFFIX,example.com,PROXY. It matches along domain boundaries rather than searching for any similar string. Use it to apply the same policy to a domain hierarchy. If a subdomain needs an exception, place the more specific rule first.
Matches when a domain contains a specified string, for example DOMAIN-KEYWORD,ads,REJECT. The keyword does not need to form a complete domain level, so it may match domains you did not intend to handle. Short keywords especially need careful review of match records; a similar string does not necessarily mean the domain is relevant.
Matches IP geolocation categories in a database, for example GEOIP,CN,DIRECT. A database category does not indicate the device’s actual location or where a website operator is based. If a destination uses a CDN or its resolved address changes, the match may change too. Check the actual destination IP when troubleshooting.
Matches a destination within an IPv4 network, expressed as an address and prefix length, for example IP-CIDR,192.168.0.0/16,DIRECT. The number after the slash defines the network range, not a server port. Before writing a local network rule, confirm the actual subnet so an overly broad range doesn’t affect connections intended to use another policy.
Matches IPv6 address ranges, for example IP-CIDR6,2001:db8::/32,DIRECT, using a documentation-only address. Check IPv4 and IPv6 separately; an existing IPv4 rule does not mean IPv6 connections will match it. If the same domain behaves differently across connections, check which address type is actually in use.
Matches based on User-Agent information when it is available. This is not a universal way to identify apps, and relevant information in encrypted requests may not always be visible. If a rule does not match, first check whether the request provides usable information, then verify the rule conditions.
Sets a fallback policy for connections not matched by earlier rules, for example FINAL,PROXY. It usually goes at the end of the Rule list and does not need a domain or network condition. If FINAL comes before specific rules, they may never get a chance to match, so rule order is an important part of config review.
Uppercase PROXY, DIRECT, and REJECT are rule policies, not Global Routing modes in the app interface.
Routes a connection through a proxy when a rule matches. The actual route depends on the current proxy selection and configuration. PROXY specifies an action; it does not include a server address or authentication details, or guarantee availability. If the log shows a PROXY match but access still fails, check the selected server, protocol settings, and connectivity.
Connects directly to the destination when a rule matches, without routing that connection through a proxy server. This does not mean DNS is skipped or that the destination is reachable over the current local network. If direct access fails but the proxy route works, check the local network, DNS results, and destination status; changing rule order alone may not explain the problem.
Rejects a connection when a rule matches, often to block requests that are clearly unwanted. This differs from a server timeout: a rejection is an intentional policy decision, while a timeout may indicate a network or settings issue. If a normal feature is affected, find the matching reject rule and narrow its conditions or add an exception rather than deleting all rules at once.
Rules are checked from top to bottom. The first rule whose conditions match usually determines the connection policy, and later rules are not considered. A more specific rule does not automatically get priority; its position matters too. In practice, put explicit exceptions first, broader rules next, and FINAL at the end as a fallback.
Server details tell Shadowrocket where to connect; the config determines how connections are handled. After importing, check the current selection, enabled config, and actual connection status.
A way to retrieve and update existing server entries using a URL obtained from your own service provider. A subscription URL may contain access credentials, so treat it as sensitive and keep it out of public screenshots. Updating the server list does not also update routing rules in Config; check each separately.
The type used to add a subscription source. Enter the complete subscription URL you already have, not an account management webpage. The example https://example.com/sub?token=xxxx illustrates the format only and cannot be used to connect. After saving, check that the expected server entries appear. Make sure the URL wasn’t truncated or copied with extra spaces or missing query parameters.
Configuration text that organizes connection behavior and rules, commonly in sections such as [General], [Rule], [Host], and [URL Rewrite]. Each section has a different purpose; put rules in the appropriate section rather than appending them anywhere at the end. After importing, check which items are enabled. Keep a copy of the original config before editing so you can compare or restore it.
The process of resolving a domain name to an IP address, which is required before many network connections can be established. Whether resolution succeeds and which address it returns can affect the connection destination and IP-based rule matches. If a domain cannot be reached, check DNS separately from proxy connectivity rather than changing several settings at once.
A configuration section for handling request URLs according to conditions. Its purpose differs from Rule, which selects the connection route. Whether a rewrite takes effect also depends on the request matching the conditions and the relevant information being available; don’t assume every encrypted request can be rewritten. If you only need to change whether traffic goes direct or through a proxy, check Rule first instead of adding a rewrite.
For step-by-step instructions, continue with the user guide. If rule results differ from what you expect, preserve the current config and match records, then adjust one item at a time.