国際接続トラブルシューティングガイド

再現可能な確認手順を作る

接続トラブルで最も難しいのは、隠れたスイッチが足りないことではなく、症状の説明が正確でないことです。「使えない」という一言は、クライアントが起動しない、サブスクリプションを読み込めない、接続先とのハンドシェイクに失敗する、接続済みなのにドメインが開かない、特定のアプリだけプロキシを経由しない、といった複数の状態を指します。画面上の印象は似ていても、原因の層は異なります。まず、クライアントが開くか、サブスクリプションに接続先が表示されるか、接続操作後に状態が変わるか、システムにネットワーク権限の通知が出るか、ドメインと直接のネットワーク要求がどちらも失敗するか、ネットワーク環境を変えても症状が続くかを確認し、主観的な感覚を観察可能な事実に置き換えましょう。

まず現在の環境を保存します。使用中のプラットフォーム、クライアントのモード、選択した接続先の種類、エラー表示の原文、トラブル発生前に最後に変更した内容を記録してください。最初から設定をすべて削除したり、接続先の変更、プロトコルの変更、DNSの変更、クライアントの再インストールを同時に行ったりしないでください。複数の変更で一時的に接続が戻っても、本当の原因が分からなくなり、再発時にまた最初から推測することになります。問題を再現できる状態を残し、確認を1つ終えるたびに同じ対象へ再テストする方法が安全です。

問題を該当する層に分類する

基準テストはできるだけ単純にします。まず、ネットワーク経路を変更する他のツールを終了し、ブラウザのネットワーク関連拡張機能を一時停止します。クライアントは初期設定のままにし、現在地から比較的近く、用途が明確な接続先を1つ選びます。VPNXVは100+か国 / 150+の接続先に対応しており、接続先一覧でIEPL、中継、直結の違いを確認できます。トラブルシューティングでは、できるだけ多くの組み合わせを試すのではなく、経路を明確にすることが重要です。初期設定で動作したら、振り分け、自分で設定したDNS、アプリ単位の設定を少しずつ戻すことで、原因を絞り込めます。

テスト結果は「一時的に復旧した」のか「安定して復旧した」のかを分けて考えます。一度開けただけでは、その変更が根本原因だったとは言えません。調整後は同じ対象へ繰り返しアクセスし、フォアグラウンドとバックグラウンドを切り替え、再接続し、ほかのよく使うアプリへの影響も確認してください。1つのブラウザだけで復旧したなら、まず拡張機能とキャッシュを確認します。すべてのアプリが同時に復旧した場合は、クライアント、システムプロキシ、接続先の層に変化があった可能性が高くなります。

症状を安定して再現できるようになったら、該当する章へ進みます。接続をまったく確立できない場合は、クライアントの権限と接続先とのハンドシェイクから確認します。接続成功と表示されるのにウェブへアクセスできない場合は、システムプロキシとDNSから確認します。夜間だけ明らかに遅くなる場合は、接続先の混雑とローカルネットワークの競合から確認します。特定のアプリだけ失敗する場合は、設定全体をリセットする必要はありません。この順序なら不要な操作を減らし、後の問い合わせにも明確な情報を提供できます。

まったく接続できない：ローカル権限から接続先とのハンドシェイクまで

「まったく接続できない」場合は、クライアントが起動しない、接続を押しても変化しない、状態が一瞬だけ切り替わって未接続に戻る、接続中のまま止まる、という状態に分けます。クライアントが起動しない場合は、通常ローカルの実行環境が原因です。操作後に変化がない場合は、ネットワーク権限、ローカルサービス、設定が反映されていない可能性があります。接続直後に切断される場合は、接続先への到達不能、システム時刻のずれ、ネットワーク切り替え、古いセッションの残留がよく見られます。接続中のままの場合は、現在のネットワークが必要な接続を許可しているか確認します。症状ごとに確認すべき方向が異なるため、すべてを接続先の障害と決めつけないでください。

クライアントに必要な権限があるか確認する

WindowsとmacOSでは、クライアントがシステムネットワークインターフェースを作成し、プロキシ設定を変更できるようにする必要があります。システムの権限確認をキャンセルすると、クライアント画面は正常に開いても、接続操作がシステムネットワーク層に反映されないことがあります。システムのネットワーク、プライバシー、セキュリティ設定を開き、VPNXVクライアント関連の権限が未確認状態になっていないか確認してください。Linuxでは起動方法とネットワーク管理サービスの組み合わせにも注意します。グラフィカル画面からの起動とターミナルからの起動では、引き継がれる環境変数が異なる場合があるため、テスト時は起動方法を統一してください。

iOSとAndroidでは、初回接続時にネットワーク構成の作成を求められます。構成を削除したことがある、システム更新後に権限状態が変わった、別のネットワークツールが同種のインターフェースを使用している場合は、まずほかのツールを終了し、VPNXVクライアントから接続をやり直します。接続状態のネットワークサービスを複数同時に残さないでください。複数のアイコンが有効と表示されても、通信が想定どおりの経路を選ぶとは限りません。システムプロキシとトンネルインターフェースが互いに上書きし、問題を引き起こすことがあります。

サブスクリプションと接続先をクライアントが読み取れるか確認する

