VPNトラブルシューティング完全ガイド

接続の入口

まったく接続できない：まず障害の範囲を切り分ける

元のネットワークが正常か確認する

まったく接続できない場合、接続ボタンが待機し続ける、すぐに失敗へ戻る、クライアントが何度も再試行する、またはシステムには接続要求が表示されるのに通信経路が確立しない、といった症状が現れます。最初に回線を変更するのではなく、クライアントを切断状態に戻し、現在のWi-Fi、有線ネットワーク、モバイルネットワークで通常のサイトを開けるか確認してください。元のネットワークも正常に使えない場合は、ルーター、ネットワーク認証ページ、機内モード、現在接続しているネットワークの障害を先に確認します。ホテル、商業施設、オフィスのゲストネットワークにはWeb認証が必要なことがあり、ブラウザで認証を完了していないと、クライアントの接続要求が破棄される場合があります。

元のネットワークが正常だと確認したら、現在のネットワーク種別を記録し、別の利用可能な接続方法に切り替えて比較テストを1回行います。たとえば同じデバイスが家庭のネットワークでは失敗し、モバイルネットワークでは接続できるなら、家庭のルーター、LAN内DNS、接続ネットワークのポリシーに原因がある可能性が高くなります。異なるネットワークでも失敗する場合は、アカウント、サブスクリプション、クライアントを確認します。比較テストの目的は別のネットワークに頼り続けることではなく、変数を最小限にして問題がデバイス側かネットワーク側かを判断することです。

クライアント、サブスクリプション、システム時刻を確認する

クライアントの回線一覧を開き、一覧が空白ではないこと、選択した項目が削除済みまたは利用不可になっていないことを確認します。一覧が空の場合は接続ボタンを繰り返し押さず、このページの「サブスクリプション更新の失敗」に進んでください。回線があるのにすべて接続に失敗する場合は、ウィンドウを閉じるだけでなく、クライアントを完全に終了してから再起動します。一部のデスクトップクライアントはウィンドウを閉じてもシステムトレイに常駐します。古いネットワークプロセスが終了していない状態で再起動すると、ポートの競合やプロキシ状態の衝突が起きることがあります。

システムの日付、タイムゾーン、自動時刻合わせも正しく設定してください。暗号化接続では証明書の有効期限が検証されるため、システム時刻が大きくずれていると、クライアントに曖昧なハンドシェイク失敗だけが表示される場合があります。システムの時刻を自動設定にしてクライアントを再起動し、別の回線を選んでテストします。ほかのネットワークフィルターツール、企業向けセキュリティソフト、別のプロキシクライアントがインストールされている場合は、まず完全に終了してください。複数のプログラムが同時にシステムプロキシ、仮想ネットワークアダプター、DNSを管理するのを防ぎます。PDDVPNで使用するクライアントだけを接続状態にし、通信経路が確立できることを確認してから、ほかのツールを1つずつ戻します。

1回線の失敗から全体の失敗を判断する

1本の回線だけをテストしても、サービス全体の状態は判断できません。同じクライアントで地域と回線タイプの異なる項目を比較します。ただし、切り替えるたびに前の接続が完全に切断されるまで待ってください。特定の回線だけが失敗し、ほかの回線が使える場合は、利用可能な回線を使い続け、失敗した回線名を問い合わせ用に記録します。すべての回線が失敗する場合は、ローカルファイアウォールがクライアントを遮断していないか、古いプロキシが残っていないか、サブスクリプションが正しく更新されているかを確認します。PDDVPNは90+か国 / 200+回線をカバーしていますが、実際に表示される項目は現在のサブスクリプションとクライアントの同期結果によって決まります。1本の回線の結果から、すべての回線を推測しないでください。

ここまで確認しても接続できない場合は、クライアントに表示されたエラーの原文とテストしたネットワーク種別を保存してください。読みにくいエラーでも、「接続できない」という説明より発生段階を特定する手がかりになります。名前解決の失敗はサブスクリプションまたはDNS、ポート使用中は端末内の競合、ハンドシェイク失敗はシステム時刻、ネットワーク環境、具体的な回線を組み合わせて判断します。サブスクリプション内容のサーバーパラメーターを自己判断で削除・変更しないでください。1文字の変更でも、その後の診断根拠が失われる可能性があります。

