開代理後瀏覽器提示 HTTPS 憑證錯誤?常見原因與 Clash 相關排查步驟

憑證錯誤提示的幾種類型與含義

瀏覽器給出的憑證錯誤訊息看起來種類繁多,但實際歸納起來只有幾個方向:憑證不受信任(NET::ERR_CERT_AUTHORITY_INVALID)、憑證過期或尚未生效(NET::ERR_CERT_DATE_INVALID)、網域不符(NET::ERR_CERT_COMMON_NAME_INVALID),以及連線被劫持類的通用警告。這些提示本身是瀏覽器在做該做的事——TLS 交握階段驗證伺服器憑證鏈是否可信、是否在有效期內、是否與存取網域一致。開代理前不出現、開代理後頻繁出現,基本可以確認問題出在本機的時間、DNS 解析路徑或憑證信任鏈上,而不是目標網站本身出了故障。

排查這類問題時先記錄清楚:是所有網站都報錯,還是只有部分網站;是所有節點都報錯,還是切換節點後消失;是關閉代理立刻恢復,還是代理關閉後依舊存在。這三組對照能把問題範圍迅速縮小到系統層、代理層還是本機軟體層。

系統時間偏差導致的憑證錯誤

TLS 憑證驗證會檢查目前系統時間是否落在憑證的有效期區間內。如果裝置時間與真實時間偏差超過幾分鐘,憑證驗證就可能判定為「尚未生效」或「已過期」,即便憑證本身完全正常。這種情況在虛擬機、雙系統、長期休眠後重新開機的裝置上尤其常見,和是否使用代理沒有直接關係,但往往在切換節點、重啟客戶端之後才被使用者注意到,容易被誤判為節點問題。

1. 檢查系統時間是否自動同步

   Windows 在「設定 → 時間與語言」裡確認「自動設定時間」已開啟;macOS 在「系統設定 → 一般 → 日期與時間」裡確認已勾選自動設定。

2. 手動核對時區

   時間同步開啟但時區選錯,同樣會導致憑證有效期判斷偏差,尤其是剛更換過所在地區設定的裝置。

3. 強制重新同步一次

   關閉自動同步再重新開啟,或在系統時間服務裡手動觸發一次同步,讓本機時間立即對齊網路時間伺服器。

節點劫持與中間人風險

如果只有切換到某個特定節點才出現憑證錯誤,而更換到其他節點立即恢復正常,需要認真對待這種訊號。正常的代理轉發不會介入 TLS 交握過程,客戶端與目標網站之間建立的是端對端加密連線,中間的代理伺服器只負責轉發加密後的資料封包,理論上沒有能力也沒有必要查看或替換憑證。如果某個節點的出口在做流量層面的中間人干預——比如插入自簽憑證來解密流量——瀏覽器會立刻報出憑證不受信任的錯誤,因為呈現的憑證簽發者根本不在系統信任的根憑證清單裡。

這種情況多出現在來源不明、價格異常低廉的免費節點或未經審核的第三方分享節點上,正規機場的可信節點極少出現此類問題。排查方法很直接:

• 記錄報錯時使用的節點名稱,切換到同一訂閱下的其他節點觀察是否重現。
• 查看錯誤詳情裡顯示的憑證頒發者(瀏覽器網址列鎖形圖示 → 憑證資訊),如果頒發者是陌生的自建 CA 而不是網站原本使用的知名憑證頒發機構,基本可以確認是節點層面的中間人行為。
• 確認問題節點後,在客戶端裡將其移出選用群組,更換來源可信的訂閱。

TUN 模式下的 DNS 污染回退問題

TUN 模式接管系統全部網路流量,包括 DNS 查詢請求。Clash Meta(mihomo)核心在 TUN 模式下通常會啟用自身的 DNS 解析邏輯,優先走加密 DNS(如 DoH/DoT)並結合 fake-ip 或 redir-host 策略避免被本地網路的 DNS 劫持污染。但如果設定裡的 DNS 設定存在遺漏——比如沒有正確啟用 enhanced-mode,或者 nameserver 清單裡混入了容易被污染的一般 DNS 伺服器——系統在 TUN 模式解析失敗時可能悄悄回退到本機預設 DNS,而本機預設 DNS 如果處於被污染的網路環境下,解析出的 IP 會指向錯誤的伺服器,該伺服器自然拿不出目標網域相符的合法憑證,瀏覽器就會報出網域不符或憑證不可信的錯誤。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://doh.example.net/dns-query
    - https://1.1.1.1/dns-query
  fallback:
    - https://dns.google/dns-query
tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53

核對設定時重點看三處:enhanced-mode 是否設為 fake-ip(或 redir-host,視使用情境而定)、nameserver 是否全部為加密 DNS 而非明文 udp:// 位址、dns-hijack 是否覆蓋了 53 埠以強制所有 DNS 請求走客戶端接管的解析邏輯。任意一處缺失都可能導致解析在特定網路環境下回退到不可信的路徑。

本機封包截取軟體殘留憑證

另一類容易被忽略的來源,是本機曾經安裝過的偵錯代理或封包截取工具。這類工具為了解密 HTTPS 流量以供分析,通常會產生一張自簽根憑證並要求使用者手動安裝到系統信任清單裡,這樣它才能在中間「合法地」充當一次中間人。如果卸載工具時沒有同步刪除該憑證,或者憑證已過期但仍留在信任清單中,後續使用代理時某些流量路徑恰好經過殘留的代理設定,就會觸發憑證警告,表現和真正的中間人劫持在瀏覽器提示上幾乎一樣,容易誤判為節點問題。

1. 檢查系統憑證信任清單

   Windows 用「憑證管理員」(certmgr.msc)查看「受信任的根憑證授權單位」;macOS 用「鑰匙圈存取」查看登入與系統憑證,尋找帶有偵錯工具名稱的自簽項目。

2. 刪除或停用可疑憑證

   確認某筆憑證來自已不再使用的偵錯工具後,將其從信任清單中移除或標記為不信任。

3. 檢查系統層級代理設定是否殘留

   部分封包截取工具會在系統網路設定裡寫入固定的代理位址與埠號,卸載工具後需要手動清空這些殘留設定,避免與 Clash 客戶端的代理設定互相衝突。

排查步驟優先順序清單

遇到憑證報錯時,按下面的順序逐條排查,優先做成本最低、最容易排除的項目:

1. 確認系統時間與時區

   這是最快能排除的一類,幾十秒內就能確認或排除。

2. 關閉代理複測

   完全退出客戶端後重新存取同一網站,判斷問題是否與代理相關;若關閉後依然報錯,說明問題在系統憑證信任清單或本機 hosts 設定裡,與 Clash 無關。

3. 切換節點複測

   若關閉代理後恢復正常,再逐個切換節點觀察,定位是否為單一節點的劫持行為。

4. 核對 TUN 模式 DNS 設定

   確認 enhanced-mode、nameserver、dns-hijack 三項設定齊全且使用加密 DNS。

5. 檢查系統憑證信任清單裡的可疑項目

   重點排查曾安裝過的偵錯工具、封包截取軟體留下的自簽根憑證。

6. 更新客戶端與規則訂閱

   確保 Clash Meta(mihomo)核心版本為較新版本,舊版本在 TLS 函式庫或 DNS 處理上的已知問題可能已在後續更新中修復。