Import a v2rayN subscription
and test your connection

Before you begin: client and subscription URL

Have the client installed and a valid subscription URL you’re authorized to use. The client reads configuration, runs the core, and forwards traffic; it does not provide remote servers. If you haven’t installed a client yet, go to the download center, choose the package for your device, install it, and open the main window. Then return here to continue.

Use a subscription URL from a configuration source you trust. It is usually a long link. When copying it, don’t include any instructions, quotation marks, or line breaks, and don’t share it in public screenshots or chat messages—it may contain access credentials. If you only have a single server share link, use the client’s import-from-clipboard feature instead of entering it as a subscription URL.

For your first setup, keep only one proxy client in charge of traffic. Temporarily disable system proxy or virtual network adapter handling in any other clients. Note your current proxy settings, check that the device date, time, and time zone are correct, and make sure your regular network connection works. This helps avoid confusion from port conflicts, overlapping proxies, or certificate errors caused by an incorrect clock. Start by importing the subscription; don’t enable TUN yet.

Step 1: Import a subscription and update the list

Add a subscription group

In the v2rayN main window, open “Subscription Group” and select “Subscription Group Settings,” then add a group. Enter a recognizable name in “Alias,” such as “Daily use,” and paste the full subscription URL into “Optional address (url).” The alias is for local organization and does not change the server configuration. Check for spaces at either end of the URL, and make sure you haven’t entered a webpage or subscription management page by mistake. Then save the settings.

If the interface has an “Enable updates” option, select it if this group should be included in subscription updates. For the initial setup, run one manual update to confirm the URL works before setting an “Automatic update interval (minutes).” How zero values and update tasks are handled can vary by version, so don’t assume automatic updates are disabled just because you entered a particular number. Check the interface and update history. Frequent updates aren’t necessary at first; the priority is to retrieve the configuration reliably.

Update the current group and check the results

Return to the main window and choose Update current group from the “Subscription Group” menu. If there are separate options for a regular update and an update through the proxy, choose based on your current network. If you don’t have a working proxy yet, try a regular update first. When it finishes, switch to the group you just created and check for server entries in the list. Seeing the group name alone doesn’t mean the import succeeded: confirm that configuration entries were added and that there are no subscription parsing or request timeout errors.

If the update fails, first check that the URL is still valid, the device clock is correct, and the address hasn’t been truncated. Then check whether the logs show a request failure or a parsing error. Being able to open a subscription management page in a browser doesn’t mean the client can access the actual subscription endpoint. Updating through a proxy also requires an existing, working proxy connection. Don’t keep switching this option before the first connection works. For specific errors, see Troubleshooting.

In v2rayNG, open “Subscription Group Settings” from the menu, use the add option to enter a name and subscription URL, and save. Return to the main screen and update the subscription. In some versions, the update option is under the overflow menu. Confirm success by checking for server entries in the list, not just by checking that the subscription was saved. An update may rebuild entries based on the subscription contents, so consider whether your manual changes will be overwritten next time before editing subscription-generated entries.

For now, just confirm that the list contains entries you can select. There’s no need to edit individual protocol, transport, or security settings. Those fields should already be supplied by the subscription, and changing them at random can break the configuration. Keep the group you just imported and move on to deciding how app traffic reaches the client.

Step 2: Choose a proxy mode and routing

Test your browser with the system proxy first

In the v2rayN status area or tray menu, find “System Proxy” and select “Set system proxy automatically” for your initial test. This points the system proxy to the client’s local listening endpoint, giving apps that honor system proxy settings a way to send requests through the client. It does not connect to a remote server, and not every app follows this setting. Browser extensions, apps with their own proxy settings, or existing management policies may override the system setting.

The other common options are “Clear system proxy” and “Do not change system proxy.” The first removes the system proxy settings; the second leaves existing settings untouched. “Do not change” does not mean “disable proxy.” If another tool set a proxy earlier, its values may remain in place. For the initial setup, explicitly choose the mode you need rather than relying only on whether the menu shows a check mark.

Then choose where routed traffic goes

Next, open the “Routing” menu and try a preset such as “Bypass mainland China (Whitelist).” This type of preset generally sends traffic matching rules for mainland China directly, while routing other traffic through the proxy. The result depends on the active rules and rule data, so don’t assume every request will behave as the preset name suggests. Confirm the route for a specific destination using the connection records in the final step.

The system proxy and routing settings each handle a different stage: the system proxy determines whether an app sends a request to the client, and routing determines which outbound connection the client uses. Setting routing to “Global” does not mean every app is using the client. Automatically configuring the system proxy does not mean every domain will go through the proxy. For the first test, use a straightforward combination and leave custom rules alone. Changing both the entry point and exit route at once makes problems harder to diagnose.

Leave “Enable Tun” off for now. TUN uses a virtual network adapter to capture eligible traffic and can help with apps that don’t use the system proxy, but it also involves permissions and compatibility with routing, DNS, and other network tools. You usually don’t need it for a basic browser test. If you need to capture traffic from other apps, enable it separately after the basic connection works. See the routing section of the configuration guide for related settings.

v2rayNG for Android uses a different traffic entry point: starting it creates a system VPN service, and the client’s routing settings determine whether traffic goes direct or through the proxy. Start with a regular routing mode that meets your needs, and leave per-app proxy settings unchanged for now. If you’ve set an allowlist or exclusion list, make sure the test browser isn’t accidentally excluded. With the traffic entry point and routing behavior established, you can enable a server and check the core status.

