V2Ray: 10 Questions and Answers for Beginners — A Quick Guide to Cores, Subscriptions, and Proxy Modes

1. How V2Ray, Cores, and Clients Fit Together

Question 1: Is V2Ray a desktop client?

No. In everyday usage, “V2Ray” may refer to a family of proxy technologies or specifically to the core program that handles protocols, transports, routing, and DNS. The core usually does not include a complete interface for everyday users; v2rayN, v2rayNG, and v2flyNG are the clients used to import configurations, choose nodes, start the core, and manage the system proxy.

A working configuration can be viewed as three layers: the client handles interaction and configuration management, the core establishes connections and applies routing, and node parameters describe the server address, port, user identifier, transport, and encryption layer. When a client shows “running,” it only means that the core process has started; it does not guarantee that the selected node can connect successfully.

Question 2: How should the V2Fly and Xray cores be understood?

V2Fly continues the protocol, transport, and routing capabilities of V2Ray Core and works well with common VMess, VLESS, WebSocket, and gRPC configurations. Xray extends a similar configuration model and is often used for nodes with VLESS, Reality, or specific flow-control parameters. Neither is a subscription service, and neither provides a server automatically. They read the configuration generated by the client and process traffic according to its rules.

Question 3: How do I choose between v2rayN, v2rayNG, and v2flyNG?

Use v2rayN on Windows, macOS, and Linux desktops. On Android, choose between v2rayNG and v2flyNG. v2rayNG uses the Xray core and suits subscriptions that require newer Xray capabilities; v2flyNG uses the V2Fly core and suits nodes that explicitly require the V2Fly configuration model. Do not choose by name alone—the protocols and transport parameters listed by the subscription provider determine which core you need.

2. Distinguishing Node Links from Subscription URLs

Question 4: Where does a subscription URL come from?

A subscription URL is generated by the node service operator or by the configuration system on a self-hosted server. It is not created automatically by v2rayN, v2rayNG, v2flyNG, or the core. It is usually an HTTPS URL that the client accesses to retrieve a set of node configurations. Because it may contain a token identifying your account, do not post it on public pages or include it in screenshots or shared logs.

If you only have a server IP, port, and user identifier, you still need the protocol, transport layer, TLS, SNI, path, Flow, and other fields to build a complete configuration manually. An IP address alone is not enough to connect. The safest approach is to ask the configuration provider which clients, core types, and update methods are supported.

Question 5: How are vmess://, vless://, and subscription links different?

vmess:// and vless:// usually represent a single node share link. Importing one creates a local configuration in the client. A subscription URL is a remote collection of configurations that may contain multiple nodes and groups; when you update the subscription, the client fetches the content again and synchronizes changes. A single-node link does not update automatically when the service changes its name or parameters.

• When the copied content is a single vless:// or vmess:// link, use an option such as “Import from clipboard.”
• When the copied content is an HTTPS URL identified by the provider as a subscription, add it under “Subscription groups” rather than the manual node editor.
• If the node count drops after an update, the remote configuration may have changed; this does not necessarily indicate a client malfunction.

3. The Right Order for Importing Subscriptions and Choosing a Core

Question 6: What should I do after the first import?

For the initial setup, do not change routing, DNS, TUN, and ports all at once. Import the subscription, choose a node, start the core, enable the system proxy, and test web access. Once the basic path works, adjust routing rules one at a time. This makes it easier to tell whether a problem comes from node parameters, system interception, or a later rule.

1. Confirm the client

   Open v2rayN on a desktop system. On Android, choose v2rayNG or v2flyNG according to the configuration requirements. After launching it, check the status bar to confirm that the core loads normally.

2. Add the subscription

   In v2rayN, go to “Subscription groups” → “Subscription group settings” → “Add,” enter a name, and paste the subscription URL. Save it, then select “Update all subscriptions.”

3. Choose the core

   Go to “Settings” → “Parameters” → “Core type” and choose Xray or V2Fly as required by the node. When fields such as Reality or Flow are present, follow the provider’s instructions first.

4. Select a node

   Choose a configuration from the node list and set it as the active server. Check that the address is not empty and that the port is between 1 and 65535 before starting the core.

5. Enable the proxy

   Start with system proxy mode, visit two different sites, and check the core log. Once basic access works, decide whether to enable TUN or custom routing.

