Use this guide when v2rayN on desktop, v2rayNG, or v2flyNG on Android times out, fails to connect, or cannot load webpages after startup. First confirm whether requests reach the core, then check the clock, subscription, remote port, and protocol settings. Finally, compare the logs against one reproducible request. Change one variable at a time to avoid mistaking a local proxy issue for a failed server.
1. Identify where the failure occurs: startup, connection, or web request
A “timeout” means a step did not finish in time; it does not necessarily mean the server is offline. A connection test in the client, a browser request, and a subscription download may use different destination addresses, routing, and timeout limits. Note which action fails first, then check the relevant layer.
On desktop, only apps configured to use the system proxy send traffic through the local proxy; an explicit proxy test removes that uncertainty. On Android, a VPN icon confirms that VpnService is running, but does not prove the remote handshake or destination website is working.
| What you see | Check first | What you cannot conclude yet |
|---|---|---|
| Client stops immediately after you click Start | Configuration loading, core startup, port conflicts | You cannot conclude that the remote connection is down |
| Every server test times out | Test destination, system time, local network, and core logs | Do not delete every server based on a single round of tests |
| One server fails while others work | That server’s address, port, credentials, and transport settings | Reinstalling the client does not prove the server works |
| Test succeeds, but the browser still cannot load pages | System proxy, per-app settings, routing, and destination DNS resolution | A successful test does not mean every app will work |
2. Check system time and your local network
First, restore automatic time synchronization. VMess authentication depends on the clock, and TLS checks certificate validity against the local time. If the clock is significantly off, authentication may fail even when a TCP connection to the server port succeeds. Changing the time zone manually is not the same as synchronizing the clock: the displayed time zone and clock accuracy are separate issues.
- Windows: Go to Settings → Time & language → Date & time, turn on Set time automatically, select Sync now, then restart the client connection.
- Android: Open Date & time in Settings and enable automatic time. Depending on the manufacturer, this option may be under System or Additional settings; you can also search Settings.
- Check your basic internet connection: Pause the proxy and visit a site that normally works without one. If public Wi-Fi requires sign-in, complete the sign-in first, then start the client.
- Switch networks once: On the same device, using the same server and test destination, compare Wi-Fi with mobile data. Do not switch both the server and network at once, or you will not know which made the difference.
If only one network works, note the differences, including IPv6 availability, router policies, and whether another VPN is active. Do not disable the system firewall outright. If you need to change its settings, confirm the client’s outbound access and check the specific block logs.
3. Update the subscription and verify the active server configuration
A successful subscription update only means the configuration was downloaded; it does not mean every server in it works. Likewise, a subscription timeout does not mean all locally saved servers are unusable. Subscription downloads and server connections are separate requests, so test them separately.
- In v2rayN, check the target group under Subscription groups, then update that subscription. Menu names may vary by version; make sure you distinguish a direct update from an update through the proxy.
- In v2rayNG or v2flyNG, check the subscription URL and update result in the subscription settings. If the subscription site requires a proxy, first connect through a server you have already verified, then choose the option to update through the proxy.
- After updating, select the intended server again and restart the service. Do not rely on a matching display name: open the editor and check whether the server address, port, and protocol actually changed.
- Note the client version and the actual core name and version. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Do not assume they support the same fields just because their interfaces look similar.
If the subscription returns a login page or an error page, importing it again usually will not help. Check your account status, make sure the subscription URL is complete, and look for parsing errors in the update log. Do not enter a subscription URL in the “Server address” field, and do not use a single vmess:// or vless:// share link as a subscription URL for scheduled updates.
4. Test the remote server port and local listening port separately
The remote port connects to the server; the local listening port accepts app requests. Do not confuse the two. The examples below use remote port 443 and local SOCKS or mixed-proxy port 10808. These are examples, not universal defaults; check your actual server and client settings before running any tests.
On Windows, start by running these PowerShell commands and enter the actual server hostname or IP address and port when prompted. This tests TCP connectivity only; it does not verify the VMess, VLESS, TLS, or REALITY handshake, and it cannot determine whether UDP transport works.
$server = Read-Host "Enter the server hostname or IP address"
$port = [int](Read-Host "Enter the server port")
Test-NetConnection -ComputerName $server -Port $port -InformationLevel DetailedTcpTestSucceeded : True: The TCP handshake completed for this test. Check the protocol settings next; this does not confirm that the server works.TcpTestSucceeded : False: Check DNS resolution, the port, and the network path. The server may not be listening, or a firewall may be dropping traffic.- If the hostname resolves to multiple addresses, note the
RemoteAddressused by the command. One successful test does not mean every IPv4 and IPv6 address is reachable.
Next, test the local proxy. In v2rayN, go to Settings → Parameter settings and check the listening address, port, and proxy type; these options may be on the Basic settings page in some versions. If the actual port is 10808 and SOCKS is enabled, run the explicit proxy request below in a terminal. On Windows, use curl.exe so older versions of PowerShell do not interpret curl as a different command.
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/The 10- and 20-second limits here are diagnostic timeouts you set yourself, not speed-test results. socks5h sends the destination hostname to the proxy for resolution, but this alone does not reveal the final outbound path of every DNS request. The destination is only a test target; if it is unreachable, retry with a known-working HTTPS URL.
Bottom line: First confirm the request reaches the right proxy
If an explicit proxy request succeeds but the browser fails, check whether the browser bypasses the system proxy and verify the client’s system proxy status. If the explicit request is immediately refused locally, fix the listening port before switching remote servers.
5. Verify protocol, transport, and TLS settings
Once the port is reachable, compare each setting with the valid configuration provided by the server. The same address and port do not guarantee equivalent configurations. Save the original values before making changes. Change one setting at a time and restart the service so you can identify the cause if editing the UUID, SNI, or path breaks the connection.
| Setting | What to check | Common mistake |
|---|---|---|
| VMess / VLESS | Protocol type, UUID, and any required encryption or flow fields | Switching between protocols or adding a flow value that does not match |
| WebSocket | Transport type, path, Host header, and TLS setting | Omitting the leading slash in a path, or confusing Host with the server address |
| gRPC | Service name, TLS, and any related settings required by the server | Using a WebSocket path as the gRPC service name |
| TLS | SNI, certificate hostname, ALPN, and local time | Changing SNI at random or disabling certificate verification to hide a configuration error |
| REALITY | Server-provided public key parameters, short ID, serverName, and fingerprint settings | Guessing field values from their names or using a core that does not support the configuration |
The server address identifies the connection destination, TLS SNI supplies the server name during the handshake, and the WebSocket Host header is used in the HTTP request. These values may match, but they do not have to. Do not force them to one hostname just to make them “consistent.” For REALITY, check how fields map in your current client and core version instead of copying JSON field names from another version.
6. Match one request against the core logs
Stop running repeated speed tests. Clear the current log view, start the service, and make just one request. Note the time, selected server, destination hostname, and final complete error chain. The top-level “connection failed” message is usually just a summary; the actual cause is often in the subsequent dial, lookup, tls, or bind details.
In v2rayN, check the log area in the main window for startup and connection details. On Android, open the log screen from the client menu; the exact location varies by version. If you temporarily increase the log level, restore the original setting when you are done. Access logs may contain destination hostnames, so redact them before sharing. The examples below are common errors, but each can have more than one cause.
Error: bind: address already in use
Cause: Another process is using the local address and port required by the core. Fix: Check whether the client is running more than once. Identify and close the duplicate instance, or change the listening port and update the app proxy settings accordingly.
Error: connect: connection refused
Cause: The connection was actively refused, possibly because nothing is listening on the destination port or a policy rejected it. Fix: First determine whether the address in the error is the local proxy or remote server, then check the core’s startup status or the server port, as appropriate.
Error: i/o timeout
Cause: A network read or write did not finish in time. This line alone does not identify which layer failed. Fix: Use the destination address and operation from the surrounding log entries to test DNS resolution, the TCP port, and a full proxy request separately.
Error: no such host
Cause: The hostname could not be resolved to a usable address, or it may be misspelled. Fix: Identify whether the failed hostname belongs to the server or the destination, then check the spelling and current DNS settings. Do not change every routing rule.
Error: x509: certificate has expired or is not yet valid
Cause: Based on the current system time, the certificate is outside its validity period. Fix: Synchronize the local clock first. If the error persists with the correct time, ask the server administrator to check certificate renewal and deployment.
If the log shows EOF, it only means the connection reached the end of its input; it does not, by itself, prove the UUID is wrong. Check whether it occurred after the TCP connection, during the TLS handshake, or during the transport request. If the issue persists, share the client and core versions, error time, a redacted error chain, and the same server’s results on another network. That is more useful than a screenshot showing only “timeout.”
7. Still cannot connect? Run one final check based on what you see
By now, you should have a better idea whether the issue is the local proxy, remote reachability, or the protocol handshake. Keep settings you have verified as working, and do not reset routing, DNS, and subscriptions all at once. Use the smallest possible changes to narrow down these common cases.
Subscription updates keep timing out, but old servers still work. What should I change first?
Keep the old server and confirm its explicit proxy request succeeds. Then choose the option to update through the proxy in the subscription menu. If it still fails, check the subscription URL and account status. Do not delete working configurations just because the subscription server is unreachable.
v2rayN tests succeed, but why won’t my browser load pages?
Open the System proxy menu and confirm that Automatically configure system proxy is selected. Also check the browser’s own proxy settings. If you use TUN, check its startup log and routes too; system proxy and TUN are not the same switch.
Android says the client is running, but why does one app still fail?
Check the per-app proxy list in the client settings and confirm whether the target app is included or excluded. The meaning of a checked box depends on the list mode. Save your changes, restart the proxy service, then reopen the app to avoid reusing an old connection.
It disconnects only after the phone screen turns off and recovers when it wakes. Is that a server timeout?
First check whether the service was still running when the connection dropped. In Settings → Apps → the client → Battery, allow background activity; some manufacturers also have a separate autostart setting. After changing it, repeat the test with the same screen-off duration. Do not change server settings first.
It works on mobile data. Do I still need to reinstall?
Do not reinstall yet. Keep the same server and record the resolved addresses and port test results on both networks. If the difference is consistent, focus on the original network’s access policies, IPv6 route, and router settings, then share your findings with the network or server administrator.
Bottom line: Retest with the same server and destination, changing one variable at a time
After making a change, repeat the action that originally failed instead of relying on the client showing “Running.” Save the time and log for one successful request. If it still fails, continue from the steps you have already verified rather than changing settings at random from the beginning.