開啟代理後 HTTPS 憑證錯誤怎麼辦：常見原因與逐項排查

HTTPS 憑證錯誤通常發生在 TLS 交握階段。瀏覽器在真正傳送網頁請求前，會檢查伺服器回傳的憑證是否由受信任機構簽發、憑證中的網域是否與目前網址一致、目前時間是否在有效期限內，以及憑證鏈能否完整連接至系統信任的根憑證。開啟 Clash 或 mihomo 後出現錯誤，只能表示連線路徑發生變化，不能直接將原因歸咎於某個節點。

標準的 HTTP CONNECT、SOCKS5 或 TUN 轉發不會替網站簽發憑證。mihomo 核心通常只負責轉發連線、比對規則與選擇出口，不會解密網頁中的 TLS 內容。如果瀏覽器看到的憑證簽發者突然變成本機安全軟體、公司閘道或陌生機構，應繼續檢查 HTTPS 掃描、上游代理、公共網路認證頁及系統憑證庫，而不是反覆修改代理規則。

先依錯誤代碼縮小範圍

不同憑證錯誤對應不同的檢查方向。Chrome、Edge 與基於 Chromium 的用戶端通常會顯示以 NET::ERR_CERT_ 開頭的代碼；Firefox 常見 SEC_ERROR_UNKNOWN_ISSUER 或 SSL_ERROR_BAD_CERT_DOMAIN。先展開瀏覽器的「進階」或「檢視憑證」，再對照下表處理。

憑證頁面重點查看四項

1. 頒發給：應包含目前造訪的網域。萬用字元憑證 *.example.com 可以涵蓋 www.example.com，但通常無法涵蓋更深一層的 a.b.example.com。
2. 頒發者：若直連時是公開憑證機構，使用代理後卻變成本機軟體名稱或單位內部 CA，表示連線路徑中存在 TLS 檢查。
3. 有效期限：比較「生效時間」與「到期時間」時，必須同時確認系統時區。日期正確但時區偏差數小時，也可能在憑證剛續期時觸發錯誤。
4. 主體別名：現代瀏覽器主要檢查 SAN，而不是只查看舊式的 Common Name。憑證中缺少目前網域就會觸發網域不相符。

第一步：校準系統時間與憑證環境

時間錯誤是涵蓋範圍最廣、排查成本最低的一項。如果所有 HTTPS 網站都失敗，或電腦剛從休眠恢復、主機板電池剛更換、裝置使用雙系統，應先完成時間同步。Windows 11 路徑為「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」和「自動設定時區」，接著點選「立即同步」。

Windows 也可以在終端機執行以下命令查看時間服務狀態。結果中的 Source 應顯示可用的時間來源，Last Successful Sync Time 應接近目前時間。

w32tm /query /status
powershell -NoProfile -Command "Get-Date"

macOS 路徑為「系統設定」→「一般」→「日期與時間」，開啟自動設定。Linux 可用 timedatectl status 檢查 System clock synchronized 與時區。Android 常見路徑為「設定」→「系統」→「日期和時間」；不同廠牌可能將入口放在「更多設定」中。

清理過期的本機憑證介入

如果裝置曾安裝封包擷取工具、除錯代理、公司端點管理軟體或 HTTPS 掃描元件，應檢查這些程式是否仍在執行。只退出瀏覽器通常不夠，因為過濾驅動程式、系統服務和本機代理程序可能繼續接管連線。先從軟體本身的設定中關閉 HTTPS 掃描或 TLS 解密，再徹底退出對應程式並重新啟動瀏覽器。

• Windows 可按 Win + R，輸入 certmgr.msc 查看目前使用者憑證；電腦層級憑證可透過 MMC 的「憑證」管理嵌入式管理單元檢查。
• macOS 可在「鑰匙圈存取」中檢查「系統」和「登入」鑰匙圈，重點查看近期加入且用途為憑證簽署的項目。
• Firefox 可開啟「設定」→「隱私權與安全性」→「憑證」→「檢視憑證」，檢查「憑證授權單位」清單。
• Android 可在「設定」→「安全性」→「加密與憑證」中查看使用者安裝的憑證，實際選單名稱會隨系統版本而異。

第二步：比較直連、系統代理與 TUN 路徑

排查憑證問題最有效的方法是進行受控對照。每次只變更一個變數，避免同時切換節點、DNS、規則及重新安裝憑證。建議先選擇穩定的 HTTPS 網站測試，再測試原先報錯的目標網站，以區分「所有網站失敗」和「單一網站失敗」。

