疑難排解 閱讀時間約 12 分鐘

開啟 Clash 後網站顯示憑證錯誤：系統時間、中間人與 TUN 排查順序

開啟代理後瀏覽器出現 NET::ERR_CERT 錯誤？常見原因包括系統時間不準、節點遭干預，或 TUN 與安全軟體衝突。本文整理由簡入繁的排查步驟與判斷方式。

保留錯誤資訊，再依序檢查時間、節點與 TUN

先別按「仍要前往」，也不要安裝對方臨時傳來的根憑證。HTTPS 憑證錯誤表示瀏覽器無法確認目前連線對象的身分，並不代表「代理速度很慢」。一般的 Clash 代理轉送不會要求瀏覽器放棄憑證驗證；mihomo 的 TUN 接管也不等於解密 HTTPS。

如果正在開啟電子郵件、付款頁面或管理後台，請先停止輸入密碼。記下錯誤代碼、存取網域、憑證簽發者與發生時間，再進行比對。本文的連接埠與網域僅用於示範檢查方法，不代表用戶端的預設設定或本站實測結果。

  1. 檢查系統日期、時區與憑證有效期間，排除本機時鐘異常。
  2. 確認真正結束代理後的結果，再比較兩個節點。
  3. 查看憑證網域與簽發者，判斷是否遇到入口網站或 HTTPS 檢查。
  4. 一次只切換 TUN，並核對 DNS、路由與安全軟體。
  5. 使用命令列再次確認，依據結果決定要還原哪項設定。

辨識錯誤代碼：憑證錯誤不等於 TLS 交握失敗

Chromium 系瀏覽器常見的錯誤代碼前綴是 NET::ERR_CERT_。Firefox 顯示的文字與代碼不同，但檢查項目仍包括時間、憑證鏈、網域與信任來源。先抄下完整代碼，別只記得「無法建立安全連線」。

錯誤範例 主要含義 優先檢查項目
NET::ERR_CERT_DATE_INVALID 本機判定憑證尚未生效或已過期 系統時間、憑證起訖日期
NET::ERR_CERT_AUTHORITY_INVALID 憑證鏈無法連結至受信任的根憑證 簽發者、憑證鏈是否完整、HTTPS 檢查
NET::ERR_CERT_COMMON_NAME_INVALID 憑證不適用於目前的主機名稱 憑證 SAN、入口網站重新導向、DNS 與 hosts
NET::ERR_CERT_REVOKED 憑證被判定為已撤銷 憑證本身、網站或安全產品狀態
ERR_SSL_PROTOCOL_ERROR TLS 協定交握異常，不一定取得了有效憑證 代理連接埠、協定、網路設備與伺服器

判斷範圍同樣重要：只有一個網域出錯，優先懷疑該網站或套用於該網站的規則；多個彼此無關的 HTTPS 網站同時出錯，則優先檢查本機時間、信任存放區，以及共同經過的網路設備。無論哪種情況，都不能只因為「剛開啟 Clash」就認定核心損壞。

第一步：檢查系統時間與憑證有效期間

啟用系統自動同步，再重試相同網址

Windows 11 可開啟「設定」→「時間與語言」→「日期與時間」，確認「自動設定時間」已開啟，再按「立即同步」。macOS 可開啟「系統設定」→「一般」→「日期與時間」，確認自動設定日期與時間的狀態。若裝置由組織管理而無法修改，請聯絡管理員。

  • 先確認年份、月份與日期；從睡眠狀態恢復或主機板電池異常，都可能讓時鐘跳回過去。
  • 接著檢查時區。顯示的當地時間正確，不代表 UTC 時間一定正確，別只用肉眼確認時鐘。
  • 開啟瀏覽器提供的憑證檢視器，記下「生效時間」與「到期時間」，再與系統時間比對。

例如，憑證到期日早於目前日期，而且只有這個網站出錯，應由網站維護方更新憑證；若系統日期早於憑證生效日，多個網站可能會同時連線失敗。不要為了配合過期憑證而把時鐘調回過去，這會影響登入權杖、軟體更新與其他連線。

在 Linux 使用命令確認同步狀態

timedatectl status
date -u

在使用 systemd 的發行版中，第一個命令可查看時間、時區與同步狀態；第二個命令會顯示 UTC 時間。若已啟用時間同步卻長時間未同步，請檢查目前使用的時間服務及其網路連線。修正後重新開啟目標網頁，再判斷是否需要調整代理設定。

