VPNのトラブルシューティング
接続とアクセスの復旧

接続の問題

まったく接続できない：まず問題の発生箇所を確認

ローカルネットワークの状態を確認する

「接続できない」といっても、クライアントが起動しない、回線一覧が空、接続ボタンが反応しない、接続処理が待機中のまま進まないなど、さまざまな状態があります。まず、実際にどこで止まるのかを書き留め、別々の症状を一つの問題として扱わないようにしましょう。接続を切り、普段そのまま開けるWebサイトにアクセスして、端末のネットワークが正常か確認します。直接アクセスもできない場合は、ネットワークのログイン画面、Wi-Fiの接続状態、システムのネットワーク通知を先に確認してください。この段階で国際回線を何度も切り替えても、通常は解決につながりません。

ホテル、学校、公共のネットワークでは、Wi-Fiに接続済みと表示されても、ネットワーク認証が完了しているとは限りません。ブラウザーを開き、利用規約への同意やネットワークへのログインが必要か確認してください。認証を済ませてからクライアントを起動しましょう。ネットワークにプロキシ設定がある場合は、まず現在の設定値を記録し、利用環境に由来するものか確認します。組織が管理するネットワーク設定をむやみに削除したり、用途が分からないままシステムのセキュリティ機能を無効にしたりしないでください。

同じ端末を別の利用可能なネットワークにつなぐと、ローカル接続の問題かどうかを切り分けやすくなります。クライアント、サブスクリプション、選択中の回線は変えず、接続するネットワークだけを変更してください。それで接続が復旧する場合、元のネットワークのアクセス制限や通信条件が原因である可能性があります。元のネットワークで他の端末は接続できるのに、この端末だけ失敗する場合は、端末の権限、プロキシ設定の残存、セキュリティソフトの通知を優先して確認しましょう。

回線一覧、権限、接続ハンドシェイクを切り分ける

回線一覧が空の場合は、まずユーザーパネルでサブスクリプションの状態を確認し、クライアントで正しい設定が選択されているかを確認します。設定をインポート済みなのに一覧が表示されない場合と、回線は表示されるものの接続ハンドシェイクに失敗する場合では、確認手順が異なります。前者はサブスクリプションの更新へ進み、後者は回線、ネットワーク、ログを比較してください。クライアント画面にサービス名が表示されているだけで、設定が完全に読み込まれたと判断しないようにしましょう。

モバイル端末で初めて接続するときは、通常、システムからVPNの使用許可を求められます。許可画面をキャンセルすると、クライアントでは接続ボタンが押せる状態でも、システム上にトンネルが作成されていない場合があります。もう一度接続し、システムの通知を確認して許可してください。デスクトップでネットワークコンポーネントのインストールや権限の昇格が必要な場合は、パネルにあるクライアントの案内に従います。組織の端末でネットワーク設定を変更できない場合は、無理に変更せず、端末管理者に相談してください。

回線一覧と権限を確認しても接続できない場合は、ログに最初に現れるエラーを確認してください。接続タイムアウトは、待機時間内に応答がなかったことを示しますが、それだけで回線の故障とは断定できません。認証エラーならアカウント、サブスクリプション、設定に原因がある可能性が高く、ドメイン名の解決エラーならDNSを確認します。最後に表示された赤い通知だけでなく、エラー発生前後のログを短く切り出して保存すると、原因を判断しやすくなります。

システムの日付、時刻、タイムゾーンが正しいか確認してください。安全な接続では証明書の有効期間を検証するため、時刻が大きくずれていると証明書の検証に失敗することがあります。システムの通常の時刻同期機能を使って修正し、接続を一時的に通すために証明書検証を無効にしないでください。時刻が正しいのに証明書の警告が繰り返し表示される場合は、元のエラーを保存して問い合わせてください。設定の詳細が分からないままセキュリティ検証を弱めるのは避けましょう。

比較条件をそろえて回線をテストする

別の回線を選ぶときは、まず利用目的を変えずに、回線の種類や地域を比較します。サブスクリプションの更新、クライアントの再インストール、ルーティングモードの変更、ネットワークの切り替えを同時に行うと、復旧しても何が効いたのか分からなくなります。回線一覧と種類の説明は回線一覧で確認できます。現在のネットワークに適しているかどうかは、実際の接続結果で判断してください。地理的な距離だけでは判断できません。

特定の回線だけ接続できず、他の回線では同じ接続先にアクセスできる場合は、利用できる回線を使いながら、失敗した回線名、接続ネットワーク、エラーを記録してください。すべての回線で失敗する一方、直接アクセスは正常なら、システムのVPN機能やプロキシ機能を使う他のソフトを一時的に終了して再度テストします。終了する前に相手側の設定を保存し、確認が終わったら元の用途に合わせて復元してください。業務環境の設定を損なわないよう注意しましょう。

権限、サブスクリプションの有効性を確認し、接続ネットワークを変えても同じエラーが繰り返される場合は、むやみに再インストールを続けないでください。再現条件をまとめて問い合わせましょう。必要な情報は、プラットフォーム、クライアントに表示されるエラー、選択した回線、直接アクセスの可否、ネットワーク変更後の結果です。サブスクリプションURL全体、アカウントのパスワード、未加工の設定ファイルは送らないでください。通常、サポートに必要なのは発生条件とログの一部であり、アカウントの認証情報ではありません。

確認の順番：直接アクセスは正常か → 設定に回線が表示されているか → システムが接続を許可しているか → ログはどの段階で止まるか → ネットワークや回線を変えると結果が変わるか。

