接続トラブル診断ガイド

まったく接続できない：まず失敗している層を特定する

「接続を押しても反応しない」というのは表面的な症状にすぎません。クライアントが有効なサブスクリプションを取得できていない、選択した回線に一時的に到達できない、ローカルネットワーク自体がつながっていない、システムプロキシが切り替わっていない、古い設定が経路を占有しているなど、原因はさまざまです。診断中に回線、プロトコル、ルール、DNSを同時に変更しないでください。一度に1つだけ変えて再テストしましょう。そうしないと復旧しても、どの操作が効いたのか分からず、次回また手探りになります。

まずは最小限の切り分けを行う

最初にクライアントを終了して再起動し、画面に回線名が表示されることを確認します。空のリスト、期限切れの表示、サブスクリプション読み込みエラーではないことが重要です。次に現在の回線を切断して再接続し、どの段階で止まるかを見ます。クリック直後に未接続へ戻るなら、設定が完全かを確認します。接続中のまま長時間進まないなら、回線に到達できないか、ローカルネットワークで遮断されている可能性があります。接続済みと表示されるのにどのサイトにもアクセスできない場合は、次章でシステムプロキシとDNSを確認してください。何度もクリックを繰り返す必要はありません。

続いてローカルネットワークを確認します。接続を一時的に切断し、普段アクセスできるサイトを開いてください。通常のネットワークでも開けないなら、まずローカルネットワークを復旧します。クライアントは、オフラインのデバイスに突然経路を作るものではありません。通常のネットワークが使えるなら、別の地域の回線を選んでテストします。JVVPNは90+か国 / 200+回線をカバーしています。回線を切り替える目的は、闇雲に試すことではなく、特定の回線だけの問題か、クライアント環境全体の問題かを判断することです。特定の回線だけ失敗する場合は回線名を控え、別の回線で利用を続けます。すべての回線で失敗する場合は、クライアントとシステムの層を確認します。

互いに主導権を奪い合うアプリを整理する

システム上で複数のプロキシ、ネットワークフィルター、セキュリティツール、企業向け接続ツールを同時に動かすと、同じシステムプロキシ設定を奪い合うことがあります。クライアントは接続済みなのに、システムの通信がそこを通らない場合があります。また、別のツールを終了した後にプロキシアドレスだけが残り、存在しないローカル入口へサイトが転送され続けることもあります。診断時は、同種のアプリをウィンドウを閉じるだけでなく完全に終了し、タスクトレイやメニューバーにプロセスが残っていないことも確認してください。その後、システムのネットワーク設定で、現在のクライアントがプロキシを管理しているか確認します。出所の分からないアドレスを手動で残さないでください。

Windowsではシステムのプロキシ設定を開き、自動プロキシまたは手動プロキシが現在のクライアントの状態と同期しているか確認できます。macOSでは、現在使用中のネットワークサービスを確認してください。使っていないインターフェースを見ても判断できません。Linuxでは、グラフィカルデスクトップのプロキシ、ターミナルの環境変数、アプリ独自のプロキシという、互いに連携しない可能性のある3種類の設定に注意が必要です。ターミナルでプロキシの環境変数を設定したことがある場合は、現在のセッションを確認します：

env | grep -i proxy

古いアドレスが表示されたら、現在のターミナルで該当する変数を解除してから、テストするコマンドラインプログラムを再起動します。出所不明のプロキシ変数をグローバルな起動ファイルに書き込まないでください。すべてのターミナルに期限切れの搭乗券を配るようなものです。

再インストールよりリセットの順番が重要

それでもまったく接続できない場合は、「接続を切断、クライアントを終了、他のネットワークツールを閉じる、クライアントを再起動、サブスクリプションを更新、別の回線に切り替える、再接続」の順に実行します。クライアントが起動しない、設定ファイルが破損している、システム権限が明らかに不足している場合に限り、クライアントの再取得を検討してください。クライアントはユーザーパネルのダウンロード入口から取得し、出所不明のインストールファイルは使用しないでください。再インストール前には古いクライアントを終了し、新旧のプロセスが同時に動かないようにします。

