開啟 Clash 後網頁顯示 HTTPS 憑證錯誤：原因與處理方式

先判斷憑證錯誤是否真的由 Clash 引起

HTTPS 憑證錯誤不代表 Clash 客戶端損壞。瀏覽器連線至 HTTPS 網站時，會檢查憑證中的網域名稱、有效期限、簽發機構與憑證鏈。Clash 通常只負責轉送加密流量，無法讀取已建立的 TLS 工作階段內容。只要連線目標、系統時間與憑證鏈正常，啟用規則代理或 TUN 模式本身不會要求額外安裝網站憑證。

問題更常發生在轉送路徑改變之後：代理節點將連線送至錯誤伺服器、DNS 回傳異常位址、區域網路 HTTP 代理嘗試解密流量，或裝置時間偏差導致有效期限判斷錯誤。開啟 Clash 後剛好觸發這些路徑，因此兩件事在時間上接近，但排查時仍須區分客戶端、設定、節點與目標網站。

先做一組開關對照

1. 記下發生錯誤網站的完整網域，例如 accounts.example.com，不要只記首頁名稱。
2. 擷取警告頁中的錯誤代碼、憑證簽發者與有效期限。Safari 可能顯示「此連線並非私人連線」，Chromium 核心瀏覽器常見代碼包括 NET::ERR_CERT_DATE_INVALID、NET::ERR_CERT_COMMON_NAME_INVALID 與 NET::ERR_CERT_AUTHORITY_INVALID。
3. 關閉 Clash 的系統代理或 VPN 連線，完全退出後重新開啟瀏覽器，再造訪相同的 HTTPS 位址。
4. 重新啟用 Clash，將該網域暫時設為 DIRECT。若直連正常、代理群組卻出錯，應優先檢查目前節點與上游線路。
5. 分別使用 Wi-Fi 與行動網路測試。只有某個 Wi-Fi 出錯時，應優先檢查路由器、公共網路驗證頁面與手動代理。

節點遭劫持或上游回傳錯誤憑證

當規則將網域交給代理節點後，節點會代表裝置連線至目標伺服器。如果節點出口遭透明代理、惡意閘道或異常上游接管，瀏覽器收到的憑證可能屬於另一個網域，也可能由裝置不信任的機構簽發。這類問題通常只會隨著某個節點或某組線路出現。

典型表現

• 同一網站使用 DIRECT 正常，切換至特定代理節點後出現網域不相符。
• 憑證的「簽發給」欄位與網址列網域完全無關，例如造訪帳戶網域卻收到路由器管理頁面或陌生網域的憑證。
• 切換同一訂閱中的其他地區節點後恢復正常，原節點重複測試仍然出錯。
• HTTP 網站被重新導向至廣告頁、驗證頁或陌生搜尋頁面，同時 HTTPS 網站出現憑證異常。

Clash 的全域模式適合用來比對節點，因為所有符合條件的流量都會進入目前代理群組。測試完成後應恢復原本的規則模式。若只有一個節點異常，不必刪除整份訂閱；先在代理群組中排除該節點，再更新訂閱，觀察服務提供者是否調整線路。

核對憑證中的三個欄位

1. Subject Alternative Name：應包含正在造訪的完整網域，萬用字元 *.example.com 通常只能涵蓋一層子網域。
2. Issuer：確認簽發機構是否穩定。測試前後若突然從公開 CA 變成公司閘道、路由器裝置或陌生名稱，便需提高警覺。
3. Validity：確認目前時間介於「生效時間」與「到期時間」之間。憑證到期也可能是網站本身的維護問題。

在 macOS 上可以使用系統內建指令查看遠端握手結果。以下的 example.com 應替換為實際出錯的網域，連接埠 443 是標準 HTTPS 連接埠：

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

-servername 會傳送 SNI，缺少它可能讓同一台伺服器回傳預設憑證，造成誤判。指令輸出的憑證資訊可用來比較直連與代理測試，但不要把指令顯示「握手成功」理解成網站內容一定安全，仍須核對網域與簽發鏈。

系統時間偏差導致憑證有效期限判斷失敗

憑證包含明確的生效時間與到期時間。iPhone 時間慢了幾天，可能將新憑證判定為「尚未生效」；時間快了幾個月，則可能將正常憑證判定為「已經過期」。這類故障往往不只影響單一網站，而是讓一批 HTTPS 服務、App 登入與系統帳號同時失敗。

iPhone 與 iPad 的檢查路徑

