VPNに接続しても効果がない場合は、まず出口IP、次にDNS、最後にアプリごとの通信経路を確認します。接続アイコンが示すのは、クライアントの接続処理の一部が完了したことだけです。ブラウザーやデスクトップアプリ、バックグラウンド通信まで想定どおりの経路を使っているとは限りません。「接続成功」と「通信の振り分け成功」は分けて考えましょう。
ノードを何度も切り替えるより、未接続時の状態を記録し、同じアプリから同じ接続先へ再度アクセスする方法が確実です。以下の手順は、OS標準のVPNだけでなく、サブスクリプションから設定を読み込むクライアントや、システムプロキシ・仮想NICを使うクライアントにも使えます。設定名はクライアントの画面に表示される名称を確認してください。
まず確認：接続状態から分かること
プロキシコアの起動時点で「実行中」と表示するクライアントもあれば、リモートノードとのハンドシェイクを検証するものもあります。OS標準のVPNでは、トンネルインターフェースも作成されます。これらはそれぞれ異なる段階を示すもので、特定のアプリがどの経路を使っているかまでは分かりません。最終的な出口は、システムプロキシ、ルーティングテーブル、アプリ固有の設定、ルーティングルールによって決まります。
| 確認できた現象 | 分かること | まだ分からないこと | 次に確認する項目 |
|---|---|---|---|
| クライアントに接続済みと表示される | クライアント上の接続処理が完了した | すべてのアプリの通信がVPN経由になっている | 動作モードとルーティングを確認 |
| ブラウザーの出口IPが変わった | そのWebリクエストが別の出口を使った | 他のアプリやDNSも同じ経路を使っている | 対象アプリと名前解決の経路を確認 |
| DNSテストで別の場所のリゾルバーが表示された | テストの問い合わせが該当する再帰リゾルバーを経由した | すべてのドメイン名がルールどおりに解決されている | クライアントのDNS設定とログを確認 |
| 対象サイトで地域制限が表示される | サイトが今回のアクセスを許可しなかった | トンネルが必ず機能していない | 出口IP、アカウントの地域設定、サイトのルールを確認 |
つまり、「Webページを開けること」と「すべての通信が想定どおりであること」は別です。まず、指定したサイトだけをVPN経由にしたいのか、クライアントが対応するアプリの通信をまとめてトンネルに通したいのか、目的を明確にしましょう。目的によって、確認すべき結果も異なります。
出口IP：同じブラウザーで接続前後を比較
- 接続前の状態を記録します。クライアントを切断し、ブラウザーでグローバルIPアドレスを確認して、アドレス、ネットワークの所属先、おおよその地域を控えます。確認ページにネットワーク情報が表示される場合があるため、結果をそのまま公開しないでください。
- 接続後に再度アクセスします。対象の回線を選び、想定したシステムプロキシまたはトンネルモードが有効か確認してから、確認ページを再読み込みします。ページに残った古い結果だけを見ないようにしましょう。
- ルールを確認します。IPが変わらない場合は、クライアントの接続一覧で確認用ドメインを探し、直接接続とプロキシ接続のどちらに判定されているかを確認します。確認サイトが直接接続ルールに該当していても、他のサイトも直接接続になっているとは限りません。
- IPアドレスの種類ごとに確認します。端末がIPv4とIPv6の両方を利用する場合は、それぞれの出口を確認してください。片方だけ出口が変わっても、もう片方の通信までVPN経由になったとは判断できません。
- 複数の方法で照合します。別々の確認サービスでIPアドレスを調べます。位置情報データベースの更新は遅れることがあります。国や都市の表示が一致しない場合は、地図だけで失敗と判断せず、実際のアドレスとネットワークの所属先を比較してください。
ブラウザーのプロキシ拡張機能を使っている場合、OSのクライアントを確認する際は、設定を記録したうえで競合する拡張機能を一時的に無効にします。社内ネットワーク、別のVPN、セキュリティソフトがルーティングを変更することもあります。確認時は、調べたい通信制御ツールだけを使うのが望ましいですが、組織で必要とされているセキュリティ対策を勝手に無効にしないでください。
DNS：正常な名前解決と意図しない漏えいを見分ける
DNSは、ドメイン名を接続に必要なアドレスへ変換します。Webページの通信がプロキシ経由でも、ドメイン名の問い合わせまで同じ経路を通るとは限りません。アプリが使うDNSは、システムDNS、ブラウザーのセキュアDNS、クライアントのDNSサービスなどさまざまです。接続方式によって、ドメイン名をリモート側で解決する場合もあれば、ローカルで先に解決する場合もあります。
DNSリークに当たるかどうかは、想定しているルールを基準に判断します。対象ドメインをトンネル経由で解決するつもりなのに、意図せずローカルネットワークのリゾルバーへ問い合わせている場合は、設定を確認してください。一方、ルールモードで日本国内のサイトをローカルで解決する設定なら、ローカルのリゾルバーが表示されただけで不具合とは言えません。
- ✅ まずクライアントのDNSモード、上流DNSの設定、DNS問い合わせが制御対象かを確認します。「DNSハイジャック」「DNSルーティング」など、クライアントによって項目名が異なります。
- ✅ DNS確認ページで新しいテスト問い合わせを実行し、切断時の結果と比較します。クライアントに対応する名前解決の記録があるかも確認してください。
- ✅ ブラウザーのセキュアDNS設定も確認します。暗号化DNSは問い合わせの通信を保護しますが、それだけではDNS問い合わせがVPNの出口を通った証拠になりません。
- ❌ リゾルバーの所在国が接続先ノードと異なるという理由だけで、DNSリークと判断しないでください。パブリックDNSは分散型のノードを使う場合があり、確認結果にネットワーク上の所在地が表示されることもあります。
- ❌ 詳細を確認せず、見慣れないDNSアドレスへ変更しないでください。社内ドメインや社内サービス、既存のルーティングルールに影響しないよう、まずクライアントのドキュメントを確認します。
DNS確認ページで通常確認できるのは、テスト用ドメインへの問い合わせを処理した再帰リゾルバーです。端末が直接接続しているサーバーとは限りません。システムとブラウザーの設定、クライアントのログをあわせて確認してください。キャッシュにより問い合わせが一時的に表示されないこともあります。ログが空だからといって異常と決めつけず、テストを再実行しましょう。
システムプロキシとTUN：一部のアプリだけに適用される理由
システムプロキシは、その設定に従うアプリにプロキシの接続先を提供します。ブラウザーは対応していることが多い一方、一部のデスクトップアプリ、コマンドラインツール、ゲームは設定を無視したり、独自のプロキシ設定を使ったりします。HTTPプロキシやSOCKSプロキシで何ができるかも、クライアントとアプリの実装によって異なります。「システムプロキシ有効」の表示だけで、すべての接続が制御されているとは判断できません。
TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を制御するため、通常はシステムプロキシより広い範囲の通信を扱えます。ただし、アプリの除外設定、対象ネットワーク、DNS、権限、プロトコルの対応状況に左右されます。TUNモードは「すべての通信が必ずリモート経由になる」という意味ではありません。ルールモードでは、TUNに入った通信もクライアントのルールに従って直接接続される場合があります。
アプリごとに通信経路を確認する
まず対象アプリを完全に終了します。回線に接続してからアプリを起動し直し、既存の接続が再利用される可能性をなくします。次に、リモートのコンテンツを更新する、サービスへ再接続するなど、結果を確認しやすい操作を行います。クライアントの接続一覧でアプリのプロセスや対象ドメインを探し、適用されたルール、ポリシーグループ、最終的なノードを確認してください。
クライアントに接続ログがない場合は、対象アプリのネットワーク診断機能や、信頼できるリモート側のセッション記録を参考にします。画面の言語、表示されるおすすめ、アクセス速度の変化だけから出口を正確に特定することはできません。テスト目的でも、アクセストークン、サブスクリプションURL、パスワードを見知らぬ確認ツールに送らないでください。
Windowsでは、独自のプロキシスタックを使うアプリがあります。macOSでは、クライアントに必要なネットワーク権限が許可されているか確認します。iOSとAndroidでは、OSのVPN接続状態と、アプリ単位の除外設定を確認してください。Linuxでは、デスクトップのプロキシ設定とターミナルの環境変数が連動しない場合があるため、それぞれ個別に検証します。
システムコマンドで確認する：設定を結果と混同しない
以下のコマンドは関連する設定を表示するだけで、ネットワーク設定は変更しません。アプリがどの経路を使う可能性があるかを知る手がかりにはなりますが、出口IPやアプリの実際の通信経路を確認する代わりにはなりません。該当するOSのターミナルで実行し、別のOS向けのコマンドをそのまま貼り付けて実行しないでください。
macOS：システムプロキシとDNS設定を確認
scutil --proxy
scutil --dns前者はシステムプロキシ関連の設定、後者はDNSリゾルバーと適用範囲を表示します。プロキシアドレスが表示されても、分かるのは設定が存在することだけです。アプリが設定に従うか、プロキシの接続先が利用可能かは、実際に試して確認する必要があります。システムに複数のDNSリゾルバーが表示されることもあり、特定の行だけをすべての問い合わせ先とみなさないでください。
Windows：WinHTTPとDNSの設定を個別に確認
netsh winhttp show proxy
Get-DnsClientServerAddress後者はPowerShellで実行します。WinHTTPの設定は、一般にブラウザーが使うユーザープロキシ設定とは異なります。そのため、直接アクセスと表示されても、ブラウザーがプロキシを使っていないとは限りません。DNSアドレスの一覧に表示されるのはインターフェースの設定であり、ブラウザーのセキュアDNSやクライアント内部の名前解決経路は含まれない場合があります。
Linux：ターミナルのプロキシ環境変数を確認
env | grep -i proxyプロキシ用の環境変数や、プロキシを経由しない接続先の一覧が設定されていないか確認します。何も表示されなくてもトンネルがないとは限りません。環境変数があっても、すべてのツールがそれを読み取るとは限りません。コマンドの結果を共有する場合は、内部アドレス、ユーザー名、認証情報を含む可能性があるプロキシURLを隠してください。
よくある誤解：現象から問題の箇所を特定する
サブスクリプションは更新できるのに、対象サイトへアクセスできない
サブスクリプションの更新成功が示すのは、設定を取得できたことだけです。ノードが現在接続可能であることや、読み込んだ設定を実際に使用していることまでは分かりません。現在の設定ファイル、選択中のノード、接続ログを確認してください。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルを使うには、クライアントがそれぞれに対応している必要があります。サブスクリプションURLを開けても、すべての項目を正しく処理できるとは限りません。
ブラウザーは使えるのに、他のアプリでは失敗する
まず、アプリがシステムプロキシを無視していないか、独自のプロキシ設定がないか、除外対象になっていないか、必要な通信方式が現在の構成でサポートされているかを確認します。通信がそもそもクライアントに届いていない場合、ノードを切り替えても通常は結果が変わりません。接続経路の範囲に関する問題を、ノードの切り替えだけで解決しようとしないでください。
出口IPが変わったのに、サイトにアクセスを拒否される
サイトはアカウントの地域設定、過去のセッション、位置情報の許可、出口ネットワークの評価なども参照する場合があります。サイトのルールを守ったうえで、アカウントとセッションの状態を確認してください。地域を短時間で何度も切り替えるのは避けましょう。出口IPの変化で分かるのはネットワーク経路が変わったことだけであり、サイトがその出口やアカウントを受け入れる保証にはなりません。
専用線に切り替えても、結果が変わらない
IEPL専用線、中継、直結は、回線の伝送方式を表すもので、アプリの通信をどのように制御するかとは別の話です。ブラウザー拡張機能の競合、DNS設定、誤ったルーティングルールは自動で修正されません。遅延が小さい、速度測定の結果が良いといったことも、経路の確認が取れた証拠ではありません。まず通信先の経路を確認してから、回線の性能を検討してください。
確認結果の判断と問い合わせ時の情報整理
判断基準：対象アプリの実際の通信が想定したルールに該当し、想定した出口を使用していて、関連するDNS問い合わせも設定どおりであれば、そのテストについて「有効」と判断できます。ブラウザーで確認できても、すべてのアプリで確認できたわけではありません。サイトにアクセスを拒否されても、VPNが機能していないとは限りません。
サポートが必要な場合は、端末のOS、クライアント名、現在の通信制御モード、問題が起きているアプリ、対象ドメイン、接続前後で確認した違いをまとめてください。ルール適用の記録やエラーログを、機密情報を隠したうえで添付し、他のVPNやプロキシ拡張機能の有無、社内ネットワークの要件も伝えます。サブスクリプションURL、パスワード、アクセストークン全体は送らないでください。
手順は固定しましょう。まず設定とノードを確認し、次に通信制御の状態、出口IPとDNS、最後に接続先サービス側の制限を調べます。関連する設定を一度に一つだけ変更し、再テストして結果を記録してください。原因の範囲を特定しやすくなり、特定のアプリの問題を解決するために、他のアプリで正常な通信経路まで変えてしまう事態を防げます。
クライアントのインストールとサブスクリプションの追加方法は使い方ガイドをご覧ください。VPNBoatのサービス内容や基本的な使い方についてはよくある質問をご確認ください。ログイン後のパネルからクライアントとサブスクリプションを取得できます。各プラットフォームでの取得条件はパネルをご確認ください。