V2Ray Beginner FAQ: Subscription Import, Connection Failures & Proxy Modes

1. Subscription Links and Node Import

Question 1: Where do subscription links come from?

A subscription link is not an account generated by the client, and it does not come bundled with v2rayN or v2rayNG. It usually comes from a self-managed server configuration, a network service provider's user panel, or a configuration portal shared by an organization administrator. The client only reads node details from the link, then passes them to the V2Ray, Xray, or v2fly core to establish a connection.

A single subscription link may return multiple VMess or VLESS configurations, or just one node. When copying it, keep the complete protocol prefix, path, and query parameters; do not copy only the domain. If the link requires authentication, do not import the webpage URL as the subscription address. Confirm the source and your access rights before use, and store any included credentials securely.

Question 2: Why are there no nodes after importing a subscription?

The most common reason is that a subscription group was created but never updated. Other possibilities include spaces added to the link, an expired subscription, an empty response, or filters that hide every node in the group. Run an update first, then check the client message and node count in the subscription group instead of judging import status from a blank main screen alone.

1. Copy the complete link

   Copy the full address from the provider's subscription page. Make sure it starts as a recognizable web address and that chat software has not truncated its ending parameters.

2. Create a subscription group

   In v2rayN, open “Subscription Groups” → “Subscription Group Settings” → “Add”. Enter an alias and subscription address, then save.

3. Update all subscriptions

   Return to the main screen and open “Subscription Groups” → “Update All Subscriptions (Without Proxy)”. If the subscription cannot be reached directly from your current network, use the proxy update option instead.

4. Check the filters

   If the update reports success but the list is still empty, clear the include and exclude keywords in the group and make sure name filtering has not hidden the nodes.

5. Review the update result

   Check the returned item count in the status bar or logs. A response with zero configurations usually means the subscription itself needs checking, not repeated client reinstallation.

2. Connection Failures and Unreachable Websites

Question 3: The node test works, but connecting fails. What should I do?

A latency test only shows that an address responded at that moment; it does not guarantee a successful protocol handshake. A real connection also checks the server address, port, user ID, transport, TLS, SNI, REALITY parameters, and system time. Any mismatch can cause a timeout, a closed connection, or an unreachable destination error.

Try another node from the same subscription first. If only one node fails, focus on that node's configuration. If every node fails at once, check the local network, DNS, core startup status, and system time. In Windows 11, open “Settings” → “Time & language” → “Date & time” and enable automatic time setting; a large time difference can disrupt the TLS handshake.

Question 4: The client says connected, so why are websites still unreachable?

“Connected” usually means only that the core has started or that one test request succeeded; it does not mean browser traffic is using the proxy. On desktop, check the system proxy switch first. On Android, confirm that the system VPN permission is still active. If only one website fails, also check routing rules and DNS results instead of assuming every node is down.

For a setup using local port 10808, a browser with a manually configured proxy should point to 127.0.0.1:10808, not the remote port on the node server. When the system proxy is enabled, the client writes the setting to the operating system, so the browser usually follows it automatically. If the port is changed manually, update the browser's old proxy setting as well.

3. Global, Rule-Based Routing, System Proxy, and TUN

Question 5: Should I use global mode or rule-based routing?

Global mode sends all traffic managed by the client through the proxy, making it useful for quickly checking whether a problem is caused by routing rules. Rule-based routing chooses direct, proxy, or blocked access according to domains, IPs, protocols, or rule sets, making it better for everyday use. Beginners can start with global mode for connectivity testing, then switch back after confirming that the node works.

Rule-based routing is not simply a matter of deciding between “mainland China” and “outside China”. The client matches routing rules from top to bottom, and the first match determines the outbound path. A custom rule placed after the default rules may never take effect. After changing rules, reload the configuration and use the logs to confirm which rule actually matched the target domain.

Question 6: What is the difference between system proxy and TUN mode?

A system proxy mainly affects applications that follow the operating system's proxy settings. Browsers usually do, but some programs, command-line tools, and software with its own network stack may bypass it. TUN mode uses a virtual network adapter to capture a broader range of IP traffic, so it offers wider coverage but depends more on drivers, permissions, DNS interception, and routing-table configuration.

In v2rayN, ordinary web browsing can start with “System Proxy” → “Set system proxy automatically”. Consider TUN only when an application clearly ignores the system proxy. If local network devices become unreachable after enabling TUN, check the LAN bypass rules. If the core fails to start, check administrator permissions, virtual adapter status, and port conflicts.

