トラブルシューティング
症状から解決まで

トラブルシューティングがうまく進まない最大の理由は、問題が複雑だからではなく、状況の説明が具体的でないことです。「つながらない」「遅い」「たまに切れる」だけでは、どの層の障害か直接判断できません。操作を始める前に、症状を再現可能な条件へ置き換えましょう。使用中のプラットフォーム、家庭内ネットワークか公共ネットワークか、クライアントを正常に開けるか、サブスクリプション一覧が見えるか、回線を選択できるか、接続状態が成功するか、ブラウザーと他のアプリも同時に異常かを確認します。条件が明確なら、問題がローカルネットワーク、クライアント、システムプロキシ、名前解決、回線出口、対象サービスのどこにあるかをすばやく判断できます。

まず障害の範囲を確認し、いきなり再インストールしない

まずクライアントの接続を切り、普段正常に開けるローカルサイトへ直接アクセスします。直接接続でも安定して読み込めない場合は、ルーター、無線ネットワーク、システムネットワーク、接続事業者側の問題を先に確認してください。高速化接続は既存のネットワーク伝送に依存するため、ローカルネットワーク自体が切れている状態では、回線を変えても通常は解決しません。直接接続が正常になったらクライアントを起動し、1本の回線だけでテストします。この時点ではブラウザー拡張、他のプロキシツール、システムレベルのネットワークフィルター、同種クライアントを同時に有効にしないでください。システムプロキシ、仮想ネットワークインターフェース、DNS設定を奪い合う可能性があります。

次に、「すべての対象が失敗する」のか「特定の対象だけ失敗する」のかを分けます。ブラウザー、デスクトップアプリ、システム更新がすべて異常なら、接続状態、プロキシモード、DNSを優先して確認します。特定のサイトだけ開けない場合は、地域設定、キャッシュ、ログイン状態、一時的なサービス障害の可能性があります。特定のアプリだけプロキシを通らない場合は、ルーティングルール、アプリ独自のネットワーク処理、システム権限の問題が考えられます。範囲が小さいほど、すべての設定を消去するような大きな操作は避けてください。既知の正常な設定を残すことで比較できます。

比較用の条件を1組残す

以前使えた回線を1本基準にし、異なる地域または異なる回線タイプの回線をもう1本比較対象にすることをおすすめします。回線タイプの違いはノードページで確認できます。テスト中はデバイス、クライアント、ネットワークを固定して回線だけを切り替え、その後は回線を固定してローカルネットワークだけを切り替えます。これにより、異常が回線に追随するのか、ネットワークに追随するのかを確認できます。特定の回線だけで発生する場合は回線名を記録し、特定のネットワークだけで発生する場合は、そのネットワークの名前解決、ルーティング、アクセス方針を重点的に確認します。

検証できる情報だけを記録する

記録には、プラットフォーム名、ネットワークの種類、クライアントに表示された状態、選択した回線、エラーメッセージの原文、問題を安定して再現できるか、実施済みの操作を含めます。「いろいろ試した」だけでは不十分です。エラーメッセージをコピーできる場合は全文を残し、スクリーンショットしかない場合はステータスバーと回線名が写るようにします。ただし、ユーザー名、サブスクリプションリンク、ログインに使える認証情報は隠してください。サブスクリプションリンクはアカウントの認証情報に相当するため、公開グループやフォーラムに投稿しないでください。

5TVPNはWindows、macOS、iOS、Android、Linuxに対応しており、アカウントは台数制限なく利用できます。プラットフォームごとにシステムプロキシ、バックグラウンド方針、仮想ネットワークの実装が完全には同じでないため、同じアカウントが1台では正常で別の1台では異常でも、アカウント障害とは限りません。以降の章でプラットフォームごとの差を説明します。クライアントを初めて使う場合や、サブスクリプションの取得場所が分からない場合は、クイックスタート手順に戻ってください。前提手順を飛ばして診断ガイドだけを進めないでください。

「まったく接続できない」とは、クライアントを開けて回線の表示や選択はできるものの、接続が常に失敗する、すぐ未接続状態に戻る、または接続中のまま長時間進まない状態です。まず、サブスクリプション内容が正しく読み込まれていないのか、回線は読み込まれているが接続ハンドシェイクに失敗しているのかを分けます。前者では、回線一覧が空、サブスクリプション名が消える、更新エラーが表示されるといった症状が出ます。後者では回線名が見えるものの、安定した接続状態に移行できません。両者は対処の順番が異なるため、混同しないでください。

直接接続、システム時刻、クライアント権限を確認する

まずクライアントを切断し、直接接続が利用できることを確認します。次に、システム時刻が自動同期になっているか確認してください。暗号化接続では証明書と時間範囲の検証が必要なため、システム時刻が大きくずれていると、回線障害に見えるハンドシェイク失敗が起こることがあります。続いて、クライアントがシステムネットワーク接続に必要な権限を持っているか確認します。デスクトップでは仮想ネットワークインターフェースの作成やプロキシ設定の変更を許可する必要がある場合があります。モバイルでは初回接続時にシステムレベルの確認画面が表示されるため、拒否した場合はシステム設定から再度許可してください。

クライアント起動直後に異常終了する場合は、接続ボタンを連打せず、プロセスを完全に終了してから再起動します。WindowsとmacOSでは、別の同種クライアントがバックグラウンドで動作していないかも確認してください。Linux環境では、ネットワークインターフェースとルーティングテーブルを操作する権限を起動方法が持っているか確認します。最初からすべての設定を削除するのはおすすめしません。削除すると、判断材料になるサブスクリプション状態とエラー記録も失われます。まず競合プログラムを終了し、元の設定で再テストしてください。

