Clash 節點 TLS 握手失敗或逾時？從憑證鏈與 SNI 分五步排查

為什麼「測得通」卻「用不通」？

在 Clash 與基於 mihomo 內核的客戶端中，節點逾時與 TLS 握手失敗是兩類常見但成因不同的現象。前者多與網路徑、防火牆、DNS 或協定（例如依賴 UDP 的傳輸）有關；後者則多半發生在與遠端建立加密通道時——客戶端送出的 Client Hello、攜帶的 SNI（Server Name Indication）、以及本機對伺服器憑證的驗證鏈任一步不吻合，都可能導致握手中止。若你只看延遲數字或 ICMP，很容易誤判為「節點沒問題」，因為那些測試未必重現實際 HTTPS 連線的完整條件。

下列五步請盡量依序進行：前兩步處理時間與憑證、以及遠端主機名是否正確；第三步處理分應用代理是否讓部分程序未進隧道；第四步處理嗅探與域名覆寫對 TLS 的間接影響；第五步再把 UDP、策略與真實逾時分開討論。每完成一步，都建議截圖或複製當下日誌關鍵行，方便與服務商或社群討論時對齊上下文。

步驟一：系統時間、根憑證庫與完整憑證鏈

TLS 驗證高度依賴本機時間。若筆電、手機或路由器長時間離線，系統時間快或慢超過數分鐘，就可能出現「憑證尚未生效」或「已過期」的錯誤，日誌常寫成 x509 相關訊息或籠統的 握手失敗。請先在所有參與連線的裝置上開啟網路自動對時，再重試同一節點與同一網站。

第二個檢查點是憑證鏈是否完整。部分精簡系統、舊版 Android、或自行裁剪過的信任庫，可能缺少某張中繼 CA，導致無法驗證伺服器憑證。桌面環境可對照瀏覽器直接開啟同一域名是否報錯；若瀏覽器正常而僅代理連線失敗，才再懷疑節點或 SNI。企業網路若掛了 HTTPS 檢查（middlebox），也可能替換憑證而與 Clash 內建驗證邏輯衝突——此時可暫時換一條網路（例如手機熱點）做對照。

步驟二：節點的 SNI、servername 與實際連線主機名

SNI 讓單一 IP 上多個 HTTPS 網站能依域名選擇正確憑證。若你的代理出站設定中，server 填的是 IP，卻未正確指定 servername／sni（或與訂閱模板預設不符），遠端可能回傳錯誤憑證或直接斷線，日誌即顯示 TLS 握手異常。這在「用 IP 當位址」的 VMess／VLESS／Trojan 類型上特別常見。

請打開目前使用中的設定檔，核對該節點區塊：連線位址是域名還是 IP？若為 IP，是否有一段與服務商文件一致的域名應寫在 SNI 欄位？部分面板產生的訂閱會把 SNI 與 host 分開，更新訂閱連結後也應重新整理設定，避免本地仍快取舊欄位。完成後在客戶端日誌中搜尋該連線的目標主機名，確認 Client Hello 層級的名稱與你預期相符。

若你使用 REALITY 或其他依賴「偽裝站點」的傳輸，SNI 還必須與遠端配置的 server-names／允許清單一致；任意改成熱門大站卻未在服務端對齊，也會表現為握手階段失敗。這類問題換節點無效，必須與服務端參數一一對表。

步驟三：分應用代理是否讓流量沒進 Clash

分應用代理（Per-App Proxy）在行動端幾乎是標配：你可指定「只有這些 App 走代理」或「這些 App 略過」。一旦清單與模式搞反，就會出現「Clash 顯示已連線、瀏覽器卻仍被系統直接送出」或「只有內建測速走代理、實際 App 全直連」的錯位。表層症狀有時被誤解成 節點逾時，因為請求根本沒走到你以為的那條線路。

建議在調整分應用設定後，完全結束再重開目標 App，並在 Clash 的連線或日誌面板觀察：當你載入網頁時，是否出現對應程序的連線紀錄？若沒有任何紀錄，代表流量未進隧道，應回到清單與 VPN 權限；若有紀錄但馬上失敗，再銜接步驟二與步驟四。桌面端若搭配 TUN 模式，也要確認沒有其他 VPN 或過濾驅動搶佔路由表，否則同樣會出現「以為有代理、實際沒套上」的現象。與 Android 權限、DNS 相關的完整流程，也可與本專欄中 Clash for Android 訂閱與逾時教學對讀。

