VPNが接続されているかどうかは、クライアントの接続アイコンだけでは判断できません。出口IPが想定どおりか、DNSの問い合わせがどのように処理されるか、対象アプリにルールが適用されているかを、それぞれ確認する必要があります。ブラウザーでウェブページを開けても、そのアクセスが成功したことを示すだけで、端末全体の通信が同じ経路を通っているとは限りません。

実用的なのは、接続前後を比較してから、実際に使うアプリを確認する方法です。ここで紹介するのは繰り返し実行できる確認手順であり、特定の時点の速度測定ではありません。また、ウェブサイトに表示された地域だけで判断することもできません。

まず接続方式を確認する

一般にVPNと呼ばれるものには、端末全体を対象とするトンネル接続のほか、ローカルプロキシ経由で通信を転送するクライアントもあります。システムプロキシが影響するのは、通常、プロキシ設定に従うソフトウェアだけです。トンネル方式はより広範な通信を扱えますが、アプリ別設定やルート除外、クライアントの実装による影響は残ります。画面上の「グローバル」も、プロキシ内の通信をすべてプロキシ経由にする意味にすぎず、すべてのソフトウェアがプロキシを使うとは限りません。

確認前に、現在のモード、選択中のサーバー、ルール設定、対象アプリが除外リストに含まれているかを記録してください。Shadowsocks、VMess、Trojan、VLESSなどのプロトコル名から分かるのは接続方式であり、端末上の通信がどこまで対象になるかではありません。最終的には、クライアントがどのように通信を処理するかによります。

接続前後の確認結果を記録する

同じ端末とネットワークを使い、ほかのプロキシツールやブラウザー拡張機能はいったん終了して、設定の競合を避けます。確認するクライアントを切断し、信頼できるパブリックIP確認サイトで出口を記録してから、クライアントに接続し、同じサイトで再確認します。確認サイトはネットワーク情報を表示するだけのものを選び、不明なプログラムのインストールやアカウントのパスワード入力を求めるサイトは避けてください。

  1. 切断した状態で、パブリックIP、表示されたプロバイダー情報、接続中のネットワークを記録します。ルーターの設定画面に表示されるプライベートIPを、パブリックIPと取り違えないようにしてください。
  2. 想定するサーバーに接続し、クライアントにエラーがないことを確認してから、確認サイトを再読み込みします。必要に応じて新しいブラウザーセッションを使い、ページキャッシュの影響を抑えましょう。
  3. 接続後の出口とネットワークの割り当てを記録します。異なるアドレスファミリーの結果が表示された場合は、それぞれを照合し、目立つアドレスだけを見て判断しないでください。
  4. 実際に使うウェブサイトやアプリを開き、新しい通信を一度実行します。その後、切断して再接続し、同じ結果を再現できるか確認してください。

パブリックIPは通常、出口に応じて変わりますが、共有出口やサーバー切り替えの方式、アドレス割り当ての仕組みによって結果は異なります。アドレスが変わらない場合は、すぐに接続障害と判断せず、直結ルールが適用されていないか確認してください。反対に、ブラウザーの出口が変わっていても、チャットツールやゲーム、バックグラウンド同期アプリも同じ経路を使っているとは限りません。

確認結果と、そこから分かることを分けて考える
確認結果 分かること 次に確認すること
ブラウザーの出口が想定どおり 今回のウェブリクエストは想定した出口を利用した ほかのアプリや別のアドレスファミリーも経由しているか
DNSの結果にローカルネットワークのリゾルバーが表示される 名前解決の経路をさらに確認する必要がある ルール設定、ブラウザーのセキュアDNS、DNSログ
アプリにはアクセスできるが、ブラウザーの出口は変わらない アプリ独自のプロキシや別のルールが使われている可能性がある アプリのプロキシ設定とクライアントの接続ログ
アプリを前面に戻すとアクセスが復旧する バックグラウンド動作やネットワーク再接続に影響している可能性がある OSの省電力設定、トンネルの状態、再接続ログ

