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

Start with the TLS failure point

The TLS handshake takes place between establishing a connection and authenticating the proxy protocol. VMess and VLESS are proxy protocols; TLS is a transport security layer, and they are not the same setting. A selected node and a running core only show that the local client started—they do not confirm that the remote certificate passed validation. First check whether the selected node uses TLS or REALITY for transport security, then follow the applicable steps below.

In v2rayN, find the timestamp for the failed request in the main window's log panel and copy the innermost cause—not just the top-level “connection failed” message. In v2rayNG and v2flyNG, open Logs from the side menu. Menu labels may vary by version. Record the client version, core type, node security type and full error chain. Before sharing logs, redact subscription URLs, user identifiers and authentication details.

Sync the system clock to rule out local validity errors

Certificates have a start date and an expiration date. An incorrect device year, date or system clock can make a valid certificate appear “not yet valid” or “expired.” Changing only the displayed time zone usually will not fix an incorrect clock: the time zone affects how time is displayed, while certificate validation uses the actual point in time.

1. Check the date

   On Windows, open Settings → Time & language → Date & time. Check the year, month, day and time zone. Correct any obvious errors, then try syncing online.

2. Sync the clock

   Turn on Set time automatically, then select Sync now under Additional settings or Sync your clock. On Android, open Settings → Date & time and enable automatic time. Some versions put this option under System.

3. Check the result

   On Windows, check when the clock last synced successfully. If syncing fails, use an administrator terminal to check the time service with the command below. If the network blocks time-sync traffic, resolve the network or service issue first.

4. Reconnect

   Disconnect, then reconnect using the same node and send a new request. Check the timestamp in the new log entries; do not use an old error still visible in the log panel to judge the result.

w32tm /query /status
w32tm /resync

These commands are for the Windows Time service, not the proxy core. If the service is stopped, check Windows Time in the system Services console first. On organization-managed computers, use the time source specified by your administrator. If the date keeps resetting after a restart, check the device's clock battery and system time settings instead of repeatedly switching nodes.

Set SNI: the connection address is not the certificate domain

The node's Address specifies which server to connect to; Port specifies which service to reach. SNI is usually set through the core's serverName field. It helps select the TLS virtual host and is used to validate the certificate name. The connection address can be an IP address while SNI is a domain name. That is valid, as long as the remote server presents the certificate for that domain.

• Address: Use the hostname or IP address provided by the subscription or server configuration. Do not swap it with SNI arbitrarily.
• Port: Use the port specified in the node configuration. 443 is a common TLS port, not a requirement—do not change every node to use it.
• SNI / serverName: Enter the certificate domain required by the server, such as example.com in the documentation. This is only a format example; use the actual value from your node configuration.
• Format: Enter only the hostname—no https://, path, query parameters or :443.
• Certificate coverage: Modern validation usually checks the certificate's SAN. A wildcard such as *.example.com generally matches a.example.com, but not the base domain example.com or a deeper subdomain such as a.b.example.com.

In v2rayN, double-click the node to open its editor, then check the TLS settings under Transport security for SNI or serverName. In v2rayNG and v2flyNG, look for the same field in the node editor. Depending on the version, you may see only one of these labels. Do not confuse the WebSocket Host with SNI: Host is an HTTP request header, while SNI is used during the TLS handshake.

Certificate chains and TLS timeouts: check the name, trust and port separately

A name mismatch and an unknown certificate authority are different problems. For a name mismatch, check that SNI falls within the certificate's SAN coverage. For an unknown authority, check that the certificate chain is complete and its issuer is trusted in the current environment. A website opening in a browser does not prove that the proxy connection works: the browser may use a different port or address, or handle trust and certificate chains differently.

On Windows, use PowerShell to test the target TCP port. The domain and port in the command below are examples; replace them with the actual address and port for your node. A true TcpTestSucceeded result confirms only that the TCP connection succeeded—it does not validate the certificate, SNI or proxy authentication.

Test-NetConnection -ComputerName example.com -Port 443

If OpenSSL is installed, you can inspect the certificate chain sent by the remote server. The connection target and SNI in the command can differ: they correspond to the node's Address and serverName fields. The example uses placeholder domains for both and explicitly enables name verification:

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

• Check the returned certificate's SAN, validity period and any verification errors. Seeing certificate output alone does not mean validation succeeded.
• If the server still presents an old certificate after renewal, check the certificate file path and reload the configuration on the service that actually terminates TLS.
• OpenSSL and the proxy core may use different root trust stores. Use the tool's output to investigate, then verify again with the client.

Fingerprints and REALITY: use separate troubleshooting steps

A client fingerprint affects how the ClientHello looks; it cannot fix a wrong certificate domain, an expired certificate or a missing intermediate certificate. Do not assume Xray and V2Fly support exactly the same features: v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. The fact that both interfaces offer TLS settings does not mean every parameter works with both.

• Standard TLS nodes: Start by restoring the fingerprint from the original subscription. Use a different value only if the server explicitly requires it; do not cycle through fingerprints at random.
• After changing cores: Check the logs for unknown fields, unsupported options or configuration parse errors. These indicate a configuration compatibility issue, not a certificate validation failure.
• REALITY nodes: Check the server-specified serverName, public-key parameters, shortId and fingerprint. Field names can vary between interface versions; follow the documentation for the relevant core and the server configuration.
• Use only specified values: Do not guess the REALITY target domain or try to fix REALITY authentication failures by skipping certificate validation as you might with standard TLS.

If a standard TLS node completes the handshake only with a particular fingerprint, also check the server's access policy and any intermediate network devices. Save the full error chain before and after each change to tell whether the handshake recovered or the test request took a different outbound route. Keep the same node and test request throughout troubleshooting; do not change routing rules, TUN mode or the system proxy at the same time.

allowInsecure: keep certificate validation on and fix the cause

In a standard TLS configuration, allowInsecure controls whether normal certificate validation can be skipped. The traffic may still be encrypted when this setting is enabled, but the server's identity is no longer verified through the usual certificate chain and name checks, leaving you vulnerable to impersonation or man-in-the-middle interception. It is not a compatibility or speed boost.

The example below shows a tlsSettings object inside streamSettings for standard TLS. It is not a complete node configuration and does not apply to REALITY. Replace serverName with the actual domain required by the server; do not paste the example into every node.

{
  "serverName": "example.com",
  "allowInsecure": false
}

• If skipping validation restores the connection, that only means certificate validation needs further investigation. It does not tell you whether the cause is the clock, the name or the trust chain.
• If the connection still times out, return to checking the port and handshake. Repeatedly toggling this setting cannot fix an unreachable remote server.
• After fixing the issue, make sure Allow insecure connections is turned off in the node editor, then reconnect to verify.

Common questions: how to confirm the fix

For a final check, follow the same sequence: confirm the system clock is correct, node fields match the server configuration, and certificate validation is enabled. Reconnect, check that the logs show no new TLS validation errors, then verify that application requests use the expected outbound route. Note the changed fields and results so you can check them again after a subscription update or core switch.