接続後の問題

接続できるのにWebサイトが開かない：アクセスとDNSを分けて確認

接続済みでもWebサイトにアクセスできるとは限らない

クライアントに「接続済み」と表示されても、通常はトンネルやプロキシの入口が確立したことを示すだけです。接続先の名前解決、ルーティング、アプリからのリクエストがすべて成功したとは限りません。まず、すべてのWebサイトが開かないのか、特定のサイトだけなのかを確認し、ブラウザーと他のアプリでも比較します。1つのサイトだけ失敗する場合は、ドメイン名とエラーの種類を記録し、サブスクリプション全体に問題があるとすぐに判断しないでください。接続先サイトのメンテナンス、地域要件、アカウントの状態がアクセスに影響することもあります。

ブラウザーの「サーバーが見つかりません」と「接続がリセットされました」では、確認すべき点が異なります。前者はまずドメイン名の解決を確認し、後者はリクエストが接続先に届いているか、ローカルソフトが処理していないか、途中で接続が切れていないかを調べます。アクセス制限、地域に関する案内、アカウント認証が明示されているなら、接続先サービスから応答が届いています。表示された案内を確認し、アカウント権限の問題をDNSキャッシュの削除で解決しようとしないでください。

ブラウザーのプライベートウィンドウで同じページを開くと、古いキャッシュ、拡張機能、既存のログイン状態の影響を減らせます。ただし、プライベートウィンドウは独立したネットワーク環境ではありません。プライベートウィンドウで正常に開く場合は、拡張機能、サイトのキャッシュ、ブラウザーのプロキシ関連設定を確認してください。通常ウィンドウとプライベートウィンドウの両方で失敗する場合は、ネットワークの確認に進みます。業務用サイトの閲覧データをすべて消去せず、まず該当サイトだけを対象にしてください。必要なログイン状態を失わずに済みます。

ドメイン名の解決に問題がないか確認する

DNSはドメイン名を接続先のアドレスに変換します。設定には、システムのリゾルバー、クライアント内蔵の名前解決、ブラウザーの暗号化DNS、プロキシ側の名前解決が関わることがあります。これらが互いに上書きし合うと、想定外の経路にリクエストが送られる場合があります。確認するときは、まずクライアントのログを読み、ドメイン名が解決されているか、どの層が結果を返しているかを調べます。名前解決のオプションを一度にすべて有効にしないでください。機能を重ねても、安定するとは限りません。

デスクトップでは、システムのコマンドを使って名前解決の結果を確認できます。以下のコマンドでは例示用のドメインを使っており、サブスクリプションやアカウント情報は含まれていません。システム層でアドレスを取得できるかを確認するためのものであり、接続先サービスが利用可能であることを証明するものではありません。クライアントによってはプロキシ内で名前解決するため、システムコマンドの結果がブラウザーの実際のリクエストと異なることがあります。コマンドの出力だけで判断せず、クライアントのログも確認してください。

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

Windowsのコマンド環境で、curlが別のコマンドとして解釈される場合は、curl.exe -I https://example.comと入力して、該当するプログラムを明示的に実行できます。macOSとLinuxでは、まずツールが利用可能かを確認してからテストしてください。「見つかりません」というエラーはツールが使えないことを示し、回線の問題ではありません。この確認のために不明なサイトからスクリプトをダウンロードしたり、用途が分からないコマンド一式をターミナルに貼り付けたりしないでください。

名前解決に失敗する場合は、まずクライアントの説明にあるデフォルトのDNS設定に戻し、ブラウザーだけ別の名前解決経路を使っていないか確認します。端末のhostsファイルを編集したことがある場合は、接続先のドメインに関連する古い項目がないか確認してください。変更前にバックアップを取り、削除する場合は問題があると確認できた項目だけにします。企業が管理するhostsファイルや名前解決のポリシーは管理者に確認し、ファイル全体を上書きしないでください。

キャッシュ、残存プロキシ設定、接続先からの応答

DNS設定を修正しても、ブラウザーやシステムに古い名前解決のキャッシュが残っている場合があります。まず該当ページを閉じてブラウザーを再起動し、システムの手順に沿ってキャッシュを更新してください。Windowsでは、以下のコマンドでローカルのDNSキャッシュを消去できます。サブスクリプションの更新や、利用できなくなった回線の修復はできません。実行後は同じドメインを再テストし、「名前解決できない」から別のエラーに変わったか記録しましょう。ページが一時的に再読み込みできただけで、修復済みと判断しないでください。

ipconfig /flushdns

クライアント接続中はアクセスできるのに、終了後にすべてのWebサイトが開かなくなる場合は、システムプロキシが停止済みのローカルプロキシを参照したままになっていないか確認します。まずクライアントを通常の方法で終了するか、プロキシ設定を復元してください。組織のネットワークで使うプロキシ値は保持しましょう。システムのネットワーク設定をすべて削除しないでください。アプリによっては起動時にプロキシ設定を読み込むため、設定変更後にアプリを完全に終了して再起動する必要があります。Webページを再読み込みするだけでは、設定は読み直されません。

DNSに問題がなく、他のサイトも開けるのに、接続先で地域制限や再生制限が表示される場合は、接続先サービスの利用条件や関連するガイドを確認してください。動画視聴の利用案内も参考になりますが、回線の地域名だけで接続先サービスがその出口を受け入れるとは限りません。問い合わせる際は、ドメイン名、ブラウザーの表示、すべてのサイトで起きるか、名前解決の確認結果、回線変更後の差を記載してください。個人情報を含むページの場合は必要なパスだけを伝え、ログイン状態を含むリクエスト全体はアップロードしないでください。