第二步：比較直連與不同節點，確認故障範圍

「關閉系統代理」不一定代表直連：TUN 可能仍在接管流量，其他 VPN 也可能保留路由。先儲存目前的模式、節點與 DNS 設定，再結束用戶端，確認 TUN 已關閉且系統代理已還原。請勿為了測試而造訪不熟悉的登入頁面。

測試條件 觀察項目 可據此判斷
結束用戶端，並關閉其他 VPN 相同網址是否仍出現相同錯誤代碼 仍然出錯時，先檢查網站、本機或目前網路
開啟系統代理、關閉 TUN，使用節點 A 命中的規則、實際出口、憑證簽發者 建立一般代理轉送的基準結果
維持相同模式，切換至節點 B 錯誤是否消失、憑證是否改變 若錯誤只隨節點改變，應優先檢查節點連線路徑
切回節點 A，只啟用 TUN 錯誤是否只在 TUN 模式下出現 改查路由、DNS 與安全軟體的共存情況

切換節點後，請在用戶端的「連線」面板確認新連線確實經過該節點。策略組可能自動選擇其他成員，規則也可能將目標網域導向 DIRECT。關閉出錯的分頁後重新開啟，必要時重新啟動瀏覽器，避免沿用舊連線影響比較。

第三步：查看憑證簽發者，區分入口網站與中間人

一般代理轉送不需要替換網站憑證

瀏覽器透過 HTTP CONNECT、SOCKS 或 TUN 傳送流量時，目標網站的 TLS 通常仍由瀏覽器與網站建立。開啟代理不代表 Clash 或 mihomo 必須重新簽發所有網站的憑證。如果多個不同網站突然都顯示同一家本機安全產品或企業名稱作為簽發者，請檢查 HTTPS 檢查功能與裝置管理政策。

企業閘道可能依組織政策解密並檢查 HTTPS；部分安全軟體也提供類似功能。如果目前的瀏覽器不信任其根憑證，就可能出現憑證鏈錯誤。Firefox 與 Chromium 在憑證信任設定、平台整合及企業政策上各有差異，因此「換個瀏覽器就能開啟」只能縮小問題範圍，不能證明連線路徑一定正常。

  • 網域比對：查看憑證的主體別名（SAN）是否包含造訪的主機名稱。萬用字元 *.example.com 不涵蓋根網域 example.com，也不涵蓋多層子網域。
  • 簽發者異常：若簽發者變成路由器、陌生組織或本機產品名稱，請先確認來源，不要直接將其設為信任。
  • 憑證有所變化：CDN 可能依地區提供不同憑證，憑證不同本身不代表遭到劫持；還要檢查網域是否相符、有效期間與信任鏈。

使用公共 Wi-Fi 時，先完成網路認證

飯店或機場的網路可能尚未完成入口網站認證。請優先使用系統跳出的網路登入視窗，並確認網路名稱；必要時可前往已知的一般 HTTP 網頁觸發入口網站。不要在 HTTPS 憑證警告頁面輸入帳號，也不要為了通過入口網站認證而安裝陌生憑證。完成認證後重新測試；若憑證仍不相符，請勿透過這條連線處理敏感業務。

如果只有某個節點持續提供不相符的憑證，而其他節點正常，請先停用該節點，並向服務提供者提供發生時間、網域與憑證資訊。節點故障、出口 DNS 異常或轉送路徑遭到干預，都值得檢查；但單憑一次錯誤，無法斷定究竟是哪一方進行了劫持。

第四步：只有 TUN 模式出錯時，檢查 DNS 與路由

TUN 是將系統流量送入虛擬網路介面的方式，本身不會簽發網站憑證。只有啟用 TUN 後才出錯，通常表示原本未經代理的流量遭到接管，或 DNS、路由與安全產品的處理路徑有所改變。先維持相同節點與規則模式，只關閉 TUN 進行比較。

fake-ip 位址不是網站提供的憑證

