システム診断マニュアル

ネットワークトラブル診断完全ガイド

ローカルネットワーク、システムプロキシ、クライアント、サブスクリプション、回線、振り分け、DNSを順に確認します。まず問題の層を特定してから設定を変更し、複数の条件を同時に変えないようにしましょう。

クイックスタートを見る ヘルプセンターへ
  • 100か国以上対応エリア
  • 210以上の回線選べる回線
  • 台数無制限利用デバイス
  • 30日間理由を問わない返金
Diagnosis model

トラブル診断の基本手順

原因を決めつけず、まず症状を記録する

ネットワークの問題で最も起こりやすい誤判断は、「そう見えるもの」を「実際の原因」と決めつけることです。ページが読み込み中のままなのは、DNSが応答していない、接続先が現在の出口を拒否している、ブラウザーが古い接続を使い続けているなど、複数の原因が考えられます。クライアントに「接続済み」と表示されても、ローカルプロキシと選択した回線のハンドシェイクが一段階完了したことを示すだけで、すべてのアプリが想定どおりその回線を通るとは限りません。確認時は、影響を受けるアプリ、すべてのサイトか特定のサイトか、ローカルネットワークを変えると改善するか、同じサブスクリプションを使う別のデバイスは正常かを先に記録しましょう。こうした情報だけでも原因の範囲を大きく絞れます。

通信経路は連続した複数の層として考えると分かりやすくなります。ローカル接続ネットワークは、まずデバイスが通常のサイトへアクセスできる状態を作ります。システム時刻と証明書環境は暗号化接続の確立を支え、クライアントはサブスクリプションを読み込んでローカルプロキシを起動します。システムプロキシまたは仮想ネットワークインターフェースが通信を引き継ぎ、振り分けルールがローカルネットワークとリモート回線のどちらを使うか決め、DNSがドメイン名をアドレスに変換します。その後、リモート回線が接続先サービスと通信します。どこか一層でも想定どおり動かなければ、上位層では「開けない」としか見えません。診断はデバイスに近い側から始め、最初からリモート回線を何度も変えないことが重要です。

再現できる基準を作る

操作を始める前に、ダウンロード、クラウド同期、システム更新など、ネットワークを継続的に使う処理を停止します。使用中のクライアント、システム、接続モード、回線名、ローカルネットワークの種類を記録してください。次に、通常のサイト、影響を受けるサービス、ブラウザーキャッシュに依存しないテスト方法を一つずつ選んで確認します。条件は一度に一つだけ変更します。たとえば回線だけを変え、プロトコルと振り分けは同時に変えません。ブラウザー拡張機能だけを無効にし、システム設定をすべて消去することもしません。変更後に同じテストを繰り返せば、改善の原因を判断できます。

VPNVBはWindows、macOS、iOS、Android、Linuxに対応しています。プラットフォームによって権限の仕組みは異なります。デスクトップでは、システムプロキシ、仮想ネットワークインターフェース、ファイアウォールの関係を確認します。モバイルでは、省電力設定、バックグラウンド動作の権限、ネットワーク切り替えも重要です。診断の原則は共通ですが、ボタン名や権限画面は異なる場合があります。現在のクライアントで同じ名称の項目が見つからないときは、完全一致のスイッチを探すのではなく、「ルールモード」「ルールベースのルーティング」「自動振り分け」など、同等の機能を探してください。

確認できる結果 優先して確認する層 今はしないこと
クライアントを起動できない システム権限、設定ファイル、プロセスの競合 リモート回線を次々に切り替える
接続済みなのにドメインを開けない システムプロキシ、振り分け、DNS いきなりOSを再インストールする
特定のアプリだけ異常 アプリのプロキシ対応と振り分けルール 家庭内ネットワーク全体を変更する
すべてのデバイスで同時に異常 ローカル接続ネットワーク、サブスクリプションの状態、回線 特定のブラウザーだけキャッシュを消去する

診断記録を残す

有効な記録に複雑なツールは必要ありません。「時刻・環境・変更・結果」の4列で十分です。たとえば、家庭のネットワーク、ルールモード、回線Aではサイトは開くが特定のアプリがタイムアウトし、グローバルモードにすると復旧し、ルールモードに戻すと再び異常になった、と記録します。この結果から、問題は回線そのものではなく振り分けルールだと分かります。ローカルネットワークを変えてすぐ復旧した場合は、元のネットワークのDNS、ルーティング、アクセス制御を優先して確認します。記録を残せば初期設定を忘れずに済み、接続が戻った後にどの変更が効いたのかも確認できます。

初回のサブスクリプション取り込みがまだなら、クイックスタートの手順に戻ってください。接続はできるものの、「ノード、プロトコル、ルールモード」の意味が分からない場合は、初心者向け用語早見表をご覧ください。基本用語と障害の症状を分けて確認するほうが、設定画面で一つずつ試すより早く解決できます。

Connection

完全に接続できないときの確認方法

クライアントの問題と回線の問題を切り分ける

「まったく接続できない」には、少なくともいくつかの状態があります。クライアント自体が開かない、開くがサブスクリプションが空、回線を選べるが接続直後に失敗する、接続処理が長時間止まる、接続成功と表示された直後に切断される、といったケースです。最初のケースはデバイス側、2つ目はサブスクリプションの取得、後者は回線、システム時刻、ローカルネットワーク、プロトコルの互換性を比較する必要があります。これらを混同すると、起動権限やプロセス競合を解決しないまま、サブスクリプション更新だけを繰り返すことになります。

