啟用 Clash、Clash Meta（mihomo）客戶端後，瀏覽器可能突然顯示「連線不是私人連線」「憑證不受信任」或「憑證與網域不相符」，應用程式也可能回報 TLS 交握失敗。這類現象很容易直接歸咎於代理節點，但 HTTPS 驗證牽涉系統時間、目標網站憑證、DNS 解析、作業系統信任庫、上游網路設備與應用程式本身的憑證策略；代理只是改變其中一段連線路徑。

標準的 HTTP CONNECT、SOCKS5 或 TUN 轉發不會自動解密 HTTPS 內容。客戶端通常只負責將加密流量送往選定的出口，網站憑證仍由目標伺服器提供。mihomo 的網域嗅探用於識別流量對應的主機名稱，也不代表會替換網站憑證。因此，排查重點不是反覆匯入訂閱或盲目切換代理模式，而是先確認錯誤類型，再透過對照測試找出異常發生在哪一層。

先了解 HTTPS 憑證錯誤屬於哪一類

建立 HTTPS 連線時，客戶端會檢查憑證有效期限、存取網域、簽發鏈與用途。不同錯誤指向的原因並不相同。記錄瀏覽器錯誤代碼、錯誤網域、憑證簽發者與有效期限，比只保留「打不開」的截圖更有幫助。

憑證尚未生效或已經過期

這類錯誤首先要檢查電腦或手機的日期、時間與時區。系統時間偏差數月時，大量正常網站都可能同時連線失敗；若只有單一網站失敗，則更可能是網站憑證過期、伺服器部署遺漏，或某個出口連到了尚未更新憑證的邊緣節點。即使開啟自動校時後仍不正確，也要確認系統選用的時區，而不只是查看時鐘顯示的時間。

憑證網域不相符

憑證中的主機名稱與網址列網域不同，常見情況是憑證簽發給另一個網站、網路登入頁面或內部閘道。可能原因包括 DNS 回傳錯誤位址、本機 hosts 規則覆寫、透明閘道重新導向、目標網站虛擬主機設定錯誤，以及代理出口連到了異常伺服器。若憑證簽發給路由器管理網域、公共 Wi-Fi 登入網域或陌生企業閘道，應優先檢查目前網路是否要求驗證。

憑證簽發者不受信任或憑證鏈不完整

伺服器需要提供從網站憑證到中繼憑證的完整鏈，系統再利用內建的信任根完成驗證。舊版系統的根憑證庫長期未更新、網站遺漏中繼憑證，以及企業安全閘道進行 HTTPS 檢查，都可能觸發這類錯誤。部分瀏覽器使用獨立的憑證庫，因此同一網站在不同瀏覽器中的結果可能不一致，這正是定位信任庫問題的重要線索。

TLS 交握失敗，但沒有明確的憑證頁面

命令列工具或應用程式通常只會顯示 handshake failed、certificate verify failed、unknown CA 等簡短訊息。問題也可能涉及客戶端支援的 TLS 版本、伺服器名稱指示、應用程式憑證固定、上游代理協定錯誤，或連線在途中被關閉。此時應結合 Clash 記錄與應用程式記錄判斷：是在連線節點時失敗、連線目標位址時失敗，還是收到目標憑證後驗證失敗。

透過對照測試確認問題出在裝置、網路還是代理路徑

有效的排查應一次只改變一個條件。若同時更換節點、DNS、TUN 設定與瀏覽器，就無法判斷究竟是哪項變更影響結果。建議先選擇一個能穩定重現問題的網域，並記錄目前的設定名稱、代理模式、策略群組與所選節點。

  1. 關閉代理後存取同一個網域。關閉客戶端的系統代理與 TUN 接管，確認流量確實恢復直連。直連也出現錯誤時，應優先檢查系統時間、網站憑證與目前網路。
  2. 維持設定不變，只切換節點。某個節點失敗而其他節點正常，通常表示問題出在該出口的 DNS、上游網路、透明檢查設備，或目標網站針對不同地區回傳的伺服器。
  3. 維持節點不變，比較系統代理與 TUN。只有 TUN 模式異常時，檢查 DNS 劫持、Fake-IP 對映、路由衝突與其他網路過濾軟體；只有系統代理異常時，檢查應用程式是否讀取了獨立的代理設定。
  4. 更換瀏覽器或命令列客戶端測試。單一瀏覽器失敗可能與瀏覽器憑證庫、擴充功能、快取的 HSTS 狀態或安全設定有關。所有應用程式都失敗，則更接近系統或網路層問題。
  5. 更換裝置但維持相同網路。只有一台裝置失敗時，應檢查該裝置的時間、憑證庫與網路元件；同一網路中的多台裝置都失敗，則檢查路由器、公共網路驗證與上游閘道。
  6. 更換網路但維持相同裝置。家用網路失敗而行動網路正常，表示問題更可能位於本地 DNS、閘道或電信業者路徑，而不是客戶端設定本身。

