開啟 Clash 後瀏覽器提示 HTTPS 憑證錯誤的原因分析與解決方法

代理為什麼會牽扯到憑證驗證

HTTPS 連線的憑證驗證發生在 TLS 交握階段,由客戶端(瀏覽器或系統)完成,與是否使用代理本身沒有直接因果關係——代理只負責把資料封包送到目標伺服器,憑證是伺服器回傳、客戶端驗證的東西。多數情況下,Clash 或 Mihomo 核心工作在純轉發模式:它把 TCP/UDP 流量按規則分流到對應節點,資料在傳輸層原樣透傳,不拆解、不重新簽發憑證,瀏覽器看到的仍然是網站伺服器本身的憑證鏈。這種模式下開啟代理導致的憑證報錯,幾乎全部是「代理改變了連線路徑,暴露出原本被掩蓋的其他問題」,而不是代理本身偽造了憑證。

但也存在例外:一部分客戶端提供「HTTP 抓包/MITM 解密」功能,用於查看請求詳情或做規則除錯,這類功能會啟用一張本機產生的根憑證,代理程序用它對被解密的連線重新簽發憑證,再把內容轉發出去。如果這個開關處於開啟狀態,而根憑證沒有被系統或瀏覽器信任,憑證鏈就會在驗證階段直接失敗,錯誤訊息通常包含「不受信任的頒發者」「憑證由未知機構簽發」一類描述。這是唯一一種由代理軟體自身憑證機制直接導致報錯的情形,區分它是排查的第一步。

排查前先確認的三件事

在深入具體情境前,先按順序核對以下三點,能快速縮小問題範圍。

系統時間與時區是否準確
TLS 憑證驗證會比對目前系統時間與憑證的有效期間,系統時間早於憑證生效時間或晚於過期時間,都會直接判定為憑證無效,與代理無關。開啟自動同步網路時間,或手動核對時間與時區,是最容易被忽略卻最常見的原因之一。
代理是系統層級還是僅瀏覽器層級
系統代理模式下,所有應用程式的流量都會經過代理規則判斷;僅瀏覽器擴充功能代理時,其他應用程式不受影響。如果只在瀏覽器裡出現憑證報錯,而系統其他程式存取同一站台正常,問題範圍應縮小到瀏覽器擴充功能或瀏覽器自身的代理設定,而不是 Clash 客戶端。
是否剛剛切換過節點或訂閱
剛匯入新訂閱或切換到新節點後出現憑證報錯,要考慮該節點伺服端是否存在劫持、竄改憑證或強制跳轉的行為,這類問題通常只出現在特定節點上,更換到其他節點測試同一網站即可確認。

常見情境逐一分析

情境一:公共網路的門戶劫持(Captive Portal)

機場、飯店、校園等場所的公共 Wi-Fi 常見「先登入再上網」的門戶頁機制,網路層會在你完成驗證前攔截所有 HTTPS 請求並回傳自己的登入頁憑證,與目標網站的真實憑證完全不匹配,瀏覽器判定憑證不受信任。這種情況下,先斷開代理,完成門戶頁登入流程,確認可以正常存取任意網站後再重新開啟代理,報錯通常隨之消失。如果開啟代理後完全無法彈出登入頁,可以先暫時關閉代理完成驗證,再打開代理正常使用。

情境二:MITM 解密開關被意外開啟

如前文所述,若客戶端的抓包/重寫功能被啟用,而對應根憑證未安裝到系統信任清單或瀏覽器信任清單中,幾乎每個 HTTPS 站台都會報錯,現象是「批量性」的,而不是針對某一兩個網站。處理方式是在客戶端設定裡找到抓包或重寫相關選項並關閉,或者按客戶端說明安裝並信任對應根憑證。日常僅用於分流代理而不需要查看請求內容的情境,保持該功能關閉是更省心的做法。

情境三:憑證鏈不完整

部分自建代理節點或使用了自簽憑證的服務在中間憑證設定上有缺失,瀏覽器能驗證到葉憑證但補不齊到根憑證的完整鏈條,錯誤訊息常見「未知頒發者」或「憑證鏈不完整」。這類問題出在伺服端設定,與本機 Clash 客戶端設定無關,能做的排查是換用其他節點存取同一網站進行對比,如果只有某個特定節點觸發,說明是該節點自身的憑證設定問題,建議切換到其他線路或聯繫訂閱提供方。

