V2Ray / Configuration Glossary
Protocols, cores, routing, and security. Look up client settings, understand each concept, then adjust the parameters.
In “VLESS + TCP + REALITY,” each term describes a different layer: the proxy protocol, transport, and security. They are not interchangeable clients.
See the protocol and core reference →PROTOCOL / TRANSPORT
The protocol defines how the two ends exchange proxy requests. TCP and WebSocket are transport options at a different layer; also check the security settings and server configuration.
Protocols and Transport · Proxy Protocols
VMess is a proxy protocol in the Project V ecosystem with user authentication and traffic encryption. A user ID identifies each user. The client and server must use matching user IDs, transport settings, and related parameters; a system clock mismatch can also cause authentication to fail. Don't copy a node's port, path, or security settings just because it uses VMess.
See the protocol selection guide →Protocols and Transport · Proxy Protocols
VLESS is designed with a streamlined protocol layer and does not encrypt traffic itself. Understand the role of TLS or REALITY based on how the server is set up. User ID, flow control, transport, and security are separate fields; none can substitute for another. If you see xtls-rprx-vision, configure it as required by the server and confirm the core supports that combination.
Protocols and Transport · Proxy Protocols
Trojan typically uses TLS for a secure connection and password-based authentication. It does not use a VMess or VLESS user ID as its authentication field. After importing, check the password, server name, and transport settings; a matching port alone doesn't mean the configurations are compatible. If the connection fails, first determine whether the issue is a TLS handshake or password authentication, then check the relevant settings.
Understand TLS and certificate validation →Protocols and Transport · Proxy Protocols
Shadowsocks is often abbreviated to SS. It uses a pre-shared credential and an agreed encryption method to protect proxy traffic. The encryption method, password, and port must match the server; supported key formats and core capabilities can vary by method. After importing a share link, check that the encryption method was recognized correctly. Not all SS configurations use the same format.
See the protocol compatibility guide →CORE / CLIENT
The client provides the interface and manages configuration; the core handles connections. A setting appearing in the client doesn't guarantee that the current core supports it.
Cores and Ecosystem · Connection Handling
Xray is a proxy core project that grew out of the V2Ray ecosystem. It handles protocols, routing, and outbound connections. Support for VLESS, REALITY, and Vision configurations depends on the specific Xray version—not just the client name. Re-test the connection after switching cores, as some fields in the existing configuration may have different meanings or support.
Compare core features →Cores and Ecosystem · Core Projects
V2Fly is a community project continuing development of the V2Ray core. Some interfaces also label it v2fly or V2Ray Core. It shares history with Xray, but later features, configuration fields, and supported capabilities differ. A JSON configuration isn't necessarily interchangeable between the two cores; check protocol, security, and routing support before switching.
Compare with the Xray core →Cores and Ecosystem · Desktop Client
v2rayN is a desktop GUI client for managing server lists, subscription imports, routing, and system proxy settings. Client actions are translated into a configuration the core can run, so record both the client version and active core when troubleshooting. The interface may differ between desktop and classic WPF editions; menu locations in guides depend on the version.
See desktop downloads →Cores and Ecosystem · Android Clients
v2rayNG and v2flyNG are Android GUI clients based primarily on the Xray and v2fly cores, respectively. Both can manage server configurations, but that doesn't mean every share link, subscription format, or protocol extension works in both. On first connection, Android typically asks for VPN permission. This only allows the app to handle traffic; it doesn't confirm that the remote server is reachable.
See Android clients →CLIENT / SETTINGS
Traffic capture, connection multiplexing, and test metrics each have limits. Before changing a setting, determine whether the issue is that an app bypasses the proxy or that the remote connection fails.
Client Features · Traffic Entry
The system proxy points the operating system's proxy address to the client's local listening port. It mainly affects browsers and apps that follow that setting. v2rayN's “Set system proxy automatically” option doesn't route every app through the proxy or decide which outbound a connection ultimately uses. If you change the local port manually, update the system proxy address too; otherwise, apps may keep sending requests to the old port.
Compare TUN traffic capture →Client Features · Virtual Network Interface
TUN mode uses a virtual network interface to capture traffic, including traffic from some apps that ignore system proxy settings. The actual coverage depends on routing and exclusion rules. It may require administrator permissions; check for conflicts involving DNS, other VPN software, and virtual adapters. TUN is only a traffic entry point: it won't fix incorrect node settings or guarantee that all traffic exits through the remote server.
See connection and verification steps →Client Features · Connection Multiplexing
Mux combines multiple logical connections over fewer underlying connections to reduce connection setup overhead in some cases. Its effectiveness depends on the core, protocol, flow control, and workload; it isn't a universal speed boost. Check compatibility first, especially with combinations such as Vision. If problems arise, restore the original setting and compare before changing anything else.
See protocol and feature compatibility →Client Features · Connection Testing
Real connection latency usually measures how long a client takes to complete a specified stage of an actual request to a test address through the proxy. It more closely reflects real use than simply probing a server port, but results still depend on the test address, DNS, handshake, and current network. A lower value doesn't mean large downloads will be faster. If a test fails, check the logs before concluding that the server is offline.
Compare latency test methods →ROUTING / DNS
Routing determines which outbound handles traffic; DNS resolves domain names. Whether the domain is preserved and routing data is available can change the final match.
Routing and DNS · Outbound Selection
Traffic splitting routes requests to a direct, proxy, or blocking outbound based on the domain, destination IP, port, or other criteria. Rules are usually evaluated in order, so an overly broad rule near the top can prevent more specific rules from taking effect. Presets such as “Bypass mainland China” are strategy names; when troubleshooting, also check the default outbound for unmatched traffic and whether DNS provides the information required for matching.
See the routing strategy guide →Routing and DNS · IP Sets
In proxy configurations, GeoIP usually refers to a set of IP addresses that routing rules can use to choose an outbound based on address category. Results depend on the data file, update date, and tag definitions; they don't pinpoint a device's physical location. Dynamic addresses and shared infrastructure can make IP classification insufficient, so check domain rules and actual connection records too.
Compare with the GeoSite domain list →Routing and DNS · Domain Sets
GeoSite is a collection of domains that routing rules can reference, organized by service, use, region, or other categories depending on the data source. Before using it, make sure the client has a compatible data file and the active core can access the domain being matched. If an app connects directly to an IP, domain information is missing, or the data doesn't cover a new domain, a rule may not match even when the proxy connection itself is working.
Understand rule matching order →Routing and DNS · Virtual Address Mapping
FakeDNS returns a virtual IP to an app, then the core uses a mapping to recover the domain and handle subsequent traffic. It's commonly used with TUN configurations. It is not a public DNS server address and doesn't automatically replace all DNS policies. After closing the client, virtual address caches left in the app or system may affect access. Check the relevant caches and traffic capture settings when disabling FakeDNS.
Distinguish DNS routing issues →SUBSCRIPTION / SERVER
A subscription distributes configurations; a node is one connection profile. A successful import only means the content was parsed—it doesn't confirm valid credentials or an established connection.
Subscriptions and Nodes · Configuration Distribution
A subscription is usually a URL that provides a set of server configurations. When a client refreshes it, the client parses the content and updates the relevant group. Subscription content can change or remove existing entries; whether manual edits are preserved depends on the client. A URL may contain access credentials, so treat it like a password. Don't share the full subscription URL when asking for help.
See how to import a subscription →Subscriptions and Nodes · Server Entry
A node is a selectable server connection profile in a client, usually containing an address, port, protocol, authentication details, transport, and security settings. The displayed name is only a label and may not reflect the server's physical location or exit location. Switching nodes changes the remote configuration; it doesn't automatically enable the system proxy. Selecting a node, starting the core, and accessing a website are three separate states.
Check how app traffic enters the proxy →Subscriptions and Nodes · Parameter Format
A share link carries connection parameters in a specific URI format, commonly with prefixes such as vmess://, vless://, or ss://. Clients may differ in how they recognize optional fields; after importing, check that the transport, security, and server name are present. A link may contain a password or user ID, so remove credentials before sharing screenshots, logs, or questions.
Subscriptions and Nodes · Test Metrics
Latency is the time taken by a particular test. ICMP round-trip time, TCP connection setup, and a proxy request measure different things. To compare nodes, use the same test method and target at similar times; otherwise, the results aren't comparable. A server that doesn't respond to one type of probe may still handle normal traffic. Low latency doesn't necessarily mean higher bandwidth or more stable long-lived connections.
See the definition of real connection latency →ENCRYPTION / SECURITY
Check the security layer, server name, and DNS path separately. An enabled setting alone doesn't prove the whole connection behaves as expected.
Encryption and Security · Connection Protection
TLS is a transport-layer security protocol for connection encryption and authentication, and can be combined with different proxy protocols and transports. Check that the certificate is valid, the server name matches, and the system clock is accurate. “Allow insecure” weakens authentication. For handshake errors, check the certificate and name settings first rather than leaving verification disabled.
See Server Name Indication (SNI) →Encryption and Security · Xray Security
REALITY is a transport-layer security solution in the Xray ecosystem, often used with VLESS. It is not a substitute protocol at the same layer as VLESS. Match the server's settings for SNI, PublicKey, ShortId, and any required Fingerprint, which describes the client's handshake characteristics. Having all fields filled in doesn't make their values correct; example public keys or arbitrary server names won't work for a real connection.
Compare with the VLESS protocol layer →Encryption and Security · Handshake Name
SNI is an extension in the TLS handshake that indicates the target server name. A client may label it “Server Name” or serverName. It is a separate field from the connection address: the address locates the server, while the name is used in the relevant handshake and authentication process. A mismatch isn't necessarily an error, but don't change either value arbitrarily. Follow the server's requirements and check how the certificate or REALITY parameters correspond.
Encryption and Security · DNS Resolution Path
A DNS leak usually means domain lookups take a different path than intended—for example, queries go through the system's default resolver instead of the specified outbound. Check browser secure DNS, system DNS, client DNS, and routing settings together; the website's exit IP alone isn't enough. A query routed directly by policy isn't necessarily a leak. What matters is whether the actual resolution path matches the intended policy.
See DNS troubleshooting →