1. 保留 Clash 或 mihomo 執行，但關閉系統代理與 TUN，測試直連。
2. 只啟用系統代理，使用相同節點與相同瀏覽器再次測試。
3. 關閉系統代理，只啟用 TUN，再測試一次。
4. 維持模式不變，將目前節點切換至另一條不同線路的節點。
5. 最後才切換規則模式、全域模式或直連模式，觀察問題是否與規則命中有關。

使用 curl 驗證本機混合連接埠

Clash 圖形化用戶端常將本機混合連接埠設為 7890，但實際值應以設定中的 mixed-port 或用戶端「設定」→「連接埠設定」為準。以下兩個命令分別測試直連與透過本機 HTTP 代理連線。-I 只請求回應標頭，-v 會顯示連線與 TLS 過程。

curl -Iv https://www.cloudflare.com/
curl -Iv --proxy http://127.0.0.1:7890 https://www.cloudflare.com/

如果直連成功、代理失敗，繼續切換節點並查看 mihomo 記錄。如果所有節點都失敗，但關閉某個本機安全元件後恢復，應優先處理本機 TLS 檢查。如果只有單一節點失敗，可能是節點出口網路、上游 DNS、公共網路認證或伺服器至目標網站的路徑異常。

也可以使用 OpenSSL 觀察伺服器傳送的憑證鏈。較新的 OpenSSL 支援透過 HTTP 代理建立連線：

openssl s_client -proxy 127.0.0.1:7890 -connect www.cloudflare.com:443 -servername www.cloudflare.com -showcerts

-servername 會傳送 SNI。缺少 SNI 時，多網域伺服器可能回傳預設網站憑證，進而造成網域不相符。比較直連與代理結果時，重點查看憑證主體、簽發者、有效期限和驗證回傳碼，不要只看命令最後是否建立了 TCP 連線。

第三步：檢查節點、DNS 與代理規則

切換節點能說明什麼

透過代理使用 HTTPS 時，用戶端通常會先與節點建立加密通道，再由節點連線至目標網站。對 HTTP 代理而言，瀏覽器會透過 CONNECT example.com:443 建立通道；對 SOCKS5 而言，網域或目標位址會透過 SOCKS 請求傳遞。正常通道中的 TLS 仍由瀏覽器與目標網站完成。

如果切換至另一個節點後立即恢復，可進一步檢查故障節點所在網路是否將目標網域導向錯誤位址、是否遇到電信商認證頁，或是否無法取得目標網站目前使用的憑證鏈。只有當節點在連線路徑中具備憑證替換能力，且裝置信任其簽發的憑證時，瀏覽器才可能無警告地接受替換內容；缺乏信任時通常會直接出現憑證錯誤。

DNS 錯誤為何會變成憑證網域錯誤

DNS 將網域解析至錯誤伺服器時，瀏覽器仍會將原網域作為 SNI 傳送。如果錯誤伺服器沒有對應的虛擬主機，可能會回傳其他網站的憑證，最後出現 NET::ERR_CERT_COMMON_NAME_INVALID。此時憑證本身可能仍在有效期限內，但適用網域與網址列不一致。

mihomo 的 fake-ip 模式會先從保留位址池回傳對應位址，再於核心中還原原始網域並依規則連線。Fake-IP 本身不會產生網站憑證。如果問題只在 Fake-IP 下出現，應檢查網域是否被錯誤加入 fake-ip-filter、應用程式是否繞過 TUN，以及區域網路 DNS 請求是否確實進入 mihomo。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

fake-ip-filter 應針對確實依賴真實位址的區域網路服務、裝置探索網域或特定相容性情境設定，不宜將大範圍網域全部排除。排除後，這些網域會使用真實解析，解析來源與規則路徑也會隨之改變。

查看規則實際命中結果

在支援連線清單的 Clash 用戶端中，開啟「連線」或「記錄」頁面，造訪報錯網站後依網域篩選。記錄命中的規則、策略群組與最終節點。如果目標本應直連卻進入代理，檢查前面的 DOMAIN、DOMAIN-SUFFIX、GEOSITE 與規則集；如果本應代理卻直連，則檢查區域網路規則、私有位址規則和最後的 MATCH。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

規則會依序比對，前面命中後不會繼續往下。修改 YAML 後應先確認縮排，再重新載入設定。如果用戶端同時使用訂閱覆寫、腳本或全域擴充設定，還要確認最終生效的設定，而不是只查看訂閱原文。

第四步：定位 MITM、HTTPS 掃描與防火牆介入

MITM 在這裡是指中間元件終止原始 TLS 連線，再向瀏覽器簽發一張替代憑證，同時由該元件與目標網站建立第二條 TLS 連線。企業稽核閘道、封包擷取除錯工具、家長監控程式和部分端點安全產品可能採用這種方式檢查 HTTPS 流量。

