VPNに接続したと表示されても、すべてのアプリが想定した経路を通るとは限りません。まずIPアドレスとDNSを確認し、次に実際に使うアプリの通信を検証しましょう。クライアントの「接続済み」は、接続またはローカルプロキシが起動したことを示すだけの場合があり、ブラウザーやチャットアプリなどすべての通信が想定どおりとは限りません。
この記事では、実際には確認していない結果を示しません。ご自身の端末で接続前後を比較し、クライアントのルールや接続ログとあわせて判断してください。IPアドレス、名前解決の経路、アプリごとのルーティングはそれぞれ別の確認項目です。緑色のアイコンだけですべてを判断することはできません。
接続状態と実際の通信経路の違い
一般的なクライアントは、OSのVPNトンネルを使うものと、ローカルプロキシを起動してシステムのプロキシ設定を変更するものがあります。前者はシステムのネットワークインターフェースを通じて、ルーティングルールに合致する通信を処理します。後者はアプリがプロキシ設定に従うかどうかに左右されます。どちらも画面上は「接続済み」と表示されることがありますが、通信をカバーする範囲は異なります。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたはプロトコル体系であり、クライアントの動作モードを示すものではありません。これらの名称だけで、すべての通信がVPN経由になったとは判断できません。VLESS自体には暗号化機能がなく、実際の保護はトランスポート層の設定にも左右されます。他のプロトコルも、クライアントとサーバーの実際の設定を確認してください。
| 確認項目 | 確認できること | それだけでは確認できないこと |
|---|---|---|
| クライアントが接続済み | クライアントが報告する接続またはプロキシの状態 | すべてのアプリがトンネルを経由していること |
| Webページに表示されるIPアドレス | そのWebリクエストで外部に表示されたアドレス | 他のアプリ、DNS、すべてのアドレスファミリーの通信経路 |
| DNSテストの結果 | そのテストで名前解決に使われたサーバーの手がかり | 名前解決リクエストの全経路と暗号化の有無 |
| クライアントの接続ログ | 適用されたルール、選択された出口、処理されたリクエスト | クライアントが処理していないすべてのシステム通信 |
IPアドレス：接続前後を比較する
まず、グローバルIPアドレスを表示できる確認ページを選びます。「グローバルIP 確認」などで検索してツールを探せますが、確認のために提供元が不明な拡張機能をインストールしたり、アカウント情報を入力したりしないでください。確認ページにはアクセス元の情報が伝わるため、ツールを選ぶ際はプライバシーに関する説明も確認しましょう。
- 直接接続時の基準を記録する。クライアントを切断し、同じブラウザーで確認ページを開いて、グローバルIPアドレス、ネットワークの事業者情報、ページに表示される地域を記録します。アドレス全体を公開しないでください。
- 接続先の回線を選ぶ。クライアントで選択した回線と動作モードを確認します。比較しやすくするため、テストのリクエストがプロキシ経由になるモードを一時的に選び、確認後は普段のルールに戻してもよいでしょう。
- 新しいテストを実行する。ページのテストを再実行してください。古いスクリーンショットやキャッシュされた内容だけを見ないようにします。接続前後のIPアドレスを比較し、該当するリクエストがクライアントに記録されているかも確認します。
- 結果を読み取る。アドレスが変わり、リクエストが想定した出口に一致する場合は、有効な判断材料になります。アドレスが変わらない場合は、まずテスト用ドメインがルールで直接接続に指定されていないか確認し、そのうえで接続に問題がないかを調べます。
IPアドレスの地域情報はデータベースに基づくため、反映が遅れていたり、アドレスの登録情報だけを示していたりする場合があります。クライアントに表示された地域と確認サイトの表示が異なっても、それだけで回線が機能していないとは判断できません。ネットワークの事業者情報、回線の説明、実際のリクエストログを照らし合わせ、必要に応じてサポートに問い合わせてください。
同様に、Webサイトが開けることだけでは接続が有効とは確認できません。もともと直接アクセスできるサイトだったり、ページの主要部分がキャッシュから読み込まれたりする場合があります。反対に、出口が正しくてもサイトが開けない場合は、サイト側の不正利用対策、アカウント制限、出口の拒否が原因かもしれません。クライアント全体が機能していないとは限りません。
DNSチェック：名前解決の設定を確認
DNSはドメイン名をネットワーク上のアドレスに変換します。DNSリークとは一般に、名前解決のリクエストが想定したトンネルや設定を通らず、関与させたくないネットワーク上のDNSリゾルバーに問い合わせが届く状態を指します。DNSとWebアクセスの出口は別々に確認する必要があります。Web通信がプロキシを経由していても、DNSは異なる設定で動作していることがあります。
未接続の状態でDNSテストを行い、リゾルバーの情報を記録してから、接続先の回線を選んでもう一度テストします。テストでは通常、新しく生成されたドメインへのアクセスを通じて名前解決に関与したサーバーを特定するため、実際にテストを実行する必要があります。結果ページを更新するだけでは、新しい問い合わせが発生するとは限りません。
- ✅ クライアントがDNSを処理しているか、またルールモードで一部のドメインがローカルDNSを使う設定になっていないか確認します。
- ✅ ブラウザーの「セキュアDNS」設定を確認し、システム設定を使うのか、指定された暗号化DNSサービスを使うのか把握します。
- ✅ 接続ログとリゾルバーの事業者情報を照らし合わせ、設定した方針に沿った結果か確認します。
- ❌ リゾルバーの地域と出口の地域が異なるという理由だけで、DNSリークと判断しないでください。
ブラウザーがDNS over HTTPSを使うと、システムで設定したリゾルバーを経由しない場合があります。ただし、DNSサービスへの接続自体はプロキシ経由の可能性があります。パブリックDNSが分散ネットワークを使っている場合、テストに表示される場所と出口が一致するとは限りません。そのため、「パブリックDNSが表示された」だけではリークとは言えず、「ローカル事業者名が表示されない」だけでプライバシーが十分に保護されているとも言えません。
見慣れないアドレスにDNS設定を安易に変更しないでください。まず、名前解決、リモートDNS、分割トンネルに関するクライアントの説明を読み、設定は一度に一項目ずつ変更して、変更前後の結果を記録しましょう。
テストにローカルネットワークのリゾルバーが表示され、すべてのDNSリクエストをトンネル経由にしたい場合は、クライアントのDNS処理、ブラウザーによる設定の上書き、システム設定を確認してください。変更後は古いテストページを閉じて、もう一度テストを実行します。原因を特定できない場合は、個人情報を伏せた結果とクライアントの設定を用意してサポートに相談してください。
アプリごとに確認する：ブラウザーだけでは不十分
システムプロキシの設定にすべてのアプリが従うわけではありません。独自に接続を確立するアプリ、特定のプロキシ方式しかサポートしないアプリ、新しい設定を読み込むために完全終了が必要なアプリもあります。ブラウザーのテストに成功したら、同じWebページを何度も開くのではなく、実際に使うアプリも確認しましょう。
Windows、macOS、Linuxでは、クライアントがシステムプロキシ、TUNモード、その他のトンネルモードのどれで動作しているか確認します。TUNを使うと処理できる通信の範囲が広がりますが、ルーティング、ルール、権限、除外設定の影響は受けます。「グローバル」と表示された設定も、処理対象のリクエストをすべてプロキシに通すという意味にとどまり、すべてのプログラムを対象にしているとは限りません。
iOSとAndroidでは、システムのVPN状態とクライアントのアプリ除外設定を確認します。Androidのクライアントには、アプリごとにプロキシを設定できるものがあります。iOSでどこまで通信が対象になるかは、クライアントの実装とシステム設定によって異なります。ステータスバーの表示は参考情報にとどめ、対象アプリから新しいリクエストを送って確認してください。
- 対象のアプリを開き、コンテンツの更新や新しいページの読み込みなど、ネットワーク通信を確認できる操作を行います。
- クライアントのログを確認し、該当するドメインや接続が記録されているか、直接接続とプロキシのどちらのルールが適用されたかを調べます。
- ログにリクエストが見つからない場合は、アプリの除外設定、プロキシ対応状況、クライアントの権限を確認してください。ログが有効になっていないだけの可能性もあります。
- 設定を変更した後は、対象アプリを再起動してもう一度確認します。回線の変更、ルールの変更、DNSの変更を同時に行うと、どの変更が有効だったのか分かりにくくなります。
コマンドラインツールの通信経路は、ブラウザーと異なる場合があります。ターミナルのプログラムがデスクトップのシステムプロキシを自動的に使うとは限らず、プロキシ環境変数もすべてのツールで利用できるとは限りません。ターミナルで確認する場合は、使用するツールのプロキシ設定やオプションを調べてください。ブラウザーの結果をそのまま当てはめることはできません。
IPv6とWebRTC：別経路も確認する
端末がIPv4とIPv6の両方でインターネットに接続できる場合があります。トンネルが一方のアドレスファミリーしかカバーしていないと、アプリがもう一方の経路で接続する可能性があります。IPv4とIPv6のグローバルアドレスを個別に表示できるツールを選び、接続前後で両方を確認してください。一方のアドレスしか表示されないからといって、もう一方の通信も処理されているとは判断できません。
接続後もIPv6アドレスが直接接続時の基準と同じで、クライアントがすべての通信を対象にする設定の場合は、IPv6のルーティングとサポート範囲を確認してください。クライアントの公式案内に沿って対処し、システム側でIPv6を無効にする方法がすべての端末に適用できると考えないでください。IPv6が表示されない場合も、現在のネットワークやテストツールが対応していない可能性があります。
WebRTCはブラウザーのリアルタイム通信に使われ、通常のWebリクエストとは異なる経路を通る場合があります。テストにローカルIPアドレスや、隠す処理が施されたローカル識別子が表示されても、グローバルIPアドレスが漏れているとは限りません。直接接続のグローバルIPアドレスが表示された場合は、ブラウザー、クライアントのUDP処理、ルーティング設定を確認してください。
Web上のテストツールで確認できるのは、それぞれのツールが発生させたリクエストに限られます。問題の手がかりにはなりますが、端末に迂回経路が一切ないことや、出口のIPアドレスだけでトンネルの暗号化方式を証明することはできません。暗号化設定を確認する場合は、実際のプロトコルとトランスポートの設定を参照してください。より詳しい調査が必要な場合は、経験のある人にシステムのルーティングやパケットキャプチャの分析を依頼できます。
よくあるトラブル：症状から原因を探す
まず、「想定した出口を通っていない」のか、「出口を通っているがアクセスできない」のかを切り分けましょう。直接接続、中継、IEPL専用線といった回線の種類は、主に通信経路や回線の構成を表すものであり、端末のDNS、ブラウザー、アプリごとのルーティングが適切かどうかを自動的に決めるものではありません。回線を変更しても、端末側の通信処理に関する問題がすべて解決するわけではありません。
| 症状 | まず確認する項目 | 次に行うこと |
|---|---|---|
| 接続済みだがWebのIPアドレスが変わらない | テスト用ドメインが直接接続になっていないか、ブラウザーのプロキシ設定 | ルールを確認してテストを再実行 |
| ブラウザーでは使えるが、他のアプリでは使えない | アプリの除外設定、システムプロキシへの対応、トンネルモード | アプリのリクエストログを確認し、必要に応じて通信の処理範囲を調整 |
| 出口は変わったが、DNSの結果が想定と異なる | クライアントのDNS設定、ブラウザーのセキュアDNS | 名前解決の方針を決めてから、一項目ずつ調整 |
| 出口は正しいが、Webサイトにアクセスを拒否される | サイトのエラーメッセージ、アカウントの地域設定、出口に対する制限 | サイトのポリシーと回線の問題を切り分ける |
| ネットワークを切り替えると結果が変わる | 接続の復旧状況、システムのルーティング、新しいネットワーク設定 | 接続を確立し直し、IPアドレスと名前解決を再確認 |
クライアントで選択できる回線がない場合や設定の更新に失敗する場合は、ユーザーパネルにログインして、サブスクリプションの状態とクライアントの互換性を確認してください。サブスクリプションリンクは回線設定を取得するためのもので、接続の成功を証明するものではありません。更新後も回線を選択し、上記の手順で検証してください。また、サブスクリプションリンク全体をテストサイトに送らないでください。
確認結果のまとめと定期チェック
確認結果は、具体的に記録すると役立ちます。たとえば、対象ブラウザーの出口が選択した回線に合っている、DNSの結果が設定した方針に沿っている、普段使うアプリのリクエストに想定したルールが適用されている、対象となるアドレスファミリーも確認済み、といった内容です。「すべて正常」とだけ記録するより、次に問題が起きたとき、どこが変わったかを把握しやすくなります。
クライアントの変更、分割トンネルルールの変更、OSのアップデート、ネットワークの切り替え後には、同じ手順で再確認できます。スクリーンショットやログを共有する前に、グローバルIPアドレス全体、ユーザー名、サブスクリプションリンク、アクセスしたドメインのうち機微なもの、認証情報を隠してください。サポートを求める際は、端末のOS、クライアント名、動作モード、症状を伝えると調査を始めやすくなります。