Setting names · key distinctions · where to use them

V2Ray Quick Reference

Start with the fields in your client to distinguish proxy protocols, transport security, cores, and routing. Each term has its own anchor for quick reference while reviewing settings and logs.

6 setting categories 26 common terms Configuration guide →

Protocol type in a connection configuration

Transport protocols

These names usually appear under “Add server” or in a “Protocol” field. After selecting a protocol, check the transport and security layer as well.

VMess
A proxy protocol in the Project V ecosystem that uses a user ID for authentication and is common in existing subscription configurations. VMess authentication and transports such as TCP and WebSocket are separate settings. Entering a user ID does not mean the other parameters are complete. After importing, check the transport and security layer required by the server, along with the device time. Support for legacy configuration fields depends on the current core.
VLESS
A streamlined proxy protocol that authenticates with a user ID but does not encrypt payloads on its own. Connections typically use TLS or REALITY, so selecting VLESS alone does not configure the security layer. If a subscription includes extension fields such as flow, keep the server-provided values and confirm that the current core supports that combination. Do not infer compatibility from the name alone.
Trojan
A proxy protocol that typically runs over TLS and uses a password for authentication. Along with the address, port, and password, check the server name and certificate verification settings. For handshake errors, first check the name, certificate trust, and device time rather than disabling certificate verification. Authentication and establishing a secure connection are related but separate steps.
Shadowsocks SS
A family of proxy protocols that use an encryption method and password as key connection parameters. Share links commonly use the ss:// prefix. Encryption methods and protocol generations differ in compatibility, so the current core must support the method specified by the server. Check the method name as well as the password; some methods also require a specific key format.

The interface and the component that handles connections

Cores and ecosystem

The graphical client manages configurations; the core handles connections. A client name, core family, and protocol name are not interchangeable.

Project V
The broader ecosystem of networking tools associated with V2Ray, including proxying, routing, and extensible configuration. It is not a connection protocol you can select directly in a client, nor does it mean every related tool has the same features. When reading documentation, identify the client, the core it uses, and the protocol it connects with—in that order. This helps avoid treating an ecosystem name as a list of specific capabilities.
V2Fly
A community project continuing V2Ray development. Its core is commonly called v2fly-core, and v2flyNG is one related Android client. V2Fly and Xray share roots, but their features and configuration fields have diverged. When migrating a configuration, consult the documentation for the relevant core. Both reading JSON does not guarantee that their protocol extensions or routing behavior match.
Xray
A proxy core developed from a fork of the V2Ray project, commonly known as Xray-core. v2rayNG uses this core family. It handles protocol connections, routing, and related DNS processing, while the graphical interface generates and manages the configuration. Support for a particular REALITY, transport, or flow option depends on the actual core version, not just the client version name.
Switch core
Change the core that handles connections, if the client provides this option; not every client has the same core switch. The same connection configuration may fail to start after a switch if protocol extensions or fields are interpreted differently. Review the logs and generated configuration, and make sure the routing database works with the new core. Switching cores is not a universal fix for connection problems.

Handshake, authentication, and security settings

Transport security

A valid protocol type does not guarantee valid handshake settings. Enter the server name, public-key-related parameters, and fingerprint as provided by the server.

TLS
A security protocol that provides transport encryption and authentication and can be combined with various proxy protocols. Standard certificate verification checks the trust chain, name match, and validity period, so an incorrect device clock can also cause a connection to fail. For errors, first check the server name and certificate settings; do not use “allow insecure” as a routine fix.
REALITY
A transport security method in the Xray ecosystem, often used with VLESS. Calling it the “REALITY protocol” does not mean it replaces VLESS at the same layer. Configuration typically includes the server name, server public-key-related fields, short ID, and fingerprint; field names may vary by interface version. Preserve all server-provided parameters and do not assume the same conventions as ordinary TLS.
SNI Server Name Indication
An extension in the TLS handshake that indicates the target server name. A client may label the field “Server name” or serverName. It does not have to match the actual connection IP address, but it must meet the server's requirements and verification rules. Entering an arbitrary website domain will not make an otherwise mismatched configuration connect.
Client fingerprint
The set of characteristics used during a TLS handshake. Some cores offer presets named after browsers. Selecting a fingerprint does not switch browsers or directly change the browser identity seen by websites. Whether the option takes effect depends on the core, connection type, and configuration location. When troubleshooting, keep the subscription's original value where possible and avoid changing multiple handshake parameters at once.

Configuration sources, saved profiles, and test results

Subscriptions and nodes

Importing, updating, selecting, and testing are four different actions. Seeing entries in the list only confirms that the client parsed the configuration.