如何檢查系統時間、憑證鏈與中間代理

確認系統時間與憑證有效期限

先讓系統與可靠的時間來源同步，再完全結束並重新啟動瀏覽器。開啟憑證詳細資訊，檢查「簽發對象」「簽發者」「有效期限起訖時間」與憑證路徑。若目前日期不在有效期限內，不要只根據頁面提示判斷網站憑證已過期；系統年份錯誤也會產生相同結果。

桌面系統長期停止更新時，根憑證庫也可能過於老舊。應透過作業系統正式的更新機制更新憑證信任資料，而不是從不明頁面下載根憑證手動安裝。若公司或學校網路要求安裝內部根憑證，應先向網路管理員核實憑證指紋資訊、適用裝置與部署範圍，再依組織流程處理。

辨識 HTTPS 檢查與中間代理

企業閘道、家長監護、安全防護軟體與除錯代理可能會終止原始 TLS 連線，再使用本機受信任的憑證，為目標網域簽發臨時憑證。此時憑證的網域可能正確，但簽發者會變成組織名稱或本機安全產品名稱。若對應的根憑證未安裝、已過期，或只安裝在系統憑證庫而未加入瀏覽器的獨立憑證庫，就會出現不受信任錯誤。

一般 Clash 規則分流不會執行這種憑證替換。若看到陌生簽發者，應檢查系統中是否同時執行封包擷取工具、過濾程式、防毒軟體 HTTPS 掃描、企業代理與上游 HTTP 代理。不要為了消除提示而隨意匯入頁面提供的根憑證，因為根憑證一旦受信任，就可能被用來簽發任何網站的憑證。

使用命令查看交握結果

系統已安裝相應工具時，可以查看回應與憑證鏈。以下命令中的網域應替換為實際發生錯誤的網站，執行時請保留憑證驗證，不要加入略過驗證的選項。

curl -Iv https://example.com/
openssl s_client -connect example.com:443 -servername example.com -showcerts

curl 輸出可顯示連線目標、代理通道建立結果與憑證驗證原因；openssl s_client 可顯示伺服器回傳的憑證鏈。使用系統代理時，也應確認命令列工具是否實際讀取代理環境變數，否則測到的可能仍是直連路徑。若測試結果中的憑證簽發者會隨節點變化，表示不同出口到目標網站之間存在路徑差異；若簽發者始終相同而只有某個應用程式失敗，則應轉向檢查應用程式信任庫與憑證固定策略。

Clash 系統代理、TUN 與 DNS 對憑證錯誤的影響

系統代理模式

系統代理通常會讓支援代理設定的應用程式透過 HTTP 或 SOCKS 介面連線。存取 HTTPS 網站時，HTTP 代理一般會透過 CONNECT 建立通往目標主機的通道，TLS 交握仍在應用程式與網站之間進行。若 CONNECT 請求遭上游代理拒絕、替換或要求額外驗證，應用程式可能顯示代理連線失敗，也可能收到閘道產生的憑證頁面。

有些應用程式不讀取系統代理，而是直接連線；有些應用程式則保留獨立的代理設定。出現「瀏覽器正常、特定應用程式失敗」時，要確認該應用程式究竟使用系統代理、TUN，還是自己的網路堆疊。Clash 記錄中沒有對應的連線記錄，往往表示流量根本沒有進入客戶端，而不是規則選擇錯誤。

TUN 模式

TUN 模式會在網路層接管更多流量，適合不支援系統代理的應用程式。它會改變封包路由與 DNS 處理方式，但不會因為接管範圍更廣就自動解密 TLS。若啟用 TUN 後出現憑證網域不相符，重點應檢查 DNS 模式、其他虛擬網卡、路由優先順序，以及裝置上是否同時執行另一個 VPN 或過濾服務。

多個網路元件同時接管流量時，封包可能先進入某個過濾器，再進入 mihomo，回傳路徑也可能不一致。排查時應暫時只保留一個流量接管元件，確認問題消失後再逐一恢復。行動裝置通常只能有一個主要的 VpnService，工作階段被另一個應用程式取代時，也可能表現為斷流，而不是明確的憑證錯誤。

Fake-IP、網域嗅探與憑證網域

Fake-IP 模式會先向應用程式回傳保留位址，再由核心根據對映找到原始網域並建立連線。這個過程本身不會讓網站憑證變成 Fake-IP 位址，因為瀏覽器仍會按照原始存取網域驗證憑證。真正需要注意的是對映過期、DNS 請求繞過客戶端、特殊應用程式直接驗證憑證或連線位址，以及不當的 hosts 覆寫。

