VPNの接続表示だけで、有効かどうかは判断できません。出口IPからは特定のリクエストの接続元を、DNSチェックからはドメインの名前解決経路を確認できます。アプリごとの検証では、使いたいソフトが想定した回線を経由しているかを確かめます。これらの情報を合わせて確認することで、正常なルール分岐と、通信が適切に処理されていない状態を見分けられます。
接続状態と実際の通信は別のもの
クライアントの「接続済み」は、トンネルが確立した状態を指す場合もあれば、プロキシサービスが起動した状態やノードが選択された状態を示す場合もあります。具体的な意味はクライアントによって異なります。サブスクリプションのインポート成功は設定を読み込めたことを示すだけです。ノードテストに成功しても、特定のテストが通っただけであり、すべてのアプリのリクエストがそのノードを使うとは限りません。
一般的なプロキシクライアントでは、システムプロキシを設定すると、その設定に従うアプリにプロキシの接続先が渡されます。ブラウザは通常これを利用できますが、ほかのソフトは独自のネットワーク設定を使う場合があります。TUNモードやシステムVPNモードでは、仮想ネットワークインターフェースを通じて、ルーティング条件に合う通信を処理します。通常はより広い範囲をカバーしますが、除外アプリ、ルール、DNS設定の影響は受けます。
「グローバルプロキシ」と「すべての通信」も区別が必要です。クライアントによっては、グローバルモードにしても、プロキシエンジンに入ったリクエストの経路が変わるだけで、もともとプロキシを通らないアプリが自動的に処理対象になるわけではありません。接続方式、動作モード、アプリの設定をそれぞれ確認し、似た画面表示を同じ設定項目だと思い込まないようにしましょう。
| 確認項目 | 確認できること | そこからは判断できないこと |
|---|---|---|
| クライアントの接続状態 | トンネルまたはローカルプロキシサービスの動作状況 | すべてのアプリがその接続を経由していること |
| ウェブサイトで確認する出口IP | そのウェブサイトのリクエストで検出されたパブリックIPアドレス | ほかのアプリやドメインも同じ出口を利用していること |
| DNSチェック | テスト用ドメインで使われた再帰DNSリゾルバーの手がかり | リゾルバーの所在地とデータ通信の出口が同じであること |
| クライアントの接続ログ | ログに記録されたリクエストのルール、ポリシー、出口の選択 | ログに記録されていない通信も処理されていること |
| 対象アプリでの実際の操作 | 現在のネットワーク環境でその機能がどう動作するか | 機能が使えれば、すべての通信経路が想定どおりであること |
まず出口IPを接続前後で比較する
まず、テストの目的を明確にします。特定の海外サイトだけプロキシ経由にしたいのか、アプリ全体をシステムトンネル経由にしたいのかを確認しましょう。信頼できるパブリックIP確認サイトを選び、検出結果、日時、使用中のネットワーク、クライアントのモードを記録します。確認サイトにはアクセス情報が送信されますが、ネットワークを調べるためにサブスクリプションURLやアカウント情報、クライアント設定をアップロードする必要はありません。
- 直接接続時の状態を記録する。直接接続をテストしても問題ない環境でプロキシを切断し、IP確認サイトを開いてパブリックIPアドレスとアドレスファミリーを記録します。作業上、直接接続による情報露出を避ける必要がある場合は、この手順を省略してください。必要な保護を中断してまでテストする必要はありません。
- 接続してモードを確認する。対象の回線を選び、システムプロキシまたはトンネルによる通信の処理が予定どおり有効になっているか確認します。ルールモードの場合は、確認サイトのドメインにどのルールが適用されるかも確認しましょう。
- リクエストを再実行する。確認ページを再読み込みします。必要に応じて古いタブを閉じてから開き直してください。新しいアドレスを記録し、クライアントに該当する接続ログが残っているか確認します。
- 別の方法でも確認する。信頼できる別の確認サービスでもテストし、IPアドレスの登録情報を比較します。データベースによって地域の表示は異なることがあるため、地図に表示された都市だけで接続失敗と判断しないでください。
アドレスが変わらない場合は、まず確認サイトがルールで直接接続に設定されていないかを調べ、次にブラウザが独自のプロキシや拡張機能の設定を使っていないか確認します。アドレスが変わっても確認できるのは、そのウェブページへの今回のリクエストで出口が変わったことだけです。IPv4とIPv6にも注意してください。確認ページには片方しか表示されない場合があり、対象アプリがもう一方を優先して使うこともあります。
DNSの確認：国だけでなく名前解決の経路を見る
DNSはドメイン名をネットワークアドレスに変換します。ウェブページのデータがプロキシ経由でも、名前解決のリクエストが自動的にリモート側で処理されるとは限りません。逆に、リモートDNSを使っていても、ウェブページのデータがプロキシ経由だとは証明できません。クライアントはローカルまたはリモートで名前解決を行うほか、ルールに応じて使い分ける場合があります。ブラウザが独自の暗号化DNSを使うこともあります。
一般的なDNSチェックサイトでは、専用のテストドメインに対してブラウザからリクエストを送り、名前解決に使われた再帰リゾルバーを確認します。結果に表示されるアドレスは通常、DNSサービスのものであり、ウェブ通信の出口ではありません。パブリックDNSサービスではエニーキャストや分散ノードが使われることもあります。表示地域が国内や見知らぬ国であっても、それだけでDNSリークとは判断できません。
より確実な方法は、まず設定の意図を確認することです。どのドメインをローカルで名前解決し、どれをプロキシ側に任せるのか、暗号化DNSへの接続自体がどの経路を通るのかを確認します。次にテストを実行し、想定したDNSサービスと結果を照らし合わせ、クライアントのDNSログも確認します。対象ドメインがすべてリモートで名前解決される想定なのに、想定外のローカル経路が繰り返し確認される場合は、さらに原因を調べましょう。
Windowsでは、次のPowerShellコマンドでネットワークアダプターのDNS設定を確認できます。これは設定を把握する手がかりであり、実際の経路を証明するものではありません。ブラウザの暗号化DNS、クライアント内蔵のリゾルバー、トンネルによるリダイレクトなどで動作が変わる場合があります。
Get-DnsClientServerAddress切り分けでは、ブラウザのセキュアDNS設定とクライアントのDNS設定を別々に確認します。一度に変更するのは一項目だけにして、複数の設定を同時に切り替えて比較できなくなるのを避けましょう。キャッシュの削除は名前解決をやり直す助けになりますが、誤ったルーティングの修正にはなりません。既存の接続では古いアドレスが再利用される場合もあるため、対象アプリを開き直して確認してください。
ブラウザで確認できても終わりにせず、アプリごとに検証する
実際に使うアプリをリストアップし、対象ページを開く、リモートコンテンツを更新する、新しいサービス接続を確立するといった、繰り返し実行できる操作を選びます。テストごとにアプリ名、操作時刻、対象ドメイン、クライアントログで一致した記録を残します。ログにプロセス名がない場合は、操作時刻と対象ドメインを手がかりに関連付けられますが、時刻が近いだけで確実な証拠とは言えません。
- ✅ ブラウザ：システムプロキシ、拡張機能のプロキシ、暗号化DNSの設定を確認し、テスト中のブラウザがどの設定を使っているか確かめます。
- ✅ デスクトップアプリ：アプリ独自のプロキシ設定を確認します。システムトンネルを使う場合は、そのアプリが除外対象になっていないか確認してください。
- ✅ コマンドラインツール：環境変数とツール独自のプロキシ引数を確認し、ターミナルのテスト結果をブラウザのテスト結果の代わりにしないでください。
- ✅ モバイルアプリ：システムVPN接続が維持されていることを確認し、クライアントでアプリ別の通信分岐が有効になっていないか調べます。
- ✅ 対象の機能：ログインやコンテンツの読み込みなどをそれぞれ確認し、異なるドメインに接続していないか注意します。
Windowsでは、WinHTTPプロキシとユーザーインターフェースのシステムプロキシは別の設定です。次のコマンドでWinHTTPの設定を確認できますが、出力が直接接続になっていても、ブラウザが必ず直接接続しているとは限りません。表示を揃えるためだけに、設定をむやみに変更しないでください。
netsh winhttp show proxymacOSでは、ネットワークサービスのプロキシ、アプリ内プロキシ、トンネルの設定をそれぞれ確認します。Linuxのデスクトップ環境で設定したプロキシが、ターミナルのプログラムにも適用されるとは限らず、ターミナルではプロキシ環境変数が使われる場合があります。Androidのアプリ別設定やiOSクライアントのルーティング機能は実装によって異なるため、各プラットフォームで同じメニューや動作が使えるとは限りません。
オンラインゲーム、音声通話、一部のリアルタイムアプリではUDP通信が使われる場合があります。ブラウザでページが正常に読み込めても、こうした通信が処理されているとは限りません。クライアントと現在の設定が必要な通信に対応しているか確認し、対象の機能を実際にテストしてください。プロトコル名だけを根拠に、特定のアプリが必ず使えると判断することはできません。
「接続中に見える」のによくある原因
確認サイトは直接接続なのに、対象サイトはプロキシ経由で正常に使える
多くの場合、これは矛盾ではなくルールの違いによるものです。2つのドメインに適用されるルールとポリシーグループを確認してください。ルール名は目印にすぎないため、ポリシーグループを開き、最終的にどの出口が選ばれているかも確認します。サブスクリプションURLで設定を配布できても、ローカルにあるルールの優先順位が目的に合っているとは限りません。
ブラウザの出口は変わったが、ほかのソフトは従来のネットワークを使っている
まず、通信の処理対象となる範囲を確認してください。システムプロキシは設定に従うアプリでのみ有効です。アプリが独自のプロキシを使っている場合や、古い接続を維持している場合、トンネルから除外されている場合もあります。対象アプリを完全に終了してから開き直し、新しい接続を確認します。それでも想定どおりでなければ、クライアントの説明に沿って接続方式を調整してください。システムのネットワークコンポーネントをいきなりアンインストールしないでください。
IPアドレスは変わったが、サービス上の地域表示が変わらない
サービスは、アカウントの地域、過去のセッション、位置情報の権限、キャッシュ、自社のIPアドレスデータベースなどを基に地域を判定することがあります。「ネットワークの出口確認」と「サービスによる地域判定」は分けて記録しましょう。関連するサイトデータを消去するか、新しいブラウザーセッションを使うとキャッシュの影響を確認できますが、出口を変更しても対象サービスの地域表示や提供コンテンツが変わるとは限りません。
DNSは想定どおりに見えるのに、ウェブページが開かない
名前解決の成功はアドレスを取得できたことを示すだけで、その後にルーティング、証明書、接続先サービスの制限、接続失敗などが発生する可能性があります。システム時刻とブラウザのエラーメッセージを確認してから、クライアントのログを調べてください。いわゆる検証のために証明書の警告を無視しないでください。また、提供元が確認できていないページにアカウント情報を入力しないでください。
切り分けの内容を再現できる記録にまとめる
問題が起きた場合は、1回のテストで変更する項目を1つに絞ります。たとえば、ルールモードだけを切り替える、回線だけを変更する、特定アプリのプロキシ設定だけを調整するといった方法です。対象の操作を固定し、接続を確立し直してから確認すれば、どの変更が影響したか判断できます。ネットワーク、クライアント、設定を同時に何度も変えると、「たまに直る」理由を特定しにくくなります。
サポートへ問い合わせる際は、端末のOS、クライアント名、テスト日時、通信の処理モード、対象ドメイン、エラーメッセージ、個人情報を伏せた関連ログを伝えてください。パブリックIPも機密性のある情報なので、連絡の目的に応じて取り扱いに注意しましょう。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。公開の掲示板に貼り付けないでください。スクリーンショットを共有する場合は、サブスクリプションURL全体とアカウントのトークンを隠してください。
MHZVPNの利用方法はクライアントの使い方ガイドをご覧ください。回線選びについてはサーバー一覧をご確認ください。回線数や対応地域は選択肢の目安であり、特定のアプリが必ず使えることを示すものではありません。実際の利用状況は、この記事の手順に沿って確認してください。