Subscription
A way to fetch multiple connection configurations from a single URL, with the client usually storing them in a designated group. Updating a subscription fetches the configurations again; it does not renew an account or necessarily switch the current connection. Subscription URLs may contain access credentials and should be treated as sensitive information. Remove the full URL and any authentication details before sharing screenshots, logs, or support requests.
Node
A selectable connection configuration in a client list, usually containing an address, port, protocol, authentication, and transport parameters. The display name is just a label, not reliable evidence of location, performance, or availability. Two entries with different names may point to the same service. Compare their actual connection fields to check for duplicates, not just their labels.
Real connection latency
The response time when requesting a test address through the proxy. It may include several steps, such as the proxy handshake, DNS, TLS, and the target site's response. This differs from a TCP test that only checks an address and port, and cannot be directly converted into download speed. For a fair comparison, use the same test address and method in the same network conditions. A failed test may be caused by the test target, not a completely unusable configuration.

Traffic routing and DNS resolution paths

Routing

Traffic routing depends on rules, databases, and DNS results working together. Seeing a rule in the list does not confirm that a connection matched it.

Routing rules and traffic routing
A mechanism for directing connections to a direct, proxy, or block route based on criteria such as domain, IP, port, or inbound connection. In common Xray routing configurations, rules are checked in order and the first matching rule determines the route, so broad conditions can override later exceptions. After making changes, use logs to verify the actual outbound route and check what happens when no rule matches.
GeoIP
A collection of IP addresses grouped by category for routing, often loaded from a database such as geoip.dat. Region or usage labels in a database are not live geolocation and do not directly identify the service associated with a domain. If a rule resolves a domain to an IP before matching, check the domain resolution strategy as well; updating the database alone may not change how a current connection is routed.
GeoSite
A collection of domains grouped by category for routing, commonly stored in a file named geosite.dat. For example, geosite:cn references a category, but the available tags and their contents depend on the database in use. Do not assume that databases from different sources contain the same entries. A missing tag can cause a configuration error, and a valid category does not guarantee that a newly added domain is included.
FakeDNS
A mechanism that maps domains to a reserved address pool and restores domain information for later connections. This can preserve domain-based routing after IP traffic is intercepted. The mapped address is not the target site's real public IP and should not be used to determine its location. DNS, traffic interception, and related routing settings must work together; enabling one option alone may prevent the original domain from being recovered correctly.
DNS leak
A DNS query that does not follow the intended resolution path—for example, when a connection uses a proxy but the domain lookup still goes to another system resolver. Check system DNS, browser secure DNS, in-app resolution, and the client's DNS routing together. A changed egress IP does not prove that the DNS path changed. Interpret resolver names shown by DNS test sites in light of your actual configuration.
Sniffing Sniffing
Extracting information such as a domain from visible protocol data early in a connection to help with routing or target identification. Sniffing cannot decrypt arbitrary traffic; the information available depends on the connection protocol, encryption method, and core implementation. Also distinguish between settings used only for routing and those that override the connection target. The latter can change where traffic goes, so more features are not always better for every use case.

How app traffic reaches the client

Client features

A system proxy, virtual interface, and local inbound solve different problems. After configuring one, test it with the target app rather than relying on the connection toggle alone.

System proxy
Registers a proxy address with the operating system so apps that follow its settings can connect to a local proxy endpoint. Enabling it does not route traffic from every app through the client; some programs use their own network settings or connect directly. If a browser works but another program does not, first check whether that program uses the system proxy. Then consider an in-app proxy or another traffic interception method.
TUN mode
A way to route IP traffic through a virtual network interface and related system routes. It can cover apps that do not use the system proxy. It is a separate setting, and its implementation and permission requirements vary by platform and client. After enabling it, check for conflicts involving DNS, local network access, and existing virtual interfaces. An Android client's VPN permission screen may not use the term “TUN.”
SOCKS inbound
A local proxy endpoint for apps to connect to the client, commonly using a SOCKS5 address and port. Some configurations use local port 10808, but check the actual value in the client settings. Do not enter the local inbound port as the remote server port. UDP support also depends on the app, core, and server-side connection. Listening on the local machine is usually sufficient; assess access controls before enabling LAN access.
HTTP proxy inbound
A local endpoint that lets apps send requests to the client using the HTTP proxy protocol. Where supported, the CONNECT method can establish an HTTPS tunnel. Some configurations use local port 10809, but other versions may have a separate port or a mixed inbound; check the current settings. HTTP proxy and SOCKS work differently, so the proxy type selected in the app must match the protocol offered on the port.

Explore related guides

Once you understand the fields, return to the steps for your specific task. Change one setting at a time where possible, and keep a copy of the original configuration so you can compare results and restore it if needed.