ネットワーク環境を変えると接続できる場合、元のネットワークに経路、DNS、アクセス方針の違いがある可能性があります。すべてのネットワークで失敗する一方、同じアカウントが別のデバイスでは正常なら、問題は現在のデバイスに集中しています。複数のデバイスと複数の回線で同時に失敗する場合は、発生時刻、クライアントのプラットフォーム、回線名、エラー原文を記録し、問い合わせの章へ進んでください。「もう一度再起動してみる」より、この分岐による切り分けの方が有効で、髪も減りません。

接続できるのにサイトが開かない：プロキシとDNSを分けて確認する

クライアントに接続済みと表示されても、接続処理が完了したことしか分かりません。名前解決、システムプロキシ、アプリの通信が同じ経路を通っているとは限りません。サイトが開かないときは、「すべてのサイトで失敗」「ドメインだけ失敗」「特定のサイトだけ失敗」「ブラウザーだけ失敗し、他のアプリは正常」のどれかを切り分けます。見た目が似ていても、対処方法はまったく異なります。

ドメインと基本リクエストで障害を切り分ける

まず接続を切断して通常のネットワークが使えることを確認し、再接続して複数の異なるサイトを開きます。すべてのサイトを読み込めず、クライアントにも明確なエラーがない場合は、システムプロキシが有効か、ブラウザーに独自プロキシが設定されていないかを確認します。ブラウザー拡張機能がシステム設定を上書きすることもあるため、テスト時は関連する拡張機能を一時停止し、古い状態を大量に保持したセッションではなく通常のウィンドウを使ってください。特定のサイトだけ異常なら、そのサイトのキャッシュとログイン状態を消去し、別の回線で再テストします。1つのサイトのメンテナンスだけでクライアント全体を無効と判断しないでください。

コマンドラインでは、次の方法でドメインが名前解決できるか確認できます。例示のドメインは実際のサブスクリプションや認証情報に関係しません：

nslookup example.com

curl -I https://example.com

最初のコマンドで名前解決の結果が返らず、他の基本的なネットワーク操作は正常なら、問題はDNSに近いと考えられます。最初は正常で、次のコマンドが失敗する場合は、プロキシ経路、証明書の時刻、アプリ設定を確認します。システムの日付が大きくずれていると、証明書検証に失敗して暗号化接続が拒否されます。まずシステムの自動時刻合わせを有効にしてください。エラーメッセージを飛ばさないことも重要です。ブラウザーの「アドレスが見つかりません」「接続がリセットされました」「証明書が無効です」は、それぞれ異なる障害層を示します。

DNS異常でよくある症状

DNSはドメイン名をネットワークで認識できるアドレスに変換します。接続を切り替えた後も、システムが古いキャッシュを使い続けることがあります。クライアントが名前解決を引き継いでも、特定のアプリが独自の解決方法を使い続ける場合があります。家庭用ネットワーク機器が以前の結果をキャッシュしていることもあります。よくある症状は、ドメインが断続的に開けない、同じサイトの表示がブラウザーとアプリで異なる、回線を切り替えてもコンテンツの地域が変わらない、接続を切断しても古いアドレスを参照し続ける、といったものです。

対処時は、問題が起きているアプリを閉じ、クライアントを切断してから再接続し、アプリを開きます。それでも直らない場合は、OSのDNSキャッシュを消去して再試行します。Windowsでは、必要な権限を持つターミナルで次を実行できます：

ipconfig /flushdns

macOSとLinuxのキャッシュ機構はシステム環境によって異なるため、出所不明のガイドから高い権限を必要とする長いコマンドをコピーすることはおすすめしません。現在のネットワークへの再接続、システムの名前解決サービスの再起動、またはデバイスの再起動の方が安全です。クライアントにDNSの引き継ぎ設定がある場合は、現在のモードと一致させてください。クライアントの名前解決を有効にしたままブラウザーで別の名前解決を強制し、両者が訓練された編隊のように動くことを期待しないでください。

ルールモードがリクエストを誤った出口へ送っていないか確認する

ルールモードは、ドメインやアドレスに応じて通信を高速化回線へ送るか、ローカルネットワークへ送るかを決めます。ルールが古い、分類が不完全、ユーザー定義ルールの順番が誤っていると、サイトが誤って直接接続されることがあります。テストでは一時的にグローバルモードへ切り替えます。グローバルモードは正常でルールモードだけ失敗するなら、回線自体は使えており、問題はルールに集中しています。両方のモードで失敗するなら、DNS、システムプロキシ、回線の層に戻って確認します。

