For users who have imported a configuration but are seeing test timeouts or websites that won't load. First establish whether the local proxy works, then check the remote port, transport and TLS, and finally review routing and DNS. These steps use v2rayN on Windows as an example. Change one setting at a time and use the logs and the same request to verify the result—don't assume a failed speed test means the node is down.
1. Tell a Test Timeout from a Connection Failure
A “timeout” only means an operation didn't finish within the allotted time; it doesn't identify where the problem is. Latency tests, subscription updates and browser requests follow different paths. If the subscription server won't load, an imported node may still work. And a slow test endpoint doesn't mean every website is unreachable.
| What you're seeing | Check first | Next step |
|---|---|---|
| Only the latency test times out | Whether websites load and the test endpoint is reachable | Send a proxy request to a fixed URL |
| Browser can't load pages; no requests appear in the core logs | System proxy, local listening port, browser proxy extensions | Test the local proxy first |
| Logs show a timeout connecting to the remote server | Node hostname resolution, remote port, current network | Check remote reachability |
| Only some websites fail | Routing rules, destination website and DNS | Check the outbound route logged for that domain |
Before testing, note the node name, client version, core in use and test time. v2rayN is the client interface; the core actually establishes the connection. An open client window doesn't mean the core started successfully. Find the version under Help → About. Menu labels may differ between releases, so record what you see on your device.
2. Sync the System Clock and Set Up a Minimal Test
An incorrect local date or time can affect certificate validity checks and may cause VMess time-based authentication to fail. VLESS doesn't use the same time-based authentication, but TLS connections still check certificate dates. Sync your date and time first; don't attribute every authentication error to the protocol.
-
Sync the clock
In Windows 11, open Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now under Additional settings. Check the date and time zone too; changing the displayed time zone won't fix an inaccurate system clock.
-
Pin the node
In the v2rayN node list, right-click the target and select Set as active server. Keep this configuration fixed while troubleshooting and avoid automatic switching, so consecutive requests don't go through different servers.
-
Simplify the connection path
Turn off Enable TUN in the v2rayN main window and exit other proxy or VPN apps that may intercept traffic. This is just to reduce variables. Test TUN separately after confirming the local proxy works.
-
Reproduce the issue once
Open the log panel, note the current time and visit one fixed URL. Keep the errors around that request. Don't switch through a dozen nodes and then try to guess the cause from mixed logs.
3. Check the System Proxy and Local Listening Port
In v2rayN, open Settings → Parameter settings and find the local listening port settings. Confirm the actual port and protocol. The examples below use a SOCKS proxy at 127.0.0.1:10808; this isn't the default for every version or installation. If your local port differs, update the commands accordingly.
Run these two commands in Windows PowerShell. The first checks the listening status and process ID. The second bypasses differences in whether an app reads the system proxy and sends a request directly through the local SOCKS proxy. example.com is just a sample test site; if one request fails, try another known-working URL to compare.
netstat -ano | findstr ":10808"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 15 -I https://example.com/- No LISTENING state: Check whether the core is running and whether the port is correct. Don't rely on the client window alone.
- Listening, but you don't recognize the PID: Check the PID in Task Manager → Details. Multiple IPv4 and IPv6 listeners aren't necessarily a conflict; the key is which process owns the port.
- The command returns an HTTP response, but the browser fails: Check the system proxy and browser extensions first. Status codes such as 301 or 403 still mean an HTTP response was received, but don't guarantee that every feature on the destination site will work.
- Local connection is refused immediately: Fix the listening address, port or core startup issue first. At this point, there's no evidence that the remote node is down.
Once the command succeeds, select Set system proxy automatically from the System proxy menu at the bottom of v2rayN, then retry in your browser. In Windows, check Settings → Network & Internet → Proxy and confirm the proxy address and port. The port must match the client's HTTP or mixed proxy; don't enter a SOCKS-only port arbitrarily.
Bottom line: Verify the local proxy works first
If a request with the local proxy specified explicitly succeeds but the browser fails, fix the app's proxy settings first. Don't keep changing the node UUID, TLS or transport path.
4. Use the Logs to Distinguish DNS Errors, Refusals and Timeouts
Once the local proxy works, check errors from the core's connection to the remote server. These are common log snippets; the surrounding text can vary by core and operating system. A single error points to an area to investigate, but check the associated destination address and timestamp to narrow it down.
no such host
Cause: A hostname couldn't be resolved. It may be the node's hostname or the destination website's hostname.
Fix: First identify which hostname appears in the log, then check its spelling and your local DNS. Don't replace the entire node just because you see a resolution error.
connection refused
Cause: The connection was explicitly refused, often because nothing is listening on the destination port or the connection was actively rejected.
Fix: Check the remote port and service status. If the address in the error is a loopback address on your own machine, go back to checking the local listener.
i/o timeout
Cause: A network read or write didn't complete in time. Possible causes include the network path, a firewall, server load or a later handshake stage.
Fix: Find out whether the error happened during connection setup or the handshake, then test the same configuration on another network. Don't conclude that the account is invalid based on this message alone.
address already in use
Cause: Another listener is already using the local address and port the core needs to bind to.
Fix: Use the PID to identify the process, close duplicate instances, or change the local port and update the app's proxy settings to match.
If you know the server address and port, use PowerShell's Test-NetConnection to check TCP connectivity. The example below shows the command format only; example.com:443 is not your node. For an actual test, use the server and port supplied by your subscription provider.
Test-NetConnection -ComputerName example.com -Port 443TcpTestSucceeded: True only confirms that a TCP connection was established; it doesn't confirm that TLS, VMess or VLESS authentication succeeded. This TCP check also can't verify data channels that use UDP. If the same configuration works on a mobile hotspot but not on your current network, investigate network restrictions first. Check the server logs too, and don't treat one network comparison as a definitive diagnosis.
5. Check Transport and TLS Settings One by One
If the remote port is reachable but the handshake fails, open the node editor and compare each setting with the provider's original configuration. Port 443 doesn't automatically mean TLS should be enabled, and you shouldn't disable certificate verification just to make an error disappear.
| Setting | What must match | Common mistake |
|---|---|---|
| Protocol and authentication | VMess or VLESS, UUID, and any other authentication fields required by the configuration | Changing only the protocol name while keeping fields from the other protocol |
| Address and port | Server address and remote listening port | Entering local port 10808 as the remote port |
| WebSocket | Transport, path and Host | Omitting the slash before the path, or treating Host as SNI |
| gRPC | Transport, serviceName and TLS settings required by the server | Adding a slash to serviceName as if it were a WebSocket path |
| TLS | Whether TLS is enabled, serverName/SNI, certificate trust and validity | Changing the connection address to an IP and changing SNI to that IP as well |
| REALITY | Required serverName, public key, shortId, fingerprint, flow and other settings | Treating it as ordinary TLS or mixing parameters from different configurations |
x509: certificate has expired or is not yet valid
Cause: The certificate validity check failed. The local clock may be wrong, or the server certificate may have expired.
Fix: Sync the system clock first. If the error persists with the correct time, ask the service provider to check the certificate deployment and renewal.
websocket: bad handshake
Cause: The WebSocket upgrade handshake didn't get the expected response, often because the path, Host or reverse proxy rules don't match.
Fix: Restore the path and Host from the original configuration, and ask the server operator to check the forwarding rules for that site.
VMess and VLESS are proxy protocols; WebSocket and gRPC are transport methods; TLS is a security layer. They aren't interchangeable options. If fields look incomplete after updating a subscription, reimport a configuration confirmed by the provider and check whether your current core supports that combination. Don't cobble together settings from multiple nodes.
6. Check Routing, DNS and TUN Last
If the same node can reach some websites but not others, routing rules deserve more attention than when every request fails. The routing selection at the bottom of v2rayN and the system proxy are separate: the system proxy determines where an app sends requests, while core routing determines which outbound route handles them. Changing core rules won't help if an app bypasses the local proxy.
- Check the route match first: Visit the failing domain and check whether the request appears in the logs and whether it goes through the proxy or connects directly. If needed, briefly increase the log level, reproduce the issue and then restore it to avoid logging excessive browsing details.
- Compare with one variable changed: Select a routing preset that sends test traffic through the proxy outbound and repeat the same request. If it works, check the order and scope of the original rules. You don't need to keep the test preset.
- Distinguish the two DNS lookups: Resolving the node server's hostname determines whether it can be reached. Resolving the destination website's hostname affects the visit and routing. Fixing one doesn't guarantee the other works.
- Check routing resources:
geositeis a domain collection;geoipis an IP address collection. Missing resources or invalid rule references can prevent the core from loading. Check the core startup logs before updating the relevant resources.
After the local proxy works, enable Enable TUN to test apps that don't use the system proxy. TUN usually involves a virtual network adapter, routing and DNS interception, and may require additional permissions. If your connection drops as soon as you enable it, turn TUN off and confirm the network recovers. Then check permissions, routes from other VPNs and virtual adapter conflicts. Don't change transport settings at the same time.
Bottom line: Isolate TUN issues with the same request
If the same node works with the local proxy specified explicitly but fails only when TUN is enabled, investigate the virtual adapter, routing and DNS interception before changing the remote protocol.
7. Common Questions and When to Stop Troubleshooting
Every latency test times out, but websites load. Should I switch nodes?
Not yet. Confirm that the websites are actually going through the proxy, then check the test endpoint, test method and timeout setting. Verify real access by repeating the request to the same URL; don't use a single test result as a proxy connection check.
Subscription updates time out. Should I enable updates through the proxy?
First check that the subscription URL is valid and that a working proxy is available. If the subscription site fails over a direct connection but works through a proxy, select the appropriate proxy update option. If none of your nodes work, forcing updates through a proxy can create a loop.
It works on my computer, but the same configuration fails on Android. Why?
Connect both devices to the same network first, then compare the time, active configuration and logs. v2rayNG uses the Xray core, while v2flyNG uses the v2fly core; supported configuration features depend on each core. A configuration that requires an Xray-specific feature isn't necessarily compatible just because its share link imports successfully.
Will increasing the timeout from 5 to 30 seconds fix it?
It may give a slow response more time, but it won't fix an incorrect port, authentication field or certificate. Use a fixed timeout to compare results before and after. If the request still fails, keep investigating the failure stage shown in the logs.
Stop retrying random settings when the local port works, the configuration matches its source, the system clock is correct, and the same node fails at the same stage on two independent networks. At that point, send the service provider the redacted timestamp, core version, error snippet and remote port test result. That's more useful than continuing to change DNS settings at random.
- Keep the full timeline for one failed request; don't send your entire private configuration.
- State whether the failure occurred at the local listener, remote connection, TLS handshake or destination access stage.
- When troubleshooting is complete, restore your original routing, log level and preferred proxy mode.