まずクライアントを終了し、バックグラウンドに同種のプロセスが残っていないことを確認してから再起動します。デスクトップでは、プロキシクライアントがローカル待受ポートや仮想ネットワークインターフェースを作成することがあります。別のネットワークツールが同じリソースを使っていると、新しいクライアントは起動したように見えても接続を引き継げません。システムプロキシ、仮想ネットワーク、通信フィルタリングを担うツールを複数同時に動かさないでください。セキュリティソフト、ファイアウォール、企業のデバイス管理ポリシーがネットワーク拡張を制限する場合もあるため、リモート回線が使えないと決めつけず、システムの通知やイベント記録を確認します。

システム時刻と基本ネットワークを確認する

暗号化接続では、デバイスの時刻を使って証明書の有効期間を判断します。日付、タイムゾーン、時刻同期に大きなずれがあると、キャッシュ済みのページは表示できても、新しい安全な接続に失敗することがあります。日付、時刻、タイムゾーンをシステムの自動管理に戻し、クライアントを再起動してください。次にプロキシを完全に無効にし、現在のローカルネットワークから通常のサイトを開けるか確認します。プロキシなしでもネットワークに接続できないなら、ルーター、無線ネットワーク、LANケーブル、認証、ローカル通信事業者の接続を先に直す必要があります。リモート回線でこの基礎接続を代替することはできません。

家庭のネットワークでは失敗し、別の接続では正常なら、問題は元のローカルネットワークに絞られます。まずルーターを再起動してネットワークアドレスを再取得し、手動DNS、固定ゲートウェイ、特殊なフィルタリングルールを確認します。すべてのローカルネットワークで失敗する一方、同じサブスクリプションを別のデバイスで使えるなら、現在のデバイスのクライアント状態、権限、設定破損が疑われます。反対に、同じネットワークに接続したすべてのデバイスで接続できない場合は、サブスクリプションの状態と回線選択を確認するのが適切です。

最小構成で検証する

トラブル対応では、大量のカスタムルール、スクリプト、多段プロキシを残したままにしないでください。まず現在の設定をバックアップし、パネルで提供されている最新のサブスクリプションを取り込み、標準的な回線とクライアントの推奨デフォルトモードを使います。最小構成で接続できるなら、サービスと基本ネットワークは利用可能で、問題は元の設定にあるルール、ポート、チェーンプロキシ、手動上書き項目です。その後はカスタム内容を一つずつ戻し、項目ごとにテストしてください。

# 基本的な接続確認の例
# まずプロキシを無効にし、ローカルネットワークで通常のドメインを解決・閲覧できることを確認
nslookup example.com

# 次にシステムから公開テストドメインへ到達できるか確認
ping example.com

コマンドの結果は環境と合わせて解釈してください。一部のネットワークや接続先は ping を無視するため、応答がないだけでネットワーク断と判断することはできません。ただし、ドメイン解決に失敗する、デフォルトゲートウェイに到達できない、すべての HTTPS リクエストが失敗する場合は、基本ネットワークがまだ確立していない可能性が高いです。コマンドラインは補助的な証拠であり、クライアントログやネットワークを変えた比較の代わりにはなりません。

回線を切り替える正しい手順

ローカルネットワーク、時刻、クライアント、サブスクリプションが正常だと確認してから、地域または種類の異なる回線を選びます。VPNVBは100か国以上 / 210以上の回線に対応しており、地域と回線の種類は回線一覧で確認できます。切り替えるときは古い接続を手動で切断し、クライアントが状態を整理するまで待ってから新しい回線に接続します。複数の回線を素早く連続してクリックすると、古いセッション、DNSキャッシュ、新しい回線の状態が混ざり、判断しにくくなります。

特定の回線だけ失敗し、他の回線が正常なら、使える回線で作業を続け、失敗した回線名、失敗した段階、発生時刻を記録します。1台のデバイスですべての回線が失敗し、他のデバイスは正常なら、デバイスの権限とクライアント設定を再確認します。すべてのデバイスと異なるローカルネットワークで失敗し、サブスクリプションも更新済みなら、問い合わせを送ります。問い合わせには「接続できない」だけでなく、クライアントが起動するか、サブスクリプションを更新できるか、接続がどの段階で止まるか、試したネットワークと回線、再現可能なエラーテキストを記載してください。

Traffic path

接続できるのにサイトを開けない

「接続済み」は経路の一部が確立したことを示すだけ

クライアントに接続済みと表示される場合、通常はローカルクライアントとリモート回線のセッションが確立したことを意味します。ただし、通信が実際にそのセッションへ入るかどうかは、システムプロキシ、仮想ネットワークインターフェース、アプリ固有のプロキシ設定、振り分けルールにも左右されます。まず「すべてのリクエストが通らない」のか「ドメインへのリクエストだけ通らない」のかを分けます。以前開いたことのない通常のサイトを試し、ブラウザーと他のアプリを比較してください。ブラウザーだけ正常ならアプリの振り分けを、ドメインを使うアクセスがすべて失敗するならDNSを、どのアクセスも失敗するならクライアントがシステム通信を引き継いでいるかを確認します。

デスクトップクライアントの一般的なシステムプロキシモードは、システムプロキシ設定に従うアプリだけに影響します。コマンドラインツール、ゲーム、ストアクライアント、独自のネットワークスタックを使うプログラムは、自動的にこの設定を使わないことがあります。仮想ネットワークモードはより広い通信を引き継げますが、追加のシステム権限が必要で、他のネットワーク拡張と競合する場合もあります。現在のモードを確認し、「システムプロキシが有効」だからといって、すべてのアプリが回線を通ると判断しないでください。

