First distinguish app screens, connection protocols, and routing rules; then check the relevant settings. The terms below are explained in the context of using Shadowrocket on iPhone and iPad. English names are kept as they appear in the app and configuration files. Use the linked heading on each card to jump to a term.
Screens, modes, and controls each serve a different purpose. An imported server, an enabled connection switch, and a successful request are three separate things to verify.
Home is the main screen for viewing server entries, selecting one, and toggling the connection. A name in the list only means the app has saved a record; it does not confirm that the address, credentials, or remote server have been verified. After connecting for the first time, test with an actual request rather than relying on the switch state.
Global Routing determines how traffic is handled overall: Config applies configuration rules, Proxy uses proxy mode, and Direct connects directly. In Config mode, traffic follows the rules in the current configuration. If rules do not seem to take effect, first check that Global Routing is set to Config, then inspect the individual rules.
Config can refer either to the configuration file management screen or to a Global Routing mode. Opening the Config screen to view a file does not enable it or switch the overall mode. Check the file contents, selected configuration, and Global Routing mode separately; they are three distinct steps.
On Demand starts a VPN connection when configured network conditions are met. Its behavior depends on those conditions and the system state. It does not update subscriptions, filter servers, or fix connection details. First connect manually and verify access, then set up automatic triggers. This makes it easier to tell whether a problem comes from the connection settings or the trigger conditions.
Add Server creates a server record manually. The selected protocol determines which fields appear. Enter the address, port, authentication details, transport, and TLS settings to match the server information you already have. Reopen the saved record to check the fields, and do not enter a label in place of the server address.
A protocol defines how the app communicates with a server; it does not determine which destinations use a proxy. The descriptions below explain the technical components. Use the options shown in the app and the server details you already have to configure a connection.
Shadowsocks establishes a proxy connection using details such as a server address, port, encryption method, and password. The encryption method and password must match the server; a reachable address alone does not confirm successful authentication. If your server details include a plugin or other options, check whether the app supports them rather than omitting them and assuming they are equivalent.
VMess is a proxy protocol that requires checking the user ID and related authentication details. The user ID is often a UUID. Transport, path, Host, and TLS belong to other parts of the connection, so checking only the protocol name is not enough. If authentication fails, verify all connection details and the device time instead of repeatedly changing the port.
VLESS authenticates using a user ID; the connection may also involve transport and security settings. The protocol name alone does not indicate what encryption protection a connection has; check the actual TLS and other settings. After importing, verify the fields recognized by the app instead of mechanically applying options from another protocol.
Trojan is commonly used with TLS and authenticates using details such as a password. The server address, port, password, and certificate name must match the server. The address and certificate name may differ. If a certificate error occurs, first check the name, device time, and server certificate status; disabling verification is not a routine fix.
Hysteria2 is a QUIC-based proxy protocol that relies on UDP. The fact that another connection method works at the same address does not confirm that the current network allows the required UDP traffic. Check the protocol, authentication, and TLS settings first, then check UDP connectivity on the local network and remote server.
WireGuard uses keys to establish a tunnel. Configuration typically includes an interface address, peer public key, Endpoint, and allowed address ranges. Public and private keys serve different purposes and must not be swapped. Do not share a configuration containing a private key. Routing and DNS settings also affect what is reachable after connecting, so checking the key format alone is not enough.
An HTTP proxy typically uses an address and port to identify the proxy endpoint and may also require a username and password. HTTPS destinations are usually reached through a CONNECT tunnel, but that does not mean the connection between the client and proxy endpoint uses TLS. Distinguish the proxy endpoint's security settings from the protocol used by the destination website.
SOCKS5 is a proxy protocol that can handle different types of connection requests and may require authentication, depending on the server. UDP forwarding depends on the client configuration, server capabilities, and network path; the protocol name alone does not guarantee it. SOCKS5 does not itself imply encryption, so check the actual connection path.
Rules are usually checked in order, and the first matching rule determines the action. The example domain example.com is for syntax only. PROXY, DIRECT, and REJECT are policy names, not server addresses.
DOMAIN matches an exact destination domain name and is useful when a rule should apply to one specific host. For example, DOMAIN,example.com,DIRECT routes that domain using DIRECT; it does not automatically cover all subdomains. Enter a domain in the match condition, not a full URL with a scheme, port, and path.
DOMAIN-SUFFIX matches a domain suffix, making it useful for applying the same policy to a root domain and its subdomains. For example, DOMAIN-SUFFIX,example.com,PROXY can match example.com and its subdomains. If some subdomains need a different policy, place the more specific rules before this broader rule.
DOMAIN-KEYWORD checks whether the destination domain contains a specified string. It usually matches more broadly than an exact-domain rule. Short keywords can match unrelated domains, so check the actual results. Use this only when string matching is needed; for a known, fixed domain, prefer a more specific condition.
GEOIP matches the region associated with a destination IP in an address database, not the device's location or the language of a website. Database records, DNS results, and distributed services used by the destination can all affect the match. If a rule produces an unexpected result, first confirm the destination IP, then check the database and rule order.
IP-CIDR matches IPv4 address ranges, while IP-CIDR6 matches IPv6 ranges. The prefix length after the slash determines the range size. For example, IP-CIDR,192.168.0.0/16,DIRECT routes the specified IPv4 range using DIRECT. An IPv4 condition does not automatically cover IPv6; check both separately on dual-stack networks.
FINAL is the fallback rule used when none of the earlier conditions match. It usually belongs at the end of the rule list. For example, FINAL,PROXY sends remaining requests to PROXY; it does not send requests matched by earlier rules through a proxy. To diagnose a specific destination, find the first matching rule and check whether it falls through to FINAL.
PROXY means route through a proxy, DIRECT means connect directly, and REJECT means deny the request. Rules can also refer to policy group names defined in the configuration. The uppercase policy keywords and Proxy or Direct in Global Routing belong to different contexts: the former can be the action for an individual rule. A request can use DIRECT while the VPN is connected, so this alone does not reveal the switch state.
A subscription describes how content is retrieved, a server record describes how to connect, and a configuration file describes how to handle requests. A link opening successfully does not mean its contents are suitable for the import option you are using.
Subscribe is an entry point for subscription-related content. To determine whether it accepts a server list or a remote configuration, check the screen where it appears and the link contents. Use subscription details you already have, and confirm the content type before choosing an import option. Subscription URLs may contain access credentials; do not post them publicly or include them in public screenshots.
A server record is a set of connection details saved in the app. It can be added manually or created from a share link, QR code, or subscription. A label helps identify the record; the address, port, and authentication details are used to connect. Changing the label will not fix a remote server problem. Multiple records may point to the same address, so compare the protocol and port instead of relying on names alone.
A configuration file organizes rules, policy references, and related network settings. It serves a different purpose from a subscription containing only a server list. After importing one, check that its policy names exist, its rules are complete, and the file is selected. If traffic is not routed as expected in Config mode, check the mode, file selection, and rule matching separately.
A subscription update requests the existing link again and syncs the records with the returned content; it does not update the Shadowrocket app. The update may change record names, count, or settings. Afterward, confirm that the selected record is still the server you intended to use. Before editing subscription-generated content, check whether a future update will overwrite your changes and keep a private backup if needed.
A connection involves several steps. A successful test does not prove that a website is reachable, and resolving a domain name does not guarantee that the connection will succeed.
DNS resolves domain names to IP addresses. The result is used to establish a connection and may affect IP-based rule matching. If a domain cannot be reached, distinguish between no DNS response, an unsuitable result, and a correct result followed by a connection failure. Note the DNS settings and actual result, and change one variable at a time rather than changing rules and servers together.
Latency is the round-trip or response time measured using a specific test method. It varies with the test target, protocol, local network, and temporary congestion. It does not indicate available bandwidth or prove how websites, video, or other requests will perform. For a meaningful comparison, keep the test method and network conditions consistent, and consider actual access results too.
Connectivity Test checks a server's connection status. Results depend on the test method and target selected in the app. A failed test may be caused by the target's response, the protocol path, or network restrictions; it does not automatically mean all access will fail. Repeat the test, then verify the same server with an actual request. Keep both results to help diagnose the issue.
URL Rewrite modifies or redirects request URLs according to specified conditions. It differs from routing rules, which determine where requests go. Check the match expression and replacement target together; an overly broad condition may affect unintended requests. Rewriting HTTPS content also depends on encryption and related configuration, so adding an expression alone does not mean every request can be handled.
If you have not completed your first connection, follow the setup instructions in order. If you have imported content but the records are incomplete, first check the subscription type and fields. These terms explain what each part does; troubleshooting still depends on your current configuration and the results shown in the app.