V2RayのTLSハンドシェイク失敗・証明書エラー対策｜時刻同期とSNI設定を確認

1. 証明書エラーとハンドシェイクのタイムアウトを切り分ける

TLSハンドシェイクは、プロキシプロトコルでデータをやり取りする前に行われます。クライアントはまずサーバーに接続し、ハンドシェイクのパラメーターを送信してサーバーの身元を確認し、暗号化接続を確立します。どの段階で失敗しても、ログには「接続失敗」とだけ表示されることがあります。最後の1行だけで判断せず、x509、tls、または具体的なネットワークエラーを含む原因の記録まで遡って確認してください。

v2rayNではメイン画面下部のログ欄で、失敗した接続の時刻とノード名を記録します。v2rayNGではメイン画面のメニューから「ログ」を開き、再接続後に追加された記録を確認してください。バージョンによってメニュー名は多少異なりますが、調べるポイントは同じです。「すべての再試行に失敗しました」という概要ではなく、同じ接続に関する最も具体的な低レベルのエラーを探します。

2. システム時刻がずれている場合：同期してから再接続

証明書には有効期間の開始日時と終了日時があります。端末の日付が数か月前にずれていると「有効期間前」、未来にずれていると「期限切れ」と判定されることがあります。TLSの検証では実際の時刻が基準です。表示されるタイムゾーンが異なっていても、必ずしもシステム時計が間違っているとは限りません。ただし、タイムゾーンを手動で変更したうえで時刻も手動調整すると、実際の時刻がずれることがあります。

1. Windows 11：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。タイムゾーンを確認してから「今すぐ同期」をクリックしてください。同期後、年・月日・分まで正しいことを確認します。
2. 同期状態を確認：ターミナルで以下の確認コマンドを実行し、時刻ソースと最後に同期が成功した時刻を確認します。すぐに再同期する場合は、2つ目のコマンドを管理者権限で実行してください。
3. Android：システムの「設定」→「システム」→「日付と時刻」を開き、「日時を自動設定」と「タイムゾーンを自動設定」をオンにします。機種によっては「詳細設定」内にあります。ネットワークに再接続して、時刻が更新されたことを確認してください。
4. 再テスト：現在のノードを切断してから再接続し、新しいリクエストを1回実行します。時刻を合わせても失敗済みの接続は自動で直りません。新しいログで結果を確認してください。

w32tm /query /status
w32tm /resync

Windowsで時刻サービスが起動していないと表示された場合は、「サービス」でWindows Timeの状態を確認してください。組織管理のPCでは、管理者が設定した時刻ソースに従い、独自の時刻ソースに変更しないでください。シャットダウンのたびに日付が戻る場合は、デバイスのファームウェア時計とハードウェアの状態も確認します。時刻が正しいのに期限切れの証明書エラーが続く場合は、サーバー側で証明書を更新し、サービスを再読み込みする必要があります。

3. SNIとserverName：接続先IPをそのまま入力しない

SNIは、ハンドシェイク時にクライアントが送信するサーバー名です。同じアドレス上で複数のサービスを運用している場合、適切な証明書やサイトを選ぶために使われます。一般的な設定では、tlsSettings.serverNameがSNIの送信と証明書名の検証の両方に使われます。ノードの接続先アドレスやWebSocketのHTTP Hostとは別の項目です。3つの値が同じ場合もあれば、サーバーの構成によって異なる場合もあります。

v2rayNでは対象サーバーの行をダブルクリックしてノード編集画面を開き、TLS関連項目の「SNI」または「サーバー名」を確認します。v2rayNGではノードの編集アイコンをタップし、TLS欄の該当項目を確認してください。項目名はバージョンやノードの種類によって異なるため、サブスクリプションで提供された設定を基準にします。接続先アドレス、偽装ドメイン、SNIを機械的に同じ文字列へ変更しないでください。

• edge.example.comのようにドメイン名だけを入力します。https://edge.example.com/のようなURLや、:443は付けないでください。
• ノードへの接続にIPアドレスを使い、証明書がドメイン名用に発行されている場合でも、通常は提供元が指定したドメイン名を入力します。そのIPアドレスをSNIにそのまま設定しないでください。
• ワイルドカード証明書*.example.comは通常、edge.example.comをカバーしますが、example.comやa.edge.example.comはカバーしません。
• サブスクリプションの更新で手動変更が上書きされることがあります。一時的なテストの前にノードを複製し、テスト用だと分かる名前を付けておくと、次回の更新後も調査記録を残せます。