通信経路確立後の確認

接続済みなのにサイトが開かない：プロキシとDNSを確認

「通信経路が確立した」と「通信が経路に取り込まれた」を区別する

クライアントに接続済みと表示されても、ブラウザの通信が必ずその経路に入っているとは限りません。まずクライアントのステータス画面で、有効な回線が選択されているか確認します。次に、システムプロキシのスイッチ、またはクライアントのシステム全体を取り込むモードが有効か確認してください。デスクトップでは、クライアントは接続に成功しているのにシステムプロキシが手動で無効になっているケースがよくあります。また、ブラウザに独立したプロキシ拡張機能があり、独自のルールでシステム設定を上書きしている場合もあります。テスト時はブラウザの同種の拡張機能を一時停止し、システムプロキシだけを使います。

特定のブラウザだけサイトを開けず、ほかのブラウザでは開ける場合、原因はそのブラウザの拡張機能、専用DNS、キャッシュ、ネットワークポリシーにあることが多いです。拡張機能なしのブラウザウィンドウで比較し、ブラウザ独自のプロキシ設定を無効にして、ブラウザのプロセスを再起動します。ページを更新するだけでは下位層の接続は再構築されないことがあります。完全に終了してから開くほうが、古い接続の再利用を除外できます。すべてのブラウザとアプリでアクセスできない場合は、DNS、ルーティングモード、システムに古いプロキシアドレスが残っていないかを確認します。

残留プロキシと名前解決キャッシュを整理する

クライアントが異常終了すると、システムプロキシがすでに停止したローカルポートを指したままになり、すべてのサイトが読み込めなくなることがあります。まずクライアントを再起動し、通常の手順で切断してから終了し、システム設定を復元する機会を与えてください。それでも直らない場合は、システムのネットワーク設定でプロキシが手動設定のままになっていないか確認します。具体的なアドレスが分からない状態で新しい値を入力せず、使っていない手動プロキシを無効にしてからクライアントを再接続してください。

ドメインを名前解決できない場合、サイトにアクセスするとアドレスが見つからないと表示される一方、キャッシュ済みのサービスには直接アクセスできることがあります。まずシステムのDNSキャッシュを消去し、切断してから再接続します。以下のコマンドは各システムのターミナルで実行してください。権限が不足する場合は、システムの案内に従って管理者用ターミナルを使用し、不明な提供元のスクリプト全体を貼り付けないでください。

Windows:
ipconfig /flushdns

macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux:
resolvectl flush-caches

コマンドを実行したら、ブラウザを完全に終了してから再テストします。システムに該当するコマンドがない場合は、システムのネットワーク設定にある再接続操作を使えば十分で、キャッシュ削除のために追加ツールをインストールする必要はありません。DNS問題の判断では、「ドメインは開けないが既知のネットワーク接続は存在する」ことが重要です。表示されたWebエラーをすべてDNSのせいにしないでください。クライアントのログに名前解決失敗が明記されている場合は、クライアントがシステムDNS、リモートDNS、ルール指定のDNSのどれを使っているかを確認します。

エラーの範囲から対処方針を選ぶ

ルールの問題と回線の問題を区別するため、クライアントのグローバル接続モードに一時的に切り替え、短時間テストします。グローバルモードで正常に戻るなら回線自体は利用可能で、原因は分割ルーティングのルールである可能性が高くなります。グローバルモードでもアクセスできない場合は、DNS、システムプロキシ、選択した回線を再確認します。テスト後は元のモードに戻し、一時的なグローバル設定を常用しないでください。特定のアプリがルールの対象にならない場合は、「特定のアプリだけプロキシを通らない」の章を確認してください。

パフォーマンスの切り分け

速度低下と混雑時間帯の遅延：レイテンシーとスループットを分けて確認

まず、どこが遅いのかを確認する

「速度が遅い」には少なくとも、サイトの初回表示に時間がかかる、動画の画質が何度も下がる、大容量ファイルの転送速度が低い、音声やインタラクティブアプリの反応が遅い、といった複数の症状があります。ボトルネックはそれぞれ異なります。Webページやインタラクティブアプリはレイテンシー、パケットロス、DNSの影響を受けやすく、大容量ファイルの転送は継続的なスループットに左右されます。動画は対象プラットフォームへの経路、キャッシュノード、アカウント地域の判定も影響します。確認時は具体的な状況を先に記録し、単に「遅い」とだけ残さないでください。

