v2rayN Beginner FAQ: 10 Answers on Subscriptions, System Proxy, and Connection Issues

1. What is v2rayN, and what else do you need after downloading it?

v2rayN is a client, not a node service. It manages server configurations, runs a proxy core, and provides system proxy and routing settings. Downloading the client does not provide a working server automatically. You also need a valid subscription or a node share link containing the server address, port, authentication, and transport parameters.

Use v2rayN on desktop systems. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Protocol support depends on the core and its version; the ability to import a subscription does not mean every node is compatible. For VLESS + REALITY in particular, confirm that the client core explicitly supports it.

• Windows: Open Settings → System → About to check your system type, then choose a package for your processor architecture.
• Linux: Run uname -m; x86_64 usually means x64, while aarch64 usually means ARM64. Then choose a package format for your distribution.
• macOS: Open About This Mac to check the chip information and distinguish Apple silicon from an Intel processor.
• First launch: Extract the entire archive before running the main program. Install packages as prompted by the system. Do not drag just one executable out of the archive.

2. How do you import a subscription, and where do you add a share link?

A subscription address usually fetches a group of nodes. Content beginning with vmess:// or vless:// is usually a share link for a single node. These use different entry points. Save subscription addresses in a subscription group and import single-node links from the clipboard. Do not identify a link by its length alone.

1. Copy the subscription

   Copy the complete subscription address from your service provider. Check that it has no quotation marks, spaces, or line breaks at either end. The token in the address is an access credential; do not post it in a public chat.

2. Add a group

   Open Subscription Group → Subscription Group Settings, click the add button, enter a remark and address, then save. A remark such as “Daily use” can make the group easier to identify.

3. Update the nodes

   In the Subscription Group menu, choose Update All Subscriptions (without proxy). If this is your first setup and no proxy is available yet, try fetching the subscription directly.

4. Check the list

   Switch to the group and confirm that server entries appear. If you see the group name but no nodes, the settings were saved, but the subscription has not been fetched or parsed successfully.

For a single-node share link, copy the entire content, then use Server → Import bulk URL from clipboard in the main interface. You can also use the Ctrl + V shortcut shown in the interface. After import, select a node, make it the active server, and configure the application's proxy entry point.

3. Should you keep retrying a failed subscription update or change how it updates?

Read the error first, then decide whether to fetch through a proxy. “Without proxy” means the client requests the subscription address directly. “Through proxy” requires an already working node. If you have no usable node during the initial setup, repeatedly choosing the proxy option usually creates a dependency loop.

A subscription link is an access key. During troubleshooting, note the error code, time, and relevant client logs, but hide the full URL, user identifiers, and authentication fields in screenshots. Do not send your subscription to an unknown online conversion service for testing.

4. How do you select a node and confirm which one is active?

Select a node in the server list, right-click it, and choose Set as active server. Check the active indicator and startup logs to confirm the change. Highlighting a row alone may not switch the active node. After switching, check whether the logs reload the configuration and report authentication, certificate, or transport errors.

• Choose one first: Prefer a node marked available by the provider and supported by the current core. Do not change the core, routing, and DNS settings at the same time.
• Then test latency: The latency test in the right-click menu can help narrow down the choices. A successful TCP connection only confirms that a connection to the port can be established; it does not confirm that authentication or webpage requests will succeed.
• Finally, test access: Make a real request and open the target webpage in a browser. Latency is not download speed, and the lowest figure does not necessarily mean the best experience.

For example, a node with 80 ms TCP latency is still unusable if requests fail authentication. A node with 150 ms latency may be a better choice for troubleshooting if requests complete normally. These figures are illustrative, not measurements from this site.

5. Which system proxy option should you choose, and what is the difference between “Do not change” and “Clear”?

For a first browser test, start with “Automatically configure system proxy.” Right-click the tray icon and open System Proxy to select the option. This points the system proxy to the client's local listening port, but an application will use that entry point only if it reads the system proxy settings.

Support for system proxies varies among Linux desktop environments and applications. Command-line tools often need their own parameters or environment variables. Do not assume every application is routed just because the system proxy is enabled. If the browser has a proxy extension, check whether it overrides the system settings.

6. What local address and port should you enter, and why isn't it the server port?

Applications connect to the local proxy entry point, and the core forwards requests to the remote server. Ports such as 443 on a remote node are for the client-to-server connection; do not enter them as the browser's local proxy port. First check the local listening port under Settings → Parameter Settings. The exact fields vary by version and inbound type.

If the logs show address already in use, the listening address or port is already occupied. Close duplicate client instances first, then check other programs. After changing the local port, update any applications with manually configured proxy settings. Do not expose the listening address on all network interfaces just to connect a local browser.

7. It says connected, but webpages will not open. What should you check, and in what order?

