V2RayのTLSハンドシェイク失敗・証明書エラー対処法｜時刻・SNI・フィンガープリント設定 | V2Ray サブスクリプションガイド

この記事の要点

ノードをインポート済みなのに、接続時にTLSまたはx509エラーが出る場合に役立ちます。まずエラーがサブスクリプションの取得時か、ノードへの接続時かを切り分け、端末の時刻、証明書のドメイン名、信頼チェーン、フィンガープリントの順に確認しましょう。設定は一度に1項目だけ変更し、比較用に元のノードを残してください。証明書検証を無効にして解決扱いにするのは避けましょう。

サブスクリプション取得時のエラーとノードのハンドシェイク失敗を切り分ける

「TLSハンドシェイクに失敗しました」というエラーだけでは、原因を特定できません。HTTPSのサブスクリプションURLにアクセスするときにもTLS接続が確立され、TLSを有効にしたプロキシノードへ接続するときにも別の接続が行われます。ブラウザーでHTTPSサイトを開く場合にも、独自の証明書検証があります。いずれもx509と表示されることがありますが、確認すべき対象はそれぞれ異なります。

サブスクリプションを更新した直後にエラーが出て、ノード一覧が変わっていない場合は、まずサブスクリプションURLのサイト証明書を確認します。更新は正常に完了するのに、特定のノードを選んでWebサイトへアクセスするとコアがエラーを出す場合は、そのノードのTLS設定を確認してください。ブラウザーだけに証明書エラーが表示され、コアに該当するエラーがない場合は、ブラウザーの信頼ストア、ネットワークのログインページ、ローカルのHTTPS検査ソフトも確認しましょう。

アドレスを解決トランスポート接続を確立ハンドシェイク情報を送信サーバー証明書を検証プロキシプロトコルで認証

エラーが起きた操作を記録：サブスクリプションの更新、ノードへの接続、特定のWebサイトの表示のどれかを記録します。「接続に失敗」の一言だけでは不十分です。
エラー発生時刻を記録：まずクライアントのログを確認し、リクエストを1回実行して、同じ時刻の詳細なエラーを探します。最後の要約行だけで判断しないでください。
セキュリティ層を確認：VMess、VLESSはプロキシプロトコルの名称であり、すべてのノードで通常のTLSが有効とは限りません。セキュリティ層がREALITYの場合は専用パラメーターを確認し、通常のTLSの判断をそのまま当てはめないでください。

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

ログには、以下の英語メッセージの前後にサーバーアドレス、時刻、コアの呼び出し情報が付くことがあります。最も具体的な原因を探してください。EOFやcontext deadline exceededだけでは、証明書の問題とは限りません。サーバー側からの切断、ネットワークの遮断、ハンドシェイクのタイムアウトなども考えられます。

エラー：`x509: certificate has expired or is not yet valid`

原因：現在時刻が証明書の有効期間外です。端末の時計がずれている場合と、サーバー証明書の期限が切れている場合があります。対処：まず端末の時刻を同期します。時刻が正しいのにエラーが続く場合は、ログに記録された有効期間をサービス提供元に伝え、証明書の設定を確認してもらいましょう。

エラー：`x509: certificate is valid for …, not …`

原因：クライアントが検証しようとしている名前が、サーバー証明書で許可されたドメインに含まれていません。省略部分には実際のドメインが表示されます。対処：ノードのSNI、serverNameと、提供元が指定する証明書のドメイン名を確認してください。接続先アドレスだけを変更しても解決しません。

エラー：`x509: certificate signed by unknown authority`

原因：証明書チェーンが信頼されたルート証明書につながっていません。中間証明書の不足、自己署名証明書、端末の信頼ストアの異常などが考えられます。対処：まず別のネットワークでも同じエラーが出るか確認し、サーバー側で証明書チェーン全体を確認してもらいましょう。提供元が不明なルート証明書を安易にインストールしないでください。

