故障排查 預計閱讀 10 分鐘

開啟代理後網頁顯示憑證錯誤:HTTPS 憑證錯誤原因與逐步排查

開啟代理後出現 HTTPS 憑證錯誤?從系統時間、Fake-IP 與 DNS、HTTPS 檢查憑證及節點異常逐步排查。

先保留憑證驗證,再確認是哪一段連線出了問題。一般 HTTP CONNECT 或 SOCKS 轉送通常不需要解密網頁 HTTPS;Clash 用戶端正常轉送流量,也不需要在瀏覽器安裝根憑證。開啟代理後突然出現錯誤,表示連線路徑有所變動,但不能因此直接判定用戶端故障或節點遭到劫持。

1. 先分辨:網頁憑證錯誤,還是節點 TLS 交握失敗

錯誤訊息同樣包含 certificate,發生位置不同,該檢查的對象也不同。瀏覽器檢查的是目標網站憑證;使用 TLS 的代理協定也可能由核心檢查節點伺服器憑證,兩者不可混為一談。

錯誤位置與內容通常代表優先檢查
瀏覽器 NET::ERR_CERT_DATE_INVALID憑證有效期間與裝置時間不符系統日期、時區、憑證有效起訖日期
瀏覽器 NET::ERR_CERT_COMMON_NAME_INVALID瀏覽器造訪的網域與憑證名稱不符網址列網域、憑證 SAN、DNS 與認證入口網站
瀏覽器 NET::ERR_CERT_AUTHORITY_INVALID憑證鏈無法連結至受信任的根憑證簽發者、系統信任存放區、封包檢查工具或安全軟體
用戶端記錄 x509: certificate signed by unknown authority核心不信任某次 TLS 連線的憑證鏈同一筆記錄中的目標位址及連線用途
用戶端記錄 x509: certificate has expired or is not yet valid連線服務的憑證已過期、尚未生效,或本機時間異常時間同步、節點或訂閱伺服器憑證

記錄中的 TLS 錯誤也可能來自訂閱下載、測速網址或加密 DNS 服務,不一定是節點造成。請記下完整目標主機名稱、錯誤時間及操作,不要只截取 x509 那一行。若瀏覽器顯示 ERR_PROXY_CONNECTION_FAILED,應先檢查本機監聽連接埠及用戶端是否正在執行,而非修改憑證設定。

2. 優先檢查系統時間與憑證有效期間

時間不正確會導致許多正常網站同時無法連線。電腦長時間關機、虛擬機還原快照或主機板電池異常後,都值得優先檢查。只看工作列的時間不夠,年份、日期和時區也要確認。

  1. Windows 11:前往「設定」→「時間與語言」→「日期與時間」,開啟「自動設定時間」、確認時區,再按一下「立即同步」。
  2. macOS:前往「系統設定」→「一般」→「日期與時間」,確認「自動設定日期與時間」及自動時區選項。
  3. Android:原生系統通常可在「設定」→「系統」→「日期與時間」找到相關選項;其他廠牌可能放在「更多設定」。請確認自動設定日期時間及時區已開啟。
  4. 從瀏覽器錯誤頁面的「進階」選項或憑證檢視入口查看有效期間。介面名稱會依瀏覽器版本而異,請留意「生效時間」與「到期時間」。

如果只有一個網站顯示憑證過期,裝置時間正確且其他網站正常,通常需要由網站管理者更新憑證。切換節點無法讓過期憑證恢復效力。如果多個網站在同一分鐘開始出錯,先檢查系統時間或統一攔截流量的軟體,比反覆更新訂閱更有效。

3. 固定測試條件,比較直連與代理路徑

使用同一個完整 HTTPS 網址測試,每次只變更一項條件。不要同時切換節點、修改 DNS、開啟 TUN,否則無法判斷是哪個操作造成變化。先記下目前的規則模式、選用節點、系統代理狀態及 TUN 狀態。

建議依下列四個步驟逐一比對

  1. 關閉 Clash 用戶端的系統代理和 TUN,確認沒有其他 VPN 或瀏覽器代理擴充功能接管流量,再造訪目標網站。
  2. 只開啟系統代理,維持 TUN 關閉,使用原本的節點重試。前往用戶端的「連線」頁面,確認目標網域實際使用節點或 DIRECT。
  3. 其他設定維持不變,只換成另一個已知可用的節點,再造訪相同網址。
  4. 改用手機熱點,在相同的用戶端設定下重新測試。這一步主要用來區分目前區域網路與裝置本身的問題。

