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

First identify whether the error comes from a subscription or node connection

When you see a TLS error, note what you were doing when it occurred. An HTTPS certificate error while updating a subscription usually concerns the subscription URL. A handshake error in the core logs while using a selected node to access a webpage may concern the proxy node. These connections use different destination domains, so changing the node's SNI will not fix the subscription site's certificate.

A standard TLS proxy connection follows this sequence. A successful TCP connection to the port only proves that a service responded; it does not prove the certificate is valid, proxy authentication succeeded, or a webpage will load. VMess and VLESS are proxy protocols; TLS is an optional transport security layer, and not every node uses it.

• Record the destination: Keep the destination address, port, error time, and complete error message from the logs. Before sharing, remove subscription tokens, user IDs, and passwords.
• Check the port: For example, if the node uses 443, test that port—not the client's local listening port.
• Identify the failure stage: For connection refused, check the listener and firewall first. An i/o timeout can occur during connection or handshake; use the surrounding log entries to narrow it down.
• Limit variables: Use one node and one test destination, changing only one setting at a time. Avoid changing DNS, transport, and proxy mode all at once.

Use the exact error message to guide your checks

Different core implementations and versions may wrap errors with extra connection details. Look for the innermost x509 or tls cause rather than repeatedly restarting the client based only on an outer “connection failed” message. The examples below are common error messages; actual logs may include certificate dates or specific domains.

Sync the system clock, then check whether the certificate has expired

TLS verification checks the actual point in time. Changing only the time zone shown in the taskbar does not ensure the device clock is correct; conversely, a different displayed time zone does not necessarily cause certificate errors. Sleep and wake cycles, a failing motherboard battery, or manually changing the date can all throw the clock off.

1. Check the date

   In Windows 11, open Settings → Time & language → Date & time. Check the year, month, and day first, paying particular attention to the year.

2. Sync the clock

   Turn on Set time automatically, then select Sync now under Additional settings. If syncing fails, troubleshoot the network or time service first. An enabled automatic setting does not mean the clock has synced successfully.

3. Retry the connection

   Return to v2rayN, re-enable the current node, and make a request. Check the logs with the new timestamp rather than using an old error to judge whether the fix worked.

4. Check the validity period

   If the certificate still appears expired, check its notBefore and notAfter values. If the device time is correct but outside the certificate's validity period, ask the server administrator to update the certificate.

On Android, search Settings for Date & time, enable automatic time, then retry v2rayNG or v2flyNG. Menu locations vary by device; the key is to confirm the actual date after syncing, not just toggle the setting. Don't roll the system clock back into the certificate's validity period as a long-term fix.

Check the SNI, connection address, and transport Host

SNI is the name sent to the server during the TLS handshake, which the server can use to select a certificate. In standard TLS settings, serverName is also typically used to specify the name to verify against the certificate. “Fake domain” can mean different things: it may refer to TLS SNI or the WebSocket Host. Confirm which field is meant before changing anything.

In the v2rayN main window, double-click the node, then check Address and Port in the node editor, followed by SNI and the certificate verification bypass setting in the TLS section. Labels may vary slightly by version. Don't change global options under Settings → Parameter settings as a substitute for checking this node's settings.

When you use an IP address to connect, you may still need to enter the domain specified by your provider as the SNI. To verify a certificate against an IP address, the certificate must include a matching IP-type SAN; a certificate containing only a domain name won't satisfy this requirement. Wildcards also have limits: *.example.com typically does not cover example.com or a.b.example.com.

Check the full certificate chain and what the server actually returns

Servers usually need to send the leaf certificate and any required intermediate certificates; the client's trust store typically supplies the root certificate. A setup with only the leaf certificate may work in some environments but fail with an unknown issuer on another device. Browsers may cache intermediate certificates, so a site opening in a browser does not by itself prove the server's chain is complete.

If you manage the server, run the following command in an environment with OpenSSL installed. example.com is a reserved example domain. Replace both instances with the actual TLS domain and replace the port with the node's actual port before running the command. It checks the standard TLS endpoint; it does not verify subsequent VMess or VLESS authentication.

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

• Inspect the certificate served: Check the returned certificate's Subject Alternative Names and validity period. Make sure the server isn't returning a default site or an old certificate.
• Check the verification result: Verify return code: 0 (ok) means verification passed with the settings and in the environment used for this test; it does not mean every device has the same trust store.
• Look for a missing link: unable to get local issuer certificate may mean the server is missing an intermediate certificate, or the test environment lacks a required trusted root. Check both sides separately.
• Check where TLS terminates: If TLS terminates at a reverse proxy or edge endpoint, update the certificate there—not just the files used by the backend core.
• Confirm the new certificate is loaded: After renewal, reload the service as required by its configuration and fetch the certificate again. Updating a file on disk does not mean the running process is using the new certificate.

Understand allowInsecure: Keep verification on; don't use a switch to hide the problem

allowInsecure controls whether standard TLS certificate verification is skipped. When set to true, the connection may still be encrypted, but the server's identity is no longer protected by normal certificate chain and name verification. This does not fix the certificate, nor does it guarantee that you are connecting to the intended server.

The following is only a tlsSettings snippet from a standard TLS outbound configuration, not a complete node you can import. Replace the example domain with the real server name. For nodes managed through a subscription, fix the source configuration whenever possible to avoid having local changes overwritten at the next update.

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

• For everyday connections: Keep false and fix the actual problem with the clock, name, certificate chain, or trust store.
• For controlled diagnostics: If you need a temporary comparison, do it only in a test environment with a verified endpoint. Don't send account, payment, or other sensitive data, and turn verification back on immediately afterward.
• Know what the test proves: If the connection works with verification disabled, that only suggests the problem may be in certificate verification. It doesn't tell you whether the certificate is expired, the name is wrong, or the chain is untrusted.
• For self-signed deployments: Distribute and configure the expected certificate or a trusted private CA through a trusted channel. The exact method depends on core support. Don't leave verification disabled as a substitute for configuring trust.

Common questions and post-fix checks

Keep a brief record of what triggered the issue, the full error type, each setting changed, and the time and result of your retest. If the problem persists, send the record and redacted logs to the server administrator, asking them to check the certificate returned by the actual endpoint rather than just reporting that the “node doesn't work.” For steps to verify that the proxy is active, see the connection testing guide.