Webサイトのエラーページが表示されたことも判断材料になります。アカウント、地域、サイトのメンテナンスに関する明確な案内と、サーバーから応答がない状態には、同じ修復方法を使わないでください。

速度と利用目的

速度が遅い、夜間に重い：アクセス全体を比較する

まず遅くなる箇所を切り分ける

「速度が遅い」といっても、ページの表示に時間がかかる、動画が何度もバッファリングする、ダウンロードが途中で止まる、AIの応答がなかなか始まらないなど、状況はさまざまです。原因が同じとは限りません。ページの初回表示には名前解決、接続の確立、接続先からの応答が関わります。連続再生では通信の安定性が重要です。AIのストリーミング出力には、接続先サービスの混雑やアカウントの利用枠も影響します。確認を始める前に、どの操作のどの段階で遅くなるかを説明できるようにしましょう。「重い」とだけ記録しても、原因の切り分けには不十分です。

同じ接続先、同じ端末、近い操作条件で、直接アクセスできるサイトと国際回線が必要な接続先を比較します。直接アクセスできるサイトも明らかに遅い場合は、まずWi-Fiの電波状態、ネットワークの混雑、端末のバックグラウンド処理を確認してください。システム更新、クラウドストレージの同期、他の端末でのダウンロードが、接続ネットワークの帯域を使っていることがあります。確認できるバックグラウンド通信を一時停止して同じ操作を繰り返すと、結果を比較しやすくなります。

クライアントの回線一覧で、遅延の小さい順に並べた結果をダウンロード速度の順位と同一視しないでください。遅延は特定の経路での応答を示しますが、連続したデータ転送は回線の混雑、接続先サーバー、接続数、ローカルネットワークの影響を受けます。動画が途切れず再生できるか、ファイルを安定してダウンロードできるか、ツールが出力を完了できるかのほうが、実際の用途に即した判断材料です。これらの判断に代わる固定の速度保証は提供していません。

夜間の混雑と回線タイプを比較する

夜間に通信が重くなる場合は、同じ回線を時間帯を変えて比較し、そのときの接続ネットワークも記録します。接続先、端末、ネットワークが同じで、混雑する時間帯だけ大きく遅くなるなら、共有回線の負荷が関係している可能性があります。一日を通して不安定な場合は、ローカル環境、ルーティング、接続先サービスを引き続き確認してください。一度アクセスに失敗しただけでは、継続的な混雑とは断定できません。同じ条件で再現するかを確認することが大切です。

回線を選ぶ際は、IEPL専線、中継、直結を用途に応じて比較できます。ただし、回線タイプの名称を無条件の速度ランキングとして捉えないでください。中継は一部の接続ネットワークで経路を改善することがあります。直結は現地から出口までのネットワーク条件に左右され、専線でもローカルネットワークや接続先サービスを経由します。選択できる回線はパネルの一覧で確認してください。詳しくは回線一覧をご覧ください。

動画をテストするときは、同じコンテンツと同じ再生設定を使ってください。自動画質調整が有効だと、回線変更後に画質が下がり、再生が復旧したように見えることがあります。それだけで通信状態が完全に改善したとはいえません。プレーヤーで選択されている画質を確認し、バッファリングが繰り返されるか観察してください。同じ端末で大容量ファイルのダウンロードと動画テストを同時に行うのも避けましょう。互いにリソースを使い、正確に比較できなくなります。

AIツールへのアクセスが遅い場合は、接続を待っているのか、生成を待っているのかを切り分けます。ページが読み込まれ、アカウントにもログインできているのに、送信後しばらく出力が始まらない場合は、接続先サービス側の処理が原因かもしれません。ツールが何度も再接続したり、ストリーミングの回答が途中で途切れたりする場合は、回線とクライアントのログを確認してください。用途別の情報はAI高速化ガイド、プログラミングツールについてはAIプログラミング向け回線の選び方もご覧ください。

設定変更を速度改善の近道にしない

ネット上の投稿を参考に、通信パラメーター、キャッシュサイズ、システムのネットワークスタック設定をむやみに変更しないでください。設定が合わないと、一部のサイトは開けても別のリクエストが停止し、かえって復旧が難しくなることがあります。まずクライアントの説明にあるデフォルト設定を使用し、その状態で問題が再現するか確認してください。ログやサポートの判断で特定のパラメーターが原因と分かった場合に限り、元に戻せるよう記録を残して変更しましょう。

回線を切り替えて明らかに改善した場合は、まず動作する設定を維持し、普段の用途で問題がないか確認します。回線一覧の測定値の最小値を追い続ける必要はありません。速度の問題を問い合わせる際は、ページ、動画再生、ダウンロード、ストリーミング出力のうち何が遅いのかを説明し、おおよその発生時間帯、接続先、接続方法、回線の比較結果を添えてください。他サービスの速度測定のスクリーンショットを、そのままVPNNQの性能の証拠にしないでください。測定対象や経路が異なる場合があります。

比較するときに変更する条件は一つだけにします。回線、ネットワーク、接続先を同時に変えると、速度が戻ってもボトルネックを特定できません。

接続の安定性

頻繁に切断される・モバイル端末でバックグラウンド接続が切れる

トンネルの切断か、アプリの中断かを確認する

