First, distinguish interface options from protocol names and rule keywords, then check the relevant settings. This glossary groups common terms into five categories. Labels remain as they appear in the app, with explanations of their purpose, scope, and common points of confusion.
Overall traffic handling, automatic connection triggers, and server entry each serve a different purpose. Before changing a setting, decide whether you need to change the connection route or the conditions that trigger a connection.
This setting controls how traffic is handled overall. Its three options are Config, Proxy, and Direct. It determines how connections are routed; it does not supply server addresses or authentication details. After importing a server, check this setting separately.
See how to use Global Routing →Selecting Config in Global Routing means connections are handled according to the currently enabled configuration and rules. It does not mean all connections go through a proxy. Config also appears in configuration management, so use the surrounding context to distinguish the mode from a configuration file.
The Proxy option in Global Routing typically sends traffic through the selected proxy route. It can help reduce the effect of rule matching temporarily during troubleshooting. It will not fix incorrect server parameters or prove that every service is reachable. After testing, restore the option that fits your needs.
The Direct option in Global Routing typically connects to the destination through the local network rather than the selected remote proxy. Use it to compare the local network with the proxy route. Switching to Direct does not turn off the app's connection switch or guarantee that the destination is reachable.
On Demand triggers connections based on configured conditions. Check the specific conditions in the app's current settings. It serves a different purpose from Global Routing: On Demand controls when a connection is triggered, while Global Routing controls how traffic is handled. After enabling it, confirm that the server is available and check what happens after a manual disconnect.
Add Server is where you manually enter details for an existing server. The fields vary by protocol. Select the correct type, then check the address, port, authentication, transport, and TLS settings. The display name is a local label; changing it does not alter the connection parameters.
See the server field guide →A protocol defines how the client and server authenticate and transmit data. These explanations help you understand existing server parameters; a protocol name alone does not indicate speed or reliability.
Shadowsocks is a proxy protocol. Common parameters include the server address, port, password, and encryption method. The client and server must use the same encryption method; a matching password alone does not confirm that the settings are correct. Check any additional parameters against the original details from your service provider.
VMess uses a user ID and other information for authentication. A UUID is a common key field, but it is not the only connection requirement. Check the transport, path, hostname, and applicable TLS settings as well. The same UUID does not make different server entries interchangeable, and an incorrect device time can also affect authentication.
VLESS identifies users with a UUID, but the protocol itself does not encrypt data. Connection protection depends on the transport and security settings in use. Check the UUID, transport type, server name, and any other fields specified by your service provider. Do not assume VMess settings apply just because both protocols use a UUID.
Check existing server parameters →Trojan typically runs over TLS. Check the password and server name carefully. The server address is used to establish the network connection, while the server name in TLS is used for the handshake and certificate validation; they may differ. If a certificate error appears, first check the name, device time, and server certificate status.
See how to check connection parameters →HTTP and SOCKS5 are common proxy protocols with different authentication methods and traffic support. The protocol name alone does not mean the connection is encrypted; check the configuration for any additional protection. When entering the details, confirm the type, address, and port, and whether the server requires a username and password.
WireGuard is a key-based tunneling protocol. Common parameters include the local private key, peer public key, endpoint address, and tunnel address. The routing scope also determines which traffic enters the tunnel, so checking the keys alone is not enough. A private key is sensitive; redact it when organizing a configuration or asking for help.
Hysteria2 is based on QUIC and relies on UDP. Performance depends on packet loss, round-trip time, bandwidth, and server configuration. It is not faster on every network. If the current network restricts UDP, check the transport path first, then review the authentication and TLS settings rather than repeatedly changing bandwidth options.
Check the match condition first, then the policy, and finally the rule order. The example domain example.com is for illustrating syntax only and does not represent an actual service configuration.
[Rule] is the section of a configuration that contains traffic-routing rules. Rules are typically evaluated from top to bottom, and the first match determines what happens next. Place more specific conditions before broader ones. When troubleshooting an unexpected match, check whether a rule above it has already matched.
See how rule routing works →DOMAIN-SUFFIX matches a domain by its suffix. For example, example.com matches that domain and its subdomains, not any domain that happens to contain the same text. In DOMAIN-SUFFIX,example.com,PROXY, the final field specifies the policy. Do not include a protocol prefix or web page path.
DOMAIN-KEYWORD matches domains that contain a specified string. For example, the keyword example can match domains with many different suffixes. This is broader than suffix matching and may include destinations you did not intend to match. If a rule behaves unexpectedly, check the actual matched domain in the connection log.
IP-CIDR is used for IPv4 address ranges, and IP-CIDR6 for IPv6 ranges. The number after the slash indicates the network prefix length. For example, 192.168.0.0/16 is a range of addresses, not a single device. These rules match destination addresses, unlike rules that match domain text.
GEOIP matches a destination IP based on its region in an address database, as in GEOIP,CN,DIRECT. Database classification is not a real-time measurement of physical location and does not indicate the user's current location. If a domain resolves to different addresses, the match may change; check the DNS results as well.
FINAL is the policy used when none of the preceding conditions match, and is usually placed at the end of the rule list. For example, FINAL,DIRECT sends the remaining traffic through DIRECT. It is not a dispensable closing note: changing its policy affects every connection not matched by an earlier rule.
PROXY routes traffic through a proxy, DIRECT connects without one, and REJECT blocks the connection. These are rule outcomes, not match conditions. Distinguish the uppercase policies from the Proxy and Direct options in Global Routing. If a request is rejected, find the matching rule before changing servers.
Subscriptions organize server details; configurations define how traffic is handled. They are not interchangeable. This section assumes you already have a subscription or server details; get the subscription link from your service provider.
Subscribe is used to manage existing subscriptions. Refreshing retrieves the server list from the subscription URL. The URL may contain credentials, so do not share it publicly. Refreshing a server list is different from updating the app, and a failed refresh does not necessarily mean existing servers have stopped working. Check retrieval and connection behavior separately.
See how to manage Subscribe →SERVER entries describe the protocol, address, port, and authentication details needed to connect to a remote service. They are also commonly referred to as servers or nodes. The display name may not be the server domain. When comparing entries, check their actual parameters rather than relying on names, region labels, or list order.
Share links encode connection parameters in a supported format. Scan QR Code reads content stored in a QR code, while clipboard import reads copied text. A QR code may contain only a regular web address, so a successful scan does not mean a server was imported. Before saving, check the type, address, and completeness of the fields.
See how to import from a QR code or clipboard →A Config file can contain rules, policies, and related settings, but it may not include a usable server and is not the same as a server subscription. After importing, confirm which configuration is enabled and whether it has replaced existing settings. Keep a copy before making changes, and check for account details, passwords, or subscription credentials before sharing the file.
Check DNS resolution, connectivity, authentication, and data transfer separately. A test result applies only to a specific target, method, and moment in time.
DNS resolves domain names to addresses. The result affects the connection destination and may also affect IP-based rule matching. A domain failing to open does not necessarily mean the server is down; DNS may have timed out, the result may be cached, or the returned address may be unreachable. First determine whether the failure occurred during resolution or later in the connection.
Latency is the time taken for a request and response using a specific test method. It is not download speed and does not directly measure available bandwidth. Results are easier to compare when the network and test method are the same and the tests are run close together. A timeout means the test did not complete; check the actual connection to identify the cause.
See latency testing and sorting →Connectivity Test checks whether a specific connection request can complete over a selected route. Results depend on the test target and current network conditions. A successful test does not mean every app or domain will work. If access still fails, check Global Routing, the matching rule, DNS, and the destination service.
TLS encrypts traffic and verifies identity. The handshake depends on the server name, certificate, and device time. The connection address may differ from the name used for certificate validation; enter the values provided by your service provider. If a certificate error appears, do not routinely bypass validation; investigate the server name or certificate instead.
Glossary entries explain fields; follow the current interface for specific steps. During troubleshooting, change one setting at a time and note how the connection behaves before and after. Redact credentials from parameters, QR codes, and logs before sharing them.