VPNトラブルシューティング完全ガイド - VPNXA｜接続・速度・サブスクリプションの問題

SCOPE FIRST

まず影響範囲を確認

ネットワークの問題で最も起こりやすいミスは、最初から多くの変数を変更してしまうことです。Webサイトが開けないと、すぐにクライアントを再インストールしたり、サブスクリプションを入れ直したり、プロトコルやDNSを変更したりしがちです。たまたま復旧しても、どの操作が有効だったのか分からなくなります。より確実なのは、まず症状を具体化し、比較できる基準を作ることです。VPNXA のクイックスタートガイドでは利用開始から接続までの基本操作を案内し、このページでは接続異常や不安定な動作、特定アプリの予期しない挙動を項目別に確認できます。

「使えない」を検証可能な症状に置き換える

まず影響範囲を確認します。まったく接続できない場合は、クライアントが長時間「接続中」のままになるか、ハンドシェイク、認証、タイムアウトなどのエラーがすぐに表示されます。接続済みと表示されるのにWebサイトを開けない場合、クライアントは少なくともローカルプロキシの状態を確立しているため、システムプロキシ、DNS、ルーティングルール、出口経路に原因がある可能性が高くなります。特定のWebサイトだけで問題が起きる場合は、クライアント全体を先に変更しないでください。地域別の配信方針、キャッシュ、アカウント地域、ブラウザー拡張機能なども影響します。特定のアプリだけが異常な場合は、システムプロキシを迂回していないか、独自のネットワークスタックを使っていないか、ルールモードがドメインに適用されているかを確認します。

問題がすべてのネットワーク環境で起きるのか、現在のネットワークだけで起きるのかも確認します。高速化接続を切り、普段安定して開ける一般的なWebサイトを表示してください。一般的なWebサイトも開けない場合は、まずローカルネットワークを復旧し、端末側の通信断を経路の障害と誤認しないようにします。同じ端末で別のネットワークに切り替えて比較する方法や、別の端末を同じネットワークに接続する方法もあります。前者は接続中のネットワークに制限があるか、後者は特定の端末だけの問題かを判断するのに役立ちます。VPNXA は Windows、macOS、iOS、Android、Linux に対応し、プランに端末台数の制限はないため、既存の別端末で比較確認できます。

一度に変更する変数は1つだけ

比較基準を作ったら、「ローカルネットワーク、クライアント、サブスクリプション、経路、システム設定、対象アプリ」の順に確認します。毎回1項目だけ変更し、変更後は同じテストを繰り返してください。たとえばWebサイト、速度測定の場所、測定方法は固定します。経路を切り替えて復旧した場合は、現在のクライアント設定とDNSをそのまま保ちます。ネットワークを変えて復旧した場合は、元のネットワークのゲートウェイ、認証ページ、アクセス方針を確認します。こうすれば、一度だけの偶然の成功ではなく、再現可能な結論を得られます。

症状を記録する際は、クライアントに表示されたエラー全文を残し、「エラーが出た」とだけ書かないでください。使用プラットフォーム、選択した経路、現在のネットワーク種別、問題が起きたおおよその時刻、すべてのWebサイトに影響するか、接続を切った後のローカルネットワークが正常かも記録します。スクリーンショットにはエラー表示と経路名を含めますが、ユーザー名、サブスクリプションの内容、アクセス認証情報は隠してください。ログにサブスクリプションURLが含まれる場合は、送信前にトークン部分を削除します。

システムツールで問題の層を確認する

コマンドラインは複雑な引数を使わなくても、有用な手がかりを示します。まずドメインを解決できるか確認し、次にシステムが現在使用しているプロキシ設定を確認します。ドメインを解決できるのにWeb接続を確立できない場合は、プロキシポート、システムファイアウォール、経路を重点的に確認します。ドメインを解決できないのに既知のサービスへ直接アクセスすると応答がある場合は、DNSを確認します。システムごとにコマンドは異なるため、実行前に機密情報を含む端末履歴の同期を停止し、出力にローカルユーザー名が含まれていれば送信前に隠してください。

nslookup example.com
ipconfig /flushdns

scutil --proxy
dscacheutil -flushcache

getent hosts example.com
env | grep -i proxy

これらのコマンドは名前解決とプロキシ環境の確認に使うもので、特定の経路が必ず利用できることを検証するものではありません。判断はクライアントの状態、ブラウザーの表示、ネットワーク比較と組み合わせて行います。基本確認でローカルネットワークの障害が明らかな場合は、ルーター接続、ネットワーク認証、システムのネットワークサービスを先に直してください。高速化接続を有効にしたときだけ異常が起きる場合は、後続の章に進みます。手順全体はソフトウェアを何度も再インストールするのではなく、原因の範囲を絞り込む作業として進めます。

CONNECTION

完全に接続できない

クライアントが接続を完了できない場合は、まずどの段階で止まっているかを確認します。接続ボタンを押してすぐ失敗する場合、サブスクリプションの読み込み不良、選択した経路がサブスクリプションから削除された、クライアントにシステム権限がない、または別のネットワークツールが同じプロキシ入口を使用していることが主な原因です。長時間待った後にタイムアウトする場合は、現在のネットワークから経路へ到達できない、ネットワーク品質が不安定、または現在の接続環境にその経路が適していない可能性が高くなります。認証失敗と表示された場合は、多数の経路を連続して切り替える前に、パネルのログイン状態とサブスクリプションの有効性を確認してください。

まずローカルネットワークとシステム時刻を確認する

クライアントの接続を切り、一般的なWebサイトとシステムのネットワークサービスが正常に使えることを確認します。公共ネットワークでは、先にブラウザーで認証を完了する必要がある場合があります。認証ページが自動表示されない場合は、高速化接続を一時的に切ってから、一般的なWebサイトを開き直してください。システム時刻に大きなずれがあると、安全な接続の検証に失敗することもあります。時刻はシステムの自動同期に任せ、手動で推測して設定しないでください。確認後はクライアントを終了して再起動し、認証前に作られた古い接続を使い続けないようにします。

