VPN接続済みなのに使えない？出口IP・DNSの確認方法

VPNが機能しているか確認する：接続状態とアプリの通信経路を区別

VPNに接続しても使えない場合は、まず出口IPとDNSを確認し、次に対象アプリの通信を検証します。クライアントの接続表示は確認の出発点にすぎません。ブラウザーでウェブサイトを開けても、ほかのアプリが同じ経路を使っているとは限りません。

切り分けでは、クライアントがサーバーに接続できるか、OSが通信をクライアントに渡しているか、ルールがプロキシを選択しているか、接続先サイトにどの出口が認識されるかを確認します。一部のクライアントで「接続済み」と表示されるのは、プロキシコアの起動や設定の有効化を示すだけで、すべてのリクエストがリモート接続を完了したことを意味しません。

そのため、「機能している」の範囲を明確にしましょう。ブラウザーで海外サイトにアクセスできればよいのか、デスクトップアプリもVPN経由にするのかを決めます。ルールモードでは、一部の通信が直接接続になるのが一般的です。日本国内のサイトがローカル回線を使っていても、必ずしも不具合ではありません。対象の通信が想定したルールに従っているかが重要です。

出口IPの確認：接続前後で比較する

出口IPとは、確認サイトから見えるリクエスト元のIPアドレスです。家庭内ネットワークで使われる端末のローカルアドレスとは異なります。まず、こちらのネットワーク確認ページを開いて結果を記録します。次にクライアントを有効にし、同じブラウザーと確認ページでもう一度調べてください。表示された国旗だけで判断しないようにしましょう。

1. ほかのプロキシツールやブラウザー拡張を一時停止し、現在のクライアントを切断してから、通常のネットワークで使われる出口アドレスと所在地情報を記録します。管理対象の端末では、まず組織のポリシーを確認し、許可なく業務用接続を切断しないでください。
2. クライアントで対象の回線を選び、システムプロキシまたは仮想ネットワークアダプターによる通信制御が有効か確認します。ノードを選択しただけでは、システムの通信経路が変わらないことがあります。
3. 開いている確認ページのタブを閉じ、新しいタブでページを開き直して再確認します。必要に応じて対象サイトのキャッシュを消去し、以前の結果を新しい結果と取り違えないようにしてください。
4. アドレスが変わったか比較し、クライアントの接続ログで対象ドメイン、適用されたルール、出口も確認します。確認サイト自体が直接接続に設定されている場合もあります。

アドレスが変われば、その確認リクエストが以前と異なる出口を使ったことがわかります。ただし、すべての通信がVPN経由になった証拠ではありません。変化がない場合は、確認サイトが直接接続になっている、ブラウザーがシステムプロキシを使っていない、プロキシ設定が無効になっている、といった可能性を切り分けます。一時的にグローバルプロキシモードに切り替えて再確認し、終わったら元のルールに戻してください。

確認ページにIPv4とIPv6が個別に表示される場合は、それぞれを確認してください。一方のアドレスファミリーだけがVPN経由になり、アプリがもう一方の経路を優先する設定もあります。まずクライアントのIPv6ルーティングとDNS対応を確認しましょう。IPv6の無効化を、すべての端末に適用できる恒久的な解決策と考えるのは避けてください。

DNSの確認：名前解決の場所と通信の出口は別

DNSはドメイン名をIPアドレスに変換し、その後アプリが接続先のアドレスに接続します。この2つの経路は異なる場合があります。ウェブ通信はプロキシ経由でも、名前解決のリクエストはローカルネットワークに送られることがあります。また、ブラウザーだけがセキュアDNSを使い、ほかのアプリは引き続きシステムのDNSリゾルバーを使うケースもあります。

DNSリークとは、想定した経路で処理されるはずのドメイン名の問い合わせが、ローカルネットワークを通じて意図しないDNSリゾルバーに送信される状態を指します。信頼できるDNSテストページを使い、接続前後のリゾルバー情報をそれぞれ記録して、クライアントのDNS設定と照らし合わせてください。DNSテスト機能が明示されていない一般的なIP確認ページでは、名前解決の経路は判断できません。

DNSテストでは、複数のテスト用ドメインを使って再帰DNSリゾルバーを確認することがあります。結果に表示されるアドレスは、DNSサービスの出口であり、端末が直接接続しているアドレスとは限りません。また、パブリックDNSサービスではエニーキャストが使われることがあり、リゾルバーの所在地とノードの地域が異なっても、それだけでDNSリークとはいえません。

• ✅ クライアントでDNS制御が有効か確認し、プロキシ経由のドメインと直接接続するドメインで、どの名前解決方式が使われるか確認します。
• ✅ ブラウザーのセキュアDNS設定を確認し、システムとは別の名前解決経路を使っているか確認します。
• ✅ 設定を変更したら関連アプリを再起動します。必要に応じてシステムのDNSキャッシュを消去し、テスト用ドメインに再アクセスしてください。
• ❌ パブリックDNSリゾルバーの名前が表示されただけでリークと判断しないでください。一度正常な結果が出ても、すべてのアプリで今後も問題がないとは限りません。