問題が現在のネットワークに追随するか確認する

デバイス、クライアント、サブスクリプションを変えずに、別の利用可能なネットワークでテストします。別のネットワークで接続できるなら、アカウントとクライアントの基本設定はおそらく正常で、元のネットワークのルーティング、DNS、プロトコル処理、接続方針に問題がある可能性が高くなります。その場合は、まず元のネットワークのルーターを再起動し、ネットワークパラメータの再取得を待ってから、異なる回線をテストします。公共ネットワークでは、ブラウザーで接続確認を完了させる必要がある場合があります。確認が終わるまで、クライアントが接続を開始できても、ネットワークが通常の通信を許可していないことがあります。

すべてのネットワークで接続できない場合は、次に回線を切り替えます。隣接する回線だけを連続して切り替えず、異なる地域または異なる回線タイプを比較してください。5TVPNは120+か国 / 230+回線を提供しており、回線ページで選択可能な地域とタイプを確認できます。特定の回線だけが失敗する場合は、他の利用可能な回線を使えばよく、クライアントを何度も再インストールする必要はありません。複数のネットワークで複数の回線が失敗する場合に限り、サブスクリプション状態、システム権限、クライアント設定をさらに確認します。

モードの競合と残留システムプロキシを確認する

システムプロキシモードと別のネットワーク制御ツールを同時に有効にすると、接続後の通信が再び転送され、接続失敗や再試行の繰り返しにつながることがあります。診断中はクライアントを1つだけ残し、ブラウザーのプロキシ拡張、開発用デバッグプロキシ、ネットワークフィルターソフトのプロキシ機能、システムに手動で入力したプロキシアドレスを無効にします。その後クライアントを終了し、システムプロキシが復元されていることを確認してから再起動します。クライアントに自動制御機能がある場合は、同じクライアントに一元管理させ、手動設定と自動設定を混在させないでください。

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

上記はサンプル値の形式であり、サブスクリプションリンクの構造を見分けるためだけに使います。実際のサブスクリプションアドレスはユーザーパネルから取得し、サンプルを置き換えて公開しないでください。クライアントがサブスクリプションの読み込みを求めているのに、通常のウェブページのURLを貼り付けていたり、コピー時に先頭または末尾の文字が欠けていたりすると、回線は正しく読み込まれません。パネルから完全にコピーし直してインポートし、チャットツールを経由しないでください。一部のツールはリンクを書き換えたり、特殊文字を切り捨てたりします。

プラットフォームごとの接続入口の違い

ここまで確認して、特定のネットワークだけで障害が起きる場合は、ネットワークの種類と再テスト結果を問い合わせに記載してください。すべてのネットワークと複数の回線で失敗する場合は、クライアントのエラーメッセージを添付します。「接続失敗」とだけ書いた部分的なスクリーンショットでは不十分です。サポートがプラットフォーム、選択回線、発生段階、メッセージ全文を確認できて初めて、サブスクリプションの解析、権限、ネットワークハンドシェイク、回線入口のどこに問題があるか判断できます。

クライアントに「接続済み」と表示されても、接続経路が確立したことを示すだけで、すべての通信が正しく経路に入るとは限りません。ウェブが開けない場合は、システムプロキシが通信を取り込めていないのか、DNSが正しく解決していないのか、ブラウザーに誤ったキャッシュが残っているのか、対象サイト自体が一時的に利用できないのかを確認します。この段階で接続ボタンを何度も押しても効果は小さく、問題は接続後の通信処理にあります。

まず範囲からプロキシの有効性を判断する

接続状態を保ったまま、ブラウザーとシステムネットワークを使う別のアプリをそれぞれテストします。すべてのアプリにアクセスできない場合は、クライアントが想定したモードか、システムプロキシが正常に書き込まれているかを確認します。ブラウザーだけ使えて他のアプリが使えない場合、ブラウザーが独自のプロキシやDNSを使い、システム通信が一括制御されていない可能性があります。逆に、他のアプリは正常でブラウザーだけ異常なら、ブラウザーのプロキシ拡張、プライバシーネットワーク機能、カスタム名前解決設定を無効にし、古い拡張を読み込まない新しいウィンドウでテストします。

ブラウザーを終了してから再起動する方法もあります。ブラウザーは接続プール、名前解決結果、サイトセッションを保持するため、回線を切り替えても古い接続が以前の出口を指し続けることがあります。ページの更新だけでは基礎接続が再構築されない場合があります。新しいウィンドウで復旧するなら、問題は通常ブラウザーのキャッシュまたは拡張にあり、回線ではありません。複数のブラウザーで同じ結果になる場合は、システムプロキシとDNSを続けて確認します。

名前解決の問題を見分ける

DNSはドメイン名をネットワークアドレスへ変換します。解決に失敗すると、クライアントは接続済みなのに、ページにサーバーが見つからない、ドメインが存在しない、解決がタイムアウトしたなどと表示されます。既知のネットワークアドレスを直接使うアプリは動作することがあります。診断時は、まずシステムDNSを自動取得に戻し、ブラウザーのカスタム安全DNSを無効にして、クライアントに既定の方法で制御させます。ルーター、システム、ブラウザー、クライアントで異なる解決方式を同時に設定しないでください。リクエストが異なる出口から送信され、判断が難しくなります。

