v2rayN Subscription Import and Connection Guide

Check the client and subscription URL before starting

Before you begin, prepare an installed client and a valid subscription URL. Use v2rayN on desktop and v2rayNG on Android. A subscription URL is usually a complete link beginning with https://; it is not an individual VMess, VLESS, or Trojan configuration, nor a web account login URL. When copying it, preserve every character from start to finish and avoid missing query parameters, adding spaces, or introducing line breaks.

If the client is not installed yet, visit the download center and choose the right platform. Open the client after installation, but do not start changing DNS, TUN, port, or custom routing settings. The initial goal is to establish a basic connection that can be verified. Changing too many settings at once makes it difficult to tell whether a problem comes from the subscription, server, proxy mode, or local network.

Also check that the device date, time, and time zone are correct. Some protocols use time information during the connection process, and a large clock difference can prevent the handshake even when the configuration appears complete. Enable automatic time synchronization, then confirm that the current network can access ordinary websites. If the basic network is already offline, the client cannot replace the local network connection.

Import the subscription and build the server list

In v2rayN for desktop, open the menu for subscription groups and choose the option to add or manage a group. When creating one, enter an easy-to-recognize note such as “Daily subscription,” then paste the complete subscription URL into the address field. Save it, return to the main window, and run “Update all subscriptions” or update the current group. The client will read the subscription and organize its server configurations in the main list.

After the update, the main window should show several selectable server entries. Common columns include alias, address, port, protocol, and subscription group. Seeing a list only means that the subscription was parsed; it does not mean every server can connect. First confirm that the entries belong to the group you just created and that the protocol and address columns are populated. If the group is saved but no entries appear, reopen its settings, check the beginning, end, and middle of the URL for spaces, and run a manual update.

In v2rayNG for Android, open the top-right menu, go to subscription group settings or subscription settings, and tap the add button. Enter a note and subscription URL, save them, return to the main screen, and choose Update subscription from the menu. Keep the network connection active during the update. When it finishes, the main screen should show the server configurations. Tap the group name at the top to confirm which subscription group is displayed; the update may have succeeded while the app remained on a different group.

If the subscription update fails, do not immediately keep changing protocol parameters. Copy the URL into a browser address bar again and confirm that it is still complete, but do not save the opened content as a plain text file and import that instead. Then check the system time, current network, and subscription service status. If the runtime log shows a parse error, request timeout, or empty response, fix the subscription retrieval issue first. Server parameters are worth checking only after the subscription successfully produces a list.

Once the list appears, do not import several subscriptions at the same time. Keeping one group makes it easier to identify the source of the active server and rule out duplicate configurations or same-named entries when a connection fails. Subscription updates, server latency tests, and actual connections are three separate actions: updating retrieves configurations, latency testing attempts a test connection, and the actual connection is determined jointly by the active server and proxy mode.

Choose system proxy, routing rules, or TUN mode

Once the subscription list is ready, decide which application traffic the client should handle. For first-time use, start with the system proxy. It changes the proxy settings provided by the operating system, so browsers and desktop apps that follow system settings will generally use it automatically. Its scope is clear and easy to undo, making it suitable for verifying whether the subscription and server work at all.

In v2rayN for desktop, find the system proxy menu and choose automatic system proxy configuration or enable the system proxy. Wording may vary slightly by version, but the status bar or tray menu should clearly show when it is enabled. Then check the routing mode. For an initial setup, use a rule-based mode that bypasses the local network and common direct addresses; avoid writing many domain rules from the start. Rules are matched from top to bottom. Once a request matches a direct rule, it will not continue through the proxy outbound.

If an application does not read system proxy settings, or you need to handle a broader range of network requests, consider TUN mode after the basic connection has been verified. TUN creates a virtual network interface and sends a wider range of traffic to the client, so system permission is usually required. If the system asks for permission, verify that the request comes from the current client before continuing. TUN and the system proxy are not better when combined indiscriminately; during initial troubleshooting, enable only one primary interception method to reduce port conflicts, duplicate forwarding, and layered routing.

In v2rayNG for Android, tap the connection button on the main screen and the system will show an authorization prompt for establishing a network connection. Confirm it so the client can receive application traffic that needs handling. Per-app proxying, LAN bypass, and routing rules provide more granular control; for the first connection, keep the default rules. After web access and logs look normal, decide whether only selected apps should use the connection.

The proxy mode determines whether traffic enters the client; routing rules determine whether traffic that enters is sent direct, through the proxy, or blocked. They are not the same thing. If the client is running but browser requests do not appear in the log, check the system proxy or connection authorization first. If requests appear in the log but the destination cannot be reached, then check the server, DNS, and routing outbound. See the full documentation for rule priority, domain matching, and TUN configuration; this guide keeps only the settings needed for a first connection.

Choose the active server and connect

