本文目錄
日誌裡同樣有 handshake failed，失敗的卻可能是下載訂閱、連線代理伺服器或開啟目標網站。對應的憑證與設定不同，盲目換節點或關閉驗證會掩蓋原問題。找出錯誤發生的位置，再依原文檢查時間、信任鏈和伺服器名稱，最後重試同一筆失敗請求。
TLS 握手失敗：日誌原文與失敗位置決定檢查方向
複製完整 TLS 錯誤，並記錄它發生在訂閱下載、節點連線還是目標網站存取。交握會協商加密通訊，一般 HTTPS 通常由用戶端驗證伺服器身分；下表依時間、憑證和節點欄位區分檢查方向。
常見原文
| 日誌文字 | 優先方向 |
|---|---|
| x509: certificate has expired or is not yet valid | 系統時間、憑證有效期 |
| x509: certificate signed by unknown authority | 系統 CA、企業 SSL 檢查、私有憑證 |
| remote error: tls: handshake failure | SNI、協議欄位、伺服器端 TLS 設定 |
| tls: failed to verify certificate: x509 | 憑證鏈、servername 與實際憑證名稱 |
| EOF / connection reset by peer | 對端提前關閉、網路攔截；不能只憑這一句斷定憑證問題 |
複製錯誤前後幾行，保留時間、目標網域和連接埠，但遮住訂閱 token、UUID 與密碼。只截「TLS failed」會丟掉真正能區分原因的部分。
訂閱、單個節點與目標網站發生錯誤，檢查對象不同
Profile 更新報 TLS，現有節點還能用
失敗在訂閱 URL；檢查該網域憑證、系統時間和網路檢查裝置。
只有一個節點報 handshake failure
失敗在用戶端到代理伺服器；比較該節點的 server、port、SNI 與 TLS 欄位。
節點能連，只有一個 HTTPS 網站報憑證錯誤
查看目標站憑證、瀏覽器/應用憑證庫和是否被安全軟體解密。
所有節點同時開始 x509 發生錯誤
先看系統時間、核心升級和網路是否統一替換了憑證。
憑證顯示已過期或尚未生效時，檢查系統時間
# Linux
date -R
timedatectl status
# Windows PowerShell
Get-Date
w32tm /query /status憑證有 Not Before 與 Not After。雙系統切換、虛擬機快照、長期斷電的 OpenWrt 或關閉自動校時，都可能讓時間偏離。把日期、時區和 NTP 同步恢復後，重新啟動 Mihomo 再復現一次；錯誤仍完全相同才繼續檢查握手欄位。
單個節點失敗時，對照 SNI 與伺服器端憑證名稱
TLS 節點的 server 可能是 IP，憑證卻簽發給網域；這時通常需要正確的 servername 或 sni。值必須來自伺服器設定，不能在網路上猜一個熱門網域。連接埠、傳輸類型、ALPN、Reality public-key/short-id 等欄位也須成套匹配。
proxies:
# 下列 IP、域名和密码都是占位值，不能直接连接
- name: tls-example
type: trojan
server: 203.0.113.10
port: 443
password: REDACTED
sni: edge.example.com
skip-cert-verify: false在同一網路查看伺服器實際回傳的憑證
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/在 openssl 輸出中查看 subject、issuer、有效期與 Verify return code。以網域連線時，SNI 可能自動送出，不能只憑刪掉參數判定它未送出。
比較沒有 SNI 的結果前，確認所用 OpenSSL 支援 -noservername。刪除 -servername 及其值，再加入 -noservername；保留相同目標、-verify_hostname 和 -verify_return_error。兩個 SNI 參數不能並用。
同一目標在手機熱點正常、公司網路卻回傳企業 CA 憑證時，表示憑證可能被檢查裝置替換。把兩邊結果交給管理員，不自行安裝陌生根憑證。
代理協議連接埠不一定提供普通 HTTPS 頁面，curl 失敗並不自動說明節點壞了；openssl 的憑證與握手資訊更有參考價值。Reality 等協議也不能按普通網站憑證逐項套用，應回到對應協議文件。
公司網路的 HTTPS 檢查是否替換了憑證？
企業代理、安全閘道和部分殺毒軟體會重新簽發 HTTPS 憑證。受管裝置應由管理員安裝組織 CA 並說明哪些流量允許檢查；個人不要從發生錯誤網頁下載陌生根憑證，也不要為讓 Clash 更新成功關閉全系統憑證驗證。
換手機熱點後同一訂閱 URL 立即正常，是網路路徑差異的證據。把公司網路下的 issuer、錯誤時間和目標網域交給管理員，比不斷換節點更有用。
修復後重複原來失敗的那條連線
驗證結果
- 系統時間與時區正確，重啟核心後不再出現 not yet valid/expired
- 訂閱失敗時，手動更新成功且更新時間變化
- 節點失敗時，同一節點完成握手並產生實際連線記錄
- 目標網站失敗時，憑證 issuer 與網域符合預期
- 臨時關閉的憑證檢查或安全設定已經恢復
- skip-cert-verify 保持 false，除非受控測試有明確理由