V2Ray TLS 憑證錯誤排查清單：逐項確認系統時間不同步與 SNI 設定錯誤

V2Ray、Xray 或 V2Fly 核心建立 TLS 連線時，會先驗證遠端憑證，再進入 VMess、VLESS 等協定的資料交換階段。只要憑證有效期限、網域比對、憑證鏈或交握參數中任一項不符合要求，連線就會在協定驗證前中止。因此，日誌出現憑證錯誤時，不宜先修改使用者 ID、加密方式或路由分流規則。這些項目通常尚未有機會參與目前的連線。

憑證類故障的關鍵，是區分三個物件：實際連線的伺服器位址、TLS 交握攜帶的伺服器名稱，以及憑證宣告的有效網域。三者可能相同，也可能因節點使用入口位址、反向代理或內容分發架構而不同。判斷標準不是「看起來接近」，而是設定提供者給出的欄位能否與憑證精確對應。

一、先確認錯誤確實發生在 TLS 階段

先開啟用戶端日誌，再發起一次連線。v2rayN 可從日誌區域查看核心輸出；v2rayNG 與 v2flyNG 可在連線後查看對應的執行日誌。只保留本次測試產生的記錄，避免把數小時前的錯誤誤當成目前結果。

常見提示可能包含 certificate、x509、handshake、unknown authority、expired、not yet valid、hostname 或 server name 等關鍵字。不同核心版本的文字會有差異，但可以依含義分類。

日誌含義	優先檢查項目	常見原因
憑證尚未生效	本機日期、時間與時區	系統時鐘落後，或時區設定錯誤
憑證已經過期	本機時間與遠端憑證狀態	系統時鐘超前，或伺服器憑證尚未續期
網域不相符	SNI、serverName、位址欄位	交握網域缺失，或誤填為位址欄中的 IP
未知簽發機構	系統憑證庫、網路攔截、憑證鏈	根憑證過舊，或遠端未傳送完整的中繼憑證
交握被關閉或重設	連接埠、TLS 開關、傳輸類型	連到了非 TLS 連接埠，或節點參數組合錯誤

如果日誌只顯示逾時、無法解析網域或連線遭拒，應先檢查網路可達性、DNS 與連接埠監聽。這些現象發生在憑證驗證之前。若日誌已明確指出憑證日期或名稱不相符，再依下文順序處理。

二、核對系統時間、時區與自動同步狀態

TLS 憑證包含生效時間與到期時間。用戶端會以本機時鐘判斷憑證是否處於有效區間。即使時間只差幾分鐘，一般網頁可能仍能開啟，但剛簽發或剛續期的憑證仍可能被判定為尚未生效。睡眠喚醒、主機板時鐘異常、虛擬環境暫停，以及長期關閉自動同步，都可能造成時間偏差。

查看系統顯示的年份、月份、日期與分鐘，先排除明顯錯誤。
確認時區與目前所在地一致。時間數字正確但時區錯誤，也可能導致實際時間偏移。
開啟系統自動設定時間與自動設定時區，接著立即執行一次同步。
完全退出用戶端並重新啟動，讓核心在新的時間狀態下建立連線。
重新查看日誌，確認「尚未生效」或「已經過期」的提示是否消失。

Windows 可在日期與時間設定中檢查自動同步狀態。macOS 可在日期與時間設定中確認時間來源。Android 應同時檢查自動日期與時間及自動時區。Linux 桌面環境通常可在系統設定中完成同步；需要進一步確認時，可在終端機查看系統時間同步狀態。

timedatectl status

重點查看本地時間、通用時間、時區，以及系統時鐘是否已同步。只修正用戶端介面中的參數，不能取代系統校時，因為憑證驗證由核心與系統時間共同決定。

三、逐項核對 SNI、serverName 與伺服器位址

SNI 是 TLS 交握中攜帶的伺服器名稱。一個入口位址可能承載多個網域，伺服器依靠 SNI 選擇應回傳的憑證。V2Ray 與 Xray 設定中常見的 serverName，通常就是用來指定這個交握名稱。部分用戶端介面會將它顯示為 SNI、伺服器名稱或 TLS Server Name。

