VPNに接続できたかどうかは、まず出口IP、次にDNS、最後に実際に使うアプリで確認します。クライアントに「接続済み」と表示されても、通常わかるのは接続状態だけで、すべての通信が意図した経路を通るとは限りません。接続状態、通信経路、振り分けルールを分けて確認しましょう。
接続状態と通信経路
クライアントはシステムプロキシを使う場合もあれば、仮想ネットワークインターフェースで通信を処理する場合もあります。システムプロキシは、その設定に従うアプリにプロキシの接続先を提供します。システムプロキシを参照しないアプリは、直接インターネットに接続することがあります。仮想ネットワークインターフェースはVPNやTUNモードでよく使われますが、通信を処理する範囲はルーティング、アプリの除外設定、振り分けルールによって異なります。モード名だけでは判断できません。
「グローバル」の意味も、設定内容を確認する必要があります。クライアントによっては、グローバルモードでもプロキシコアに渡された通信の出口を一律に選ぶだけで、端末上のすべてのアプリを自動的にVPN経由にするわけではありません。ルールモードでは、ドメイン名、宛先アドレス、アプリなどの条件に応じて経路を振り分けます。一部の通信が直接接続されるのは、設定どおりの動作かもしれません。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどは、それぞれ異なるプロキシプロトコルと通信方式を指します。通信をどこまで処理するかを示すものではありません。サブスクリプションの読み込みに成功しても、クライアントに設定が追加されたことがわかるだけです。現在どの回線が選択されているか、システムプロキシやトンネルモードが有効かは、別途確認してください。
出口IP：接続前後を比較する
- 未接続時の結果を記録する。クライアントを切断し、信頼できるパブリックIP確認ページをブラウザーで開いて、IPアドレス、ネットワークの事業者、地域を記録します。システム設定に表示されるローカルIPアドレスを、インターネット側の出口IPと取り違えないようにしましょう。
- 接続後にもう一度確認する。回線を選び、必要なプロキシまたはトンネルの設定が有効になっていることを確認してから、同じ確認ページを再読み込みします。必要に応じて新しいブラウザーウィンドウを開き、古いページの結果を見てしまわないようにします。
- 確認ページへの通信ルールを調べる。IPアドレスが変わらない場合は、クライアントの接続ログで、確認ページのドメイン名が直接接続かプロキシ経由かを確認します。確認ページがルールで直接接続に設定されていれば、表示されるのは直接接続時の出口であり、ほかのサイトの通信経路を示すものではありません。
- 実際に使うサービスでも確認する。対象サイトでリクエストを新たに送信し、クライアントの接続詳細と照らし合わせます。ルールの適用状況や出口情報がクライアントに表示される場合は、地域表示だけで判断せず、これらの情報を優先して経路を確認しましょう。
IPアドレスが変わった場合、その確認リクエストのインターネット出口が変化したことはわかりますが、端末全体の通信がVPN経由になったとは限りません。IPアドレスの地域情報はデータベースによる推定で、更新に時間がかかることがあります。回線の入口、出口、データベース上の地域名が一致するとも限りません。地域表示が異なる場合は、接続が機能していないと決めつけず、実際の出口と回線の説明を確認してください。
IPv4とIPv6の違いにも注意が必要です。確認ページが個別の検査に対応していれば、両方の通信を確認しましょう。一方のアドレスファミリーはVPN経由、もう一方は通常の経路で送信されると、結果が交互に変わる場合があります。異常かどうかは、クライアントの対応状況と想定する設定に照らして判断してください。ネットワーク環境を理解しないまま、システム機能をむやみに無効にするのは避けましょう。
DNS：名前解決の経路を確認する
DNSはドメイン名をネットワーク上のアドレスに変換しますが、ウェブリクエストと同じ経路を通るとは限りません。ブラウザーで暗号化DNSが有効になっていたり、クライアントがDNSを処理したりする一方で、システムがローカルネットワークのDNSリゾルバーを使い続けることもあります。ウェブ通信の出口が想定どおりでも、DNSの経路が適切とは限りません。
接続後、ブラウザーで信頼できるDNS検査ページを開き、表示される再帰DNSリゾルバーとネットワーク事業者を確認します。クライアントのDNS設定やブラウザーのセキュアDNS設定とあわせて結果を見ましょう。すべての名前解決をトンネル経由にする想定なのに、ローカルネットワークのリゾルバーが表示される場合は、迂回経路がないか引き続き確認します。
リゾルバーの所在国だけでDNS漏れと判断しないでください。パブリックDNSサービスは、近隣拠点での接続や分散型の出口を使うことがあり、検査ページの位置情報もIPアドレスのデータベースに基づく場合があります。反対に、リゾルバーが目的の地域にあるように見えても、通信経路の安全性を証明することにはなりません。重要なのは、誰が名前解決を行い、どの経路で送信され、設定したポリシーに沿っているかです。
コマンドラインでのドメイン名検索結果は、システムのDNS設定を把握する手がかりになりますが、ブラウザーやプロキシクライアントの名前解決動作を再現するとは限りません。アプリによっては、プロキシ経由でリモート名前解決を行ったり、独自のDNSサービスを使ったりします。システムのDNSリゾルバー一覧は参考情報として扱い、それだけでDNS漏れの最終判断をしないでください。
アプリごとに確認する：ブラウザー以外の通信
ブラウザーで確認できたら、実際に使うアプリでも通信を新たに発生させます。たとえば、リモート文書を更新する、業務サービスに再接続する、対象ページを読み込むといった操作です。既存の接続は、回線を切り替える前の経路を使い続けることがあります。設定を変更した後は、必要に応じてアプリを終了して再起動し、新しい接続を確認してください。
- ✅ ブラウザー：プロキシ拡張機能、セキュアDNS、システムプロキシの設定が互いに影響していないか確認します。シークレットウィンドウは一部のキャッシュによる影響を減らせますが、ルーティングを自動で変えるわけではありません。
- ✅ デスクトップアプリ：アプリ側でプロキシ設定が必要か、クライアントがその種の通信を処理できるかを確認します。ブラウザーでは使えるのにデスクトップアプリで失敗する場合は、まず通信を処理する範囲を確認しましょう。
- ✅ モバイルアプリ：システム上のVPN接続が有効か確認します。クライアントにアプリごとの振り分けや除外設定がある場合は内容を確認し、ネットワークを切り替えた後にもう一度テストしてください。
- ✅ コマンドラインツール：ツールがプロキシの環境変数を参照するか、独自の設定を使うか確認します。ブラウザーがプロキシを使っているからといって、ターミナルも同じ出口を使うとは限りません。
- ❌ クライアントの遅延だけを見る：接続先へのテストに成功しても、確認できるのはそのテスト先に到達できたことだけです。対象アプリ、DNS、出口の確認の代わりにはなりません。
WindowsやmacOSのシステムプロキシを、すべてのソフトウェアが使うわけではありません。iOSやAndroidで通信が処理される範囲は、クライアントの実装やシステム設定によって異なります。Linuxでは、デスクトップのプロキシ設定、ターミナルの環境変数、ルーティングが一致しているか確認しましょう。使用中のクライアントの説明を参照し、あるプラットフォームの手順を別の環境にそのまま当てはめないでください。
よくある結果と確認ポイント
| 現象 | 考えられる原因 | 次に確認すること |
|---|---|---|
| 接続済みと表示されるが、確認したIPが変わらない | 確認先のドメインが直接接続になっている、またはアプリが通信処理の対象外 | ルールの適用状況、システムプロキシ、トンネル設定を確認する |
| ブラウザーの出口は想定どおりだが、ほかのアプリで失敗する | アプリがシステムプロキシを参照しない、または独自設定がある | アプリのプロキシ設定、除外項目、新しい接続のログを確認する |
| ウェブの出口は想定どおりだが、DNSの結果が想定と異なる | システム、ブラウザー、アプリがそれぞれ個別に名前解決している | DNSの処理設定とセキュアDNSの設定を順に確認する |
| 出口の地域表示が一致しない | データベースの地域情報に差がある、または別の出口が実際に選択されている | 現在の回線、接続ログ、ほかの確認サービスの結果を照合する |
| 一部のサイトは使えるが、目的のサービスでエラーが出る | 対象サイト向けのルール、アカウント権限、サービス側の制限 | エラー内容を記録し、ネットワーク障害かサービス側の拒否かを切り分ける |
| ネットワークを切り替えた後に問題が起きる | 既存の接続が切れた、またはルーティングやDNSの状態が戻っていない | クライアントに再接続し、アプリの接続を作り直して再確認する |
問題の切り分けのために、一時的にプロキシの対象範囲を広げる場合は、先に元の設定を控え、テスト後に戻してください。変更する条件は一度に一つだけにします。たとえば、まず通信処理モードを変更し、その後DNSを確認します。回線、ブラウザー設定、ルールを同時に変更すると、結果を比較できなくなります。
対象サイトで地域やアカウントに関するエラーが出ても、VPNが機能していないとは限りません。サービスはアカウントの地域、ログイン状態、支払い情報、独自のポリシーなどをもとに判断することがあります。出口の検査でわかるのは「リクエストがどこから送信されたか」であり、対象サービスを利用できる保証ではありません。
検査結果の範囲と再確認の記録
出口IPやDNSの確認は通信経路の検証であり、プライバシー全体の監査ではありません。サービス側でデータがどのように扱われるかや、接続が切れたときに直接接続を確実に防げるかを証明するものではありません。VPNSoundのプライバシー方針にある「ログを記録しない」はサービスの方針に関する説明です。ブラウザーで一度検査しただけで確認できるものではなく、匿名性を絶対に保証するものでもありません。
クライアントに切断保護機能がある場合は、動作を理解したうえで個別にテストできます。回線を手動で切断し、本来トンネルを通るアプリの通信が停止するか確認します。テスト前に作業内容を保存し、転送中のデータに影響が出ないようにしてください。機能の搭載を確認していない場合、クライアントがローカルネットワークへの切り替わりをすべて防ぐと決めつけないでください。
問い合わせに必要な情報は、プラットフォーム、クライアントのバージョン、接続モード、回線名、対象アプリ、エラーメッセージです。サブスクリプションURLには認証情報が含まれることがあるため、公開の検査サイトに貼り付けないでください。スクリーンショットを共有する前に、サブスクリプションURL、ユーザー名、完全なパブリックIPアドレスを隠してください。サポートが必要な場合は、ユーザーパネルのチケットから再現手順をお知らせください。