Troubleshooting TLS certificate errors

1. Distinguish certificate errors from connection failures in the logs

“TLS handshake failed” describes the outcome, not the cause. Check the full error for your latest connection in the log area at the bottom of the v2rayN main window. If the log panel is collapsed, expand it first. The interface may vary by version, so look for the core's original message containing x509, tls, or certificate, rather than relying on a browser message such as “Connection reset.”

Select one node, note the connection time, and make a single request. The examples below show common English error messages; actual logs may also include the core module name, connection address, and nested causes. Before sharing logs, remove sensitive details such as subscription URLs, user identifiers, and destination addresses.

2. Sync your system clock, then check whether the certificate has expired

TLS validation compares the current time with the certificate's notBefore and notAfter values. A clock reset after a power outage, an old virtual machine snapshot, or a manually changed date can make a valid certificate appear “not yet valid” or “expired.” Check the date and minute, not just the hour on the taskbar.

1. Check the date

   In Windows 11, go to Settings → Time & language → Date & time and check the date, time, and time zone. Compare them with another device whose clock is syncing correctly.

2. Sync now

   Turn on “Set time automatically,” then select “Sync now” under “Additional settings.” If syncing fails, restore a regular internet connection and try the system time service again.

3. Reconnect

   Return to the client, re-enable the node, and make a new request. Use the new log; don't keep diagnosing an old error from before the clock was synced.

4. Check the validity period

   If the time is correct but the certificate still appears expired, inspect the validity period of the certificate the server actually returns. If the current time is later than notAfter, the maintainer must renew the certificate and reload it in the TLS service.

On Android, search for “Date and time” in Settings and turn on automatic time. Menu names vary by device. The time zone changes how time is displayed; when the underlying absolute time is correct, choosing a different time zone alone usually won't cause a certificate error. Manually setting the clock back may temporarily restore a connection, but can disrupt other services and isn't a fix.

Time synchronization and node connections use separate network paths. A node using port 443 doesn't mean time sync uses that port too. When checking network policies for time sync, verify the actual time source and protocol; don't open inbound ports on your device without a clear reason.

3. Check SNI, server address, and Host

A node's “address,” the TLS “server name,” and the WebSocket “Host” are not interchangeable. The server address determines where the connection goes. SNI is sent during the TLS handshake to help the server select a site and certificate. HTTP Host, or HTTP/2 authority, belongs to the application layer. Changing Host won't automatically fix the name used for certificate validation.

In the v2rayN main window, double-click the node to open its server settings. Confirm that transport security is set to TLS, then check “SNI” or the equivalent server name field. Labels vary by version; look for the field corresponding to serverName. In v2rayNG, open the node's edit screen and check SNI in the TLS settings. Don't include https://, :443, or a URL path in the hostname field.

• If you connect using an IP address, you may still need to enter a domain as SNI. Otherwise, the client may validate the IP even though the certificate only covers a domain.
• *.example.com typically matches a.example.com; that doesn't mean it also covers example.com or a.b.example.com.
• “Camouflage domain” is an ambiguous label used in some interfaces. First check whether it refers to SNI or Host, then compare the setting with the values provided by the maintainer.
• If the issue returns after updating your subscription, check whether its SNI value is outdated. Local changes may be overwritten the next time the subscription updates.

4. Check the certificate chain and what the server actually returns

“Unknown authority” doesn't mean “expired certificate.” Even a site with a valid domain certificate can fail to establish a complete chain of trust if it omits an intermediate certificate. A successful browser visit doesn't rule this out: browsers and proxy cores may use different trust stores, cached certificates, or methods for retrieving intermediates.

If OpenSSL is installed, use the following commands to check the server. example.com is a reserved example domain, not a node from this site. Replace the domain and port in the commands with the actual values before running them. If the connection address differs from SNI, set the real connection target with -connect, and the expected TLS hostname with -servername and -verify_hostname.

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

• Check whether the returned leaf certificate belongs to the expected site. If the server returns a certificate for another site, check SNI and the server's virtual host configuration.
• Check whether Certificate chain includes the required intermediate certificates. A server should generally send the leaf certificate and intermediate certificates, but doesn't need to include the root certificate.
• Check the final verification result. Verify return code: 0 (ok) means the test passed using this tool's current trust environment; it doesn't guarantee that every device will pass.
• If OpenSSL's CA trust paths aren't configured correctly, it may report an issuer error. Check the test tool's trust environment first to avoid misdiagnosing the server.

The maintainer should configure the complete certificate chain on the service that actually terminates TLS. For example, if a reverse proxy sits in front, update the certificate loaded by the proxy, not just a file in the backend core's directory. After renewing the certificate, reload the relevant services and perform a new handshake from outside the server to confirm that it returns the new certificate.

5. Retest with the same conditions after applying a fix

Changing nodes, SNI, DNS, and TUN mode all at once makes the results impossible to compare. Keep the same node and test destination, and change only one variable at a time. This sequence helps distinguish an actual configuration fix from simply switching to a working route by chance.

1. Set a baseline: Record the node address, port, TLS type, and SNI, along with the error time. Don't share node credentials.
2. Retest after syncing: Keep the node settings unchanged and sync only the system clock. If the validity error goes away, check whether a name or trust chain error remains.
3. Retest after correcting the name: Set SNI to the value provided by the maintainer, reconnect, and check that the name in the new log matches what you expect.
4. Compare networks: Test the same device and node on another network. If a different certificate appears on only one network, investigate network filtering, DNS resolution, and intermediary devices.
5. Confirm the fix holds: Update the subscription, reopen the client, and test again. Check whether the subscription overwrote your fix or the server is still returning an old certificate.

If the certificate still appears expired or the chain is incomplete with the correct time and SNI, there's little more the client can fix. Send the maintainer the exact error, test time, client and core versions, connection port, and expected SNI. This is more useful for diagnosing the issue than a screenshot saying only “node doesn't work.” For other network and core issues, see the troubleshooting guide.

6. FAQ: Skipping verification and interrupted handshakes