伺服器位址負責建立 TCP、WebSocket、gRPC 或其他底層連線；serverName 負責 TLS 名稱驗證。兩者用途不同。節點位址可以是網域，也可能是 IP，但 serverName 通常應填寫憑證涵蓋的網域。不能因為連線位址是 IP，就直接將 IP 複製到 SNI 欄位。

依以下四項比對

位址欄位：確認沒有多餘空格、協定前綴、路徑或連接埠。位址欄通常只放網域或 IP。
連接埠欄位：確認數值與節點資料一致，不要自行依常見連接埠替換。
TLS 開關：資料要求 TLS 時必須啟用；資料未使用 TLS 時不要額外開啟。
serverName 欄位：依節點資料原樣填寫憑證網域，不要擅自改成位址欄位的值。

網域比對遵循憑證規則。憑證涵蓋 node.example.com，不代表一定涵蓋 example.com 或 api.node.example.com。萬用字元憑證也只涵蓋規定的層級。即使多個網域最終解析到同一個 IP，憑證名稱驗證仍依網域執行。

透過訂閱匯入後，先不要手動「簡化」欄位。訂閱可能分別提供位址、host、path、SNI 與傳輸類型。將它們合併成一個網域，容易破壞原有組合。若懷疑訂閱內容過舊，應先更新訂閱，再刪除重複的舊節點，最後對新匯入的節點測試一次。

WebSocket 與 gRPC 不要混淆 Host 和 SNI

WebSocket 設定中的 Host 屬於 HTTP 請求標頭，SNI 屬於 TLS 交握。兩個值有時相同，但不是同一個參數。gRPC 的服務名稱同樣不是 serverName。排查時應逐欄對照，不要把路徑、Host、服務名稱填入 SNI。

典型的邏輯關係如下：

連線位址：入口網域或入口 IP
連線連接埠：節點指定的 TLS 連接埠
TLS：啟用
serverName / SNI：憑證涵蓋的網域
WebSocket Host：節點指定的 HTTP Host
WebSocket Path：節點指定的請求路徑

如果修改 serverName 後，日誌從「憑證網域不相符」變成「WebSocket 回傳異常狀態」或「服務名稱不存在」，表示 TLS 階段可能已通過，故障已轉移到傳輸層。此時不要繼續反覆調整憑證選項，應改為核對 Host、路徑或 gRPC 服務名稱。

四、確認連接埠、TLS 開關與傳輸參數屬於同一組設定

憑證錯誤不一定由憑證本身引起。用戶端向非 TLS 服務傳送 TLS 交握，或向 TLS 入口發送一般連線，都可能產生交握失敗、連線重設或非預期回應。最常見的原因是手動編輯節點時只修改了連接埠，卻沒有同步修改 TLS 與傳輸類型。

確認 VMess 或 VLESS 協定類型沒有在複製節點時被誤改。
確認傳輸類型與資料一致，例如 TCP、WebSocket 或 gRPC。
確認 TLS 相關開關與連接埠屬於同一組節點參數。
確認 WebSocket 路徑以正確格式填寫，避免複製到網域欄位。
確認 gRPC 服務名稱維持原始大小寫與字元內容。
確認沒有把本地監聽連接埠填入遠端伺服器連接埠。

路由分流通常不會改變憑證的網域比對結果，但分流可能讓連線經過不同出口。排查階段可先確認目標節點本身能夠建立連線，再恢復複雜規則。若僅在某條路由規則命中時失敗，應檢查該規則選擇的出站是否仍指向預期節點，而不是直接關閉憑證驗證。

同樣地，系統代理狀態主要決定應用程式流量是否進入用戶端，不決定節點憑證是否有效。日誌已顯示核心正在連線至遠端時，表示測試請求已到達用戶端。此時繼續切換系統代理模式，對憑證過期或 SNI 錯誤沒有直接修復作用。

五、正確理解 allowInsecure 的用途

allowInsecure 用於控制用戶端是否放寬遠端憑證驗證。正常使用時應保持關閉。開啟後可能略過憑證名稱、簽發鏈或有效性檢查，雖然某些錯誤會暫時消失，但這不能證明原始設定正確，也不能修復伺服器憑證。

