TLSハンドシェイクと証明書エラーの対処法：システム時刻・SNI・検証スキップの判断

TLSハンドシェイクはどの段階で失敗するのか

TLSはTCP接続の確立後、プロキシプロトコルが実際のデータを交換する前に位置します。TLSを使用するVMessまたはVLESSノードでは、まずクライアントがサーバーアドレスを解決してリモートポートへ接続します。一般的なポートは443です。続いてClientHelloを送信し、そこにはSNI、対応するTLSバージョン、ALPNなどが含まれる場合があります。サーバーが証明書チェーンを返すと、本体のシステムが証明書の有効期間、発行関係、名前を確認し、検証に成功して初めて暗号化セッションが確立されます。

そのため、「遅延テストに失敗した」ことをそのまま「ノードが使えない」と判断することはできません。DNS解決の失敗、TCPポートに接続できない、TLS証明書の検証失敗、プロキシプロトコルのパラメータエラーは、いずれもテスト結果をタイムアウトや利用不可にしますが、問題の箇所はそれぞれ異なります。まずログに記録された最初の明確なエラーを確認し、変更するパラメータを決めるほうが、ノードを何度も切り替えるより効果的です。

リモートアドレスへ接続する前にログへ「no such host」と出る場合は、まずDNSまたはアドレスの入力ミスを確認します。x509、certificate、handshakeなどのキーワードが出ている場合に、証明書とTLSの確認へ進みます。TLS完了後にinvalid user、authentication failed、protocol responseなどが出るなら、問題はUUID、パスワード、プロトコル種別、通信設定にあり、証明書が原因ではありません。

ログの原文から証明書エラーを特定する

v2rayN 7.xでは、まずメイン画面下部のログ欄でカーネルの出力を確認し、「設定」→「パラメータ設定」でログレベルが低すぎないことを確認します。テスト時は現在のカーネルを停止してから再起動し、HTTPSページへアクセスすると、古いログの影響を減らせます。ノードはサーバー一覧で右クリックし、「サーバーを編集」を選択してTLSとSNIの項目を確認します。

Androidでも、まず現在の設定を確認します。v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用します。両者の証明書の有効期限とホスト名に関する基本的な検証原則は同じですが、ログの表現には多少の違いがあります。「起動に失敗しました」という最後の1行だけを切り取らず、上へさかのぼって最初に現れたx509、tls、certificateの記録を探してください。

EOF、connection reset by peer、unexpected EOFは、通常、接続が途中で閉じられたことを示しますが、それだけで証明書エラーだとは限りません。同じノードがモバイル回線では使えるのに固定回線でリセットされ続ける場合は、DNSの結果、IPv4とIPv6の経路、リモートの443ポートへTCP接続できるかを優先的に比較してください。

curl -vI --connect-timeout 8 https://node.example.net/

openssl s_client \
  -connect node.example.net:443 \
  -servername node.example.net \
  -showcerts

上記のコマンドは、通常のTLSサイトに対するハンドシェイクを個別に確認するためのものです。実行時は、例示のドメイン名をノード設定で指定された証明書のドメイン名に置き換えてください。OpenSSLの出力にあるsubject、issuer、証明書の開始・終了時刻、Verify return codeは、名前、期限、証明書チェーンの問題を切り分けるのに役立ちます。ただし、プロキシサービスが特定のPathやアプリケーション層プロトコルを要求する場合、通常のHTTPSリクエストが失敗しただけではプロキシ入口が利用できないとは断定できません。

システム時刻とタイムゾーンの確認方法

証明書には有効開始時刻と有効期限が含まれており、本体は自身の時計で現在時刻がその範囲内にあるかを判断します。日付が正しくてもタイムゾーンが間違っていると、表示上の時刻は近く見えても実際のUTC時刻が数時間ずれることがあります。デュアルブート、マザーボードの電源断、仮想マシンの一時停止からの復帰、自動時刻合わせの無効化などがよくある原因です。

1. Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にしてから、「今すぐ同期」をクリックします。
2. macOSでは「システム設定」→「一般」→「日付と時刻」を開き、日付と時刻の自動設定を有効にして、現在地のタイムゾーンを確認します。
3. Androidでは「設定」→「システム」→「日付と時刻」を開き、ネットワークから提供された時刻とタイムゾーンを有効にします。システムによってメニュー名が多少異なる場合があります。
4. Linuxではtimedatectl statusを使ってUniversal time、RTC time、Time zone、System clock synchronizedを確認し、必要に応じてtimedatectl set-ntp trueを実行してネットワーク時刻同期を有効にします。
5. 同期が完了したらクライアントを完全に終了し、カーネルを再起動します。古い接続で遅延テストを繰り返すだけでは不十分です。

トラブル対処では、目視ではなくずれの量を記録してください。本体の時刻が正確な時刻より24時間進んでいると、有効期間内の証明書でも期限切れと判定されることがあります。24時間遅れていると、新しく発行された証明書がまだ有効でないと判定される可能性があります。一部の環境ではハンドシェイク時のわずかな時刻差が許容されますが、数分の余裕を安定した基準と考えてはいけません。

SNI、アドレス、Host、証明書名の関係

ノードの「アドレス」はDNS解決とTCP接続に使われ、SNIはTLSのClientHelloでクライアントがアクセスしたい名前をサーバーへ伝えます。また、カーネルが証明書名を検証する際にも使われることがあります。両者は同じ場合もあれば、入口の構成によって異なる場合もあります。正しい値は有効なサブスクリプションまたはサーバー設定から取得し、ノードのメモだけを根拠に推測してはいけません。

WebSocket設定にはHostリクエストヘッダーが含まれる場合もあります。HostはTLS確立後のHTTP層、SNIはTLSハンドシェイク層に属します。両方に同じドメイン名を入力することが多くても、完全に同じものではありません。gRPCにはserviceNameも関係し、REALITY設定ではserverName、publicKey、shortIdが同時に関係する場合があります。これらの項目はそれぞれ異なる役割を担います。

v2rayNでは対象ノードを右クリックして「サーバーを編集」を選び、まずセキュリティタイプがTLSになっていることを確認してからSNIを確認します。サブスクリプションの更新後に手動変更が上書きされた場合は、更新のたびに値を変更し直すのではなく、サブスクリプショングループへ戻って元のデータを確認してください。VLESS REALITYでは、一般公開証明書の対処方法をそのまま当てはめてはいけません。ただし、serverName、システム時刻、各パラメータを一式で一致させることは重要です。

証明書チェーンの不備とネットワーク中間装置

サーバーは通常、サイト証明書と必要な中間証明書を送信し、クライアントがシステムまたはカーネルの信頼ストアにあるルート証明書を使って検証します。サーバーがサイト証明書だけを送信している場合、中間証明書をキャッシュ済みの端末では一時的に使えても、新しい端末ではunknown authorityが表示されることがあります。「一部の端末では正常」という事実だけで、サーバーのチェーン設定が完全だとは判断できません。

同じ端末で固定回線とモバイル回線をそれぞれテストします。特定のネットワークだけで失敗する場合は、DNSの解決結果を比較し、ドメインが異なる入口へ解決されていないか確認します。すべてのネットワークと複数のプラットフォームで同じ時刻に同じ証明書チェーンエラーが出るなら、サーバー設定に問題がある可能性が高くなります。企業プロキシ、HTTPS検査装置、独自証明書の環境によって、実際に受け取る発行チェーンが変わる場合もあります。

• openssl s_client -showcertsを使い、サーバーが実際に送信した証明書の枚数と発行関係を確認します。
• 出力末尾の検証結果を確認し、最初の証明書のドメイン名だけを見て判断しないでください。
• ノードのアドレスと設定上のSNIをそれぞれ使ってテストし、2回の接続で異なる証明書が返されるか確認します。
• v2rayN、v2rayNG、v2flyNGのカーネルを終了して再起動し、古いセッションが再利用されていないことを確認します。
• サーバーから中間証明書が送信されていない場合は、各クライアントで検証を回避するのではなく、サーバー側に完全な証明書チェーンを設定します。

