Follow four steps in order: import a subscription, choose a proxy mode, connect to a node, and verify access. A first-time setup usually takes about ten minutes.
Check these three basics first to make the remaining steps easier to troubleshoot.
Use v2rayN on desktop devices and v2rayNG on Android devices. The first launch may ask for network access; follow the system prompts to grant permission. If the client is not installed yet, visit the installation package page and choose the version for your platform. After installation, return here and start with subscription import.
A subscription URL is usually provided by your service provider and starts with https://. Copy the entire link, including any parameters at the end. Do not mistake the sign-in page URL in your browser’s address bar for the subscription URL. Subscription links may contain account identifiers, so store them only on your own devices and in a password manager.
Your device still needs a working base network before the client can establish a connection. Close any older proxy tools, then use a browser to open a website that normally works without special settings. If regular websites do not load either, restore the Wi-Fi, wired, or mobile connection first. This separates local network problems from client configuration issues.
Once all three conditions are met, keep the subscription URL ready to copy and move to step one.
The goal of subscription import is not merely to save a link. It lets the client read the link and generate selectable nodes in the server list.
Open the v2rayN main window and find “Subscription groups” or a similar subscription management entry in the top menu. Choose to add a subscription group, then enter a name and URL. The name is only for local identification; use a service name, purpose, or region. Paste the complete subscription URL into the address field, check that it has no leading or trailing spaces, and save it.
Saving the group only records the subscription source; you must update it next. Return to the “Subscription groups” menu and choose to update the current subscription, or update the new entry from the group list. The client will request and parse the server configuration. When the update finishes, one or more entries should appear in the main server list, commonly showing an alias, address, port, protocol, transport, and subscription group.
If the list already contains other servers, check the “Subscription group” column to confirm that the new entries belong to the group you just added. Do not judge the import only by node names, since different subscriptions may use similar names. Once servers appear under the new group, this step is complete; there is no need to edit each node’s protocol fields yet.
Open v2rayNG and go to subscription settings from the side menu. Tap the add button, enter an easy-to-recognize remark, paste the complete subscription URL into the address field, and save it. Return to the subscription list and confirm that the new entry is enabled. Then choose “Update subscriptions” and wait for the notification that the update is complete.
After a successful update, return to the client home screen. The node list will show the servers parsed from the subscription, usually with node names; the selected item will appear highlighted. Do not repeatedly tap the connect button yet. First confirm that the list contains entries and that the update did not report a parse error, unavailable URL, or empty response.
A successful result has two parts: the subscription group is saved in the client, and the server list contains nodes belonging to that group. If you see only the group name without server entries, the client has not successfully retrieved or parsed the subscription. If servers are already present, do not add the same URL again, as this can create duplicate groups and nodes.
A subscription is not a one-time file import. When the service provider changes its nodes, update the existing group instead of creating another group with the same name. If all nodes later become unavailable, update the current subscription first, then determine whether the issue is connection-related. The server list is ready; next, decide which traffic the client should handle.
The proxy mode determines how the client captures application traffic; routing rules determine whether captured requests use the proxy or stay direct.
For a first setup, use “system proxy + rule-based routing.” The system proxy sends applications that follow the operating system’s proxy settings through v2rayN, while rule-based routing chooses the exit based on domains, addresses, or predefined rules. This combination has a clear scope, works well for browser testing, and makes it easy to check whether the system proxy is enabled.
“Global” generally sends most captured traffic through the current node. “Rules” separates direct and proxied traffic according to routing rules, while “Direct” bypasses the proxy. Different versions may use labels such as “Global,” “Bypass LAN and mainland China addresses,” or “Clear system proxy.” You do not need to study every rule yet. Choose a common rule mode offered by the client and make sure the system proxy is not disabled.
Find “System proxy” in the v2rayN status bar or system tray menu, then choose the option to configure or enable the system proxy. The status text should change from disabled to configured. Next, open “Routing” or “Routing settings” and choose an existing rule-based routing profile. Save it, return to the main window, and check that the bottom area shows both the current system proxy status and routing mode.
If you want only one proxy-aware application to use the client, you can leave the system proxy disabled and enter the local proxy port manually in that application. However, this requires checking the protocol type and listening port, so it is not the best first-time path. This guide uses the system proxy to verify the complete connection chain before moving to per-application settings.
When v2rayNG connects, it uses the system network connection configuration to capture traffic, so it does not have exactly the same “Set system proxy” button as the desktop client. Open Settings or Routing settings and choose one of the client’s rule modes. For a first setup, leave other advanced options at their defaults. Do not change local DNS, per-app proxying, traffic detection, and transport settings at the same time; otherwise it will be difficult to identify the cause of a failure.
When you tap Connect, the system may show a network connection authorization dialog. Confirm that the app name is correct and allow the connection. This permission usually appears only on the first use or after system configuration changes. Authorization does not prove that the node works; it only allows the client to create a local traffic-capture tunnel. Confirm the actual connection in the next step using the button state and runtime logs.
Some desktop applications do not read the system proxy. Game launchers, command-line tools, and software using an independent network stack may also bypass it. In that case, consider TUN mode to capture traffic at a lower level. TUN involves a virtual network interface, DNS handling, administrator privileges, and routing priority, so it should not be enabled before the basic connection is verified.
First use the system proxy to confirm that the subscription and node work. Only switch to TUN if a specific application still cannot be captured. For system-level guidance on TUN, DNS, and platform-specific settings, read the complete documentation. This page continues with the basic mode and moves on to node selection and connection.
After setting up the subscription and proxy mode, select an active server and check whether the core successfully loads its node configuration.
Node names often describe a region, route, or purpose, but the name itself says nothing about current connection quality. For the first test, choose any ordinary node from the subscription list; there is no need to test every entry. If the service provider recommends a route, use that one first. Otherwise, a relatively nearby node is usually a practical choice for the initial test.
Do not switch rapidly between multiple nodes while connecting. Each change of active server requires the client to reload the configuration and establish a new connection, while old browser connections may remain temporarily open. Frequent switching mixes several startup records in the logs and makes it harder to tell whether a particular node actually failed.
Click the target node in the server list, then choose “Set as active server” from the context menu. Some versions also let you double-click to make it active. The active node usually shows a color, icon, or row-state change. After confirming the selection, start the service from the system tray menu or main interface, and keep the system proxy enabled as configured in the previous step.
Then check the status bar and log area at the bottom of the main window. A normal startup shows records for loading the configuration, starting the core, and opening the local listener, while the status bar keeps the active server name. If the logs immediately report a port conflict, invalid configuration field, or failed process start, the connection is not ready for verification. Fix that error before refreshing the browser.
If the log area is not visible, open the log window from the menu or expand the bottom pane. Logs show how far the program got; you do not need to understand every line. Focus on whether the latest lines contain recurring errors and whether the same error repeats at every startup. A single retry does not necessarily mean failure; repeated errors of the same type deserve attention.
Tap the target node in the home-screen node list to select it, then tap the connection button in the lower-right corner. If the system shows an authorization prompt on the first connection, grant permission. The button state will change during connection, and the system status area will show an active network connection indicator. Return to the node list and confirm that the node remains selected. When the uptime or traffic counters begin updating, the client is working.
If the client immediately returns to a disconnected state, open Logs from the side menu and review the latest startup record. Common causes include changed node parameters, an outdated subscription, a significant device clock offset, a network change, or a temporarily unreachable node. Update the existing subscription once, then select the node and reconnect. If it still fails, compare it with another node from the same subscription.
When the client shows “Connected,” it usually means that the local traffic-capture tunnel and core process have started. It does not mean every target website will open. Remote node reachability, DNS resolution, and whether the application follows the system proxy must be verified next. Keep the client running, do not exit its tray process, and do not change the proxy mode yet.
The key is to distinguish between “the client has started,” “the application is being captured,” and “the target request succeeds.”
Keep the client connected, close the old pages used for the preliminary check, and open a new browser window. First visit a website that normally works directly to confirm that proxy settings have not interrupted the base network. Then visit the target website that should use the current node. A new window reduces the influence of old connections, cached data, and background requests from already-open pages.
If both types of websites open normally and the client logs show new connection records during the visit, the subscription, active node, proxy mode, and application capture are working together. There is no need to adjust protocol parameters. Keep the current node as a regular server and update the subscription when needed.
When a page will not open, refresh it and check whether the logs show a new entry. If the logs do not change at all, the problem is more likely in the application-capture stage: on desktop, check that the system proxy is still enabled; on Android, check that the client connection is still running. You can also fully exit and reopen the browser so it does not reuse a session created before the connection.
If the logs show the target domain or connection request but then repeatedly report timeouts, remote refusal, or handshake failures, the traffic has reached the client. Focus on the node, subscription freshness, and protocol parameters. Update the existing subscription first, then switch to another node in the same group. Change one condition at a time so the results remain comparable.
If some websites work while others fail, the basic connection is usually established. The difference may come from routing rules, DNS resolution, or the target service itself. Do not reinstall the client or delete every subscription. Record the failed sites, current routing mode, and relevant log lines, then continue by issue type in Troubleshooting.
This order works from the outside in and avoids changing several settings at once. If a step restores normal behavior, stop modifying settings and verify again. For device time, port conflicts, DNS, TUN, or complex routing, consult the relevant section of the complete documentation.
Keep the setup simple. Subscription updates, node switching, and log checks cover most everyday use cases.
When node names, addresses, or parameters change, update the existing subscription group. Afterward, confirm that the active server still exists. If the original node was removed, choose one from the updated list. Adding the same URL repeatedly only makes the list harder to manage.
Set the new node as the active server, wait for the client to reload, then test it in a new browser window. A brief interruption during the switch is part of rebuilding the connection; do not click several nodes in succession.
On desktop, disable the system proxy or stop the service from the tray menu before exiting, then close the client process. On Android, use the connection button to disconnect. This leaves the system network state clearly restored to a direct connection.
When something goes wrong, record the client name, current mode, node group, time of occurrence, and latest log message. Clear context is more useful for diagnosis than repeated reinstalls and makes it easier to find the right branch in Troubleshooting.
The basic workflow ends here. See the complete documentation for platform installation, TUN, DNS, and routing details; see Troubleshooting for specific errors and common symptoms.