TLS 憑證錯誤排查:系統時間不同步與 SNI 設定錯誤

遇到憑證無效或交握失敗,請依序檢查裝置時間、SNI 與偽裝網域是否相符、allowInsecure 設定及指紋,逐一排除常見 TLS 錯誤。

本文重點

適用於 v2rayN、v2rayNG 與 v2flyNG 連線時發生憑證驗證失敗、TLS 交握中斷等問題。先從日誌判斷是時間、網域或信任鏈錯誤,再核對節點的連線位址、SNI 與傳輸層 Host;一般 TLS 與 REALITY 請分開檢查。每次只修改一個欄位,維持憑證驗證開啟,最後以實際連線確認是否恢復。

一、先看日誌:憑證錯誤不代表連接埠不通

TLS 交握是在傳輸連線建立後才進行。TCP 能連線,只代表目標位址的連接埠有回應,不代表憑證可信、網域相符或代理驗證成功。v2rayN 的 TCPing 有結果,但實際連線測試失敗,兩者並不矛盾;因此不必反覆切換本機代理連接埠。

先記下用戶端名稱、版本、實際執行的核心版本、節點安全類型與失敗時間。停止在背景反覆測試,只對一個節點發起一次連線,並在日誌中找出同一時間最內層的錯誤。外層的 failed to find an available destination 只是彙總訊息,還要繼續查看後面的具體原因。

錯誤:x509: certificate has expired or is not yet valid

原因:本機時間不在憑證有效期限內,也可能是伺服器憑證確實已過期。解決方式:先同步裝置時間,再檢查憑證的起訖日期;若時間正確仍然失敗,請伺服器管理者更新憑證或修正憑證部署。

錯誤:x509: certificate signed by unknown authority

原因:無法建立信任鏈,常見原因包括缺少中繼憑證、使用自簽憑證,或網路中的憑證遭到替換。解決方式:核對憑證簽發者與完整憑證鏈,不要直接關閉驗證。

錯誤:remote error: tls: handshake failure

原因:對端拒絕交握,可能與 SNI、通訊協定版本、用戶端憑證要求或伺服器政策有關。解決方式:先核對伺服器要求的安全類型與 SNI,再參考伺服器日誌判斷;不能只憑這一行就認定憑證已過期。

二、同步系統時間:檢查日期、時區與憑證有效期限

憑證包含 notBefore 和 notAfter 時間。驗證時會使用系統時鐘對應的絕對時間,不只是查看工作列顯示的時數。只調整時區、但維持絕對時間正確,通常不會讓憑證失效;若手動把本地時間改成另一個時區的時間,則可能造成數小時的誤差。

  1. 確認日期

    先確認年、月、日正確。裝置長時間關機、還原快照或主機板時鐘異常後,日期可能會跳回過去。不要只調整分鐘,讓時間看起來接近即可。

  2. 同步桌面系統時間

    Windows 11 前往「設定」→「時間與語言」→「日期與時間」,開啟「自動設定時間」,確認「時區」正確,再按一下「立即同步」。macOS 前往「系統設定」→「一般」→「日期與時間」,開啟自動設定日期與時間。

  3. 同步 Android 時間

    Android 通常可在「設定」→「系統」→「日期與時間」中開啟「自動設定時間」與自動時區。不同系統的選項名稱可能不同,可在設定中搜尋「日期與時間」。

  4. 重新測試並記錄結果

    確認同步成功後,重新啟動用戶端並連線。若仍顯示憑證過期,請記下錯誤中的目前時間與憑證有效期限,交由節點維護者核對伺服器實際提供的憑證。

Windows 可在終端機執行 w32tm /query /status,查看時間同步狀態;同步指令 w32tm /resync 通常需要系統管理員權限,且須仰賴 Windows 時間服務。若指令失敗,請先檢查服務與網路;執行過指令不代表已成功同步。Linux 可用 timedatectl status 檢查系統時鐘與時間同步服務狀態,啟用方式則視發行版而異。

結論:時間正確但憑證仍過期,應檢查伺服器

同步成功且錯誤中顯示的目前日期正確,就不要再反覆調整裝置時鐘。請伺服器維護者檢查憑證更新、服務重新載入,以及不同入口是否仍提供舊憑證。

三、分別核對 SNI、連線位址與 Host

SNI 是 TLS ClientHello 中用來指定目標主機名稱的擴充欄位;用戶端設定中的 serverName 通常會用來選擇交握名稱及驗證憑證名稱,實際行為取決於核心。此欄位須符合伺服器要求,且憑證的 SAN 必須涵蓋該網域。「偽裝網域」不是統一的通訊協定欄位,請先確認提供者指的是 SNI、WebSocket Host,還是其他傳輸層參數。

欄位用途核對重點
連線位址與連接埠決定實際連線的伺服器入口可以是網域或 IP;連接埠以節點提供的設定為準
SNI / serverNameTLS 交握名稱,以及通常用來驗證憑證名稱的依據只填網域,不含通訊協定、路徑或連接埠
WebSocket HostWebSocket 交握中的 HTTP 主機欄位須符合反向代理或上游網站的路由設定
WebSocket pathWebSocket 請求路徑保留開頭的斜線;路徑錯誤通常與憑證名稱錯誤無關

連線位址使用 IP、SNI 使用網域,可能是正常設定。例如直接連線到 IP,但透過網域完成 TLS 名稱驗證。反過來說,移除 SNI 後改由用戶端以 IP 驗證,而憑證只包含網域,就可能出現 cannot validate certificate ... because it doesn't contain any IP SANs。不要只因「位址與 SNI 不同」就判定設定錯誤。

