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

1. ログ全体を確認し、どの段階で失敗したかを特定する

「TLSハンドシェイク失敗」は問題が起きた範囲を示すもので、原因を特定するものではありません。一般的な接続では、サーバーアドレスの名前解決、TCP接続、TLSネゴシエーションと証明書検証の後に、プロキシプロトコルや上位の転送処理が行われます。VMessとVLESSはプロキシプロトコルの名称であり、プロトコル名だけでは証明書の正しさは判断できません。

v2rayNのメイン画面にあるログ欄を確認します。必要に応じて「設定」→「パラメータ設定」を開き、コアのログレベルを一時的にinfoに設定してください。項目の場所や名称はバージョンによって異なる場合があります。v2rayNG、v2flyNGでは、アプリのメニューにあるログ画面でコアの出力を確認できます。古いログを消してからノードを1つだけ再試行し、その接続で発生したエラーを記録してください。他のアプリの接続エラーが混ざらないようにします。

ログにあるi/o timeout、connection refused、EOFだけでは、証明書の問題とは断定できません。最初の2つは、ネットワークの到達性とサービスの待ち受け状態を先に確認してください。EOFだけが表示される場合は接続が途中で終了したことを示すため、サーバー側のログと合わせて原因を特定します。ログを共有する際は、サブスクリプションURL、ユーザー識別情報、アクセストークンを隠してください。

2. システム時刻のずれ：同期してから証明書の期限を確認

証明書には有効期間の開始日時と終了日時が記録されています。システムの日付が1年ずれていれば、有効期間の範囲外となります。数分のずれでも、証明書の発行直後や期限間近には検証に失敗することがあります。タイムゾーンの表示が異なっていても、時計が間違っているとは限りません。タイムゾーン名だけで判断せず、端末が記録する実際の時刻が正確かを確認してください。

1. Windows：「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」をクリックします。日付、年、タイムゾーンを確認し、クライアントのコアを再起動してください。
2. macOS：「システム設定」→「一般」→「日付と時刻」を開き、「日付と時刻を自動的に設定」を有効にします。長時間のスリープから復帰した後も、現在の時刻を確認してください。
3. Android：システム設定で「日付と時刻」を検索し、「日時を自動設定」と「タイムゾーンを自動設定」を有効にします。ネットワークに接続できることを確認し、v2rayNGまたはv2flyNGに戻って同じノードを再試行してください。
4. Linux：timedatectl statusで時刻同期の状態を確認します。systemdを使用するシステムでは、sudo timedatectl set-ntp trueを実行してネットワーク時刻同期を有効にできます。

Windowsでは、まずターミナルで同期状態を確認できます。2つ目のコマンドは管理者として実行してください。同期に失敗した場合は、システムの案内に従って時刻サービスとネットワークを確認し、ノードの設定を次々に変更しないようにします。

w32tm /query /status
w32tm /resync

これらは各プロトコルで一般的に使われるポートであり、ノードが必ずそのいずれかを使用するとは限りません。ネットワークでUDP 123が遮断されると、従来のNTP同期に影響することがありますが、プロキシのポートも遮断されているとは限りません。システム時刻が正確なのにログに証明書の期限切れが明記されている場合は、サーバー側で証明書を更新して再読み込みしてください。端末の日付を変更しても解決しません。

3. SNI、サーバーアドレス、Host：3つの項目を個別に確認

SNIは、TLSハンドシェイク時に送信するサーバー名です。同じアドレスで複数のサービスを運用している場合に、適切な証明書を選択するために使われます。v2rayNのノード編集画面にある「SNI」または「サーバー名」は、通常、コアのTLS設定にあるserverNameに相当します。クライアントは設定されたサーバー名を使って証明書の相手先を検証するため、表示できそうなWebサイトのドメインを適当に入力してはいけません。

たとえば、サーバーアドレスにIPアドレスを指定し、SNIには証明書の対象となるドメイン名を指定できます。両者が同じである必要はありません。ただし、IPアドレスで証明書を検証する場合は、証明書のSANに該当するIPアドレス形式の項目が必要です。ドメイン名の項目だけでは不十分です。通常のドメイン証明書では、証明書画面のタイトルだけでなく、SAN（Subject Alternative Name、サブジェクト代替名）を確認してください。

• SNIにはexample.comのようにドメイン名だけを入力します。https://、ポート、スラッシュ、空白は付けないでください。
• *.example.comは通常、a.example.comをカバーします。ただし、example.comやa.b.example.comもカバーするとは限りません。
• サブスクリプションに記載された「偽装ドメイン」は、Hostを指す場合もSNIを指す場合もあります。項目ごとの役割を確認し、「ドメイン」という言葉だけを見て同じ値をすべてにコピーしないでください。

