v2rayN Subscription Import and Connection Setup

First, identify what you have. A subscription URL lets the client retrieve a set of server configurations. A single share link usually starts with vmess://, vless://, trojan://, or ss://. Each uses a different import option. A long URL isn’t necessarily a subscription, and an account management page URL is not a subscription URL.

In the v2rayN main window, open Subscription Group, then Subscription Group Settings, and choose Add. Enter a recognizable note for the group, paste the full subscription URL into the address field, and save. The note is a local label and does not change the server settings. Check that the URL has no extra spaces or line breaks, and don’t include any accompanying instructions.

Saving a group does not download its server configurations. Return to the main window, open Subscription Group, and select Update subscription. If you don’t have a working proxy yet, use the option to update without a proxy. Wait for the operation to finish and check the log or prompt, then look for server entries such as protocol and address. If the interface filters by group, select the one you just created so you don’t mistake another group’s list for a failed import.

For a single share link, copy the entire URL, then open the Server menu and select Import share links from clipboard. After importing, check that the new entry’s protocol and address look right. Don’t edit the encoded content in the link. If the format isn’t recognized, ask the configuration provider whether it’s compatible with your client instead of repeatedly changing the link prefix.

In v2rayNG, open Subscription group settings from the menu, add a group with a note and subscription URL, and save. Return to the server list and choose Update subscription from the menu. To import a single link, use the clipboard import option in the main screen’s add menu. Android may ask for permission to read the clipboard as part of the import. Afterward, confirm that a new entry appears in the list.

If the list is empty, check the update result before changing routing. An unreachable URL, an empty subscription, or a web page returned instead of configuration data can all prevent import. If your current network can’t fetch the subscription directly, connect using an existing working configuration and then try updating through the proxy. If you don’t have one, ask the provider how to retrieve the configuration.

Server entries mean the configuration was added to the client, not that the servers are reachable. There’s no need to edit advanced fields one by one yet. Keep the original settings and move on to choosing how traffic will be handled. For more on the differences between subscription updates and share links, see the installation and setup section of the FAQ.

With the configuration imported, decide how apps will send traffic to the client. These are two separate layers: system proxy or TUN determines how traffic reaches the core, while routing rules determine which outbound route it takes. Enabling the system proxy does not mean every app will use it, and choosing a routing preset does not start a connection.

For a first desktop test, start with the system proxy and leave Enable Tun mode off. In the main window or the tray icon’s System Proxy menu, choose Auto configure system proxy. This tells the client to add its local proxy listening address to the system proxy settings for apps that follow them. Some apps may not have network access until the core starts. After selecting a mode, continue to the next step rather than judging the connection here.

Next, check the Routing menu. If the client offers a Bypass mainland China preset, it can be a starting point for everyday browsing; the current rule set determines which requests connect directly and which use the proxy. Presets with the same name may contain different rules across versions. For testing, choose a destination that should use the proxy under the current rules. Being able to open a site that connects directly does not prove the proxy is working.

The system proxy is a good starting point for testing a browser connection. Some apps have their own proxy settings or ignore system settings, so they may behave differently from the browser. Check the app’s network options first, rather than enabling multiple traffic capture methods to make one app work. Once the basic connection is verified, consider TUN and per-app settings if needed.

In v2rayNG, there is no desktop-style Auto configure system proxy button. It typically captures traffic through Android’s VPN interface, and the system requests permission when you start it. Before connecting, check the routing options. If per-app proxy is enabled, make sure the browser you’re testing is in scope, and determine whether the list means “only proxy selected apps” or “bypass selected apps.” These options have opposite meanings, so don’t judge by the checkboxes alone.

If you’ve used custom rules before, note your current settings, then restore a preset you understand for the initial troubleshooting. Don’t change DNS, routing, transport parameters, and traffic capture all at once; if the test fails, you won’t know which change caused it. For a deeper explanation of TUN permissions, system proxy scope, and rule matching order, see the protocol and core reference after completing the basic test.

By the end of this step, you should be able to identify two things: how the app you’re testing sends traffic to the client, and which routing rules apply to the destination. Keep both unchanged in the next step, where you’ll select a server and check whether the core starts.

