VPNは接続できている？出口IP・DNSの確認方法を初心者向けに解説

VPNが実際に機能しているか確認するには、まず出口IPを調べ、次にDNSの名前解決経路を確認し、最後に実際に使うアプリで検証します。クライアントに「接続済み」と表示されても、それはクライアントが報告する接続状態を示すだけです。すべてのアプリやドメインが選択した経路を通っている証拠にはなりません。

最初に確認したいのは、目的が特定のブラウザーで海外サイトにアクセスすることなのか、端末上の対象アプリをルールに従って通信させることなのかです。分割トンネルでは一部の通信が直接接続されるため、特定のサイトで通常の出口が表示されても、必ずしも不具合とは限りません。以下の手順で一つずつ確認し、ブラウザー、クライアント、アプリの問題を切り分けましょう。

まず確認：接続状態・出口IP・アプリの通信経路

クライアント、OS、接続先のサイトが把握する情報は、それぞれ異なります。OSにVPNの表示があれば、通常はネットワーク拡張機能やトンネルが有効になっています。クライアントでサブスクリプションを更新できても、確認できるのは設定情報の取得に成功したことだけです。どちらも、対象のWebページが指定した出口を実際に経由した証拠にはなりません。

各チェック結果から分かること
確認項目	分かること	そこからは判断できないこと
クライアントに「接続済み」と表示される	クライアントが接続中、またはプロキシ起動中と報告している	すべてのアプリがプロキシを経由している
検査ページでグローバルIPが変わった	そのWebリクエストの出口が変わった	ほかのアプリやDNS通信も同じ出口を使っている
DNS検査で特定のリゾルバーが表示された	検査リクエストで確認された再帰DNSの出口	リゾルバーの地域だけでDNSリークがあると判断すること
対象アプリにアクセスできる	その時点で該当機能を利用できた	アプリのすべての通信が指定した経路を通る
動画配信サービスで目的のコンテンツが表示された	その時点でプラットフォームの地域・コンテンツ判定が想定どおりだった	今後もその経路を常に利用できる

より確実に判断するには、複数の情報を照合します。出口IPが想定どおり変わり、DNSの動作が設定と一致し、対象アプリの通信も適切なルールに一致していることを確認しましょう。検査ページがすべて緑色になることより、結果が目的に合っているかどうかが重要です。

出口IPを確認する：接続前後の結果を比較

出口IPとは、接続先のサーバーから見えるグローバルIPアドレスです。家庭内ネットワークで端末に割り当てられるローカルIPとは異なります。ブラウザーで「グローバルIP 確認」と検索し、IPv4とIPv6を個別に表示できるツールを使いましょう。検査ツールにもアクセス情報は送信されます。確認のためにアカウント情報を入力したり、見慣れない拡張機能をインストールしたりする必要はありません。

接続前の状態を記録します。クライアントを切断し、検査ページを開いてグローバルIP、ネットワーク事業者、表示地域を控えます。Wi-Fiとモバイルネットワークを同時に切り替えず、同じネットワークを使い続けてください。
確認したい経路に接続します。対象のノードが選択されていることを確認し、ルールモード、システムプロキシ、端末全体を対象にするトンネルモードのどれが有効かを確認します。
新しいリクエストを送信します。検査ページを再読み込みします。再検査の操作がない場合は、ページを閉じて開き直してください。必要に応じて別の検査ツールでも確認します。
IPアドレスを比較します。まずIPが変わったかを確認し、その後で登録情報や表示地域を見ます。国旗だけで判断せず、検査ページに表示される都市を物理的なサーバー所在地とみなさないようにしましょう。

IPアドレスの位置情報データベースは更新が遅れる場合があり、検査サービスによって表示地域も異なります。選択したノード名、出口アドレスの登録情報、プラットフォーム独自の地域判定は、必ずしも一致しません。IPの変化は手掛かりになりますが、想定した出口かどうかは、サービスのノード情報やクライアントの記録と合わせて判断してください。

検査ページへの通信に直接接続ルールが適用されていると、接続後もIPアドレスが変わらないことがあります。確認のため一時的にクライアントのグローバルプロキシモードを使い、検査後は元のルールに戻してください。ただし「グローバル」は多くの場合、クライアント内部のルーティング設定を指し、すべてのアプリを必ず経由させるものではありません。アプリによってはシステムプロキシを使わない場合もあります。

