VPN接続のトラブルシューティング

基本的な接続

まったく接続できない：まずネットワークを確認

最初に「クライアントを終了すると、普段アクセスできるサイトを開けるか」を確認します。基本のネットワーク接続に問題がある場合、回線を変更しても解決しないことがあります。クライアントの接続を一時停止し、端末がWi-Fiの電波を表示しているだけでなく、実際にネットワークへ接続されているか、システム設定で確認してください。公共Wi-Fiではブラウザーで利用開始の確認が必要な場合もあります。通常のサイトにアクセスできる状態に戻るまでは、クライアントを何度も再インストールしたり、サブスクリプション設定を変更したりしないでください。

アカウントの問題と接続の問題を切り分ける

ユーザーパネルにログインし、アカウントにアクセスできるか、プランが有効か、利用可能なデータ容量が残っているかを個別に確認します。パネルにログインできても、選択した回線の接続が確立しているとは限りません。一方、ブラウザーに保存されたログイン状態が期限切れでも、回線が使えなくなったとは限りません。ログインエラーならアカウント情報を、接続エラーならクライアントの表示を確認し、異なる原因を混同しないようにしましょう。

VPNAmpではメールアドレス不要で、ユーザー名とパスワードを使ってアカウントを作成できます。元のアカウントのユーザー名を入力しているか、入力方式や大文字・小文字、コピー時に空白が混ざっていないか確認してください。トラブル確認のために新しいアカウントを何度も作ると、プランのないアカウントを確認してしまうおそれがあります。アカウントを特定できない場合は、試行を繰り返さず、利用可能なアカウント窓口からサポートを受けてください。パスワードをスクリーンショットや公開の場に載せないでください。

クライアントの状態を順に確認する

クライアントに戻り、サブスクリプション設定がインポートされただけでなく、選択されていることを確認します。接続を開始したときの変化を見てください。クリックしても反応しないのか、権限の確認が表示されるのか、エラーが出て接続処理が止まるのかを確認します。システムの許可が必要な場合は、システム標準の確認画面で操作してください。設定の解析エラーが表示されたらサブスクリプションの項目へ、ネットワークに到達できないと表示されたら、異なるネットワークでの動作を比較しましょう。

ネットワークを制御しているほかのプロキシツールを終了してから、再接続します。複数のツールが同時にシステムプロキシを変更したり、仮想ネットワークインターフェースを作成したりすると、通信が意図しない経路へ送られることがあります。ほかのツールは通常の方法で終了してください。システムサービス、ドライバー、ネットワークインターフェースを直接削除しないでください。組織の管理下にある端末で権限を変更できない場合は、端末の管理者に相談しましょう。組織のセキュリティ設定を無効にしてテストするのは避けてください。

条件を一つずつ変えて切り分ける

端末と設定はそのままに、パネルで選べる別の回線に切り替えてみます。回線を変更すると接続できる場合は、元の回線名とエラーを記録しておきましょう。問題はその経路に限られる可能性があります。すべての回線で同じ症状が出る場合は、回線を固定したまま、信頼できる別のネットワークに切り替えて比較します。ネットワーク、回線、クライアントを同時に変更するより、一度に一つの条件だけを変えるほうが結果を判断しやすくなります。

対応端末がほかにもある場合は、同じアカウントで接続を試す方法もあります。同じネットワークで特定の端末だけ失敗するなら、その端末の権限、システム時刻、残っているプロキシ設定を確認しましょう。同じネットワークで複数の端末が失敗し、別のネットワークでは復旧する場合は、接続元のネットワークに注目します。システムの日付や時刻が大きくずれていると証明書の検証に失敗することがあります。自動時刻設定に戻し、証明書エラーを無視して接続しないでください。

アクセスと名前解決

接続済みなのにWebサイトが開かない：DNSと接続経路を確認

クライアントに「接続済み」と表示されても、接続処理がある段階まで進んだことを示すだけの場合があり、Webサイトへのアクセス確認の代わりにはなりません。まず種類の異なる複数のサイトを開き、「どのページも開かない」「特定のドメインだけ開かない」「ページは開くがログインできない」のどれに当たるか確認します。ブラウザーに表示されたエラーも記録してください。ドメインの名前解決に失敗する、接続がタイムアウトする、証明書に問題がある、接続先に拒否されるといった症状は、それぞれ確認すべき点が異なります。すべてを速度の問題として扱わないようにしましょう。