如果直連原本就無法連線,直連失敗便無法用來比較憑證問題;請勿把逾時和憑證錯誤當成相同結果。一般無痕視窗也不代表憑證環境乾淨,它仍可能使用系統根憑證,無法排除企業安全軟體的影響。

使用命令檢視交握資訊

以下是 Windows PowerShell 範例。7890 僅為示範連接埠,執行前請替換為用戶端目前的 HTTP 或混合監聽連接埠;請勿直接套用到僅提供 SOCKS 的連接埠。執行第二個測試時,用戶端必須正在該連接埠監聽,並確認環境變數 NO_PROXY 沒有讓測試網域略過代理。

PowerShell · 直連與明確指定 HTTP 代理
curl.exe -I -v --noproxy "*" https://example.com/
curl.exe -I -v --proxy http://127.0.0.1:7890 https://example.com/

這裡沒有使用略過憑證驗證的參數。第一個命令只略過應用程式層代理;若 TUN 仍在執行,流量仍可能被接管,因此必須先關閉 TUN,才能進行直連比對。不同 curl 版本使用的信任存放區可能不同,請搭配瀏覽器的憑證詳細資料判讀,不能只憑一次命令成功就排除瀏覽器信任存放區的問題。

4. Fake-IP 與 DNS:確認網域是否解析到錯誤的伺服器

Fake-IP 本身不會取代網站憑證。在 mihomo 的 Fake-IP 模式中,DNS 會回傳合成位址,核心則保存網域與位址的對應關係,再依連線狀況進行路由。若設定使用 198.18.0.1/16,查到該範圍內的位址可能是預期結果;這不等於公網伺服器的實際位址,也不能直接視為 DNS 污染。

DNS 遭竄改、路由指向錯誤服務,或舊連線與映射狀態不一致,都可能讓瀏覽器收到不屬於目前網域的憑證。另一方面,許多錯誤映射只會造成逾時,不一定出現憑證警告。請交叉比對憑證名稱與實際連線記錄。

先確認證據,再調整解析策略

  • 在 Windows PowerShell 執行 Resolve-DnsName example.com,查看回傳位址;請將範例網域替換為實際發生錯誤的網域。
  • 開啟用戶端的「連線」或記錄檢視畫面,確認網域、符合的規則及出站節點。系統命令查詢到的 DNS,不一定就是瀏覽器使用的 DNS。
  • 在 Chrome 的「設定」→「隱私權和安全性」→「安全性」中,可檢查「使用安全 DNS」。只在比對測試時暫時調整,並記下原本的設定;DoH 流量仍可能經過 TUN。
  • 若剛切換 DNS 模式,請先關閉相關網頁及瀏覽器連線,必要時重新啟動用戶端;Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取。這不會自動清除所有瀏覽器快取及核心映射。

以下只是 mihomo DNS 設定片段,用來辨識欄位,並非修復憑證錯誤的完整設定。DNS 上游、路由及用戶端覆寫仍須依照現有環境設定。

YAML · DNS 欄位示意
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

若特定應用程式確實與 Fake-IP 不相容,確認原因後再評估 fake-ip-filter,不要直接排除所有網域。訂閱代管的設定應透過用戶端支援的覆寫機制修改,以免下次更新時還原。更多設定方式請參閱進階設定。

5. 中間人封包檢查憑證、企業 HTTPS 檢查與公共 Wi-Fi

如果多個互不相關的網站都顯示同一個本機組織或安全產品為簽發者,請檢查 HTTPS 檢查功能。Fiddler、Charles、mitmproxy 等除錯工具安裝並信任其根憑證後,可以解密 HTTPS;部分企業閘道和端點安全軟體也有類似機制。這與 Clash 用戶端一般轉送 HTTPS 的方式不同。

如何確認憑證來源

  1. 在錯誤頁面或憑證檢視器中記下主體別名(SAN)、簽發者、有效期間及憑證鏈。SAN 必須涵蓋網址列中的網域。
  2. 結束封包檢查工具,並確認系統代理是否仍指向該工具的監聽連接埠。關閉工具視窗不代表系統代理已還原。
  3. Windows 可使用 certmgr.msc 檢視目前使用者的憑證;檢視本機電腦憑證的 certlm.msc 通常需要相應權限。macOS 可在「鑰匙圈存取」中檢視憑證及信任設定。
  4. 個人裝置只處理已確認來源的除錯憑證。公司管理的裝置請先聯絡管理員,不要直接大量刪除企業根憑證。