Step 3: Enable a server and check that it’s running

Select a server and set it as active

Return to the v2rayN server list. Click a server entry you’re authorized to use, then choose “Set as active server” from the right-click menu. Some versions also let you double-click an entry. Highlighting a row only selects it; it may not switch the active configuration. Check the active marker or current server status afterward to confirm that the client is using the entry you chose.

Switching configurations usually loads or restarts the core. Open the client’s log panel and look for recurring startup failures, occupied listening ports, or configuration parsing errors. No obvious errors only means the startup process looks okay; it doesn’t prove the remote connection works. If the logs show that a local port is already in use, check whether another proxy program is still running before changing any ports.

The client’s connectivity test can help you compare servers, but make sure you know what it tests. A TCP test checks the connection to a target port; it doesn’t verify a complete protocol handshake or successful webpage access. A test may also fail because its target is unreachable. Don’t choose or reject a configuration based only on a test result. Use the browser request and client logs in the next step to make the final call.

Approve the system connection request on Android

On the v2rayNG main screen, select the server you want to use and tap the Start button. The first time you run it, Android will show a system VPN connection request. Approve it, then check that the client is running and that the system shows a VPN connection indicator. System permission only allows the client to create a local traffic tunnel; it doesn’t confirm that the remote server is working. If another VPN service is running, stop it before starting this client.

If the client stops immediately after starting, check the error message first, then confirm that the subscription entry is complete, the system isn’t restricting background operation, and the network is working. If it disconnects later when the screen is locked, check battery optimization and background restrictions for your device. Don’t disable multiple system protections before the connection works. On desktop and Android alike, fix core or service startup problems before troubleshooting website access.

Keep the current client running. Don’t change the core, subscription source, or DNS settings yet. The next step is to test whether this specific configuration works. Change one variable at a time so you can tell whether an issue comes from the server, the app’s traffic entry point, or the routing mode.

Step 4: Test websites and apps

Start by testing a request that should use the proxy

Open a new browser tab and visit an HTTPS page you’re authorized to access that should use the proxy under your current routing rules. After it loads, open another page on the same site to make sure you aren’t just seeing cached content. If your browser has a separate proxy extension, make sure it uses the system proxy or temporarily turn off its traffic handling. The browser’s secure DNS, enterprise policies, and custom proxy settings can all change the request route.

At the same time, check the client’s connection details or logs for an entry matching the test time and destination domain. Use it to see whether the connection went through the proxy or direct. How much detail the logs show depends on the version and settings. If an entry is missing, check the log level before assuming the traffic never reached the client. A page loading successfully alone doesn’t prove that routing is correct; it may have loaded over a direct connection.

If you need to check the exit IP address, use a lookup service you trust and compare the result with the routing records. With split routing, different destinations may use different exits, so one lookup doesn’t show the route for every connection on the device. Also visit a site that should go direct to make sure regular access still works. If only certain sites have problems, check their rules and DNS first instead of assuming the whole client is broken.

Once the browser works, test your other apps

If the browser works but a download manager, terminal program, or other app doesn’t, first check whether the app supports and has enabled the system proxy. For apps with manual proxy settings, use the listening address, port, and protocol shown in the client’s current settings; don’t copy port numbers from another guide. If the app only supports HTTP proxies, don’t enter a SOCKS endpoint, and vice versa.

Test TUN separately only if an app can’t use the system proxy and you need to capture its traffic. Grant the permissions requested by the client and system, and watch for errors related to virtual adapter creation, DNS, or routing. Whether to use TUN alongside the system proxy depends on your client version and needs. After enabling it, test the same destination again and check that local network and work connections still function. If anything breaks, turn TUN off to return to the verified setup, then see Troubleshooting rather than layering on more changes.

If webpages still won’t load, troubleshoot one layer at a time: check that the client starts, confirm the correct server is active, make sure the app’s traffic reaches the client, and then inspect the remote handshake and routing logs. For certificate errors, check the system clock and configuration source. For connection timeouts, consider the remote address and network conditions. Don’t disable security checks just to make a page load. For details on protocol, DNS, and outbound settings, see the configuration guide; this page focuses on the steps needed for an initial connection.

After setup: save your settings and exit

After completing these checks, keep the working subscription group, active server, and routing selection. If you want automatic updates, return to Subscription Group Settings and choose a sensible interval. If behavior changes after an update, check the server entries and routing first instead of reinstalling the client. Before sharing screenshots to report a problem, hide subscription URLs and server credentials. Include only the error message and relevant setting names.

Before exiting the desktop client, clear the system proxy in the client, then quit. If the client offers an option to clear the proxy on exit, confirm that it works as expected. Otherwise, some apps may keep trying to connect to a local proxy endpoint that is no longer running. Stop TUN or the Android VPN service from the client and confirm that the system connection has ended. If regular network access is still affected after quitting, check for leftover manual proxy settings first.

Your initial setup is complete when the subscription has updated, the active server is clear, the core is running, and actual traffic follows the expected route. Once all four are in place, explore custom routing or DNS settings as needed; there’s no need to enable every feature at once. Continue with the V2Ray configuration reference, or visit Troubleshooting to diagnose a specific error.