「VPNトラブル」などで検索する人が実際に遭遇しているのは、クライアント全体の停止ではなく、DNSとルール振り分けの不一致であることがあります。診断では、確認可能なリクエスト経路に注目してください。ドメインが解決されているか、どのルールに一致したか、最終的にどの出口から送信されたかを確認します。エラー画面と再現したドメインを保存しておけば、サポートがルールの問題を直接判断できます。「サイトが使えない」とだけ伝えるより、はるかに役立ちます。

速度低下と混雑時間帯の遅延：ボトルネックを先に確認する

速度が遅いからといって、回線が壊れているとは限りません。体感速度は、ローカル回線の品質、無線干渉、距離、接続先サービスの応答、ルールモード、デバイスの負荷、時間帯によって変わります。1回だけ、1回線だけ測定してピーク値だけを見ると、結論ではなく感情しか残りません。より正確な測定方法はVPNの速度測定を正確に行う方法で解説しています。本章では、トラブル発生時に素早く原因を絞り込みます。

切断時と接続後の変化をまず比較する

同じデバイス、同じネットワーク環境、近い時間帯で、接続を切断した状態と接続した状態のサイト表示、ファイル転送、ストリーミング再生をそれぞれ確認します。切断中も明らかに遅いなら、最初に疑うべきはローカルネットワークです。切断中は正常で、接続後にすべての回線が遅いなら、クライアントのモード、デバイスのリソース使用量、暗号化接続がローカルネットワークに与える影響を確認します。特定の回線だけ遅いなら、距離が近い、または経路に適した地域へ切り替えます。

テスト中は、同期、ダウンロード、アップロードを行っているアプリを終了します。クラウドストレージ、システム更新、ビデオ会議、LANバックアップは回線を消費します。特にアップロードが飽和すると、サイトへのリクエストも遅く感じられます。無線ネットワークは距離や同一周波数帯の干渉の影響も受けるため、安定した有線接続が使える場合は比較テストを行えます。長期的に有線へ変更する必要はなく、無線区間が原因かを確認するためだけの比較です。

遅延、スループット、安定性は別の指標

遅延はクリック後の応答速度に影響し、スループットは継続的な転送能力に影響します。安定性は、再生や会議が周期的に止まるかどうかを左右します。低遅延の回線が大容量ファイルに最適とは限らず、スループットの高い回線が短いリクエストに最も速く応答するとも限りません。回線は用途に合わせて選びます。サイト閲覧やインタラクティブなツールでは応答の連続性、ストリーミングでは持続的なスループット、リモート協業では特にジッターと短時間の切断を重視します。

混雑時間帯は時間帯と回線をまたいで比較する

日中は正常で夜間に繰り返し遅くなるなら、時間帯による特徴があると考えられます。遅い時間に同じ回線へ何度も再接続するのではなく、別の地域または別タイプの回線と比較し、同じ時間帯に安定する回線を記録してください。回線の詳細とタイプの説明は回線ページで確認できます。直接接続は経路が比較的シンプルですが、ローカルネットワークの変化に敏感です。中継経路は中間区間が増える一方、好ましくない国際経路を避けられる場合があります。IEPL専線は経路の安定性を重視する用途に適しています。最終的には、特定のラベルを万能のお守りにせず、現在のネットワークでの実測結果を基準に選んでください。

ストリーミングの画質が落ちるときは、サービス側の自動画質調整と接続速度を区別する必要があります。プレーヤーは一定時間の継続的な転送状態に応じて画質を調整するため、回線を切り替えた直後だけ見ても正確ではありません。再生を停止し、回線を切り替え、コンテンツを開き直して、安定した状態が続くか確認してください。ビットレート、帯域幅、画質低下の関係は4K動画が480pに落ちるときの対処法で詳しく解説しています。

同じネットワークですべての回線が遅く、別のネットワークに移すと明らかに改善する場合は、ローカルネットワークの種類と発生時間帯を問い合わせに記載します。特定のサービスだけ遅く、他のサイトが正常なら、対象ドメインと利用地域を記録します。速度が大きく変動する場合は、ピーク値のスクリーンショットだけでなく、一定時間続いた症状を説明してください。安定性の問題には時系列が必要です。1枚の画像だけでは、経路がいつ乱れたのか判断しにくいからです。

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