同じ端末が別のネットワーク環境では接続できる場合、サブスクリプションとクライアントはおおむね正常で、元のネットワークに問題が集中しています。この場合は設定を削除し続けず、元のネットワークで追加のファイアウォール、ペアレンタルコントロール、企業ネットワークポリシー、ゲートウェイフィルタリングが有効になっていないかを比較します。すべてのネットワークで失敗する場合は、クライアントの権限とサブスクリプションを確認します。デスクトップシステムでは、ネットワーク拡張、仮想ネットワークインターフェース、ファイアウォールの許可が必要なことがあります。モバイルシステムでは、ネットワーク設定の許可が表示されます。権限が取り消されても、クライアント画面には経路一覧が残る場合がありますが、実際の通信経路は確立できません。

クライアント間の制御競合を確認する

同じ端末で複数のプロキシ、フィルター、パケットキャプチャ、セキュリティソフトを同時に動かすと、インターフェースの競合が起きやすくなります。確認時は、システムネットワークを制御する他のプログラムを完全に終了し、現在のクライアントだけを残してください。ウィンドウを閉じただけでは終了していない場合があるため、システムトレイ、メニューバー、バックグラウンドプロセスを確認します。ブラウザー独自のプロキシ拡張機能も一時停止してください。存在しないローカルポートへリクエストを送る可能性があります。接続が復旧したら、必要なツールを1つずつ有効にし、どのコンポーネントが競合を起こすか確認します。

システムプロキシの残留もよくある原因です。クライアントが異常終了すると、OSがWebリクエストを古いローカルプロキシポートへ転送し続けることがあります。この場合、クライアント自体が接続できず、ブラウザーも同時にオフラインのような状態になります。まずクライアント内の「システムプロキシを無効化」または「ネットワークを復元」機能を使います。クライアントを開けない場合は、システムのネットワーク設定で手動プロキシが無効なローカルアドレスを指していないか確認します。企業ネットワーク、仮想マシン、業務ソフトへの影響が分からない状態で、ネットワークインターフェースをすべて削除しないでください。

古いコピーを何度も読み込まず、サブスクリプションを再取得する

経路一覧が空、経路名が不自然、選択するとすぐ設定エラーになる場合は、ユーザーパネルからサブスクリプションを再取得します。クライアントのダウンロードとサブスクリプションはパネルから提供され、静的な案内ページに実際のサブスクリプションURLは掲載されていません。コピー時はURL全体を保持し、チャットアプリを経由したり、パラメーターを手動で削除・変更したりしないでください。読み込み前に、明らかに重複または無効な古い設定をクライアントから削除しても構いませんが、ローカルルールのバックアップは残します。完全な読み込み手順はクイックスタートガイドでプラットフォーム別に確認できます。

VPNXA は 110+ か国 / 210+ 経路をカバーしています。1つの経路で接続を確立できなくても、サブスクリプション全体が無効とは限りません。同じ地域の予備経路を選ぶか、近隣地域へ切り替えて確認してください。経路の分類は経路一覧で確認できます。テスト時はクライアントの標準プロトコルと標準の通信ルールを使い、カスタム設定を基本接続の確認に持ち込まないでください。標準設定で接続できたら、個人ルールを少しずつ戻します。

症状	優先して確認する項目	推奨アクション
クリック直後に失敗	サブスクリプション、権限、設定形式	サブスクリプションを再取得し、標準設定に戻す
接続を続けた後にタイムアウト	現在のネットワークと選択中の経路	ネットワークを変えて比較し、予備経路へ切り替える
画面上は接続済みだがシステムに経路がない	ネットワーク拡張と仮想インターフェース	再認証し、クライアントを完全に再起動する
すべてのアプリが同時にオフラインになる	システムプロキシの残留	手動プロキシを無効にし、ネットワークを復元する

上記を実行しても接続できない場合は、接続リクエストを何度も繰り返さないでください。失敗した経路名、エラー表示、比較結果を残し、問い合わせの章で必要な情報を準備します。サポートが最も必要とするのは、「どの環境で、どの手順を行い、どのエラーが安定して再現するか」という情報であり、「すべての経路が使えない」という説明だけではありません。再現可能な内容によって、サブスクリプション、経路、ローカルシステムのどこから調べるべきかが決まります。

CONNECTED, NO WEB

接続済みなのにWebサイトを開けない

クライアントに接続済みと表示されても、接続処理がある段階まで完了したことを示すだけで、ブラウザーのリクエストが正しく経路を通った証拠にはなりません。Webサイトを開けない場合は、「ドメインを解決できない」「ブラウザーがプロキシを使っていない」「経路には入ったが対象サイトに拒否される」「ページは開くが一部リソースを読み込めない」を区別します。画面上はどれも空白ページやタイムアウトに見えることがありますが、対処方法はそれぞれ異なります。

ブラウザー、システムアプリ、直接リクエストを比較する

通常のブラウザーウィンドウで安定したWebサイトを開き、別のブラウザーやシステム標準のネットワークアプリでも比較します。1つのブラウザーだけが失敗する場合は、プロキシ拡張機能、安全なDNS、キャッシュ、独自のネットワーク設定を確認します。すべてのアプリで失敗する場合は、システムプロキシ、DNS、経路を重点的に調べます。ブラウザーのプライベートウィンドウはキャッシュや拡張機能の影響を減らせますが、一部の拡張機能はプライベートウィンドウでも動作を許可されるため、拡張機能の管理画面で明示的に無効化してください。

