VPN 接続後の確認方法：IPアドレス・DNS・アプリ別チェック入門

「接続済み」「通信の転送」「アクセス成功」の違い

「接続済み」は、トンネルが確立した状態を示す場合もあれば、ローカルプロキシが起動しただけの場合もあります。意味はクライアントによって異なります。システムプロキシを使うクライアントは、その設定に従うアプリだけを経由させることがあります。仮想ネットワークインターフェースで通信を処理する場合も、ルーティング、除外リスト、振り分けルールの影響を受けます。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などのプロトコル名だけでは、端末全体の通信が経由されているかどうかは分かりません。確認すべきなのは、クライアントの動作モード、システム権限、アプリの実際の通信経路です。画面上の「グローバル」は、プロキシルールのすべてがプロキシ出口を向いているという意味の場合があり、すべてのアプリがクライアントを経由しているとは限りません。

出口IPアドレス：接続前後を比較する

信頼できる公開IPアドレス確認ページで現在の出口を記録し、IPv4とIPv6が個別に表示されるか確認します。確認するのは公開アドレスで、システムのネットワーク設定に表示されるローカルアドレスではありません。記録したらクライアントに接続し、同じブラウザーで再度確認します。

1. クライアントを切断し、現在のネットワーク、確認ページに表示された公開アドレス、ネットワークの情報を記録します。ページにIPv6の結果が表示されない場合は「未検出」と記録し、端末にIPv6がないと決めつけないでください。
2. 接続先のノードを選び、システムプロキシまたは仮想インターフェースモードがクライアントの説明どおり有効になっていること、必要なシステム権限が許可されていることを確認します。
3. 古いページの表示を使わないよう、確認ページを開き直します。あわせてクライアントの接続記録を確認し、確認リクエストにプロキシルールと直接接続ルールのどちらが適用されたか調べます。
4. アドレスが変わったかを比較し、対象サイトも確認します。確認ページに直接接続ルールが適用されている場合、アドレスが変わらなくても正常な振り分けの可能性があります。テスト対象を変更するか、クライアントが対応していれば一時的にグローバルプロキシルールで再確認してください。

IPアドレスの位置情報はデータベースによる推定で、更新に遅れが生じることがあります。出口の都市とノード名が一致しなくても、接続失敗とは限りません。一方、ページの言語、検索結果の地域、アカウントの地域も出口の証拠にはなりません。ログイン情報、位置情報の権限、過去の設定に左右されるためです。

確認ページに分かるのは、そのページに届いたリクエストの経路だけです。ブラウザー拡張機能が別のプロキシを設定している場合、ブラウザーでの結果はデスクトップアプリを代表せず、端末全体の状態を示すものでもありません。

DNS：地域だけでなく名前解決の経路を確認

DNSはドメイン名をIPアドレスに変換します。DNSチェックページでは通常、ブラウザーから新しいテスト用ドメインへのリクエストを送り、どの再帰リゾルバーが名前解決に関与したかを確認します。表示されるのは多くの場合、DNSサービスの出口情報であり、端末からリゾルバーまでのネットワーク経路全体ではありません。

すべての名前解決がクライアント経由になる想定なのに、テスト結果にローカルの接続ネットワークのリゾルバーが現れる場合は、DNSリクエストが迂回していないか確認してください。ただし、パブリックDNSのブランド名や別の国のリゾルバーが表示されただけで、漏えいと判断することはできません。パブリックDNSは分散配置されている場合があり、クライアントがリモートDNS、暗号化DNS、合成アドレスを使うこともあります。

ブラウザーとシステムのDNSを個別に確認する

ブラウザーのセキュアDNS設定は、システムの名前解決設定とは独立している場合があります。暗号化DNSは名前解決の通信内容を保護できますが、プロキシを経由するかどうかは接続経路とルールで決まります。「暗号化済み」だから「対象の経路を通る」とは限りません。

まずクライアントのDNS設定に関する説明を読み、ブラウザーのセキュアDNSとシステム設定を照らし合わせます。設定を変更したら、テストをやり直してください。キャッシュによって新たな名前解決が行われないことがあるため、通常のサイトを何度も再読み込みするのではなく、検査ページで新しいテストを実行しましょう。よく分からないDNSアドレスを、異常に気づいたからといってむやみに入力するのも避けてください。

一部のクライアントはFake-IPを使い、ドメイン名を一時的に合成アドレスへ対応させてから、後続の接続を処理します。この場合、システムツールに表示されるアドレスは実際のWebサイトのアドレスとは限らず、名前解決が改ざんされた証拠にはなりません。クライアントのログ、適用されたルール、最終的なアクセス結果をあわせて判断してください。

IPv6とWebRTC：別経路の通信も確認

IPv4がプロキシ経由でも、IPv6が同じ経路を使うとは限りません。ネットワークとアプリがIPv6に対応している一方、クライアントがIPv4しか処理しない場合、一部のリクエストが元のネットワークを通る可能性があります。目立つアドレスだけを見るのではなく、検査結果を個別に確認し、クライアントのIPv6処理が経由、直接接続、遮断のどの設定になっているか調べてください。

IPv6の経路が想定と異なる場合は、まずクライアントのドキュメントに従って通信の処理設定を調整します。クライアントが明確に対応していない場合は、影響を理解したうえで該当ネットワークのIPv6を一時的に無効にして比較し、その後元に戻して適切な設定を選びます。システムのネットワーク設定を長期的に変更する前に、利用中のネットワークのサービスに支障がないか確認してください。