標準 mihomo 設定中的 proxies、proxy-groups、rules、tun 與 dns 欄位不負責為網頁簽發憑證。因此，在 Clash 用戶端介面中找不到所謂「網站憑證開關」是正常現象。若憑證簽發者顯示為本機軟體，應回到該軟體的網路防護或 HTTPS 掃描設定處理。

逐項停用，不要一次卸載所有元件

1. 關閉瀏覽器擴充功能中的代理切換、封包擷取或除錯功能，完全退出瀏覽器後重新開啟。
2. 暫停本機封包擷取程式的系統代理和 HTTPS 解密，只保留 Clash 的系統代理。
3. 在安全軟體中暫時關閉「HTTPS 掃描」、「加密連線檢查」或同類功能，完成一次對照測試後再恢復。
4. 中斷公司 VPN、零信任用戶端或遠端辦公閘道，再比較家用網路與行動熱點。
5. 若公共 Wi-Fi 尚未完成認證，先關閉代理並造訪系統提供的登入頁面，完成認證後再啟用代理。

某些公共網路會將首次 HTTP 請求重新導向至認證頁面。HTTPS 無法直接接受這種重新導向，因為認證閘道回傳的憑證不屬於原始網站，瀏覽器便會顯示網域不相符。切換至手機熱點後立即恢復，是辨識這類問題的有效訊號。

第五步：處理僅瀏覽器或僅應用程式報錯

Chrome、Edge 正常，Firefox 報錯

Chrome 與 Edge 通常沿用作業系統的憑證環境，Firefox 的憑證處理方式可能與系統不同。先在 Firefox 開啟「設定」→「隱私權與安全性」→「憑證」→「檢視憑證」，確認所需機構是否存在。企業裝置應由管理員統一部署憑證原則，不應從網頁提示中臨時下載憑證。

瀏覽器正常，桌面應用程式或手機應用程式失敗

部分應用程式使用獨立憑證庫，部分應用程式還會執行憑證固定驗證，也就是只接受開發者預先指定的憑證或公開金鑰關係。此時瀏覽器可以正常開啟網站，但應用程式仍會拒絕連線。解決方向通常是讓該應用程式的流量繞過 TLS 解密元件，而不是將更多憑證匯入系統。

若問題只在 TUN 模式出現，檢查應用程式流量是否同時經過另一套 VPN、安全過濾器或私人 DNS。Android 和 iOS 通常一次只允許一個主要 VPN 通道，但本機 DNS、內容過濾設定或裝置管理原則仍可能改變路徑。關閉其他網路延伸功能後，再單獨啟動 Clash 用戶端，可以減少變數。

無痕視窗正常，一般視窗失敗

這通常指向瀏覽器擴充功能、快取的 HSTS 狀態、獨立代理擴充功能或使用者設定差異。先在擴充功能管理頁停用網路相關擴充功能，再清除目標網站的 Cookie 與網站資料。不要將「忽略憑證錯誤」啟動參數作為長期方案，這會降低整個瀏覽器工作階段的憑證驗證能力。

一套可重複使用的十分鐘排查順序

1. 第 1 分鐘：抄下錯誤代碼，並查看憑證的網域、簽發者和有效期限。
2. 第 2 分鐘：同步系統時間，確認日期、時區和時間服務狀態。
3. 第 3 分鐘：關閉系統代理與 TUN，進行一次直連對照。
4. 第 4 分鐘：只開啟系統代理，使用相同網站與相同瀏覽器測試。
5. 第 5 分鐘：更換另一條不同線路的節點，不變更其他設定。
6. 第 6 分鐘：查看連線記錄，確認網域命中的規則、策略群組與出口。
7. 第 7 分鐘：使用 curl -Iv 比較直連與 127.0.0.1:7890 代理結果。
8. 第 8 分鐘：暫停 HTTPS 掃描、封包擷取和企業網路元件，逐一進行對照。
9. 第 9 分鐘：切換至手機熱點，排除公共網路認證和目前路由器路徑。
10. 第 10 分鐘：整理重現條件，包括用戶端版本、mihomo 核心版本、系統版本、節點、模式和錯誤代碼。

最終判斷應建立在對照結果上：所有網路和所有裝置都對同一網站報錯，傾向於網站憑證部署問題；只有一台裝置失敗，優先檢查時間、憑證庫與安全軟體；只有代理路徑失敗，繼續檢查節點、DNS、規則和上游網路；只有單一應用程式失敗，則重點考慮獨立憑證庫、憑證固定和應用程式流量接管範圍。

完成排查後，逐項恢復暫時關閉的安全功能，並再次驗證瀏覽器與常用應用程式。Clash 或 mihomo 設定也應恢復至日常使用模式，避免長期保留全域代理、過寬的 Fake-IP 排除項目或僅為測試而新增的規則。