開啟代理後網頁顯示憑證不安全？HTTPS 憑證錯誤原因與排除方法

先分清憑證錯誤與代理連線失敗

遇到 HTTPS 憑證警告時，請先停止輸入密碼或付款資料，再檢查系統時間、憑證簽發者與實際連線路徑。不要把「仍要前往」當成修復方法。一般代理轉送不需要瀏覽器信任新的根憑證；單純匯入訂閱，也不應要求安裝網站提供的憑證。

ClashX 或使用 mihomo 核心的用戶端通常負責轉送流量。瀏覽器透過 HTTP CONNECT 通道、SOCKS 或 TUN 路徑連線至 HTTPS 網站時，仍由瀏覽器驗證網站憑證。TUN 接管網路流量不代表會解密 HTTPS；mihomo 的流量嗅探功能也不代表會替網站重新簽發憑證。

常見訊息	優先檢查項目	不能直接據此判斷
`NET::ERR_CERT_DATE_INVALID`	本機時間、憑證有效期間	不一定是節點故障
`NET::ERR_CERT_AUTHORITY_INVALID`	簽發者、根憑證信任狀態、憑證鏈	不代表應安裝來路不明的憑證
`NET::ERR_CERT_COMMON_NAME_INVALID`	網址與憑證 SAN、DNS、重新導向	不一定只是 DNS 快取問題
`ERR_PROXY_CONNECTION_FAILED`	代理監聽連接埠、用戶端執行狀態	這不是網站憑證驗證錯誤
`ERR_SSL_PROTOCOL_ERROR`	TLS 交握、服務端連接埠錯誤、中間設備	不等於缺少根憑證

不同瀏覽器顯示的錯誤名稱可能不同。請先記下錯誤代碼、造訪的網域、發生時間及憑證簽發者；後續每次只變更一項條件。記錄網域即可，請勿公開含有登入權杖的完整網址。

第一步：檢查系統時間與憑證有效期間

系統時間錯誤可能讓多個正常網站同時顯示憑證已過期或尚未生效。虛擬機器還原快照、裝置長時間斷電或切換雙系統後，尤其應優先檢查。時區顯示不一致本身未必會影響驗證，關鍵是系統記錄的實際時間是否正確。

Windows 11：開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」，再於「其他設定」中選擇「立即同步」。
macOS：開啟「系統設定」→「一般」→「日期與時間」，啟用自動設定日期與時間；舊版系統的選單名稱可能不同。
重新開啟瀏覽器，查看錯誤頁中的憑證詳細資料，確認「生效時間」和「到期時間」。若系統時間正確，且只有一個網站的憑證過期，應由網站管理者更新憑證。

可在終端機執行以下指令讀取 UTC 時間，再與可信任的裝置比對。此指令只會讀取時間，不會修改系統設定。

# macOS / Linux
date -u

# Windows PowerShell
(Get-Date).ToUniversalTime().ToString("o")

第二步：透過直連與明確指定代理確認影響範圍

「關閉系統代理」不一定等於直連。TUN 仍可能接管連線，瀏覽器擴充功能也可能另行設定代理；企業網路還可能在裝置以外檢查流量。請先記下目前模式、所選節點及設定檔，再建立可重複的對照條件。

使用同一網域進行三組對照

直連組：關閉用戶端的系統代理與 TUN，暫時停用瀏覽器代理擴充功能；在允許直連且能連上目標網站的網路中，造訪同一個 HTTPS 網域。
節點 A：還原原本設定並選取原節點，記錄憑證簽發者及錯誤代碼。
節點 B：只切換節點，保持瀏覽器、目標網域及其他設定不變，再測試一次。

直連無法連線時，不能把逾時視為「憑證正常」。可改用另一個可信任的網路補充比對，例如手機熱點。不要同時變更 DNS、節點、瀏覽器與規則，否則無法判斷是哪項設定影響結果。

使用 curl 檢查 HTTP CONNECT 連線

以下以用戶端實際監聽的混合連接埠 7890 為例。請先確認目前生效的設定中 mixed-port 數值；若連接埠不是 7890，請一併修改指令。Windows 建議使用 curl.exe，以免部分 PowerShell 環境將同名項目視為別名。

