v2rayN Setup Guide: From Subscription to Connection Test

STEP 01 / SUBSCRIPTION

Add a Subscription: Create a Group and Update the List

Before adding a subscription, copy the full subscription URL from your provider's account page. A subscription is a link the client can read—not a login URL or a webpage for an account dashboard. Keep any query parameters intact, and check that no spaces or line breaks were added at either end. The URL may contain account identifiers, so paste it only into the subscription settings in your local client. Don't share it in screenshots, online conversion tools, or support posts.

Open v2rayN and find “Subscription Group Settings” in the top menu or relevant feature menu. Add a group, give it a recognizable name such as “Everyday,” and paste the subscription URL into the address field. For your first setup, leave other options at their defaults. If there's an enable toggle, make sure the group is enabled. Save and return to the main screen, then check that the group name appears in the group selector. Saving the URL alone doesn't populate the server list; you still need to run an update.

Choose “Update Subscription” from the subscription menu, and check whether the action applies to the current group or all groups. If you haven't connected yet, start with an update that doesn't use a proxy. Watch the status area or log window: when the update finishes, select the new group and check that the list shows server entries with names, addresses, or protocol details. If the list is still empty, clear any search filters and confirm that the correct group is selected. Then check the logs to see whether the download failed or the content couldn't be parsed. Recreating the same group won't fix either issue.

In v2rayNG, the relevant option is usually “Subscription Group Settings” in the sidebar. Tap Add, enter a label and subscription URL, then save. Return to the main screen and run Update Subscription from the menu. Confirm that the right group is selected and that the list contains server entries. If you already have another working connection and the subscription URL can't be reached on your current network, you can try updating through that connection. “Update through proxy” requires an existing working route; it can't create a first connection that doesn't exist yet.

A single share link and a subscription URL serve different purposes: the former usually imports one server configuration, while the latter retrieves and updates multiple entries in a group. If your provider gives you a single link, use the client's clipboard import option instead of pasting it into the subscription URL field. If an update fails with a certificate or parsing error, note the error keywords and check the Help Center. For definitions, see the subscription and server entries in the Glossary.

Step complete: The group is saved, and the updated list contains server entries. This only confirms that you have configuration data; it doesn't prove the remote server is reachable. Next, choose how app traffic will enter the client.

STEP 02 / TRAFFIC PATH

Choose a Proxy Mode: Separate Entry Points from Routing

Proxy mode settings have two layers. The first is the traffic entry point: whether apps send requests to the client's local listening port or are routed through a virtual network interface. The second is core routing: once traffic enters the client, should it connect directly, go through a proxy, or be blocked? In v2rayN, the system proxy and routing mode are separate settings. Enabling the system proxy doesn't automatically enable global routing; choosing global routing also doesn't make every app use the proxy if it doesn't follow system proxy settings.

For an initial desktop connection, start with the system proxy and avoid enabling additional traffic capture methods such as TUN at the same time. Find the system proxy option in the main window's status area or tray menu, and note the difference between “Set System Proxy” and “Clear System Proxy.” The first points the system proxy to the local client; the second removes that setting. Consider enabling it after confirming in the next step that the core starts properly. Otherwise, your browser may start sending traffic to a local port before the core is running, temporarily cutting off access.

Next, find the routing mode setting. To simplify initial troubleshooting, temporarily choose the global routing option offered by the interface, so test requests that reach the core use the proxy outbound. After verifying the connection, switch to a split-routing setup that suits your everyday use. If you choose a preset such as “Bypass mainland China,” remember that it matches destination domains or IP addresses using rules and resource files; check that the required resources are loaded. If a site unexpectedly connects directly, check which rule matches before toggling the system proxy.

v2rayNG usually captures app traffic through VPN mode, with routing options in Settings. If per-app proxying is enabled, make sure the browser you're testing is actually included. Depending on the option, selected apps may be the ones proxied or the ones bypassed, so read the interface description before selecting apps. For the first test, keep the capture scope simple. Avoid changing custom routing, DNS, and several experimental settings at once, or it will be hard to tell what caused an unexpected result.

Don't enable the system proxy and VPN capture together as a troubleshooting fix. They are different traffic entry methods; whether you need both depends on a specific configuration goal. This guide starts with one entry method and keeps the default listening settings. If you need to handle apps that don't follow system proxy settings, read the routing section of the JSON Configuration Guide and use the Glossary to understand the relevant fields.

Step complete: You've chosen a traffic entry method, know whether routing is global or split, and confirmed whether the test app will be captured. Next, select an outbound server and start the core.

STEP 03 / CONNECTION

Connect: Select a Server and Check Core Logs

