V2Ray TLS handshake failed or certificate error: fix system time and SNI settings

When the V2Ray or Xray core establishes an encrypted connection, it first completes TCP or another underlying transport before starting the TLS handshake. Any mismatch involving the certificate validity period, certificate domain, system time, SNI, TLS version, or client fingerprint can terminate the connection before a proxy request is sent. So a browser connection failure, an unavailable result in v2rayN latency testing, or a certificate error in the v2rayNG log does not by itself mean that the server port is closed.

Identify the TLS error from the logs first

The first step in troubleshooting TLS is not repeatedly clicking the latency test, but saving one complete log. In v2rayN, view core output in the log area on the main screen, or check the log level under Settings → Parameter Settings. In v2rayNG and v2flyNG, open the Logs page from the side menu and reconnect once. Record the first error line; later connection closures and retry failures are usually just follow-on effects.

EOF, connection reset by peer, and timeouts are not specific to TLS. They can also result from a server process that is not listening, a mismatched transport path, or an intermediary network device closing the connection early. Only prioritize certificate-chain troubleshooting when the log also contains x509, certificate, serverName, or explicit TLS handshake text.

• Find the earliest error instead of copying only the last log line.
• Record the node address, port, transport, TLS setting, and SNI, but never share subscription links publicly.
• Test the same node twice at most; frequent reconnects can bury the useful log entries under repeated messages.
• If multiple nodes show certificate time errors on the same device, check the device clock first.

System time and time zone come first

A certificate has a not-before time and an expiration time. The device uses its local system clock to determine whether the current moment falls within that validity period. A correct date with the wrong time zone, clock drift after sleep, or a virtual machine that has not synchronized with its host can trigger not yet valid or expired. Do not check only the hour and minute in the taskbar; verify the year, month, day, and time zone as well.

1. Check the date

   Make sure the year, month, and day are correct. If the device has just resumed from a long sleep, wait for network time synchronization to finish.

2. Check the time zone

   On Windows, open Settings → Time & language → Date & time. Make sure the time zone matches your location and enable automatic time setting.

3. Sync now

   Click “Sync now” on the same page. On Android, open Settings → System → Date & time and enable automatic time and automatic time zone.

4. Restart the core

   Stop the current connection, exit the client core, and start it again. Then run one latency test and visit a real webpage through the original node.

On Windows, you can also check the time service status and initiate synchronization from an administrator terminal. On Linux, use timedatectl to check local time, UTC time, the time zone, and NTP status. After the command succeeds, restart the V2Ray or Xray core so an old connection does not continue using its previous handshake state.

w32tm /query /status
w32tm /resync

timedatectl status
sudo timedatectl set-ntp true

Check the node address, SNI, and certificate domain

The node “address” and TLS serverName serve different purposes. The address is used for DNS resolution and establishing the network connection; serverName is placed in the TLS ClientHello SNI extension and is typically also the target for certificate-domain validation. The server address may be an IP or access domain, but SNI should match a domain covered by the server certificate.

For example, if the client connects to 203.0.113.20 and the certificate covers only edge.example.net, the address can remain the IP while SNI should be set to edge.example.net. If SNI is empty, the core may derive the name to validate from the address. When the address is an IP but the certificate contains only a domain, an error saying that the certificate is valid for one domain but not the current address is likely.

1. Open the node

   In the v2rayN main window, select the target node and open the edit window. In v2rayNG or v2flyNG, open the edit entry for the corresponding configuration.

2. Copy down the parameters

   Record the address, port, transport protocol, TLS setting, SNI, Host, ALPN, and fingerprint. Keep the original values so you can roll back changes.

3. Compare the domains

   Compare SNI character by character with the certificate domain shown in the error. Pay special attention to extra spaces, non-ASCII punctuation, wrong suffixes, and missing subdomains.

4. Save and retest

   Save the changes and restart the core, then test only this node. If the error changes from a domain mismatch to a connection timeout, check address resolution and port reachability separately.

