VPN接続が有効かどうかは、まず出口IPを確認し、次にDNSの名前解決経路を調べ、最後に対象アプリで動作を確かめます。クライアントの「接続済み」は確認の出発点にすぎません。対象の通信が想定どおり選択した回線を経由して、はじめてその通信にVPNが反映されたと判断できます。

ウェブページが開く、ステータスアイコンが点灯する、クライアントの通信量が増えるといった点だけで判断しないでください。キャッシュでページが一時的に表示されたり、バックグラウンド更新で通信が発生したりする場合があります。以下では接続前後の比較から確認します。最初にプロトコルを変えたり、クライアントを再インストールしたりする必要はありません。

接続状態と実際に有効な状態の違い

「接続済み」の意味はクライアントによって異なります。システムのトンネル確立を示すものもあれば、ローカルプロキシの起動を示すもの、リモートサーバーへの疎通まで確認するものもあります。ステータスが正常でも、ブラウザーやチャットアプリなど、すべてのアプリがプロキシ経由とは限りません。

特に「システムプロキシ」と「トンネルモード」は区別が必要です。システムプロキシは、主にシステムのプロキシ設定に従うアプリで利用されます。設定を参照しないアプリは、直接接続を続ける場合があります。トンネルモードはより多くの通信を処理できますが、ルーティング、除外アプリ、DNS設定、システム権限などにも左右されます。モード名だけで判断しないでください。

確認結果は複数の項目を組み合わせて判断し、単独のサインから全通信の状況を結論づけないようにしましょう。
確認項目 確認できること それだけでは確認できないこと
クライアントに「接続済み」と表示される 接続またはローカルでの通信処理が開始されたこと。具体的な意味はクライアントによって異なる すべてのアプリがリモート出口を利用していること
IP確認ページで出口IPが変わった 今回の確認リクエストが別の出口を利用したこと ほかのサイト、プロトコル、アプリも同じ経路を使うこと
DNSチェックに表示される名前解決サービス テスト対象ドメインの名前解決リクエストが、最終的にどのDNSサービスで処理されたか DNSリゾルバーの所在地と、実際のアクセスに使う出口の所在地が同じであること
対象アプリのプロキシログが表示される 該当リクエストが記録されたルールとアウトバウンドを利用したこと リモートのサービスが現在のアカウントや地域を必ず受け入れること
対象の機能が実際に動作した 現在のアプリ利用シーンで通信できること すべての通信が処理されること、または今後も常に利用できること

出口IP:接続前後を比較する

まず接続を一時停止し、同じブラウザーでIP確認ページを開いて、表示されたグローバルIPアドレスと地域を記録します。次に選択した回線へ接続し、もう一度確認して結果を比べます。ネットワークの切り替えによる変化をVPNの効果と誤認しないよう、端末・ブラウザー・ローカルネットワークはできるだけ同じ条件にしてください。

  1. 接続前の出口情報を記録し、クライアントの現在の通信処理モードも控えておきます。
  2. 接続後、選択した回線と想定する地域が合っているか確認し、確認ページを再度開きます。結果がキャッシュの可能性がある場合は、ページを閉じてから開き直してください。
  3. 出口が変わった場合は、地域が想定どおりか確認します。変化がない場合は、まず確認サイトがルールで直接接続に指定されていないか調べましょう。
  4. ルールや通信処理モードを変更したら、再度確認します。設定は一度に一つだけ変更し、結果を説明できるよう変更前後を記録してください。

IPアドレスの位置情報データベースには更新の遅れがあり、確認サービスによって表示される都市が異なることもあります。回線名やIPアドレスの割り当て先とデータベース上の地域が一致しなくても、すぐに回線の障害と判断しないでください。まずグローバルIPが変わったか確認し、クライアントのリクエストログも併せて、どのアウトバウンドが使われたか調べましょう。

確認ツールでIPv4とIPv6を個別にチェックできる場合は、それぞれが想定するルートを通っているか確認します。一方のアドレスファミリーが処理されていないと、それに対応するアプリが別の経路を選ぶ可能性があります。まずクライアントの対応状況とルーティングポリシーを確認し、システム機能を恒久的に無効化することを標準的な対処にしないでください。

DNS:所在地だけでなく名前解決の経路を確認

DNSはドメイン名をIPアドレスに変換します。一般にDNSリークとは、プライバシーやルーティングの方針に従って処理されるはずの名前解決リクエストが、ローカルネットワークのDNSサービスなど別の経路へ送られる状態を指します。確認する前に、すべての名前解決をトンネル経由にするのか、直接接続するドメインではローカルDNSを許可するのか、想定する設定を明確にしましょう。

接続した状態で、DNSサービスの情報を表示できるチェックツールを実行し、結果をクライアントの設定と照らし合わせます。ローカルネットワークの事業者が提供するDNSサービスが表示された場合は、ルールによる振り分けの設計に沿っているか確認してください。通常、確認できるのはテスト対象のドメインに関係するリゾルバーだけで、端末上の全アプリのDNS動作を一覧できるわけではありません。

DNSサービスが別の地域にあるからといって、必ずしもリークとは限りません。パブリックDNSは分散配置されている場合があり、IPアドレスの登録地域、実際の処理場所、出口IPの地域が一致しないことがあります。逆に、リゾルバーの地域が想定どおりでも、すべてのアプリの通信がプロキシ経由とは限りません。

ブラウザーのセキュアDNSとシステムの名前解決は異なる場合がある

