This guide assumes the client is installed and you have a valid subscription URL. Follow the steps to complete a basic setup in about 10 minutes; actual time depends on your subscription provider and network. The client reads node settings and establishes a connection, but you need to obtain the subscription URL and working nodes separately. Installing the software alone is not enough to connect.
Before you begin, quit any other proxy tools that are routing traffic, and keep your current internet connection available. Avoid changing DNS, the core, and custom routing rules at the same time; that makes problems harder to diagnose. If you haven't installed the client yet, visit the download page to choose the right version. For installation permissions, system requirements, or setup on multiple devices, see the full setup guide for all platforms.
1. Import a Subscription and Update Nodes
Copy the complete subscription URL from your provider. It usually starts with https:// and may include a path or query parameters used to identify your account. When copying, avoid extra spaces, line breaks, or punctuation added by a chat app, and copy the actual URL rather than its display text. A subscription URL may provide access to your account's nodes. Don't post it publicly or leave it visible in troubleshooting screenshots.
Open v2rayN and find “Subscription Group Settings” in the subscription menu. Add a group, enter a recognizable name in the remarks field, and paste the URL into the subscription address field. The name helps you identify the group; the URL determines where nodes are retrieved from. Make sure the group is enabled, save it, and return to the main window. Menu locations may vary slightly between versions, but the process is the same: create a group, then fetch its contents.
After saving, the group exists, but its nodes may not appear right away. Open the subscription menu and update the current group. If the only option is to update all subscriptions, you can use that instead. Check the status bar or logs and wait for the update to finish. If the menu offers updates through or without a proxy, choose the option that works with your current network. Don't depend on a proxy that hasn't been started yet.
Once the update finishes, select the group you just created and check the main list for node details such as server name, address, or protocol. Seeing the group name doesn't mean the subscription updated successfully; nodes in the list show that the client has received and recognized its contents. Don't edit node settings or enable TUN yet. Next, select a node and establish a basic connection you can test.
In v2rayNG, open the menu in the top-right corner of the main screen and select “Subscription Group Settings.” Tap the add option, enter a name and subscription URL, and save. Return to the main screen, select Update subscription from the menu, and wait for the node list to refresh. Saving a URL in group settings without updating may leave the main list empty. If you have multiple subscriptions, select the new group first so you don't mistake old nodes for results from the new URL.
If you have a single share link starting with vless:// or vmess://, use the import-from-clipboard option rather than entering it as a remote subscription URL. A share link usually describes one node; a remote subscription lets you update multiple nodes later. Descriptive text on a webpage, a login page URL, or a raw JSON configuration may not be importable as a subscription. A link opening in your browser doesn't mean it's in the right format.
If the list is still empty, first check that the URL is complete and the subscription is valid, then review the update logs for network or parsing errors. Don't keep deleting the entire client configuration and trying again. A failed update and a failed node connection are different problems: with an update failure, the client hasn't received the configuration; with a connection failure, it has received the configuration but can't connect. For help identifying formats and fixing an empty list, see common issues. Once at least one node appears, move on to choosing a traffic mode.
2. Choose a System Proxy and Routing Mode
In v2rayN, treat these as two separate settings: the system proxy determines which apps send requests to the client, while the routing mode determines whether the client sends those requests direct or through a proxy. They're not the same switch. “Set system proxy automatically” doesn't mean every destination will use the proxy, and Global routing won't capture traffic from apps that ignore the system proxy. Confirm the traffic entry point first, then where it goes. That gives you a clear basis for testing.
For a first-time setup on Mac, leave TUN off and test your browser with the system proxy. Find “Set system proxy automatically” in the client's system proxy menu, but wait until you've confirmed the core is running before enabling it. This setting writes local proxy details to your system network settings for apps that follow them. If macOS asks for permission, check who is requesting it and what access is needed, then approve it in the system dialog.
“Do not change system proxy” in the same menu means the client won't actively change your current settings; it doesn't remove proxy addresses already set. If you previously enabled the system proxy, the old address may remain after selecting this option. Use “Clear system proxy” to undo the corresponding system proxy settings. Keep this distinction in mind when you're done, so your browser doesn't keep sending requests to a local port after the core has stopped.
Next, find Routing settings or the routing preset on the main screen. For everyday testing, start with “Bypass mainland China.” Destinations matching the relevant direct-connection rules will connect directly; other traffic is handled according to the preset. The result depends on the rule database and rule order, not the language displayed on a webpage. With Global proxy, traffic entering the client is generally sent through the proxy according to the preset. It's useful for comparisons, but doesn't guarantee a faster connection.
Don't add a long list of custom routing rules during your first setup. Keep the client's preset, note which one you chose, and test different destinations later. Otherwise, if a destination won't load, it can be difficult to tell whether the cause is the node, DNS, or a custom rule. For rule priority and GeoIP or GeoSite configuration, wait until the basic connection works, then see the full documentation.
On Android, check the current mode in v2rayNG's settings or routing menu. For your first test, avoid complex per-app exclusion rules so you don't accidentally exclude the browser you're testing. When v2rayNG connects, it uses the system VPN interface to route traffic covered by your settings. This system VPN permission is not an account login with your subscription provider, and you don't need to enter the subscription URL in Android's built-in VPN settings.
TUN routes more traffic, including from apps that don't follow the system proxy, but it also involves a virtual network interface, routing, and DNS. Don't treat it as a switch to flip when a connection fails. First complete a test using the system proxy. Configure TUN separately only if you confirm that an app ignores the system proxy and needs broader traffic routing. Keep your selected routing mode for now, then choose a node and connect.
3. Choose a Node and Connect
Return to the main v2rayN list and find a node from the updated subscription. Select it, then use the right-click menu or another available option to set it as the active server. Some versions also let you double-click a node to select it. Don't assume the highlight on a selected row means the active server changed; check for an active indicator or current server status. Having multiple nodes in the list doesn't mean the client will use them all at once.
For your first connection, choose a complete node that your subscription provider identifies as usable. There's no need to test every node first. A latency test isn't the same as a real web request, and a latency result doesn't prove that every site is reachable. Completing the full process with one node avoids extra requests from bulk testing and gives you a useful baseline for checking logs.
After confirming the active server, check the core status or logs. v2rayN starts or reloads the core when applying a configuration, though the startup controls and status indicators vary by version. If the logs show a configuration parsing error, the core exits, or a local listening port is already in use, fix that first instead of repeatedly changing routing modes. The local proxy endpoint can respond only when the core is running properly.
Next, select “Set system proxy automatically” from the system proxy menu. On Mac, open the proxy settings for your network service in System Settings and check whether a local proxy address has been set for the service in use. You don't need to change the port manually. Use the client's actual listening settings; don't copy port numbers from another guide. If you've switched Wi-Fi, connected by Ethernet, or added another network service, check which service's settings are currently active.
In v2rayNG, tap a node to select it as the current configuration, then tap Connect on the main screen. The first time you connect, Android asks to set up a VPN connection. Approve the request, return to the client, and check the connection status and system status bar. If another VPN is already active, the new connection may replace it; check whether you need to keep the existing work connection before proceeding. Selecting a node alone won't route traffic until you grant system permission.
Keep the client running after connecting. Closing the desktop window may minimize it to the tray, depending on your settings; on Android, battery and background restrictions may interrupt the connection. Don't clear the app from the background or force-quit it during your first test. If the connection drops soon after starting, check whether the system stopped the client before assuming there's a node problem.
If the logs show a handshake, authentication, or timeout error, first check that your device's date and time are correct, then try another node from the same subscription. Don't change the UUID, transport type, REALITY settings, or server name without a reason; these values must match the server. If the error persists, note its type and the step where it occurs, then see troubleshooting for next steps. Remove subscription URLs and account details before sharing logs.
4. Test Your Browser and Apps
A running status in the client only means the local service or traffic routing has started; it doesn't prove that your target app is using it. Open your usual browser, start a new tab, and visit a page that normally loads to confirm your internet connection still works. Then open the destination you want to reach through the proxy and reload it. Don't rely on a page that was already open before you connected; caching can make a failed connection look like it still works.
Check the browser and client logs together. If the client provides access logs, look for the target domain or connection and the outbound route when you make a request. The amount of detail varies by configuration; a missing domain in the logs alone doesn't prove the request bypassed the client. Node latency, core status, and your apparent public IP each provide different clues. The main test is whether the request to your intended destination succeeds.
With “Bypass mainland China,” test both destinations expected to connect directly and those expected to use the proxy. A direct page loading doesn't prove the proxy outbound works; one proxied page loading doesn't prove every routing rule is correct. If needed, temporarily switch to Global proxy and test the same destination again, then restore your original preset. If only one routing mode fails, check the matching rules next instead of reinstalling the client.
To check your public IP, use a trusted IP lookup page in the same browser you're testing, and interpret the result in light of your routing mode. With split routing, the lookup page may connect directly, so seeing your local public IP doesn't necessarily mean the proxy is broken. Don't keep switching nodes just to get a particular result. What matters is whether the target app's request enters the client as expected and leaves through the right outbound route.
If the browser works but another app doesn't, check whether that app uses the system proxy, has its own proxy settings, or still has an old address or port configured. Some command-line tools and developer apps don't automatically use the desktop system proxy. Don't assume the node is down or switch cores without a reason. Try configuring a compatible proxy endpoint in the app first. If you need broader traffic routing, follow the TUN setup instructions in the full documentation.
If no destinations load, clear the system proxy or stop the Android connection first, then check whether your basic internet connection works again. Once it does, check in order whether the subscription updated, a node is active, the core is running, and the system proxy is set. Change one thing at a time and repeat the same page test. This helps distinguish a traffic entry, node, or routing problem—and is easier than enabling TUN, changing DNS, and switching protocols all at once.
Once the connection works, keep the working node and routing settings before considering automatic subscription updates or other preferences. When you're done, clear the system proxy on desktop before stopping the core or closing the client. If TUN is enabled, stop its traffic routing first. On Android, tap Disconnect and confirm the system VPN has ended. Finally, reload a regular webpage to make sure your connection still works. That completes both setup and cleanup.