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

まずログを確認：TLSハンドシェイクはどの段階で失敗したか

接続の流れ：ノードがタイムアウトと表示されても、証明書エラーとは限りません。一般的なTCP + TLS接続では、サーバーアドレスの名前解決、TCP接続、TLSネゴシエーションの後に、プロキシプロトコルの認証とデータ転送が行われます。途中のどの段階で失敗しても、画面上は接続できないように見えることがあります。

ログの確認：クライアントのログ画面から、直近の接続で発生したエラーを探し、時刻、エラー全文、使用中のコア名を控えます。failed to process outbound trafficのような外側のエラー表示だけでなく、根本原因を優先して確認してください。後者はエラーをまとめた表示にすぎず、それだけでは証明書、ネットワーク、プロトコル設定のどれが原因か判断できません。

タイムアウトとの切り分け：ログがdial tcp、i/o timeout、または接続拒否のみで証明書エラーがない場合は、まずアドレス、ポート、サーバーの待ち受け状態を確認します。サーバー証明書を受信する前の段階では、証明書検証の設定を変えても接続は直りません。

システム時刻がずれている：日付と同期状態を確認

有効期間の判定：証明書には有効期間の開始日時と終了日時があり、クライアントは端末の時刻をもとに有効性を判断します。長期間の電源オフ、仮想マシンのスナップショット復元、電池切れによる時刻のリセットなどで、正常な証明書が有効期間前または期限切れと判定されることがあります。タスクバーの時分だけでなく、年と日付も確認してください。

1. Windowsで時刻を合わせる：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。タイムゾーンを確認し、「今すぐ同期」をクリックしてください。ボタンの位置はWindowsのバージョンによって多少異なります。
2. 同期結果の確認：最後に同期が成功した日時を確認します。さらに調べる場合は、コマンドプロンプトで以下の読み取り専用コマンドを実行し、時刻サーバーと同期状態を確認してください。
3. Androidで時刻を合わせる：システム設定で「日付と時刻」を検索し、日時の自動設定とタイムゾーンの自動設定を有効にします。設定項目の場所は端末によって異なります。設定後、もう一度接続してください。
4. 再接続して確認：時刻を合わせた後、同じノードに再接続して新しいログを確認します。それでも期限切れと表示される場合は、端末の日付をさらに変更するのではなく、サーバーの管理者に証明書を確認してもらいましょう。

w32tm /query /status
w32tm /query /source

タイムゾーンの違い：タイムゾーンは主に現地時刻の表示に影響しますが、TLS検証で比較されるのは絶対時刻です。証明書の問題を直すためにタイムゾーンを別の地域へ変更しても解決しません。時計の表示を別の端末に近づけるのではなく、システムの実時刻を正確にしてください。

SNIの設定ミス：サーバーアドレス、証明書のドメイン名、Hostを個別に確認

各項目の役割：SNIは、TLSハンドシェイク時にクライアントが送信するサーバー名です。同じアドレスで複数のサービスを運用する場合、適切な証明書やサイトを選ぶために使われます。XrayやV2Rayの一般的なTLS設定では、serverNameで指定します。クライアントによっては「SNI」や「サーバー名」と表示されます。接続先アドレスにIPを指定しても、証明書の照合には通常、サーバー指定のドメイン名が必要です。

クライアント画面で確認：v2rayNでは現在のノードを編集し、アドレス、ポート、転送方式、TLS設定を確認します。v2rayNGやv2flyNGでは、対象ノードの編集画面でサーバー名に関する項目を確認してください。画面構成はバージョンによって異なるため、入力欄の位置だけで判断せず、項目の意味と実際に生成されるコア設定を基準にします。

• 名前の形式：SNIには通常、ホスト名のみを指定します。https://、ポート、パス、末尾の空白は含めません。
• 証明書との照合：証明書のSAN（サブジェクト代替名）を確認してください。証明書一覧に表示される短縮名だけでは不十分です。ワイルドカード証明書は通常、1階層下のサブドメインのみを対象とし、ルートドメインまでは自動的にカバーしません。
• 未入力の場合：設定によってはサーバーアドレスから名前が推定されます。特にIPアドレスで接続する場合は推定に頼らず、サーバーの案内に従って明示的に確認してください。
• サブスクリプションによる上書き：手動で修正しても、次回のサブスクリプション更新で設定が上書きされることがあります。インポートした設定が繰り返し誤っている場合は、同じノードを何度も修正するのではなく、サブスクリプションの設定元に問い合わせてください。

