一、TLS Handshake Timeout 代表什麼
在 Clash／Mihomo 系列用戶端日誌裡，TLS Handshake Timeout（或「握手逾時」「TLS 握手失敗」等相近字串）通常表示：核心已嘗試與遠端建立 TLS，但在逾時時間內沒有完成 Client Hello 之後的往返。它不等同於「節點離線」——節點管理介面仍顯示延遲正常，但某一條實際 HTTPS 連線仍可能在握手階段卡住。
實務上可把握手逾時理解成時間維度的症狀：對端不回、路徑丟包嚴重、被中間設備攔截重試、或本機在錯誤的目標位址／錯誤的 SNI 上反覆嘗試，都會表現為逾時。接下來要做的，是把「逾時」拆回節點／SNI 與憑證／嗅探／規則／DNS五條可驗證的線索，而不是一次改五個設定。
# Example log fragments (wording varies by core / UI)
TLS handshake timeout
dial ... i/o timeout
若你同時看到全系統無法上網、路由異常或虛擬介面未起來，優先對照 TUN 與路由防火牆排查；本文聚焦典型錯誤字串與 HTTPS 握手鏈路，與「整張網卡斷流」類問題互補。
二、先做三分流：節點、握手、規則／DNS
開啟日誌後，請先抄下同一筆失敗連線能對齊的三件事：目標網域或 IP、當下命中的規則與策略組（或 policy）、實際使用的節點或 proxy 名稱。若 UI 能顯示連線預覽，再補上解析結果是否落在 fake-ip-range、以及嗅探是否還原出預期網域。
三分流的判讀直覺如下：多數網域、多數協定在同一節點上都逾時，較像節點或線路品質問題；僅少數網域逾時、且與特定 CDN／金融／企業入口重疊，較像 SNI、憑證或嗅探相容性；僅在開啟 fake-ip 或特定 DNS 上游時才出現握手異常，則應回到 DNS 與 fake-ip-filter，可併讀 fake-ip 與 DNS 排查 專文。
三、步驟一：節點品質與測速對照
先用節點測速（延遲、丟包、下載）確認底線：若延遲飄高或 UDP／TCP 品質明顯差，HTTPS 握手更容易在邊界時間內失敗。請注意測速顯示的是「到測速目標」的品質，與你實際造訪的網站出口可能不同；因此仍建議對同一目標網域在兩個節點上各測一次，確認問題是否「跟著節點走」。
若切換到另一條線路或另一個地區後握手錯誤立刻消失，可先暫時把該服務綁定到穩定節點（策略組裡的 sticky 或手動選擇），再回頭向服務商回報線路品質。若更換節點完全無感，就不要在節點層無限打轉，往下進入 SNI／嗅探／規則。
與「逾時」相鄰的日誌訊息
若同一時間窗內還有 i/o timeout、dial tcp 失敗或重試計數快速增加，多數仍偏路徑或對端無回應。此時可檢查本機是否有第二張 VPN 網卡、企業安全代理或「加速器」搶佔預設路由，造成實際出口與 Clash 狀態列不一致。
四、步驟二：SNI 與憑證線索
TLS 握手的 Client Hello 會帶 SNI（Server Name Indication），讓對端在共用 IP 上選擇正確的憑證。若規則或嗅探還原出的網域與瀏覽器實際請求不一致，或中間設備注入替代憑證，可能出現握手重試、逾時或直接 RST。在日誌裡請比對：應用程式請求的網域、嗅探還原的網域、以及節點實際連出去的 SNI 是否一致。
部分站點會在登入跳轉、CDN 邊緣或 API 子網域之間切換主機名稱；若規則只鎖了根網域而漏了 api.*、static.* 這類前綴，表面上「主站能開」，但資源請求仍可能在錯誤出口上握手逾時。此時應回到規則集補齊網域後綴，而不是只調 DNS。
若瀏覽器出現憑證錯誤或 HSTS 相關提示，但 Clash 日誌寫握手逾時，仍建議先排除本機或企業中間憑證，再回來看代理；不要把兩種不同層級的錯誤混在一起解讀。
五、步驟三：嗅探與資料來源
嗅探（sniffer） 讓核心在加密流量中還原網域名稱，供規則模組在看不到明文 Host 時仍能分流。嗅探範圍過大、或與特定 QUIC／HTTP3、ECH 行為不相容時，少數站會表現為握手極慢或逾時。建議順序：先在日誌確認該連線是否標示經過嗅探；再把嗅探縮小到需要的埠與協定；最後才做「短暫關閉嗅探」的對照實驗。
若關閉嗅探後問題消失，優先調整嗅探覆蓋範圍與排除清單，而不是關閉整段 DNS 或整包訂閱。對於同時開啟 fake-ip 的情境，嗅探與解析鏈路會互相影響，請與第六節 DNS 一併思考。
| 日誌或現象 | 優先聯想的檢查點 |
|---|---|
| 嗅探還原網域與瀏覽器不一致 | 規則資料來源是否混用 IP 規則與網域規則；是否需要限縮嗅探或補 DOMAIN-SUFFIX |
| 僅 HTTP／2 或 QUIC 站點異常 | 嗅探與 ALPN／UDP 路徑；暫時關閉嗅探或改走相容較好的節點對照 |
| 僅少數網域握手逾時 | SNI 與子網域分流；fake-ip-filter 是否漏列（見第七節與 fake-ip 專文） |
六、步驟四：規則命中與策略組
請在日誌或連線預覽中確認規則命中：該網域是否被預期規則導向代理，還是誤入 DIRECT、誤入另一個策略組，或落入兜底規則而走到不適合的節點。常見情況是：主站走代理，但靜態資源子網域仍直連，導致握手在錯誤路徑上逾時；或反過來，應直連的檢測網域被誤送代理。
調整規則時，建議以可重現的最小 URL做驗證（同一瀏覽器設定檔、清除 DNS 快取後再試），並保留一段日誌輸出給自己對照。若你使用訂閱規則集，升級後命中順序改變也可能「突然」開始握手逾時，此時應檢查自訂規則是否仍插在正確優先順位。
七、步驟五：本機 DNS、fake-ip 與日誌
當 enhanced-mode 為 fake-ip 時，應用程式先拿到占位位址，真正的解析與連線建立會與核心內部行為綁得更緊。若 fake-ip-filter 漏列特定主機名稱，或 DNS 上游在當前網路被干擾，少數站會表現為握手階段長時間無進展。此時請依 fake-ip 專文 的順序做對照實驗，而不是先更換節點。
也請檢查 nameserver、fallback 與 nameserver-policy：企業網或電信網路可能對特定 DoH 主機名稱或埠位做限制，造成間歇性解析延遲，進而讓後續 TLS 連線看起來像「握手逾時」。將 DNS 查詢改為可分域的上游，往往比全域單一上游穩定。
日誌級別與取證習慣
短期內可把日誌級別調到能看見規則命中、DNS 回應摘要、proxy 名稱的程度，完成排查後再調回，避免磁碟與隱私風險。建議為每一輪實驗記錄：時間、網域、節點名稱、是否開啟嗅探、enhanced-mode 設定與結果，之後升級用戶端或合併訂閱時才能快速回歸。
八、小結
Clash TLS handshake timeout 類日誌是強搜尋意圖下的「入口症狀」，真正的修復通常落在節點線路、SNI／憑證一致性、嗅探範圍、規則命中與 DNS／fake-ip 鏈路其中之一。依本文順序縮小範圍，可與 TUN 斷網、純 fake-ip 相容性問題區隔，並減少無效地更換訂閱或關閉整段功能。
若你希望先從可信管道取得用戶端與基礎範本，再依本文核對日誌與規則，可先閱讀 本站設定文件，並自 下載頁 取得對應平台的安裝包，建立可重現的最小環境後再逐步加回嗅探與進階規則。
相比其他同類工具，Clash 系列在規則、DNS 與多模式協同方面可觀測性較好；把日誌讀成「可對照的實驗紀錄」後，長期維護會比反覆試錯更省時間。