通信がクライアントに届いているか確認する

クライアントの接続画面やアクティビティ画面で、通信が表示されるか確認します。画面名は使用中のクライアントによって異なります。ブラウザーを更新しても該当する通信がまったく表示されない場合は、システムプロキシが有効か、現在の設定が適用されているか、ブラウザーに個別のプロキシ設定がないか確認します。通信が表示されても直結に振り分けられている場合はルールを確認し、選択中の回線を通っている場合は、名前解決と接続先へのアクセスを切り分けます。

次にIPアドレス確認ページで現在の接続元情報を確認します。結果が示すのは、その確認リクエストの接続元だけです。すべてのアプリが同じ経路を通ることを証明するものではありません。確認ページにアクセスできなくても、すぐに端末から情報が漏れている、または回線が使えないと判断しないでください。まず確認ページ自体にアクセスできるかを確かめます。同じブラウザーと同じ設定のまま、接続前後の結果とクライアントの通信記録を照らし合わせると、原因を絞り込みやすくなります。

DNSの確認で分かること

DNSはドメイン名を接続先のアドレスに変換します。システム、ブラウザーのセキュアDNS、クライアント内蔵の機能、アプリ独自の機能がそれぞれ名前解決を行う場合があります。そのため、システムのコマンドが成功しても、ブラウザーが正常に動くとは限りません。確認時は現在のDNS設定を残し、正常な応答、タイムアウト、ドメインが存在しないという応答のどれだったかを記録します。返されたアドレスを、インターネット上の固定の回答と機械的に比較しないでください。コンテンツ配信サービスでは、ネットワーク上の位置に応じて異なるアドレスが返されることがあります。

nslookup example.com

このコマンドは、システムの名前解決が応答するか確認するためのものです。ドメイン名は説明用の例にすぎません。実際の確認には問題が発生している公開ドメインを使い、個人用のサブスクリプションURLは入力しないでください。コマンドが成功してブラウザーで名前解決エラーが出る場合は、ブラウザー独自のDNS設定、拡張機能、キャッシュを確認します。コマンドとブラウザーの両方で失敗する場合は、クライアントの接続を切ったときの結果と比較し、現在の設定を有効にした場合だけ問題が起きるかを確認してください。

プラットフォームに応じてキャッシュや残存設定を確認する

結果を記録してからキャッシュを削除します。Windowsでは、システムで使用できるターミナルから次のコマンドを実行して、端末内のDNSキャッシュを消去できます。その後、ブラウザーを完全に終了してから開き直してください。この操作で誤った振り分けルールが直ったり、利用できないDNSサービスが復旧したりするわけではありません。macOSとLinuxでは名前解決の管理方法が異なるため、Windowsのコマンドをそのまま使わないでください。システムのネットワーク設定や、使用しているディストリビューションの手順を確認しましょう。

ipconfig /flushdns

「DNSを直す」ために証明書の検証を無効にしたり、出所の分からない証明書をインストールしたり、システムの名前解決設定を安易に変更したりしないでください。証明書の名前が一致しないと表示された場合は、ドメイン名、端末の時刻、公共Wi-Fiの接続確認が済んでいるかを確認します。特定のサイトだけに拒否される場合は、そのサイトのアカウント、地域、リスク判定のルールが関係している可能性があります。回線を変えて比較すると経路の違いは確認できますが、そのサイトが現在のアカウントで必ず利用できることを保証するものではありません。

速度の確認

速度が遅い：応答・ダウンロード・再生を分けて確認

まず「遅い」と感じる状況を具体的にしましょう。ページをクリックしてから反応するまで時間がかかる場合は、名前解決や接続確立が遅い可能性があります。ページは開くものの画像の表示が進まない場合は、データ転送が制限されている可能性があります。動画の再生はすぐ始まるのに何度も読み込みが止まる場合は、画質、コンテンツの配信元、回線の継続的な転送能力が関係することがあります。どの段階で待ち時間が発生するのか記録してから回線を変更し、すべての問題を単なる帯域不足と見なさないようにしましょう。