まず接続を切断し、同じデバイス、同じネットワーク、同じ時間帯で元のネットワークが安定しているか確認します。元のネットワークがすでに混雑している場合、回線を切り替えても国際経路が変わるだけで、ローカルWi-Fiの電波やブロードバンド出口は改善しません。無線接続ではできるだけルーターに近づき、クラウド同期、システム更新、大容量ファイルのアップロードを同時に行わないでください。アップロード帯域を使い切ると、Webリクエストや動画の制御情報も待ち行列に入り、ダウンロード速度が低下したように見えます。基準状態を確認してから回線に接続し、同じ対象と近い操作で比較して初めて診断に意味が生まれます。

名称ではなく地理的な経路で回線を選ぶ

回線名が似ていても経路が同じとは限りません。通常は対象サービスの地域に合い、地理的に近い回線を選んでから安定性を確認します。対象サービスに地域条件がある場合は、名称上の近さだけを追わず、出口地域が正しいことを優先してください。回線タイプによって迂回の程度、混雑への敏感さ、接続の安定性が異なる場合があります。中継や直結などの違いはサーバーページで確認できます。

回線をテストするときは、ほかの条件を変えず、一度に1本だけ切り替え、一定時間連続して利用してから判断します。頻繁に切り替えると、ブラウザ、動画アプリ、DNSキャッシュに古い接続が残り、結果が混ざります。回線変更後にWebページは戻ったのに動画だけが止まる場合は、対象プラットフォーム、画質設定、アプリキャッシュを確認します。すべてのアクセスが遅くなった場合は、ローカルネットワーク、システムプロキシモード、バックグラウンド通信の使用量を優先して確認してください。

混雑時間帯の問題は時間帯を比較する

混雑時間帯の遅延では、混雑がローカル接続、通信事業者の出口、選択した回線、対象プラットフォームのどこで起きているかを判断します。同じデバイスとテスト対象を使い、通常時間帯と問題が発生する時間帯の結果をそれぞれ記録してください。切断時も同じように遅くなるなら、ローカル接続または通信事業者の経路を優先して確認します。特定の回線だけが特定の時間帯に異常で、ほかの回線が正常なら、同じ地域の代替回線に切り替え、元の回線名と発生時間帯を問い合わせに記載します。

瞬間的な速度テストのスクリーンショットを、継続利用の結論の代わりにしないでください。短時間のテストは、キャッシュヒット、一時的な帯域増加、アプリの先読みの段階に当たる可能性があり、長時間の転送を代表しません。より確実なのは、対象を固定し、ページの連続読み込み、動画のバッファリング、実際の作業が安定しているか観察する方法です。本サイトは、回線状態を説明するために偽のオンライン人数や偽の可用率を表示しません。診断は、現在のデバイス、ネットワーク、回線、対象サービスから成る一連の経路に基づいて行ってください。

複数の地域、複数のネットワーク環境で同じ継続的な性能問題が起きる場合は、問い合わせに元のネットワークが正常か、テスト対象の種類、異常な回線名、発生時間帯、クライアントログを添えてください。速度のスクリーンショットだけを送ったり、回線名やテスト環境を切り取ったりしないでください。これらの情報があれば、サポートはローカル接続、回線の調整、対象プラットフォームのどこに問題があるかを切り分けやすくなり、追加確認を減らせます。

接続の維持

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

ネットワーク切り替えか通信経路の中断かを判断する

頻繁な切断が起きたら、まずそのときデバイスがWi-Fiからモバイルネットワークへ切り替わっていないか、別のアクセスポイントへローミングしていないか、弱い電波の場所に入っていないかを確認します。下位ネットワークのアドレスが変わると、既存の接続を再確立する必要が生じることがあります。これは接続ネットワークの切り替えとクライアントの再接続が重なった結果です。特定の場所を離れるたびに切断するなら、まず無線のカバレッジを確認します。デバイスを動かしておらず、元のネットワークも安定しているのにクライアントが再接続を繰り返す場合は、回線、省電力設定、システムのネットワーク権限を確認してください。

