開啟代理後網站出現憑證錯誤？HTTPS 錯誤原因與解決方法

先釐清：網站憑證錯誤，還是代理節點交握失敗

開啟 Clash 後出現 HTTPS 錯誤，不代表 Clash 修改了網站憑證。一般 HTTP CONNECT、SOCKS 代理與 TUN 轉送通常只負責轉送連線，不會解密瀏覽器與目標網站之間的 HTTPS 內容。請先確認錯誤發生在哪個環節，再決定要檢查瀏覽器、系統信任存放區，還是節點設定。

瀏覽器錯誤碼也有其判斷範圍。例如 ERR_SSL_PROTOCOL_ERROR 是 TLS 通訊協定層級的錯誤，不能據此認定憑證遭到替換。這也可能是因為 HTTPS 請求送到一般 HTTP 服務、伺服器 TLS 設定異常，或網路設備提前中斷交握。

第一步：確認系統時間與憑證有效期

憑證會標示生效時間與到期時間。若電腦時間不在這段期間內，即使連線到正確的伺服器，也可能出現錯誤。從睡眠模式恢復、主機板電池異常或虛擬機時間未同步，都可能造成時間偏差。先檢查系統時間，比立刻更改 DNS 或重新安裝用戶端更直接。

1. Windows 11：前往「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」，確認時區後點選「立即同步」。
2. macOS：前往「系統設定」→「一般」→「日期與時間」，確認已開啟自動設定日期與時間；若需修改，請依系統提示完成授權。
3. Android：在系統設定中搜尋「日期和時間」，開啟自動設定時間與時區。不同廠牌的選單位置可能不同。
4. iOS：前往「設定」→「一般」→「日期與時間」，確認已開啟「自動設定」。若受裝置管理政策限制，請聯絡管理員確認。

在瀏覽器的憑證警告詳細資訊中，找到檢視憑證的入口，記下「有效期起始」、「有效期截止」與「簽發者」。桌面版 Chromium 瀏覽器也可在開發人員工具的「安全性」面板檢視憑證資訊；入口名稱可能隨瀏覽器版本而異。

如果本機日期正確，且只有單一網站的憑證過期，應由網站維護者更新憑證。切換節點無法讓過期憑證恢復有效。若只有特定節點出現舊憑證，則需進一步確認該出口是否連到了不同的伺服器。

第二步：使用相同網址比較直連與代理

比較測試時，網址必須完全相同，包括網域與路徑。每次只變更一個條件，並記錄錯誤碼、憑證簽發者與套用的規則。不要同時更換節點、DNS、瀏覽器與網路，否則即使恢復正常，也無法確認原因。

建議分四輪檢查

1. 記錄原始狀態：記下用戶端目前的模式、選取的節點、系統代理與 TUN 開關狀態。先在「連線」清單搜尋該網域，確認實際套用的策略。
2. 測試直連：關閉系統代理與 TUN，並確認瀏覽器代理擴充功能、手動代理及其他 VPN 都沒有接管連線。接著造訪相同網址並記錄結果。
3. 恢復代理：依照原本狀態重新開啟代理，選擇節點 A。確認「連線」清單顯示該請求確實經由節點 A，而不是命中 DIRECT。
4. 只切換節點：改用節點 B，其餘設定維持不變，再檢查錯誤碼與憑證資訊。

直連正常、節點 A 異常、節點 B 正常，表示問題較可能出在節點 A 的出口路徑、解析結果或服務設定，但不能只憑這一輪測試就判定遭到攔截。直連與代理都異常時，應優先檢查裝置時間、網站憑證、系統信任存放區與目前使用的網路。

有些網站在目前的網路環境中無法直連，因此直連逾時不能證明「憑證正常」。此時可改用另一個可信任的網路或其他裝置輔助比較，但仍應記錄變更的條件。不要因為其他裝置能正常連線，就直接認定本機設定沒有問題。

使用命令確認本機代理連線路徑

如果用戶端實際使用的混合連接埠是 7890，可在 Windows 終端機執行以下命令。macOS、Linux 請以 curl 取代 curl.exe。範例網域僅用來示範命令格式，排查時請換成發生錯誤的網站網域。

curl.exe -v --noproxy "*" https://example.com/
curl.exe -v --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

第一個命令不會使用 curl 明確指定的代理，但無法繞過系統中的 TUN 或其他網路層級接管，因此執行前仍需關閉這些功能。第二個命令會明確經由本機 HTTP 代理；連接埠請以用戶端顯示的值為準。不同 curl 版本與瀏覽器可能使用不同的信任存放區，因此兩者結果不同並不矛盾。

第三步：檢查中間人攔截與根憑證來源

企業閘道、防毒軟體的 HTTPS 掃描功能及封包擷取工具，可能會在本機或網路中終止 TLS，再提供重新簽發的憑證給瀏覽器。如果裝置信任其根憑證，瀏覽器可能不會顯示警告；若根憑證遺失、過期，或不受目前瀏覽器信任，就可能出現「簽發機構不受信任」的提示。

先檢查憑證鏈，再決定是否調整信任存放區