同じ条件で比較できるようにする

普段問題が発生する公開ページやコンテンツを選び、端末、接続ネットワーク、アプリ、対象コンテンツを固定して、回線だけを変更します。ブラウザーのキャッシュによって再アクセスが速く見えることがあるため、ページの表示速度だけで判断せず、アプリの動作も確認してください。テスト中はクラウドストレージの同期、システム更新、ほかの端末での大量通信を一時停止し、ネットワークが使われている影響を先に除外しましょう。

Wi-Fiの電波強度は、実際に利用できる通信速度と同じではありません。アクセスポイントから端末が離れている、周囲のWi-Fiが混雑している、中継機器の状態が不安定といった要因で、国際回線の利用状況が悪くなることがあります。可能であればアクセスポイントの近くで試すか、信頼できる別の接続方法と比較してください。クライアントを切断しても、普段開けるサイトの表示が明らかに遅い場合は、まず基本ネットワークを確認します。その状態で国際回線を何度も切り替えると、確認条件が増えるだけになることがあります。

回線までの距離と実際の通信経路は別に考える

まず地理的に近い選択可能な回線から試し、接続先サービスでの実際の結果を見て調整するとよいでしょう。ただし、距離が近いことは速度を保証しません。接続元の通信事業者、ルーティング、接続先サイトの配信拠点、アプリの仕様などによって結果は変わります。VPNAmpの提供範囲は100+か国 / 160+回線です。選択できる回線はパネルで確認してください。提供範囲の数から各回線の帯域やサービスへの対応状況を推測することはできません。

クライアントの接続テストは、応答しない候補を絞り込むためのもので、ファイルのダウンロードや動画再生の体感をそのまま示すわけではありません。テスト先の応答が速くても、対象アプリと同じ経路を使うとは限りません。回線情報ページを確認したら、実際の用途に戻って動作を確かめましょう。たとえば文書を開く、アプリからリクエストを送る、止まりやすいコンテンツを再生するといった方法があります。テスト一覧の順位だけで最終的な回線を決めないでください。

プランのデータ容量と速度を区別する

データ容量は利用可能な通信量を示すもので、瞬間的な通信速度を保証するものではありません。月額プランのデータ容量は利用開始日を基準に毎月リセットされます。暦月の初めに一律でリセットされるわけではないため、パネルで現在の使用量を確認してください。容量が足りない場合はプランページで確認できます。容量に問題がないのに速度が遅い場合は、プランを価格だけで変更するのではなく、通信経路の比較を続けてください。

動画配信の再生状況は、配信元、エンコード方式、配信プラットフォームのルールにも左右されます。画質の表示だけでは回線の測定結果になりません。回線を選ぶ際の考え方はNetflixの配信地域と帯域の確認方法も参考になりますが、実際にアクセスできるかを確認してください。同じ条件で回線ごとの差が繰り返し確認できる場合は、単に「速度が遅い」と書くより、アプリ名、問題が起きる段階、比較結果を添えると状況を伝えやすくなります。

時間帯と接続の安定性

夜間の混雑による遅延と頻繁な切断

夜間の遅延と頻繁な切断は分けて記録します。前者は接続が続いているものの、ページの応答や動画再生が遅くなる症状です。後者はクライアントが明確に再接続する、またはアプリの通信が中断される症状です。発生した現地時刻とタイムゾーン、継続時間、選択中の回線を記録し、「夜は使えない」とだけ書かないでください。時刻の情報は通信経路の状態を確認するためのもので、同じ時間帯に起きる問題がすべてサーバーの混雑によるとは限りません。

同じ条件で混雑時とそれ以外を比較する

端末、接続ネットワーク、対象アプリを固定し、日中に正常だったときの設定を残したまま、問題が起きる時間帯の状況を確認します。テスト中は更新のダウンロードやWi-Fiのアクセスポイント変更を避けてください。特定の回線だけが近い時間帯に遅くなり、ほかの回線は使える場合は、一時的に切り替えて元の経路と結果を記録します。通常のWebアクセスも同時に遅いなら、接続元ネットワークの混雑も確認対象です。

