v2rayN、v2rayNG、v2flyNGで発生するTLSハンドシェイク失敗、証明書切れ、ドメイン不一致、接続切断を対象にしています。まず端末の時刻を合わせ、次にノードのアドレス、SNI、トランスポート設定を確認し、最後にコアログから原因がローカル設定、ネットワーク遮断、サーバー証明書の異常のどれかを切り分けます。
TLSハンドシェイクの順番に沿って障害箇所を特定する
TLSはトランスポート接続の上位で動作します。クライアントはまずサーバーアドレスを名前解決し、TCP接続を確立してから、プロトコルバージョン、暗号スイート、SNIを含むClientHelloを送信します。サーバーが証明書を返すと、XrayまたはV2Flyコアが有効期限、発行チェーン、ドメインを検証します。いずれかの検証に失敗すると、VMessやVLESSの認証データはまだ正常な交換段階に入っていません。そのため、UUID、alterId、ルーティングルールを変更しても、通常は証明書エラーを解決できません。
確認時は、まずコアログ全体を保存し、画面に表示される「接続失敗」だけで判断しないでください。v2rayNではメイン画面下部のログ欄、または「ヘルプ」→「ログを表示」から最近の出力を確認できます。v2rayNGでは左上のメニューにある「ログ」を開いてコアエラーを確認します。コアのバージョンによって表現は多少異なりますが、x509、certificate、handshake、server nameなどのキーワードで原因の方向を絞れます。
エラー：x509: certificate has expired or is not yet valid
原因と対処：端末の時刻が証明書の有効期間から外れているか、サーバー証明書が実際に期限切れです。まず日付、時刻、タイムゾーンを自動同期し、再接続してください。複数の端末で同時に発生する場合は、設定の提供元に証明書の更新を依頼します。
エラー：x509: certificate is valid for another domain, not current domain
原因と対処：SNIに指定したドメインが、証明書のSubject Alternative Nameに含まれていません。TLSのserverNameを証明書の対象ドメインに変更し、サーバーのIPアドレスをそのまま入力しないでください。
エラー：remote error: tls: handshake failure
原因と対処：サーバーがハンドシェイクを拒否しています。SNI、ポート、TLSの有効化、トランスポート方式の不一致でよく発生します。サーバー側の設定と一項目ずつ照合し、WS、gRPC、TCPなどのトランスポート設定を混在させていないか確認してください。
エラー：tls: failed to verify certificate
原因と対処：証明書チェーン、ドメイン、または有効期限の検証に失敗しています。まず時刻とSNIを修正し、通常の対処として証明書検証を無効にしないでください。
端末の時刻、タイムゾーン、ネットワーク時刻を合わせる
証明書には有効開始時刻と有効終了時刻が明記されており、検証には端末の現在時刻が使われます。時刻が数分ずれているだけでも、発行直後や更新直後の証明書が「まだ有効ではない」状態になることがあります。スリープ後の時計のずれ、デュアルブートで異なる時刻基準が書き込まれる問題、仮想マシンの一時停止からの復帰、ルーターによる時刻同期の遮断なども原因になります。
Windowsでは「設定」→「時刻と言語」→「日付と時刻」の順に開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にしてから、今すぐ同期を実行します。macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を有効にします。Androidでは「設定」→「システム」→「日付と時刻」を開き、ネットワークから提供された時刻とタイムゾーンを有効にします。Linuxではシステム時刻、タイムゾーン、時刻同期サービスがすべて正常に動作していることを確認してください。
-
元のエラーを記録する
現在の接続を切断し、ログ表示を消去してから一度再接続します。x509、TLS、対象ドメインを含むエラー行全体を残してください。
-
日付とタイムゾーンを確認する
年、月、日、時刻、タイムゾーンを確認します。時計だけを直してタイムゾーンを修正しないと、再起動後に再びずれることがあります。
-
時刻同期を実行する
システムの自動時刻設定を有効にし、手動で一度同期を実行します。同期に失敗する場合は、まずネットワーク時刻サービスへ正常にアクセスできる接続へ切り替えてください。
-
クライアントを再起動する
v2rayN、v2rayNG、v2flyNGを完全に終了してから再起動し、コアを立ち上げ直します。以前のハンドシェイク状態が古い接続で再利用されるのを防げます。
-
別の端末で切り分ける
時刻が正確な別の端末で同じ設定を試します。1台だけ失敗する場合は、その端末の時刻と証明書環境を優先して確認してください。
サーバーアドレス、SNI、証明書ドメインを確認する
サーバーアドレスは接続を対象ホストへ届けるために使われ、SNIはTLSハンドシェイク中にサーバーへ返すべき証明書を伝えます。両者は同じ場合も異なる場合もあります。たとえばサーバーアドレスがIPアドレスで、SNIには証明書が対象とするドメインを入力するケースがあります。IPをSNIにも入力すると、公開証明書は通常ドメインのみを対象としているため、ドメイン不一致エラーになりやすいです。
証明書のドメインを確認するときは、ルートドメインとサブドメインを区別してください。証明書がexample.netを対象としていても、edge.example.netまで必ず対象になるとは限りません。ワイルドカード証明書が1階層のサブドメインを対象としていても、さらに深い階層まで自動的に対象になるわけではありません。ノードに記載されたhost、SNI、serverName、偽装ドメインはそれぞれ異なる役割を持つ場合があり、表記が似ているからといってすべて同じ値にしないでください。
| 設定項目 | 役割 | 正しい入力の原則 | よくあるミス |
|---|---|---|---|
| アドレス | DNS名前解決と接続の確立に使う | ノードに指定されたドメインまたはIPを入力する | プロトコルのプレフィックス、パス、余分な空白を貼り付ける |
| ポート | リモートサービスの待受位置を指定する | サーバー側の実際の待受ポートと一致させる | ローカルプロキシポート10808を誤って入力する |
| SNI | TLS証明書とバーチャルホストを選択する | 証明書の対象で、サーバーが要求するドメインを入力する | IPまたは無関係なドメインを入力する |
| Host | HTTP、WSなどのトランスポート層リクエストに使う | ノードの説明に従い、SNIと無理に同じにしない | パスを含む完全なURLを入力する |
| トランスポートのセキュリティ | TLSまたは該当するセキュリティ層を有効にするか決める | サーバー側の構成と完全に一致させる | サーバーはTLSを有効にしているのに、クライアントでnoneを選択する |
エラー：x509: cannot validate certificate for an IP because it does not contain any IP SANs
原因と対処：クライアントがIPアドレスで証明書を検証していますが、証明書にそのIPが含まれていません。接続アドレスにはIPを残し、SNIまたはserverNameには証明書に対応するドメインを入力してください。
エラー：EOF または connection closed by peer
原因と対処：リモート側がハンドシェイク中に接続を直接閉じています。まずポートとTLSの有効化を確認し、次にSNI、トランスポート方式、ネットワークが接続を誤ったサービスへ送っていないかを確認してください。
サブスクリプションのノードにあるTLS項目は、通常サブスクリプションの内容から生成されます。手動で変更しても、サブスクリプションを再更新すると上書きされることがあります。同じグループ内のすべてのノードで同じエラーが出る場合は、まずサブスクリプションを更新し、内容が修正されているか確認してください。1つのノードだけ失敗する場合は、そのノードの証明書、ドメイン、またはサーバーの待受設定に異常がある可能性が高いです。
allowInsecureの用途を正しく理解する
allowInsecureは、クライアントが証明書検証の一部を省略するかどうかを制御します。公開サービスへ通常接続する場合は無効のままにし、コアが証明書チェーン、有効期限、ドメインを検証できるようにしてください。有効化して一時的に接続できても、問題が証明書検証の段階にあると分かるだけで、SNI、証明書の配置、端末の時刻が正しいことを証明するものではありません。
- 通常利用：allowInsecureは無効のままにし、証明書、端末の時刻、SNIを修正します。
- 短時間の診断：リスクを十分に理解し、障害の段階を確認する必要がある場合に限って一時的に試し、完了後はすぐ無効に戻します。
- 自己署名環境：検証を長期的に省略するのではなく、管理下の端末へ信頼できるルート証明書を正しくインストールしてください。
- サブスクリプション設定：すべてのノードでこの項目を一括して有効にしないでください。各ノードにある異なる証明書問題を隠してしまいます。
REALITY設定でもserverNameに関する問題が起きることがありますが、そのセキュリティ層のパラメーターを通常のTLSノードにそのまま当てはめることはできません。VLESSはプロキシプロトコルであり、TLS、XTLS Vision、REALITYはトランスポートのセキュリティ設定です。確認時はまずノードがどの方式を採用しているかを確認し、その方式に対応する項目を調べてください。異なるセキュリティ層に通常のTLS証明書対策を機械的に適用しないでください。
v2rayN、v2rayNG、v2flyNGで項目ごとに再確認する
デスクトップ版とAndroid版では画面上の名称が異なりますが、確認すべき項目は同じです。アドレス、ポート、トランスポートプロトコル、トランスポートのセキュリティ、SNI、Host、パス、コアログを確認してください。まず元の設定をバックアップとして複製し、一度に1項目だけ変更して再テストすると、どの項目が変化の原因か判断できます。
-
コア設定を確認する
v2rayNで「設定」→「パラメーター設定」→「Coreタイプ」を開き、想定したコアでノードが処理されていることを確認します。通常のXray設定を互換性のないコアへ誤って切り替えないでください。
-
ノードの項目を編集する
v2rayNのノードをダブルクリックして編集画面を開き、アドレス、ポート、トランスポートプロトコル、TLS、セキュリティタイプ、SNIを順番に確認します。アドレス欄にhttps://のプレフィックスを追加しないでください。
-
Androidの設定を確認する
v2rayNGまたはv2flyNGの設定一覧で対象設定を選択して編集画面を開き、「偽装ドメイン」「SNI」または同等の項目を確認し、保存してから接続を再起動します。
-
サブスクリプションの内容を更新する
サブスクリプショングループを開いて更新を実行し、失敗したノードの項目が変化したか比較します。サブスクリプションの更新失敗とノードのTLS接続失敗は別の接続処理なので、それぞれのログを分けて確認してください。
-
古い接続を終了する
クライアントのプロキシを停止し、古い接続が解放されるまで待ってから再起動します。デスクトップ版では、システムプロキシが終了済みの古いインスタンスではなく、現在のローカル待受ポートを指していることも確認してください。
-
他のノードと比較する
同じサブスクリプションにある別のノードを試します。すべてのノードで失敗する場合は端末環境を確認し、1つだけ失敗する場合はそのノードの証明書とサーバー設定を重点的に確認してください。
ルーティングによる分流は通常、リモート証明書の内容を変えませんが、どのアウトバウンドから接続するかを決めることがあります。ルールによってノードのドメインが利用できないプロキシアウトバウンドへ送られると、タイムアウトや接続切断として現れる場合があります。分流の影響を除外するには、短時間だけ直接接続する明確なテストルールへ切り替えます。TLS接続が戻ったら元のルーティング設定に戻し、ヒットログを一つずつ確認してください。
よくある質問と最終確認リスト
時刻、SNI、証明書検証を確認しても接続に失敗する場合は、ネットワーク層とサーバー側を引き続き調べます。DNS汚染によってドメインが誤ったアドレスへ解決されたり、透過プロキシによって接続経路が書き換えられたり、サーバーのリバースプロキシが更新後の証明書を読み込めていない可能性があります。この段階では、名前解決結果、接続ポート、サーバーログを組み合わせて判断し、UUIDの変更を繰り返さないでください。
スマートフォンでは接続できるのに、パソコンでは証明書の時刻エラーが出続ける場合は？
まずパソコンの年、タイムゾーン、自動時刻同期を確認します。同期が完了したらv2rayNを完全に終了し、コアを起動してテストしてください。ノードを切断してすぐ再接続するだけでは不十分です。
SNIを空欄にしてクライアントに自動判定させられますか？
接続アドレスが証明書のドメインそのものであれば、一部の設定ではアドレスをデフォルトのserverNameとして使用できます。アドレスがIP、前段ドメイン、特殊な構成の入口である場合は、ノードの説明に従ってSNIを明示してください。
サブスクリプション更新後、すべてのノードでハンドシェイクに失敗する場合は？
まずシステム時刻を確認し、次にサブスクリプションによってトランスポートのセキュリティ、SNI、ポートが変更されていないか確認します。複数の端末で同じ時間帯に同じエラーが出る場合は、設定提供元に証明書とサーバー構成を確認してもらう必要があります。
allowInsecureを有効にすると使えますが、ずっと有効にしてもよいですか？
おすすめしません。短時間の原因切り分けに限って使う機能です。厳格な検証へ戻し、ドメインの一致、証明書チェーン、時刻の問題を修正してください。
TLSエラーはVMessやVLESSの鍵と関係しますか？
証明書検証はプロキシプロトコルの認証より前に行われます。ログがx509、certificate、server nameを明確に示している場合は、まずTLSを処理してください。ハンドシェイク成功後にUUID、暗号方式、フロー制御パラメーターを確認します。
- 端末の日付、時刻、タイムゾーンが正確で、自動同期が正常に完了していることを確認する。
- ノードのアドレスにプロトコルのプレフィックス、パス、空白、入力ミスがないことを確認する。
- リモートポートがサーバーの待受ポートと一致し、10808などのローカルポートを誤入力していないことを確認する。
- SNIが証明書の対象ドメインに対応し、証明書対象外のIPを直接入力していないことを確認する。
- TLS、WS、TCP、gRPCなどのトランスポートパラメーターがサーバー側と一致していることを確認する。
- allowInsecureは無効のままにし、ログで実際の証明書エラーを特定する。
- サブスクリプション更新で手動修正が上書きされていないことを確認し、必要なら設定を複製して個別にテストする。
- 別の端末と別のノードを比較し、ローカル端末の問題かサーバー側の問題かを切り分ける。
確認手順は固定してください。まずログを読み、次に時刻を同期し、その後アドレス、ポート、SNI、トランスポートのセキュリティを確認し、最後に証明書チェーンとサーバーの状態を調べます。この順番なら、証明書障害をノード認証、システムプロキシ、ルーティングルールの問題と誤認しにくくなり、無効な一括変更も減らせます。