開啟代理後網頁顯示憑證錯誤：HTTPS 憑證錯誤與 Clash 的關係解析

HTTPS 憑證錯誤：先確認問題發生在哪一層

開啟 Clash 用戶端後出現「您的連線不是私人連線」，只能表示瀏覽器無法確認目前連線的身分，不能直接據此認定代理節點竄改了網頁。系統時間錯誤、網站憑證過期、公共 Wi-Fi 登入頁面、企業網路的 HTTPS 檢查，以及 DNS 將網域解析到錯誤伺服器，都可能引發類似警告。

HTTPS 通常會連線至目標伺服器的 443 連接埠。進行 TLS 交握時，瀏覽器會檢查憑證有效期限、憑證鏈，以及憑證是否符合要求的網域。代理改變的是流量路徑；瀏覽器仍須完成這些身分驗證。排查時別急著關閉驗證，先記下完整錯誤代碼、網址列中的網域，以及憑證的簽發者和有效期限。

Clash 用戶端如何轉送 HTTPS 流量

一般代理轉送不需要替換網站憑證

瀏覽器透過本機 HTTP 代理存取 HTTPS 網站時，通常會先傳送 CONNECT 目標網域:443，再透過建立的通道與目標網站進行 TLS 交握。SOCKS 代理和 TUN 模式也能轉送加密連線。正常轉送時，瀏覽器看到的應該是目標網站的憑證，而不是某張「Clash 憑證」。

Clash 用戶端的規則會決定連線採直連或代理，以及使用哪個策略群組。即使啟用網域嗅探，讀取可見的交握資訊也不代表解密了 HTTPS 內容。不能只因為啟用了 TUN、Fake-IP 或嗅探，就認定瀏覽器憑證已遭替換。

分清目標網站憑證與代理節點憑證

部分代理協定本身也使用 TLS，因此會有兩層不同的驗證：核心檢查代理節點的 TLS 憑證，瀏覽器檢查目標網站的 HTTPS 憑證。如果核心記錄顯示連線至代理伺服器時出現 x509: certificate has expired or is not yet valid，問題可能出在節點端；如果瀏覽器顯示目標網站憑證並指出網域不符，則應檢查網站連線這一層。

mihomo 設定中的部分 TLS 節點支援 skip-cert-verify。這個欄位只影響對應節點的憑證驗證，不會關閉瀏覽器對目標網站的檢查。將它設為 true 不但無法可靠修復網頁憑證錯誤，還會降低節點身分驗證的安全性。請設定提供者修正節點憑證、伺服器名稱或連線位址。

第一輪排查：時間、網域與憑證詳細資料

1. 記下錯誤資訊。記錄完整網址和錯誤代碼。在瀏覽器的網站資訊或憑證檢視器中，查看簽發者、有效期限及「主體別名」，也就是 SAN。不同版本的瀏覽器入口可能不同，請以憑證詳細資料視窗為準。
2. 校正裝置時間。Windows 11 可前往「設定」→「時間與語言」→「日期與時間」，開啟自動設定時間並選擇「立即同步」。macOS 可前往「系統設定」→「一般」→「日期與時間」，檢查是否已開啟自動設定日期與時間。
3. 確認實際網域。檢查是否輸入錯誤，或從舊書籤連到新的子網域。憑證 SAN 中的 *.example.com 通常涵蓋 www.example.com，但不涵蓋 a.b.example.com，也不會自動涵蓋根網域 example.com。
4. 比對憑證有效期限。例如，裝置日期顯示為 2025 年，但憑證自 2026 年起才生效，系統便會判定憑證尚未生效；若裝置日期跳到 2030 年，也可能將仍有效的憑證判定為過期。這只是判斷示例，並非目前網站的憑證資料。

時區主要影響本地時間的顯示。若只是時區不同，但裝置的實際時間戳記正確，通常不會造成憑證驗證失敗。需要校正的是實際日期和時間，而不只是將時區名稱改成所在地區。

只有單一網站出現錯誤

如果同一網路上的其他 HTTPS 網站都正常，且直連和代理看到的是同一張過期憑證，應優先考慮網站端憑證續期或憑證鏈部署問題。更換多個節點也無法讓已過期的憑證恢復有效。可記下錯誤資訊並提供給網站維護人員，等待伺服器端修復。

第二輪排查：透過對照測試找出代理路徑

測試時每次只變更一個條件，使用相同網址、相同瀏覽器，並在相近時間進行。先記下目前的規則模式、策略群組和節點，再進行以下比較。不同路徑可能連到不同的 CDN 邊緣伺服器，因此憑證不同本身不足以證明遭到攔截；還須確認網域涵蓋範圍及憑證鏈是否可信。

關閉系統代理，不一定代表已改用直連

如果 TUN 模式仍在運作，流量可能繼續由虛擬網卡接管；瀏覽器擴充功能也可能設定獨立代理。進行直連對照前，請關閉 Clash 用戶端的系統代理與 TUN，並確認瀏覽器沒有使用獨立代理。測試完成後請還原原設定。受機構管理的裝置應遵守網路要求，不要自行繞過強制政策。

在 Clash 用戶端的連線清單中，找到目標網域對應的連線，查看符合的規則與最終策略。不要因為介面選取了某個節點，就認定所有請求都經過該節點：規則可能將目標分配至 DIRECT 或其他策略群組。更多比對邏輯請參閱進階設定。