• Browser traffic only: Prefer the system proxy. It is simple to configure and easy to restore after turning it off.
• Desktop apps ignore the proxy: Check that the app has no separate proxy setting, then test TUN mode.
• Need access to LAN devices: Keep private-address direct rules for networks containing printers, routers, and home storage devices.
• No network after switching modes: Turn off TUN first, then exit the client and confirm that the system proxy has been disabled.

4. VMess, VLESS, and Subscription Updates

Question 7: Can VMess and VLESS parameters be mixed?

No. VMess and VLESS are different protocols. Although both may expose fields such as address, port, user ID, transport, and TLS, the protocol type and server-side configuration must match. A VLESS configuration may also combine REALITY and XTLS Vision. Without the public key, short ID, flow control, or server name, the handshake usually cannot complete.

Importing a subscription reduces manual transcription errors. If you must add a node manually, compare the protocol, address, port, user ID, encryption or flow control, transport, path, Host, TLS, SNI, and fingerprint settings one by one. Do not copy parameters from one protocol into another just because two nodes use the same address.

Question 8: What should I do if subscription updates fail or keep timing out?

First determine whether the subscription address itself is reachable, then check whether it needs to be fetched through a proxy. An update failure does not usually remove existing nodes immediately; the client can generally continue using the last successfully saved configuration. Do not delete the entire subscription group before troubleshooting, or you will lose both the old nodes and the entry used for proxy updates.

After a subscription update, the configuration currently running may not reload automatically. In v2rayN, select a node again and start the core once; in v2rayNG, stop the connection, select the updated node, and start it again. Check the log timestamps to confirm that the active configuration is the updated version, not an older copy still in memory.

5. Android Background Connections and Client Choice

Question 9: Why does v2rayNG disconnect in the background, and how do I set per-app proxying?

Android may restrict background apps through battery policies. The first time you connect with v2rayNG, accept the system VPN connection request; if permission is denied, the client cannot create a VpnService channel. If the connection stops after running for a while, add the client to the system battery-optimization allowlist and permit background activity. A common path in Android 14 is “Settings” → “Apps” → “v2rayNG” → “App battery usage” → “Unrestricted”; menu names vary slightly by device.

Per-app proxying specifies which apps use the proxy tunnel. In v2rayNG, open “Settings” → “Per-app proxy”, enable the feature, then choose the allowlist or bypass list. Do not confuse the two: the allowlist sends only selected apps through the proxy; the bypass list connects selected apps directly while the rest use the proxy. Disconnect and reconnect after making changes so the new rules load.

1. Confirm system permission

   Accept the VPN connection request on the first connection. Once the system VPN indicator appears in the status bar, test a webpage.

2. Relax battery restrictions

   Go to “Settings” → “Apps” → “v2rayNG” → “App battery usage” and choose the option that allows continued background activity.

3. Enable per-app proxying

   In the client, open “Settings” → “Per-app proxy”, explicitly choose the allowlist or bypass list, then select the target apps.

4. Reconnect

   Stop the current connection and start it again. Test one selected app and one unselected app to verify that the rule direction matches your expectations.

Question 10: Which should I choose: v2rayN, v2rayNG, or v2flyNG?

For desktop, start with v2rayN. It provides subscription groups, system proxy, routing, TUN, and other common features for Windows, macOS, and Linux. On Android, choose according to your core requirements: v2rayNG uses the Xray core and suits common combinations such as VLESS and REALITY; v2flyNG uses the v2fly core and suits users who need the corresponding V2Ray configuration ecosystem.

Whether the same subscription can be fully imported into different clients depends on the protocols and parameters it actually contains, not just the link format. If a node works in one client but is not recognized by another, compare core support and configuration fields first instead of immediately blaming a network problem.

For beginner troubleshooting, follow the same order every time: confirm that the subscription contains nodes, confirm that the core starts, check system proxy or VPN permission, and finally inspect DNS and routing rules. Change only one variable at a time and keep the previous configuration. This makes it possible to identify whether a failure comes from the subscription, node, client, or traffic-capture layer.

• Node list is empty: check the subscription address, update action, and filters.
• Every node times out: check the local network, DNS, system time, and core logs.
• Only one node fails: verify that node's protocol, port, TLS, and transport parameters.
• Shows connected but websites do not load: check the system proxy, VPN permission, and local listening port.
• Some websites fail: check DNS results, rule order, and the outbound that actually matched.
• Android disconnects in the background: adjust battery restrictions and confirm that the client can keep running in the background.