Prepare the client and a valid subscription URL
Before starting, make sure the client opens normally and have the subscription URL provided by your service provider ready. A subscription URL is usually a link beginning with https://. It lets the client retrieve server configurations, routing information, and future updates. A subscription is not a single server name or an installation file; if you received a standalone share link, the import path will differ slightly from this guide.
Use v2rayN on desktop devices and v2rayNG on Android devices. Their core components and setup logic are similar, but menu locations, connection buttons, and system permission flows differ. Before your first setup, identify which client you are using, then follow the “desktop” or “Android” instructions for each step. Menu names may change slightly after an update, but core entries such as “subscription groups,” “update subscription,” “routing settings,” and “connect” usually remain available.
Also check that the device clock is correct. TLS connections rely on system time to determine certificate validity, and a large time discrepancy can cause a handshake failure. Make sure the current network can open ordinary web pages as well, since the client cannot fix a disconnected local network, an unauthenticated Wi-Fi network, or disabled mobile data. Completing these checks first narrows the scope of later troubleshooting.
This page covers only the settings needed to establish a basic connection. The terms VMess, VLESS, TLS, REALITY, Xray, and V2Fly are explained in the glossary. Custom DNS, complex routing, TUN mode, and multi-subscription management are later-stage settings; read Advanced configuration after the basic workflow succeeds.
Import a subscription and generate the server list
The goal of importing a subscription is not to connect immediately, but to let the client retrieve a set of server configurations to choose from. After a successful import, the main interface should show entries such as server names, address types, or protocol types. Confirm that the list has been generated before choosing a proxy mode; clicking Connect while the list is empty will not produce a useful result.
v2rayN desktop instructions
Open the v2rayN main window and find “Subscription groups” or a similarly named subscription management entry in the top menu. In the subscription group settings, choose to add a new group. Give it an easy-to-recognize name, such as “Common subscriptions,” then paste the complete subscription URL into the address field. The name is only for local identification and does not change the server configuration.
Save the group and return to the main window. Open the subscription menu again and choose “Update all subscriptions,” or update the group you just added. When the update finishes, the server list will appear in the main window. If older entries are already present, look for new entries or a changed update time rather than relying only on cached content. Some versions show parsing results at the bottom of the window or in the log area; messages such as “Update complete” or “New configuration added” indicate that the operation has finished.
If no servers appear after the update, return to the subscription group settings and check the beginning and end of the URL, including whether spaces were added during copying. Do not use a web console URL, payment page URL, or single-server note as the subscription URL. After confirming the address, update it again. If the client says the returned content cannot be recognized, ask the subscription provider whether the link format is supported by the current client.
v2rayNG Android instructions
Open v2rayNG, then use the main-screen menu to enter “Subscription group settings.” Tap the add button, create a subscription group, enter its name and subscription URL, and save it. Return to the main screen, open the menu in the upper-right corner, and choose “Update subscriptions.” The client will read the saved URL and add the parsed server entries to the main list.
Android may retain both older manually added configurations and those generated by the new subscription. To avoid choosing the wrong entry, identify new items by their group name. If the list is long, there is no need to open every protocol detail; first confirm that at least one item belongs to the group you created. When the provider changes its servers later, update the subscription again instead of creating the same group from scratch.
Updating a subscription only synchronizes configurations. It does not automatically decide which apps use the proxy, nor does it necessarily select a suitable server. The next step defines how traffic is handled. For a first setup, start with the client’s standard routing mode and avoid changing DNS, FakeDNS, or custom rules before a successful connection.
Choose a proxy mode and basic routing
The proxy mode determines which traffic the client handles, while routing rules determine how the client chooses an outbound route after taking over that traffic. They often appear in different menus, so “server connected” alone does not prove that the browser is using the connection. During basic setup, start with the client’s standard rules to keep the access path simple, then fine-tune routing after the connection works.
Desktop: combine routing rules with the system proxy
In the v2rayN main window or settings menu, find “Routing settings.” If the client provides predefined basic rules, choose a rule set intended for general use during initial setup instead of creating new rules immediately. Rule modes usually distinguish direct and proxied connections; the client selects an outbound route based on domains, addresses, or rule order. The goal here is to use an existing default rule set, not edit matching conditions one by one.
After selecting the routing rules, desktop applications must send their traffic to v2rayN. The most common method is “Set system proxy.” This is usually available in the tray menu or the system proxy menu in the main window, but it is best enabled formally after selecting a server and starting the core in the next step. For now, locate the entry and make sure a state such as “Clear system proxy” is not selected.
The system proxy works for browsers and applications that follow the operating system’s proxy settings. Some applications have independent network settings and may ignore the system proxy; do not try to solve this difference by repeatedly changing routing during the initial connection. Verify with a standard browser first, then decide whether deeper traffic interception is needed for a specific app.
Android: keep the basic routing settings
v2rayNG takes over device traffic through the system connection interface, so there is no separate desktop-style “Set system proxy” button to find. In Settings or Routing settings, keep the client’s basic rules during initial use. If the subscription provider specifies a compatible routing scheme, follow those instructions; otherwise, avoid enabling several experimental options at once, as they add more variables to DNS and routing decisions.
Android may also offer options such as “Bypass LAN” and “Per-app proxy.” During basic verification, let a standard browser participate in the connection test instead of creating a complex app exclusion list first. If per-app proxy rules are configured incorrectly, the client may show as connected while an excluded browser bypasses it entirely, which can be mistaken for a failed server.
After this step, the client has a clear basic traffic-handling method, but the connection has not yet been established. Next, select a server from the subscription list, start the core, and send system traffic through the client. If something fails later, you can distinguish a server connection failure from traffic that never entered the client.
Choose a server and establish the connection
Return to the server list and choose an entry from the subscription group you just imported. During initial setup, there is no need to guess at complex parameters from a server name, and you should not test several servers at once. Connect to and verify one entry first; if it fails, try another entry from the same subscription. This helps determine whether the issue is limited to one server or affects the client settings.
v2rayN desktop connection flow
Click the target server in the main list to make it the active configuration. Depending on the version, selection may require a double-click, right-clicking and choosing “Set as active server,” or using a shortcut. After selection, the active server usually shows a color change, checkmark, or status-bar message. Confirm that the active configuration name matches your selection, then check whether the client core has started.
Next, open the system proxy menu and choose “Automatically configure system proxy” or a similarly named enable option. v2rayN is responsible for two things: the core connects to the server, while the system proxy sends traffic from apps that follow system settings to the local proxy port. If you start only the core without setting the system proxy, the main window may run normally while the browser continues using its original direct path.
If the window is minimized, find the v2rayN icon in the system tray and check the current server and system proxy status. Do not switch rapidly between multiple proxy options; wait for the status to settle after each change before testing in a browser. When exiting the client, confirm whether the system proxy is restored automatically so the browser does not later point to a stopped local port.
v2rayNG Android connection flow
Tap the target entry in the server list so its left side or title area shows it as selected. Then tap the connect button on the main screen. The first connection displays a system network permission dialog; approve it so the client can establish the local connection interface. This is a system-level connection permission, not a subscription account login.
After the connection is established, the main-screen button changes state and the system status area shows a connection indicator. Do not exit the client process immediately; keep v2rayNG running and continue to verification. Power-saving policies on some devices restrict background network activity. If the connection works at first but drops soon after switching apps, check the system’s background activity restrictions for v2rayNG.
A connection indicator only shows that the client has started working; it does not by itself prove that the target website is reachable. Protocol handshakes, server status, routing results, and DNS resolution can still affect the final outcome. The last step must therefore check both client status and actual access instead of relying on a single icon.
Verify that the connection is working
Verification has three layers: whether the client keeps running, whether browser traffic enters the client, and whether the target loads normally. Checking only one can hide problems. For example, the client may stay running while the system proxy is disabled, or the browser may read the proxy settings while the selected server cannot complete the connection.
Check the client status first
Keep the current server unchanged and watch whether the client repeatedly falls from connected to stopped. On desktop, check the bottom of the main window, tray status, or log area for persistent connection failures. On Android, check the main-screen connection status and confirm that it does not disconnect immediately after authorization. An occasional retry does not necessarily mean overall failure; focus on whether the same error keeps appearing while all access attempts fail.
Then test actual access in a browser
Open a new browser tab and first visit a regular page that normally opens directly to confirm that the local network is working. Then visit the target page that should be tested through the current proxy path. Use a new tab or reload the page so cached content does not make an old result appear successful. If the page loads reliably, open one of its subpages to confirm that the cached home page is not the only content available.
On desktop, if every page behaves exactly as it did before connecting, return to the system proxy menu and confirm that it is enabled. Also check whether the browser uses an independent proxy extension or custom network settings. On Android, if one app cannot connect while the browser works, check whether the app is excluded by per-app proxy rules instead of immediately changing protocol parameters.
Finally, check the logs
Return to the client’s log area while testing access. If the action creates new connection records, traffic has entered the client. If the logs do not change at all, the issue is more likely related to the system proxy, app exclusion rules, or the browser’s independent settings. If new records appear but repeatedly show connection timeouts, handshake failures, or domain resolution errors, check the current server, device time, and DNS settings respectively.
After basic verification succeeds, do not change settings broadly at once. Keep the working server, subscription group, and routing mode, then close and reopen the browser to confirm that the result is reproducible. You can later test other servers in the same subscription and gradually add routing rules for specific use cases.
Troubleshoot by stepping back through each layer
If verification fails in Step 4, do not reinstall the client, delete the subscription, change DNS, and alter routing at the same time. Changing several conditions makes the source harder to identify. Check each layer from the local side outward, in this order: subscription content, active server, client connection, system traffic, and target access.
Subscription updates successfully, but the list is empty
Open the subscription group settings again, confirm that the complete subscription URL was saved, and update it once more. If the client explicitly says the format cannot be recognized, confirm that the link type matches the current client. Do not manually edit the encoded content returned by the subscription.
The list exists, but the current server cannot connect
First confirm that the device clock and basic network are working, then switch to another server in the same subscription. If only one entry fails while others work, you usually do not need to rebuild the entire client configuration.
The client shows as running, but the browser is unchanged
On desktop, check that the system proxy is enabled and that the browser has no independent proxy configuration. On Android, check that the system connection is still active and that the browser has not been excluded by per-app rules.
Even regular web pages fail after connecting
Stop the connection first and confirm that basic network access returns, then choose another server. If access still fails after stopping, check whether the system proxy was restored on desktop. If access returns immediately after stopping, continue checking the current server and routing rules.
In client logs, “timeout” usually means the connection did not complete within the allowed time; “handshake” messages indicate that negotiation did not finish; and “DNS” messages point to domain resolution. Error names help narrow the scope, but do not copy complex configurations from online sources without understanding them. Check the relevant terms in the glossary, then read the routing, DNS, TUN, and multi-subscription sections in Advanced configuration.
Next: routing, DNS, and multi-subscription management
Once the basic connection is stable, decide whether to adjust routing rules, DNS policies, TUN mode, or subscription groups based on the apps you use. Advanced settings should build on a reproducible basic configuration.