先判斷：憑證錯誤不等於一般連線逾時

先確認系統時間，再記下憑證資訊，最後比較代理與 TUN 連線路徑。瀏覽器出現 NET::ERR_CERT_AUTHORITY_INVALID，表示收到的憑證未通過信任驗證；這和節點逾時、訂閱失效是不同問題。切換節點或許會改變狀況，但不能取代憑證檢查。

一般 Clash 或 Clash Meta（mihomo）代理連線通常只會轉送 HTTPS 流量，不會替目標網站重新簽發憑證。使用 HTTP 代理時，瀏覽器可透過 CONNECT 建立通道，再與目標網站進行 TLS 交握；目標網站的憑證仍由瀏覽器驗證。正常使用 Clash 用戶端不需要安裝所謂的「Clash 根憑證」。

先記下這 5 項資訊

  • 網址列中的完整網域名稱，以及錯誤頁顯示的錯誤代碼；分享時請移除 URL 中的權杖和個人參數。
  • 憑證的簽發者、有效期限、主體別名（SAN）；不同瀏覽器可從錯誤頁的進階資訊或憑證檢視器查看。
  • 故障範圍：單一網域、同一機構的多個網域，或幾乎所有 HTTPS 網站。
  • Clash 目前使用的模式、實際選取的節點，以及系統代理和 TUN 模式是否已啟用。
  • 故障發生前是否啟用了封包擷取工具、更新了安全軟體，或連上飯店、機場等需要登入驗證的網路。

依錯誤代碼縮小排查範圍

Chrome、Edge 等 Chromium 瀏覽器的錯誤代碼相近，Firefox 的錯誤訊息可能不同。代碼只能指出驗證失敗的環節，無法直接證明是什麼軟體造成。先參考下表，再進行後續排查。

錯誤代碼常見原因優先檢查項目
NET::ERR_CERT_DATE_INVALID憑證已過期、尚未生效，或裝置時間不正確系統日期與時間、時間同步、憑證有效期限
NET::ERR_CERT_AUTHORITY_INVALID憑證鏈無法連結至受信任的根憑證封包擷取代理、安全軟體、企業憑證，以及伺服器中繼憑證鏈
NET::ERR_CERT_COMMON_NAME_INVALID憑證涵蓋的名稱與連線的網域不符網址拼寫、DNS、hosts、網路驗證入口
NET::ERR_CERT_REVOKED憑證已遭撤銷網站憑證狀態、簽發者與伺服器更新情況

ERR_SSL_PROTOCOL_ERROR 不一定是憑證信任錯誤，也可能是連接埠服務不符、TLS 交涉失敗或網路設備干擾。不要把所有含有 SSL 的錯誤都歸因於「缺少根憑證」。

第一步：確認系統時間與憑證有效期限

裝置時間若跑到過去或未來，原本有效的憑證就可能被判定為「尚未生效」或「已過期」。若許多無關網站同時出現日期錯誤，應先檢查本機，而不是批次修改規則。

  1. 在 Windows 11 開啟「設定」→「時間與語言」→「日期與時間」，確認「自動設定時間」已開啟，再按一下「立即同步」。檢查日期、年份和顯示時間是否正確。
  2. 在 macOS 開啟「系統設定」→「一般」→「日期與時間」，確認自動設定日期與時間及時區選項。
  3. 同步完成後，請完全結束瀏覽器再重新開啟，接著重新輸入原網址；不要只重新整理舊的錯誤頁面。
  4. 若仍只有單一網站無法連線，請查看該網站憑證的有效起訖日期；若伺服器憑證確實過期，應由網站管理者續期。

使用 Windows 命令列輔助檢查

Get-Date
w32tm /query /status

以下命令可在 PowerShell 查看目前時間及 Windows 時間服務狀態；如果服務未執行，第二個命令可能會顯示錯誤。時區主要影響時間顯示，憑證驗證依據的是實際系統時間，因此別只修改時區而忽略年月日。若裝置每次斷電後時間都會重設，還需檢查韌體時間和硬體時鐘。

