First, the basics
1. Is V2Ray a client, a protocol, or a core?
In everyday conversation, “V2Ray” often refers broadly to an entire proxy-tool ecosystem. Strictly speaking, however, it is neither a single interface nor a specific protocol. The V2Ray project provides a proxy core and related capabilities for handling inbound and outbound connections, transports, security, DNS, and routing rules. The apps users actually open and operate—v2rayN, v2rayNG, or v2flyNG—are graphical clients. A client stores configuration, displays nodes, starts the core, and switches the system proxy; the core it invokes performs the actual connection and traffic forwarding.
Once this relationship is clear, troubleshooting becomes much easier: an interface that will not open is a client-level issue, failed node-parameter parsing may be a configuration issue, connection timeouts may occur on the network or server side, and unexpected routing results call for a review of core rules. To explore how protocols, transports, and routing work together, see the protocol reference.
2. What is a subscription link, and how does it differ from a single node?
A single node is a set of specific connection parameters, typically including a server address, port, user ID, protocol, transport, and security settings. A subscription link is an entry point for a client to retrieve a set of node configurations. After importing the subscription URL, the client requests and parses the subscription data into a node list. When you run “Update subscription” later, it fetches the latest nodes, names, and parameters provided by the server.
A subscription URL is not a node address and should not be entered in the server-address field. The correct sequence is: copy the complete subscription link, open the client’s subscription manager, add the subscription, save it, run an update, and then choose a node from the server list. If you only have a VMess or VLESS share link, use an option such as “Import from clipboard” rather than adding it as a subscription. For the exact buttons and steps, see the installation and configuration guide.
3. What do the client, core, and subscription service each do?
The client handles interaction, the core performs connections, and the subscription service provides configuration; none can replace another. On desktop, for example, v2rayN reads a subscription, turns the selected node and routing options into a configuration the core can understand, and then starts the appropriate core to process network traffic. v2rayNG and v2flyNG on Android follow a similar process, although the system takeover method and interface entry points differ.
This distinction is essential when identifying the source of a problem. If a subscription update returns empty content, first check the subscription URL and service status. If nodes appear but startup reports a configuration error, verify that the parameters were parsed completely. If the client reports that it is running but the target app still connects directly, check the system proxy, virtual-adapter takeover, or the app’s own network settings. Do not change the protocol, DNS, routing, and port repeatedly before locating the problem; doing so turns one fault into several interacting variables.
Choose a client by platform and core
4. How do v2rayN and v2rayNG differ?
v2rayN is a desktop client for managing servers, subscriptions, the system proxy, and routing in Windows, macOS, or Linux desktop environments. Available package formats and system capabilities vary by platform, so confirm the operating system and processor architecture before downloading. v2rayNG is an Android client that typically uses the Xray core and relies on the system’s network-takeover capability to connect apps according to the configuration.
Their names are similar, but their installation packages are not interchangeable, and their configuration entry points are not identical. Common desktop tasks include enabling the system proxy, selecting a routing mode, and viewing core logs. On Android, the first connection usually requires confirmation of system permission, and per-app proxy rules may be available. To choose a package quickly, open the download center, select your platform, and then choose the file for your architecture.
5. Which should you choose, v2rayNG or v2flyNG?
Both are Android clients; the main difference is the core ecosystem they use. v2rayNG uses the Xray core and suits configurations that require Xray protocol extensions or transport capabilities. v2flyNG uses the v2fly core and suits standard configurations supported by the V2Fly ecosystem. Follow the compatibility guidance from your subscription provider rather than comparing interface names alone.
If a subscription contains VLESS configurations that depend on specific Xray capabilities, v2rayNG is usually the better choice. If the configuration is explicitly based on protocols and transports supported by the v2fly core, v2flyNG can handle the connection. An “unsupported configuration item” or an unrecognized field after import does not necessarily mean the subscription link is invalid; the current core may simply not support that combination. Compare both clients in the Android download section, then choose based on configuration compatibility.
Protocols and subscriptions: don’t change them by name alone
6. Which should you choose, VMess or VLESS?
VMess and VLESS can both be used for proxy connections between a client and server, but their authentication and security designs differ. VMess configurations typically include a user ID, additional identification parameters, transport settings, and security options, and they are more sensitive to inaccurate client time. VLESS has a leaner protocol design and does not encrypt content by itself; it is commonly used with TLS, REALITY, or other supported security and transport combinations.
Beginners do not need to manually “convert” a working node to another protocol. The server determines the protocol, and the client parameters must match it field by field. If the subscription provides VMess, import it as VMess; if it provides VLESS, import it as VLESS. Changing the protocol name, port, user ID, or transport yourself will usually cause a handshake failure. Neither protocol has a fixed speed advantage independent of the specific route and configuration; real-world performance also depends on server load, network paths, congestion, and routing. For field descriptions, see the protocol reference.
7. Why are there no nodes after importing a subscription?
First confirm that you ran “Update subscription” rather than merely saving the subscription URL. Adding a subscription usually only creates a record; the client still needs to request its contents. If the list remains empty after updating, check in order whether the link was copied completely, whether spaces were added at either end, whether the subscription has expired, whether your current network can reach the URL, and whether the client log shows a parsing error.
If opening the subscription URL in a browser displays a long string of text, there is no need to copy that content into the client piece by piece; as long as the link works, let the client request and parse it. If the response is a web notice, login page, or error message, the client cannot recognize it as a node list. Also check compatibility between the subscription and the client core: fields unsupported by the current core may result in only some nodes being imported or in a format error. Follow the tutorial through “Add subscription, update subscription, choose a node” again to quickly identify where the process stops.
Connections and routing: check layer by layer
8. Why won’t websites open when the client says it is connected?
“Core started” only means that the local process has begun running. It does not mean the remote connection through the node has completed, nor that browser traffic is entering the proxy. First run a real connection-latency test for the selected node, then open the runtime log and look for timeouts, refused connections, DNS resolution failures, or authentication errors. A successfully opened local port alone does not prove that the server is reachable.
After confirming that the node works, check the traffic entry point. On desktop, make sure the system proxy is enabled and that the browser is not using a separate, conflicting proxy setting. On Android, verify that connection permission is still active and check whether per-app rules are enabled. If only certain domains fail, inspect DNS and routing matches. If every node fails at once, first check the local network, subscription status, and client log. If only one node fails, the issue is more likely with that node’s parameters, route, or service status. See the connection guide for the complete troubleshooting order.
9. What do global, rule-based, and direct modes mean?
These modes determine which outbound path receives traffic. Global mode usually sends most traffic that can be intercepted through the proxy node. It is useful for quickly confirming that a node works, but it can create unnecessary proxy traffic. Rule-based mode matches domains, IPs, ports, processes, or rule datasets so that some requests use the proxy while others connect directly. Direct mode largely bypasses the proxy and can help restore local connectivity or provide a comparison during troubleshooting.
Rules are usually matched in a defined order. More specific rules should come before broader ones; otherwise, a broad rule may match first and prevent later entries from running. Domain rules handle domain matching, while IP rules handle destination addresses. DNS results and the resolution path can also affect the final decision. Beginners should start with the client’s stable preset, confirm that the connection works, and then make small changes—altering and testing one rule group at a time. For domain, IP, CIDR, and geosite syntax, see the protocol and routing reference.
Updates and migration: save your configuration first
10. What should you save when updating the client, changing devices, or reinstalling?
Most importantly, save any subscription URL that is still valid, and record your current routing, DNS, system proxy, and per-app settings. If a manually added node is not included in the subscription, back it up separately using the client’s export or share function. Do not save only the node name: it is merely a display label and cannot restore the server address, user ID, transport, or security parameters.
Before updating the client, exit the running core and disable the system proxy, then choose the new installation package for your platform. After installation, reimport the subscription and update the nodes first. Do not overwrite the new configuration wholesale with every advanced field from the old one; configuration structures and defaults may change between versions. After migration, verify in this order: update the subscription, choose a node, test latency, start the connection, check the logs, and verify routing. See the tutorial for installation steps, and get the relevant platform file from the download center.
First connection for beginners: a practical checklist
Here is the earlier discussion condensed into a practical workflow. If every step produces a clear result, you can locate problems immediately without repeatedly uninstalling the client or rebuilding the entire configuration.
- Confirm your platform in the download center, choose v2rayN, v2rayNG, or v2flyNG, and verify the processor architecture.
- After installation, open the client first. Do not rush to change DNS, routing, or advanced core parameters.
- With a subscription URL, open subscription management, save it, and run an update. With a single share link, import it from the clipboard.
- Select a node from the list and run a real connection-latency test to rule out obviously unreachable configurations.
- Start the connection and complete the system proxy or network-takeover permission flow for your desktop or Android client.
- Open the target page to verify the connection while checking the log to confirm that requests are actually using the selected outbound.
- Once the basic connection is stable, switch to rule-based mode and gradually add custom DNS or routing rules.
If the connection fails, return to the most recent step with a clear result: can the subscription update, can the node be parsed, can the server be reached, is traffic entering the client, and does the route match? Handle one layer at a time and record what changed before and after. This is faster and makes the real cause easier to find than repeatedly switching protocols or changing several settings at once.