TLS Handshake and Certificate Errors: System Time, Certificate Validity, and SNI

Which layer is failing during TLS

The TLS handshake takes place while the proxy core establishes an encrypted connection to the remote server. v2rayN imports subscriptions, edits servers, and generates configuration; the Xray core handles the actual connection, while the system proxy or TUN determines which application traffic enters the client. These layers must be assessed separately: if a browser is not using the proxy, even a correct node configuration will never reach the core. If the application is connected but the core cannot complete the TLS handshake, certificate or handshake errors appear in the log.

VMess and VLESS are proxy protocol names, while TLS is the transport security layer. Using VLESS does not necessarily mean TLS is enabled, and using VMess does not imply a different certificate verification method. Check the security type, destination port, server address, SNI, and hostname covered by the certificate in the node's transport settings. Port 443 is common for TLS, but it is not mandatory; if the server uses another port, the client must match it.

When troubleshooting, find the first TLS error rather than focusing only on later connection closures, EOF messages, or retry failures. After certificate verification fails, the core usually ends the current connection; subsequent read failures are only consequences. If every node in the same subscription fails at once, check local time, network middleboxes, and client-wide settings first. If only one hostname fails, the issue is more likely that node's certificate, SNI, or server deployment.

Step 1: Check Windows time, time zone, and synchronization status

A certificate contains a start time, notBefore, and an expiration time, notAfter. The core uses the local system clock to determine whether the certificate is currently valid, so an incorrect date, time zone, or clock offset can trigger “not yet valid” or “has expired” errors. For example, a computer may physically be in UTC+8 while its time zone is set to UTC and its clock has been manually adjusted to local time. The displayed time may look close to correct, while the underlying time reference is still offset.

Open Windows Settings → Time & language → Date & time. Confirm that “Set time automatically” and “Set time zone automatically” match the current environment, then select Sync now. Corporate networks and managed devices may use an internal time source. Do not replace that policy casually; record the synchronization source and offset, then ask the device administrator to verify them.

1. Compare the system date, hour, and minute—not just the minute shown in the taskbar.
2. Confirm that the time zone name matches your location; in regions using daylight saving time, also check the current offset.
3. Query the status to see the most recent successful synchronization time and time source.
4. After correcting the clock, fully exit v2rayN, restart the core, and retest the same node.

w32tm /query /status
tzutil /g
powershell -NoProfile -Command "Get-Date -Format o"

Use 60 seconds as a practical troubleshooting threshold, not as a universal tolerance defined by certificate standards: if the local clock differs from a trusted time source by more than 60 seconds, correct it first. TLS implementations and server deployments may behave differently, so do not rely on a grace period that may exist in one implementation. If every node recovers after the clock is corrected, the problem is in the local time chain; there is no need to edit subscription nodes one by one.

Step 2: Check certificate validity, the chain, and the hostname

Once the time is correct, inspect the certificate itself. At minimum, check its validity period, Subject Alternative Name entries, and whether the issuing chain reaches a root certificate trusted by the system. Checking only the expiration date shown in a UI is not enough: the certificate may not have become valid yet, or an intermediate certificate may be missing. If a server replacement updates only the leaf certificate without supplying the correct intermediate certificate, it may work in some environments while others report an unknown issuer.

Hostname matching is based primarily on the certificate's Subject Alternative Name. If the client connects by IP while the certificate covers only a hostname, direct IP validation will usually fail. Likewise, if the connection uses one hostname but SNI names another hostname not covered by the certificate, the result is a name mismatch. Wildcard certificates also have limited scope: *.example.com generally covers one subdomain level, but does not automatically cover deeper levels or the root domain.

Also distinguish an expired certificate from an old connection that is still working. An established long-lived connection may not drop the moment a certificate expires, but a new connection will perform a fresh handshake and validation. This can make a newly started client fail while an existing connection remains temporarily usable, or reveal the problem only after switching networks. Fully restart the core and establish a new connection when testing; do not rely on a single session that is still open.

Step 3: Check SNI, the server address, and subscription fields

