For v2rayN on desktop and v2rayNG or v2flyNG on Android, this guide covers cases where the client is running but the browser cannot reach websites. First check whether requests reach the client, then whether the core can connect to the remote server. Change one setting at a time and retest the same URL. The steps include system menus, port-check commands, DNS comparisons, and log clues. A connection icon or a single latency test does not prove that websites are reachable.
1. Connected Doesn’t Always Mean Websites Can Load
Depending on the client, “connected” may mean the local core is running or that an Android VPN interface has been established. It does not necessarily mean the remote server has authenticated successfully, or that DNS, TCP, and TLS are all working for the website. A latency test may check only one address or connection type, so it cannot verify access to every site.
Keep your current configuration and note when the problem started, which server is selected, how traffic is routed, and which URL fails. Turn off automatic server switching so both tests use the same route. Don’t change DNS, the subscription, and the core at the same time; otherwise, even if access returns, you won’t know which change fixed it.
- All websites fail: Check the basic network connection, local listener, and traffic routing first.
- Only some domains fail: Compare DNS results, routing matches, and the target website’s status.
- The browser fails, but other apps work: Check browser proxy extensions, standalone proxy settings, and Secure DNS.
- Wi-Fi works, but mobile data fails: Test again with the same server and note the network differences. Don’t assume the subscription is invalid.
2. Check the System Proxy and VPN Connection
In v2rayN, the system proxy sends requests from apps that honor system proxy settings to a local port. TUN routes traffic through a virtual network interface. For a standard browser check, start with the system proxy only to reduce variables. If you’re already using TUN, save the current settings before switching modes for comparison.
-
Confirm the active server
In the v2rayN main window, confirm that the selected server is the configuration you intend to test, and check the logs for core exits. Selecting a row in the list may not activate that configuration; rely on the active configuration and logs.
-
Set the system proxy
Open the v2rayN tray menu and choose “System proxy” → “Automatically configure system proxy.” Labels may differ slightly between versions. The goal is to point the system proxy to the local address that is listening—not merely to launch the main window.
-
Check the system proxy address
In Windows 11, open Settings → Network & internet → Proxy → Manual proxy setup and check the address and port. If the client uses an automatic configuration script, check those script settings instead of adding a separate manual proxy.
-
Check for browser overrides
Temporarily disable browser extensions that change proxy settings, then close and reopen the browser. In Firefox, check Settings → General → Network Settings → Settings to see whether it uses the system proxy settings.
-
Check the Android VPN connection
With v2rayNG or v2flyNG, start the configuration and confirm that VPN access is authorized. If per-app proxying is enabled, make sure the browser is included. Also check whether another app is already using the VPN connection.
The VPN icon on Android only confirms that an interface exists. If the system restricts the client in the background, the interface or app status may not reflect actual traffic forwarding. Keep the app in the foreground, retry the same URL, and check for new connection logs. You can review background permissions under Settings → Apps → the client’s battery settings; labels vary by device and Android version.
3. Is the Local Port Actually Listening?
Even with the right proxy address, the browser cannot connect if nothing is listening on the port. The example below uses the local SOCKS inbound 127.0.0.1:10808. This is only a sample port, not a required default for every version. Check the client’s current inbound settings or startup logs for the actual port, then replace the number in the commands.
Run these commands in Windows PowerShell. The first lists TCP listeners and connections; the second checks whether a local TCP connection can be established. If you see LISTENING, check the PID in the last column to make sure the expected core—not another process—is listening.
netstat -ano | findstr ":10808"
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808- No listener found: Check the core startup logs and confirm that the configuration loaded successfully. Repeatedly changing the browser proxy won’t help.
- Another process owns the listener: Find the PID under Details in Task Manager. After confirming what the process does, close the conflicting app or change the client’s inbound port and update the system proxy settings.
- Local TCP test succeeds: This only proves that the port accepts connections. It does not confirm that SOCKS negotiation or the remote connection works.
Next, send a request through the explicitly specified proxy to bypass the system proxy settings. On Windows, use curl.exe to avoid differences caused by command aliases. On macOS and Linux, use the available curl command. This command requires a SOCKS5 inbound; don’t substitute an inbound that supports HTTP only.
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/What the result means: If the explicit proxy works, check the browser
If the command receives an HTTP response but the browser still fails, check for a browser proxy override and verify the system proxy address. Even a 403 or 405 means the request received an HTTP-layer response; the local port is not simply “not listening.”
4. Find Where DNS Resolution Fails
DNS can be involved in resolving at least two kinds of domains: the server’s hostname and the website’s hostname. If the server hostname cannot be resolved, the client cannot find the remote server. If the website hostname fails to resolve, only some websites may be affected. Don’t assume you need to change system DNS just because the browser says it can’t find the server.
First check local resolution, then compare two SOCKS requests. With socks5://, curl typically resolves the destination domain locally. With socks5h://, the destination domain is passed to the proxy. The resolver used in the latter case depends on the core’s DNS and routing configuration; it does not necessarily use the remote server’s system DNS.
nslookup example.com
curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- Local resolution fails, but socks5h works: Check the DNS resolution path on your device first. After changing DNS settings in Windows, you can run
ipconfig /flushdns, but clearing the cache won’t fix an unreachable DNS server. - Both proxy requests time out: Check routing and the remote connection next; don’t focus on DNS alone.
- System DNS works, but the browser fails: Check the browser’s Secure DNS setting. It may use a separate DNS path and return different results from the system resolver.
- The logs point to the server hostname: Run
nslookupfollowed by the actual server hostname. Don’t confuse the server’s hostname with the website you’re trying to visit.
5. Check Routing Rules and Server Availability
If the local port and DNS are working, check which outbound route handles the failed request. V2Ray/Xray routing usually applies rules in order, and the first matching rule determines where traffic goes. Overly broad direct or block rules, or app exclusions, may send requests around the intended proxy entirely.
- Note the current routing mode and custom rules, and keep a copy you can restore. Check the client’s connection or access logs to confirm that the test domain reached the core.
- Temporarily switch to the client’s global proxy routing mode and retry the same domain. This changes the core’s outbound route; it does not turn on the system proxy again.
- If global mode works but rule-based routing does not, restore the original mode and check the rule order, direct outbound, and domain/IP matching conditions for that domain.
- If global mode still fails, leave the other settings unchanged and test another known-working configuration. If only one configuration fails, check its server address, port, authentication details, and expiry.
VMess and VLESS are protocol types, not connection switches. The transport, TLS, SNI, or REALITY parameters must match the server configuration; changing protocols at random won’t fix the connection. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Successfully importing a subscription doesn’t mean every setting it contains is supported by the current core. For help choosing a client, see the client comparison guide.
A successful subscription update only confirms that the subscription content was retrieved; it doesn’t mean every configuration in it is currently reachable. A successful TCP connection to a server port doesn’t prove protocol authentication worked. Test with one fixed server and confirm that a complete HTTPS request returns before restoring automatic selection or complex routing rules.
6. Read Error Logs and Choose the Next Step
After triggering a failed request, look for the first related error around that time. The snippets below are common examples; different cores may include an address, port, or more specific cause. Don’t blame the server based on the last log line alone. Before sharing logs, remove subscription URLs, credentials, and personal network details.
Error: connection refused
Cause: The destination port refused the connection. This could be the local proxy port or the remote server port.
What to do: Check the address in the error first. If it’s 127.0.0.1, check the local listener. If it’s the server address, verify the server port and service status.
Error: no such host
Cause: A hostname could not be resolved. Use the same log line or nearby entries to identify which hostname.
What to do: Check the hostname for typos, then determine whether it belongs to the server or the website. Test the corresponding DNS path as described above.
Error: context deadline exceeded
Cause: An operation exceeded its time limit. The delay could involve DNS, the remote connection, or the handshake; this error alone does not identify a single cause.
What to do: Use earlier log entries to find where the request stalled. Then change one variable at a time: test the same server on another network, or another server on the same network.
Error: address already in use
Cause: The local address and port the core tried to bind are already in use, preventing the relevant inbound from starting.
What to do: Use a port-check command to find the PID. Resolve the conflict, restart the core, and confirm that the system proxy points to the actual port in use.
For an expired certificate, hostname mismatch, or handshake failure, first check the system date, time, and time zone, then verify the TLS settings in the subscription. Don’t treat skipping certificate verification as a routine fix. Once the issue is resolved, turn off temporary verbose logging to avoid unnecessarily recording access details.
7. FAQs After Restoring Access
Why does the speed test work while websites still time out?
A speed test may check only a connection to a specific address. Use the explicit proxy command in this guide to test a real HTTPS request, then compare the result with the browser. If only the browser fails, check its separate proxy settings and Secure DNS first.
Will enabling TUN fix internet access for every app?
No. TUN changes how traffic enters the client; it won’t fix an unavailable server or incorrect authentication. First verify the outbound connection in system proxy mode. If you need to route apps that ignore system proxy settings, enable TUN as directed by the client and check permissions, routing, and DNS.
Why can’t the browser connect after I close the client?
Check for a leftover system proxy pointing to the local port. In Windows, open Settings → Network & internet → Proxy and clear the manual proxy. Alternatively, reopen v2rayN, then choose System proxy → Clear system proxy before exiting.
Which changes should I keep after troubleshooting?
Keep only changes that you confirmed worked through comparison tests. Restore temporary global routing, turn off debug logs, and make sure the browser’s proxy settings match the current connection mode. Note the fix, test URL, and time so you can check the same place first if the issue returns.
If you still can’t identify the cause, collect the client name, core type, connection mode, redacted logs, and whether the explicit proxy test succeeded. This information helps narrow down the problem more than a screenshot showing “connected.” For basic setup, see the installation and setup guide; for related concepts, see the glossary.