V2Ray Setup Guide: From Subscription Import to Connection Verification

BEFORE START

Pre-flight checks: client, subscription, and system time

Before you begin, make sure the client starts normally. After opening v2rayN on desktop, you should see its main window, menu bar, or system tray icon; on Android, opening v2rayNG should take you to the configuration list. If the program exits immediately, the interface will not open, or it repeatedly reports a missing runtime, fix the installation first instead of importing a subscription. Installation files and platform guidance are available on the client download page.

The second requirement is a working subscription URL. It is usually a complete link beginning with https:// that points to an updateable node list. Copy every character from the beginning to the end; do not include explanatory text from a chat app or manually remove parameters at the end of the URL. A single link beginning with vmess:// or vless:// is a share link, not a subscription URL, and uses a different import entry. This guide covers subscription URLs first; individual share links can be added through “Import from clipboard” or a similar option.

The third requirement is accurate system time. Some protocols rely on precise time during handshakes and authentication, so a large clock difference can prevent a connection even when the node parameters are correct. Enable automatic date, time, and time zone settings, then restart the client. Also confirm that the underlying network can open ordinary websites; if the basic connection is already down, connection failures in the client log do not necessarily indicate a problem with the subscription or node.

Do not change many advanced settings during first-time setup. Keep the default local port, DNS, and routing rules, and complete one short verification path. Once the basic connection works, consult the configuration reference for inbound, outbound, routing, and DNS fields. This avoids compounding changes and makes the failing step easier to identify.

The goal of importing a subscription is not merely to save its URL, but to let the client access it, read the configuration, and generate nodes on the main screen. “Add subscription” and “Update subscription” are therefore two consecutive actions. If you add it without updating, the subscription group may exist while the node area remains empty—one of the most common first-use misunderstandings.

v2rayN desktop steps

Open the v2rayN main window and find “Subscription groups,” “Subscription settings,” or a similarly named option in the top menu. In the subscription manager, add a group and give it an identifiable note, such as “Main subscription.” Paste the complete subscription URL into the URL field. The note is only for local identification; the URL content determines whether nodes can be retrieved.

Return to the main window after saving, open the subscription menu again, and choose “Update all subscriptions” or update the new group individually. The client will request the subscription and parse its configurations. When finished, the main list will usually contain multiple entries with fields such as alias, address, port, protocol, or subscription group. Column names and layouts vary by version, so you do not need to edit each one; nodes appearing in the list means retrieval and parsing are complete.

If an error appears during the update, do not keep clicking. Check the status text or log area at the bottom of the main window and distinguish between “the subscription URL cannot be reached” and “the subscription content cannot be parsed.” The first is usually caused by an incomplete URL, inaccessible network, or temporary service outage. The second may mean you copied a webpage or login URL, or that the content is not in a format the client supports. Copy the complete URL from the provider again, replace the old one, and run one more update.

v2rayNG Android steps

Open v2rayNG, then use the top-left menu or top-right action menu to find “Subscription group settings.” Add a group, enter a recognizable name, paste the complete URL, and save it. Return to the configuration list, open the subscription actions, and update the current group or all subscriptions. When the update finishes, nodes will appear in the list; the selected entry is usually highlighted or marked with a check.

Android may restrict background network activity, battery use, or data usage. During the first subscription update, keep v2rayNG in the foreground and wait for the result instead of switching apps immediately. If the list remains empty, confirm that v2rayNG has network permission and that the current Wi-Fi or mobile network can reach the subscription URL. Even after the first successful update, it is best to update in the foreground so errors are visible immediately.

Continue only after nodes appear

The completion criterion is clear: the main screen must show at least one selectable node. Do not bulk-edit node parameters or import multiple subscription sources at this stage. Finish the remaining connection steps with one subscription group to avoid duplicate names, dead nodes, and conflicting rules. Once the list is populated, determine how the client should handle traffic.

Nodes appearing in the list does not mean browser traffic will automatically pass through the client. Proxy mode determines how traffic is split, while the system proxy or system connection permission determines whether application traffic can enter the client. Think of this as two switches: first choose which requests to handle, then let the operating system hand those requests to the client.