ネットワークフィルター、ペアレンタルコントロール、広告ブロッカー、企業向け接続ツールを以前インストールしていた場合、プログラムを終了しても残ったシステムの名前解決サービスが動き続けることがあります。デスクトップでは、現在のネットワークアダプターのDNSが手動アドレスを指していないか確認し、モバイルでは現在の無線ネットワークに手動DNSやプロキシが設定されていないか確認します。自動設定に戻したら、ネットワークを切断して再接続し、クライアントを起動します。順番が重要です。先にシステムネットワークを復元してから、クライアントに設定を書き込ませます。

接続成功後に残ったルーティングを処理する

クライアントの異常終了、デバイスのスリープ中断、複数ツールによるネットワーク制御の交代が起きると、システムに古いプロキシやルートが残ることがあります。典型的には、クライアントは接続済みなのにすべてのリクエストが正しく返らず、クライアント終了後は直接接続にも影響します。この場合は正常に切断してクライアントを終了し、ネットワーク接続をいったんオフにしてから再びオンにし、ルーティングと名前解決パラメータを再取得させます。直接接続が戻ったことを確認してから、クライアントを起動してテストします。

Linuxでコマンドラインクライアントを使う場合は、デフォルトルート、ポリシールーティング、名前解決サービスが存在しないインターフェースを指していないか重点的に確認します。出所不明のクリーンアップコマンドを直接コピーしないでください。まず現在の状態を確認し、どのルールをクライアントが作成したかを把握してから、クライアント自身の停止手順で削除します。サービスとして動かしている場合は、前面のインスタンスを同時に起動しないでください。2つのインスタンスがそれぞれルーティングとDNSを変更する可能性があります。

特定のウェブサイトだけ開けない場合の判断

特定のサイトの異常は、全体の接続障害を意味しません。まずサイト内の別の入口を開き、ログインページ、動画ページ、リソースドメインだけが失敗していないか確認します。次にシークレットウィンドウで古いCookieとキャッシュを除外し、その後別地域の回線を選びます。サービスによっては出口地域に応じて内容が変わり、ログインセッションにも以前の地域情報が残ることがあります。地域を切り替えたら、元のタブを使い続けずページを開き直してください。

同じ回線で他のサイトは正常で、対象サイトが複数のブラウザーで同じエラーを返す場合は、サイトのドメイン、選択した地域、エラーメッセージを記録します。アカウントのパスワード、ページ内の個人情報、サブスクリプションリンクをスクリーンショットに含めないでください。ストリーミングの地域判定については視聴アクセスに関するガイドを、出口地域の選択についてはノードページを参照してください。

復旧後の確認

アクセスが戻っても、すぐにすべての拡張機能やフィルターを再び有効にしないでください。まず既定設定のまま一定時間使い、ブラウザー、他のアプリ、スリープ復帰後も正常であることを確認してから、追加ツールを1つずつ戻します。各ツールを戻すたびに再テストすれば、競合元を特定できます。追加設定を一度にすべて戻すと、再発しても原因を絞れません。

接続後もウェブが開けず、クライアント内の接続確認だけが正常な場合は、問い合わせに「接続状態は成功したが、すべてのウェブが失敗した」のか「特定ドメインだけ失敗した」のかを記載し、自動DNSへの復元、拡張機能の無効化、回線切り替え後の結果も書いてください。単に「DNSが使えない」と説明するより、これらの情報の方が原因特定に役立ちます。

速度の問題では、起動の遅さ、継続的な転送量不足、高遅延、接続の不安定さをまず分ける必要があります。ウェブを初めて開くまで長く待たされる場合は、DNSまたは遅延が原因かもしれません。ファイルの開始は速いのに途中で止まる場合は、回線の揺らぎや対象サービスの速度制限が考えられます。動画が自動で画質を下げる場合は、利用可能帯域の不足だけでなく、短時間の変動に対してプレーヤーが保守的に動いている可能性もあります。すべてを「ノードが遅い」とまとめると、本当に影響している箇所を見落とします。

意味のある速度比較を作る

まずクライアントを切った状態でローカルネットワークが安定しているか確認し、その後、距離の近い回線に接続して同じ操作を行います。テストでは同じデバイス、同じネットワーク、同じ対象、近い時間帯を使います。ブラウザーの速度テスト、動画の読み込み、アプリのダウンロードを別々に行って直接比較しないでください。対象ごとにサーバーの場所、速度制限、キャッシュ状態が異なります。診断の目的は見栄えのよい数字を得ることではなく、性能低下がどの区間で起きているかを確認することです。

直接接続そのものに大きな揺らぎがある場合は、無線信号、ルーターの負荷、接続ネットワークを先に確認します。接続機器に近づく、同時にネットワークを使う処理を減らす、より安定した接続方式へ変えるといった対策があります。直接接続が安定していて、接続後に遅くなる場合は、異なる地域と回線タイプを比較します。物理的に遠い回線は往復経路が長くなるため、アジアの対象へアクセスする際に欧米の出口を選ぶ必要は通常ありません。特定地域のサービスを使う場合は、そのサービス地域に合う出口を優先します。

夜間の問題は時間帯を変えて再テストする

夜間の停止が特定の時間帯だけ起きる場合、別の時間帯で一度正常だった結果だけを根拠に問題を否定しないでください。発生時間帯、回線名、対象アプリ、具体的な症状を記録し、発生中に同じ地域の別回線へ切り替え、さらに異なる回線タイプと比較します。複数の回線が同時に遅くなり、直接接続にも揺らぎがあるなら、ボトルネックはローカル接続または公共ネットワークの出口にある可能性があります。特定の回線だけが継続して異常なら、代替回線を使い、その名前をサポートへ伝えます。

