啟用代理後瀏覽器顯示憑證不受信任：HTTPS 憑證錯誤原因與排查方式

一、先保留錯誤資訊，別直接略過警告

啟用 Clash 系列用戶端後，瀏覽器若出現「你的連線不是私人連線」或「此連線非私人連線」，表示瀏覽器無法驗證目標網站的身分。這不代表節點逾時，也不代表訂閱失效。連線可能已抵達某台伺服器，只是伺服器提供的憑證、憑證鏈或本機信任狀態不符合要求。

排查前，先不要在該頁面輸入密碼、付款資訊或驗證碼。記下網址列中的完整主機名稱、瀏覽器錯誤碼、憑證簽發者及有效期限。截圖求助時，請遮蔽帳戶資訊、訂閱網址及含有權杖的查詢參數。

錯誤範例	含義與優先檢查項目
`NET::ERR_CERT_DATE_INVALID`	本機時間不正確，或憑證尚未生效、已過期。先確認時間，再檢查憑證日期。
`NET::ERR_CERT_AUTHORITY_INVALID`	無法建立受信任的憑證鏈。請檢查簽發者、根憑證來源及伺服器中繼憑證。
`NET::ERR_CERT_COMMON_NAME_INVALID`	造訪的主機名稱與憑證涵蓋範圍不符。請特別查看憑證的主體別名。
Safari 顯示「此連線非私人連線」	這是彙整提示。請展開詳細資訊，查看憑證和具體原因，不能只看提示標題就下判斷。

二、Clash 代理在 HTTPS 握手中負責什麼

一般轉送不會替換網站憑證

以瀏覽器透過本機 HTTP 代理造訪 HTTPS 網站為例：瀏覽器先向代理傳送 CONNECT example.com:443，代理建立可用的轉送通道，接著由瀏覽器與目標網站進行 TLS 握手。網站憑證由瀏覽器驗證；本機監聽連接埠即使是 7890，也不代表 HTTPS 內容變成明文。

SOCKS 代理與 TUN 接管的入口不同，但本身也不會解密 HTTPS。Clash 與 Clash Meta（現稱 mihomo）的常規代理轉送不需要使用者安裝用來解密網頁的根憑證。設定中的流量嗅探也不等於解密 HTTPS 內文；讀取可見的握手中繼資料，和簽發替代憑證是兩回事。

代理節點的 TLS 與網站 TLS 是兩層連線

部分節點通訊協定本身也會使用 TLS。此時，用戶端與節點伺服器之間有一層握手，瀏覽器與網站之間則有另一層握手。若記錄顯示節點端憑證驗證失敗，常見結果是代理連線失敗、逾時或通道錯誤，不一定會出現瀏覽器的網站憑證警告。

部分設定支援的 skip-cert-verify 是針對相應的出站連線進行憑證驗證，不會修復網站的憑證鏈，也不會讓瀏覽器信任該網站。不要為了解決網頁錯誤就將它設為 true；請確認節點位址、伺服器憑證及 TLS 伺服器名稱均由服務提供者正確設定。

三、先檢查系統時間，再逐項比較

確認 macOS 日期與時間

在 macOS Ventura 13 及後續版本中，開啟「系統設定」→「一般」→「日期與時間」，確認是否已啟用自動設定日期與時間，並核對目前日期、年份與時區。較舊版本的 macOS 可在「系統偏好設定」→「日期與時間」中檢查。還原舊系統備份或長時間未連線後，尤其要確認年份沒有偏差。

憑證有效期限是依時間戳記判定。若本機時間錯誤，即使是正常網站，也可能被判定為尚未生效或已過期。只修改時區通常無法校正錯誤的系統時鐘；請以自動同步後的實際時間為準。修正後，結束並重新開啟瀏覽器，再造訪相同主機名稱。

使用同一網址記錄四種測試結果

目前節點：記下瀏覽器錯誤、憑證簽發者，以及用戶端連線清單中的規則與出站策略。
其他節點：只切換策略群組中的節點，不要同時變更 DNS、規則和瀏覽器設定。
直接連線：暫時關閉系統代理與 TUN，並確認瀏覽器擴充功能或獨立代理設定沒有繼續接管流量。
其他網路：情況允許時，改用個人熱點重複測試，以判斷目前的 Wi-Fi、路由器或組織網路是否造成影響。

直接連線測試失敗，不一定代表網站憑證有問題：目前的網路可能根本無法連上該網站。只有取得具體憑證、錯誤碼或成功頁面，結果才有比較價值。測試時保持網址不變，尤其要留意重新導向後是否到了另一個子網域。

四、檢查中間人解密與陌生根憑證

公司網路的 HTTPS 檢查、除錯封包擷取工具及某些安全軟體，可能會在瀏覽器與網站之間終止 TLS，再向瀏覽器提供重新簽發的憑證。這類機制需要裝置信任相應的根憑證。若根憑證未正確部署、憑證已過期或軟體移除不完整，都可能出現「不受信任」的提示。

查看簽發者：在瀏覽器警告的詳細資訊或憑證檢視器中，記下憑證簽發者。如果多個無關網站都出現相同的陌生組織名稱，這是值得進一步調查的線索。
檢查憑證儲存區：開啟「應用程式」→「工具程式」→「鑰匙圈存取」，分別查看「登入」與「系統」鑰匙圈中的憑證。不要批次刪除系統根憑證。
確認除錯工具設定：若曾安裝 HTTPS 封包擷取工具，請先關閉它的 HTTPS 解密與系統代理接管功能，再重新測試，避免兩個本機代理彼此衝突。
確認裝置是否受管理：若 Mac 由公司或機構管理，憑證可能透過裝置管理設定檔部署。請管理員確認憑證用途、有效期限及部署狀態，不要自行變更組織的信任政策。