接続先一覧が空なら、接続ボタンが機能しないのは当然です。まずユーザーパネルでサブスクリプションを取得できるか確認し、クライアントに戻って更新します。接続先の名前は表示されるのにすべて即時失敗する場合は、ネットワーク環境を変えて、現在のネットワークが原因かクライアント自体が原因かを確認します。固定回線から別の利用可能なネットワークへ、またはその逆に切り替えてテストできます。ネットワークを変えるとすぐ復旧する場合は、元のネットワークの経路、DNS、ゲストネットワークの制限、ローカルのセキュリティソフトを重点的に確認します。異なるネットワークでも症状が同じなら、クライアント設定とアカウント状態を確認してください。

接続できない状態で複数の接続先を連続して素早くクリックしないでください。前の接続処理が終わる前に次の処理が状態を上書きし、ローカルインターフェースが解放されないことがあります。正しくは現在の接続を停止し、クライアントが明確な未接続状態に戻るまで待ってから別の接続先を選びます。接続先の種類を比較する場合は、接続先一覧の説明を確認してください。IEPL、中継、直結は経路が異なるため、同じ種類の接続先を無秩序に切り替えるより、種類を変えるほうが判断材料になります。

システム時刻と古いネットワーク状態を確認する

暗号化接続は正確なシステム時刻を必要とします。端末の時刻、日付、タイムゾーンが大きくずれていると認証を拒否され、クライアントには一般的な接続失敗だけが表示されることがあります。システムの時刻を自動同期にし、スリープ復帰後に古い時刻のままになっていないか確認してください。その後、クライアントを完全に終了してから再起動し、もう一度テストします。ウィンドウを閉じるだけでは終了したことにならず、一部のデスクトップクライアントはバックグラウンドでネットワークサービスを維持します。トレイ、メニューバー、システムのタスク管理画面でプロセスが終了しているか確認してください。

端末がスリープ、ネットワーク切り替え、異常終了から復帰した直後なら、古いインターフェースに無効な経路が残っている可能性があります。まずクライアントを切断し、現在のネットワーク接続を無効にしてから再度有効にし、最後にクライアントを開き直します。これらの元に戻せる操作がすべて効かない場合に限り、システムネットワークのリセットを検討してください。ネットワークのリセットは保存済みのローカルネットワーク、企業設定、ほかのプロキシ設定に影響するため、最初に行う操作ではありません。

nslookup example.com
curl -I https://example.com

上記のコマンドは、ドメイン解決と基本リクエストを切り分けるためのものです。ドメインの問い合わせ自体に失敗する場合はDNSの章へ進みます。ドメインは解決できるのにリクエストを確立できない場合は、プロキシ経路と接続先を確認します。コマンド出力にはローカルネットワーク情報が含まれることがあるため、問い合わせを送る前に無関係な個人情報を削除してください。異なるネットワーク、異なる接続先の種類、初期設定のすべてで接続できず、エラーを安定して再現できるなら、問い合わせを送る条件が整っています。

接続済みと表示されるのにウェブが開かない

クライアントに「接続済み」と表示されるのは、ローカルのトンネルまたはプロキシサービスが起動したことを示すだけで、すべてのアプリの通信がその経路に入ったことを意味しません。ウェブが開かない場合は、まず影響範囲を確認します。すべてのブラウザで失敗するのか、特定のブラウザだけなのか。ドメインが開かないのか、既知のアドレスにもアクセスできないのか。海外サイトに問題があるとき、日本国内のサイトは正常なのか。クライアントを閉じるとネットワークが戻るのか。この範囲によって、問題がDNS、ブラウザ、システムプロキシ、ルールによる振り分け、接続先の出口のどこにあるかが決まります。

まずブラウザの問題とシステムの問題を分ける

ネットワーク関連の拡張機能を入れていない別のブラウザで同じページを開きます。別のブラウザが正常なら、元のブラウザのプロキシ拡張機能、安全なDNS、キャッシュ、持続接続を優先的に確認してください。ブラウザが独自のDNSを有効にして、クライアントが提供する解決経路を回避している可能性があります。また、接続前に確立された古いセッションを保持し、無効な出口を使い続けることもあります。ページを更新するだけでなく、ブラウザを完全に終了してから再起動すると、古い接続をより確実に消去できます。プライベートウィンドウはキャッシュの切り分けに役立ちますが、ブラウザ単位のプロキシや安全なDNS設定は回避しないため、該当項目は引き続き確認してください。

すべてのブラウザとアプリでネットワークに接続できない場合は、システムプロキシが正しく書き込まれているか確認します。クライアントが異常終了すると、システムに古いプロキシアドレスが残ることがあります。クライアントが再接続しても、ローカルの待受サービスがその場所で動作していなければ、すべてのリクエストが存在しない入口へ送られます。まず接続を切り、システムプロキシが通常の状態に戻っていることを確認してから再接続してください。出所の分からないプロキシアドレスを手入力したり、ガイドの例示値を実際の設定として使ったりしないでください。

モードとルールが対象を誤った経路へ送っていないか確認する

ルールモードでは、ドメイン、アドレス、アプリに応じてプロキシ経由か直結かを決めます。古いルール、順序の誤り、カスタム項目の競合により、対象サイトが不適切な経路へ送られることがあります。確認時は一時的にクライアントのグローバルモードへ切り替えてテストできます。グローバルモードが正常でルールモードだけ失敗するなら、接続先自体は通常利用でき、問題はルールの適用に集中しています。初期ルールに戻し、カスタム内容を1つずつ確認してください。接続先をさらに変更し続ける必要はありません。テスト後は実際の用途に合わせてモードを選び直します。

