V2Ray TLS Handshake Failed? Fix Certificate Errors, System Time & SNI

1. Check the logs to pinpoint the failure

Open the side menu on the v2rayNG home screen and tap “Logs.” Note the current time, return to the home screen, stop the connection, then reconnect to the same node and make a web request. Go back to the logs and review only the errors added after this test. Menu layouts vary by version; look for “Logs.”

Don't copy only the last line, failed to process outbound traffic. This is usually a summary from a higher layer; the underlying cause often appears after x509, tls, or dial tcp. Save the full error chain, from the connection target through the innermost cause, so you can tell whether to fix the clock, change a field, or contact the server administrator.

This flow illustrates a standard node using TCP with TLS. Errors such as connection refused or i/o timeout can occur before a certificate is received. An x509 error usually means the connection reached certificate validation. A latency test can return a value without confirming that TLS validation succeeded, especially if it tests only the TCP connection.

2. Sync the date and time on Android

On Android, go to Settings → System → Date & time, then turn on “Set time automatically” and “Set time zone automatically.” Some devices put these options under “Additional settings” or “General management”; search Settings for “Date & time” if needed. Then return to v2rayNG, stop and restart the connection, and let the core perform a fresh handshake.

1. Check the date and year: After a long shutdown or manual clock change, the device may be outside the certificate's validity period. Even a small discrepancy can matter: a certificate renewed moments ago may appear not yet valid if the clock is a few minutes behind.
2. Make sure the clock actually synced: Turning on automatic time does not guarantee a successful sync. First confirm the device has a working internet connection, then check that the displayed date and time are current.
3. Compare the two timestamps in the log: Validity errors often show both the client's current time and the certificate's start and end dates. If the current time is clearly wrong, fix the device clock first. If it is correct but the certificate has expired, the server needs a renewal.

The time zone affects how the time is displayed; certificate validation compares the actual point in time. Simply switching to another time zone will not usually fix an incorrect system clock. Don't set the clock back to make an expired certificate work temporarily; this can also disrupt subscription requests and other secure connections.

3. Check the server address, SNI, and transport Host

In v2rayNG, tap the node's edit icon and check “Address,” “Port,” “TLS,” and “SNI” or “Server name.” For WebSocket nodes, also check “Host” and “Path.” Keep a copy of the original configuration before saving. You can duplicate a subscription node for comparison so a test change doesn't overwrite every node.

“Fake domain” is not a precise field name. Some guides use it for both SNI and the HTTP Host header, but they operate at different layers. They may be the same or differ depending on the server setup. Check each value separately rather than forcing both domains to match.

If the node's address is an IP but the certificate covers only a domain, the correct server name must be provided for validation. IP-based validation can work only if the certificate includes that IP address. The SNI field usually takes a hostname only—no https://, port, or path. What happens when it is left blank depends on the core and node type, so don't guess.

Port 443 doesn't guarantee that the correct TLS service is running there. A connection to the wrong reverse proxy endpoint may return another site's certificate. VMess and VLESS are proxy protocols; TLS is a transport security layer. Switching from VMess to VLESS alone won't fix a certificate name mismatch.

4. Use the exact error to distinguish certificate and server issues

These snippets may appear within a longer error chain, and the surrounding messages can vary by core version. Follow the most specific error rather than choosing a fix based only on the words “handshake failed.”

If the clock and server name are correct, and the same node returns the same certificate error across different networks, the server's certificate configuration is the more likely cause. If it fails only on one Wi-Fi network, complete that network's sign-in or captive portal check first, then investigate possible network filtering. Opening an HTTPS page in a browser is only a clue; it doesn't prove that the node's core sees the same certificate chain.

5. Keep allowInsecure off; troubleshoot TLS and REALITY separately

Return to the node editor and find “Skip certificate verification,” “Allow insecure connections,” or the corresponding allowInsecure option. Keep it off for normal use. This option relaxes server identity checks; it does not complete a certificate chain, renew a certificate, or correct a misconfigured transport endpoint.

{
  "tlsSettings": {
    "allowInsecure": false
  }
}

This is an example of one field in a standard TLS configuration, not a complete node that can be imported as-is. If you use the graphical interface, change the corresponding switch rather than pasting this snippet over the entire configuration file. If enabling certificate verification bypass makes the connection work temporarily, that only suggests a validation issue; it does not confirm that the connection reached the intended server.

• Standard TLS: Check the validity period, server name, certificate chain, and trust source. Once corrected, use the connection with certificate verification enabled.
• REALITY: Check the server name, authentication public key or other required credentials, shortId, and any other parameters specified by the node provider. Field names and locations vary by version; refer to the original subscription and your current client.
• Protocol support: v2rayNG uses the Xray core; v2flyNG uses the v2fly core. Don't assume the latter can use a REALITY configuration intended for the former.

6. Change one setting at a time, then verify the full connection

Change just one thing at a time: check the clock first, then the server name, then the certificate chain. After saving the node, stop and restart the connection, make a new request, and check the new logs. If you change DNS, routing rules, the port, and TLS settings all at once, you won't know which change fixed the issue.

1. Keep a copy of the original node and note the client version, core version, and time of the error so you can reproduce the issue.
2. With certificate verification still enabled, revisit the destination that originally failed and make sure you're not seeing a cached page.
3. Check the new logs for the same x509 or tls error. Don't rely on a single latency test as the only measure of success.
4. Recheck the fields after updating the subscription. If the update overwrites a manual fix, ask the subscription administrator to correct the source configuration.

In the desktop version of v2rayN, double-click a node to open its editor and check the TLS server name and “Allow insecure connections” option. Check the core output in the log area or log window. On Windows, sync the clock under Settings → Time & language → Date & time. Menu labels vary by version, but the same three checks always apply: time, certificate name, and trust chain.

7. TLS certificate troubleshooting FAQs