Start with rule mode

Common modes include rule, global, and direct. Rule mode separates direct and proxied traffic according to the client's existing rules, making it suitable for everyday use and a safer starting point for first-time setup. Global mode sends more traffic through the active node and is useful for a short comparison test when checking whether routing rules cause an access problem, but it should not be used long-term before the node is confirmed working. Direct mode pauses proxy handling or provides a baseline comparison; even with the core running, selected websites may continue using the local network.

Depending on the version, these options may be called “routing mode,” “predefined rules,” or “proxy mode.” The names differ, but the approach is the same: when you see “rules,” “bypass LAN,” or built-in client rules, start with the default rule set instead of editing custom JSON. Advanced domain matching, IP matching, inbound tags, and DNS routing can be configured later in the routing chapter of the configuration reference.

v2rayN: enable the system proxy as well

After selecting rule mode in v2rayN, open the client menu from the system tray. Find “System proxy” and choose automatic system proxy configuration or a similarly named enable option. The tray icon or menu status will usually change, indicating that compatible applications on Windows, macOS, or Linux can read the system proxy settings. If only the node is selected and the core is running while the system proxy remains off, the browser may still use its original direct route.

Some browsers and applications use independent network settings and may not follow the system proxy. For the first verification, use a familiar browser that follows system settings. Do not install multiple proxy extensions or manually change the browser proxy port. After the client connection is confirmed, handle applications that ignore system settings separately. This makes it easier to distinguish a client connection problem from an application that is not reading the system proxy.

v2rayNG: confirm connection mode and app scope

v2rayNG takes over traffic through Android's system connection interface. Keep the default routing settings for first-time use; there is no need to start with complex per-app proxy rules. If you previously changed “bypass LAN,” “per-app proxy,” or custom rules, temporarily restore a simple configuration and ensure the test browser is included. If an app is excluded by mistake, the client may show a connection while that app continues using the original network, which can look like a failed node.

There is no need to switch repeatedly between global and rule modes at this stage. Keep rule mode fixed for one connection and browser test. If the target page fails while the log shows that a connection was established, use global mode for one short comparison. If global works but rule mode does not, the problem is more likely in routing rules; if neither works, return to the node, subscription, network, and system time.

The subscription list is ready and the proxy mode is set, so choose one node as the active outbound. For the first connection, do not chase the most complex-looking protocol or name, and do not test many nodes at once. Start with a clearly sourced node whose parameters were generated by the subscription, complete the full path, and switch nodes only if actual access results require it.

Set an active server in v2rayN

Return to the v2rayN main list, click the target node, and use the context menu, Enter key, or top menu to set it as the active server. The selected state is usually shown by a color, icon, or status-bar label. Confirm that the system proxy is enabled as described above. The client will start the relevant core and generate a runtime configuration for the active node.

After the connection starts, watch the log window first. Under normal conditions, you may see configuration loading, the local listening port starting, and the core running. A quiet log is not necessarily a problem; many clients produce no continuous output when there are no new requests. Focus on repeated connection refusals, name-resolution failures, authentication failures, port conflicts, or configuration parsing errors. When a clear error appears, record the first meaningful one rather than capturing many repeated lines.

If the local port is reported as occupied, another client, an old process, or a browser proxy tool may be using it. Fully exit other similar programs, confirm from the taskbar tray that an old v2rayN instance has closed, and restart. Avoid changing multiple ports during first-time setup. Only change the local listening port when the conflict cannot be cleared, and update any applications that depend on that port.

Connect in v2rayNG

In the v2rayNG configuration list, tap a node to make it active, then tap the circular connection button on the main screen. Android will show a system connection permission dialog the first time. Approve it; the status should change from disconnected to connected, and a connection indicator should appear in the system status bar. If permission was denied, the client cannot handle application traffic, so tap connect again and approve it.

Once the connection button shows that it is running, do not exit the client immediately. Wait a few seconds and open the log or live log page to confirm that no errors are repeating rapidly. Then switch to the browser for verification. Some systems restrict background apps after they have been inactive; if the connection works at first but drops soon after locking the screen or switching apps, check v2rayNG's background and battery permissions instead of repeatedly reimporting the subscription.