回線を切り替えた後は、対象アプリの接続を再構築してください。動画プレーヤー、ダウンローダー、ブラウザーは、クライアントが切り替え済みと表示しても古い接続を一時的に再利用することがあります。最も確実なのは、処理を一時停止し、対象ページまたはアプリを閉じてから回線を切り替え、再び開くことです。回線だけを切り替えてアプリの接続を再構築しないと、誤った結論になりやすくなります。

遅延と帯域幅は別の指標

遅延は、ウェブの初回応答、ライブ配信のインタラクション、リモート操作、ゲーム操作などの反応に影響します。帯域幅は、高画質動画、大容量ファイル、システム更新などの継続的な転送に影響します。遠い回線は帯域幅が十分でも操作の反応が遅いことがあり、近い回線でも対象出口が合わなければ動画サービスに影響することがあります。用途に合わせて選び、すべての場面で同じ回線を固定する必要はありません。

デバイス側の見えない帯域使用を確認する

システム更新、クラウド同期、写真のバックアップ、ゲームプラットフォームの更新、他のデバイスでの高画質動画は、同じ接続ネットワークの帯域を消費します。診断時はこれらのバックグラウンド処理を一時停止し、ルーター配下に継続的に通信しているデバイスがないか確認します。モバイルでは、写真の同期やデータの復元中でないかも確認してください。バックグラウンド処理を止めてすぐ改善するなら、回線だけがボトルネックではありません。まずローカル帯域の配分を管理します。

クライアントのモードも体感に影響します。グローバル制御ではより多くのバックグラウンド通信が回線に入り、ルールベースのルーティングでは条件に合う対象だけが処理されます。グローバルモードで速度が大きく下がる場合は、多数のシステムサービス、クラウド同期、ローカルネットワーク処理まで一緒に制御されていないか確認します。ただしモードを切り替えた後は、対象アプリが想定した回線を通っていることを確認してください。速度のために対象通信を接続経路から外してはいけません。

ストリーミングと大容量通信を確認する順番

動画がバッファリングする場合は、まず一時停止して再生し直し、プレーヤーの一時的なキャッシュ不足でないか確認します。次に他のデバイスの使用量を減らし、その後同じ地域の回線へ切り替えてプレーヤーを完全に再起動します。高画質でだけ不安定な場合は、ストリーミングの画質と帯域幅に関する解説を読んで、ビットレート、継続転送量、自動画質調整の関係を確認してください。記事は指標の説明を目的とし、このページでは引き続き診断手順を中心に扱います。

速度の問題を問い合わせる場合、速度テストのスクリーンショット1枚だけを送らないでください。直接接続が安定しているか、ネットワークの種類、回線名、対象サービス、発生時間帯、回線変更後に改善したかを併記します。第三者の速度テストと実際のアプリ経路は異なるため、1回の結果ですべての場面を代表することはできません。孤立した数字より、再現条件が重要です。

頻繁な切断では、回線セッションが中断したのか、デバイスがネットワークを切り替えたのか、システムがクライアントを停止したのか、クライアントは接続中だが対象アプリのセッションが無効になったのかを分けます。モバイルデバイスが無線ネットワークからモバイルネットワークへ切り替わる、画面ロック後に省電力状態へ入る、システムがバックグラウンド処理を終了するといった動作で、接続の再構築が必要になることがあります。デスクトップでも、スリープ、ネットワークアダプターの省電力、有線から無線への切り替えで同じ症状が起こります。トリガーとなる動作を特定して初めて、適切な対処を選べます。

まず明確な発生条件を探す

デバイスを動かさず、同じネットワークを使い続けて切断が起きるか観察します。安定するなら、ネットワーク切り替え、画面ロック、スリープ、バックグラウンド方針が原因の可能性が高くなります。その後、画面ロックからの復帰、無線ネットワークの切り替え、スリープ復帰、長時間操作しない状態をそれぞれテストします。一度に試す動作は1つだけにしてください。画面ロックのたびに再接続が必要なら、バックグラウンド動作と省電力設定を確認します。ネットワーク切り替え時だけ中断するなら接続移行の問題であり、すぐに設定を消去せず、クライアントが経路を再構築するのを待ちます。

デバイスを動かさず、スリープもしない状態でも中断する場合は、他の条件を固定して回線を切り替えます。問題が回線に追随するなら回線名を記録します。すべての回線が固定ネットワークで切断され、別ネットワークでは復旧するなら、元のネットワークの安定性、ルーターのセッション維持、無線信号を確認します。公共無線ネットワークでは接続状態の再確認が定期的に求められ、クライアントが突然通信できなくなることがあります。

iOSのバックグラウンド動作とネットワーク切り替え

iOSはシステムリソース、低電力状態、ネットワーク条件に応じてバックグラウンド動作を管理します。診断時は、クライアントのシステム接続設定が残っており、別のネットワークツールに置き換えられていないことを確認します。画面をロックする前に接続状態を確認し、ロック解除後はステータスアイコンだけでなく、実際にウェブを開いて検証してください。アイコンが表示されているのにアクセスできない場合は、いったん切断して再接続します。画面ロックのたびに設定が失われるなら、システム内に競合する接続設定が複数ないか確認します。

