Configuration concepts · Browse by topic
Protocols define how communication works, cores execute configurations, and clients provide the interface. Start by separating these three layers, then explore subscriptions, routing, DNS, and proxy modes to understand how their settings fit together.
This page explains terminology and its limitations; menu names may vary by client version. Start with the getting started guide, or see the complete manual for a more in-depth walkthrough.
This section covers both proxy protocols and transport security mechanisms. They can be used together, but they are not interchangeable options at the same layer.
VMess is a proxy protocol in the Project V ecosystem, with authentication and traffic encryption. Its configuration typically includes a user ID, server address, and port. It can also use different transport methods, so the protocol name alone does not tell you whether a configuration is complete. Some authentication flows depend on the time, so if the device clock is significantly off, correct it before troubleshooting the connection.
VLESS is a lightweight proxy protocol that does not encrypt traffic by itself; transport security is typically provided by TLS, REALITY, or a similar mechanism. When importing a configuration, make sure the user ID, transport, security options, and any flow-control settings match the server. VLESS and VMess do not use identical field meanings, so switching the protocol in a dropdown is not enough to convert a configuration.
Trojan typically carries proxy traffic over a TLS connection and uses a password for proxy-layer authentication. The server address, authentication password, and TLS server name serve different purposes: locating the server, authenticating access, and verifying the server's identity. Check authentication errors and TLS errors separately if a connection fails; repeatedly changing the local listening port is unlikely to help.
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol. It is commonly used with VLESS. Enter the server name, public-key parameters, short ID, and other values exactly as provided by the server; do not make them up. The client and its core must also support the relevant settings. If a configuration imports successfully but will not connect, check core compatibility next.
TLS protects data in transit and verifies the identity of the other party using certificates and related mechanisms. This is separate from user authentication in a proxy protocol. The connection address can be an IP, but the server name used for validation must still match the certificate. To troubleshoot certificate errors, check the device clock, server name, and certificate configuration; disabling validation should not be treated as a routine fix.
The same graphical interface may use different cores. To determine whether a protocol is supported, check the client, the core it actually uses, and the core version.
Project V provides useful context for understanding V2Ray and related tools. Its core design uses composable inbounds, outbounds, and routing. It is not a desktop installer or a subscription service. Projects in the ecosystem develop independently, so not every client offers the same protocols and settings.
V2Fly is a community project continuing V2Ray development and maintaining its core and documentation; the name may also appear as v2fly in interfaces. The Android client v2flyNG uses this core ecosystem and may suit configurations that depend on it. Cores do not support identical extensions, so when migrating from another client, check protocol and transport support setting by setting.
Xray is a proxy core project that grew out of V2Ray and has evolved independently. Settings such as REALITY require a compatible core. v2rayNG uses the Xray core; for desktop clients, check which core is actually selected and running. If a field is unrecognized or a protocol is unsupported, verify the active core as well as the client name.
v2rayN, v2rayNG, and v2flyNG are graphical clients for importing configurations, organizing subscriptions, and presenting settings. The core handles actual connections and applies rules. An option that the interface can save is not necessarily supported by the active core. When updating, migrating, or troubleshooting, note both the client and core details, and distinguish interface errors from core startup or network connection errors.
Subscriptions distribute configurations; nodes are selectable connection configurations. Organizing groups, updating subscription content, and testing connectivity are separate tasks.
A subscription uses a URL to fetch and update a set of connection configurations. The format returned by that URL must be compatible with the client. Updating a subscription refreshes its configuration; it does not establish a proxy connection or guarantee that every configuration works. Subscription URLs may contain access credentials, so do not share them in public screenshots, logs, or chats. When switching clients, preserve your existing group settings as well.
A node usually refers to a remote connection configuration in a client, with details such as an address, port, protocol, authentication, and transport settings. Its display name is only a label; it does not verify the physical location, connection quality, or current availability. After selecting a node, app traffic still has to enter the proxy processing chain through the system proxy, TUN, or the client's corresponding mode.
Subscription groups organize configurations by source or purpose, making them easier to update, filter, and maintain separately. They are typically a client-side management feature, not automatic load balancing or failover. Before editing entries generated by a subscription, check whether the next update will overwrite your changes. Save important custom configurations separately.
Real connection latency generally means the time taken to reach a test target through the selected proxy configuration, though the exact timing depends on the client. The target, connection reuse, and timeout settings all affect the result. It is neither a pure network round-trip time to the server nor a measure of sustained download speed. If a test fails, consider whether the target is reachable and check the logs; one result alone does not prove the configuration is broken.
DNS resolution determines how an address is found; routing determines which outbound a connection uses. They affect each other, but one switch cannot replace the complete set of policies.
Routing rules direct connections to specified outbounds—such as direct, proxy, or block—based on domains, IPs, ports, or other supported criteria. Rules are usually evaluated in order, so an overly broad rule near the top can prevent more specific rules from taking effect. When making changes, check both the matching criteria and what happens to unmatched connections, then test with a specific browsing scenario.
Traffic routing uses rules to send different connections to different outbounds; it is not a standalone protocol. Options labeled bypass mainland China or global in a client usually refer to preset rules or handling modes, but the exact scope depends on the current configuration. If an app does not connect as expected, first check whether its traffic reaches the client, then review the matching rule and DNS results.
In routing configurations, GeoIP usually refers to a list of IP addresses grouped by region or purpose, reducing the need to enter address ranges individually. Classification depends on the data source and update schedule; it is not a real-time measurement of server location. If a rule behaves unexpectedly, check the actual destination IP, data file, and classification scope rather than relying on the website name alone.
GeoSite groups domains associated with websites, services, or purposes so rules can match them by category. It matches domain criteria, unlike GeoIP, which categorizes IP addresses, and it does not replace DNS resolution. A service may use multiple domains and third-party resources, so if parts of it fail to load, check whether the rules cover all the domains actually requested.
DNS resolves domain names to IP addresses and other records, making it a fundamental part of connecting to a domain. The operating system, browser, and proxy core may each perform lookups, so changing a DNS address in one place may not affect every app. When configuring DNS, identify which component performs the lookup, which path the query takes, and how the result is used for routing before deciding whether to change the resolver.
FakeDNS returns virtual addresses from a reserved range and maps them to the original domain. The core then recovers the domain from that mapping when handling subsequent connections. This does not mean the destination is actually at the virtual address, nor does it force every DNS result to the same address. The mechanism depends on DNS resolution and traffic capture working together. After enabling or disabling it, check whether apps still have old mappings cached.
A DNS leak occurs when queries use a resolver or network path other than the one intended. Before judging a test, define your DNS policy. A test page showing a resolver name alone does not prove the DNS path used by every app or indicate that the proxy connection has failed. Check app-level encrypted DNS, system settings, and client rules to identify where each query actually comes from.
A routing domain strategy determines whether and when domain names are resolved to IP addresses for IP-rule matching. For example, IPIfNonMatch typically means that if no domain rule matches, the domain is resolved and then checked against IP rules. This is not a DNS server address, nor does it mean all requests must use a particular address family. Similar names in different settings may have different meanings, so check each setting in context.
First determine which app traffic is captured, then decide how the core handles it. Traffic capture scope and outbound selection are separate things.
The system proxy registers a local proxy address with the operating system so apps that honor the setting send their requests to the client. It does not capture every app or guarantee that all UDP traffic uses the proxy. If websites stop working after you close the client, check whether the system still points to a local listening port before changing the remote configuration.
TUN receives matching IP traffic through a virtual network interface and passes it to the core for routing and connection handling. It typically covers more apps than the system proxy. It expands the scope of traffic capture; it does not automatically send every connection through a proxy outbound or replace DNS settings. Enabling it may require permissions, and you should watch for routing conflicts with other virtual networking tools.
Sniffing identifies protocol or domain clues in the initial data of some connections, providing more information for routing rules. It cannot decrypt arbitrary encrypted traffic or recover a domain from every connection; what it can identify depends on the protocol and settings. Whether it replaces the destination address depends on the specific options, so enable it as needed rather than treating it as a universal fix.
Per-app proxy lets you include or exclude apps from traffic capture and is typically used with VPN mode in Android clients. The list may mean proxy only the selected apps or bypass them, so first check what the current mode means. Traffic from included apps still goes through routing rules, so selecting an app does not necessarily send all of its requests through a proxy outbound.