Return to the v2rayN server list and choose an entry from a known source with an active account. You can run the client's connection test to narrow down candidates, but don't treat a test result alone as proof that the configuration works. A TCP test generally checks whether it can reach the destination port; it doesn't replace a protocol handshake or an actual web request. Select one entry before testing so that server changes during page loads don't make it hard to match requests to logs.

Right-click the entry and choose “Set as Active Server” or the equivalent option; some versions also let you double-click it. Confirm that the active marker or status area points to that entry, rather than relying on the highlighted row alone. A selected row and the active server aren't necessarily the same thing. v2rayN usually starts or reloads the core according to its current settings. If the interface asks you to restart the service manually, use the option provided by your version once; there's no need to repeatedly close the whole app.

Open the status area or log window and check for core exits, configuration parsing failures, or listening errors. If a local address is already in use, first close other proxy apps that might be using the same listening port, or change the port in the client settings and update any apps that depend on it. Don't change only the browser's port while leaving the client unchanged, and don't terminate system processes you can't identify. For detailed steps, see Troubleshooting a Local Port Conflict.

After confirming that the core starts without errors, use the “Set System Proxy” option you identified in the previous step. Check the status area for the selected mode, then keep the client running. Minimizing to the tray isn't the same as exiting the app. If closing the window's behavior is configurable, minimize it during the first test so the local proxy entry doesn't remain active after the client exits. If your desktop environment doesn't offer a system proxy option, follow the client documentation to configure a manual proxy explicitly; don't guess the local port.

In v2rayNG, select the desired server and confirm it's active, then tap Start. The first time you connect, Android asks for permission to set up a VPN connection; review and approve the prompt. Importing a server doesn't capture app requests unless VPN access is granted. After connecting, check the in-app logs and the system VPN indicator. If another VPN app is running, decide which app should handle traffic to avoid having one connection replace the other. The system indicator confirms that local traffic capture is active; it doesn't prove that traffic was forwarded successfully to the remote server.

Step complete: The active server is selected, the core has no obvious startup errors, and the system proxy or VPN capture is enabled. The connection button and status indicator only show the client-side state. Next, test the full traffic path with an app request.

STEP 04 / VERIFICATION

Verify Traffic: Compare Browser Requests with Logs

Open a browser that follows system proxy settings on desktop, or one covered by the VPN on Android, and visit a known-working HTTPS page. Make a new request rather than relying on an already-open tab: the page may be cached, or an existing connection may be reused. If the browser has its own proxy extension, first check that it isn't overriding system settings. Apps with built-in proxy settings need to be checked separately as well.

Watch the client logs while the request is in progress. The default log level may not record every request, so no new log entry by itself doesn't prove that traffic bypassed the client. But connection, parsing, or handshake errors can help you narrow down the cause. If you need more detail, temporarily increase the log level and repeat the request, then restore your usual level. Before sharing logs, remove subscription URLs, server details, and personal browsing data.

If practical, run a reversible comparison: on desktop, clear the system proxy and visit the same destination, then set the system proxy again and make a new request. On Android, stop the connection, test, then reconnect and test again. This comparison can show whether the entry method changed, but if the site loads in both states, that doesn't automatically mean something is wrong—it may be directly reachable. Consider the routing mode, request logs, and server availability together. A changed exit IP isn't required in every split-routing setup.

If the browser can't access sites after connecting, check in this order: confirm the core is still running, verify that the system proxy points to the current listening port, check the active server and account status, then inspect routing and DNS. If only one app fails, first check whether it follows system proxy settings or is excluded by per-app rules. If all apps fail, focus on startup logs and remote connection errors. Change one setting at a time, repeat the same test, and record the result. Changing servers, ports, and routing all at once can erase useful clues.

After verification, switch from temporary global routing to your preferred everyday split-routing setup, then repeat the test request. You can configure automatic subscription updates later: first make sure manual updates work reliably, then choose a reasonable interval based on your provider's guidance. Updates may remove old servers or change their configurations, so check that the active entry is still available afterward. While setting up your first connection, avoid adding custom DNS, complex routing, and scheduled tasks all at once.

When you're done, clear the system proxy in v2rayN before fully exiting. If websites stop loading afterward, check whether the system still has a proxy setting pointing to the local client. In v2rayNG, tap Stop in the app and confirm that the system VPN connection has ended. Next time, reuse the saved group and configuration; there's no need to import everything again. To restore a connection you've already tested, start by checking the active server and connection status.

Step complete: The test app can access the web as expected, the traffic entry method matches the routing mode, and stopping and restoring the connection produce predictable results. For individual issues, see the Help Center. To understand how inbounds, outbounds, routing, and dns work together, see the JSON Configuration Reference—there's no need to edit individual fields when getting started.