V2RayのTLS証明書エラー対処法：システム時刻のずれとSNIの設定ミス

まずログを確認：証明書エラーと接続タイムアウトを見分ける

ノードが接続できなくても、TLSが原因とは限りません。TLSハンドシェイクは基盤となる接続の確立後、プロキシプロトコルのデータを送る前に行われます。ログにx509、certificate、または具体的なハンドシェイクの原因が記録されている場合に、証明書の問題として調べましょう。context deadline exceededだけでは、待ち時間を超過したことしか分からず、証明書の期限切れとは判断できません。

v2rayNではメイン画面下部のログ欄を確認します。使用中のバージョンでログが別画面にある場合は、「ログ」を開いてから再接続してください。v2rayNGではメイン画面のサイドメニューから「ログ」を開き、サービスを停止して再起動した後、直近の記録を確認します。v2flyNGでも今回の接続に関するコアのログを確認し、以前の失敗記録と混同しないようにしましょう。画面の構成はバージョンによって異なるため、実際の表示に従ってください。

• クライアントのバージョン、使用中のコアの種類、接続時刻、詳細なエラーを記録します。「接続に失敗しました」といった概要だけを切り取らないでください。
• バックグラウンドで動作しているブラウザーのリクエストを一時停止してから再接続し、複数のエラーが入り交じって誤判定するのを防ぎます。
• ログを共有する前に、サブスクリプションURL、認証情報、サーバーアドレスを伏せてください。エラーの種類とタイムスタンプ、マスキングしたドメインの対応関係は残します。

x509エラーの内容から確認箇所を絞り込む

以下はよく見られる実際のエラー例です。完全なログにはコア名の接頭辞、証明書名、日付などが含まれ、表現もコアのバージョンによって異なる場合があります。詳細な原因を確認してください。特に有効期間に関するエラーは、ログの現在時刻と証明書の有効期間を照らし合わせて判断します。「期限切れ」という表示だけでノードの交換を求めないようにしましょう。

ログに、証明書が別の名前には有効だが現在の名前には適用されないと表示される場合は、SNIと検証名を優先して確認してください。EOFや接続リセットだけの場合は、指定ポートのサービスが現在のハンドシェイクを受け付けていない可能性もあります。すぐにシステム時刻の問題と決めつけないでください。

システム時刻を同期する：証明書の期限を調べる前に時計を合わせる

証明書には有効開始日時と有効期限があります。端末の時刻がその範囲外だと、サーバー側の設定に問題がなくても、証明書は未有効または期限切れと判定されます。デュアルブート、マザーボードの電池切れ、長期間のオフライン、手動での日付変更などにより、時刻がずれることがあります。タイムゾーンは主に表示に関係します。タイムゾーンを正しく設定しただけでは、システムが記録する実際の時刻まで正しくなるとは限りません。

1. 日付と時刻を確認

   まず年、月、日、時刻を確認します。Windows PowerShellでGet-Date -Format oを実行し、タイムゾーンのオフセットを含む時刻を信頼できる時計と照らし合わせてください。

2. 時刻を同期

   Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。「その他の設定」にある「今すぐ同期」をクリックしてください。同期できない場合は、まずネットワークまたは時刻サービスの問題を解決します。

3. Androidの設定を確認

   Androidでは通常、「設定」→「システム」→「日付と時刻」から設定できます。「日時を自動的に設定」と「タイムゾーンを自動的に設定」を有効にしてください。メーカーによってメニューが異なる場合は、設定内で「日付と時刻」を検索し、表示時刻が更新されたことを確認します。

4. 再接続

   同期後、クライアントの接続を停止して再起動し、新しいログを確認します。現在時刻が正確で、証明書の有効期限も過ぎている場合は、サーバー側で証明書を更新して再読み込みする必要があります。

Windowsではw32tm /query /statusを実行して、時刻同期の参照元と状態を確認できます。コマンドの結果がサービス停止を示す場合は、プロキシのコアを何度も再起動するのではなく、まずWindows Timeサービスを確認してください。組織のポリシーで管理されている端末では、指定された時刻源の修正を管理者に依頼し、管理ポリシーを勝手に上書きしないでください。

SNIと偽装ドメイン：接続先、名前、Hostを分けて確認