WebRTCはブラウザーのリアルタイム通信に使われ、検査によってWebページのリクエストとは異なるネットワーク経路が見つかる場合があります。ただし、ローカルアドレスやマスクされたホスト識別子が表示されても、公開アドレスが漏れたとは限りません。想定外の公開アドレスが表示されているかを確認し、ブラウザーのプライバシー設定とクライアントのUDP対応もあわせて判断してください。

検査ページを「すべて緑」にするためだけに、リアルタイム通信機能をむやみに無効にしないでください。設定変更は会議や通話に影響することがあります。異常なアドレスの種類を確認してから、必要な設定だけを変更しましょう。

アプリ別に確認：ブラウザーの次はほかのアプリも

システムプロキシをすべてのソフトウェアが使うとは限りません。WindowsやmacOSでは、ブラウザーとデスクトップアプリでネットワーク設定が異なる場合があります。コマンドラインのプログラムが独自のプロキシ設定を参照することもあります。iOSやAndroidでVPNを許可しても、アプリの除外設定やオンデマンド接続ルールがないとは限りません。Linuxでは、デスクトップのプロキシ、端末の環境変数、システムルーティングの違いに特に注意が必要です。

アプリを検証するときは、クライアントで該当ドメイン、プロセス、接続記録を探し、適用されたルールと出口を確認します。すべてのクライアントでプロセス情報が表示されるわけではなく、すべてのモードでドメインを確認できるわけでもありません。記録だけでは判断できない場合は、システム設定やアプリ内のプロキシ説明も確認してください。記録がないことだけを根拠に、直接接続だと判断しないようにしましょう。

• ✅ ブラウザー：拡張機能のプロキシとセキュアDNSを確認し、出口を再チェックしてから、実際に利用するWebサイトを開きます。
• ✅ メール・オフィスアプリ：接続し直して送受信や同期を試し、該当する通信に想定のルールが適用されているか確認します。
• ✅ ビデオ会議：ログイン、会議への参加、音声・映像をそれぞれ確認します。Webページが開けても、リアルタイムメディアが使うUDP経路が正常とは限りません。
• ✅ コマンドライン・バックグラウンド処理：ツール独自のプロキシ設定を確認し、ブラウザーでの結果をそのまま端末のプログラムに当てはめないようにします。
• ❌ 中国国内のサイトが直接接続のままでも、すべて失敗とは限りません。ルールによる振り分けを使っているなら、それが想定どおりの設定である可能性があります。

回線を切り替えても、確立済みの長時間接続には以前の経路が一時的に残る場合があります。作業内容を保存してから対象アプリを終了し、再度開いてください。必要に応じてログインし直します。アプリのホーム画面を見るだけでなく、実際の作業に必要な操作まで確認しましょう。

トラブルシューティング：症状から原因を絞り込む

ブラウザーは正常だが、ほかのソフトウェアは変化しない

まず、ブラウザー拡張機能だけが有効になっていないか、対象ソフトウェアがシステムプロキシに従うかを確認します。クライアントに仮想インターフェースモードがある場合は、公式の説明に従って有効にし、再度確認してください。アプリの除外リストも確認します。管理対象の業務用端末では、組織のポリシーを独自に回避せず、管理者に確認してください。

出口は変わったのに、対象サイトにアクセスできない

必ずしもプロキシの不具合とは限りません。対象サービスがアカウントの地域、出口アドレスの評価、位置情報の権限、独自のルールをもとにアクセスを制限している場合もあります。まず対象リクエストにプロキシルールが適用されたか確認し、その後でサイト側の案内を調べます。特定のサービスが使えないだけで、すべての通信が経由されていないと判断することはできません。

ノードを切り替えても、表示結果が変わらない

確認ページに直接接続ルールが適用されていないか、ブラウザーが古い接続を再利用していないか確認します。アプリを開き直して新しいリクエストを送り、必要なら別の信頼できる確認ページでも照合してください。異なるノードでも同じ公開出口を共有することがあるため、アドレスが同じというだけでは接続失敗の十分な証拠になりません。

どのサイトにもつながらない、またはクライアントにノードが表示されない

まずクライアントを切断し、基本のネットワークでアクセスできることを確認します。次に、サブスクリプションが有効か、ノード一覧が更新されているかを調べてください。サブスクリプションリンクは接続設定をインポートするための認証情報であり、Webサイトの閲覧に使うものではありません。対応クライアントにインポートして更新します。インポートが成功しただけでは接続できたことにはなりません。ノードを選び、接続を有効にしたうえで、前述の方法で確認してください。

IEPL専用線、中継、直接接続は回線の構成方法を表すもので、端末側の確認に代わるものではありません。また、DNSやすべてのアプリの通信が想定どおり転送される保証にもなりません。問題が続く場合はトラブルシューティングを確認するか、カスタマーサポートに個人情報を伏せた状況記録を送ってください。

確認記録を保存し、接続情報の漏えいを防ぐ

役立つトラブル記録には、OS、クライアント名、接続モード、ノード名、対象アプリ、適用されたルール、接続前後の変化を含めます。公開IPアドレス全体を公開する必要はありません。スクリーンショットを共有する場合は、アカウント情報、サブスクリプションリンク、アクセストークン、調査に関係のないリクエスト内容を隠してください。

サブスクリプションリンクを、見知らぬオンライン検査・変換ページに貼り付けないでください。リンクが漏れた場合は、サービスの管理画面で利用できるリセットまたは無効化機能を使い、クライアントに再インポートします。チャットのメッセージを削除しただけでは、すでにコピーされた認証情報は無効になりません。

YuanVPNのプライバシーポリシーでは、ログを記録しないとしています。これはサービスの方針に関する説明であり、端末側の権限、名前解決、通信の振り分けを確認する必要がなくなるわけではありません。サービスへの接続、ブラウザーの動作、アプリの設定はそれぞれ別の観点から確認してください。