無線ネットワークの信号が弱いと、システムが無線ネットワークとモバイルネットワークの間で切り替わることがあります。基礎ネットワークのアドレスが変わると既存の接続を再構築する必要があり、短時間の中断は必ずしも回線障害ではありません。切り替え後も長時間復旧しない場合は、自動ネットワーク切り替えに関する設定を一時的に無効にして比較するか、安定した単一ネットワークで再テストします。信号の境界付近で回線品質を同時にテストしないでください。ローカル無線の揺らぎが本当の結果を隠してしまいます。

Androidの省電力とバックグラウンド制限

Androidデバイスのバックグラウンド方針はメーカーごとに異なりますが、判断方法は共通しています。クライアントがバックグラウンド制限対象になっていないか、画面ロック後に省電力モードがネットワーク動作を止めていないか、システム接続の権限を現在のクライアントが保持しているか確認します。まずクライアントをバックグラウンド実行の許可対象にし、バックグラウンドタスクを自動消去する設定を無効にして比較します。テスト後は必要な権限だけを残し、診断のためにネットワーク接続と無関係な権限まで許可し続けないでください。

システムに常時接続や、接続なしの通信をブロックする設定がある場合は、変更前に効果を理解してください。常時接続はクライアント接続の維持を試み、接続なしの通信をブロックする設定は、クライアントの再起動や異常時にすべてのネットワークを一時的に使えなくすることがあります。診断中はまずクライアントの既定動作を使い、基本接続が安定してから厳格なシステム方針を有効にすることをおすすめします。そうしないと、設定による通信断を回線障害と誤認します。

デスクトップシステムのスリープ復帰

WindowsとmacOSでは、スリープ復帰後にネットワークアダプター、システムプロキシ、仮想ネットワークインターフェースが復元される順番が異なる場合があります。復帰後もクライアントが接続済みなのにウェブへアクセスできない場合は、まず正常に切断し、ローカルネットワークが完全に復旧するまで待ってから再接続します。直接接続も戻っていない場合は、無線または有線ネットワークを再接続します。システム復帰直後で有効なパラメータを取得していない状態で、回線を連続して切り替えないでください。

Linuxでシステムサービスが接続を維持している場合は、スリープ復帰用フックが復帰後にサービスとルーティングを戻せるか確認します。端末の前面で動かしている場合は、端末やセッションを閉じるとクライアントも終了することがあります。現在のクライアントが前面プロセスなのかシステムサービスなのかを明確にし、両方を同時に動かさないでください。ログにネットワークインターフェースの消失、ルートの再構築、名前解決サービスの再起動がある場合は、その時間帯を問い合わせに添付します。

切断と対象アプリの再接続を分ける

クライアントの接続は途切れておらず、ライブ配信、チャット、リモートセッションだけが切れることもあります。このような長時間接続は、短時間のネットワーク切り替え、アプリのバックグラウンド停止、対象サービスのタイムアウトで再構築される場合があります。テスト時に通常のウェブページも同時に開きます。ウェブがすぐ読み込めるなら回線経路は動作しているため、まず対象アプリのセッションを再起動します。ウェブも失敗する場合は、クライアントの接続状態を確認します。特定アプリの「再接続中」という表示だけで、回線全体が切断されたと判断しないでください。

比較の結果、特定プラットフォームの画面ロックまたは復帰時に安定して発生する場合は、問い合わせ時にシステムプラットフォーム、トリガーとなる動作、クライアントの復旧方法、手動再接続が必要かを記載します。特定の回線だけで起きる場合は回線名を伝えてください。サポートにアカウントパスワードや実際のサブスクリプションリンクを送る必要はありません。再現できる発生条件が重要です。

サブスクリプションは、アカウントで利用できる回線をクライアントへ渡します。更新失敗は、必ずしもアカウント無効を意味しません。コピー内容の不足、クライアントの古いキャッシュ、現在のネットワークからサブスクリプション入口へアクセスできないこと、クライアントが読み込んだ形式に対応していないことも原因になります。まず古い回線がまだ使えるか確認し、その後に更新を処理します。古い回線は接続できるのに更新だけ失敗するなら、既存の接続機能は動作しており、問題はサブスクリプションの取得または解析に絞られます。回線一覧も空なら、読み込み手順を優先して確認します。

サブスクリプションの入手元とアカウント状態を確認する

サブスクリプションはユーザーパネルから取得し、他人から転送されたもの、公開ページ、過去のチャット履歴にあるアドレスは使わないでください。5TVPNはメールアドレスなしで登録でき、ユーザー名とパスワードで登録できます。そのため、ユーザー名とパスワードを適切に保管してください。ユーザーパネルへログインしてサブスクリプションを完全にコピーし、クライアントに戻って更新します。コピー時はアドレス横の説明文まで選択せず、余分に見える文字を手動で削除しないでください。

パネルにログインできない場合は、まずユーザー名が正しいか確認し、サブスクリプションを何度も新規作成するのではなく、パネルのアカウント手順で対応します。ログインできてもサブスクリプション状態が異常なら、現在の月額サブスクリプションまたはデータパックがまだ利用できるか確認してください。月額サブスクリプションは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は開通日を基準に毎月リセットされ、途中でアップグレードした差額は残り日数に応じて計算されます。データパックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効で、無期限です。ここで料金プランの事実を示すのはパネル状態の確認を助けるためであり、クライアントのキャッシュから残量を推測することはおすすめしません。

ダウンロード失敗と解析失敗を分ける