プロキシによる通信の引き継ぎと残存設定を確認する

クライアントを切断した後、システムプロキシが自動的に元へ戻っているか確認します。クライアントが異常終了すると、システムにローカルポートを指すプロキシアドレスが残り、対応するプロセスだけ停止していることがあります。この場合、システムプロキシに従うアプリはすべてサイトを開けません。クライアントを再起動して正常に切断すれば戻ることが多く、システムのネットワーク設定で自動プロキシスクリプト、HTTPプロキシ、安全なプロキシが存在しないローカル待受先を指していないか確認することもできます。不明なプロキシアドレスをシステム設定へ入力しないでください。通常はクライアントが管理します。

クライアント内蔵の接続テストは成功するのにブラウザーが失敗する場合は、ブラウザーを完全に終了して再起動します。ブラウザーが既存の接続を再利用したり、独自の安全なDNS、ネットワーク拡張、プロキシ拡張を有効にしたりすることがあります。通信経路を変更する拡張機能を一時的に無効にし、ブラウザーのDNS設定をシステムに従わせて比較します。プライベートウィンドウだけ正常なら、拡張機能、キャッシュ、サイトデータを確認します。すべてのブラウザーで失敗するなら、システムプロキシとDNSに戻り、各ブラウザーのキャッシュを個別に削除する必要はありません。

DNS異常かどうかを判断する

DNS異常では、クライアントは正常に見えるのに一部の既存ページだけ更新でき、新しいドメインが長時間応答しないことがあります。同じドメインでもアプリによって結果が違う、ネットワークを切り替えると一時的に復旧する、エラーに名前解決と明記される、といった症状もあります。DNSはドメイン名をネットワークアドレスへ変換しますが、解決処理はシステム、ローカルルーター、クライアント、リモート回線のいずれかで行われます。複数の層を同時に設定すると結果が一致しにくくなるため、診断時は上書き項目を減らし、クライアントとシステムが明確な一つの経路を使うようにします。

# Windows
nslookup example.com
ipconfig /flushdns

# macOS
dscacheutil -flushcache

# Linux（systemd-resolved を使用する環境）
resolvectl query example.com
resolvectl flush-caches

まず問い合わせを実行し、キャッシュを消すかどうかは結果を見て判断します。問い合わせがタイムアウトするなら、名前解決経路が適時に応答していません。アドレスが返ってもサイトを開けない場合は、ルーティング、証明書、接続先サービス、ブラウザーに問題がある可能性があります。キャッシュ削除で消えるのは古い解決結果だけで、上流DNSの誤設定は直りません。キャッシュ削除を繰り返せば解決するとは考えないでください。DNSを手動設定している場合は元の値を記録してから自動取得へ戻して比較します。クライアントに「回線のDNSを使用」などの機能があれば、システム権限が正常であることを確認してから試します。

IPv4、IPv6、振り分け結果を確認する

ドメインは異なるアドレスファミリーのアドレスを同時に返すことがあり、現在の回線やローカルネットワークによって処理経路が異なります。一部のサイトはすぐ開くのに、別のサイトは長時間待って失敗することがあります。特定のアドレスファミリーを恒久的に無効にするのではなく、クライアントが統一して通信を引き継げるか、DNSの応答が接続モードと一致しているか、同じサービスのドメインが異なる出口へ振り分けられていないかを確認します。一時的な変更で復旧した場合は、変更前後の解決結果を記録してから長期設定を決めてください。

ルールモードでは、一つのページが複数ドメインのスクリプト、画像、API、ログインリソースを読み込むことがあります。メインページのドメインがリモート回線を通っていても、関連ドメインがすべて同じ経路を通るとは限りません。ページに文字しか表示されない、ボタンが反応しない、ログインが繰り返される場合は、クライアントの接続記録を確認し、失敗したリソースがどのルールに一致したかを調べます。短時間だけグローバルモードに切り替えて比較することもできます。グローバルモードでは正常でルールモードでは異常なら、原因は回線速度ではなくルールの適用範囲です。確認後はルールモードに戻し、ルールを補充または更新します。

ストリーミングの画質や特定サイトのリソース読み込みに問題が集中する場合は、ビットレートと帯域幅の実測ガイドを参照してください。すべてのドメインを解決できず、異なるネットワークとデバイスでも同じ結果になる場合は、問い合わせに問い合わせ結果、クライアントログ、影響を受けるドメインを添えます。企業や学校のネットワークだけで異常が出る場合は、ログイン認証や専用DNSが必要かどうかも記載してください。

Performance

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

「遅い」を観測できる指標に分ける

速度低下は一つの障害ではありません。ページの初回表示まで時間がかかる場合は、遅延、DNS、接続の再利用が関係することがあります。ダウンロードの継続速度が低い場合は、帯域幅や混雑の問題に近いでしょう。動画の画質が頻繁に変わる場合は、ビットレートの調整や短時間の変動も影響します。ゲーム操作の反応が遅い場合は、遅延、ジッター、パケットロスを同時に確認します。症状ごとに適したテストが必要です。1回の速度テストだけでは、ページは遅いのにダウンロードは正常な理由も、回線が継続利用で安定しているかも判断できません。

