TLS 交握與憑證錯誤排解：系統時間、憑證有效期與 SNI

TLS 錯誤發生在哪一層

TLS 交握發生在代理核心與遠端伺服器建立加密連線的階段。v2rayN 負責匯入訂閱、編輯伺服器與產生設定，Xray 核心負責實際連線；系統代理或 TUN 決定哪些應用程式流量會進入用戶端。這三層需要分開判斷：瀏覽器未接入代理時，即使節點設定正確，也不會經過核心；應用程式已接入但核心無法完成 TLS 交握時，記錄中才會出現憑證或交握相關錯誤。

VMess、VLESS 是代理協定名稱，TLS 則是傳輸安全層。使用 VLESS 不代表一定啟用 TLS，使用 VMess 也不代表憑證驗證方式不同。真正需要核對的是節點傳輸設定中的安全類型、目標連接埠、伺服器位址、SNI，以及憑證涵蓋的網域。常見的 443 只是 TLS 伺服器連接埠，並非強制值；若伺服器端使用其他連接埠，用戶端就必須保持一致。

排查時先找最早出現的 TLS 錯誤，不要只看後續的連線關閉、EOF 或重試失敗。憑證驗證失敗後，核心通常會結束目前連線，之後出現的讀取失敗只是結果。若同一份訂閱中的所有節點同時異常，優先檢查本機時間、網路中間設備與用戶端全域設定；若只有一個網域異常，更可能是該節點的憑證、SNI 或伺服器端部署問題。

第一步：確認 Windows 時間、時區與同步狀態

憑證包含生效時間 notBefore 與到期時間 notAfter。核心會使用本機系統時間判斷憑證目前是否有效，因此日期、時區或時鐘偏差都可能觸發「尚未生效」或「已經過期」。例如電腦實際位於 UTC+8，但時區被設為 UTC，而使用者又手動將時鐘調成當地時間，表面顯示可能接近正確，內部時間基準卻會產生偏移。

先開啟 Windows「設定」→「時間與語言」→「日期與時間」，確認「自動設定時間」和「自動設定時區」的狀態符合目前使用環境，然後按一下立即同步。公司網路或受管理裝置可能指定內部時間來源，此時不要任意替換策略，應記錄同步來源與偏差，再交由裝置管理員確認。

1. 比較系統日期、小時與分鐘，不要只檢查工作列顯示的分鐘數。
2. 確認時區名稱與所在地一致，位於夏令時間地區時也要檢查目前偏移量。
3. 執行狀態查詢，查看最近一次成功同步的時間與時間來源。
4. 修正後完全結束 v2rayN，再重新啟動核心並使用同一個節點重新測試。

w32tm /query /status
tzutil /g
powershell -NoProfile -Command "Get-Date -Format o"

可將 60 秒作為人工排查的警戒線，而不是憑證標準中的統一容忍值：如果本機與可信時間來源相差超過 60 秒，就應先校正時鐘。不同 TLS 實作與伺服器部署可能有不同表現，不應依賴某個實作可能提供的時間寬限。若修正時間後所有節點同時恢復，問題就在本機時間鏈路，不需要逐一修改訂閱節點。

第二步：核對憑證有效期、簽發鏈與網域

時間正確後，再檢查憑證本身。憑證詳細資料至少要查看三項：有效期、主體別名，以及簽發鏈是否能連接至系統信任的根憑證。只看頁面上顯示的到期日並不足夠，因為憑證也可能尚未生效，或缺少中繼憑證設定。伺服器端更換憑證後，若只更新葉憑證而未提供正確的中繼憑證，部分環境可能成功，其他環境則會回報簽發者未知。

網域比對主要以憑證的 Subject Alternative Name 為依據。用戶端以 IP 作為連線位址，而憑證只涵蓋網域時，直接使用 IP 驗證通常會失敗；連線位址是某個網域，但 SNI 填寫了憑證未涵蓋的另一個網域，也會產生名稱不符。萬用字元憑證的涵蓋範圍同樣有限，例如 *.example.com 通常可涵蓋一層子網域，但不能據此推定它涵蓋更深層的子網域或根網域。

還要區分「憑證到期」與「舊連線仍可用」。已建立的長連線不一定會在憑證到期的瞬間中斷，但新連線會重新交握並執行驗證，因此可能出現用戶端剛啟動時失敗、已維持的連線暫時正常，或切換網路後才暴露問題。判斷時應完全重新啟動核心並建立新連線，不要只依據仍在維持的單一工作階段。

第三步：檢查 SNI、伺服器位址與訂閱欄位

SNI 是用戶端在 TLS 交握階段傳送的伺服器名稱，伺服器端可據此選擇憑證與虛擬主機。它不等同於 DNS 解析結果：伺服器位址決定連線至哪個 IP，SNI 則決定交握時宣告要存取哪個名稱。兩者在特定部署中可以不同，但必須獲得伺服器端設定支援，且回傳的憑證必須涵蓋用於驗證的伺服器名稱。