動画の連続再生、オンライン会議、リアルタイムの操作では、接続に求められる条件が異なります。動画プレーヤーはキャッシュによって短い通信の乱れを吸収できますが、会議やリモート接続では中断が表れやすくなります。そのため、ブラウザーでサイトを開けても、長時間の接続が安定しているとは限りません。問題を伝えるときは、動画の読み込み停止、音声の途切れ、リモート接続の終了、クライアント自体の切断表示のどれなのかを明記してください。アプリの動作と接続経路の変化を切り分ける手がかりになります。

ネットワーク切り替え、スリープ、実際の切断を区別する

切断の直前にWi-Fiと別の接続方法が切り替わったか、端末を閉じたか、画面をロックしたか、省電力状態になったかを確認します。接続先のアドレスやルートが変わると、既存の通信を再確立する必要が生じることがあります。まず端末をスリープさせず、接続ネットワークを固定した状態で試してください。端末の移動やアクセスポイントの切り替え時だけ中断するなら、ネットワーク切り替え後の復帰を確認します。固定した環境でも切れる場合は、回線とクライアントの確認を続けましょう。

クライアントの最近のイベントを確認し、切断前後のエラーの種類を探します。接続先による切断、名前解決のタイムアウト、システムによるネットワーク権限の取り消し、端末側のネットワーク切断では、必要な対応が異なります。最後の「接続失敗」だけを切り取らず、前後の関連イベントも残してください。ただし、サブスクリプション情報やアカウント情報は削除します。詳細なイベント画面がない場合は、内部の原因を推測せず、状態が変化した順序を記録してください。

自動切り替えを繰り返して問題を見えにくくしない

自動選択で一時的に使えるようになることはありますが、接続元が頻繁に変わると、対象アプリでセッションの再確認が必要になる場合があります。原因を調べる間は回線を固定し、症状が続くかを確かめてから通常の選択方法に戻してください。切断を表面上防ぐために、タイムアウト、再試行、接続維持の設定を何度も変更しないでください。設定項目の意味はクライアントごとに異なります。誤った設定は待ち時間や消費電力、同時接続を増やすことがあります。

混雑する時間帯に特定のコンテンツだけで問題が起きる場合は、回線全体の障害とすぐに判断せず、同じアプリの別の公開コンテンツでも比較します。ライブ配信の開始時における接続先の負荷、配信元の切り替わり、端末側ネットワークの利用状況が、回線の影響と重なることがあります。視聴環境に合わせた選び方はスポーツライブ配信の遅延と混雑時の選び方を参考にできますが、現在の問題については発生時の状況を記録してください。

次のような場合はサポートへの問い合わせを検討してください。ネットワークを固定しているのに複数の選択可能な回線で同じ切断が続く、クライアントに同じエラーが繰り返し表示されて自動復旧しない、または通常のアプリで中断を再現できる場合です。端末がスリープしたか、ネットワークを切り替えたか、ほかのプロキシを同時に使っていたか、回線変更後にどうなったかを記載してください。一時的に復旧した場合も、復旧の条件を添えると再現できないという情報だけが残るのを防げます。

設定とアカウント

サブスクリプションの更新失敗と設定エラー

サブスクリプションの更新は、クライアントが設定を取得する処理です。一方、回線接続では取得済みの設定を使って通信経路を確立します。設定が表示されていても最新の更新が成功したとは限らず、更新に成功しても選択中の回線が利用できるとは限りません。まず更新画面のメッセージ全文を確認し、サブスクリプションの接続先にアクセスできない、認証に失敗する、形式を認識できない、更新は完了したが新しい設定に切り替わっていない、といった状況を区別してください。

パネルで設定の取得元を確認する

本サイトのユーザーパネルで、現在のアカウントとサブスクリプションの取得先を確認し、プランがあるアカウントでログインしていることを確かめます。サブスクリプションURLはアクセス用の重要な情報です。問い合わせ本文、チャットグループ、外部の変換サイトに貼り付けないでください。再インポートする場合は、パネルに記載された方法と、現在のクライアントに対応した設定形式を使用します。この記事では実際のサブスクリプションURLを案内していません。ネット上の手順から接続先を推測したり、自分でURLを組み立てたりしないでください。