第二步：檢查封包擷取代理與 HTTPS 掃描

Charles、Fiddler 等除錯工具啟用 HTTPS 解密後，會向瀏覽器提供由其本機根憑證簽發的網站憑證。部分安全軟體的 HTTPS 掃描和企業閘道也可能採用類似機制。若目前使用的瀏覽器不信任該根憑證、憑證已過期，或工具移除後仍殘留代理設定，都可能觸發警告。

從憑證簽發者著手排查

  • 若多個不同網站的憑證都由同一個本機除錯工具或組織名稱簽發，應優先檢查中間代理，而不是網站本身。
  • 暫時停止自行安裝的封包擷取工具及其 HTTPS 解密功能，再確認系統是否仍指向該工具的監聽連接埠。
  • 在 Windows 11 可前往「設定」→「網路和網際網路」→「Proxy」檢查手動代理；在 macOS 可前往「系統設定」→「網路」→目前的連線→「詳細資訊」→「代理」查看。
  • 同時記下 Clash 實際使用的混合連接埠。7890 只是常見範例，也可能由其他處理程序佔用；系統代理位址應與目前用戶端顯示的監聽位址一致。

個人裝置若只有一種瀏覽器出錯，可改用另一款已更新的瀏覽器比較。不同瀏覽器的版本、根憑證儲存區和管理政策可能不同，因此「另一款瀏覽器可以開啟」只代表驗證環境有差異，不表示可以直接信任那張異常憑證。

第三步：檢查 DNS、hosts 與網路驗證頁面

DNS 本身不會簽發 HTTPS 憑證，但錯誤解析可能讓連線前往其他伺服器。若要求連線的網域與對方傳回的憑證網域不同，就會發生名稱不符。公共 Wi-Fi 的驗證閘道、殘留的 hosts 記錄和錯誤的 DNS 對應都值得檢查。

先完成網路驗證，再檢查 DNS 解析

  1. 若剛連上飯店或機場 Wi-Fi，請先使用系統提供的網路登入入口完成驗證；不要在憑證錯誤頁面輸入帳號。
  2. 檢查 hosts 檔案中是否有目標網域的舊對應。Windows 檔案位置為 C:\Windows\System32\drivers\etc\hosts；macOS 和 Linux 通常為 /etc/hosts。
  3. 在 Windows 可使用以下命令查看系統 DNS 查詢結果並清除系統快取；清除後也應重新啟動瀏覽器，再檢查 Clash 的 DNS 快取和連線狀態。
nslookup example.com
ipconfig /flushdns

example.com 是命令格式範例，實際排查時請改用發生錯誤的網域。請注意，nslookup 的查詢路徑不一定與瀏覽器相同：瀏覽器安全 DNS、代理端解析和 TUN DNS 攔截都可能改變結果。單靠一份命令輸出，無法證明瀏覽器實際連線到哪個位址。

不要直接把 Fake-IP 位址判定為 DNS 污染

mihomo 使用 Fake-IP 模式時，可能會回傳 198.18.0.0/16 範圍內的對應位址給應用程式，再由核心依網域名稱進行關聯。這是常見設定範圍，但並非所有用戶端都相同。看到這類位址不代表連上了偽造網站；請搭配目前生效設定中的 dns.enhanced-mode、fake-ip-range 和連線記錄判斷。

只有在直連路徑收到錯誤憑證、透過代理連線正常時，才進一步檢查本機 DNS 解析、電信業者網路和直連伺服器。不要為了測試把 HTTPS URL 改成 IP 位址：憑證通常是依網域簽發，直接連線到 IP 本身就可能造成名稱不符。

第四步：分別測試系統代理與 TUN 模式

TUN 模式通常會在網路層接管流量，本身不會解密 TLS。啟用後才發生錯誤，常見原因是路由、DNS 處理或規則比對改變，讓連線改走另一條路徑；也可能與其他 VPN、虛擬網卡或安全軟體衝突。