頻繁な切断では、まず「クライアントが自動的に切断した」「システムがネットワークを一時停止した」「無線ネットワークが切り替わった」「アプリがバックグラウンドに移り、システムに停止された」を区別します。前面で使っている間は安定し、画面ロックやアプリ切り替え後に切断するなら、まずバックグラウンド権限と省電力設定を確認します。前面でも一定間隔で切断するなら、ネットワークの揺らぎ、回線セッションの失効、複数のネットワークツールの競合が考えられます。

デスクトップではスリープとネットワーク切り替えを先に確認する

Windows、macOS、Linuxでは、スリープからの復帰、無線ネットワークの切り替え、有線から無線への変更後も、元の接続が有効と表示され続けることがあります。しかし、基盤となるネットワーク経路はすでに変わっています。最も確実な復旧方法は、まずクライアントを切断し、新しい通常のネットワークでサイトにアクセスできることを確認してから再接続することです。復帰するたびに異常が出るなら、システムの電源設定で、アイドル時にネットワークインターフェースを停止する設定がないか確認し、ネットワークを自動的に引き継ぐ他のツールを終了します。

デバイスが複数の利用可能なネットワークに接続していると、信号の変化に応じてシステムが自動的に切り替えることがあります。接続セッションが古いインターフェース上で確立されている場合、新しいインターフェースに引き継がれた際に切断される可能性があります。診断中は1つのネットワークに固定し、他のネットワークへ自動参加する設定を一時的に無効にしてください。固定すると安定するなら、問題は回線ではなくネットワークインターフェースの切り替えにあります。複数のアクセスポイントを移動しながら、セッションにレールへ溶接されたような安定性を求めることはできません。

iOSとAndroidのバックグラウンド設定

モバイルOSは、電池残量、バックグラウンド動作、アプリの使用状況に応じてプロセスを停止することがあります。クライアントをバックグラウンドに移してしばらくすると使えなくなる場合は、アプリによるネットワーク接続の継続が許可されているか、厳しい省電力の対象になっていないか、画面ロック時に現在のネットワークが切断されていないかを確認してください。ワンタップのクリーナーでクライアントを強制終了したり、タスク切り替え画面から必要なプロセスを手動でスワイプ終了したりしないでください。

iOSでは、クライアントに必要なネットワーク設定が残っていることを確認します。ネットワーク切り替えやシステム復帰後に自動で戻らない場合は、クライアントを開いて手動で再接続してください。Androidは省電力の実装が機種によって大きく異なるため、システムのバッテリー設定またはアプリのバックグラウンド設定でクライアントの継続動作を許可し、データ使用が制限されていないことも確認します。設定名は環境によって異なります。判断基準は1つです。バックグラウンドに移した後も、クライアントのプロセスとネットワーク接続が保持されているかどうかです。

時間の規則性から回線かデバイスかを判断する

切断が完全にランダムなら、その時にネットワーク切り替え、画面ロック、復帰、大容量通信が起きていなかったかを記録します。特定の回線だけで起きるなら、回線を変更して回線名を控えます。すべての回線が同じデバイスで切断し、他のデバイスが正常なら、現在のデバイスを優先して確認します。複数のデバイスが同じネットワークで同時に切断し、ネットワークを変えると復旧するなら、問題はローカルネットワークに近いと考えられます。この交差検証に複雑なツールは必要ありません。毎回、変更する変数を1つに絞るだけです。

切断後にクライアントが自動再接続してもアプリが復旧しない場合は、影響を受けたアプリを閉じて開き直します。古いネットワークセッションを保持している可能性があるためです。クライアント自体も復旧しない場合は、完全に終了して再起動します。何度も再現する場合は、すぐに再インストールを繰り返さないでください。「前面では安定するか」「画面ロック後に起きるか」「回線変更で復旧するか」「ネットワーク変更で復旧するか」を問い合わせに記載すれば、サポートはセッションのライフサイクルに沿って調査できます。

サブスクリプション更新失敗：リンクから設定まで順に確認する