デスクトップでは、スリープ復帰後の自動復元を一時的に無効にしてテストし、システムを完全に再起動してから再接続します。スリープから復帰すると、古い仮想ネットワークアダプターやルートが一時的に残り、クライアントには接続済みと表示されても実際の通信経路が無効になっていることがあります。正常に切断してクライアントを終了し、再起動するほうが、接続ボタンを連続して押すより古い状態を整理できます。特定の回線だけで切断するなら同じ地域の代替回線に切り替えて元の回線を記録します。すべての回線が似た状況で切断するなら、ローカルネットワークの変動、システムのスリープ、セキュリティソフトを確認します。

モバイルのバックグラウンド制限を確認する順序

モバイルOSは消費電力を抑えるため、バックグラウンドに長くあるネットワークアプリを制限します。画面ロック後に接続が消える、別のアプリへ切り替えてしばらくすると再接続が必要になる、システムがバックグラウンドを整理してクライアントを終了する、といった症状が一般的です。システム設定でクライアントのネットワーク動作を許可し、このクライアントへのバックグラウンド制限を解除して、システムのVPN権限が許可されたままか確認してください。メーカーによって設定名は異なりますが、確認すべき点は同じです。クライアントをバックグラウンドに移したとき、プロセスと通信経路がシステムによって一時停止されていないかを確認します。

システムに標準搭載された別のVPN設定、企業用プロファイル、複数のプロキシクライアントを同時に有効にしないでください。モバイルOSでは通常、現在のネットワーク拡張だけが通信を取り込めます。後から起動した設定が先の接続を置き換えることもあります。ステータスバーのアイコンが繰り返し表示・消去される場合は、システムのVPN設定画面で現在有効な項目を確認し、テスト中の設定だけを残します。比較が終わったら、必要に応じてほかの仕事用設定を戻してください。

ログから強制切断を見分ける

クライアントログにユーザー操作、システムのスリープ、ネットワーク変更、プロセス停止が記録されている場合は、まずデバイスの状態を確認します。回線接続のタイムアウト、ハンドシェイクの繰り返し失敗、リモート側の切断が表示される場合は、回線を切り替えてログを保存してください。「自動再接続に成功した」だけで解決と判断しないでください。頻繁な再接続は、リアルタイム通話、転送、インタラクティブなセッションを中断します。本当に安定した状態とは、通常利用中、画面ロックからの復帰後、ネットワークが変わらない状況で通信を維持できることです。

モバイルネットワークとWi-Fiを切り替えるときは、いったん手動で切断し、新しいネットワークへの接続が完了してから再接続してください。手順は1つ増えますが、ネットワーク切り替え中に古いセッションが再試行を続けるのを防げます。頻繁なネットワーク切り替えが必要な場合は、クライアントのオンデマンド接続または自動再接続を有効にできます。ただし、まず単一ネットワークで接続が安定することを確認してください。そうしないと自動機能が根本的な障害を隠し、ログが同じ再試行で埋まってしまいます。

切断に明確な発生条件がある場合は、画面ロック、Wi-Fiからのネットワーク切り替え、システム復帰、特定アプリの起動など、トリガーとなった操作を問い合わせに記載します。明確な条件がない場合は、発生時間帯、選択した回線、ネットワーク種別、クライアントが前面かバックグラウンドかを記録してください。こうした説明により、「ランダムな切断」を再現可能な条件に変えられます。サポートはデバイス、電源管理、接続ネットワーク、回線の4方向から確認できます。

サブスクリプションの同期

サブスクリプション更新の失敗：リンク、権限、キャッシュを確認

インポート失敗と更新失敗を区別する

インポート失敗は、クライアントが一度も回線一覧を生成できていない状態です。更新失敗は、既存の回線は表示されるものの、最新内容を取得できない状態です。対処方法は異なります。初回インポートに失敗した場合は、ユーザーパネルから完全なサブスクリプションをもう一度コピーしてください。文字の一部だけを選択したり、長いテキストを自動的に切り詰める中間ツールで転送したりしないでください。既存のサブスクリプション更新に失敗した場合は、まず古い回線で接続できるか確認し、クライアントに表示された更新エラーの原文を確認します。

