啟用代理後網站出現 HTTPS 憑證錯誤：原因解析與排除方法

先確認錯誤類型，不要直接略過憑證警告

啟用 Clash 後，瀏覽器出現「您的連線不是私人連線」，不代表代理軟體需要安裝憑證。請先停留在警告頁面，記下完整網域、錯誤代碼和發生時間。暫時不要登入帳號、付款，也不要從錯誤頁面下載所謂的憑證修復工具。

一般的 HTTP CONNECT 或 SOCKS5 代理主要負責轉送連線。瀏覽器與目標網站之間仍會進行 TLS 交握，並由瀏覽器驗證網站憑證的網域、有效期限與信任鏈。Clash、Clash Meta（mihomo）一般的代理轉送不需要瀏覽器信任新的本機根憑證。

「忽略憑證錯誤」並非通用的連線修復方法。請先判斷憑證為何不受信任，再調整時間、網路或代理路徑。不要把關閉驗證當成日常設定。

不同瀏覽器的提示文字可能不同，Firefox 也可能顯示 SEC_ERROR_UNKNOWN_ISSUER 等代碼。協定錯誤與連線逾時不一定代表已收到憑證，不能一概歸因於「憑證過期」。

第一步：校正系統時間並記錄憑證資訊

先同步時間，再重新開啟頁面

1. Windows 11：前往「設定」→「時間與語言」→「日期與時間」，開啟「自動設定時間」，確認時區後點選「立即同步」。
2. macOS：前往「系統設定」→「一般」→「日期與時間」，開啟自動設定日期與時間，並確認時區。
3. Android：通常可在「設定」→「系統」→「日期與時間」中開啟自動設定；不同廠牌的選單名稱可能是「其他設定」。
4. iPhone：前往「設定」→「一般」→「日期與時間」，開啟「自動設定」。

日期相差數個月，可能導致許多正常網站同時出現錯誤。只看到時區不同，不代表 TLS 驗證一定會失敗；關鍵在於裝置的實際時間是否正確。同步後請關閉原本出錯的分頁，再重新造訪原網域，不要只是不斷重新整理舊的警告頁面。

記下三項憑證資訊

透過瀏覽器提供的「檢視憑證」功能，記下有效期限、簽發者和「主體替代名稱」（SAN）。新版瀏覽器的入口可能位於網址列左側的網站資訊，或警告頁面的進階資訊中。請勿為了檢視憑證而選擇繼續前往。

• 有效期限：目前日期是否介於生效時間與到期時間之間。
• SAN：是否涵蓋網址列中的實際主機名稱。憑證涵蓋 *.example.com，通常不涵蓋根網域 example.com，也不涵蓋更深一層的 a.b.example.com。
• 簽發者：是否顯示飯店、公司閘道或安全軟體的名稱。名稱本身不能證明憑證可信，仍需配合網路環境確認。

如果時間正確，且只有一個網站的憑證已過期，應由網站維護者更新憑證。更換節點或許碰巧能連到另一個正常入口，但不能取代網站修復，也不應降低驗證強度來繞過問題。

第二步：排除公共 Wi-Fi 認證與本機 HTTPS 檢查

機場、飯店和校園訪客 Wi-Fi 通常要求先完成網頁認證。尚未認證時，閘道可能會重新導向一般 HTTP 要求；若 HTTPS 也遭到錯誤攔截，收到的憑證可能屬於認證閘道，而非目標網站。此時盲目切換代理節點通常無濟於事。

1. 暫時關閉系統代理與 TUN，並保持目前的 Wi-Fi 連線。只關閉其中一項時，另一項仍可能接管流量。
2. 優先使用系統跳出的「登入網路」視窗。若沒有跳出視窗，可開啟 http://example.com/ 觸發認證重新導向；此網址只用來引出認證頁面，不可用來提交敏感資料。
3. 確認認證頁面屬於現場網路業者，再完成必要的認證。若認證頁面本身出現憑證警告，請先向現場人員確認。
4. 確認直接連線至一般 HTTPS 網站正常後，再啟用原有的代理設定並重新測試。

如果同一台裝置改用手機熱點後恢復正常，應優先懷疑原 Wi-Fi 的認證、閘道或網路政策；但這只是判斷線索，還不足以確認原因。企業網路可能依規定部署 HTTPS 檢查，請向管理員確認合法的憑證派送方式，不要自行繞過組織政策。

只有某台電腦異常時，檢查本機攔截鏈

安全軟體的「加密連線掃描」、封包擷取工具和除錯代理可能會介入 HTTPS 解密。先確認最近是否啟用這些功能，並查看憑證簽發者是否與之相符。個人裝置可依軟體官方說明暫停相關功能，進行一次對照測試，之後再恢復原設定；受管理的裝置應交由管理員處理。

不要大量刪除系統根憑證，也不要匯入節點業者提供的陌生根憑證。一般代理訂閱通常包含節點、策略群組和規則，不需要安裝網站信任憑證才能運作。

第三步：以相同網域比較直連與代理

保持網址完全一致，只改變一個條件。以下的「直連」是指關閉系統代理、TUN，以及瀏覽器個別設定的代理；「代理」則是確認要求確實經過目前的用戶端。若網站無法直連，記錄為「逾時」即可；逾時不代表憑證正常。

使用 curl 區分驗證錯誤與連線失敗

以下範例假設用戶端的混合代理連接埠確實是 7890。請先在用戶端設定中確認連接埠；它並非所有安裝環境的固定值。Windows PowerShell 請使用 curl.exe，macOS 或 Linux 則可使用 curl。

# 略過明確設定的代理環境變數，測試直連
curl --noproxy "*" -Iv --connect-timeout 10 https://example.com/