出口の地域が想定と異なる場合は、まず判定の誤差を確認する

IP確認サイトに表示される国や都市は、IPアドレスのデータベースに基づくもので、サーバーの所在地をリアルタイムで測定した結果ではありません。データベースごとに更新時期が異なる場合があります。また、ウェブサイトはアカウントの地域、言語設定、位置情報の許可、既存のセッションなどに応じて表示を変えることがあります。サイトのトップページが特定の言語で表示されても、出口がその地域にある証拠にはなりません。

地域が想定と異なる場合は、まずパブリックIPとネットワークの割り当てを確認し、別の信頼できるサイトの結果と照合します。同じIPなのに確認サイトごとに都市が異なる場合は、データベースの差が考えられます。IPが切断時と変わらない場合は、確認用ドメインが直結していないか確認してください。サイトの表示に合わせようとして、多数の設定を次々に変更するのは避けましょう。

アドレスファミリーによって異なるルートが使われる場合もあります。クライアントが特定の種類の通信を処理せず、接続先のウェブサイトがその通信に対応していると、一部のリクエストは経由し、別のリクエストはローカルネットワークを通ることがあります。設定を変更するかどうかは、クライアントの対応範囲と具体的な設定を踏まえて判断してください。影響が分からないまま、OSのネットワークスタックを変更することはおすすめしません。

DNSの確認:国ではなく名前解決の経路を見る

DNSはドメイン名を接続可能なアドレスに変換します。出口IPの確認では通信がどこから出ていくかを調べ、DNSの確認ではドメイン名の問い合わせがどこを通るかを調べます。これは別の確認です。ウェブページの通信はリモートの出口を通っていても、ドメイン名の問い合わせはローカルネットワークのリゾルバーに送られていることがあります。

信頼できるDNS確認サイトでテストを実行し、表示されたDNSサービスの情報を記録して、切断時の結果と比べます。リゾルバーが国内にあるからといって、必ずしもDNSリークとは限りません。パブリックDNSサービスが近隣の拠点を使う場合や、ルール設定によって国内ドメインを意図的に国内で名前解決する場合もあります。確認すべきなのは、経由させる予定のドメイン名の問い合わせが、意図せずローカルネットワークに送られていないかです。

ブラウザーのセキュアDNS、OSの暗号化DNS、クライアントのDNS設定によって、異なる経路が使われる場合があります。暗号化DNSは問い合わせの通信が暗号化されていることを示しますが、現在のプロキシを必ず経由するという意味ではありません。結果が想定と異なる場合は、ブラウザーが独自のDNSサービスを指定していないかを確認してから、クライアントのDNSルールとリモート名前解決の設定を調べます。一度に変更するのは一項目だけにして、その都度再テストしてください。

アプリ別に確認する:対象アプリから新しい接続を発生させる

ブラウザー拡張機能のプロキシは通常ブラウザーだけに影響し、システムプロキシを無視するアプリもあります。アプリ内蔵のプロキシ、システムトンネル、アプリ別の許可・除外リスト、ドメインルールによっても通信経路は変わります。確認するのは「すべてのソフトウェアが同じ動作をするか」ではなく、「対象アプリごとに、事前に設定したルートが使われているか」です。

既存の長時間接続が古い経路を使い続けないよう、対象アプリをいったん終了してから開き直します。新しい検索、再読み込み、同期などを実行してください。すでにダウンロード済みのコンテンツを閲覧するだけでは、接続確認になりません。クライアントに接続ログがある場合は、プロセス名、ドメイン名、接続先アドレスから該当リクエストを探し、プロキシ経由か直結かを確認します。ログはトラブルシューティング用の情報として扱い、むやみに公開しないでください。