グローバルモードでも失敗する場合は、用途が近くても経路の種類が異なる別の接続先を試します。ウェブアクセスは接続先の出口、DNS解決、対象サイトの応答に左右されるため、1つの出口に一時的な異常があってもサブスクリプション全体が使えないとは限りません。VPNXVは100+か国 / 150+の接続先に対応しています。確認時は名前が似た接続先を連続してクリックするのではなく、明確な違いのある接続先を比較してください。特定地域の出口だけが特定サイトへアクセスできない場合、対象サイトが地域、アカウント状態、セッション内容を制限している可能性もあり、1ページだけで接続先全体の障害とは判断できません。

無効な名前解決と古い接続をクリアする

システムとブラウザはいずれもドメイン解決をキャッシュします。接続前に取得したアドレスが元のネットワークに対応していて、接続後も使われ続けることがあります。逆に、切断後もプロキシ環境で取得した結果が残る場合があります。まずブラウザを完全に終了し、クライアントを切断して再接続し、同じドメインをテストします。デスクトップシステムでは、システムが提供するDNSキャッシュ削除機能を使用できますが、コマンドはプラットフォームによって異なります。不明な出所の高権限スクリプトをコピーすることは推奨しません。削除後に一時的に復旧してすぐ失敗する場合は、キャッシュを何度も消すのではなく、DNSの取得元とブラウザの安全なDNSを確認してください。

ページ自体が複数のドメインに依存していないかも確認します。トップページが開いても、画像、ログインAPI、メディアリソースが同じドメインを使うとは限りません。ルールモードがメインドメインだけをプロキシし、関連リソースを直結させると、ページが白紙になる、ログインボタンが反応しない、コンテンツの読み込みが不完全になることがあります。クライアントログを開き、失敗時に表示される対象ドメインと適用されたルールを確認してください。ログにサブスクリプショントークンやアカウント情報が含まれる場合は、共有前に必ず隠します。

VPNXVを閉じてもネットワークが戻らない場合、システムにプロキシまたは経路の状態が残っている可能性があります。まずクライアントが完全に終了していることを確認し、システムプロキシがローカルサービスを指し続けていないか確認します。元の設定の用途を理解している場合だけ手動で変更してください。企業ネットワーク、開発環境、ほかのツールもプロキシを使うことがあります。判断できない場合は、システム設定をむやみに削除するより、スクリーンショットを残して問い合わせるほうが安全です。

速度低下と混雑時間帯を層別に判断する

速度の問題は、1回の速度テストだけでは判断できません。ウェブの初回表示が遅い、ファイル転送が継続的に遅い、動画がバッファリングする、操作の遅延が大きい、といった症状は、DNS、往復経路、出口帯域、対象サービス、ローカルネットワークの影響をそれぞれ受けます。確認前にどの体験が悪化しているかを明確にし、固定した対象で繰り返しテストします。接続先とテストサイトを同時に変更したり、クラウド同期、システム更新、メディア再生を同時に行ったりしないでください。変化が接続先によるものか、ローカルの通信競合によるものか分からなくなります。

ローカルネットワークの基準を作る

まずクライアントを切断し、現在のネットワーク自体でよく使う国内サービスへ安定してアクセスできるか確認します。切断後も同じように遅いなら、ルーター、無線干渉、接続ネットワークの混雑、バックグラウンドのダウンロードを優先的に確認します。国際経路でローカル接続品質を改善することはできません。固定回線では有線接続に変えて比較できます。無線環境では端末の位置を調整し、電波の境界や頻繁にローミングする場所を避けます。モバイルネットワークでは基地局の切り替えや電波状態の変化によって一時的な揺らぎが生じるため、テスト中は位置とネットワークの種類を安定させてください。

続いて、地理的に近い経路の接続先へ接続し、同じアプリと同じ対象で繰り返し操作します。近距離の接続先が明らかに安定し、遠距離の接続先で操作遅延が大きいなら、物理的な経路差による正常な現象です。接続先は地域名だけで選ばず、用途も確認します。リアルタイムの共同作業、リモート端末、音声では応答の連続性が重要です。大容量ファイルの転送では継続的なスループットが重視されます。ストリーミングでは対象プラットフォームの地域やキャッシュ方針も影響します。接続先一覧を参考にIEPL、中継、直結を選び、すべての用途を同じ出口に固定する必要はありません。

混雑時間帯の遅延がどこで起きるか見極める

昼間は安定していて夜間に繰り返し遅くなる場合は、まず切断後のローカルネットワークと比較します。国内アクセスも遅いなら、接続ネットワークの混雑である可能性が高くなります。ローカルネットワークが正常で特定の種類の接続先だけ遅いなら、異なる経路の種類へ切り替える意味があります。同じ地域の似た接続先だけを切り替えないでください。上流経路の一部を共有している可能性があります。別の地域または別の種類の接続先を選び、遅延が経路に応じて変化するかを確認すると、ローカル接続、国際区間、対象サービスのどこに問題があるか判断しやすくなります。

混雑時間帯のテストでは、一瞬の最高値ではなく連続した使用感を見ます。ウェブが安定して読み込みを完了するか、メディアの品質が何度も下がるか、リモート操作が長時間停止するかのほうが、実用性をよく表します。速度テストのサーバーと実際の対象は同じネットワークにないため、結果が良くても実際のアプリが遅いことがあります。反対に、速度テストの結果が普通でも、テキストの共同作業やウェブ閲覧が必ず使えないとは限りません。最終的には自分の主な用途を基準にしてください。