基準を作るときは、同じデバイスと同じローカルネットワークで、まずプロキシを無効にして通常のアクセスをテストします。その後、地理的に妥当な回線へ接続し、同じ作業を繰り返します。無線中継、リモートデスクトップ、クラウド同期、システム更新は同時に使わないでください。テスト対象も固定し、同じダウンロード元、同じ動画、同じページを使います。ローカルネットワーク自体が不安定なら、リモート回線の比較結果は基礎的なノイズに埋もれます。

回線の距離、種類、混雑

物理的な距離は往復経路を長くしますが、距離だけが条件ではありません。経路の迂回、ネットワーク間接続、無線干渉、ローカル通信事業者の出口混雑によって、近い回線より別の経路のほうが安定することもあります。回線を選ぶときは用途と地域で候補を絞り、異なる回線タイプを比較してください。国名だけで判断しないことが重要です。VPNVBは100か国以上 / 210以上の回線に対応しており、地域と種類は回線一覧で確認できます。

混雑時間帯の遅延は、共有回線の一部が混雑したときによく起こります。時間との関連性が判断のポイントです。日中は安定しているのに、決まった時間帯だけ大きく低下し、別のローカルネットワークや回線に変えると明確に変化する場合です。家庭の無線ネットワークだけに影響するなら、信号、周波数帯の干渉、ルーターの負荷を先に確認します。プロキシを無効にしても同じように低下するならボトルネックはローカル接続にあります。通常のネットワークが正常で特定の回線だけ低下するなら、同じ地域の別回線と比較するほうが有効です。

症状 考えられる原因 推奨する比較
ページの読み込み開始が遅いが、その後は正常 DNS、遅延、接続確立 解決経路を変えてブラウザーを再起動
ダウンロードの継続速度が低い 帯域幅、混雑、ダウンロード元の制限 ダウンロード元を固定して回線を切り替える
動画の画質が頻繁に変わる 短時間の変動、ビットレートの調整 1回の速度テストではなく継続再生を確認
操作の反応が遅く、ときどきカクつく 遅延、ジッター、パケットロス 有線と無線ネットワークを比較

デバイスとアプリ側の制限を除外する

デバイスの省電力モードは、バックグラウンド通信や処理性能を制限することがあります。ブラウザーの大量のタブ、暗号化スキャン、リアルタイム同期、ディスク使用量もダウンロードや展開に影響します。ルーターでプロキシを動かしている場合は、現在の暗号化通信を処理できる性能があるかも確認してください。簡単な判断方法は、同じネットワークで別のデバイスを使い、同じ回線へ接続することです。別のデバイスが明らかに正常なら元のデバイスを優先して確認し、すべてのデバイスで同じならルーター、ローカルネットワーク、回線を確認します。

アプリのサーバーが、単一接続、アカウントの地域、特定のコンテンツ元に制限を設けている可能性もあります。特定のダウンロードサイトだけ遅い場合、回線全体の問題とは限りません。異なる接続元で相互に確認し、ブラウザー、クライアントアプリ、コマンドラインのリクエストを比較してください。AIツールでは、最大速度より長時間接続の安定性が重要な場合があります。この用途はAI画像生成と長時間接続の要件をご覧ください。ゲームについては遅延、ジッター、パケットロスの違いを参照し、帯域幅の数値だけで判断しないようにしましょう。

混雑時間帯の確認順序

まずプロキシを無効にしたローカルネットワークが正常か確認します。次に同じ地域の別回線へ切り替え、その後に近隣地域の回線を試します。接続モードを変えるのは最後です。切り替えるたびにテスト条件をそろえ、接続の再確立に十分な時間を与えてください。短時間に速度テストを繰り返すと回線を消費し、テスト先の制限を受けることもあります。動画では、一度の最大値を追うより実際の再生が安定して続くかを確認するほうが重要です。

速度の問題がプランの容量に近づいたときだけ起こる場合は、パネルへログインして現在の周期の使用量を確認します。月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中でのアップグレード差額は残り日数に応じて計算されます。データパックは使い切るまで有効で、期限はありません。プランを見直す場合はプランの詳細を確認してください。サブスクリプション更新を繰り返して容量の問題を解決しようとしてはいけません。更新で同期されるのは設定とアカウント状態であり、使用済み通信量は変わらないためです。

Stability

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

セッションの中断かネットワーク切り替えかを判断する

切断には、クライアントの状態が変わる、アプリの接続がリセットされる、サイトが一時的に途切れて復旧する、無線ネットワークから別の接続へ切り替えた際に回線が再確立される、といった症状があります。まず、切断時にローカルネットワークのアイコンも変化したかを記録します。通常のネットワークも同時に切れるなら、無線信号、ルーター、LANケーブル、接続認証を確認します。ローカルネットワークが常に正常でクライアントのセッションだけが再接続するなら、回線、システムのスリープ、バックグラウンド権限、ネットワーク拡張の競合を確認してください。

アプリのログインが1回失敗しただけで、回線全体が切断されたと判断しないでください。接続先サービスによっては、出口の変更、セッションの期限切れ、アプリ固有の再接続方針によって再ログインが必要になります。継続的なリクエストとクライアントの状態を同時に観察します。他のサイトやアプリが正常なら、問題は特定サービスに限定されます。プロキシを通るすべての接続が同時に切れ、通常のネットワークは正常なら、クライアントのセッションまたは回線の問題に近いでしょう。

デスクトップのスリープとネットワーク変化