SNI is the server name sent by the client during the TLS handshake, allowing the server to select a certificate and virtual host. It is not the same as the DNS result: the server address determines which IP to connect to, while SNI declares the hostname requested during the handshake. They can differ in certain deployments, but the server must support that arrangement, and the returned certificate must cover the hostname used for verification.

In v2rayN, select the target server and use the context menu's “Edit server” option to check the address, port, transport security, and SNI. To inspect global behavior, open Settings → Parameters. Field groupings may vary between interface versions, but do not mechanically copy “address,” “Host,” and “SNI” as if they were the same value. A WebSocket Host is an HTTP request header, while SNI belongs to the TLS handshake. A reverse proxy may require them to match—or explicitly require them to differ.

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

• After importing the sni parameter from a VLESS share link, confirm that it matches the server name shown in the client editor.
• A subscription update may overwrite manually edited node fields. Before retesting, confirm that the selected node is actually the modified configuration.
• If the address is an IP and SNI is a hostname, first confirm that the server explicitly supports this combination.
• After changing the port from 443 to another value, also verify the server listener, firewall rules, and client port.
• Routing rules only select the traffic exit; they do not correct an invalid certificate name or SNI.

If the node came from a subscription, record the original values first, then update the subscription once and compare the fields. If a manual correction works only briefly and fails again after the next update, the subscription source is still delivering an incorrect value. Fix the subscription generator instead of editing every imported node again. If several nodes use the same hostname, check their ports and transport settings individually; identical names do not prove that their server entry points are identical.

Step 4: Narrow the issue down from the exact error text

TLS log messages vary with the core version and error path, but the key information usually falls into four groups: time, hostname, trust chain, and handshake negotiation. When sharing logs, keep the connection target and timestamps around the error, but do not expose UUIDs, subscription URLs, or full configuration. Focus on where the first failure occurred, not on the number of retry records that followed.

If the log shows only a timeout and no certificate details, the connection may not have reached certificate verification. Confirm DNS resolution, the destination IP, the TCP port, and network reachability first. Connecting to the wrong port—for example, treating a plain HTTP port as a TLS endpoint—can also result in a closed connection or an unrecognized handshake error. An open port only proves that a process is listening; it does not prove that the listener is the expected TLS service.

If a company, campus, or managed network deploys TLS inspection, the certificate issuer seen by the client may differ from the one seen on a direct connection. With authorization, switch to another compliant network for comparison: if the same device and node behave differently after only the network changes, continue investigating the intermediate network. If the same hostname or validity error appears on the other network, the node configuration or server certificate is more likely at fault.

Why certificate verification should not be disabled long term

“Skip certificate verification” usually tells the client to stop checking the certificate name and trust chain. It does not fix an expired certificate, incorrect SNI, wrong port, or server virtual host. The option may keep the connection appearing to work, but it removes an important step for confirming the remote identity, making bad configuration and certificate replacement by a network middlebox harder to detect. At most, use it briefly for comparison in a controlled environment; it should not be the conclusion of routine configuration.

A more effective comparison changes one condition at a time. Keep the server address, port, and network unchanged while correcting only the system time. Once the time is confirmed, correct only the SNI, then verify the server certificate chain. Restart the core and create a new connection after each step, recording whether the error changes from “not yet valid” to “name mismatch,” or progresses to a later protocol stage. The change in error is itself a troubleshooting clue.

1. Restore allowInsecure: false so the test includes full certificate verification.
2. Confirm the system date, time zone, and synchronization source, then fully restart v2rayN.
3. Check notBefore, notAfter, and the certificate hostname list.
4. Check the server address, port, SNI, Host, and the original subscription fields.
5. Check the server virtual host, certificate chain, and actual listening endpoint.
6. Only then compare different networks to determine whether an intermediate device is involved.

Finish with a fixed decision path: if every node fails, check time and network first; if one hostname fails, check its certificate and SNI; for a name error, verify the field mapping; for an unknown issuer, inspect the certificate chain; for a timeout alone, return to DNS, the port, and the listener. This avoids trial and error across system proxy settings, routing rules, and TLS parameters, while clarifying whether the issue belongs to client configuration, proxy-core logs, subscription data, or server deployment.