V2Ray Setup Guide: From Subscription Import to Connection Verification

Before starting setup, install the graphical client for your device and prepare a working subscription URL. Use v2rayN on desktop and v2rayNG on Android. If the client is not installed yet, visit the download page and choose the version for your platform. If it is already installed, simply open it; there is no need to change the core directory or create configuration files manually.

A subscription URL is usually a single link beginning with https://, provided by your service provider. Copy it in full from start to finish. Do not copy only the truncated portion shown in a browser, and do not include spaces, line breaks, or Chinese punctuation before or after the link. A subscription is different from an individual VMess, VLESS, or Trojan share link: a subscription can update a group of servers at once, while a share link imports one configuration. This guide focuses on subscriptions because updating and switching servers is more straightforward.

If the client already contains older servers, first check which subscription group they belong to instead of deleting everything. When adding a subscription, use an easy-to-recognize group name, such as the service source, so failed updates are easier to identify later. Once ready, the goal is simple: save the subscription in the client and make sure the server list actually shows selectable entries.

In the v2rayN desktop client, open the subscription group or subscription management entry and create a group. Enter an easy-to-recognize name in the notes or name field, then paste the complete URL into the subscription URL field. Save it, return to the main window, and choose “Update subscriptions” or the equivalent group update command. When the update finishes, the main server list should contain multiple entries, commonly showing an alias, address, port, transport, and subscription group.

In v2rayNG on Android, open the top-left menu and go to subscription group settings. Tap the add button, enter the group name and subscription URL, and save. Return to the server list and choose Update subscriptions from the menu. After a successful update, the list will show servers parsed from the subscription. Do not repeatedly tap the connect button yet. First confirm that the list is not empty and that the new entries belong to the group you just created.

If no servers appear after an update, reopen the subscription editor and check that the URL is complete, that no extra spaces were copied, and that the device can access the network. Save it and perform one manual update. Do not create multiple identical groups after a failure, or the list may contain many duplicates once it recovers. If your service provider specifically requires a custom user agent, request headers, or subscription conversion rules, that is beyond this quick start. See the advanced setup guide for subscription management.

Once the server list appears, choose any fully configured server as a candidate. Do not worry yet about which protocol is best. The priority for beginners is to get the workflow working. Next, decide how much traffic the client should handle by choosing a proxy mode.

Next Choose a proxy mode →

The proxy mode determines which connections the client handles. Menu names vary slightly by version, but they generally fall into three categories: rule-based routing, global proxy, and direct connection. For first-time setup, rule-based routing is recommended. The client uses built-in or custom rules to decide where requests go: traffic that needs a proxy uses the selected server, while the rest stays direct. This is a practical daily starting point and makes it easier to verify both types of access.

In the v2rayN desktop client, choosing rule-based routing is only part of the setup; you must also check the system proxy status. Ordinary browsers and apps that follow system proxy settings need the client to enable the system proxy before they can use it automatically. If the client is connected but the system proxy is off, the core may be running while the browser continues using the original network. Keep the system proxy status consistent with your current purpose. Before closing the client, it is also a good idea to restore the system proxy state so the browser does not point to a stopped local port after the next startup.

In v2rayNG on Android, the connection takes over traffic through the system VPN service. The first launch displays an authorization prompt; approve it before a local connection can be established. The client may also offer per-app proxying to specify which apps use the proxy and which bypass it. For first-time setup, do not build a complex app list yet. Use the default scope for verification, then see the advanced setup guide for per-app rules, routing priority, and custom outbounds.

After choosing a mode, avoid changing DNS, routing rules, and several low-level parameters at the same time. Change one variable at a time so problems are easier to isolate. For now, remember three points: use rule-based routing, enable the system proxy on desktop when needed, and authorize the VPN service on Android. Next, return to the server list, set one server as the active configuration, and start the connection.

Next Connect to a server →

Return to the server list and click or tap a fully configured server to make it active. In v2rayN, the current server is usually indicated by highlighting, color, or a menu state. After double-clicking the server or choosing “Set as active server,” start the service from the main interface or system tray. In v2rayNG, tap a server in the list until a selection mark appears beside it, then tap the circular connection button on the main screen.

After starting, first watch the client’s own feedback. On desktop, the core status should change and the tray icon or status bar should show that the service is running. On Android, the connection button changes state and the system status area shows a VPN service indicator. This only confirms that the local proxy service has started; one icon cannot prove that a target webpage is reachable, so an actual test is still required.

If the service stops immediately after starting, first check the client notification or the error at the end of the log. Common causes include incomplete server fields, a local listening port already used by another program, a large system-time offset, or a client version that cannot recognize a configuration from the subscription. Do not keep clicking the start button rapidly. Stop the service, choose another server from the same subscription, and start again. This quickly shows whether the problem affects one server or the client as a whole.

If only one server fails while others start successfully, keep using a working server to finish the guide and later ask the subscription provider about the faulty entry. If every server fails to start, close other proxy clients that may be using similar local ports, then reopen the current client. For more complex port conflicts, core logs, and transport parameters, continue with advanced setup and troubleshooting.

Once the client shows that the service is running and both the active server and proxy mode are set, move to the final step. Do not rely only on the client status text. Use a browser to test proxy access and ordinary direct access separately, confirming that the entire path is working.

Next Verify that it works →

Keep the client running and open a new browser window. First visit a page that normally requires a proxy. Do not rely only on an existing tab, as it may use cached content or a connection established earlier. A new window triggers fresh DNS lookups and network connections more directly. Once the page loads, refresh it and open an image or subpage to confirm that you did not merely load a locally cached homepage.

Then visit a website that normally uses a direct connection and check that the page, images, and sign-in status work normally. In rule-based routing mode, both types of access should work: requests requiring a proxy use the active server, while requests matching direct rules keep their original route. If the proxy page works but ordinary websites fail, the issue is more likely routing or DNS. If ordinary websites work but the proxy page fails, check the active server, subscription configuration, and system proxy takeover first.

You can also check the client connection log for new access records appearing continuously. Connection-establishment entries show that browser traffic is reaching the client, but beginners do not need to interpret every line of the underlying protocol. The basic setup is complete when pages load as expected, switching servers changes the result accordingly, and the system network returns to normal after the client stops.

After verification, keep the current server as your active daily configuration. When the subscription changes, use the update subscription function rather than repeatedly deleting and re-adding the URL. To switch servers, select another entry and set it as active; you usually do not need to recreate the subscription group. If a client update moves the controls, keep following the same decision order: subscription first, mode second, connection third, and verification last.

When something goes wrong during quick setup, the most effective approach is not to change many parameters at once, but to check the workflow in reverse order. Confirm that the client is still running, then verify the active server, and finally check the proxy mode and subscription update time. After each change, test again in a new browser window to avoid interference from cache and old connections.

If these checks do not locate the problem, record the client name, operating system, the step where the failure occurred, whether only one server is affected, and the error type at the end of the log. Do not publish the subscription URL or complete server details. Bring these specific symptoms to the advanced setup guide; this is more likely to reveal the cause than repeatedly reinstalling the client.