ブラウザーで暗号化DNSを使うと、DNSの問い合わせ内容がブラウザーからDNSサービスまでの通信経路で見られるリスクを減らせますが、ウェブ通信が自動的にVPN経由になるわけではありません。逆に、ウェブ通信の出口が変わっても、DNSがVPN経由になったとは限りません。両方を個別に確認しましょう。

アプリごとに確認する：システムプロキシと仮想ネットワークアダプターの違い

システムプロキシはアプリにプロキシ設定を提供しますが、実際に使うかどうかはアプリの実装によります。仮想ネットワークアダプターモードでは、通常、ルーティングを通じてより多くのIP通信を制御できますが、除外設定、権限、アドレスファミリー、クライアントの実装などの影響を受けます。グローバルプロキシはルールの選択方式であり、システムレベルですべてのアプリの通信を制御するとは限りません。

デスクトップアプリを確認するときは、いったん終了して再起動し、コンテンツの更新やリモートファイルを開くなど、通信が発生する操作を行います。同時にクライアントの接続ログで、そのアプリからのリクエストがあるか、どのルールに一致したか、直接接続か対象ノード経由かを確認してください。ログに記録がない場合、まだ確認できていないことを示すだけで、アプリがネットワークに接続していないとは限りません。

WindowsとmacOSでは、システムプロキシがコマンドラインツールや独自にネットワークを管理するアプリに適用されないことがあります。Linuxでは、デスクトップ環境のプロキシ設定とアプリが参照する環境変数が異なる場合もあります。iOSとAndroidでは、システムのVPNインターフェースを通じて通信を制御するのが一般的ですが、対象範囲はクライアントの設定やOSの制約によって異なります。使用中のクライアントの操作ガイドを優先し、別のプラットフォームの画面例をそのまま当てはめないでください。

接続済みでもVPNを経由しない：よくある原因と確認手順

サブスクリプションを追加しただけで、通信制御が有効になっていない

サブスクリプションURLはノードやルールの設定を取得するためのもので、追加できてもVPNトンネルが使えるとは限りません。現在の設定が有効か、ノードが設定内に残っているか、クライアントが対象プロトコルに対応しているかを確認し、システムプロキシまたは仮想ネットワークアダプターの状態も確認してください。プロトコルは通信方式を定めるもので、各アプリの経路を自動的に決めるものではありません。

サブスクリプションURLにはアカウントへのアクセス情報が含まれる場合があります。公開の確認サイトに貼り付けたり、画面を公開したりしないでください。サポートが必要な場合は、機密情報を隠したエラーログをサポートチケットから送信してください。

ルールで直接接続が選ばれている、または複数のツールが設定を上書きしている

設定によって直接接続するドメインもあれば、ルールに一致せず既定の出口を使うリクエストもあります。まず適用されたルールを確認し、対象ドメインのポリシーを調整してください。複数のプロキシクライアント、ブラウザー拡張、業務用接続を同時に動かすと、システム設定やルーティングが変更されることがあります。どのツールが通信を制御するかを明確にし、競合要因を一つずつ切り分けましょう。

ブラウザーは使えるのに、接続先プラットフォームで地域が一致しないと表示される

プラットフォームはアカウントの地域、支払い情報、位置情報の許可、セッションキャッシュ、出口IPなどを組み合わせて地域を判定したり、特定の出口を制限したりする場合があります。まず対象の通信がVPN経由になっていることを確認し、そのうえでプラットフォーム側の条件を調べてください。回線を切り替えて比較することはできますが、出口IPが変わっても、特定地域のコンテンツが必ず利用できるとは限りません。

確認のまとめ：記録を残してから回線の問題を判断

「ローカルネットワークの確認 → クライアントによる通信制御 → 確認リクエストの出口 → DNSの経路 → 対象アプリのルール」の順で調べるのがおすすめです。一度に変更する設定は一つに絞り、変更前後の結果を記録してください。ノード、DNS、モードを同時に変更すると、成功しても失敗しても原因を特定しにくくなります。

出口とルールが想定どおりなのに対象アプリで問題が続く場合は、回線への到達性、プラットフォームの制限、アプリ自体のエラーを確認してください。IEPL専線、中継、直接接続はネットワーク経路の構成を表すもので、アプリごとの検証に代わるものではなく、特定のプラットフォームで継続して使えることを保証するものでもありません。

サポートには、端末のプラットフォーム、クライアント名、選択した設定、問題発生時のネットワーク環境、すでに試した比較手順を伝えてください。「ブラウザーの出口は変わったが、デスクトップアプリのログでは直接接続になっている」のように具体的に説明すると、「接続しても使えない」だけの場合より原因を特定しやすくなります。設定方法はクイックスタートガイド、地域の選び方は動画視聴ガイドをご覧ください。