故障排除 預計閱讀 8 分鐘

開啟代理後瀏覽器提示 HTTPS 憑證錯誤的原因與排查步驟

解釋憑證校驗鏈與代理的關係:系統時間偏差、MITM 解密、劫持頁面與節點異常各自的報錯特徵,按現象分類給出逐項排查方法與復原手段。

開啟代理之後瀏覽器突然彈出憑證警告,是使用 Clash 或 Clash Meta(mihomo)核心用戶端時最容易讓人緊張的報錯之一。警告文案通常是「您的連線不是私密連線」「憑證無效」或「NET::ERR_CERT_AUTHORITY_INVALID」,但這些提示背後對應的原因差異很大——有的只是系統時鐘慢了幾分鐘,有的則是節點本身出了問題。本文按報錯特徵分類,拆解四種最常見的成因,並給出可以照著執行的排查步驟。

憑證校驗鏈與代理之間的關係

要理解代理為什麼會牽連到 HTTPS 憑證,先要明白瀏覽器校驗憑證的基本邏輯。每次存取 HTTPS 網站,瀏覽器都會檢查伺服器回傳的憑證是否滿足三個條件:憑證鏈能追溯到系統信任的根憑證、憑證上的網域與存取的網域一致、憑證目前處於有效期內。這三項檢查全部通過,網址列才會顯示安全鎖標誌。

Clash 系列用戶端在絕大多數使用場景下工作在傳輸層,只負責把 TCP/UDP 流量轉發到遠端節點,並不解密也不重新簽發 HTTPS 憑證,瀏覽器看到的仍然是目標網站自己的原始憑證。這意味著正常情況下,開啟代理不應該引發任何憑證變化。一旦出現憑證警告,基本可以判定問題出在以下四類原因之一:本機系統時間不準、用戶端開啟了帶有解密功能的特殊模式、鏈路中間存在頁面劫持,或者目前連線的節點本身異常。接下來逐一拆解。

系統時間偏差:最容易被忽略的成因

憑證有效期檢查依賴裝置本機時鐘,如果系統時間與真實時間相差較大(常見於長期未連網的虛擬機、被手動改動過時間的測試機,或電池耗盡後主機板時鐘重置的老舊裝置),瀏覽器會誤判憑證「尚未生效」或「已過期」,報錯資訊中通常會包含 ERR_CERT_DATE_INVALID 字樣。這類報錯的特點是:所有網站無差別報錯,不區分節點、不區分是否開啟代理,換一台裝置存取同一網站完全正常。

排查方法很簡單:開啟系統時間設定,確認是否開啟了「自動同步網路時間」,並核對時區是否正確。

注意:部分企業內網環境會封鎖時間同步伺服器,導致自動同步顯示「已開啟」但實際從未成功同步過,這種情況需要手動改成正確時間後再重新開啟自動同步。

Windows 使用者可在設定的日期和時間頁面點擊「立即同步」;macOS 使用者在系統設定的一般 - 日期與時間中確認;Linux 使用者可用以下指令快速核對系統時間與網路時間是否一致:

timedatectl status

如果輸出中 System clock synchronized 顯示為 no,說明同步服務未生效,需要檢查網路連通性或更換時間伺服器位址。

MITM 解密與規則劫持類憑證錯誤

第二類原因和系統時間無關,而是用戶端本身的功能設定。部分基於 Clash Meta(mihomo)核心的用戶端支援 MITM(中間人)解密功能,用於對特定網域的 HTTPS 流量進行腳本重寫或廣告過濾,這個功能需要用戶端產生一張自簽根憑證並安裝到系統信任清單。如果這張根憑證沒有被系統或瀏覽器正確信任,存取被納入 MITM 規則的網域時就會報出 NET::ERR_CERT_AUTHORITY_INVALID,提示憑證發行者不受信任。

這類報錯的判斷特徵是:只有設定檔裡 mitm 段列出的少數網域報錯,大多數網站存取正常;報錯頁面裡能看到憑證詳情裡發行者是用戶端自己的名稱,而不是網站原本的憑證機構。

  1. 確認是否啟用了 MITM

    在用戶端設定或規則頁面查看是否存在 MITM/腳本/重寫相關開關,如果不需要該功能,直接關閉最為省心。

  2. 補裝根憑證

    如果確實需要保留該功能,進入用戶端提供的憑證匯出入口,重新下載根憑證並按系統提示手動信任(macOS 需要在鑰匙串取用中把憑證信任等級改為「永遠信任」;Windows 需要安裝到「受信任的根憑證授權單位」)。

  3. 縮小 MITM 生效範圍

    把 mitm 規則收窄到確實需要處理的網域,避免對銀行、支付等對憑證極度敏感的站點生效,降低風險面。