# macOS / Linux：排除環境變數中的 HTTP/SOCKS 代理
# 只有在 TUN 已關閉且沒有其他透明代理時，才能作為直連對照
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 明確使用本機 HTTP 代理；清除 no_proxy 的略過清單
curl -Iv --connect-timeout 10 --max-time 20 --noproxy "" \
  --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell：明確使用本機 HTTP 代理
curl.exe -Iv --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

200 Connection established 只表示代理接受了 CONNECT 要求，不代表後續 TLS 驗證已成功。請繼續檢查憑證驗證結果及最終回應。範例網域僅用於示範指令；排查時請改用實際發生錯誤的網域，不必附上私人路徑。

curl 和瀏覽器可能使用不同的 TLS 後端與信任庫，因此「curl 成功、瀏覽器失敗」只能作為定位線索，不能據此定論。請勿在命令列加入 -k 或 --insecure，否則會略過本次要檢查的驗證程序。

第三步：檢查 MITM、封包擷取工具與殘留的根憑證

MITM 是指中間人攔截。在獲得明確授權的除錯或企業環境中，封包擷取工具可能會終止原始 TLS 連線，再使用本機根憑證簽發網站憑證。如果代理設定仍然存在、根憑證已移除，或應用程式不信任該憑證庫，就會出現憑證錯誤。

先查看簽發者，再追查設定來源

在瀏覽器錯誤頁或網站資訊面板中開啟憑證詳細資料，查看簽發者、有效期間與「主體替代名稱」（SAN）。SAN 必須包含目前造訪的網域。
如果多個互不相關的網站都顯示相同的陌生組織或本機工具名稱，請檢查封包擷取工具、HTTPS 掃描功能、瀏覽器擴充功能及裝置管理政策。
Windows 可在「設定」→「網路和網際網路」→「Proxy」檢查手動代理及設定指令碼；macOS 可在「系統設定」→「網路」→目前使用的網路→「詳細資訊」→「代理」檢查是否有殘留設定。
也請檢查環境變數 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY。瀏覽器與終端機不一定使用相同的代理設定。

移除憑證前，先確認其用途

macOS 可在「鑰匙圈存取」中分別檢查「登入」和「系統」鑰匙圈。Windows 可用 certmgr.msc 查看目前使用者的憑證，用 certlm.msc 查看本機電腦的憑證；後者通常需要系統管理員權限才能修改。檢查「受信任的根憑證授權單位」時，請先確認憑證名稱、用途與部署來源。

在個人裝置上，確認憑證是由舊版封包擷取工具安裝後，請先關閉該工具的 HTTPS 攔截並還原代理設定，再依照其解除安裝說明移除憑證。不要大量刪除系統根憑證。受組織管理的裝置應交由管理員處理，以免影響內部服務或違反網路管理規範。

第四步：排查異常節點、DNS 與錯誤網站

如果只有某個節點出現憑證網域不符，切換節點後便立即恢復，應隔離該節點並檢查 DNS 解析路徑。但不能只憑一次錯誤就認定節點遭到劫持：出口附近的登入入口網站、上游 DNS 或錯誤的反向 Proxy 設定，也可能將要求導向其他伺服器。

DNS 污染為何會引發憑證警告

網域若被解析到錯誤的伺服器，瀏覽器仍會依照網址列中的原始網域驗證憑證。錯誤伺服器若回傳其他網域的憑證，就會造成名稱不符。攻擊者通常無法只靠修改 DNS 取得目標網域的有效憑證，因此憑證警告是必須保留的安全防線。

先確認網址列中的網域拼寫，再檢查本機 hosts、瀏覽器安全 DNS、路由器 DNS 與用戶端 DNS 設定。mihomo 的 fake-ip 模式可能會回傳 198.18.0.0/16 範圍內的對應位址；該網段本身並非 DNS 污染的證據。一般的 nslookup 也不一定會使用瀏覽器的安全 DNS，或用戶端實際採用的解析路徑。

在用戶端的「連線」或「日誌」頁面依目標網域篩選，確認匹配的規則、策略群組及最終節點；實際選項位置請以用戶端介面為準。
檢查是否有優先順序更高的 DOMAIN、DOMAIN-SUFFIX 或規則集，將目標導向 DIRECT。規則通常依序比對；切換策略群組不一定會改變已匹配直連規則的要求。
不要長期使用全域模式來掩蓋問題。可短暫切換以進行比對；測試完成後，請恢復原模式並修正規則。
使用公共 Wi-Fi 時，請先完成系統提供的網路登入流程。若入口網站的憑證取代了 HTTPS 頁面的憑證，請改用可信任的網路進行驗證，不要為了通過入口網站而忽略目標網站的憑證警告。