エラー：`remote error: tls: handshake failure`

原因：接続先がハンドシェイクを拒否しています。SNI、TLSパラメーター、プロトコルの接続先、サーバー側のポリシーなどが関係している可能性があります。対処：サブスクリプションの元の設定に戻し、ポートとセキュリティ層が一致しているか確認します。証明書検証を無効にせず、サーバーログも確認して原因を絞り込みましょう。

端末の時刻：まず同期してから再接続

証明書の検証で比較されるのは絶対時刻であり、画面に表示された時刻だけではありません。タイムゾーンの表示が異なっても絶対時刻が正しければ、通常は証明書エラーになりません。一方、時計を手動で進めたり戻したりすると、エラーの原因になります。端末を長期間電源オフにした後、デュアルブートを切り替えた後、自動時刻合わせに失敗した後は、特に確認してください。

パソコンの時刻を同期する

Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にしてタイムゾーンを確認し、「今すぐ同期」をクリックします。同期できない場合は、まず通常のネットワーク接続を確認してください。ノードの設定を何度も変更する必要はありません。
スマートフォンの時刻を同期する

Androidでは通常、「設定」→「システム」→「日付と時刻」で「時刻を自動的に設定」と「タイムゾーンを自動的に設定」を有効にします。機種によっては、設定画面で「日付と時刻」を検索できます。メニュー名は端末のシステムにより異なります。
接続をやり直す

v2rayNではコアを再起動します。v2rayNGでは接続を停止してから、もう一度開始します。リクエストを再実行して新しいログを確認し、時刻を同期する前に記録されたエラーと混同しないようにしましょう。
証明書の有効期間を確認する

時刻を正しく戻しても有効期間のエラーが続く場合は、ログに記録された現在時刻、証明書の開始日時と終了日時、タイムゾーンを確認します。証明書の期限が実際に切れている場合、サーバー側で更新して再読み込みする必要があります。クライアント側の日付を変更しても正しく修復できません。

Windowsでは、ターミナルで以下のコマンドを実行すると、ローカル時刻と時刻サービスの状態を確認できます。2つ目のコマンドは、システムサービスが停止しているとエラーになる場合があります。これは診断の補助情報であり、ノード自体の異常を示すものではありません。問い合わせ時に端末の詳細情報をすべて提出する必要はありません。

powershell -NoProfile -Command "Get-Date -Format o"
w32tm /query /status

SNI・接続先アドレス・Hostを個別に確認する

ノードの「アドレス」は接続先のIPアドレスまたはドメインを指定します。SNIはTLSハンドシェイクで送信するサーバー名で、通常は証明書の名前の検証にも使われます。WebSocketのHostは、その後のHTTPリクエストに含まれるフィールドです。これらが同じ値になる構成もあれば、異なる値になる構成もあります。3つすべてをアクセス可能なWebサイトのドメインに変えても、ノードが使えるようになるわけではありません。

設定項目	用途と確認ポイント
アドレスとポート	実際の接続先を指定します。ポート443はTLSでよく使われますが、ポート番号だけではTLSが有効な接続先とは判断できません。サブスクリプションに記載された値を使用してください。
SNI / serverName	TLSサーバーに接続先の名前を伝えます。通常のTLSノードでは、提供元が指定し、証明書と一致するドメインを指定します。プロトコルの接頭辞、パス、ポート番号は含めません。
Host	WebSocketなどのHTTPトランスポートで、仮想ホストの照合に使われます。Hostを変更してもSNIは変わらず、証明書名の不一致も解消できません。
パスとALPN	パスは該当するトランスポートの接続先を指定し、ALPNはアプリケーション層のプロトコルをネゴシエートします。明確な指定がなければサブスクリプションの値を維持し、h2やhttp/1.1を独自に強制しないでください。

