Configuration reference / 25 terms
Start by distinguishing protocols, cores, and clients, then check subscriptions, routing, and traffic interception. Find terms by what each setting does instead of treating similar names as interchangeable.
Connection conventions and security layers
A protocol name is not a complete configuration. Match the transport, authentication fields, and security layer individually.
A proxy protocol in the Project V ecosystem that handles user authentication and data encapsulation; the user ID is usually a UUID. The client and server must also use matching transport and security settings. A matching UUID alone is not enough to establish a connection. When troubleshooting authentication errors, check the device clock too, so a time difference isn't mistaken for an expired subscription.
A lightweight proxy protocol that does not provide a general-purpose data encryption layer; deployments typically pair it with TLS or REALITY. The UUID, transport, and any flow field must match the server configuration. When you see VLESS, check that the core supports the extensions used by the configuration—compatibility cannot be determined from the protocol name alone.
A protocol that typically carries proxy requests over a TLS connection and uses a password for authentication. In addition to the address and port, check the server name, certificate, and transport parameters; a correct password does not guarantee a successful TLS handshake. If you encounter a certificate error, first check the device clock and name matching rather than disabling certificate verification.
A family of proxy protocols that use symmetric encryption. A connection configuration includes the server address, port, password, and encryption method. The method is part of protocol compatibility and cannot be changed arbitrarily in the client. Implementations may support different methods and extensions, so after importing a configuration, confirm that the core can actually run it.
A transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VMess or VLESS. The client usually needs the server-specified public key, server name, and shortId; check the current version's interface for the exact fields. Preserve how these fields correspond when copying a configuration—don't migrate only the address, port, and UUID.
Interface, execution layer, and project background
An option appearing in the interface does not necessarily mean the running core supports every parameter.
The ecosystem surrounding modular network proxy tools, with V2Ray as a common technical name. Tutorials and shared configurations may target different core branches, so configuration syntax is not always interchangeable. When consulting older documentation, check its publication date, target core, and the version of the client in use.
A community project that continues development of the V2Ray core and handles tasks such as protocol processing, routing, and DNS. v2flyNG is an Android client that uses this core family and is best used with its corresponding configuration system. V2Fly and Xray share technical roots, but their later extensions are not identical; check feature support before migrating.
The proxy core responsible for connections, protocol processing, DNS, and routing. v2rayNG uses the Xray core, and v2rayN also supports configuring cores; available features depend on the specific version integrated or invoked by the client. After updating the graphical interface, check the runtime log to confirm the core was also updated and started successfully.
Software with an interface for managing subscriptions, editing configurations, controlling the core, and viewing logs. It typically translates interface settings into core configuration. v2rayN, v2rayNG, and v2flyNG are client names, not proxy protocols. The interface can open even if the core fails to start, so check the client status and core logs separately when troubleshooting.
Inbound receives traffic from apps, while outbound determines how that traffic connects next—for example, directly or through a remote proxy. A routing rule can use outboundTag to point to a defined outbound. In examples, direct is a label convention, not a fixed outbound that exists automatically in every configuration.
Configuration sources and test results
A successful import only means the configuration was read; confirm connectivity with an actual request.
A mechanism for retrieving and updating a set of connection configurations from a URL; the subscription URL itself is not a proxy server address. The example https://example.com/sub?token=xxxx is for demonstration only and cannot be used to connect. Parameters in a real URL may grant access to configurations, so hide the full URL and any credentials before sharing logs or screenshots.
A selectable remote connection configuration in a client, usually including an address, port, protocol, authentication, and transport parameters. Any region or purpose in its name is a label supplied by the configuration provider, not something verified by the client. Switching nodes selects a connection configuration; it does not change the system proxy or automatically fix local routing problems.
A management unit for organizing nodes by configuration source, making them easier to update, filter, and remove separately. In v2rayN, check the source URL and update scope under “Subscription Groups.” Groups help manage configurations; they are not traffic-routing rules. The outbound used for a website depends on the active routing rules and the currently selected connection.
The time taken by a particular test, which must be interpreted in light of the test method. TCP connection time reflects only part of the connection process to a target port; it does not show that authentication succeeded, a webpage is accessible, or downloads will be fast. Keep the test address and network conditions consistent when comparing results. A low reading once does not mean the connection will remain stable.
The time taken for an actual request to a test address through the selected proxy configuration, covering more of the connection process than a simple port check. Results still depend on DNS, the test site, authentication, and server status; they cannot be converted directly into bandwidth. If a test fails, first confirm the test address is reachable, then use the logs to identify where the failure occurred.
Match conditions and request destinations
First make sure app traffic reaches the client; then decide which outbound a rule should select.
A configuration that selects an outbound based on conditions such as domain, IP, port, or inbound tag. Rules are usually evaluated from top to bottom, and the first matching active rule determines where a request goes. Broad rules can therefore override more specific ones below them. Check domain, ip, and outboundTag together, as well as the core's domain-resolution strategy.
A policy that sends different requests through outbounds such as direct, proxy, or block according to rules—for example, sending local network addresses directly and specified domains through a proxy. Routing only handles traffic that has entered the core; it does not automatically connect every app. “Global” in a client usually means using one outbound for all intercepted requests, not intercepting every connection on the operating system.
A collection of IP addresses grouped by region or purpose, commonly provided by geoip.dat. geoip:private is a common reference for private address ranges and similar categories. It matches IP addresses, not website names. Database entries may lag behind actual address usage; if traffic is routed incorrectly, first check the destination IP and the data file's source.
A collection of domains grouped by category, commonly provided by geosite.dat; geosite:cn is a common reference. Available categories depend on the data file loaded—files do not all contain the same categories. If you see an error such as “category not found,” check the file version, reference syntax, and the actual path read by the core.
Returns synthetic IP addresses to apps while maintaining an internal mapping between each IP and its original domain, allowing the domain to be recovered for later connections. It must work with DNS interception, the virtual address range, and routing settings; simply enabling a switch does not ensure every resolution path is correct. If an app still has synthetic addresses cached after you disable it, you may need to clear its cache or restart it.
Local traffic interception and resolution paths
Proxy entry points, DNS resolution, and routing are separate stages. Change one setting at a time when troubleshooting.
A proxy setting provided by the operating system for apps to read; only apps that honor it use the corresponding proxy entry. In v2rayN, “Set system proxy automatically” configures the entry, “Clear system proxy” removes it, and “Do not change system proxy” leaves it as is. Some terminals and apps require separate configuration, and enabling the system proxy does not intercept all traffic.
A method that receives IP packets through a virtual network interface and passes them to the proxy for processing. It can cover some apps that do not use the system proxy. TUN usually requires additional permissions and may conflict with other virtual adapters, DNS interception, or routing settings. Before enabling it, confirm that the regular proxy entry works. If the network stops working, disable TUN first, then check permissions, network adapters, and runtime logs.
When DNS queries take a different resolution path than intended—for example, when queries expected to go through a specific resolver are still sent to the system's default resolver. Encrypted DNS in the browser, app-specific resolution, and client DNS settings can all affect the result. A changed public IP does not prove DNS is using the right path; check resolution settings and actual query destinations for each app.
The port where the client accepts proxy requests on the local device, such as 10808 in the interface; use the value shown in your current settings. The HTTP or SOCKS proxy type configured in the app must also match the listening protocol—don't copy the port number alone. If the connection is refused, confirm the core is running, the port is not already in use, and the app is connecting to the correct local address.
A mechanism that extracts domain or protocol clues from a connection's initial data to help with domain-based routing. It does not decrypt HTTPS content or guarantee that a domain can be identified in every connection. Whether sniffed results affect routing alone or the destination address too depends on the settings. Before changing them, determine whether the issue is domain detection or the resolution path.
Glossary definitions clarify what each setting does. For hands-on steps, follow a guide to establish a working connection first, then adjust DNS, TUN, and custom routing.