アプリに接続が中断されたと表示されても、システムのVPN接続まで切れたとは限りません。まずクライアントの接続状態を確認し、次にシステムにVPNの表示が残っているか、他のアプリから引き続きアクセスできるかを確認します。動画アプリやチャットツールだけが中断し、他のアクセスは正常なら、接続先アプリのセッションや特定のリクエストに問題がある可能性があります。クライアントも切断状態になっている場合は、接続ネットワーク、バックグラウンド制限、接続ログを確認してください。

切断前に端末で何をしていたか記録しましょう。画面ロック、Wi-Fiの切り替え、省電力モードへの移行、スリープからの復帰、別のネットワークツールの起動など、こうした動作は「ときどき切れる」という情報より原因を特定しやすくなります。選択した回線は変えず、同じ動作を再現してみてください。ネットワークを切り替えるたびに接続が切れるなら、静止状態で回線を変えるだけでなく、クライアントの再接続動作を確認する必要があります。

ネットワークを切り替えるとローカルアドレスや通信経路が変わり、既存の接続を継続できないことがあります。Webページの再読み込み後は復旧するのに、ストリーミング処理が失敗するのは、後者が確立済みのセッションに依存するためです。生成中のコンテンツやアップロード中のファイルは、まず進捗を保存してから再接続し、処理をやり直してください。すべての失敗リクエストを自動で再送しないようにしましょう。接続先では処理が完了していて、確認応答だけが届かなかった可能性もあります。

AndroidとiOSのバックグラウンド動作

Androidでは、システムのバッテリー最適化やメーカー独自のバックグラウンド管理によって、画面ロック後のクライアント動作が制限されることがあります。システムのアプリ設定を開き、VPNNQクライアントの電池使用量、バックグラウンド動作、ネットワーク権限を確認し、クライアントの案内に沿って必要な動作を許可してください。端末によってメニュー名は異なるため、他社製端末のスクリーンショットをそのまま参考にせず、機能の内容をもとに探しましょう。設定後に画面をロックし、元の利用状況でテストしてください。

システムにバックグラウンドアプリの終了、自動起動、アプリのロックなどの設定がある場合は、現在のクライアントプロセスを終了させないか確認してください。使用中のクライアントに必要な権限だけを調整し、他のアプリの権限まで広げる必要はありません。システム更新後に設定が変わることがあり、以前正常だったからといって現在も必要な権限が有効とは限りません。インストールと権限の設定を確認するには、Androidのインストールから接続確認までのガイドも参考にしてください。

iOSでは、システムのVPN設定が現在のクライアントに対応しているか、別のアプリが接続を管理していないかを優先して確認します。Androidのようなバックグラウンド許可リストが見当たらないからといって、設定を何度も削除しないでください。ネットワークを切り替えた後に復旧しない場合は、クライアントから通常の手順で切断して再接続し、システムの通知を確認します。端末が組織の管理下にある場合は、許可されている接続方法を管理者に確認してください。

デスクトップのスリープ、競合、復旧確認

Windows、macOS、Linuxでは、スリープから復帰した後、ネットワークインターフェースが新しいアドレスを取得する一方、クライアントが古い接続状態を保持することがあります。ローカルネットワークが復旧してから、クライアントで切断と再接続を試してください。それで復旧する場合は、スリープからの復帰が引き金になっていることを記録します。スタートアップ時にクライアントを起動する設定だけでは、ネットワークの準備完了と同時にトンネルが確立するとは限りません。

システムプロキシ、仮想ネットワークインターフェース、VPN設定を複数のツールが同時に変更すると、設定が互いに上書きされることがあります。確認中は接続を担当するクライアントを一つに絞り、他のツールはウィンドウを閉じるだけでなく完全に終了しているか確認します。組織のリモートアクセスツール、セキュリティソフト、本サービスの互換性は、それぞれのポリシーを踏まえて判断してください。接続のためにすべての保護機能を無効にしたり、用途の分からないネットワークインターフェースを削除したりしないでください。

切断ログを確認するときは、切断時刻がシステムのスリープ、Wi-Fiの再接続、クライアントプロセスの終了と一致するかを見ます。画面ロック中にログの記録が突然止まる場合は、バックグラウンドプロセスがシステムによって終了された可能性があります。接続の再試行がログに続いている場合は、ネットワークや回線の問題が考えられます。「再接続に成功しました」という最後の記録だけでなく、切断前後の状況を含むログを保存してください。

バックグラウンド設定を変更したら、クライアントを前面に表示したまま試すのではなく、元の切断動作を再現して確認します。画面ロック後のアクセス、ネットワーク切り替え後の復旧、長時間の処理が完了するかをそれぞれ確認してください。異なる回線や接続ネットワークでも同じ動作で切断される場合や、クライアントが終了する場合は、プラットフォームとシステムの通知を添えて問い合わせましょう。特定の回線だけで起きる場合は、回線名と比較結果も添えると、環境と回線を切り分けやすくなります。

バックグラウンド切断の修復確認では、「バックグラウンドに戻っても使える」ことが重要です。「クライアントを開き直すと再接続できる」だけでは不十分です。画面ロックやネットワーク切り替えなど、元の動作を再現してテストしてください。

設定の受け渡し

サブスクリプションを更新できない：使える設定を残して確認

アカウントの状態と取得エラーを切り分ける

サブスクリプションの更新には、パネルのアカウント、サブスクリプションURL、ネットワークアクセス、クライアントでの解析が関係します。どこか一つに問題があっても「更新に失敗しました」と表示されることがあります。まずアカウント概要にログインし、サブスクリプションの状態、利用可能なデータ量、プランの有効性を確認してください。パネル側の状態に問題がある場合は、アカウントや注文を先に確認し、クライアントで同じURLを何度も削除して再登録しないでください。

