TLS 握手與憑證錯誤排查：系統時間、SNI 與略過驗證的取捨

TLS 握手失敗發生在哪個階段

TLS 位於 TCP 連線建立後、代理協定開始交換有效負載前。以使用 TLS 的 VMess 或 VLESS 節點為例，客戶端先解析伺服器位址並連線至遠端連接埠，常見連接埠為 443；接著傳送 ClientHello，其中可能包含 SNI、支援的 TLS 版本與 ALPN。伺服器回傳憑證鏈後，本機核心會檢查憑證時間、簽發關係與名稱，驗證通過後才建立加密工作階段。

因此，「延遲測試失敗」不能直接等同於「節點無法使用」。DNS 解析失敗、TCP 連接埠無法連通、TLS 憑證驗證失敗與代理協定參數錯誤，都可能讓測試結果顯示逾時或無法使用，但它們對應的是不同鏈路位置。先查看日誌中的第一個明確錯誤，再決定要修改哪項參數，比反覆切換節點更有效。

如果日誌在連線遠端位址前就出現「no such host」，應先處理 DNS 或位址拼寫；如果已出現 x509、certificate、handshake 等關鍵字，才進一步檢查憑證與 TLS。若 TLS 已完成，之後才出現 invalid user、authentication failed 或 protocol response，問題便位於 UUID、密碼、協定類型或傳輸設定，而不是憑證。

依日誌原文辨識憑證錯誤

v2rayN 7.x 可先在主視窗底部的日誌區查看核心輸出，並透過「設定」→「參數設定」確認日誌層級沒有設得過低。測試時先停止目前的核心，再重新啟動並開啟 HTTPS 頁面，這樣能減少舊日誌干擾。節點可在伺服器清單中按右鍵選擇「編輯伺服器」，核對 TLS 與 SNI 欄位。

Android 端同樣應從目前設定著手。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；兩者對憑證有效期與主機名稱的基本驗證原則相同，但日誌用語可能略有差異。不要只截取最後一行「啟動失敗」，應向上尋找最早出現的 x509、tls 或 certificate 記錄。

EOF、connection reset by peer 與 unexpected EOF 通常表示連線遭到提前關閉，本身並不能證明是憑證錯誤。若同一節點在行動網路可用、在固定網路卻持續重設，應優先比較 DNS 結果、IPv4 與 IPv6 路徑，以及遠端 443 連接埠是否能建立 TCP 連線。

curl -vI --connect-timeout 8 https://node.example.net/

openssl s_client \
  -connect node.example.net:443 \
  -servername node.example.net \
  -showcerts

上方指令用於獨立觀察一般 TLS 網站的握手。執行時應將範例網域替換為節點設定要求的憑證網域名稱。OpenSSL 輸出中的 subject、issuer、憑證起訖時間與 Verify return code，有助於區分名稱、有效期限與憑證鏈問題；但代理服務若要求特定路徑或應用層協定，一般 HTTPS 請求失敗並不能單獨證明代理入口無法使用。

如何核對系統時間與時區

憑證包含開始生效時間與到期時間，本機會使用自己的時鐘判斷目前時刻是否落在區間內。日期正確但時區錯誤時，系統顯示的時間可能看似接近，實際 UTC 時間卻已偏移數小時。雙系統切換、主機板斷電、虛擬機器暫停後恢復，以及關閉自動校時，都是常見原因。

1. Windows 開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」與「自動設定時區」，然後按一下立即同步。
2. macOS 開啟「系統設定」→「一般」→「日期與時間」，啟用自動設定日期與時間，並確認所在時區。
3. Android 開啟「設定」→「系統」→「日期與時間」，啟用網路提供的時間與時區；不同系統介面的選單名稱可能略有差異。
4. Linux 使用 timedatectl status 查看 Universal time、RTC time、Time zone 與 System clock synchronized，必要時執行 timedatectl set-ntp true 開啟網路校時。
5. 完成同步後，徹底退出客戶端並重新啟動核心，不要只在舊連線上重複延遲測試。

排查時應記錄誤差量，而不是憑肉眼判斷。若本機時間比可信時間快 24 小時，仍在有效期內的憑證可能被判定為已過期；若慢 24 小時，新簽發的憑證可能被判定為尚未生效。部分環境允許很小的握手時鐘誤差，但不能把幾分鐘的容差當作固定規則。

SNI、位址、Host 與憑證名稱的關係

節點「位址」用於 DNS 解析並建立 TCP 連線，SNI 則在 TLS ClientHello 中告知伺服器客戶端希望存取的名稱，也常由核心用於憑證名稱驗證。兩者可以相同，也可能因入口架構不同而不同。正確值應來自有效訂閱或伺服器設定，不能只依節點備註推測。

WebSocket 設定還可能包含 Host 請求標頭。Host 屬於 TLS 建立後的 HTTP 層，SNI 屬於 TLS 握手層；即使兩個欄位經常填寫相同網域，也不能視為完全等價。gRPC 還涉及 serviceName，REALITY 設定則可能同時涉及 serverName、publicKey 與 shortId，這些欄位各自負責不同功能。