Use latency tests only as a screening aid

Clients often offer latency, connection, or batch tests. These can help exclude nodes that do not respond at all, but they cannot prove that every website will load. The test target, protocol, and path may differ from an actual browser request; a reported value only means that the test path responded at that time. Real website access and client logs remain the final basis for evaluation.

If the first node fails, switch to another node in the same subscription group for comparison. After each switch, wait for the old connection to close and the new configuration to load before opening a new browser page. Rapid switching mixes results from multiple nodes in the log and makes diagnosis harder. Change one variable at a time: switch nodes first and test; if all nodes fail, then check mode, time, and network.

Check three things together: browser access, the client's current status, and runtime logs. Looking at only one can lead to the wrong conclusion. A client showing connected only means its local service has started, not that the remote node is reachable; opening a website that is normally direct-accessible does not prove the request used the active node.

Run two groups of website tests first

Keep the client connected and open a new browser window. First visit a familiar website that normally loads to confirm that basic browsing still works with the proxy enabled; then visit a target page that should be handled by the active proxy rules. The page should load within a reasonable time and remain stable after refreshing. If text appears but images, scripts, or login requests fail, the connection may not be fully functional; return to the logs and check the relevant domain or connection error.

During testing, disable other browser proxy extensions and independent network tools to prevent traffic from being rewritten twice. Do not rely only on a tab that has been open for a long time, since cached content can make an old page appear usable. Open a new window, enter the complete URL, and refresh to trigger a more accurate new request.

Check the client status

In v2rayN, confirm that the active server is still the node you selected, the system proxy remains enabled, and the tray menu has not unexpectedly switched back to direct mode. If the browser produces no log entries at all, first suspect that the system proxy is off, the browser does not follow system settings, or an extension has overridden the proxy configuration.

In v2rayNG, confirm that the main screen still shows an active connection and that the system status-bar indicator remains visible. Check that the test browser is included in the per-app scope. If the connection stops immediately after switching to the browser, check whether the system is restricting v2rayNG's background activity. If the connection remains but no requests appear, focus on routing mode and per-app settings.

Use logs to identify the failing layer

Logs show which outbound handled a target request and where the connection failed. For name-resolution errors, restore the default DNS settings and test again; for timeouts or refused connections, try another node in the same subscription; for authentication or handshake errors, update the subscription instead of continuing with outdated parameters; for configuration parsing errors, undo recent manual changes to routing or core settings.

Do not reinstall the client because of one occasional timeout. A webpage usually makes many requests at once, and a failed image or analytics domain may not affect the main page. Look for repeated errors of the same type and whether the main page loads reliably. Diagnose these four stages separately: can the subscription update, can the node start, can app traffic enter the client, and can the remote request return? This makes troubleshooting much more direct.

After the connection works

Once browser access and logs look normal, keep the current node and rule mode. On desktop, if you want to use v2rayN after startup, review its startup options, but first confirm that system proxy behavior is what you expect. On Android, make sure background operation will not frequently interrupt the connection. You do not need to add the subscription again at every launch; update the existing group when needed.

If node names or counts change after a subscription update, that is normal list refresh behavior. When the active node stops working, update the subscription first, then choose another node from the same group. For mainland China and outside-China domain routing, DNS resolution, inbound ports, or custom routing, open the configuration reference and adjust one section at a time. Keep a copy of the currently working configuration and change only one part per test.

QUICK TROUBLESHOOTING

When the connection fails, troubleshoot in order

When first-time setup fails, the most effective approach is not to change everything at once, but to check each layer along the request path. The order below starts with the subscription source and ends with application traffic. Retest after each step; once a step restores access, stop changing advanced settings further down the chain.

Troubleshooting information worth keeping

For deeper analysis, record the client name and version, operating system, time of the issue, selected proxy mode, whether the subscription updates, and the first meaningful error in the logs. Remove the subscription URL, node addresses, user identifiers, and authentication parameters before sharing logs. “It doesn't work” is rarely enough to tell whether the fault is in the subscription, core, system proxy, or target network; organizing details by layer can greatly shorten diagnosis.