WindowsとmacOSでは、システムプロキシとトンネルによる通信の取り込みを区別してください。Androidではアプリの除外リストとバックグラウンドの省電力制限に注意します。iOSでは現在有効なVPN構成と、アプリ自体の通信状態を確認してください。Linuxではデスクトップのプロキシ、環境変数、システムルートの適用範囲を区別します。クライアントによって機能は異なるため、実際の画面やドキュメントに沿って操作してください。

接続済みなのに通信できないときの原因と確認手順

クライアントは接続済みでも、対象の通信が直結される

まず、どのルールが適用されたかを確認します。対象ドメインが直結グループに含まれている、アプリが除外リストに入っている、またはアプリがシステムプロキシに従っていない可能性があります。クライアントが対応していれば、診断しやすい接続モードに一時的に切り替えて比較できます。確認が終わったら必要なルールに戻してください。すべてのルールを恒常的に無効にする方法を、標準の解決策にしないでください。

ブラウザーは使えるが、アプリにはアクセスできない

アプリ独自のプロキシ設定があるか、クライアントが処理しない通信に依存しているか、古い接続がまだ残っていないか確認してください。サーバーに接続できても、接続先のプラットフォームへのアクセスが必ず許可されるとは限りません。アカウントの状態、プラットフォームの地域ポリシー、サーバー側の障害が原因のこともあります。ネットワーク経路の問題と、プラットフォームからの応答を分けて記録しましょう。

接続直後は正常でも、しばらくすると使えなくなる

端末のスリープ、接続ネットワークの切り替え、バックグラウンド制限を確認します。まずクライアントが実際に再接続しているかを確かめてから、出口と対象アプリを再チェックしてください。モバイル端末では、OSの説明に従ってクライアントのバックグラウンド動作を許可します。デスクトップでは、スリープから復帰した後のプロキシやトンネルの状態を確認し、画面だけ復旧して通信転送が再開していない状態に注意してください。

サブスクリプションはあるのに、サーバー一覧に問題がある

サブスクリプションのインポートに成功しても、クライアントが設定を読み込めたことを示すだけで、サーバーとのハンドシェイクが成功したとは限りません。まず更新結果、選択中のサーバー、クライアントとの互換性を確認してください。サブスクリプションURLを公開の確認サイトに送信したり、プロトコル設定をむやみに変更したりしないでください。URLにはアカウントのアクセス情報が含まれることがあるため、パスワードと同じように管理してください。

判断の目安:

出口が想定どおりで、DNSの経路がルールと一致し、対象アプリの新しいリクエストにも正しい経路が使われていれば、より確かな確認結果が得られます。どれか一つでも異なる場合は、該当する設定に戻って原因を調べてください。「接続済み」という表示だけでは、これらの確認に代わりません。

問い合わせ時に共有する情報と、定期的な再確認

サポートが必要な場合は、OS、クライアント名、接続モード、選択中のサーバー、問題が起きる状況、すでに試した比較内容をまとめてください。スクリーンショットでは、ユーザー名、サブスクリプションURL、アクセストークン、不要な接続先ドメインを隠します。ログを共有する場合は適切なサポート窓口を利用し、設定全体をそのまま公開しないでください。

クライアントの変更、ルールの更新、接続ネットワークの切り替え後は、この手順を再度実行すると安心です。毎回複雑なテストをする必要はありませんが、実際に使うアプリが引き続き想定どおりに通信しているかは確認してください。量子暗号はU5VPNのセキュリティに関する主な訴求ポイントです。個々のリクエストが経由しているかどうかは、セキュリティ表示だけで判断せず、出口、名前解決の経路、アプリのログで確認してください。

U5VPNのアカウントはメールアドレス不要で、ユーザー名とパスワードで利用できます。クライアントの入手方法ははじめてガイドをご覧ください。接続の問題を解決できない場合は、サポートページで問い合わせ方法を確認できます。利用を始める前に、プランページでデータ容量と料金ルールを確認すると、接続の問題とデータ使用量の問題を区別しやすくなります。