VPNが接続済みなのに使えない場合は、まず出口IP、次にDNS、最後にアプリごとの通信を確認しましょう。接続アイコンが示すのは接続処理の一部が確立したことだけで、実際にアクセスできるかどうかは別途確認が必要です。何度も接続ボタンを押すのではなく、リクエストがどこから送信され、ドメインがどこで名前解決され、対象アプリの通信がルールに適用されているかを確認します。
接続と通信の振り分けを区別する
一般にVPNクライアントと呼ばれるものには、OSのVPNインターフェースでトンネルを確立するものもあれば、主にローカルプロキシを提供するものもあります。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは方式です。名称だけで端末全体の通信が自動的に経由すると判断することはできません。実際に対象となる範囲は、クライアント、動作モード、振り分け設定によって異なります。
デスクトップの「システムプロキシ」は通常、その設定に従うプログラムにのみ適用されます。独自のネットワーク設定を使うアプリは、自動的にプロキシを利用しない場合があります。TUNモードや仮想ネットワークアダプターは、より多くの通信を取り込めますが、ルーティング、除外設定、OSの権限にも左右されます。AndroidのVPNアイコンは、OSの関連インターフェースが確立したことを示すもので、すべてのアプリが除外されていないことまでは保証しません。
接続が確立していても、実際のリクエストが正常に完了しないことがあります。クライアントが接続先に到達できても、出口、ドメインの名前解決、アクセス先のサイトが正常とは限りません。IEPL専用線、中継、直結は回線の経路や伝送方式を示すもので、通信を取り込む範囲とは別の話です。アプリごとの確認の代わりにもなりません。
| 確認できた現象 | 考えられる原因 | 優先して確認する項目 |
|---|---|---|
| クライアントは接続済みだが、ブラウザーの出口IPが変わらない | 確認サイトがルールで直結になっている、またはブラウザーがプロキシを使っていない | システムプロキシ、ブラウザー拡張機能、確認用ドメインに適用されたルール |
| ブラウザーの出口IPは変わったが、特定のアプリで接続できない | アプリが対象外になっている、古い接続を保持している、またはサーバー側でアクセスが拒否されている | アプリごとの設定、再起動後の動作、具体的なエラーメッセージ |
| ドメインにアクセスできないが、クライアントは接続済みと表示される | 名前解決の失敗、ルールの誤り、出口またはアクセス先の異常 | DNSログ、接続ログ、ほかのアクセス先サイト |
| ネットワークを切り替えた後に使えなくなった | ローカルネットワークの制限、トンネルの再接続失敗、名前解決キャッシュの残存 | 基本的なインターネット接続、再接続の状態、クライアントの診断情報 |
出口IPを確認する：比較用の情報を記録
出口IPは、ウェブサイトから見えるリクエストの送信元アドレスであり、端末のローカルネットワーク上のアドレスではありません。まずクライアントを切断し、信頼できるパブリックIP確認サイトを開いて、アドレスとネットワークの情報を記録します。次に回線を選んで接続し、同じブラウザーで同じページを再読み込みします。地域名だけでなく、IPアドレス自体とネットワーク情報もあわせて比較してください。
- 接続を切り、通常のウェブサイトにアクセスできることを確認して、直接接続時のパブリックIPアドレスを記録します。基本的なインターネット接続に問題がある場合は、先にローカルネットワークを確認してください。
- 回線に接続し、設定が有効になっていることを確認します。IP確認ページを更新してください。必要に応じて古いタブを閉じ、新しいページを開き、キャッシュされた結果を使わないようにします。
- クライアントの接続ログを確認し、確認用ドメインに直結ルールとプロキシルールのどちらが適用されたかを見ます。ルールモードでは、確認サイトが直結でも、ほかのサイトも直結とは限りません。
- クライアントが対応している場合は、テスト対象のリクエストに適用されるプロキシルールを一時的に設定して再確認します。完了したら元の設定に戻し、実際に使うアプリでも確認してください。
回線でIPv4とIPv6の処理方法を選べる場合は、両方のアドレスを個別に確認します。一方のリクエストはプロキシ経由でも、もう一方がローカルネットワーク経由だと、確認結果が一致しないことがあります。クライアントがIPv6を完全に取り込めない場合は、説明書を確認し、対応するルーティングや制限の設定を選びましょう。システムのネットワーク設定をむやみに変更するのは避けてください。
DNSを確認する：名前解決の経路を見る
DNSはドメイン名をIPアドレスに変換する仕組みです。通信がプロキシ経由でも、DNSクエリが同じ経路を使うとは限りません。名前解決は、OS、クライアント、ブラウザーのセキュアDNS、またはアプリ内蔵のリゾルバーが行うことがあります。一般にDNS漏れとは、本来は指定したトンネルやプロキシのポリシーで保護されるはずのクエリが、ローカルネットワークから外部へ送信されることを指します。
接続中に信頼できるDNS確認サイトを使い、検出されたDNSサービスと地域を確認して、クライアントのDNS設定と照らし合わせます。確認サイトに表示されるのは、多くの場合、再帰リゾルバーの出口であり、端末からリゾルバーまでの通信経路全体ではありません。そのため、サービス名だけを根拠に漏れがある、または保護されていると判断することはできません。
結果に食い違いがある場合の確認方法
- クライアントでDNS通信の取り込みが有効か、直結ドメインとプロキシ経由のドメインで異なる名前解決ポリシーが使われているかを確認します。ルールモードでは、一部の名前解決をローカルに残す設定が意図されている場合もあります。
- ブラウザーのセキュアDNS設定を確認します。ブラウザーが独自に暗号化DNSを使うと、OS側とは異なる結果になることがあります。暗号化DNSはクエリの通信を保護しますが、リクエストが自動的にプロキシ経由になるわけではありません。
- 設定を変更したら接続を確立し直し、OSまたはブラウザーの案内に従ってDNSキャッシュを消去します。古いキャッシュが残っていると、新しい設定の効果がすぐに確認できない場合があります。
- 原因が分からない場合は、クライアントのログでDNSクエリの経路を確認します。ログを共有する前に、サブスクリプション情報、アカウント情報、不要なアクセス履歴を隠してください。
DNSを特定のパブリックリゾルバーに変更しただけで、問題が解決したと考えないでください。リゾルバーの場所、クエリの送信経路、IPアドレス取得後の通信経路は、それぞれ別の問題です。また、ドメイン名の代わりにサイトのIPアドレスへ直接アクセスして判断するのも避けましょう。HTTPS証明書、バーチャルホスト、コンテンツ配信の仕組みにより、ネットワーク経路に問題がなくてもアクセスに失敗することがあります。
ブラウザーだけでなくアプリごとに確認する
ブラウザーでの確認が済んだら、実際に使うアプリでもテストします。新しい内容を読み込めるかを確認し、新しいページを開く、データを更新する、通常のリクエストを送るなど、一般的な操作を試してください。キャッシュ済みのホーム画面や過去の内容が表示されても、現在の接続が有効とは限りません。ログインに失敗しても、ネットワークではなく、アカウントの状態、地域ごとのポリシー、サーバー側のリスク判定が原因の場合があります。
WindowsやmacOSでは、まずアプリがシステムプロキシに従うか確認します。アプリに独自のプロキシ設定がある場合は、互いに競合するアドレスを同時に指定しないようにしてください。ターミナルのプログラムはプロキシ環境変数を参照することもあるため、ブラウザーでは使えてもコマンドラインでは失敗することがあります。TUNモードの対応状況や必要な権限は、使用中のクライアントの説明を確認してください。
Androidのクライアントには、アプリごとのプロキシ設定やバイパスリストが用意されていることがあります。対象アプリが通信の取り込み範囲に含まれているか、バックグラウンドの省電力制限でクライアントが停止していないか確認してください。iOSでは、現在のVPN設定とクライアントのルールを確認します。オンデマンド接続を使う場合は、設定が保存されているだけでなく、テスト時に実際に接続が開始されているかも確かめてください。
- ✅ 対象アプリがアプリ別のルールで除外されていないこと、ドメインに誤って直結ルールが適用されていないことを確認する。
- ✅ 回線を切り替えたら対象アプリを完全に終了してから開き直し、古いセッションではなく新しい接続を確立する。
- ✅ ブラウザーと実際に使うアプリを個別にテストし、それぞれの結果を記録する。ブラウザーで成功しても、端末全体で成功したと判断しない。
- ✅ 具体的なエラーメッセージを記録し、タイムアウト、名前解決エラー、証明書エラー、アカウントのアクセス制限を区別する。
- ❌ キャッシュ済みのページが開くこと、接続アイコンが点灯すること、特定の確認サイトで成功することだけを判断材料にしない。
まだ使えない場合：順番に原因を絞り込む
確認作業では、一度に変更する設定を一つに絞ります。ノード、DNS、プロトコル、振り分けモードをまとめて変更すると、アクセスが回復しても原因を特定できません。まず現在の設定をバックアップし、通信を取り込む範囲から始めて、名前解決と回線を順に確認しましょう。権限の確認が表示された場合は、提供元と用途を確認してください。アイコンを点灯させるためだけに、すべての権限を許可しないでください。
設定を確認してから回線を確認する
クライアントの設定画面を開き、想定した設定が選択されていることを確認します。サブスクリプションURLはノードやルールを取得するためのものですが、インポート後も自動で更新され続ける保証ではありません。クライアントの対応する方法でサブスクリプションを更新し、成功したかを確認してから、選択したノードが現在の設定に含まれているかを見ます。インポートに失敗した場合、サブスクリプション形式とクライアントのコアが互換性を持たない可能性があります。ファイルの拡張子を変えて解決しようとしないでください。
続いて、ほかのプロキシクライアント、ブラウザーのプロキシ拡張機能、ネットワークフィルターツールが同時に動作していないか確認します。システムプロキシ、ルーティング、DNSを取り合うことがあります。不要な同種のツールを一時的に停止して再試行します。ただし、試しにシステムのセキュリティ機能を無効にするのは避けてください。会社や学校が管理する端末では、管理者のポリシーに従い、管理設定を独自に回避しないでください。
別の条件でも確認する
同じ端末で別の回線に切り替えて復旧した場合、原因を元の回線、またはそこから対象サービスまでの経路に絞れます。同じ回線のまま別のネットワークに接続して復旧した場合は、ローカルネットワークの制限を優先して確認しましょう。公衆Wi-Fiでは、先にログイン画面で認証が必要なこともあります。まずプロキシを切断して通常のインターネット接続を確認してから再接続し、認証が完了していない状態をサービス障害と誤認しないようにしてください。
どのような結果なら確認できたと言えるか
実用的な判断基準は、回線を経由させたいリクエストに想定したルールが適用され、出口IPが期待どおりで、DNSの動作も説明でき、対象アプリで実際の操作ができることです。ルールで通信を振り分けている場合、日本国内のサイトが直結でも失敗ではありません。端末全体の通信を取り込みたい場合は、除外設定、IPv6、システムプロキシに従わないプログラムも確認してください。
サポートに問い合わせるときは、OS、クライアント名、動作モード、選択中の回線、テスト時刻、個人情報を隠したエラー内容を伝えれば十分です。「ブラウザーの出口IPは変わったが、対象アプリで接続がタイムアウトする」と伝えるほうが、「VPNが使えない」とだけ伝えるより原因を特定しやすくなります。パスワード、完全なサブスクリプションURL、確認していないログは添付しないでください。
設定方法が分からない場合は、まず初心者向けガイドで利用するプラットフォームの設定と接続手順を確認してください。回線情報はグローバルノードのページで確認できます。特定のサイトにアクセスできるかどうかは、地域、アカウント、アクセス時の状況も踏まえて確認する必要があります。