VPNの接続確認方法｜出口IP・DNS・アプリ別チェック入門

VPNが機能しているか確認するには、接続状態と通信経路を分けて考える

VPNが機能しているか確認するには、まず出口IP、次にDNS、最後に実際に使うアプリをチェックします。出口IPは「リクエストがどこから送信されたか」、DNSは「誰がドメインを名前解決したか」、アプリの確認は「対象のアプリが想定した経路を使ったか」を示します。それぞれの結果を照らし合わせる必要があり、接続アイコンが緑色だからといって十分な確認にはなりません。

クライアントの「接続済み」は、プロキシのコア機能が動作中、システムトンネルが確立済み、またはノードへの接続完了などを意味する場合があります。具体的な意味はクライアントによって異なります。ブラウザーやコマンドラインツール、その他のアプリがすべて通信を切り替えたことや、アクセス先のサイトが正常に応答したことを示すとは限りません。

確認を始める前に、現在のネットワーク、選択中のノード、動作モード、対象アプリを記録します。システムプロキシの設定が上書きされないよう、ほかのプロキシクライアントや同様の機能を持つ拡張機能は終了してください。テスト中はできるだけネットワークを切り替えず、一度に変更する設定は一つにします。そうしないと、どの変更が反映されたのか判断しにくくなります。

出口IPの確認：接続前の状態を記録してから比較

出口IPは、Webサイトから見えるインターネット上の送信元IPアドレスです。自宅ネットワーク内で端末に割り当てられたローカルIPとは異なります。システムのネットワーク設定に表示されるローカルIPを見ても、プロキシが機能しているかは判断できません。ブラウザーで「グローバルIP 確認」などと検索し、現在のアクセス元を表示するチェックページを利用してください。

1. 接続前の状態を記録します。一時的な直接接続が可能で、機密性の高い作業をしていない場合は、クライアントを切断してチェックページを新しく開き、グローバルIPと利用中のネットワークを記録します。通信遮断機能を有効にしている場合、切断後にインターネットへ接続できなくなるのは想定内の動作である可能性があります。テストのために保護機能を無効にする必要はありません。
2. 選択中のノードに接続します。設定が有効になっていることを確認し、同じチェックページを開き直します。必要に応じて強制再読み込みを行い、古い結果が表示されないようにしてください。
3. 実際の出口を確認します。IPアドレスが変わったか比較し、クライアントの接続ログでチェックページのドメインにプロキシルールが適用され、想定したノードが使われているか確認します。
4. IPアドレスの種類を確認します。チェックページでIPv4とIPv6の両方が表示される場合は、それぞれ確認してください。一方のアドレスしか表示されなくても、もう一方の通信経路まで確認できたことにはなりません。

IPアドレスが変われば、今回のブラウザー通信の出口が変わった可能性は高いものの、すべてのアプリがプロキシ経由になったとは限りません。変化がなくても、すぐに障害と判断しないでください。チェック用ドメインがルールで直接接続に設定されている、ブラウザーがシステムプロキシを使っていない、以前の接続が再利用されている、といった可能性があります。

地域表示はあくまで参考情報です。IPの位置情報データベースは更新が遅れることがあり、登録地域とサーバーの実際の所在地が異なる場合もあります。地域表示とノード名が一致しないときは、地図上の位置だけで判断せず、IPアドレス、ネットワーク事業者、クライアントの接続ログを確認してください。

DNSの確認：名前解決の出口が異なっても、必ずしも漏えいとは限らない

DNSはドメイン名をIPアドレスに変換します。Webサイトへの接続はプロキシ経由でも、ドメインの問い合わせはローカルネットワークで処理されることがあります。クライアントが名前解決を引き受ける場合や、ブラウザーが暗号化DNSを使う場合もあります。そのため、「Webの出口IPが変わったか」と「DNSが想定どおりか」は別々に確認する必要があります。

同じ動作モードのまま「DNSリーク テスト」などで検索し、テストを実行してDNS事業者を記録します。この種のページは専用のテスト用ドメインを使い、再帰DNSサーバーを確認するのが一般的です。表示されるのは多くの場合、DNSサービスの出口であり、端末から送信された通信の全経路ではありません。クライアントの設定も踏まえて結果を判断してください。

まず、クライアントでDNSの引き受け、リモート名前解決、ルールに応じた名前解決が有効か確認します。次に、ブラウザーでセキュアDNSが個別に有効になっていないか確認してください。ブラウザーの暗号化DNS通信がプロキシを経由するかどうかは、ルーティングやクライアントの実装によって異なります。「暗号化済み」という表示だけで、選択中のノードを経由しているとは判断できません。

ここでいうDNSリークとは、DNSリクエストが本来利用する想定だった保護された経路から外れることです。ルールでローカルサービスへの直接接続が明示され、その名前解決にローカルDNSを使う場合は、それだけで異常とは限りません。一方、対象への通信をすべてプロキシ経由にする想定なのに、ローカルネットワークで名前解決されている場合は、原因を調べる必要があります。

DNSの設定を変更した後は、テスト接続をやり直し、必要に応じてOSやクライアントの案内に従ってDNSキャッシュを消去してください。チェックページの表示をそろえるためだけに、知らないDNSサーバーを安易に設定するのは避けましょう。設定を誤るとドメインを名前解決できなくなり、問題の切り分けも難しくなることがあります。

アプリごとに確認：ブラウザーで成功しても、ほかのアプリで使えるとは限らない

