啟用 Clash 後瀏覽器顯示憑證錯誤：HTTPS 錯誤與代理伺服器的關係解析

HTTPS 憑證錯誤究竟代表什麼

瀏覽器存取 HTTPS 網站時，會先與目標伺服器建立 TLS 連線。伺服器會回傳憑證鏈，瀏覽器接著核對憑證的有效期限、簽發機構、涵蓋網域與撤銷狀態。任何一項不符合要求，都可能中止連線並顯示憑證錯誤。Clash 位於網路轉送路徑中，但一般的系統代理伺服器、HTTP 代理伺服器、SOCKS5 代理伺服器與 TUN 轉送本身不會自動解密網頁內容。

以 HTTP 代理伺服器為例，瀏覽器存取 HTTPS 網站時，通常會先向本機代理連接埠傳送 CONNECT 請求，例如連線至 127.0.0.1:7890，再要求建立通往 example.com:443 的通道。通道建立後，TLS 交握仍發生在瀏覽器與遠端伺服器之間。只要中間環節沒有執行 HTTPS 解密，Clash 就看不到網頁明文，也不會代替網站簽發憑證。

依瀏覽器錯誤代碼判斷檢查方向

錯誤代碼	常見含義	優先檢查項目
`NET::ERR_CERT_DATE_INVALID`	憑證不在有效期限內，或本機時間偏差過大	系統日期、時區、自動校時、網站憑證期限
`NET::ERR_CERT_COMMON_NAME_INVALID`	憑證涵蓋的網域與目前存取的網域不一致	DNS 汙染、節點劫持、錯誤的 hosts 記錄
`NET::ERR_CERT_AUTHORITY_INVALID`	憑證鏈無法追溯至受信任的根憑證	本機封包擷取憑證、企業閘道、憑證庫異常
`ERR_SSL_PROTOCOL_ERROR`	TLS 交握遭中斷，回傳內容不是預期的 TLS 資料	節點可用性、連接埠轉送、通訊協定設定、網路攔截
`SEC_ERROR_UNKNOWN_ISSUER`	Firefox 無法信任憑證簽發者	Firefox 獨立憑證庫、本機中繼憑證

為什麼啟用 Clash 後才出現錯誤

啟用 Clash 會改變連線使用的出口、DNS 解析路徑與路由規則。錯誤在啟用代理伺服器後出現，只能表示問題與這條新路徑有關，不能直接認定是 Clash 核心修改了憑證。實際排查時，應將路徑拆分為瀏覽器、本機代理伺服器、規則比對、節點、遠端 DNS 與目標伺服器六個環節。

節點將請求送往錯誤的伺服器

如果節點出口使用異常 DNS，或線路中存在網域劫持，目標網域可能會被解析至錯誤的 IP。瀏覽器原本存取 account.example.com，遠端卻回傳另一個網站的憑證，因而出現網域不符。這類問題通常只影響部分網域，切換至另一個節點後便會立即恢復。

也可以查看憑證詳細資訊中的「簽發給」欄位。如果目前網域與憑證中的 Subject Alternative Name 完全無關，應優先檢查節點與 DNS，不要直接點選瀏覽器的「繼續前往」。登入頁面、付款頁面與帳戶中心出現網域不符時，應停止輸入帳號與密碼。

本機軟體執行了 HTTPS 解密

Charles、Fiddler、mitmproxy、部分除錯代理伺服器、企業端點管理軟體與安全性軟體可以安裝本機根憑證，再對 HTTPS 流量執行中間人解密。設定正確時，瀏覽器會信任本機簽發的暫時憑證；根憑證遺失、過期，或只安裝在錯誤的憑證庫中時，就會顯示簽發機構無效。

常見鏈路是瀏覽器先連線至 Clash，Clash 再將流量轉送給另一個本機代理伺服器，或作業系統仍保留舊的 PAC 位址。即使 Clash 面板顯示系統代理伺服器已啟用，流量仍可能經過多個程序。Windows 可在「設定」→「網路和網際網路」→「Proxy」檢查手動代理伺服器與設定指令碼；macOS 可在「系統設定」→「網路」→目前網路→「詳細資訊」→「代理伺服器」檢查網頁代理伺服器、安全網頁代理伺服器與自動代理伺服器設定。

系統時間讓憑證看似尚未生效或已經過期

TLS 憑證包含明確的 Not Before 與 Not After 時間。電腦日期誤差一天、時區選擇錯誤，或裝置從睡眠狀態恢復後時鐘未同步，都可能觸發 NET::ERR_CERT_DATE_INVALID。代理伺服器啟用與時間錯誤可能只是同時發生，尤其是在剛重新安裝系統、主機板電池電量不足或虛擬機器從快照還原時。

Windows 11 可開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」與「自動設定時區」，再點選「立即同步」。macOS 可開啟「系統設定」→「一般」→「日期與時間」，啟用自動設定。同步後應完全退出瀏覽器再重新開啟，而不是只重新整理目前的分頁。

依序完成的 Clash 憑證錯誤排查

