Mihomo OpenVPN tls-auth 握手超時怎麼修？

Mihomo issue #2992 記錄的是一個很窄的組合：OpenVPN 出站使用 tls-auth，同時 auth 設定為 SHA512。

設定可以載入，DNS 解析和 PROCESS-NAME 規則也能命中，但控制通道在 4 次重傳後超時，用戶端日誌出現 make OpenVPN handshake: read hard reset response after 4 retransmits: context deadline exceeded。

報告環境是 Windows 11 與 Mihomo v1.19.29。HTTP 請求可返回 502，HTTPS 在代理接受 CONNECT 後沒有繼續收到 TLS 資料；同一 Mihomo 環境中，不使用 tls-auth 的另一條 OpenVPN 設定可以工作。

這組對照支援繼續檢查 tls-auth 與 auth，而不是先把問題歸給 DNS、規則或整個代理入口。

PR #3189 確認舊實作把 tls-auth 控制包的 HMAC 固定為 SHA1。伺服器端若按 SHA256、SHA384 或 SHA512 等其他 auth 摘要驗證，就會因標籤長度不一致丟棄第一個控制包。

有伺服器端日誌權限時，可能看到 TLS Error: cannot locate HMAC in incoming packet。使用 SHA1 的伺服器端不受這一特定缺陷影響，普通 TLS、憑證、連接埠或網路錯誤也不在本文結論內。

先複製一份只供檢查的設定，不要直接改正在執行的原檔案。確認代理項確實是 type: openvpn，並記錄 auth、是否存在 tls-auth、key-direction、proto、連接埠和伺服器網域。

官方文件說明 tls-auth 與 tls-crypt、tls-crypt-v2 互斥，使用 tls-auth 時 key-direction 支援 0 或 1；auth 支援 MD5、SHA1、SHA256、SHA384 和 SHA512，預設值是 SHA256。

不要把 tls-auth 靜態金鑰、username、password、用戶端私鑰、憑證完整內容或實際伺服器位址貼到公開工單。公開證據只保留欄位名、摘要演算法、脫敏位址、錯誤時間和首條相關日誌；原始設定應儲存在私有位置。

不要為了測試而刪除 tls-auth、猜測 key-direction 或把伺服器端 auth 降為 SHA1。那會改變認證邊界，無法證明升級是否修復了原問題，還可能讓用戶端設定與伺服器端不一致。

握手錯誤只說明 OpenVPN 控制通道沒有完成，不能單獨證明原因。先確認伺服器網域已經解析、目標 UDP 或 TCP 連接埠可達、請求確實命中這條 OpenVPN 出站，並保留一條已知可用出站作對照。

如果日誌在解析、撥號、憑證讀取或設定驗證階段已經出現更早錯誤，就先處理那一條。只有 DNS 和規則都成功，連線進入 OpenVPN 握手，再出現 4 次 hard reset 重傳超時，才符合 issue #2992 的診斷順序。

同一個伺服器、同一份脫敏設定和同一個 HTTPS 目標應貫穿升級前後。若測試期間同時更換節點、協議、連接埠、憑證和 auth，即使連線恢復也無法把結果歸因到 v1.19.31。

v1.19.31 是包含 PR #3189 修復的穩定版。升級前先記錄目前二進位的完整版本輸出、作業系統、CPU 架構、由哪個用戶端或服務管理器托管，以及目前核心檔案的實際位置。

完整備份設定、憑證引用檔案和舊核心二進位，但讓備份保持私有。使用圖形用戶端時，還要記錄它的核心更新入口與自動更新策略；應用版本和正在執行的 Mihomo 版本並不總是同一個值。

遠端裝置、路由器或無人值守主機必須先確認有不經過該 OpenVPN 出站的管理路徑。沒有備用入口時，不應在唯一連線視窗直接替換核心。

Mihomo v1.19.31 於 2026 年 9 月 14 日發布，Release 明確包含提交 6d179a1c：讓 OpenVPN tls-auth 的 HMAC 摘要跟隨 auth，而不是固定使用 SHA1。

最低目標是實際執行 v1.19.31；若使用後續穩定版，應確認其包含 6d179a1c 修復。只更新圖形用戶端介面或訂閱不能替代核心升級。

直接執行 Mihomo 時，從 MetaCubeX/mihomo 官方 v1.19.31 Release 選擇與作業系統、CPU 架構和建置變體一致的資產，並核對該資產在 Release 頁面列出的 SHA256。

由 Clash Verge Rev、OpenClash 或其他前端管理核心時，使用該專案已有的官方核心更新入口，更新後再次讀取實際執行版本。

停止舊核心後再替換檔案，保留原權限、啟動參數和服務設定。不要混用不同版本的單個庫檔案，也不要從搜尋廣告、雲端硬碟或不明鏡像取得同名核心。

升級後的關鍵不是介面顯示成功，而是同一伺服器、同一 Profile、同一 auth 和同一 tls-auth 能完成控制通道握手。先固定策略群組選擇，讓一條請求明確命中該 OpenVPN 出站，再存取升級前使用的同一 HTTPS 目標。

檢查日誌不再出現 read hard reset response after 4 retransmits，並確認請求得到實際 HTTPS 回應。還應驗證一條普通出站，確保核心升級沒有破壞其他路徑；需要 UDP 時再單獨做一次實際 UDP 業務驗證，不能用延遲數字代替。

不要把關閉 tls-auth、改為 SHA1 或換到另一台伺服器後的成功算作修復驗證。那些變化只能證明另一條設定可用，不能證明 v1.19.31 已修復原組合。

如果實際執行版本已經是 v1.19.31 或確認包含該修復的後續穩定版，卻仍出現握手失敗，不要繼續把所有錯誤歸給舊版固定 SHA1。先比較錯誤是否還是同一條、請求是否仍命中同一出站，以及伺服器端是否同時記錄 HMAC、憑證、金鑰方向或認證失敗。

重新核對 ca、cert、key、tls-auth、key-direction、auth、proto、連接埠和系統時間；確認 tls-auth 沒有和 tls-crypt 或 tls-crypt-v2 混用。若伺服器端設定或金鑰近期變化，應以伺服器端目前設定為準，不從舊用戶端檔案猜測。

只有原錯誤消失、換成另一條明確錯誤時，才按新的首條錯誤繼續檢查。反覆修改摘要、金鑰方向和憑證會破壞版本對照，也可能觸發伺服器端的失敗保護。

如果 v1.19.31 在目前裝置上引入其他啟動或相容問題，可以停止新核心，恢復升級前儲存的完整舊二進位和原設定，再透過同一托管入口啟動。還原後先確認版本和設定載入，再驗證普通出站與裝置管理入口。

舊核心會重新帶回本文描述的 tls-auth 非 SHA1 握手問題，所以它不是這條 OpenVPN Profile 的長期修復。業務需要立即恢復時，應切換到已經驗證可用的其他節點或協議，或暫時停用該 Profile；不要刪除 tls-auth、猜測 key-direction，或為了相容舊用戶端降低伺服器端 auth。

後續重新升級時，繼續使用同一脫敏基線、官方資產和實際請求。向上游回報時應包含系統、架構、完整版本輸出、欄位組合、升級前後首條相關日誌和最小復現步驟，但絕不能包含靜態金鑰、帳號、私鑰或實際服務位址。