コピー時にURLの前後へ空白や改行、句読点が入ったり、一部が欠けたりすると、更新に失敗することがあります。クライアント内で登録元がすべて読み込まれているか確認してください。ただし、確認のためにURL全体を他人に見せないでください。取得先を自分でリセットまたは変更した場合、以前の項目が使えなくなることがあります。パネルに表示されている最新情報に従って再インポートします。バックアップから端末を復元した場合は、以前保存した無効な設定を使い続けていないかも確認してください。

更新に使う接続経路が無効になっていないか確認する

クライアントによっては、サブスクリプションの更新をシステムのネットワーク経由にするか、現在のプロキシ経由にするか選べます。更新に使う回線が使えない場合は、更新リクエストも失敗することがあります。設定は残したまま、基本ネットワークが正常であることを確認し、クライアントの説明に沿って更新経路を調べます。利用可能な回線があれば、それを使った結果も比較できます。更新の失敗だけでアカウントが停止されたと判断したり、理由を確かめずにすべての項目を削除したりしないでください。

形式の解析エラーが出たら、取得した内容が本当に設定データか確認します。公共Wi-Fiの接続確認ページ、ブラウザーのエラーページ、認証失敗のメッセージがテキストとして返されても、クライアントでは設定として解析できません。端末の時刻が正しくないと、安全な接続に失敗する場合もあります。まずネットワークへの接続と自動時刻設定を確認してから、パネルで適切な取得先を再取得してください。証明書エラーを無視したり、出所の分からない変換サービスを使ったりして問題を回避しないでください。

更新した設定が実際に使われているか確認する

更新後は、項目の更新日時、現在選択されている設定、回線一覧に変化があるかを確認します。表示される項目はクライアントによって異なります。似た名前のサブスクリプションが複数あると、新しい項目を更新したのに古い項目を使い続けることがあります。残しておく項目には見分けやすいローカル名を付け、目的の設定に切り替えてから再接続してください。独自ルールがインポートしたルールを上書きすることもあります。調査中は上書きされた内容を記録し、すぐにすべて削除しないでください。

アカウントの利用可能な容量も個別に確認します。月額プランのデータ容量は利用開始日を基準に毎月リセットされ、期間途中のアップグレード差額は残り日数に応じて換算されます。暦月の日付だけから利用状況を判断できません。データパックは使い切るまで有効期限がなく、無期限で利用できますが、容量が減らないという意味ではありません。請求や残量に疑問がある場合はプランページでルールを確認し、パネルで利用記録を確認してください。容量を戻そうとしてインポートを繰り返さないでください。

パネルでアカウントが正常と表示されているのに、信頼できる複数のネットワークで更新できない場合は、クライアント名、OS、エラーの全文、更新に使用したネットワーク経路を添えて問い合わせてください。スクリーンショットには項目の状態だけを残し、サブスクリプションURL、QRコード、アカウント情報を隠します。設定を作り直す必要がある場合は、ローカルルールと現在の選択項目を記録してから、使い方ガイドに沿って再インポートしてください。復元後はまず基本的なアクセスを確認し、すぐに複雑な独自ルールを追加しないでください。

アプリの通信経路

特定のアプリだけプロキシを経由しない、またはログインできない

ブラウザーは正常なのに特定のアプリだけ動かない場合は、まずアプリ独自のネットワークの動作を確認します。デスクトップアプリはシステムプロキシを使う場合も、独自のプロキシ設定を使う場合もあります。モバイルアプリはシステムのネットワーク拡張機能に依存することがあり、コマンドラインツールは環境変数を参照する場合があります。まず問題が特定のアプリだけに限られるのか、同じ種類のプログラム全体に及んでいるのかを確認してから、アプリ設定、クライアントのルール、システムによる通信の制御を調べましょう。

動作モードを変える前に通信を確認する