サブスクリプションリンクはアクセス資格情報です。自分のデバイスとクライアント内だけで保管してください。リンクが公開された疑いがある場合は、ユーザーパネルで利用可能な操作から再取得し、公開の掲示板にリンクを貼って確認を依頼しないでください。問い合わせにも完全なサブスクリプションURLを貼り付けないでください。通常、サポートに必要なのはアカウントのユーザー名、クライアント名、更新時刻、エラー情報です。リンク内のアクセスパラメーターをスクリーンショット、ログ共有、記事コメントに載せないでください。

コピー内容、ネットワーク、システム時刻を確認する

更新時に形式エラーが出る一般的な原因は、リンクの前後に空白、改行、全角の句読点が混ざることです。クライアントの誤ったサブスクリプション項目を削除し、パネルから再コピーして直接貼り付けます。クライアントでアドレスを編集できる場合は、先頭のプロトコルと末尾のパラメーターが完全か確認します。ただし、ドメイン、パス、アクセスパラメーターを自己判断で置き換えないでください。説明用の例は次のように記載できます。

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

このアドレスはリンク構造の説明用であり、接続には使用できません。実際のサブスクリプションは本サイトのユーザーパネルから取得してください。クライアントにネットワークタイムアウトが表示された場合は、まず現在の元のネットワークでユーザーパネルにアクセスし、ネットワーク自体が利用可能か確認してから更新を試します。古いプロキシ状態によって、クライアントの更新リクエストが利用できない回線へ送られることもあります。その場合は接続を切断し、システムネットワークを復元してからサブスクリプションを更新します。システム時刻が正しくない場合も安全な接続に失敗することがあるため、「まったく接続できない」の章と同様に自動時刻合わせを有効にしてください。

重複したサブスクリプションと古いキャッシュを整理する

同じサブスクリプションを複数回インポートすると、クライアントに似た名前の設定グループが複数表示されることがあります。新しいグループを選択していても、自動更新先が古いグループのままだと、「更新成功なのに変化がない」「選択した回線と実際の接続先が違う」といった状態になります。現在のパネルから取得したものだと確認できるサブスクリプションを1つだけ残し、重複項目を削除してから手動更新し、更新時刻を確認してください。削除前に、カスタムルールが古い設定に紐づいていないか確認し、個人設定を誤って削除しないようにします。

クライアントのキャッシュが破損している場合は、まずクライアント内蔵の更新または設定の再ダウンロード機能を使います。サブスクリプションアドレスが正しく、元のネットワークとシステム時刻が正常で、重複項目も整理済みだと確認してから、サブスクリプションを削除して再インポートすることを検討してください。いきなりアンインストールするとログも失われ、解析エラーの特定に不利です。デスクトップでは、クライアントが設定フォルダーへの読み書き権限を持っているかも確認します。設定フォルダーがシステムのセキュリティポリシーで読み取り専用になっていると、ダウンロードは完了しても新しい内容を保存できません。

パネルを正常に開け、サブスクリプションアドレスを再コピーしても複数のクライアントで同じエラーが出る場合は、問い合わせを送信してください。クライアント名、システムのプラットフォーム、エラーの原文、発生時間帯、「初回インポートの失敗」か「既存サブスクリプションの更新失敗」かを添えます。完全なサブスクリプションアドレスを送ったり、「失敗」の2文字だけが見えるように切り取ったスクリーンショットを送ったりしないでください。背景情報がそろっていれば、リクエストが届いていないのか、内容解析に失敗したのか、設定保存時の権限に問題があるのかを判断しやすくなります。

アプリの振り分け

特定のアプリだけプロキシを通らない：ルールからプロセスまで順に確認

まず回線自体が利用可能だと確認する

ブラウザは正常なのに特定のアプリだけ使えない場合、いきなりサブスクリプションを変更しないでください。まずブラウザで対象サービスのWeb版、または同じ地域のサービスにアクセスできるか確認し、回線と出口地域が基本条件に合っているか確認します。次にクライアントをグローバル接続モードへ一時的に切り替え、対象アプリを再起動して短時間テストします。グローバルモードで復旧するなら、分割ルーティングのルール、アプリプロセスの識別、アプリ独自のネットワーク設定に原因があります。グローバルモードでも異常なら、対象サービスの地域、アカウント状態、アプリキャッシュ、選択した回線を確認します。