PCを閉じる、スリープする、無線ネットワークを切り替える、LANケーブルを抜き差しする、テザリングを開始・停止する、といった操作の後は、既存の接続が依存するローカルアドレスやデフォルトルートが変わっている可能性があります。自動的に再構築するクライアントもあれば、手動切断後の再接続が必要なものもあります。復帰するたびに「接続済みだがアクセスできない」と表示される場合は、まず手動で切断し、システムのネットワーク接続が完了するまで待ってから再接続します。システムが有効なネットワークを取得する前に、接続ボタンを連続して押さないでください。

頻繁な切断は、複数のネットワークツールがシステムプロキシや仮想インターフェースを取り合うことでも起こります。企業ネットワーククライアント、通信フィルター、パケットキャプチャー、ペアレンタルコントロール、他のプロキシプログラムを同時に動かしていないか確認してください。診断中は通信を引き継ぐクライアントを一つだけ残します。特定のツールを終了すると復旧した場合は、すべての保護機能を恒久的に無効にするのではなく、両方を併用できるか確認します。

モバイルのバックグラウンド権限

モバイルOSはバッテリーを節約するため、長時間フォアグラウンドにないアプリを制限します。ネットワーク高速化クライアントは継続して動作するシステムネットワーク拡張に依存するため、省電力モード、バックグラウンド動作の制限、自動クリーンアップ、メーカー独自のバッテリー設定がプロセスを停止または凍結することがあります。クライアントがネットワーク接続に必要なシステム権限を持ち、必要なバックグラウンド動作を許可されているか確認します。システムの制限対象からクライアントを外した後、画面をロックしてしばらく待ち、デバイスを起こして確認してください。フォアグラウンドでの短時間のテストだけでは不十分です。

「アプリの画面が終了させられた」場合と「システムネットワーク拡張が停止した」場合も分けて考えます。クライアント画面が再読み込みされても、ステータスバーのネットワーク接続は維持されていることがあります。逆に、画面には古い状態が表示されていても、実際のセッションが終了している場合があります。実際のアクセス結果とシステムのネットワーク表示を基準にしてください。システムに常時接続やオンデマンド接続の機能がある場合は、現在の設定が安定していることを確認してから有効にします。設定を誤ると自動再接続が繰り返され、通常のネットワークにも影響します。

状況 重点確認項目 確認方法
画面ロック後に切断 バックグラウンド動作と省電力制限 権限を調整してロック後に再確認
無線ネットワーク切り替え後に切断 デフォルトルートと自動再接続 接続完了を待って手動で再接続
PCを閉じて復帰するとネットワークがない 古いセッションとシステムプロキシの残存 正常に切断してから再接続
特定アプリだけログアウトされる アプリのセッションと出口の変化 他のアプリも同時に中断するか比較

回線と通信方式を比較する

切断が画面ロック、スリープ、ネットワーク切り替えと無関係で、特定の回線でだけ起こるなら、同じ地域の別回線と比較します。すべての回線が同じローカルネットワークで不安定なのに、別のネットワークでは復旧する場合、元のネットワークが長時間接続、特定の通信方式、アイドルセッションを処理する方法に原因がある可能性があります。2種類のネットワークの比較記録を残し、「たまに切れる」だけで済ませないようにしましょう。

再接続の頻度を過度に高く設定しないでください。短時間のネットワーク揺らぎに対して複数のセッションをすぐ作り直すと、復旧が遅くなることがあります。ハートビート、タイムアウト、オンデマンド接続の役割を理解している場合を除き、クライアントのデフォルト方針を優先します。手動設定のタイムアウト、多段プロキシ、複雑なスクリプトも、最小構成のテストでは一時的に外してください。

モバイルで特定のアプリをバックグラウンドへ移したときだけ切断され、他のアプリが正常なら、そのアプリ自身のバックグラウンド通信権限を確認します。回線を通るすべてのアプリが同時に停止するなら、高速化クライアントとシステムネットワーク拡張を確認します。デバイスが発熱している、ストレージの空きが少ない、システムがバックグラウンドを継続的に終了させている場合は、まずデバイスの基本状態を整えます。再現が続くなら、デバイスのシステム、クライアント、回線、フォアグラウンドとバックグラウンドの切り替え操作、再現手順を記載してください。サポートが同じ手順で確認できます。

Subscription

サブスクリプション更新の失敗と設定異常

サブスクリプションURL、サブスクリプション内容、回線接続は別のもの

サブスクリプションURLはクライアントが設定を取得する入口で、サブスクリプション内容はダウンロード後に保存される回線とルールの情報です。回線接続は、その設定から一つを選んでセッションを確立する処理です。更新に失敗しても、保存済みの回線がすべて直ちに使えなくなるわけではありません。特定の回線に接続できなくても、サブスクリプションURL自体が間違っているとは限りません。まずクライアントが「サブスクリプションのダウンロード」段階でエラーになったのか、更新後に回線だけが使えないのかを確認します。

サブスクリプションの仕組みを初めて使う場合は、サブスクリプションURLの取得・インポート・更新ガイドをご覧ください。VPNVBはメールアドレスなしで登録でき、ユーザー名とパスワードだけで登録できます。パネルへログインして現在のサブスクリプションを取得し、チャット履歴、スクリーンショットからの読み取り、手作業で作った古いURLは使わないでください。サブスクリプションURLはアカウント設定への入口なので安全に保管し、漏えいが疑われる場合はパネルで利用できる機能から更新し、古いURLを使い続けないようにします。

まず取得経路を確認する

サブスクリプションを更新するとき、クライアントはサブスクリプションURLへアクセスする必要があります。システムプロキシがすでに無効なローカルポートを指している場合や、未接続の回線を経由しなければ更新できない設定になっている場合、接続には新しい設定が必要なのに、新しい設定の取得には先に接続が必要という循環が起こります。まず無効なプロキシを停止するか、クライアントの直接更新オプションを使います。更新経路を選べるクライアントでは、ローカルネットワークからパネルへアクセスできることを確認してから試してください。