サブスクリプションは、利用可能な回線と設定をクライアントへ渡します。更新に失敗すると、クライアントに古い回線が表示され続けたり、リストが空になったりします。まだ使える古い設定を先に削除しないでください。先に削除してから更新に失敗すると、「一部利用可能」が「完全に空」へ変わります。正しい順序は、アカウント状態を確認し、サブスクリプションを再取得し、ブラウザーまたはクライアントでリンクにアクセスできることを確認してから、置き換えるか再インポートすることです。

現在のサブスクリプション入口を取得しているか確認する

ユーザーパネルにログインし、概要またはサブスクリプション関連の画面から現在の入口を再度コピーします。チャット履歴、古いドキュメント、別のデバイスの過去のクリップボードからリンクを取得しないでください。サブスクリプション入口はアカウントに紐づく提供情報です。信頼できるクライアントだけにインポートし、公開ページに掲載したり、不明な変換サービスに渡したりしないでください。説明用の例は次のような形ですが、実際に使えるアドレスではありません：

https://example.com/sub?token=YOUR_TOKEN

コピー時に空白、改行、句読点が混ざると、クライアントが無効なアドレスと認識することがあります。パネルのコピー機能を使い、クライアント内の古い値を完全に置き換えてください。既存のサブスクリプションを更新できる場合は、まず更新を使います。項目自体が破損している、名前が重複している、編集できない場合に限り、新しい項目を作成します。新しい項目で正常に更新できることを確認してから古い項目を削除し、2つの設定が同時に使えなくなるのを避けます。

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

「ネットワークエラー」は、クライアントがサブスクリプション入口へ正常にアクセスできていないことを示す場合が多いです。現在のプロキシを切断してから更新し、次に利用可能な回線へ接続して更新してみます。これにより、現在のネットワークから入口へ至る経路を切り分けられます。「形式エラー」は、クライアントが返却形式に対応していない、リンクが途中で欠けている、別のページの内容に置き換わっている可能性があります。「認証失敗」の場合は、パネルに再ログインして現在の入口を取得し、リンクの文字を何度も編集しないでください。更新成功と表示されても回線が変わらない場合は、同名の別サブスクリプションを開いていないか、クライアントがキャッシュ設定を使い続けていないか確認します。

一部のクライアントは自動更新に対応していますが、システムのバックグラウンド制限により自動タスクが実行されないことがあります。まず手動で1回更新し、サブスクリプション自体が使えることを確認してから自動更新を調べます。手動では成功し、自動では失敗するなら、問題はクライアントのスケジュール処理またはシステムのバックグラウンド権限です。手動でも失敗するなら、ネットワークとサブスクリプション入口を確認します。更新頻度を過度に高くしないでください。リクエストを繰り返しても回線が突然新しくなるわけではなく、診断価値のない同じエラーでログが埋まるだけです。

設定の重複と古いルールの残存を避ける

再インポート後、クライアントに古いサブスクリプション、手動追加した回線、新しいサブスクリプションが同時に残ることがあります。回線を選ぶ前に、どのグループに属しているかを確認し、完全に重複していて停止済みの設定を削除します。回線が表示されるのに接続できない場合は、「まったく接続できない」の章へ戻り、問題をサブスクリプションのせいにし続けないでください。更新は設定を取得する処理、接続はネットワークセッションを確立する処理です。隣り合う区間ではありますが、同じ部品ではありません。

アカウントでパネルに正常に入れるのに、どのクライアントでも更新できない場合は、使用プラットフォーム、クライアント名、エラー原文、「切断して更新」と「接続してから更新」の結果を記録します。特定のプラットフォームだけ失敗し、他が正常なら、そのクライアントのインポート形式またはネットワーク権限が原因の可能性が高いです。初回インポートに不慣れな場合は、iOSでのサブスクリプション導入手順を読むか、使い方ガイドに戻って基本手順を確認してください。

特定のアプリだけプロキシを通らない：ルール、プロセス、ネットワークスタックを確認する

ブラウザーは正常なのに特定のアプリだけアクセスできない場合、全体の接続ではなく、そのアプリ独自のプロキシ方針、振り分けルール、ネットワーク実装に問題が集中している可能性があります。システムプロキシに従うアプリもあれば、独自のプロキシ設定を持つアプリもあります。また、システム設定を読まずに直接接続するアプリもあります。まず問題が1つのアプリだけで起きていることを確認し、クライアントのルールとアプリの設定のどちらを変更するか決めます。

