開啟 Clash 後 HTTPS 憑證報錯的原因分析與正確處理方式
解釋瀏覽器憑證告警與代理之間的真實關係:哪些報錯源自節點劫持、時間偏差或本機攔截軟體,哪些與客戶端無關,以及各情形下的處理辦法。
憑證告警不是代理軟體本身產生的
不少人第一次遇到瀏覽器彈出「您的連線不是私密連線」或「憑證無效」時,第一反應是關掉代理客戶端。這個反應可以理解,但方向大多是錯的。HTTPS 憑證驗證發生在瀏覽器與目標網站之間,驗證的是網站憑證鏈是否由受信任的憑證頒發機構(CA)簽發、網域是否相符、有效期是否覆蓋目前時間。Clash 或 Clash Meta(mihomo)核心作為代理層,負責的是把請求轉送到哪個節點、走哪條線路,它不會也不能修改 TLS 交握過程中傳遞的憑證內容——除非中間發生了主動的流量竄改。
換句話說,憑證報錯本質上是「瀏覽器不信任這個憑證」,而信任鏈被破壞的原因通常來自三類場景:代理節點或落地網路本身存在中間人行為、本機系統時間與網路環境不同步導致憑證有效期判斷錯誤、以及某些安全軟體或企業閘道在本機層面插入了自簽根憑證用於流量檢測。理解這三類場景的差異,是判斷問題出在哪一層、該找誰處理的前提。
三類高頻場景與判斷方法
先分類,再排查,比盲目重裝客戶端或頻繁換節點更有效率。
這是最需要警惕的一類。如果瀏覽器提示憑證「由不受信任的頒發機構簽發」或「憑證與網域不符」,並且點開憑證詳細資料後發現頒發者名稱陌生、不是該網站慣用的 CA(例如銀行、大型平台的憑證通常固定來自幾家知名 CA),這表示流量在到達目標網站之前,可能被某個中間節點攔截並重新簽發了一份偽造憑證——這就是典型的 TLS 中間人劫持。這種行為可能發生在落地伺服器所在的網路業者層面,也可能是節點本身被設定為主動嗅探流量。
排查方法:同一網站,切換到另一個節點或另一個訂閱源再試一次。如果換節點後憑證恢復正常,基本可以確認問題出在原節點或其落地線路,而不是客戶端或本機設定。這種情況下應當停用該節點,不建議繼續使用,尤其是涉及登入、付款等場景。
憑證有一個明確的有效期窗口,瀏覽器會核對本機系統時間是否落在這個窗口之內。如果電腦的系統時間因為長期未連網校時、虛擬機時鐘漂移、或者手動改過日期而出現明顯偏差(哪怕只偏差幾小時,遇到接近生效或到期邊界的憑證就可能觸發告警),就會出現「憑證尚未生效」或「憑證已過期」的提示,而這與代理毫無關係,換任何節點都不會解決。
排查方法:檢查系統時間是否自動同步、時區是否正確。Windows 上可在「設定 → 時間與語言 → 日期與時間」裡開啟自動設定時間,並手動點一次「立即同步」。如果時間修正後報錯消失,說明問題一直出在本機時鐘,不必懷疑客戶端或訂閱。
部分防毒軟體、家長監護工具、企業網路管理策略會在系統或瀏覽器的憑證存放區安裝一枚自己的根憑證,用來對 HTTPS 流量做內容檢測,這個過程本質上也是一種「合法的」中間人行為,只是發生在本機而非遠端節點。如果憑證詳細資料裡頒發者顯示為某個安全軟體廠商的名稱,或者是企業內部的憑證頒發機構,那麼報錯和代理節點、和 Clash 客戶端都沒有關係,是這類軟體的憑證注入機制導致的。
排查方法:暫時退出相關安全軟體或斷開企業網路後重試同一網站。如果報錯消失,問題定位到本機軟體層,可以在該軟體設定裡關閉「HTTPS 流量掃描」一類選項,或者接受其憑證為受信任(需評估該軟體的可信度)。
TUN 模式下的憑證表現有什麼不同
TUN 模式接管全局流量後,排查思路需要做一點調整。
Clash Meta(mihomo 核心)支援的 TUN 模式會在系統網路層建立一張虛擬網卡,把裝置上幾乎所有出站流量都納入代理,而不只是瀏覽器或者手動設定了代理的應用程式。這意味著一旦某個節點存在中間人行為,受影響的範圍會從「瀏覽器存取的網站」擴大到「所有走這張虛擬網卡出去的 TLS 連線」,包括系統更新、部分客戶端軟體的介面請求等,這些場景平時不太容易被使用者直接觀察到憑證告警,因為很多程式不會像瀏覽器那樣彈出明顯的安全提示,而是直接連線失敗或靜默重試。
如果在開啟 TUN 模式後發現某些應用程式出現連線異常、交握失敗或者莫名其妙的登入狀態失效,而這些應用程式在系統代理模式(只走 HTTP/SOCKS 代理)下又表現正常,可以把 TUN 模式暫時關閉,退回到系統代理模式重新測試。這一步能幫助確認問題是否和虛擬網卡的流量接管範圍有關,而不是節點本身的憑證問題。日常使用中,建議只在確實需要全局代理(比如某些不支援系統代理設定的客戶端軟體)時才開啟 TUN 模式,減少排查面。
逐步排查的實用順序
遇到憑證報錯時,建議按下面的順序逐一排除,而不是同時改動多個設定。
- 先查看憑證詳細資料裡的頒發者名稱和有效期,判斷是「陌生 CA」還是「有效期異常」,這一步能快速把場景分成節點問題或時間問題兩條路徑。
- 如果懷疑是節點問題,切換到另一條線路重試同一網站;如果換節點後恢復正常,停用原節點,不必進一步排查客戶端設定。
- 檢查系統時間是否自動同步,尤其是長期未連網的電腦或虛擬機,手動同步一次時間後再試。
- 確認是否安裝了帶 HTTPS 掃描功能的安全軟體,暫時關閉該功能後重試,判斷是否本機憑證注入導致。
- 如果開啟了 TUN 模式,暫時切回系統代理模式測試,縮小問題出現的範圍。
- 以上都排除後,如果報錯仍然存在,再考慮是瀏覽器本身的憑證快取問題,清空瀏覽器的 HSTS 快取和憑證快取後重試。
核心 mihomo
適用 TUN 模式與系統代理模式
哪些提示可以放心忽略,哪些不能
不是所有憑證提示都意味著風險,但涉及敏感操作時不建議冒險繼續。
如果存取的是登入頁面、付款頁面或需要輸入帳戶密碼的網站,一旦出現憑證頒發者陌生、網域不符這類告警,建議先停止操作,換一個節點或斷開代理直連測試,確認網站本身憑證是正常的之後再繼續,避免帳戶資訊經過被劫持的中間節點。
如果只是存取一般的資訊類網站,且憑證告警在切換節點、同步系統時間後就消失了,說明問題已經定位並解決,不需要額外擔心;這類偶發的中間人攔截通常和某條落地線路的網路環境有關,更換節點後即可恢復正常存取。
常見疑問
為什麼只有某個網站報憑證錯誤,其他網站都正常?
這種情況更多指向目標網站自身的憑證設定問題,例如憑證即將到期、憑證鏈不完整、或者該網站的某個 CDN 節點設定有誤,和代理軟體的關係較小。可以先嘗試直連(暫時關閉代理)存取同一網站,如果直連也報錯,說明問題完全在網站一側,與 Clash 無關。
清空瀏覽器快取後憑證報錯依然存在,還能怎麼排查?
可以換一個瀏覽器測試同一網站,如果新瀏覽器也報同樣的錯誤,說明問題不在瀏覽器快取層,更可能出在節點或系統憑證存放區,回到前文按場景逐條排查即可。
關閉 TUN 模式後憑證問題消失,是否說明 TUN 模式本身有缺陷?
不是缺陷,而是接管範圍不同帶來的表現差異。TUN 模式接管了更多類型的連線,一旦某條節點線路存在問題,受影響的連線數量會更多、暴露得更明顯,問題根源仍然是節點,而不是 TUN 模式這項功能本身。