Return to the v2rayN server list and select a complete configuration. Right-click it and choose Set as active server to use it for the current connection. Some versions also offer a keyboard shortcut or double-click, but use the menu the first time to avoid mistaking a selection for a switch. Afterward, check the active indicator in the list and the status bar to confirm that the expected entry is in use.

After you set an active server, v2rayN usually loads its configuration and starts or restarts the core. There may not be a separate, prominent Connect button. Open the log area in the main window and check new messages from this operation. Look for errors such as configuration load failures, port conflicts, or the core failing to start. Fix startup errors before repeatedly refreshing a browser.

A local port conflict may mean the client is running more than once or another program is listening on the same port. Check the tray and taskbar, close duplicate instances, and restart the current client. If you need to change the listening port, make sure the system proxy points to the new one. This guide doesn’t require a specific port number; use the value shown in the client settings and status bar.

Once the core has started, check that System Proxy is still set to Auto configure system proxy and that the routing mode is unchanged. Switching the active server usually doesn’t require reimporting the subscription. If you have to restart the client, check both settings again afterward rather than assuming they were restored.

In v2rayNG, tap a server entry and confirm that the active indicator moves to it, then tap the start button on the main screen. The first time, Android asks for permission to establish a VPN connection; check the app name and allow it. Android usually allows only one active VPN connection. Stop any other app’s connection before starting this one.

After startup, the v2rayNG button and Android’s connection indicator should change. This shows that the local service and traffic capture interface are running, but does not by itself prove that requests can reach the remote server. If the button quickly returns to the stopped state, check the client logs to distinguish denied permission, a configuration load problem, and a startup failure before deciding what to do next.

Tcping and similar client tests mainly indicate whether a target port is reachable; they don’t cover the full proxy handshake or access to the destination. A “real connection latency test” comes closer to an actual proxy request, but its results still depend on the test URL and routing. Use it as an initial check if helpful, but don’t keep switching servers to chase a latency number. The real test is whether the expected app can reach the destination in the next step.

Keep the client running, open a new browser tab, and visit a known-working HTTPS page that should use the proxy under your current routing rules. Whenever possible, use a page where you can tell that the content has refreshed, rather than relying on an already-open tab’s cache. Wait for text or other resources to load, then check the client logs for that time period.

A useful test checks three things: the core has started, the browser is sending requests to the client, and the destination is using the expected outbound route. A running client icon or access to a single ordinary website does not prove all three. If the log level and interface show connection records, check the destination domain and outbound tag. If detailed records aren’t available, don’t assume that no traffic was generated just because the logs didn’t change.

On desktop, check the proxy address and port in your system network settings and confirm they match the client’s current local listening address. If your browser has an extension that controls proxy settings, check whether its mode overrides the system settings. First set the browser to use the system proxy and retry the same destination. Don’t configure conflicting proxy addresses in the extension, system settings, and client at the same time.

On Android, first check that v2rayNG is still running and that another app hasn’t replaced its VPN connection. Then make sure the test browser is included in the per-app proxy scope. If the connection only drops when the app goes into the background, check the device’s battery and background activity restrictions for that app. Whether to relax them depends on how your device behaves; there’s no need to disable system management settings in bulk before the first launch.

If a page won’t load, check the path in this order: local startup, app traffic capture, server connection, then destination access. Look for startup errors, confirm the system proxy or VPN status, and run a real connection test on the active server. If only one destination fails, try another known-working destination that should also use the proxy. If they all fail, check the server settings and network connectivity. A problem with one site doesn’t necessarily mean the whole client is broken.

If the logs show a name resolution or certificate error, keep the exact error text and note when it occurred. For a certificate error, check the device time and the server name in the configuration; don’t bypass it by disabling verification. Don’t immediately switch to a fixed IP to resolve a name resolution issue, as this can also change TLS and routing behavior. For help with a specific error, see the FAQ and troubleshooting guide while leaving the basic settings on this page unchanged.

To compare servers, change only the active server. Keep the browser, traffic capture mode, routing, and test destination the same, and compare the results after each test. This helps isolate whether the difference comes from the server or local settings. Changing several conditions at once makes the cause difficult to reproduce, even if access starts working again.

Once access works as expected, close the test tab and keep the current group and mode. When subscription details change, update the existing group instead of deleting and recreating it. Before exiting v2rayN, choose Clear system proxy and confirm ordinary network access has returned. On Android, stop the connection with the button and confirm that the system connection indicator disappears.