Distinguish an expired certificate, a missing chain, and a server configuration error

If the system time is accurate and SNI matches the domain but certificate verification still fails, inspect the server certificate itself. Common causes include an expired certificate, a service that did not reload after renewal, a new certificate deployed to the wrong virtual host, or a server sending only the site certificate without its intermediate certificates.

If a regular browser also shows a certificate problem for the same domain, the issue is more likely with the server’s certificate deployment. If the browser works but V2Ray/Xray fails, compare the connection port, SNI, ALPN, and transport. A successful browser visit proves only that the particular domain and port used by the browser work; it does not prove that another port in the node configuration uses the same certificate.

• Make sure the certificate’s start and expiration times cover the current moment.
• Make sure the certificate’s Subject Alternative Names include the full domain used by SNI.
• Make sure the reverse proxy or TLS termination service sends the complete certificate chain.
• After renewal, make sure the process actually listening for connections has reloaded the configuration.
• Make sure port 443 or the custom port is not occupied by another service.
• Make sure a subscription update has not written the old domain or port back into the client.

How to configure allowInsecure, fingerprint, and ALPN

allowInsecure controls whether the client skips certificate and domain validation. In v2rayN, v2rayNG, and v2flyNG, it may appear as “Skip certificate verification” or a similar switch. With a publicly trusted certificate, leave it off so the core continues to validate the certificate chain and serverName.

Temporarily enabling this option can help isolate the problem: if the connection works immediately, the network address, port, and main transport path are probably reachable, while the issue is likely the certificate validity period, domain match, or trust chain. This is for diagnosis only; restore strict validation and fix the underlying cause.

• allowInsecure: Affects certificate validation; it does not fix an incorrect SNI or renew an expired certificate.
• fingerprint: Adjusts the TLS ClientHello profile, such as the required chrome setting. It is not a certificate fingerprint and cannot replace certificate-chain validation.
• ALPN: Common values include h2 and http/1.1; they must be compatible with the server entry point and transport.
• TLS version: The client and server need at least one mutually supported version. Older system environments may be unable to complete a modern TLS negotiation.

Before changing the fingerprint, confirm what the node provider or self-hosted service explicitly requires. Changing the fingerprint, ALPN, and SNI all at once makes the results impossible to compare. Keep a copy of the original configuration, change one field at a time, restart the core, and save the corresponding log.

Test 1: Keep strict certificate validation enabled; fix only the system time
Test 2: Keep all other parameters unchanged; fix only SNI
Test 3: Restore strict validation; change only the fingerprint required by the server
Test 4: Check ALPN and the transport, then reconnect

Retest in a fixed order to avoid parameter interference

After making changes, stop the old connection and restart the core. Clicking Save in the interface does not always interrupt an established or retrying connection. Retest with one node latency check, then visit a normal HTTPS page, and finally check whether the log still shows the same first error.

1. Sync the clock

   Bring the system clock back within a normal range and confirm the date, time zone, and automatic time-sync status.

2. Check the address

   Confirm that the node domain resolves, the server address and port were copied correctly, and the TLS service is listening on the target port.

3. Fix SNI

   Set serverName to a domain covered by the certificate. Enter only the domain; do not include https://, a port, or a path.

4. Verify the certificate chain

   Check the validity period, intermediate certificates, and the certificate actually loaded by the service. After renewal, confirm that the listening service is using the new certificate.

5. Change parameters one at a time

   Check the fingerprint and ALPN as needed, changing only one item per round and keeping the logs from before and after each change.

6. Restore strict validation

   After troubleshooting, turn off the skip-certificate-verification option, restart the core, and run a final connection test.

If the desktop and Android clients fail on the same network and node while both devices have accurate clocks, check the server certificate and SNI first. If only one device fails, compare its system time, client configuration, and system certificate environment first. If every TLS node fails while non-TLS connectivity tests work, also check whether local security software, the network gateway, or the system TLS environment is altering the handshake path.