端末上の通信競合を確認する

システム更新、クラウド同期、写真のバックアップ、ゲームプラットフォームの更新、ブラウザの先読みはネットワークを使用します。画面を閉じても一部の処理はバックグラウンドで続きます。確認時はシステムのネットワーク使用状況を確認し、テストと無関係な通信を一時停止してから再接続してください。VPNXVは同時接続台数に制限がありませんが、複数の端末で大容量通信を同時に行えば、現在利用しているネットワークの容量を共有します。「同時接続台数に制限なし」はオンライン端末数の制限を示すもので、ローカル回線のリソースが共有されないという意味ではありません。

クライアントの複雑なルールも判断を難しくします。多数のカスタムルール、チェーンプロキシ、追加フィルターがあると、同じアプリのリクエストごとに経路が分かれ、メインページは速いのにリソースだけ遅いという状態になります。まず初期設定に戻してテストし、基本の接続先が正常なことを確認してから、必要なルールを少しずつ追加します。追加するたびに同じ操作を繰り返せば、症状が悪化した時点で直前の変更を特定できます。

問題が特定の時間帯、特定の接続先の種類、特定の対象でだけ発生するなら、問い合わせにはその条件を明記してください。速度テストのスクリーンショットを1枚添付するだけでは不十分です。サポートには、切断時のローカルネットワークが正常だったか、ほかの接続先が正常だったか、問題を安定して再現できるか、主に影響を受けるアプリは何かを伝える必要があります。情報が具体的であるほど、接続先を調整すべきかクライアント設定を確認すべきか判断しやすくなります。

頻繁な切断とモバイル端末のバックグラウンド切断

頻繁な切断では、まず接続先とのセッションが本当に切れたのか、アプリがバックグラウンドに入りシステムによって停止されたのかを判断します。デスクトップでは、クライアントが未接続になる、システムネットワークが一時的に切れる、ネットワーク切り替え後に自動復旧しない、といった症状がよくあります。モバイル端末では、画面ロック、ネットワーク切り替え、省電力設定の後に接続維持が止まることがあります。両者の対処は異なります。ステータスバーのアイコンが消えただけでは原因を特定できないため、クライアントで接続状態、最近のエラー、システムネットワークの変化を確認してください。

デスクトップではスリープとネットワーク切り替えを先に確認する

WindowsとmacOSがスリープから復帰すると、ネットワークインターフェースが再構築され、元のセッションが無効になることがあります。クライアントが新しいネットワーク状態をすぐ取得できないと、接続しているように見えるのに通信できない状態になります。まず自動スリープを一時的に無効にして比較するか、復帰後に手動で切断して再接続してください。スリープ後にだけ発生するなら、クライアントのバックグラウンド実行権限とシステムの省電力設定を重点的に確認します。サブスクリプションを何度も変更する必要はありません。

有線から無線へ、固定ネットワークから共有ネットワークへ切り替えると、ローカルアドレスとデフォルト経路が変わります。切り替え時に古いセッションが元のインターフェースに残ると、通常そのまま移行できません。システムが新しいネットワークを利用可能と確認するまで待ち、その後クライアントを再接続します。クライアントに自動再接続の設定がある場合は有効にしてテストできますが、切り替え中に古いシステムプロキシが残らないことも確認してください。自動再接続は頻繁であるほど良いわけではなく、ネットワークが安定する前に繰り返すと状態が何度も変わることがあります。

モバイル端末ではバックグラウンドと省電力設定を確認する

iOSとAndroidは、バッテリー残量、バックグラウンド動作、ネットワーク状態に応じてアプリを管理します。VPNXVクライアントのバックグラウンド実行が制限されていると、画面を消した後に接続を維持する処理が停止することがあります。システム設定で必要なバックグラウンド通信を許可し、クライアントを厳格なスリープや強力な省電力の対象に入れないでください。端末メーカーによって設定名は異なりますが、判断方法は共通です。同じ接続先を使い、前面では正常なのにバックグラウンドへ移るとすぐ切断され、クライアントを開き直すと復旧するなら、接続先の継続的な障害よりもシステムのバックグラウンド制御が疑われます。

モバイル端末が無線ネットワークとモバイルネットワークの間で切り替わると、接続が再作成されることがあります。無線の範囲外へ移動したときや、電波の弱い場所に入ったときだけ問題が起きるなら、自動切り替えを一時的に無効にして比較し、単一ネットワークで安定するか確認します。単一ネットワークで安定するなら、原因はネットワーク移行にあります。この場合は自動再接続を有効にし、同時に動作するほかのネットワークツールを減らすほうが、特定の接続先に固定するより効果的です。

接続先の切断とアプリのフリーズを分ける

クライアントは接続中と表示されているのに、すべてのリクエストが止まり、接続先を切り替えると復旧することがあります。クライアントがセッションの無効化をすぐ判定できていない可能性があります。まず特定のアプリだけが停止しているか確認します。ブラウザ、システムのリクエスト、ほかのアプリが正常なら、問題はアプリ側にある可能性が高くなります。すべてのアプリが同時に停止した場合は、同じ接続先を切断して再接続します。同じ接続先への再接続で復旧するならセッション状態の問題が考えられ、接続先を変えた場合だけ復旧するなら、出口や経路を比較する必要があります。