以下順序用於快速縮小問題範圍。每一步只變更一個變數，並記錄結果。不要同時更換節點、修改 DNS、重新安裝憑證與清除瀏覽器資料，否則恢復後無法確認真正原因。

記錄完整的錯誤代碼。 不要只記錄「連線不安全」。複製網址列中的網域、瀏覽器錯誤代碼與憑證簽發者，並確認錯誤發生的時間。
關閉系統代理伺服器後重新測試。 在 Clash 客戶端中關閉「系統代理伺服器」，完全退出瀏覽器，再存取同一網址。如果直連正常、使用代理伺服器時發生錯誤，問題範圍可縮小至規則、節點或代理鏈路。
切換至不同線路的節點。 優先選擇不同地區、不同服務商或不同通訊協定的節點。切換後等待 3 至 5 秒，讓舊連線關閉，再使用無痕視窗測試。
暫時將代理模式改為全域。 如果全域模式正常、規則模式發生錯誤，表示同一頁面所需的主網域、API 網域或靜態資源網域可能被分配至不同出口。測試完成後請改回規則模式。
核對系統時間。 檢查年月日、時、分與時區。中國大陸通常使用 UTC+08:00；不要只看工作列顯示的時間是否接近目前時間。
檢查憑證簽發者。 在瀏覽器網址列開啟憑證詳細資訊。如果簽發者名稱指向本機除錯工具、公司閘道或安全性軟體，請繼續檢查對應程式與根憑證。
停用額外的代理層。 退出封包擷取程式、瀏覽器代理擴充功能與其他代理客戶端，確認系統中只有一個程式監聽預期的連接埠。
最後再檢查 DNS 與設定檔。 如果只有少數網域回傳錯誤憑證，請比較直連與代理伺服器路徑取得的解析位址，並核對規則是否將相關網域送往錯誤出口。

檢查連接埠、代理鏈路與本機監聽狀態

不同客戶端的預設連接埠可能不同，設定中常見的混合連接埠是 7890，SOCKS 連接埠可能是 7891，外部控制連接埠常見為 9090。這些只是常見值，實際結果應以目前設定與客戶端設定頁為準。瀏覽器或系統代理伺服器指向舊連接埠時，可能會連線至另一個仍在執行的程序。

在 Windows PowerShell 中，可以檢查常見連接埠由哪個程序監聽：

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -In 7890,7891,9090 |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id <OwningProcess 數值>

在 macOS 或 Linux 中，可使用以下指令：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:7891 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

如果 7890 被舊版客戶端、除錯代理伺服器或其他服務佔用，目前的 Clash 客戶端可能會自動改用另一個連接埠，也可能啟動失敗。此時應先退出衝突程序，再回到客戶端的「設定」→「連接埠設定」或「設定」→「Clash 設定」，核對 Mixed Port、HTTP Port 與 SOCKS Port。選單名稱會因客戶端而異，但連接埠值必須與系統代理伺服器中填寫的值一致。

檢查是否存在上游代理伺服器

mihomo 設定可以透過代理提供者、鏈式代理伺服器或 dialer-proxy 等機制，讓連線經過另一個代理伺服器。瀏覽器擴充功能也可能覆寫系統代理伺服器。排查時先保留最短鏈路：瀏覽器使用系統代理伺服器，系統代理伺服器直接指向 Clash 的 Mixed Port，Clash 選擇一個確定可用的一般節點。鏈路恢復後，再逐項加入中繼與擴充功能。

若使用命令列測試，可以分別比較直連與本機代理伺服器回傳的憑證資訊。以下範例只會傳送請求標頭，不會提交帳戶資料：

curl -I https://example.com/
curl -I --proxy http://127.0.0.1:7890 https://example.com/

如果直連成功，而代理伺服器請求顯示憑證錯誤，請再切換節點並重複第二個指令。若只有一個節點失敗，通常不需要修改系統憑證庫；停用該節點，並向節點提供商回報網域、時間與錯誤代碼即可。

DNS、規則模式與 TUN如何影響憑證結果

憑證驗證是針對網域進行，但連線最終必須連到 IP 位址。Clash 的 DNS 模組、Fake-IP 模式、規則分流與節點遠端解析共同決定實際連線目標。設定不一致時，雖然瀏覽器網址列中的網域沒有變化，伺服器回傳的憑證卻可能屬於另一個網域。

規則模式中的出口不一致

現代網頁通常會同時請求主站、登入 API、內容傳遞網路與第三方資源。主網域走代理伺服器、API 網域走直連，不會自動導致憑證錯誤；但在有地區限制、企業內網解析或分區 CDN 的情況下，不同出口可能取得不同位址。應開啟客戶端的連線記錄，依錯誤發生時間尋找目標網域，確認命中的規則與代理群組。

如果暫時切換全域模式後恢復，可以為同一業務網域補充一致的規則。例如主網域與其子網域需要使用同一代理群組時，可依實際網域加入規則：

rules:
  - DOMAIN,login.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

規則會由上至下比對。更具體的網域規則應放在寬泛規則之前。不要將範例網域直接寫入正式設定，應根據連線記錄確認真實請求網域。