現在の回線を維持し、クライアントのアクティビティ記録を開いた状態で、問題を再現できる操作を一度行います。関連する通信がまったく表示されない場合、アプリが現在のプロキシ経路を使っていない可能性があります。通信が表示されても直結と判定される場合は、振り分けルールを確認します。選択中の回線を通っているのに拒否や認証のメッセージが返る場合は、接続先サービスのアカウント、地域の利用条件、サービス自体の状態も確認してください。確認できる記録の範囲は、使用中のクライアントによって異なります。

システムプロキシと仮想ネットワークによる通信制御は、同じ仕組みではありません。システムプロキシはアプリがシステム設定に従う必要があります。仮想ネットワークによる制御はより低い層で通信を処理しますが、クライアントとシステムの対応が必要です。特定のアプリが失敗したからといって、特定のモードを有効にすべきだと決めつけないでください。まずパネルにあるクライアントの説明を読み、機能と必要な権限を確認してから、現在の設定を残した状態で試します。組織の管理下にある端末では、ネットワーク管理ポリシーを無視しないでください。

アプリ独自のプロキシ、環境変数、プロセスごとのルールを確認する

アプリに独自のプロキシアドレスを入力したことがある場合は、現在のクライアントが待ち受けているローカル接続先を指定しているか確認します。ほかの人の手順からポート番号やプロキシの種類をそのままコピーしないでください。実際の設定値は現在使用中のクライアントで確認します。使用を停止した古いツールの設定がアプリに残り、存在しないローカルサービスへ通信を送っている場合もあります。設定を削除した後は、アプリを完全に終了してから開き直し、バックグラウンドのプロセスが古い接続を使い続けないようにしてください。

開発ツールやターミナルには、古いプロキシの環境変数が引き継がれていることもあります。変数の有無を確認する際、秘密鍵などが含まれる可能性があるため、環境変数をすべて出力して問い合わせに添付しないでください。プロキシを設定したことがあるか、変数がシステムと起動スクリプトのどちらにあるか、削除後に動作が変わったかだけを伝えます。CursorやGeminiなどでは、ログイン画面と主なリクエストが別のコンポーネントを通る場合があります。ホーム画面が開くかどうかだけでなく、それぞれの動作を確認してください。

アクセス失敗とサービス側の拒否を区別する

接続先サービスからアカウントに関する明確なエラーが返る場合、リクエストがサービス側の処理まで到達している可能性があります。この場合、DNSを変更しても解決しないことがあります。アプリのログイン状態、サービスの利用条件、公開されている稼働状況を確認してください。VPNAmpが提供するのはネットワークの接続経路であり、接続先プラットフォームのアカウント資格を決めるものではありません。一度アクセスできたことを長期的な対応の保証として扱わないでください。回線変更後に復旧しても、アカウント制限が恒久的に解除されたとは限りません。

テストが終わったら一時的な変更を元に戻し、動作に必要な最小限の設定を記録します。サポートへの問い合わせには、アプリ名、ログイン時と実際の操作時のどちらで失敗するか、ブラウザー版が正常か、クライアントに該当する通信が表示されるかを記載してください。セッション情報、開発ツールの鍵、閲覧履歴全体を送らないでください。特定の操作だけが失敗する場合は、再現する手順を明確に書くほうが、画面全体の通信スクリーンショットより原因を判断しやすくなります。

端末とシステム

モバイル端末のバックグラウンド切断とプラットフォームごとの違い

前面では接続できるのに、画面をロックしたり別のアプリに切り替えたりすると問題が起きる場合は、まずシステムがバックグラウンド動作をどう扱うか確認します。モバイルOSはバッテリー残量、アプリの状態、端末の管理ポリシーに応じてバックグラウンドの動作を調整します。クライアントが一時停止することと、接続先の回線が切れることは別の問題です。まずクライアントを前面に表示したままアクセスを確認し、その後に画面をロックするか別のアプリへ切り替えます。前面に戻したとき自動で正常に戻るか、システムの動作と切断のどちらが先に起きたかを記録しましょう。

Android：バックグラウンド動作の制限を確認する

