VPN が有効か確認する方法:出口 IP・DNS・アプリ別の検証

まず押さえる:接続できても正しい回線とは限らない

クライアントで接続ボタンを押し、ステータスが緑になっても、それは端末からノードまでのトンネルが確立したことだけを意味します。出口 IP が選択した地域になる保証はなく、ドメインがリモート側で解決される保証もなく、すべてのアプリがトンネルを通る保証もありません。

トンネルの確立に成功していても、ノードが実際には使えない、サブスクリプションが期限切れ、振り分けルールが直結にマッチした、といった理由で通信がローカルの出口に戻ることがあります。しかもクライアントの画面には何の通知も出ません。つまり「接続済み」はある操作の結果であって、回線が有効だという証明にはなりません。

回線が本当に有効かを確かめるには、3つの具体的な問いに答える必要があります。通信がどの IP から出ているか、ドメインがどこで解決されているか、どのアプリがトンネルに入っているか、です。

3 つの検証ステップ:出口 IP、DNS 解決、アプリ別振り分け

120+ の国と地域。確認した所在地が選択した回線と一致するかを照合

180+ の回線。別の回線に切り替えて再測定すれば、ノード側か設定側かの切り分けが速い

7日間の無条件返金。検証も試用もコストを抑えられる

この3つを確認可能な基準に落とし込んだのが、次のチェックリストです。3項目すべてを満たして、はじめて通信が国際回線を通っていると言えます。

✅ 確認した出口 IP の所在地が、選択した回線の地域と一致している。
✅ リゾルバーが回線の出口側にあり、一覧にローカル事業者の DNS が含まれていない。
✅ 回線を通す必要のあるアプリがすべてプロキシルールにマッチし、ブラウザーとターミナルで同じ結果が得られる。
❌ クライアントが「接続済み」と表示しているだけで、残りの3項目は確認していない。

ステップ1:出口 IP と接続先地域を照合する

出口 IP はもっとも直接的な検証項目です。回線を切断した状態で現在のグローバル IP と所在地を控え、接続後にもう一度確認して2つの結果を比べます。確認方法は、検索エンジンで「IP アドレス確認」と検索するのでも、ターミナルでコマンドを1つ実行するのでもかまいません。

# 回線に接続した後に実行し、現在の出口 IP を確認する
curl -s https://ipinfo.io/ip

# 予備の確認方法
curl -s https://ifconfig.me/ip

合格の基準は明確です。接続後に確認した IP の所在地が、選択した回線の地域と一致していれば問題ありません。それでもローカル事業者の IP が返ってくる場合は、通信がトンネルに入っていないということです。後の2ステップは急がず、まず最後の節の手順で切り分けてください。

見落としやすいのが IPv6 です。多くのクライアントは既定で IPv4 しか通さないため、IPv6 のリクエストはそのまま直結で出ていきます。一方、確認サイトは IPv6 アドレスを優先して返すことがあり、「接続したのに反映されていない」ように見えます。対処は、クライアントで IPv6 のトンネル通過を有効にするか、一時的に IPv6 を無効にして再測定します。

もう一つ見落としやすいのが WebRTC です。TCP のみをプロキシするモードでは、WebRTC の UDP 通信がトンネルを迂回し、端末のグローバルアドレスが露出することがあります。これは出口 IP の判定には影響しませんが、露出が気になる場合はブラウザーで WebRTC を制限するか、クライアントを TUN モードにしてすべての通信を通すようにします。

ステップ2:DNS のリーク検査を行う

トンネル内の通信は軍事レベルの暗号化で保護されていますが、DNS リクエストは Web 通信とは別の経路を通ります。名前解決がローカル事業者の DNS に送られたままだと DNS リークになります。IP は回線を通っているのに、ドメインは手元で解決されている状態です。その結果、解決結果が近くの CDN ノードに振り分けられて表示が遅くなったり、開けなくなったりします。解決経路そのものから閲覧の意図が漏れることもあります。

確認方法は、「DNS リークテスト」で検索していずれかのテストページを開き、返ってくるリゾルバーの一覧を見るだけです。一覧にローカル事業者や地元都市の DNS があればリークしています。正常なら、回線の出口地域のリゾルバーが表示されます。

