For v2rayN, v2rayNG, or v2flyNG setups that show as running while the browser still times out, certain sites remain inaccessible, or every request fails. Check the local listener, traffic interception, DNS, routing, server exit, and logs in that order. Run an independent test after each step to identify exactly where the connection breaks.
First, identify what “connected” actually means
The client’s running status usually only means that the core process has started or that Android has established a local network interface. It does not mean the remote server completed its handshake, nor that browser traffic has entered the proxy. Break the path into five segments: application request, local proxy port, DNS resolution, remote server, and target website.
Using the common v2rayN 7.14.3 setup as an example, the local SOCKS port is usually 127.0.0.1:10808, and the HTTP port is usually 127.0.0.1:10809. You can change these ports under “Settings” → “Parameter Settings” → “Basic Settings”, so always test the values currently shown by the client rather than relying on the defaults.
Temporarily disable standalone proxy settings in browser extensions, quit other programs that may control the system proxy or virtual network adapter, and restart the client. This does not directly fix the problem; it reduces parallel paths so one application does not use the system proxy while another uses a custom SOCKS port, producing contradictory test results.
Conclusion: running status cannot replace a request test
Until the local port is listening and the browser is sending requests to it, the availability of the remote server has not yet been tested.
Step 1: Confirm the local port and system proxy
On Windows, open PowerShell first and check whether v2rayN’s local SOCKS port accepts a TCP connection. If you changed the port, replace 10808 in the command with the value shown under “Parameter Settings”. A successful test only proves that the port is listening; it does not prove that the remote exit works.
Test-NetConnection 127.0.0.1 -Port 10808The result should show TcpTestSucceeded as True. If it is False, first confirm in the v2rayN main window that a server is selected, then choose “Servers” → “Set as Active Server”. Restart the core afterward. If it still fails, check the logs directly for a port conflict or configuration loading error.
Once the local port works, check v2rayN’s system proxy mode. For testing with a regular browser, choose “Set system proxy automatically” from the tray menu. Windows “Settings” → “Network & Internet” → “Proxy” should show the local proxy configuration written by the client. If the old proxy address remains after quitting the client, disable the system proxy first, then restart the client.
- Select a server known to work and set it as the active server.
- Confirm that the local listening address is
127.0.0.1and that the SOCKS and HTTP ports do not overlap. - Enable “Set system proxy automatically”, then fully close and reopen the browser.
- Using a browser window with no standalone proxy rules, visit two different domains. Note whether both fail or only a specific domain fails.
Step 2: Test the proxy exit without the browser
The browser may retain an outdated proxy setting, DNS cache, or extension rule. To determine whether the failure occurs before or after the browser, send a request directly through the local proxy port. On macOS and Linux, use curl in a terminal; on Windows, the same test works when the corresponding command-line tool is installed.
curl --proxy socks5h://127.0.0.1:10808 https://v2rayroot.com/ -I --connect-timeout 10In socks5h, the letter h means that the domain name is resolved through the SOCKS connection. If the response is HTTP/2 200, HTTP/1.1 200, or a normal redirect status, the local port, server, and remote DNS have completed at least one full request. The website issue is then more likely related to the browser proxy, cache, extensions, or system-level interception.
If the command immediately reports that it cannot connect to 127.0.0.1, the failure is in the local listener. If it times out after about 10 seconds, the local port has usually accepted the request, but the remote server or destination has not responded. If only one domain fails, check routing rules, DNS resolution, or the target service instead of immediately replacing the entire configuration.
| Test result | Path assessment | Next step |
|---|---|---|
| Local port connection refused | The core is not listening or the port is incorrect | Verify 10808, restart the core, and check for port conflicts |
| Connection timed out after 10 seconds | Server handshake or exit failure | Switch servers and review the core logs |
| Command succeeds, browser fails | The proxy core path is working | Reset the browser and system proxy settings |
| Only a few domains fail | DNS or routing rule mismatch | Temporarily use global proxy mode for comparison |
Step 3: Check DNS and routing rules
DNS failures often appear as a node latency test returning a value while a webpage keeps waiting after you enter its domain. A latency test may connect directly to the server address, while the browser still needs to resolve the target domain. Run nslookup v2rayroot.com in the system terminal first to confirm that your device gets an address. Then use the earlier socks5h command to compare local resolution with resolution through the proxy.
If an IP address works but the domain does not, check DNS first. In v2rayN 7.x, DNS options are available under “Settings” → “Parameter Settings”. During troubleshooting, do not add several complex rule sets at once. Restore the basic configuration provided by the client, save it, and restart the core. You can also clear the system DNS cache; on Windows, run ipconfig /flushdns, then fully quit and reopen the browser.
If only some websites fail, temporarily switch routing to global proxy mode for comparison. If global mode works but rule mode fails, the server is probably usable and the problem is concentrated in domain rules, IP rules, or the direct-connection path. Pay close attention to rule priority: earlier rules match first, and an overly broad direct-connection rule may bypass the proxy for the target request.
- All domains fail: Check system DNS, the client’s DNS settings, and whether the server domain resolves.
- Domain fails but IP works: Narrow the issue to DNS and leave protocol parameters unchanged for now.
- Global mode works: Disable custom routing rules one by one to find the incorrect direct-connection or blocking condition.
- Global mode still fails: Continue by checking the server handshake, transport layer, and server exit.
Latency shows 120 ms. Why does the website still time out?
A latency test covers only a specific probe request. Use curl --proxy socks5h://127.0.0.1:10808 to make a complete HTTPS request, then determine whether the server actually provides working internet access.
Global proxy mode fixes the issue. What should I change?
Under “Settings” → “Routing Settings”, check the order of custom rules. Disable recently added domain, GeoIP, or direct-connection rules first, restoring one group at a time and retesting after each change.
All servers stopped working right after updating the subscription?
Confirm that the active server was not deleted or replaced. Select a server again and set it as the active server. If the server parameters changed substantially, restart the core after updating so it can load the new configuration.
It shows as started on Android, but apps still cannot connect?
In v2rayNG or v2flyNG, first disable per-app proxy settings and custom routing, then run a global test with a single server. Once it works, restore the app scope and routing rules.
Step 4: Use logs to diagnose server, protocol, and TLS failures
Once the local port and traffic interception work, logs are the main evidence for remote failures. In v2rayN, view core output in the log area of the main window, or adjust the log level under “Settings” → “Parameter Settings”. The info level is usually enough for troubleshooting. Increase verbosity only when necessary, then restore it afterward to avoid repetitive output obscuring the diagnosis.
The protocol names VMess and VLESS do not by themselves prove that the configuration is correct. The server address, port, user identifier, transport, TLS, SNI, path, and service name must match the server side. Subscription imports normally populate these fields, but manually changing even one can result in a TCP connection followed by TLS or protocol authentication failure.
Error: failed to listen TCP on 127.0.0.1:10808
Cause and fix: The local port is already in use by another process—quit duplicate client instances, or choose an unused port under “Settings” → “Parameter Settings”, save it, and restart the core.
Error: failed to find an available destination
Cause and fix: The outbound server address cannot be resolved or no destination is available—check the server address for typos, restore the basic DNS configuration, and restart the core.
Error: lookup server.example: no such host
Cause and fix: The server domain cannot be resolved—check DNS availability on the current network, update the subscription again, and confirm that the server address was not truncated manually.
Error: TLS handshake timeout
Cause and fix: The client attempted to establish TLS, but the handshake did not finish in time—check the server port, SNI, transport, and system time, then compare with another server from the same subscription.
Error: connection reset by peer
Cause and fix: The connection reached the remote side but was actively reset—check whether the protocol and transport parameters match, then test other servers to distinguish a single-server failure from local network restrictions.
If only one of three servers in the same subscription fails, first suspect that server’s configuration or status. If every server produces exactly the same local port error, fix the local configuration first. If all TLS servers fail, also verify the system date, time zone, and minute value. A significant clock offset can cause certificate validity checks to fail.
Conclusion: identical errors define the scope of the investigation
For one-server errors, inspect server parameters. For errors across all servers, inspect the local port, DNS, and system environment. Comparing whether the errors match is more effective than switching servers at random.
Step 5: Restore the minimum configuration, then add features back one at a time
If the cause is still unclear after the first four steps, establish a baseline with the minimum configuration. Keep one server freshly obtained from a working subscription update, disable custom DNS, routing rules, per-app proxy settings, and TUN, and enable only the system proxy. Restart the client, test the local port, run one proxy request, and then open the browser.
Once the minimum configuration works, restore features in a fixed order: DNS first, then routing rules, followed by browser- or app-level rules, and TUN last. After each change, visit the same two test domains and record the step where failure begins. This isolates the problem to one configuration layer instead of guessing among dozens of settings.
The same logic applies on Android with v2rayNG or v2flyNG: select one server, disable custom routing, confirm that ordinary webpages load, and then restore per-app settings. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Even with the same subscription, they may behave differently because their supported features and specific transport parameters differ.
- Reset to one server, basic DNS, system proxy, or the default traffic interception mode.
- Confirm that
127.0.0.1:10808or the port in the current configuration accepts connections. - Send a request with
socks5hto confirm that both domain resolution and the exit work. - Restore routing rules and compare global mode with rule mode.
- Restore TUN, per-app scope, and other advanced settings last.
| Break point | Typical symptom | What to check |
|---|---|---|
| Local listener | 10808 connection refused | Core startup, configuration format, and port conflicts |
| Traffic interception | Command succeeds but browser fails | System proxy, browser extensions, and stale settings |
| DNS | IP works but domain fails | Resolution method, cache, and server domain |
| Routing | Global mode works but rule mode fails | Rule priority, direct-connection conditions, and blocking conditions |
| Server exit | Handshake times out for multiple destinations | Server status, protocol parameters, TLS, and SNI |