以下是一般 TLS 的局部設定示意,並非可直接連線的完整節點,也不適用於 REALITY。實際節點的傳輸類型必須維持原設定;範例省略連線位址、身分驗證及其他輸出欄位。

{
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "example.com",
      "allowInsecure": false
    }
  }
}

四、allowInsecure:不能取代憑證修復

將 allowInsecure 設為 true 會略過一般的伺服器憑證驗證。介面中的「允許不安全連線」或「略過憑證驗證」通常就是這項設定。TLS 加密仍可能存在,但用戶端無法再透過一般憑證鏈與名稱驗證確認對端身分;這不是通用的「提升相容性」按鈕。

狀況:關閉驗證後連線成功

原因:問題可能出在憑證有效期限、網域比對或信任鏈,不一定是網路品質不佳。解決方式:重新開啟驗證,逐項修正對應的憑證問題;這種情況不能證明對端身分可信。

狀況:關閉驗證後仍然交握失敗

原因:問題可能發生在憑證驗證之前,例如連接埠並非 TLS 服務、SNI 遭伺服器拒絕,或安全類型設定錯誤。解決方式:回頭檢查位址、連接埠與交握設定,不要再疊加不安全選項。

五、指紋與 REALITY:依實際核心分別排查

用戶端指紋描述 TLS 交握特徵,不是憑證網域,也不是略過驗證的開關。在支援相關功能的 Xray 設定中,fingerprint 可使用 chrome 等核心支援的值。修改指紋不會讓過期憑證恢復有效,也不會讓不相符的 SAN 自動涵蓋目標網域。

設定類型優先檢查避免混用
一般 TLS裝置時間、serverName、憑證有效期限與完整憑證鏈不要以 REALITY 的公鑰參數取代憑證設定
REALITYserverName、伺服器公鑰、shortId、指紋及伺服器要求不要套用一般 TLS 的關閉憑證驗證做法
未啟用 TLS 的節點先確認錯誤是否來自訂閱更新、測試目標或其他連線不要隨意在原節點上啟用 TLS

v2rayNG 使用 Xray 核心,v2flyNG 使用 V2Fly 核心,兩者功能與欄位不能照搬。v2rayN 則須以目前節點實際使用的核心為準。遇到 REALITY 或 XTLS Vision 設定,應先確認所選核心支援這些功能;不能只因用戶端能匯入連結,就認定所有參數都已生效。

六、使用交握工具定位:連接埠、憑證鏈與伺服器

若裝置已安裝 OpenSSL,可直接用它檢視一般 TLS 入口的憑證。以下指令中的 example.com 僅為格式示例,執行前必須替換成實際入口與伺服器要求的 SNI。連線連接埠也以節點設定為準;此測試只驗證 TLS 層,不會驗證 VMess 或 VLESS 的身分驗證。

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error
443
TLS 入口連接埠範例,並非所有節點都使用相同連接埠
TLS 1.2
常見交涉版本,須由雙方支援
TLS 1.3
另一種常見交涉版本,不是指紋名稱

結論:工具測試通過,只代表該次 TLS 檢查成功

若憑證驗證正常但代理仍無法使用,請改查傳輸路徑、身分參數與伺服器入站設定。不要繼續修改已確認正確的 SNI,也不要把所有交握後的錯誤都歸咎於憑證。

七、修復後驗證與常見問題

每次修改後先儲存節點,再重新建立連線;既有長連線不一定會立即套用新參數。依「核心啟動正常 → 節點交握成功 → 實際請求可用」的順序確認。若用戶端日誌已不再出現憑證錯誤,但瀏覽器仍有異常,請改查系統代理、應用程式代理設定與路由規則,不要把排查範圍重新擴大到所有 TLS 參數。

  1. 確認自動校時成功,並檢查裝置重新啟動後日期仍然正確。
  2. 確認 SNI 符合伺服器要求、憑證驗證維持開啟,且傳輸層 Host 與路徑沒有被誤改。
  3. 選取修復後的節點,執行一次實際連線測試,再透過已正確設定代理的應用程式存取目標。
  4. 記錄修改的欄位與結果;若設定來自訂閱,請聯絡提供者修正來源資料,避免下次更新時覆蓋本機修改。
更新訂閱時出現憑證錯誤,也是節點的 SNI 設定錯了嗎?

不一定。下載訂閱時,用戶端會對訂閱網址發出 HTTPS 請求,驗證的是訂閱網站的憑證,通常不會使用節點編輯視窗中的 SNI。先判斷錯誤發生在「更新訂閱」還是「連線節點」,再檢查相應網域、系統時間與信任鏈。

同一個節點在另一台裝置上能用,就能排除伺服器問題嗎?

不能完全排除。兩台裝置可能解析到不同入口,也可能使用不同的信任庫、核心或時間設定。請先比對實際連線位址、SNI、憑證簽發者與到期時間,再逐項檢查設定;不要直接複製整套系統設定。

瀏覽器可以開啟偽裝網域,為什麼用戶端仍然連不上?

瀏覽器可能連到不同位址、使用不同的信任庫,也未必走相同的傳輸路徑。網頁能開啟,只代表該次網頁請求成功。用戶端仍須依節點提供的位址、連接埠、SNI、傳輸參數與身分參數完成連線。

下載用戶端