開啟代理後網站出現憑證錯誤：HTTPS 憑證錯誤原因與排除

先記下錯誤代碼，切勿略過憑證驗證

開啟 Clash 後出現「你的連線不是私人連線」，只能表示瀏覽器未能透過目前的連線路徑驗證伺服器身分，不能據此判定節點失效。HTTPS 驗證取決於存取網域、憑證有效期限、憑證鏈及本機信任庫；代理改變連線路徑後，其中任何一項問題都可能浮現。

先記下網址列中的完整主機名稱、瀏覽器錯誤代碼、系統時間，以及憑證檢視器中的「簽發者」、「有效期限」和 Subject Alternative Name（SAN，主體別名）。通常記錄主機名稱就足夠；分享畫面截圖時，請遮住網址中的登入權杖、電子郵件地址及其他個人資訊。

切勿將關閉憑證驗證、安裝來源不明的根憑證或點選「繼續前往」當成修復方法。銀行、付款、電子郵件及帳號登入頁面出現憑證警告時，請停止輸入密碼，並先透過可信任的網路確認連線。

Clash、mihomo 與 HTTPS 憑證的關係

一般 Clash 或 mihomo 設定負責轉送連線。瀏覽器透過 HTTP 代理的 CONNECT 通道、SOCKS5 或 TUN 路由連上目標網站時，網站 HTTPS 的 TLS 交握通常仍在瀏覽器與網站之間進行。僅啟用系統代理，並不需要在系統安裝用來解密網頁的根憑證。

請區分兩層 TLS：節點設定中的 tls、servername 和 skip-cert-verify 可能控制「核心到代理節點」的連線；瀏覽器的憑證警告通常涉及「瀏覽器到網站」的連線。修改節點的 skip-cert-verify 無法修復網站憑證，還會降低節點身分驗證的可靠性。

三種現象，各有不同的排查方向

• 瀏覽器顯示憑證警告：檢查網頁憑證上的網域、簽發者與有效期限。
• 用戶端記錄出現 x509，瀏覽器顯示代理連線失敗：檢查節點網域、節點憑證，以及核心執行環境的時間和信任庫。
• 只有啟用 TUN 後才出現異常：確認連線實際套用的規則、DNS 路徑及其他 VPN；TUN 本身不會替網站簽發新憑證。

瀏覽器安全 DNS、擴充功能代理、系統代理和 TUN 可能同時啟用。診斷時先固定一種連線方式，避免關閉系統代理後流量仍由 TUN 接管，誤以為直連也有問題。

系統時間錯誤與憑證有效期限

憑證有生效時間與到期時間。本機時間早於生效時間或晚於到期時間，都會導致驗證失敗。雙系統切換、還原虛擬機快照、主機板電池故障及時間同步服務異常，都可能造成多個原本正常的網站同時出錯。

先確認時間，再檢查時區

• Windows 11：前往「設定」→「時間與語言」→「日期與時間」，檢查「自動設定時間」，再點選「立即同步」。公司或學校管理的裝置，時間來源可能由組織政策控制。
• macOS：前往「系統設定」→「一般」→「日期與時間」，確認已啟用自動設定日期與時間，並檢查時區。
• Ubuntu：執行以下指令，查看目前時間、時區及同步狀態。

date -Is
timedatectl status

請特別確認 System clock synchronized。若主機採用 systemd 管理時間，且不受其他時間服務或組織政策限制，可執行下列指令啟用網路時間同步，再重新檢查狀態：

sudo timedatectl set-ntp true
timedatectl status

時區不同不代表系統絕對時間錯誤，不必為了配合網站所在地而修改時區。如果時間正確，只有單一網域的憑證過期，通常應由網站管理者更新憑證；修改本機日期只會掩蓋問題，還可能影響其他網站。

攔截工具、HTTPS 檢查與本機信任庫

Fiddler、Charles、mitmproxy 等工具啟用 HTTPS 解密後，會為存取的網站動態簽發憑證。部分安全軟體和企業閘道也可能執行類似檢查。因此，瀏覽器顯示的簽發者可能變成工具或組織名稱，而非網站原本使用的公開憑證授權機構。

依簽發者追查原因，不要直接匯入憑證

1. 在錯誤頁面提供的憑證詳細資料中查看簽發者與憑證鏈；各瀏覽器版本的操作路徑可能不同。
2. 確認是否有攔截工具正在執行、是否啟用 HTTPS 解密，以及系統代理是否仍指向該工具。
3. 結束個人測試時，請關閉工具的 HTTPS 解密功能，並依照工具說明還原代理設定；只有在確認測試根憑證屬於該工具且不再需要時，才將其移除。
4. 若簽發者屬於公司或學校，請向管理員確認裝置管理及信任憑證部署情況，不要自行刪除組織憑證或規避政策。

不要假設所有應用程式都使用同一套憑證信任機制。Firefox、系統瀏覽器、命令列 curl 及容器內的程式，可能受不同憑證庫、版本和組織政策影響。「瀏覽器可開、curl 不行」時，應繼續比對各自使用的信任來源，而不是反覆切換節點。

若 Ubuntu 的問題只是公開 CA 憑證套件過舊，可透過可信任的軟體來源更新 ca-certificates。以下操作會更新系統信任憑證，不會自動修復網站網域錯誤，也不會讓來源不明的私有憑證變得可信：

sudo apt update
sudo apt install --only-upgrade ca-certificates
sudo update-ca-certificates

以直連、固定節點及憑證詳細資料進行比對