開啟「設定」→「一般」→「日期與時間」，啟用「自動設定」。接著檢查時區是否與所在地一致。若開關呈灰色，可能受到螢幕使用時間限制、電信業者設定或裝置管理政策控制，須先處理相應限制。

• 時間偏差超過 5 分鐘時，部分登入權杖與一次性驗證碼也可能同時失效。
• 修改時間後，關閉 Safari 中發生問題的分頁並重新開啟，避免繼續重複使用舊連線。
• 若裝置剛從長時間關機狀態恢復，先連線至穩定網路，等待系統完成網路校時。
• 受管理的公司裝置應聯絡管理員，不要自行移除單位下發的管理描述檔。

也要留意憑證錯誤中的日期。如果瀏覽器顯示憑證剛剛過期，而系統日期準確，且直連、不同節點與不同網路都得到相同結果，問題更可能出在網站伺服器。此時切換 Clash 設定無法修復，只能等待網站更新憑證。

DNS 污染將網域導向錯誤伺服器

HTTPS 連線開始前，裝置需要將網域解析為 IP 位址。若 DNS 回傳錯誤位址，TLS 請求便會抵達另一台伺服器，而該伺服器自然可能回傳不相符的憑證。此時瀏覽器常見的提示是憑證不適用於目前網域，而不只是連線逾時。

在 Clash 或 mihomo 設定中，DNS 行為可能來自 nameserver、fallback、nameserver-policy、Fake-IP 對映，以及規則中的 DOMAIN、DOMAIN-SUFFIX。TUN 模式還可能接管系統 DNS 請求。排查時不要一次修改所有欄位，否則無法判斷是哪個項目造成影響。

以最少變因檢查 DNS

1. 先更新訂閱與設定，確認 YAML 可以正常載入，沒有縮排或欄位錯誤。
2. 將出錯網域暫時加入直連規則，並確認規則位於 MATCH 之前。
3. 清除客戶端 DNS 快取；若客戶端沒有獨立入口，可中斷系統 VPN 連線約 10 秒後重新連線。
4. 關閉再開啟飛航模式，重新取得行動網路與 DNS 狀態。
5. 改用另一個 Wi-Fi 或行動網路重新測試，區分本地路由器 DNS 與 Clash 內建 DNS。

暫時規則可以寫成以下形式。規則會由上至下比對，具體網域應放在寬泛規則之前：

rules:
  - DOMAIN,accounts.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

如果直連規則仍使用 Clash 的 DNS 模組，測試結果只能說明出口方式改變，不能完全排除 DNS。更嚴格的對照需要同時比較系統 DNS 與設定中的 DNS。修改前請儲存原始設定，測試結束後恢復，避免長期使用暫時規則破壞原有分流。

Fake-IP 不是憑證偽造

Fake-IP 模式會向本機應用程式回傳保留位址，再由核心依照網域對映轉送連線。應用程式看到的位址可能類似 198.18.0.0/15 範圍，但 TLS 握手仍應使用原始網域完成。僅僅看到 Fake-IP 位址，不代表憑證遭到替換。真正需要注意的是網域對映遺失、DNS 請求繞過核心，或目標應用程式不相容 Fake-IP 而連線至錯誤目標。

若只有區域網路裝置、遊戲主機或少數不相容應用程式出現異常，可以針對網域設定 Fake-IP 過濾，而不是直接關閉整套 DNS。具體欄位取決於 Clash Meta 或 mihomo 設定版本，編輯後應先確認設定檢查通過，再啟動 TUN。

HTTP 代理、封包擷取工具與安裝憑證的影響

一般 Clash 轉送 HTTPS 時，通常只建立連線通道，不需要簽發網站憑證。只有封包擷取、除錯、家長監護、企業閘道或內容過濾工具主動進行 TLS 解密時，裝置才會看到由本機或閘道 CA 重新簽發的憑證。如果這張 CA 未獲系統信任，所有遭解密的網站都可能顯示「簽發機構不受信任」。

檢查 Wi-Fi 手動代理

在 iPhone 上開啟「設定」→「Wi-Fi」→目前網路右側的資訊按鈕→「設定代理伺服器」。日常使用 Clash 的系統 VPN 或網路延伸功能時，這裡通常應設為「關閉」，除非你明確需要連線至區域網路代理。

