VPN接続後に確認すること：出口IP・DNS・アプリごとの通信経路

VPNに接続したら、まず対象の通信に使われる出口IPアドレスを確認し、次にDNSの解決経路を調べ、最後に実際に使うアプリで検証します。接続アイコンが示すのは、クライアントが接続確立を報告していることだけです。ブラウザー、デスクトップアプリ、バックグラウンドプロセスが同じ経路を使うとは限りません。

確認する前に、すべての通信をVPN経由にしたいのか、特定の海外サイトだけをVPN経由にしたいのかを明確にしましょう。ルールモードでは、国内サイトへの直接接続が想定どおりの場合もあります。すべてのサイトでVPNの接続先と同じ地域が表示されるべきだと考えると、正常な振り分けを誤判定するおそれがあります。

接続状態・出口・振り分けを分けて確認

通信経路は、アプリがリクエストを送信し、システムまたはクライアントが経路を選び、直接接続またはプロキシ経由で対象サーバーにアクセスする流れです。ドメイン名はIPアドレスに解決する必要があります。この処理はシステム、ブラウザー、プロキシクライアントのいずれかが行うため、ウェブページの通信と同じ経路とは限りません。

システムプロキシは、システムのプロキシ設定に従うアプリの通信を中継するもので、すべての通信を自動的に取り込みません。TUNやシステムVPNインターフェースは、より広い範囲の通信を取り込めますが、ルーティング、対象外アプリ、LANルール、アドレスファミリーの扱いに左右されます。仮想ネットワークアダプターが存在しても、すべてのアプリが対象だとは限りません。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコル名は、異なるプロキシ転送方式を示すもので、端末上で通信が取り込まれる範囲を表すものではありません。IEPL専線、中継、直接接続は通信経路に関するものであり、端末のルーティング確認の代わりにはなりません。プロトコル名から結果を推測せず、実際のリクエストから確認しましょう。

出口IPアドレス：接続前後を比べて経路を確認

現在のリクエストのグローバルIPアドレスを表示する、信頼できる確認ページを使いましょう。結果を確認するだけでよく、位置情報の許可や拡張機能のインストールは不要です。表示内容はその時点のリクエストを観測したものです。位置情報データベースには更新の遅れがあるため、表示された都市を回線の物理的な所在地の証明とみなすことはできません。

1. クライアントを切断し、ブラウザーで確認ページに表示されるグローバルIPアドレスと通信事業者の情報を記録します。これを直接接続時の基準にします。
2. 利用する接続先に接続し、使用中のモード、接続先名、アプリ除外ルールの有無を記録します。
3. 古いタブに残った結果を見ないよう、確認ページを開き直します。国名だけでなく、グローバルIPアドレスを比較しましょう。
4. クライアントの接続ログで確認用ドメインを探し、適用されたルールと出口を確認します。そのドメインが直接接続に設定されている場合、結果が変わらなくても、対象の海外サイトが直接接続されているとは限りません。
5. 実際に利用したいウェブサイトに戻り、ページを更新するか接続を再確立してから、そのリクエストの記録を確認します。

ブラウザーの出口IPアドレスは変わったのに、コマンドラインのプログラムではローカルの出口が表示される場合、そのプログラムがシステムプロキシを使っていない可能性があります。反対に、ターミナルでプロキシ環境変数を使っていても、ブラウザーがその変数を引き継ぐとは限りません。プロセスごとに確認し、別々の結果を混同しないようにしましょう。

IPv4とIPv6の違いにも注意してください。一方の通信だけが取り込まれ、もう一方は直接接続されることがあります。確認サービスにそれぞれの検査項目があれば個別に確認し、クライアントが両方をどう扱うかも調べましょう。表示をそろえるためだけに、システムのネットワーク機能を長期間むやみに無効化しないでください。

DNS：表示される国名だけでなく、名前解決の経路を確認

DNSリークとは、トンネルやプロキシのルールで保護されるはずのDNSリクエストが、想定外の経路から送信されることを指します。重要なのは設定どおりの経路かどうかであり、検査ページに自国の国名が表示されるかどうかではありません。ルールモードでは、国内ドメインをローカルのリゾルバーで解決する設計もあります。

ブラウザーのDNS検査ページは、通常、テスト用ドメインを生成し、問い合わせを受け取る再帰リゾルバーを確認します。端末に設定されたDNSサーバーではなく、転送経路の先にあるリゾルバーが表示される場合もあります。パブリックDNSのエニーキャストネットワークや位置情報データベースの影響で、所在地の表示が実際と異なることもあります。

ブラウザーとシステムを分けて確認する

ブラウザーのセキュアDNSは、HTTPSなどを使ってDNSを送信する機能です。システムのDNS設定を経由しない場合があります。DNS通信を暗号化しても、その通信が自動的にVPN経由になるわけではありません。まずブラウザーで独自のDNSサービスが有効かを確認し、そのリクエストに実際に適用されたルールを調べましょう。

Windowsでは、PowerShellまたはコマンドプロンプトで読み取り専用のコマンドを使い、手がかりを確認できます。例にあるドメインはDNS問い合わせを行うためのもので、VPN19の回線確認用エンドポイントではありません。

ipconfig /all
nslookup example.com

ipconfig /all は、アクティブなネットワークアダプターと設定済みのDNSを確認するのに役立ちます。nslookup は、問い合わせ先のサーバーと応答を表示します。ただし、後者の問い合わせ方はブラウザーやすべてのアプリ、クライアントのリモートDNS経路を代表するものではありません。サーバーがローカルアドレスと表示されても、ローカルの転送先にすぎない場合があります。

