TLS Handshake Failures and Certificate Errors: Three Key Checks for System Time, SNI, and allowInsecure

Where the TLS error occurs

After TLS is enabled for a VMess or VLESS node, the client does not immediately send proxy data upon connecting to the server. It first establishes a TCP connection and sends a TLS ClientHello, which may include SNI, supported TLS versions, and ALPN. The server then returns its certificate chain and negotiates session keys. Only after the handshake succeeds do protocol authentication and data transfer enter the encrypted channel.

So, “the node won’t connect” does not necessarily mean the node account is invalid. If the logs show an expired certificate, hostname mismatch, or unknown certificate authority, the failure usually occurs before the VMess user ID, VLESS UUID, transport path, and routing rules are involved. Changing subscription groups, the system proxy port, or routing rules will not usually fix a certificate error.

During troubleshooting, open the client core logs instead of relying only on a browser page. In v2rayN, review recent connections in the log area at the bottom of the main window, and check Settings → Parameter Settings to ensure the log level is not set too low. In v2rayNG and v2flyNG, open the runtime log page for the relevant configuration and record the first TLS or x509 error exactly as shown.

Step 1: Check the system time and time zone

TLS certificates contain two time boundaries: Not Before and Not After. The client uses the device’s current time to determine whether a certificate is valid or expired. If the clock is months ahead, a valid certificate may appear expired; if it is months behind, the certificate may appear not yet valid. The time zone does not change absolute time, but an incorrect time zone combined with a manually set clock often causes a real time offset.

On Windows, enable automatic time and automatic time-zone settings, then run an immediate sync. On a Linux desktop, check the system time status and confirm that the NTP service is synchronized. On Android, enable network-provided date, time, and time zone. After correcting the clock, fully stop and restart the client core so it does not reuse a failed connection state.

1. Save the original logs

   Disconnect from the current node, clear the logs, reconnect once, and save the first x509 or TLS error with its timestamp. Do not keep only later timeout messages.

2. Check the current time

   Compare the device date, minutes, and time zone with a trusted system time source. Keep the difference within 60 seconds where possible, and check that the clock was not set manually.

3. Synchronize the time

   Enable automatic system synchronization. On Linux, run timedatectl status and confirm that the system clock is synchronized and the time zone is correct.

4. Restart the client core

   In v2rayN, stop the service first and then start it again. On Android clients, disconnect the current configuration, end the connection, and reconnect to avoid reusing the old session.

5. Compare the retest results

   If the not yet valid error disappears, the local clock was the root cause. If the same certificate expiration date still appears, continue checking whether the certificate has actually expired.

Step 2: Check SNI against the node address

SNI is the server name sent in the TLS ClientHello. A single IP address may host multiple sites, so the server uses SNI to choose the certificate and virtual host. A node’s connection address can be a domain or an IP, but the certificate name being verified usually must be a domain listed in the certificate. Do not guess it from the node label.

For example, the client may connect to an entry-point IP while the certificate was issued to a domain. In that case, enter the domain in the serverName or SNI field. Conversely, if the node address is already the correct domain and the subscription explicitly provides an SNI, keep the subscription value. Copying a WebSocket Host, HTTP path, subscription name, or node label into SNI will cause a name mismatch.

In v2rayN, double-click the target node or right-click it and choose Edit Server. In the TLS section, check the serverName, SNI, or “Fake domain” field; the exact label varies by core and configuration type. Save the original subscription value before editing, then test only this setting. Do not change the port, transport, and UUID at the same time.

In v2rayNG or v2flyNG, disconnect first, then open the edit control beside the configuration and find the server name or fake domain under TLS security settings. If the configuration comes from a subscription, manual changes may be overwritten at the next update. Once the correct value is confirmed, ask the subscription provider to fix the source configuration.

Step 3: Check for an expired or incomplete certificate chain

Once the system time and SNI are correct, check which certificate the server actually returns. An expired certificate has a Not After date earlier than the current time. An incomplete chain commonly occurs when the server sends only the site certificate and omits required intermediate certificates. Both are server-side configuration issues; reimporting the subscription will not normally fix them.

In a Linux environment with OpenSSL installed, use the command below to inspect the certificate chain returned on port 443. After -connect, enter the actual connection domain and port; after -servername, enter the SNI required by the node. Keep both parameters in the test, or the result may come from a different default certificate.

openssl s_client -connect server.example:443 \
  -servername node.example \
  -showcerts

openssl s_client -connect server.example:443 \
  -servername node.example \
  -verify_return_error < /dev/null

In the output, subject is the current certificate subject, issuer is the issuer, and notBefore and notAfter define the validity period. If the last line shows Verify return code: 0 (ok), the current system trust environment can build a complete verification path. Code 10 usually indicates an expired certificate; codes 20 or 21 commonly mean the local issuer could not be obtained or the first certificate could not be verified.

• Only one device reports the error: First update the system time, system certificate environment, and client core, then rule out local network interference with TLS.
• Windows and Android report the error: An expired certificate, incorrect SNI, or a missing server certificate chain is more likely.
• Only one domain on the same server reports the error: Check that domain’s certificate binding and virtual host. Do not modify every node immediately.
• The issue disappears after changing networks: Compare the IP addresses returned on both networks and check for DNS resolution problems or transparent proxy interference.
• The old expiration date still appears after renewal: Confirm that every entry-point server has loaded the new certificate, then restart or reload the relevant TLS service.

What allowInsecure fixes—and what it risks

The purpose of allowInsecure is to let the client accept a server certificate that fails normal validation. It may temporarily allow expired, self-signed, name-mismatched, or untrusted certificates, but it does not repair the server certificate or automatically correct the SNI, address, port, or transport configuration.

TLS data remains encrypted when this option is enabled, but the client loses the key step that reliably confirms the server’s identity. If an attacker can interfere with the network connection, they may impersonate the target server with another certificate. Use this option only for brief diagnosis: if the connection immediately works, the certificate verification stage is implicated. Then disable it and fix the time, SNI, or server certificate chain.

In v2rayN, edit the relevant server and look for allowInsecure or “Skip certificate verification” in the TLS section. In v2rayNG and v2flyNG, the TLS settings on the configuration edit page usually show “Allow insecure connections” or a similar label. Change it only for the node being tested; never apply it in bulk to every subscription configuration.

Identify the responsible side from the logs

An effective troubleshooting session changes only one variable at a time and records the first error before and after each change. If you reimport the subscription, switch cores, change SNI, enable allowInsecure, and change networks all at once, even a successful connection will not reveal the real cause. A later subscription update may bring the problem back.

Build a minimal test set: keep the same node, network, and client core, then sync the time, verify SNI, validate the certificate chain, and only then test allowInsecure briefly. Temporarily disable frequent automatic node switching so errors from other servers do not contaminate the logs.

The final diagnosis can be reduced to three rules: fix time errors on the local device; correct SNI using the subscription and certificate domain; if multiple devices receive an expired certificate or incomplete chain, fix it on the server. Separating these cases prevents TLS handshake failures from being mistaken for port, UUID, subscription, or routing problems.