ブラウザーに「プロキシサーバーが接続を拒否しました」と表示される場合、監視していないローカルポートへ送られている可能性があります。クライアントがシステムプロキシを有効にしているか、ブラウザー拡張機能に設定されたポートがクライアントの現在のポートと一致しているかを確認します。他のガイドからローカルポートをそのまま写さないでください。クライアント、モード、設定によって入口が異なる場合があります。最も確実なのは、クライアントの現在の画面または生成されたシステムプロキシ設定を確認することです。

DNS名前解決の問題を特定する

ドメインが見つからない、名前を解決できない、DNSに失敗したという表示がある場合は、まず一般的なドメインを1つ検索します。結果が返らない場合は、システムのDNSキャッシュを消去してブラウザーを再起動します。それでも失敗する場合は、クライアントの標準DNS設定に戻してください。システム、ブラウザー、ルーター、クライアントで別々のDNSを同時に指定しないでください。リクエスト経路が分かりにくくなります。ブラウザーの安全なDNSがシステム設定を迂回することもあるため、確認中は一時的に無効にし、接続復旧後に再度有効にするか判断します。

ドメインを解決できるのにWeb接続がタイムアウトする場合、DNSは現在の最優先事項ではありません。予備経路に切り替え、通信ルールが対象ドメインを誤って直接接続にしていないか確認します。Webサイトは通常、1つのドメインだけで構成されていません。本文、画像、スクリプト、動画が異なるドメインから配信されることがあります。本文は開くのに画像やログイン部品だけ失敗する場合、関連リソースのドメインが同じ出口を通っていない可能性があります。まずグローバルモードで比較します。グローバルモードで正常、ルールモードで異常なら、DNSを変え続けるのではなくルールを修正します。

キャッシュ、プロトコル、アカウント地域の違いを確認する

Webサイトによっては、過去のアクセス履歴、アカウント地域、ブラウザーの保存データ、出口の場所に応じて異なる内容を返します。経路を切り替えてもページが古い状態のままなら、そのサイトのキャッシュとサイトデータを消去するか、新しいプライベートウィンドウで開き直します。対象サイトだけを消去すればよく、ブラウザーのデータ全体を削除する必要はありません。ログイン後だけ異常で、ログアウトすると正常な場合は、アカウント地域と選択した経路の地域が合っているか確認します。経路を変えてもアカウント自体の地域属性は自動的に変わりません。

ページの読み込みが途中で止まる場合は、すべてのリソースが失敗しているのか、特定の種類だけが失敗しているのかを確認します。開発者ツールのネットワークパネルでリクエストの状態を確認できますが、スクリーンショットを送る際は、アカウント認証情報や認証ヘッダーを含む詳細を開かないでください。大きな画像、動画、ファイルだけが失敗する場合は、経路品質、分割接続、対象サービスの方針が関係している可能性があります。テキストページも完全に失敗する場合は、プロキシやDNSの可能性が高くなります。同じ地域の別経路に切り替えると単一経路の問題か判断でき、別地域へ切り替えると対象サービスの地域方針との関係を確認できます。

システムプロキシが実際に適用されているか確認する

デスクトップシステムでは、クライアントのスイッチ操作に応じてプロキシが変化するか、システムのネットワーク設定で確認します。接続時にプロキシ入口が現れ、切断時に削除されるのが正常な動作です。接続後も設定が変わらない場合は、クライアントがローカルポートのみのモードになっていないか確認します。このモードではブラウザーやアプリを個別に設定する必要があります。切断後もプロキシが残る場合は、クライアントのネットワーク復元機能を実行します。モバイルシステムでは、ステータスバーのネットワーク接続表示を確認し、同種の別設定が同時に有効になっていないか確認します。

企業管理端末では、一部のプロキシやネットワーク設定が管理ポリシーで固定されている場合があります。この場合、クライアントはシステムポリシーを上書きできず、画面上は接続済みでもアプリの通信を引き受けられないことがあります。個人の管理範囲にない設定を削除しようとせず、端末管理者に許可されたネットワーク方式を確認してください。個人端末でインストールとアンインストールを何度も行った場合は、無効な古いネットワーク設定を削除して現在のクライアントを再認証できますが、作業前に他の業務用ネットワークサービスへ影響しないことを確認します。

すべてのブラウザーとアプリにアクセスできず、DNS検索は正常で、システムプロキシも正しい場合は、問題を経路またはクライアントの通信経路に絞ります。経路とネットワーク環境を変えても改善しない場合は、クライアントログを保存して問い合わせを送信してください。ログはリクエストが経路に入ったかをスクリーンショットより詳しく示しますが、完全なサブスクリプションURLやその他の機密項目が含まれていないか、必ず確認してください。

PERFORMANCE

速度低下と混雑時間帯の遅延

速度の問題は、1回のダウンロード結果だけで判断できません。国際経路は、ローカル接続、無線信号、通信事業者の経路、距離、対象サービスの容量、時間帯の変化に左右されます。案内ページに掲載された1回の数値は、自分の環境でのテストの代わりにはなりません。端末、ネットワーク、テスト対象、方法を固定し、経路または時間帯だけを変えて、結果が安定して再現するか観察してください。詳しい方法はVPNの速度測定方法を参照してください。

接続前のローカル基準値を確認する

高速化接続を切り、同じ端末でローカルネットワークに大きな変動がないことを確認します。無線信号が弱い、ルーターが混雑している、バックグラウンドでファイルを同期している場合は、どの経路でも遅く感じられます。確認中はクラウド同期、システム更新、ライブ配信、大容量ファイルのダウンロードを停止し、できるだけ無線アクセスポイントに近づいてください。デスクトップ端末では有線ネットワークと比較できます。有線が安定し無線だけが変動する場合は、遠隔経路の問題とせず、まず無線環境を改善します。

