V2Ray TLS Handshake Failures and Certificate Errors: System Time, SNI, and allowInsecure Explained

Common TLS handshake errors and the order to troubleshoot them

The TLS handshake is the first step in establishing a V2Ray connection. The client sends a ClientHello, the server returns its certificate chain, and the local core then verifies the certificate validity period, domain match, and issuing chain. If any step fails, the connection is terminated during the handshake, showing up as "connected but immediately disconnected" or a certificate error in the core log. v2rayN and v2rayNG use the same Xray core, so the error format is identical.

A fixed troubleshooting order works best: read the exact error message first, then check system time, then domain/SNI match, and finally the certificate chain. Skipping around most often leads to endlessly switching servers while the real problem stays unchanged.

These three errors map to three independent checkpoints. The following sections cover them in this order, with the exact v2rayN and v2rayNG steps at the end of each section.

System time skew: the first source of expired and not yet valid

Certificate validation uses the device's local time. A certificate contains NotBefore and NotAfter boundaries; if the local time falls outside them, you get an "expired" or "not yet valid" error. v2rayN's core log panel prints a local timestamp for every handshake — compare that with real time. A difference of more than a few minutes is enough to confirm a clock issue.

Syncing time takes two steps: turn on automatic time, then tap sync now once. Virtual machine and dual-boot users should also make sure the guest OS refreshes its time after resuming — time freezes while suspended.

Time sync paths on Windows and Android

• Windows 11 / 10: Settings → Time & language → Date & time, turn on "Set time automatically" and click "Sync now".
• Android: Settings → System → Date & time, turn on "Automatic date & time"; on some models the option is under "More settings".
• Virtual machines and dual-boot systems: manually sync time once after resuming, to avoid time freezing during suspend or hibernation.

After syncing, restart the core and try again. In v2rayN, use "Core" → "Restart Core"; in v2rayNG, toggle the connection switch off and on. If the error is gone, the problem was time skew.

SNI and domain matching: pinpointing the certificate name mismatch error

Domain matching is the second step of certificate validation. The client compares the certificate's CN and SAN list against the "server address" or a separate SNI field. When the address is an IP but the certificate is only issued for a domain, the log shows valid for xxx, not yyy. In the Xray core this field is called serverName; the GUI shows it as SNI.

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

There are only two fixes: change the address back to the domain, or keep the IP and enter the certificate's domain in the SNI field. The first works when the domain resolves; the second is for when the domain is polluted and you need to connect by IP. In v2rayN, SNI is in the TLS group of the server edit window; in v2rayNG, it's under the TLS settings on the server edit page.

Missing certificate chains and the correct use of allowInsecure

A certificate chain consists of a leaf certificate, intermediate certificates, and a root certificate. The server must send the leaf and intermediate certificates; the root comes from the client system's trust store. If the intermediate certificate is missing, the client can't build a trust chain and reports unknown authority. This is a server-side configuration issue, most often caused by writing only the leaf certificate into the deployment file.

allowInsecure skips the entire certificate validation chain — validity period, domain, and issuer. It doesn't fix the certificate itself; it just lets the handshake pass. If enabling it temporarily makes the connection succeed, the problem is indeed on the certificate side. Fix the certificate on the server afterward instead of leaving this option on permanently.

In v2rayN, allowInsecure is in the TLS group of the server edit window; you need to restart the core for it to take effect. In v2rayNG, it's the allowInsecure toggle on the server edit page; toggle it off and reconnect. Traffic is still TLS-encrypted, but the certificate identity is no longer verified, allowing a man-in-the-middle to substitute the certificate.

v2rayN and v2rayNG TLS settings comparison

The table below summarizes where to find the four checkpoints in both clients. Following this order covers the vast majority of certificate-related errors.