Look up terms by where they appear, from protocol names to configuration fields. First distinguish the client, core, and connection settings; then decide whether to change an option in the interface or set it in config.json.
A protocol defines how data is exchanged, a transport carries the connection, and a security layer handles the relevant handshake and protection. Match each layer to the server.
VMess is a proxy protocol in the Project V ecosystem. It authenticates using parameters such as a user ID, so the client configuration must match the server. If authentication fails, check the address, port, and UUID, as well as the device's system clock: a time mismatch can affect the handshake. VMess and WebSocket are different kinds of settings: VMess is a proxy protocol, while WebSocket is a transport that can carry it.
View outbound fields →VLESS is a lightweight proxy protocol that does not encrypt data on its own. It is typically deployed with a security layer such as TLS or REALITY. Choosing VLESS is only part of the setup: check the transport, service name, and security parameters separately. Support for combinations and extensions varies by core, so check the version in use.
VLESS vs. REALITY →Trojan typically carries proxy traffic over a TLS connection and uses a password for authentication. A correct password alone does not guarantee a successful handshake; the server name, certificate trust, and transport settings must also be correct. If you encounter a certificate error, first check the domain and device clock rather than skipping certificate verification.
Compare connection settings →REALITY is a transport security mechanism in the Xray ecosystem, not a standalone proxy protocol or a node address. It is often paired with VLESS. The client needs parameters that match the server, such as the public key, server name, and short ID. A REALITY option in the interface does not mean every core can run this combination; the core actually in use must support it.
See the Xray definition →The transport layer describes how proxy data travels over a connection. Common options include TCP, WebSocket, and gRPC. Parameters such as the WebSocket path and gRPC service name must match the server and any intermediate forwarding setup. Matching transport names alone do not guarantee a working connection; check security settings such as TLS as well.
Find transport settings →Project names, the core that runs connections, and graphical clients are different layers. A client's name does not identify the core it actually uses.
Project V is an ecosystem built around network proxying and communication tools, with V2Ray serving as a key entry point to its technology. The inbound, outbound, and routing models commonly used today stem from this configuration approach, which later gave rise to different projects and forks. When reading older guides, don't assume a field is supported just because it mentions Project V or V2Ray.
Projects vs. clients →V2Fly is a community project that maintains V2Ray-related core implementations and documentation. The term V2Fly-core commonly refers to its core program. The Android client v2flyNG uses the V2Fly core to handle connections, making it suitable for configurations built around that ecosystem. Configuration formats and supported features vary by version; don't copy new parameters from another core without checking compatibility.
View the Android client →Xray is a core project that grew out of the V2Ray ecosystem, with its own implementations of protocols, security layers, and configuration fields. v2rayNG is based on the Xray core; the features available in v2rayN depend on the selected core. The two cores share some configuration concepts, but that doesn't mean every JSON snippet is interchangeable.
Read the core selection notes →The core establishes connections, applies routing, and handles DNS queries. The client manages configuration, subscriptions, and runtime controls. v2rayN, v2rayNG, and v2flyNG are client names; interface settings may be translated into core configuration or may only affect the client itself. To determine whether a feature is available, check both client and core support—not just which client is installed.
Clients and platforms →Use the top-level section names in config.json to find what each part does. First identify where connections enter and leave, then see how routing selects an outbound.
config.json is a common filename for a core's JSON configuration file. It typically organizes settings into sections for inbounds, outbounds, routing, DNS, and policies. JSON requires correctly formatted quotes, commas, and brackets; standard JSON files do not allow explanatory comments. The runtime configuration generated by a client may differ from the client's own settings file, and manual changes to generated files may be overwritten at the next launch.
inbounds is an array of inbound configurations that defines how the core accepts connections, such as local SOCKS or HTTP proxy listeners. Each inbound can specify a listen address, port, protocol, and identifier. 127.0.0.1 typically accepts connections only from the local machine. Changing the listen address to accept connections on all interfaces expands access, so consider authentication and firewall restrictions as well.
outbounds is an array of outbound configurations that describes how connections are sent next, such as through a proxy, directly, or to a blocking handler. An outbound's tag is an identifier referenced by routing rules, not a fixed protocol name; name it as needed for your configuration. Declaring an outbound is not enough: make sure routing can select it and check what happens when no rule matches.
routing selects an outbound based on conditions such as domain, destination IP, port, or inbound identifier. Rules are usually checked in order. A broad rule near the top may prevent more specific rules below it from taking effect. Different condition types in a single rule often all need to match; don't assume any one matching field is enough.
policy defines connection-handling policies, including handshake timeouts, idle timeouts, and buffering by user level. Its role differs from routing: it does not decide whether a domain uses a proxy or a direct connection. Increasing timeouts or buffer sizes at random does not improve speed; first check the field's units, default value, and support in your core.
DNS resolution and connection forwarding affect each other, but they are not the same processing chain. Check rule data, DNS queries, and the final traffic route separately.
DNS resolves domain names to IP addresses. The dns section in a V2Ray configuration typically controls the built-in resolver. The operating system, browser, and core may each send their own queries, so changing built-in DNS does not mean every app will use it. When troubleshooting, first identify which layer resolves the domain, then check the DNS server, query path, and related routing rules.
Here, GeoIP refers to IP address ranges grouped by identifier that can be used in routing rules, for example with geoip:cn. It checks whether a destination IP belongs to a specified set; it does not identify a website's language or pinpoint a server's current physical location. Matches depend on the local data file. If only a domain is available, the subsequent resolution strategy may also matter.
GeoSite is a collection of domain rules grouped by category, used for routing or, in supported DNS configurations, limiting the scope of resolution. The geosite:cn expression references a category in a data file; it does not fetch entries from the internet. Category names and coverage vary by data source. A missing category or incorrect file path can cause loading to fail.
FakeDNS answers domain queries with synthetic IP addresses and stores the IP-to-domain mapping internally, so the domain can be recovered when the connection is processed later. It is not a regular public DNS address and must work with traffic interception, mapping recovery, and routing. If an app caches a synthetic address outside that processing path, the connection may fail. Switching modes may also require clearing the relevant cache.
Understand DNS field boundaries →A DNS leak occurs when domain queries do not follow the expected resolution path—for example, when queries go to another DNS server through the operating system instead of through the proxy. A test page showing the location of a DNS server is only a clue; it cannot prove where all traffic goes. Check the browser's secure DNS settings, system resolver, and core logs. Using encrypted DNS does not, by itself, mean queries use the intended outbound.
Read the DNS routing notes →Routing sends connections along different paths based on conditions—for example, connecting directly to specific domains while sending other connections through a proxy outbound. It is not automatic latency testing and does not necessarily include failover between nodes; those require additional mechanisms. Routing behavior depends on rule order, whether the domain is still visible, and the default outbound used when no rule matches.
View routing examples →These terms often appear in client interfaces. Importing a configuration, capturing app traffic, and testing a connection are three separate steps.
A subscription is a URL or data source used to retrieve and update a set of connection configurations. The client reads it and turns the data into selectable nodes. Subscription URLs may contain access credentials, so treat them as sensitive information and avoid exposing them in public screenshots or logs. Updating a subscription refreshes the configuration list; it does not automatically fix system proxy, DNS, or local network settings.
View subscription import steps →A node is a common client term for a set of server connection parameters, typically including an address, port, protocol, authentication, and transport settings. Its display name can be changed by the provider or user and does not prove the server's location, route type, or performance. Importing a node only means the client accepted the data format; the core still needs to start and the connection needs to be tested.
See the outbound parameters →A system proxy is a proxy setting provided by the operating system for apps to use, usually pointing to an address and port where the client listens locally. Only apps that follow this setting send their connections through it, so enabling the system proxy does not capture all traffic on the device. Check the actual path separately for apps with their own proxy settings, direct connections, or independent networking components.
Compare TUN mode →TUN mode uses a virtual network interface and routing rules to capture network traffic, allowing apps that ignore the system proxy to enter the client's processing path. Actual coverage still depends on administrator permissions, routing, exclusion rules, and other networking software; turning on the switch does not guarantee that all traffic is proxied. TUN is a client and operating system integration feature, not something enabled by adding a field with the same name to any core's JSON configuration.
View TUN settings notes →Latency is a time measurement from a particular test method. It may refer to an ICMP round trip, TCP connection setup, or the duration of a complete request. Different methods cover different stages of the network path, so values from differently named tests may not be directly comparable. Lower latency does not mean faster downloads; also consider throughput, packet loss, and sustained stability.
Understand real connection latency →Real connection latency usually measures how long the client takes to reach a test target through the selected configuration, making it closer to a real request than simply probing a server port. Whether DNS, TLS, or other stages are included depends on the client and test method, so the term does not have a universal definition. Timeouts can also be caused by the test target or routing rules; compare with normal browsing results.
View the connection test process →