v2rayN、v2rayNG、v2flyNGのログにTLS、x509、ハンドシェイク中断が表示される場合に役立つ解説です。まず元のエラーから接続タイムアウトと証明書検証失敗を切り分け、システム時刻、ノードのアドレスとSNI、証明書チェーン、フィンガープリント、通信設定を順に確認します。通常のTLSとREALITYは分けて対処してください。証明書検証のスキップは設定修正の代わりにはなりません。
1. ログを確認：ハンドシェイク失敗が証明書エラーとは限らない
TLSは接続の確立後、プロキシプロトコルで通信を始める前に使われます。ノードのアドレス解決失敗、TCPポートへの接続不可、サーバーによる接続切断などでも、クライアントには最終的に「接続失敗」と表示されます。証明書の有効期間、ホスト名、信頼された認証局に関するエラーがログに明記されている場合に、証明書を優先して確認してください。EOFやcontext deadline exceededの一行だけでは、原因を特定できません。
v2rayNのメイン画面にあるログ欄で接続を一度再現し、エラーの発生時刻を記録して、同じ接続に関する少し前のエラーも確認します。Androidクライアントではメニューの「ログ」から確認できます。バージョンによってログの場所は異なりますが、必要なのはカーネルの生ログであり、速度測定一覧に表示される「失敗」だけではありません。ログを共有する際は、サブスクリプションURL、ユーザー識別情報、認証情報を隠してください。
エラー：x509: certificate has expired or is not yet valid
原因と対処：端末の時刻が証明書の有効期間から外れているか、サーバー証明書が実際に期限切れになっています。まず端末の日付と時刻を同期し、証明書の有効開始日と有効期限を確認してください。
エラー：x509: certificate signed by unknown authority
原因と対処：証明書の検証チェーンを信頼されたルートまでたどれません。中間証明書の不足、自己署名証明書、ネットワーク上での証明書差し替えなどが考えられます。サーバーの証明書チェーン全体と端末の信頼環境を確認し、検証を安易に無効化しないでください。
エラー：tls: unrecognized name
原因と対処：サーバーがクライアントから送信されたSNI名を拒否した可能性があります。ノードに設定されたサーバー名と、サーバーが受け付ける名前を一字ずつ照合し、接続先の入口が正しいか確認してください。
エラー：remote error: tls: handshake failure
原因と対処：接続先がハンドシェイクを中断しています。TLS設定、クライアント証明書の要求、サーバー側の接続ポリシーなどが原因として考えられます。サーバーログとノード設定をあわせて確認してください。このエラーだけで証明書の期限切れとは判断できません。
2. システム時刻を同期：日付・タイムゾーン・証明書の有効期間
証明書の検証では、現在時刻を証明書のnotBeforeとnotAfterに照らして確認します。端末の年が誤っていたり、スリープから復帰した後に時計が大きくずれていたりすると、有効な証明書が「まだ有効でない」または「期限切れ」と判定されることがあります。タイムゾーンは主に時刻の表示に影響します。重要なのはシステムの実時刻が正確かどうかであり、画面上のタイムゾーンを直すだけで確認を終えないでください。
-
パソコンの時刻を同期する
Windows 11の「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。「今すぐ同期」をクリックし、日付、年、タイムゾーンを確認してください。
-
Androidの時刻を同期する
標準Androidの「設定」→「システム」→「日付と時刻」で、時刻とタイムゾーンの自動設定を有効にします。メーカー独自のシステムで項目の場所が異なる場合は、設定内で「日付と時刻」を検索し、ネットワーク時刻が反映されているか確認してください。
-
再接続して確認する
ノードを切断してから再接続し、新しいログのタイムスタンプを確認します。それでも期限切れと表示される場合は、サーバー側の証明書の日付を確認してください。期限切れの証明書は、サーバー管理者による更新と再読み込みが必要です。
時刻を同期できない場合は、まず端末がインターネットに接続できるか確認してください。会社のネットワークでは時刻同期の通信が制限されることがあります。期限切れの証明書に合わせてシステムの日付を過去に戻さないでください。ほかのHTTPS接続に影響するうえ、サーバー側の更新漏れを見えにくくします。
3. SNIを確認：サーバーアドレス・証明書名・Hostを区別する
ノードの「アドレス」は接続するホストまたはIPを、「ポート」は接続するサービスを指定します。SNIはTLSハンドシェイクで送信するサーバー名です。通常のTLS設定では、明示的に指定したserverNameが証明書のホスト名検証にも使われます。接続先アドレスにはIPを指定できますが、検証に使う名前は証明書の対象ドメインと一致し、サーバー側の接続条件も満たす必要があります。
| 項目 | 用途 | よくある入力ミス |
|---|---|---|
| アドレスとポート | 接続先の入口を指定 | HTTPSでよく使われる443を、すべてのノードのポートだと思い込む |
| SNI / serverName | TLS仮想ホストを選択し、通常のTLSの名前検証にも使用 | https://、パス、誤ったサブドメインを入力 |
| WebSocket Host | TLS確立後のHTTPリクエストで使うホスト名 | Hostを変更すれば証明書名の不一致も直ると思い込む |
| WebSocket path | WebSocketリクエストのパスを指定 | 先頭のスラッシュを忘れる、または別ノードのパスを使う |
| gRPC serviceName | gRPCサービス名を指定 | ドメイン名を誤入力する、またはサーバー側の名前と一致しない |
v2rayNのノード一覧で対象ノードをダブルクリックし、編集画面で「アドレス」「ポート」と、TLS欄の「SNI」またはサーバー名を確認します。v2rayNGではノード右側の編集アイコンをタップし、TLSとSNIの項目を確認してください。項目名はバージョンによって異なるため、対象ノードの編集画面を確認します。SNIを全般的なルーティング設定から探す必要はありません。
- SNIには通常、
www.example.comのようなドメイン名だけを入力します。プロトコル、ポート、パスは付けません。このドメインは形式の例です。実際にはサーバー管理者から指定された名前を使用してください。 - 通常の証明書で使われるワイルドカード
*.example.comは、一般にa.example.comには一致しますが、ルートドメインや複数階層のサブドメインまで対象になるとは限りません。 - サービス提供者が使う「偽装ドメイン」という言葉の意味は明確でない場合があります。TLS SNI、HTTP Host、REALITYのサーバー名のどれを指すのか確認し、同じものとして扱わないでください。
ログに「証明書は別の名前には有効だが、現在の名前には無効」と明記されている場合は、まず誤ったIPに接続していないか、入口からデフォルトサイトの証明書が返されていないかを確認し、その後SNIを修正してください。有名サイトのドメインに適当に変更しても、別の名前不一致を招くことがほとんどです。
4. 証明書チェーン・フィンガープリント・REALITY設定を確認
ルート証明書が信頼されていても、サーバーが送信する証明書チェーンが完全とは限りません。通常のTLSサーバーは、リーフ証明書と必要な中間証明書を提示します。ブラウザーによってはキャッシュを使って中間証明書を補完するため、「ブラウザーでは開ける」からといって、プロキシのカーネルでも同じチェーンを検証できるとは限りません。また、同じアドレス、ポート、SNIで確認しているかも確認してください。ドメインの別の入口を試している可能性があります。
- 証明書チェーンのエラー：サーバー管理者に証明書チェーン全体と、更新後の証明書が読み込まれているか確認してもらってください。端末の信頼ストアが古い場合は、システムとクライアントを更新して再確認します。
- フィンガープリントの不一致：uTLS対応のカーネルでは、
fingerprintでClientHelloの特徴を選択できます。これは証明書のフィンガープリントでも、証明書の信頼設定でもありません。まずノードで指定された値を使ってください。 - REALITYノード：サーバー設定に合わせて、サーバー名、公鍵、shortIdなどを設定する必要があります。項目名はバージョンによって異なる場合があるため、管理者から提供された設定一式をインポートするのがおすすめです。
- カーネルの対応状況：v2rayNGはXray、v2flyNGはV2Flyを使用しており、対応するセキュリティ設定や通信方式は完全には同じではありません。REALITYが必要なノードは、未対応のカーネルでTLS設定を一つ変更するだけでは動作しません。
v2rayNはクライアントの画面であり、実際の接続動作はノードが使うカーネルにも左右されます。画面を更新しても古いカーネルが動作している場合、新しい設定項目が想定どおり反映されないことがあります。ログに表示されるカーネル名と起動バージョンを確認し、ノードの要件に合わせて更新してください。「フィンガープリントを変更したら一度つながった」だけで証明書の問題を特定したと考えないでください。
5. allowInsecureを恒久的な対策にできない理由
通常のTLSでは、allowInsecureによって安全でない証明書検証を許可できます。有効にすると通常は証明書チェーンやホスト名の検証が省略されますが、通信が平文に戻るわけではありません。暗号化は続いていても、通常の検証手順で接続先の身元を確認できなくなる点が問題です。そのため、接続できるようになっても、設定が正しくなったとは限りません。
症状：証明書検証をスキップすると接続できる
原因と対処：証明書検証が関係する問題の可能性はありますが、時刻ずれ、名前の誤り、証明書チェーンの不足、証明書の差し替えをまだ区別できていません。検証を元に戻し、ログに沿って一つずつ修正してください。接続先が信頼できると判断する根拠にはなりません。
症状：証明書検証をスキップしてもタイムアウトする
原因と対処：証明書の検証段階まで接続が進んでいないか、通信方式や接続入口のポリシーに問題がある可能性があります。アドレス、ポート、ネットワーク到達性、サーバーログを確認してください。関係のない設定を次々と有効にしないでください。
許可された管理下のテスト環境では、原因を絞るために管理者が検証設定を一時的に変更することがあります。ただし、信頼できないネットワークで日常的な接続方法として使うべきではありません。特にアカウントへのログイン、サブスクリプションの取得、機密情報を扱うリクエストの前には、検証可能な接続を確立してください。独自の証明書体系を使う場合は、カーネルが対応する信頼設定を使って正しく信頼を構築し、検証を恒久的に省略しないでください。
- 元のノード設定を保存するかスクリーンショットを撮り、検証設定の状態を記録して、テスト後に戻し忘れないようにします。
- 通常の証明書検証を有効にした状態で一度再現し、詳細なエラーをすべて記録します。
- 時刻の補正やSNIの修正など、根拠のある項目を一つだけ変更して再接続します。
- 修正後は
allowInsecureがfalseになっていること、または画面の「証明書検証をスキップ」がオフになっていることを確認してください。
6. 再テスト項目：証明書検証後も接続できない場合
TLSハンドシェイクの成功は、接続処理の一段階にすぎません。その後のWebSocketハンドシェイク、gRPCサービスとの照合、プロキシプロトコルの認証、接続先ドメインの名前解決で失敗することもあります。新しいログにx509エラーがなく、HTTPステータスコードの異常や認証失敗が表示される場合は、該当する層を調べてください。すでに正しいSNIを何度も変更する必要はありません。
時刻を同期したのに、証明書が期限切れと表示されるのはなぜ？
新しいログを確認し、古い記録を見ていないか確かめてください。そのうえで、現在の接続入口が実際に返す証明書をサーバー管理者に確認してもらいます。更新後の証明書ファイルが生成されてもサービスが再読み込みしていない場合や、ロードバランサーの一部の入口で古い証明書が使われている場合は、エラーが続くことがあります。
スマートフォンでは接続できて、パソコンではできません。SNIを変更すべきですか？
まず両方の端末でノード設定一式、使用カーネル、時刻を比較し、接続しているネットワークも確認してください。パソコンでセキュリティソフトが証明書を差し替えていないか、別の入口に接続していないかも調べます。端末の違いだけを理由にSNIの誤りと判断しないでください。
WebSocketが400または404を返します。TLSの問題ですか？
HTTPレスポンスが返っている場合は、通常すでにHTTP層まで進んでいます。WebSocketのHost、path、リバースプロキシのルールを確認してください。また、想定したサービスからのレスポンスかどうかも確認し、デフォルトサイトの応答をノードの正常動作と誤認しないようにします。
サブスクリプションを更新したら、直した設定が元に戻りました。
サブスクリプションの更新でノードの設定項目が上書きされる場合があります。ノードを複製して個別にテストし、修正内容を記録したうえで、管理者にサブスクリプションの設定元を修正してもらってください。更新のたびに設定を手動で入れ直す運用を続けないでください。
トラブル調査を依頼するとき、何を伝えればよいですか？
クライアントとカーネルのバージョン、システム時刻、エラーの発生時刻、個人情報を隠した元のログ、TLSまたはREALITYの使用状況を伝えてください。ネットワークを変更すると結果が変わるかも説明します。共有リンクやサブスクリプションの認証情報を公開しないでください。
最終確認では証明書検証を有効にしたまま、同じノードで接続、接続先へのアクセス、切断後の再接続を続けて行います。エラーが解消し、実際のリクエストも正常に完了してはじめて今回の修正は完了です。基本項目については用語集をご覧ください。ネットワーク、プロキシ接続、カーネルのどこに問題があるか切り分けるには、技術リファレンスもご確認ください。