確認已修正 DNS 設定後，再考慮清除快取。Windows 可執行 ipconfig /flushdns；macOS 可執行以下指令。瀏覽器與用戶端也可能各自維護快取，必要時請完全結束程式後重新啟動。

# macOS：重新整理系統 DNS 快取，需要管理員權限
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

若同一節點持續回傳不符的憑證，但其他可信任節點與直連都正常，請暫停使用該節點，並向服務提供者回報已移除敏感資訊的證據。提供的資訊可包含網域、時間、簽發者與錯誤代碼；請勿提交訂閱網址、節點密碼或完整設定檔。

第五步：區分網站憑證鏈與用戶端信任庫問題

系統時間正確且連線路徑穩定後，常見的剩餘問題是憑證鏈不完整或信任庫不同。若網站伺服器漏送中繼憑證，有些瀏覽器可能透過快取補齊，其他裝置或命令列工具則可能驗證失敗。不能因為某台電腦能開啟網站，就認定伺服器設定正確。

使用 OpenSSL 檢查憑證鏈與網域驗證

在支援這些參數的 OpenSSL 環境中，可執行以下指令。-servername 用來指定 SNI，讓共用 IP 位址的伺服器選擇對應網站；-verify_hostname 則會明確啟用網域檢查。只執行一般的 s_client 並看到連線成功，不代表憑證已通過完整驗證。

# 直連檢查：確認測試時未啟用 TUN 或其他透明轉送
openssl s_client -connect example.com:443 \
  -servername example.com -showcerts \
  -verify_hostname example.com -verify_return_error < /dev/null

# 經由本機 HTTP CONNECT 代理；OpenSSL 必須支援 -proxy
openssl s_client -proxy 127.0.0.1:7890 \
  -connect example.com:443 -servername example.com \
  -showcerts -verify_hostname example.com \
  -verify_return_error < /dev/null

查看輸出中的驗證錯誤、憑證鏈及 Verify return code。OpenSSL 的信任庫可能與 macOS 鑰匙圈、Windows 憑證存放區或瀏覽器不同；若出現「無法取得本機簽發者憑證」，需同時考慮本機 CA 設定與伺服器漏送中繼憑證的可能性，不能立即判定是節點問題。

只有一個網站失敗，且在不同裝置與網路上都一樣：優先聯絡網站管理者，檢查憑證是否過期、SAN 是否符合，以及憑證鏈是否完整。
只有一台舊裝置失敗：更新至仍受支援的作業系統與瀏覽器，再檢查根憑證更新狀態；不要從論壇下載來源不明的憑證套件。
只有一個應用程式失敗：檢查該應用程式是否使用獨立 CA 檔案或憑證釘選機制。不要以關閉驗證的方式處理憑證釘選失敗。
出現與憑證撤銷相關的錯誤：記錄具體錯誤與網路條件，確認撤銷檢查服務是否可連線，並交由管理員或網站管理者確認；不要永久關閉撤銷檢查。

修復後的驗證與安全界線

完成修改後，請使用原本發生錯誤的網域重新驗證，而不是只開啟另一個網站。依序檢查瀏覽器、實際需要使用的應用程式，以及用戶端日誌中的規則與節點。恢復原本的規則模式，並確認重新啟動用戶端後問題不再出現，才算設定穩定。

系統日期與時間正確，且憑證有效期間涵蓋目前時間。
憑證 SAN 與目標網域相符，且憑證鏈可連結至裝置信任的根憑證。
系統代理、TUN、瀏覽器擴充功能與環境變數的用途明確，沒有殘留的除錯代理。
未使用忽略憑證錯誤的瀏覽器啟動參數，也未在命令列略過 TLS 驗證。
重新測試原節點或替代節點，確認故障範圍與修復措施相符。

若曾在警告頁選擇繼續造訪並提交敏感資料，請在可信任的網路中更改相關密碼、撤銷可疑工作階段，並檢查帳戶登入紀錄。憑證警告不代表資料必然已外洩，但在連線安全性存疑時，不應繼續處理敏感操作。