続いて地理的に近い経路へ接続し、同じアクセス操作を繰り返します。距離が近いほど往復時間の低減には有利ですが、常に最速とは限りません。近い経路の結果がよくない場合は、経路一覧で経路種別を確認し、近隣地域の別の入口を選びます。Webサイトの表示、動画の再生開始、継続的な転送など実際の利用場面をテストし、クライアント画面の状態だけで判断しないでください。

遅延、ジッター、継続帯域を区別する

Webページのクリック後に長く待つものの、ダウンロード開始後の速度が正常なら、遅延またはDNSの問題に近い傾向があります。動画がすぐ再生されても、視聴中に画質低下やバッファリングを繰り返すなら、継続帯域の不足、経路の変動、対象サービスの速度制限が考えられます。通話やスポーツ配信はジッターの影響を受けやすく、平均帯域が十分でも短時間の変動で音声が途切れたり映像が追いつこうとしたりします。リアルタイム用途とオンデマンドの違いはスポーツライブ配信の経路選びガイドを参照してください。

すべての状況を「速い」「遅い」だけでまとめないでください。Webページの初回表示に遅延があるか、動画が必要な画質を安定して維持できるか、長時間接続が中断するか、経路変更後にどの項目が改善したかを記録します。これにより、接続確立が遅いのか、継続転送が不足しているのか、短時間の変動なのかを判断できます。Web応答は速いが大容量ファイルが不安定な経路は操作向けに残し、継続転送が安定する経路は動画やダウンロードに使う方法もあります。

混雑時間帯は同じ時間帯で比較する

ネットワークが空いている時間に1回測定するだけでは、混雑時間帯の体感は分かりません。問題が実際に起きる時間帯に、同じ端末、同じ対象、同じ経路で再測定し、その後に予備経路へ切り替えます。すべての経路が同時に低下し、接続を切ったローカルネットワークも低下する場合、ボトルネックはローカル接続または通信事業者の経路にある可能性が高くなります。特定の経路だけが低下し、近隣地域の経路が正常なら、いったんその経路を避けて症状を記録します。対象Webサイト自体が混雑時間帯に遅くなる場合は、別の安定した対象で比較してください。

混雑時間帯に経路を変えるとき、すべての地域を無秩序に試す必要はありません。まず同じ地域で異なる経路種別を選び、次に近隣地域、最後に遠い出口を試します。切り替えるたびに古い接続を完全に終了し、クライアントが新しい接続を完了してからテストページを開き直してください。ブラウザーが確立済みの接続を再利用して古い経路を使い続けることがあります。必要に応じて関連タブを閉じるか、対象アプリを再起動し、リクエストが新しい経路を使うようにします。

利用時の症状	考えられる原因	確認方法
Webページの初回表示は遅いが、継続ダウンロードは正常	遅延、DNS、ブラウザーによる接続の再利用	近い経路に切り替え、対象サイトのキャッシュを消去する
動画の再生開始は速いが、その後何度もバッファリングする	継続転送の変動または対象サービスの速度制限	同じ地域で経路を変え、連続再生を確認する
通話音声が途切れる	ジッター、ローカル無線の干渉	有線または別のネットワーク環境で比較する
混雑時間帯だけ速度が低下する	ローカル接続または時間帯による経路混雑	同じ時間帯に直接接続の基準値と予備経路を比較する

クライアントのモードとシステムリソースを確認する

グローバルモードでは、より多くの通信が経路に入るため、バックグラウンド更新、同期、他のアプリがネットワークを共有します。ルールモードを適切に設定すれば、必要な通信だけを処理できます。速度を確認するときは、まずシステムのタスクマネージャーやアクティビティモニターで、他のプロセスが継続的に通信していないか確認します。省電力状態、端末の高温、システムリソース不足では、クライアントの暗号化処理にも影響が出る場合があります。不要なプログラムを閉じ、安定した電源に接続してから再測定してください。

ブラウザーだけが遅く、他のアプリが正常なら、ブラウザー拡張機能、安全なDNS、ハードウェアアクセラレーション、キャッシュを確認します。特定のアプリだけが遅い場合は、アプリごとの経路設定の章を確認してください。すべてのアプリがすべての経路で遅く、接続を切ったローカル基準値が正常なら、同じ時間帯の経路名、対象サービス、再現手順を残して問い合わせを送信します。速度測定のスクリーンショット1枚だけでは、環境、経路、再現性が分かりません。

STABILITY

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

頻繁な切断では、通信経路が自動的に再接続しているのか、端末がネットワークを切り替えたのか、システムがバックグラウンドプロセスを終了したのか、クライアント自体が終了したのかを区別します。デスクトップではスリープからの復帰、無線ネットワークの切り替え、他のネットワークツールとの競合がよくあります。モバイルでは省電力設定、バックグラウンド動作の権限、ネットワーク切り替えの影響を受けやすくなります。ステータスバーのアイコンが一瞬消えただけでは経路障害とは判断できないため、発生タイミングとクライアントログを組み合わせて確認します。

切断の発生条件を確認する

切断がロック画面表示後、無線ネットワークからモバイルネットワークへ切り替えた後、端末の復帰後、大型アプリの起動後など、いつも同じ条件で起きるか記録します。ネットワークの切り替えと同時に切断する場合、古い接続が無効になった後、再構築に失敗している可能性があります。まず1つのネットワーク環境に固定して安定性を確認します。切り替えない状態で正常なら、クライアントの自動再接続またはオンデマンド接続を有効にし、ネットワーク切り替え後に復旧するか観察します。

ネットワークを切り替えなくても切断する場合は、同じ地域の予備経路と比較します。特定の経路だけが切断するなら、経路名を残して一時的に別の経路を使います。すべての経路が切断する場合は、ローカル無線信号、ルーターのリース変更、システムのスリープ、クライアントのバックグラウンド権限を確認します。接続を切った後もローカルネットワーク自体が一時的に切れるなら、まずローカル接続を直してください。ローカルネットワークが不安定なまま、経路の連続切り替えで問題を隠さないでください。