以下は通常のTCP + TLSで使うstreamSettingsの一部であり、単独で動作する完全な設定ではありません。例のドメイン名は項目を説明するためのものです。実際にはノードで指定された値に置き換えてください。WebSocketなど別のトランスポートを使う場合は、既存のトランスポート種別と関連設定を維持します。

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

4. allowInsecureと証明書チェーン：証明書の検証を維持する

allowInsecureは「互換モード」や「高速化」のための設定ではありません。通常のTLS設定でこれをtrueにすると、証明書の重要な検証が省略され、期限切れ、名前の不一致、信頼されていない証明書が通常どおりブロックされなくなります。問題を見えにくくするだけで、意図したサーバーに接続できている証明にはならず、ネットワークのタイムアウトも解決しません。

ノードの編集画面で「証明書の検証をスキップ」または「安全でない接続を許可」がオフになっていることを確認してください。通常の設定ではオフにし、allowInsecure: falseにします。以前の設定でこの項目を有効にしていた場合、検証を有効に戻して証明書エラーが出ても、エラーの原因を調べてください。長期的な対処として再び有効にするのは避けましょう。

• 名前が一致しない：まずSNIを確認します。値が正しい場合、サーバーがデフォルトサイトの証明書を読み込んでいる可能性があるため、仮想ホストの設定を確認してください。
• 発行者が不明：サーバーから中間証明書を含む完全な証明書チェーンを提供する必要があります。公的に信頼された証明書なら、通常、利用者が独自のルート証明書を追加でインポートする必要はありません。
• 古い端末1台だけで失敗する：システムとサポート対象のクライアントを更新し、システムの信頼ストアを確認してください。特定のノードのために、出所不明のルート証明書をインポートしないでください。
• ネットワークを切り替えると証明書が変わる：公衆Wi-Fiのログイン画面、企業プロキシ、セキュリティソフトのHTTPS検査機能を確認し、必要に応じてネットワーク管理者に問い合わせてください。

5. ALPNとタイムアウト：サーバーのトランスポート要件に合わせる

ALPNはTLSハンドシェイクでアプリケーション層のプロトコルをネゴシエートする仕組みで、よく使われる値はh2とhttp/1.1です。ノードのプロトコル名ではなく、値を増やせばよいというものでもありません。HTTP/2ベースのgRPCトランスポートには、対応するHTTP/2サポートが必要です。従来のWebSocket UpgradeではHTTP/1.1が使われることが一般的ですが、実際の要件はサーバーとリバースプロキシの構成によって異なります。

1. まずノードのトランスポート種別を確認し、提供元の説明に従ってALPNを設定してください。明確な指定がない場合は、試しに単一のプロトコルへ無理に固定しないでください。
2. ログにtls: no application protocolと出る場合は、クライアントが提示するALPNとサーバーが許可するプロトコルに共通のものがあるか確認してください。
3. ログにタイムアウトしか記録されていない場合は、まず実際のサーバーポートを確認してください。ノードの設定が8443なら、443への接続テストが成功しても、そのノードが使えることの証明にはなりません。
4. ノードの設定を変えずに、現在のネットワークと別の利用可能なネットワークでそれぞれ再テストしてください。結果が異なる場合は、ネットワーク経路やアクセス制限を優先して調べます。

Windowsでは、以下のコマンドで指定ポートへのTCP接続をテストできます。例のドメイン名とポートはコマンド形式を示すためのものなので、ノードの実際の値に置き換えてください。TcpTestSucceeded: Trueが示すのはTCP接続が確立できたことだけです。TLS証明書、ALPN、プロキシ認証が正しいことまでは確認できません。

Test-NetConnection -ComputerName edge.example.com -Port 443

6. よくある質問と修正後の確認

修正後はノードに再接続して実際にアクセスし、新しいログに証明書検証やハンドシェイクのエラーがないことを確認してから、アプリでのアクセスが復旧したか調べてください。TLSが完了してもアクセスできない場合は、プロキシプロトコルの認証、トランスポート経路、ルーティング設定を引き続き確認します。正しいと確認できたSNIを何度も変更しないでください。

• 調査記録を残す：クライアントのバージョン、コアのバージョン、失敗した時刻、ネットワーク環境、具体的なエラーを記録します。「接続できない」だけで済ませないでください。
• 安全な設定に戻す：証明書検証のスキップがオフになっていることを確認し、試行錯誤のために追加した根拠のないパラメーターを削除してください。
• 必要な情報を共有する：管理者には証明書エラーとポートの状況を伝えてください。ログを共有する前に、サブスクリプションURL、認証情報、個人のネットワークアドレスを伏せてください。