v2rayN、v2rayNG、v2flyNGでノードに接続する際のTLSハンドシェイクや証明書検証の問題を対象にしています。まずコアのログからタイムアウト、証明書の日付、ドメインの不一致を見分け、システム時刻、ノードアドレス、SNI、トランスポート設定、サーバー証明書チェーンを順に確認します。一度に変更する項目は一つに絞り、証明書検証は有効のままにしてください。TUNモードを有効にしても、ハンドシェイクの問題が一般的に解決するわけではありません。
1. まず失敗している段階を確認
TLSハンドシェイクは、安全な接続を確立する過程で行われ、通常は実際のデータ通信より前に発生します。ノード一覧で遅延を測定できても、TLS接続に成功したとは限りません。TCP接続テストで確認できるのは、ポートに到達できることだけの場合があり、証明書、認証、プロキシ転送が正常かどうかまでは分かりません。VMessとVLESSはプロキシプロトコル名、TLSはセキュリティ層の設定です。両者を混同しないでください。
v2rayNのメイン画面下部にあるログ欄で、接続失敗の前後の内容を確認します。Androidではサイドメニューから「ログ」を開けます。バージョンによって場所が異なる場合があるため、現在の画面を確認してください。古いログを消すか時刻を控えてから、一度だけアクセスを試します。サブスクリプションのダウンロードエラー、ノード接続エラー、接続先サイトのエラーを同じ障害として扱わないようにしましょう。
エラー：x509: certificate has expired or is not yet valid
原因：端末の時刻が証明書の有効期間外になっているか、サーバー証明書が実際に期限切れになっています。対処法：まず端末の時刻を同期し、ログに記録された現在時刻と証明書の有効期間を照合します。時刻が正しいのに解決しない場合は、ノードの管理者に証明書を確認してもらいましょう。
エラー：x509: certificate signed by unknown authority
原因：証明書チェーンが信頼されたルート証明書につながっていません。中間証明書の不足、自己署名証明書、ローカルでのHTTPS検査などが考えられます。対処法：システムの更新状況、ネットワーク環境、サーバーから送信される証明書チェーンを確認してください。検証を安易に無効にしないでください。
エラー：remote error: tls: handshake failure
原因：接続先がハンドシェイクを拒否しています。SNI、TLS設定、または入口サービスの設定が一致していない可能性があります。対処法：元のノード設定と照らし合わせてセキュリティ層とトランスポート方式を確認し、同じ時刻のサーバーログを管理者に調べてもらいましょう。
ログにi/o timeout、connection refused、EOFしかない場合、証明書が原因とは限りません。まずノードアドレスを名前解決できるか、リモートポートに接続できるか、そのポートでTLSサービスが実際に動作しているかを確認してください。最後の単語だけでなく、エラーの流れ全体を記録するほうが役立ちます。
2. システム時刻を合わせて再接続
証明書には有効期間が設定されています。端末の日付が前年になっていたり、古いスナップショットから仮想マシンを復元して時刻がずれていたりすると、有効な証明書でも「まだ有効ではない」または「期限切れ」と判定されることがあります。ノードの設定を変更する前に時刻を修正すれば、正しい設定を無駄に変更せずに済みます。
-
日付を確認
Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、年月日と現在時刻を確認します。タスクバーの時分だけで判断しないでください。
-
時刻を同期
「時刻を自動的に設定する」をオンにし、「その他の設定」の「今すぐ同期」をクリックします。同期に失敗する場合は、現在のネットワークから時刻サービスに接続できるか確認してください。組織管理の端末では、管理者の設定に従ってください。
-
Androidの時刻を確認
Androidでは通常、「設定」→「システム」→「日付と時刻」で「時刻を自動的に設定」と「タイムゾーンを自動的に設定」をオンにします。機種によっては「その他の設定」にあるため、設定内で「日付と時刻」を検索してください。
-
ログを取り直す
時刻を修正したら、クライアントの接続を停止して再起動し、もう一度アクセスします。日付に関するエラーが続く場合は、ログに記録された証明書の有効期間を確認し、ノードのトランスポート設定を次々に変更しないでください。
macOSでは「システム設定」→「一般」→「日付と時刻」で自動設定を確認します。Linuxでは、以下のコマンドで時刻と同期状態を確認できます。タイムゾーンは主に表示に関わる設定です。証明書の検証で比較されるのは絶対時刻なので、表示上のタイムゾーンを変更するだけでは、誤ったシステム時刻は直りません。
timedatectl status判断のポイント：まず時刻を確認し、その後でノードを変更
異なる提供元の複数のTLSノードで同時に証明書の日付エラーが出る場合は、まず端末の時刻を確認します。時刻が正しく、特定のノードだけ期限切れになる場合は、エラーが発生した時刻とノード情報を管理者に伝えてください。
3. サーバーアドレス、SNI、Hostを区別
v2rayNのノード一覧で対象ノードをダブルクリックし、編集画面の「アドレス」「ポート」と、TLS欄の「SNI」または「サーバー名」を確認します。v2rayNGとv2flyNGでは、ノード右側の編集メニューから該当する設定を確認できます。項目名はバージョンやプロトコルによって異なるため、画面例に合わせる目的でプロトコルを切り替えないでください。
| 項目 | 役割 | 確認方法 |
|---|---|---|
| サーバーアドレス | 接続先となるIPアドレスまたはドメインを指定 | サブスクリプションの元の値とDNSの名前解決結果を確認します。Webページのパスは付けません。 |
| リモートポート | サービスの待ち受けポートを指定 | サーバー側の設定に合わせて入力します。TLSを使うからといって、すべて443に変更する必要はありません。 |
| SNI / serverName | 通常、ハンドシェイク時にドメイン名を伝え、証明書の名前を検証するために使用 | 管理者から指定されたドメインを使い、その名前が証明書の対象に含まれていることを確認 |
| WebSocket Host | HTTPリクエストで仮想ホストを振り分け | リバースプロキシまたはCDNの設定に合わせます。SNIの代わりにはなりません。 |
| WebSocket Path | リクエストの転送先パスを指定 | 大文字・小文字と先頭のスラッシュを確認します。SNIには入力しません。 |
たとえば証明書にedge.example.netが含まれているのに、SNIにother.example.netを指定すると、名前が一致しないことがあります。SNIにはドメイン名だけを入力し、https://、ポート番号、/wsは付けません。ここに示したドメインは入力形式の例であり、接続可能なノードではありません。
サーバーアドレスにIPアドレス、SNIにドメイン名を指定する構成も、接続先の設定と証明書が一致していれば有効です。IPアドレスで接続する場合、正しい検証名が設定されていないと、クライアントはIPアドレスで証明書を検証することがあります。一般的なドメイン証明書には、そのIPアドレスが含まれていません。設定画面の「偽装ドメイン」は任意のドメインを入力してよい項目ではなく、HTTP HostとTLSサーバー名のどちらを指すのかを確認する必要があります。
4. 証明書チェーンとトランスポートのセキュリティ設定を確認
端末の時刻とSNIが正しい場合は、システムの信頼設定とサーバー証明書チェーンを確認します。古いシステムでルート証明書が更新されていなかったり、サーバーがサイト証明書だけを送信して中間証明書を送っていなかったりすると、検証に失敗することがあります。同じドメインのWebページをブラウザーで開けても、問題がないとは限りません。ブラウザーとプロキシコアでは、信頼ストアや証明書チェーンの補完方法が異なる場合があります。
- 1台の端末だけで失敗する：システムの日付、更新状況、管理対象のルート証明書ポリシーを確認します。許可されている別のネットワークでも再試行し、ネットワーク側のHTTPS検査が関係しているか切り分けてください。
- すべての端末で同じノードに接続できない：証明書の有効期限、証明書チェーン全体、ドメインの対象範囲、証明書更新後にサービスが再読み込みされているかを管理者に確認してもらいましょう。
- 最近トランスポート設定を変更した：TCP、WebSocket、gRPCとTLSの設定を再確認します。通常のHTTPポートにTLSハンドシェイクを送っている場合、SNIを変更しても解決しません。
- サブスクリプション更新後に再発した：ノードを手動で変更していないか確認します。更新によってローカルの変更が上書きされることがあります。更新のたびに手動で設定を直すのではなく、サブスクリプションの提供元に設定を修正してもらいましょう。
ログにREALITYの認証失敗が記録されている場合は、信頼できる提供元から設定全体を再インポートし、クライアントとコアがその設定に対応しているか確認します。セキュリティ方式をREALITYからTLSに変更して試したり、公開鍵を証明書のドメイン名として入力したりしないでください。
5. 証明書検証をスキップしてはいけない理由
ノード編集画面の「安全でない接続を許可」「証明書検証をスキップ」や、設定のallowInsecureは、サーバーの身元を確認する方法を変えます。通信が暗号化されていても、接続先が信頼できるとは限りません。証明書の誤り、接続先の間違い、接続のすり替えがあっても、本来表示される証明書の警告が出なくなるおそれがあります。
- 日付の誤りはシステム時刻を修正し、サーバー証明書の期限切れは証明書を更新します。期限切れを無視する設定にしてはいけません。
- ドメイン名が一致しない場合はSNIと証明書の対象範囲を確認します。検証を無効にしたまま使い続けないでください。
- 自分で運用するサーバーで独自の信頼設定が必要な場合は、証明書の配布方法と信頼範囲を十分に理解したうえで設定してください。出所不明のルート証明書はインポートしないでください。
- 切り分けのために一時的にこの設定を変更した場合は、検証を有効に戻して再テストし、最終設定で正常に接続できることを確認してください。
システムプロキシやTUNモードを有効にすると、通信をプロキシに流す方法が変わりますが、通常、ノード自体の証明書エラーは解決しません。エラーがサブスクリプションURLへのHTTPS接続で起きている場合は、サブスクリプションのドメイン名と更新時のネットワークを確認してください。これは現在のノードとのTLSハンドシェイクとは別の接続です。ノードのSNIを変更しても、サブスクリプションサイトの証明書エラーは解決しません。
6. よくある質問とトラブル時の記録
時刻を同期しても証明書が期限切れと表示されます
再接続して新しいログを確認し、古い記録ではないことを確かめます。システムの日付が正しく、エラーに表示された有効期限が過ぎている場合は、ノードの管理者に証明書の更新と関連サービスの再読み込みを依頼してください。端末のタイムゾーンを変更し続ける必要はありません。
サブスクリプションのSNI欄が空欄です。入力が必要ですか？
まず、サーバーアドレスがドメイン名かどうかと、現在のコアがそこからサーバー名を自動判定するかを確認します。空欄でも必ずしも誤りではありません。ログに名前の検証失敗が明記されている場合は、必要なSNIを管理者に確認してください。他のノードのドメイン名を流用してはいけません。
スマートフォンでは接続できるのに、パソコンでは接続できません。何から確認すればよいですか？
まず両方の端末でノードアドレス、ポート、SNI、セキュリティ方式、トランスポート設定を比較し、次にパソコンの時刻とシステムの信頼設定を確認します。元の設定を残し、一度に変更するのは1項目だけにしてください。Androidで接続できるからといって、デスクトップ版のコアや設定との互換性を見落とさないようにしましょう。
管理者に問い合わせるとき、どんな情報を伝えるとよいですか？
クライアントとコアのバージョン、エラーが起きた時刻、前後の文脈を含むエラー全文を伝えます。時刻を同期したか、すべてのノードで失敗するかも添えてください。サブスクリプションURL、UUID、パスワード、認証情報は伏せてください。設定全体をそのまま送るのは避けましょう。
最後に、同じノードと接続先で再テストし、新しいログに同じエラーが出ないことを確認してから、通常のルーティング設定に戻します。まだ失敗する場合は、「何を変更したか」「エラーがどう変化したか」を簡潔に記録してください。証明書の日付エラーが接続タイムアウトに変わった場合は新たな手がかりです。同じ証明書対策を繰り返す必要はありません。