モバイル端末のバックグラウンド設定

モバイルシステムは電力を節約するため、長時間前面にないアプリを制限します。システム設定でクライアントのバックグラウンド動作を許可し、バッテリー設定を現在のクライアントに対して制限なしにします。端末メーカーによってメニュー名は異なりますが、通常はアプリ情報、バッテリー、バックグラウンド管理の項目にあります。VPNXA クライアントに関する項目だけを変更し、システム全体の省電力機能を無効にすることは推奨しません。システムに「常時接続」またはオンデマンド接続の設定がある場合は、クライアントが安定してから有効にできます。

端末によっては、ロック画面になると無線ネットワークを一時停止し、復帰時に別のネットワークへ切り替えます。この場合、古い通信経路は再度ハンドシェイクが必要になり、短時間の中断はネットワーク切り替えの過程で起こります。クライアントが自動復旧しない場合は、アプリを開いて再認証の表示がないか確認します。システム更新、設定の復元、再インストール後には、以前のネットワーク設定が無効になることがあります。古い設定を削除し、現在のクライアントを再認証してください。名前が似た古いネットワーク設定を複数残すと、システムの制御権を奪い合う可能性があります。

デスクトップのスリープ、復帰、インターフェース変更

デスクトップ端末がスリープから復帰すると、ネットワークインターフェースのアドレスやデフォルトルートが変わる一方、クライアントはスリープ前の接続状態を保持することがあります。画面上は接続済みなのにWebサイトへアクセスできず、切断して再接続すると復旧するのが典型的な症状です。クライアントのネットワーク変更時の自動再接続を有効にしてください。その項目がない場合は、復帰後に手動で再接続します。頻繁に起きる場合は、仮想インターフェースを作成する他のソフトウェアがインストールされていないか、デフォルトルートを同時に変更していないか確認します。

有線から無線へ切り替えたり、無線アクセスポイントを変更したりすると、既存の接続も無効になります。確認中は1つの接続方式に固定してください。固定すると安定する場合、経路自体に問題はなく、インターフェース切り替え後の再接続が焦点になります。固定しても切断する場合は、システムイベントログとクライアントログで切断前後の表示を確認します。ログのタイムアウト、ネットワーク到達不能、インターフェース消失、プロセス終了はそれぞれ異なる原因を示すため、すべてを「経路が不安定」と一括りにしないでください。

アプリの切断と通信経路の切断を区別する

動画、通話、ゲームだけが再接続を求め、ブラウザーは正常にアクセスできる場合、通信経路全体ではなく対象アプリのセッションが中断している可能性があります。ネットワーク出口の変更、アカウント地域の変化、アプリのバックグラウンド終了によってセッションが無効になることがあります。この場合は対象アプリを再起動してセッションを再確立し、すぐにクライアントを再インストールする必要はありません。ブラウザー、システムアプリ、対象アプリが同時にネットワークを失った場合に、通信経路全体の切断として扱います。

継続的に観察するときは、安定したWebページを1つ基準として残します。対象アプリがエラーを表示したら、すぐに基準ページを更新します。ページが正常なら通信経路は維持されています。ページも失敗する場合は、クライアントの状態を確認します。この簡単な比較は、一部のシステムではアイコンの更新が遅れるため、状態アイコンだけを見るより確実です。クライアントプロセスがシステムに終了させられた場合はバックグラウンド権限を確認し、プロセスが存在するのに接続を繰り返し再構築する場合は、経路とネットワーク環境を比較します。

この種の問題を問い合わせる際は、端末が前面で使用中、ロック中、スリープ中、ネットワーク切り替え後のどの状態で切断したかを説明し、切断前後のログを添付します。「よく切れる」とだけ書くと発生条件が分からず、サポート側で再現できません。特定アプリのバックグラウンド状態だけで起きる場合は、前面での使用が正常かも記載し、システムによる終了と経路の問題を区別できるようにします。

SUBSCRIPTION

サブスクリプション更新失敗と端末状態の異常

サブスクリプション更新の失敗は、経路接続そのものではなく「サブスクリプション内容の取得」時に起きることが多い問題です。更新時のネットワークエラー、経路一覧が変わらない、読み込み後に空になる、古い経路が残る、クライアントが設定の解析失敗を表示するなどの症状があります。端末状態の異常では、新しい端末で設定を取得できない、古いセッションが残り続ける、複数のクライアントが設定を上書きし合うことがあります。VPNXA のプランには端末台数の制限がないため、「端末数の上限」といった表示が出ても、プランの台数制限とは考えず、クライアント側の制限、ログインセッション、古い設定、第三者ソフトのルールを確認します。

ユーザーパネルから有効なサブスクリプションを再取得する

まずユーザーパネルにログインし、プランと通信量の状態が正常であることを確認してから、ダウンロードまたはサブスクリプションの欄で現在のURLをコピーし直します。VPNXA はメールアドレス不要で、ユーザー名とパスワードだけで登録できます。ユーザー名を忘れた、ログインできない場合は、パネルの問い合わせ手続きを利用し、似たアカウントを何度も作成しないでください。サブスクリプションをコピーするときは、パネルからクライアントへ直接渡し、プレビューを生成したり、パラメーターを切り詰めたり、文字を自動変換したりする中間アプリを避けます。

