V2Ray Beginner FAQ: 10 Answers on Subscription Links, Nodes, and Clients

01 | How do V2Ray, clients, cores, and nodes fit together?

V2Ray is the name of a proxy project and its related technology—not a connection you can use by itself. You work through a client interface; the core reads the configuration and handles connections; and a node provides the details for connecting to a remote server. Installing a client alone doesn't give you a working node.

• Client: v2rayN, v2rayNG, and v2flyNG provide an interface for importing configurations, choosing nodes, viewing logs, and changing settings.
• Core: Xray and V2Fly handle low-level tasks such as protocol communication and routing. Their capabilities depend on the core and its version.
• Node: Includes the server address, port, user ID or password, and transport and security options.
• Subscription: An address used to retrieve or update a set of node configurations—not a standalone communication protocol.

Troubleshoot by layer: if the window won't open, check the client environment first. If the core reports a startup error, check the configuration and ports. If the core starts normally but connections time out, check the node, network, and traffic-routing settings.

02 | Which client should you use on desktop or Android?

Choose an app for your device first, then check that its core meets the node's requirements. Use v2rayN on desktop. On Android, v2rayNG with Xray is the usual choice; consider v2flyNG only when your configuration specifically requires V2Fly. The recommendation below is for a first-time Android setup, not a universal ranking across platforms.

In Android packages, arm64 typically means a 64-bit ARM device. If you're unsure of your architecture, check your device information or choose the usually larger universal package. On desktop, check both your operating system and processor—don't install a package just because its filename includes the client name.

03 | How do subscription links differ from single-node links, and how do you import them?

A subscription is usually an HTTPS address that returns multiple nodes. A single-node share link often starts with vmess://, vless://, or trojan://. A QR code is just a way to encode text: it may contain a single node or a subscription address, so you can't tell which by its appearance alone.

1. Import a subscription in v2rayN: Open “Subscription Group” → “Subscription Group Settings” → “Add.” Enter a remark and the subscription URL, save, then use the “Subscription Group” menu to update. Menu labels may vary slightly between versions.
2. Import a subscription in v2rayNG: Open “Subscription Group Settings” from the side menu, tap “＋,” enter a remark and the URL, and save. Return to the main screen and choose “Update Subscription” from the top-right menu.
3. Import a single node: Copy the entire share text, then use the client's “Import from clipboard” option. This usually adds only the current node; it won't create an updateable subscription group.

Updating a subscription refreshes the configurations in that group, so nodes removed or changed by the provider may change too. To keep manual edits, copy the nodes to a separate group before the next update.

04 | Can one subscription be used on a computer and phone at the same time?

Technically, you can import the same compatible subscription on both devices. Whether they can connect simultaneously, how many devices are allowed, and how traffic is counted depend on the service's rules. Successfully importing a subscription doesn't mean unlimited devices can be online at once.

To move between devices, import the subscription again and then check the local settings. Don't overwrite an Android setup with the full desktop configuration: local listeners, file paths, and traffic routing may differ.

05 | How should you choose between VMess, VLESS, and REALITY?

The protocol selected in the client must match the server. Changing a VMess node's protocol dropdown to VLESS won't turn it into a VLESS connection. REALITY is a security-layer feature, not a user protocol alongside VMess and VLESS, and it isn't a universal switch supported by every core.

A port of 443 doesn't prove that a node uses TLS. With WebSocket transport, the path and Host may also affect the connection. Test the imported configuration first; don't change several fields at once in an attempt to “optimize” it.

06 | Is lower node latency always better?

Low latency helps with interactive tasks, but one number can't tell you whether a node is usable. A TCP connection test only measures the connection to a port. A real connection test accesses a specified destination through the proxy. A download speed test is a better measure of throughput, but it uses traffic.

• Check that it works first: Run a real connection test on candidate nodes and confirm that the request completes. The test destination itself may be down, which can also cause a failure.
• Then compare stability: Repeat the test 3 times on the same network and against the same destination. Look for recurring timeouts instead of picking the lowest result.
• Finally, test your actual use case: Open the website or app you need. Video and large downloads depend more on sustained throughput; remote interaction depends more on latency consistency.