ブラウザーのセキュアDNSは、暗号化された接続で指定のDNSサービスに問い合わせることができます。この接続もプロキシやルーティングの方針に影響されますが、クライアントで指定したシステムDNSが使われるとは限りません。ブラウザーのチェック結果だけではシステム全体の確認にならず、システムの問い合わせ結果だけでブラウザーの動作を判断することもできません。

コマンドラインツールの nslookup は、システム環境での名前解決結果を確認する補助になりますが、DNSリークを網羅的に検査するツールではありません。クライアントによっては合成アドレスやリモート名前解決を使うため、表示されたアドレスがウェブサイトの最終的なサーバーアドレスとは限りません。クライアントの説明も併せて確認してください。

アプリごとの動作確認:ブラウザーで使えても、すべてのアプリで使えるとは限らない

実際に利用したいアプリを選び、それぞれで新しい通信を発生させ、クライアントのログに該当するドメイン、プロセス、接続が記録されているか確認します。リクエストが直接接続・プロキシ・拒否のどのルールに一致し、最終的にどのアウトバウンドが選ばれたかを確認してください。ログ項目はクライアントによって異なるため、まったく同じ画面名を探す必要はありません。

Windows・macOS・Linux

PCでは、まずシステムプロキシが有効か、アプリ独自のプロキシ設定が使われているかを確認します。ターミナルのツールはプロキシ環境変数を参照する場合もあれば、デスクトップのシステム設定を無視する場合もあります。ブラウザー拡張機能の影響がブラウザー内に限られることもあります。トンネルモードでは追加の権限が必要な場合があるため、許可が完了していないときはクライアントの案内に従い、仮想ネットワークインターフェースが正常に作成されているか確認してください。

Android・iOS

モバイルでは、システムがVPN接続を許可しているか、ネットワークを処理する別のツールが動作していないか確認します。Androidのクライアントには、アプリを処理対象に含める、または除外する設定がある場合があります。iOSでどこまで通信を処理できるかは、クライアントの実装やシステム設定によって異なります。バックグラウンドに移行してから切断する場合は、前面のアイコンだけで判断せず、クライアントのログとバックグラウンド動作の制限を確認してください。

対象のプラットフォームに地域が対応していないと表示されても、すぐにDNSが原因と決めつけないでください。プラットフォームは出口IPだけでなく、アカウントの地域、過去のセッション、独自のポリシーを参照する場合があります。通信経路の確認でわかるのは、リクエストが想定どおり送信されたことまでで、対象サービスの利用可否を保証するものではありません。

接続しても反映されない場合:症状から原因を絞り込む

すべてのアプリで問題が起きる

まず接続を一時停止し、ローカルネットワーク自体が使えるか確認します。次に、サブスクリプションが正常に読み込まれているか、アカウントの状態や通信量に問題がないか、選択した回線が現在のサブスクリプションに含まれているかを調べます。サブスクリプションリンクは、クライアントが回線設定を取得するためのものであり、接続成功の証明ではありません。更新後も実際に接続して確認し、サブスクリプションリンク全体を公開ページに掲載しないでください。

ブラウザーは使えるが、ほかのアプリは使えない

まずシステムプロキシの適用範囲、アプリ独自のプロキシ設定、除外リストを確認します。切り分けのため、クライアントで利用できるより広い通信処理モードを一時的に使うと、対象範囲の問題か判断しやすくなります。テスト後は日常利用に適した振り分け設定に戻しましょう。すべてのリクエストを長期間同じ経路に通す必要はありません。

回線を変更しても、アプリに以前の地域が表示される

まず出口IPを再確認し、対象アプリの古い接続を終了してから試します。アカウントの地域、ページキャッシュ、サービス側のセッションは、出口を変えてもすぐに更新されない場合があります。サイトデータを消去するとログイン状態に影響するため、必要性を確認してから行ってください。キャッシュの削除を何度も繰り返すことは、回線のトラブルシューティングの中心的な手順ではありません。

ウェブページは開くが、画像やリアルタイム機能が動かない

一つのアプリが複数のドメインに接続し、異なる通信方式を使うことがあります。トップページがプロキシ経由でも、画像用ドメインやリアルタイム接続に同じルールが適用されるとは限りません。操作が失敗したときのログを確認し、ドメインルール、アウトバウンド、対象通信へのクライアントの対応状況を調べてから、回線を切り替えるか判断しましょう。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどは、それぞれ異なるプロキシプロトコルや方式を示す名称です。プロトコル名だけでは、システムで処理される通信の範囲やDNSの経路はわかりません。同様に、直接接続・中継・IEPL専用線は回線の構成を示すもので、端末上で接続が反映されているかの確認に代わるものではありません。VPNBackで選択できる回線は、回線一覧とクライアントの現在の設定をご確認ください。

あとから確認できる記録を残す

トラブルシューティングでは、端末のOS、クライアント名、通信処理モード、選択した回線、接続前後の出口情報、問題が起きたアプリと具体的な操作を記録します。ログは必要な部分だけ抜き出し、共有前にアカウント情報、アクセストークン、サブスクリプションURLを隠してください。サポートが必要な場合は、こうした状況をカスタマーサポートにお知らせいただくと、「接続済みなのに使えない」という情報だけの場合より原因を特定しやすくなります。

まとめ:出口IP、名前解決、アプリの動作を照らし合わせて、接続が有効か確認しましょう。

出口IPは現在のリクエストの経路確認に、DNSチェックは名前解決の方針確認に、アプリの操作とログは通信処理の範囲確認に役立ちます。結果が食い違う場合は、まずルールと古い接続を確認し、次に権限、回線、アカウントの状態を調べます。設定を変えるたびに再確認し、ステータスアイコンだけで結論を出さないようにしましょう。