クライアントの更新に失敗した場合は、まずブラウザーでパネルにログインし、ページ自体へアクセスできるか確認します。パネルは開けるのにクライアントの更新だけが失敗する場合、クライアントがサブスクリプションのリクエストを、まだ利用できないプロキシへ誤って送っていないか確認します。一部のクライアントには「プロキシ経由で更新」と「直接接続で更新」の選択肢があります。まず標準方式を使い、現在のプロキシが無効なら接続を切ってから更新します。実際のサブスクリプションURLを公開検査サイトへ貼り付けたり、完全なURLをスクリーンショットや公開ログに載せたりしないでください。

古いキャッシュと重複設定を整理する

経路一覧が変わらない場合、クライアントがキャッシュを使い続けている可能性があります。まずサブスクリプションを手動更新し、クライアントを完全に終了して再起動します。同じ名前の設定が複数ある場合は、更新直後の設定が有効になっているか確認します。古い設定をローカルにバックアップしてから重複項目を削除し、起動時に古い設定へ自動的に戻らないようにします。クライアントに更新時刻の表示があれば、更新が完了したか判断する材料になりますが、ボタンの「成功」表示だけでなく、経路一覧がパネルの最新内容と一致しているかも確認してください。

設定の解析に失敗した場合、サブスクリプションの内容を手動で編集しないでください。手動改行、パラメーターの削除、Webページの返却内容を設定として読み込む操作は、形式エラーの原因になります。コピーし直しても失敗する場合は、対応している別のクライアントで比較します。別のクライアントで読み込めるなら、元のクライアントの形式互換性またはキャッシュを確認します。すべてのクライアントで読み込めない場合は、エラー全文を残して問い合わせを送信します。クライアントのダウンロードは必ずユーザーパネルから行い、出所不明のインストールパッケージを使わないでください。

端末の状態とログインセッションを確認する

新しい端末だけログインできず、既存の端末が正常な場合は、同じユーザー名を入力しているか確認し、パスワードマネージャーが古いアカウントを自動入力していないか確認します。いったんログアウトして手入力し、ブラウザーに保存された誤った認証情報に頼らないでください。すべての端末で同時にログインできない場合は、アカウント状態またはパスワードの問題である可能性が高くなります。支払いとプラン情報は料金ページで確認できますが、実際のアカウント状態はユーザーパネルを基準にしてください。

第三者クライアントに端末制限の表示が出た場合は、表示元がクライアント自体、OSのネットワーク設定、サービス側の応答のどれかを確認します。VPNXA の事実上のルールは端末台数無制限です。クライアント自体が保存できる設定数を制限している場合や、OSが古いネットワーク設定を保持している場合があります。無効な設定を削除し、古いセッションを終了して再読み込みする方が、アカウントを繰り返し作成するより適切です。サービス側から明確な異常応答が返る場合は、ユーザー名とサブスクリプショントークンを隠したうえで、応答箇所全体のスクリーンショットを添えて問い合わせます。

症状	確認のポイント	対処方法
更新成功と表示されるが経路が変わらない	キャッシュまたは古い設定が有効	更新後に再起動し、現在の設定を確認する
設定の解析に失敗	コピーが不完全またはクライアントの互換性	パネルからコピーし直し、別クライアントで比較する
新しい端末でログインできない	アカウント、自動入力、古いセッション	同じアカウントを手入力し、古いセッションを終了する
端末制限の表示が出る	表示元と古いネットワーク設定	無効な設定を整理し、エラー全文を残す

通信量のリセットと通信量パックの違い

月額サブスクリプションには ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれ、通信量は開通日を基準に毎月リセットされます。途中でアップグレードした場合は、差額を残り日数に応じて換算します。通信量パックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、無期限です。クライアントがサブスクリプションを更新できるのに接続できない場合は、パネルで現在のプランと通信量の状態を確認し、通信量を使い切ったことを設定障害と誤認しないでください。ページとローカルクライアントの表示が一致しない場合は、まずパネルを更新してからサブスクリプションを再更新します。

リセット日や残り通信量を自分で換算しないでください。月額サブスクリプションは開通日を基準とし、具体的なアカウント状態はパネルの表示に従います。途中でアップグレードした場合、残り日数は差額に応じて換算されるため、クライアントに残った古い有効期限が一時的に正確でないことがあります。サブスクリプションを再取得してクライアントを再起動してから判断します。パネルの情報自体に異常がある場合は、注文状態ページのスクリーンショットを添えて問い合わせますが、支払い情報や個人の機密情報は隠してください。

支払い後に開通しない、プラン状態が一致しない、通信量がルールどおり表示されないといった場合、支払いを繰り返して解決しようとしないでください。VPNXA は Alipay、WeChat、USDT に対応し、30日間の無条件返金を提供しています。注文とアカウントの問題はサポートがバックエンドの状態を確認します。利用者は注文識別子、支払い方法、問題が表示されたページだけを提示し、支払いパスワード、完全な取引情報、アカウントへアクセスできる秘密情報は送らないでください。

ROUTING & DNS

特定アプリがプロキシを使わない場合とDNS異常

ブラウザーは正常なのに特定のアプリだけアクセスできない場合、アプリごとの経路設定に関する典型的な症状です。アプリがシステムプロキシを読み込まない、直接ネットワーク接続を確立する、Webページとは異なるドメインや通信方式を使うことがあります。DNS異常では、ドメインを解決できない、解決結果がキャッシュされている、ブラウザーとクライアントが異なる名前解決経路を使うなどの原因で、ルールの判定材料が失われます。その結果、「同じWebサイトが直接接続されたり、プロキシ経由になったりする」不一致が起きます。

まずアプリがシステムプロキシに従うか確認する

接続後にブラウザーで通信経路が正常であることを確認し、その後で対象アプリを起動します。ブラウザーは使えるのにアプリが使えない場合は、クライアントに仮想ネットワークインターフェースや拡張モードがあるか確認します。システムプロキシだけを設定した場合、システムプロキシに従うアプリは動作しますが、直接接続するアプリは迂回する可能性があります。仮想インターフェースを有効にする前に、同種の他のネットワークツールを終了し、クライアントの案内に従ってシステム権限を許可します。有効化後に対象アプリを再テストし、変化の原因を確認できるよう、ルールとDNSを同時に変更しないでください。