使用 curl 對照本機代理

以下以 example.com 示範指令格式，並假設本機 HTTP 或混合連接埠為 7890。實際連接埠請以 Clash 用戶端目前的設定為準。Windows 請使用 curl.exe；macOS 或 Linux 請使用 curl。

# 明確忽略代理環境變數，比較直連路徑
curl --noproxy "*" -Iv https://example.com/

# 明確使用本機 HTTP 代理
curl --proxy http://127.0.0.1:7890 -Iv https://example.com/

如果 TUN 仍在運作，第一條指令也可能被接管，因此請先完成前述關閉步驟。-I 會要求回應標頭，-v 會輸出連線與交握資訊；不要加入 -k 或 --insecure，否則會略過這次要檢查的憑證驗證。curl 和瀏覽器使用的 TLS 實作與信任儲存區可能不同，結果只能作為比對線索，不能取代瀏覽器驗證。

DNS、Fake-IP 與網路登入頁如何影響憑證

連到錯誤位址可能會收到另一張憑證

DNS 將網域解析到錯誤伺服器時，瀏覽器仍會依原網域檢查憑證。例如，瀏覽 www.example.com，卻收到只涵蓋網路登入入口的憑證，就可能出現網域不符的錯誤。如果多個完全不同的網站都顯示同一個陌生簽發者或入口網域，應優先檢查公共 Wi-Fi 認證、路由器設定和本機 HTTPS 檢查軟體。

Fake-IP 是網域與連線之間的對應機制，不是用來偽造 HTTPS 憑證的功能。mihomo 常見範例會以 198.18.0.1/16 作為 Fake-IP 範圍，實際設定仍以設定檔為準。解析至此範圍不代表一定遭到污染；應一併檢查 DNS 增強模式、TUN 接管狀態，以及網域對應是否有效。

• 切換 DNS 增強模式或關閉 TUN 後，舊的 DNS 快取可能暫時保留對應位址。請先確認新設定已生效，再清除快取並重新啟動瀏覽器。
• Windows 可執行 ipconfig /flushdns 清除系統 DNS 快取，但瀏覽器可能另有獨立快取；清除快取也無法修復過期憑證。
• 瀏覽器的安全 DNS 設定可能改變網域解析路徑。請先記下目前設定，再依用戶端的 DNS 方案進行一致性測試，避免同時更換節點和解析器。

使用公共 Wi-Fi 時，先完成正常登入

飯店、機場或校園網路可能要求先開啟登入入口。請優先使用系統跳出的網路登入視窗，或網路業者提供的認證入口。如果 HTTPS 頁面遭重新導向並出現憑證警告，請勿在警告頁面輸入帳號密碼。透過可信入口完成認證後，再恢復代理並重新瀏覽目標網站。

企業根憑證、網站憑證鏈與安全界線

企業閘道、安全軟體或除錯工具可能會主動檢查 HTTPS：先在裝置與閘道之間建立一段 TLS 連線，再由閘道連線至網站。此時，瀏覽器可能會看到由機構根憑證簽發的網站憑證。對受管理裝置而言，這可能是明確設定的網路政策；對個人裝置而言，若突然出現陌生簽發者，就應仔細查證。

1. 確認管理來源。詢問機構管理員是否部署 HTTPS 檢查，並核對根憑證來源與裝置管理紀錄；切勿透過論壇附件或陌生訊息取得憑證。
2. 比較網路。在允許的情況下，改用可信任的個人網路。如果只有在特定網路才出現異常簽發者，請優先檢查該網路的閘道；若所有網路都會出現，則檢查本機軟體和信任設定。
3. 檢查網站憑證鏈。網站缺少中繼憑證時，有些瀏覽器可能依靠快取正常存取，其他裝置卻會連線失敗。應由網站維護人員補齊伺服器端憑證鏈，而不是要求訪客信任網站的終端憑證。
4. 使用受支援的環境。更新作業系統和瀏覽器，以取得相應的安全修補程式與信任儲存區更新。受管理裝置的更新及憑證調整，應由管理員依政策執行。

恢復連線前的檢查清單

• 時間正確：系統已完成時間同步，憑證仍在有效期限內。
• 網域相符：憑證 SAN 涵蓋網址列中的網域，無須手動略過錯誤繼續瀏覽。
• 路徑明確：已確認系統代理、TUN、瀏覽器獨立代理，以及實際套用的規則狀態。
• 簽發者可信：已查明陌生憑證的來源；機構憑證也已透過正式管理管道確認。
• 變更可還原：已保留原始設定，沒有透過略過憑證驗證來掩蓋問題。

提交問題時，建議提供錯誤代碼、作業系統與瀏覽器版本、Clash 用戶端及核心版本、是否啟用 TUN，以及直連與代理的對照結果。憑證截圖可保留網域、簽發者和有效期限；記錄檔應隱藏訂閱連結、節點密碼、存取權杖及個人網址。基本連線排查也可參閱疑難排解。

排查順序可整理為：先確認錯誤發生在哪一層，再檢查時間與憑證身分，接著比對連線路徑，最後找出 DNS、閘道或網站部署問題。修復目標是恢復可信任的 HTTPS 連線，而不是讓警告頁面消失。