パネルへのログイン自体に失敗する場合は、ユーザー名とパスワードが正しいか確認し、ブラウザーで他のページを開けるかを調べます。サブスクリプションURLを公開の検査サイトへ貼り付けないでください。パネルにはログインできるのにクライアントのダウンロードだけ失敗する場合は、クライアントから該当サブスクリプションを削除して現在のURLを再インポートできます。ただし、削除前にカスタムルールとローカル上書きを記録してください。サブスクリプションに関連する手動設定も同時に消える可能性があります。

形式と解析エラーを確認する

クライアントによって対応するサブスクリプション形式とフィールドの範囲は異なります。一つのクライアントで読み込めても、別のクライアントが同じ内容を認識できるとは限りません。よくある解析エラーには、Webページを設定として扱っている、コピー時にURLの一部が欠けている、クライアントが返却形式に対応していない、テキストエンコードに異常がある、ローカル設定に競合するフィールドがある、といったものがあります。対象プラットフォーム向けにパネルが提供する取得方法を優先してください。クライアントのダウンロード先はユーザーパネルへ統一し、静的インストールパッケージの直リンクは使いません。

# ドキュメント内の安全な例。URLの構造確認専用
https://example.com/sub?token=YOUR_TOKEN

# 実際のサブスクリプションURLをスクリーンショット、公開ログ、共有設定に記載しない
# 更新に失敗したらエラーの種類を記録し、完全な token は送らない

エラー表示がWebページのタイトル、ログインページ、通常のHTMLになっている場合、クライアントは想定したサブスクリプション内容を取得できていません。URLの期限切れ、コピーの欠落、リダイレクトの可能性があります。ダウンロードはできるのに設定が空なら、クライアントログの解析メッセージを確認します。エラーを消すために、実際のサブスクリプションをオンラインで安易に変換しないでください。第三者の変換処理に完全なURLが渡ることになります。パネルから再取得するか、問い合わせで対象クライアントの取り込み方法を確認します。

更新後に回線が消える、または重複する

回線が消える原因には、サブスクリプション項目が上書きされた、フィルターで非表示になった、グループが展開されていない、古いサブスクリプションを残したまま別の項目を追加した、などがあります。まずサブスクリプション一覧に似た名前のソースが複数ないか確認し、現在どの設定を使っているかを確認します。回線の重複は、サービス側が同じ回線を複数提供しているのではなく、同じサブスクリプションを重複してインポートしたことが原因である場合が多いです。有効な項目を一つ残し、更新後にグループを選び直してください。

カスタムルールが古い回線名を参照している場合、更新後の名称やグループ変更によってルールが対象を見つけられなくなることがあります。クライアントがデフォルト回線へ戻す場合もあれば、直接エラーになる場合もあります。ルールの対象がまだ存在するか確認し、多数のルールを単一回線に結びつけるのではなく、安定したグループを優先してください。更新前にローカルのカスタム内容をエクスポートし、更新後に一項目ずつ戻すと設定の混乱を防げます。

アカウント状態と通信量の周期

サブスクリプションの更新はアカウント状態の影響も受けます。パネルへログインし、プランが利用可能か、通信量の使用状況を確認してください。月額プランは ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GB。通信量は開通日を基準に毎月リセットされ、途中のアップグレード差額は残り日数に応じて計算されます。データパックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効で期限はありません。プランを比較する場合はプランページへ進み、クライアントのエラー表示から価格や周期を推測しないでください。

パネルの状態が正常で、現在のサブスクリプションを再インポートしても解析できない場合は、クライアント名、システムプラットフォーム、更新方法、エラーテキスト、発生時刻を記載して問い合わせます。ログに完全なサブスクリプションURLが含まれる場合は、先にトークン部分を隠してください。サポートに必要なのはエラーの種類と応答の状態であり、アカウント認証情報ではありません。複数のクライアントのうち一つだけ失敗する場合は、成功するクライアントとの差異を明記します。形式の互換性かアカウント側の問題かを判断しやすくなります。

Routing rules

特定のアプリがプロキシを通らない、振り分けが異常

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

アプリによってネットワークの使い方は異なります。ブラウザーは通常システムプロキシに従いますが、独自の安全なDNSを使うこともあります。コマンドラインプログラムは環境変数を読み取り、ゲームや一部のデスクトップアプリはシステムプロキシを通らないネットワークインターフェースを使います。モバイルアプリはシステムネットワーク拡張がまとめて引き継ぎますが、アプリ単位のルールの影響を受けることがあります。したがって、「ブラウザーで開ける」ことはブラウザーの経路が有効だと示すだけで、システム内のすべての通信が同じ出口を通る証拠にはなりません。

まずクライアントがシステムプロキシモードか仮想ネットワークモードかを確認します。システムプロキシモードでは、影響を受けるアプリがシステムプロキシに対応しているか、アプリ内で個別設定が必要かを確認します。仮想ネットワークモードでは、システム権限がそろっているか、他のネットワーク拡張と競合していないか、クライアントがそのアプリを除外していないかを確認してください。対応するプロトコルとアドレスがクライアントのドキュメントに明記されていない限り、アプリへローカルポートを安易に入力しないでください。

グローバルモードで短時間比較する

