開啟 Clash 後瀏覽器出現憑證錯誤：NET::ERR_CERT 原因與解決方法

先記下憑證錯誤，不要點選繼續前往

Chrome 或 Edge 出現「你的連線不是私人連線」時，先記下頁面底部的完整錯誤代碼。NET::ERR_CERT_DATE_INVALID 和 NET::ERR_CERT_AUTHORITY_INVALID 的檢查方向不同，不能一概當成「節點故障」處理。如果網址是付款、電子郵件、企業登入或管理後台，請立即停止輸入密碼。

一般的 Clash、Clash Meta（mihomo）代理轉送不會替目標網站重新簽發憑證。瀏覽器透過 HTTP 代理建立 CONNECT 通道，或由 TUN 接管流量後，HTTPS 通常仍是在瀏覽器與目標網站之間建立。啟用代理不需要先安裝來源不明的根憑證。

記下以下四項資訊

網址與錯誤代碼：只記錄網域和必要路徑；分享前移除登入權杖、查詢參數及個人資料。
影響範圍：只有一個網站無法連線，還是多個互不相關的 HTTPS 網站都出現問題。
連線路徑：是否啟用系統代理或 TUN，以及目前使用的策略群組和實際節點。
憑證資訊：透過錯誤頁面或瀏覽器的憑證檢視功能，記下簽發者、有效期限及主體替代名稱（SAN）。入口名稱可能隨瀏覽器版本而異。

依 NET::ERR_CERT 錯誤代碼縮小問題範圍

錯誤代碼	主要含義	優先檢查項目
`NET::ERR_CERT_DATE_INVALID`	憑證尚未生效或已過期，也可能是裝置時間錯誤。	系統日期、時間同步狀態，以及憑證的起訖日期。
`NET::ERR_CERT_AUTHORITY_INVALID`	瀏覽器無法建立通往受信任根憑證的驗證鏈。	自簽憑證、缺少中繼憑證、HTTPS 檢查軟體及根憑證政策。
`NET::ERR_CERT_COMMON_NAME_INVALID`	連線的主機名稱與憑證涵蓋的名稱不符。	SAN、錯誤的 DNS 解析、入口網站重新導向，以及網站伺服器設定。
`NET::ERR_CERT_REVOKED`	憑證被判定為已撤銷。	網站憑證狀態及本機安全軟體；不應透過降低驗證標準繼續瀏覽。

錯誤名稱中的 COMMON_NAME 不代表只檢查憑證的 CN 欄位。現代瀏覽器主要依據 SAN 驗證主機名稱。例如造訪 www.example.com，卻收到只涵蓋 portal.example.net 的憑證，主機名稱驗證就會失敗。

ERR_SSL_PROTOCOL_ERROR、ERR_TUNNEL_CONNECTION_FAILED 和上述憑證錯誤並非同一類問題。前者可能發生在 TLS 協商階段，後者可能表示代理通道尚未建立；此時未必已取得目標網站的憑證，應先查看用戶端的連線記錄與日誌。

日期錯誤：先校準系統時間，再檢查網站憑證期限

如果許多網站同時出現 NET::ERR_CERT_DATE_INVALID，請先查看工作列的時間。裝置長期關機、電池異常或手動調整過年份，都可能讓有效憑證看起來已過期或尚未生效。單純時區顯示不同不一定會造成錯誤，關鍵是系統的實際時間是否準確。

Windows 11：開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」，確認時區，再到「其他設定」中點選「立即同步」。
macOS：開啟「系統設定」→「一般」→「日期與時間」，啟用「自動設定日期與時間」。
Android：在系統設定中搜尋「日期與時間」，啟用自動設定時間；各廠牌的選單位置可能不同。
校準後，完全關閉瀏覽器再重新開啟，並再次造訪同一網址。若裝置重新啟動後時間又跑掉，請進一步檢查系統同步服務或硬體時鐘。

如果系統時間正確，且只有某個網站無法連線，請查看該網站憑證的有效期限。憑證確實過期時，應由網站維護人員更新；更換節點或許剛好連到另一台伺服器，但無法替網站修復憑證。記下故障網域、時間及憑證有效期限，再回報網站維護人員會更有效。