ターミナルでも確認できます。nslookup の出力には Server の行が含まれるので、回線の接続前と接続後に1回ずつ実行し、この行のアドレスが変わったかを見比べます。

# 回線の接続前と接続後に1回ずつ実行し、Server の行を見比べる
nslookup example.com

リークが見つかったら、クライアントで「リモート DNS」または「回線側の DNS を使用」を有効にして、名前解決もトンネルを通します。DNS の処理モードを選べるクライアントなら、トンネル側で処理する設定を選びます。なお、ブラウザー内蔵の暗号化 DNS(DoH)はシステム設定を迂回するため、検証時は設定をそろえるか、一時的に無効にしてください。

DNS リークはクライアントの接続状態を変えないため、画面は緑のままです。能動的にテストしないと気づけないので、このステップは省けません。

ステップ3:アプリ別と振り分け検証

アプリ別プロキシは Android クライアントでよく見られます。チェックを入れたアプリだけがトンネルを通り、それ以外は直結になります。デスクトップでは振り分けルールを使うことが多く、クライアントがルールセットに従ってドメインと IP をプロキシ側と直結側に分けます。ルールのマッチを誤ると、目的のサイトがローカルの出口から出てしまいます。

検証は次の4ステップです。

クライアントの接続ログまたはルールのマッチ記録を開く。
回線を通す必要のあるサイトにアクセスし、ログで該当するエントリを見つけて、直結ではなくプロキシルールにマッチしていることを確認する。
重要なアプリごとに繰り返す。ブラウザーで出口 IP を1回、ターミナルで出口 IP を1回確認し、両者が一致するか比べる。
結果が一致しないアプリは、アプリ別リストまたはカスタムルールに戻って個別に調整し、もう一度測定する。

ブラウザーとターミナルで出口が違うのはよくあることです。ターミナルは既定でブラウザーのプロキシ設定を使いません。クライアントが SOCKS または HTTP プロキシモードの場合、ターミナル側でプロキシの環境変数を別途設定しないと、確認結果はローカル IP のままになります。これは回線の問題ではなく、トンネルの適用範囲の問題です。

振り分けルールも誤判定することがあります。目的のサイトが海外 CDN 上にありながら、メインドメインが中国本土のドメインのように見えると、ルールセットがドメイン判定で直結とみなすことがあります。ルールセットのバージョンが古く、新しいドメインが収録されていない場合も同じです。こうした場合は、そのドメインをカスタムのプロキシルールに追加して再測定します。

ここまでで、3項目の基準は具体的になりました。出口 IP の所在地が回線の地域と一致し、リゾルバーが回線側にあり、重要なアプリがすべてプロキシルールにマッチしていることです。3項目のうち1つでも満たさない場合は、すぐに回線の不具合と決めつけず、次の節のよくあるケースに照らして1つずつ除外していけば、通常は数分で原因を特定できます。

「つながっているように見えて実は通っていない」よくあるケース

以下の現象に共通するのは、クライアントの接続状態は正常なのに、通信が期待どおりに回線を通っていないという点です。現象から原因を照合して切り分けたほうが、何度も再接続を繰り返すよりはるかに効率的です。

現象	実際の原因	対処の方向
クライアントは接続済みなのに、確認するとローカル IP のまま	ノードのハンドシェイクに失敗して直結にフォールバックした、またはサブスクリプションの期限切れ・通信量の使い切り	別の回線に切り替えて再測定し、サブスクリプションの状態も確認する
Web ページは開くが、動画がずっとバッファリングする	ドメインが手元で解決され、近くの CDN ノードに振り分けられている	リモート DNS を有効にして、リーク検査をやり直す
回線を通るアプリと通らないアプリがある	アプリ別プロキシのチェック漏れ、または振り分けルールが直結にマッチしている	アプリ別リストとルールのマッチログを照合する
ブラウザーとターミナルで確認した出口が一致しない	ブラウザーにプロキシ拡張機能が入っている、または独自のプロキシ設定がある	プロキシ設定を統一してから再確認する
確認すると IPv6 アドレスだけがローカルになる	クライアントが IPv6 を通していない	IPv6 のトンネル通過を有効にするか、一時的に IPv6 を無効にする
接続後に中国本土のサイトがかえって開けなくなる	グローバルモードですべての通信を外に出している、またはルールセットが中国本土のドメインをプロキシ判定している	ルールベースの振り分けモードに戻し、ルールセットを更新する

