Use the configuration layer to narrow down an issue. First distinguish the client from the core, then check the protocol, security layer and transport method. Subscriptions, routing and DNS determine how settings are updated and requests are handled.
Choosing a client: Start with v2rayN on desktop and v2rayNG on Android. Consider v2flyNG if you need a V2Fly core. A client's name alone doesn't tell you what its core supports.
Ecosystem context: Project V is a good starting point for understanding the open-source proxy technology ecosystem around V2Ray. It is not the name of a specific graphical client. “V2Ray configuration” may refer broadly to related protocols and tools, but support for individual fields varies by project. When following a guide, distinguish the ecosystem name from the core actually in use.
Core lineage: V2Fly continues community development of V2Ray and evolves its core software and configuration capabilities. This site's v2flyNG is an alternative Android client that uses a core from this family, useful when an existing configuration specifically requires its features. A configuration labeled “V2Ray” does not mean every extended field is supported by other cores.
Core capabilities: Xray grew out of the V2Ray technology stack and is now an independently developed core project, commonly used with v2rayN and v2rayNG. For features such as REALITY, check the core and version actually in use—not just whether the client shows a corresponding field. After updating a client, confirm that the selected core is compatible with the imported configuration.
Where responsibilities differ: The client provides the node list, subscription management, mode controls and log viewer; the core parses configuration, establishes connections and applies routing. A client being able to import a link doesn't guarantee that the selected core supports every parameter in it. To troubleshoot compatibility, note the client, active core and error field, then determine whether the issue lies in the client's conversion or the core's execution.
Know the layers: VMess, VLESS and Trojan define proxy communication; TCP and WebSocket describe how data is carried. Similar-looking options aren't interchangeable.
Protocol settings: VMess is a proxy protocol in the V2Ray ecosystem. A connection requires the user ID, address, port and transport settings to match. Authentication also depends on the system clock, and a time difference can cause connection failures. Don't copy outdated settings from old guides into a current configuration; use the complete set of parameters provided by the server.
Security setup: VLESS does not provide full transport encryption on its own and is typically paired with a security layer such as TLS or REALITY. The user ID, flow control, transport and security settings must all match the node—changing only the protocol dropdown is not enough. If an imported configuration contains unsupported fields, check the core's capabilities before clearing security parameters one by one.
Connection setup: Trojan typically carries proxy requests over a TLS connection, so authentication and TLS settings must match the server. Even with the right password, an incorrect server name can cause a handshake failure. Distinguish authentication errors from certificate errors; don't disable certificate verification instead of checking the domain, system clock and certificate chain.
How data is carried: The transport method determines how proxy data is organized and delivered; it is a different layer from the proxy protocol. A WebSocket path, request host name and gRPC service name each mean something different. Don't copy a value from one field into another. Changing the transport usually requires server-side support; switching it only on the client won't make the connection compatible.
What to check: The connection address, server name and authentication material serve different purposes. For handshake errors, check each field according to its meaning instead of routinely skipping verification.
Secure connections: TLS encrypts transport and authenticates the server. Certificate validation is a key step in verifying who you're communicating with. A trusted certificate chain, matching name and correct system clock all affect the result. For certificate errors, first check the clock and server name, then the server certificate. An encrypted connection does not necessarily mean the peer's identity was verified.
Match the parameters: REALITY is a transport security mechanism in the Xray ecosystem, often used with VLESS. It is not a standalone toggle that replaces the node's protocol. Match the client's public key material, server name, short ID and other parameters against the server configuration. Field names may vary between versions, so check what each parameter means and avoid piecing together settings from different nodes.
Server name: SNI is an extension in the TLS handshake that indicates the target service name, helping the server select the right configuration. The node's connection address can be an IP while the server name is a domain; they don't have to match. The client may label this field “Server Name.” Use the value required by the server, not the node's label or an arbitrary website domain.
What's the difference? Encryption protects data in transit; authentication verifies the identity of the other party. They solve different problems. A setting indicating no protocol-level encryption doesn't necessarily mean the entire connection lacks a security layer; check for options such as TLS as well. Review the configuration layer by layer instead of drawing conclusions from a single encryption dropdown.
What to keep in mind: Subscriptions fetch configuration, nodes describe connection endpoints, and groups help organize them. A successful update and a working node are separate things to check.
Configuration source: A subscription link lets a client fetch a set of node configurations and sync changes during later updates. It may contain access credentials, so treat it as sensitive and don't share it in screenshots, logs or discussions. Updating a subscription only fetches configuration; it won't fix a server-side problem. If an update fails, check whether the link is invalid, the network is reachable and the content can be parsed.
Connection endpoint: A node typically includes a server address, port, proxy protocol, authentication, transport and security settings—not just a server IP. The node name is a label for convenience, not proof of its location or connection quality. Keep all parameters when copying a node; entering only its address and port is usually not enough to recreate the original configuration.
What groups do: Subscription groups distinguish configuration sources and make it easier to filter nodes, update subscriptions and manage labels. A group's name doesn't decide whether a request is proxied or goes direct; the route depends on the selected node, operating mode and routing rules. When using automatic updates or server filters, check which group the setting applies to so filtered results aren't mistaken for missing subscription content.
What the test measures: Real connection latency usually means the time measured when accessing a test target through a specified node. The stages included depend on how the client implements the test. It differs from the time to establish a TCP connection to a server port and doesn't directly indicate download speed. For a fair comparison, use the same test address, network and method. Check actual access and logs before drawing conclusions from a single timeout.
Trace the path: First check whether the request contains a domain or an IP, then review the rules and DNS strategy. Verify the application connection path separately from the DNS query path.
Choose a route: Routing rules send requests to an outbound such as direct, proxy or block based on conditions including domain, IP, port or inbound. Rules are commonly evaluated in order, so a broad rule placed too early can prevent more specific rules from matching. Traffic splitting isn't a standalone protocol; it results from the rules, default outbound, DNS resolution and traffic interception working together.
Address lists: GeoIP organizes IP addresses into collections by region or category. Compatible cores can reference this data using the corresponding tags. Matches depend on the data source, update date and actual destination IP; a region label isn't a precise location. For shared infrastructure or changing addresses, check the destination IP in the logs before adding a more specific rule.
Domain lists: GeoSite organizes domain rules by category so you can manage routing for a group of sites using tags. It matches domains, unlike GeoIP, and doesn't automatically include every IP those sites currently use. Whether a rule matches also depends on whether the core can obtain domain information and the data file contains the relevant tag.
How it works: FakeDNS answers domain lookups with fake IPs from a reserved address range and saves the mapping so the destination domain can be restored for later traffic. It needs to work with a traffic interception path such as TUN and a mechanism to restore the mapping; it isn't simply a different public DNS address. Some apps may not work with these addresses, and old DNS cache entries may matter when switching settings.
Where resolution happens: A DNS leak usually means domain queries aren't sent along the expected path and are instead handled directly by the system, an app or another resolver. Routing the application connection through a proxy doesn't mean its DNS queries use the same route. Check browser-level resolution, the system cache and the client's DNS rules; an exit IP or resolver name alone doesn't prove there's a leak.
How traffic is handled: System proxy and TUN cover different traffic; local inbound determines how apps connect. When something goes wrong, use logs to see where the request stalls.
What it covers: System proxy registers the local proxy address in the operating system settings. Only apps that follow those settings will use it. Some programs use their own network settings, so enabling the system proxy doesn't route all traffic. If regular internet access fails after closing v2rayN, check whether the system still points to a proxy port that's no longer running.
How interception works: TUN sends traffic to the client through a virtual network interface. It usually covers more apps than system proxy, but system routes and exclusions still apply. Enabling it may require additional permissions and compatible DNS and loopback protection settings. When troubleshooting for the first time, confirm the node works before enabling TUN so you don't change too many settings at once and lose a useful baseline.
Listening endpoint: Local inbound is where the core receives app requests. Common options include HTTP, SOCKS and mixed proxy ports. The app's proxy type, address and port must match the actual listening configuration; an open port doesn't guarantee protocol compatibility. A loopback address and a listener on all interfaces have different access scopes, so confirm that LAN access is really needed before changing the setting.
Troubleshooting evidence: Runtime logs record events such as configuration loading, parsing, handshakes and connections, helping distinguish local settings errors from remote connection failures. Check the time window for a specific access attempt instead of mixing historical errors with the current request. Before sharing logs, remove subscription links, user IDs, authentication details and other sensitive data. If needed, share only the error type and relevant field names.