ルールモードで異常が出る場合は、短時間だけグローバルモードへ切り替えて検証できます。グローバルモードではすぐ復旧し、ルールモードでは失敗が続くなら、回線とアプリの基本接続は正常で、問題はルールの適用、ドメインセット、アドレス範囲にある可能性が高いです。検証後はルールモードに戻して接続記録を確認します。誤ったルールを隠すためにグローバルモードを長期使用するのは避けてください。本来ローカルネットワークを使う通信まで経路が変わってしまいます。

グローバルモードでも失敗する場合は、別の回線へ切り替えてアプリを再起動します。アプリが古い接続を保持していると、クライアントが回線を切り替えても、以前の経路を使い続けたり、無効な状態になったりすることがあります。アプリを完全に終了し、バックグラウンドプロセスが終わったことを確認してから開き直してください。モバイルではタスク切り替え画面からアプリを一度終了して再確認します。アカウントのログインだけが失敗し、他の機能が正常なら、サービス地域、アカウントのセキュリティ確認、キャッシュされたセッションを確認し、振り分け表全体を変更しないでください。

接続記録からルールを特定する

現代のアプリは通常、一つのドメインだけにアクセスするわけではありません。ログイン、画像、API、プッシュ通知、WebSocket、コンテンツ配信が異なるホストから提供されることがあります。ルールがメインドメインだけを対象にしていると、トップページは開くのにログインボタンが反応しない、メッセージが更新されない、画像が表示されないといった症状が出ます。クライアントの接続記録を開き、問題を再現しながら新しいリクエストを確認します。ドメインまたはアドレス、適用されたルール、選択されたグループ、最終的な回線を確認し、一覧中のすべてのドメインを同じルールへ追加するのではなく、失敗したリクエストを重点的に見ます。

ルールを変更するときは、狭い範囲から広い範囲へ進めます。まず明確な完全ドメインを追加し、次に同じサービスのサブドメイン範囲を検討します。クライアントに既存のルールセットがあれば優先して使い、広すぎるワイルドカードで無関係なサイトの経路まで変えないでください。変更ごとにアプリの古いセッションを消去して再テストします。ルールがサブスクリプション由来なら先に更新し、ローカル上書きを使う場合は適用順を記録します。クライアントによってローカルルールの優先順位が異なるためです。

アプリの種類 一般的な通信の引き継ぎ方法 重点確認項目
ブラウザー システムプロキシまたはブラウザー独自の設定 拡張機能、安全なDNS、古い接続
コマンドラインツール 環境変数または明示的なプロキシ引数 変数の適用範囲とプロトコルの種類
デスクトップ独立アプリ システムプロキシ、アプリ内プロキシ、仮想ネットワーク システムプロキシを迂回していないか
モバイルアプリ システムネットワーク拡張 アプリ単位のルールとバックグラウンド権限

コマンドラインと環境変数を確認する

開発ツールには、以前設定したプロキシ環境変数が残っていることがあります。クライアントがポートを変更したり終了したりした後も、コマンドラインが古いアドレスへ接続しようとすると、ブラウザーは正常なのにパッケージマネージャーだけ失敗します。ターミナルで現在の環境を確認できますが、認証情報を含む完全な出力を公開して送らないでください。以下は構造の例であり、ポートはクライアントに実際に表示される値を使います。固定値をそのまま入力しないでください。

# 現在のターミナルにプロキシ変数が設定されているか確認
env | grep -i proxy

# 現在のターミナルセッションから一般的なプロキシ変数を一時的に削除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

削除後に影響を受けるコマンドを再実行すると、問題が古い環境変数に由来するか判断できます。コマンドラインにプロキシが必要な場合は、クライアントが示すローカルアドレスと対応プロトコルを使い、作用範囲を理解した場所へ設定します。競合するHTTPとSOCKSの経路を同時に設定しないでください。企業の開発環境では、ツール自身の設定ファイルにプロキシが保存されていることもあるため、システム設定だけでなく個別に確認します。

AIツール、ストリーミング、長時間接続の場面

AIツールやリアルタイム共同作業アプリは、WebSocketや継続的なリクエストを使うことがあります。ページは開くのに生成処理が止まる場合、関連ドメインが同じルールで処理されていないか、ネットワーク切り替え後に長時間接続が再構築されていない可能性があります。まずアプリを再起動し、グローバルモードとルールモードを比較して、失敗した接続を確認します。MidjourneyとDiscordの具体的な要件は接続要件の実測比較をご覧ください。

ストリーミングでは、出口の地域、アカウントの地域、キャッシュ、コンテンツの利用許諾も関係します。トップページを開けても、コンテンツを再生できるとは限りません。画質の変化も振り分けだけが原因とは限りません。視聴サービス利用ガイドと対応回線の情報を確認し、目的に合う回線を選んでください。複数のデバイス、ネットワーク、対応回線で同じアプリが同じように失敗する場合は、アプリ名、失敗した手順、接続記録でのルール適用、エラー表示を記載します。「特定アプリが使えない」だけでは不十分です。

Account & support

デバイス利用、アカウント状態、問い合わせ送信

「デバイス数の上限」は表示元を先に確認する

VPNVBのデバイス利用は台数無制限です。クライアントやアプリに「デバイス数の上限」と表示されても、本サービスのプラン制限だとすぐに判断しないでください。まず、表示元がOSアカウント、アプリストア、接続先サービスのアカウント、企業のデバイス管理、高速化クライアントのどれかを確認します。同じ「デバイス」でも意味はまったく異なります。表示を切り取るときはウィンドウのタイトルまたはアプリ名を含め、ユーザー名、サブスクリプションURL、その他の機密情報を隠してください。

