On this page
When you see TLS handshake failed, save the complete error and the stage that failed
Certificate errors, incorrect system time, and a wrong SNI can all appear as a TLS handshake failure, but require completely different fixes. Copy the full original log message first, then determine whether the error occurs while downloading the subscription, handshaking with the proxy node, or opening the target website. Once both are known, you can inspect the time, certificate chain, or node fields.
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 download, node handshake, and target website are three separate connections
Run a simple comparison first: can existing nodes still reach other HTTPS sites, and can the subscription still update manually? Together, those results usually identify which hop has the handshake failure.
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.
When the system time is wrong, every certificate setting can be misdiagnosed
# 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 -showcerts </dev/null
curl -Iv https://edge.example.com/In openssl output, inspect subject, issuer, validity, and Verify return code. If adding -servername returns a different certificate, the server depends on SNI. If the certificate is normal on a mobile hotspot but becomes a corporate CA on the company network, SSL inspection or an intermediary gateway is present.
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.
If failure occurs only on the corporate network, check for managed certificate inspection first
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
Do not replace verification with “other sites open.” Return to the subscription, node, or target website that originally failed, retry it on the same network, and confirm that the original log error is gone.
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