v2rayNGで通常のTLSを使うノードが対象です。まずログで証明書検証エラーと接続タイムアウトを区別し、Androidの自動時刻、ノードのサーバー名、証明書チェーンを確認します。v2rayNでの確認箇所や、証明書検証のスキップを恒久的な対処にすべきでない理由も解説します。REALITYを使うノードは専用の認証パラメーターを確認してください。通常のTLSの証明書対処をそのまま適用することはできません。
1. ログを開き、失敗した段階を確認する
v2rayNGのメイン画面でサイドメニューを開き、「ログ」を選択します。現在時刻を記録し、メイン画面に戻って接続を停止してから、同じノードで接続を開始し、Webページへのリクエストを1回送信します。ログに戻り、この操作後に追加されたエラーを確認してください。メニューの配置はバージョンによって異なる場合があります。「ログ」の項目を探してください。
最後の failed to process outbound traffic だけを切り取らないでください。これは上位レイヤーの要約であることが多く、実際の原因は x509、tls、dial tcp の後に続く場合があります。接続先から最も内側の原因まで、エラーの一連の流れを保存しましょう。時刻や設定項目を変更すべきか、サーバー管理者に問い合わせるべきかを判断できます。
この流れは、通常のTCP上でTLSを使うノードを想定しています。connection refused や i/o timeout が出る場合、証明書を受け取る前の段階で失敗している可能性があります。x509 エラーなら、通常は証明書の検証段階まで進んでいます。遅延テストに数値が表示されても、TLS検証に成功したとは限りません。特にTCP接続だけを確認するテストでは注意が必要です。
2. まずAndroidの日付と時刻を同期する
Androidの「設定」→「システム」→「日付と時刻」を開き、「日時を自動設定」と「タイムゾーンを自動設定」を有効にします。機種によっては「詳細設定」や「一般管理」にあります。設定内で「日付と時刻」を検索しても見つけられます。設定後、v2rayNGに戻り、接続を停止してから再起動し、コアにハンドシェイクをやり直させます。
- 日付と年を確認：長期間電源を切っていたり、時刻を手動で変更したりすると、端末の時刻が証明書の有効期間外になっていることがあります。わずかなずれでも問題になる場合があり、更新直後の証明書は数分の差で有効期間前と判定されることがあります。
- 時刻が同期済みか確認：設定を有効にしただけでは、同期が成功したとは限りません。端末が正常にネットワークへ接続できていることを確認し、システムに表示される日付と現在時刻を照合してください。
- ログに記録された2つの時刻を確認：有効期間のエラーには、クライアントの現在時刻と証明書の開始・終了時刻が含まれることがあります。現在時刻が明らかに誤っていれば、まず端末を修正します。正しいのに証明書の期限が切れている場合は、サーバー側で更新が必要です。
タイムゾーンは画面上の時刻表示に影響しますが、証明書の検証では実際の時刻が比較されます。タイムゾーンを別の地域に切り替えるだけでは、通常、システム時計のずれは直りません。期限切れの証明書を一時的に通すために日付を戻さないでください。サブスクリプションの取得やほかの安全な通信にも影響します。
3. サーバーアドレス・SNI・転送時のHostを照合する
v2rayNGのノード一覧で対象ノードの編集アイコンをタップし、「アドレス」「ポート」「TLS」「SNI」または「サーバー名」の項目を確認します。WebSocketを使う場合は、「Host」と「パス」も確認してください。保存前に元の設定を控えておきます。サブスクリプションのノードは複製して比較すれば、試した変更がすべてのノードに上書きされるのを防げます。
| 項目 | 役割 | 確認方法 |
|---|---|---|
| アドレスとポート | 接続先のサービスを指定する | ノードの提供元が示す値を入力します。証明書エラーを理由にポートを変更しないでください。 |
| SNI / serverName | TLSのサーバー名を通知し、通常は証明書名の検証にも使われる | 提供元が指定する名前を入力します。証明書にその名前が含まれている必要があります。 |
| WebSocket Host | HTTPリクエストやリバースプロキシのサイト振り分けに使う | 転送設定と照合してください。証明書検証の切り替え項目ではありません。 |
| WebSocketパス | リバースプロキシの転送先サービスを指定する | 先頭のスラッシュ、大文字・小文字、パス全体を確認してください。 |
「偽装ドメイン」は、項目名として十分に正確ではありません。SNIとHTTP Hostの両方をそう呼ぶ説明もありますが、使われるレイヤーは異なります。両者が同じ場合も、サーバー構成に応じて別々に設定する場合もあります。項目ごとに確認し、ドメイン名が2つあるからといって無理に一致させないでください。
ノードアドレスにIPアドレスを設定していて、証明書にドメイン名しか含まれていない場合は、検証に正しいサーバー名が必要です。IPアドレス自体が証明書に含まれている場合に限り、IPアドレスでの検証が通る可能性があります。SNIには通常、ホスト名だけを入力します。https://、ポート、パスは付けません。空欄の場合の動作はコアやノードの種類によって異なるため、推測に頼らないでください。
ポートが443でも、正しいTLSサービスが有効とは限りません。誤ったリバースプロキシの入口に接続すると、別サイトの証明書が返される場合もあります。VMessとVLESSはプロキシプロトコル、TLSは通信を保護するレイヤーです。VMessをVLESSに変更するだけでは、証明書名の誤りは解消しません。
4. エラーの原文から証明書とサーバーの問題を見分ける
以下のエラー断片は、より長いエラーの途中に含まれる場合があります。前後の表示形式はコアのバージョンによって変わります。最も具体的なエラーに対応してください。「ハンドシェイク失敗」という言葉だけで変更内容を決めないようにしましょう。
エラー：x509: certificate has expired or is not yet valid
原因：現在時刻が証明書の有効期間外です。対処：まず端末の時刻を同期します。時刻が正しい場合は、サーバー管理者に実際に配信されている証明書の期限と、更新後に再読み込みされたかを確認してもらってください。
エラー：x509: certificate signed by unknown authority
原因：検証側で信頼できる証明書チェーンを構築できません。中間証明書が不足しているか、信頼されていない認証局が使われている可能性があります。対処：サーバー管理者に証明書チェーン全体を確認してもらいます。独自に管理する環境に限り、検証済みの信頼できる証明書をコアの対応方法に従って設定してください。
エラー：x509: cannot validate certificate for
原因：後ろに because it doesn't contain any IP SANs と表示される場合、IPアドレスで検証しているものの、証明書に対応するIPアドレスの項目がありません。対処：提供元が指定するサーバー名を確認し、接続先のIPアドレスをSNIに入力しないでください。
エラー：remote error: tls: handshake failure
原因：接続先がハンドシェイクを拒否しています。SNI、TLSパラメーター、サーバー側のポリシーなどが関係している可能性があり、この1行だけで証明書の期限切れとは判断できません。対処：まずサブスクリプションの元の設定に戻し、サーバー管理者に同時刻のサーバーログと照合して拒否理由を確認してもらってください。
エラー：tls: first record does not look like a TLS handshake
原因：接続先からTLSレコードではないデータが返されています。平文のサービスや誤ったポートに接続している場合によく起こります。対処：ポートと通信のセキュリティ方式を確認し、その接続先が実際にTLSを提供しているかを確かめてください。TLSを無効にして試すのは避けてください。
時刻とサーバー名が正しく、同じノードで異なるネットワークでも同じ証明書エラーが出る場合は、サーバー側の証明書設定が原因である可能性が高くなります。一方、特定のWi-Fiだけで失敗する場合は、まずそのネットワークの認証を済ませ、ネットワーク側で通信が遮断されていないか確認してください。ブラウザーでHTTPSページを開けても、ノードのコアが同じ証明書チェーンを受け取っている証明にはなりません。
5. allowInsecureは無効のままにし、TLSとREALITYを分けて確認する
ノードの編集画面に戻り、「証明書検証をスキップ」「安全でない接続を許可」、または allowInsecure に相当する項目を探します。通常は無効のままにしてください。この設定はサーバーの身元確認を緩めるだけで、証明書チェーンの不足を補ったり、証明書を更新したり、誤った通信の接続先を正したりするものではありません。
{
"tlsSettings": {
"allowInsecure": false
}
}これは通常のTLS設定にある一部項目の例で、インポート可能な完全なノード設定ではありません。GUIでは該当するスイッチを変更してください。この内容を設定ファイル全体に貼り付けて上書きしないでください。検証をスキップして一時的に使えるようになっても、想定したサーバーに接続できているとは限りません。
- 通常のTLS：有効期間、サーバー名、証明書チェーン、信頼元を重点的に確認します。修正後は証明書検証を有効にした状態で使用してください。
- REALITY：ノードの提供元が指定するサーバー名、認証用公開鍵などの認証情報、shortIdといったパラメーターを確認します。画面上の項目はバージョンによって異なるため、元のサブスクリプションと現在のクライアントを基準にしてください。
- プロトコルの対応状況：v2rayNGはXrayコアを、v2flyNGはv2flyコアを使用します。後者が前者のREALITY設定にそのまま対応するとは限りません。
6. 保存後は変更を1つに絞り、全体を確認する
一度に変更する項目は1つだけにします。時刻、サーバー名、証明書チェーンの順に確認してください。ノードを保存したら接続を停止して再起動し、リクエストを再送して新しいログを確認します。DNS、ルーティング、ポート、TLSの設定を同時に変更すると、接続が復旧しても何が効いたのか分からなくなります。
- 元のノード設定を保存し、クライアントとコアのバージョン、エラー発生時刻を記録しておくと、問題を再現しやすくなります。
- 証明書検証を有効にしたまま、以前失敗した接続先にアクセスし、キャッシュされたページではないことを確認してください。
- 新しいログに同種の
x509またはtlsエラーが残っていないか確認します。遅延の測定結果だけで判断しないでください。 - サブスクリプションの更新後、設定項目をもう一度確認してください。手動で修正した内容が上書きされる場合は、サブスクリプションの管理者に元の設定を修正してもらいます。
デスクトップでv2rayNを使う場合は、ノードをダブルクリックして編集画面を開き、TLSのサーバー名と「安全でない接続を許可」の設定を確認します。コアの出力はログ欄またはログウィンドウで確認してください。Windowsでは「設定」→「時刻と言語」→「日付と時刻」から時刻を同期できます。メニュー名はバージョンによって異なりますが、時刻、証明書名、信頼チェーンを確認する原則は変わりません。
7. TLS証明書のトラブル対処に関するよくある質問
時刻は自動同期済みなのに、証明書の期限切れと表示されるのはなぜですか？
まず、エラーに記録された現在時刻が正しいか確認してください。正しい場合は証明書の有効期限を確認します。サーバー側で証明書ファイルを更新していても、リバースプロキシが古い証明書を読み込んだままの場合があります。スマートフォンの日付を変更し続けるのではなく、エラー発生時刻を管理者に伝え、実際にリッスンしている接続先を調べてもらってください。
SNIとWebSocketのHostには、同じドメイン名を設定する必要がありますか？
必ずしも同じではありません。SNIはTLSレイヤーで使われ、HostはHTTPのルーティングに使われます。ノードの編集画面で、提供元が示す元の設定とそれぞれ照合してください。明確な設定根拠がない場合、一方の項目で他方を上書きしないでください。
証明書検証をスキップすると接続できます。このまま有効にしてもよいですか？
おすすめしません。まず設定を無効に戻し、エラーに応じて端末時刻、サーバー名、証明書チェーンを確認してください。検証を無効にしないと接続できない場合は、長期的に身元確認を回避するのではなく、管理者に証明書の修正や明確な信頼設定を依頼してください。
ノードには接続できますが、サブスクリプションの更新時だけ証明書エラーが出る場合はどうすればよいですか？
サブスクリプション取得時のHTTPSリクエストと、ノードのTLSハンドシェイクを切り分けてください。これは別々の接続で、ネットワーク経路や信頼の仕組みも異なる場合があります。サブスクリプションURLが有効か、端末時刻が正しいかを確認し、更新時のエラーを調べてください。ノードのSNIを変更しても、通常、サブスクリプションサーバーの証明書エラーは解消しません。
DNSを変更すれば、すべてのTLSハンドシェイク失敗を解決できますか？
いいえ。DNSが重要な手がかりになるのは、名前解決に失敗した場合や誤った接続先に解決された場合です。証明書の期限切れや名前の不一致が明確な場合は、該当する設定を優先して修正してください。独自のルーティングを使っている場合は、テストのリクエストが調査対象のノードを実際に経由しているかも確認しましょう。