現在の設定で接続できるなら、更新に失敗してもその設定は残してください。再試行のために回線一覧を消去しないようにしましょう。既存の設定を残しておくと、新しい設定の取得部分だけに問題があるかを判断できます。削除して現在使える回線まで失うと、更新と接続の両方を調べることになります。変更前に設定名、選択中の回線、ルーティングモードを記録してください。認証情報を含む設定画面を公開しないようにしましょう。

パネルが提供するサブスクリプションURLをコピーしてください。パネルのWebページ、ログイン画面、ブラウザーのアドレス欄にある一時的なリダイレクトURLではありません。コピーした文字列に空白、改行、他の文字が混ざると、クライアントで認識できない場合があります。まずパネルのコピー機能やインポート方法を使い、失敗した場合は説明に沿って手動でインポートしてください。クライアントのダウンロードとサブスクリプションの取得はユーザーパネルから行ってください。

エラーの種類に応じて対処する

更新がタイムアウトする場合、クライアントが取得処理を正常に完了できていません。現在のネットワークや更新リクエストのプロキシ経路が原因の可能性があります。URLは変更せず、接続を有効にした場合と無効にした場合で更新できるか比較してください。クライアントに更新時のプロキシ利用設定がある場合は、説明を読んで元の設定値を記録します。環境によって直接取得が必要な場合も、既存の接続を利用する必要がある場合もあります。一つの方法がすべてのネットワークに当てはまるわけではありません。

認証エラーやアクセス拒否が表示された場合は、パネルに戻ってサブスクリプションURLを取得し直し、リセット操作を行ったことがないか確認してください。サブスクリプションURLは機密情報です。漏えいした場合は、パネルの方法でリセットし、各端末に保存した設定も更新してください。チャット履歴などで共有された古いURLを使い続けたり、形式確認のために見知らぬオンライン変換サイトへ渡したりしないでください。変換処理で認証情報が漏れるおそれがあります。

取得には成功したのに設定の解析で失敗する場合は、クライアントとインポート形式が合っているかを優先して確認します。サブスクリプションの応答には回線、ルール、クライアントのパラメーターが含まれることがあり、インポート方法はすべてのクライアントで共通とは限りません。パネルから該当するプラットフォームとクライアント用の入口を選び、用途の分からない項目をファイル内で直接変更しないでください。他サービスのテンプレートで本サービスの設定を上書きするのも避けましょう。利用できないプロキシグループやルール参照が残る場合があります。

解析エラーに見えても、実際には設定ではなくWebページの案内が取得されていることがあります。ネットワークの認証ページ、接続先からの案内、リダイレクトなどが原因になる場合があります。クライアントのログでコンテンツタイプや形式の無効に関する記述を確認すれば十分です。取得した内容をすべて公開しないでください。アカウント情報が含まれている場合は、問い合わせ前にエラーの説明と必要な構造情報だけを残し、機密部分を隠してください。

更新後の動作を最後まで確認する

クライアントに更新成功と表示されたら、現在使っている設定が更新したものかを確認してください。同じ名前の設定が複数あると、更新したのに変化がないように見えることがあります。設定を見分けやすい名前に変更し、現在のプロキシグループが利用できる回線を参照しているか確認しましょう。回線一覧の更新後、以前の選択肢が変わることがあります。成功表示だけでなく、回線を選び直してアクセスを確認するほうが確実です。

サブスクリプションの更新でルールが変更されることがあるため、接続ボタンだけを確認して終わりにしないでください。よく使うWebサイト、AIツール、動画視聴などを試し、想定どおりアクセスできるかを確認します。特定のアプリだけ変化した場合はアプリとルーティングへ進んでください。以前の動作に戻すためにすべてのルールをすぐ無効にせず、更新前後のモードとマッチング記録を比較し、どの層で差が生じたかを確認しましょう。

同じアカウントを複数の端末で使っていても、各端末に保存されている設定は、別の端末で更新しただけでは自動で同じになりません。サブスクリプションURLをリセットした場合は、引き続き使う端末ごとに更新し、不要になった古いコピーは自分で確認してから削除してください。本サービスは同時接続台数無制限ですが、各端末がクライアント設定を個別に管理します。「同じアカウント」でも、システム権限、設定形式、プロキシモードまで同じとは限りません。

更新の問題を問い合わせる際は、パネルにログインできるか、現在の回線で接続できるか、接続を有効にした場合と無効にした場合のどちらで更新に失敗したか、クライアントに表示されたエラーの種類を説明してください。個人情報を除いたログを添付し、実際のサブスクリプションURLは送らないでください。URLの形式を説明する必要がある場合は、https://example.com/sub?token=YOUR_TOKENのような例示用の値を使い、これは見本であり実際の設定としてインポートできないことを明記してください。

サブスクリプションのインポート、回線への接続、普段使うアプリへのアクセスは、それぞれ別の確認項目です。更新後は現在の設定とプロキシグループも確認してください。

アプリの接続経路

特定のアプリだけプロキシを使えない：モードとルールを確認

ブラウザーは正常なのにアプリが失敗する理由

ブラウザーではアクセスできるのに、デスクトップアプリやコマンドラインツールではできない場合、プログラムごとに異なるネットワーク経路を使っている可能性があります。システムプロキシは、対応するプログラムが参照する設定であり、すべての通信リクエストが自動的に利用するわけではありません。独自のプロキシ設定があるアプリもあれば、システムVPNやクライアントの仮想ネットワークモードに依存するものもあります。まずアプリがどの経路を使うのかを確認し、クライアントのモードを変更する必要があるか判断してください。