グローバルモードで一度切り分ける

同じ回線を維持したまま、ルールモードから一時的にグローバルモードへ切り替え、問題のアプリを完全に終了してから開き直します。グローバルモードで復旧するなら、回線とアプリ自体は利用でき、問題は振り分けルールにある可能性が高いです。それでも失敗するなら、アプリに独自プロキシが設定されていないか、古いネットワークセッションをキャッシュしていないか、対象サービスが特定地域でのみ提供されていないかを確認します。テスト後は元のルールモードに戻して具体的なルールを調整してください。診断状態を最終設定として長期利用することはおすすめしません。

ルールは通常、上から順番に照合されます。前方の広すぎるルールが先に一致すると、後方の精密なルールが適用される機会を失います。カスタムルールを確認するときは、サービスのトップページだけでなく、対象ドメイン、関連サブドメイン、アプリが実際にアクセスするサービスのドメインを確認してください。クライアントに接続ログやルールの一致結果が表示されるなら、アプリを開いた際にリクエストが直接接続とプロキシのどちらを通ったかを見ます。ログに完全なサブスクリプション入口を含めないでください。スクリーンショットを共有する前に、アカウント情報も隠します。

システムプロキシと仮想ネットワークモードを区別する

システムプロキシは、OSのプロキシ設定に従うプログラムに主に影響します。仮想ネットワークモードはより低い層で通信を引き継ぐため、より多くのアプリをカバーできる場合があります。特定のアプリがシステムプロキシを完全に無視し、クライアントに対応する引き継ぎモードがある場合は、システムの権限に関する表示を理解したうえでテストできます。モードを切り替える前に接続を切断し、切り替え後に再接続して対象アプリを再起動します。古いセッションが以前の経路を使い続けるのを避けるためです。

Linux環境では、グラフィカルデスクトップのプロキシ、ターミナルの環境変数、コンテナのネットワーク、アプリ内プロキシを特に区別する必要があります。ターミナルプログラムではプロキシ変数を確認できます：

env | grep -i proxy

対象プログラムがコンテナや独立したサンドボックスで動作している場合、ホストシステムのプロキシが自動的に渡されるとは限りません。その場合は、実行環境のネットワーク設定方法に従って対応し、実際のサブスクリプションアドレスをイメージや設定リポジトリへ直接書き込まないでください。サンプル設定にはダミー値だけを使い、必要なローカルプロキシ情報は実行時環境から渡します。

キャッシュ、地域、ログインセッションを確認する

サービスによっては、出口地域、アカウント地域、キャッシュ、既存のログインセッションを同時に参照します。回線を切り替えても、古いアプリプロセスが以前の接続を保持していると、ブラウザーでは変化しているのにアプリだけ変わらないことがあります。アプリを終了し、回線を切り替え、接続が安定したことを確認してから再度開いてください。それでも異常が続く場合は、アプリのキャッシュを消去するか再ログインします。最初からすべてのデータを削除する必要はありません。まず元に戻せる操作を行い、その後に破壊的な操作へ進むのが診断の基本です。

同じサービスがブラウザーでは使えるのにアプリでは使えない場合、アプリ名、プラットフォーム、選択した回線、ルールモードとグローバルモードの比較結果を記録します。回線によって結果が異なるなら、回線ページで地域と回線タイプを確認し、対象サービスに合った出口を選んでください。「VPNは接続済みなのにアプリが動かない」という場合、多くはアプリがシステムプロキシを読んでいないか、ルールがリクエストを誤った出口へ送っています。この層を確認する方が、回線を一通り交換するより効果的です。

アプリの更新後に突然使えなくなり、他の環境に変化がない場合は、まずアプリのネットワーク動作やキャッシュの変化を疑います。同じサービスをブラウザーで開いて比較し、問い合わせには「更新前は使えたが、更新後に異常が出た」と記載してください。ただし、クライアントのバージョンを推測して書かないでください。サポートに必要なのは再現条件であり、間違っているかもしれないバージョン番号の羅列ではありません。

デバイスとアカウントの異常：ログイン問題を回線障害と混同しない