テストはアプリを完全に終了してから行ってください。多くのデスクトップアプリはウィンドウを閉じてもバックグラウンドに残り、プロキシモードを切り替えても古い接続を自動的に再構築しません。トレイ、メニューバー、システムのタスク管理画面でプロセスが終了したことを確認してから再起動します。モバイルでは最近使ったアプリの一覧から対象アプリを閉じて再試行します。アプリ内でページを切り替えるだけでは、プロキシ接続前に確立されたネットワークセッションを再利用する場合があります。

システムプロキシと仮想ネットワークアダプターの違いを理解する

システムプロキシに従うアプリもあれば、直接ネットワーク接続を確立するアプリ、独自のネットワークフレームワークを使うアプリもあります。クライアントがシステムプロキシだけを有効にしている場合、後者2種類の通信は取り込まれない可能性があります。仮想ネットワークアダプターやシステム全体を取り込むモードを有効にすると対象範囲は広がることが多い一方、企業向けセキュリティソフト、ほかのVPN設定、ローカル開発環境との競合も起きやすくなります。モードは「強そうな項目」を常用するのではなく、対象アプリの動作に合わせて選んでください。

対象アプリに独自のプロキシ設定がある場合は、システムプロキシと重複設定しないでください。アプリ内プロキシが無効なアドレスを指していると、システムプロキシが正常でもそのアプリは失敗します。アプリのネットワーク設定をシステムに従う状態へ戻し、クライアントで一元的に取り込むと診断しやすくなります。開発ツール、ターミナルプログラム、コンテナ環境は個別の環境変数を参照する場合があり、グラフィカル画面のシステムプロキシが自動的に反映されるとは限りません。その場合は各ツールの公式ネットワーク設定を確認し、サブスクリプションアドレスをプロジェクトファイルや共有スクリプトに直接書き込まないでください。

ルールの一致とドメインの名前解決を確認する

ルールモードでは通常、ドメイン、アドレス、プロセス、ルールグループによって通信先が決まります。対象アプリが複数のドメインを使い、一部が直接接続、一部がプロキシ経由になると、ログインページは正常でもコンテンツの読み込みに失敗することがあります。クライアントの接続履歴を確認し、アプリのリクエストが記録されているか、どのルールに一致したか、最終的にどの回線が選ばれたかを確認してください。記録がまったくない場合、アプリがシステムプロキシを迂回しているか、取り込まれていない環境で動作している可能性があります。記録はあるのに経路が想定と違う場合は、サブスクリプション全体を無作為に変更せず、該当するルールグループを調整します。

アプリに専用DNSがある場合、システムとは異なる名前解決結果になることがあります。アプリ内の専用DNSを一時的に無効にし、アプリキャッシュを消去して再起動すると、解析経路が原因か確認できます。グローバルモードでは使えるのにルールモードでは使えない場合、対象ドメインとルール一致の結果を保存して問い合わせてください。アプリ名だけを伝えるより有効です。サービスによってはアカウント地域、コンテンツの利用許諾、ログイン状態に応じて結果が変わります。回線は対応する出口を提供できますが、サービス側のアカウント条件を代替するものではありません。

特定のアプリを継続的に使う場合は、再現条件を整理してください。ブラウザでは正常か、グローバルモードでは正常か、ルールモードで何に一致したか、プロセスを再起動すると結果が変わるか、選択した出口地域が対象サービスの要件に合っているかを記録します。ストリーミングについてはストリーミング利用ガイド、AIツールのネットワーク要件についてはChatGPTのネットワーク選びと安定利用のポイントも参照できます。これらのページは対象サービスの違いを理解するためのもので、この章では端末の通信が正しく取り込まれているかの確認を優先します。

アカウントの状態

デバイス、通信量、プランの状態を照合する

「デバイス数の上限」表示を判断する

PDDVPNはデバイス台数に制限がないため、デバイス数に関する表示が出ても、固定台数の上限を前提にしないでください。まず、その表示が本サイトのユーザーパネル、クライアント自体、OSのネットワーク設定のどこから出ているか確認します。クライアントによっては、重複設定、同時接続の競合、ローカル認証の異常をデバイスの問題としてまとめて表示することがあります。これはサービスプランの制限とは異なります。ほかのデバイスにある異常な接続を終了し、現在のデバイスで再接続して、同じ設定の繰り返し試行によるセッション競合を除外します。正常なデバイスを削除する必要はありません。

