Tell interface controls apart from connection protocols and rule actions. Each entry has its own anchor for checking a setting or documenting an issue. For step-by-step instructions, see the relevant guide or server management section.
01 · Settings and behavior
Interface and settings
Identify the global mode before checking individual rules. Connection settings, DNS, and URL rewriting address different issues.
The control for choosing how traffic is handled overall. The main options are Config, Proxy, and Direct, with Scene applying behavior based on configured conditions. The mode affects whether rules in the current configuration are used, so check it before troubleshooting routing. It does not add a server or indicate that the connection is on.
In Global Routing, Config means traffic is handled according to the current configuration rules, rather than sending every request through the same route. In configuration management, it can refer to the configuration entry point or related content. When instructions say “switch to Config,” check the screen to tell whether they mean changing the mode or selecting a different configuration file.
In Global Routing, Proxy sends the relevant traffic through a proxy. The connection still depends on the selected server and its settings. You can use it to narrow down whether a problem is related to rule selection. Switching to Proxy will not fix an unavailable server, an incorrect password, or a failed transport connection.
In Global Routing, Direct connects without sending the relevant requests through a remote proxy server. It can help compare the regular network path with the proxy path, but it does not turn off the app or remove the system VPN configuration. To end the connection, check the connection switch and On Demand settings; the mode name alone does not tell you whether it is disconnected.
Distinguish Direct mode from the DIRECT rule action
Selects behavior based on configured scene conditions, such as using different settings on different networks. Scene applies at the scene level; it is not an individual request-matching rule like DOMAIN. Check the conditions and actions for the selected scene first. Switching scenes does not automatically fix a server.
Uses the system’s on-demand mechanism to start or maintain a connection based on network conditions. Wi-Fi and cellular networks can be configured separately. On Demand controls when to connect, not whether each domain should use a proxy or connect directly. If the connection turns off and then comes back on, check this setting and related system settings before repeatedly deleting server records.
DNS resolves domain names to IP addresses, a step often involved before a connection can be established. Successful resolution does not mean server authentication succeeded, and a DNS issue cannot be fixed just by changing a rule action. When troubleshooting, note the domain, DNS settings, and response, then check the connection log to identify which layer failed.
Rewrites or otherwise processes request URLs based on matching expressions. This is different from rules that decide which route a connection takes. Before making changes, understand the match scope and target; an overly broad expression can affect requests that were working. What can be handled for HTTPS requests also depends on encryption visibility and related settings—adding an expression alone does not guarantee it will work.
Check the match first, then the conditions for processing
A proxy protocol that connects using settings such as server address, port, encryption method, and password. The encryption method must match the server; a correct address and password alone may not be enough. After importing a share link beginning with ss://, check the fields rather than assuming the prefix confirms that the connection will work.
A proxy protocol that authenticates using a user ID and other settings. Server records commonly include transport and TLS settings as well. After importing, check the hostname, path, and other transport fields. A badly incorrect system clock can also interfere with authentication, so don’t check only the server port.
Check protocol settings and transport settings separately
A proxy protocol that uses a user ID. It is different from VMess; changing the protocol name alone does not make all the existing settings compatible. The protocol itself does not provide transport encryption, so check which secure transport the server requires. Preserve the transport, hostname, and other fields in the original share link.
A proxy protocol that typically uses TLS and password-based authentication. The server address, certificate hostname, and password serve different purposes and cannot substitute for one another. If you see a certificate error, check the hostname, device time, and certificate status first. Skipping verification is not a standard fix.
Check authentication and certificate validity separately
A QUIC-based proxy protocol that requires UDP connectivity. The protocol version and authentication settings must match the server; similar names do not mean settings can be mixed. UDP restrictions, server misconfiguration, or certificate issues can all prevent a connection. A failed website request alone does not identify the cause.
A protocol that establishes a tunnel using a public/private key pair and peer settings. It typically requires a key, endpoint, tunnel address, and other details. Its fields differ from a simple address-and-password record, so match them against the existing configuration one by one. A private key is sensitive information; do not expose it in shared configurations, backups, or issue reports.
HTTP proxy and SOCKS5 are two different proxy protocols with different handshakes. Do not switch between them just because they use the same port. Check the server’s actual capabilities to find out whether it requires a username and password or supports UDP. The protocol name alone does not guarantee encrypted transport; check the security requirements separately.
Protocol type ≠ port number
03 · Matching and actions
Rule keywords
In Config mode, rules are generally checked from top to bottom, and the first match determines the action. The example domain example.com is used only to illustrate syntax.
Matches an exact domain name, useful when you want to handle a specific hostname. Enter the domain itself, without a URL scheme, path, or query parameters. Matching example.com does not also match all subdomains. To cover a domain and its subdomains, check DOMAIN-SUFFIX.
Matches a domain suffix, covering the specified domain and its subdomains. Use it to apply the same action to a domain family. It is not a search for a string anywhere in the domain and does not match URL paths. After adding a rule, check its order against more specific rules so that exceptions are not overridden first.
Checks whether a domain contains a specified string, generally matching more broadly than exact-domain or suffix rules. A short string may match unrelated domains, so check the logs to see what actually matched. If you can describe the target scope precisely, prefer a more specific match that is easier to maintain.
Matches a target IP according to its classification in a geographic database—not the webpage language, domain suffix, or user’s location. A domain connection may need to be resolved first, and database classifications can differ from actual network deployments. Check the target IP and match record rather than inferring from the website name.
Matches IPv4 and IPv6 network ranges, respectively. The number after the slash indicates the network prefix length. It describes an address range, not a port or domain suffix. An IPv4 rule does not automatically cover IPv6 connections to the same service, so check both address types when troubleshooting a dual-stack network.
Handles connections that did not match any preceding rules. This fallback rule usually goes at the end of the list, and its action determines what happens to otherwise unclassified traffic. Changing it can affect a broad range of connections. If a specific rule is not matching as expected, check the domain, rule order, and current mode before changing FINAL.
The action taken when a rule matches: use a proxy, connect directly, or reject the connection. These are not matching conditions. Distinguish the uppercase keywords from the Proxy and Direct mode names in the interface. If the log shows REJECT, the failure may be exactly what the rule requested; first check whether the intended rule matched.
Imports and updates an existing subscription. Its content is returned by the server at the subscription URL. A successful update only means the client received and processed a response; it does not guarantee that every server record in it will connect. Subscription URLs may contain credentials, so hide the full address in screenshots, logs, and notes you share.
After importing, check the record count, names, and connection results
The entry point for adding a server record manually. Choose a protocol based on your existing server details, then fill in its corresponding fields. Passwords, user IDs, keys, and transport settings vary by protocol and cannot be interchanged. Saving only adds the settings to the local list; select the record and test the connection to check whether it works.
A server record stores the address, authentication, and transport settings used to connect. A share link encodes one record as text for easier import. A single share link generally does not retrieve ongoing list updates like a subscription URL. A QR code simply carries text; after scanning, check the import type and settings, and never share a QR code containing credentials.
Checks whether a test target is reachable and reports the elapsed time for the selected test method. Results depend on the target, network path, and test method; they do not measure bandwidth or represent how every website will perform. For comparisons, keep test conditions consistent. If a test times out, continue troubleshooting DNS, the handshake, and the target’s response separately.
Organizes rules, DNS, and other settings, unlike a subscription that contains server records. After downloading or editing a configuration, confirm which one is active and whether Global Routing is set to Config. Keep a recoverable copy before editing and make changes one at a time, so you can identify the cause if something goes wrong.
Edit → select → verify rule matches
For full instructions on importing, updating, organizing, and backing up, see the server management guide.
05 · Devices and permissions
Installation and system permissions
Processor architecture, app purchase records, and network permissions are managed separately; one does not replace another.
A system record that authorizes the app to handle relevant network traffic. It is not information about a remote server. When prompted to add it on the first connection, confirm that the request was initiated by Shadowrocket, which you just opened, then follow the system instructions. Removing this record may mean you need to add it again next time; it will not fix an incorrect server password.
Check system authorization and server authentication separately
These labels distinguish processor architectures and help you choose the right installer; they do not indicate different proxy modes. On a Mac, check About This Mac for its chip or processor, then choose the Apple silicon or Intel version. arm64 in an Android installer also refers to the device architecture. Follow the download page’s instructions to approve the first launch on each platform.
An App Store app record associated with your purchasing account. On a new device or after reinstalling, find and redownload the app using the original account. The iPhone / iPad app costs $2.99 as a one-time App Store purchase; the Mac / Windows / Android / Linux versions are free and available from this site. Check the App Store listing for developer Shadow Launch Technology Limited and app ID 932747118. System requirements are as listed on the App Store page.
An operating system confirmation for an app’s first launch or installation source is separate from VPN configuration authorization. After verifying the download came from this site, Windows users can select “More info” in SmartScreen and review “Run anyway”; macOS users can review “Open Anyway” under Privacy & Security; Android users can allow the app used to run the installer to install unknown apps. If the system offers no approval option, keep the warning and check device management restrictions. Do not turn off overall protection.