サブスクリプション更新時にネットワークリクエスト失敗、タイムアウト、アクセス不能と表示される場合、クライアントはまだサブスクリプション内容を取得できていません。アカウント情報を変えずにローカルネットワークを切り替えるか、現在使える回線を経由してから更新します。形式エラー、内容が空、解析できないと表示される場合は、内容は返ってきたもののクライアントが正しく認識できていません。現在のクライアントに合うインポート入口を使っているか確認し、ウェブページのURLをサブスクリプションとして扱わないでください。また、異なるクライアント専用の読み込み方法を混用しないでください。

クライアントによって、リンクを直接貼り付けるもの、システム共有やインポートボタンを使うものがあります。使い方ガイドの各プラットフォーム向け手順に従ってください。読み込み後は、まずサブスクリプション名と回線一覧が表示されるか確認し、その後に回線へ接続します。一覧がまだ読み込まれていない状態で更新を連打しないでください。並列リクエストが表示を上書きし、本当のエラーが見えにくくなることがあります。

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

クライアントに同名のサブスクリプションが複数あると、古い項目を更新したのに別の項目で回線を選んでいることがあります。まず現在有効なサブスクリプション名を確認し、重複項目を無効にします。古いサブスクリプションが不要だと確認できた場合は、必要な新しい入口を保存してから古い項目を削除し、再インポートします。通常の削除と再読み込みで復旧しない場合を除き、クライアントのデータディレクトリ全体を削除しないでください。削除する場合も、必要な情報を記録してから行います。

更新後も回線名が変わらないからといって、更新失敗とは限りません。サービスが回線内部のパラメータだけを調整する場合があります。クライアントに表示される更新時刻、更新メッセージ、実際の接続結果を総合して判断してください。サブスクリプションログを確認できるクライアントでは、リクエスト失敗か解析失敗かを記録できます。ただし公開スクリーンショットに完全なアドレスを表示しないでください。リンクの認証情報が公開された場合は、使い続けるのではなく、パネルからアカウントの安全対策をやり直してください。

台数無制限とデバイス状態を正しく理解する

5TVPNは台数制限なく利用でき、ユーザーが固定のデバイス枠を計算する必要はありません。クライアントがデバイス数超過やログインデバイス異常を表示した場合は、その表示が5TVPNのユーザーパネルからのものか、クライアント自身のローカル設定、アプリストアアカウント、システム接続制限からのものかを確認します。プラットフォームによっては、同時に複数のアプリがシステム接続入口を使うことを制限します。これはデバイスのシステム層における排他であり、サブスクリプションのデバイス数制限とは異なります。

同じデバイスに複数のクライアントをインストールしている場合、アカウントが台数無制限でも、システムが現在のネットワークを制御できるクライアントは通常1つだけです。現在のクライアントを閉じる前に正常に切断し、その後別のクライアントを起動します。強制終了すると、古いプロキシ、接続設定、ルーティングが残り、新しいクライアントが使用中と表示したり接続に失敗したりすることがあります。モバイルシステムに複数の接続設定がある場合は、どれが有効かを明確にしてください。

デバイス間の結果をどう活用するか

台数無制限は診断に適した比較条件になります。同じサブスクリプションが別のデバイスで同じネットワークなら正常な場合、アカウントとネットワーク入口はおおむね利用可能で、元のデバイスのクライアントとシステム設定を重点的に確認します。同じデバイスでネットワークを変えると正常になる場合は、元のネットワークに近い問題です。すべてのデバイスとネットワークで更新できない場合に、アカウント状態の確認や問い合わせを優先します。比較時に実際のサブスクリプションリンクを信頼できないデバイスへコピーしないでください。

更新失敗が続く場合、問い合わせにはプラットフォーム、クライアントでの操作入口、表示されたメッセージの原文、古い回線が使えるか、ネットワーク変更後の結果、パネルからコピーし直した後に改善したかを記載します。パネル自体にアクセスできない場合は、直接接続時と接続済み状態での違いも書いてください。これにより、アカウント状態、入口へのアクセス、クライアントの解析問題をすばやく切り分けられます。

ブラウザーは正常なのに特定のAppへアクセスできないのは、典型的な局所問題です。回線自体は利用できるものの、対象アプリが同じ通信経路に入っていない可能性があります。ルーティングルールがそのアプリやドメインを直接接続と判定している、アプリが独自のネットワークプロトコルを使っている、システムプロキシが一部の通信しか対象にしていない、アプリに接続前の古いセッションが残っているなどが原因です。この場合、アカウント変更やクライアント全体の再インストールを先に行わず、対象アプリを中心に比較します。

まずアプリが古い接続を再利用していないか確認する

クライアントが接続を確立する前から開いていたアプリは、古い接続プールを使い続けることがあります。まず対象アプリを完全に終了し、バックグラウンドプロセスも終了したことを確認してから、回線に接続して再び開きます。これで復旧するなら、古いセッションが再構築されていなかっただけです。動画、チャット、ゲームランチャー、クラウド同期ツールは接続を長時間保持しやすく、回線を切り替えただけでは出口がすぐ変わらないことがあります。

再起動しても異常が続く場合は、同じサービスのウェブ版をテストします。ウェブ版は正常でAppだけ異常なら、アプリのルーティング、システムプロキシの対象範囲、アプリキャッシュを重点的に確認します。ウェブ版とAppの両方が異常なら、対象サービスの地域、回線出口、DNSの可能性が高くなります。地域に合う回線へ切り替えて再テストし、アプリの問題と地域の不一致を混同しないでください。

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

