REFERENCE / TERMS & FIELDS
Browse six categories, from connection protocols to configuration fields. First distinguish the client, core, protocol and security layer, then find the relevant setting. Similar names do not mean fields are interchangeable.
01 / PROTOCOL & TRANSPORT
The protocol defines proxy requests and authentication; the transport defines how data is carried. They are separate settings.
VMess is a proxy protocol in the Project V ecosystem. It authenticates with a user identifier and other parameters, and includes its own data protection mechanism. When importing a node, check the user ID, server port and transport settings—not just the address.
Older configurations may include options tied to legacy authentication methods. Don't change parameters just to match an old example; first check compatibility with the server configuration and current core version.
VLESS is a lightweight proxy protocol that identifies users with UUIDs but does not encrypt payloads on its own. Whether a connection is protected depends on the security layer, such as TLS or REALITY, and the overall deployment.
The encryption, flow and transport security settings serve different purposes. flow requires support from both the server and the core; don't enable it as a general-purpose option.
Trojan is a proxy protocol commonly used with TLS. It primarily authenticates with a password, not the user ID used by VMess and VLESS. After importing a node, check the password, destination port, server name and transport settings.
Even when different protocols use the same address and port, their authentication formats differ. Changing the protocol dropdown to Trojan alone does not convert a connection.
Transport defines how proxy data is carried over a network connection. Common types include TCP, WebSocket and gRPC. Paths, Host values and service names are transport-specific parameters and should not be copied between types.
Names shown in the client and JSON values may vary by version. When checking a configuration, review streamSettings.network and the settings object for that transport, and confirm that both ends are compatible.
02 / CORE & CLIENT
The GUI manages settings; the core handles connections. A client being able to import a link does not mean its running core supports every field.
Xray is a proxy core maintained by the Xray project. It handles protocols, routing and domain resolution. Features such as REALITY are part of its ecosystem; availability depends on the core version and parameter combination in use.
When troubleshooting connection issues, check the client and core versions separately. After updating the GUI, verify which core is actually running in the client details or logs.
V2Fly is a community project continuing V2Ray development and maintaining v2ray-core. It is related to the Xray ecosystem, but protocol extensions, configuration formats and supported fields have evolved differently.
When migrating a configuration between cores, check support section by section. A file named config.json is not necessarily compatible as-is.
GUI clients provide interfaces for managing nodes, importing subscriptions, editing routing rules and controlling connections. v2rayN is for desktop platforms; v2rayNG and v2flyNG are for Android, with v2flyNG as an option for the V2Fly core.
Clients may generate runtime configurations from GUI settings, so manual changes to generated files can be overwritten on the next launch. Prefer the client's supported settings or custom configuration options.
TUN mode captures traffic through a virtual network interface and typically covers more apps than system proxy settings alone. Actual coverage depends on system routes, permissions and the client implementation. System proxy settings mainly affect apps that honor them, so the two modes are not equivalent.
After enabling TUN, check DNS and exclusion rules too. If the connection drops, inspect the virtual interface and route changes instead of repeatedly switching nodes.
03 / CONFIG STRUCTURE
Follow the data flow through the JSON: inbounds receive requests, routing selects where they go, outbounds make connections, and policy controls connection behavior.
inbounds is the array that defines where the core receives traffic. A typical local SOCKS inbound includes listen, port, protocol and settings.
127.0.0.1 usually allows access only from the local machine. If you change the listening scope, consider authentication, firewall rules and your actual needs. The inbound port is where apps connect to the local proxy, not the remote server port.
outbounds is the array that defines how connections are made. It can include proxy, direct and block outbounds. Each outbound's tag identifies it for routing rules.
For example, if a rule sets outboundTag to direct, an outbound with that tag must exist. The name is just a custom label; it does not create a direct connection by itself.
streamSettings configures transport and security, and commonly appears in proxy outbounds. network selects the transport type; security selects the security mechanism. Other objects hold the corresponding parameters.
Copying this object alone does not make a complete node: authentication details and the server address are usually in the protocol's settings. Check the current core documentation for field names and supported combinations.
policy configures the core's connection policies, such as handshake timeouts, idle connection time and statistics by user level. This is not a routing rule that sends certain sites through a particular outbound.
If connections drop frequently, check the timeout settings, but don't simply increase every value. Use the logs to identify whether the interruption occurs during the handshake, transport or idle phase, then adjust the relevant fields.
04 / ROUTING & DNS
Routing determines where a connection goes; DNS resolution maps a domain to an address. Check both paths when troubleshooting routing results.
Routing rules select an outbound based on domains, IP addresses, ports, inbound tags and other criteria. This is commonly called traffic routing. Rules are usually checked from top to bottom, and the first match determines where the connection goes, so put specific rules before broad ones.
Within a rule, different condition fields generally all need to match; multiple values in the same field are usually alternatives. Also verify the default behavior when no rule matches, not just the matching cases.
View routing rules →GeoIP classifies IP address ranges for routing, with entries such as geoip:private. The actual ranges depend on the data file in use; a label does not perform a live geolocation lookup.
When a destination starts as a domain name, whether an IP rule can match it also depends on the resolution strategy. Changes to the database or resolved IP can make the same rule produce different results.
GeoSite classifies domain groups for routing, with entries such as geosite:cn. The difference from GeoIP is what each matches: GeoSite matches domains, while GeoIP matches IP address ranges.
Available labels and the domains they cover depend on the data source and version. Check which data file the client loads before using a label. For a specific site, use a more precise domain rule rather than relying on a whole category.
DNS resolves domain names to addresses. routing.domainStrategy determines when routing attempts to resolve a domain during rule matching. For example, with IPIfNonMatch, IP rules are checked using the resolved address only if no domain rule matches.
This field does not mean that every app uses the core's DNS. The operating system, browser and proxy core may each perform their own lookups. Fields with similar names in outbounds should also be understood in their specific context.
View DNS configuration →FakeDNS maps synthetic addresses to domain names so the destination domain can be recovered for a later connection. These addresses are mainly for internal mapping, not the destination website's real public IP address.
FakeDNS depends on coordination between the DNS entry point, traffic interception and domain recovery; adding a configuration object alone may not be enough. After switching modes, check both the cache and actual traffic path if old DNS results are still being used.
A DNS leak occurs when queries are sent to a resolver outside the expected resolution path. It describes a routing deviation; the resolver's name or location alone doesn't establish whether a leak occurred.
Check system DNS, encrypted DNS in the browser, the client's traffic interception and the core's DNS outbound separately. Proxying a web request does not mean the preceding DNS lookup followed the same route.
05 / SUBSCRIPTION & NODE
A subscription manages a collection of parameters; a node stores a connection configuration. Successful import and successful connection are separate checks.
A subscription retrieves and updates a collection of nodes from a URL; it is not a proxy protocol. The client must support the subscription format to turn its contents into usable node entries.
An update usually fetches the remote content again, and whether manually edited node settings are retained depends on the client. Subscription URLs may contain access credentials; don't expose them in screenshots, public logs or shared text.
A node is a set of connection parameters saved in a client, typically including the server address, port, proxy protocol, authentication and transport settings. A node entry does not necessarily correspond to a separate physical server, and its display name is not used for protocol authentication.
A successful DNS lookup only confirms that the domain resolved. A connection also requires an accessible port, valid authentication, and compatible transport and security settings.
A share link encodes node parameters as importable text; a QR code is one way to carry that text and may also contain a subscription URL. Scanning a code does not use a separate connection protocol—the contents still need to be converted into a client configuration.
Clients may differ in which link extension fields they recognize. After importing, check the transport, security layer and server name. QR codes may contain authentication details, so review their contents and intended audience before sharing.
Real connection latency usually measures how long a client takes to reach a test target through a proxy. Whether the measurement includes DNS resolution, the handshake or response time depends on the client. It is not the same metric as TCP latency, which tests only whether a port connection can be established.
For a useful comparison, keep the test target and method consistent. Lower latency does not mean higher sustained download speeds, and a timeout may be caused by the target site or DNS resolution.
06 / SECURITY LAYER
Authentication identifiers, certificate validation and transport protection solve different problems. When a handshake fails, first identify which layer is involved.
TLS encrypts and authenticates transport connections. Certificate validation depends on the trust chain, validity period, system time and domain name. Being able to reach the server does not mean its certificate will pass the client's checks.
If you see a certificate error, first check the system time, server name and certificate deployment. Enabling allowInsecure relaxes certificate validation and should not be the default fix for every TLS error.
REALITY is a transport security mechanism in the Xray ecosystem, commonly combined with protocols such as VLESS. It is not a proxy protocol at the same layer as VLESS. Both cores must support it, and the authentication and handshake parameters must match.
The client typically needs a server name, a public key or related verification parameters, and a short ID; field names vary by version. Never enter the server's private key on the client, and don't treat standard TLS settings as REALITY settings.
SNI is the server name indication sent during a TLS handshake. serverName is a client configuration field related to that name and certificate validation. The connection address can be an IP address while the server name remains a domain.
These two fields do not always have to match, but both must meet the server's deployment requirements. The server name is also different from the WebSocket Host or an HTTP request header; changing one does not automatically update the others.
A UUID is a user identifier used by protocols such as VMess and VLESS. The client value must match an authorized entry on the server. A UUID identifies a user; it is not a transport encryption algorithm and cannot replace TLS or REALITY parameters.
A valid format only means the value meets the syntax requirements; it does not mean the server has authorized it. After generating a new UUID, update both sides. Mask user identifiers and other authentication details in screenshots of public nodes.