# 明確連線至本機 HTTP 混合代理連接埠
curl --noproxy "" -x http://127.0.0.1:7890 -Iv --connect-timeout 10 https://example.com/

這裡的 http://127.0.0.1:7890 表示連線至本機 HTTP 代理，不代表目標網頁改用 HTTP。HTTPS 目標通常會透過 CONNECT 通道存取。不要任意改成 https://127.0.0.1:7890，後者要求本機代理入口本身支援 TLS。

測試直連時也應關閉 TUN，因為 --noproxy 無法略過系統層級的透明接管。curl 回傳碼 60 通常表示憑證驗證失敗，7 表示連線失敗，28 表示逾時；這些結果並非本文實測數據。curl 和瀏覽器可能使用不同的信任庫，即使結果不同，也應繼續核對，而非任選一個結果作結論。

第四步：確認規則、DNS 與實際出口

規則設定錯誤通常不會直接修改網站憑證，但可能讓連線走錯出口，或讓網域解析到不適合目前路徑的伺服器。先在用戶端的「連線」頁面篩選出錯的網域，再重新發出一次要求，記錄命中的規則、策略群組和最終節點。接著查看記錄中是否出現解析失敗或交握失敗。

全域模式僅供短時間對照測試

如果規則模式會出錯，但同一節點在全域模式下正常，請檢查該網域是否提早匹配到 DIRECT，或被分配到另一個策略群組。測試後請恢復規則模式。規則由上而下匹配，不應只為了單一網域就長期將所有流量改走同一個出口。

以下僅示意規則順序，並非完整設定。新增前請先確認策略群組中確實有名為 Proxy 的群組，並將範例網域替換為實際出錯的網域。如果設定由訂閱管理，請優先使用用戶端支援的覆寫或合併功能，避免下次更新時改動遺失。

mode: rule
rules:
  - DOMAIN,example.com,Proxy
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,Proxy

fake-ip 位址不代表憑證遭到偽造

mihomo 的 fake-ip 模式會為網域指派虛擬位址，常見網段為 198.18.0.0/16，實際設定依配置而異。核心會透過對應關係繼續處理原始網域；看到這類位址，不能證明發生了 HTTPS 解密。瀏覽器仍應使用網域進行 TLS 連線，並驗證該網域的憑證。

• 不要將網址列中的網域改成解析出的 IP 位址來測試憑證。這會改變憑證比對條件，也可能影響 SNI 和虛擬主機的選擇。
• 檢查本機 hosts 和設定中的 hosts 區段，確認沒有將出錯的網域固定指向舊伺服器。
• 如果瀏覽器啟用了安全 DNS，請記下使用的解析器；它可能與用戶端 DNS 走不同路徑。只有在了解影響後才進行單項對照測試，測試後請恢復原設定。
• 變更 DNS 後應重新建立連線。Windows 可使用 ipconfig /flushdns 清除系統快取，但瀏覽器和用戶端可能仍有各自獨立的快取。

不要一次更換 DNS、節點、規則模式和 TUN 設定。每次只變更一項，重新測試相同 URL，並記錄錯誤代碼和簽發者是否有變化，才能判斷哪個步驟產生效果。

區分瀏覽器網站憑證與節點傳輸憑證

另一種常見混淆是：瀏覽器沒有顯示網站憑證警告，但用戶端記錄出現 x509: certificate signed by unknown authority。如果核心連線使用 TLS 傳輸的代理節點，就可能發生這種情況。這是「用戶端到節點」的憑證問題，不一定是「瀏覽器到網站」的憑證問題。

先確認節點位址、伺服器憑證有效期限、憑證鏈，以及節點業者指定的伺服器名稱設定。自建服務應修復憑證鏈，或以受控方式設定信任；訂閱節點則應聯絡業者確認。不要憑猜測修改 SNI，也不要填入無關網站的網域。

節點設定中的 skip-cert-verify: true 會略過該節點 TLS 連線的憑證驗證，無法修復目標網站的憑證。瀏覽器端的忽略驗證選項同樣不適合當成長期處理方式。

如果只有一個節點反覆出現異常，請先停用該節點，改用已確認正常的出口，再將發生時間、節點識別資訊和已遮蔽敏感資訊的記錄提供給業者。不要公開訂閱 URL、存取權杖、節點密碼或完整設定檔。

恢復後的確認與故障紀錄

網頁恢復顯示還不夠，還應確認沒有透過暫時降低驗證強度來「消除」警告。依照下列順序完成檢查，可降低下次切換網路時再次發生的機率。

1. 恢復日常使用的規則模式，並確認系統代理與 TUN 的啟用狀態符合原本的使用方式。
2. 重新開啟原本出錯的網域，確認不再出現憑證警告，憑證 SAN 與主機名稱相符，且目前日期仍在有效期限內。
3. 再檢查兩個平時常用的 HTTPS 網站，排除只有單一頁面因快取而成功的情況。
4. 還原暫時變更的 DNS、規則或除錯設定；若有必須保留的變更，請寫入支援的覆寫設定並備份。
5. 記下最終原因，例如「系統年份錯誤」、「Wi-Fi 尚未認證」或「某節點出口異常」，不要只記「重新啟動後就好了」。

若需進一步尋求協助，請提供瀏覽器名稱與版本、系統版本、用戶端與核心版本、故障網域、錯誤代碼、直連與代理的對照結果，以及憑證簽發者。截圖前請隱藏帳號、私人網域和訂閱憑證。提供準確資訊，比反覆匯入訂閱更有助於找出問題。

排查順序可固定為：先確認時間與錯誤類型，再排除 Wi-Fi 認證和本機檢查，接著比較出口，最後檢查規則與 DNS。若遇到不明簽發者，或敏感網站出現異常，請停止提交資訊；這比強行開啟頁面更重要。