v2rayN and v2rayNG
Subscription Setup and Connection Guide

Step 1: Import a Subscription and Select a Configuration

Copy the complete subscription URL first. Remove any quotation marks, spaces, or line breaks included when copying, but don't delete parameters at the end of the URL. You can name the subscription group anything you like, such as “Daily setup”; this is just a label in the client and doesn't affect the connection. Add one group for your first attempt, then organize other sources once everything works.

v2rayN: Save the Group, Then Update the Subscription

Open the “Subscription Group” menu at the top of the main window, go to “Subscription Group Settings,” and choose Add. Enter a group name under Remarks or Alias, paste the subscription URL, and save. Back in the main window, use the subscription group menu to update the current group. If there are multiple update options, use the one that doesn't go through a proxy before you've connected for the first time.

Wait for the update to finish, then check the status area at the bottom or the update message. On success, the main list should show configurations from the group, including details such as the name and protocol. Make sure the displayed group is the one you want, then select a configuration and use “Set as active server” in the right-click menu or the equivalent option in the interface. Don't assume a row is active just because it's selected—confirm that the active indicator has changed.

v2rayNG: Add a Subscription Group, Then Update the List

Open “Subscription Group Settings” from the side menu, tap Add, enter a remark and the subscription URL, then save. Return to the main screen and choose Update Subscription from the top menu. If you have multiple groups, check whether the update applies to the current group or all groups. When it's done, switch to the relevant group, confirm its configurations appear, then tap one to select it for connection.

If you have a single-server share link, don't save it as a subscription URL. Copy the link, then use the main screen's Add option or “Import from clipboard” in the server menu. Importing a single server adds that configuration but doesn't create a subscription that can be updated later. If the server details change, import a new link or use the provider's official subscription URL instead.

If the List Is Empty, Stop Here and Check

A “Group saved” message doesn't mean configurations have been retrieved. If the list is still empty, check the group filter, then reopen the URL field and make sure you pasted a subscription URL—not an account management page. For a timeout, check that your regular internet connection and the subscription service are reachable. For a parsing error, check whether the response uses a subscription format supported by the client. Don't keep creating groups with the same name; that only makes troubleshooting harder.

Only switch to updating through an existing proxy if the provider explicitly requires it and you already have a working connection. If the subscription keeps failing, continue with common issues; see subscription format reference for compatibility. You're ready to move on when the configuration list is populated and you've selected one configuration. Next, decide which app traffic should go through the client.

Step 2: Choose a Proxy Mode and Routing

Keep two things separate: the system proxy, VPN mode, or TUN determines how traffic enters the client; routing rules determine whether traffic is proxied or sent directly once it gets there. These are separate layers. Choosing a proxy outbound rule won't help if an app never sends its requests to the client. Keep the setup simple at first: get browser traffic working before configuring more apps.

v2rayN: Start with Automatic System Proxy Configuration

Find “System Proxy” in the main window or system tray menu, then select “Automatic system proxy configuration.” This sends requests from apps that follow the system proxy to the local client. If the menu also offers “Clear system proxy” or “Do not change system proxy,” don't treat those as equivalent ways to start: the first removes the setting, while the second may preserve the device's existing proxy state. Neither is the default choice for a first-time setup.

Next, check the routing settings. For everyday browsing, start with a built-in rule set that matches your needs; there's no need to edit domain or IP rules right away. To check whether routing is causing a specific access issue, briefly test with a rule that sends ordinary traffic through the proxy, then switch back. Preset names vary between versions, so read their descriptions instead of assuming that “Global” means every app is being routed through the client.

Leave TUN off for now. The system proxy is usually enough to test browser traffic. If a standalone app doesn't use the system proxy, troubleshoot that separately later. TUN adds variables involving virtual network interfaces, permissions, and routing, so don't debug it at the same time as your first subscription import. If you need to route traffic from those apps, wait until Step 4 passes, then read the protocol and core reference and connection troubleshooting guide before trying TUN on its own.

v2rayNG: Check Routing and Per-App Settings

Open the routing options in Settings and keep the built-in rules for now; don't add custom domain or IP entries yet. If per-app proxying is enabled, check whether it means “proxy only selected apps” or “bypass selected apps.” These lists work in opposite directions: selecting the same browser can produce completely different results. For your first test, turn off per-app restrictions so it's easier to see what's being routed.

When you tap Connect on Android, the client uses the system VPN interface to handle traffic covered by your settings. You don't need to copy the desktop system proxy steps. If another VPN is already connected, Android may ask to switch or replace it; check what the existing connection is for first. Don't replace a connection in a work environment without understanding the impact.

By the end of this step, you should know which traffic-entry method you're using, which routing rules are active, and whether the app you're testing is included. There's no need to understand every protocol parameter yet; leave the server fields in the subscription unchanged. Once the connection is stable, read the REALITY protocol reference to learn how VLESS, REALITY, and core support relate. Don't change the protocol type just to try a different option.

Step 3: Connect and Check the Client Status

Return to the configuration list and double-check the current group and selected configuration. For your first connection, use just one configuration; don't enable extras such as load balancing or custom proxy chains. The name in the list is a label supplied by the provider, not proof that the server works. Confirm the connection using the startup status and a real access test in the next step.

