On this page
The same handshake failed message can occur while downloading a subscription, connecting to the proxy server, or opening the target website. The certificates and settings involved differ, and blindly changing nodes or disabling verification can hide the original problem. Locate the failure, use the exact error to check time, trust chains, and server names, then repeat the same failed request.
TLS handshake failures: the exact log and failure location guide troubleshooting
Copy the full TLS error and record whether it occurs during subscription downloads, node connections, or access to the target site. The handshake negotiates encrypted communication; in ordinary HTTPS, the client normally verifies the server’s identity. Use the table below to distinguish time, certificate, and node-field checks.
Common original messages
| Log text | Where to look first |
|---|---|
| x509: certificate has expired or is not yet valid | System time and certificate validity |
| x509: certificate signed by unknown authority | System CA, corporate SSL inspection, or private certificates |
| remote error: tls: handshake failure | SNI, protocol fields, and server-side TLS configuration |
| tls: failed to verify certificate: x509 | Certificate chain, servername, and the certificate's actual name |
| EOF / connection reset by peer | The peer closed early or the network intercepted the connection; this line alone does not prove a certificate problem |
Copy several lines before and after the error, preserving the time, target domain, and port while hiding the subscription token, UUID, and password. Capturing only “TLS failed” removes the details that distinguish the causes.
Subscription, single-node and website errors require different checks
Profile update reports TLS, but existing nodes still work
The subscription URL is failing; inspect that domain's certificate, system time, and any network inspection device.
Only one node reports handshake failure
The client-to-proxy-server connection is failing; compare the node's server, port, SNI, and TLS fields.
The node connects, but only one HTTPS site reports a certificate error
Inspect the target site's certificate, the browser or app certificate store, and whether security software is decrypting the connection.
All nodes begin reporting x509 errors at the same time
Check system time, core updates, and whether the network has replaced certificates globally.
Check the system time when a certificate appears expired or not yet valid
# Linux
date -R
timedatectl status
# Windows PowerShell
Get-Date
w32tm /query /statusCertificates have Not Before and Not After values. Switching between dual-boot systems, restoring a virtual-machine snapshot, leaving OpenWrt powered off for a long time, or disabling automatic time sync can skew the clock. Restore the date, time zone, and NTP synchronization, restart Mihomo, and reproduce the issue once. Continue inspecting handshake fields only if the error remains identical.
If only one node fails, compare SNI with the server certificate name
A TLS node's server may be an IP while its certificate was issued to a domain. In that case, the configuration usually needs the correct servername or sni. The value must come from the server configuration; do not guess a popular domain from the internet. The port, transport type, ALPN, and Reality public-key/short-id fields must also match as a set.
proxies:
# 下列 IP、域名和密码都是占位值，不能直接连接
- name: tls-example
type: trojan
server: 203.0.113.10
port: 443
password: REDACTED
sni: edge.example.com
skip-cert-verify: falseInspect the certificate actually returned by the server on the same network
openssl s_client -connect edge.example.com:443 -servername edge.example.com -verify_hostname edge.example.com -verify_return_error -showcerts </dev/null
curl -Iv https://edge.example.com/Inspect subject, issuer, validity, and Verify return code in the openssl output. Connecting by domain may send SNI automatically, so removing an argument alone does not prove that SNI was omitted.
Before comparing a connection without SNI, confirm that your OpenSSL supports -noservername. Remove -servername and its value, then add -noservername. Keep the same target, -verify_hostname, and -verify_return_error. The two SNI options cannot be used together.
If the same target returns its usual certificate on a mobile hotspot but a corporate CA certificate on the company network, an inspection device may be replacing it. Give both results to the administrator rather than installing an unfamiliar root certificate yourself.
A proxy protocol port does not necessarily serve an ordinary HTTPS page, so a curl failure does not automatically mean the node is broken. Certificate and handshake details from openssl are more informative. Protocols such as Reality also cannot be evaluated field by field like an ordinary website certificate; return to the corresponding protocol documentation.
Is HTTPS inspection on the corporate network replacing the certificate?
Corporate proxies, security gateways, and some antivirus products re-sign HTTPS certificates. On managed devices, an administrator should install the organization's CA and document which traffic may be inspected. On personal devices, do not download an unfamiliar root certificate from an error page or disable system-wide certificate verification just to make Clash updates work.
If the same subscription URL works immediately after switching to a mobile hotspot, that is evidence of a different network path. Give the administrator the issuer, error time, and target domain from the corporate network; that is more useful than repeatedly switching nodes.
After fixing it, repeat the exact connection that originally failed
Verification results
- System time and time zone are correct, and not yet valid/expired no longer appears after restarting the core
- When a subscription failed, a manual update now succeeds and the update time changes
- When a node failed, that same node now completes its handshake and creates a real connection record
- When the target website failed, the certificate issuer and domain now match expectations
- Any certificate inspection or security setting temporarily disabled has been restored
- Keep skip-cert-verify false unless a controlled test has a specific reason