簽發者異常：檢查 MITM、封包擷取工具及安全軟體殘留

若多個不相關網站的憑證都顯示同一個陌生簽發者，請檢查是否有軟體正在解密 HTTPS 流量。MITM 是一種中間人流量檢查方式；除錯代理、企業閘道及部分安全軟體可以使用本機受信任憑證重新簽發網站憑證。這與 Clash 的一般流量轉送不同。

先停用重新簽發功能，再確認憑證來源

結束曾用於封包擷取的 Fiddler、Charles、mitmproxy 等工具，並在相關工具中關閉 HTTPS 解密或 SSL Proxying。只關閉視窗不代表背景處理程序一定已結束。
檢查安全軟體的 HTTPS 掃描或加密連線檢查功能。個人裝置可暫時停用該功能進行比對，測試後依產品文件恢復設定；受管理的裝置應先聯絡管理員。
在 Windows 按 Win + R，輸入 certmgr.msc，查看目前使用者的「受信任的根憑證授權單位」→「憑證」。電腦層級的憑證可用 certlm.msc 查看。
在 macOS 開啟「鑰匙圈存取」，分別檢查「登入」和「系統」鑰匙圈中的憑證及信任設定。

根憑證仍存在，不代表目前一定有重新簽發憑證的情況；連線時還需要有相應的代理或檢查服務參與。反之，重新簽發服務仍在運作，但信任憑證已刪除，也會出現簽發者不受信任的錯誤。因此應一併檢查代理入口、執行中的程序及憑證，不要只在憑證管理員中反覆新增或刪除憑證。

名稱不符：區分 DNS 異常、入口網站與網站設定問題

NET::ERR_CERT_COMMON_NAME_INVALID 常見於連線被導向錯誤的伺服器，但不能只憑這個錯誤就認定 DNS 遭污染或節點遭劫持。網站 CDN 設定錯誤、公共 Wi-Fi 登入入口網站，或手動輸入 IP 位址，也可能造成相同結果。

先檢查本機覆寫設定，再確認實際解析路徑

確認網址列中的網域拼寫正確，且沒有把 HTTPS 網域改成裸 IP 位址。憑證通常涵蓋網域，不一定涵蓋伺服器 IP。
檢查 hosts 檔案是否留有測試用對應設定。Windows 路徑為 C:\Windows\System32\drivers\etc\hosts，macOS 和 Linux 為 /etc/hosts。修改前先備份檔案。
在機場、飯店等網路環境中，請先依系統的網路登入提示完成入口網站驗證。不要在偽裝成目標 HTTPS 網站的憑證錯誤頁面輸入入口網站密碼。
瀏覽器啟用安全 DNS 時，解析路徑可能與系統不同。可在 Chrome 的「設定」→「隱私權和安全性」→「安全性」中查看「使用安全 DNS」，記下原設定後再暫時調整以進行比對。

在 Windows 可執行以下命令，查看系統預設解析器傳回的結果；修正 hosts 或系統 DNS 後，也可清除系統快取。以下網域僅供命令範例使用，排查時請換成實際出錯的網域。

nslookup example.com
ipconfig /flushdns

nslookup 無法單獨證明瀏覽器實際使用了哪個 IP 位址。啟用 mihomo 的 TUN、DNS 劫持或 fake-ip 後，查詢路徑可能會被接管；fake-ip 模式傳回 198.18.0.0/16 範圍內的合成位址，也不一定代表異常。應搭配目前設定中的 dns、enhanced-mode、fake-ip-range 及用戶端連線記錄一併判斷。

不要同時修改 DNS、更換節點又清除快取。每次只調整一項，關閉舊連線後再試。CDN 在不同網路中傳回不同 IP 很常見，IP 不同本身不能作為遭污染的證據；此處真正需要確認的是憑證是否涵蓋要求的網域。

比對直連與代理節點，定位代理連線問題

如果問題只在啟用代理後出現，可以進行一次有控制的比對。選擇不需要登入的公開頁面，記錄同一網域在直連、節點 A 和節點 B 下的結果。使用自動選擇策略群組時，實際節點可能會切換，因此應在連線記錄中確認最終出口，不要只記下策略群組名稱。