v2rayN: Confirm the Active Server and Core Are Running

After you set the target configuration as the active server, the client typically generates a runtime configuration and starts or reloads the core. Check the main window's status area for any persistent startup errors. If there's an option to restart the service or reload the configuration, use it once after making changes, then wait for the result instead of clicking repeatedly. Finally, make sure “Automatic system proxy configuration” is still selected.

If you see a local port conflict, first exit other proxy programs that may be listening on the same port, then try again. If you need to change the listening port, change it in the client settings and check any apps where you manually configured a proxy. Changing the port in only one place will cause another connection failure. Don't copy a fixed port number from another guide; use the settings on your device when troubleshooting.

On desktop, the client may keep running in the system tray when its window is minimized. Closing the main window may not exit the client. Keep access to the logs during testing so you can compare failed requests with status messages. If the system asks for network access, allow what's needed for local use; you don't need to disable system-wide protection to troubleshoot.

v2rayNG: Tap Connect and Approve the System Request

Select the configuration you want, then tap Connect on the main screen. The first time you start, Android displays a VPN connection request. Make sure v2rayNG is the requesting app, then approve it. If you cancel the request, the client can't handle traffic even if configurations are already loaded. After connecting, check that the main screen shows a running status and that the system displays the VPN indicator.

If the button quickly returns to the disconnected state, open the client log or error message and check for configuration parsing, core startup, or permission errors. If a field is explicitly unsupported, don't delete unfamiliar parameters and hope for the best. First check whether the client needs an update and whether its core supports the subscription's requirements. Protocol and transport settings must match the server; changing them at random may turn a startup error into a handshake failure.

If the connection drops only when you switch apps or lock the screen, first confirm that it stays up while the app is in the foreground. Then check the system's background activity and battery restrictions for that app. Settings names vary by device, so change only options related to the app. Don't mistake the system stopping the app in the background for every configuration in the subscription being broken.

You're ready to move on when the client stays running without obvious startup errors. A running status only confirms that the local service has started—it doesn't prove that remote access works. Next, test the full path with a browser and the app you need.

Step 4: Test Whether Your Browser and Apps Work

Open a new browser tab and visit a site you know is currently available, then try the service you actually need. Don't just refresh a cached page or check whether its title appears. Follow a new link or load fresh content to confirm that the request completes. If even ordinary sites won't load, check your internet connection and the client's running status first instead of immediately changing routing rules.

Check Real-World Access Before Test Results

Latency tests in the client can help you compare configurations, but they don't guarantee that browser requests will succeed. Some tests check only whether a connection can be established; others send a specific request. The test method and target may differ from what your app uses. If a latency result appears but a page won't load, check whether the app uses the proxy, how the domain resolves, and which routing rule applies. If the test times out but access works, don't delete a configuration based on one result.

On desktop, if the browser works but a standalone app doesn't, check whether the app has its own proxy settings and whether it follows the system proxy. Don't assume the server is at fault. If some Android apps don't work, go back to Step 2 and check the per-app list and routing rules to make sure the app isn't excluded. Test one app at a time to pinpoint where the behavior differs.

To investigate further, check the client logs or connection records while making a new request. Depending on the log level, the interface may show the destination address, matched rule, or error. If a request doesn't appear, the log level may simply be too low; that alone isn't conclusive. If you temporarily increase logging detail, restore your usual settings once you finish, and remember that logs may include the sites you visit.

Compare With the Connection On and Off to Check Routing

If it won't disrupt important work, compare results with the connection on and off. On desktop, clear the system proxy and stop the service; before testing again, restore automatic system proxy configuration and start the service. On Android, disconnect with the Connect button, then reconnect. Make a fresh request each time and use the same test target so cached pages or network fluctuations don't skew the comparison.

If you use an external IP lookup page, the address it shows only tells you which exit was used for that specific request. It doesn't prove that every app or domain follows the same route. With split routing, different requests using different exits may be expected. Compare the active routing rules with what you need rather than expecting every page to show the same address.

If it still doesn't work, check these in order: is your regular internet connection working, did the subscription update successfully, is the correct configuration active, is the core still running, is the test app sending traffic to the client, and do the routing rules match your needs? For connection issues, see connection troubleshooting; for unexpected test results, see latency test guide; for slow loading despite working access, see speed troubleshooting. Identify the symptom first, then follow the relevant guide instead of resetting everything.

Restore Your Device Settings When You're Done

Before exiting the desktop client, select “Clear system proxy,” then exit from the system tray menu so apps don't keep sending traffic to a stopped local service. If you enabled another traffic-handling mode, turn it off using its corresponding option too. On Android, tap Disconnect and confirm the client and system have ended the connection. Then visit a regular website to check that your device is back to the expected network state.

After completing the four steps, keep the working configuration as it is; there's no need to keep changing parameters. For routine use, you usually only need to update the subscription, select a configuration, and connect. On a new device, check the system proxy or which apps are routed instead of assuming the old device's behavior carries over. To learn more about protocol choices, core differences, or subscription compatibility, see the protocol reference. For a specific term, use the glossary.