4. 証明書チェーンの不足：ブラウザーで開けてもコアで検証できるとは限らない

サーバーは通常、サイト証明書と必要な中間証明書を送信し、クライアントは自身の信頼するルート証明書を使って検証します。ブラウザーは中間証明書をキャッシュしていたり、異なる信頼の仕組みを使っていたりする場合があります。そのため、「同じドメインをブラウザーで開ける」ことは手掛かりにはなりますが、サーバーの証明書チェーン設定に問題がない証明にはなりません。

1. まず影響範囲を確認：時刻が正確な複数の端末で同じノードに「不明な認証局」のエラーが出る場合は、管理者に適用中の証明書と中間証明書を確認してもらいましょう。
2. 次に端末ごとの差を確認：古いシステムでのみ失敗する場合は、システムの更新状況と信頼するルート証明書を確認し、クライアントと実際に使用しているコアのバージョンを記録します。
3. ネットワークによる介入を確認：社内ネットワークやHTTPS検査機能を有効にしたセキュリティソフトの環境でのみ発生する場合は、ネットワーク管理者に証明書の差し替えが行われていないか確認してください。
4. プライベート証明書への対応：管理下にあることが明確な環境でのみ、管理方針に従って信頼できる証明書を設定してください。入手元が不明なルート証明書をインポートしないでください。

コマンドライン環境がある場合は、OpenSSLでサーバーが返す証明書を確認できます。以下では予約済みのサンプルドメインを使い、コマンドの形式だけを示します。実際の調査では、接続先アドレスと想定するSNIにそれぞれ置き換え、ポートもノードの設定に合わせてください。

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

-servernameはSNIの送信に使い、-verify_hostnameは検証する名前の指定に使います。用途は異なります。このコマンドが参照する信頼ストアは、クライアントのコアと異なる場合があります。ローカルのOpenSSLに信頼できるCAが正しく設定されていなければ、コマンドがエラーになってもサーバー側の障害とは断定できません。確認時は、返された証明書のSAN、有効期間、証明書チェーンを記録し、最後の1行だけを切り取らないでください。

5. 証明書検証のスキップ：無効のままにして設定の問題を修正

「安全でない接続を許可」「証明書検証をスキップ」は、一般にallowInsecureに対応します。有効にすると、信頼できない証明書や名前が一致しない証明書をクライアントが拒否しなくなる場合がありますが、証明書の問題が直るわけではありません。接続先の身元を通常どおり検証できなくなります。また、TCPタイムアウト、ポートの誤設定、WebSocketパスの誤り、プロキシ認証の失敗も解決しません。

以下は通常のTLSアウトバウンドにおけるstreamSettingsの一部を示したものです。インポートして使える完全な設定ではなく、REALITYにも適用できません。example.comは項目間の関係を説明するための例です。実際の値はサーバー設定に基づいて入力し、例のドメインでノードに接続しないでください。

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

• 保存後にコアを再起動し、新しい設定が実際に読み込まれたことを確認してください。
• ログに古いドメイン名が残る場合は、選択中のノードとサブスクリプショングループを確認し、使用中の設定を編集したか見直してください。
• 一時生成ファイルを直接編集しても、変更が恒久的に反映されるとは限りません。クライアントの次回起動時やノード更新時に、ファイルが再生成される場合があります。

6. 証明書検証後も失敗する場合：転送層とサーバー側の記録を確認

証明書検証に成功しても、プロキシ接続が成功したとは限りません。WebSocketのパスとHost、gRPCのサービス名、プロキシプロトコルのユーザー識別情報は、それぞれの段階で通信に使われます。ログがx509エラーからHTTPステータスエラーや認証エラーに変わった場合は、新しいエラーに沿って調査してください。再び検証スキップを有効にする必要はありません。

一度に変更する項目は1つにし、同じノードで再試行してください。DNS、SNI、コア、ポートを同時に変えると、接続が回復してもどの変更が有効だったか判断できません。クライアントやコアを更新する前に設定を保存し、ノードに必要なプロトコルと転送方式がサポートされていることを確認します。エラーを消すためだけに、むやみにコアを切り替えないでください。

• 端末の記録：OS、クライアントのバージョン、コアの名称とバージョン、システム時刻の同期結果。
• ノードの記録：接続先の種類、ポート、TLSの種類、SNI、転送方式。ユーザー識別情報とサブスクリプションの認証情報は伏せてください。
• ログの記録：失敗した正確な日時とエラーの全体を保存し、接続段階、証明書検証段階、転送段階のどこで失敗したかを記録します。
• サーバー側の確認：現在の証明書の有効期間、SAN、中間証明書の設定、更新後に関連サービスを再読み込みしたか。

7. よくある質問：エラーの範囲に応じて次の確認項目を選ぶ