v2rayN and v2rayNG
Subscription and connection guide

Step 1: Import a subscription and update the server list

A subscription URL and a single-server share link are different. A subscription URL retrieves a set of configurations that you can update later; a share link usually imports just one server. This guide starts with a subscription URL. Use the copy button on your provider's page to avoid including surrounding instructions, line breaks, or spaces. If the page offers formats for different clients, choose the one for your client. Don't copy the account dashboard URL.

v2rayN: Add a subscription group, then update it

Open v2rayN and choose “Subscription Group” from the top menu, then open “Subscription Group Settings.” Add a group and enter a recognizable source name in the remarks field. Paste the full link into the subscription URL field. For your first setup, leave filters, update intervals, and conversion options at their defaults. Save and close the settings window. The group name is for local organization only; you don't need to enter your account password.

Return to the main screen, open the “Subscription Group” menu, and choose to update the current group or all subscriptions. Some versions offer separate options to update through or without a proxy. If you don't have a working connection yet, try updating without a proxy so the request doesn't depend on a server you haven't set up. If your current network can't access the subscription, and you already have a working connection, try updating through the proxy. Watch for status messages and wait for the server list to refresh; don't click repeatedly.

v2rayNG: Save the subscription source, then refresh the group

On the v2rayNG main screen, open the top-right menu and choose “Subscription Group Settings.” Tap the add button to create a group, enter a label, paste the subscription URL, and save. Return to the main screen and choose “Update Subscription” from the menu. If multiple groups are shown, select the one you just created to view its entries. “Import from clipboard” under the top-right plus button is generally for importing one or more shared configurations. A success message there doesn't necessarily mean you've saved a subscription source that can be updated later.

After the update, both clients should show selectable entries in the server list. Check that the names and number of entries match your provider's instructions, then select one as the current server. A populated list only means the configuration was read; it doesn't confirm that the connection works. Protocol settings, service status, and your local network still need to be checked. If the list is empty, check that you're viewing the right group, that no name filter is set, and that the update message didn't report an unrecognized format.

By the end of this step, you should have a saved subscription group, an updated server list, and a selected server. Next, decide how traffic enters the client and which connections should use the proxy.

Step 2: Choose how traffic enters the client and select a routing mode

“Enable proxy” and “Global” aren't the same setting. Traffic handling determines whether browser or app requests reach the client; routing determines whether requests go direct or through the proxy once they arrive. A common first-time setup issue is changing the routing mode without enabling the system proxy, or enabling multiple traffic-handling methods at once, which makes results harder to interpret. Use one method at a time: test your browser first, then consider other apps.

v2rayN: Start with the system proxy and rule-based routing

Find “System Proxy” at the bottom of the v2rayN main screen or in the tray menu, then choose the option to configure the system proxy automatically. The exact label may vary by version. After you enable it, the status bar should indicate that the system proxy is set, not show the state associated with “Clear System Proxy.” Most browsers that follow system proxy settings will use the local proxy port, though some apps have their own network settings that you'll need to check separately.

Next, find the routing options and choose a built-in rule-based preset for your first setup. If the interface offers presets such as “Bypass LAN” or “Bypass mainland China,” read the description to make sure it suits your needs. Rule-based routing selects an outbound route by domain, address, or other criteria; it doesn't send every request through the proxy. For now, don't edit custom rules or enable TUN. Once the default route works, learn about rule order and matching in the routing section of the advanced configuration guide.

v2rayNG: Keep the default app coverage and check the routing preset

v2rayNG usually handles traffic through Android's VPN interface after you start it, so you don't need to look for a desktop-style “System Proxy” switch. First, check the routing options in the menu or settings and use a built-in preset suited to your needs. If you've enabled per-app proxying, make sure your test browser is included. If you're unsure, restore the default app coverage to avoid mistaking an excluded browser for an unavailable server.

The VPN interface is how the system lets the client handle network traffic; it doesn't mean every connection will go through a remote server. Routing rules and per-app coverage still determine where traffic goes. If another network tool on your device uses the same type of interface, stop that connection before starting v2rayNG. Otherwise, the apps may replace each other's VPN connection or prevent it from starting.

Once you've chosen your settings, note the traffic-handling method and routing preset. If you need to troubleshoot later, keep both unchanged and test one other server at a time. This makes the results easier to interpret than changing several settings at once.

Step 3: Start the connection and check its status

Return to the server list and make sure the server you want is selected or active. A single click that highlights a row may only select it for an action, rather than make it the current server. Look for a “Set as active server” option in the right-click menu, or check whether the interface clearly shows the current server name. On mobile, tapping an entry usually switches configurations. Selection indicators vary by version, so follow what the current interface shows.

v2rayN: Check the core and system proxy status