保存目前狀態：記下目前設定、規則模式、系統代理及 TUN 的啟用狀態。先暫停其他 VPN 和封包擷取代理，避免連線路徑疊加。
直連測試：關閉 Clash 的系統代理與 TUN；確認系統沒有殘留手動代理或自動設定指令碼，再結束用戶端並重新開啟瀏覽器。只結束用戶端不一定會自動清除所有代理設定。
代理測試：恢復原本設定，使用固定節點造訪同一網域，並在連線記錄中確認套用的規則與出口。
一次只更換一項變數：保持規則和 DNS 設定不變，只改用另一個可信任的節點，再比較憑證名稱、簽發者及錯誤代碼。

需要用命令列比對時，明確指定本機連接埠

以下以用戶端顯示 HTTP 或混合連接埠為 7897 的 Windows 環境為例；實際連接埠請以用戶端顯示為準。使用明確代理進行測試前，請先關閉 TUN，避免所謂的「直連」仍被透明接管。macOS、Linux 通常只要將命令名稱改為 curl 即可。

curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7897 https://example.com/

第一條命令不使用明確代理，第二條則指定本機 HTTP 代理。不要加上 -k 或 --insecure，否則會略過這次要檢查的憑證驗證。-I 會送出 HEAD 請求，部分網站回傳 405 不代表憑證錯誤；若已收到 HTTP 回應，通常表示這次 TLS 驗證已通過。

curl 和瀏覽器使用的信任庫及代理路徑可能不同，因此命令執行成功不能取代瀏覽器測試。分享 -v 輸出前，請移除驗證標頭、Cookie、內網位址等敏感資訊。也不要為了測試而把訂閱連結貼進命令列或公開檢測網站。

依比對結果決定下一步

直連正常，只有一個節點失敗：停用該節點，並回報出錯網域、時間、憑證簽發者及錯誤代碼。若多個不相關網站反覆收到相同異常憑證，應留意連線是否遭重新導向或劫持，但仍須依據證據確認。
所有節點和直連都失敗：優先重新檢查系統時間、本機 HTTPS 檢查、根憑證及目前網路，不要一直更換訂閱。
只有一個網站在多種網路環境下都失敗：較可能需要由網站端處理憑證鏈、到期續期或 CDN 綁定問題。
瀏覽器失敗，命令列成功：檢查瀏覽器擴充功能、政策、安全 DNS 及個別憑證設定；Firefox 的信任設定也可能與 Chromium 瀏覽器不同。

恢復設定並重新測試：不要在設定中保留略過驗證

設定中的 skip-cert-verify: true 不是修復瀏覽器憑證錯誤的通用方法。對使用 TLS 的代理協定而言，此欄位通常控制核心是否驗證代理伺服器憑證，而不是讓瀏覽器信任目標網頁。修改它可能削弱節點連線的身分驗證，卻無法修復網頁憑證的網域、有效期限或信任鏈問題。

同樣地，TUN 主要改變流量接管路徑，本身不會替網站簽發憑證。若只有啟用 TUN 後才出錯，應檢查流量是否改走其他節點、DNS 是否遭接管，或是否與其他 VPN 衝突，而不是立刻替系統安裝憑證。

將暫時調整過的安全 DNS、安全軟體檢查及策略群組恢復為已確認的設定。
完全重新啟動瀏覽器，分別測試原先出錯的網域和另一個正常網域。
確認系統時間同步正常、錯誤頁面不再出現，且連線記錄中的規則和節點符合預期。
如果曾在異常憑證頁面繼續瀏覽並提交密碼，請使用可信任的裝置和網路變更密碼、檢查登入工作階段，並依帳號服務的安全流程處理。

處理憑證錯誤的順序可以固定為：查看完整代碼、檢查系統時間、確認憑證簽發者與名稱，再比對直連和代理節點。這樣能分辨本機信任問題、網站設定問題及代理連線問題，避免反覆更換設定或關閉驗證來碰運氣。