クライアントログでは時間の順序が重要です。切断前にネットワーク切り替え、スリープ、システムプロキシの変更、DNSエラーが発生していなかったか記録します。最後の1行だけを切り取らないでください。最後に表示された再接続失敗は、その前のネットワーク切断の結果にすぎない場合があります。ログを送るときは、障害の前後にある連続した内容を残し、サブスクリプショントークンやユーザー名などの機密項目を削除します。ログが長い場合は再現操作を記載し、サポートが該当箇所から確認できるようにしてください。

頻繁な切断にローカルネットワーク全体の中断が伴うなら、まず接続ネットワークを確認します。ルーターの再接続、無線ローミング、電波の揺らぎはいずれも上位の接続を切断します。ローカルネットワークが安定していて、異なるプラットフォームやネットワークでもVPNXVが同じ接続先で切断を安定して再現する場合は、問い合わせを送ってください。問い合わせには、プラットフォーム、ネットワークの種類、接続先名、スリープや前面・バックグラウンドの切り替えの有無、同じ接続先への再接続で復旧するかを記載します。

サブスクリプション更新失敗と接続先一覧の異常

サブスクリプション更新失敗には、接続先一覧が空、古い接続先が表示され続ける、更新ボタンでエラーが出る、インポート後に何も変わらない、同じサブスクリプションが一方のクライアントでは使えるのに別のクライアントでは認識されない、といった症状があります。確認時は「サブスクリプションを取得できない」状態と「取得できたが解析に失敗する」状態を分けます。前者はログイン状態、サブスクリプションURL、ネットワークアクセス、アカウント状態に関係することが多く、後者はクライアントの形式、キャッシュ、インポート画面、古い設定との競合に関係することが多いです。

ユーザーパネルからサブスクリプションを取得し直す

チャット履歴、スクリーンショットの読み取り結果、古いメモからサブスクリプションをコピーしないでください。ユーザーパネルにログインし、ダウンロードまたはサブスクリプションの画面から現在の内容を取得します。サブスクリプションは機密情報なので、公開したり完全なURLを問い合わせに送ったりしないでください。VPNXVはメールアドレスなしで登録でき、ユーザー名とパスワードで登録できます。ユーザー名やパスワードを忘れた場合は、新しいアカウントを何度も作るのではなく、まずローカルに保存した情報を確認してください。複数のアカウントを混在させると、「パネルにはプランがあるのに、クライアントは別のサブスクリプションを取得している」という錯覚が起きやすくなります。

コピー時に前後の空白、改行、句読点を含めないよう注意してください。空白を自動削除するアプリもあれば、アドレスの一部として扱うアプリもあります。システムのクリップボードで端末間に渡す場合は、テキストツールによって途中で切られていないか確認します。サブスクリプションをインポートしたら、クライアントで明示的に更新を実行してください。名前を保存するだけでは不十分です。クライアントに古いサブスクリプションが残っている場合は、現在見ている接続先がどのグループに属するか確認し、古い一覧だけを見て新しいサブスクリプションが反映されていないと判断しないでください。

https://example.com/sub?token=YOUR_TOKEN

上記のアドレスはサブスクリプションURLの構造を説明するための明らかな例であり、接続には使えません。実際のサブスクリプションはVPNXVのユーザーパネルからのみ取得してください。トラブルシューティングのスクリーンショットでは、クエリパラメータ以降のトークンを隠します。問い合わせには通常、完全なトークンは不要で、エラー表示、クライアントのプラットフォーム、インポート方法、発生した時間帯だけで十分です。

ダウンロード失敗か解析失敗かを判断する

更新時にすぐネットワークエラーが表示される場合は、まずクライアント自体がサブスクリプションの取得元へアクセスできるか確認します。クライアントによっては、サブスクリプション更新はシステムネットワークに従い、接続先への通信は別の経路を使うため、接続済みでも更新リクエストが同じ出口を通るとは限りません。切断状態と接続状態でそれぞれ試し、違いを記録します。更新リクエストは完了するのに一覧が空、または形式を認識できないと表示される場合は、正しいサブスクリプションのインポート画面を選んでいるか、クライアントがパネル提供の形式に対応しているかを確認します。

同じサブスクリプションを別の対応プラットフォームで正常に読み取れるなら、重要な比較材料になります。アカウントと取得元はおそらく利用可能で、問題は元のクライアントのキャッシュまたは解析に集中しています。この場合は古い項目を削除せず、独立したサブスクリプション項目を新規作成して読み取れるか確認します。古い設定を残せば、利用可能なルールを誤って削除せずに済み、項目の違いも比較できます。新しい項目が正常なことを確認してから、重複項目を整理してください。

キャッシュ、重複サブスクリプション、更新による上書きを処理する

クライアントはサブスクリプション名、アドレス、内部識別子に基づいて内容をキャッシュすることがあります。同じアドレスを何度もインポートすると、画面上は新しい項目が増えたように見えても、実際には古いキャッシュを参照している場合があります。まず現在の項目を更新し、更新時刻と接続先一覧が変わったか確認します。変化がなければクライアントを終了して再起動し、名前を明確にした新しいサブスクリプション項目を作成します。自動生成される部分を手動で編集したり、サブスクリプション内の接続先名を頻繁に変更したりしないでください。次回の更新で変更が上書きされます。