Regions, multipliers, and labels such as “premium route” in node names are provider descriptions, not properties verified by the client. Test nodes instead of relying on their names, and avoid repeatedly speed-testing large numbers of nodes.

07 | What do system proxy, local ports, and TUN do?

In v2rayN, selecting a node only chooses the outbound configuration. App traffic still needs to reach the client. On Windows, a common method is to open the tray menu and choose “System Proxy” → “Set system proxy.” When you're done, choose “Clear system proxy.” On other desktop systems, check the result in the system network proxy settings.

The two ports below are examples of local listeners, not defaults for every version. Check the actual listener settings under “Settings” → “Parameter Settings” in the client, and confirm them in the startup log.

• System proxy: Tells apps that follow the system proxy settings to send requests to the local proxy. Some games, command-line tools, and apps with their own network stack may ignore it.
• App-specific proxy: If an app supports proxy settings, enter the local address 127.0.0.1, the actual listening port, and the correct protocol. Don't enter the remote node's port as the local proxy port.
• TUN: Routes more traffic through a virtual network interface. It may require additional permissions and involve routing and DNS settings. Enable it only after basic proxy connectivity works.

You usually don't need to change the listening address to 0.0.0.0 for local use. Allowing LAN access expands who can connect, so consider firewall rules and access controls. Beginners should keep the listener restricted to the local device.

08 | What's the difference between global proxy and split routing?

System proxy settings control whether apps send requests to the client; routing rules control which outbound route handles requests that reach the core. These are separate layers. Even with global proxy routing enabled, programs that ignore the system proxy may not send traffic through the client.

1. Verify the connection first: Select a node and confirm it works with a test request that explicitly uses the proxy. Don't add custom rules yet.
2. Then choose a routing mode: For everyday use, choose a suitable preset from the routing options in v2rayN, and check its direct, proxy, and block rules. Preset names may vary between versions.
3. Check rule order: Rules are usually evaluated in order. A broad rule near the top may prevent more specific rules below it from taking effect.
4. Verify the actual route: Test one destination that should go direct and another that should use the proxy. Check the logs instead of relying only on the mode name in the toolbar.

Android per-app settings are another layer of control: excluded apps may not enter the client's VPN tunnel. If only one app fails, check the per-app list first, then the domain routing rules. Don't assume the node is at fault.

09 | Should you change DNS? Why does the connection succeed but websites won't load?

DNS translates domain names into addresses. A successful connection test doesn't prove that all domains resolve or that app traffic is working. Different routing policies may use different DNS paths for direct and proxied requests, so switching to a random DNS address won't fix every issue.

• Check how widespread the problem is: Test multiple destinations. If only one site fails, check the site's status, the node's exit, or your rules before resetting the whole configuration.
• Identify the error type: DNS resolution failures, connection refusals, timeouts, and certificate errors in the logs indicate different stages. Start with the first relevant error.
• Check the system clock: Enable automatic time synchronization. A badly incorrect date can break certificate validation and may affect authentication for some protocols.
• Change DNS one setting at a time: Record the original values in the client, change only one setting, then restart the relevant connection test. Encrypted DNS over the network also needs a working route to its resolver.

10 | What should you check first when updates or startup fail, or the connection drops?

Troubleshoot in this order: can the client run → can the core start → can the node connect → does the app send traffic through the proxy? Change one thing per test and note when the error occurs. These three common symptoms point to specific settings.

When asking for help, include your operating system, client and core versions, the steps that led to the error, and relevant logs with sensitive details removed. Hide subscription tokens, user IDs, passwords, and private addresses. The protocol, exact error text, and point of failure are usually more useful than a screenshot saying “can't connect.”

1. Keep a record of the current configuration and test another known-working node first.
2. Temporarily disable extra TUN settings, custom routing, or per-app changes to return to a simple configuration you can troubleshoot.
3. Once the basic connection works, restore settings one at a time and repeat the same test request.