「VPNに接続したのに反映されない」は初心者が最も戸惑いやすいポイントです。クライアントは接続済みと表示しているのにページが開かない、開いても表示されるのがローカルのアドレスのまま——。判断の方法はとてもシンプルで、通信がどのアドレスから出ているかを見るだけです。この記事では出口IP、DNS解決、アプリ別検証の3ステップを順にたどり、それぞれ具体的な操作と判断基準を示します。読み終われば、問題がどの層で止まっているか自分で切り分けられるようになります。
接続≠反映:まず通信が通っているか確認
クライアントの「接続済み」が意味するのは、クライアントとサーバーの間に暗号化トンネルが確立したこと、つまりトンネルが通ったことだけです。システム上のすべてのアプリがこのトンネルから出ていくことを保証するものではありません。この2つはよく混同され、「接続済みなのに反映されない」という疑問につながります。
クライアントが通信を引き受ける方式は主に3つあり、それぞれカバーする範囲が異なります:
- システムプロキシ:システムプロキシ設定を読み取るアプリにだけ作用します。ブラウザは通常読み取りますが、コマンドラインツールや多くのデスクトップアプリは読み取りません。
- TUN / 仮想NIC:システムのルーティングテーブルを書き換え、NIC層で通信を引き受けます。カバー範囲が最も広く、ほとんどのアプリが対象になります。
- アプリ別プロキシ:選択したアプリだけを引き受け、リスト外のアプリはこれまで通り直接接続します。
つまり「接続済みなのに反映されない」の多くは、回線が壊れているのではなく、引き受け範囲が使いたいアプリまで届いていないだけです。ここを押さえておけば、あとは一つずつ確認していくだけです。
システムプロキシモードでは、ターミナルの curl や一部のデスクトップアプリはシステムプロキシを読み取らないため、通信は直接接続のままです。これは故障ではなく、このモードのカバー範囲によるものです。
ステップ1:出口IPが変わったか確認する
出口IPとは、外部のサイトから見えた「あなた」のことです。接続前後の出口IPを比べるのが、最も直接的で間違いの少ない判断方法です。
- まず接続を切り、任意のIP確認ページを開いて現在の出口IPと所在地をメモします。
- 接続して、同じページを再読み込みし、もう一度メモします。
- 2回のアドレスが異なり、2回目の所在地が選んだ地域であれば、通信はトンネルを通っています。
- 2回が完全に同じなら、いま使っているアプリはトンネルを通っていません。次の項目へ進みましょう。
ページを開きたくない場合は、OS標準のコマンドで確認する方法もあります:
# macOS / Linux
curl -s https://api.ipify.org
# Windows PowerShell(Windows 10 / 11 は curl.exe 標準搭載)
curl.exe -s https://api.ipify.org
# プロバイダーと都市まで見たい場合はこちらに差し替え
curl -s https://ipinfo.io/json
コマンドラインの結果とブラウザの結果が一致しないのはよくあることです。ブラウザはシステムプロキシを読み取り、ターミナルは読み取りません。この違い自体が役に立ち、クライアントが現在どの引き受けモードで動いているかを判断する手がかりになります。
出口IPがまったく変わらない場合、原因はたいてい次のいずれかです:
- クライアントがシステムプロキシモードで、使っているアプリがシステムプロキシを読み取らない。
- 分流ルールが現在のドメインを直接接続と判定している。
- システム上で別のプロキシツールも動いていて、2つのクライアントが引き受けを奪い合い、後から起動した方が優先されている。
- ブラウザにプロキシ系の拡張機能が入っていて、その設定がシステムプロキシを上書きしている。
ステップ2:DNSが漏洩していないか確認する
DNSはドメイン名をIPアドレスに変換する役割を持ちます。トンネルがWebの通信を引き受けていても、名前解決がローカルのプロバイダーに送られたままだと、「接続はできるのに開くサイトが違う、あるいは開けない」という状態になります。これがよく言われるDNSリークです。
確認方法は2つ、どちらか一方で構いません:
- 任意のDNSリーク検出ページを開き、表示されるリゾルバーの所在地を確認します。接続後にリストがローカルのプロバイダーばかりなら、名前解決のリクエストがトンネルを通っていません。
- コマンドライン:macOS / Linux では
dig +short whoami.akamai.netを実行します。返ってくるのは再帰リゾルバーから見た出口アドレスで、名前解決のリクエストがどこから出ているかの判断に使えます。Windows ではnslookupで照合できます。
分流モードでは、国内ドメインがローカルDNSを使うのは設計の一部であり、リークには当たりません。リークかどうかは、アクセスする海外ドメインも海外の出口で解決されているかどうかだけで判断します。
名前解決が実際にローカルを通っていると確認できたら、次の順で対処します:
- クライアントでDNSの引き受けを有効にします。クライアントによっては「DNS保護」や「暗号化DNS」と呼ばれます。
- ブラウザで「セキュアDNS / DoH」を有効にしている場合は、いったんオフにするか、クライアントと同じ設定にします。クライアントのDNS引き受けを迂回してしまうことがあります。
- 変更したら一度再接続し、上記のチェックをもう一度実行して、解決の出口が変わったか確認します。
ステップ3:アプリごとに検証する
同じアドレスでもアプリによって結果が変わる——これは切り分けで最も情報量の多いステップです。
ブラウザ
シークレットウィンドウで目的のサイトを開きます。シークレットでは開けて通常ウィンドウでは開けない場合、何らかの拡張機能がリクエストを書き換えている可能性が高く、一つずつ無効化すれば特定できます。
ターミナル
コマンドラインはシステムプロキシを読み取りません。トンネルを通したい場合は、クライアントをTUNモードに切り替えるか、環境変数を一時的に設定します。ポートはクライアントに表示されている値に合わせてください:
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -s https://api.ipify.org
設定後に出口IPをもう一度確認し、アドレスが変わっていればターミナルもトンネルに入っています。
デスクトップアプリとモバイル
- デスクトップアプリの多くは独自のプロキシ設定を持ち、初期値は「プロキシを使用しない」です。手動で「システム設定を使用」に変更するか、ローカルアドレスとポートを入力する必要があります。
- モバイルのアプリ別プロキシは選択したアプリにだけ作用し、リスト外のアプリは直接接続になります。「接続はできているのに特定のアプリが開けない」という症状はこれが原因です。
- iOSでは低電力モードとバックグラウンド更新の仕様により、長時間のバックグラウンド接続が切れることがあります。長くバックグラウンドに置いた後に開くときは、まずクライアントの接続状態を確認しましょう。
「接続済みなのに反映されない」代表的なケースと対処
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| 出口IPがまったく変わらない | クライアントがシステムプロキシモードで、現在のアプリがシステムプロキシを読み取らない | TUN / 仮想NICモードに切り替えるか、アプリ側で手動でプロキシを設定する |
| 特定のアプリだけ開けない | アプリ別プロキシのリストに入っていない | リストに追加するか、全体を引き受ける設定に変更する |
| ページは開けるが内容が違う | ドメインが分流ルールで直接接続と判定されている | ルールを確認し、そのドメインをプロキシ対象に追加する |
| 解決結果がローカルを指している | DNSがトンネルを通っていない、またはブラウザのセキュアDNSが迂回している | DNSの引き受けを有効にし、ブラウザのDoHをオフにする |
| 接続後に遅くなる、一部のサイトがタイムアウトする | 2つのプロキシツールが同時に動き、引き受けを奪い合っている | 片方だけ残し、もう片方はバックグラウンドプロセスごと終了する |
| しばらく使うと切れて、手動で再接続が必要になる | スリープや省電力設定がトンネルを切断している | 該当する省電力制限を解除し、クライアントの自動再接続を有効にする |
同じ端末ではプロキシツールを1つだけにしてください。2つのクライアントを同時に動かすと、後から起動した方が引き受けを奪い、「つないだ直後は大丈夫なのに、しばらくするとまたダメになる」という症状になります。
- ❌ クライアントが「接続済み」と表示しているだけで成功と判断し、出口アドレスを確認しない。
- ❌ 国内ドメインがローカルDNSを使うのをリークと決めつけ、設定を何度も変えてしまう。
- ❌ 切り分け中に2つのプロキシツールを同時に起動し、変数を増やしてしまう。
- ❌ ブラウザだけで検証し、ターミナルやデスクトップアプリがシステムプロキシを読み取らないことを忘れる。
- ✅ 回線を切り替えるたびに、出口IPとDNSの出口を確認し直す。
- ✅ まずプロキシツールを1つだけにし、「出口IP → DNS → アプリ別」の順で確認する。
3分自己点検の手順
上記の3ステップを決まった流れにまとめました。今後、回線や端末を変えるたびにこの順で確認してください:
- 接続を切り、出口IPと所在地を確認してメモします。
- 接続し、ページを再読み込みして、出口IPが変わっていること、所在地が選択した地域であることを確認します。
- DNSリーク検出ページを開き、解決の出口も海外にあることを確認し、ついでにブラウザのセキュアDNSもオフにします。
- シークレットウィンドウとターミナルから同じサイトに一度ずつアクセスし、結果が一致すればシステム全体の引き受けは正常です。
- アプリ別のリストと分流ルールを確認し、目的のアプリとドメインが引き受け範囲に入っていることを確かめます。
- 3項目すべて通れば本当に反映されています。どれか1つだけ通らない場合は、前節の対照表に沿って対処してください。
出口IPが変わった、DNSの出口が海外にある、目的のアプリが開ける——この3つが同時に満たされれば、今回の接続は本当に反映されていると確認できます。
回線を変える前に確認したい二点
3項目の自己点検で「開けない」だけが通らない場合、多くの人はまず回線を変えようと考えます。その前に2つ確認しておくと、無駄な往復をかなり減らせます。
プランと通信量の状態
月額プランの通信量は契約日ごとに毎月リセットされます。その月の通信量を使い切ると、「接続はできるのに開けない」という症状になりがちです。通信量パックは買い切りで、使い切るまで有効・期限なしなので、いつでも追加できます。
回線タイプの違い
- IEPL専用線:独立したチャネルを使うため、夜のピーク時間帯でも安定し、安定性が求められる用途に向いています。
- 中継:入口が国内にあり、1ホップ増えますが、振り分けの自由度が高くなります。
- 直結:ローカルから海外ノードへ直接接続するため、国際帯域の変動の影響を受けやすくなります。
同じ地域の別の回線に切り替えて、もう一度出口IPのチェックを実行します。アドレスが変わってサイトが開けるなら元の回線の問題、アドレスが変わらないなら問題は端末側の設定にあります。
結論:「接続したかどうか」ではなく「反映されているかどうか」は、次の3点だけで判断できます。出口IPが変わったか、DNSの出口が海外にあるか、目的のアプリが実際に開けるか。3つすべて通れば設定をいじる必要はありません。どれか1つでも通らない場合、原因はほぼ引き受けモード、分流ルール、2つ目のプロキシツールのいずれかで、回線そのものとは関係がありません。