V2Ray TLS Handshake Failed? Fix Certificate Errors, Clock Skew, SNI & allowInsecure

Distinguish certificate errors from connection failures

“TLS handshake failed” describes a stage, not a specific cause. The client first connects to the node’s address and port, then negotiates TLS and verifies the certificate, and only then starts the proxy protocol exchange. A connection timeout, a server-side disconnect, or a certificate name mismatch may all be reported as a connection failure. Expand the core logs and check the final cause in the error chain instead of relying on a failed status in the speed-test list.

In v2rayN, check the log area on the main screen for the current connection. In v2rayNG and v2flyNG, open Logs from the main menu. Menu labels may differ between releases. Note the client version, core, transport, and full error, then make one request through a single node so background connections don’t clutter the logs.

System time: sync it before checking certificate expiry

Certificates have a start date and an expiration date. A device clock set too early can trigger a “not yet valid” error; a clock set too late can make a valid certificate appear expired. Changing the time zone alone usually doesn’t change the underlying system timestamp. Correct the actual date and time. Check this first after switching between operating systems, starting a device that’s been off for a long time, or when automatic time sync has failed.

1. Sync the clock

   Windows 11: Go to Settings → Time & language → Date & time, turn on Set time automatically, then select Sync now under Additional settings. If syncing fails, troubleshoot the device’s network connection first.

2. Check other devices

   macOS: Go to System Settings → General → Date & Time and turn on Set time and date automatically. Android: Go to Settings → System → Date & time and turn on automatic time. Some manufacturers put this option under Additional settings.

3. Reconnect

   After syncing the clock, stop and restart the client connection, then check the new error. Don’t use logs from before the clock was corrected to judge whether the fix worked.

4. Check the certificate validity period

   If the device time is correct but the certificate still appears expired, check the validity dates of the certificate actually being served. After renewing a certificate, the TLS service must reload it; a new file on disk doesn’t mean active connections are using it yet.

Keep the connection address, SNI, and Host straight

The Address field in the node editor specifies where to connect. SNI is the server name sent in the TLS ClientHello, which the server often uses to select a certificate. For WebSocket, Host is an HTTP request header sent after the TLS handshake. These values may use the same domain or different ones, but they must match the server configuration. A “disguise domain” isn’t a decorative field you can change at will.

For example, using the documentation-only domain edge.example.com: if the certificate’s Subject Alternative Name includes that name, set SNI to the hostname—not https://edge.example.com/path. When connecting by IP, you can still explicitly set the server-required hostname as SNI. If you verify the certificate against the IP directly, the certificate must include a matching IP address entry; a domain name entry alone isn’t enough.

Where to check SNI and allowInsecure in your client

Labels vary between versions, so use the node editor and the actual field names below as a guide. Subscription updates may overwrite imported settings. Before making changes, duplicate the node for testing and note its original values. Don’t change the address, port, SNI, and transport all at once; even if the connection starts working, you won’t know what fixed it.

• v2rayN: Double-click the node on the main screen to open the server editor. Check Address and Port, then look under transport security for tls, SNI, and Skip certificate verification or Allow insecure connections. For standard TLS, keep the latter disabled. If you use a custom configuration, check the JSON that’s actually loaded; the regular editor may not change that file.
• v2rayNG: Tap the edit icon next to the node in the list, then scroll to the TLS settings. Confirm transport security is set to tls and check SNI and Allow insecure connection (allowInsecure). If you use WebSocket, check Host and path separately under transport settings. This client uses the Xray core; check REALITY nodes using their corresponding fields.
• v2flyNG: Open a node from the list and check TLS, Server name or SNI, and Allow insecure connection. This client uses the v2fly core, so don’t copy Xray-specific security settings. If the editor doesn’t show the relevant field, check the node type and app version rather than entering the value in Host as a substitute.

This standard TLS streamSettings snippet shows where the fields go; it isn’t a complete node configuration. The example uses TCP transport and a documentation-only domain. If your node uses WebSocket or another transport, don’t switch it to TCP just to match the example. Supported fields depend on the core actually in use.

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false
    }
  }
}

Certificate chain and SNI: narrow it down with a separate handshake

If you have access to a terminal, you can inspect the certificate returned by the server independently, using the same device and network. These commands require OpenSSL to be installed. Replace the example hostname, SNI, and port with the actual values before running them. The connection address and SNI are passed separately, which is especially useful when connecting by IP but verifying against a domain name.

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

• First, check whether a certificate is returned: If the connection times out before it’s established, check the network, DNS, port, and firewall first. No certificate output does not prove that the certificate has expired.
• Next, check the name and validity dates: Inspect the domain names, start date, and expiration date in the returned certificate. If SNI selects the default site’s certificate, check the server’s virtual host and certificate binding.
• Check the certificate chain: The server should usually send the leaf certificate and any required intermediate certificates; the client’s trust store provides the root certificate. A site working in a browser doesn’t guarantee that every core can build the same trust chain.
• Compare trust environments: OpenSSL and the client core may use different trust stores. A successful command only confirms the result for that tool, target, and set of parameters; it doesn’t replace testing in the client.

If you receive a certificate from a different issuer only on one network, check for HTTPS inspection, a captive portal, or traffic redirection. Don’t install an unknown root certificate from an error dialog. If someone else manages the server, send them the redacted final error line, time of occurrence, SNI, and port. Don’t include the full subscription URL, UUID, or other credentials.

Common questions and how to verify a fix

After changing a setting, save the node, restart the connection, and repeat the same request. Don’t judge success by latency alone: the original certificate error should be gone from the logs, the request should complete, and certificate verification should remain enabled for standard TLS nodes. If the handshake succeeds but you see a path error, an unexpected HTTP status, or protocol authentication failure, investigate the transport path and account settings instead of changing SNI again.

• Record which single field you changed and the final error line from before and after the change.
• Make sure the client is using the updated node, not another subscription entry with the same name.
• Delete temporary configurations created during troubleshooting, or clearly label their purpose to avoid selecting one by mistake.
• For details on field structure, see the Configuration Reference. For definitions, see the Glossary.