v2rayN: 10 Common Questions About Subscriptions, Cores, and System Proxy

Where subscriptions come from and what to do after importing one

Question 1: Does v2rayN provide subscription URLs?

No. v2rayN is a desktop client for reading configurations, starting the core, and forwarding local traffic; it does not provide servers. A subscription URL must come from the node service provider and usually contains the server address, port, user ID, transport, TLS, SNI, REALITY public key, and other connection parameters.

A subscription URL is an access credential. Do not paste it on public pages, in screenshots, or in chat groups. After receiving one, confirm that it is a complete HTTPS URL rather than a web control-panel address. The control panel manages your account; the subscription URL is the configuration endpoint the client can read periodically.

Question 2: Why is the server list still empty after adding a subscription?

Saving a subscription group only registers the URL; you must still update it. Using the v2rayN 7.15.7 interface as an example, follow the steps below for the first import. Menu labels may vary slightly between 7.x releases, but the three actions remain the same: add a group, update the subscription, and select a node.

1. Add a group

   Open the main window and choose “Subscription groups” → “Subscription group settings” → “Add”, then enter a note and paste the complete subscription URL.

2. Save the URL

   Make sure there are no spaces or line breaks before or after the URL. Save it, then return to the server list; do not import the subscription URL as a single server.

3. Update the subscription

   Choose “Subscription groups” → “Update all subscriptions” and wait for the status bar to show the retrieval and parsing results.

4. Select a node

   Double-click a node in the server list, or use the context menu to set it as the active server, then run a latency test.

5. Enable the proxy

   Choose an appropriate system proxy mode from the tray menu so browsers and other applications that support system proxy settings use the local listening port.

What is a core, and how should you choose between Xray and v2ray?

Question 3: Why is a core needed after installing v2rayN?

v2rayN mainly handles the graphical interface, subscription management, routing, and process control. The Core establishes connections using protocols such as VMess and VLESS. Think of the client interface as the control layer and Xray or v2ray Core as the execution layer: the interface turns the selected node and routing rules into a runtime configuration, then the core listens on local ports and connects to the remote server.

When the core file is missing, outdated, or unable to support the configuration parameters, a common symptom is that Core exits immediately after a node is selected. Do not keep switching system proxy modes; open the logs first and determine whether the issue involves a file path, configuration field, or protocol compatibility.

Question 4: Which should you choose, Xray Core or v2ray Core?

Choose based on the node configuration, not on which name sounds newer. VLESS, XTLS Vision, and REALITY parameters generally require Xray Core; existing VMess, TCP, and WebSocket configurations can use v2ray Core when that matches the provider’s compatibility requirements. If the imported subscription already specifies a compatible core, keep the automatic selection.

If you need to verify the choice manually, open “Settings” → “Parameter settings” → “Core type” and check the core selected for the current protocol. After changing it, stop the old Core and set the active server again to prevent the old process from retaining local ports such as 10808 and 10809.

What is the difference between system proxy and TUN?

Question 5: Why enable the system proxy after selecting a node?

Selecting a node only prepares a local proxy endpoint in Core; it does not make every application use it automatically. System proxy mode points Windows proxy settings to v2rayN’s local HTTP or SOCKS listening port. Browsers and applications that follow system proxy settings can then send requests to Core.

If Core is running normally but the system proxy remains disabled, an application configured directly with 127.0.0.1 and the corresponding port may still connect, while a regular browser may continue to connect directly. During troubleshooting, treat “the core has started” and “application traffic has entered the core” as two separate states.

Question 6: Is TUN mode always better than the system proxy?

No. TUN creates a virtual network interface and receives traffic closer to the network layer, so it can cover applications that ignore system proxy settings and is better suited to UDP or full-traffic interception. In return, it depends more on permissions, virtual adapters, DNS, and routing tables, which makes troubleshooting broader.