システムプロキシとトンネルモードでは、通信をカバーする範囲が異なります。システムプロキシはアプリにプロキシ設定を提供しますが、実際に使うかどうかはアプリの実装次第です。独自のネットワーク設定を使うプログラムもあります。トンネルモードは仮想ネットワークインターフェースを通じて、より広い範囲の通信を引き受けられますが、除外リスト、ルーティング、権限、プラットフォームの制約を受けます。すべての通信が自動的に対象になるわけではありません。

WindowsまたはmacOSでは、まずシステムプロキシの接続先が現在のクライアントになっているかを確認し、対象プログラムに独自のプロキシ設定がないか調べます。コマンドラインツールはプロキシ環境変数を読み込む場合もあれば、個別のオプション指定が必要な場合もあります。ブラウザーでWebページを開けても、ターミナルのダウンロードや開発ツールが同じ経路を使っているとは限りません。

iOSやAndroidでは、システムにVPNの表示があっても、関連するネットワーク設定が動作していることを示すだけです。クライアントのアプリ別設定、ルール、除外項目も確認してください。Linuxでは、デスクトップのプロキシ設定、ターミナルの環境変数、トンネルのルーティングをそれぞれ確認します。デスクトップの設定がすべてのプログラムに適用されると思い込まないようにしましょう。

• ✅ ブラウザー：新しいページを開いて出口IPを確認し、接続ログで該当ドメインを探します。
• ✅ 対象アプリ：アプリを完全に終了してから起動し直し、ログイン、読み込み、同期など実際に必要な操作を行います。
• ✅ クライアントのログ：通信量が増えたかだけでなく、対象のリクエストに想定したルール、プロキシグループ、ノードが適用されたか確認します。
• ✅ コマンドラインツール：ツール自身のプロキシ設定と環境変数を確認してから、以前失敗した操作をもう一度実行します。
• ❌ キャッシュされたページや過去の内容、ログイン済みの状態だけを、現在の通信に設定が反映された証拠にしないでください。

アプリをテストするときは、リモートの内容を再読み込みする、もう一度同期するといった、新しいリクエストが発生する操作を選びましょう。キャッシュ済みのページは、オフラインでも表示される場合があります。ログに該当するリクエストがないときは、アプリがまだ通信していない、またはログの絞り込みで非表示になっている可能性もあります。実際の操作内容と合わせて判断してください。

接続表示なのにプロキシ経由にならないときは、症状から原因を絞り込む

サブスクリプションを追加したが、設定が有効になっていない

サブスクリプションURLは設定を取得するためのものです。追加が完了しても、含まれるノードが選択され、有効になったとは限りません。現在有効な設定、ノードの選択、サブスクリプションの更新結果を確認してください。プロトコルの項目を根拠なく変更するのは避けましょう。クライアントが対応するプロトコルとサブスクリプションの形式が一致している必要があります。

Shadowsocks、VMess、Trojan、VLESSなどは、プロキシプロトコルや関連する設定を表す名称です。特定のアプリの通信がプロキシ経由になるかどうかを直接決めるものではありません。回線がIEPL、中継、直接接続のいずれであっても、端末側のルール確認に代わるものではありません。通信の伝送経路とアプリのルーティングは、別のレイヤーの問題です。

ルールで直接接続が選ばれている、または一時的な設定変更が残っている

まず接続ログで、対象ドメインに適用されたルールを確認します。アプリによっては複数のドメインを使うため、メイン画面がプロキシ経由でも、ログイン、添付ファイル、APIのリクエストが同じ経路とは限りません。ルールの問題を切り分けるため、一時的にグローバルプロキシモードへ切り替える方法もあります。ただし、出口を切り替えるのに適さない作業は避け、確認後は元の設定に戻してください。

以前の接続、ブラウザー拡張機能、アプリ独自のプロキシ設定が干渉している

ノードを切り替えた後も以前の接続が再利用されることがあり、ブラウザー拡張機能がシステムプロキシの設定を上書きする場合もあります。競合する拡張機能を無効にし、対象アプリを完全に終了してから、接続を確立し直してください。複数の設定を同時に変えると原因を再現できなくなるため、一度に一つずつ対応し、変更前後の結果を記録しましょう。

リクエストはプロキシ経由だが、アクセス先のサービスに拒否される

ログに想定したノードが表示され、リクエストが送信されている場合は、アクセス先のサービスの状態、アカウントの地域、サブスクリプションの権限、セキュリティ上の制限に関する表示も確認してください。認証画面、アクセス拒否、地域に関するメッセージが出ても、クライアントが機能していないとは限りません。ノードを何度も切り替えると追加のアカウント確認が発生する場合があるため、まず具体的なエラー内容を確認しましょう。

確認結果を記録してから、継続する問題に対処する

一通りの確認結果には、テスト日時、端末のOS、クライアント名、ネットワークの種類、動作モード、ノード名、出口IP、DNSの結果、対象アプリの状態を含めます。「ブラウザーの出口IPは変わったが、対象プログラムのログでは直接接続になっている」と伝えるほうが、「接続できない」とだけ伝えるより原因を特定しやすくなります。

スクリーンショットを送る前に、サブスクリプションURL、アクセストークン、アカウント情報、関係のないドメインを隠してください。サブスクリプションURLには設定取得用の認証情報が含まれる場合があるため、公開の掲示板に投稿しないでください。VPNJGのサポートが必要な場合は、ユーザーパネルのチケットから必要な記録をお知らせください。基本設定はクライアントの使い方ガイドも参考にしてください。