Before you begin, install and open the client, and get a valid subscription link from a source you trust. The client reads configuration and forwards requests; it does not provide a working remote server. Check your subscription’s expiration date, data allowance, and device limits in your provider’s account portal. These are separate from whether the client is installed correctly on your device.
For your first setup, run only one proxy client and temporarily close other tools that can take over network traffic. This helps prevent them from repeatedly changing the system proxy. Avoid changing a whole set of advanced options up front. Keep the client’s default local listener settings and check the subscription, server selection, and browser access one at a time. If something goes wrong, you’ll know which step to investigate.
Step 1: Import a subscription and update the server list
Copy the full subscription URL from your provider’s account portal. This is the link used to update server configuration—not the account sign-in page or a plan description. The URL usually contains credentials, so don’t share it in public chats or screenshots. If you report an issue, redact the entire URL, not just the last few characters. If your provider supplies only a QR code or a single share link, confirm its type first, then use the appropriate import option in the client.
Add a subscription group in v2rayN
Open the v2rayN main window, find Subscription Group in the menu, and open Subscription Group Settings. Choose Add, enter a recognizable label for the group, paste the full URL into the subscription URL field, and save. Depending on the version, Add may appear as a plus button or in a context menu. Either way, you’re creating a group entry with a subscription URL. Saving it adds the update source; the server list won’t change until you update it.
Return to the main window, open the Subscription Group menu, and update the group you just created. If you haven’t connected through a proxy yet, choose the option to update without a proxy. If your current network can’t reach the subscription URL, consider another connection path only if you know it works. Once the update finishes, select the group and check that its servers appear. Check the group filter first so you don’t mistake another group’s empty list for a failed update.
If the list is still empty, check the client’s message: a network timeout and a content parsing error are different problems. For a timeout, check whether the subscription URL is reachable and still valid. For a parsing error, confirm that the content is in a supported subscription format. Don’t paste returned webpage content into config.json. A subscription URL, a single vmess:// or vless:// share link, and a full JSON configuration each have their own import option. Don’t use them interchangeably just because they’re all text.
Use the corresponding option in v2rayNG
In v2rayNG, open the side menu and go to Subscription Group Settings. Tap the plus button to add a group, enter a label and subscription URL, then save. Return to the server list, choose Update subscription from the menu, and check the group. Adding a group without updating it may leave the server list empty. If servers are already listed but the subscription has changed, update it again instead of repeatedly adding the same URL.
You’re ready to continue when the correct group contains selectable servers and the update completes without repeated errors. You don’t need to test every server or edit server parameters by hand yet. To learn about subscription encoding and share-link formats, see Subscription imports and Base64/URI formats. Keep the server list open and move on to proxy mode settings.
Step 2: Choose a system proxy and routing mode
Servers appearing in the list confirms that the configuration was imported; it doesn’t mean app traffic is reaching the client. Keep two things separate: the system proxy or TUN determines how requests enter the client, while routing rules determine which outbound route they take. These are different layers, not the same switch. To get started, use the system proxy to test a browser, keep the existing basic routing preset, and don’t enable TUN or change DNS at the same time.
Understand the three system proxy options
In v2rayN, Set system proxy attempts to point the system proxy to the client’s local listening address so apps that follow the system setting can use it. Clear system proxy removes the system proxy settings and is usually used when you stop using the client or troubleshoot. Do not change system proxy leaves the current system settings untouched. It doesn’t mean traffic goes direct or that a proxy is enabled: another proxy address already configured on the system may still be active.
Locate these three options now so you know where to find them. Before switching to Set system proxy, select a server in the next step and confirm that the core has started. If the system proxy currently points to an app that isn’t running, clear it first to avoid losing browser access during setup. When you enable the system proxy later, use the local listening address and port shown by the client. Don’t copy a fixed port from another guide.
Start with a routing preset; consider TUN later
In the client’s routing settings, choose an existing preset that suits your needs. Split routing sends some requests direct and others through a proxy outbound; a global proxy preset sends more requests through the proxy. The exact behavior depends on the rules and their order, so don’t judge by the preset name alone. For your first test, choose a destination that clearly matches a proxy rule, and keep a direct destination as a comparison.
TUN uses a virtual network interface to capture traffic. It often requires additional permissions and may change DNS and routing behavior. It can help with apps that don’t follow the system proxy, but it shouldn’t be the first extra switch you turn on when a connection fails. Leave TUN off and confirm the basic connection through the system proxy first. If you need to capture traffic from specific apps, configure TUN separately using the platform section in the full documentation. This avoids changing both traffic capture methods at once and making the cause harder to identify.
v2rayNG captures app traffic through Android’s VPN interface, so there’s no need to look for the desktop system proxy options. If per-app proxying is enabled, make sure the browser you’re testing is included. Routing mode and the per-app list can both affect results. For your first test, keep the basic settings clear and avoid adding lots of exception rules. Once you’ve chosen a mode, the next step is to connect through your selected server.
Step 3: Select a server and connect
Return to the v2rayN server list and choose a server that your provider marks as available and that suits your needs. Clicking a row to highlight it may only select it; it doesn’t necessarily make it the active server. Use Set as active server in the context menu, or the equivalent option in your version, and check that the active marker moves to that entry. Similar server names may use different protocols or transport settings. Don’t copy a field from one entry into another to piece together a configuration.
Check the core before setting the system proxy
v2rayN usually starts or reloads the core after you set an active server. Check the latest entries in the main window’s log and make sure there are no recurring configuration parsing errors, startup failures, or port conflicts. An open window doesn’t guarantee that the core is running. Without a local listener, even correctly configured system proxy settings have no local service to receive requests.
If the log reports a port conflict, quit other proxy apps or duplicate instances of the same client, then try again. Don’t pick a random new port and forget to update the system settings. If the log says a configuration field isn’t supported, check the client version and subscription format. Don’t delete fields you don’t understand to force it to start. For installation permissions, app launch restrictions, or platform environment issues, consult the installation and setup documentation for all platforms. You don’t need to maintain a full configuration file by hand just to make your first connection.
Once the core is running, select Set system proxy from the v2rayN menu. On macOS, go to System Settings → Network, select the network service you’re using, then check the relevant settings under Details → Proxies. The labels and menu levels may vary slightly by macOS version. Check that the enabled proxy options point to your device and use the same port as the client’s current listener. Only check options that are actually enabled; you don’t need to turn on every proxy type listed.
On Android, connect and approve the system request
In the v2rayNG server list, select the server you want and tap Connect. When Android first displays a VPN connection request, make sure it was initiated by the client you’re using before allowing the connection. A connection icon in the status bar means the VPN interface is active; it doesn’t prove the remote server is reachable. If another network tool using the same type of interface is running, stop it and reconnect to avoid a conflict.
After connecting, you can use the client’s built-in test as an initial check. A failed test doesn’t necessarily mean every app is unable to connect, and a successful test doesn’t mean every app follows the same route. Don’t change several settings in response to a single test result. Keep the server, routing, and traffic capture mode unchanged, then use a real browser request in the next step to test the full path.
Step 4: Test your connection
Open a browser that follows the system proxy, start a new tab, and visit an HTTPS site you’re authorized to use that should match a proxy rule. Don’t rely on a page that was already open: cached content, existing connections, and background preloading can make it look like the connection still works. Reload the page and perform a new action while watching for a new connection entry in the client log. Match its timestamp to your request.
Cross-check the page, client log, and system settings
The evidence should line up: the page completes a new request, the client shows corresponding connection activity, and the system proxy or Android traffic capture state matches what you expect. If the log shows an outbound tag, it may help you tell whether a request used proxy or direct. The actual tag depends on your configuration and may not match these examples. With split routing, some sites are expected to connect directly, so not every connection needs to use a proxy outbound.
Open a second page that you expect to connect directly to confirm that basic network access still works. If you check your public IP address, treat it as supporting evidence only: routing rules may send the lookup page direct while other requests in the same browser use the proxy. Before checking the result, confirm which rule matched the lookup site. An unchanged address alone doesn’t mean that all proxy traffic has stopped working.
When something goes wrong, check one layer at a time
If no pages load, clear the system proxy first and check whether your basic connection returns. On Android, disconnect v2rayNG and make the same comparison. Once basic network access works, check the core status and active server in the client. If the browser can’t connect to the local proxy, check the listening service and port first. If the request reaches the client but times out remotely, check server availability, subscription status, and current network conditions. Don’t attribute every error at every layer to DNS.
If the browser works but a particular app still behaves the same, check the app’s own proxy options and whether it follows the system proxy. Some apps need to be configured individually; others may need TUN to capture their traffic. If only certain domains fail, check the matched routing rule and DNS behavior. For more detailed troubleshooting by layer, see Common configuration issues in the full documentation. Keep the browser path you’ve already confirmed working, and don’t overturn all your settings to fix one app.
Restore network settings before you finish
When you’re done on desktop, select Clear system proxy before quitting v2rayN. Closing the main window may only hide it, while force-quitting the process could leave the system pointing to a local port that’s no longer active. If your browser loses network access after quitting, check for leftover proxy settings in your system network settings and restore the previous state. If your device is managed by your organization, don’t remove existing managed settings; first confirm what you’re allowed to change.
In v2rayNG, tap Disconnect first and make sure the system connection icon disappears before closing the app. You only need to note which server, routing preset, and traffic capture mode worked. There’s no need to record or share the subscription URL. At this point, the subscription update, active server, traffic capture, and real-world access have all been verified. When you change settings later, follow the same order: change one thing at a time and test with the same destinations. If something breaks, you’ll know what changed most recently.