システムプロキシは通常、システムプロキシ設定に従うアプリだけに影響します。アプリによってはシステムプロキシを読み取らず、直接ネットワーク接続を行うため、ブラウザーは使えてもそのアプリは直接接続に失敗します。仮想ネットワークモードはより広範なシステム通信を制御できますが、システム権限が必要で、ファイアウォール、フィルター、他のネットワーク拡張と競合する場合があります。診断時はまず現在のクライアントモードを確認し、必要な場合だけ切り替えてください。複数の制御方式をむやみに重ねないでください。

より広い範囲を制御するモードへ切り替えた後は、対象アプリを再起動し、ローカルサービスが正常か確認します。たとえばLANプリンター、ファイル共有、ローカルデバイス管理には直接接続ルールが必要な場合があります。ルーティングの目的はすべての通信を無差別に転送することではなく、国際ネットワークが必要な対象を回線へ入れつつ、ローカルネットワークへのアクセスを残すことです。ルールを変更するときは、対象範囲をできるだけ明確にします。

ルールのマッチ方向を確認する

クライアントにルールモード、グローバルモード、直接接続モードがある場合は、短時間の診断としてグローバルモードを使います。グローバルモードでは対象アプリが復旧し、ルールモードでは失敗するなら、問題はルールのマッチングにあります。グローバルモードでも失敗するなら、アプリのプロトコル、回線地域、システムネットワークを続けて確認します。診断後は日常利用に適したモードへ戻し、短時間のテスト設定を恒久的に使わないでください。

ルールは、ドメイン、ネットワークアドレス、アプリプロセス、対象地域などを基準に判定することがあります。1つのAppがログイン、API、画像、動画、更新など複数のドメインへ接続することもあります。メインサイトのドメインだけを追加すると、ページの枠組みは開いても内容が読み込めない場合があります。クライアントの接続ログで対象アプリと同時に現れるリクエストを確認し、直接接続と判定されたもの、回線へ入ったものを把握します。ログは診断にのみ使い、アカウント識別子や完全なリクエストパラメータを含む内容を公開しないでください。

アプリ内蔵DNSと暗号化名前解決

一部のブラウザーやアプリは独自の名前解決機構を使い、システムDNSを迂回することがあります。システム上の他のアプリは正常なのに対象アプリだけドメインエラーが続く場合は、独自の安全DNS、プライベートDNS、実験的ネットワーク機能が有効になっていないか確認します。診断中は一時的に既定値へ戻し、クライアントとシステムが同じ名前解決経路を使うようにします。復元後はアプリを再起動し、古い名前解決キャッシュの影響を避けます。

AndroidのプライベートDNS、ブラウザーの安全な名前解決、クライアントのリモート名前解決を同時に有効にすると、異なる出口が生まれる可能性があります。iOSでも、一部のネットワーク拡張やコンテンツフィルター設定が名前解決に関与します。デスクトップのブラウザー拡張が独自にプロキシを指定することもあります。原則は同じです。まず中間層を減らし、既定の経路を検証してから追加機能を1つずつ戻します。

アプリストア、ストリーミング、AIツールの違い

アプリストアはアカウント地域、システム地域、現在の出口を同時に参照することがあり、回線を切り替えるだけではログイン済みアカウントの内容が変わらない場合があります。ストリーミングサービスも地域セッションと再生キャッシュを保存するため、回線切り替え後はアプリを開き直す必要があります。AIツールでは、ログイン、API、静的リソースが異なるドメインに分散していることがあります。ルールの一部が抜けると、ログインは成功するのに会話できない、ページは開くのに内容が返らないといった局所的な症状が出ます。

スポーツライブやリアルタイム性の高いアプリでは、「プロキシを通っていない」のか「プロキシは通っているが遅延が合わない」のかも分ける必要があります。前者はグローバルモードで復旧することが多く、後者はより近い、または対象に合う回線を選ぶ必要があります。低遅延の場面での判断順序はスポーツライブ向け回線の選び方を参照してください。iOS特有の読み込みやシステム設定の問題は、iOSクライアントとサブスクリプションの読み込み手順を確認できます。

この種の問い合わせでは、アプリ名、プラットフォーム、ウェブ版が正常か、グローバルモードとルールモードの違い、使用した回線地域、アプリを完全終了した後に復旧したかを記載します。「特定のAppが使えない」だけでは不十分です。どの経路でだけ問題が起きるかを示せるほど、ルールや出口の問題を特定しやすくなります。

自己診断の目的は、すべての問題を一人で解決することではありません。まず一般的なローカル要因を除外し、残った問題を再現可能な技術条件として説明できるようにします。基本的な比較を終えた後、異なるネットワークで複数の回線が失敗する、サブスクリプションを継続して更新できない、同じ回線で複数のデバイスに同じ異常が出る、または問題が特定の回線に安定して追随する場合は、ユーザーパネルから問い合わせを送るのが適切です。5TVPNの問い合わせ入口はユーザーパネルにあり、送信前にアカウント認証情報を公開する必要はありません。

そのまま問い合わせを送るのに適したケース

クライアントで同じエラーを安定して再現でき、直接接続の確認、ネットワーク変更、回線変更、クライアント再起動も完了している場合、同じ操作を繰り返しても情報は増えません。問い合わせを送ってください。回線一覧が空でパネルから再インポートしても失敗する、異なるネットワークでも接続を確立できない、特定の回線が継続して使えない、複数のデバイスで同じサブスクリプション解析エラーが出る場合も、サポートへ確認を依頼するのに適しています。