IPv4とIPv6の両方を確認してください。どちらか一方に元のネットワークのアドレスが表示される場合は、クライアントがそのIPアドレスの種類をどのように処理する設定なのかを確認します。IPv4が変わっただけで、すべての通信が保護されたと判断しないでください。

DNSを確認する：地域だけでなく名前解決経路を見る

DNSはドメイン名を接続先のIPアドレスに変換します。Web通信がプロキシを経由していても、ドメイン名の問い合わせまで同じ経路を通るとは限りません。この記事でいうDNSリークとは、本来は想定した保護経路で処理されるはずの問い合わせが、設定と異なる経路で処理されることです。たとえば、ローカルネットワーク経由で通信事業者のリゾルバーに問い合わせるケースが該当します。

対象の経路に接続したまま、DNSリーク検査ツールを開いてテストします。一般的なツールでは、ブラウザーから一時的に生成したドメイン名へリクエストを送り、検査側が権威DNSサーバーで再帰リゾルバーを確認します。表示されるのは主に再帰DNSの出口です。端末が直接通信したサーバーとは限らず、DNS通信全体の経路が分かるわけでもありません。

まず未接続時の結果を記録します。通常のネットワークで使われるリゾルバーを確認し、接続後の結果と比較します。
設定内容を確認します。プロキシ経由のドメインと直接接続するドメインを、クライアントがそれぞれどのように名前解決するか、DNSの制御が有効になっているかを確認します。
ブラウザーのセキュアDNSを確認します。ブラウザー独自の暗号化DNSが、OSの名前解決設定を上書きしたり、別の経路を使ったりする場合があります。その通信がプロキシを経由するかどうかは、ルーティング設定にも左右されます。
接続記録と照合します。検査結果に元のネットワークのリゾルバーが表示された場合、すぐに検査ツールの誤りと決めつけず、DNS問い合わせが直接送信されていないか確認してください。

リゾルバーが別の地域に表示されても、それだけでDNSリークとは限りません。パブリックDNSサービスは、分散配置された出口を使うことがあります。逆に、リゾルバーとノードの地域が同じでも、問い合わせが暗号化されていることや、トンネルを最後まで経由していることの証明にはなりません。クライアントがfake-IPを使う場合、アプリに一時的な対応アドレスを渡すのは通常の仕組みです。実際のグローバル出口と混同しないでください。

判断のポイント：DNS検査は問題を調べる手掛かりであり、プライバシー保護の証明ではありません。検査結果をクライアントのDNS設定、ブラウザーのセキュアDNS設定、接続記録と合わせて確認してください。経路を特定できない場合は記録を残してサポートに問い合わせ、地域表示だけで判断しないようにしましょう。

アプリごとに確認する：ブラウザーが正常でもすべてのアプリが正常とは限らない

システムプロキシ、ブラウザー拡張のプロキシ、端末全体を対象にするトンネルでは、通信の対象範囲が異なります。WindowsやmacOSではシステムプロキシに従うアプリもあれば、独自のネットワーク設定を使うアプリもあります。Linuxではデスクトップ環境のプロキシ設定や環境変数が関係する場合もあります。ブラウザー拡張が通常影響するのはブラウザー関連の通信であり、ほかのソフトの状態までは判断できません。

iOSやAndroidのクライアントは、システムのネットワーク機能を使って通信を制御することがよくあります。ただし、対象アプリやドメインルール、除外設定は実装と設定によって異なります。Androidでは省電力設定によってバックグラウンド動作が制限される場合があります。ネットワークを切り替えた後は、接続が復旧しているか改めて確認してください。VPNのアイコンが表示されていても、実際の通信テストの代わりにはなりません。

✅ 対象のブラウザーで出口IPを再確認し、別のプロキシ拡張機能が有効になっていないか確認します。
✅ 実際に使うアプリで検索し直す、キャッシュされていないコンテンツを開くなど、新しい通信を発生させます。読み込み済みのホーム画面だけで判断しないでください。
✅ クライアントに接続記録がある場合は、アプリ名や対象ドメインごとに適用ルール、出口ノード、接続エラーを確認します。
✅ アプリ別ルーティングの「対象に含める」「対象から除外」の意味を確認し、対象アプリが直接接続に設定されていないか確認します。
✅ ネットワークを切り替えた後や端末をスリープから復帰させた後にも確認し、バックグラウンドからの復帰時だけ問題が起きるかを調べます。

