V2Ray TLS Certificate Errors: Troubleshooting System Time, SNI, and serverName

Where does the TLS error occur?

When V2Ray or Xray establishes a TLS connection, the client first connects to the node's IP address and port, then sends a ClientHello containing SNI. The server selects a certificate based on the SNI, after which the client checks its validity period, hostname coverage, issuing chain, and system trust. If any check fails, the connection stops before the proxy protocol begins.

A TLS error in the log therefore does not necessarily mean that the VMess or VLESS user identifier is wrong. The user identifier, encryption method, and flow-control settings typically come into play only after the TLS handshake completes. Troubleshoot the certificate layer first instead of changing the UUID, port, transport, and routing rules all at once.

Step 1: Correct the system time and time zone

A certificate contains explicit validity and expiration times. The client uses the local clock to determine whether the current time falls within that window. An incorrect date, wrong time zone, or a clock that fails to resynchronize after sleep can make a valid certificate appear not yet valid or expired. Dual-boot systems, desktops that stay powered off for long periods, and devices with automatic time disabled are especially prone to this issue.

1. Check the current time

   Compare the year, month, day, hour, and minute with a trusted time source. If the clock is off by 5 minutes or more, fix system time before changing any node parameters.

2. Confirm the local time zone

   In Windows, open Settings → Time & language → Date & time. Confirm that the time zone matches your location and enable Set time automatically.

3. Sync immediately

   On the Date & time page, open Additional settings and sync now. In one troubleshooting case, correcting a 7-minute-12-second drift immediately cleared the not-yet-valid certificate warning.

4. Restart the client core

   In the v2rayN main window, select Servers → Restart service, then test the current server's latency again so an old failed connection is not reused.

Android devices also require automatic time and time-zone settings to be checked under Date & time. Manually adjusting the minutes is not reliable because an incorrect date or time zone can still affect certificate validation. After synchronizing the clock, fully exit v2rayNG or v2flyNG, reopen it, and test the node again.

Step 2: Check SNI, serverName, and the node address

SNI is the hostname sent to the server during the TLS handshake. In V2Ray and Xray configurations, it is usually set by serverName. When it is not specified, the core may derive it from the node address. If the node address is an IP, the entry hostname differs from the certificate hostname, or SNI was lost during subscription conversion, the server may return its default certificate and trigger a hostname mismatch.

Three fields must be kept separate: the node address determines where to connect, the port determines the connection entry point, and serverName determines which hostname is declared during the TLS handshake. A WebSocket Host header is sent after TLS is established and cannot replace SNI. If Host is correct but serverName is wrong, certificate validation will still fail.

In a typical VLESS TLS outbound configuration, the address and serverName can differ. The example below shows only how the fields relate; the actual address, user identifier, port, and transport must come from a valid subscription.

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.net",
            "port": 443,
            "users": [
              {
                "id": "11111111-2222-3333-4444-555555555555",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com"
        }
      }
    }
  ]
}

Step 3: Check certificate validity and the complete chain

Once system time and SNI match, errors such as unknown authority or unable to verify certificate point to the certificate chain returned by the server. Normally, the server sends the site certificate along with the required intermediate certificates, allowing the client to validate it through a trusted root certificate. If an intermediate certificate is missing, some environments with cached certificates may work temporarily while other devices fail consistently.

With a command-line environment, use OpenSSL to inspect the certificate chain returned by the target entry point. -connect specifies the actual address and port, while -servername specifies the SNI. Keeping them separate makes it easier to verify configurations where the entry hostname and certificate hostname differ.

openssl s_client \
  -connect edge.example.net:443 \
  -servername node.example.com \
  -showcerts

• In the output, check the site certificate's subject hostname and confirm that it covers node.example.com.
• Check Not Before and Not After on the certificate and confirm that the current time falls within the validity window.
• Check that Certificate chain contains the site certificate and the required intermediate certificates, rather than only a single certificate numbered 0.
• Confirm that the final verification result is successful. If the chain is incomplete, the server must add the missing intermediate certificates and reload the entry-point configuration.
• If multiple nodes share one entry point and fail at the same time, check certificate renewal and reverse-proxy configuration first instead of editing each client node.

End users usually cannot repair a server-side certificate chain. Preserve the node name, test time, first error log, and network in use, then update the subscription once and test again. If the same chain error appears across different networks and devices, provide these details to the node maintainer to help locate the certificate deployment issue.

Step 4: Check TLS parameters in the client

After confirming that the external certificate is valid, inspect the node parameters saved in the client. The v2rayN desktop client usually runs the Xray core; v2rayNG uses the Xray core; v2flyNG uses the V2Fly core. Log wording varies between cores, but the five checks remain in the same order: address, port, transport security, SNI, and system time.

1. Pin a single node

   Turn off automatic selection and choose one node that reproduces the error consistently. Record its label, address, port, transport, and TLS serverName first so rotation between nodes does not confuse the diagnosis.

2. Check the core type

   In v2rayN, open Settings → Parameter settings → Core type and confirm that the current protocol uses the expected core. Save, then select Servers → Restart service.

3. Edit the server

   In the v2rayN server list, select the node and open the editor. Check the address, port, transport protocol, transport-layer security, and SNI one by one. Do not copy the node label into serverName.

4. Check the Android configuration

   In v2rayNG or v2flyNG, open the target node's edit page from the configuration list and check Address, Port, Transport security, and SNI. Save, select the node again, and start the connection.

5. Update the subscription and retest

   If a manually added node works but a subscription node fails, update the subscription and compare the TLS fields. When several subscription groups are present, confirm that the current node belongs to the group you just updated.

6. Read the first error

   Clear or separate the logs, connect only once, and read the first certificate or handshake error. Then return to the corresponding troubleshooting branch using the error keywords.

Step 5: Separate certificate, network, and protocol issues

Some logs contain handshake failed even when the root cause is not the certificate. A target port without TLS, a connection reset in transit, or an entry point that is not listening can all end the handshake early. Look for x509, certificate, hostname, expired, or unknown authority in the error. If present, follow the certificate path first; otherwise check network reachability and server listening status.

Change one variable at a time: synchronize the clock and retest, then change SNI and retest, inspect the certificate chain, and only then update the core or rebuild the node. If you change networks, switch cores, edit the port, and reimport the subscription together, a recovered connection will not reveal what actually fixed it.

Final retest checklist

After correcting the configuration, perform one complete, reproducible test instead of checking only whether the client says Connected. Restart the core, run a node latency test, make an actual web or application request, and check the logs for new TLS errors. If the connection succeeds but webpages do not load, the issue is beyond TLS; check the system proxy, DNS, routing rules, and outbound configuration.

• The system date, time, and time zone are correct, and automatic synchronization has been run.
• The node address contains no spaces or outdated hostname, and the port matches the server entry point.
• Transport-layer security is enabled according to the subscription, with the TLS entry point using the specified port.
• serverName matches the hostname covered by the certificate; it is not the node label or an IP address.
• WebSocket Host and TLS SNI were checked separately; the two fields were not treated as the same setting.
• The certificate is within its validity period, and the server sends the required intermediate certificates.
• After updating the subscription, confirm that the current node is the new one rather than a same-named configuration in an older group.
• The first certificate error has disappeared from the log, and three consecutive connection tests produce the same result.

Following this order turns a vague handshake failed message into a verifiable diagnosis: an incorrect clock affects validity checks, wrong SNI returns a mismatched certificate, an incomplete chain breaks trust validation, and a wrong port or entry point may disconnect before the handshake completes. Recording each change and retest is more effective than repeatedly deleting the client or bulk-editing node parameters.