カスタムルールはサブスクリプションの接続先設定とは分けて保存してください。自動更新領域にルールを直接書き込み、更新後に消えたとしても、サブスクリプションが壊れたわけではありません。クライアントが設計どおりにリモートの内容へ置き換えたためです。クライアントが提供する上書き、設定の統合、独立したルール画面を使う方法が安全です。画面はプラットフォームによって異なります。不明な場合はすぐに始めるガイドへ戻り、標準のインポート手順からカスタム設定を少しずつ復元してください。

アカウントと通信量の状態を確認する

月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中でのアップグレード差額は残り日数分に換算されます。通信量パックは使い切るまで有効で、永久に期限切れになりません。パネルに表示されるプランや通信量の状態が想定と異なる場合、サブスクリプションを何度もインポートして解決しようとしないでください。クライアントはパネルが生成した結果を読むだけで、アカウント状態を変更できません。まずパネルで現在のアカウント、プランの種類、注文履歴を確認し、アカウントに関する問い合わせが必要か判断します。

ユーザーパネルが正常に開き、サブスクリプションをコピーできるのに、複数の対応クライアントで読み取れず、エラー原文も一致する場合は問い合わせを送れます。プラットフォーム、クライアントのインポート画面、エラー原文、別のネットワークで更新できるか、パネルにサブスクリプションが表示されるかを添えてください。完全なサブスクリプションURLやパスワードは添付しないでください。追加確認が必要な場合、サポートが問い合わせを通じて必要な情報を案内します。

特定のアプリだけプロキシを経由しない

ブラウザは正常なのに特定のアプリだけネットワークに接続できない場合、通常はクライアント全体をリセットする必要はありません。アプリがシステムプロキシを回避している、独自のネットワークスタックを使っている、アプリ内プロキシが設定されている、特定のプロトコルだけを使っている、ルールによって直結と判定されている可能性があります。まず、アプリが起動時に失敗するのか、ログイン時に失敗するのか、画像、音声、同期など一部の機能だけが失敗するのかを確認します。現在のアプリは、画面、認証、コンテンツを異なるドメインに分けることが多く、特定機能の異常はアプリ全体が非対応なのではなく、一部のリクエストが誤った経路を通っていることを示す場合があります。

グローバルモードでルールの適用を確認する

現在の接続先を維持したまま、一時的にグローバルモードへ切り替え、対象アプリを完全に終了してから再起動します。アプリが復旧したなら、接続先自体はその通信を処理でき、問題はルールに集中しています。クライアントログでアプリ起動時にアクセスしたドメインとアドレスを確認し、どのルールが適用されたかを確認してください。ルールは通常、上から順に照合されます。範囲の広い直結ルールが前にあると、本来プロキシを通すべきリクエストを先に捕捉することがあります。変更時は対象に関係する項目だけを修正し、不明な通信をすべて同じ経路へ恒久的に変更しないでください。

グローバルモードでも効果がない場合は、アプリ自体にプロキシ設定がないか確認します。アプリ内プロキシがシステムプロキシを上書きし、古いアドレスや停止したローカルポートを指していることがあります。アプリのプロキシをシステム設定に従う状態へ戻して再テストします。起動時にだけプロキシ環境を読み取るアプリもあるため、変更後はプロセスを完全に終了してください。ウィンドウを閉じるだけでは設定が再読み込みされないことがあります。

アプリの振り分けとシステム権限を確認する

アプリ単位の振り分けに対応するクライアントでは、どのアプリをプロキシへ送るか選択する必要があります。システム更新、アプリの再インストール、パスの変更後に、以前の選択が現在のプログラムを指さなくなることがあります。対象アプリを選び直し、直結リストとプロキシリストの両方に同時に入っていないことを確認します。Windowsでは同じ製品に複数の起動プログラムがある場合があります。macOSのアプリも補助プロセスからネットワーク要求を送ることがあります。画面のプログラムだけを選び、ネットワーク用の補助プロセスを選び忘れると、ログインは成功してもコンテンツを読み込めないことがあります。

モバイル端末のアプリ単位設定は、システムの機能による制限を受けます。クライアントがグローバルモードまたはルールモードしか提供していない場合は、存在しないアプリ設定を探すのではなく、ドメインルールで処理します。iOSとAndroidのシステムネットワーク権限は、企業設定、仕事用プロファイル、ほかのネットワークサービスの影響も受けます。確認時はまず通常のネットワーク環境でテストし、管理対象の設定によってアプリの経路が変わっていないか確認してください。

一部のリソースだけ失敗する場合は関連ドメインを確認する

アプリのメイン画面は開くのに、画像、添付ファイル、音声、ログインのコールバックだけが失敗するなら、関連ドメインが同じポリシーで処理されていない可能性があります。クライアントの接続ログを開き、問題を安定して再現できる操作を1回行い、失敗前後に表示されるドメインを確認します。複数の機能を一度に操作しないでください。ログとの対応が難しくなります。関連ドメインを特定したら、まず一時的なルールを追加して確認します。復旧したら恒久的なルールとして整理し、用途を記録して、後で誤って削除しないようにします。

アプリが特定地域のアカウントを使っている場合、出口を切り替えると再認証やコンテンツの違いが発生することがあります。その場合は出口地域を安定させ、アプリの古いセッションを消去してからテストします。短時間に複数の地域へ連続して切り替えないでください。アカウント側の状態変化が増え、接続先の問題とアカウントの問題が混在します。AI ツールでアプリとウェブの挙動が異なる場合はAI特集を、Windowsのグローバルプロキシと振り分けについてはWindows VPN実測比較を参照してください。