比對測試應使用同一台裝置、同一個 URL，並盡量在相近時間進行；每次只變更一個條件。先暫時關閉攔截工具與其他 VPN，再確認 TUN、系統代理及瀏覽器擴充功能的實際狀態。規則模式下，目標網域可能符合 DIRECT，因此「用戶端已啟用」不代表該請求一定經過節點。

透過本機 mixed-port 比對連線

以下範例假設本機 mixed-port 為 7890，並使用公開範例網域 example.com。測試實際故障時，請改用該網站不含權杖的 URL，並依用戶端顯示的連接埠替換。Windows 建議明確執行 curl.exe，避免部分 PowerShell 環境中的同名別名造成混淆。

# 不使用 curl 的明確代理設定；TUN 仍可能接管此連線
curl -Iv --noproxy '*' https://example.com/

# 使用 mixed-port 的 HTTP 代理入口
curl -Iv --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

--noproxy '*' 只會略過 curl 的代理設定，無法避開 TUN、透明閘道或系統路由。若要取得真正的直連基準，必須在允許的環境中同時停用相關流量接管。以上指令未關閉憑證驗證；輸出可能包含請求資訊，分享前請先移除敏感資料。

• 只有某個節點出錯：固定其他條件後更換節點，比較憑證 SAN、簽發者與錯誤代碼；同時在用戶端連線記錄中確認命中的策略及實際出口。
• 所有出口都只有一個網站出錯：優先懷疑該網站的憑證、憑證鏈或 CDN 邊緣設定，而非本機代理連接埠。
• 同一台裝置上的多個網站都出錯：優先檢查時間、信任庫、攔截工具及受管理網路。
• 同一網路中的多台裝置都出錯：檢查入口網站認證、路由器 DNS、閘道及電信業者網路；必要時改用可信任的網路交叉測試。

不同出口看到不同憑證，不一定代表遭到劫持。CDN 可能依地區使用不同但有效的憑證和中繼憑證鏈。判斷時應確認網域是否相符、憑證鏈是否可信、時間是否有效，以及異常簽發者是否有合理解釋。

DNS 污染、節點異常與入口網站認證的差異

DNS 污染或解析錯誤可能讓網域指向無關的伺服器，進而觸發憑證網域不符。這不會讓對方自動取得目標網域的有效憑證。攻擊者單靠修改解析結果，通常無法悄悄解密憑證驗證正常的 HTTPS 連線；瀏覽器警告正是應保留的安全防線。

fake-ip 位址不代表解析錯誤

mihomo 的 fake-ip 模式會向應用程式回傳用於映射的合成 IP；常見設定使用 198.18.0.0/16，實際範圍則以 fake-ip-range 為準。查詢結果落在此範圍，不能單憑這點判定 DNS 遭到污染。應檢查核心是否保留網域映射，以及連線最後套用的規則與出口。

• 先查看 dns.enhanced-mode、nameserver、可能設定的 nameserver-policy，以及 TUN 的 dns-hijack。
• 確認瀏覽器是否啟用安全 DNS；瀏覽器自行選用的解析器可能讓網域解析路徑與預期不同。
• 不要只比較兩個解析器回傳的 IP 是否相同。CDN、地理位置及負載平衡都可能造成正常差異。
• 變更解析設定後，請重新載入設定並建立新的測試連線；舊連線、DNS 快取及 fake-ip 映射可能使結果暫時混雜。

若異常只在某個出口出現，而且憑證網域不符或簽發者無法解釋，請停用該出口並保留已去除敏感資訊的記錄。這表示問題與該連線路徑有關，但不足以單獨證明節點主動劫持；出口網路的 DNS 或中間設備也可能異常。

飯店、機場等網路可能要求先完成入口網站認證。HTTPS 請求若被導向登入閘道，可能出現憑證錯誤。請使用系統提供的「登入網路」提示完成認證；不要在憑證異常的原網站頁面輸入帳號，也不要為入口網站安裝來源不明的根憑證。

確認修復結果與常見誤區

為什麼 HSTS 網站沒有「繼續前往」選項？

HSTS（HTTP Strict Transport Security，HTTP 嚴格傳輸安全）要求瀏覽器對相關網站嚴格使用 HTTPS。憑證錯誤時不提供略過驗證的選項，可能是預期行為。清除 HSTS 狀態並不能修復憑證；應處理時間、憑證鏈、網域或網路路徑本身的問題。

切換成全域模式或啟用 TUN 有用嗎？

這兩項操作可能改變出口或流量接管範圍，可用於受控比對，但無法修復過期憑證或來源不明的簽發者。全域模式會改變路由選擇，TUN 則接管網路層流量；兩者都不應改變瀏覽器驗證網站身分的標準。若測試後恢復正常，仍須找出原本的規則或連線路徑為何異常。

排除問題後的檢查清單

1. 還原所需的規則模式和代理入口，移除暫時的測試設定，並保持憑證驗證開啟。
2. 關閉舊分頁後重新瀏覽，確認主機名稱正確、憑證有效，且不再出現錯誤。
3. 在用戶端連線記錄中確認實際套用的策略，避免依據快取頁面或未經預期出口的請求判斷結果。
4. 如需回報問題，請提供作業系統、瀏覽器版本、用戶端與核心版本、錯誤代碼、發生時間及已去除敏感資訊的憑證資料；不要提交訂閱網址、節點密碼或完整設定。

建議依序排查：錯誤代碼 → 時間 → 憑證詳細資料 → 本機 HTTPS 檢查 → 直連與固定出口比對 → DNS 與網路路徑。保留驗證防線，再逐項縮小範圍，比同時修改多個設定欄位更容易找出原因。