每次只變更一項，依序測試

  1. 記錄基準狀態：記下目前模式、節點、DNS 設定和錯誤憑證資訊。測試期間固定使用同一節點，不要同時更新訂閱或修改規則。
  2. 測試系統代理：關閉 TUN、啟用系統代理，完全結束瀏覽器後再重新開啟。確認瀏覽器沒有被擴充功能或組織政策指定使用其他代理。
  3. 測試 TUN：關閉系統代理，再啟用 TUN。使用相同的網域和節點，查看 Clash 連線記錄中的規則、出口策略及目標資訊。
  4. 測試本機直連：關閉系統代理與 TUN，並確認其他 VPN 或手動代理也沒有接管連線。重新建立連線後比較憑證，而不只是確認網站能否開啟。

若只有 TUN 路徑失敗，先檢查 DNS 攔截、其他 VPN 和虛擬網卡衝突；若系統代理路徑也失敗，則重點比較憑證簽發者和實際使用的節點。修改設定前先備份，每次只變更一項。更新訂閱可能會覆蓋直接編輯的內容；要保留調整，請使用用戶端支援的覆寫或合併機制，並依目前 mihomo 版本確認欄位。

使用 curl 比較連線路徑並保留驗證資訊

以下以本機 HTTP 或混合代理連接埠 7890 為例。執行命令前，先到用戶端設定頁確認連接埠；Windows PowerShell 使用 curl.exe 可避免部分環境中同名別名造成的影響。

curl.exe -Iv --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -Iv --noproxy "*" https://example.com/

macOS、Linux 可將 curl.exe 改為 curl。第一個命令會明確指定應用層代理，第二個則略過 curl 的應用層代理設定。第二個命令不會繞過 TUN，也不會繞過系統中其他網路層接管。若要對照本機直連，仍須先關閉這些功能。

  • 比較 TLS 驗證結果、憑證主體和簽發者；curl 能輸出多少憑證資訊，取決於版本和 TLS 後端。
  • curl 傳回錯誤碼 60 通常表示憑證驗證失敗，仍須查看後續的具體原因，不能直接判定是 DNS 問題。
  • 不要加入 -k 或 --insecure，否則會略過目前正在排查的驗證步驟。
  • curl 和瀏覽器使用的信任儲存區可能不同，curl 成功不代表瀏覽器的驗證政策一定正常。HEAD 要求傳回 405 也不代表 TLS 交握失敗。

分享記錄前，請移除代理驗證資訊、Cookie、訂閱網址和帶有權杖的要求參數。保留測試時間、錯誤代碼和憑證簽發者，通常比提供完整設定檔更有助於找出問題。

依故障範圍決定後續處理方式

所有網站都發生錯誤

優先檢查系統時間、根憑證更新、封包擷取工具和網路驗證。請讓作業系統與瀏覽器維持在受支援的更新版本；舊系統的信任儲存區可能缺少較新的憑證鏈。不要下載來源不明的根憑證「修復包」。

只有一個網站發生錯誤

改用其他裝置和網路測試。若都顯示相同的過期憑證或名稱錯誤，請聯絡網站管理者；若只有特定節點發生問題，記下該節點和憑證資訊，改用其他可信任的節點重測，並回報服務提供者。

問題排除後如何確認

  • 原先出錯的網域，以及至少另外兩個不同網站，都能通過正常的憑證驗證。
  • 憑證涵蓋目前連線的網域、有效期限合理，且沒有新增來源不明的根憑證。
  • 恢復日常規則模式後，連線記錄中的出口策略符合預期；重新啟動用戶端和瀏覽器後，結果仍一致。

最終要修復的是系統時間、信任鏈、DNS 解析或連線路徑中的具體問題，而不是隱藏瀏覽器警告。若需確認模式與訂閱操作，可參閱Clash 設定手冊；用戶端安裝及初次設定步驟請見使用教學。