v2rayNではメイン画面で対象ノードをダブルクリックし、サーバー編集画面でアドレス、ポート、トランスポートプロトコル、TLS欄のサーバー名を確認します。v2rayNGでは対象ノードの右側にある編集アイコンをタップし、「アドレス」「ポート」とTLS欄の「SNI」を確認します。バージョンによってserverNameやサーバー名と表示されることもあります。すべてのバージョンで共通のメニューを探すのではなく、項目の意味を基準に確認してください。

結論：まず元のSNIに戻し、次に名前解決を確認

証明書名が一致しない場合は、インポートし直したサブスクリプションのノードと照らし合わせ、まずSNIを元に戻します。設定値が一致しているのに別の証明書が返される場合は、ノードアドレスのDNS名前解決とサーバーの接続先を確認してください。根拠なく「偽装ドメイン」を変更すると、確認項目が増えてしまいます。

接続先アドレスにIPアドレスを使うこと自体は問題ではありません。サーバーがその接続方法を許可し、SNIも正しく設定されていれば、ドメイン証明書を検証できます。
ワイルドカード証明書が通常一致するのは1階層のサブドメインまでです。たとえば*.example.comはa.b.example.comには一致しません。ここに記載したドメインはルールの説明用で、ノード設定ではありません。
サブスクリプションのノードを手動で変更すると、次回の更新で変更が上書きされることがあります。切り分けの際はノードを複製して編集し、比較用にサブスクリプションの元の項目を残してください。

証明書チェーンと検証のスキップを混同しない

証明書の検証では、ドメイン名だけでなく署名チェーンと有効期間も確認します。サーバーが中間証明書を送信していない場合、証明書がキャッシュに残っているブラウザーではページを開けても、プロキシコアではエラーになることがあります。「ブラウザーで開ける」ことは手がかりの1つにすぎず、コアの検証結果の代わりにはなりません。

特定のノードだけ失敗する：同じ端末でほかのTLSノードが正常なら、該当する接続先の証明書チェーン全体、証明書のドメイン名、証明書の読み込み状態を提供元に確認してもらいましょう。
同じ端末で複数のサービスが失敗する：システムの更新状態、ルート証明書の信頼ストア、ローカルのHTTPS検査ソフトを確認します。テストのためにセキュリティ保護をすべて無効にしないでください。
特定のネットワークだけで失敗する：まずネットワークのログイン認証を済ませ、別の信頼できるネットワークでも試します。受信した証明書の発行者に異常がある場合は、サブスクリプションの認証情報を入力せず、ネットワーク環境を確認してください。
自己署名証明書を使用すると明示されている：信頼できる経路で提供元の身元を確認し、クライアントとコアが対応する方法で信頼設定を行います。身元を確認できない場合は、検証を無視して使い続けないでください。

証明書検証のスキップを有効にしていた場合は、トラブルシューティングの終了後に無効にし、再接続してください。検証を元に戻しても同じエラーがログに出ず、実際のリクエストも成功して初めて修復完了です。遅延テストが一度成功しただけでは、すべてのリクエストが想定したTLS接続先を通ったとは限りません。

TLSフィンガープリント：ノードの指定に合わせ、手当たり次第に試さない

TLSフィンガープリントは、拡張機能の並びや対応パラメーターの組み合わせなど、クライアントのハンドシェイク情報の特徴に影響します。証明書の代わりにはならず、期限切れの証明書を有効に戻すものでもありません。通常のTLSとREALITYでは必要なパラメーターが異なるため、ある種類のノードの設定を別の種類にそのまま流用しないでください。

v2rayNはクライアントの画面を提供し、実際のハンドシェイクは選択中のコアが実行します。v2rayNGはXrayコアを、v2flyNGはV2Flyコアを使用します。設定項目が画面に表示されていても、各コアが同じように対応しているとは限りません。トラブルシューティングでは使用中のコア名を記録し、クライアント名だけで比較せず、サービス提供元の指定も確認してください。