月額サブスクリプション、データパック、支払い状態、返金に関する問題は、パネルの注文と問い合わせ手順から処理します。5TVPNはAlipay、WeChat、USDTに対応し、14日間の無条件返金を提供しています。問い合わせには注文ページに表示される現在の状態を記載しますが、支払い情報に含まれる機密情報はアップロードしないでください。プランの詳細はプランページで確認できます。月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中のアップグレード差額は残り日数に応じて計算されます。データパックは使い切るまで有効で、無期限です。パネルの表示が想定と異なる場合は、パネルの注文状態のスクリーンショットを添付してください。

処理可能な問い合わせに含める内容

問い合わせのタイトルには、症状とプラットフォームを記載します。たとえば「macOSで接続成功後、すべてのウェブが開けない」「Androidで画面ロック後、接続を手動で復旧する必要がある」などです。本文では、最初に問題を確認した状況を書き、現在も安定して再現するかを続けて説明します。その後、プラットフォーム、ネットワークの種類、クライアントの現在のモード、回線名、エラーメッセージの原文、実施した比較操作を列挙します。最後に、一時的に復旧する操作と、効果がなかった操作を明確にします。

スクリーンショットには十分な前後関係を含めます。クライアントのエラー画面には、接続状態と回線名も表示するのが理想です。サブスクリプション更新画面には更新入口とエラー情報を表示しますが、完全なサブスクリプションアドレスは必ず隠してください。ウェブのエラー画面にはドメインとブラウザーのメッセージを残し、個人情報は削除します。ログを送る場合は、問題の前後に関係する部分だけを切り出し、長期間の履歴、ユーザー名、リクエストパラメータを含む完全なファイルをそのままアップロードしないでください。

問題の症状：
使用プラットフォーム：
現在のネットワーク：
選択した回線：
クライアントモード：
エラーメッセージ：
安定して再現できるか：
回線変更後の結果：
ネットワーク変更後の結果：
サブスクリプション再インポート後の結果：
一時的な復旧方法：

テンプレートの項目は実際の状況に合わせて記入し、該当しない項目は「該当なし」と説明してください。推測で埋めないでください。特に「サーバー障害」と自己判断して結論だけを送るのではなく、観察した根拠も添えます。サポートは、障害が回線、ネットワーク、デバイス、アプリのどれに追随するかを把握して初めて、回線入口、サブスクリプション内容、プラットフォーム設定のどこを確認すべきか判断できます。

問い合わせに入れてはいけない情報

アカウントパスワード、完全なサブスクリプションリンク、支払い用パスコード、他のサービスのログイン認証情報を送信しないでください。接続問題の診断に通常これらは必要ありません。アカウントの確認が必要な場合は、ログイン済みのユーザーパネルからのみ送信してください。問い合わせのスクリーンショットを公開コミュニティへ転送するのも避けます。ユーザー名、注文状態、回線名、デバイス情報が含まれる可能性があります。

ログにはネットワークアドレス、アクセス先ドメイン、ローカルパスが含まれることがあります。送信前に内容を読み、問題発生付近の部分だけを残してください。項目が機密情報か分からない場合は、まず文章の説明とエラー画面だけを送り、必要な診断資料をサポートへ確認します。必要最小限の原則は、アカウントを守るだけでなく、無関係な情報による診断の妨げも減らします。

問い合わせ送信後の再テスト方法

送信後は、できるだけ再現環境を維持し、すぐにクライアントを削除したり、システムをリセットしたり、すべての設定を変更したりしないでください。サポートから回線切り替え、サブスクリプション更新、既定設定への復元を求められた場合は、操作を1つ完了するたびに結果を記録し、元の問い合わせへ返信します。同じ問題で問い合わせを複数作成しないでください。経緯が分散します。問題が自然に復旧した場合も、復旧時刻、ネットワークや回線を変更したかを追記し、一時的な状態か設定変更によるものか判断できるようにします。

サポートから一時的な代替回線を案内された場合は、まず現在の状況を安定して解決できるか確認してから、元の回線の診断を続けるか決めます。夜間、モバイルネットワークの切り替え、特定Appの問題では、再テストを元の発生条件に戻す必要があります。異なる条件で正常だっただけでは、問題が解決した証拠になりません。問い合わせを終了する前に、障害の範囲、現在使える方法、再現が続いているかを明確にしてください。

診断後の設定整理

問題が解決したら、重複するサブスクリプションと使わなくなった古いクライアントを削除し、必要な省電力方針とプライバシー設定を戻し、既知の正常な回線を1本、今後の基準として残します。診断のために有効にしたグローバルモード、広すぎるルール、不要なシステム権限を長期間残さないでください。ブラウザー拡張、ネットワークフィルター、別のプロキシツールが原因だった場合は、競合した組み合わせを記録し、後で同時に有効にしないようにします。

ユーザー名とパスワードも適切に保管してください。5TVPNはメールアドレスなしで登録できるため、アカウント復旧はユーザー自身によるログイン認証情報の保管により大きく左右されます。サブスクリプションリンクも同じくアカウント認証情報として管理します。新しいデバイスで使う場合は、ユーザーパネルから再取得し、公開チャット履歴や他人からの転送に頼らないでください。クライアントの入口はユーザーパネルから取得します。

このガイドは体系的な切り分けを目的としています。クイックインストールと初回読み込みは使い方ガイドを、回線の地域とタイプはノードページを、料金、通信量、支払い情報はプランページとユーザーパネルを基準にしてください。この順番で進めれば、不要な再インストールを避けながら、サポートにも十分な前後関係を伝え、問題を具体的な層まで絞り込めます。