v2rayN Setup Guide
Import a Subscription and Test Your Connection

1. Import a subscription and refresh the list

First, identify what you received. A subscription is usually a URL that retrieves a list of configurations; use “Update subscription” to refresh its servers. Content beginning with vmess:// or vless:// is typically a single-server share link. Importing it adds one configuration, but does not create an automatically updated subscription. These use different import options, so check how the provider says to use the link before copying it.

v2rayN: Add a subscription group, then update it

Open v2rayN and find “Subscription Group Settings” under the subscription group menu. Add a group, enter a name that helps you identify its source, and paste the full subscription URL into the address field. Check for extra spaces or line breaks at either end, then save. The remark is only a local label; it does not affect connection settings. Don’t put subscription credentials in it.

After saving the group, return to the main window and update it from the subscription menu. Some versions offer both update through proxy and update without proxy. If you don’t have a working connection yet, try updating without a proxy first. If the source requires proxy access, use an existing working connection; a configuration you haven’t imported cannot provide that connection. Check the update result. On success, the group’s servers should appear in the main list.

v2rayNG: Save the subscription URL, then refresh

In v2rayNG, open the side menu and find “Subscription Group Settings.” Use the add option to enter a remark and subscription URL, then save. Return to the main screen and choose “Update subscription” from the menu, or use the refresh option in your version. Saving the URL alone may not create a server list. Make sure the update completes, then check the main screen for configurations you can select.

For a single-server share link, use an option such as “Import from clipboard.” A QR code should also contain configuration data the client can recognize. After importing, check that the protocol, server address, and port are populated. Don’t guess at unknown settings just to move ahead. The provider usually maintains the protocol and transport details in a subscription; seeing an entry in the client doesn’t guarantee its settings are still valid.

Don’t change advanced server fields yet. Next, decide how app traffic reaches the client and which rules apply once it does. If subscription updates keep failing, go to Troubleshooting and follow the steps for subscription failures.

2. Choose a proxy entry point and routing mode

“Proxy mode” can refer to two different things. The first is the traffic entry point: an app hands requests to the client through the system proxy, a local port, or a VPN interface. The second is routing: once the client receives a request, it decides whether to send it directly or through the proxy. Choosing a routing mode doesn’t connect apps on your system to the client, and enabling the system proxy doesn’t mean every app will follow it.

v2rayN: Start with browser access through the system proxy

Find the routing settings in the main window or tray menu. For everyday use, start with a preset such as “Bypass mainland China” that fits your needs. These rules generally send matching destinations in mainland China directly and handle other traffic according to the preset, but the exact behavior depends on the rules and their order. For initial setup, leave the rule files alone. Don’t change DNS, routing, and transport settings at the same time, or it’ll be hard to pinpoint the cause if something fails.

Next, find “System Proxy” and choose “Automatically configure system proxy,” or the equivalent option in your version. This usually points the system proxy to a local port the client is listening on, allowing browsers and other apps that follow the system proxy to use it. Keep the default client ports for now. 10808, often shown in tutorials, is an example of a local SOCKS port; it isn’t a universal port number across versions or entry points. Check the actual settings for the HTTP or mixed port.

An app that ignores the system proxy may still connect directly, even if your browser works. Check the app’s own proxy settings before switching servers. TUN is another way to route traffic through the client and may require extra permissions and network changes. For a first setup, don’t enable it alongside other options; consider it only after you’ve tested a basic connection.

v2rayNG: Use VPN mode and check app coverage

In v2rayNG settings, confirm that the client is using its standard VPN mode. If per-app proxying is enabled, check whether the current mode includes only selected apps or excludes them. Make sure the browser you’re testing is covered; otherwise, it may bypass the client even while the main screen shows a connection. For your first test, leave the app list at its default to reduce variables.

Start with a routing preset that suits your needs here, too. If you temporarily use global proxy mode to compare results, remember that it applies a broader proxy policy only to traffic that reaches the client. It doesn’t prove that all system traffic is being routed through it. Restore your previous rules after testing so you don’t mistake a temporary diagnostic setting for a long-term setup.

3. Select a server and connect

Return to the main list and select a server from the group you just imported. Prefer a configuration the provider recommends for your network. Don’t judge availability by the server name alone, and don’t start by testing the entire list. Selecting a server, starting the local core, and connecting to the remote server are separate stages. A selected state in the interface is only the first step.

v2rayN: Confirm the active server and check core logs