証明書検証のスキップは短時間の切り分けに限る

v2rayNと関連カーネルの設定にあるallowInsecureは、証明書検証に失敗してもTLS接続を継続することを意味します。期限切れの証明書、誤ったSNI、不足している中間証明書を修復するものではなく、該当する検証結果を回避するだけです。接続が復旧しても、問題箇所が証明書検証段階にある可能性を示すだけで、現在のパラメータが正しいとは限りません。

この項目は、条件を管理した比較テストに一度だけ使用します。アドレス、ポート、プロトコル、通信方式、ルーティングを変えず、証明書検証の設定だけを切り替えます。カーネルを起動して1回リクエストを実行したら、検証を元に戻し、元のログに基づいて時刻、SNI、証明書チェーンを修正します。SNI、Host、ポート、allowInsecureを同時に変更すると、テスト結果から判断できなくなります。

1. 元のノードをコピーして保存し、現在のallowInsecureの状態を記録する。
2. テスト対象の出所が明確で、ほかの接続パラメータを同時に変更していないことを確認する。
3. 一時的に有効化してカーネルを再起動し、元のx509エラーが消えるか確認する。
4. それでもタイムアウトする場合は、DNS、TCPポート、通信方式、サーバーの状態を引き続き確認する。
5. 接続が復旧したら、すぐに証明書検証を元へ戻し、システム時刻、SNI、完全な証明書チェーンを修正する。

検証を長期的にスキップすると、リモートの身元を確認する重要な手段を失います。特にノードアドレスがDNSによって複数の入口へ向けられている場合、クライアントは証明書名と発行チェーンで、接続先が想定したサービスかどうかを判断できなくなります。サブスクリプションの項目をサーバー設定と一致させ、システムの信頼ストアと時刻同期を正常に保つほうが安全です。

再現可能な最終トラブル対処手順

証明書の問題は、複数のパラメータを同時に変更すると原因の手がかりを失いやすくなります。実際の作業ではノードとネットワークを固定し、時刻を記録して、ログに出た最初の低レベルエラーを基準にします。各手順の後にカーネルを再起動し、同じリクエストを繰り返してこそ、結果を比較できます。

1. システム時刻を確認：日付、タイムゾーン、ネットワーク時刻を同期し、ずれを数分や数時間ではなく秒単位まで縮めます。
2. 解決結果を確認：ノードのドメインを解決できるか確認し、IPv4とIPv6が想定した入口を指しているか判断します。
3. TCPポートを確認：サブスクリプションに記載された443、8443などの明示的なポートを確認し、自己判断で置き換えないでください。
4. TLSの有効化を確認：ノードがTLSを要求する場合は必ず有効にし、非TLSの入口へTLSを無理に適用しないでください。
5. SNIを確認：サブスクリプションで指定された証明書名を使い、ノードアドレス、メモ、Host、serviceNameを区別します。
6. 証明書の有効期間を確認：現在のUTC時刻と証明書の開始・終了時刻を比較し、本体の時計が原因かサーバー証明書の期限切れかを判断します。
7. 証明書チェーンを確認：サーバーが必要な中間証明書を送信しているか確認し、複数のプラットフォームで比較します。
8. 通信パラメータを確認：WebSocketのPathとHost、gRPCのserviceName、REALITYの関連項目が一式で一致していることを確認します。
9. 短時間の比較検証：切り分けの段階に限ってallowInsecureを切り替え、テスト終了後は証明書検証を元に戻します。
10. 元のサブスクリプションへ戻る：手動変更が増えすぎた場合は正しいグループを再インポートし、テスト設定を1つだけ残します。

ここまで確認すると、エラーは通常、次の3つに明確に分類できます。本体の時刻または信頼環境の異常、ノードの項目と入口の不一致、サーバーの証明書または待受設定の異常です。1つ目だけは本体側ですぐ修正できます。2つ目は正しいサブスクリプションのパラメータへ戻し、3つ目はサーバー側で証明書の更新、証明書チェーンの補完、入口設定の修正が必要です。