クライアントに「接続済み」と表示されても、ローカルのトンネルプロセスが起動しただけで、通信が実際に回線の出口から出ているかは分かりません。VPNが有効かどうかの確認手順は決まっています。まず出口IPとその国・地域、次にDNS解決がどこで行われているか、最後にアプリごとの動作確認です。3つすべてを通過して、はじめてその回線が現在の端末で本当に使えると判断できます。
順序を入れ替えてはいけません。切り分けができなくなるからです。先にアプリを試して開けなかった場合、回線が効いていないのか、名前解決が誤っているのか、アプリ側が出口の地域を要求しているのかを区別できません。出口と名前解決の2層を先に確定させれば、残る問題は必ずアプリ側にあります。
3ステップ自己診断の順序と判定基準
次の表が3ステップの全体像です。各ステップには観測できる判定基準があり、最初に不合格になった行で止まり、それを解決してから次へ進みます。
| 順序 | 確認する内容 | 合格基準 | 不合格時の典型的な症状 |
|---|---|---|---|
| 1 | 出口IPと国・地域 | 表示される国が選択した回線と一致する | 依然として国内の国・地域が表示される、または選択した回線の国と一致しない |
| 2 | DNS解決の経路 | 名前解決が回線側で行われ、国内のプロバイダに届かない | 解決サーバーが国内プロバイダのアドレスのまま |
| 3 | アプリ層の疎通 | 目的のアプリを継続して使え、地域制限のエラーが出ない | ページは開くが機能が制限される、または繰り返し認証を求められる |
第2ステップが最も飛ばされやすいところです。IPの国・地域だけ確認して使い始めると、アクセス自体は通じますが、ページの読み込みが遅い、一部のリソースが読み込めない、ログイン時に追加の認証を求められる——こうした症状は回線そのものではなく、名前解決の経路に原因があることが多いです。
自己診断中は変数を1つだけ動かします:回線の切り替え、分割ルールの変更、クライアントの変更を同時に行わないでください。一度に1か所だけ変えれば、成功・失敗がどの設定に対応するのか分かります。
ステップ1:出口IPと国・地域を確認する
出口IPとは、接続先のサイトから見えるアドレスのことで、通信が回線を通っているかどうかを判断する最も直接的な証拠でもあります。確認方法は2つあり、用途が異なります。
GUIでの確認:ブラウザのシークレットウィンドウを開き、アクセス元IPを表示する任意のページにアクセスします。ページにはIPと国・地域が同時に表示されます。シークレットウィンドウを使うのは、キャッシュと拡張機能を避けるためです。ブラウザ拡張のプロキシ設定はクライアントが書き込んだシステムプロキシを上書きするため、通常のウィンドウで確認した結果が思っている回線とは限りません。
コマンドラインでの確認:ブラウザのプロキシ設定に影響されないため、「ブラウザは通っているが他のプログラムは通っていない」といった問題の切り分けに向いています。
# IPだけを取得。スクリプトでの照合に向く
curl -s https://api.ipify.org
# 国・地域とプロバイダも同時に見たい場合はJSONを取得
curl -s https://ipinfo.io/json判定基準は1つだけです。国・地域が選択した回線と一致していること。都市レベルまで求める必要はありません。IPの国・地域データベース自体に誤差があり、データセンターの住所が隣接する都市や隣接する国として登録されることも珍しくありません。香港、東京、シンガポールのようにノードが密集する地域では都市フィールドの参考価値は限られるため、国フィールドを基準にしてください。
IPv6はよくある抜け穴
多くの回線はデフォルトでIPv4のみを引き受けます。端末が利用可能なIPv6アドレスを同時に持っていて、接続先のサイトがIPv6に対応している場合、ブラウザはIPv6の直接接続を優先します。その結果、IPv4の出口は海外にあるのに、実際のリクエストは国内から送られることになります。自己診断の際はIPv6の欄を確認してください。国内のアドレス帯が表示されているなら、IPv6は回線を通っていません。クライアントでIPv6を無効にするか、デュアルスタックを引き受けられるモードに切り替えてください。
注意:設定を変更したら、再接続してから確認してください。一部のOSではネットワークインターフェースの状態変化後にデフォルトルートが再構築され、古いトンネルがデフォルトルート上に残っていないことがあります。
ステップ2:DNSのリークを確認する
DNSリークとは、通信は回線を通っているのに、ドメイン名の解決リクエストが国内プロバイダのDNSサーバーに送られ続けている状態を指します。トンネルが引き受けるのはIP層の通信であり、解決リクエストはトンネル確立前に送信されることもあれば、OSがインターフェースの優先度に従って国内のリゾルバに振り分けてしまうこともあります。
影響は2つあります。1つは解決結果が出口の地域と一致しないことです。CDNは解決元に応じて配信先を決めるため、返ってくるノードが国内に近く出口から遠いものになり、開くのに時間がかかる、一部のリソースが読み込めないといった症状が出ます。もう1つは判定の不整合です。接続先のサービスから見て海外の出口IPと国内の解決元が同時に観測されると、不正利用対策の観点から追加の認証を求められやすくなります。
| プラットフォーム | 確認方法 | 確認する項目 |
|---|---|---|
| Windows | コマンドプロンプトで ipconfig /all を実行 |
「DNS サーバー」の行が国内プロバイダのアドレスかどうか |
| macOS | ターミナルで scutil --dns を実行 |
nameserver[0] が指すアドレス |
| Linux | ターミナルで resolvectl status を実行 |
現在のリンクのDNSと暗号化解決の状態 |
| ブラウザ | 設定で「セキュアDNS」を検索 | 有効かどうか。有効にするとシステムDNSを迂回する |
さらに、解決リクエストが実際にどこへ送られているかを確認します。nslookup または dig で固定のドメインを引くと、出力の Server が現在使われているリゾルバです。それが国内プロバイダを指しているなら、名前解決は回線を通っていません。
nslookup example.com
dig +short example.comブラウザのセキュアDNSはトンネルを迂回する
Chrome、Edge、Firefoxにはいずれも「セキュアDNS」、すなわちDNS over HTTPSが組み込まれています。有効にするとブラウザが独自に暗号化解決を行い、システムのDNS設定を読みません。この場合、クライアントがシステムの名前解決を引き受けていても、ブラウザの解決リクエストはブラウザ指定の解決サービスへ直接送られ、出口の地域と一致しないことがあります。自己診断の段階ではまずこれをオフにし、回線自体に問題がないことを確認してから、必要かどうかを判断してください。
合格基準:システムのリゾルバが回線側のアドレス(または出口の地域と一致するアドレス)を示し、かつ nslookup の出力が国内プロバイダのアドレスでなくなっていること。両方を満たしたらステップ3へ進みます。
ステップ3:アプリごとに動作確認する
出口と名前解決が正常でも、すべてのアプリが使えるとは限りません。プログラムによってプロキシ設定の読み方が異なるため、このステップでは実際に使っているプログラムを1つずつ確認します。
- ブラウザ:シークレットウィンドウで目的のサイトを開き、ページが完全に読み込まれ、ログイン状態も正常であることを確認します。拡張機能を入れている場合は、まずシークレットモードで拡張機能の影響を排除してください。
- デスクトップクライアント:システムプロキシだけを読むプログラム、SOCKSしか認識しないプログラム、システムプロキシをまったく読まずTUNモードでの引き受けが必須のプログラムがあります。見分け方は簡単です。クライアントを終了してもそのプログラムが普通に通信できるなら、もともとプロキシを通っていません。
- コマンドラインツール:多くのコマンドラインプログラムは環境変数しか参照しません。
curlにはhttp_proxyとhttps_proxyが必要です。あるいはTUNモードで意識せず引き受けさせる方法もあります。 - モバイル:iOSもAndroidもバックグラウンドで接続を回収します。バックグラウンドから戻したら、まずクライアントの状態を確認してからアプリを開いてください。長時間バックグラウンドに置いた後にそのまま使うと、切れていることがよくあります。
- 地域判定が厳しいサービス:こうしたサービスは出口IP、解決元、アカウントの過去の地域を同時に参照します。3つが食い違っていると、通信が通っていてもブロックされます。
合格の目安は、しばらく継続して使え、リソースの読み込み失敗が起きず、認証を繰り返し求められないことです。トップページを開いて一瞥しただけでは合格とはいえません。
「接続済みなのに経由していない」よくあるケース
以下はいずれもクライアント画面には接続済みと表示されるのに、通信が期待どおり回線を通っていないケースです。発生頻度の高い順に並べています。
- ❌ システムプロキシの書き込みに失敗している。クライアントは接続と表示しているのに、システムプロキシのスイッチがオフで、ブラウザは国内回線のまま通信しています。システムプロキシの設定がローカルループバックアドレスとポートを指しているか確認してください。
- ❌ TCPしか引き受けていないのに、ブラウザがQUICを使っている。HTTP/3はUDP 443を使うため、回線がTCPのみを転送している場合、ブラウザはプロキシを迂回して直接接続します。ブラウザでQUICを無効にするか、UDPを引き受けられるモードに切り替えてください。
- ❌ IPv6の直接接続。ステップ1で触れたとおり、IPv6を引き受けていないとOSは国内アドレスを優先します。
- ❌ 分割ルールが目的のドメインを直接接続と判定している。ルールセットの期限切れやドメイン归属データベースの不足によって、目的のサイトが直接接続になることがあります。
- ❌ 複数ネットワークインターフェースの優先度の誤り。仮想マシンを入れたり2枚目のNICを挿したりすると、デフォルトルートが別のNICから出ることがあります。
- ❌ トンネルは切れているのに画面が更新されていない。ハートビートに失敗しても接続済みと表示され続けることがあるため、再接続してから確認してください。
- ✅ 逆もまた成り立ちます。3ステップすべて合格なのにアプリが使えない場合、問題は回線ではなくアプリ自身の地域ポリシーにあります。
分割モード:サイトによって通る・通らないが分かれる理由
クライアントは通常3つのモードを用意しています。グローバル、ルール(分割)、ダイレクトです。グローバルではすべての通信が回線を通るため、自己診断は最も通りやすくなります。ルールモードはドメインやIPの所属に応じて経路を決める柔軟な方式ですが、「一部だけ通る・通らない」が最も起きやすいモードでもあります。
- グローバル:すべての通信が回線を通ります。自己診断や一時的な利用に向きますが、長期間使うと通信量を浪費し、国内サービスが遅くなることもあります。
- ルール:ルールセットに基づいて判定し、直接接続に該当したものは国内回線、それ以外は回線を通ります。ルールセットは定期的な更新が必要で、古くなると誤判定します。
- ダイレクト:オフと同じ状態です。問題が回線自体に起因するかどうかの確認に使います。
切り分けの際はモードを一時的にグローバルへ切り替え、もう一度出口IPを確認してください。グローバルで合格しルールで不合格なら、問題はルールセット側にあり、回線にはありません。
自己診断が通ったあと
3ステップすべて通れば、その回線は現在の端末と現在のネットワークで使えるということです。次に見るべきは長期的な挙動です。夜のピーク時間帯に安定しているか、長時間接続しても切れないか、Wi-Fiからテザリングに切り替えたあと自動で復帰するか。これらは一度で判定できるものではなく、しばらく実際に使って観察するしかありません。
自己診断が何度も通らない場合は、まず別の回線に切り替えて試してください。出口が接続先サービスに制限されている、ルートが遠回りしているといった問題は、クライアントの設定変更では解決できません。VPNEHは現在90+の国・地域、190+の回線をカバーし、月額プランは¥9.9からで60GBを含みます。初回のお支払いから14日以内であれば理由を問わない全額返金を申請できるため、自己診断の段階で回線を替えながら試せます。