ログに記録されるDNS問い合わせ、Webリクエスト、アプリ接続では、同じドメインが使われるとは限りません。アプリがログイン、画像、動画、更新用のサービスに接続することもあります。あるドメインがプロキシ経由になっていても、確認できるのはその接続だけです。調べたい機能に対応するリクエストを特定してください。

接続中に見えても経由していない：症状から原因を調べる

サブスクリプションを追加できたのに、接続できない

サブスクリプションリンクにはノードや設定が含まれていますが、それ自体がネットワークトンネルではありません。追加後に利用可能なノードを選び、接続を開始する必要があります。設定を読み込めるかどうかはクライアントのバージョンや実装によって異なります。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどはそれぞれ異なるプロトコルであり、どのクライアントでも使えるとは限りません。ここでは互換性を説明しており、LQVPNがこれらすべてのプロトコルを提供するという意味ではありません。

サブスクリプションを更新できない場合は、リンクが完全か、クライアントが対応しているかを確認します。ノードへの接続に失敗する場合は、認証、接続状態、設定に関するエラーを確認してください。アクセス情報が含まれている可能性があるため、サブスクリプションリンクを公開の検査サイトに貼り付けないでください。

ブラウザーの出口IPは変わらないのに、ほかのアプリは使える

まずブラウザー拡張、個別のプロキシ設定、検査対象ドメインに適用されたルールを確認します。逆に、ブラウザーの出口IPは変わってもほかのアプリがプロキシを経由しない場合は、アプリがシステムプロキシに従っていないか、アプリ別ルールで除外されている可能性があります。ノードを何度も切り替えても、通信の対象範囲の問題は解決しないことがほとんどです。

Webページは開けるのに、通話などのリアルタイム機能が不安定

こうした機能は、一般的なWebページとは異なる接続方式を使うことがあります。WebRTC検査でローカルIPやmDNSによって隠されたホスト名が表示されても、それだけでグローバルIPが漏れているとは限りません。元のネットワークのグローバルIPが表示された場合は、メディア通信の経路をさらに確認してください。関連するUDP通信をプロキシ経由にできるかは、クライアント、ノード、ルールの対応状況によります。

出口IPは想定どおりなのに、動画配信サービスで地域が合わないと表示される

プラットフォームはアカウントの地域、支払い情報、位置情報の権限、キャッシュ、出口IPの評価などを参照する場合があります。アプリを開き直し、地域に関する設定を確認してください。必要に応じて、プラットフォームの案内に従ってキャッシュを処理します。IEPL専用線、中継、直接接続は経路の構成方法を示すものであり、DNSリークが起きないことや特定のコンテンツライブラリを常に利用できることを保証するものではありません。

検査結果を記録し、再確認できるようにする

調査時には、端末のOS、クライアント名とバージョン、選択したノード、動作モード、出口IPの変化、DNS検査結果を記録します。クライアントログを有効にする場合は、問題を再現してから該当部分を取得してください。外部に送る前に、ユーザー名、サブスクリプションリンク、アクセストークン、問題に関係のないアクセス記録を隠してください。

同じ調査の中で、DNS、分割ルール、ノードを同時に変更しないでください。一つ変更するたびに、同じ対象アプリで再試行します。問題が解決したら、不要な一時設定を元に戻してください。診断のためにグローバルプロキシへ切り替えた場合は、元のルールに戻した後の動作も確認しましょう。

最終確認の基準：対象リクエストの出口が想定どおりで、ドメインの名前解決経路が設定に一致し、実際のアプリ通信にも適切なルールが適用されていれば、動作を確認するための十分な根拠がそろいます。ただし、確認できるのは現在の環境でのテスト結果です。すべてのアプリや今後の通信まで検証できたことを意味しません。

LQVPNの利用者は、まず初心者向けガイドでクライアントとサブスクリプションの手順を確認し、次によくある質問で設定を確認できます。原因を特定できない場合は、情報を伏せた記録をサポートチケットから送信してください。「接続できているのに開けない」とだけ伝えるより、原因を調べやすくなります。