DESKTOP
v2rayN on Desktop
Enable the system proxy first, then choose a routing mode that makes verification easy. Browsers and other apps that read system proxy settings will send requests to the client.
QUICK CONFIGURATION
This guide covers the four essentials for first-time setup: import a subscription, choose a proxy mode, establish a connection, and verify that traffic passes through the client. Follow the steps in order to complete the basic setup in about 10 minutes.
BEFORE STARTING
Before starting setup, make sure the appropriate client is installed on your device. Use v2rayN on desktop and v2rayNG on Android. If it is not installed yet, visit the client download page and choose a version matching your device platform and processor architecture. After installation, launch the client once so it can initialize its basic directories and runtime components before you import a subscription.
You also need a complete subscription URL. It is usually a link beginning with https://, and serves a different purpose from an individual VMess, VLESS, Trojan, or Shadowsocks share link: a subscription URL retrieves a group of server configurations, while a single-server link contains only one configuration. When copying it, select every character from the beginning to the end. Do not include a title generated by a chat app, spaces, or punctuation at the end of the sentence.
Finally, check the device date, time, and time zone. TLS connections use system time to validate certificate lifetimes, so a significant clock error can cause a handshake failure or certificate time error even when the subscription and server parameters are correct. Enable automatic time settings first, then close and reopen the client. This is only a basic check; investigate certificate, SNI, DNS, and related issues in the Troubleshooting documentation.
SUBSCRIPTION INPUT
After opening v2rayN on desktop, find “Subscription Groups” or a similarly named subscription-management entry in the top menu of the main window, then choose to add a subscription. Give it an easy-to-recognize note, such as “Daily setup” or the service name, and paste the complete URL into the subscription URL field. Before saving, inspect both ends of the field to make sure you did not paste quotation marks, explanatory text, or line breaks.
Saving a subscription record does not mean that server configurations have been retrieved. Return to the subscription menu and choose “Update all subscriptions,” or update the current group directly. Do not click repeatedly while the update is running: the client must request the subscription, parse its servers, and write them to the list. When finished, the server area of the main window should show one or more configuration entries, usually with fields such as an alias, address, port, and transport. At this point, only confirm that the list was created; there is no need to edit the node parameters immediately.
Open v2rayNG on Android, go to Subscription Settings, tap the add button, enter a note, and paste the subscription URL. Save it, return to the main screen, and use the top-right menu to update subscriptions. When the update finishes, the configuration list should show server entries. If the main screen is still empty, reopen Subscription Settings, confirm that the new record is enabled, and update once more. Some versions display the update action as a circular refresh icon; it still rereads configurations from the saved subscription URL.
If you only have a share link beginning with vmess://, vless://, trojan://, or ss://, use “Import from Clipboard” or “Import Configuration” instead of pasting it into the subscription URL field. The import will usually add only one configuration. A QR code is also a single-configuration import method, useful for transferring a server between devices, but it does not automatically create an updatable subscription group.
Once the server list appears, do not rush to test every server. A successful subscription update only proves that the client read and parsed the configurations; it does not mean that system traffic is already being routed through the client. Next, define the proxy scope. Otherwise, the client may appear to be running while the browser and other apps continue connecting directly.
Done when: The subscription is saved, and after an update the main screen shows selectable server configurations.
TRAFFIC SCOPE
The proxy mode determines which requests the client handles and is often the most confusing part of first-time setup. On desktop, “system proxy” and “routing mode” are usually separate settings. The system proxy tells apps that support it to send requests to v2rayN. The routing mode then determines which of those requests use a proxy outbound, connect directly, or follow routing rules. They serve different purposes and must be checked separately.
For the first verification, open v2rayN’s system tray menu and choose “Auto Configure System Proxy,” or the equivalent option in your version. Once enabled, the Windows or macOS system proxy points to the local port listened to by the client, so common browsers and apps that read system settings send traffic to v2rayN. If you choose “Do Not Change System Proxy,” the client can still run in the background, but other system apps will not use it automatically. This mode is better suited to users who have configured ports manually or use another traffic-capture method.
Next, check the routing mode. To minimize variables during the first test, start with the client’s global-style mode, confirm that the server connects, and then switch back to rule-based routing. Global-style routing sends more requests through the selected server, making it easier to verify the basic path. Rule-based routing chooses an outbound based on domains, IPs, protocols, and preset rules, making it more suitable for daily use. Troubleshooting inside complex rules from the start makes it difficult to tell whether the problem is the server, DNS, or rule priority.
Android works differently. When v2rayNG starts a connection, it requests system authorization for VpnService. After authorization, the system routes device traffic to the client. When the connection request first appears, allow it; if you deny it, the configuration can remain in the list but the connection cannot be established. If app-based proxying is enabled, also check whether it is set to “Proxy only selected apps” or “Bypass selected apps,” and make sure the browser you plan to test is included in the correct scope.
Configure app-based proxying after the basic connection has been verified. During first-time setup, the default scope covering the whole device is usually easier to evaluate. Once the connection is confirmed, narrow the app scope as needed. TUN mode on desktop can also handle programs that do not read system proxy settings, but it involves a virtual network interface, permissions, and DNS capture and is beyond this page’s basic steps. To cover terminal tools or special applications, continue with Systematic Troubleshooting.
DESKTOP
Enable the system proxy first, then choose a routing mode that makes verification easy. Browsers and other apps that read system proxy settings will send requests to the client.
ANDROID
Confirm VpnService authorization at startup and check the app-proxy scope. Continue only after the system status bar shows a connection indicator.
Done when: The system proxy and routing mode are set on desktop; on Android, the traffic scope is clear and system permission is ready to be granted at connection time.
ACTIVE CONNECTION
Return to the server list and select a configuration from the subscription group. On desktop, double-click a server entry or use its context menu to set it as the active server; some versions also accept Enter. The selected entry may be shown with a color, highlight, check mark, or active indicator. Select one server only. Do not edit multiple nodes at once, and do not treat a speed-test result as the sole measure of success because test traffic does not exactly match real application traffic.
After confirming the active server, check v2rayN’s system tray status. If the system proxy was enabled in the previous step, selecting a server will usually start the corresponding core. Some versions also provide a separate start or restart-service action. Open the log area at the bottom of the main window. A normal startup should show configuration loading, creation of the local listening port, and the core running. You do not need to understand every line; simply confirm that there are no repeated startup failures, port conflicts, or configuration parsing errors.
If the log says that a local port is already in use, another program or client instance is listening on the same port. Close duplicate v2rayN windows and similar network tools, then restart the current client. Do not change several ports in succession without understanding their purpose: the system proxy may still point to the old port, leaving the core running while applications cannot connect. If you must change a port, verify both the client’s listening port and the system proxy target.
On Android, tap a node in the configuration list to make it current, then tap the connection button on the main screen. The first connection displays a system authorization dialog; confirm it and wait for the status to change. The connection button, status text, or system status bar will indicate that VpnService is established. v2rayNG then starts the core and loads the selected configuration. If the button changes briefly and immediately returns to a disconnected state, open the log and find the first clear error instead of switching through many nodes.
Separate connection problems into two layers: whether the client starts successfully and whether the remote path can be established. The first mainly involves configuration parsing, local ports, and system permissions; the second involves the server address, port, protocol parameters, TLS, and network reachability. Browser verification is meaningful only after the core is running normally. If every server shows the same startup error, check local settings first. If the client runs normally but one server times out, compare it with another server in the same subscription.
Done when: The target node is active, the client remains connected, and the log shows no repeated local startup errors.
REQUEST VERIFICATION
A running connection button does not mean that every app’s traffic passes through the client. For verification, close previously opened test pages and open a new browser window to visit a familiar, reliable website. While it loads, watch the client log. New connection records, target domains, or outbound details indicate that the browser request entered the client. If the page opens normally but the log does not change at all, return to the proxy-mode step and check the system proxy or app scope.
On desktop, perform an on/off comparison. Keep the same browser page open, clear the system proxy in v2rayN and refresh, then enable automatic system proxy configuration again and refresh. Do not change the server, routing mode, and DNS settings at the same time; otherwise, you cannot identify which change affected the result. If the log shows requests with the system proxy enabled and stops growing when it is disabled, the browser is reading the system proxy as expected.
On Android, open the browser while connected and check the v2rayNG log. If “Proxy only selected apps” is enabled, confirm that the browser is selected. If “Bypass selected apps” is enabled, confirm that the browser is not on the bypass list. Some apps keep existing connections, so after changing the app scope, fully close the test app and reopen it to create a fresh network connection.
Also consider the failure type. If the page immediately reports a connection failure and the log shows a local request but no remote response, the server may be unreachable or its parameters may not match. If the page stays in the resolving stage, investigate DNS. If the browser works but terminal commands do not, the terminal likely is not reading the system proxy environment. Do not classify every symptom as a server failure; use whether the request entered the client as the dividing line for the next check.
After verification, switch to a rule-based routing mode better suited to daily use and repeat the browser test. Under rule-based routing, different destinations may use the proxy or connect directly; that is how routing rules work. If a website works in global-style mode but fails after switching to rule-based routing, check rule order and the selected outbound instead of importing the subscription again. The complete workflow for routing rules, split DNS, and TUN capture is covered in the Troubleshooting Guide.
Done when: The test request enters the client, the page result matches the log activity, and toggling the proxy produces an explainable comparison.
AFTER CONFIGURATION
After confirming the basic connection, keep the working configuration and do not immediately edit internal node parameters. Server details in a subscription are maintained by its source. Manually changing the address, port, user identifier, or transport parameters may be overwritten at the next update or leave the node inconsistent with the subscription. Daily operation should focus on updating subscriptions, selecting an active server, and adjusting the routing mode.
The second checkpoint is the subscription update cycle. When you need fresh configurations, update them from the subscription menu; do not add the same URL again every time the client starts. If the server list changes after an update, confirm that the current active server still exists. If an update fails, returns empty content, or reports an invalid format, keep the existing list while troubleshooting instead of deleting configurations that still work.
The third checkpoint is app scope. A desktop browser working does not prove that every terminal tool reads the system proxy. On Android, app-based proxying sends only apps within its scope through the client. If one program works while another does not, compare their proxy mechanisms before judging the server quality. Find common scenarios and next steps quickly in the FAQ.