瀏覽器與命令列工具使用的憑證信任來源可能不同,因此可能出現瀏覽器正常、curl 出錯,或相反的情況。安裝根憑證前,請先確認這項 HTTPS 檢查確實屬於裝置管理政策,並確認憑證來源可信。

6. 只有特定節點出錯:檢查 SNI 與憑證鏈

如果同一台裝置、同一個網站及相同 DNS 設定下,只有切換到某個節點才出錯,請先暫停使用該節點,並分辨兩種狀況:用戶端無法連上節點,或節點連線成功後,瀏覽器收到異常的網站憑證。

用戶端記錄顯示節點 TLS 錯誤

對使用 TLS 的節點而言,連線位址與用於憑證驗證的名稱可能不同。mihomo 不同協定使用的欄位也不完全相同:例如 VMess、VLESS 常見 servername,Trojan 常見 sni。請依照該協定文件及服務提供者提供的參數核對,不要把同一個欄位名稱套用到所有節點。

  • 連線位址若填入 IP,憑證不一定包含該 IP 的 SAN;請向服務提供者索取正確的伺服器名稱及連線參數。
  • 如果記錄顯示憑證已過期或憑證鏈不完整,應由節點維護者更新憑證並補齊中繼憑證;使用者無法透過修改規則修復伺服器憑證。
  • skip-cert-verify 只會影響相應節點連線的驗證,不會修復瀏覽器對目標網站憑證的驗證。請勿將其設為 true 來掩蓋錯誤。

瀏覽器收到異常的網站憑證

一般轉送節點沒有目標網站的私鑰,無法憑空簽發瀏覽器信任的網站憑證。異常憑證可能代表 DNS 錯誤、出口網路認證或流量攔截、遠端設定錯誤,也可能涉及惡意干預。單次錯誤不足以判定遭到劫持,但應暫停透過該路徑進行敏感操作。

保留該節點下的憑證資訊,再透過其他可信任的網路或節點進行比對。不同 CDN 出口可能合法使用不同憑證及簽發機構,不能只因簽發者不同就認定遭到劫持;應確認網域涵蓋範圍、有效期間、憑證鏈是否可信,以及重複測試結果。

7. 依結果完成後續處理:修復、複測與整理求助資訊

完成一項修復後,請回到最初出錯的完整網址重新測試,再檢查另一個不同的網站。網頁能開啟只是第一步,也要確認規則模式、系統代理與 TUN 都已恢復至預期狀態,沒有留下測試期間啟用的全域路由或臨時 DNS 設定。

比對結果優先處理方向
所有網路上的多個網站都顯示日期錯誤校正裝置時間,再檢查系統更新與信任存放區
只有一個網站在不同連線路徑下都顯示憑證過期聯絡網站管理者,不要略過憑證驗證
只有目前的 Wi-Fi 異常,手機熱點正常檢查認證入口網站、閘道 DNS 與網路 HTTPS 檢查
只有一個節點異常停用該節點,檢查節點 TLS 參數與出口路徑
只有一個瀏覽器異常檢查瀏覽器政策、擴充功能、專用信任存放區與安全 DNS

回報問題時請附上以下資訊

  • 作業系統版本、Clash 用戶端名稱與版本、mihomo 核心版本。請勿只寫「最新版」。
  • 完整錯誤碼、發生時間,以及錯誤來自瀏覽器或用戶端記錄。
  • 目標網域、憑證 SAN、簽發者及有效期間;請隱去網址查詢參數中的個人資訊。
  • 系統代理與 TUN 狀態、實際監聽連接埠、規則模式,以及直連/節點 A/節點 B 的比對結果。
  • 與問題相關的少量記錄;請先刪除訂閱網址、存取權杖、節點密碼及外部控制金鑰。

排查順序可固定為:錯誤位置 → 系統時間 → 路徑比對 → DNS 與憑證來源 → 節點參數。每一步都有依據,不必一開始就重新安裝用戶端或大幅修改 YAML。初次匯入與代理設定請參閱使用指南;常見連線問題可繼續查看說明中心。

下載Clash依平台選擇用戶端