VPN 接続中なのに通信できない？出口IPとDNSの確認ガイド

VPNが使えないときは、接続と通信の経路を切り分ける

VPNに接続しても通信できない場合は、まず出口IP、次にDNS、最後に対象アプリを確認します。クライアントの「接続済み」は、通常トンネルやプロキシが起動したことを示すだけで、ブラウザーやゲーム、コマンドラインの通信すべてがVPNを使っているとは限りません。

原因を調べる際は、アプリがリクエストをどこに渡すのか、クライアントがどのルールで処理するのか、ドメインをどこで名前解決するのか、接続先サイトにどのグローバルIPアドレスが見えているのかを切り分けましょう。どこか一つでも想定と異なれば、「接続アイコンは点灯しているのにサイトが開かない」という状況が起こり得ます。最初からクライアントを再インストールしたり、複数の設定を一度に変更したりしないでください。

システムプロキシ、仮想ネットワークアダプターによる通信の取り込み、ブラウザー拡張機能では、適用範囲が異なります。システムプロキシは、アプリ側がプロキシ設定に従う必要があります。TUNモードは、仮想ネットワークインターフェースを通じてルーティング条件に合う通信を受け取りますが、除外設定や権限、ルールの影響を受けます。ブラウザー拡張機能は通常、対象のブラウザーだけに適用されます。同じ接続アイコンだけで、それぞれの動作を判断することはできません。

確認のポイント：接続状態は出発点にすぎません。結果を判断するには、対象アプリの実際の通信経路を確認します。出口IP、DNSの経路、ルールの適用状況はそれぞれ個別に調べる必要があり、互いに代用できません。

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

IPアドレス確認ページを開き、表示されたグローバルIPアドレス、プロバイダー、地域を記録します。次に利用するサーバーに接続し、同じブラウザーでもう一度確認してください。地域データベースの更新には時間差があるため、地図上の地名だけでなく、IPアドレスそのものを比較しましょう。

接続前の結果を記録。確認対象のクライアントを切断し、ほかのプロキシ拡張機能やネットワーククライアントがブラウザーの通信を処理していないことを確認してから、結果を記録します。
地域を選んで接続。利用中のサーバー名と動作モードを記録し、テスト中に何度も切り替えないようにします。
新しいリクエストを送信。確認ページを再読み込みします。キャッシュの影響が疑われる場合は、古いタブを閉じ、新しいウィンドウでページを開いてください。
ルールを確認。確認ページが直接接続に設定されている場合、IPアドレスが変わらなくても設定どおりの可能性があります。一時的にそのサイトをプロキシ経由にして再確認し、確認後は元のルールに戻します。
対象アプリを確認。ブラウザーの出口IPが変わっても、変化が確認できるのは今回のブラウザー通信だけです。ほかのアプリは個別に確認してください。

異なるサーバーでも出口IPアドレスを共有している場合があるため、サーバーを切り替えてもIPが変わらないからといって、切り替えに失敗したとは限りません。反対に、IPが変わっても、すべての通信がVPN経由になった証明にはなりません。確認サービスがIPv4とIPv6を別々に表示する場合は、それぞれ比較してください。一方だけを見て判断しないようにしましょう。

ブラウザーのシークレットウィンドウで分離できるのは、主に一部のローカルセッションや保存データです。システムプロキシを自動的に回避する機能はなく、独立したネットワーク出口にもなりません。ログイン状態やキャッシュの影響を除く補助にはなりますが、端末全体の通信経路を証明するものではありません。

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

DNSはドメイン名をIPアドレスに変換します。ウェブ通信はプロキシ経由でも、名前解決はローカルネットワークに任されている場合があります。ブラウザーのセキュアDNS、クライアント内蔵のリゾルバー、リモートプロキシが処理することもあります。出口IPの確認とDNSの確認では、異なる段階を調べています。

信頼できるDNSテストページを利用する場合は、表示されるのがDNSサーバーのアドレスと所属先であり、ウェブ通信の出口ではないことを理解しておきましょう。テストページは通常、専用ドメインへの問い合わせを発生させ、再帰リゾルバーを確認します。パブリックDNSは分散配置されていることがあり、表示地域が利用中のサーバーと異なるだけでは、DNS漏洩の証拠になりません。

注目すべきなのは、本来リモート側で名前解決するはずのドメインが、意図せずローカルネットワークのDNSサービスに問い合わせていないかどうかです。まずクライアントで、プロキシ経由のドメインと直接接続するドメインにそれぞれどのリゾルバーを使うか確認します。次にブラウザー独自のセキュアDNSが有効かを調べましょう。暗号化DNSは名前解決時の通信の一部を保護できますが、「暗号化されている」ことと「現在のプロキシ経由で送信される」ことは同じではありません。