一つのアプリを動かすために、すべての通信を長期間同じ経路に切り替えないでください。グローバルモードは、ルールのマッチングが原因かを判断するための一時的な比較には使えますが、本来は直接アクセスすべき業務通信まで変えることがあります。テスト前に現在のモードを記録し、対象アプリと回線は変えずにモードだけ切り替えます。その後、アプリを完全に終了してから起動してください。改善した場合はルールモードに戻り、該当ルールを確認します。比較用の設定をそのまま最終設定にしないでください。

アプリによっては起動時にプロキシ環境を読み込み、その後システム設定が変わってもすぐに反映されません。ウィンドウを閉じるだけでは終了しない場合があるため、アプリの終了操作を行ってから再起動してください。コマンドラインツールは、ターミナルの環境変数やツール独自の設定からプロキシを読み取ることもあります。新しいターミナルと以前のターミナルで動作が異なる場合は、重要な手がかりです。ブラウザーで成功した画面だけでは、他のアプリもプロキシを使っている証拠にはなりません。

ルールのマッチングとアプリ固有の要件

クライアントの接続ログを開き、アプリのリクエストに含まれるドメイン名と適用されたルールを探します。直結かプロキシグループのどちらに割り当てられているか確認してください。アプリ画面に表示されるサービスのドメイン名だけで、すべてのリクエストを把握できるとは限りません。ログイン、リソースのダウンロード、API、コンテンツの配信で異なるドメインを使うことがあります。メインのドメインだけを修正して実際に失敗しているAPIのドメインを見落とすと、ホーム画面は開くのにログインや生成が失敗することがあります。

ルールを変更する場合は、現在のクライアントが対応する形式とルールの順序に従ってください。一般に、より具体的なルールは、それを上書きする範囲の広いルールより前に置く必要がありますが、実際のマッチング方法はクライアントの説明を確認してください。ネット上にある大量の設定を既存のサブスクリプションに直接コピーしないでください。特に、プロキシグループ名や参照を上書きしないようにしましょう。変更前に元に戻せるコピーを保存し、ログで確認できた接続先だけを調整してください。他の用途まで使えなくしないよう注意しましょう。

AIアプリが開くのに使えない場合は、接続先アカウントの利用資格、地域に関する案内、利用枠、サービスの稼働状況も確認します。ネットワーク接続だけでは、接続先サービスの利用条件を満たせません。Cursor、Copilot、コマンドラインツールでは長時間接続や異なるリクエスト経路が使われるため、状況の把握にはAIプログラミング向けVPNの選び方も参考になります。個別の問題は、アプリに表示された元のエラーとクライアントの記録をもとに判断してください。

プラットフォームごとの違いと権限

Androidクライアントにアプリごとの包含・除外機能がある場合は、対象アプリが除外されていないか確認してください。アプリレベルの選択でリクエストがトンネルに入るか先に決まることがあるため、ドメインルールだけを確認しても不十分です。アプリの選択を変更したら、クライアントの案内に従って接続し直してから、対象アプリを起動します。仕事用プロファイルと個人用プロファイルのアプリは、管理範囲が異なる場合があります。端末の管理ポリシーに従ってください。

デスクトップの仮想ネットワークモードでは、追加の権限やネットワークコンポーネントが必要な場合があります。あらゆるアプリの問題を解決する万能な方法ではありません。まずクライアントがそのモードに対応しているか確認し、パネルの案内に沿って許可を設定してください。有効にした後でローカル業務に問題が出た場合は、速やかに元に戻してからルーティングや除外ルールを確認します。組織内ネットワーク、リモートデスクトップ、ローカル端末へのアクセスにはそれぞれ要件があります。一つの国際アプリのために、すべてのローカル通信経路を強制的に変更しないでください。

Linuxでは、デスクトップ環境やコマンドラインツールによって、プロキシ設定の読み取り方が異なる場合があります。まずツール独自のプロキシ設定を確認し、次に現在のターミナル環境に古いプロキシ変数が残っていないか調べます。削除や変更の前に、元の値を記録してください。古い項目を整理せず、シェルの起動ファイルに設定を繰り返し追加しないでください。新しいターミナルにも競合する設定が引き継がれることがあります。クライアントの実際の接続先を確認する前に、ローカルプロキシのアドレスをむやみに入力しないでください。

ルールモードでは失敗し、比較用モードでは成功する場合は、問い合わせに対象アプリ、失敗した操作、適用されたルール、実際のプロキシグループを記載してください。すべてのモードで失敗する場合は、アプリに表示された元の案内とブラウザーでの比較結果も添えます。ログに個人のファイル名、業務プロジェクト、リクエストパラメーターが含まれることがあるため、隠してから送信してください。ログインが必要な接続先でも、サポートに接続先アカウントのパスワードを知らせる必要はありません。再現手順と個人情報を除いたエラーで通常は十分です。

アカウントと料金

端末数の警告、通信量、サブスクリプションの状態に関する問題

「端末数の上限」表示は、まず表示元を確認

VPNNQは同時接続台数無制限です。「端末数の上限」や同様の表示が出た場合は、VPNNQのパネル、クライアント、アクセス先のプラットフォームのどこに表示されているかを確認してください。動画、コラボレーションツールなどの接続先サービスには、独自の端末数やセッションのポリシーがある場合があります。本サービスの端末に関する条件は、接続先のルールとは別です。表示された画面と文言を保存し、接続先の制限を本サービスのプラン制限と取り違えないようにしましょう。

