This guide is for new v2rayN users who have imported a subscription but are unsure what to do next. Follow the steps to check the core setup, filter servers, run a real connection test, set an active server, enable the system proxy, and check the exit IP. This clearly separates “the app is running,” “the server is reachable,” and “browser traffic is being proxied.”
Check the Subscription, Core, and Local Ports First
v2rayN is a desktop GUI client; server entries are configurations passed to the core for execution. Successfully importing a subscription does not mean a connection has been established, and seeing servers in the main window does not mean system traffic is using the proxy. Before connecting for the first time, confirm that the subscription group contains at least one server and that its address, port, protocol, and transport settings are populated.
VMess, VLESS, or Trojan configurations supplied by a subscription usually include the required transport parameters automatically. For the first connection, avoid changing the server address, UUID, TLS, Reality, WebSocket path, or SNI one by one. Any mismatch with the server can cause timeouts or handshake failures. Adjust these fields in the server editor only when the subscription provider gives explicit manual parameters.
Local Proxy Port Example
- SOCKS Port
- 10808
- HTTP Port
- 10809
- Listen Address
- 127.0.0.1
Use the ports shown under “Settings” → “Parameters” as the source of truth, and do not run another program that uses the same ports.
Recommended First-Run Settings
- Core Type
- Xray
- Proxy Method
- System Proxy
- Routing Mode
- Rule Mode
Start with the standard system proxy for verification, then decide whether to configure TUN based on application compatibility.
- Go to “Settings” → “Parameters” → “Core Type” to confirm the active core. When the subscription contains VLESS or Reality servers, Xray is usually the appropriate choice.
- Check the bottom of the main window or the log area for messages such as “port already in use,” “core failed to start,” or configuration parsing errors.
- If the server list is empty, first confirm that the group is enabled under “Subscription Groups,” then run Update All Subscriptions once.
- Do not confuse the remote server port with the local proxy port. The remote port may be 443 while the local client listens on 10808.
Filter Servers Before Running a Real Connection Test
The location text in a server name only identifies the route; it does not directly indicate current performance. For the first selection, narrow the list by destination region and then compare real connection latency. Nearby routes often have shorter round-trip times, but entry-point load, inter-network routing, and peak-hour congestion can change the result. Do not judge a server by its location name alone.
Common v2rayN tests include TCP latency, real connection latency, and speed tests. TCP latency mainly confirms that a basic connection to the remote port can be established; a low value does not guarantee a successful protocol handshake or request. A real connection test uses the server to make a request closer to actual browsing, making it more useful for the first selection. Speed tests take more time and bandwidth, so there is no need to run them repeatedly on every server during initial troubleshooting.
| Test Result | What It Means | Next Step |
|---|---|---|
| Below 180 ms three times in a row | The response is relatively stable on the current network | Set it as the active server and verify web access |
| 120 ms once, then a timeout | The route is jittery or its load is changing | Compare another entry in the same region |
| TCP returns a value, but the real connection times out | The port is reachable, but the protocol request did not complete | Check the core logs and server parameters |
| All servers time out | More likely a subscription, core, or local network issue | Do not keep testing servers blindly; check the logs first |
When the latency difference is only a few dozen milliseconds, there is no need to switch constantly. A stable 140 ms route is often more suitable for ongoing use than one that alternates between 90 ms and timeouts. If the subscription lists traffic multipliers, compare those as well: a 2x server may count 1 GB of transferred data as 2 GB, so speed-test numbers are not the only factor.
Complete the First Connection in Order
The sequence below keeps configuration, testing, and the system proxy separate, with a clear result at each step. If a webpage fails to load, you can quickly determine whether the issue lies with the subscription, core, server, or system proxy instead of changing several options at once.
-
Confirm the Core
Open “Settings” → “Parameters” → “Core Type,” choose the Xray core compatible with the subscription protocol, save, and check the logs for a normal startup.
-
Update the Subscription
Under “Subscription Groups,” select the relevant group and run Update All Subscriptions. Confirm that the server list shows names, addresses, ports, and protocol types.
-
Filter the Servers
Start with 3 to 5 servers in the target region. Do not run full speed tests on hundreds of entries right away.
-
Run a Real Connection Test
Select the candidate servers and use the main interface’s server testing function to run a real connection latency test. Keep entries that return consistently with limited variation.
-
Set the Active Server
Double-click the target server or use the Server menu to set it as the active server, then confirm that the active-row indicator has moved to it.
-
Enable the System Proxy
Open the tray icon menu, go to “System Proxy,” and choose “Auto-Configure System Proxy.” Then reopen a browser window for verification.
After a successful startup, the logs usually show the local listening port, configuration loading, and outbound connection records. An occasional reset from one website does not mean the entire server has failed; judge it together with the real connection test, results from several webpages, and the exit IP.
System Proxy Verification Differs from Android
After the system proxy is enabled on desktop, browsers and apps that follow system proxy settings send requests to v2rayN. Local traffic first enters the listening port on 127.0.0.1 and is then forwarded through the active server. Some programs manage proxy settings independently and do not read system options automatically; enter the local HTTP or SOCKS address inside those programs.
Recommended Approach: Verify Desktop and Android Connections Separately
Desktop (v2rayN)
- Run a real connection latency test first
- Enable automatic system proxy configuration
- Cross-check with the exit IP and web access
Android (v2rayNG)
- Import the same subscription and choose a server
- Start the connection with the in-app button
- Configure per-app proxy only when needed
The subscription can be shared, but the active server, routing rules, and local connection status are managed separately on each device.
- To test only whether v2rayN itself is running, check the logs for a local listener and core startup messages.
- To test whether a server can complete requests, run a real connection latency test and repeat it two or three times after waiting a few seconds between tests.
- To test whether browser traffic is proxied, enable the system proxy, check the exit IP, then compare it with the result when the proxy is disabled.
- For a specific app, confirm that it uses the system proxy or manually set its HTTP proxy to 127.0.0.1:10809.
Do not enable full TUN during initial troubleshooting. TUN captures more traffic from apps that ignore system proxy settings, but it also adds routing, DNS, permission, and virtual-network-adapter variables. First make sure the browser works reliably through the system proxy, then handle games, command-line tools, or special apps. This makes diagnosis much clearer.
Verify the Proxy with the Exit IP and Web Access
“The server is selected” is only a client status, while “the real connection latency has a value” means the server completed a test request. “The proxy is working” requires checking the target app’s actual traffic. The most direct method is to record the exit IP, region, and network operator with the system proxy off and on.
Use the same browser and network connection during testing, and avoid running other proxy tools at the same time. First clear the system proxy, refresh an IP lookup page, and record the result. Then return to v2rayN, enable automatic system proxy configuration, reopen the browser, and check again. Basic verification is complete when the exit address changes to the selected server’s region and several ordinary webpages load successfully.
- From the tray menu, choose “System Proxy” → “Clear System Proxy,” then close and reopen the browser.
- Search for and open an exit IP lookup page, then record the IP, region, and operator.
- Return to the tray menu and choose “System Proxy” → “Auto-Configure System Proxy.”
- Reopen the browser window, check the exit IP again, and compare it with the first result.
- Open two different websites and check whether their homepages, images, and subsequent pages continue loading.
- Finally, review the v2rayN logs and confirm that new outbound connection records appeared during verification.
| Observed Result | Assessment | What to Do |
|---|---|---|
| Exit IP changed and webpages load normally | The proxy is basically working | Keep the current server and adjust routing as needed |
| Exit IP unchanged and no requests in the logs | The browser did not reach the local proxy | Check the system proxy status and browser proxy settings |
| Exit IP unchanged, with direct-connection records in the logs | Routing rules sent the lookup site directly | Try another lookup site or temporarily review the routing mode |
| Exit IP changed, but some webpages fail | The server works; DNS or the target website may be the issue | Check the logs and routing result for the specific domain |
Troubleshoot Common First-Connection Problems
When the first connection fails, the most effective approach is to keep the current settings unchanged and replace only one variable at a time. If a server times out, try another server from the same subscription. If every server fails, check the core and subscription. If the browser fails while the real connection test succeeds, prioritize checking the system proxy and local ports.
All Real Connection Tests Time Out?
Open the logs first and confirm that the core has started, then go to “Settings” → “Parameters” and check Core Type. Update the subscription once and test three servers from different regions. If all time out after about 5000 ms, check whether the current network restricts these connections.
Why Does the Browser Still Use the Original Exit Route After Selecting a Server?
Check whether “System Proxy” in the tray menu is set to “Auto-Configure System Proxy.” If the logs contain no browser requests, close and reopen the browser. If there are still no records, check whether the browser has an independent proxy or bypasses the system proxy.
What Should I Do If Port 10808 Is Already in Use?
Exit other programs using that port, or go to “Settings” → “Parameters” and change the local port to an unused value, such as 10818. Save, restart the core, and update any apps that were manually configured with the old port.
Why Is Web Browsing Slow Even Though the Server Latency Is Low?
Run the real connection latency test three times in a row, then compare another server in the same region. Low latency only means that requests receive a quick response; it does not guarantee high sustained throughput. Peak-hour congestion, server load, and traffic multipliers should all be considered.
Why Do Only Some Websites Fail to Load?
When the failure occurs, check the domain, routing destination, and error message in the logs. If other websites and the exit IP work normally, rule out a single-site outage first, then check DNS settings and whether the rules incorrectly sent the domain directly.
When troubleshooting is finished and you need to restore the original network state, use the tray menu: “System Proxy” → “Clear System Proxy.” Do not simply close the main window. In some configurations, the app remains in the tray after the window closes, so the core and system proxy may continue running. Use the tray status and system proxy settings as the source of truth.
Basic Maintenance After Connecting Successfully
After completing the first verification, keep two or three stable servers as backups instead of chasing the lowest latency every day. Subscription updates may add, rename, or remove servers. If the active server stops working after an update, run the real connection test again and choose a new entry.
Routing determines which domains use the proxy, connect directly, or are blocked. At the beginning, use the client’s standard Rule Mode. Once browser access and the exit IP are stable, adjust rules for work apps, local-network resources, and specific domains. Add one rule at a time and verify it immediately; this makes conflicts easier to find than importing a large rule set all at once.
Weekly Check
- Subscription Update
- Run once
- Backup Servers
- Keep 2–3
- Latency Retest
- Repeat 3 times
Re-sort servers only when their performance changes noticeably, and avoid pointless frequent switching.
Incident Log
- Time of Occurrence
- To the Minute
- Active Server
- Record the Full Name
- Error Location
- Save the Relevant Log Lines
Record the network environment and test results as well; this makes it easier to distinguish server fluctuations from local configuration issues.
A reliable first-connection checklist should be: the subscription list contains servers, the core is listening normally, local ports are conflict-free, candidate servers return stable real-connection latency, the target server is active, the system proxy is enabled, the exit IP changes accordingly, and multiple webpages remain accessible. Checking each item in this order lets you locate most cases where a connection appears active but is not actually working.