システムのアプリ情報から使用中のクライアントを開き、バッテリー最適化、バックグラウンド動作、ネットワーク権限の設定を確認します。設定画面の名称は端末によって異なるため、システムの表示に従ってください。バックグラウンド動作を制限する項目がある場合は、システムの説明に沿ってクライアントの設定を調整し、画面ロック時の動作を再確認します。すべてのアプリの省電力管理をまとめて無効にしたり、確認のために追加の管理ツールをインストールしたりする必要はありません。変更は使用中のクライアントだけにとどめてください。

バックグラウンドの整理、自動最適化、一部の省電力機能によってクライアントのプロセスが終了することがあります。クライアントに接続済みと表示されたままか、再起動が必要かを確認すると、プロセスが終了したか判断しやすくなります。アプリがシステムによって終了されているなら、回線を変更しても通常は解決しません。基本設定はAndroidのサブスクリプション追加・権限・省電力設定ガイドも参考になります。ただし、ほかの端末には存在しないメニュー手順をそのまま使わないでください。

iOS：システムの設定とアプリ画面を分けて確認する

iOSでは、システムのVPN状態とクライアントの画面の両方を確認します。アプリがバックグラウンドに移っても、システムの接続が停止したとは限りません。アプリ画面に以前の状態が残っていても、通信が通っているとは限りません。システム設定で現在有効な構成が使用中のクライアントのものか確認し、ほかのネットワークツールが別の構成に切り替えていないか確認します。再度の許可が必要な場合は、システムに表示される確認手順を使い、出所の分からない構成プロファイルをインストールしないでください。

別の端末からシステムのバックアップを復元した場合、古いネットワーク構成が残っていることがあります。構成の名前と取得元を記録し、用途を確認してから対応してください。仕事や学校で使う構成を誤って削除しないよう注意しましょう。クライアントの入手はユーザーパネルから行えます。パネルのクライアント入手先に進み、検索結果に表示された出所不明のインストーラーや修復用構成を使わないでください。構成の所有者が分からない場合は、先にサポートへ相談してください。

デスクトップOSでもスリープ後に通信経路が変わることがある

WindowsやmacOSでは、端末を閉じたりスリープさせたりした後、Wi-Fi、システムプロキシ、既存のアプリ接続が異なる順序で復旧することがあります。復帰後はまず基本ネットワークを確認し、クライアントが再接続を完了したかを見てから、動作しないアプリを開き直してください。下位の通信経路が復旧しても、長時間の接続はすぐに再確立されないことがあります。アプリを開き直して正常になった場合でも、それ以前の原因が回線だったとは限りません。復旧に必要だった操作を記録してください。

Linuxでは、デスクトップのネットワーク管理、名前解決サービス、アプリのプロキシ機能がディストリビューションによって異なります。まず、どのコンポーネントがネットワークを管理しているかを確認し、現在のクライアントが対象アプリの通信を実際に制御しているか調べます。ネットワーク管理ツール、名前解決ファイル、ターミナルの環境変数を同時に変更すると、どの操作が影響したか判断しにくくなります。システム管理コマンドは、用途と元に戻す方法を理解したうえで使い、ほかのディストリビューション向けの修復コマンドを共通の手順として扱わないでください。

問題が画面ロック中、バッテリー残量が少ないとき、またはスリープからの復帰後だけ起きる場合は、その条件を問い合わせに明記します。アプリを前面に戻すと自動で復旧するか、手動で再接続が必要か、ほかのアプリにも影響するかも記載してください。前面表示かつネットワークを固定した状態でも切断する場合は、混雑時の遅延と切断の項目を確認しましょう。端末の状態変化による問題と接続経路の問題を分けることで、サブスクリプションの再インポートやシステムの不要なリセットを減らせます。

記録と対応

端末の表示、問い合わせ、トラブル対応のまとめ

VPNAmpでは同時接続できる端末数に制限はありません。「デバイス数の上限」などの表示が出ても、本サービスに非公開の端末数制限があるとすぐに判断しないでください。表示がユーザーパネル、使用中のクライアント、接続先サイトのどこから出ているかを確認します。クライアント独自のアカウント同期機能、システムの管理ポリシー、接続先アプリのセッション制限も、似たメッセージを表示することがありますが、VPNAmpの同時接続ルールとは別のものです。

