Find settings by interface term, check parameters by protocol, and understand request routing through rule keywords. English interface names remain unchanged; the explanations clarify concepts and their scope.
Suggested reading order: Global Routing → Config → rules → policy actions. Before importing, have your existing subscription or server details ready.
First identify whether you are changing connection triggers, the overall routing mode, or a specific server parameter. These settings are not interchangeable.
This setting determines how requests are handled overall and offers three modes: Config, Proxy, and Direct. These correspond to configuration-based routing, proxy routing, and direct access. Use the English interface labels when operating the app. Changing the mode affects where requests go, but does not supply missing server credentials or prove that the network connection is working.
In Global Routing, Config handles requests according to the rules in the current configuration. A matched rule may use a proxy, connect directly, or reject the connection. Config does not mean that every request uses a proxy. When troubleshooting routing, first confirm which configuration file is active, then check rule order and the action applied by the final match.
In Global Routing, Proxy sends proxyable requests through the currently selected proxy. Use this mode to compare rule-based routing with the proxy path. It is a different setting from the PROXY action at the end of a rule. Even with Proxy selected, remote authentication, TLS, and the local network must all work; the toggle alone does not confirm a successful connection.
In Global Routing, Direct accesses destinations over the local network. Use it to compare the local network path with the proxy path. Success depends on the current network, the destination service, and DNS results. Direct does not remove server entries or verify DIRECT rules in the configuration file.
On Demand starts a connection based on preset network conditions, such as behavior configured for Wi-Fi or Cellular. It answers “when should a connection start?”; Global Routing answers “how should requests be handled?” If the connection starts again after being manually disconnected, check the trigger conditions first, then decide whether to adjust this feature.
Use this screen to enter server details manually. Start by choosing the protocol that matches your existing parameters. Protocols use different authentication fields, transport fields, and security settings, so copying only the address and port is not enough. Before saving, compare every field with the information from your service provider, especially the UUID, password, TLS, and server name.
Data displays traffic statistics. Check both the traffic being counted and the time period. Client-side records and server-side billing statistics may use different methods, so their figures may not match exactly. Increasing traffic only indicates that data is being transferred; check actual access results to determine whether the requests reached their destinations.
A protocol name determines how its parameters are interpreted; it does not guarantee a particular speed or quality. Use the protocol and complete parameters supplied for your existing server.
Shadowsocks establishes a proxy connection using parameters such as the server address, port, password, and encryption method. The encryption method must match the server; similar names are not interchangeable. If an entry saves but will not connect, check the password and encryption method first, then the address, port, and network reachability.
VMess uses parameters such as a UUID for authentication and can work with different transport methods. A correct UUID does not guarantee that the other fields are correct; check the path, Host, TLS, and other settings against the server details. Do not reuse fields from a different protocol just because it uses the same address. Review imported settings against the original information.
VLESS uses a UUID for authentication. The protocol itself does not encrypt transmitted content, so consider TLS and other configured security layers when assessing the connection. Check the transport type, server name, and any additional fields required by the server. Matching the protocol name is only a starting point; the complete set of parameters must match for the connection to work.
Trojan typically uses password authentication over TLS. Password authentication and certificate validation are separate checks. The server address is used to connect, while the server name in TLS identifies the server; they do not have to be the same text. If you see a certificate error, check the server name, device time, and server certificate rather than disabling verification.
Hysteria2 is based on QUIC and typically requires a working UDP path between the local network and the remote server. Authentication details, TLS, and any other server-required fields must match. If the same settings behave differently on different networks, check the network path and parameters separately; the protocol name alone does not indicate sustained transfer speed.
WireGuard is a tunnel protocol that identifies peers using keys. It typically requires matching interface addresses, peer details, and routing ranges. A private key is sensitive and should not be shared in diagnostic screenshots or configuration text. If details are missing, ask the provider of your existing service information. Do not swap public and private keys or enter an arbitrary interface address.
Rules typically combine match conditions with actions. The examples below explain syntax only; example.com is a sample domain, not a server you need to connect to.
DOMAIN matches a request by its full domain name, making it suitable for applying a policy to one specific hostname. Matching example.com does not automatically match all its subdomains. Do not include a protocol prefix or web path in a rule domain; those are parts of a URL, not the domain name.
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX matches by domain suffix and can include both the root domain and its subdomains, making it useful for applying one policy across a domain hierarchy. It does not match arbitrary strings that merely contain the suffix. For a single host, use a more precise condition where possible, and place specific rules before broader rules that could override them.
DOMAIN-SUFFIX,example.com,PROXY
GEOIP matches a destination using regional labels in an IP geolocation database; it does not use the website’s language or the user’s location. Database classifications may differ from where a service is actually hosted, and different DNS results can produce different matches. When troubleshooting, note the destination IP and database information rather than relying on assumptions based on the domain name.
IP-CIDR matches IPv4 address ranges using CIDR notation. For example, 192.168.0.0/16 represents a range of private addresses. The number after the slash is the prefix length, not a port. Use IP-CIDR6 for IPv6 ranges. Check the address family and range to avoid extending a targeted change to unrelated destinations.
IP-CIDR,192.168.0.0/16,DIRECT
FINAL sets the action for requests that do not match any preceding rules and is usually placed at the end of the rule list. It does not add another connection; it determines how remaining requests are handled. Changing FINAL can affect many requests. Identify which destinations need specific rules before changing the fallback, then verify the results with actual requests.
FINAL,PROXY
PROXY is a rule action that sends a matched request through a proxy, usually specified after the match condition. It belongs to the rule layer, while Proxy in Global Routing sets the overall routing mode. A usable proxy must still be selected when a request matches PROXY. The rule does not provide service access or restore a failed server connection.
DIRECT means that a matched request accesses its destination over the local network, without using the selected remote proxy server. It determines the route but does not guarantee that the destination is reachable. You can create rules for local network destinations based on their actual subnet, but check the subnet range first to avoid changing how unrelated requests are handled.
REJECT blocks matching requests and is suitable for destinations you explicitly want to prevent access to. If some app features suddenly stop working, check whether an overly broad reject rule is matching their requests. Narrow the match and note the results as you troubleshoot; do not mistake a rejected request for server latency or a DNS failure.
A server subscription tells you which server details are available; a configuration file determines how requests are handled. Identify the type of content you are importing, then check whether an update changed the active connection or rules.
Subscribe retrieves and updates server details from an existing subscription URL provided by your own service provider. A subscription URL may contain access credentials, so do not post or share it publicly. A successful update only means the content was retrieved. Server availability still depends on accurate details, service status, and the current network.
A SERVER entry typically includes an address, port, protocol, and authentication details. In Chinese documentation, “node” often refers to this kind of entry. Its name is only a label, not evidence of speed or availability. Seeing an entry in the list does not mean a connection has been established; check that it is selected and verify access with an actual request.
A configuration file holds settings such as rules and DNS, unlike a subscription that only updates the server list. After importing a file, confirm that it is the active configuration. Save the original before replacing it, then review changes to rules and related settings so you do not mistake a configuration change for a server problem.
Rules connect match conditions to policy actions. They are usually checked in order, with the first matching condition determining how a request is handled. The order of specific and broad conditions directly affects the result. Change one thing at a time and test with the same destination; otherwise, even if access is restored, it may be unclear which change fixed the problem.
iCloud Sync depends on your account, system permissions, network, and the relevant in-app settings. Check the interface for which data is supported. Syncing does not restore a purchase or necessarily copy every app state between devices. Before switching devices, save any configuration you need separately and confirm that the required data has arrived on the destination device.
System permissions, DNS results, test readings, and purchase records relate to different parts of the process. Checking each layer in turn is more effective than repeatedly toggling the connection.
DNS resolves domain names to IP addresses. Check DNS resolution separately from proxy traffic. If a latency test returns a result but a website will not open, DNS may still have failed or returned an unsuitable address. Record your current DNS settings before making changes, then retest the same domain. Avoid changing the server and several DNS settings at once.
Latency is the response time measured for a specific test method and target. It is not the same as sustained download speed or total webpage load time. Results from different test methods cannot be compared directly. Low latency does not guarantee that authentication, TLS, DNS, and access to the destination are all working. Check Connectivity Test alongside results from actual requests.
On the first connection, Apple’s system may ask for permission to add a VPN configuration. This system record is required to manage network extension connections and is separate from a remote server’s address, password, or subscription validity. If you accidentally remove it, return to Shadowrocket and follow the prompts to authorize it again. Then check the selected server and test access.
Purchased in the App Store lets you view apps associated with the current purchasing account, which can help confirm purchase records when changing or restoring a device. Restoring the app does not automatically restore all server details; check configuration data separately. Shadowrocket is available only through the App Store. Check the App Store page for system requirements and device compatibility.