先判斷憑證錯誤發生在哪一層
Clash 開啟後，瀏覽器出現「連線並非私密連線」「憑證簽發者未知」「憑證名稱不相符」或 TLS 交握失敗，並不代表 Clash 用戶端直接修改了網站憑證。標準的 HTTP CONNECT 或 SOCKS5 代理通常只負責建立與目標伺服器之間的傳輸通道，HTTPS 加密與憑證驗證仍在瀏覽器和目標網站之間進行。正常情況下，瀏覽器看到的憑證仍應由目標網站及其受信任的憑證機構簽發。
Clash、Clash Meta（mihomo）以及以這些核心為基礎的用戶端，啟用系統代理或 TUN 模式本身，都不要求為一般 HTTPS 存取安裝通用根憑證。若憑證簽發者突然變成公司閘道、安全檢查程式、路由器或陌生機構，應優先檢查代理上游與本機網路中介層，而不是直接刪除訂閱或反覆重新安裝用戶端。
開始排查前，先記錄三個條件：哪些網站發生錯誤、關閉 Clash 後是否立即復原，以及同一網路中的另一台裝置是否也會出錯。只有單一網站失敗，較像是網站憑證、網域解析或規則分流問題；大量網站同時失敗，則更常見於系統時間、憑證儲存區、上游代理與網路檢查設備；若只有某個瀏覽器失敗，應關注該瀏覽器的憑證儲存區、擴充功能與安全設定。
常見錯誤與優先檢查項目
- 憑證尚未生效或已經過期：先檢查系統日期、時間、時區以及自動校時狀態。
- 憑證簽發者不受信任：檢查憑證鏈是否完整，以及是否存在企業 HTTPS 檢查或本機過濾程式。
- 憑證名稱不相符：檢查 DNS 解析、透明閘道、登入驗證頁面與規則分流結果。
- 交握失敗或協定錯誤：檢查代理節點可用性、上游協定參數、TLS Server Name、網路阻擋與用戶端記錄。
- 只有部分子資源失敗：在瀏覽器開發人員工具中確認具體失敗網域，避免把第三方介面故障誤判為主站憑證問題。
檢查系統時間、時區與自動校時
TLS 憑證具有明確的生效時間與到期時間。裝置時間若相差數小時、數天甚至數年，瀏覽器就會將仍然有效的憑證判定為尚未生效或已經過期。筆電長時間斷電、主機板時鐘異常、虛擬機器暫停後恢復、雙系統切換，以及手動修改時區，都可能造成這類現象。開啟代理後剛好存取先前未連線的網站，錯誤便集中出現，因此容易被誤認為是 Clash 所致。
- 確認系統顯示的日期、時間與所在時區正確，尤其檢查 UTC 偏移是否符合目前位置。
- 開啟系統的自動設定時間與自動設定時區功能，然後主動執行一次時間同步。
- 完全退出瀏覽器後重新開啟，避免舊 TLS 工作階段或錯誤頁面繼續留在分頁中。
- 若自動同步失敗，暫時關閉代理後再同步一次，並檢查時間服務是否被規則錯誤轉送。
Windows 時間檢查
在 Windows 設定中進入「時間與語言」，確認自動設定時間與時區。也可以在具備相應權限的終端機中查詢同步狀態：
w32tm /query /status
w32tm /resync如果系統提示時間服務未執行，應先在服務管理中檢查 Windows Time 服務。網域環境中的裝置可能由組織的時間伺服器統一管理，此時不宜任意更改同步來源。
macOS 與 Linux 時間檢查
macOS 可在「系統設定—一般—日期與時間」中啟用自動設定。使用 systemd 的 Linux 發行版則可查看目前時間狀態：
timedatectl status
sudo timedatectl set-ntp true容器或虛擬機器中的應用程式通常會沿用主機時間。若只有虛擬機器內部出錯，應同時核對主機與來賓系統，確認還原快照後時間已重新同步。
核對瀏覽器看到的憑證鏈
憑證鏈通常由網站憑證、中繼憑證與受信任的根憑證組成。瀏覽器會檢查存取網域是否包含在憑證的主體別名中、憑證是否仍在有效期限內、簽章鏈是否能連接到本機信任的根憑證，以及憑證用途是否適合伺服器身分驗證。排查時不能只看錯誤頁標題，應開啟憑證檢視器並記錄具體欄位。
首先查看網站憑證的「簽發給」或主體別名，確認其中包含目前存取的網域。接著查看「簽發者」，並與關閉 Clash 後看到的結果比較。如果兩種狀態下的憑證主體、序號資訊或簽發者明顯不同，表示流量路徑中存在能夠終止並重新建立 TLS 的中介層。它可能來自企業網路的合規檢查、家長控制、安全軟體的 HTTPS 掃描、除錯代理，或訂閱中設定的上游代理服務。
如果憑證始終相同，但某個瀏覽器仍提示不受信任，應比較不同瀏覽器的結果。部分瀏覽器主要使用系統憑證儲存區，另一些環境可能維護獨立的憑證資料庫。系統更新不完整、根憑證清單長期未更新，或瀏覽器設定損壞，都可能使同一張憑證在不同程式中得到不同判定。
使用命令列查看交握結果
命令列工具有助於區分瀏覽器設定與系統網路問題。以下請求分別測試預設連線，以及透過本機 HTTP 代理埠連線；埠號應依用戶端實際設定修改：
curl -Iv https://example.com/
curl -Iv --proxy http://127.0.0.1:7890 https://example.com/比較輸出中的憑證主體、簽發者、有效期限與最終錯誤。如果直連成功而明確指定代理失敗，應繼續檢查 Clash 選取的節點、代理群組與上游鏈路；如果兩者都失敗，則更可能是系統時間、憑證儲存區、DNS 或目前網路的問題。測試實際故障網域時，應避免在公開記錄中暴露包含帳號、權杖或查詢參數的完整網址。
排查 Clash 代理鏈路與規則分流
Clash 的規則模式會依照設定檔中的規則順序，為請求選擇代理群組、具體節點或 DIRECT。瀏覽器載入一個頁面時，主網域、靜態資源、登入介面與內容傳遞網域可能分別命中不同規則。若主頁面經由代理，而驗證介面卻直連至受限制或遭重新導向的地址，瀏覽器可能呈現憑證錯誤、登入迴圈或部分資源交握失敗。
開啟用戶端連線記錄與核心日誌，找到錯誤時間附近的目標網域，確認命中的規則、出口策略與節點。Clash Meta（mihomo）設定通常可透過面板查看即時連線；不同圖形化用戶端的入口名稱可能是「連線」「日誌」「規則」或「代理」。重點不是反覆切換全域模式，而是確認具體網域實際經過哪條路徑。
依最少變數切換策略
- 維持原有網路不變，將故障網域暫時切換為 DIRECT，重新開啟瀏覽器測試。
- 若直連正常，再讓該網域經過另一個確認可用的節點，觀察憑證是否恢復。
- 若所有節點都失敗，檢查訂閱中是否設定了統一的鏈式代理、外部控制程式或額外上游。
- 若只有一個節點失敗，查看該節點的伺服器位址、埠號、傳輸參數、TLS Server Name 與系統時間。
- 測試完成後恢復規則模式，避免全域策略掩蓋原本的規則順序問題。
節點協定本身可能使用 TLS 連線至代理伺服器，這一層的憑證與瀏覽器存取網站時看到的憑證並非同一個物件。節點日誌中的「certificate verify failed」「x509」或「hostname mismatch」，通常表示用戶端驗證代理伺服器憑證失敗；瀏覽器頁面中的憑證警告，則指向目標網站連線。區分這兩層，就能避免把節點伺服器憑證問題誤認為網站憑證問題。
如果節點設定使用網域作為伺服器位址，TLS Server Name 通常應與伺服器憑證涵蓋的名稱一致。任意改成 IP 位址、填入另一個網域，或上游伺服器憑證已經更換，都可能導致節點交握失敗。這類參數應以服務提供者發布的有效設定為準，不應透過關閉節點憑證驗證來維持連線。
系統代理與 TUN 模式的差異
系統代理主要影響遵循作業系統代理設定的程式；TUN 模式則透過虛擬網卡接管更廣泛的 IP 流量，並配合路由與 DNS 處理不讀取系統代理的應用程式。切換至 TUN 後，大量程式同時開始出錯，常見原因包括 DNS 劫持設定衝突、其他 VPN 同時修改路由、安全軟體過濾虛擬網卡，或區域網路驗證流量遭到接管。
TUN 模式不會因為接管範圍更廣就自動解密 HTTPS。如果只有開啟 TUN 才出現憑證名稱不相符，可暫時關閉 TUN、保留系統代理進行對照，再檢查 fake-ip、DNS 監聽、路由排除項目以及其他 VPN。一次只變更一個選項，才能判斷差異是由路由、解析還是上游節點造成。
識別 DNS 異常、驗證頁面與網路劫持
憑證名稱不相符，經常表示瀏覽器連線到了錯誤的伺服器。公共 Wi-Fi、飯店與校園網路可能要求先完成網頁驗證。裝置首次連線時，閘道會將一般請求導向登入頁；如果 HTTPS 請求也遭到攔截，驗證頁便無法提供目標網域的合法憑證，瀏覽器於是顯示憑證警告。此時應關閉代理，前往作業系統提供的網路檢測頁面或一般 HTTP 頁面完成驗證，再重新啟用 Clash。
DNS 回傳錯誤位址也會造成相同現象。關閉與開啟 Clash 時，解析可能分別由系統 DNS、用戶端 DNS 模組、遠端解析器或 fake-ip 機制處理。若某個網域只在其中一種狀態下出錯，可分別查詢解析結果，並與可信網路中的結果比較。請注意，大型網站可能使用地區化位址，IP 不完全相同不一定代表異常；關鍵在於位址歸屬、憑證網域與存取結果是否合理。
nslookup example.com
dig example.com A
dig example.com AAAA家庭路由器的安全過濾、電信網路中的異常重新導向、公司出口的 TLS 檢查，以及本機除錯代理，都可能改變連線路徑。最有效的交叉測試，是讓同一部裝置暫時連線至另一個可信網路，並維持 Clash 設定不變。如果更換網路後立即恢復，應檢查原路由器的 DNS、存取控制、韌體設定與上網驗證狀態；如果所有網路都失敗，則回到本機憑證儲存區、用戶端設定與安全程式繼續排查。
本機過濾程式與企業憑證
部分企業環境會透過受管理的根憑證檢查 HTTPS 流量。在組織管理的裝置上，這張憑證通常由管理員統一部署，瀏覽器會顯示組織指定的簽發者。若憑證過期、部署範圍遺漏，或瀏覽器使用獨立憑證庫，就可能出現信任錯誤。此時應記錄憑證指紋以外的主體、簽發者與有效期限資訊，交由網路管理員確認，不應自行刪除組織憑證。
個人裝置若曾安裝封包擷取除錯工具、流量分析工具或具備 HTTPS 掃描功能的安全程式，也應檢查它們是否仍在執行。退出介面不一定代表背景服務與本機代理已停止，可在系統代理設定、處理程序清單與憑證管理器中核對。確認軟體來源與用途後，再透過其正式解除安裝流程移除相關網路元件。
分步復原與結果驗證
憑證故障排查應從影響最小、最容易復原的操作開始。直接重設所有網路設定或刪除全部憑證，會破壞現有環境，也會遺失關鍵證據。以下順序適用於多數開啟 Clash 後出現 HTTPS 錯誤的情境。
- 記錄錯誤：保存瀏覽器錯誤代碼、故障網域、憑證主體、簽發者、有效期限與發生時間。
- 校準時間：確認日期、時區與自動同步狀態，接著重新啟動瀏覽器。
- 進行開關對照：分別測試關閉 Clash、僅使用系統代理、僅使用 TUN 或維持原有模式，記錄每次結果。
- 查看連線日誌：確認目標網域命中的規則、代理群組、節點與 DNS 解析路徑。
- 替換單一出口：在不變更其他設定的情況下切換節點，判斷故障是否跟隨節點。
- 更換可信網路：排除路由器、公共網路驗證與出口檢查設備的影響。
- 檢查中介程式：核對其他 VPN、本機除錯代理、安全過濾與企業管理政策。
- 還原設定：若近期修改過 DNS、TUN 或規則，使用修改前保留的設定逐項復原。
哪些情況應聯絡網站或服務提供者
如果同一網站在多部裝置、多個網路、直連與代理環境下，都顯示相同的過期憑證或不完整憑證鏈，問題可能位於網站伺服器端，應等待網站維護或聯絡網站管理員。若錯誤只跟隨某個代理節點，且節點日誌明確顯示伺服器憑證名稱或有效期限異常，應向節點設定提供者回報發生時間、節點名稱與日誌摘要。
回報時不需要提交完整訂閱網址、驗證金鑰或帳號資訊。提供用戶端核心版本、作業系統、連線模式、錯誤發生時間、目標網域、規則命中結果與經過處理的日誌即可。清楚區分「節點 TLS 交握失敗」與「瀏覽器存取網站時出現憑證警告」，能大幅縮短定位時間。
復原後仍需檢查的設定
故障消失後，不要立即將原因歸結為偶發現象。重新啟用原本的規則模式，分別測試常用網站、軟體更新、登入介面與不遵循系統代理的應用程式。如果曾暫時關閉 TUN 或 DNS 模組，應逐項恢復並觀察日誌。若某條自訂規則使驗證網域與主站經由不同出口，可將相關網域放入同一策略群組，同時保留規則順序說明，方便訂閱更新後再次檢查。
對於經常切換公司網路、家庭網路與公共 Wi-Fi 的裝置，可以保留一份基礎設定作為對照：使用穩定的訂閱、明確的 DNS 設定與較少的自訂規則。出現問題時，先用基礎設定重現，再逐步加入 TUN、腳本或自訂規則。這種最小化測試，比反覆安裝用戶端更容易確認真正的故障層。