Fake-IP 與 DNS 劫持

Fake-IP 模式會向本機回傳對映位址，再由核心根據網域執行規則與真實解析。瀏覽器看到 198.18.0.0/16 範圍內的位址，不代表憑證遭到替換，這是 Clash 常見的內部對映方式。真正需要注意的是流量是否由核心正確接管，以及目標網域是否被加入不適合的 Fake-IP 過濾清單。

TUN 模式通常會接管更多應用程式流量，也可配合 DNS 劫持，將 53 連接埠的查詢交由核心處理。如果系統同時執行企業 VPN、遊戲加速器、虛擬機器網路或另一套 TUN 驅動程式，路由與 DNS 可能互相競爭。測試時可在客戶端的「設定」→「TUN 模式」暫時關閉 TUN，只保留系統代理伺服器。如果憑證錯誤消失，應繼續檢查路由表、DNS 劫持與其他虛擬網卡，而不是匯入來源不明的根憑證。

比較網域解析結果

Windows 可使用 Resolve-DnsName，macOS 與 Linux 可使用 dig。先在 Clash 關閉時查詢一次，再在啟用後查詢。Fake-IP 模式下結果不同屬於預期，應配合 Clash 連線記錄確認真實目標；Redir-Host 模式下若回傳完全不同的公網位址，則要檢查 nameserver、fallback、代理節點的遠端解析與本機 hosts 檔案。

Resolve-DnsName example.com
nslookup example.com

dig example.com A
dig example.com AAAA

處理憑證庫與瀏覽器差異的方法

Chrome、Edge 通常使用作業系統的憑證功能，但不同平台的實作細節並不完全相同。Firefox 可以使用自己的憑證儲存區，因此可能出現 Chrome 正常、Firefox 顯示 SEC_ERROR_UNKNOWN_ISSUER 的情況。只有單一瀏覽器發生錯誤時，應先排查該瀏覽器的擴充功能、代理設定、憑證庫與安全性原則。

Windows 憑證檢查

按下 Win + R，輸入 certmgr.msc，即可查看目前使用者的憑證。重點檢查「受信任的根憑證授權單位」→「憑證」中是否存在已停用的封包擷取工具憑證。不要批次刪除系統根憑證，也不要依據不明教學任意匯入憑證。若憑證明確屬於已解除安裝的除錯工具，應先查閱該工具的解除安裝說明，再移除對應憑證。

macOS 鑰匙圈檢查

開啟「應用程式」→「工具程式」→「鑰匙圈存取」，分別查看「登入」與「系統」鑰匙圈。搜尋錯誤頁面憑證詳細資訊中顯示的簽發者名稱，檢查憑證有效期限與信任設定。企業或學校管理的裝置可能由描述檔安裝憑證，此類憑證不應自行刪除，應交由網路管理員確認。

Firefox 獨立檢查

開啟「設定」→「隱私權與安全性」→「憑證」→「檢視憑證」，核對「憑證授權單位」清單。還應在「設定」→「一般」→「網路設定」確認 Firefox 使用的是系統代理伺服器、手動代理伺服器還是自動代理伺服器設定。如果系統代理伺服器已指向 Clash，而 Firefox 又手動指向另一個連接埠，就會形成與其他瀏覽器不同的鏈路。

從 Clash 記錄判斷故障位置

憑證驗證發生在瀏覽器端時，Clash 記錄不一定會直接出現「certificate invalid」。記錄通常會提供連線目標、命中規則、節點名稱與底層交握錯誤。排查期間可暫時將記錄層級調至 info 或 debug，重現一次後立即恢復，避免長期產生大量記錄。

i/o timeout：連線或交握逾時，優先檢查節點品質、目標可達性與防火牆。
connection refused：目標連接埠或上游代理伺服器拒絕連線，請檢查連接埠、通訊協定與服務狀態。
tls handshake timeout：TLS 交握未在限定時間內完成，可能是線路封包遺失、節點異常或目標限制。
remote error: tls：遠端主動結束 TLS 工作階段，需要結合前後記錄與目標網域判斷。
no such host：網域解析失敗，重點檢查 DNS 設定、網路可達性與網域拼寫。

如果記錄顯示連線已命中預期規則，透過另一個節點也能成功，而瀏覽器仍顯示本機簽發者憑證，問題更可能位於瀏覽器與 Clash 之間。反過來，如果只有某個節點出現交握逾時或錯誤目標位址，應停用該節點，不要透過降低瀏覽器安全性設定來規避。

恢復後的設定收尾

找到原因後，應撤銷排查期間的臨時變更。將全域模式改回規則模式，恢復正常記錄層級，關閉不再使用的手動代理伺服器，核對 TUN 與系統代理伺服器是否符合日常需求。如果修改過規則，至少測試首頁、登入 API 與常用資源網域，確認它們命中了預期的代理群組。

可以保留一份已驗證可用的設定副本，並記錄客戶端名稱、核心版本、Mixed Port、DNS 模式與出問題的節點。下次再次遇到憑證錯誤時，先比較這些項目，比清除所有設定或重新安裝更容易找出差異。