在 v2rayN 中先選取目標伺服器，使用右鍵選單「編輯伺服器」檢查位址、連接埠、傳輸安全性與 SNI；需要檢查全域行為時，再進入「設定」→「參數設定」。不同介面版本的欄位分組可能有所調整，但不要把「位址」、「Host」和「SNI」當成同一個值機械式複製。WebSocket 的 Host 屬於 HTTP 請求標頭，SNI 屬於 TLS 交握，伺服器端反向代理可能要求兩者相同，也可能明確要求不同。

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

• 匯入 VLESS 分享連結中的 sni 參數後，應與用戶端編輯介面顯示的伺服器名稱一致。
• 更新訂閱可能會覆蓋手動修改的節點欄位；重新測試前要確認目前選取的確實是修改後的設定。
• 位址填寫 IP、SNI 填寫網域時，先確認伺服器端明確支援這種組合。
• 將連接埠從 443 改為其他值後，需要同時確認伺服器端監聽、防火牆放行規則與用戶端連接埠。
• 路由分流只會選擇流量出口，不會修正錯誤的憑證名稱或 SNI。

如果節點來自訂閱，建議先記錄原始值，再更新一次訂閱並比較欄位。手動修正後只暫時有效，下次更新又失敗，表示訂閱來源仍在下發錯誤值；正確的處理方式是修正訂閱產生端，而不是每次匯入後重新編輯。若同一個網域存在多個節點，也要分別檢查它們的連接埠與傳輸設定，不能因為名稱相同就假定伺服器端入口完全一致。

第四步：依錯誤原文縮小範圍

TLS 記錄文字會隨核心版本與錯誤路徑而變化，但核心資訊通常可歸入時間、名稱、信任鏈與交握協商四類。複製記錄時保留錯誤前後的連線目標與時間，不必公開 UUID、訂閱網址或完整設定。排查重點是第一次失敗發生在哪一層，而不是累計出現了多少筆重試記錄。

如果記錄中只有逾時而沒有憑證資訊，連線可能尚未進入憑證驗證階段。此時先確認網域解析、目標 IP、TCP 連接埠與網路可達性。若連線至錯誤連接埠，例如將只提供一般 HTTP 的連接埠當作 TLS 入口，也可能出現連線關閉或無法識別的交握錯誤。連接埠可連通只代表有程式正在監聽，不代表監聽者就是預期的 TLS 服務。

如果公司、校園或受管理網路部署了 TLS 檢查，用戶端看到的憑證簽發者可能與直接連線時不同。在取得授權的前提下，可以切換至另一個合規網路進行比較：同一台裝置、同一個節點只更換網路後表現有所變化，表示應繼續檢查中間網路；更換網路後仍回報完全相同的網域或有效期錯誤，則更接近節點設定或伺服器端憑證問題。

為何不應長期跳過憑證驗證

「跳過憑證驗證」通常只會讓用戶端不再檢查憑證名稱與信任鏈，不會修復過期憑證、錯誤 SNI、錯誤連接埠或伺服器端虛擬主機。這個選項可能讓表面上的連線繼續，但同時移除了確認遠端身分的重要步驟，使錯誤設定與中間網路替換憑證更難被發現。因此最多只能用於受控環境中的短時間對照，不應作為日常設定結論。

更有效的比較方法是一次只變更一個條件。例如保持伺服器位址、連接埠與網路不變，只修正系統時間；時間確認無誤後，再只修正 SNI；接著確認伺服器端憑證鏈。每一步都重新啟動核心並建立新連線，記錄錯誤是否從「尚未生效」變成「名稱不符」，或是否進入後續協定階段。錯誤的變化本身就是定位線索。

1. 恢復 allowInsecure: false，確保測試結果包含完整的憑證驗證。
2. 確認系統日期、時區與同步來源，再完全重新啟動 v2rayN。
3. 核對憑證 notBefore、notAfter 與網域清單。
4. 核對伺服器位址、連接埠、SNI、Host 與訂閱原始欄位。
5. 檢查伺服器端虛擬主機、憑證鏈與實際監聽入口。
6. 最後才比較不同網路，判斷是否存在中間設備影響。

最後可用一條順序固定的判斷鏈收尾：所有節點失敗先查時間與網路，單一網域失敗先查憑證與 SNI，名稱錯誤查欄位對應關係，簽發者未知查憑證鏈，只有逾時則回到 DNS、連接埠與監聽。如此可避免在系統代理、路由規則與 TLS 參數之間反覆試錯，也能明確判斷問題屬於用戶端設定、代理核心記錄、訂閱資料還是伺服器端部署。