クライアントに表示される場合は、選択中の設定が現在のVPNNQアカウントのものか確認してください。同じクライアントに複数サービスの設定があると、古いサブスクリプションや別の設定を使っていることがあります。パネルで現在のサブスクリプションを確認し、クライアントの設定名、回線一覧、プロキシグループを確認してください。確認できていない表示を解決しようとして重複して支払ったり、他サービスの端末ルールから本サービスの制限を推測したりしないでください。

パネルとクライアントの両方で本サービスの設定だと確認できているのに、「台数無制限」と異なる端末数の警告が出る場合は、個人情報を隠したスクリーンショットを添えて問い合わせてください。確認すべきなのは表示元、アカウントの状態、設定の対応関係です。端末を一台ずつ削除して解決するか試す必要はありません。複数の端末では、それぞれ権限、ネットワーク、バックグラウンドの条件が異なります。一台で起きた問題だけで、アカウントに端末数制限があるとは限りません。

通信量のルールと状態の同期

月額プランの通信量は、利用開始日を基準に毎月リセットされます。暦月の初日にリセットされるわけではありません。月額プランは、¥9.9/月（60GB）、¥18/月（250GB）、¥28/月（500GB）のみです。途中でアップグレードした場合、差額は残り日数に応じて計算されます。プランを比較する場合はプラン一覧を確認してください。クライアントに保存されたプラン名や古いスクリーンショットだけで、現在の料金状態を判断しないでください。

データパックは使い切るまで有効で、有効期限はありません。プランは¥158/300GB、¥358/1000GB、¥658/3000GBです。有効期限がないのはデータパックのルールであり、通信量が消費されないことや、月額プランの通信量がリセットされないことを意味しません。利用可能な状態はパネルで確認してください。クライアントで接続できず、パネルに通信量不足と表示される場合は、回線やDNSを調べる前にプランの種類と残量を確認しましょう。

クライアントに表示される利用履歴と、パネルの精算状況では、集計方法や更新時刻が異なる場合があります。単純に差し引いて通信量の異常と判断しないでください。システムのバックグラウンド通信、他の接続中の端末、すでに送信されたリクエストも利用状況に影響します。疑問がある場合は、パネルの表示、発生した時間帯、そのとき接続中だった端末の用途を記録してサポートに確認してください。独自の換算方法を作ったり、固定の消費率を推測したりしないでください。

支払い後に状態が想定どおり変わらない場合は、まずパネルの注文詳細と決済画面の最終結果を確認し、同じアカウントに戻っているかを確認してください。利用できる支払い方法は支付宝 / 微信 / USDTです。決済画面を閉じただけで完了したと判断したり、状態を確認する前に同じ注文を続けて作成したりしないでください。注文を特定するために必要な情報を保存し、パネルの問い合わせ窓口から相談してください。

ログイン情報と設定の保護

本サービスはメールアドレス不要で、ユーザー名とパスワードで利用を開始できます。ログイン情報は安全に保管してください。パスワードを忘れた場合は、パネルで提供されている方法に従って復旧します。アカウントを確認すると称する見知らぬ相手に、パスワードを送らないでください。ブラウザーに複数のアカウントを保存している場合は、購入やサブスクリプション取得に使ったアカウントでログインしているか確認しましょう。アカウントを取り違えると、プランが表示されない、サブスクリプションが一致しないなどの問題に見えることがあります。

別の端末からアカウントを確認すると、ブラウザーのキャッシュと実際の状態を切り分けやすくなります。信頼できる自分の端末を使ってください。ログイン後にアカウント概要を確認し、元の端末に戻ってページを更新するか、再ログインします。端末によって表示が異なる場合は、差異を記録し、アカウント名が一致しているか確認してください。同期を強制するために閲覧データをすべて削除すると、必要なログイン状態やトラブルシューティングの記録まで失うことがあります。

サブスクリプションURLとログインパスワードは用途が異なりますが、どちらも公開してはいけません。自分の端末に設定をインポートするときは、パネルから通常の方法で取得してください。使わなくなった端末からは保存済みの設定を削除します。サブスクリプションURLが漏れた疑いがある場合は、パネルの機能でリセットして自分の端末の設定も更新してください。ローカルで設定名を変更しても認証情報は変わらず、漏えい後の継続利用を防ぐこともできません。

アカウント、注文、プランに関する問題はサポートに確認を依頼してください。端末のネットワーク設定を変更する必要はありません。問い合わせには、アカウントに表示されるプランの種類、注文状況、警告の表示元、すでに試したログイン確認などを記載できます。認証情報は必ず隠してください。本サービスは14日間の無条件返金に対応しています。申請条件は利用規約をご確認ください。返金の相談と接続の問題は関連づけて説明できますが、原因を特定していない障害を料金に関する結論として扱わないでください。

同時接続台数に上限がないこと、月額プランの通信量が利用開始日にリセットされること、データパックに有効期限がないことは、それぞれ別のルールです。まず表示元とプランの種類を確認してから問題に対処してください。

問い合わせと確認

サポートに問い合わせるタイミングと修復の確認方法

むやみな設定変更を止める判断基準