排查時可以將它視為範圍有限的診斷開關：如果關閉時明確出現憑證驗證錯誤，暫時開啟後能夠進入下一階段，表示問題集中在憑證驗證鏈路。完成定位後應立即恢復關閉，並修正系統時間、serverName、憑證鏈或伺服器設定。

不建議長期將 allowInsecure 作為「能連線即可」的處理方案。TLS 的名稱與簽發驗證用於確認連線至預期服務。略過驗證後，用戶端無法依正常規則確認遠端身分。尤其在公共網路或存在流量轉送的環境中，應保留完整驗證。

六、檢查憑證鏈、系統憑證庫與網路攔截

當日誌提示未知簽發機構或無法建立信任鏈時，先更新作業系統，再重新啟動裝置。系統根憑證庫長期未更新，可能無法識別較新的簽發鏈。用戶端與核心也應使用目前維護中的版本，因為舊版本可能包含過時的 TLS 元件或憑證處理邏輯。

如果同一節點在行動網路可用，卻在公司、學校或公共網路中回報憑證錯誤，應比較兩種網路下日誌中的憑證名稱與簽發資訊。某些網路會透過認證閘道回傳自己的登入頁面，用戶端收到的就不是目標伺服器憑證。此時應先完成網路認證，或聯絡網路管理員確認存取策略。

若所有裝置、所有網路都對同一節點回報憑證鏈不完整，而其他節點正常，問題可能位於伺服器端。伺服器設定 TLS 時不僅要提供網站憑證，還要傳送必要的中繼憑證鏈。用戶端無法僅憑網站憑證自動補齊所有缺失環節。一般使用者應保留完整日誌並向節點維護方回報，不要透過反覆重裝用戶端掩蓋伺服器端問題。

七、用對照測試縮小故障範圍

對照測試比連續試錯更有效。準備一個先前可正常使用的節點作為基準，再依裝置、網路與節點三個面向測試。每次只替換一個變數。

測試結果	優先判斷	下一步
同一部裝置上只有一個節點失敗	節點參數或遠端憑證	核對 SNI、連接埠、傳輸與憑證狀態
同一節點只在一部裝置上失敗	裝置時間、憑證庫或用戶端設定	同步時間、更新系統、重新匯入訂閱
同一節點只在一個網路中失敗	網路認證、DNS 或中間設備	完成認證並比較不同網路的日誌
所有 TLS 節點同時失敗	系統時間、系統憑證庫或網路環境	先校時，再測試另一個網路
TLS 通過後出現協定驗證失敗	使用者參數或協定設定	改查 ID、協定類型與訂閱內容

測試過程中，先暫停頻繁更新訂閱與批次修改節點。訂閱更新可能覆蓋手動設定，也可能產生同名節點，使測試對象發生變化。可以記錄節點更新時間、用戶端名稱、核心類型、網路環境與完整錯誤時間點。回報問題時，這些資訊比「連不上」更容易協助定位。

八、最終複查清單

系統日期、時間與時區皆正確，且已完成自動同步。
用戶端日誌顯示的是本次連線產生的錯誤。
伺服器位址只包含正確的網域或 IP，沒有混入路徑。
遠端連接埠與節點資料一致，沒有誤填本地代理連接埠。
TLS 開關、傳輸類型與連接埠來自同一組設定。
serverName 或 SNI 與憑證涵蓋的網域一致。
WebSocket Host、路徑或 gRPC 服務名稱沒有填錯欄位。
訂閱已更新，測試對象不是殘留的同名舊節點。
allowInsecure 已恢復關閉，沒有作為長期設定保留。
系統、用戶端與核心皆處於目前維護版本。
已透過另一部裝置或另一個網路完成一次對照測試。
若僅單一節點持續失敗，已儲存日誌並回報維護方。

TLS 排查的核心順序可濃縮為：時間、名稱、連接埠、傳輸、憑證鏈。先確認本機時間，再判斷 serverName 是否與憑證相符，接著檢查 TLS 是否連到正確連接埠，最後才處理憑證鏈與網路環境。依此順序逐項確認，可以避免無關地全面重做 VMess、VLESS、訂閱或路由分流設定。