SNIはTLSハンドシェイクで接続先の名前をサーバーに伝える拡張機能です。サーバーはこれをもとに証明書や仮想ホストを選択できます。通常、設定したTLSサーバー名は証明書名の検証にも使われますが、コアによっては検証名を個別に指定できるため、明示的な上書き設定がないかも確認してください。サーバーの案内にある「偽装ドメイン」は、項目の定義が統一されていません。SNI、HTTP Host、その他の転送パラメーターのどれを指すのか、必ず確認しましょう。

v2rayNでは対象ノードをダブルクリックして編集画面を開き、TLS欄の「SNI」または該当するサーバー名の項目を確認します。v2rayNGではノード右側の編集アイコンをタップし、TLS設定の「SNI」を確認してください。項目名はバージョンによって異なる場合があります。TLS欄を確認し、転送設定の「Host」と混同しないようにしましょう。v2flyNGでも、使用中のコアとノードのプロトコルに対応する項目を使ってください。

たとえば、サーバーからTLS名としてedge.example.comを指定されている場合、この欄にhttps://edge.example.com/と入力してはいけません。ここに記載したドメイン名は形式の説明用であり、実際に使えるノード設定ではありません。サーバーアドレスがIPアドレスでも、必ずしも誤りではありません。接続先が正しく、TLSで証明書に含まれる正当な名前を使っていれば、アドレス欄までそのドメイン名に変更する必要はありません。

証明書検証を有効に保つ：サーバーの証明書チェーンとネットワークを確認

「証明書検証をスキップ」は、allowInsecureなどの項目で設定される場合があります。有効にすると、クライアントが証明書チェーンや名前を正しく検証しなくなる可能性があります。これではサーバーの身元を確認できず、元の設定ミスも解決しません。トラブル対処中は無効のままにしてください。以前に有効にしていた場合は検証を再び有効にし、改めて表示された正確なエラーをもとに原因を調べましょう。

• 特定のノードだけで発生：管理者に証明書の有効期間、中間証明書を含む完全な証明書チェーン、SNIに対応する仮想ホスト、更新後にサービスが証明書を再読み込みしたかを確認してもらいましょう。
• 複数のノードで同時に発生：まず端末の時刻、システム更新、現在のネットワークを確認してください。会社のネットワークやセキュリティソフトによるHTTPS検査で、証明書の信頼経路が変わることがあります。ただし、エラーが出たという理由だけで通信の傍受と決めつけず、根拠を確認してください。
• ネットワークを変えると復旧：元のネットワークでWeb認証が必要か、DNSが想定どおりの接続先を返しているか、ネットワークポリシーがTLSに影響しているかを確認します。出所が不明なルート証明書を、接続のためだけにインストールしないでください。
• プライベート証明書を使用：明確な管理上の要件があり、発行者と証明書の入手元を確認できる場合に限り、管理者の指示に従って信頼設定を行います。一般のサブスクリプション利用者は、まず提供元に設定内容を確認してください。

この記事では一般的なTLS証明書の検証を扱っています。ノードのセキュリティ方式がREALITYの場合は、サーバーから指定されたサーバー名、公公開鍵、ショートID、クライアントコアの対応状況を確認してください。通常の証明書更新と同じ方法では対処できません。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。対応するプロトコルやセキュリティパラメーターは完全には同じではないため、クライアント名だけを変えて互換性があると判断しないでください。

接続復旧後の確認とよくある質問

設定を変更するたびに接続をやり直し、新しいログを確認してください。以前の接続が残っていたり、サブスクリプションの更新で手動設定が上書きされたりすると、結果に一貫性がないように見えることがあります。時刻、SNI、DNS、ルーティングを一度に変更しないでください。変更内容と新しいエラーを手順ごとに記録すると、どの設定が影響したのか特定できます。

1. システムの時刻自動同期が有効で、日付とタイムゾーンが正しく表示されることを確認します。
2. ノードのTLS名がサーバーの案内と一致し、証明書検証が無効化されていないことを確認します。
3. 接続を停止してから再接続し、新しいログに同じ種類の証明書エラーが出ないことを確認します。
4. 解決しない場合は、クライアントとコアのバージョン、発生時刻、確認済みの項目、マスキングした詳細エラーを添えて問い合わせてください。サブスクリプション全体をそのまま送るのは避けましょう。