ローカルネットワーク、サブスクリプションの状態、権限を確認しても問題が安定して再現する場合は、問い合わせを検討してください。特に、異なるネットワークでもすべての回線で同じ認証エラーが出る、設定の解析に繰り返し失敗する、パネルの状態と注文結果が一致しない場合は、再インストールを続けても有効な情報は増えません。サポートには明確な症状と発生条件が必要です。端末を元に戻せない状態にするまで変更する必要はありません。

証明書の異常、矛盾するアカウント通知、見覚えのない設定に遭遇した場合は、セキュリティ検証を弱める操作を中止してください。一時的に接続できても、異常を無視してよい理由にはなりません。端末が組織によって管理されている場合は、ネットワーク権限、社内ルート、セキュリティポリシーの範囲を管理者にも確認します。本サービスへの問い合わせでは回線やクライアントの問題を切り分けられますが、組織による端末の管理権限に代わるものではありません。

利用できる予備回線が見つかった場合は、失敗時の条件を記録しながらその回線を使い続けてもかまいません。業務中に設定全体を大きく変更するのは避けましょう。連続出力、アップロード、リモートセッションなどに使う場合は、復旧できるテスト用の作業を先に用意してから調整を試します。不安定な接続の確認に重要なファイルややり直せない操作を使わないでください。トラブルシューティングでは、データを失う新たなリスクを作らず、影響を抑えることが大切です。

問い合わせで状況を正確に伝える

ユーザーパネルの問い合わせフォームから問題を送信してください。冒頭で症状と影響範囲を説明します。たとえば「ブラウザーではアクセスできるが、コマンドラインツールは接続がタイムアウトする」「画面ロック後にクライアントのログ記録が停止する」のように書きます。続けてプラットフォーム、接続ネットワークの種類、選択中の回線、設定モード、失敗した操作を記載してください。「使えない」とだけ書いても、アカウントとネットワークのどちらから調べるべきか判断できません。

実施した比較は、操作名だけでなく結果を記載してください。「ネットワークを変えても失敗し、エラーは変わらなかった」は、「ネットワークを変えてみた」より役立ちます。「ルールモードでは失敗し、比較用モードではアクセスできた」は、「設定を変更した」より明確です。比較が有効だったかをサポートが判断できるよう、変えなかった条件も説明しましょう。操作後に設定を戻し忘れた場合は、現在の状態も問い合わせに記載してください。双方で異なる環境を前提に話す事態を防げます。

失敗の前後に当たるログを選び、時刻の順序と元のエラー文を残してください。スクリーンショットには通知が表示されたアプリを含めつつ、アカウントの認証情報、サブスクリプションURL、個人用パス、決済の機密情報、業務上の内容は隠します。ログにリクエストのパラメーターや認証情報が記録されることもあるため、送信前に必ず確認してください。設定ファイル全体を公開したり、パネルと無関係な見知らぬサイトにログ解析を依頼したりしないでください。

問い合わせの記載例：macOSでブラウザーは正常だが、対象のデスクトップアプリでログインがタイムアウトする。現在はルールモードを使用。アプリを完全に終了して再起動しても失敗し、別の回線でもエラーは変わらない。比較用モードに一時的に切り替えるとログインできた。現在は元のモードに戻してあり、失敗したリクエストのマッチング記録を個人情報を隠して添付。

障害の発生時刻は、実際に確認した時刻とタイムゾーンを記載してください。端末の時計が間違っている場合、その表示を正確な発生時刻として扱わないようにします。夜間だけ問題が起きる場合は、再現する時間帯と利用目的を説明します。バックグラウンドで切断される場合は、画面ロック、ネットワーク切り替え、スリープなどの動作を記載してください。測定していない遅延、帯域、稼働率の数字を加える必要はありません。推測で記載すると、確認済みの事実が分かりにくくなります。

修復後、普段の利用条件で確認する

設定変更の案内を受けたら、まず現在の設定を保存し、指示に沿って一つずつ変更します。変更するたびに元の失敗操作を繰り返し、症状に変化があるか確認してください。変化がなければ結果を記録し、不要な変更を元に戻します。サポートの案内とネット上の設定を同時に適用しないでください。次の確認でどの変更が効いたか分からなくなります。プラットフォームによってメニューが異なる場合は、該当するスイッチを推測せず、実際の画面を説明してください。

修復確認は「接続済み」と表示された段階で終わりではありません。対象のWebサイト、アプリへのログイン、長時間の接続を使う処理、バックグラウンドでの利用が復旧したか確認し、正常だったローカル業務に影響が出ていないことも確認しましょう。一時的にグローバルモードへ切り替えて原因を調べた場合は、最後に適切なルール設定へ戻します。プロキシ設定の残存を修正した場合は、クライアント終了後も直接アクセスが正常か確認してください。新たなネットワーク依存を残さないようにしましょう。

最終的に有効だった条件を短く記録します。使用した設定、維持が必要な権限、問題を引き起こした操作、元に戻せるデフォルト設定などです。次回、システム更新やネットワーク変更の後に同じ症状が起きても、違いをすぐ比較できます。サブスクリプションURLやパスワードをトラブルシューティングのメモに書かないでください。用途と設定名を記録すれば十分です。機密情報は引き続きパネルで管理してください。

初回インストールは使い方ガイド、よくある短い質問はヘルプセンター、回線の比較は回線一覧をご覧ください。問題が接続先サービスのアカウントやコンテンツの地域条件に由来する場合は、接続先の案内に従ってください。本サービスのサブスクリプションや回線に問題がある場合は、同じ問い合わせに調査結果を追加し、症状、比較、復旧までの記録をまとめましょう。毎回背景を説明し直す手間を減らせます。