常見的本機 HTTP 或 mixed 監聽連接埠包括 7890，SOCKS 連接埠常見為 7891，但設定可以修改。若 Wi-Fi 代理指向陌生的區域網路位址，例如 192.168.1.20:8080，請先記錄設定，再關閉代理重新測試。不要把某台裝置上的 127.0.0.1 當成另一台電腦；回送位址永遠代表目前裝置本身。

檢查描述檔與憑證信任設定

1. 開啟「設定」→「一般」→「VPN 與裝置管理」，查看是否存在不認識的設定描述檔。
2. 開啟「設定」→「一般」→「關於本機」→「憑證信任設定」，核對已啟用完全信任的根憑證。
3. 不要為了消除警告而安裝網頁臨時提供的 CA，也不要任意啟用陌生根憑證的完全信任。
4. 公司或學校管理的裝置可能會合法部署檢查憑證，應先向網路管理員確認名稱、用途與有效期限。

僅刪除 Clash 設定通常不會移除其他工具安裝的描述檔或根憑證。反過來，任意刪除企業憑證可能導致公司 Wi-Fi、內部網站與郵件停止運作。處理憑證前先確認來源，再決定要停用封包擷取工具、關閉手動代理，或由管理員重新下發憑證。

Clash 設定與規則的專項檢查

憑證錯誤也可能是規則選錯出口造成的。例如網域原本應直連，卻被過於寬泛的 DOMAIN-SUFFIX 規則送入不穩定節點；或者訂閱使用的策略群組名稱發生變更，規則落入最後的 MATCH 策略。此時應查看實際命中記錄，而不是只看目前模式名稱。

確認模式與策略群組

• 規則模式：依規則決定直連、代理或拒絕，適合定位特定網域的命中結果。
• 全域模式：統一使用目前的全域節點，適合比較不同節點，但測試後應恢復原設定。
• 直連模式：繞過代理節點，可用來判斷異常是否隨代理鏈出現。

進入客戶端的連線記錄，找到出錯網域及其子網域。現代網頁可能同時連線至登入網域、靜態資源網域與 API 網域，主頁直連不代表所有請求都直連。請重點核對命中的規則類型、策略群組名稱與最終節點。

避免混用連接埠與代理鏈

如果同時執行桌面封包擷取工具、瀏覽器代理擴充功能與 Clash，可能形成多層代理。例如瀏覽器擴充功能指向 127.0.0.1:8080，封包擷取工具再轉送至 Clash 的 127.0.0.1:7890。其中任何一層啟用 HTTPS 解密，都可能改變憑證。

排查期間只保留一條路徑：關閉瀏覽器代理擴充功能、停用封包擷取工具，再讓系統代理或 TUN 直接交由 Clash 處理。恢復時一次只開啟一個元件，每次使用相同網域測試。如此即可定位究竟是哪一層開始替換憑證。

一套由低風險到高風險的處理順序

1. 儲存錯誤資訊：記錄網域、時間、錯誤代碼、憑證簽發者與目前節點。
2. 停止輸入敏感資料：原因確認前，不要登入帳號或提交付款資料。
3. 校準系統時間：透過「設定」→「一般」→「日期與時間」啟用自動設定。
4. 關閉 Clash 進行對照：退出瀏覽器後重新測試，排除重複使用舊連線的可能。
5. 切換直連與節點：判斷錯誤是否只隨某個代理出口出現。
6. 更換網路：比較 Wi-Fi 與行動網路，辨識路由器或公共網路驗證造成的干擾。
7. 檢查規則命中：確認網域實際使用的策略群組與節點。
8. 檢查 DNS：清除快取，核對 Fake-IP、nameserver 與網域策略。
9. 檢查手動代理：查看 Wi-Fi 的「設定代理伺服器」及瀏覽器代理擴充功能。
10. 檢查根憑證：確認描述檔與完全信任憑證的來源。

如果錯誤只出現在單一節點，且憑證網域明顯不符，應停止使用該節點，將發生時間、目標網域與憑證簽發者提交給訂閱服務提供者。如果所有網路、所有裝置都在同一個網站看到完全相同的過期憑證，通常應等待網站營運方修復。

若裝置在移除陌生代理、關閉異常節點後，仍對大量 HTTPS 網站顯示錯誤，可以先備份重要資料，再考慮重置網路設定。iPhone 路徑為「設定」→「一般」→「傳送或重置 iPhone」→「重置」→「重置網路設定」。此操作會清除已儲存的 Wi-Fi 網路、VPN 與部分網路參數，應放在一般檢查之後，不要當作第一步。

常見問題