Step 1: Import a subscription
Before you start, get a valid subscription URL from your service provider and make sure you can access regular websites on your current network. A subscription is usually a complete URL that the client uses to retrieve server configurations. It is not the URL for an account dashboard or payment page. Copy the link without any surrounding instructions, quotation marks, or line breaks. A subscription may contain account credentials, so never share the full URL in public screenshots, chats, or troubleshooting posts.
v2rayN: Create a group, then update it
Open the main window, find the subscription group menu, and select Subscription Group Settings. Add a group, give it a recognizable name, paste the subscription URL into the address field, and save. This only saves the subscription source; the server list may not change yet. Return to the subscription menu and update the group. Some versions offer separate options to update through or without the proxy. Start with the option that works on your current network.
If you don’t have a working proxy yet, don’t keep retrying updates through the proxy just because an update failed. That can create a loop: you need the subscription to connect, but need a connection to update the subscription. If your provider requires specific network conditions for updates, follow their instructions or ask for a usable single-server share link. When the update finishes, open the group you created and confirm that server details—such as names, addresses, and protocols—appear, rather than just the group name.
v2rayNG: Save the URL, then update the subscription
Open Subscription Settings in the side menu, or the equivalent option in your version. Tap Add, enter a name and URL, then save. Return to the main list and choose Update Subscription from the menu. Check the status message and whether the list refreshes. If you have multiple groups, make sure the right one is selected so you don’t mistake older configurations in another group for the imported servers. The menu location may vary by version, but saving a subscription URL and retrieving server configurations are separate actions.
For a single share link starting with vmess://, vless://, trojan://, or ss://, copy the entire link and choose an option such as Import from Clipboard. Importing a single link usually adds one configuration directly; it does not create a subscription that can be updated later. QR code imports work similarly: check the configuration fields after scanning, since successful scanning doesn’t mean the server is reachable.
Before moving on: Make sure the target group contains at least one selectable server configuration. If the list is still empty, check whether the URL has expired, whether the update message reports a parsing error, and whether the correct group is selected. Don’t keep adding duplicate groups; keep one source and troubleshoot it first. For more details, see subscription and installation troubleshooting in the Help Center. For the difference between subscriptions, nodes, and share links, see the quick glossary.
Step 2: Choose a proxy mode
Once configurations are available, decide which traffic the client should handle, then how that traffic should be routed. These are separate settings: system proxy or VPN mode determines which traffic enters the client; routing presets send that traffic direct, through the proxy, or elsewhere. Changing the routing mode alone doesn’t mean every app is using the client. Enabling traffic interception alone doesn’t mean every site should follow the same route.
v2rayN: Start with the system proxy
Find System Proxy in the main window or tray menu. For your first setup, choose Auto-configure System Proxy. This directs requests from apps that honor the system proxy settings to the local proxy, making it a good starting point for browser tests. Some apps have their own proxy settings or ignore the system proxy, so this won’t route traffic from every program. For now, avoid running other proxy tools at the same time; they may overwrite the system proxy settings.
Next, open the routing options and start with the client’s Bypass LAN and mainland China preset, or an equivalent option. This keeps LAN traffic and common sites in mainland China on a direct connection while routing other traffic according to the preset. Names and rules vary by version, so check the setting description. Global proxy can help briefly test whether routing rules affect a particular destination, but it shouldn’t be your first attempt to fix every connection issue. There’s no need to enable broader traffic interception, such as TUN, during initial setup.
The local SOCKS and HTTP ports are entry points provided by the client on your device, not ports on the remote server. Common defaults are SOCKS 10808 and HTTP 10809, but check your current settings. If automatic system proxy configuration is enabled, you usually don’t need to enter the same ports manually in your browser. Mixing automatic and manual settings can make it harder to tell what needs restoring after you stop the client.
v2rayNG: Check VPN mode and app scope
In Settings, confirm that VPN mode is enabled rather than proxy mode, which only provides local ports and doesn’t automatically route traffic from other apps. Then open the routing settings and start with a preset that bypasses the LAN and common local sites. If you’ve enabled per-app proxying, check whether the selected apps are proxied or bypassed, and confirm that your test browser is in the intended scope. For an initial setup, leave per-app filtering off to reduce variables.
For now, leave DNS, sniffing, and custom rules at their defaults. Don’t combine advanced settings from multiple guides. A domain taking the wrong route may be caused by rule order, DNS results, or app scope—not just the protocol. Before moving on, note the traffic mode and routing preset you selected. Use them as a reference during testing. For more on protocols and cores, see the protocol reference; first, get a basic connection working.
Step 3: Connect
You now have a configuration and a traffic entry mode, so select a server and try connecting. Start with the values imported from the subscription. Don’t change the address, port, user ID, transport, or security settings to “optimize” them. For VLESS with REALITY in particular, the server name, public-key fields, and other security parameters must match the server. Changing any of them at random can cause the handshake to fail.
v2rayN: Set a server as active
Select a server in the list and choose Set as Active Server from the right-click menu, or use the equivalent option in your version. Some versions also support double-clicking; follow the interface prompts. Check that the active marker moves to the selected row, then open the log and confirm that the core hasn’t exited immediately. Also make sure the system proxy is still enabled: selecting a server and enabling the traffic entry point are separate actions. Some connections are only established when a request is made, so the absence of a remote connection in the logs at first doesn’t necessarily indicate a failure.
If a port is already in use, close duplicate client instances and check whether another local proxy app is using the same port before trying again. Don’t change the remote server port to an arbitrary unused number. If the configuration won’t load, the protocol isn’t supported, or the core fails to start, note the exact error and check compatibility between the client and selected core. A subscription appearing in the list only confirms that the client parsed it; it doesn’t guarantee that the current core supports every option in it.
v2rayNG: Approve the system connection request
Tap the target configuration to select it, then tap Connect. The first time you use VPN mode, the system will ask to authorize the connection. Confirm the request is from the current client, then allow it. Return to the app and check whether the connection status changes and the system shows a VPN indicator. Authorization only allows the client to establish a local virtual network interface; it doesn’t confirm that the remote server has responded. Test actual access in the next step.
If another VPN app is running, first check which app is currently routing your network traffic. Apps that use the same type of connection may replace one another. If the connection stops immediately after starting, check the logs for configuration errors, permission issues, or core exit messages. If it works in the foreground but often disconnects with the screen locked, then check the system’s background and battery restrictions for the client. There’s no need to change a whole set of power-saving settings during your first connection.
Connection or latency tests can be useful, but they may cover only part of the network path. A successful result doesn’t guarantee that a full webpage will load, and a failure doesn’t necessarily identify whether authentication, DNS, or routing is the cause. Before moving on: The client should still be running, the target configuration should be active, and traffic routing should be enabled. If not, check the startup logs first. Don’t change the server, routing, DNS, and core all at once. Change one variable at a time so you can tell what made a difference.
Step 4: Verify the connection
Verification should answer two questions: did the target app’s request reach the client, and was it routed as expected—through the proxy or directly? A lit button, a system VPN indicator, or a selected server row only confirms that one part of the setup is active. Choose one site that should use the proxy and one common local site that should connect directly. Test them one at a time in the same browser to keep the logs easy to follow.
Check access first, then review the logs
Open a site that should use the proxy and confirm that the page content and essential resources load—not just a cached page in the browser. Refresh or open a new browsing session to reduce cache effects, then check the client’s connection records or logs. If your version shows destination addresses and outbound routes, match them to the time and domain of your visit. If the logs are brief and don’t list every request, don’t assume a request never reached the client just because its domain isn’t shown.
To check further, visit the same trusted IP or exit information page before and after connecting, then compare the results. Expect the proxy exit to change only if the routing rules send that page through the proxy. If it matches a direct-connection rule, an unchanged exit may be correct. Exit location, page language, and whether the page loads aren’t reliable indicators on their own. There’s no need to submit your subscription URL or client configuration to the test page.
Check direct connections and app scope
Visit a common local site that should connect directly. If needed, also test your router or another known service on your LAN. Confirm that normal access still works. If proxy sites work but LAN services don’t, check whether global mode is enabled, private addresses are excluded from the proxy, or a custom rule overrides the preset. If your browser works but another app doesn’t, first check whether that app follows the system proxy or is excluded by v2rayNG’s per-app rules. Don’t start by reinstalling the client.
If every test site fails, narrow down the issue in this order: is the original network working → is the request reaching the client → do the logs show a connection error → is the server configuration still valid? For a DNS resolution error, check the DNS messages first. For a connection timeout, check the remote address and network reachability. For an authentication or handshake error, review the subscription fields and compatibility. Temporarily switching to global routing can help isolate a routing issue, but restore your usual preset afterward.
Finally, check that normal access returns after disconnecting
Once verification is complete, stop the connection and check that normal access is restored. Before exiting v2rayN, clear the system proxy and confirm that the browser is back on your usual network. In v2rayNG, disconnect with the connection button and check that the system VPN indicator disappears. If the desktop client exits unexpectedly and webpages still point to a stopped local port, check for leftover system proxy settings. This prevents stale settings from being mistaken for a network problem after a reboot or network change.
Keep a verified baseline: the subscription group, active server, traffic mode, and routing preset. When problems arise later, return to this baseline and adjust one setting at a time. When asking for help, share only the client, operating system, steps taken, and redacted error text—never the full subscription URL or account details. That completes all four steps of the initial setup. For subscription update failures or issues with specific apps, see the Help Center. For differences between protocols, secure transports, and core families, see the protocol reference.