コマンドラインで確認できること

Windowsでは、ターミナルで次のコマンドを実行すると、既定のDNSサーバーとドメインの応答を確認できます。例に使うドメインは名前解決のテスト用であり、CPUVPNのサーバーやサービスの接続先ではありません。

nslookup example.com

macOSやLinuxでも、関連ツールがインストールされていれば同じコマンドを使えます。別の方法として、dig example.comでも確認できます。こうしたツールは通常、ブラウザーのHTTPプロキシ設定には従いません。TUN、DNSのリダイレクト、システムの名前解決設定によって経路が変わることがあるため、コマンドの出力だけでブラウザーが実際に使っているリゾルバーを判断することはできません。

DNS設定を変更したら、もう一度問い合わせを行い、必要に応じて該当するシステムやアプリのDNSキャッシュを消去します。キャッシュに古い応答が残っていても、現在も古いリゾルバーに問い合わせているとは限りません。テストページの表示をそろえるためだけにDNS設定をすべて置き換えるのは避けてください。ローカルサイトや社内ネットワークのドメインに影響する可能性があります。

症状から原因を特定：ルール、次にアプリを確認

次の表では、見えている症状ごとに確認箇所を整理しています。表だけで故障原因を断定することはできません。同じ症状でも原因は異なるため、設定を一つずつ変更して再確認し、範囲を絞り込んでください。

接続状態と実際のアクセス結果を比較
症状	考えられる原因	まず確認すること
ブラウザーの出口IPが変わらない	システムプロキシが無効、拡張機能が設定を上書き、または確認サイトが直接接続の対象になっている	プロキシの接続先と、対象ドメインに適用されたルールを確認
ブラウザーは正常だが、デスクトップアプリは使えない	アプリがシステムプロキシに従わない、または独自のネットワーク設定を使用している	アプリのプロキシ設定と、仮想ネットワークアダプターで通信を取り込む範囲を確認
出口IPは変わったが、対象サイトへのアクセスを拒否される	アカウントの地域設定、プラットフォームの方針、出口IPの評価、またはサービス側の障害	拒否画面とネットワーク接続エラーをまず区別する
一部のドメインだけ開けず、ほかのサイトは正常	ドメインの名前解決、ルーティングルール、または接続先サービスの問題	名前解決の結果、適用されたルール、エラーの種類を比較
IPv4は想定どおりだが、IPv6は元のネットワークのまま	現在のモードがIPv6を対象にしていない、またはIPv6に関する迂回ルールがある	クライアントのIPv6対応状況と実際のルートを確認
ネットワークを切り替えた後にだけ通信できなくなる	既存の接続、ルート、名前解決の状態がすぐに更新されていない	接続を再確立し、システムプロキシと新しいリクエストを確認

「ドメインを解決できない」「接続がタイムアウトする」「プラットフォームにはっきり拒否される」は、別々の症状として記録しましょう。名前解決のエラーでは、まずDNSを確認します。タイムアウトはルートやサーバー、接続先サービスが原因の可能性があります。アクセス拒否はアカウントの権限や地域のルールにも関係する場合があります。一つのエラーページだけで、クライアントが機能していないと断定することはできません。

ルーティングルールとサービス側の利用制限を確認する

ルールモードでは、一部の通信を直接接続し、残りをプロキシ経由にするのは一般的な設計です。クライアントの接続一覧や診断情報では、対象ドメインにどのルールが適用され、最終的にどの出口が選ばれたかを確認します。そうした情報を確認できない場合は、対象アプリの実際の動作と出口IPの確認結果を照らし合わせましょう。存在しないメニューの場所を推測で案内しないでください。

多くのクライアントで「グローバル」と呼ばれるモードは、プロキシのコアに届いたリクエストを一つの出口にまとめるだけで、すべてのアプリの通信を自動的に取り込むわけではありません。リクエストが実際にクライアントへ届いていることを前提に、ルーティングの問題を切り分ける際に利用できます。確認後は、普段の利用に適したルールへ戻してください。ローカルの通信まで不要に転送しないようにしましょう。

