Clash 代理後 HTTPS 憑證錯誤：原因判斷與分層排查方法

啟用 Clash 的系統代理或 TUN 模式後，瀏覽器突然出現「連線並非私人連線」、「憑證授權單位不明」、「憑證名稱不相符」等提示，容易讓人直接將問題歸咎於用戶端。實際排查時，首先要區分兩件事：流量是否因代理而改走不同路徑，以及 HTTPS 連線在哪一層終止。一般 Clash、Clash Meta（mihomo）核心通常負責轉送連線及依規則選擇出口，不會在本機解密一般網站的 TLS 內容。只要設定中沒有額外的流量嗅探、腳本或中間人代理元件，瀏覽器看到的憑證原則上仍應由目標網站提供。

因此，憑證錯誤較常見的來源包括系統時間偏差、網站憑證鏈設定異常、DNS 指向錯誤、代理出口回傳攔截頁面、公司或校園網路進行 HTTPS 檢查、安全軟體插入本機憑證，以及瀏覽器使用獨立憑證庫。正確順序不是反覆切換節點，而是先記錄錯誤，再透過對照測試確認故障範圍。

一、先了解 HTTPS 憑證與 Clash 的位置

存取 HTTPS 網站時，瀏覽器會核對憑證中的網域、有效期限、簽發鏈與用途。憑證必須涵蓋目前存取的主機名稱，目前時間也必須落在有效期限內，憑證鏈最終還要連接到系統或瀏覽器信任的根憑證。任何一項不成立，瀏覽器都會阻擋或發出警告。

Clash 的系統代理通常會讓支援系統代理的應用程式，將 HTTP 或 SOCKS 連線交給本機監聽連接埠；TUN 模式則透過虛擬網路介面接管更多 IP 流量。兩種方式改變的是連線入口與路由範圍，不代表會自動替換網站憑證。代理節點或其上游網路仍可能改變解析結果、阻斷目標位址，或回傳認證頁與風險提示頁。此時瀏覽器存取的網域沒有變化，但收到的內容來自另一台伺服器，因此可能呈現憑證名稱不相符或簽發者異常。

還要區分 TLS 憑證與訂閱網址的關係。訂閱只是向用戶端提供代理節點、策略組與規則等設定。訂閱下載失敗並顯示憑證錯誤時，應個別檢查訂閱網域、系統時間與網路路徑，不能據此判斷所有節點都已失效。反過來，訂閱更新成功也只能表示該網址可存取，不能證明每個目標網站的 TLS 鏈都正常。

二、用四組對照測試縮小故障範圍

排查前先暫停涉及帳號登入、付款或管理後台的操作。接著選擇一個平時穩定的 HTTPS 網站和一個發生錯誤的網站，分別進行以下對照。每次只變更一個條件，避免同時切換瀏覽器、節點、DNS 與 TUN，導致結果無法解釋。

1. 開啟與關閉代理的對照：關閉 Clash 的系統代理和 TUN 後重新存取。如果直連正常、代理路徑出錯，重點檢查節點出口、規則命中、DNS 與中間設備；如果兩種狀態都出錯，優先檢查系統時間、瀏覽器憑證庫和目標網站。
2. 單一網站與所有網站的對照：只有一個網域失敗，通常較接近網站憑證、網域解析或特定規則問題；大量無關網站同時失敗，則更像是本機時間、根憑證庫、公司網路檢查或安全軟體造成的共通故障。
3. 單一瀏覽器與所有應用程式的對照：只有某個瀏覽器失敗時，檢查該瀏覽器的安全政策、擴充功能、DNS over HTTPS 設定和獨立憑證庫。瀏覽器、命令列與其他應用程式都失敗時，問題更可能位於系統或網路路徑。
4. 目前網路與備用網路的對照：在符合使用條件的情況下切換到另一條可信任的網路。若公司或校園網路出錯，而其他網路正常，可能存在認證入口、閘道檢查或出口政策；如果所有網路的結果都相同，應回到本機和設定層檢查。

測試時還要確認 Clash 面板中的實際規則命中情況。同一個網域可能依規則走代理，相關的圖片、介面或登入網域卻走直連。網頁主文件可以開啟，不代表頁面所有 HTTPS 請求都經過同一個出口。若開發人員工具只顯示某個子網域憑證失敗，應記下這個完整主機名稱，再查看它命中了哪條規則與哪個策略組。