表示がサードパーティ製クライアントの画面に出た場合は、原文全体とクライアント名を保存してください。表示だけを根拠に追加のデバイス枠を購入したり、問題を回避するために複数のアカウントを作ったりしないでください。本サイトのプランではデバイス台数に制限がありません。サポートはアカウント状態、サブスクリプションのリクエスト、クライアントエラーを照合して原因を判断します。複数のデバイスが同じネットワークで異常になり、別のネットワークでは正常なら、ルーターの接続追跡、LAN内DNS、接続ネットワークの制限も確認します。

サブスクリプションの状態と通信量の周期を確認する

接続が突然停止した場合は、ユーザーパネルにログインし、現在のサブスクリプションが有効か、通信量が残っているかを確認します。月額サブスクリプションには ¥9.9/月・60GB、¥18/月・250GB、¥28/月・500GBがあり、通信量は開通日を基準に毎月リセットされます。途中でのアップグレード差額は残り日数に応じて計算されます。暦月を基準にリセット時刻を推測せず、クライアントのローカル表示だけでアカウント状態を判断しないでください。クライアントのキャッシュはパネルのデータより遅れることがあります。

長期的な使用量が一定でない場合は、プランページで通信量パックも確認できます。¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効期限はありません。月額サブスクリプションと通信量パックでは計算方法が異なるため、まず現在どちらを使っているか確認してください。購入履歴があるのにクライアントが古いサブスクリプションを使っている場合は、サブスクリプションを更新し、現在の設定グループを確認してから再接続します。途中でアップグレードした場合も更新を行い、古いキャッシュが使われ続けないようにしてください。

アカウントの問題と端末固有の問題を区別する

同じアカウントで別のデバイスには接続でき、現在のデバイスだけ接続できない場合、原因は現在のデバイスのクライアント、システムプロキシ、権限、ネットワーク環境にある可能性が高くなります。同じアカウントで全デバイスに同じエラーが出る場合は、サブスクリプションの状態、更新、選択した回線を優先して確認します。デバイスを比較するときは、デバイス、ネットワーク、回線の3つを同時に変えないよう、できるだけ同じネットワークと同じ回線を使ってください。

登録にメールアドレスは不要で、ユーザー名とパスワードだけで登録できます。そのため、ユーザー名はアカウント確認の重要な手がかりです。問い合わせ前に正しいユーザー名を入力しているか確認し、別のアカウントで生成したサブスクリプションを誤って使っていないか確認してください。公開スクリーンショットに完全なユーザー名、注文情報、サブスクリプション資格情報を表示しないでください。アカウントの状態が分からない場合は、ユーザーパネルのログインと問い合わせ窓口を利用し、再登録して別アカウントの設定を同じクライアントに混在させないでください。

支払い方法はAlipay / WeChat / USDTに対応しています。支払い記録は注文手順の証明に使えますが、クライアントの更新完了を直接示すものではありません。購入またはアップグレード後も、パネルの状態を確認し、サブスクリプションを更新して再接続してください。注文状態と実際の支払い結果が一致しない場合は、パネルの注文情報と決済サービス側の結果を保存し、問い合わせで確認します。本文では14日間の無条件返金について案内していますが、接続問題は通常、まず診断で解決できます。適用条件の詳細は返金ポリシーをご確認ください。

サポートへの相談

サポートへ相談するタイミングと問い合わせに添える情報

問い合わせを送るべきケース

該当する章の基本確認を終えても、すべての回線に接続できない、複数のネットワーク環境で同じ結果になる、複数のクライアントでサブスクリプション更新に同時に失敗する、特定の回線だけが継続的に異常になる、アカウントや注文状態がパネル表示と一致しない、といった場合は問い合わせを送ってください。サポートの役割は、ユーザーに再インストールを無限に繰り返させることではなく、アカウント側の状態、回線側のログ、利用環境の情報を照合することです。単一のブラウザ拡張機能、ローカルスクリプト、企業ネットワークポリシーだけで障害が起きる場合も問い合わせできますが、通常のネットワークとの違いを明確に説明してください。