JVVPNは同時接続デバイス数に制限がありません。そのため通常、接続中のデバイス数がプランの上限に達したことが原因で使えなくなることはありません。「別のデバイスでは使えるのに、現在のデバイスでは使えない」場合は、現在のデバイスの設定、サブスクリプションの同期、アカウント状態、通信量の状態を確認します。家で何台の画面を開いているかを数えるより、こちらを優先してください。複数デバイスでの利用については、VPNの複数デバイス共有ガイドをご覧ください。

まずアカウントとプランの状態を確認する

ユーザーパネルに正常にログインできることを確認し、現在のサービス状態を確認します。JVVPNはメールアドレスなしで登録でき、ユーザー名とパスワードだけで利用を開始できます。ユーザー名は安全に保管してください。忘れたのがログイン情報なのかクライアント設定なのかを確認せず、似たアカウントを次々に作らないでください。複数のアカウント間で購入、サブスクリプションのコピー、問い合わせを行うと、隣の便に荷物を預けるような混乱が起きます。

月額サブスクリプションには、¥9.9/月・60GB、¥18/月・250GB、¥28/月・500GBが含まれます。通信量は開通日を基準に毎月リセットされ、途中でアップグレードした場合は差額が残り日数に応じて計算されます。通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効期限はありません。クライアントが接続できても、その後正常に通信できない場合は、パネルにログインして現在のサブスクリプションと通信量の状態を確認してください。クライアント画面を何度も更新するだけでは解決しません。プランの詳細と選択入口はプランページにあります。

デバイス間でキャッシュファイルをコピーしない

新しいデバイスで利用するときは、ユーザーパネルから現在のプラットフォームに適したクライアントを取得し、現在のサブスクリプションを再インポートしてください。別のOSのクライアントキャッシュディレクトリを直接コピーしないでください。プラットフォーム固有のパス、古いルール、失効したセッション、互換性のない設定が含まれている可能性があります。JVVPNはWindows / macOS / iOS / Android / Linuxに対応しています。各プラットフォームでは、システムプロキシ、バックグラウンド権限、ネットワークの引き継ぎ方法が異なります。サブスクリプションの内容が同じでも、クライアントの実行環境を単純に複製することはできません。

特定のデバイスだけ回線リストが空で、他のデバイスが正常なら、まず問題のデバイスでサブスクリプションを手動更新します。更新に失敗したら、サブスクリプションの章に従います。リストはあるのに接続できないなら接続の章を確認します。接続できるのにアプリが通信できないなら、振り分けの章へ進みます。このように段階ごとに分けると、すべての問題を「アカウント異常」というブラックホールに押し込まずに済みます。

アカウントログイン、クライアントのサブスクリプション、決済状態を区別する

Webサイトのアカウントにログインできても、クライアントにサブスクリプションがインポート済みとは限りません。クライアントにサブスクリプションがあっても、現在の状態へ更新済みとは限りません。決済が完了した後も、パネルに戻って対応するサービスが表示されていることを確認する必要があります。Alipay / WeChat Pay / USDTは本サイトで利用できる決済方法です。注文状態が想定と異なる場合は、ユーザーパネルで注文を確認して問い合わせを送信してください。システムを試すために注文を繰り返し作成しないでください。

決済後の利用に関する期待と問題がある場合は、まずプラン規約を確認してください。本サイトでは7日間の無条件返金を提供しています。具体的な申請はユーザーパネルから行ってください。トラブル対応と返金は別の手続きです。技術的な問題は引き続き問い合わせで診断し、返金を希望する場合は対象の注文と要望を明確に記載してください。混ざった説明から、接続を直したいのか注文を処理したいのかをサポートに推測させないためです。

サポートへ連絡するタイミングと問い合わせの書き方

セルフチェックの目的は、ユーザーを兼業のネットワークエンジニアにすることではありません。問題の範囲を素早く判断できる情報を集めることです。基本ネットワークの確認、回線変更、クライアントの再起動、サブスクリプション更新を行っても失敗するなら、問い合わせを送ってください。複数のプラットフォーム、ネットワーク環境、回線で同じ問題が起きる場合も、ローカルで宇宙船を分解し続ける必要はありません。サービス側でまとめて確認する価値がある症状です。

