CONCEPT REFERENCE / 25 TERMS
Look up terms by configuration layer: protocols define how communication works, the core handles connections, the client manages settings, routing selects an outbound, and DNS resolves names. Identify the layer before changing settings.
Follow the user guide in order →PROTOCOL / TRANSPORT
A protocol name does not tell you the connection speed or imply a specific transport. After importing a configuration, confirm that both the client and selected core support the combination.
Protocols and transports
Proxy protocol · User ID authentication
VMess is a proxy protocol in the Project V ecosystem. It identifies users with a user ID and includes its own protocol security mechanisms. A significant device clock offset can affect authentication, so check system time synchronization when troubleshooting connections. VMess and the transport method are separate layers; matching user IDs alone do not make two configurations equivalent.
Protocols and transports
Lightweight proxy protocol
VLESS identifies users with a user ID but does not provide full transport encryption on its own. Its security depends on accompanying layers such as TLS or REALITY and their configuration. The flow setting must also be supported by the server and core. Check the full set of parameters when choosing VLESS; the protocol name alone does not guarantee a successful connection.
Protocols and transports
Proxy protocol · Password authentication
Trojan typically runs over TLS and uses a password for authentication. Check the server address, port, password, and server name separately; the connection address and the domain in the certificate may serve different purposes. If certificate validation fails, check the name, certificate chain, and device time rather than routinely disabling validation.
Protocols and transports
Transport security mechanism
REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol on the same level as VLESS. It is often used with VLESS. The client must support it and match parameters supplied by the server, such as the public key, server name, and short ID. Field names vary between clients; do not copy these settings directly into a standard TLS configuration.
Protocols and transports
Transport · TCP / WebSocket / gRPC
The transport method describes how a proxy protocol carries data. Common options include TCP, WebSocket, and gRPC. WebSocket paths and request hosts, as well as gRPC service names, must match the server. Changing the transport usually requires corresponding server-side changes; switching a client dropdown alone is not enough.
CORE / ECOSYSTEM
Websites, clients, and cores are separate entities. When checking a feature, identify the client, the core it actually runs, and the core version.
Cores and ecosystem
Modular network proxy ecosystem
Project V is the project and ecosystem built around modular network proxy capabilities, with V2Ray as an important entry point to the technology. It is not the name of a graphical client or a unified subscription service. When searching for the V2Ray website or a client download, distinguish the core project, graphical client projects, and documentation sites.
Cores and ecosystem
V2Ray community core project
V2Fly is a community project continuing development of the V2Ray core, with inbound, outbound, routing, and DNS capabilities. v2flyNG is one Android graphical client built around this core ecosystem. Check the actual core version to confirm supported protocols, configuration formats, and features; a field appearing in the interface is not proof that it works.
Cores and ecosystem
Independently developed proxy core
Xray originated in the V2Ray technology ecosystem and developed independent features based on shared concepts, including REALITY. Some protocols and fields overlap with V2Fly, but that does not make configurations fully compatible. After switching cores, check the logs and generated configuration, especially whether core-specific fields are still valid.
Cores and ecosystem
Core · Component that handles connections
The proxy core handles connections, protocols, routing, and name resolution; the graphical client manages configurations and starts or stops the core. Updating the client interface does not necessarily update the core, and a setting the interface can save may not be supported by the running core. When troubleshooting, check interface errors separately from core runtime errors.
Cores and ecosystem
v2rayN / v2rayNG / v2flyNG
Graphical clients use windows, menus, and toggles to manage subscriptions, server configurations, and proxy access. v2rayN is for desktop systems, while v2rayNG and v2flyNG are for Android; features also depend on the core and app versions. A client is not a protocol, and one client can manage configurations for multiple protocols.
Choose a client for your platform →CLIENT / SUBSCRIPTION
Confirm where a configuration came from before importing or updating it. Seeing a server entry in a list only means the configuration was recognized—not that the connection has been tested.
Clients and subscriptions
Subscription · Configuration distribution
A subscription uses a URL to fetch and update a set of server configurations. The client must support the format of the returned data. Subscription URLs may contain access credentials, so hide the full URL in screenshots, logs, and support requests. Converting a subscription only changes how the configuration is represented; it does not create servers or add protocol support to the core.
Clients and subscriptions
Node · Single server configuration
A node is a common client-side term for a single server connection configuration, usually including an address, port, protocol, authentication, and transport settings. Its display name may not accurately indicate the server's physical location or connection quality. Two differently named configurations may use the same address; compare their actual parameters to find the difference.
Clients and subscriptions
Subscription group · Organize by source
Subscription groups organize configurations by source, making them easier to update, find, and remove individually. They are usually just a client-side management feature: they do not determine traffic routing or correspond to outbound tags used by routing rules. Before editing subscription-generated entries, check whether an update will overwrite your changes; save a separate configuration if needed.
Clients and subscriptions
System proxy · App access method
The system proxy uses operating system settings to direct apps that honor them to the client's local listening port. Some apps use their own network settings, so enabling the system proxy does not route all traffic through the client. The core still selects an outbound for traffic that does connect; the system proxy toggle is not the same as global or bypass routing modes.
Read about proxy modes →Clients and subscriptions
Connection test · Measured through the proxy
Real connection latency usually means the time measured when a client reaches a test target through the proxy; whether the measurement includes the handshake depends on the implementation. It differs from a TCP test that only checks whether a port is reachable, and it cannot be converted directly into download speed. For a fair comparison, keep the test target, network, and method consistent. One failed test does not prove the configuration is broken.
ROUTING / OUTBOUND
Traffic enters the core first, then matching conditions select an outbound. When troubleshooting routing, check rule order, available domain information, and dataset contents together.
Routing and traffic rules
Routing rule · Match conditions
Routing rules select an outbound based on conditions such as domain, IP, port, network type, or inbound tag. Rules are commonly evaluated in order, so put specific conditions before broader ones to avoid an earlier match. The order of rules is different from how multiple fields within a single rule are combined; confirm the matching logic before making changes.
Routing and traffic rules
Traffic routing · Choose a path by condition
Traffic routing selects how traffic is handled based on its characteristics—for example, direct, through a proxy, or blocked. Global mode usually means that traffic already reaching the core prefers a proxy outbound; it does not automatically capture every app. Bypass modes keep some traffic on a direct route according to the rules. The actual behavior depends on the routing configuration generated by the client, not just the menu label.
Routing and traffic rules
IP address category list
GeoIP groups IP addresses by category for use in routing conditions. For example, geoip:private commonly matches private address ranges. Results depend on the dataset and how recently it was updated; GeoIP does not measure a server's actual location in real time. For domain destinations, whether IP rules can be applied also depends on the domain strategy and DNS results.
Routing and traffic rules
Domain category list
GeoSite groups domains by category. For example, geosite:cn can be used as a domain-matching condition; what the label includes depends on the dataset. Matching uses domain entries maintained by the dataset authors, not a live lookup of the server's location. Domain and IP lists serve different purposes, and the same destination may be categorized differently in each.
Routing and traffic rules
tag / outboundTag
An outbound declares its identifier with tag, and routing rules reference it with outboundTag. direct, proxy, and block are common convention names; actual behavior depends on the outbound's protocol and settings. Entering a tag does not create an outbound—the reference must match an object in the configuration.
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}DNS / TRAFFIC CAPTURE
Name resolution and traffic capture can affect each other. Save a recoverable configuration before changing these settings, and avoid changing the network interface, routes, and resolver all at once—you need to be able to isolate the cause of any problem.
DNS and TUN
Virtual network interface capture
TUN mode captures traffic through a virtual network interface and system routes, including traffic from some apps that ignore system proxy settings. It may require administrator privileges or network permissions, and coverage depends on the client and system routes. Enabling TUN does not force all traffic through a proxy; routing rules, DNS, local network exceptions, and conflicts with other network software still need attention.
DNS and TUN
Synthetic IP and domain mapping
FakeDNS returns synthetic IP addresses to apps and maps them to the original domains, allowing later connections to recover the domain for routing. It is not a public resolver, and the domain has not actually resolved to that address. DNS handling and traffic capture must work together. After leaving a mode that uses FakeDNS, an app may still have a synthetic address cached and need to resolve again or restart.
DNS and TUN
DNS requests taking an unexpected path
A DNS leak occurs when name-resolution requests do not follow the intended path and are sent through another resolver or interface. First clarify the expected policy, then check the operating system, browser-specific resolution, core DNS settings, and app cache. A test page showing a resolver's location is not enough to prove a leak; what matters is the path the requests actually took.
DNS and TUN
routing.domainStrategy
In routing, domainStrategy controls when domains are resolved during rule matching so IP rules can be evaluated. For example, IPIfNonMatch attempts resolution when a domain does not match a rule, then continues matching. This is not the address-selection strategy for outbound connections; fields with similar names must be understood in the context of their configuration layer. Changing this setting does not configure DNS by itself.
DNS and TUN
Sniffing · Extract target information
Traffic sniffing extracts information such as the target domain from protocol characteristics in some connections, helping connections that only provide a target IP match domain-based routes. It does not decrypt app content, and detection is limited by the protocol and encryption. Whether it is used only for routing or also rewrites the destination depends on the settings; check its scope when troubleshooting compatibility.
Use these terms to identify each configuration layer, then follow the relevant guide for menu paths and troubleshooting steps. If interface labels change between versions, use parameter meanings and runtime logs to identify what is happening.
Follow the steps in order: choose a client, import a subscription, configure how traffic connects, and test the connection. Change one configuration layer at a time.
Read the user guide →First confirm whether traffic reaches the core, then check rule matching and the outbound connection. Do not assume a DNS problem is caused by the protocol choice.
Browse troubleshooting FAQs →