Step 1: Import a subscription
A subscription URL is different from a single share link. A subscription is usually a URL that starts with https://; the client fetches a set of server configurations from it. Content starting with vmess:// or vless:// is usually a single share link. Check which type you have before choosing an import option. Pasting a subscription URL into an “Import from clipboard” option may not create an updateable subscription group.
v2rayN: Add a group and update the subscription
In the main window, open “Subscription Group” and then “Subscription Group Settings,” and choose Add. Enter a descriptive name under “Remark” and paste the full URL into “Optional address” or the subscription URL field, then save. The remark is only for identifying the group locally; it does not affect the connection. Keep the URL unchanged, especially any parameters after the question mark. In some versions, the Add option appears above the group list; the goal is still to create a subscription entry containing the URL.
After saving, return to the main window and choose Update from the “Subscription Group” menu. If you do not yet have a working proxy connection, you can initially choose an update option that does not use a proxy. If the update fails, do not just keep clicking. Check the message to distinguish an unreachable URL, an empty response, or a configuration parsing error. If your provider explicitly requires updates to go through a proxy, you must first have a working connection; you cannot rely on the same subscription you have not yet imported successfully.
When the update finishes, switch to the group you just created and confirm that server configurations appear in the main window. Select one, then right-click and choose “Set as active server.” Some versions also let you double-click an entry to make it active. For now, confirm only that an entry is selected; seeing entries in the list does not mean the connection is working. The active entry determines which remote settings the core uses when it starts.
v2rayNG: Save the URL in Subscription Group Settings
Open the side menu, go to “Subscription Group Settings,” and tap Add. Enter a “Remark” and the “Optional address,” save, then return to the main screen and choose “Update subscription” from the menu. After the update, tap a configuration entry to select it. If the list is filtered by group, make sure the filter includes the group you just added; otherwise, an empty list can look like a failed update.
If you have a single share link, either client can import it using an option such as “Import from clipboard”; select the configuration after importing. A single link usually does not change when you update subscriptions. Do not mix up import methods just to make entries appear, and do not edit server addresses or user IDs you do not understand. For help identifying link types, see Share links vs. subscription URLs.
Step 2: Choose a proxy mode
There are two separate questions to address: whether an app sends requests to the client, and which outbound route the client uses for requests it receives. On desktop, “System Proxy” mainly controls the first; “Routing” controls the second. Android’s VPN mode receives app traffic through the system VPN interface. Keep these layers separate to tell whether traffic was not captured or a rule sent it directly.
v2rayN: Configure the system proxy and routing separately
Find “System Proxy” in the main window or tray menu. For your first browser test, choose “Automatically configure system proxy.” This points the system proxy to the client’s local listening endpoint. It does not route every program on the device: some apps have their own proxy settings, while others ignore the system proxy. For the initial test, use a browser that follows the system proxy and do not enable TUN at the same time; that would add another way to capture traffic.
Next, check the “Routing” selection. To route traffic directly or through the proxy according to rules, you can start with “Bypass mainland China (Whitelist)” or the equivalent predefined rule set in your version. This mode handles requests according to specific rules, not the language of a webpage. Similar rule set names may include different private address, domain, and IP conditions, so check the active rules to understand how local devices and specific sites will be handled.
“Global” routing generally sends default traffic through the proxy outbound, but the actual rules and outbound settings still determine what happens; it is not another name for the system proxy toggle. For your first test, choose one rule set that matches your needs. Do not change rule order, DNS, and the core all at once. For details on how the two settings differ, see System proxy vs. routing modes.
v2rayNG: Check VPN mode and routing settings
In “Settings,” confirm that VPN mode is enabled, then open “Routing settings” and review the predefined rules. Depending on the version, these may appear under labels such as “Predefined rules” or “Domain strategy.” Keep the other defaults for your first setup, and choose a rule that bypasses mainland China if that matches your needs. Do not copy every desktop setting; predefined rules can also change between client versions.
For the initial test, leave “Per-app proxy” disabled. When enabled, the app list and “Bypass mode” together determine which apps use the VPN. If your test browser is excluded, its requests may not reach the client even when the VPN is connected. If you need per-app routing, first complete the basic test in this guide. Then enable the option, check what the app list means, change one setting, and test again.
You do not need to enter custom JSON or change the transport protocol here. The protocol, port, transport, and TLS parameters in an imported configuration must match the remote service; do not replace them just because an option looks newer. The routing section of the configuration reference explains the fields and rule structure. You can skip it during your first setup.
Step 3: Connect
You now have an active configuration and have chosen how traffic reaches the client. As you connect, check the client status and logs rather than relying on the button color alone. Proxy clients typically open remote connections in response to app requests, so a running core does not mean there is an ongoing remote session. First confirm that the app starts, then test the connection with real traffic in the next step.
v2rayN: Confirm the active server and core startup
Return to the main window and confirm the active server. When you set an entry as active, v2rayN typically loads its configuration and starts or restarts the core; check the status bar and logs for your version’s behavior. If prompted to reload the configuration, use the restart option provided in the interface. Avoid switching between several servers in quick succession, as the mixed log entries make it harder to identify what caused an error.
Open the log area in the main window and look for configuration loading, listener startup, or clear error messages. Then check “Parameter settings” for the local listening port and compare it with the address and port used by the system proxy. A common local mixed port is 10808, but use the value shown in your settings rather than changing it to match a guide. If your browser has a separate proxy configured, make sure it is not still using an old port.
If the log says an address or port is already in use, check whether the client is open more than once or another proxy app is using the same port. Close the conflicting app and try again. If the configuration cannot be parsed, check the active entry and subscription update history rather than toggling the system proxy repeatedly. A low log level may hide request activity, but any clear startup error still needs attention first.
v2rayNG: Connect and approve the system VPN request
Select a configuration on the main screen and tap the Connect button in the bottom-right corner. On first launch, Android usually displays a VPN connection request. Confirm it after checking that the request is from v2rayNG. Without permission, the client cannot capture app traffic through the VPN interface; this is separate from whether the subscription is valid. A device that has already granted permission may connect directly without showing the same prompt every time.
After startup, check the button state, the running notification in the notification shade, and the system VPN indicator. Then check the client logs for startup errors. If another VPN is running on the device, stop it and try again. VPN services on the same device may replace one another, so another app’s notification alone does not confirm that v2rayNG is capturing traffic.
For the first test, keep the client in the foreground; there is no need to change battery settings yet. Only check restrictions on background activity if the client works in the foreground but disconnects after you switch away. These settings vary by device, so change only the permissions v2rayNG needs rather than adjusting every system option. If there are no startup errors, move on to testing real traffic.
Step 4: Verify the connection
Choose an HTTPS page you already know loads, then open it in a desktop browser that follows the system proxy or an Android app that is not excluded by per-app rules. Open a new page and refresh if needed to avoid seeing cached content. Choose a test target that should match the route you want to check. If the active rules send it directly, a successful page load does not prove that proxy outbound is working.
Compare the page result with the logs
Keep the client logs visible and note when you open the page. Check for a related connection or error at the same time. If the current log level does not record ordinary requests, a lack of new entries does not prove that the request missed the client. You can temporarily enable the client’s information-level logs, then restore the previous setting when finished. Before sharing logs, hide subscription URLs, user IDs, and other connection credentials.
Ideally, the app sends a request, the client selects an outbound according to the active rules, the page returns valid content, and the logs show no related connection failure. If the page loads but the logs show a direct connection, that may be the expected result of a bypass rule. If it does not load and the logs show a timeout, check the remote configuration and network path. A direct connection is not always an error, and one successful page load does not prove that every app is using the client.
The client’s connection test can be useful as a secondary check, but it tests a specific target in a specific way and cannot replace an app-level request. Its result is not the same as file download speed. For the initial verification, confirm that the traffic entry point, routing, and page result line up; there is no need to keep changing settings to chase a test score.
If it fails, trace one path at a time
If the browser is not going through the client, check the entry point first: is “Automatically configure system proxy” still selected in v2rayN, and does the browser have its own proxy setting? Is v2rayNG still running, and has “Per-app proxy” excluded the test app? If traffic is not being captured, changing the remote protocol usually will not help. Fix one setting, then retry the same page under the same conditions.
If the logs show a request followed by a timeout, check that the active server is correct, the subscription is valid, and the current network can reach the remote server. For TLS handshake errors, first check the device clock and parameters such as the server name in the subscription; do not work around the issue by disabling certificate verification. If only domain lookups fail, investigate DNS separately from the remote connection. For more help, see How to read client log errors.
To compare behavior before and after stopping the client, first choose “Clear system proxy” on desktop, then exit v2rayN. On Android, stop the VPN using the Connect button. Do not leave the desktop system proxy pointing at a local port with no listener after quitting the client. After reconnecting, repeat the same test; reproducible results make it easier to confirm that the settings are working.
Once the test passes, keep the current working configuration as your baseline. When you later enable per-app proxy, change routing, or switch cores, change one variable at a time and repeat the same test. For advanced settings involving inbounds, outbounds, routing, and dns, see the V2Ray configuration reference. There is no need to turn a first-connection walkthrough into a full configuration rewrite.