在 v2rayN 中，對目標節點按右鍵並選擇「編輯伺服器」，先確認安全類型確實是 TLS，再核對 SNI。若訂閱重新更新後手動修改被覆蓋，應回到訂閱群組檢查原始資料，而不是每次更新後重複修改。對於 VLESS REALITY，不應套用一般公開憑證的排查結論；但 serverName、系統時間與各項參數成套一致仍然重要。

憑證鏈不完整與網路中間環節

伺服器通常需要傳送網站憑證及必要的中繼憑證，客戶端再使用系統或核心信任庫中的根憑證完成驗證。如果伺服器只傳送網站憑證，某些曾快取中繼憑證的裝置可能暫時可用，另一台新裝置卻會回報 unknown authority。這種「部分裝置正常」並不能證明伺服器的憑證鏈設定完整。

先在同一台裝置上分別測試固定網路與行動網路。如果只有某個網路失敗，應比較 DNS 解析結果，確認網域是否被解析到不同入口；如果所有網路、不同平台都在同一時間回報相同的憑證鏈錯誤，伺服器設定異常的可能性較高。企業代理伺服器、HTTPS 檢查設備或自訂憑證環境，也可能改變實際收到的簽發鏈。

• 使用 openssl s_client -showcerts 查看伺服器實際傳送了幾張憑證以及簽發關係。
• 檢查輸出末尾的驗證結果，不要只看第一張憑證的網域。
• 分別以節點位址和設定中的 SNI 進行測試，確認兩次連線是否回傳不同憑證。
• 關閉並重新啟動 v2rayN、v2rayNG 或 v2flyNG 核心，排除舊工作階段持續重複使用。
• 若伺服器漏傳中繼憑證，應在伺服器端部署完整憑證鏈，而不是讓每台客戶端各自略過驗證。

略過憑證驗證只能用於短時間定位

v2rayN 與相關核心設定中的 allowInsecure，表示允許 TLS 連線在憑證驗證未通過時繼續。它不會修復過期憑證、錯誤 SNI 或缺少中繼憑證，只是繞過對應的驗證結果。連線恢復只能證明故障點可能位於憑證驗證階段，不能代表現有參數已經正確。

此選項適合進行一次受控對照：保持位址、連接埠、協定、傳輸與路由不變，只切換憑證驗證設定；啟動核心並完成一次請求；接著恢復驗證，再依原始日誌修復時間、SNI 或憑證鏈。不要同時修改 SNI、Host、連接埠與 allowInsecure，否則測試將失去判斷價值。

1. 儲存原始節點副本，並記錄目前 allowInsecure 狀態。
2. 確認測試對象來源明確，且沒有同時修改其他連線參數。
3. 暫時啟用後重新啟動核心，觀察原本的 x509 錯誤是否消失。
4. 若仍然逾時，繼續檢查 DNS、TCP 連接埠、傳輸方式與伺服器狀態。
5. 若連線恢復，立即恢復憑證驗證，並修復系統時間、SNI 或完整憑證鏈。

長期略過驗證會失去確認遠端身分的關鍵依據。尤其當節點位址經 DNS 指向多個入口時，客戶端便無法再透過憑證名稱與簽發鏈判斷目前連線是否抵達預期服務。較穩妥的做法是讓訂閱欄位與伺服器設定一致，並維持系統信任庫與時間同步正常。

一套可重現的最終排查順序

憑證問題很容易因同時變更多項參數而失去線索。實際操作應固定節點、固定網路並記錄時間，以日誌中的第一個底層錯誤作為基準。每完成一步都重新啟動核心，並重複相同請求，結果才具備可比性。

1. 確認系統時間：同步日期、時區與網路時間，誤差應縮小至秒級，而不是相差數分鐘或數小時。
2. 確認解析結果：檢查節點網域是否能解析，並判斷 IPv4、IPv6 是否指向預期入口。
3. 確認 TCP 連接埠：核對訂閱中的 443、8443 或其他明確連接埠，不可自行替換。
4. 確認 TLS 開關：節點要求 TLS 時必須啟用，非 TLS 入口不能強行套用 TLS。
5. 確認 SNI：使用訂閱提供的憑證名稱，區分節點位址、備註、Host 與 serviceName。
6. 確認憑證期限：比較目前 UTC 時間與憑證起訖時間，判斷問題出在本機時鐘還是伺服器憑證到期。
7. 確認憑證鏈：檢查伺服器是否傳送必要的中繼憑證，並在多個平台上進行對照。
8. 確認傳輸參數：WebSocket 的 Path 與 Host、gRPC 的 serviceName、REALITY 的相關欄位必須成套一致。
9. 短時間對照驗證：僅在定位階段切換 allowInsecure，測試結束後恢復憑證驗證。
10. 回到原始訂閱：若手動修改越來越多，請重新匯入正確群組，並只保留一份測試設定。

完成以上步驟後，錯誤通常會歸入三個明確類別：本機時間或信任環境異常、節點欄位與入口不相符、伺服器憑證或監聽設定異常。只有第一類適合直接在本機修復；第二類應恢復正確的訂閱參數；第三類則需要伺服器更新憑證、補齊憑證鏈或修正入口設定。