プラットフォーム別の確認ポイント

同じ検証手順でも、OS によって注意点は異なります。プラットフォームごとに押さえておくと遠回りを避けられます。

Windows と macOS

デスクトップクライアントの接続方式は、システムプロキシと TUN モードの2つが一般的です。システムプロキシはシステムのプロキシ設定を読むアプリしかカバーせず、ターミナルや一部のソフトは迂回します。TUN モードはより広く通信を捕捉しますが、システムプロキシと同時に有効にしないよう注意してください。重ねるとルールが衝突しやすくなります。検証の前に、クライアントがどちらのモードを使っているかを確認しましょう。

Android と iOS

モバイルはシステムの VPN 設定を使うため、接続状態は OS の設定画面でも確認できます。Android はアプリ別プロキシに対応しているので、検証ではチェックリストを重点的に確認します。iOS には通常アプリ別の切り替えがないため、ルールベースの振り分けへの依存度が高く、DNS とルールのマッチが検証の中心になります。また、モバイル回線では DNS が事業者から配布されるので、リーク検査はモバイルデータ通信でも一度やっておく価値があります。

Linux とルーター

Linux ではコマンドラインのクライアントを使うことが多く、systemd-resolved が DNS を引き受ける点に注意が必要です。resolvectl status で現在使われているリゾルバーを確認し、それがトンネル側に移っているかを確かめます。回線をルーターに展開する場合、ネットワーク内の機器は同じ出口を共有するため、任意の1台で検証すれば足ります。ただし解析経路はルーター自身の DNS 転送設定で決まるので、リーク検査はルーターの層で見る必要があります。

VPNYN のクライアントは Windows、macOS、iOS、Android、Linux に対応しており、サブスクリプションを読み込めば上記の手順で項目ごとに検証できます。同じアカウントで同時接続の台数制限はないため、複数端末で並行して再測定できます。

検証に合格したら、3つの結果を一度記録しておきましょう。出口 IP の所在地、リゾルバー、重要なアプリの一覧です。以後、回線を変えたとき、端末を変えたとき、OS をアップデートしたときも、同じ手順で再測定すれば数分で完了します。

検証に通らないときの切り分け順序

次の順序で進めると、各ステップで範囲を1つずつ絞り込めるので、複数の設定を同時にいじらずに済みます。

別の回線で再測定する。同じ設定のまま回線だけ変えて正常に戻れば、原因はノード側なので端末の設定に触る必要はありません。
サブスクリプションの状態を確認する。期限切れや通信量の使い切りは「つながるのに通信が通らない」形で現れるので、まずこの2点を確認します。
ブラウザーのプロキシ拡張機能と内蔵の暗号化 DNS を無効にして、ブラウザー層の独自設定を除外する。
DNS のトンネル通過を確認する。クライアントでリモート DNS を有効にし、リーク検査をもう一度実行する。
IPv6 を確認する。トンネル通過を有効にするか一時的に無効にして、出口 IP をもう一度測定する。
クライアントとネットワークを再起動する。トンネルと DNS の設定は接続のたびに作り直されるので、ルーター機器の再起動も有効です。
ログを記録する。クライアントのログと3項目の検証結果をまとめてサポートに送ると、原因の特定が格段に速くなります。

この手順に特別なツールは要りません。IP 確認の入口が1つ、DNS リークテストのページが1つ、クライアントの接続ログがあれば、3項目すべてをカバーできます。回線を切り替える前に回線一覧を見て、地域の合う回線を選んでから測定するのもおすすめです。

3ステップの検証は順序を固定するのがおすすめです。まず出口 IP、次に DNS リーク検査、最後にアプリごとの振り分け確認です。3つすべてを通って、はじめて通信が国際回線を通ったと言えます。1つ目だけで終わっている状態は、トンネルが張れたというだけで、「有効」まであと2ステップ残っています。