Menu names on Android may change between versions, but the workflow is the same: add a subscription, update the configuration, choose a node, and start the connection. When the system first asks for permission to create a network connection, approve it. Otherwise, the client may show the selected node while system traffic never enters the local proxy channel.

4. The Boundary Between System Proxy and TUN Mode

Question 7: What is the difference between a system proxy and TUN?

A system proxy uses the operating system’s proxy settings to direct applications that support HTTP or SOCKS proxies to the client’s listening port. It is easy to configure and its scope is relatively easy to observe, making it suitable for browsers and desktop applications that follow system proxy settings. Some applications ignore those settings or open network connections directly, so their traffic will not automatically enter the proxy core.

TUN mode creates a virtual network interface and intercepts traffic that matches its routing rules at a lower network layer, covering more applications that do not read system proxy settings. It usually requires system permissions and also involves routing tables, DNS, and bypass rules. If enabling TUN makes local devices unreachable, DNS resolution fail, or the network loop, disable TUN first and return to system proxy mode to verify that the basic node works.

Beginners should start by verifying the system proxy. If the core log shows a local SOCKS listener at 127.0.0.1:10808, manually configured applications must use the local loopback address, with the port matching the log. Do not enter the remote node port as the local proxy port; they serve completely different roles.

1. The browser works but one application does not: first check whether that application reads system proxy settings.
2. No applications work: check that the core has started, the local port is listening, and the node has not timed out.
3. Only TUN causes problems: check virtual-interface permissions, DNS settings, and LAN bypass rules.

5. Where to Look First When a Node Will Not Connect

Question 8: A node test times out—what should I check first?

First distinguish between a failed subscription update and a failed node connection. The former occurs while retrieving subscription content and involves the subscription URL, network environment, and update method. The latter occurs while the core connects to a node, so focus on the server address, remote port, protocol, TLS, transport layer, and system time. Do not reinstall the client just because the latency column is blank; the first clear error in the log is usually more useful.

Test the same node three times in succession, waiting about five seconds between tests. If only one test times out and later tests recover, the cause may be a temporary network fluctuation. If every test fails at roughly the same point, check DNS resolution and the remote port. A system clock mismatch can also affect TLS connections, so verify the date, time zone, and automatic time synchronization.

Question 9: It says connected, but web pages still will not open. What should I do?

“Connected” may only mean that the client created a local channel or that the core process is running. Next, confirm that system traffic enters that channel and that the core can forward requests to the remote server. Check the local listener, system proxy, core log, DNS, and routing rules in that order; this is more effective than repeatedly switching nodes.

6. Start with Simple Routing Rules

Question 10: How should I choose between global, rule, and direct modes?

Global mode usually sends most proxyable traffic through the current node. It is useful for checking whether the node itself works, but not for validating complex split routing over the long term. Rule mode selects different exits based on domains, IPs, ports, or processes and is the more common everyday choice. Direct mode mainly pauses proxying or tests the local network; it does not mean the client has exited, and the core process may continue running.

When setting up routing for the first time, start with the default rules and add only one rule that can be clearly verified. For example, send LAN addresses directly and check whether printers, router administration pages, and file sharing work again. Adding many domain categories, DNS rewrites, and process rules at once makes it difficult to match log entries to specific conditions.

• Step 1: Record the current mode, active node, core type, and DNS settings to create a recoverable baseline.
• Step 2: Keep local and LAN addresses on a direct route; common private address ranges should not be sent to a remote node.
• Step 3: Add one group of rules at a time, revisit the target site, and confirm the matched outbound route in the log.
• Step 4: If the result is unexpected, roll back this change first; do not switch the core and proxy mode at the same time.

Routing rules determine whether traffic goes direct, through a proxy, or is blocked. Subscription nodes only provide optional remote connection parameters; the two are not the same thing. Updating a subscription usually does not design local routing for you. Preset client rules may also change between versions, so identify whether you are using the default or custom rules during troubleshooting.

After completing the basic checks for all 10 questions, verify the setup with a fixed workflow: update the subscription, choose a node, start the core, confirm the local listener, enable the system proxy, visit the target site, and check the matching log entry. Once this is stable, enable TUN, adjust DNS, or add split-routing rules one at a time to keep the problem boundaries clear.