表示元を確認してから対応する

メッセージ全文、表示された画面、直前に行った操作、ログイン中のサービスのアカウントを記録してください。別の端末から本サービスに接続できるか確認してもかまいませんが、不明な表示に合わせてすべての端末から順にログアウトする必要はありません。ユーザーパネルに「端末数無制限」と異なる制限が表示される場合は、問い合わせで状況を説明してください。有料プランへの変更が解除条件だと決めつけたり、無関係なツールを購入したりしないでください。

アカウントとデータ容量の問題も、表示元を分けて確認します。接続端末が多くても、プランのデータ容量に制限がないという意味ではありません。複数端末での利用状況はパネルの記録を確認してください。容量についてはプランとデータパックの説明を参照し、請求に疑問がある場合は該当する注文情報と問題の説明を添えてください。支払いアカウントの個人情報全体は送らないでください。支払い方法はAlipay / WeChat Pay / USDTです。ほかの画面に表示された支払い案内を、本サービスのルールと見なさないでください。

自分での設定変更をやめる目安

基本ネットワークとアカウントに問題がなく、選択可能な複数の回線と信頼できる複数の接続元ネットワークで同じエラーが出る場合は、方向の定まらない設定変更をやめてください。証明書エラーが出る、システム権限が何度も取り消される、設定の取得元を確認できない、端末が組織の管理下にあるといった場合も、まず現在の状態を保ちます。ネットワーク機能を削除したりセキュリティ設定を無効にしたりすると、影響が広がり、本来は特定できた問題に別の問題が重なるおそれがあります。

ユーザーパネルのお問い合わせフォームからご連絡ください。本文は「行おうとした操作、実際の結果、再現条件、確認済みの内容」の順にまとめると伝わりやすくなります。端末のプラットフォーム、クライアント名と使用中のバージョン、接続ネットワークの種類、選択した回線、発生時刻とタイムゾーンを記載してください。使用中のバージョンを伝えるのは環境の違いを確認するためであり、ネット上で指定されたバージョンを使うよう求めるものではありません。

必要な情報を伝え、認証情報を保護する

問題を示すエラーの全文やスクリーンショットを添え、クライアントを切断すると正常か、回線を変えると改善するか、ほかの端末でも再現するかを記載してください。スクリーンショットにはアプリ名とエラーの場所が分かる範囲を残し、出所を判断できないほど小さく切り抜かないでください。パスワード、サブスクリプションURL、QRコード、セッション情報、開発ツールの鍵は画像に表示しないでください。注文に関する内容は、問題の確認に必要な情報だけを共有します。

診断ログも必要最小限の範囲で共有してください。VPNAmpのサービスはログを記録しない方針ですが、端末上のクライアントには、ローカルでのトラブル確認用イベントが保存される場合があります。この二つを混同しないでください。ログを共有する前に、アクセス先、アカウント情報、設定内容が含まれていないか確認します。日常利用の記録全体ではなく、問題の前後に関係する部分だけを共有してください。機密情報に当たる項目が分からない場合は、まずエラーを説明し、問い合わせの案内に従って必要な情報を追加してください。

復旧後は必要最小限の設定に戻す

問題が解決したら、調査中に一時的に有効にしたモード、テスト用ルール、独自プロキシを元に戻し、普段使うアプリが正常か確認します。最終的に有効だった回線、必要な権限、復旧方法を記録し、古い設定を削除する際は元に戻せる情報を残してください。サブスクリプションをリセットした場合は、引き続き使う端末ごとに更新し、古い設定が再び使われないようにします。最後に目指すのは設定を増やすことではなく、確認する条件を減らすことです。

料金やサービスのルールは、正式な案内ページで確認してください。本サービスは60日間の理由を問わない返金に対応しています。申請方法は利用規約をご覧ください。プライバシーについてはプライバシーポリシーをご確認ください。トラブル対応を、終わりのない再試行にしないようにしましょう。問題を再現できても原因を特定できない場合は、すでに確認した情報をサポートに共有するほうが、何度も再インストールするより効果的で、アカウントや設定の手がかりも失わずに済みます。