啟用 Clash、Clash Meta（mihomo）或其他代理用戶端後，瀏覽器可能顯示「連線不是私人連線」「憑證無效」「憑證已過期」或 NET::ERR_CERT_AUTHORITY_INVALID。這些提示看似都與 HTTPS 有關，但觸發位置可能完全不同：有時是電腦日期偏差，導致憑證被判定為尚未生效；有時是目標網站的憑證鏈不完整；也可能是目前網路檢查了 TLS 連線，或代理規則將請求送往不合適的出口。
排查時不要一看到憑證警告就直接點選繼續瀏覽。HTTPS 憑證用於確認造訪的網域、連線的加密身分與憑證簽發關係，忽略警告可能掩蓋真正的網路攔截、錯誤出口或網域劫持。更有效率的做法是先記錄錯誤原文與出問題的網域，再逐層比較「關閉代理」和「啟用代理」時的結果，最後才檢查用戶端的憑證相關選項。
先判斷：憑證錯誤究竟代表什麼
瀏覽器造訪 HTTPS 網站時，會驗證憑證是否涵蓋目前網域、是否仍在有效期限內、是否能沿著受信任的憑證鏈找到根憑證，以及連線過程中的主機名稱是否與憑證相符。代理用戶端通常負責連線轉送與策略選擇，並不等同於 HTTPS 解密工具。一般 HTTP 代理或 SOCKS 代理可以轉送連線；當瀏覽器透過代理建立至目標網站的 TLS 連線時，瀏覽器仍會看到目標網站提供的憑證。
因此，「開啟 Clash 後出現憑證錯誤」不等於「Clash 修改了憑證」。需要區分兩種連線方式。第一種是代理只轉送 TCP，或透過通道傳輸 HTTPS，憑證通常由目標網站直接回傳。第二種是網路設備、企業安全軟體或某些除錯工具主動檢查 HTTPS 內容；它們可能在本機安裝受信任的根憑證，並為造訪的網域產生替代憑證。若該根憑證未受目前瀏覽器信任，就會出現憑證簽發者不受信任的提示。
Clash Meta 的 TUN 模式也不會自動變更所有 HTTPS 憑證。TUN 主要透過虛擬網卡接管系統流量，再依據設定中的路由、DNS 與代理規則處理連線。它改變的是流量進入代理核心的路徑；真正需要檢查的仍是最終出口、DNS 解析、規則命中情況，以及是否存在額外的 TLS 檢查元件。
第一步：檢查系統時間與時區
憑證有效期限取決於裝置目前的時間。若系統日期快了或慢了數小時、數天，瀏覽器可能會將正常憑證判定為「尚未生效」或「已經過期」。時區設定錯誤也會造成相同現象，尤其是在雙系統、虛擬機器、休眠喚醒或主機板時鐘異常之後。這個問題與代理規則無關，但常在剛切換網路環境後才被發現，因此很容易被誤認為是 Clash 導致的。
- 開啟系統的日期與時間設定，啟用自動設定時間，並確認時區與所在地一致。
- 手動同步一次時間，等待系統顯示同步成功後，完全關閉再重新開啟瀏覽器。
- 造訪兩個使用不同憑證服務商的網站進行比較。若多個網站同時提示憑證尚未生效或已過期，應優先處理系統時間。
如果只有一個網站發生錯誤，而其他 HTTPS 網站正常，時間問題的可能性就會降低。此時應繼續查看憑證詳細資訊，而不是反覆切換代理模式。行動熱點、家用寬頻和公司網路也可作為對照環境，但比較前應盡量使用相同的裝置時間與瀏覽器設定。
第二步：查看憑證網域、有效期限與簽發者
在瀏覽器網址列的安全性資訊中開啟憑證詳細資料，重點查看三個欄位。第一是主旨或使用者名稱，確認憑證是否涵蓋目前造訪的網域；萬用字元憑證只涵蓋符合規則的子網域，不能涵蓋完全不同的主網域。第二是有效期限，確認目前時間位於生效時間與失效時間之間。第三是簽發者與憑證鏈，查看中繼憑證是否完整，以及根憑證是否受到作業系統或瀏覽器信任。
如果憑證顯示的網域與網址列中的網域完全不一致，可能是 DNS 解析到錯誤伺服器、代理出口回傳異常頁面，或網路路徑中存在攔截。若網域一致但簽發者變成公司閘道、防毒軟體或本機除錯工具的名稱，則應檢查這些元件是否啟用了 HTTPS 掃描，以及其根憑證是否正確部署。不要為了消除提示而隨意安裝陌生根憑證；根憑證擁有較高的信任權限，來源與用途都應明確。
| 現象 | 優先懷疑方向 | 對照方法 |
|---|---|---|
| 多個網站同時過期 | 系統時間、時區或本機憑證存放區 | 同步時間並改用其他瀏覽器測試 |
| 只有一個網域不相符 | DNS、錯誤出口或網站端設定 | 比較關閉代理、行動網路與不同解析結果 |
| 簽發者顯示企業閘道 | HTTPS 檢查或安全軟體攔截 | 查看網路政策與安全軟體的 TLS 掃描設定 |
| 只有啟用代理後才發生 | 規則命中、出口節點或 DNS 路徑 | 暫時切換節點並查看連線記錄 |
第三步：用最少變因比較代理與直連
排查代理問題時，變因越少越容易得出結論。先關閉系統代理或暫停用戶端，使用同一個瀏覽器造訪同一個 URL，記錄是否仍然發生錯誤。接著重新啟用代理，但保持同一個節點、同一個 DNS 設定與同一個瀏覽器視窗。若錯誤只在代理啟用時出現，再切換到另一個已知可用的節點。每次只變更一個條件，避免同時修改規則模式、TUN、DNS 與瀏覽器擴充功能。
在用戶端的連線或記錄頁面中，觀察目標網域是否命中預期規則，以及實際使用了哪個策略群組和節點。在規則模式下，網域可能先符合特定規則，再交由代理、直連或拒絕策略處理；全域模式則會將更多請求交給選定的代理群組，適合用於短時間對照。直連模式有助於確認網站本身是否正常，但不應將其視為長期繞過網路政策的方案。
也要留意 DNS 解析的位置。瀏覽器、系統、Clash 核心與遠端代理可能使用不同的解析路徑。解析結果不同，可能導致連線到不同的 CDN 節點或錯誤位址。若只有某個網域異常，可以先清除瀏覽器 DNS 快取，再檢查設定中的 DNS 模式、nameserver、fallback 與 fake-ip 相關設定是否符合目前的網路環境。修改設定後，務必確認實際啟用的是該檔案，而不是編輯了尚未載入的副本。
第四步：檢查 TLS、憑證存放區與 HTTPS 掃描
當憑證簽發者指向本機軟體或組織閘道時，請檢查系統安全軟體、企業代理、家長監護程式與除錯代理的 HTTPS 掃描功能。部分軟體會在瀏覽器與目標網站之間建立兩段 TLS 連線，並使用自己的根憑證簽發本機替代憑證。若這是受管理裝置上的明確網路政策，應聯絡管理員確認根憑證部署與憑證輪換狀態；若是個人裝置上的軟體功能，則可在了解影響後關閉 HTTPS 掃描，再重新測試。
瀏覽器不一定完全使用系統憑證存放區。有些瀏覽器會啟用自己的憑證管理、加密 DNS 或安全性政策；因此系統層級看似信任的憑證，在瀏覽器中仍可能不被接受。測試時可使用另一個乾淨的瀏覽器設定檔進行比較，但不要把「換瀏覽器就能開啟」視為問題已經解決。這只表示兩個瀏覽器的憑證存放區、擴充功能或網路設定存在差異。
如果錯誤訊息涉及 TLS 版本、交握失敗或連線遭重設，而不是憑證簽發者不受信任，應將排查重點放在出口節點、目標網站相容性與中間網路設備。此時反覆匯入根憑證通常沒有幫助。對於需要用戶端憑證的網站、企業內網或採用雙向 TLS 的服務，還要確認代理鏈路是否支援該網站要求的驗證方式。
TUN 模式的專項檢查
TUN 模式會將系統流量導入虛擬網路介面；即使瀏覽器沒有設定傳統 HTTP 代理，也可能受到核心規則影響。出現憑證錯誤時，可以暫時關閉 TUN，只保留系統代理進行比較；也可以保持 TUN 開啟，切換到直連策略測試一次。這個過程的目的是定位流量路徑，不是建議固定使用某一種模式。
- 確認 TUN 虛擬網卡已正常建立，且未與其他 VPN、虛擬機器網卡或網路加速軟體發生衝突。
- 檢查 DNS 是否由目前的核心接管，以及 fake-ip 映射是否遭瀏覽器、系統安全軟體或區域網路設備異常處理。
- 查看目標網域的規則命中記錄，確認請求沒有因規則集過期而被送往錯誤的策略群組。
- 若關閉 TUN 後恢復正常，請繼續比較 DNS、路由與網卡優先順序，而不是直接重設所有設定。
建議的修復順序與安全界線
可以將整套流程濃縮成一條穩定的檢查鏈：先記錄錯誤，再校準時間；接著查看憑證網域、有效期限與簽發者；然後使用同一個網站比較直連與代理；再檢查節點、規則、DNS 與 TUN 路徑；最後處理瀏覽器、系統或安全軟體中的憑證存放區。每完成一個步驟，都重新開啟頁面並記錄結果，才能知道哪項變更真正影響了連線。
修復時不要把「忽略憑證錯誤」當作一般解決方案，也不要將陌生根憑證匯入系統來換取頁面可存取。對於公司裝置，憑證與代理政策可能由管理員統一設定，個人修改可能造成合規或存取問題。使用公共網路時，若憑證簽發者異常，應先改用可信任的網路驗證；若只有單一網站長期異常，則應聯絡網站維護者確認伺服器憑證鏈與網域設定。
記錄錯誤代碼
→ 校準系統時間與時區
→ 查看憑證網域 / 有效期限 / 簽發者
→ 以同一個網站比較直連與代理
→ 檢查節點、規則命中與 DNS
→ 比較 TUN 開關與瀏覽器憑證設定
→ 僅在來源明確時處理 HTTPS 檢查憑證完成排查後，建議恢復原本的代理模式與安全設定，並清除為測試而暫時新增的憑證、瀏覽器擴充功能或規則。若問題只在某個節點出現，可以暫時更換節點並向服務提供者回報；若所有節點和多個網路都出現相同錯誤，則更應檢查裝置時間、瀏覽器環境或目標網站憑證。透過這種分層定位，HTTPS 錯誤就能從模糊的「代理無法使用」，縮小到具體的憑證、解析、規則或網路環節。