証明書チェーンとサーバー：ブラウザーで開けても、コアが検証に成功するとは限らない

信頼チェーンの確認：通常、サーバーはサイト証明書と必要な中間証明書を送信し、クライアントは証明書チェーンを信頼済みのルート証明書までたどります。ブラウザーは中間証明書をキャッシュしていたり、異なる信頼の仕組みを使っていたりするため、「ブラウザーで開ける」ことは手がかりにとどまり、プロキシコアの検証結果の代わりにはなりません。

1. TLSの終端箇所を確認：TLSを処理しているのがリバースプロキシ、ロードバランサーの入口、プロキシコアのいずれかを確認します。証明書は、実際にハンドシェイクを処理する箇所で更新してください。
2. 証明書チェーン全体を確認：サーバーに完全な証明書チェーンが設定されているか、証明書と秘密鍵が対応しているかを確認します。証明書の更新後は、ファイルを置き換えるだけでなく、設定が再読み込みされたことも確認してください。
3. 複数の接続先を確認：ドメインに複数のIPアドレスや接続先がある場合は、それぞれが返す証明書を確認します。一部の接続先だけ古い証明書を使っていると、接続が断続的に失敗することがあります。
4. 端末の信頼設定を確認：OSとクライアントをサポート対象のバージョンに更新し、企業ネットワークでTLS検査が行われていないか確認してください。出所の不明なルート証明書を、トラブル対応のために安易にインストールしないでください。

allowInsecureの誤用：検証をスキップしても証明書は修復されない

設定の意味：一般的なTLS設定でallowInsecure: trueにすると、通常行われる証明書チェーンと名前の検証が省略され、接続先のサーバーが正当であることを確認できなくなります。TCP接続の失敗、ポートの誤り、サーバーによるハンドシェイク拒否、プロキシ認証の失敗は解決できません。長期的な運用設定としても使わないでください。

{
  "security": "tls",
  "tlsSettings": {
    "allowInsecure": false
  }
}

設定例の範囲：上記はstreamSettings内でよく使われるTLS検証スイッチのみを示したものです。完全なノード設定ではなく、実際のserverName、転送方式、認証パラメーターも含まれていません。この例で既存の設定を上書きしないでください。現在のノードのTLS設定で「安全でない接続を許可」や「証明書検証をスキップ」が有効になっていないか確認します。

• エラーが消えた場合：検証をスキップしてエラーが消えても、証明書検証に関係する問題の可能性を示すだけで、正しいサーバーに接続できた証拠にはなりません。
• 推奨する対処：証明書検証を有効にしたまま、システム時刻、SNI、証明書チェーン全体、またはサーバー証明書を修正して再テストしてください。
• 自己署名証明書を使う場合：信頼させる方法を明確に設計し、使用中のコアが対応する証明書の信頼設定を確認してください。検証の無効化を一般的な代替策にしないでください。

コアとプロトコルの違い：通常のTLSとREALITYに同じ設定を適用しない

プロトコルの区別：VMessとVLESSはプロキシプロトコルです。TLSを使うかどうかは、転送方式とセキュリティ層の設定によって決まります。VLESSだから通常のTLSを必ず使うとは限りません。また、画面にサーバー名の項目があるからといって、すべてのセキュリティ層を証明書の期限切れとして扱うこともできません。

REALITYの注意点：REALITYは通常のTLS証明書とは異なる検証方式を使い、サーバー側の設定と一式で合わせる必要があります。システム時刻の確認は引き続き有効ですが、関連するエラーが出た場合は、まずセキュリティ層の種類を確認し、使用するコアの仕様に沿って設定を照合してください。あらゆる問題を通常のサイト証明書の交換だけで解決するよう、管理者に求めないでください。

最終テスト：一度に変更するのは1項目だけにし、「元のエラー・変更した項目・新しいログ」を記録します。時刻、SNI、証明書チェーン、サーバー、セキュリティ層の互換性の順に原因を絞り込みます。TLS接続が成功してもアクセスできない場合は、安全設定を無効にし続けるのではなく、プロキシ認証、ルーティング、DNSを確認してください。

1. 変更前の状態を記録：現在の設定項目と元のエラーを控え、サブスクリプションの内容は安全な場所に保存します。
2. 1項目ずつ検証：項目を1つ修正したら再接続し、ログが今回のテストで取得されたものか確認します。
3. 設定を元に戻す：一時的な調整を取り消し、証明書検証を有効に保ちます。
4. 設定の保持を確認：クライアントを再起動します。サブスクリプションを使っている場合は、次回の更新で修正が上書きされないか確認してください。