Protocols · Fields · Settings
Start by distinguishing protocols, transports, and cores, then find the relevant configuration fields. These 27 entries are grouped by configuration layer, and each term can be used as an in-page link.
To change parameters, see Configuration Reference →. Importing a server configuration for the first time? Start with the Setup Guide →.
A proxy protocol defines how data is structured and authenticated. A transport determines how the connection is carried, while a security layer handles encryption and authentication. These are distinct roles, not interchangeable labels.
Proxy protocols
VMess is a proxy protocol in the Project V ecosystem, with authentication and data encryption. Match the user ID, server address, and transport settings; entering only an address and port is not enough. A significant system clock drift can affect authentication, so check the device time if authentication fails.
Proxy protocols
VLESS is a lightweight proxy protocol that does not encrypt data on its own and is usually paired with TLS or REALITY. The client and server must use compatible user IDs, transport settings, and applicable flow-control parameters. A share link starting with vless:// identifies the protocol, but does not tell you the full transport and security setup.
Proxy protocols
Trojan typically runs over TLS and uses a password for authentication. A correct password alone does not guarantee a working connection: the server name, certificate validation, and transport must also match. For certificate errors, first check the domain, system time, and certificate chain rather than disabling certificate validation.
Transport security
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VLESS. The client typically needs to match the server's public key, server name, short ID, and other parameters. Exact fields vary by core version. Changing only the security type in the interface will not turn a standard TLS configuration into a working REALITY setup.
Transport security
TLS provides transport encryption, integrity protection, and peer authentication. The server address can be an IP, but the server name used for certificate validation must match the certificate and server requirements. “Allow insecure” usually affects certificate validation; it is not a standard way to improve connection quality or speed.
Transports
WebSocket can carry proxy traffic, but does not define how proxy users are authenticated. Check the path, Host header, port, and whether the reverse proxy forwards connections correctly. The server name, HTTP Host, and connection address may serve different purposes; do not assume they should all have the same value just because they look like domain names.
The interface manages settings; the core handles execution. To determine whether a protocol will work, check both whether the client can generate the required configuration and whether the core it calls supports it.
Project background
Project V provides context for understanding V2Ray's modular network proxy design and related ecosystem. It is not a connection mode in a client. The technology separates components such as inbounds, outbounds, routing, and transport. When reading documentation, check which core and version it covers rather than relying on the broad label “V2Ray” to determine compatibility.
Core projects
V2Fly is the community project that maintains the V2Ray core, which handles protocol connections, routing, DNS, and other tasks. v2flyNG is an Android graphical client that uses related core capabilities; they are not the same software layer. Check the core's configuration format and version when reading field documentation, and do not assume features added by another core apply.
Core projects
Xray grew out of the V2Ray technology ecosystem and went on to develop its own protocols and transport features. REALITY is one of the best-known features in its ecosystem. Xray and V2Fly share some configuration structures, but not every field or behavior is the same. When troubleshooting a missing feature, check both the graphical client version and the version of the Xray core actually running.
Application layer
Graphical clients provide interfaces for importing subscriptions, selecting servers, viewing logs, and changing settings. They usually generate a runtime configuration for the core. v2rayN on this site is for desktop platforms; v2rayNG and v2flyNG are for Android. Seeing a configuration in the interface only confirms that it was imported—it does not confirm that the core started or that the connection works.
Compare client options →How it runs
Core switching changes the network processing program called by the client; it is not just a change of interface theme. Before switching, check that the target core supports the protocols, security layer, and routing configuration in use. You will usually need to reload the configuration afterward. A core-specific feature will not automatically work in another core just because the client still shows an option with the same name.
Check core compatibility →First find where traffic enters, then see which rules send it where. Field names retain their original capitalization so you can search for them in JSON and logs.
Configuration Structure
inbounds is an array that defines how the core receives connections from apps or other devices. Common settings include the listen address, port, protocol, and traffic sniffing. SOCKS and HTTP can both be used as local inbounds. Listening on the loopback address limits access compared with listening on all interfaces; check authentication and firewall settings before exposing an inbound to your local network.
Configuration Structure
outbounds is an array that describes how traffic is handled—for example, sent through a proxy server, connected directly, or blocked. It is not simply a copy of the server list in the interface; it defines the outbounds the core can actually select. Every outbound referenced by a routing rule must exist. In common V2Ray / Xray configurations, traffic that matches no rule typically uses the first outbound.
References between configuration objects
tag names a configuration object, while outboundTag in routing references the matching tag of a destination outbound. A tag is only an identifier: an outbound named direct still needs an actual direct-connection protocol configured; the name alone does not make it direct. Match spelling and capitalization to avoid routing traffic to a nonexistent outbound.
Transport configuration
streamSettings groups transport and security settings for a connection, separately from protocol authentication parameters such as user IDs and passwords. It may contain transport type and TLS or REALITY settings; the exact structure depends on the core version. When copying a configuration, check the entire setup against the server requirements. Replacing only the transport name while keeping incompatible fields can break the connection.
Inbound processing
sniffing is usually configured on an inbound. It inspects some initial connection data for protocol or domain clues to assist routing. It does not decrypt encrypted content or guarantee that every connection's domain can be identified. Routing options and behavior such as destination overrides vary across cores. After enabling sniffing, check the logs to see what information the rules actually used.
Traffic routing depends on match conditions, rule order, and available domain information. DNS resolves names; it does not select an outbound. The two work together but are not the same setting.
Where traffic goes
Traffic routing selects an outbound for each connection based on conditions such as domain, IP, port, or inbound tag. Standard field-based rules are checked in order, so the first applicable match determines where traffic goes; put specific rules before broader ones. If a rule has multiple conditions, check how they combine instead of assuming any one of them will match on its own.
View routing configuration →IP rule data
GeoIP groups IP address ranges by category or region; routing rules can reference tags such as geoip:private. Available tags and coverage depend on the local data file, and not all data sources contain the same entries. An IP's registered location does not necessarily indicate where a website is hosted. For shared or changing IP addresses, check the domain rules as well.
Domain rule data
GeoSite is a collection of domain rules organized by category, often used in routing with tags such as geosite:cn. It matches domains; it does not look up the region associated with a destination IP. If a connection provides only an IP address, the rule may not match. Data updates can change category coverage, so check which data file the client actually loaded before changing rules.
Routing domain resolution strategy
routing.domainStrategy controls whether and when domains are resolved during routing. Common values include AsIs, IPIfNonMatch, and IPOnDemand. For example, IPIfNonMatch tries to resolve a domain for IP matching if no domain rule matches. A field with the same name in another object may affect the connection itself; do not assume it has the same meaning.
Domain mapping
FakeDNS assigns synthetic IPs to domains and stores the mapping so a proxy handling intercepted traffic can recover the original domain. These addresses are not the website's real resolved IPs; the accompanying traffic path must know how to recognize and handle them. Enabling FakeDNS without correctly intercepting the corresponding connections can break access. Check the DNS query path, routing, and cache together.
Resolution path
A DNS leak occurs when domain queries bypass the intended resolution path; it does not mean DNS resolution failed. The system resolver, browser Secure DNS, app-specific resolvers, and queries that were not intercepted can all affect the result. Troubleshooting starts with identifying the expected resolver and the actual query route. Being able to open a website does not prove DNS traffic followed the intended path.
View DNS configuration →A subscription provides configurations, a server entry represents one configuration, and proxy mode determines how apps send traffic to the core. Test results should specify the method; a single measurement is not a lasting verdict on connection quality.
Configuration sources
A subscription gives a client an update source for a set of server configurations, usually through a URL that returns data in a supported format. Subscription URLs may contain access credentials, so do not include them in public screenshots or forward them to others. Updating fetches the latest configurations, but whether it overwrites remarks, keeps manual edits, or removes obsolete entries depends on the client and group settings.
View subscription settings →Server entries
A server entry is a common term for one server connection configuration in a client. It generally includes an address, port, protocol, authentication, and transport parameters. The name in the list is usually just a label; it does not confirm the server's location, bandwidth, or operator. Entries with different names may point to the same server. To identify duplicates, compare their actual parameters.
Connection tests
Latency figures only make sense in the context of the test method. TCP connection time and the time to request a page through a proxy measure different stages. “Real connection latency” usually accesses a specified test URL through the selected proxy and may include the handshake and wait for a response; exact behavior depends on the client. A lower figure does not mean faster sustained downloads, and a timeout can result from the test URL, DNS, or certificate issues.
App connectivity
A system proxy lets a client register a local proxy address and port with the operating system. It usually affects only apps that follow those settings. This is separate from the client's “Global” or “Rule” routing modes, and setting a system proxy does not route all traffic through the core. Apps that specify their own proxy or use a separate network stack need their connection path checked separately.
Read about system proxy settings →Traffic interception
TUN mode receives IP traffic that matches system routing rules through a virtual network interface, giving apps that ignore the system proxy a way into the proxy processing path. It often involves additional permissions, route changes, and DNS interception; exact behavior depends on the client and core. TUN is not a universal switch shared by all V2Ray / Xray JSON configurations, and it does not mean every connection will use a proxy outbound.
Check TUN compatibility →