まったく接続できない:まず切り分けるのは端末側か回線側か
「接続できない」といっても、クライアントが起動しない、接続ボタンを押しても反応しない、接続処理が終わらない、特定のWebサイトだけ開けないなど、症状はさまざまです。まず現在の画面をそのままにして、ボタンの状態とエラーメッセージ全文を記録し、クライアントが実際に接続できているか確認してください。画面に「接続済み」と表示されていても、Webサイトにアクセスできるとは限りません。また、特定のアプリでエラーが出ても、すべての回線に問題があるとは限りません。
まず端末のネットワーク接続を確認する
クライアントの接続を切り、ブラウザーで普段問題なく開けるWebサイトにアクセスしてください。ここでもアクセスできない場合は、Wi-Fiまたは有線接続でネットワークアドレスを取得できているか、公共Wi-Fiのログイン画面で認証が必要か、ルーターが正常にインターネットへ接続されているかを確認します。公共Wi-Fiでは、ネットワークに接続できてもインターネットの利用が許可されていない場合があります。ネットワーク側のログインや認証を済ませてから、クライアントに接続してください。この種の問題は、接続先の回線を何度も変えても解決しません。
接続を切ったあともブラウザーに「プロキシサーバーを利用できません」と表示される場合は、システムプロキシの設定が残っていないか確認してください。一部のクライアントはシステムプロキシ経由でブラウザーの通信を中継します。異常終了後も、停止したローカルポートをシステムが参照し続けることがあります。元のクライアントを再起動し、クライアントに用意されているシステムプロキシの無効化機能を使ってから、通常の手順で終了してください。用途のわからないネットワークアダプターを削除したり、他のクライアントの説明にある固定ポートをそのまま設定したりしないでください。ローカルポートは、使用中のクライアントの設定に合わせる必要があります。
接続に失敗したときは、状況に応じて切り分ける
端末のネットワークが正常なら、クライアントのサブスクリプションまたは設定一覧を開き、読み込み済みの設定が選択されていることを確認します。空の設定や古い手動設定が選ばれていないかも確認してください。回線一覧が表示されるか、選択中のグループに利用可能な回線があるか、アカウントページに利用可能なデータ通信量と有効なサービス状態が表示されているかを確認します。クライアントからシステム権限を求められた場合は、許可画面での操作が完了していることも確認してください。権限の拒否、設定の未有効化、接続先の障害は、いずれも接続ボタンが元に戻る形で現れることがあります。
同じ設定のまま、パネル上で利用可能と表示される別の回線を選び、他の設定は変えずに試してください。元の回線だけで失敗する場合は、その回線、または現在のネットワークから回線までの経路に原因がある可能性が高まります。すべての回線で失敗する場合は、利用可能な別のネットワークに切り替えて比較します。ネットワークを変えて復旧した場合は、接続環境を優先して確認してください。同じ設定が別の端末で正常に動作する場合は、アカウントを何度も作り直すのではなく、問題の端末の権限、プロキシ設定、ソフトウェアの競合を確認します。
権限、タイムアウト、設定エラーを見分ける
権限または認証に関するメッセージが表示されたら、まずユーザーパネルでサービスの状態を確認してからサブスクリプションを更新します。ホスト名の解決に失敗した場合は、次の章でDNSを確認してください。接続がタイムアウトする場合は、回線名と発生時刻を記録し、回線とネットワークをそれぞれ変えて比較します。エラーメッセージの文言は手がかりであり、最終的な診断ではありません。タイムアウトは名前解決、接続の確立、接続先サービスからの応答など、さまざまな段階で起こるため、「タイムアウト」という表示だけで接続先サービスの障害とは判断できません。
端末で他のプロキシ、ネットワークフィルター、セキュリティソフトを同時に使っている場合は、どの機能が通信を制御しているか確認してください。不要なネットワーク制御機能を一時的に停止して再度試し、テスト後は元の設定に戻します。組織の管理下にある端末では、管理ポリシーを自分で無効にせず、端末の管理者に確認してください。複数のネットワークと更新済みの設定を試しても接続できない場合は、エラーメッセージを添えて問い合わせてください。「全部使えない」とだけ伝えるより、原因の特定に役立ちます。
最初から再インストールすることはおすすめしません。再インストールすると、ルール、カスタムの回線選択、端末内の診断情報が消える可能性がある一方、アカウントや接続ネットワークの問題は解決しないことがあります。まず設定名、失敗した段階、比較結果を保存してください。再インストールが必要な場合は、パネルのクライアントダウンロードページからクライアントを入手し、使い方ガイドに沿って設定を復元します。クライアント自体が起動しない場合は、OS、インストール元、システムに表示されたメッセージを記録し、プラットフォーム別の確認または問い合わせに進んでください。
接続できるのにサイトが開かない:名前解決と通信経路を確認
クライアントに「接続済み」と表示されても、それは接続機能が有効であることを示すだけで、すべてのアプリの通信が接続を経由しているとは限りません。Webサイトを開く前には通常、ドメイン名をネットワークアドレスに変換し、接続を確立してから、安全な通信のためのハンドシェイクを行い、Webサイトの応答を待ちます。どの段階で失敗しても、ブラウザーには似たような空白ページが表示されることがあります。まず、すべてのサイトで異常があるのか、海外のサイトだけなのか、特定のドメインだけなのかを記録し、DNS、プロキシの適用、接続先サイトのどこを調べるか決めてください。
エラーの種類から原因を絞り込む
ブラウザーにサーバーアドレスが見つからない、またはドメインを解決できないと表示された場合は、まずDNSを確認します。プロキシ接続エラーの場合は、ローカルのプロキシプロセスとポートを確認してください。証明書またはシステム時刻のエラーが表示された場合は、端末の日付とタイムゾーンを合わせてから再試行します。接続を確認するために証明書の警告を無視したり、出所の不明な証明書をインストールしたりしないでください。証明書の異常とWebサイトの地域制限は別の問題です。警告を回避すると、設定上の本当の問題が見えにくくなる場合があります。
まず同じブラウザーで種類の異なるWebサイトにアクセスし、次に別のインストール済みブラウザーで同じドメインを開いてください。特定のブラウザーだけで異常が起きる場合は、拡張機能、独自のプロキシ、セキュアDNSの設定を確認します。すべてのブラウザーで異常があり、同じネットワーク上の別の端末では正常な場合は、問題の端末のシステムDNS設定やネットワークフィルターを確認してください。ブラウザーのセキュアDNSとクライアントのDNS経路は異なる場合があります。そのため、システムコマンドで名前解決できても、ブラウザーが同じ方法を使っているとは限りません。
DNS設定の関係を理解する
システム、ブラウザー、クライアントには、それぞれDNS設定がある場合があります。ルールモードでは、クライアントがドメイン名に基づいて通信経路を決めることもあります。アプリがドメイン名を先に解決すると、クライアントが受け取るのは接続先のアドレスだけになり、一部のドメインルールが想定どおり適用されない場合があります。別の設定では、ドメイン名とリクエストの対応を保つためにマッピング用アドレスを使うこともあります。互換性に問題がある場合は、関係のないガイドの設定をいくつも重ねるのではなく、現在のサブスクリプションまたはクライアントの既定のDNS設定に戻してください。
確認を始める前に、現在のカスタム設定を記録し、最近変更した項目を一つずつ元に戻します。システムの既定設定、クライアントの既定設定、カスタムDNSは、それぞれ現在のモードに合わせて使う必要があります。すべてのネットワークに適用できる設定はありません。特に、似た機能を持つDNS制御ツールを複数同時に有効にしないでください。変更後、一部のサイトが開くようになり、別のサイトが開けなくなった場合は、該当するドメインと適用ルールを記録し、直前の変更を元に戻して再確認します。キャッシュの問題か、名前解決の経路が変わったのかを判断しやすくなります。
| 表示される症状 | まず確認する項目 | 記録しておく情報 |
|---|---|---|
| ドメインを解決できない | システム、ブラウザー、クライアントのDNS経路 | ドメイン名、エラー全文、名前解決の結果 |
| プロキシ接続に失敗 | ローカルプロキシの稼働状況、ポートの一致 | クライアントの状態、システムプロキシの設定 |
| 証明書または時刻のエラー | システム時刻、Webサイトの証明書、ネットワーク認証ページ | エラー名、警告を無視していないこと |
| 特定のWebサイトだけ異常 | 接続先サービス、ルールの適用、アカウントの地域 | Webサイトのドメイン、ルール、選択中の回線 |
システムツールを使うときは、結果を過大解釈しない
名前解決の結果を確認するには、システムのターミナルで以下のコマンドを実行できます。ここでは公開されているサンプルドメインを使っています。トラブルシューティングでは、問題のあるWebサイトのドメインに置き換えてください。Webページ内のアカウント情報は含めないでください。コマンドでアドレスが返された場合、それはそのコマンドが使った名前解決経路で結果を取得できたことを示すだけです。現在の回線に適した結果であることや、安全な通信のハンドシェイクが完了したことまでは確認できません。コマンドを使えない場合は、ブラウザーのエラーを記録するだけで十分です。トラブルシューティングのためにツールを追加でインストールする必要はありません。
nslookup example.com
DNS設定を変更したら、問題のページを閉じて開き直してください。必要に応じて、OSの手順に従ってDNSキャッシュを消去し、関連するアプリを再起動します。すべてのWebサイトのデータを一度に消去すると、ログイン状態が変わり、原因の判断が難しくなるため避けてください。特定のサイトだけ問題が続く場合は、古い手動アドレス設定が残っていないか、クライアントでそのドメインが誤って直結に振り分けられていないか確認します。手動設定を確認するときは用途が明確な項目だけを扱い、見覚えのない設定ファイルを丸ごとコピーしないでください。
異なるネットワークや回線でも同じドメインの異常を再現できる場合、問い合わせにはドメイン名、エラーの種類、適用されたルールを記載してください。アクセス先の完全なURLは不要です。URLのセッションIDやクエリパラメーターには、機密情報が含まれている可能性があります。VPNBabyはログを記録しない方針です。端末内の診断記録は必要に応じてユーザー自身が確認できますが、サポートに提供する前に認証情報を確認し、隠してください。Webページが開いたあと、地域に関する理由で利用できないと表示された場合は、DNSの問題として扱い続けず、接続先プラットフォームのポリシーを確認してください。
速度低下や夜間の混雑:帯域と応答を分けて考える
「速度が遅い」という症状を、まず具体的に説明できる形にしましょう。ページの読み込み開始まで時間がかかる、画像の読み込みが終わらない、動画が途切れる、ダウンロードが遅い、AIの回答生成に時間がかかるなど、問題が起きている段階はそれぞれ異なります。応答までの待ち時間は経路や名前解決、接続先サービスの影響を受けやすく、データを継続して転送する速度は、ローカルネットワーク、接続先への通信、アプリの処理にも左右されます。クライアントの回線テスト結果を実際のダウンロード速度と同じものと見なしたり、特定のアプリで一度起きたことからサービス全体の品質を判断したりしないでください。
まず同じタスクで比較する
同じWebページや同じ動画など、実際に問題が起きているタスクを選び、比較に使います。端末、アプリ、ネットワークを変えずに回線だけを切り替え、どの段階で待ち時間が発生するか確認してください。次に回線を固定したまま、他の端末で同期、ダウンロード、動画再生などが行われていないか確認します。バックグラウンドのバックアップやシステム更新が接続ネットワークの帯域を使っていることがあります。ブラウザーしか使っていないように見えても、通信が混雑している場合があります。不要な通信を一時停止して同じタスクをもう一度試すと、変化の原因を切り分けやすくなります。
Wi-Fiの電波環境も別に確認してください。ルーターから離れている、壁を挟んでいる、電波が切り替わる境界にいる場合は、ローカル通信の再送が増えることがあります。ルーターの近くで試すか、可能であれば有線接続と比較してください。ローカルネットワークの状態を改善すると、すべての回線で同時に復旧する場合は、まず接続環境を見直します。回線名が地理的に近く見えるからといって、必ず速いとは限りません。実際の通信経路と現在の接続ネットワークとの組み合わせは、地理的な距離より重要なことがあります。
夜間の速度低下や途切れを確認する
混雑する時間帯に問題が集中する場合は、そのときの接続ネットワーク、回線、アプリを記録し、別の時間帯に同じタスクを試してください。混雑時だけ異常があるとしても、VPNBabyの特定の処理が混雑しているとは限りません。家庭内ネットワークの共有、アクセス回線、国際通信経路、接続先プラットフォームは、いずれも混雑時に状態が変わる可能性があります。回線を変えて改善した場合は、現在のネットワークにより適した回線を選んでください。接続ネットワークを変えて改善した場合は、ローカル側やアクセス回線の影響を優先して調べます。
地域を比較するときは、接続先のアプリが必要とする地域をできるだけ固定してください。たとえば、特定の地域を使い続けるアカウントでは、まずその地域で選べる回線同士を比較し、読み込みを少し速くするために地域を何度も切り替えないようにします。プラットフォームはアカウントやアクセス環境に応じて追加確認を求めることがあり、トラブルシューティングが複雑になる場合があります。対応地域はグローバルノードのページで確認できます。選択可能な回線はユーザーパネルで確認してください。対応地域の数だけでは、現在のタスクで実際に使えるかどうかは判断できません。
アプリの動作に応じて速度低下を確認する
動画を再生するときは、再生開始が遅いのか、再生中にバッファリングが続くのかを切り分けます。再生開始の遅れは、名前解決、アカウント認証、コンテンツ配信先の選択が関係している場合があります。再生中に途切れる場合は、継続的なデータ転送とローカルの帯域を確認してください。同時に行っているダウンロードを停止し、アプリ内で画質を下げて比較します。画質を下げて改善しても、通信条件の影響を受けやすいことが分かるだけで、具体的なボトルネックが特定できたわけではありません。画質やプラットフォームの地域に関する問題は、動画配信の特集もご覧ください。
AIツールでWebページや入力欄は正常に動作するのに、送信後の待ち時間が長い場合は、プラットフォームに待ち行列、利用上限、サービス混雑、アカウントに関する表示がないか確認してください。回答の生成速度はネットワークだけで決まるものではありません。静的ページや他のリクエストが正常で、生成処理だけ遅い場合は、プラットフォームの表示を記録し、AIツールの特集を参考にネットワークとサーバーの状態を切り分けてください。生成待ちの原因を調べるためにアカウントデータを何度も消去したり、地域を変更したりしないでください。新たな変数が増えてしまいます。
速度の問題を調べる際は、データ通信量の残りも確認してください。月額サブスクリプションの通信量は契約開始日を基準に毎月リセットされます。追加データパックは使い切るまで利用でき、有効期限はありません。両者のリセット方法は異なります。プランと残量はパネルで確認し、ルールの詳細は料金ページをご覧ください。クライアントの過去の通信量表示だけを根拠に、アカウントの残量を判断しないでください。集計対象や計算方法が異なる場合があります。パネルの表示に異常がある場合は、表示内容を記録して問い合わせてください。明記されていない速度制限のポリシーを推測しないでください。
問い合わせに役立つのは、同じタスクを異なる回線、ネットワーク、時間帯で試した結果です。関係のない速度測定のスクリーンショットを大量に送る必要はありません。テスト中にバックグラウンドの通信を停止したか、有線接続を使ったか、遅いのは最初の応答か継続的なデータ転送かを説明してください。すべてのWebサイトで同じように動作すると期待したり、要求したりしないでください。接続先のサービスの状態も変化します。偶然速かった、または遅かったという結果より、繰り返し再現できる条件のほうがサポートによる原因特定に役立ちます。
頻繁に切断される、バックグラウンドで切れる:動作条件を確認
接続が切れた場合は、まず「クライアントが停止した」のか、「クライアントは動作しているがリクエストに失敗している」のかを区別します。システムの接続表示が消え、クライアントが未接続の状態に戻った場合は、プロセス、権限、ネットワーク切り替えを確認してください。接続表示が残っているのにアプリが一時的に読み込めなくなった場合は、ネットワークの変更後に元の接続が復旧していないか、使用中の回線に異常がある可能性があります。切断回数だけでなく、直前に画面をロックしたか、ネットワークを切り替えたか、スリープしたか、省電力モードを有効にしたかを記録すると役立ちます。
画面ロック後にモバイル端末で問題が起きたときの確認手順
まず画面を点灯したまま、問題が起きるタスクをもう一度試し、そのあと画面をロックしてからアプリに戻って結果を比較してください。バックグラウンドまたは画面ロック後だけ問題が起きる場合は、クライアントのバッテリー管理、バックグラウンド動作、ネットワーク利用の制限を確認します。Androidでは、OSのバージョンによって設定項目の場所が異なります。アプリ情報から、バッテリー、バックグラウンドでの動作、データ使用量に関する設定を探してください。まず現在のクライアントに必要な制限だけを緩和し、すべてのアプリの省電力設定を無効にする必要はありません。
一部のOSでは、アプリのタスク終了機能によってクライアントが停止する場合があります。最近使ったアプリの一覧にある保持設定と、OSからVPN接続の権限を得ることは別の問題です。前者はプロセスの動作に、後者は接続の確立に影響します。設定を変更したら、保存されたことを確認するだけでなく、画面を点灯してアクセスし、画面をロックし、アプリに戻るという元の手順を実行してください。それでも問題が起きる場合は、クライアントが停止したとOSに表示されるか、クライアントを開き直したあとに手動で再接続する必要があるかを記録します。
iOSでは、まずシステムのVPN設定と使用中のクライアントが一致しているか、別の設定が接続を制御していないか確認してください。クライアントの切り替え、システムのネットワーク設定の変更、設定の更新後には、古い接続を再確立する必要がある場合があります。複数のVPN設定を同時に有効にして比較しないでください。オンデマンド接続などの設定を変更する場合は、使用中のクライアントの説明を確認します。自動接続をむやみに有効にすると、手動で切断したあとに再接続する動作を異常と誤認することがあります。
ネットワークの切り替えとデスクトップ端末のスリープ
端末がWi-Fiから別の接続方法に切り替わると、ローカルのネットワークアドレスが変わり、既存の接続が無効になる場合があります。まず、新しいネットワークで通常のWebサイトにアクセスできることをOSが確認するまで待ってから、クライアントに再接続してください。切り替えるたびに再接続が必要な場合は、切り替えた方向とクライアントの表示を記録し、自動復旧のオプションが利用できるか確認します。ネットワーク認証が完了する前に何度も回線を切り替えないでください。タイムアウトの記録が増えるだけで、復旧機能が正常に動作しているか判断できなくなります。
デスクトップ端末がスリープから復帰したら、まずネットワークアダプターが接続を回復していることを確認し、そのあとクライアントの接続状態とシステムプロキシを確認してください。プロセスが動作していてもローカルプロキシが応答しない場合は、通常の手順で一度切断してから再接続できます。端末全体を再起動する必要はありません。復帰のたびに再現する場合は、電源設定、ネットワークアダプターの状態、セキュリティソフトのイベントを確認します。会社の端末が管理システムによってスリープ設定を制御されている場合は、管理者に確認し、管理下の設定を自分で変更しないでください。
切断が続く場合、さらに原因を絞り込む
画面を点灯し、ネットワークを固定しても頻繁に切断される場合は、使用中のアプリやタスクを変えずに別の回線を試してください。特定の回線だけで再現する場合は、回線名と発生時刻を記録します。すべての回線で再現する場合は、別の端末で比較してください。別の端末で安定する場合は、問題の端末のネットワークフィルター、権限、クライアント設定を重点的に確認します。同じネットワークにつながる端末がすべて切断される場合は、別のネットワークでも比較してください。こうすることで、接続ネットワークの変動をバックグラウンド動作の問題と誤認しにくくなります。
自動再試行のオプションをすべて同時に有効にしないでください。自動再試行を続けると最初のエラーがわからなくなり、接続が変化し続ける様子だけが見えて、切断の原因を追えなくなることがあります。まず既定の動作のまま、クライアントが切断されたときの元のメッセージを記録し、必要に応じて明確な復旧オプションを有効にします。常にVPN経由で接続する設定や、切断時にネットワークを制限する設定がある場合は、用途を確認してください。接続できないときに通常のWebサイトへアクセスできないのは、その設定の想定どおりの動作である可能性があります。
問い合わせには、端末を前面で使用中、バックグラウンド動作中、画面ロック中、スリープからの復帰後のどのタイミングで問題が起きたか、他のアプリも同時にネットワーク接続を失ったかを記載してください。Androidのバックグラウンド設定やアプリごとの動作については、Androidのバックグラウンド動作とアプリ別プロキシの記事も参考になります。ブラウザーが正常に動作し、特定のアプリだけがバックグラウンドで更新されない場合は、そのアプリのバックグラウンド権限を確認し、ネットワーク全体の設定を何度も変更しないでください。
サブスクリプションを更新できない:取得元と設定を確認
サブスクリプションの更新と回線への接続は関連していますが、それぞれ別に失敗することがあります。サブスクリプションからクライアントへ設定が提供され、その読み込み済みの設定を使って回線に接続します。古い設定で一時的に接続できても、サブスクリプションのURLが有効とは限りません。更新に成功しても、現在のネットワークから一覧内のすべての回線に接続できるとは限りません。まず、コピー、インポート、取得、解析、保存のどの段階で失敗したかを記録し、該当する処理を確認してください。
ユーザーパネルで取得元を再確認する
ユーザーパネルにログインし、アカウントのサービス状態とサブスクリプションの取得先を確認してください。メールアドレスは不要です。ユーザー名とパスワードでアカウントを作成できます。トラブルシューティングの際は、現在のサービスを利用しているアカウントでログインしてください。どのアカウントを使ったか忘れた場合でも、アカウントを次々に作成しないでください。パネルにログインできることと、プランが正常な状態であることは別の判断です。まずアカウントページの表示内容を確認し、必要な対応を判断してください。
パネルに用意されているコピーまたはインポート機能を使い、チャット履歴、古いメモ、スクリーンショットからURLをつなぎ合わせないでください。コピー時に空白、改行、説明文が混ざると、クライアントに渡されるURLが不完全になることがあります。サブスクリプションをリセットしたことがある場合は、端末に保存されているURLも再確認してください。サブスクリプションURLはアクセス用の認証情報です。公開ページ、オンライン変換ツール、グループチャットに送信したり、動作例として実際のURLを問い合わせのタイトルに記載したりしないでください。
ネットワークから取得できない問題と、内容を解析できない問題を区別する
クライアントに取得のタイムアウトが表示された場合は、まず現在のネットワークからパネルにアクセスできることを確認し、サブスクリプションの更新リクエストが直結と既存プロキシのどちらを使っているか確認してください。既存の設定が無効なときに、古いプロキシ経由で強制的に更新すると、「更新には接続が必要だが、接続には更新前の設定が必要」という循環が起こる場合があります。元の設定を残したまま、クライアントが提供する更新経路のオプションを使って比較してください。古い設定を同時に削除すると、元に戻せる状態が失われるため避けてください。
形式エラー、設定の解析失敗、未対応フィールドなどが表示された場合は、パネルで選択したインポート形式が現在のクライアントに適しているか確認してください。クライアントによって対応する設定形式が異なるため、URLが似ているからといって使い回せるとは限りません。まず、パネルにある該当クライアント向けの入口から取得し直し、更新後に設定名と回線一覧を確認してください。設定内の用途がわからないフィールドを大量に手動で削除しないでください。読み込みはできても、ルールや名前解決の設定が壊れることがあります。
| 失敗した段階 | 確認する内容 | 次に行うこと |
|---|---|---|
| コピーまたは起動 | URLが完全か、正しいクライアントが選ばれているか | パネルに戻り、コピーまたはインポートし直す |
| 取得のタイムアウト | ネットワークの到達性、更新リクエストの経路 | 古い設定を残したままネットワークを比較する |
| 内容の解析 | 設定形式がクライアントに合っているか | 対応する入口から取得し直す |
| 保存後も一覧が変わらない | 現在有効な設定、回線グループ、フィルター | 実際に読み込まれている設定名を確認する |
更新後に確認すること
更新したら、まず新しく更新した設定が有効になっているか確認し、次に回線一覧とルールが読み込まれているかを確認します。クライアントによっては、サブスクリプションが一覧に保存されても自動で切り替わりません。設定とは別に回線選択の状態を保存できるクライアントもあります。更新後も古い回線が使われている場合、更新が反映されていないとは限りません。現在の回線グループの選択が以前のままになっている可能性もあります。成功メッセージだけでなく、設定名とルールの適用状況を確認してください。
更新後に一覧の項目が急に減った場合は、検索、地域フィルター、折りたたまれたグループを確認し、パネルにも表示内容を照合してください。静的ページにある対応範囲の説明は、アカウント内の各グループに表示される項目を保証するものではありません。VPNBabyは90以上の国・地域、160以上の回線に対応していますが、現在のアカウントで利用できる内容と具体的な取得先はパネルで確認してください。パネルとクライアントに明らかな違いがある場合は、設定形式、更新時刻、表示されない項目を記録してサポートに確認を依頼してください。
自動更新に失敗して手動更新には成功する場合は、バックグラウンドでのネットワーク権限、自動タスクが動作する条件、更新時にネットワークに接続されていたかを優先して確認してください。更新頻度を過度に高くしても、無効なURLや形式の不一致は解決しません。状況を把握しやすい更新方法を使い、クライアントに直近の更新成功が表示されていることを確認してから通常の利用に戻してください。基本用語を確認したい場合は、サブスクリプション、ノード、ルールの用語集をご覧ください。
複数の端末で更新に失敗し、パネルにも想定した内容が表示されない場合は、インポートを繰り返さず問い合わせてください。エラー文、クライアントの種類、選択したインポート方法、再現条件を伝えます。サブスクリプションの本文や完全なURLは添付しないでください。URLが漏えいした疑いがある場合は、パネルで利用できるリセット機能を使ってから、自分の端末を更新してください。対処方法がわからない場合は、問い合わせから相談してください。テストのためにURLを何度も他人に送ると、その後の原因調査と認証情報の管理が難しくなります。
特定のアプリだけプロキシを経由しない:ルールの適用を確認
ブラウザーは正常なのに特定のアプリだけ異常がある場合、すぐに回線全体の問題と判断しないでください。アプリがシステムプロキシを参照しない、独自の名前解決方法を使う、またはアプリ別のルールで除外されている可能性があります。ルールモードでは、ドメイン名やアドレスなどの条件に基づいて通信経路が選ばれます。まず「アプリの通信がクライアントに届いているか」、次に「どのルールが適用されているか」、最後に「選択された回線でリクエストを完了できるか」の順に確認してください。この順序なら、誤った段階の設定を変更せずに済みます。
まずプロキシの適用方法を確認する
システムプロキシは、その設定を参照するアプリで使われます。すべてのネットワークリクエストが自動的に従うわけではありません。デスクトップアプリ、コマンドラインツール、独立した実行環境では、それぞれにプロキシを設定する必要がある場合があります。クライアントが対応するネットワーク制御モードが必要な場合もあります。まず、現在のクライアントが提供する機能と権限の状態を確認し、次に対象アプリのネットワーク設定を確認してください。ローカルプロキシのアドレスに接続先の回線アドレスを設定したり、ローカルの待ち受けポートを推測して入力したりしないでください。
ターミナル、仮想環境、コンテナでは、デスクトップアプリのネットワーク設定が共有されない場合があります。ホスト側のブラウザーからアクセスできても、コンテナ内のプログラムが同じ経路を使っているとは限りません。実際に問題が起きている実行環境でプロキシ設定を確認し、停止したクライアントを参照する環境変数が残っていないか調べます。明らかに不要になった項目だけを削除し、変更後は関連するプロセスを再起動してください。アプリ起動時に読み込まれた環境変数は、そのあとでシステム設定を変更しても自動更新されないことがよくあります。
モードを切り替えてルールの問題を特定する
ネットワークと回線を変えずに、クライアントのルールモードとグローバルモードを一時的に切り替えて、原因を確認できます。グローバルモードでは正常でルールモードでは異常な場合は、まずルールの適用状況と既定の出口を確認します。どちらのモードでも異常がある場合は、アプリの通信がクライアントに届いているか、接続先サービスと回線が正常かを続けて確認してください。グローバルモードは比較のための手段であり、すべての問題に対する恒久的な解決策ではありません。テスト後は元のモードに戻し、本来直結する通信の経路が変わらないようにしてください。
ローカルの接続一覧を確認するときは、対象アプリからリクエストを再送し、該当するドメインやプロセスが表示されるか確認します。関連するリクエストが見当たらない場合は、クライアントが通信を制御する前の段階で問題が起きている可能性があります。リクエストが表示されて直結になっている場合は、ルールが想定どおりかを確認してください。プロキシグループが適用されている場合は、そのグループで実際に選択されている回線を確認します。グループ名だけでは出口はわかりません。グループ内の選択が直結、自動選択、利用不可の項目になっている場合があるため、最終的な選択までたどって確認してください。
ルールの順序とアプリの例外を確認する
ルールには通常、適用順序があります。広い条件のルールが先に一致すると、後にある細かなルールが適用されない場合があります。最近追加したルールが、より具体的なドメインのルールを上書きしていないか確認してください。アプリのログイン、静的コンテンツ、APIが異なるドメインを使うこともあります。アプリのトップページのアドレスだけをルールに追加して、すべての通信が対象になったと思い込まないでください。まず現在の設定で使われているルール体系を利用し、不足が確認できた場合に限って範囲を明確にしたルールを追加し、変更理由を記録します。
Androidのアプリ別プロキシでは、一覧の意味が「このアプリだけを使う」のか「このアプリを除外する」のか確認してください。二つの意味は混同しやすく、画面でチェックが入っていてもプロキシが有効とは限りません。変更後は対象アプリを完全に終了してから再起動し、新しいリクエストの経路を確認します。仕事用プロファイル、アプリの複製、別ユーザー環境にも同じアプリがある場合は、どのインスタンスに設定が適用されているか確認してください。メインのユーザー領域だけを変更して、すべてに反映されたと思い込まないでください。
接続先アプリに地域制限、アカウントのリスク判定、コンテンツを利用できないといった表示が出た場合は、それぞれ分けて確認してください。ネットワークリクエストがプラットフォームに到達しているなら、プロキシを経由していないことが原因とは限りません。アカウントの地域、支払い情報、プラットフォームのポリシー、コンテンツの利用許諾も結果に影響する場合があります。動画配信については、日本のアニメと配信向け回線の選び方も参考になります。判断せずに地域を頻繁に切り替えたり、アカウントのエラーを回線自体に接続できない問題と解釈したりしないでください。
カスタムルールが機能しなくなった場合は、まず自分で加えた変更の内容をエクスポートし、変更していない設定と比較します。認証情報を含む設定ファイル全体を、出所のわからないオンラインツールにアップロードしないでください。元の設定で正常に動作する場合は、必要な変更を一つずつ戻します。元の設定でも再現する場合は、アプリ名、リクエスト先のドメイン、適用ルール、実際の出口を記録して問い合わせてください。ルーティング、グローバルモード、ノードの関係は、初心者向け用語集で確認できます。用語を整理してから設定を変更してください。
プラットフォームや端末ごとの表示:状態の発生元を確認
VPNBabyはWindows / macOS / iOS / Android / Linuxに対応しており、同時接続台数に制限はありません。「端末が多すぎる」「すでに接続されています」などの表示が出ても、本サービスの端末数に上限があるとは限りません。OS、別のクライアント、接続先アプリ、端末内の接続設定が表示している可能性があります。まずメッセージ全文と表示された場所を記録し、ユーザーパネル、クライアント、システム設定、接続先のWebサイトのどこに表示されたのかを確認してください。
同時接続台数に制限がなくても、端末内の接続が競合する場合がある
接続する端末の数と、同じ端末上で通信を制御する機能が競合する問題は別です。OSによっては複数のVPN設定を同時に想定どおり使えない場合があり、プロキシツール同士が同じローカルの待ち受け先を使おうとすることもあります。別のツールがすでにネットワークを制御している場合、新しいクライアントに接続エラーや権限エラーが表示されることがあります。これはアカウントの端末数が上限に達したという意味ではありません。まず他の接続を通常の手順で切断し、現在のクライアントを有効にしてください。複数のツールを同時に動かして接続できる可能性を高めようとしないでください。
接続先アプリ自体の端末制限も区別する必要があります。動画配信、業務用アプリなどのアカウントサービスが管理するログイン端末数は、VPNBabyの同時接続方針とは関係ありません。接続先アプリだけにエラーが表示される場合は、そのアプリのアカウントページと説明を確認してください。ユーザーパネルまたはVPNBabyのクライアントにエラーが表示される場合は、スクリーンショットを保存して問い合わせます。曖昧なメッセージだけを根拠に、別のアカウントを作成したりプランを選び直したりしないでください。
| プラットフォーム | まず確認する項目 | 間違えやすい症状 |
|---|---|---|
| Windows | システムプロキシ、ネットワーク制御の権限、セキュリティソフト | クライアント終了後もプロキシ設定が残る |
| macOS | ネットワーク拡張の権限、システムプロキシ、スリープからの復帰 | 画面は開いているが権限の許可が完了していない |
| iOS | 現在のVPN設定、クライアントの状態、ネットワークの切り替え | 古い設定と現在のクライアントが一致していない |
| Android | バックグラウンドの制限、VPNの権限、アプリ別の一覧 | 画面ロック後にプロセスが停止する、またはアプリが除外されている |
| Linux | プロセスの状態、環境変数、デスクトップのプロキシ、権限 | ターミナルとデスクトップアプリで異なる通信経路を使う |
デスクトップ環境ではOS側の通信制御を確認する
Windowsでは、まずクライアントがまだ動作しているか確認し、システムプロキシが現在のクライアントを参照しているかを確認します。ブラウザーは正常なのに他のプログラムで異常がある場合は、そのアプリがシステムプロキシを参照しているか確認してください。セキュリティソフトがネットワーク制御を妨げている場合は、明確な通知やイベントを確認します。すべての保護機能をまとめて無効にしないでください。組織が管理する端末では、設定がポリシーによって元に戻され、「変更してもすぐに元に戻る」ことがあります。その場合は、管理者に権限を確認してください。
macOSでは、クライアントの画面が開いていても、必要なネットワーク拡張機能やシステム権限の許可が完了しているとは限りません。システムの指示に従って権限を確認し、接続を再確立してから対象アプリを試してください。他のネットワークツールをアンインストールしたことがある場合は、システムに関連するネットワーク設定が残っていないか確認します。ただし、出所が明確な項目だけを扱ってください。Linuxでは、デスクトップのプロキシとターミナルの環境変数が別々に設定されている場合があります。サービスのプロセスが動作していても、現在のデスクトップセッションがそれを使っているとは限りません。
モバイル端末では権限と設定を確認する
iOSでは、現在のシステムVPN設定が使用中のクライアントから作成されたものであることを確認し、切り替え時に古い設定が再び有効にならないようにしてください。初めて設定する場合は、iPhoneでサブスクリプションを読み込み、接続を確認する方法を参考に、設定、権限、確認の順に見直します。クライアントはパネルから入手してください。iOSのダウンロード先はパネルに表示されるプランの状態に応じて案内されます。静的ページから出所の不明なアプリをインストールしないでください。
Androidでは、バックグラウンドの制限に加えて、現在のクライアントがVPN接続を作成できるか、アプリ別の一覧から問題のアプリが除外されていないかも確認してください。端末のユーザー領域が異なる場合、権限やアプリ一覧の設定も別々になっていることがあります。まず対象アプリを使っているユーザー領域で確認してから、接続を比較してください。他のプラットフォームでは、ログイン後にクライアントのダウンロードページからクライアントと関連情報を入手できます。サブスクリプションの取得にもログインが必要です。第三者から転送されたインストールファイルではなく、公式の入口を利用してください。
同じアカウントを使うすべての端末でサービスの状態に同じ問題が起きている場合は、まずパネルを確認してください。特定のプラットフォームだけで異常がある場合は、そのプラットフォームの権限と設定を確認します。同じ端末でクライアントを変えると動作が異なる場合でも、すぐに元のクライアントの不具合と断定しないでください。通信の制御モード、名前解決の設定、実際に有効な設定が一致しているか比較します。比較条件が一致していなければ、そこから導いた結論も正しくない可能性があります。
端末の問題について問い合わせる際は、OS名、クライアントに表示される名称、権限のメッセージ、問題が起きた段階を伝えれば十分役立ちます。端末のシリアル番号、OSのアカウントパスワード、ネットワーク設定一式は送らないでください。メッセージに端末の制限が明記されている場合は、表示された文言をそのまま引用し、表示された場所を説明します。VPNBabyは同時接続台数に制限がありません。この事実を確認するために、より高い料金のプランへ変更する必要はありません。まず表示の発生元を確認し、次にどちらの窓口で対応すべきか判断してください。
問い合わせと設定の復元:証拠を残してから完了する
トラブルシューティングの結果は、自分で設定を変更して解決することだけではありません。問題の範囲が明確になり、サポートによる確認が必要だと分かることもあります。複数のネットワークでサブスクリプションを更新できない、同じ回線で複数の端末に継続して異常が起きる、パネルの表示と実際のサービス状態が明らかに異なる、変更していない設定でも同じエラーが再現するといった場合は、問い合わせに進んでください。そのまま再インストールや設定の消去を繰り返したり、地域を何度も切り替えたりすると、得られた証拠を失うおそれがあります。
再現できる手順として症状を説明する
まず、期待した結果と実際の結果を記載してください。たとえば「ブラウザーでトップページは開くが、ログイン後のAPIリクエストが失敗する」は、「サイトがおかしい」より正確です。「画面をロックしてアプリに戻ると、クライアントが未接続と表示される」は、「バックグラウンドが不安定」より判断しやすくなります。続いて、操作の順序、発生した時刻とタイムゾーン、接続ネットワークの種類、クライアント名、OS名を説明してください。バージョン情報が必要な場合は、端末に実際に表示されている情報を記載します。記憶で推測したり、別の端末の情報を引用したりしないでください。
次に、これまでに行った比較を列挙し、各回で変更した項目を一つずつ記載してください。回線を変えて復旧したか、ネットワークを変えて復旧したか、同じアカウントの別の端末では正常か、元の設定とカスタム設定に違いがあるかを説明できます。まだ試していない比較は未確認と記載してください。問い合わせを完全なものに見せるために、結果を推測しないでください。サポートに必要なのは、根拠の範囲がわかる情報です。推測を含む断定的な結論ではありません。
端末内の診断情報を整理する前に個人情報を隠す
VPNBabyはログを記録しません。この方針と、端末内に診断画面があるかどうかは別に考える必要があります。クライアントには、ユーザー自身がトラブルシューティングに使える接続エラー、ルールの適用状況、リクエストの状態が表示されることがあります。問い合わせのために詳細な診断を広範囲かつ長時間有効にしたり、記録をそのまますべてエクスポートしたりしないでください。問題が起きた前後の、関連するエラーだけを抜き出し、サブスクリプションURL、認証情報、個人の閲覧内容を隠してください。
スクリーンショットは端の部分も確認してください。アカウント名、クリップボードの通知、ブラウザーのタブ、クエリパラメーター、他のウィンドウの内容が意図せず写り込むことがあります。Webサイトの異常については、通常、ドメイン名とエラーの種類だけで十分です。個人のセッション情報を含む完全なURLを添付する必要はありません。注文に関する問い合わせでは、確認に必要な注文情報を提供し、関係のない支払い情報を隠してください。元のスクリーンショットを公開コメントやグループチャットに投稿してから、そのリンクを問い合わせに転送しないでください。
そのまま使える問い合わせ文のテンプレート
以下の項目は情報を整理するためのものです。すべてを埋める必要はありません。不明な項目は「不明」、試していない操作は「未テスト」と記載してください。回線名はパネルに表示される名称を使い、回線の種類や都市名を推測して付け加えないでください。特定のアプリの問題なら、アプリに表示されたメッセージと問題が起きた段階を記載します。ネットワークの切り替えが関係する場合は、切り替え前後のクライアントの接続状態を記載してください。これにより、サポートが同じ判断手順を続けやすくなり、一般的な質問を最初から繰り返す必要がなくなります。
問題の症状:
発生時刻とタイムゾーン:
OSとクライアント:
接続ネットワークの種類:
現在のモードと設定名:
選択中の回線:
エラーメッセージ全文:
回線を変更した結果:
ネットワークを変更した結果:
別の端末での結果:
最近変更した設定:
認証情報を隠した関連スクリーンショット:
問い合わせを送信したあとも、問題を再現できる設定は残し、複数の場所で大幅な変更を同時に行わないでください。その後自分で復旧できた場合は、「直った」とだけ書くのではなく、復旧前に最後に行った操作を元の問い合わせに追記します。サポートから設定のテストを依頼された場合は、変更前の値、変更後の値、結果を記録し、テスト後に設定を残す必要があるか確認してください。明確な効果がない一時設定は元に戻し、次の問題発生時に設定の由来がわからなくなるのを防ぎましょう。
復旧後、通常の使い方で確認する
接続が復旧したら、接続アイコンを見るだけでなく、実際に必要なタスクをもう一度行ってください。ブラウザー、対象アプリ、本来直結する通信が正常か確認し、ルールモード、選択中の回線、バックグラウンドの動作が普段の使い方に合っていることを確認します。トラブルシューティングのためにグローバルモードへ切り替えた、セキュリティソフトを一時停止した、バックグラウンドの制限を変えた、DNS設定を変更した場合は、最終的な状態を一つずつ確認してください。簡単な変更記録を残しておくと、次回設定を思い出すときに役立ちます。
プランの状態が原因と思われる場合は、料金ページで月額サブスクリプションと追加データパックの違いを確認し、実際の状態はパネルで確認してください。月額サブスクリプションの通信量は契約開始日を基準に毎月リセットされ、期間途中でアップグレードした場合は差額が残り日数に応じて計算されます。追加データパックは使い切るまで利用でき、有効期限はありません。理由を問わない14日間の返金保証があります。詳しい申請条件は利用規約をご覧ください。トラブルシューティング中に一時的に復旧しても、それを追加のプラン特典と解釈しないでください。原因が特定できていない段階で、むやみに上位プランへ変更する必要もありません。
最後に、安定して使える設定を今後の比較基準として残してください。同じ症状が起きたときは、ネットワーク、システム権限、最近の変更を比較してから、このページの該当する手順をもう一度確認します。新しい端末の初期設定は使い方ガイドから始めてください。接続できているのにアプリの動作に異常がある場合は、ルーティングまたは名前解決の章に戻ります。このガイドの目的は、すべてのユーザーにあらゆる設定を覚えてもらうことではありません。毎回の確認に、明確な出発点と根拠、そして終了の判断基準を設けることです。