情境四:DNS 污染或劫持導致連到錯誤的伺服器

如果網域解析被劫持到一個偽冒位址,該位址回傳的憑證自然與目標網站的真實憑證不匹配。判斷方法是在開啟代理、且規則設定為「遠端解析」(即由代理伺服器完成 DNS 查詢而非本機 DNS)的前提下重新存取,如果報錯消失,基本可以確認是本機網路的 DNS 環境存在問題;如果依然報錯,再回到情境一到三繼續排查。

注意 NOTICE 瀏覽器提示的憑證錯誤頁通常會附帶「繼續存取(不安全)」選項,但在未確認原因前不建議點擊繼續,尤其是涉及登入、支付類站台,該選項應僅用於排查測試,不應作為日常存取方式。

分平台的具體處理步驟

確認問題類型後,可以按以下平台步驟逐項操作。

Windows / macOS

核對系統時間
打開系統設定中的日期和時間選項,確認「自動設定時間」已開啟,時區與實際所在地一致。
關閉客戶端的解密相關功能
在 Clash 或 Mihomo 客戶端的連線/腳本設定中查找抓包、重寫或 MITM 相關開關,確認處於關閉狀態,除非確實需要偵錯請求內容。
切換節點做對比測試
在同一瀏覽器標籤下切換到另一個可用節點,重新存取出錯的網站,判斷問題是否隨節點變化。

Android / iOS

檢查系統代理與 VPN 模式的衝突
行動裝置客戶端多透過本機 VPN 介面接管流量,若同時安裝了其他代理類應用程式,兩者可能互相干擾導致連線異常,建議排查時只保留一個代理應用程式處於執行狀態。
確認自動時間同步已開啟
行動裝置的系統設定中同樣存在「自動設定日期和時間」選項,關閉後容易出現時間漂移。
重新啟動應用程式或重新匯入訂閱
如果切換節點仍無效,嘗試重新啟動客戶端應用程式,或刪除後重新匯入訂閱連結,排除本機快取設定異常的可能。

TUN 模式下的憑證報錯要單獨看待

TUN 模式在系統網路層建立一個虛擬網卡,接管全域流量(包括繞過應用層代理設定的程式),這種接管方式本身不涉及憑證重簽發,原理上不會引入額外的憑證問題。但因為 TUN 模式下流量路徑變化更徹底,原本被系統代理規則忽略的應用程式(例如某些背景服務、系統元件的連網請求)也會被納入代理鏈路,如果這些請求命中了本節點範圍內設定不完整的分流規則,同樣可能暴露出前文提到的憑證鏈或 DNS 解析問題。排查方法與前文一致,可以先暫時關閉 TUN 模式,恢復到系統代理模式測試同一站台,藉此判斷報錯是否與流量接管範圍擴大有關。

什麼情況下問題出在規則設定而非憑證本身

有一類現象容易被誤判為憑證錯誤:某個網站被規則錯誤地分流到了不適合存取該站台的節點,對方伺服器回傳了非預期的回應內容(例如電信業者的攔截頁面),瀏覽器在解析這個非預期回應時同樣會給出連線不安全的提示,但根源是路由規則,不是憑證驗證邏輯本身出了問題。這種情況下,檢查訂閱或本機設定檔中該網域命中的策略群組,確認對應節點是否可用、策略群組測速結果是否正常,往往比糾結憑證細節更快定位問題。規則設定的語法與欄位說明,可參考完整文件中的規則段落說明。

現象	可能原因	處理方向
幾乎所有網站同時報錯	系統時間偏差 / MITM 解密開關開啟	校準時間、關閉抓包功能
僅公共 Wi-Fi 下出現	門戶頁劫持	先完成門戶驗證再開代理
僅特定網站或特定節點出現	節點憑證鏈設定缺失	切換節點對比測試
切換遠端解析後消失	本機 DNS 被污染或劫持	啟用代理端 DNS 解析
關閉 TUN 後消失	流量接管範圍內的規則命中問題	檢查該網域對應的分流規則

整體上,HTTPS 憑證報錯的排查思路應該是先做減法:關閉代理確認問題是否消失,關閉 MITM 相關功能確認是否與解密有關,切換節點確認是否與特定線路有關,切換 DNS 解析方式確認是否與本機網路污染有關。每一步都能排除一類原因,通常在四步之內就能鎖定問題所在,不需要逐條猜測。