同じアカウントの設定を複数のデバイスへ取り込む場合は、現在のパネルからサブスクリプションを取得し、設定を公開転送しないようにします。台数無制限でも、アカウント設定を関係のない人と共有してよいわけではありません。出所不明の古い設定が多いと、診断が難しくなります。デバイスごとに更新時刻、ローカルルール、回線グループが異なる可能性があるためです。各デバイスのクライアント名と更新時刻を分かりやすく記録し、問題が起きたら現在のサブスクリプションを使っているか先に確認してください。

アカウント、プラン、支払い状態

接続異常がアカウント状態に関係する場合、クライアントには簡略化されたエラーしか表示されないことがあります。パネルへログインし、プランの有効性、通信量の利用可否、注文の完了状況を確認してください。VPNVBはAlipay / WeChat Pay / USDTに対応しています。支払い処理中、注文キャンセル、プランの有効化は別の状態です。支払いページの結果だけで判断しないでください。注文ページと実際の支払い結果が一致しない場合は、注文識別子と決済チャネルの記録を保存し、パネルの問い合わせから確認します。同じ注文を何度も作成しないでください。

月額プランは ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GB。通信量は開通日を基準に毎月リセットされ、途中のアップグレード差額は残り日数に応じて計算されます。データパックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効で期限はありません。すべてのプランに30日間の理由を問わない返金が適用されます。具体的な選択とルールはプランページと返金ポリシーを確認してください。トラブル対応では現在のアカウント状態を確認するだけで、注文の問題を解決するためにクライアントを削除したりOSを再インストールしたりする必要はありません。

問い合わせ前に最小構成で再現する

サポートが対応できるのは、再現可能なサービス、アカウント、回線、設定の問題です。送信前に、障害を最小の状況へ絞り込みます。デバイス1台、クライアント1つ、ローカルネットワーク1種類、回線1本、明確な接続先を使います。プロキシを無効にすると正常か、別の回線で変化するか、サブスクリプションを更新できるかを説明してください。特定のアプリだけで起きる場合は、グローバルモードとルールモードの比較を追加します。モバイルのバックグラウンドだけで起きる場合は、画面ロック、ネットワーク切り替え、フォアグラウンド復帰の具体的な操作を記載します。

問い合わせにパスワード、完全なサブスクリプションURL、決済情報を送らないでください。ログを提供する場合は、トークン、ユーザー名、ローカルファイルパスに含まれる個人情報を確認して隠します。エラーテキストは要約ではなく、できるだけ原文をコピーしてください。スクリーンショットには前後関係を含めますが、関係のないアカウント情報は表示しないでください。ログが長い場合は、問題が起きた位置と実行した操作を示します。障害と無関係な起動履歴全体は必要ありません。

問い合わせに添える情報

  • 症状：まったく接続できない、接続後にサイトを開けない、速度異常、切断、サブスクリプション更新失敗、特定アプリの異常。
  • 実行環境：Windows、macOS、iOS、Android、Linux、およびクライアント名。
  • ローカルネットワーク：家庭、職場、その他の接続環境と、ネットワークを切り替えたときの比較結果。
  • 回線情報：選択した回線名と、別の回線へ切り替えたときの変化。
  • 再現手順：正常な状態から、どの操作を順に行うと問題が起きるか。
  • エラーの証拠：コピー可能なエラーテキスト、機密情報を隠したログまたはスクリーンショット。
  • 実施した操作：サブスクリプション更新、クライアント再起動、モード切り替え、DNSキャッシュ削除、再インポート後の結果。

すぐにサポートへ相談すべきケース

アカウントページと注文状態が明らかに一致しない、現在のサブスクリプションをパネルから取得できない、複数のデバイスと異なるネットワークで同じ回線エラーが起きる、安定して再現する問題でクライアントログがサーバー応答を示している、本ページの手順で比較しても原因を分類できない、といった場合は問い合わせに適しています。ユーザーパネルの問い合わせへ進み、上の一覧に沿って情報を整理してください。説明が具体的であるほど、実行可能な回答を一度で得やすくなります。

概念や一般的な設定を確認したいだけなら、まずヘルプセンターをご覧ください。初回設定が済んでいない場合は使い方ガイドへ戻ります。利用する地域や回線タイプを選ぶ場合は回線一覧を確認してください。アカウント、クライアント、回線、対象アプリの問題を分けて対応すると、異なるサポート窓口で同じ説明を繰り返さずに済みます。

復旧後の仕上げ

問題が解決したら、一時的に切り替えたグローバルモード、手動DNS、無効にしたセキュリティ設定、テスト用ルールを適切な状態へ戻します。重複したサブスクリプションを削除し、現在有効な設定を残してください。本当に効果があった変更を記録し、関係のない変更は元に戻します。回線の切り替えで解決した場合は、元の回線名と発生時間帯も残しておくと、同じ問題が起きたときにすぐ比較できます。一度復旧したからといって、一時設定をすべて残さないでください。

定期的にパネルからサブスクリプションを更新し、各デバイスで出所が明確で追跡できる設定を使います。新しい問題が起きたら、通常どおりの順序で確認してください。通常のネットワーク、クライアント起動、プロキシによる通信の引き継ぎ、DNS、振り分け、回線、アカウントの順です。この順序はすべての特殊ケースを網羅するためではなく、各段階で明確な証拠を得て、次に調べる範囲を小さくするために役立ちます。

無料で始める