macOSでは scutil --dns でDNS設定を確認できます。systemd-resolvedを使うLinuxでは resolvectl status で、インターフェースごとのリゾルバーを確認できます。いずれも設定を知る手がかりであり、すべてのDNS問い合わせがトンネルを通っている証明ではありません。クライアントのDNS設定やリクエストログとあわせて判断してください。

アプリ別に確認：ブラウザーで成功してもアプリで成功するとは限らない

ウェブページは開けるのにデスクトップアプリでエラーが出る場合は、まず通信が取り込まれる範囲を確認しましょう。システムプロキシに従うアプリもあれば、独自のネットワーク設定を使うアプリもあります。ログインページ、バックエンドAPI、更新サービスをそれぞれ呼び出すアプリもあるため、トップページだけでは一連の動作を確認できません。

• ✅ ブラウザー：対象サイトにアクセスし、ログインページ、コンテンツページ、実際の操作に対応する接続記録を確認します。
• ✅ デスクトップアプリ：アプリを終了して開き直し、失敗した操作を再現して、該当プロセスまたは対象ドメインに適用されたルールを確認します。
• ✅ コマンドラインツール：個別のプロキシ設定やプロキシ環境変数があるか確認し、システムプロキシを使うと決めつけないようにします。
• ✅ モバイルアプリ：VPN設定が有効か、クライアントでそのアプリや対象アドレスが除外されていないかを確認します。
• ❌ クライアントの接続先テストが成功しただけで、実際のアプリのすべてのリクエストも成功すると判断しないでください。

WindowsとmacOSでは、システムプロキシと仮想ネットワークアダプター方式で通信が取り込まれる範囲が異なります。クライアントの実装を確認してください。Androidのクライアントでは、アプリの対象リストや除外リストを設定できる場合があります。iOSでは、現在有効なVPN設定とクライアントが対応するルールを確認しましょう。デスクトップ版と同じメニューがあるとは限りません。

Linuxでは、デスクトップの設定、ターミナルの環境変数、バックグラウンドサービスのネットワーク環境がそれぞれ異なることがあります。サービスプロセスは、デスクトップブラウザーに設定したプロキシを自動的に使うとは限りません。バックグラウンド処理だけが失敗する場合は、ブラウザーの接続先を変え続けるのではなく、そのサービスの起動環境を確認しましょう。

ログを確認する前に、対象の操作をはっきり再現し、その時刻のドメイン、プロセス、ルール、出口を探します。リクエスト自体が記録されていない場合は、まずアプリが通信の取り込み対象かを確認します。直接接続のルールが適用されている場合はルールの順序を調べ、接続先が選択されているのにハンドシェイクに失敗する場合は、接続エラーとサービスへの到達性を確認しましょう。

接続済みなのに動かない場合は、症状から原因を絞り込む

出口IPアドレスが変わらない

確認サイトのドメインに直接接続ルールが適用されていないか、ブラウザー独自のプロキシ拡張機能がないか、クライアントが接続先に接続しただけでシステム全体の通信を取り込んでいないのではないかを確認しましょう。モードを一時的に切り替える場合は、元の設定を記録し、関連する項目だけを変更します。確認後に元へ戻し、設定が互いに上書きされるのを防いでください。

特定のアプリだけ失敗する

アプリの除外リストと個別のプロキシ設定を確認します。ログイン、ファイルのアップロード、メディア再生では、異なるドメインや通信方式が使われることがあります。メインサイトのドメインを追加しただけでルールがそろったと考えないでください。実際のログやサービスが公開するドキュメントをもとにルールを補い、根拠なく適用範囲を広げないようにしましょう。

接続先を切り替えても以前の地域が表示される

アプリが長時間接続を維持していたり、ウェブサイトがセッション状態を保持していたりする場合があります。対象との接続をいったん確立し直し、新しいリクエストの出口を確認しましょう。シークレットウィンドウは一部のセッションの影響を切り分けるのに役立ちますが、アカウントの地域を変えたり、サーバー側の判定情報を自動的に消去したりするものではありません。

サブスクリプションを読み込めても、接続先へのリクエストが失敗する

サブスクリプションを読み込めたことは、クライアントが設定を読み取ったことを示すだけです。プロトコル、転送オプション、使用中のクライアントのバージョンに互換性があるとは限りません。具体的なエラーメッセージを確認し、管理パネルから有効なサブスクリプションを再取得してください。形式をむやみに変換したり、サブスクリプションURLを公開の検査サイトに貼り付けたりしないでください。

サブスクリプションURLにはアカウントを識別できる情報が含まれる場合があります。サポート担当者にスクリーンショットを送る際は、サブスクリプションURL全体、認証情報、非公開のアクセス用ドメインを隠し、問題の特定に必要なモード、エラー表示、ルールの適用結果だけを残してください。

あとから確認できる記録を残す

有効な確認では、どのアプリがどの対象にどのモードでアクセスし、どのルールと出口が使われたか、DNSが想定どおりかを把握できる必要があります。これらをひとつの記録にまとめるほうが、「接続済み」と表示された画面だけを保存するより役立ちます。システムの更新、ネットワークの切り替え、ルールの変更後も、同じ手順で再確認できます。

確認しても原因を特定できない場合は、管理パネルのチケットから、対象の操作、OS、クライアントのモード、確認済みのログをお知らせください。クライアントの設定を確認するには使い方ガイドをご覧ください。ルールやアクセスの問題は、AI高速化ガイドのトラブルシューティングも参考になります。