次のような場合は直接問い合わせる

すべての回線に同時に接続できず、基本ネットワークは正常。異なるクライアントでサブスクリプション入口を更新できない。特定の回線だけ継続的に異常が起き、回線変更で復旧する。決済履歴はあるのに、パネルのサービス状態が想定どおり表示されない。同じ問題を決まった手順で再現できる。クライアントが明確なエラーコードまたはエラー原文を表示する。これらは確認対象が明確なため、送信後はアカウント、サブスクリプション、回線、クライアントの各方向から対応できます。

特定のサイトだけ一時的に開けない場合は、まず回線を変更して時間を置いて再確認します。基本ネットワーク自体が切断されている場合は、先にローカルネットワークを直します。特定のアプリだけ通信できずブラウザーが正常なら、グローバルモードとの比較を行ってから問い合わせてください。問い合わせは願いを投げる場所ではありません。情報が具体的であるほど、確認の往復を減らせます。

実行可能な問い合わせに含める情報

• 症状：接続できない、接続後にネットワークが使えない、速度異常、頻繁な切断、サブスクリプション更新失敗、特定のアプリだけ通信できないなど、状況を明確に記載します。
• 利用環境：Windows、macOS、iOS、Android、Linuxのいずれかと、使用しているクライアント名を記載します。
• 回線情報：問題が起きた回線名と、別の回線へ変更した結果を記載します。
• ネットワーク比較：接続を切断したときに基本ネットワークが正常か、別のネットワークへ移すと復旧するかを説明します。
• モード比較：特定のアプリが関係する場合は、ルールモードとグローバルモードで結果が異なるかを記載します。
• エラー原文：クライアントに表示された内容をそのままコピーします。「エラーが出た」とだけ書いたり、推測した結論に書き換えたりしないでください。
• 再現手順：クライアントを開くところから、エラーが表示されるまで実際にクリックした順番で説明します。
• 必要なスクリーンショット：状態とエラーが分かる画像を用意します。ただし、完全なサブスクリプション入口、アカウント認証情報、決済に関する機密情報は隠してください。

推奨する再現状況のテンプレート

問題の種類：接続後にサイトを開けない
プラットフォームとクライアント：実際のプラットフォームとクライアント名を記入
選択した回線：回線名を記入
基本ネットワーク：クライアントを切断するとサイトに正常にアクセスできる
比較結果：回線変更後の実際の状態
ルールモード：現在のモードと切り替え後の結果を記入
エラー原文：クライアントに表示された完全なメッセージを貼り付ける
再現手順：
クライアントを開く
サブスクリプションを更新
回線を選択
接続を確立
対象サイトを開くとエラーが表示される

テンプレートの説明は実際の状況に置き換えてください。完全なサブスクリプション入口を添付したり、パスワードを含む設定ファイルをアップロードしたりしないでください。特定の時間帯だけ発生する場合は、おおよその時間帯と継続状況を記載します。ランダムに起きる場合は、直前にネットワーク切り替え、画面ロック、復帰、大容量通信があったかを説明してください。関係のないスクリーンショットを大量に並べるより、明確な時系列を1つ示す方が有効です。

送信後は状況を保ち、大きな変更を続けない

問い合わせを送信した後は、問題を再現できる回線名、クライアント設定、エラー情報をできるだけ保ってください。使い続ける必要がある場合は正常な回線へ切り替えても構いませんが、すべての設定をすぐ削除したり、OSを再インストールしたり、アカウントの内容を消去したりしないでください。現場を完全に変えてしまうと、サポートは残った断片から推測するしかありません。問題が自然に復旧した場合も、復旧時刻、回線変更の有無、実行した操作を問い合わせに追記してください。臨時的な回線の揺らぎ、キャッシュの失効、ローカルネットワークの変化を判断する助けになります。

送信入口はユーザーパネルの問い合わせセンターにあります。サポートに必要なのは検証可能な事実であり、「きっとサーバーが落ちた」という結論を先に放送することではありません。症状、環境、比較結果、エラー原文を揃えれば、トラブル対応は謎解きからエンジニアリングの問題へ変わります。対応が完了したら、クライアントを普段のルールとよく使う回線へ戻し、診断のために一時的に有効にしたグローバルモードを常用しないようにします。