連線疑難排解 · Clash 技術部落格

Clash TLS 握手失敗怎麼辦？憑證、時間與 SNI 檢查

先看 TLS 錯誤發生在訂閱下載、節點握手，還是存取目標網站。這三處都可能顯示 handshake failed，但要檢查的憑證、時間和 SNI 完全不同。

閱讀正文回到部落格
  • TLS
  • 憑證錯誤
  • SNI
  • 連線疑難排解
本文目錄
發布日期
更新時間
預計閱讀
約 8 分鐘

看到 TLS handshake failed，先儲存完整錯誤和失敗階段

憑證錯誤、系統時間不准和 SNI 配錯都會顯示成 TLS 握手失敗，但修法完全不同。先複製日誌中的完整原文，再確認錯誤發生在訂閱下載、代理節點握手，還是開啟目標網站；這兩項確定後，才知道該查時間、憑證鏈還是節點欄位。

常見原文

日誌文字優先方向
x509: certificate has expired or is not yet valid系統時間、憑證有效期
x509: certificate signed by unknown authority系統 CA、企業 SSL 檢查、私有憑證
remote error: tls: handshake failureSNI、協議欄位、伺服器端 TLS 設定
tls: failed to verify certificate: x509憑證鏈、servername 與實際憑證名稱
EOF / connection reset by peer對端提前關閉、網路攔截；不能只憑這一句斷定憑證問題

複製錯誤前後幾行，保留時間、目標網域和連接埠，但遮住訂閱 token、UUID 與密碼。只截「TLS failed」會丟掉真正能區分原因的部分。

訂閱下載、節點握手和目標網站是三條不同連線

先做一個很簡單的對照：現有節點還能不能存取其他 HTTPS 網站，訂閱還能不能手動更新。兩個結果組合起來，通常就能判斷握手失敗發生在哪一跳。

Profile 更新報 TLS，現有節點還能用

失敗在訂閱 URL；檢查該網域憑證、系統時間和網路檢查裝置。

只有一個節點報 handshake failure

失敗在用戶端到代理伺服器；比較該節點的 server、port、SNI 與 TLS 欄位。

節點能連，只有一個 HTTPS 網站報憑證錯誤

查看目標站憑證、瀏覽器/應用憑證庫和是否被安全軟體解密。

所有節點同時開始 x509 發生錯誤

先看系統時間、核心升級和網路是否統一替換了憑證。

時間不對時，任何憑證設定都會被誤判

Linux 與 Windows 可先查看
# 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 等欄位也必須成套匹配。

欄位名稱按代理類型與目前 Mihomo 文件核對
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 -showcerts </dev/null

curl -Iv https://edge.example.com/

openssl 輸出裡看 subject、issuer、有效期與 Verify return code。加與不加 -servername 回傳不同憑證，說明伺服器端依賴 SNI；憑證在手機熱點正常、公司網路卻變成企業 CA，則存在 SSL 檢查或中間閘道。

代理協議連接埠不一定提供普通 HTTPS 頁面，curl 失敗並不自動說明節點壞了；openssl 的憑證與握手資訊更有參考價值。Reality 等協議也不能按普通網站憑證逐項套用，應回到對應協議文件。

只有公司網路失敗，先確認是否有受管憑證檢查

企業代理、安全閘道和部分殺毒軟體會重新簽發 HTTPS 憑證。受管裝置應由管理員安裝組織 CA 並說明哪些流量允許檢查；個人不要從發生錯誤網頁下載陌生根憑證，也不要為讓 Clash 更新成功關閉全系統憑證驗證。

換手機熱點後同一訂閱 URL 立即正常，是網路路徑差異的證據。把公司網路下的 issuer、錯誤時間和目標網域交給管理員，比不斷換節點更有用。

修復後重複原來失敗的那條連線

不要用「別的網站也能開啟」代替驗證。回到最初發生錯誤的訂閱、節點或目標網站，用同一網路再試一次，並確認日誌中的原錯誤已經消失。

驗證結果

  • 系統時間與時區正確，重啟核心後不再出現 not yet valid/expired
  • 訂閱失敗時，手動更新成功且更新時間變化
  • 節點失敗時，同一節點完成握手並產生實際連線記錄
  • 目標網站失敗時，憑證 issuer 與網域符合預期
  • 臨時關閉的憑證檢查或安全設定已經恢復
  • skip-cert-verify 保持 false，除非受控測試有明確理由

參考資料