• Use the system proxy first to verify that the subscription, node, and core work correctly before enabling TUN.
• Before enabling TUN, exit other networking tools that use virtual adapters or modify system routes to prevent competing default routes.
• When TUN fails to start, check the logs for permission, driver, interface-creation, and route-writing messages instead of checking only whether a webpage opens.
• Before closing v2rayN, restore the system proxy settings or stop TUN so the system does not retain proxy settings pointing to a stopped process.

How to read the tray icon, latency, and connection status

Question 7: Does the tray icon color mean the node is connected?

Color alone cannot confirm remote availability. The tray icon mainly indicates v2rayN’s current runtime state or system proxy mode, and the color mapping may vary by version, theme, and proxy mode. A more reliable check is to open the tray menu and inspect the selected system proxy status, active server name, and whether Core is running.

Even when the icon shows that the proxy is enabled, this only means the system proxy switch has been written; it does not confirm a successful TLS handshake, remote authentication, or outbound access. Conversely, when the system proxy is disabled, a program with a manually entered SOCKS address may still connect through the local port.

Question 8: Does a negative, timed-out, or very high latency result mean the node is unusable?

Different test commands measure different parts of the path. TCP latency mainly checks whether a connection can be established to the target address and port; it does not fully validate the proxy protocol. A real latency test sends traffic through the core and remote node, so it better reflects actual access. Some servers may not respond to a particular probe while still forwarding web requests normally.

When filtering nodes for the first time, run a TCP latency test on all nodes, then run a real latency test on the candidates. Choosing a node that remains stable across repeated tests with a low error rate is more reliable than chasing the lowest single reading. If every node in the same subscription fails at once, check the local clock, DNS, subscription validity, and network environment before changing individual node parameters.

How to troubleshoot connection failures and preserve settings during updates

Question 9: The status says connected, but webpages will not open. What should you check first?

The fastest approach is to follow the traffic path from nearest to farthest: whether the application uses the proxy, whether the local port is listening, whether Core reports an error, whether the node completed its handshake, and whether routing rules incorrectly classify the destination as direct or blocked. Do not change DNS, TUN, the core, and node parameters all at once, or it will be difficult to identify what made a difference.

1. Verify the active node

   Confirm that an active server is selected in the server list, that the node protocol, address, and port are not empty, and that the subscription group has not been disabled.

2. Check the core logs

   Open the log window and look first for keywords such as failed, timeout, handshake, invalid, and address already in use. Record the first error.

3. Check local ports

   Under “Settings” → “Parameter settings”, verify the listening address and port. The system proxy should point to 127.0.0.1 and the current HTTP port.

4. Temporarily use the default route

   Temporarily switch back to the basic routing configuration to rule out custom domain rules, IP rules, or block rules sending traffic through the wrong route.

5. Try another node in the same group

   Test another node from the same subscription. If only one node fails, the problem is more likely related to the remote server or that node’s parameters.

The first error in the log is usually more important than the cascade of errors that follows. For example, a port conflict prevents Core from creating a local entry point, and subsequent connection failures are only consequences. An SNI mismatch, inaccurate system clock, or incorrect REALITY public key will interrupt the handshake. Identify the layer where the error occurs, then change the corresponding configuration.

Question 10: Will updating v2rayN erase subscriptions and custom rules?

Whether settings are preserved depends on the update method and data-directory location. Before replacing the main program, fully exit v2rayN and confirm that both the tray process and Core have stopped, then back up the configuration data in the current program directory. Do not replace files while the program is running; settings may not have been written yet or files may be locked.

After upgrading, check subscription groups, the active server, local ports, core type, and routing rules before starting the proxy. When crossing several major versions, first use the default settings to complete one node connection test, then restore custom DNS, routing, and TUN settings one by one to identify differences between old fields and new-version behavior.

The essential setup sequence for beginners is five steps: obtain a valid subscription, update the server list, choose a compatible core, set an active node, and enable the right traffic entry point. Use the system proxy for the first verification; enable TUN only after the basic path is stable. When problems occur, logs and actual ports are more useful than icon colors.