Clash 環境中的 HTTPS 憑證錯誤：常見原因與排查順序

一、先依錯誤訊息分類，再決定查哪一層

憑證錯誤是瀏覽器對 TLS 握手結果的轉述，不是 Clash 的輸出。Chrome、Edge 與 Firefox 已經把失敗環節寫進錯誤訊息，先完整抄下這句話，再對照下表決定查哪一層，比反覆開關代理有效得多。

Chrome / Edge 憑證錯誤訊息與優先排查方向
錯誤訊息	意義	優先檢查
NET::ERR_CERT_DATE_INVALID	憑證不在有效期間內	系統時間、根憑證有效期限
NET::ERR_CERT_AUTHORITY_INVALID	簽發者不在本機信任清單	中繼憑證缺失、本機攔截軟體
NET::ERR_CERT_COMMON_NAME_INVALID	憑證網域與存取的網域不一致	DNS 解析結果、hosts 對應
NET::ERR_CERT_REVOKED	憑證已被撤銷	目標網站端問題
SSL_ERROR_BAD_CERT_DOMAIN（Firefox）	網域不相符，同上	DNS 解析與 SNI

Firefox 使用內建的 NSS 憑證儲存庫，不讀取系統根憑證存放區。系統裡安裝了企業閘道或封包擷取工具的根憑證時，Chrome 能正常開啟頁面，Firefox 仍可能出現 SEC_ERROR_UNKNOWN_ISSUER。遇到「同一網域在兩個瀏覽器表現不同」，先懷疑憑證存放區，而不是代理鏈路。

命令列能更快取得細節，兩個指令就夠：

curl -vI https://example.com --max-time 8
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

curl 回傳 SSL certificate problem: unable to get local issuer certificate，代表憑證鏈不完整或本機缺少對應的根憑證；回傳 certificate has expired，則是時間或有效期限問題。這兩項資訊比瀏覽器彈窗更接近根本原因。

先用一個動作劃清界線

結束用戶端、關閉系統代理，用同一個瀏覽器存取同一個網域。關閉代理後恢復正常，問題出在代理鏈路或節點；關閉後仍持續報錯，問題在本機憑證存放區或網站本身，與 Clash 無關。這一步做完，後面就不會白費時間。

二、第一步：核對系統時間與憑證有效期限

憑證的有效期限由 notBefore 與 notAfter 兩個時間點界定，系統時間只要落在區間之外，握手就會失敗。筆電長時間休眠、雙系統來回切換、虛擬機快照還原，都會讓系統時鐘偏移幾分鐘到幾天，而使用者往往察覺不到。

Windows：設定 → 時間與語言 → 日期與時間 → 開啟「自動設定時間」，再點「立即同步」。命令列可用 w32tm /resync 強制校時，w32tm /query /status 查看目前的時間來源。
macOS：系統設定 → 一般 → 日期與時間 → 開啟「自動設定日期與時間」。在終端機執行 sudo sntp -sS time.apple.com 可手動校時。
Linux：以 timedatectl status 查看 NTP 同步狀態，sudo systemctl restart systemd-timesyncd 重新啟動校時服務。

時間正確卻仍出現 ERR_CERT_DATE_INVALID，就要檢查根憑證本身。DST Root CA X3 已於 2021-09-30 到期，當時大量舊 Android 裝置與舊版 OpenSSL 用戶端接連報錯，原因是伺服器仍在下發指向該根的交叉簽章鏈。查看本機根憑證清單的入口：Windows 執行 certlm.msc → 受信任的根憑證授權單位 → 憑證；macOS 開啟「鑰匙圈存取」→ 系統 → 憑證；Linux 查看 /etc/ssl/certs 目錄。

判斷標準很簡單：同一個網域換到時間正常的裝置就能正常存取，代表問題在本機時間或憑證存放區，與節點無關，不必再往下查。

三、第二步：檢查根憑證鏈與本機攔截軟體

中繼憑證缺失屬於伺服器端設定問題，症狀卻常常像用戶端問題。伺服器只下發網站憑證、不下發中繼憑證時，瀏覽器會嘗試用快取的中繼憑證或憑證內的 AIA 擴充欄位補齊；換了瀏覽器、清了快取之後補齊失敗，就會出現 ERR_CERT_AUTHORITY_INVALID。

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -c "BEGIN CERTIFICATE"

輸出為 1，代表伺服器只回傳網站憑證，鏈不完整；正常情況應回傳 2 到 3。這類問題只能由網站端補發中繼憑證解決，用戶端改設定沒有意義。

本機攔截類軟體是第二個高頻來源。企業閘道、附網頁防護的安全軟體、封包擷取工具（Charles、Fiddler、mitmproxy）會在本機安裝一張自簽根憑證，用它重新簽發你存取的每一個網站憑證。這張根憑證裝在系統存放區裡，Chrome 與 Edge 信任它，存取一切正常；Firefox、Java 應用程式、部分 Electron 用戶端使用各自的憑證儲存庫，就會報錯。逐項核對的位置：