アプリによっては起動時にネットワーク状態を読み込み、実行中のプロキシ切り替えがすぐには反映されません。デスクトップに戻るだけでなく、アプリを完全に終了して開き直してください。デスクトップでは、アプリがトレイやメニューバーに常駐していないかも確認します。再起動で復旧するなら、ネットワーク切り替え後に古いセッションが更新されていなかった可能性があります。それでも失敗する場合は、ルールが適用されているか確認します。アカウント地域、アプリストアの地域、アプリ自身のキャッシュもコンテンツに影響しますが、これらはプロキシ制御の問題とは別です。

グローバルモードでルールの漏れを確認する

ローカルネットワークと経路が正常だと確認できたら、一時的にグローバルモードへ切り替えてテストします。対象アプリがグローバルモードでは使えてルールモードでは使えない場合、必要なドメインまたはアドレスがルールに含まれていません。クライアントの接続ログで対象アプリの起動時にアクセスする関連ドメインを確認し、適切なルールへ追加します。1つのアプリのために無関係な通信までプロキシに送らないよう、ルールは明確なドメインを対象にしてください。完了後はルールモードに戻して再確認します。

1つのアプリは、ログイン、API、画像、更新、メディアなど異なるドメインに依存することがあります。メインサイトのドメインだけを追加すると、トップページは表示されてもログインやコンテンツ読み込みに失敗する場合があります。失敗した手順からリクエストを確認します。起動時に失敗するなら認証と設定のドメイン、ログイン後にページが空白ならAPIと静的リソース、再生に失敗するならメディア配信のドメインを重点的に確認します。見知らぬルールセットを丸ごとコピーしないでください。広すぎるルールは不要な通信を増やし、ローカルサービスを誤って経路へ送る可能性もあります。

DNS経路の不一致に対処する

クライアント、システム、ブラウザー、ルーターのすべてがDNSに関わる可能性があります。確認時は階層を減らし、まずクライアントの標準DNSに戻し、ブラウザー独自の安全なDNSを一時的に無効にします。システムのキャッシュを消去した後、対象アプリを再起動します。これで復旧した場合は、元の設定を1つずつ有効にして、競合の原因を特定します。DNSで名前を解決できても、その結果が現在の出口に適しているとは限りません。ルールモードでは、関連ドメインの名前解決とプロキシ方針を一致させる必要があります。

システムの検索ツールで結果を比較できますが、特定のアドレスを求める必要はありません。検索結果が返るのにブラウザーが名前エラーを表示する場合、ブラウザー独自のキャッシュや名前解決を使っている可能性があります。すべてのブラウザープロセスを終了して開き直すか、対象サイトのデータだけを消去します。システム検索も失敗する場合は、ローカルネットワークが独自DNSを遮断していないか確認し、自動取得に戻してみます。公開ガイドのアドレスをすべての端末へそのまま設定しないでください。ネットワーク環境が異なるため、コピーするだけで問題が複雑になることがあります。

nslookup example.com

ipconfig /flushdns

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

resolvectl flush-caches
getent hosts example.com

hosts、フィルタールール、セキュリティソフトを確認する

システムのhostsファイル、コンテンツフィルター、ファイアウォール、セキュリティソフトは、プロキシより前の段階でドメインをブロックすることがあります。特定のドメインだけが失敗する場合は、hostsに該当する項目がないか確認します。変更前にファイルをバックアップし、明らかに自分で追加した無効な項目だけを削除してください。システムファイルを一括で上書きしないでください。セキュリティソフトにWebフィルタリングや暗号化接続の検査機能がある場合は、比較のため関連モジュールを一時停止できます。競合が確認できたら、保護機能を常時無効にするのではなく、設定でクライアントを適切に許可します。

ブラウザー拡張機能がDNSやリクエスト経路を変更することもあります。広告ブロック、プライバシー保護、プロキシ拡張機能の古いルールが、ログイン部品やスクリプトリソースを遮断する場合があります。拡張機能なしのブラウザー環境で比較すると、1つずつ推測するより早く切り分けられます。拡張機能なしで正常なら、拡張機能を1つずつ戻します。目的は具体的な競合を特定することであり、すべてのセキュリティ設定を永久に無効にすることではありません。

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

DNSの問題を経路の問題と誤認しないために

経路を切り替えて一時的に復旧しても、元の経路が故障しているとは限りません。経路の切り替えには接続の再構築やキャッシュの更新が伴うため、実際に有効だったのはDNSの状態変化という可能性があります。これを確認するには、元の経路でキャッシュを消去してアプリを再起動します。同じように復旧するなら、DNS設定を優先して整理します。逆に、DNS設定が同じなのに特定の経路だけアクセスできない場合は、出口経路または対象サービスの方針が関係している可能性が高くなります。

特定のWebサイトやアプリだけが対象の場合は、ブラウザーが正常か、グローバルモードが正常か、ルールモードで失敗するか、システム検索で名前解決できるか、対象アプリを完全に再起動したかを問い合わせに記載します。これらの情報があれば、サポートは経路、ルール、DNSのどこから確認すべきか判断でき、すでに完了した基本手順を繰り返し求めずに済みます。

ESCALATION

サポートへ連絡するタイミングと問い合わせ情報

自己確認の目的は、利用者にすべての技術作業を負わせることではなく、サポートが素早く再現できる範囲まで問題を絞ることです。アカウント状態の異常、支払い後にプランが開通しない、パネル情報と注文内容が一致しない、複数のネットワーク環境ですべての経路が継続的に失敗する、クライアントが明確なサービス側エラーを返す場合は、問い合わせを送信してください。1つの経路で一時的に不安定なだけなら、まず予備経路へ切り替えます。問題が安定して再現し、複数の経路に影響する、またはアカウントデータに関係する場合は、ローカル設定を何度も変更し続けないでください。

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