The running status in the interface usually means the local core has started; it does not guarantee connectivity to every website. The application may not be using the proxy, node authentication may have failed, DNS resolution may be failing, or routing may be sending requests through the wrong exit. Check the connection from the local end outward instead of changing ten settings at once.

1. Check the local entry point

   Check the logs to confirm that the local port is listening. If there is a port conflict, configuration parsing error, or core exit, fix that first.

2. Check application routing

   Enable automatic system proxy configuration and temporarily disable browser proxy extensions, or explicitly set a local HTTP or SOCKS5 entry point in the application.

3. Confirm the request arrives

   Refresh the webpage and check the connection logs. If the current log level records access, you should find the request. If there is no entry, first check whether the application is bypassing the proxy.

4. Check the remote response

   For authentication failures, check the subscription and node details first. For timeouts, check the route and server status. For certificate errors, check the system time and server certificate configuration.

5. Test name resolution separately

   If the logs explicitly report a DNS resolution failure, check the DNS settings. Do not attribute every connection timeout to DNS or try to fix connection issues by disabling certificate verification.

If curl is available, you can bypass the system proxy settings and test a specific local entry point directly. The command below assumes a local HTTP or mixed port of 10808 and targets a page on this site. It tests only this request path; it does not confirm that every service is working.

curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2raywrt.com/

If the command succeeds but the browser fails, check the browser's own proxy settings, extensions, and cached connections first. If it cannot connect to the local port, check the listening address and core status. If the local connection succeeds but the remote request times out, compare it with another confirmed working node.

8. Should you use global routing or split routing, and what if sites in mainland China slow down?

For everyday use, start with a split-routing preset provided by the client. The system proxy determines how an application hands requests to the client; routing rules determine whether the client sends those requests through a proxy, directly, or blocks them. These are separate steps: enabling the system proxy does not mean every destination will use a remote node.

• Sites in mainland China are slow: Check whether the current routing preset sends those domains through the proxy. Restore a split-routing preset suited to your local network, then test again.
• Only one site fails: Check its domain rules, rule order, and the exit actually selected. Do not immediately reset all settings.
• Temporary global test: You can briefly choose a routing mode that sends the traffic under test through the proxy. Restore the previous preset afterward so a temporary diagnostic setting does not become your permanent configuration.
• Rule database error: If the logs report missing GeoIP or GeoSite data, check the rule files and their update status. Changing the node protocol alone will not help.

DNS and domain identification can also affect split-routing results. Keep the node and destination the same, change one routing option at a time, and reconnect after each change. Existing browser connections may temporarily keep using their previous exit, making it seem as though a setting did not take effect.

9. When do you need TUN, and why might enabling it cut off your connection?

TUN routes traffic through a virtual network interface. It is useful for applications that do not read system proxy settings and cannot easily be configured individually. It is not a speed boost and cannot fix an unavailable node. Confirm the node works in regular system proxy mode first, then introduce TUN to keep troubleshooting variables to a minimum.

• Before enabling it: Note your current system proxy and routing settings, close other network tools that modify the default route, and confirm that the system allows a virtual network interface to be created.
• Permissions: Grant permissions as prompted by the client and system. Do not give unrelated programs elevated permissions just for convenience.
• After enabling it: Test webpages, applications that previously ignored the system proxy, and local network services separately. A working webpage does not guarantee that UDP or local network access will work.
• If the connection drops: Disable TUN first and confirm that the basic network connection returns. Then check the virtual interface, DNS interception, and routing conflicts. Do not change the subscription, core, and all DNS settings at once.

10. How do you restore internet access after closing v2rayN and keep useful troubleshooting details?

A common cause is that the system still points to the local proxy after the client has exited and stopped listening on its local port. Reopen v2rayN, choose Clear system proxy under System Proxy, and then exit normally. Choose “Clear,” not “Do not change.” If TUN was enabled, disable it first and wait for the network to recover.

1. Check the system proxy: On Windows, go to Settings → Network & Internet → Proxy and check for a leftover manual proxy or setup script. Do not change settings on a device managed by workplace policy without authorization.
2. Check application settings: Browser extensions, terminal environment variables, and proxy addresses such as 127.0.0.1 entered directly in applications are not necessarily cleared with the system proxy. Restore them separately.
3. Reconnect: Restart affected applications and test direct access. If the problem persists, check the network connection, system DNS, and virtual interface status.
4. Keep useful details: Record the operating system, client version, core type, time of the error, and a short relevant log excerpt. Hide subscription tokens, user identifiers, and server authentication details.

Next time, check in this order: local network → core listener → application proxy → node connection → routing and DNS. Change one condition at a time and record the results before and after. This helps distinguish a client configuration issue from a server problem or an application-specific proxy setup.