• 確認網域：查看憑證中的「主體別名」，也就是 SAN，確認其中包含網址列顯示的主機名稱。不要只看憑證顯示名稱或組織名稱。
• 確認簽發者：如果顯示公司閘道、封包擷取工具或安全軟體的名稱，請確認是否與已安裝的工具及組織政策相符。僅憑名稱無法判定憑證可信。
• 確認影響範圍：若多個無關網站突然都顯示同一組本機簽發的憑證，而且只在某台裝置或某個網路發生，更應檢查是否有共用的 HTTPS 檢查環節。

在 Windows 按下 Win + R，執行 certmgr.msc，檢查目前使用者的「受信任的根憑證授權單位」→「憑證」；電腦層級的憑證則需透過相應的管理主控台檢查。在 macOS 可於「鑰匙圈存取」中選取「系統」或「登入」鑰匙圈，查看憑證與信任設定。

這些位置是用來確認憑證來源，不代表應大量刪除憑證。受管理裝置上的憑證可能是公司業務所需，應交由管理員確認。若個人裝置最近使用過封包擷取工具，請先依工具說明停止 HTTPS 解密並撤銷其信任，再重新測試。不要從陌生下載頁安裝所謂的「Clash 專用根憑證」；一般代理轉送不需要這麼做。

第四步：區分 DNS 異常與節點 TLS 設定錯誤

DNS 解析異常為何會造成憑證錯誤

DNS 若將網域解析到錯誤的位址，瀏覽器仍會驗證目標網域。錯誤的伺服器若回傳其他網域的憑證，就可能出現名稱不符；若直接中斷連線，則會顯示交握失敗。DNS 本身不會簽發憑證，因此需要一併比對解析結果、連線目標與憑證 SAN。

Windows 可使用 Resolve-DnsName example.com 查看系統解析結果；macOS、Linux 可使用 nslookup example.com 輔助檢查。不過，瀏覽器的「安全 DNS」、mihomo 內建 DNS，以及代理端的遠端解析可能採用不同路徑，因此系統命令的結果不一定等於瀏覽器實際使用的結果。

• 在用戶端的「連線」與「日誌」中查看目標網域、套用規則與出口策略，先確認請求實際送往何處。
• 檢查目前生效設定中的 dns、nameserver、nameserver-policy 與 TUN DNS 劫持設定，避免只修改未載入的檔案。
• 如果使用 fake-ip，看到 198.18.0.0/16 範圍內的位址不一定代表遭到污染。mihomo 常見的預設 fake-ip 位址範圍為 198.18.0.1/16，這些位址用於內部映射，不能視為網站的實際出口位址。
• 變更解析策略後，請重新建立連線再測試。舊連線與快取可能仍沿用先前的結果；一開始不要把所有 DNS 項目都改成同一個公共解析器。

節點憑證錯誤發生在另一段連線

使用 TLS 的代理通訊協定時，用戶端也必須驗證代理伺服器的憑證。這與瀏覽器驗證網站憑證是兩項獨立的檢查。如果日誌中的目標是節點伺服器，而瀏覽器顯示通道連線失敗，應優先確認訂閱提供的伺服器位址、連接埠與 TLS 參數。

以 mihomo 常見的 TLS 節點設定為例，server 是連線位址，port 是伺服器的監聽連接埠；部分通訊協定使用 servername 指定 TLS 服務名稱，其他設定類型則使用 sni。欄位是否適用取決於通訊協定與核心支援，不能直接將一種通訊協定的寫法套用到另一種。

依錯誤範圍處理，並保留可重現的紀錄

排查至此，可依影響範圍縮小處理方向。恢復連線只是其中一項結果，也要確認沒有留下錯誤的信任設定或暫時放寬的驗證選項。

公共 Wi-Fi 可能要求先完成入口網站驗證。請優先使用系統跳出的網路登入頁面，不要在 HTTPS 憑證警告頁面強行繼續並輸入帳號。若無法確認網路身分，請停止連線該熱點，改用可信任的網路。

回報問題時應附上哪些資訊

• 作業系統、瀏覽器版本、用戶端版本與核心名稱，可從「關於」或核心資訊頁面記錄。
• 發生時間、目標網域、瀏覽器完整錯誤碼，以及憑證的 SAN、簽發者與有效期。
• 直連、節點 A、節點 B 的比較結果，以及系統代理與 TUN 是否開啟。
• 錯誤發生前後的相關日誌；請遮住訂閱連結、節點密碼、權杖、帳號與不宜公開的位址。

如果系統或瀏覽器長期未更新，可透過官方系統更新與瀏覽器更新管道安裝適用的安全更新，再重新測試信任鏈。更換用戶端前，請先記下目前的連接埠、規則模式與 TUN 狀態，避免將安裝變更與網路問題混為一談。基本開關設定可參考系統代理操作說明，解析問題可接著參閱DNS 疑難排解說明。

安全的處理順序是：記錄錯誤、校正時間、比較連線路徑、檢查憑證來源，最後再定位 DNS 或節點參數。整個過程都應保留憑證驗證，不要只以「網站終於能開啟」作為唯一標準。