広範囲の異常が発生している場合、同じ内容の問い合わせを連続して作成しないでください。重複した問い合わせは文脈を分散させ、前の問い合わせで確認済みの条件を引き継げなくなります。元の問い合わせに新しいテスト結果を追記し、どの操作で症状が変わったかを明記してください。問題が自然に解消した場合も、復旧時刻、回線を切り替えたか、現在の状態を追記すると、一時的なネットワーク変動か設定変更の効果かを判断しやすくなります。

問い合わせ情報の推奨構成

タイトルには症状とプラットフォームを直接記載します。たとえば「macOSで接続後、すべてのサイトが開けない」「Androidで画面ロック後に接続が切れる」のように書き、「緊急」「使えない」だけにしないでください。本文ではまずシステムのプラットフォームとクライアント名を示し、現在のネットワーク種別、選択した回線、障害が始まった時間帯、安定して再現できるかを記載します。続いて、元のネットワークが正常か、ネットワークを変更したか、回線を変更したか、DNSを消去したか、グローバルモードとルールモードでどうなったかなど、実施済みの確認を列挙します。

スクリーンショットには、クライアントの状態、回線名、エラーの原文など十分な文脈を残します。ただし、サブスクリプションリンク、アクセスパラメーター、支払い資格情報、その他のアカウント情報は必ず隠してください。ログは障害発生前後の関連部分だけを抜き出し、結論の1行だけを送ったり、確認せずに個人フォルダー全体をアップロードしたりしないでください。クライアントが診断ログのエクスポートに対応している場合は、出力前に内容を確認し、サブスクリプション資格情報が含まれていないことを確認します。不明な場合は、まずエラーの原文をテキストで送信し、必要な追加部分をサポートに確認してください。

障害の症状：
システムのプラットフォームとクライアント：
現在のネットワーク種別：
選択した回線：
発生し始めた時間帯：
再現性：
元のネットワークは正常か：
テスト済みの別回線：
実施した確認：
クライアントに表示されたエラーの原文：
サポートに確認してほしい項目：

往復のやり取りを短縮する情報

時刻と回線名は、回線の問題を判断するうえで最も重要な文脈です。「昨日遅かった」だけでは具体的な時間帯に対応できず、ブラウザ、動画、ダウンロードのどの状況かも区別できません。発生時に使っていた回線、対象がWebページかアプリか、切断後の元のネットワークが正常だったかを説明してください。接続失敗にはエラーの原文、速度問題には実際の作業内容と継続性、サブスクリプション問題には初回インポートか既存設定の更新かを記載します。モバイルの問題では、前面、バックグラウンド、画面ロック、ネットワーク切り替えなどの発生条件も説明してください。

アカウントや注文の問題では、ユーザー名とパネルに表示される注文識別情報を提供しますが、パスワードは送らないでください。登録にメールアドレスは不要なため、サポートが照合する際はユーザー名とパネルの記録がより重要になります。支払いについては、Alipay / WeChat / USDTのどれを使ったかとパネルの表示状態を説明し、問い合わせに完全な支払い資格情報を記載しないでください。返金については、本文では14日間の無条件返金として扱い、具体的な申請範囲と手続きは返金ポリシーに従います。

障害復旧後の仕上げ

問題が解決したら、一時的なテスト設定を通常の状態に戻します。たとえばグローバルモードを元の分割ルーティングモードに戻し、重複したサブスクリプションを削除し、互換性を確認したセキュリティソフトを再有効化し、クライアント切断後にシステムプロキシが正常に復元されるか確認します。回線の切り替えで解決した場合は、元の回線名と異常が起きた時間帯を残してください。DNSの消去やクライアントの再起動で解決した場合は、実際に効果があった最後の手順を記録し、それ以前のすべての操作を必須だったと考えないようにします。

頻繁に起きる障害には、元のネットワーク、パネルの状態、サブスクリプション更新、クライアント再起動、回線切り替え、システムプロキシ、DNS、対象アプリという簡単な個人用確認順序を作ると便利です。順序を固定すれば、毎回どの層で問題が止まっているかをすぐ特定できます。サブスクリプションのインポートの仕組みを詳しく知りたい場合は、サブスクリプションリンクの意味とインポート方法をご覧ください。インストールから再確認したい場合は、クイックスタートガイドに戻ってください。このガイドは、不明な状態で試行錯誤を続けるためではなく、現場の情報を判断可能で再現可能な、引き継ぎやすい障害記録に整理するためのものです。