After you set an active server, v2rayN usually starts or reloads the core. If the interface offers a restart service option, use it after changing the configuration, then check the log area at the bottom. Confirm both that the core is still running and that the system proxy remains configured. An open window only means the graphical interface is running. If the logs keep showing errors or the core repeatedly exits, the browser won't be able to connect through it.

If your system shows a network access or firewall prompt, verify the program name and location, make sure it's a component of the client you just installed, and respond according to your device's management requirements. Don't disable the firewall entirely just to test a connection. If the logs report that a local port is in use, close other proxy programs and restart the client. If there's still a conflict, check the local listening port in settings. After changing the port, update the system proxy to use the new one too; changing only one setting won't work.

v2rayNG: Approve the connection request and keep the service running

After selecting a server in v2rayNG, tap the start button on the screen. The first time you start it, Android will ask to approve a VPN connection. Check the app name and allow the connection. A connection indicator may appear in the system status area, and the in-app button may change to “Stop.” These indicate that traffic handling has started, but don't by themselves prove the remote connection works. If you don't see the expected status, check the app for a permission prompt or see whether another similar service has replaced it.

After starting the service, leave the app running and make a real request in a test browser. Then return to the logs and check the result. Some connections start only when a request comes in, so seeing few log entries immediately after startup isn't necessarily a problem. Don't rush to change background restrictions during testing. If the connection stops only after you lock the screen or switch apps, check battery management and background permissions, and allow the client to keep running if needed.

Test results in the server list are only a guide. Latency tests and real web browsing may use different destinations and connection methods. A successful test doesn't mean every site will work, and a failed test doesn't prove the whole configuration is broken. First check whether a real request appears in the logs, whether there's a clear error, and whether results change when you try another server from the same subscription.

Once the client stays running, traffic handling is active, and startup errors aren't recurring, move on to the final step. Don't change protocols or DNS settings at the same time. First verify the current setup to establish a clear baseline.

Step 4: Verify that requests use the expected proxy route

Verification should answer two questions: Does the page load, and did the request use the expected outbound route? Seeing the client marked as running, or opening a page that can already connect directly, isn't enough to prove the proxy is working. Test the same pages in the same browser, and don't switch networks midway; otherwise, network and configuration changes can be hard to tell apart.

Visit a page, then use the logs to check the outbound route

First, open an HTTPS page you can normally access to make sure your basic network connection is unaffected. Then open an HTTPS page that should use the proxy under your current rules. Wait for it to finish loading rather than relying on a title from the browser cache. If you've opened the test page before, try a new browser window or refresh it. Don't sign in to important accounts for testing when the subscription source is unknown.

Return to the client and check the logs for the request you just made. If the current log level records connection targets and outbound routes, compare the request time, destination domain, and direct or proxy indicators to see whether routing matches expectations. Log formats vary by core, so don't expect identical wording. If no request appears, the log level may not include it. Check the log settings, then confirm the browser uses the system proxy and hasn't been excluded by per-app settings.

Use one controlled switch to tell a routing issue from a connection issue

If everyday pages load but a page expected to use the proxy doesn't, keep the current server selected and temporarily switch to global proxy routing. Then try the same page again. If it loads, focus on the original rules and outbound selection. If it still fails, check the server, network connectivity, or protocol settings. Restore rule-based routing after the comparison; don't leave a temporary test setting in place as your everyday configuration.

If the client logs never show requests from your test browser, check how traffic reaches the client before switching servers. On desktop, confirm that the system proxy is still set and that the browser's own proxy settings haven't overridden it. On Android, make sure the browser isn't excluded from per-app proxying and that v2rayNG still owns the system VPN connection. If the browser works but another app doesn't, check that app's proxy support and traffic coverage; don't assume the subscription has expired.

When testing is done, confirm your network returns to normal

When verification is complete, stop the service and check that your network recovers. On desktop, clear the system proxy in v2rayN before exiting or stopping the service, so the system doesn't keep pointing to a stopped local port. On Android, tap Stop in v2rayNG and confirm that the system connection ends. If you enabled Android's always-on VPN or the option to block connections without a VPN, check that those settings suit your needs; otherwise, network access may fail after you stop the client.

Restart the client, select the same server, restore the traffic-handling method and routing mode you verified, and revisit the test page. If the result is consistent, your initial setup is complete. Note the working group name, server name, traffic-handling method, and routing preset rather than saving screenshots that contain credentials. If a problem appears after a subscription update, compare these settings to tell whether the server entry or a local option changed.

For everyday use, repeat four steps: update the subscription, select a server, start the service, and confirm access. Set the subscription update frequency as your provider recommends; you don't need to refresh it before every connection. For a specific error, check the Help Center. To manage multiple sources, adjust rule order, or expand traffic coverage, see the advanced configuration guide. Keep a configuration you can roll back to, and change one setting at a time to make issues easier to diagnose.