三、依系統、瀏覽器與網路層逐項檢查

1. 校正系統日期、時間與時區

憑證驗證依賴準確的時間。主機板電池電力不足、虛擬機器暫停後恢復、雙系統切換或手動設定時區，都可能讓時間偏差數小時甚至數年。先開啟系統自動設定日期和時間，再執行一次時間同步；同時核對時區，不要只看工作列顯示的時數。時間恢復後，應完全關閉瀏覽器並重新啟動，讓新的 TLS 連線重新建立。

如果每次重新啟動後時間都再次錯誤，應處理系統時間來源或硬體時鐘問題，而不是持續在瀏覽器中新增例外。憑證提示中的「尚未生效」和「已經過期」都可能由本機時間造成，不能只根據頁面文字判斷憑證確實失效。

2. 檢查憑證網域與簽發鏈

開啟瀏覽器提供的憑證檢視器，重點記錄「簽發給」、「簽發者」、「有效期限」和憑證路徑。目前存取的網域與憑證涵蓋網域不一致，常見於 DNS 指向錯誤伺服器、透明閘道回傳認證頁，或網站本身部署遺漏。若簽發者顯示為公司、安全產品或本地網路設備名稱，表示連線可能經過 HTTPS 檢查元件；這類憑證是否應受信任，必須由設備或網路管理員確認。

憑證路徑缺少中繼憑證時，部分瀏覽器可能依靠快取補齊，但其他應用程式會直接失敗。這可以解釋「瀏覽器能開啟，命令列工具卻出錯」或相反的情況。此時應修復伺服器端憑證鏈，或更新系統憑證庫與應用程式執行環境，不應將關閉憑證驗證當作長期方案。

3. 比對瀏覽器政策與憑證庫

不同瀏覽器可能採用系統憑證庫，也可能維護額外的信任政策。企業管理政策、家長監護、安全軟體的 HTTPS 掃描和舊版執行環境都可能影響結果。先使用瀏覽器的訪客設定檔或建立測試設定檔，以排除擴充功能影響，再檢查瀏覽器是否顯示「由組織管理」。如果設備屬於公司或學校，應依管理員提供的正式說明處理，不要自行刪除組織憑證。

啟用加密 DNS 的瀏覽器還可能繞過 Clash 設定中的 DNS 方案，使瀏覽器解析結果與其他應用程式不同。排查階段可以暫時讓瀏覽器跟隨系統解析，再與 Clash 的 DNS 記錄比對。這裡的目標是確認解析路徑，不是簡單認定某一種 DNS 方式更好。

4. 排除認證入口與中間設備

飯店、機場、校園和訪客網路常要求先通過網頁認證。設備尚未完成認證時，閘道可能將請求導向登入頁；HTTPS 請求無法像一般 HTTP 那樣順利跳轉，便可能觸發網域不相符。可以先關閉代理，在確認網路可信任的前提下開啟網路提供的認證入口，完成認證後再恢復 Clash。

路由器的內容過濾、家庭安全功能、公司閘道和端點防護軟體也可能檢查加密連線。若憑證簽發者突然變成本地產品名稱，且關閉對應的受管理網路後恢復，應從該產品的管理政策著手。安裝來源不明的根憑證會擴大信任範圍，不適合作為快速修復手段。

四、檢查 Clash 規則、DNS、節點與 TUN

確認規則命中與策略出口

在 Clash 用戶端的連線記錄中找到出錯網域，查看它命中了直連、代理還是拒絕規則。規則會由上到下比對，較早的網域、後綴或規則集可能覆蓋後續設定。如果目標網域被誤送到不合適的出口，可以先暫時切換到明確的策略進行驗證，再回到設定中修正規則順序。不要長期依賴全域模式掩蓋規則問題。

同一個服務往往使用多個網域，例如登入、靜態資源、介面和憑證狀態查詢網址。只調整頁面主網域可能不夠。應根據連線記錄確認相關網域是否被分配到不同出口，尤其要留意登入跳轉後才出現錯誤的情況。完整的規則概念和策略組說明可繼續查看使用手冊。

核對 DNS 解析結果

啟用代理後才發生憑證名稱不相符時，DNS 是重要的檢查點。Clash Meta（mihomo）可以設定不同的 DNS 上游、規則化解析以及 fake-ip 或 redir-host 等模式。設定方式本身不會憑空製造錯誤憑證，但錯誤的上游回應、污染結果、失效快取或不相符的分流路徑，可能將網域導向錯誤位址。

