V2RayのTLSハンドシェイクエラーの原因：システム時刻のずれとSNIの設定ミス

TLSハンドシェイクが失敗する段階を特定する

TLSハンドシェイクは、安全な接続を確立する過程で行われます。通常のTLSノードに接続する場合、クライアントはサーバーとパラメーターをネゴシエートし、サーバー証明書の有効期間、証明書チェーン、ホスト名を検証します。TCPポートに接続できても、それはトランスポート層に到達できたことを示すだけです。証明書検証や、その後のVMess・VLESS認証が成功したことにはなりません。

v2rayNの下部にあるログ欄で、今回のテストに対応する記録を確認します。外側の failed to process outbound traffic だけでなく、最後に記録された具体的な原因を確認してください。接続ログは複数のエラーに包まれることがあります。重要な情報は、多くの場合、その後に続く x509:、tls:、dial tcp の付近にあります。

システム時刻とタイムゾーンを同期する

証明書の有効期間は絶対時刻で判定され、デスクトップに表示されるタイムゾーン名は基準になりません。タイムゾーンの設定だけが間違っていて、システムの実時刻が正しければ、通常は証明書エラーの原因になりません。一方、日付を手動で進めた場合、デュアルブート環境で時刻の扱いが異なる場合、仮想マシンを古いスナップショットから復元した場合は、実時刻がずれることがあります。まず年・月・日を確認し、その後に分を確認してください。右下に表示された時刻だけで判断しないようにしましょう。

1. 時刻を記録する

   ログの現在時刻と証明書の有効期間を書き留めます。ログがUTC表記の場合は、換算してから比較してください。たとえばUTC 02:00とUTC+8の10:00は同じ時刻です。8時間の差があるからといって、時刻ずれとは限りません。

2. 自動時刻設定を有効にする

   Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。タイムゾーンを確認してから「今すぐ同期」をクリックしてください。同期に失敗する場合は、現在のネットワークから時刻サーバーにアクセスできるか確認します。

3. 同期状態を確認する

   Windowsでは、ターミナルで w32tm /query /status を実行すると、時刻ソースと最後に同期が成功した時刻を確認できます。手動で同期するには、管理者権限のターミナルで w32tm /resync を実行してください。エラーが出ても、ノードの設定を次々に変更しないでください。

4. もう一度テストする

   クライアントに戻り、現在のサーバーを選択して実接続遅延テストを再実行します。修正結果は古いログで判断せず、新しいログのタイムスタンプで今回の接続を確認してください。

他のOSで時刻ソースを確認する

• macOS:「システム設定」→「一般」→「日付と時刻」を開き、「日時を自動的に設定」を有効にします。組織の管理下にある端末では、時刻ソースがポリシーで固定されていないか確認してください。
• Android:通常は「設定」→「システム」→「日付と時刻」で、自動日時設定と自動タイムゾーン設定を有効にします。機種によっては「詳細設定」や「一般管理」にあります。設定画面の検索結果を確認してください。その後、v2rayNGまたはv2flyNGに戻って接続し直します。
• Linux:systemdを使用するディストリビューションでは、timedatectl status を実行してシステムクロックの同期状態を確認します。sudo timedatectl set-ntp true で、システムが対応するネットワーク時刻同期を有効にできます。独立した時刻サービスを使うディストリビューションでは、該当サービスの状態を確認してください。

これらの数値はサービスの用途を示すもので、ノードのポートを一律に443へ変更する指示ではありません。時刻を同期しても証明書の期限切れが表示される場合は、ログに記録された証明書の有効期限を確認してください。クライアントの時刻調整でサーバー証明書の更新を代替することはできません。

SNI、サーバーアドレス、トランスポートのHostを確認する

SNIはTLS ClientHelloに含まれ、接続先サーバー名を示す情報です。画面では「SNI」「サーバー名」「serverName」などと表示され、一部の解説では「偽装ドメイン」と呼ばれます。任意の文字列を入力する項目ではありません。通常のTLS検証では、サーバーが使用する証明書の選択と、クライアントが検証するホスト名の両方に関わります。

例として示した edge.example.invalid は、SNIに入力する文字列の形式を示すためのホスト名です。実際の接続には使用できません。SNIに https://edge.example.invalid:443/path のような値を入力したり、サブスクリプションURL全体を貼り付けたりしないでください。実際に入力するホスト名はノード提供元から取得し、一般的なWebサイトのドメイン名に勝手に置き換えないでください。

1. 対象のノードを特定する

   v2rayNのサーバー一覧で、選択中の項目とサブスクリプショングループを確認し、その項目をダブルクリックして編集画面を開きます。別の同名ノードを変更しないよう、アドレス、ポート、トランスポート方式、トランスポートのセキュリティ方式を先に記録してください。