簽發者變更本身無法直接證明發生攻擊。大型網站可能更換憑證機構，CDN 的不同邊緣節點也可能傳回不同憑證。應綜合主機名稱涵蓋範圍、有效期限、信任鏈及多種連線路徑進行判斷。若個人裝置突然被要求安裝來源不明的根憑證才能「修復代理」，請先停止操作並確認來源。

五、判斷是節點異常、DNS 偏差還是網站設定錯誤

只有一個節點出錯：先停用該節點

如果其他節點都能正常連線至同一主機名稱，但某個節點持續傳回不相關網域的憑證，可能是該出口的 DNS、網路遭劫持或伺服器端路由異常。請先停止透過該節點造訪敏感網站，再向服務提供者提供發生時間、目標主機名稱、錯誤碼及憑證簽發者。單憑一次錯誤，不能斷定節點營運者實施了劫持。

DNS 遭竄改後，連線可能會到達錯誤的伺服器；正常的憑證驗證通常會阻止該伺服器冒充原網站。mihomo 的 Fake-IP 模式則是在本機將網域名稱對應至合成位址，再由核心處理連線的機制；看到合成位址不等於 DNS 污染。請參照連線詳細資訊中的識別網域、命中規則及實際出站進行核對。

所有連線路徑都只有一個網站出錯：檢查網站憑證

若同一網站透過不同節點、直接連線及其他裝置測試都出現類似錯誤，應考慮網站憑證過期、涵蓋的網域不完整或缺少中繼憑證鏈設定。例如，涵蓋 *.example.com 的萬用字元憑證通常可匹配 www.example.com，但不能只靠這條規則匹配 a.b.example.com，也不會自動涵蓋裸網域 example.com。

伺服器若漏掉中繼憑證，不同瀏覽器可能因快取或補齊能力不同而有不同表現。因此，「Safari 能開，另一個瀏覽器卻不能」也無法完全排除伺服器設定問題。記錄憑證鏈資訊並聯絡網站管理員，比變更本機信任設定更合適。

只在公共 Wi-Fi 發生：先完成網路登入

飯店、機場等網路可能要求先登入入口網站。若入口網站試圖將 HTTPS 請求導向認證頁面，就可能造成網域不符。請先使用 macOS 的網路登入提示完成認證，不要在憑證警告頁面輸入網站密碼。認證後仍有異常，可改用個人熱點測試。

六、使用 curl 比較直接連線與本機代理

終端機測試能提供不受瀏覽器快取與擴充功能影響的線索，但不能取代瀏覽器測試結果。請先在用戶端設定中確認 HTTP 或混合監聽連接埠；以下的 127.0.0.1:7890 只是明確的測試範例，並非所有用戶端都使用這個固定值。請將範例網域換成實際出錯的主機名稱，並保留 https://。

# 記錄 curl 版本與 TLS 後端
curl --version

# 略過 curl 的代理設定；若已啟用 TUN，流量仍可能被接管
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '*' https://example.com/

# 明確使用本機 HTTP / 混合代理連接埠
curl -Iv --connect-timeout 10 --max-time 20 --noproxy '' \
  --proxy http://127.0.0.1:7890 https://example.com/

建立真正的直接連線對照：除了使用 --noproxy '*'，也要關閉 TUN，並確認沒有其他 VPN 或網路延伸功能接管連線。這個參數只能略過 curl 自身的代理設定。
區分通道與網站：輸出中的 200 Connection established 通常表示代理已接受 CONNECT 請求，不代表目標網站已通過憑證驗證。
判讀錯誤類型：curl: (60) 通常表示對端憑證驗證失敗；curl: (7) 通常表示連線失敗。請先分辨是本機代理沒有監聽，還是網站 TLS 驗證失敗。
留意信任來源差異：macOS 內建的 curl 與從其他管道安裝的 curl，可能使用不同的 TLS 後端與 CA 儲存區。一個成功、一個失敗時，請核對版本和信任來源。

這些命令將連線逾時設為 10 秒、總時限設為 20 秒，避免測試長時間沒有回應；這些數值不是效能測試結果。-I 會發出 HEAD 請求，部分網站可能回應 405；但若 TLS 驗證已完成，HTTP 方法不受支援與憑證錯誤是兩個不同問題。

七、依據證據修復，並確認問題沒有遭到掩蓋

時間錯誤：恢復自動校時，重新開啟瀏覽器，確認原本的主機名稱可以正常通過驗證。
組織的 HTTPS 檢查異常：請管理員修復憑證部署或檢查閘道，不要透過聊天附件臨時安裝來源不明的根憑證。
單一節點異常：暫停使用該節點，保留證據並聯絡服務提供者；改用其他可信任的連線路徑重新測試。
網站憑證異常：等待網站更新憑證、補齊中繼憑證鏈或修正網域綁定；在本機重新安裝用戶端通常無法解決問題。
本機軟體衝突：依照軟體本身的說明停用 HTTPS 解密與代理接管功能，每次只調整一項，再重複相同測試。

最後，恢復原本需要的規則模式、系統代理或 TUN 設定，並重新檢查目標網站及另外兩個常用的 HTTPS 網站。確認網址列沒有意外跳轉、憑證有效，而且用戶端連線清單中的出站路徑符合預期。如果只是換了瀏覽器後不再顯示警告，仍應查明兩者在信任來源或擴充功能設定上的差異，不要直接認定問題已解決。

用戶端安裝與基本設定可參考快速入門；需要確認代理通訊協定、規則與 DNS 設定時，可查閱通訊協定手冊。排查憑證錯誤時，重點始終是時間、主機名稱、憑證鏈與連線路徑，而不是反覆更新訂閱或隨意更換連接埠。