Seeing v2rayN running doesn’t mean your browser requests are going through the proxy—or that the remote server can reach the site you want. This checklist covers ten areas, in order: your local network, system proxy, listening port, server status, routing, DNS, TLS, TUN, app settings and logs. The steps focus on Windows, with checks for v2rayNG and v2flyNG on Android. Change one thing at a time and retest the same URL to avoid mixing up causes.
1. Check your internet connection and rule out captive portals
Note your current server name, proxy mode and latest error, then temporarily turn off TUN and choose “System proxy” → “Clear system proxy” from the v2rayN tray menu. Try a site that normally works without a proxy. If it still won’t load, check your Wi-Fi, Ethernet, router and network sign-in before updating your subscription again.
Hotels, campuses and public Wi-Fi may require you to sign in through a captive portal. A connected network icon only means your device is on the local network. Complete any sign-in first, then test the proxy again. The steps below establish repeatable test conditions; use the same browser and destination URL throughout.
-
Record the current setup
Note the active server, system proxy status, TUN setting and test time. Keep the error keywords, but don’t share your full subscription URL.
-
Test a direct connection
Turn off TUN, select “System proxy” → “Clear system proxy,” then visit a site that works directly. Complete any network sign-in first if needed.
-
Use one test URL
Restore the server and test just one URL. Note whether it fails immediately, hangs, or only fails to load images. Don’t change several things at once.
2. Check the system proxy: are requests reaching v2rayN?
Open the v2rayN tray menu and select “System proxy” → “Automatically configure system proxy.” In Windows 11, go to “Settings” → “Network & internet” → “Proxy” to check the actual proxy address and port. The local proxy address is usually 127.0.0.1; the port must match the client’s current listening port. Don’t rely on an old screenshot.
The system proxy applies mainly to apps that follow that setting; it doesn’t automatically route traffic from every program. Turn off TUN first to test the system-proxy path on its own. If the client shows no connection when you refresh a page, try an explicit proxy command to bypass the browser settings. The 10808 below is only an example port for an enabled HTTP or mixed listener. Replace it with the actual port before running the command.
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- The command returns an HTTP response from the destination site: this request made it through the local proxy to the destination. Check the browser or system proxy settings next.
- Immediate error connecting to the local port: go to step 3 and check whether the core is listening.
- The proxy tunnel connects, but TLS fails or times out: that doesn’t mean the site is accessible. Continue by checking the remote server, DNS and certificates.
3. Check the listening port: is the core stopped or is the port in use?
v2rayN is the management interface; a core process handles the actual connections. If the interface is open but the core failed to start, the system proxy may still point to a local port with no service behind it. Check the local listening options under “Settings” → “Parameter settings” and compare them with the listening address in the logs. Option names and default ports vary between versions.
Run these commands in PowerShell. The first lists listening ports and process IDs; the second identifies the process for the ID you found. 1234 is an example, not a fixed value. Don’t terminate a process just because its port matches, and never force-close an unfamiliar system service.
Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 1234Error: bind: address already in use
Cause and fix: Another process is already using the listening address or port. Check whether the client is running twice. Close the duplicate instance or change the local listening port, then update the system proxy and app proxy settings to match.
Error: Failed to connect to 127.0.0.1 port 10808
Cause and fix: This request couldn’t connect to the example local port. Check the configured listening port, core startup logs and any blocks recorded by local security software. Don’t assume the remote server is at fault.
4. Check the server and subscription: a test result isn’t proof the server works
A latency figure in the server list doesn’t prove the entire proxy connection is working. A TCP latency test may only show that a host and port accept a connection; actual latency tests also depend on the URL used by the client. Select a server and make it active, then try to reach the real destination through it instead of relying on the number in the list.
- Select the relevant group under “Subscription group” and update it. Check the server address, port and any provider notices. The update command’s wording may vary by version.
- Check your account’s data allowance, expiration date, device limit and server maintenance status. A successful subscription update only means the configuration was downloaded; it doesn’t mean the service it points to is working.
- Try another server in the same subscription without changing the destination URL or routing mode. If only one server fails, investigate that server before reinstalling the client.
- On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Importing a profile successfully doesn’t guarantee the core supports every setting; check that the protocol and transport combination is supported.
VMess and VLESS are proxy protocols; REALITY is a related security transport. They aren’t mutually exclusive server types. Back up your settings before editing them. For VLESS with REALITY in particular, the server address, public key, short ID and server name must match the server’s requirements. Don’t fill in missing values by guesswork.
5. Check split tunneling: which outbound route handles the destination?
If only some websites fail, start by checking the routing rules. The system proxy sends requests to the local entry point; routing rules then decide whether each request goes direct, through the proxy or gets blocked. These are separate steps. Enabling the system proxy doesn’t mean every destination is routed through the remote server.
| What you see | Check first | How to verify |
|---|---|---|
| A destination that should use the proxy goes direct | Domain rules and rule order | Temporarily choose a routing profile that proxies all traffic |
| The page loads, but images don’t | Image and static asset domains | Check the outbound route for failed resources |
| Logs explicitly show a block | Is the blocking rule too broad? | Change only the rule that matched |
| Works after switching profiles | Domain and IP matches in the original profile | Restore the original profile and compare rules one at a time |
Bottom line: use a comparison profile to isolate routing issues
If the same server and URL work with a profile that proxies all traffic but fail with your original split-tunneling profile, fix the matching rule first. Switching servers or weakening TLS security would usually take you away from the actual problem.
Routing profile names vary by version and custom configuration, so check what each rule actually routes. For definitions, see the split tunneling glossary. Once you’ve finished troubleshooting, restore a profile suited to everyday use; don’t leave the temporary comparison setting in place.
6. Check DNS: distinguish the server hostname from the destination hostname
DNS is involved in at least two lookups: the client must find the remote server, and the destination website’s domain must also be resolved at the appropriate point. If the first lookup fails, the client usually can’t reach the server. If the second fails, the server may show latency while websites remain unavailable. Finding an IP address doesn’t prove the lookup is correct, and different IPs on different networks don’t by themselves indicate DNS poisoning—content delivery networks often return different results.
Resolve-DnsName example.com
ipconfig /flushdns
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/The first command checks the system’s DNS result; the second clears the Windows DNS cache. Use the third only if that port provides a SOCKS5 or mixed listener. socks5h sends the destination hostname to the proxy for resolution, which lets you compare it with local DNS. It doesn’t guarantee that the core’s own DNS or routing settings will be bypassed.
- System DNS times out: check whether the DNS server assigned by the network is reachable and whether the network restricts particular DNS services.
- Still failing after clearing the cache? Check secure DNS in the browser, the client’s DNS settings and the core’s cache. The system cache is only one layer.
- Resolution through the proxy works, but local resolution fails: focus on the local DNS path. After changing DNS services, revisit the destination to confirm the result.
7. Check the system clock, TLS and SNI
Diagnose certificate errors based on which connection is failing: the TLS handshake to the server may fail, or the browser may get a certificate error when it connects to the destination website. In Windows 11, go to “Settings” → “Time & language” → “Date & time,” enable automatic time and select “Sync now.” Certificate validation depends on the actual system time; changing the displayed time zone alone doesn’t set the clock correctly.
Error: x509: certificate has expired or is not yet valid
Cause and fix: The certificate’s validity period doesn’t match the current time. Sync your system clock first. If the error persists with the correct time, ask the server administrator to check the certificate’s validity and deployment.
Error: x509: certificate signed by unknown authority
Cause and fix: The current environment can’t build a trusted certificate chain. Check the server’s certificate chain, the system trust store and any network device inspecting HTTPS. Don’t simply disable validation.
Error: tls: handshake failure
Cause and fix: This is a generic handshake failure. Check the server name, transport and TLS settings provided for the server, then use server logs to investigate. This message alone doesn’t prove the certificate has expired.
Use the SNI name required by the server configuration. It doesn’t have to match the connection address, and you shouldn’t replace it with a well-known website’s domain. Don’t use allowInsecure as a general fix: skipping certificate validation can hide a bad connection or an issue in between, but it won’t fix account, routing or transport settings.
8. Check TUN permissions and virtual adapter conflicts
If an explicit proxy command works but the whole device loses internet access when TUN is enabled, focus on the virtual adapter, routes and DNS interception. TUN changes the system’s traffic path and usually requires elevated permissions. If you’re only setting a proxy for the browser, you don’t need to enable TUN just to test it.
- Turn off TUN first and confirm that the explicit proxy test in step 2 works. This gives you a baseline that doesn’t rely on a virtual adapter.
- Grant the permissions requested by the client to create a network adapter and change routes. On Windows, exit v2rayN, relaunch it as administrator and try enabling TUN again.
- Temporarily quit other VPNs or traffic-routing apps to prevent multiple virtual adapters from changing the default route at once. On a managed work device, follow your organization’s network policies.
- Use
Get-NetAdapterto check adapter status androute printto save the routing table. Record the output first; don’t delete unfamiliar routes in bulk.
On Android, v2rayNG and v2flyNG use the system VPN service to route traffic from selected apps. Check the connection permission, per-app proxy list and whether another VPN session is active. If the connection drops only after the screen locks, check battery optimization and background restrictions rather than assuming the server failed. For desktop TUN basics, see the TUN setup guide.
9. Check the browser, app proxy settings and firewall
If an explicit proxy test works but the browser doesn’t, start by checking differences at the app level. Browser extensions may override the system proxy, and secure DNS may use a different resolution path. Terminal apps may also read HTTP_PROXY, HTTPS_PROXY or ALL_PROXY. Incognito mode doesn’t necessarily disable every extension or organizational policy, so it isn’t conclusive on its own.
- Temporarily disable proxy-related extensions, check for manual proxy or policy settings in the browser, then fully quit and relaunch it.
- If you set a proxy directly in an app, make sure the type matches: HTTP or SOCKS5. A single port can accept both only if it supports mixed connections.
- Run
Get-ChildItem Env:*PROXY*to inspect proxy environment variables in the current PowerShell session. If you find an obsolete port, remove only entries you’ve confirmed belong to the old configuration, then restart affected apps. - Check firewall or security software logs for blocks on the core process. Add necessary allow rules for the program path; don’t leave your entire security suite disabled as a troubleshooting measure.
If only one website’s login fails, returns 403 or shows a CAPTCHA, you’ve received a response from the website; this isn’t a complete loss of connectivity. The issue may involve the reputation of the exit IP, regional restrictions or account security checks, and should be treated separately from a connection timeout.
10. Finish with the logs and change one variable at a time
If the first nine checks haven’t identified the problem, clear the current log display, note the time and make just one request to the destination. If necessary, temporarily increase the log level, reproduce the issue, then restore it to avoid recording excessive browsing details. Find the stage where the request fails: local connection, remote connection, handshake or destination response.
| Keyword or symptom | What it means | Next step |
|---|---|---|
connection refused | Connection explicitly refused | Use the error address to distinguish the local listener from the remote server |
i/o timeout | Timeout at a network stage | Check the address, port, network path and logs preceding the timeout |
no such host | Related domain failed to resolve | Identify whether the failed lookup is for the server or destination domain |
| No matching request in the logs | The request may not have reached the entry point being monitored | Confirm the log level, then check app proxy settings and traffic coverage |
When contacting the administrator, include your operating system, client and core versions, test time, network type and a redacted error excerpt. Hide subscription tokens, user IDs, passwords, private keys and sensitive browsing records; don’t send your full configuration. Before updating the client, back up your servers and routing settings, then choose the right platform and architecture from the client download page.
Common questions: How should you interpret test results?
Why can’t I open websites even though the server shows latency?
First check whether the test measured TCP latency or the latency of a real request. Select the server and run the explicit proxy command in step 2. A successful port check doesn’t prove authentication, TLS or access to the destination site is working.
If my subscription updates, does that mean the server is fine?
No. The subscription URL and the server can be separate services. After updating, check the active server, data allowance and expiration date. Then test the same destination through two servers and compare the actual results.
What if the browser works but no other apps do?
First check whether those apps follow the system proxy or let you enter a local proxy manually. Configure TUN only if you need to route apps that don’t support proxies, then check permissions and which apps are included.
It works after a restart, then disconnects again. What should I check first?
Keep the logs from the time of failure and check for port conflicts, adapter routes after waking from sleep and background restrictions. Don’t just note that restarting helped; compare the listening process, active server and proxy status before and after the disconnect.