First identify whether the core failed to start, the node handshake failed, or browser traffic never reached the proxy. The steps below use v2rayN on Windows, with additional checks for Android. Work through system time, listening ports, TLS, routing, and subscription status in order. Change one setting at a time, then repeat the same test. Port numbers are examples, not defaults for every client.
1. Keep the logs and pinpoint where the timeout occurs
A timeout is an outcome, not a diagnosis. A reachable TCP port does not mean proxy authentication succeeded; a failed connectivity test does not necessarily mean the node is offline—the test target itself may be unreachable. In v2rayN, keep the log entries at the bottom of the main window for the latest startup and one failed request. Note the node, test method, and time.
For diagnosis, use one fixed node and one HTTPS target. Don’t switch nodes, DNS, the core, and routing all at once, or you won’t know what fixed the problem. The right-click test in v2rayN is initiated by the client; browser traffic depends on system proxy settings or TUN mode. The paths they take before reaching the local proxy may differ.
- Core starts and exits immediately: Check startup logs, listening ports, and configuration parsing first. There’s no need to change remote TLS settings yet.
- Both the test and web pages fail: Check the system clock, node address, remote port, and handshake fields.
- Test succeeds, but the browser fails: Check the system proxy, any custom browser proxy, and routing rules first.
- Only one site fails: Test another destination first to rule out a problem with the site itself.
2. System clock: sync it before retrying the handshake
If the system date is clearly wrong, correct it first. TLS certificates have validity periods, and VMess authentication also depends on a time window. Even with a VLESS node, the TLS layer still requires a reasonably accurate clock. A correct time zone alone isn’t enough—check the actual date and time.
-
Open date and time settings
In Windows 11, go to Settings → Time & language → Date & time and check the year, date, and current time. In Windows 10, the setting is also under Time & language, though the page name may differ slightly.
-
Sync the clock
Turn on Set time automatically, then select Sync now under Additional settings. Choose the time zone for your location. A different displayed time zone won’t cause TLS failures if the actual timestamp is correct.
-
Run the test again
After confirming the sync succeeded, re-enable the original node in v2rayN and run the same test again. On Android, go to Settings → System → Date & time and check automatic time; some devices put this page under Additional settings.
If the log reports an expired certificate, first check whether the current time shown in the error is accurate. If the certificate still appears expired after correcting the clock, ask the node provider to check the server certificate. Don’t use “skip certificate verification” as a permanent fix.
3. Port conflicts: distinguish local listeners from remote ports
The local port accepts app requests; the remote port connects to the node server. They aren’t interchangeable. For example, a local mixed inbound port might be 10808 and a remote TLS port might be 443. The port in the server editor is not the local proxy port you should enter in your browser.
In v2rayN, open Settings → Parameter settings and check the local listening port on the Core basic settings page. Section names vary slightly between versions; the mixed listener is usually labeled “Local mixed listening port.” Don’t copy the example value. Then run this read-only command in Windows Terminal, replacing the number with the port shown in your settings:
netstat -ano | findstr ":10808"Check that the Local Address column shows the port you’re investigating and that its state is LISTENING. Don’t mistake a connection with that port in the remote address for a listener. The last column is the PID; match it to a process under Task Manager → Details. If the PID column isn’t shown, right-click a column heading and select it from the menu.
- It belongs to the active proxy core: This is usually the expected listener; a process using the port doesn’t by itself mean there’s a conflict.
- It belongs to an old client instance: Exit the old instance normally, then restart the current client. Don’t force-quit an unfamiliar system process.
- It belongs to another app: Change the local listening port and update any apps where you entered the proxy port manually. If you use the system proxy, select System proxy → Set system proxy again.
- No listener is listed: Check the logs for a core startup error. Enabling the system proxy doesn’t start a local listener service.
4. TLS and SNI: check each field against the original node settings
In the v2rayN server list, right-click the node and select Edit server. Check the address, port, and protocol first, then review the TLS and transport fields. The address determines where to connect; SNI specifies the server name used in the TLS handshake. They don’t always have to match. Follow the provider’s configuration—don’t change SNI to an IP just because the address is an IP.
| Field | What to check | Common mistake |
|---|---|---|
| Address and port | Match the current subscription node; use the server’s actual listening port | Entering the local port 10808 as the node port |
| TLS and SNI | Match the TLS mode and server name to the provider’s requirements | Entering the domain of a popular website at random |
| Transport settings | Check the WebSocket Host and Path, or the gRPC serviceName | Copying only the address and UUID and missing transport parameters |
| Authentication fields | Check the UUID, password, and protocol-specific parameters | Treating VMess and VLESS as interchangeable protocols |
| REALITY settings | Check the provider’s public key, shortId, serverName, and other fields | Removing parameters as if this were a standard TLS setup |
The WebSocket Host and TLS SNI belong to different layers; don’t assume they’re the same field. With REALITY, also check that the selected core supports the configuration. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; their node configuration support isn’t interchangeable. In v2rayN, check the core assigned to each protocol under Settings → Parameter settings → Core type settings.
x509: certificate has expired or is not yet valid
Cause: The local clock is wrong or the server certificate is outside its validity period. Fix: Correct the system time first. If the error persists, ask the provider to check the certificate.
tls: handshake failure
Cause: TLS negotiation was rejected, possibly because of SNI, server policy, or the inbound configuration. Fix: Compare TLS and SNI with the original subscription, then ask the provider to investigate using server logs. This message alone doesn’t identify a single cause.
5. Routing and traffic capture: check app traffic after the test succeeds
If the connectivity test succeeds but the browser still can’t load pages, first check whether its requests reach the client. In v2rayN, select System proxy → Set system proxy at the bottom of the main window, then check whether the browser has a separate fixed proxy configured. Apps that ignore the system proxy won’t be forced through it just because the system proxy is enabled.
- Use one traffic capture method at a time. To troubleshoot a regular browser, exit other proxy apps, temporarily turn off TUN, and test with the system proxy. If you need to check TUN, verify the Enable TUN status on the main screen and look for virtual adapter or permission errors in the startup logs.
- Then check the routing mode. View the current mode under Routing at the bottom of the main window. Temporarily select a global mode that sends the target traffic through the proxy, note the original mode, and restore it after testing.
- Check the matching rules. Go to Settings → Routing settings and review the rule order for the active mode. The core evaluates rules in order, so an earlier direct or block rule may match before the intended proxy rule.
- Check DNS last. Only investigate DNS if you see a domain resolution error, a problem limited to specific domains, or a resolution result that conflicts with routing. Browser secure DNS, system DNS, and core DNS may all take effect separately—don’t replace them all at once.
If switching to global mode restores access, focus on routing rules or the resolution path rather than generating a new UUID. If there are no request entries in the logs, revisit the traffic capture method. Keep in mind that lower log levels may not show every connection, so the absence of an entry isn’t conclusive. If you temporarily increase log detail, restore the previous level promptly to avoid logging browsing activity for longer than necessary.
6. Expired subscriptions and server issues: confirm with comparison tests
A successful subscription update only means the client retrieved the content. It doesn’t mean your account has data remaining or that every node is online. In v2rayN, update the relevant subscription from the Subscription groups menu at the top. If the current proxy isn’t working, try Update current subscription (without proxy) to connect directly. If the subscription URL isn’t reachable directly, don’t repeatedly delete existing nodes—keep your current configuration for now.
- Check the update log: Distinguish between a fetch failure, a parsing failure, and a successful update. HTTP 401 or 403 may indicate expired credentials or an access policy; confirm your account status on the provider’s website.
- Check your account status: Review the plan expiration date, remaining data, and device limits. Nodes still listed in the client don’t mean the credentials are still valid.
- Compare networks: On the same device and node, test both your usual network and a mobile hotspot. If only one network fails, focus on its restrictions and DNS instead of reinstalling the client.
- Compare nodes: On the same network, test another node in the same group. If only one node fails, record its server address and the time of failure, then ask the provider to check the server and service status.
In v2rayNG for Android, check the subscription URL under Subscription group settings in the top-right menu, then update it using Update subscription. Open a node’s card to edit it. Some versions put the update option in the group menu; use the logs and changes in the node list to confirm the result. Before sharing a screenshot, remove subscription links, UUIDs, passwords, and QR codes—they may grant direct access to the connection.
7. Read errors in context and keep a reproducible troubleshooting record
Read error messages together with the surrounding log entries. The same connection-refused message points to very different fixes depending on whether it refers to a local listener or a remote node. The messages below can help identify the stage, but none replaces the full log.
bind: address already in use
Cause: The local address and port the core tried to bind are already in use. Fix: Identify the listening process, exit any duplicate instance, or change the local listening port. Windows may show a similar message about a socket address already being in use.
connection refused
Cause: The destination refused the connection, possibly because no service is listening or a policy rejected it. Fix: Check the destination address first. If it’s local, see whether the core is running; if it’s remote, check the node port and service status.
context deadline exceeded
Cause: An operation didn’t finish within the allowed time. This may happen during dialing, the handshake, or response reading. Fix: Use the preceding dial target and error chain to identify the stage; don’t just increase the timeout to hide the issue.
no such host
Cause: The current resolution path didn’t return a valid result for the target host. Fix: Determine whether the domain in the error is the node address or the destination you’re visiting, then check its spelling, domain status, and DNS settings.
After a troubleshooting session, keep at least the following details. They make retesting easier and reduce back-and-forth with the provider. Don’t send a full configuration file or a node share link that can be imported directly.
- Client name, exact version, active core, and operating system version.
- Time of failure, network used, test destination, and test method.
- System time sync result, local listening port, and the first relevant error with sensitive details removed.
- The single setting changed, results before and after, and comparison results from another network or node.