VPNが機能しているかを判断する際、クライアント画面の「接続済み」だけを見てはいけません。この表示が示すのは通常、クライアントとリモート回線の接続またはハンドシェイクが完了したことだけで、ブラウザ、ダウンロードツール、その他のアプリの通信までその回線を経由した証拠にはなりません。最も確実なのは、接続前のネットワーク状態を記録し、外部IP、DNSの解決経路、実際に使うアプリを順に確認したうえで、ルール分岐、システムプロキシ、ルーティングモードを調べる方法です。
切り分けでは、「回線を確立できるか」「システムが通信を引き受けているか」「対象アプリがその方式に従っているか」を分けて考えます。前者が正常でも後者に問題があれば、クライアントには接続成功と表示されることがあります。反対に、外部IPが変わっていても、すべてのリクエストが同じ経路を使うとは限りません。DNS、IPv6通信、ローカルネットワークへのリクエスト、ルールで除外されたアプリは、元のネットワークを経由する可能性があります。
まず「接続済み」と実際の通信経路を区別する
プロキシやVPNクライアントは通常、いくつかの独立した処理を行います。ノード設定の読み込み、サーバーとのセッション確立、システムプロキシまたは仮想ネットワークインターフェースの設定、ルーティングルールの適用、そして分岐ポリシーに沿ったリクエスト処理です。画面上の接続スイッチが示せるのは、多くの場合このうち前半だけです。システム設定が別のソフトに書き換えられた、仮想インターフェースにルートが設定されていない、アプリがシステムプロキシを無視しているといった場合、スイッチがオンでもアクセス経路が変わらないことがあります。
プロトコルが異なっても、判断の考え方は変わりません。Shadowsocks、VMess、Trojan、VLESSは、プロキシクライアントとシステムプロキシまたは仮想ネットワークアダプターのモードを組み合わせて使うことが一般的です。Hysteria2、TUICなども、アプリの通信を対応する接続へ渡す処理がクライアント側で必要です。プロトコルのハンドシェイク成功が示すのは、クライアントからノードへ到達できたことだけです。端末全体をカバーできるかどうかは、クライアントのモード、OSのルーティング、分岐ルールによって決まります。
| 確認できた現象 | わかること | まだわからないこと |
|---|---|---|
| クライアントに接続済みと表示される | ノードセッションが確立した可能性が高い | すべてのアプリが回線を経由した証明にはならない |
| ブラウザの外部IPが変わった | そのブラウザの確認リクエストが新しい出口を経由した | 他のアプリやDNSの経路を直接示すものではない |
| 対象サイトを開ける | 現在のリクエストに利用可能なアクセス経路がある | アクセスできるだけでは、どの経路を使ったか判断できない |
| DNSチェックに見慣れないリゾルバーが表示される | 名前解決が回線側またはカスタムサービスで処理された可能性がある | 名前だけで全通信の出口を判断してはいけない |
「システムプロキシ」と「仮想ネットワークアダプター」という、よくある2つの通信引き受け方式も区別しましょう。システムプロキシは、アプリがOSのプロキシ設定を読み取る必要があります。ブラウザは対応していることが多い一方、一部のゲーム、コマンドラインツール、単独で動く更新プログラムは無視する場合があります。仮想ネットワークアダプターのモードはネットワーク層でより多くの通信を引き受けるため、一般にカバー範囲が広くなりますが、ルートの除外項目、分岐ルール、ローカルネットワーク設定の影響は受けます。
外部IPで最初の確認を行う
外部IPは最もわかりやすい確認項目です。まずクライアントを切断し、本サイトのIPチェックページを開いて、現在のアドレスとおおまかな地域を記録します。次にページを閉じて対象回線へ接続し、確認ページをもう一度開きます。長時間開いたままのタブを更新するだけでは不十分です。ブラウザのキャッシュ、ページのスクリプト状態、古い接続の再利用が確認結果に影響することがあります。
- 回線を切断し、クライアントが未接続状態に戻ったことを確認する。
- IPチェックページを開き、元のネットワークの出口を記録する。
- 確認タブを閉じ、使用する回線へ接続する。
- 確認ページをもう一度開き、アドレスと地域が選択した回線と一致するか比較する。
- 別のブラウザまたはシークレットウィンドウで再確認し、拡張機能とキャッシュの影響を除外する。
アドレスが変わらない場合は、まずクライアントの現在のモードを確認します。ルールモードでは、IPチェックサイトが直接接続と判定され、元の出口が表示されることがあります。トラブル切り分け中は、一時的にグローバルモードまたは仮想ネットワークアダプターのモードへ切り替えて比較できますが、原因を確認したら日常利用に適した分岐設定へ戻してください。切り分け用のルールを長期間残すと、国内サイト、ローカルネットワーク機器、業務リソースまで不要にリモート回線を経由する可能性があります。
アドレスが変わったものの、地域が選択したノードと明らかに異なる場合は、まずデータベースによる表示差を確認します。IPの位置情報はデータベースごとに異なり、市区町村レベルの結果が一致しないこともあります。1つのページに表示された都市名だけを回線障害の根拠にしてはいけません。より重要なのは、元のネットワークの出口から別のアドレスへ変わったか、複数の確認元が大まかに対象の国や地域を示しているかです。
ブラウザの確認は正常なのに、他のソフトが元のネットワークを使う場合、問題は通常「回線が接続されているか」から「アプリが通信を引き受けられているか」へ絞り込めます。この段階でノードを何度も変更する必要はありません。クライアントのモードと個別アプリの動作を確認しましょう。
DNS解決が元のネットワークに戻っていないか確認する
ドメインへアクセスすると、端末は通常まずDNS解決を行い、ドメイン名を接続可能なアドレスへ変換します。ウェブページの本文がリモート回線を経由していても、DNSリクエストまで同じ経路を通るとは限りません。システムが元のネットワークのリゾルバーへ解決リクエストを送り続けると、一般にDNSリークと呼ばれる状態になります。必ずしもページが開けなくなるわけではありませんが、名前解決とアクセスの経路が一致しなくなり、地域判定の誤り、ドメイン解決の異常、分岐結果のずれにつながる可能性があります。
確認時は、切断時と接続時の両方でDNSチェックを実行し、リゾルバーの所属を比較します。接続後も元のネットワークのリゾルバーだけが表示されるなら、クライアントのDNS引き受けが機能していない可能性があります。元のネットワーク側と回線側のリゾルバーが同時に表示される場合は、並列解決、ブラウザ内蔵の暗号化DNS、システムキャッシュ、複数のネットワークインターフェースが同時に動作している可能性があります。
- ✅ 接続前後にそれぞれ確認し、2回分の結果を保存して比較する。
- ✅ ブラウザで独自のセキュアDNS設定が有効になっていないか確認する。
- ✅ クライアントにリモートDNS、プロキシDNS、リーク防止の設定があるか確認する。
- ✅ 設定を変更したら古いタブを閉じ、確認をやり直す。
- ❌ 見慣れないリゾルバーが表示されたからといって、すぐに回線異常と判断しない。
- ❌ ブラウザの履歴だけを削除し、OSのDNSキャッシュを見落とさない。
ブラウザ内蔵の暗号化DNSは、結果を複雑にすることがあります。システムのDNS設定を迂回して、ブラウザが指定した解決サービスへ直接接続する場合があり、システムのポリシーに応じて自動的に切り替わることもあります。切り分け時は、いったんブラウザをシステム設定に従わせ、クライアントが名前解決を引き受けられるか確認できます。経路を確認した後、ブラウザ独自の解決を使うか、クライアントで統一するかを決め、2つのポリシーが互いに上書きしないようにします。
分岐クライアントは、ドメインルールに応じて通信経路を決めることもあります。DNS解決がルール判定の前後で異なるポリシーを使うと、元のネットワーク向けのアドレスが返された後にリモート回線へ送られたり、回線側のアドレスが返されたのに直接接続と判定されたりします。この問題は、一部のサイトは正常で別のサイトはタイムアウトする一方、外部IPチェックには異常がないという形で現れがちです。
IPv6にも個別の注意が必要です。元のネットワークがIPv6に対応していて、回線側がIPv4しか引き受けない場合、デュアルスタック対応アプリが未対応のIPv6経路を優先することがあります。確認ページに2種類のアドレスが表示される場合は、どちらも想定どおりか確認してください。クライアントがIPv6を引き受けていない場合は、クライアントで対応機能を有効にする、ルーティングポリシーを調整する、または切り分け中だけその経路を一時的に無効にして比較します。元の設定を記録せずにシステムのネットワークパラメーターを直接変更しないでください。
アプリごとに確認し、ブラウザだけで判断しない
ブラウザのチェックが通っても、端末全体が通信を引き受けているとは限りません。アプリごとにネットワークの使い方は異なります。ブラウザは通常システムプロキシに従いますが、一部のデスクトップソフトは独自のプロキシ設定を使い、コマンドラインプログラムは環境変数を参照する場合があります。ゲームやリアルタイム通信ツールはUDPを直接送信することがあり、ストアアプリやシステムサービスはOSのサンドボックスやバックグラウンドポリシーの制約を受けることもあります。
確認時は、実際に使うアプリを選び、多数のソフトを一度に起動しないでください。まずアプリを終了し、回線へ接続してからアプリを再起動し、地域やネットワークの出口を明確に示せる機能へアクセスします。起動済みのアプリは古い接続を保持することがあり、システムのルートが変わっても既存セッションがすぐ再構築されるとは限りません。
ブラウザ
まず拡張機能を確認します。プロキシ拡張機能がシステムプロキシを上書きしたり、現在のブラウザだけをプロキシしたりすることがあります。クライアントと拡張機能を同時に有効にすると、二重プロキシやルールの競合が起きる可能性があります。切り分け時は、通信を引き受ける方式を1つだけ残してください。シークレットウィンドウでは一部の拡張機能が無効になるため比較に向いていますが、ブラウザがシークレットモードでの拡張機能実行を許可しているかは確認が必要です。
デスクトップソフトとコマンドラインツール
デスクトップソフトに「システムに従う」「プロキシを使用しない」「カスタムプロキシ」などの選択肢がある場合は、現在どれが選ばれているかを確認します。コマンドラインツールは、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を読み取ることがあります。既存のターミナルが後から追加された変数を自動的に取得するとは限らないため、変更後はターミナルを開き直して確認してください。
確認手順
回線を切断 → 元の出口を記録
回線へ接続 → ブラウザで新しい確認を実行
対象アプリを再起動 → 実際にアクセス
クライアントの接続ログを確認 → ルールに一致したか確認
通信を引き受けるモードを切り替え → もう一度比較リアルタイム通信とUDPを使うアプリ
アプリによってはログインリクエストがTCP、音声・動画・リアルタイムデータがUDPを使うため、「ログインできるのに通話が不安定」ということがあります。ノードのプロトコル、クライアント、現在のネットワークが、アプリに必要なUDP通信を処理できるか確認してください。システムプロキシモードは、こうした通信のカバー範囲が通常、仮想ネットワークアダプターのモードほど広くありません。切り分け時は仮想ネットワークアダプターのモードで相互に確認できます。
1つのアプリだけに問題があり、他のアプリの出口とDNSが正常なら、まずそのアプリの設定、ファイアウォールの許可、古い接続、分岐ルールへの一致状況を確認します。この場合、回線を変更し続けても問題の特定にはつながりにくいでしょう。クライアントに接続ログがあるなら、対象ドメインやアドレスが最終的にプロキシ、直接接続、拒否のどれとして扱われたか確認できます。ログはルールの判断に使い、通信量だけを見ないでください。
よくある見かけの接続と対処方法
「接続したように見えるのに回線を経由していない」問題は、単一の障害とは限りません。次の現象を手がかりに範囲を絞り込めます。対処時は一度に1項目だけ変更し、変更のたびに同じ確認を繰り返してください。ノード、プロトコル、DNS、モードを同時に変更すると、結果の原因を特定できなくなります。
| 現象 | 考えられる原因 | 優先して確認する項目 |
|---|---|---|
| すべてのアプリで出口が変わらない | システムプロキシが設定されていない、仮想インターフェースが通信を引き受けていない、またはルートが競合している | 通信を引き受けるモード、システムプロキシの状態、仮想インターフェースの権限 |
| ブラウザは正常だが、他のソフトは正常に動作しない | 他のソフトがシステムプロキシを無視している、または独自のプロキシを使用している | アプリのネットワーク設定、仮想ネットワークアダプターのモード、アプリ別ルール |
| 出口は変わったが、DNSは元のネットワークのまま | DNSが引き受けられていない、またはブラウザが独自の名前解決を使っている | クライアントのDNSオプション、ブラウザのセキュアDNS、システムキャッシュ |
| 一部のサイトは直接接続、別のサイトは回線を経由する | ルールモードによる正常な分岐、またはルールの誤判定 | 対象ドメインに一致したルールとルールの順序 |
| 回線を切り替えても古い地域が表示される | 古い接続の再利用、キャッシュ、または位置情報データベースの違い | アプリを終了して再起動し、別の確認元でも再チェックする |
| アプリにはログインできるが、リアルタイム機能に問題がある | UDPが引き受けられていない、ネットワーク制限、または分岐が一致していない | プロトコルの対応状況、クライアントのモード、アプリの通信種類 |
サブスクリプションURLとクライアント設定が誤判定の原因になることもあります。サブスクリプションを更新した後も、クライアント内で古いノードが選択されたままの場合があります。同じ名前のノードが同じ設定とは限りません。異常が長引く場合は、まずサブスクリプションを更新し、更新時刻と現在選択中のノードを確認してから再接続してください。サブスクリプションURLをウェブの確認ツールへ直接貼り付けたり、他人に送ったりしないでください。通常、アカウントに関連する情報が含まれています。
複数のクライアントを同時に動かすことも、よくある競合原因です。1つのクライアントがシステムプロキシを設定し、別のクライアントが仮想インターフェースを作成し、その一方を終了すると古い設定が復元されることがあります。最終状態の判断が難しくなるため、切り分け中は他のプロキシまたはVPNクライアントを完全に終了し、確認するソフトだけを残してください。ウィンドウを閉じるだけでは終了したことにならない場合があるため、バックグラウンドの状態も確認します。
Wi-Fiから有線ネットワーク、テザリング、またはスリープ復帰へ切り替えた後は、既存の仮想インターフェースやデフォルトルートが無効になることがあります。セッションがすぐ更新されず、クライアントには接続済みと表示され続ける場合もあります。まず切断して再接続し、それでも改善しなければクライアントを終了して再起動してください。企業ネットワーク、ホテル、公共ネットワークでは特定の接続方式が制限されることもあります。プロトコルの変更は比較材料になりますが、まず通常のウェブ閲覧自体が正常か確認します。
決めた順序で最終確認を行う
設定を変更した後は、最初から完全な再確認を1回行ってください。異なる設定で得た結果をつなぎ合わせてはいけません。最終結果は、同じ接続、同じルール、同じネットワーク環境で得られたものである必要があります。次のチェックリストは、クライアントの変更、新しいサブスクリプションの読み込み、分岐ルールの調整後に役立ちます。
- ✅ 切断状態で元の出口とDNSの基準値を記録した。
- ✅ 接続後に出口アドレスが想定どおり変わり、地域も選択した回線とおおむね一致した。
- ✅ DNSチェックで元のネットワークの解決経路だけが意図せず表示されていない。
- ✅ IPv4とIPv6の処理方法が、現在のクライアント設定に合っている。
- ✅ ブラウザ拡張機能がクライアントのプロキシを上書きしたり二重適用したりしていない。
- ✅ 実際に使うデスクトップアプリを終了・再起動し、個別に確認した。
- ✅ 分岐ログで対象リクエストが想定したルールに一致している。
- ✅ 一時的に使ったグローバルモードやテスト設定を元に戻した。
- ❌ 1つのサイトを開けるかどうかだけを唯一の判断材料にしない。
- ❌ 1回の切り分けでネットワーク設定をすべて同時に変更しない。
外部IP、DNS、複数のアプリがすべて想定どおりなら、現在の接続が必要な通信を正常に引き受けていると判断できます。特定のアプリだけが失敗する場合は、アプリ設定と分岐を確認します。すべてのアプリが失敗する場合は、システムプロキシ、仮想インターフェース、ルーティング層に戻って確認します。出口は正常でも名前解決に問題がある場合は、DNSとブラウザ独自の解決設定を重点的に調べます。層ごとに切り分けるほうが、ノードを何度も切り替えるより安定し、再現もしやすくなります。