問い合わせが必要な場合は、アプリ名、影響を受ける機能、グローバルモードとルールモードの比較結果、アプリ内にプロキシ設定があるか、別の接続先の種類で変化したかを記載します。アプリにエラーコードが表示される場合は原文を添付できますが、再現手順のないエラーコードのスクリーンショットだけを送らないでください。サポートがルール、プロトコル、対象サービスの応答のどれが原因か判断するには、どの操作の後に問題が起きたかが必要です。

DNS異常：解決失敗、アドレスの不一致、漏洩の判断

DNSはドメインをネットワークアドレスへ変換します。異常があると、ドメインが開かない、既知のアドレスへの直接リクエストには応答がある、特定のサイトが誤った地域へ移動する、接続後も元のネットワークのDNSを使い続ける、ブラウザとコマンドラインで同じドメインの結果が異なる、といった症状が出ます。最終的にはページが読み込めないため、DNSの問題は接続先の障害と誤認されやすいものです。確認の重点は、リクエストを誰が解決しているか、結果がキャッシュを経由しているか、ブラウザがシステム設定を回避していないかです。

システム、ブラウザ、クライアントの名前解決元を比較する

クライアントがシステムDNSを引き継ぐ場合もあれば、プロキシだけを設定してシステムの名前解決を残す場合もあります。ブラウザが独自の安全なDNSを有効にすることもあります。3つが同時に存在すると、同じドメインが異なる解決経路を通ります。まずブラウザ独自のDNSを無効にし、システムの初期設定でテストします。次にクライアントでカスタムDNSまたはリモート解決が有効か確認します。確認中は明確な取得元を1つだけにし、安定したことを確認してからブラウザ設定を戻してください。

コマンドラインのドメイン問い合わせは、システムの名前解決を比較する材料になりますが、ブラウザの挙動を完全に再現するとは限りません。ブラウザは解決結果をキャッシュしたり、対象へ先に接続したり、独自の暗号化解決を使ったりすることがあります。コマンドラインは成功するのにブラウザが失敗する場合は、ブラウザのキャッシュと拡張機能を重点的に確認します。両方が失敗する場合は、システムとクライアントを確認します。ツールによって結果が違うからといって、すぐに漏洩と判断せず、それらのリクエストが本来同じ解決経路を通るべきか確認してください。

キャッシュと誤ったアドレスを処理する

DNSキャッシュは、システム、ブラウザ、ルーター、アプリなど複数の層に存在します。1か所だけ削除しても、別の層から古い結果が返ることがあります。まず対象アプリを完全に終了し、クライアントを切断して再接続してからアプリを起動する方法を推奨します。それでも問題が続く場合は、システムが提供するキャッシュ削除方法を使います。ルーターのキャッシュを直接確認できない場合は、別のネットワークに切り替えて比較します。別のネットワークが正常なら、元のネットワークの名前解決または経路を確認する価値があります。

同じドメインから複数のアドレスが返ることは、必ずしも異常ではありません。コンテンツ配信ネットワークは、解決元と出口の位置に応じて異なるアドレスを割り当てます。確認すべきなのは、返されたアドレスへ継続的にアクセスできないか、特定の解決元でだけ発生するか、接続先を切り替えると出口地域に合った結果になるかです。正常な複数アドレスの応答を汚染と決めつけたり、一時的なアドレスを手動で固定して恒久対策にしたりしないでください。対象サービスの変更後、固定アドレスが無効になることがあります。

カスタムDNSの限界

カスタムDNSは解決元を統一するのに役立ちますが、すべての障害を直す万能策ではありません。問題が接続先への到達不能にあるなら、解決サービスを変えてもアクセスできないアドレスが返るだけです。ルールによる振り分けが原因なら、カスタムDNSによってドメインと出口のポリシーがさらに一致しなくなることもあります。有効にする前に、クライアントがローカル解決とリモート解決のどちらを使うか、解決リクエスト自体が直結かプロキシ経由かを確認してください。判断できない場合は初期設定に戻し、クライアントが想定された経路を使うようにします。

ルールモードは判断にドメイン情報を使うことがあります。アプリがアドレスへ直接接続する、内蔵の名前解決を使う、独立したプロトコルにリクエストを包む場合、クライアントが得られる情報が不足し、ルールが機能しないことがあります。グローバルモードは正常でルールモードだけ異常なら、DNSとルールの両方が関係しています。ログに対象ドメインが表示されるか、どのルールが適用されたかを確認してから、ルールの追加と解決モードの調整のどちらが必要か判断します。

nslookup example.com
curl -I https://example.com

問い合わせを実行する際は、同じネットワーク、同じクライアント状態でテストし、前後の条件を変えないでください。接続前後を比較する場合は、それぞれの出力を保存し、状態を明記します。出力にサブスクリプションURL、ユーザー名、その他のアカウント情報を含める必要はありません。ドメインの問い合わせは成功するのにリクエストが失敗するなら、接続先とプロキシを確認します。問い合わせが失敗して別のネットワークでは正常なら、現在のDNSの取得元を重点的に確認します。結果は正常でブラウザだけ異常なら、ブラウザ設定に戻ります。