セキュリティ層を確認。ノードを編集し、TLSとREALITYのどちらが設定されているかを確認します。サブスクリプションの元の設定は残してください。通常のTLSでx509エラーが出る場合は、まず時刻、SNI、証明書チェーンを確認します。
フィンガープリントの項目を確認。ノードの編集画面でTLSまたはREALITY欄を開き、「フィンガープリント」またはfingerprintを探します。サブスクリプションにchromeなどの値が明記されている場合は、その値を維持し、ALPNは変更しないでください。
コアの対応状況を確認。ログに未対応の項目が表示された場合は、まず対応するクライアントとコアに更新してから、サブスクリプションを再インポートします。項目の削除を汎用的な互換性対策として扱わないでください。
REALITYは個別に確認。serverNameとフィンガープリントに加えて、公開鍵、shortIdなどの提供元指定パラメーターも確認します。公開鍵を証明書パスに入力したり、通常のTLSの検証スキップ設定で代用したりしないでください。

結論：証明書エラーは、まず証明書の条件を修正

ログに証明書の期限切れやドメイン名の不一致が明記されている場合は、該当箇所を修正してからフィンガープリントの互換性を確認します。時刻、接続先、パラメーターをすべて確認しても接続先がハンドシェイクを拒否する場合に限り、クライアントのハンドシェイク特性とサーバー側のポリシーを調べましょう。

よくある質問と修復後の確認

スマートフォンでは接続できるのに、パソコンで証明書エラーが出るのはなぜ？

まず両方の端末で、同じノード、同じSNI、同じセキュリティ層を使用していることを確認し、パソコンの時刻を同期します。次に両方を同じネットワークに接続して再テストしてください。パソコンだけで失敗する場合は、信頼ストアとローカルのHTTPS検査ソフトを確認します。ノード名が同じというだけで設定も同じとは限りません。

「証明書検証をスキップ」すれば使える場合、その設定を残してもいい？

日常的な設定として残すべきではありません。まず元の証明書エラーを記録し、その設定を無効にしてから、時刻、ドメイン名、証明書チェーンを順に修正します。提供元から検証を恒久的に無視するよう求められた場合は、不明な証明書をそのまま受け入れず、本人確認の方法を確認してください。

グローバルモードにすればTLSハンドシェイクの失敗を解決できる？

証明書の問題を直接修正することはできません。ルーティングルールはリクエストの送信先を決め、TLS検証は接続先サーバーの身元を確認します。まずログで実際に選択されたノードを確認してください。モードを切り替えてエラーが消えても、通信経路が変わっただけの場合があるため、元のノードの問題は引き続き修正が必要です。

サブスクリプションの更新時に証明書エラーが出る場合も、ノードのSNIを変更するべき？

まずノードの設定を変更する必要はありません。システム時刻を同期し、サブスクリプションURLのドメイン名が正しいか確認してください。そのURLだけで失敗する場合は、提供元にサブスクリプションサイトの証明書を確認してもらいましょう。既存ノードのSNIを変更しても、サブスクリプションサイトのHTTPS証明書は変わりません。

最終確認では同じ端末、同じネットワーク、同じノードを使い、一度に1項目だけ変更してください。接続を再起動したら、コアのログと実際のWebサイトへのアクセスをそれぞれ確認し、検証スキップを無効にしても正常に使えることを確認します。問い合わせる場合は以下の最小限の情報を伝え、サブスクリプションURL全体、UUID、パスワードなどの認証情報は公開しないでください。

クライアント名、実際にインストールされているバージョン、使用中のコアとそのバージョン、OS名。
エラーが発生した操作、正確な時刻、機密情報を伏せた詳細なエラーメッセージ。
トランスポート方式、セキュリティ層、ポート、SNIが提供元の指定と一致しているか。
時刻同期、ネットワーク変更、ノードを元の設定に戻した後の結果と、その都度変更した項目。