Windows：certlm.msc → 受信任的根憑證授權單位 → 憑證，依「發行者」欄排序，找出非公開 CA 的項目（企業網域、安全軟體廠商名稱）。
macOS：鑰匙圈存取 → 系統 → 憑證，檢查是否有來源不明的自簽根憑證。
Firefox：設定 → 隱私權與安全性 → 憑證 → 檢視憑證 → 憑證授權單位，與系統清單逐筆比對。

不要用略過驗證的方式繞過錯誤

curl 的 --insecure、瀏覽器的 ignore-certificate-errors 啟動參數，都等於直接把偵測能力關掉。問題會從看得見的錯誤變成看不見的風險，排查線索也一併消失。

這裡需要釐清一點：Clash 與 mihomo 核心只負責 TCP/UDP 轉發與規則分流，不參與 TLS 握手，也不解密 HTTPS 流量，代理鏈路本身不會替換憑證。除非你額外掛了 MITM 類工具，否則把憑證錯誤歸咎於核心，方向從一開始就錯了。

四、第三步：代理鏈路、DNS 與分流設定

網域解析到錯誤 IP，是憑證錯誤的第三個來源。憑證的 CN 與 SAN 欄位綁定的是網域，瀏覽器拿到一張不屬於該網域的憑證，就會出現 ERR_CERT_COMMON_NAME_INVALID。常見的觸發情境有三個：DNS 被污染後回傳錯誤位址；hosts 裡手寫的對應已經過期；把 fake-ip 位址當成真實位址填進其他工具。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query

fake-ip 模式下，mihomo 會為網域分配 198.18.0.1/16 網段內的虛擬位址，這個對應只存在於用戶端內部，連線建立時會還原成網域，不參與 TLS 驗證。真正會出問題的是把 198.18.x.x 寫進 hosts 或某個不走代理的工具，網域資訊遺失之後，憑證自然對不上。

分流規則也可能間接引發憑證錯誤。某個網域被規則判定為直連，而目前網路對該網域做了劫持，回傳的就是偽造憑證。排查方式：在 Clash Verge 的「連線」頁面找到這條連線，查看命中的規則與出口節點，再把這個網域切到代理節點重試。切換後恢復正常，代表問題在直連出口，不在憑證。

系統代理未涵蓋的情況要單獨區分。部分應用程式不讀取系統代理設定，流量走直連，被阻斷時拋出的是連線重設或逾時，不是憑證錯誤，把這兩類錯誤混在一起查只會繞遠路。確認連接埠一致：mixed-port 常見為 7890，Clash Verge 系列預設 7897，瀏覽器擴充功能與系統代理必須指向同一個連接埠。

TUN 模式在網卡層接管流量，不依賴應用程式是否支援代理，但它同樣不解密 TLS，憑證驗證仍在瀏覽器端完成。TUN 模式下出現憑證錯誤，優先檢查 DNS 與分流規則，而不是反覆開關 TUN 本身。

五、依序執行的排查清單

記錄完整的錯誤訊息、網域與發生時間，確認是持續性錯誤還是偶發。
結束用戶端並關閉系統代理，用同一個瀏覽器重試，判斷問題是否與代理有關。
校正系統時間，重新啟動瀏覽器後再存取一次。
執行 openssl s_client -connect 網域:443 -servername 網域 -showcerts，確認憑證鏈完整、有效期限涵蓋目前時間。
檢查系統根憑證清單，排除企業閘道或安全軟體安裝的攔截憑證；Firefox 需單獨核對一次。
在用戶端「連線」頁面確認該網域命中的規則、出口節點與 DNS 解析結果。
把該網域切到另一個節點或另一個策略組，觀察錯誤訊息是否改變。
換一個網路（例如手機熱點）交叉驗證，區分本機網路問題與節點端問題。

清單裡第 2 步和第 4 步的性價比最高：一個負責劃清責任界線，一個直接給出憑證鏈的實際狀態。多數案例走到這裡就能定位。

六、幾種常見的誤判

換節點就能解決憑證錯誤。節點只轉發位元組流，憑證由目標網站提供；換節點後仍出現相同錯誤，基本上可以排除節點。
TUN 模式會改變憑證驗證。不會，TUN 改變的是流量接管方式，TLS 驗證依舊在瀏覽器端完成。
更新訂閱能修復憑證錯誤。訂閱內容只影響節點清單與規則，不會寫入系統憑證存放區。
清除瀏覽器快取就能解決。只有在缺少中繼憑證、且先前依賴快取補齊的情況下偶爾有效，並非穩定解法。
換個用戶端就好了。主流用戶端共用 mihomo 核心與同一套系統代理設定，更換用戶端並不會改變 TLS 驗證路徑。

把順序固定下來：錯誤訊息 → 系統時間 → 根憑證鏈 → 代理與 DNS → 節點。前兩步能涵蓋大部分案例，把核心當成頭號嫌疑犯，通常只是多花時間。