After choosing a proxy mode, return to the server list and select a server. In v2rayN for desktop, double-click the target entry or use its context menu to set it as the active server. Once selected, its name should usually appear in the status bar, tray notification, or list marker. Highlighting a row with a single click does not always switch the active server, so check whether the status area changes as well.

When there are many servers, use a real-connection latency test to narrow the choices. It attempts an actual connection using each server’s configuration, making it more representative of real use than a network-layer response alone. After testing, prioritize entries that return a result and remain stable; there is no need to chase the lowest number repeatedly. Revisit failed servers later, and avoid selecting several servers or switching rapidly because logs may combine records from different servers while the previous connection is still closing.

In v2rayNG for Android, tap a configuration in the list to select it, then tap the connection button at the bottom. The first connection requests system authorization. After you confirm, a connection icon appears in the status bar and the button changes to a connected state. If the button quickly returns to disconnected, open the log immediately instead of tapping repeatedly. Common causes include an unreachable server, mismatched parameters, failed domain resolution, and an incorrect system clock.

When a connection is established, the client reads the current server parameters and starts a local listener. In v2rayN for desktop, also ensure that the system proxy points to the local port actually used by the client. The client normally configures this automatically, so you do not need to edit the browser port manually. If other network tools are installed, temporarily disable their system proxy and virtual network features to prevent multiple programs from competing for settings or overwriting the system proxy.

If every server in the list fails the real-connection test, switch back to an ordinary network environment and try again, then update the subscription manually. A single failed server usually calls for trying another server; simultaneous failure across all servers in one subscription calls for checking subscription expiry, device time, DNS, and client version. See the terminology guide for basic explanations of log terms such as timeout, rejected, and handshake failure.

Verify that the connection works through status, access, and logs

A client showing “Connected” only indicates that the local service or system connection has started; it does not by itself prove that target traffic is passing through the selected server. Verify it in three layers: check the client status, send a new request from the browser, and then watch the runtime log for the corresponding record. Only when all three results agree can you confirm that the proxy mode, routing rules, and server connection are working.

The first layer is a status check. In v2rayN for desktop, the active server name should remain visible and the system proxy status should match the mode you selected. In v2rayNG for Android, the connection should remain active and the connection indicator in the system status bar should not disappear immediately. If the status keeps switching between connecting and disconnected, check the log first instead of testing websites; the basic connection is not stable yet.

The second layer is browser access. Fully close existing test tabs, then open a new browser window and visit a website that normally works to confirm that the local network is still available. Next, visit the target page that should be handled by the current proxy rules. A new window reduces interference from old connections, caches, and extensions. If one browser works while another does not, the issue is usually that browser’s own proxy, extensions, or security settings; do not replace the subscription immediately.

The third layer is the runtime log. While making a web request, return to the client’s log page and check for a new connection record. A target domain, routing match, or outbound connection record shows that the request entered the client. If no new record appears at all, check the system proxy, the browser’s independent proxy settings, or connection authorization in v2rayNG first. If the request appears but then times out, check the current server, DNS, or target route. If the log assigns the request to a direct outbound, confirm that the current rules match your expectations.

You can also disable the system proxy or disconnect v2rayNG, then revisit the same page for comparison. The status change should match the access result, and reconnecting should produce new log records again. A comparison test is more reliable than checking only whether a page opens, because some pages may be cached and some domains may be routed directly by design.

Command-line terminals are a separate case. Many terminal tools do not automatically read the desktop system proxy, so terminal requests may still go direct even when the browser works. This does not mean the v2rayN connection has failed. To use a proxy in a terminal, configure the tool’s own proxy parameters; do not enable full traffic interception just to make one command work. See the full documentation for the complete terminal, DNS, and routing troubleshooting process.

The correct order for daily updates, switching, and disconnecting

After the first verification, daily use usually involves only updating the subscription, switching the active server, and turning the connection on or off. There is no need to add the subscription again every time the client starts; keep the existing group and update it. If the current server was removed after an update, choose a new active server. If it is still present, keep it selected for now, confirm the connection works, and then decide whether to switch.

When switching servers, select the new active server in the list first, then check the status bar and log to confirm that the new configuration is being used. Do not delete the entire subscription group to switch servers, and do not repeatedly import the same URL. The group manages the configuration source, while the active server controls the current connection. Understanding the distinction prevents duplicate entries, confusing notes, and difficulty finding the current server after an update.

When you are not using the client temporarily, v2rayN for desktop should first disable the system proxy or exit connection mode, then close the program. This prevents the operating system from retaining an invalid local proxy address. In v2rayNG for Android, tap the disconnect button and confirm that the connection has ended before closing the app. The next time, start the client, confirm the active server, and then enable the system proxy or connection; there is no need to repeat all four steps.

When a connection suddenly stops working, the fastest approach is to check this guide in reverse order: review the log and connection status, confirm the active server, check the proxy mode, and finally update the subscription. This quickly distinguishes a changed server from traffic that never entered the client or a subscription that cannot be read. For custom routing, DNS, TUN details, or platform differences, continue with the full documentation.