✅ Windows：システムプロキシの設定がクライアントの状態と一致しているか確認します。仮想ネットワークアダプターで通信を取り込む場合は、必要な権限と動作状態も確認してください。プログラムによっては独自のプロキシ設定を使い、システム設定に従わないことがあります。
✅ macOS：クライアントの要件に沿って、VPN設定、ネットワーク拡張機能、プロキシの許可を確認します。必要な権限は実装によって異なるため、すべての種類の許可設定を探す必要はありません。
✅ Android：VPNの許可とアプリごとのルーティング対象を確認します。アプリが除外されていると、ステータスバーに接続中と表示されていても、直接接続を続けることがあります。
✅ iOS：システムのVPN状態とクライアントのルールを確認します。ブラウザー以外のアプリも実際にテストしてください。ウェブページを一度確認しただけで、システム全体の通信経路を判断することはできません。
✅ Linux：デスクトップのプロキシ設定、ターミナルの環境設定、仮想ネットワークアダプターのルートをそれぞれ確認します。ターミナルのプログラムがデスクトップ環境のプロキシ設定を読み込むとは限りません。

複数のプロキシクライアントやブラウザー拡張機能を同時に動かすと、どの設定が適用されているか分かりにくくなります。テスト中は確認対象のクライアントだけを残し、プロキシや名前解決の経路を変更するほかのツールを一時的に無効にしてください。組織の管理下にある端末では、管理対象のネットワークポリシーを許可なく変更しないでください。

IPv6、WebRTC、サブスクリプション設定の適用範囲

IPv6は独立した通信経路として確認してください。対象アプリがIPv6を使い、現在のプロキシモードがIPv4しか対象にしていない場合、リクエストの一部が想定した出口を通らない可能性があります。まずクライアントに用意されているIPv6の通信取り込み機能や互換設定を利用してください。原因の特定のため一時的にシステムのIPv6を無効にする場合は、変更前の設定を記録し、テスト後に戻します。一般的な解決策として扱わないでください。

WebRTCの検査では、ローカルアドレス、プライバシー保護されたホスト名、公開候補アドレスが表示されることがあります。ローカルアドレスが見えても、ウェブ通信がプロキシを迂回したとは限りません。想定外の公開候補アドレスが表示された場合は、ブラウザーのポリシー、UDPへの対応、実際のルートをあわせて確認してください。検査の警告を消すために、提供元が不明な拡張機能を安易にインストールするのも避けましょう。

サブスクリプションリンクはサーバー情報や関連設定を取得するためのもので、すべてのルーティングルールやDNSルールが自動的に読み込まれるとは限りません。動作はサブスクリプションの形式とクライアントの実装によって異なります。更新後は、選択した設定が実際に有効になっていることも確認してください。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはそれぞれ異なるプロトコルまたは方式の名称であり、それだけでシステムの通信が取り込まれた証明にはなりません。

サブスクリプションリンクにはアクセス認証情報が含まれている場合があります。リンク全体やQRコード、トークンが写ったスクリーンショットを公開の掲示板に投稿しないでください。サポートに状況を伝える際は、認証情報、アカウント情報、不要なアドレス情報を隠してください。

回線の種類と通信の取り込み範囲は別のものです。IEPL専用線、中継、直接接続は、それぞれ異なる伝送方式を表します。専用線を選んでいても、アプリの通信がクライアントに届いていなければ、その回線経由では送信されません。まず通信経路を確認し、その後で回線の状態を比較してください。順序を逆にしないことが大切です。

確認が終わったら、再検証できるよう結果を記録する

有用なトラブルシューティング記録には、OSとクライアント名、現在のモード、選択した地域、テストしたアプリ、接続前後の出口IP、DNSの確認結果、具体的なエラーを含めます。設定は一度に一つだけ変更し、同じ操作を再試行してください。これにより、ルールの修正や名前解決の変化が原因なのか、接続先サイトがたまたま復旧したのかを切り分けられます。

対象サイトだけにアクセスできず、出口IPとルールが想定どおりの場合は、サイトのお知らせ、アカウントの権限、地域制限を確認してください。ネットワーク経路が正常でも、プラットフォームがアクセスを許可するとは限らず、コンテンツの利用許諾が変わるわけでもありません。地域を何度も切り替えるより、サービスのルールに従って確認するほうが原因を特定しやすくなります。

まとめ：出口IPを確認してウェブ通信を検証し、DNSを確認して名前解決の経路を調べ、ルールとアプリを確認して適用範囲を確かめます。三つの結果が一致して初めて、テストした環境が想定どおり動作していると判断できます。「接続済み」という表示だけで結論を出さないでください。

クライアントの接続手順を確認したい場合は、使い方ガイドをご覧ください。接続エラーの原因を引き続き調べる場合は、よくある質問をご確認ください。上記の比較結果を添えて問い合わせると、同じテストを繰り返さずに済みます。