步驟四：嗅探、覆寫與 TLS 解析的邊界

mihomo／Clash Meta 系列常啟用 嗅探，從流量中還原域名，讓「只有 IP、沒有 Host 頭」的連線仍能命中 DOMAIN 規則。多數場景下這能減少誤分流，但在少數設定組合下，覆寫或 skip 清單可能讓內層 TLS 所見的域名與你以為的不同，間接導致與遠端期望的 SNI 不一致。若日誌同時出現規則命中與握手錯誤，可嘗試暫時關閉嗅探或僅對特定入站關閉，做最小化 A／B 測試。

另一個易忽略點是 fake-ip 與本機解析的互動：域名在客戶端側先被映射成虛擬位址，再於出站階段還原；若 DNS 與規則順序不當，少數站點會出現「解析看起來正確、實際連線卻指向別組 IP」的競態。此時可參考專欄中 Fake-IP 與 Redir-Host 的對照文，先確認 DNS 模式本身沒有製造額外變數，再回到 TLS 層細查。

步驟五：UDP、QUIC、路由與「真逾時」判斷

並非所有錯誤訊息都來自 TLS 握手。當日誌顯示 i/o timeout、read timeout、或長時間無回應，可能是路徑上某段對 UDP 不友善、QoS 嚴格、或出口對 QUIC／HTTP3 有限制。部分新型協定（如 Hysteria、TUIC）依賴 UDP，若你在公司或校園網路，會比純 TCP 的線路更容易出現「偶發全紅」。

建議在相同網路下比較兩類節點：一類以 TCP 為主、一類仰賴 UDP；若只有後者失敗，偏向環境封鎖而非訂閱全面損毀。亦可暫時在瀏覽器關閉 HTTP3 做對照，或在 Clash 中針對特定域名強制走 TCP 出口（依你使用的內核與訂閱能力而定）。最後，請確認 規則分流沒有把測速域名與日常瀏覽拆到兩條品質差異極大的線路上——這會製造「測速好看、實際網站全掛」的假象。

若五步之後仍僅在單一網站失敗，可將該站的完整域名、錯誤截圖與去隱私後的日誌片段一併提供給服務商；若多站全面失敗且更換網路後立刻恢復，則應優先懷疑本地防火牆與電信策略。想從設定檔層面加深對策略組與插入順序的理解，可延伸閱讀YAML 規則入門，把「能連」與「走對線」拆開處理。

常見問題（精簡版）

節點延遲測試正常，為什麼仍出現 TLS handshake failed？

延遲測試多半只對特定 URL 做短連線，與你實際造訪的網站 TLS 參數、SNI、憑證鏈或路徑不同。若日誌在完整網頁載入階段才報握手失敗，請對照步驟二與步驟四，檢查遠端主機名、嗅探覆寫是否讓 Client Hello 攜帶錯誤 SNI，並確認系統時間與根憑證是否可信。

分應用代理會導致 TLS 錯誤嗎？

會。若瀏覽器或目標 App 被設為略過代理，流量不進 Clash 隧道，可能出現「客戶端顯示連線異常、日誌卻沒有對應記錄」或相反情形。請確認分應用清單與模式是否與測試對象一致，並以連線日誌驗證該程序實際命中的策略。

read／write timeout 一定是節點壞了嗎？

不一定。逾時可能來自本機到節點的路徑、防火牆對 UDP／QUIC 的限制、DNS 解析過慢、或規則把部分流量導向錯誤出口。請先完成步驟一至四，再依步驟五區分是真節點不可用還是特定協定／埠被攔截。

寫在最後：先對照日誌分層，再決定要不要換節點

相比於「某個網站／某個遊戲」的場景專篇，本文刻意維持在協議層通用排查：無論你用的是哪個圖形客戶端，只要內核仍要與遠端做 TLS 握手，時間與憑證鏈、SNI 是否對齊永遠是第一道門檻；接著才是分應用代理、嗅探與 DNS／規則是否把連線帶偏；最後才輪到 UDP 與真實網路逾時。把這五步當成檢查清單，通常能避免一開始就無效地更換訂閱或來回重裝軟體。

若你希望減少四處搜尋版本與權限細節的時間，也可從本站整理好的安裝包與匯入訂閱連結說明入手，搭配圖形介面逐步驗證。歡迎前往下載頁面取得對應平台客戶端。