在常見的 fake-ip 設定中，核心可能會將網域映射至 198.18.0.0/16 範圍內的位址，再依映射結果處理連線；實際範圍請以生效中的設定為準。看到這類 DNS 結果不代表憑證遭到替換。真正需要確認的是：該連線是否進入負責這項映射的核心，以及目標網域最後被送往何處。

  1. 開啟連線記錄並搜尋目標網域，記下命中的規則、策略組與出口。
  2. 檢查生效設定中的 dns.enhanced-mode、tun.dns-hijack 與路由相關設定，不要只查看訂閱原始檔。圖形介面用戶端可能另有覆寫設定。
  3. 確認瀏覽器的「安全 DNS」設定。瀏覽器內建的 DoH 與系統 DNS 可能使用不同路徑；變更此設定前請先記下原值。
  4. 檢查本機 hosts 是否將網域指向舊位址。Windows 常見路徑為 C:\Windows\System32\drivers\etc\hosts，Linux 與 macOS 則為 /etc/hosts。
  5. 逐一停止其他 VPN 或網路過濾工具進行比對。企業裝置請先徵求管理員同意，不要一次解除安裝多個元件。

若 DNS 指向錯誤的伺服器，瀏覽器仍可能成功建立 TCP 連線，卻收到其他網域的憑證，最後出現網域不符的錯誤。相反地，路由衝突更常造成逾時或連線重設，不應把所有 TUN 異常都稱為憑證錯誤。只有錯誤代碼與憑證詳細資訊相符時，才繼續沿著憑證問題排查。

第五步：使用 curl 與瀏覽器交叉比對，避免弄錯連接埠

以下以本機 HTTP 或混合代理監聽 127.0.0.1:7890 為例。請先在用戶端的監聽設定或生效設定中確認實際連接埠；7890 並非所有用戶端的固定值。網站使用 HTTPS，不代表本機代理位址要寫成 https://127.0.0.1:7890。

Windows 的兩組請求

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

第一個命令會略過 curl 明確設定的代理，第二個命令則強制使用本機 HTTP 代理，並清空不使用代理的清單。測試實際故障時，請將範例網域換成出錯網站的公開首頁，不要附上登入權杖。macOS 或 Linux 可將 curl.exe 換成 curl。

  • 關閉 TUN 後再測試直連：--noproxy "*" 無法繞過作業系統層級的 TUN 路由。
  • 分清 CONNECT 與 TLS：出現 200 Connection established 只代表代理通道已建立，不代表網站憑證已驗證成功。
  • 留意回傳錯誤：curl 錯誤 60 通常表示對端憑證驗證失敗；錯誤 7 或 28 則較可能是連線失敗或逾時。
  • 不要加入略過驗證的參數：這次的目的是確認驗證失敗的原因，而不是強制讓請求回傳網頁。

curl 與瀏覽器使用的 TLS 後端及信任來源可能不同，因此兩者結果不一致時，應繼續核對憑證簽發者、系統代理、瀏覽器擴充功能與管理政策，而非認定其中一方的結果必然較可靠。詳細記錄可能含有目標位址或驗證資訊，對外提交前請先移除敏感資料。

還原設定並重新測試：每次只變更一項

找到相關變數後，先還原其他測試設定，再只保留必要的修正。例如校準時鐘後問題消失，就不必繼續修改 DNS；只有某個節點異常，就先停用該節點；若只在企業 HTTPS 檢查下失敗，則請管理員核對憑證部署與政策。

  1. 使用原本出錯的網址重新測試，確認不再出現相同的憑證錯誤。
  2. 接著測試兩個彼此無關的 HTTPS 網站，確認是否存在全域信任問題。
  3. 在連線面板確認目標流量實際使用的出口，避免誤將恢復直連當成代理問題已修復。
  4. 還原暫時關閉的安全功能與 DNS 設定，逐項確認問題沒有再度出現。
  5. 保留錯誤代碼、節點名稱、核心名稱、TUN 狀態與修復步驟，方便日後重現問題。

提交回報時，可附上用戶端實際版本、核心版本、作業系統版本及已移除敏感資料的記錄；請勿公開訂閱網址、代理密碼或完整的私人設定。用戶端名稱與核心名稱應分開記錄：圖形介面相似，不代表使用相同的 Clash 或 mihomo 核心。

後續設定可參閱使用手冊的 DNS 說明與代理模式說明。判斷的關鍵始終是三件事：目前時間是否正確、憑證究竟簽發給誰，以及這次連線實際經過哪條路徑。

下載最新版 Clash