2. サーバー名を確認する

   トランスポートのセキュリティ設定で、SNIまたはサーバー名の項目を確認します。提供元の設定と一文字ずつ照合し、前後の空白を削除してください。https://、ポート、パスは追加しないでください。項目の場所はクライアントのバージョンやプロトコルによって異なります。

3. Hostは別に確認する

   WebSocketを使用している場合は、Hostとpathも確認します。ドメイン名のエラーを解消するために、アドレス・SNI・Hostをすべて同じ値に変更しないでください。接続先アドレスと証明書のホスト名が異なる構成もあります。

4. 保存して再テストする

   保存後、対象のノードを選択し、実接続遅延テストを実行します。エラーが証明書の不一致から別の種類に変わったか確認し、関連する項目は一度に一組だけ変更してください。

Androidでは、v2rayNGまたはv2flyNGのノード一覧から該当項目の編集画面を開き、TLS関連の設定でサーバー名を確認します。サブスクリプションのノードを手動で変更しても、次回の更新で上書きされる場合があります。修正後に接続できた場合は、端末側の設定に頼り続けず、提供元にサブスクリプションの更新を依頼してください。

証明書チェーンの問題とREALITYの設定を切り分ける

端末の時刻が正しく、SNIも設定と一致していても、サーバー側の問題は否定できません。通常のTLSサービスでは、正しいサーバー証明書と必要な中間証明書を返す必要があります。サーバー証明書だけを配置している、更新後にサービスを再読み込みしていない、ロードバランサー配下の一部サーバーだけ証明書を更新していないといった状況では、同じノードでも接続が断続的に失敗します。

• 有効期間のエラー:管理者に、ディスク上にある新しい証明書の日付だけでなく、現在の接続先が実際に返す証明書を確認してもらってください。更新に成功しても、すべての接続先で新しい証明書が使われているとは限りません。
• ホスト名のエラー:証明書のSubject Alternative Nameに、設定したサーバー名が含まれているか確認します。ワイルドカード *.example.invalid は通常、1階層下のサブドメインのみを対象とし、ルートドメインやさらに深い階層の名前は対象外です。
• 不明な認証局:中間証明書チェーン、端末のシステム更新、ルート証明書の信頼状態を確認します。会社や学校のネットワークでのみ発生する場合は、TLS検査ポリシーの有無を確認してください。出所不明のルート証明書を安易にインストールしないでください。
• REALITYノード:サーバー名だけでなく、提供元の設定に従って公開鍵、shortId、フィンガープリント、flowも確認してください。REALITYは通常の証明書を自前で導入する方式ではないため、「証明書を更新する」方法だけでは解決できません。

v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。REALITYなどの機能に関する問題では、まずクライアントとコアがノードの設定に対応しているか確認してください。画面を別のクライアントに変えても、プロトコルへの対応が自動で追加されるわけではありません。デスクトップではクライアント比較でv2rayNの用途を確認し、実際に使用中のコアとバージョンも確認してください。

実接続遅延と実際のアクセスを再テストする

設定を修正したら、まずノードを再テストし、その後アプリを確認します。TCPingに成功しても実接続遅延テストに失敗する場合は、TLS、プロキシ認証、テスト先へのアクセスのいずれかで問題が残っている可能性があります。実接続遅延はテスト先やルーティングルールにも左右されるため、所要時間の数値だけで、すべてのアプリが正常かどうかを判断しないでください。

1. 元のノードを複製するか、重要な設定値を記録しておきます。時刻を修正して一度テストし、ホスト名のエラーが続く場合はSNIを確認してください。複数の設定を同時に変更しないようにしましょう。
2. 対象のノードで実接続遅延テストを実行し、同じタイムスタンプのログを確認します。テスト方法は実接続遅延の解説を参照してください。
3. システムプロキシの解説を参照し、アプリが実際にプロキシ経由で通信しているか確認します。システムプロキシとTUNでは通信を取り込む範囲が異なるため、ブラウザーで接続できなくても、コアが起動していないとは限りません。
4. 利用が許可されたHTTPSサイトにアクセスし、出口情報を確認します。特定のサイトだけに接続できない場合は、ルーティング設定とそのサイトの証明書を確認してください。すぐにノードのSNIを変更する必要はありません。
5. 問い合わせる際は、エラーの全文、発生時刻、OSのバージョン、クライアントとコアのバージョン、確認済みの項目を伝えてください。サブスクリプションのトークン、ユーザーID、ノードの認証情報全体は伏せてください。

TLSハンドシェイクのトラブル対処FAQ