DNSについて問い合わせる際は、影響を受けるドメイン、システムのプラットフォーム、クライアントのモード、ブラウザで独自DNSを有効にしているか、コマンドラインの問い合わせが成功したか、ネットワークを切り替えた結果を提供します。閲覧履歴全体は送らないでください。サポートに必要なのは、問題を再現できる対象と条件だけです。特定サイトの地域コンテンツが関係する場合は、選択した出口地域とアカウント地域が一致しているかも記載し、サイト固有の方針をDNS障害と取り違えないようにします。

端末の通知、通信量の状態、問い合わせ情報

クライアントが端末、認証、通信量、アカウントの異常を通知した場合は、まずユーザーパネルでアカウントを確認します。VPNXVは同時接続台数に制限がないため、「端末数の上限」のような表示をプランの制限と直接解釈しないでください。よくある原因は、クライアントが古いアカウントを使っている、サードパーティ製クライアントがローカルに端末記録を保持している、セッション状態が更新されていない、エラー文がVPNXVのパネルではなくローカル設定から出ている、といったものです。現在クライアントにインポートされているサブスクリプションが、ログイン中のアカウントに属するか確認し、サブスクリプションを取得し直してテストしてください。

プランの通信量とローカルネットワークの制限を分ける

月額サブスクリプションは ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBを含み、通信量は開通日を基準に毎月リセットされます。途中でのアップグレード差額は残り日数分に換算されます。通信量パックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効で永久に期限切れになりません。クライアントに接続できないと表示された場合は、パネルで現在利用しているのが月額サブスクリプションか通信量パックかを確認し、対応する状態を確認します。クライアントの削除、システムの再インストール、サブスクリプションの繰り返し更新で、アカウント側の通信量記録を変更することはできません。

パネルの状態が正常なのにクライアントに古い情報が表示される場合は、まずサブスクリプションを更新し、クライアントを完全に終了してから再起動します。複数のサブスクリプション項目がある場合は、実際に接続している接続先がどの項目に属するか確認します。名前が同じでも取得元が同じとは限らず、古いサブスクリプションが一覧に残っていることがあります。項目名を一時的に区別しやすいローカル名へ変更することはできますが、リモートで生成された接続先の項目は編集しないでください。

支払いと返金では注文情報を残す

VPNXVはAlipay / WeChat Pay / USDTに対応しています。支払い完了後もパネルの状態が変わらない場合、同じ注文を繰り返し作成したり、新しいアカウントを作って解決しようとしたりしないでください。パネルに表示された注文状態、支払い方法、問題が発生した操作の流れを残し、ユーザーパネルから問い合わせを送ります。返金については、本文では14日間の理由不要返金と案内します。具体的な申請方法と対象範囲は返金ポリシーを確認してください。

プランごとの違いと通信量の用途はプラン料金ページで確認できます。途中でアップグレードする場合は、ユーザーパネルのプラン画面から操作してください。途中でのアップグレード差額は残り日数分に換算されます。金額を自分で換算したり、複数回注文して期間をつなぎ合わせたりしないでください。パネルの表示と注文内容が一致しない場合は、注文履歴をもとにサポートへ確認を依頼します。

問い合わせを送るべきケース

初期設定でのテスト、異なる接続先の種類への切り替え、異なるネットワークの比較を行っても問題を安定して再現できるなら、技術問い合わせに適しています。アカウント状態、注文、通信量の記録、サブスクリプション生成の異常も、問い合わせで直接処理してください。障害が一度だけ発生し、再接続後に再発していない場合は、記録を残して様子を見てもかまいません。問題が継続する、範囲が明確、アカウント状態に関係する場合は、クライアントを何度も再インストールする必要はありません。

問い合わせ窓口はユーザーパネルにあります。タイトルには「Windows接続後にウェブの名前解決ができない」「Androidでバックグラウンド中にネットワークを切り替えると切断される」のように症状を直接書き、「助けてください」だけにしないでください。本文ではまずプラットフォームとネットワーク環境を書き、次に接続先名と接続先の種類を記載します。その後、操作、期待した結果、実際の結果、試した対処を時系列で説明します。特定のアプリだけに影響する場合は、アプリ名、影響を受ける機能、グローバルモードとルールモードの比較結果を添えてください。

役立つログを保存する方法

ログは障害発生前後の連続した過程を含めます。準備操作を明確に記録し、問題を安定して再現できる操作を1回実行したら、それ以上の試行を止めてください。大量の再接続情報で重要な箇所が埋もれるのを防ぎます。ログレベルはクライアントの初期値で十分です。不慣れなデバッグ機能を、情報量を増やすためだけに有効にしないでください。書き出した後、サブスクリプションURL、トークン、アカウント項目を検索し、隠してからアップロードします。

スクリーンショットには状態とエラーの表示箇所を含めますが、デスクトップ全体を写す必要はありません。エラーがすぐ消える場合は短い操作動画を録画できますが、サポートがクリック順を画面だけから推測することはできないため、本文にも手順を書いてください。速度の問題では、速度テストの結果1枚だけでは特定できません。切断時の状態、異なる接続先の種類による違い、主に影響を受ける実際のアプリを説明してください。

問い合わせへの返信で追加情報を求められた場合は、同じ問い合わせに返信し、別の独立した問題として分けないでください。同じ障害を複数の問い合わせに分散すると、前後の判断材料が失われます。問題が復旧した後も、どの操作が有効だったか追記すると、根本原因の確認に役立ちます。システムの確認で目指すのは、できるだけ多くの設定を試すことではなく、最小限の変数で検証可能な結論を得ることです。