パネルに完了済みの注文が表示されない、プラン状態に異常がある、通信量データが明らかに更新されない、サブスクリプションを再取得しても対応クライアントすべてで解析できない場合は、サポートにアカウントとサブスクリプションを確認してもらいます。複数の端末、複数のネットワーク環境、異なる経路で同じエラーが出る場合も、単一端末の設定を超えた問題です。この場合、再インストールを続けると価値のあるログが消えるため、まず証拠を保存します。

セキュリティ関連の異常も速やかに報告してください。操作していないのにサブスクリプション内容が変わった、見覚えのないログイン状態がある、パスワードを正常に更新できない場合などです。問い合わせ前にアカウントのパスワードを変更し、古いセッションを終了します。問い合わせ本文に現在のパスワード、完全なサブスクリプションURL、支払いパスワード、アカウントへ直接アクセスできるトークンを送らないでください。サポートがこれらの秘密情報を必要とすることはありません。

問い合わせ本文に含める情報

まず、「Windowsで接続後、すべてのWebサイトで名前解決できない」や「iOSでロック後に接続が自動復旧しない」のように、明確なタイトルを書きます。本文には、プラットフォーム、使用したクライアントの入手元、現在のネットワーク環境、選択した経路、問題が初めて起きたおおよその時刻、安定して再現するかを記載します。続いて、クライアントを開く、どの経路を選ぶ、何をクリックする、どの表示が出るかを操作順に説明します。最後に、ネットワーク変更、経路変更、サブスクリプション再更新、DNSキャッシュ消去など、実施済みの確認と各操作後の結果を列挙します。

エラー表示は一文だけ抜き出さず、全文をそのままコピーしてください。スクリーンショットには、表示がクライアント、システム、対象アプリのどこから出たか分かる前後の文脈を含めます。ログは問題発生前後の関連部分だけを残し、サブスクリプションURL、ユーザー名、ローカルのディレクトリ名、その他の機密情報が含まれていないか検索します。サブスクリプションURLのトークンは完全に隠してください。ログが長い場合は、問題が起きたおおよその時刻を記載すると、サポートが確認しやすくなります。

送信前チェックリスト

プラットフォームとクライアントの入手元を記載した
現在のネットワーク環境と経路名を記載した
接続を切った後のローカルネットワークが正常か説明した
すべてのWebサイトに影響するか、特定アプリだけかを説明した
経路変更、ネットワーク変更、サブスクリプション再更新の結果を記載した
エラー全文と再現手順を添付した
スクリーンショットとログのサブスクリプショントークン、パスワード、支払い情報を隠した

問題別に必要な追加資料

接続失敗にはクライアントのエラー全文、経路名、ネットワーク比較の結果が必要です。Webサイトを開けない場合は、DNS検索結果、システムプロキシの状態、他のブラウザーが正常かを提示します。速度問題には、同じ時間帯の直接接続の基準値、選択した経路、実際の利用場面、予備経路の結果が必要です。頻繁な切断では、ロック、スリープ、ネットワーク切り替えの後に起きたかを説明します。サブスクリプション更新失敗では、パネルにアクセスできるか、クライアントのエラー、別クライアントでの比較結果を提示します。

特定のアプリがプロキシを使わない場合は、ブラウザーが正常か、グローバルモードとルールモードにどのような違いがあるか、対象アプリを完全に再起動したか、ログに関連接続があるかを説明します。DNS異常には検索コマンドと結果を添付しますが、システムのネットワーク設定ファイル全体は添付しないでください。端末状態の表示については、どの画面に表示されたかを説明し、同じアカウントを使っていることを確認します。これにより、サポートがクライアントのローカル表示をプラン制限と誤認するのを防げます。

対応を待つ間も利用可能な状態を保つ方法

特定の経路だけが異常なら、経路一覧から予備地域を一時的に使えます。速度問題では近隣地域を選び、安定した経路を残して、頻繁な自動選択は避けます。ルールの問題では、動作確認済みのモードを一時的に使えますが、変更内容を記録し、回答を受けたら元に戻して確認します。アカウントや注文状態に異常がある場合は、支払いを繰り返したり、状態を回避するために複数のアカウントを新規作成したりしないでください。確認作業が難しくなります。

クライアントログとスクリーンショットは問題解決まで保存します。サポートから新しいテスト手順を案内されたら、一度に1項目だけ実行し、実行前後の変化を返信します。問題が自然に復旧した場合も、復旧時刻、そのときの経路、設定変更の有無を追記してください。こうした偶発的な問題の情報は、経路切り替え、キャッシュ更新、ローカルネットワーク復旧のどれが原因か判断するのに役立ちます。

問題解決後の振り返り

復旧後は、確認中だけ必要だった一時設定を元に戻します。比較のために有効にしたグローバルモードを無効にし、重複したサブスクリプションを整理し、適切なバックグラウンド設定に戻し、競合しないと確認できたセキュリティツールを再度有効にします。出所不明のDNS、プロキシ拡張機能、古いネットワーク設定を複数残さないでください。設定が少なく役割が明確であるほど、次回の問題も特定しやすくなります。

最終的に有効だった操作を、「ネットワーク拡張を再認証したら復旧」「古いシステムプロキシを整理したら復旧」「リソースドメインをルールに追加したら復旧」のようにローカルへ記録できます。実際のサブスクリプションURLや認証情報は記録しないでください。次回同じ症状が起きたら、発生条件が一致するかを先に確認し、無条件にすべての手順を繰り返さず、該当する方法を再利用します。