先在 Clash 記錄中查看查詢與連線目標，必要時清除作業系統和瀏覽器的 DNS 快取，然後重新測試。若設定使用 fake-ip，應以 Clash 內部對映和最終連線記錄為準，不要將保留位址形式的 fake-ip 直接視為網站真實伺服器。修改 DNS 後應重新啟動核心或重新載入設定，確保舊連線與快取不再影響結果。

切換節點只能作為定位動作

如果同一份設定下只有一個節點導致憑證異常，而其他可信任節點正常，表示故障與該出口或其上游路徑有關。可以記錄節點、目標網域和發生時間，暫停使用該路徑。若所有節點都失敗，而直連正常，則繼續檢查共同使用的 DNS、規則提供者、鏈式代理或本機中間軟體。

測速延遲正常不代表 TLS 一定正常。延遲測試通常只驗證某個位址的回應速度，並不涵蓋目標網站的憑證鏈、SNI、DNS 結果和完整頁面請求。因此不要將「節點有延遲數值」當作已排除憑證問題的依據。

分別測試系統代理與 TUN 模式

系統代理正常而 TUN 出錯時，重點檢查 TUN 的 DNS 劫持、路由、權限和其他虛擬網卡；TUN 正常而系統代理出錯時，則檢查應用程式是否正確讀取系統代理、瀏覽器是否使用獨立代理設定，以及本機監聽連接埠是否被其他程式占用。切換模式前先停止正在進行的下載和登入操作，切換後重新建立連線。

不要同時開啟多個代理用戶端、瀏覽器代理擴充功能和重複的 TUN 軟體。它們可能形成代理鏈或迴圈，讓流量先後經過多個本機連接埠。排查時只保留一個明確入口，並在用戶端中確認 HTTP、SOCKS 或 mixed 連接埠與系統設定一致。完成基礎設定可參考Clash 使用教學。

五、常見瀏覽器錯誤代碼如何判斷

錯誤代碼文字在 Chrome、Edge、Firefox、Safari 之間並不完全一致，但判斷面向相同。查看代碼時，應同時記錄存取網址和憑證資訊。若頁面網址已從原網域跳轉到認證頁或其他網域，問題可能出在網路認證流程；若網址維持不變但憑證屬於完全無關的網域，應停止存取並檢查解析與中間設備。

六、安全處理界線與最終檢查清單

憑證警告是瀏覽器對連線身分的判斷結果，不適合透過長期關閉 HTTPS 驗證來消除。命令列工具中的略過驗證參數、瀏覽器的強制繼續入口，以及手動信任未知根憑證，都可能讓後續連線失去關鍵保護。測試可以協助定位，但測試結果不應以提交密碼、驗證碼或付款資訊為代價。

如果問題來自目標網站的憑證過期或憑證鏈設定錯誤，用戶端通常只能等待網站修復或聯絡維護者。如果問題來自受管理設備，應由組織管理員確認根憑證與檢查政策。如果問題集中在某個節點，應停止使用該路徑，並向服務提供者回報網域、時間和錯誤類型。若問題來自本機時間、DNS 快取、重複代理或錯誤規則，則修正後重新載入設定，並使用原本出錯的網站重新測試。

恢復使用前再核對一次

• 系統日期、時間和時區正確，自動同步狀態正常。
• 瀏覽器網址列中的網域與憑證涵蓋範圍一致。
• 憑證簽發者符合預期，憑證鏈能夠連接到受信任的根憑證。
• Clash 連線記錄中的規則、策略組和實際出口符合設定意圖。
• DNS 解析路徑清楚，瀏覽器與系統沒有意外使用不同的上游。
• 系統代理與 TUN 沒有和其他代理工具、虛擬網卡形成重複接管。
• 切換網路或節點後的測試結果已完成記錄，能夠穩定重現或確認恢復。

完成修復後，先用一般公開頁面進行驗證，再測試原先出錯的網域。若頁面涉及登入，應確認網址、憑證簽發者和連線狀態都正常後再輸入資訊。憑證問題看似集中在瀏覽器提示頁，實際上可能跨越時間、解析、規則、出口和網路管理等多個層次；保持一次只變更一個變數，通常比連續重新安裝用戶端更快找到原因。