網域嗅探可以從 TLS ClientHello 等資訊辨識主機名稱，協助規則比對，但嗅探不是憑證簽發，也不負責改變系統信任。若關閉嗅探後錯誤消失，應進一步檢查規則命中、目標位址還原與特殊網域排除，而不是安裝額外的根憑證。對於區域網路服務、私人網域與使用自簽憑證的裝置，可依實際用途設定直連與 DNS 例外，但憑證仍應透過組織或裝置的正式方式部署。

依風險與成本排序的修復步驟

以下順序從低風險、容易驗證的操作開始，適合大多數「啟用代理後 HTTPS 憑證錯誤」的情況。每完成一步，都要重新測試同一個網域並記錄結果。

  1. 修正日期、時間與時區。開啟自動同步，重新啟動發生錯誤的應用程式。若大量網站同時提示已過期或尚未生效，這一步的優先順序最高。
  2. 確認錯誤是否只發生在單一網站。單一網站異常時，可查看網站憑證有效期限與網域，等待網站管理員修復；不要透過關閉全域驗證來遷就單一網站。
  3. 完成公共網路登入。關閉代理後開啟一般網路檢測頁面，確認飯店、校園或商場網路沒有等待驗證。完成登入後再恢復代理。
  4. 切換至已知正常的節點。若只有特定出口失敗，暫時移除該節點，並向服務提供者回報目標網域、時間與節點名稱。
  5. 檢查 Clash 規則命中與記錄。確認目標網域進入預期的策略群組，避免規則將其送往無法使用的上游代理。記錄中的 DNS 失敗、連線遭拒與 TLS 錯誤應分別處理。
  6. 比較系統代理與 TUN。確認異常是否只存在於其中一種接管方式，再檢查對應的代理設定、虛擬網卡、DNS 與路由，而不是同時修改所有設定。
  7. 停用衝突的網路過濾元件後重新測試。一次只停用一個 VPN、封包擷取代理或 HTTPS 過濾功能，測試後再視需要恢復。
  8. 更新作業系統與瀏覽器。讓根憑證庫、TLS 元件與瀏覽器信任資料維持在支援狀態。舊版應用程式可能無法辨識新的憑證鏈。
  9. 核實組織內部憑證部署。企業或學校網路使用內部 CA 時，應由管理員提供正式安裝方式，不應從錯誤頁面臨時下載憑證。
  10. 最後再檢查或重建客戶端設定。只有記錄顯示 DNS、規則或上游代理設定異常時，才需要調整 YAML、訂閱或設定檔。重新匯入同一份有問題的設定不會改變憑證鏈。

常見誤區與進一步判斷

反覆切換全域、規則與直連模式

模式切換只能改變流量選用哪個策略，不會修復系統時間或根憑證庫。它的價值在於對照：直連正常而代理失敗，表示應檢查出口與代理路徑；三種模式都失敗，則應先處理裝置或網路環境。測試後應恢復原有模式，避免後續結果混亂。

把所有 TLS 錯誤都歸咎於 DNS

DNS 確實可能將網域指向錯誤伺服器，進而造成網域不相符，但「不受信任的簽發者」通常更指向憑證鏈或 HTTPS 檢查。先查看實際憑證內容，再決定是否清除 DNS 快取、切換解析器或檢查 Fake-IP。只修改 DNS 無法修復過期憑證與遺漏的中繼憑證。

看到自簽憑證就直接安裝

家用路由器、開發環境與企業內部服務可能使用自簽憑證，但安裝前必須確認服務歸屬與憑證來源。公共網站突然出現自簽憑證通常不是正常現象。若憑證來自陌生閘道，應停止輸入帳號資訊，並檢查網路驗證、代理設定與裝置中的根憑證是否有變更。

只有某個應用程式失敗

銀行、付款、串流媒體與部分企業應用程式可能使用憑證固定，只接受預先內建的伺服器公開金鑰或憑證鏈。即使系統信任某個中間代理簽發的憑證，應用程式仍會拒絕連線。這通常表示流量路徑中存在 TLS 檢查，或目標連線遭到替換。應讓該應用程式避開相關檢查設備，或依照組織網路規範設定，而不是嘗試修改應用程式的驗證邏輯。

完整的判斷過程可以歸納為四個問題：憑證是誰簽發的、錯誤是否會隨裝置改變、錯誤是否會隨網路改變、錯誤是否會隨節點或接管模式改變。回答這四項，通常就能將範圍縮小至系統時間與信任庫、目標網站、目前網路、特定代理出口或本機流量接管元件。修復目標是恢復正確的憑證鏈與連線路徑，而不是讓警告頁面暫時消失。