另有一種更需要警惕的情況:如果沒有主動開啟任何解密或重寫功能,卻在存取陌生頁面時收到憑證警告,並且頁面內容與預期完全不同(例如存取的是購物網站卻跳轉到不相關的推廣頁),這通常意味著鏈路中出現了劫持,流量在到達目標伺服器前被中間節點篡改或重新導向。遇到這種情況應立即停止在該節點上進行任何帳號登入或支付操作,並更換訂閱或節點來源。

節點異常導致的連線與憑證報錯

第四類原因和節點本身的健康狀態有關。當代理節點已經失效、被目標伺服器封鎖,或者節點伺服端配置有誤(常見於自建節點憑證過期未續簽、TLS 參數配置錯誤)時,瀏覽器可能表現為連線逾時,也可能表現為憑證鏈不完整的報錯,具體提示因瀏覽器而異,常見的有 ERR_CERT_COMMON_NAME_INVALID(憑證網域與存取網域不符)和 ERR_SSL_PROTOCOL_ERROR。

這類報錯的特徵是:切換到其他節點後問題立刻消失,或者同一節點存取所有網站都出現類似的連線異常,而不只是特定網域。判斷步驟如下:

  • 先在用戶端裡切換到延遲正常的其他節點重試,如果問題消失,基本確認是原節點異常,建議在訂閱群組裡將其標記跳過或等待訂閱更新。
  • 如果切換任意節點都出現同樣報錯,大概率不是節點問題,應回頭檢查前兩類原因(時間、MITM)。
  • 對自建節點使用者,可用命令列工具直接檢查伺服端憑證狀態,確認憑證是否已過期或網域不符:
openssl s_client -connect example.invalid:443 -servername example.invalid

指令輸出中的 Verify return code 一項如果不是 0,說明伺服端憑證本身存在問題,需要聯繫節點提供方或重新簽發憑證,而不是用戶端設定的問題。

TUN 模式下的特殊排查思路

開啟 TUN 模式(虛擬網卡接管全局流量)後,憑證問題的排查思路和一般代理模式基本一致,但因為流量路徑經過了系統網路堆疊虛擬介面,還需要額外確認兩點:一是虛擬網卡的 DNS 是否指向了可靠的解析伺服器,DNS 污染或劫持會讓瀏覽器連線到錯誤的 IP,進而看到與目標網域不符的憑證;二是防火牆或安全軟體是否對虛擬網卡流量做了額外攔截和重新導向。可以先暫時關閉 TUN 模式,用一般系統代理模式重複存取同一網站,如果憑證警告消失,問題範圍就能縮小到 TUN 相關的 DNS 或路由設定。

建議:排查憑證問題時按「關閉 MITM → 核對系統時間 → 切換節點 → 關閉 TUN 複測」的順序逐項排除,每次只改一個變數,能最快定位到具體環節。

快速自查清單

彙總以上四類原因,遇到憑證警告時可以按下面順序快速自查,通常幾分鐘內就能定位問題範圍:

  1. 核對系統時間與時區

    確認自動同步已真正生效,時間誤差是否超過數分鐘。

  2. 檢查是否開啟了 MITM 或腳本重寫

    暫時關閉該功能後重試,確認報錯是否消失。

  3. 觀察報錯是否限定在特定網域

    全站報錯通常指向時間或系統層面問題,單一網域報錯更可能與 MITM 規則或劫持相關。

  4. 切換節點複測

    更換到其他延遲正常的節點,判斷問題是否隨節點變化。

  5. 確認訂閱與節點來源可信

    如果懷疑存在劫持,應停止敏感操作並更換訂閱來源。

大多數憑證警告都能在這五步之內找到明確原因。若排查後確認是配置本身出了問題,重新匯入一份乾淨的訂閱配置,或者恢復用戶端的預設設定,往往比逐條修改現有規則更省時間。

下載用戶端