In the server entry’s right-click menu, choose “Set as active server” or a similar option. If your version supports setting the active server by double-clicking, you can do that instead. Check that the active indicator or status bar shows the server you selected. v2rayN usually starts or reloads the core in response. If your version has a start or restart service option, use it once the active server is set, and keep the system proxy setting from the previous step.

Open the log panel and check for recurring local startup errors. If a message says the address is already in use, another process may be occupying the local listening port. First close duplicate client instances or identify the process using the port. Don’t change it to an arbitrary number. If you do need to change a port, update both the client’s listening port and the port set in the system proxy or app; otherwise, requests will still go to the old entry point.

If the logs repeatedly report unsupported configuration fields or the core exits immediately, note the specific error and check that the required core and features match the configuration. Xray and V2Fly are related but distinct core implementations; switching between them isn’t a universal fix. Start with the option that matches the subscription’s requirements, and save deeper compatibility issues for the troubleshooting process.

v2rayNG: Connect and approve the system prompt

On the v2rayNG main screen, select the server you want and tap the Connect button. The first time you connect, the system will usually ask permission to establish a VPN connection. Confirm the app name, then allow it. Once approved, check the button state and system VPN indicator. If the system asks you to disconnect another VPN first, resolve the conflict and try again.

An Android VPN indicator only means that the local VPN service is running; it doesn’t confirm that the remote server is reachable. You can use the client’s connection test as an additional check, but results can vary with the test target and method. If a request times out, keep the error details and avoid changing several settings at once. Confirm the device date and time and that the basic network works, then test access once with the same configuration.

At this point, the client should remain running without obvious local startup errors. Next, test the connection with a real request. A button color, tray icon, or system indicator alone doesn’t prove the setup is working.

4. Test access, routing, and disconnect behavior

Start with a browser that follows the system proxy and has no separate proxy extension. On Android, use a browser included in the VPN’s app coverage. Visit a normal page expected to use the proxy and make sure it loads fully, rather than relying on a title from the browser cache. If useful, compare results in a new private window, but remember that private browsing doesn’t change system proxy rules.

Compare page results with the logs

While browsing, check the client logs for the corresponding request or an error. Log detail varies by version, so the absence of a full domain name doesn’t necessarily mean the request never reached the client. But if the page fails and there’s no related activity, first check the system proxy, the browser’s own settings, or per-app coverage. A clear remote connection timeout points to a different issue: check server reachability instead of repeatedly toggling the system proxy.

Next, visit a commonly used page expected to connect directly and check that it still works as expected. You can only make an initial judgment that the routing is suitable when both proxy and direct-connect destinations behave as expected. To check which rule matched a destination, use the client’s routing logs if available rather than judging by page load speed alone. Caching, page size, and server load all affect performance.

To check your exit IP, you can use a trusted IP information page. A change in the address only shows the exit used for that request; it doesn’t prove that every app or domain uses the proxy, or confirm the DNS path. For initial setup, focus on getting access working. If you need to investigate DNS resolution or leaks, read systematic troubleshooting and check DNS, routing, and app behavior separately.

If it fails, troubleshoot by symptom; change one thing at a time

If no pages load, disconnect and restore the previous network entry point, then check whether the basic network still works. If the failure only happens with the client enabled, return to the local startup and traffic entry point checks. If only one server fails, test another configuration from the same subscription for comparison. If some domains fail while others work, note the domains, errors, and time, then check routing and DNS. Don’t clear all settings at once.

If the browser works but another app doesn’t, first check whether that app follows the system proxy or is excluded by Android’s per-app rules. If the setup stops working after restarting the client, check that the system proxy is enabled again, the active server is still selected, and no new permission prompt has appeared. Change one variable at a time and retest so you can link the result to the change.

Save the working setup and check network access after disconnecting

Once the setup works, record the client, subscription group, active server, routing preset, and any required local ports. To back up the configuration, use the client’s export or backup feature and store the file somewhere secure; it may contain subscription credentials and server authentication details. Don’t upload it publicly. When moving to another device, import it manually and recheck ports, paths, and platform-specific settings rather than assuming everything will work unchanged.

Finish with a disconnect test. In v2rayN, clear the system proxy set by the client before exiting, then make sure the browser connects directly again. In v2rayNG, tap the connection button to disconnect and confirm the system VPN has ended. If internet access still doesn’t work after disconnecting, first check for a manual proxy setting that still points to a local entry point rather than uninstalling the client.