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

再現可能なトラブル診断方法を確立する

ネットワーク問題は、複数の工程が似た症状を示すため、誤って判断しやすいものです。クライアントに接続失敗と表示されても、ローカルネットワークの一時的な障害、システム時刻のずれ、サブスクリプション未更新、経路への到達不能、古いネットワーク拡張がインターフェースを使用していることなどが原因として考えられます。接続済みと表示されてもWebページを開けない場合があり、ブラウザーのプロキシ、DNSキャッシュ、振り分けルール、アプリ独自の接続再利用が古い経路を使い続けている可能性があります。有効な確認方法は接続ボタンを繰り返し押すことではなく、経路全体を分解し、入力、処理、出力を順に確認することです。

開始前に、現在の状態をそのまま記録してください。使用中のプラットフォーム、クライアント名、現在のネットワーク種別、選択した経路、問題が発生し始めたおおよその時刻、画面に表示された完全なエラー、サービス切断後に通常のWebサイトへアクセスできるかを書き留めます。先に設定を消去したり、すぐに再インストールしたりしないでください。元の状態を上書きすると、サブスクリプション内容、システム権限、経路選択のどれが原因か判断しにくくなります。画面からログをコピーできる場合は、まずテキストで保存してください。エラーを表示するしかない場合は、前後の文脈が分かるスクリーンショットを残しますが、送信前にユーザー名、パスワード、サブスクリプション内容を隠してください。

比較テストで原因範囲を絞る

比較テストの基本は、一度に1つの変数だけを置き換えることです。同じデバイスとクライアントを使い、まず経路を変更すれば、問題が経路側に集中しているか確認できます。経路を固定して別のローカルネットワークへ切り替えれば、現在の接続ネットワークが影響しているか判断できます。ネットワークと経路を固定し、ブラウザーと別のアプリをそれぞれ試せば、特定アプリの振り分け問題かどうか分かります。クライアント、ネットワーク、経路を同時に変更すると、復旧してもどの変更が有効だったか分からず、次回も最初から試すことになります。

「接続を確立できない」「接続は確立したがデータがない」「一部の対象にアクセスできない」「アクセスできるが安定しない」を区別することも重要です。これらは確認すべき入口が異なります。前者は権限、時刻、サブスクリプション、プロトコルを優先し、データがない場合はデフォルトルート、DNS、システムプロキシを確認します。一部の対象だけ異常ならルール、地域、アプリキャッシュを確認し、体験が不安定ならパケットロス、経路の混雑、ローカル無線環境、バックグラウンド制限に注目します。「使えない」を具体的な症状に言い換えることが、診断で最も重要な一歩になる場合があります。

まずアカウントと設定を保護する

ZJVPNはメールアドレス不要で、ユーザー名とパスワードだけで登録できます。そのため、ユーザー名とパスワードはアクセスを回復するための重要な認証情報です。確認中は、認証情報、サブスクリプション全文、トークンを含むリンクを公開の議論スペースに貼らないでください。サブスクリプションURLはアクセス認証情報に近い役割を持つため、スクリーンショットではアドレスバー、QRコード、ログに完全な内容が表示されていないか確認してください。サンプル設定には、必ず次のような明らかなダミー値を使用します。

subscription: "https://example.com/sub?token=YOUR_TOKEN"
profile: "diagnostic-copy"
dns-mode: "system"

設定をコピーして検証する場合は、未変更の元データを1部保存し、検証用コピーには分かりやすい名前を付けてください。復元時は、まずクライアントを終了してから元のコピーをインポートし、複数のネットワーク拡張を同時に有効にしないようにします。システム更新、クライアント変更、ネットワーク環境の変化の後に問題が発生した場合は、その変化も記録してください。変化の順序は、単一のエラーコードより有用な手がかりになることがあります。

基本記録が終わったら、該当する症状の章へ進みます。複数の症状が同時にある場合は、最初に失敗した箇所を基準にしてください。まず接続の確立不能を解決し、次に接続後のWebページとDNSを確認し、最後に速度と特定アプリを分析します。基礎となる接続が安定する前に行うアプリテストは、通常、診断材料として十分ではありません。

接続できない場合：権限から経路まで段階的に確認

「接続できない」とは、クライアントが接続済みの状態にならない、または接続を開始するとすぐ切断状態へ戻ることを指します。まず、失敗がクライアント内部で起きているのか、経路とのセッション確立中に起きているのかを判断します。接続を押してもシステムにネットワーク権限の確認が表示されない、またはクライアントに権限不足と明示される場合、問題は通常デバイス側にあります。接続処理がしばらく続いてからタイムアウトする場合は、ローカルネットワークから経路までの経路異常が疑われます。両者では対処の順序が異なるため、経路を変えて運任せに試すだけでは解決できません。

ローカルネットワークとシステムの基本状態を確認する

まずZJVPNを切断し、普段開ける通常のWebページへアクセスしてください。通常のWebページも開けない場合は、加速接続が現在の接続回線に依存するため、先にローカルネットワークを復旧します。接続ネットワークで規約確認やWeb認証が必要な場合は、切断状態で認証を済ませてからクライアントに戻って接続してください。オフィス、学校、ホテルなどのネットワークには、接続方式ごとに異なるルールがある場合があります。許可されたネットワーク環境で別の接続ネットワークに切り替えて比較できますが、問題のネットワークでサブスクリプションを何度も削除しても、基礎となる接続は直りません。

次に、システムの日付、時刻、タイムゾーンが正常に管理されていることを確認します。安全な接続では証明書の有効期限が検証されるため、時刻の大きなずれがハンドシェイク失敗、証明書エラー、接続直後の切断として現れることがあります。時刻を修正した後は、クライアントを完全に終了して再度開き、ネットワークコンポーネントに状態を読み直させてください。デバイスがスリープから復帰した直後なら、システムネットワークが安定するまで待ってから接続します。スリープ前に残った仮想インターフェースが一時的に利用できない場合があります。

システム権限と競合するコンポーネントを確認する

WindowsとmacOSでは、クライアントによる仮想ネットワークインターフェースの作成または使用を許可する必要があります。iOSとAndroidでは、初回使用時にVPN構成の作成を求められます。Linuxでは、ネットワークインターフェースとルートを操作する権限がクライアントにあることを確認してください。権限を拒否した後、クライアントが確認を自動表示しない場合があるため、システム設定から該当する権限を確認します。権限を有効にしたら、他の同種のネットワークツールを切断してからZJVPNをテストしてください。複数のツールがデフォルトルート、システムプロキシ、DNSを同時に変更すると、「画面上は正常なのにデータが誤ったインターフェースを通る」競合が起こります。

システム上で古いクライアント、企業向けセキュリティ接続ツール、パケットキャプチャツール、仮想マシンのネットワークコンポーネントが動作していないか確認します。これらを永久に削除する必要はありません。診断中は完全に終了し、関連するネットワーク拡張が動作していないことを確認してください。終了後に接続できるなら、1つずつ再有効化して競合元を特定します。ファイアウォールやセキュリティポリシーの確認が表示された場合は、プログラム名と出所を確認し、組織のルールに従って処理してください。テストのためにセキュリティ保護全体を無効にしてはいけません。管理対象デバイスのポリシーは管理者に確認します。

サブスクリプション、経路、プロトコルを確認する

クライアントに選択可能な経路が実際に存在し、空の構成名だけになっていないことを確認します。経路一覧が空、更新時刻が不自然、すべての項目が同時に消えた場合は、先にサブスクリプション更新の章へ進んでください。経路が存在する場合は、異なる地域の経路を比較します。ZJVPNは90+か国 / 200+経路をカバーしています。目的は連続してクリックすることではなく、「すべての経路が同じ段階で失敗する」のか「特定の経路群だけ失敗する」のかを確認することです。前者は権限、サブスクリプション、ローカルネットワークの可能性が高く、後者は特定経路の問題が考えられます。経路種別や地域選択の原則はノードページで確認できます。

クライアントに複数の接続モードがある場合は、まずサブスクリプションの既定値を使用してください。意味を理解しないままポート、転送方式、暗号化パラメーター、サーバー名を手動で変更しないでください。いずれかの項目がサブスクリプションと一致しないだけで、ハンドシェイクが失敗することがあります。設定を手動編集したことがある場合は、クリーンな構成を新規作成してサブスクリプションを再インポートし、古い構成と比較します。クリーンな構成で接続できるなら、原因はローカル変更にあり、アカウントやすべての経路を疑い続ける必要はありません。

あるネットワークではすべてタイムアウトし、別のネットワークでは正常な場合は、2つのネットワークの種別と失敗時刻を記録し、「経路が使えない」とだけ書かないでください。同じネットワークで他のデバイスは接続でき、現在のデバイスだけ接続できない場合は、権限、競合コンポーネント、クライアント設定に戻って確認します。現在のデバイスですべての経路が失敗し、他のデバイスも同じネットワークで失敗する場合は、ローカル出口やネットワークポリシーを重点的に確認します。このような交差検証で、問い合わせ対応の範囲を大きく絞れます。

接続済みなのにWebページを開けない：ルートとDNS異常を確認

クライアントに接続済みと表示されても、セッションが確立したことを示すだけで、すべての通信が正しくそのセッションに入るとは限りません。Webページを開けない場合は、ドメイン解決の失敗、デフォルトルートの未切り替え、ブラウザーが古いプロキシを使い続けている、対象サイトが現在の地域を拒否している、切り替え中にローカルネットワークの接続が失われた、といった可能性を区別します。すぐに「ノードが無効」と断定すると、確認できる工程を大量に飛ばしてしまいます。ドメイン、アドレス、複数のアプリ、複数の経路を分けてテストするのが最も有効です。

すべての対象か、一部の対象かを確認する

性質の異なる複数の通常のWebページを開き、他のアプリもインターネットに接続できるか同時に確認します。すべてのWebページとアプリでデータがない場合は、デフォルトルート、システムプロキシ、DNSを優先します。ブラウザーだけ異常で他のアプリが正常なら、ブラウザーのプロキシ、拡張機能、安全なDNSを確認します。特定のWebサイトだけ開けない場合は、対象地域、サイト自体の状態、キャッシュ、振り分けルールを検討します。単一サイトの結果でネットワーク全体を判断しないでください。対象サービスのメンテナンスでも同じ症状が出ます。

ブラウザーの独立したプロキシ拡張を無効にし、プライベートウィンドウでテストします。ブラウザーによっては古い接続プールを保持するため、システムルートが切り替わっても、既存のタブが切断前の接続を再利用することがあります。ブラウザーを完全に終了して再起動する方が、同じページを何度も更新するより確実です。プライベートウィンドウでは開けて通常ウィンドウでは開けない場合は、拡張機能、キャッシュ、サイトデータ、ブラウザー独自のDNSを確認し、経路を変え続けないでください。

DNS障害とルート障害を切り分ける

DNSはドメイン名をネットワークアドレスに変換します。解決に失敗すると、ブラウザーにはサーバーが見つからない、ドメインが存在しない、解決がタイムアウトしたなどと表示されます。ルート障害は、解決後の接続タイムアウトとして現れることが多いです。システム標準コマンドで解決結果を確認できます。以下のコマンドには認証情報が含まれないため、各プラットフォームのターミナルで実行できます。

nslookup example.com

ping example.com

traceroute example.com

システムによっては、経路追跡コマンドの名称が異なります。コマンドが使えなくても、追加ツールをインストールする必要はありません。ブラウザーのエラーとクライアントログを保存してください。また、「対象がpingに応答しない」ことをそのまま経路障害と判断しないでください。対象サーバーがこの種の要求に応答しない場合もあります。ここで確認するのは、ドメインを解決できるか、要求がローカルで即時失敗するか、切断時と接続時で結果が変わるかであり、特定の数値を得ることではありません。

ドメインを解決できない一方、既知のアドレスへ直接アクセスすると接続できる場合は、DNSに近い問題です。まずクライアントを終了してシステムのDNSキャッシュを消去し、再接続してテストします。Windowsではターミナルで次を実行できます。

ipconfig /flushdns

macOS、iOS、Android、LinuxのDNS管理は、システムのバージョン、ネットワーク管理サービス、クライアントの実装によって異なります。適用できないコマンドをそのまま使わないでください。一般的には、接続を切断し、クライアントを終了し、ネットワークを一度切り替えてから接続を再確立します。Linuxでは現在の解決状態とデフォルトルートを確認し、どのサービスが管理しているかを判断します。

resolvectl status

ip route

複数のDNS設定元が互いに上書きしないようにする

クライアント、OS、ブラウザー、ローカルネットワークはいずれもDNSを提供する可能性があります。ブラウザーで独自の安全なDNSを有効にしていると、システムが割り当てた解決経路を迂回する場合があります。クライアントが仮想DNSを有効にし、システムのネットワーク管理サービスが接続変更時に設定を上書きすると、接続直後は正常でも後から解決に失敗することがあります。診断中は変数を減らしてください。ブラウザーはシステム設定に従うよう戻し、クライアントはサブスクリプションの既定設定を使い、システムのネットワークアダプターには以前手動入力した無効なアドレスを残さないようにします。基本経路が正常だと確認してから、個別設定を1つずつ戻します。

特定のドメインだけ異常なアドレスへ解決される場合は、ブラウザーキャッシュとシステムキャッシュを消去し、経路を変えて再確認します。同じ接続ネットワークにある複数のデバイスで同じ異常が出て、ネットワークを変えると復旧する場合は、ローカルのDNS設定元を重点的に確認します。同じデバイスがどのネットワークでも異常で、他のデバイスが正常なら、現在のデバイスのブラウザー、hostsファイル、セキュリティソフト、DNS設定の可能性が高くなります。

システムプロキシとデフォルトルートを確認する

一部のクライアントはシステムプロキシでブラウザーの通信を転送し、別のクライアントは仮想インターフェースでシステムルートを制御します。クライアントが異常終了すると、システムプロキシが存在しないローカルポートのまま残り、サービス切断後もWebページを開けなくなることがあります。この場合は、システムのネットワーク設定でプロキシが手動で有効になっていないか確認します。ネットワーク解説にある公開プロキシアドレスを不用意に入力しないでください。通常は現在のクライアントが自動管理します。クライアントを再び開いて正常に切断する方が、プロセスを強制終了するより設定を戻しやすいことが多いです。

接続後にローカルネットワークのデバイスだけアクセスできず、インターネットは正常な場合、グローバルルートがローカルアドレスを制御している可能性があります。クライアントにローカルネットワークのバイパスや振り分け設定があるか確認し、既定のルールでテストしてください。インターネットとローカルネットワークの両方でデータがない場合は、デフォルトルートと仮想インターフェースの確認に戻ります。管理ネットワークの内部ドメインは組織内DNSだけが解決できる場合があり、外部経路に接続した後に解決できないのはネットワーク境界の問題です。利用可能な方法を管理者に確認してください。

速度低下と混雑時間帯の遅延を段階的に判断する

速度の問題は、1回の測定結果だけで判断できません。国際アクセスでは、ローカル接続、通信事業者の出口、経路の入口、地域間リンク、対象サービス、コンテンツ配信ネットワークを通ります。どの工程が変化しても体感に影響します。夜間の混雑による遅延は、家庭内の無線競合、対象プラットフォームの混雑、選択した地域までの距離が原因の場合もあります。診断の目的はきれいな数値を得ることではなく、ボトルネックが継続するか、どの対象で起きるか、どの条件を変えると改善するかを確認することです。

比較できるテスト条件を先に整える

切断時と接続時に、同じ安定した対象へアクセスし、デバイスの位置、接続ネットワーク、テスト内容をそろえます。複数の速度測定サイトを一度に使ったり、異なる地域、ファイル、時間帯の結果を直接比較したりしないでください。ブラウザーのダウンロード、クラウド同期、システム更新、動画再生、他のデバイスによる大容量通信はローカル帯域を消費します。テスト前に一時停止してください。無線環境では接続機器に近づき、遮蔽物や頻繁なローミングを除外します。

切断時から遅い場合は、まずローカルネットワークを確認します。切断時は正常で、すべての経路が遅く、接続ネットワークを変えると改善するなら、元のローカル出口の可能性が高くなります。特定地域の経路だけ遅く、近隣地域に変えると改善する場合は、用途に合う経路を選びます。特定のコンテンツプラットフォームだけ遅く、通常のWebページ、ファイルのダウンロード、他の動画サービスが正常なら、対象プラットフォームの地域設定、キャッシュノード、アカウント地域を検討します。ネットワーク全体の速度低下と決めつけないでください。

遅延、スループット、安定性の違いを理解する

遅延は操作への応答速度、スループットは継続的な転送量、安定性は接続に揺らぎ、再送、停止が発生するかを左右します。Webページの表示が遅い場合は、名前解決や最初の接続の遅延が原因かもしれません。動画の再生開始後に頻繁にバッファリングするなら、継続的なスループットやパケットロスに近い問題です。オンライン会議の音声が途切れる場合は、短時間の最大帯域より安定性が重要です。1回のダウンロードが速くても、リアルタイムアプリが安定するとは限りません。実際の用途に沿って症状を記録し、速度測定のスクリーンショットだけを送らないでください。

経路までの距離は、通常、往復経路に影響します。日本の対象へアクセスする場合は、距離が近く利用可能な地域を選ぶ方が合理的です。一方、欧州の対象では、入口が近いことが対象側までの最短経路を意味するとは限りません。ZJVPNは90+か国 / 200+経路をカバーしています。選択時は、まずノードの説明にある地域と経路種別を参考にし、実際の対象で比較してください。頻繁な切り替えは接続プールやコンテンツキャッシュを中断するため、変更後はアプリがセッションを再確立するまで待ち、一定時間使ってから判断します。

混雑時間帯の問題を記録する方法

混雑時間帯の問題には時間帯との相関があります。日中に正常だった結果を1枚送るだけでは再現できません。正常な時間帯と異常な時間帯に同じ作業を行い、経路名、接続ネットワーク、対象サービス、おおよその時刻を記録してください。異常な時間帯に別の経路へ変えるとすぐ改善し、ローカルの通常ネットワークが正常なら、2つの経路を明確な比較結果としてサポートへ提供できます。すべての経路と通常ネットワークが同時に遅くなる場合は、ローカル接続の混雑がより疑われます。

大容量ダウンロードを何度も更新したり、複数の速度測定を同時に実行したりして経路を「負荷テスト」しないでください。ローカル環境自体が変数になり、プランの通信量を消費する可能性もあります。月額サブスクリプションの通信量は開通日を基準に毎月リセットされます。通信量パックは使い切るまで有効で、期限はありません。確認前にアカウント概要で現在の利用状況を確認し、通信量の状態と速度問題を混同しないようにしてください。プランの詳細はプランページで確認できます。

ストリーミングと大容量ファイルの利用

ストリーミングアプリは、前回のセッションの地域やコンテンツ配信ノードをキャッシュすることがあります。経路を変更しても画質や地域設定が変わらない場合は、アプリを完全に終了し、必要に応じてキャッシュを消去してから再起動してください。再生中に経路を連続して切り替えるのは避けます。プラットフォームの選択や地域判定については、ストリーミングの地域設定ガイドを参照してください。Macでネットワーク拡張、システム権限、Appleサービスの併用が主な問題なら、Mac VPNのおすすめと選び方にある確認方法も役立ちます。

大容量ファイルのダウンロードでは、開始直後ではなく継続的な安定性を確認します。ダウンロード元は、アカウント、地域、サーバーによって速度を制限することがあります。異なる信頼できるソースで比較できますが、出所不明のテストファイルは使わないでください。Web閲覧が正常で特定のダウンロード元だけ遅いなら、まず対象側を確認します。複数の信頼できる対象が同じ経路で継続的に遅い場合は、経路、時刻、対象種別を問い合わせに整理してください。

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

頻繁な切断では、まず能動的な切断と受動的な中断を区別します。能動的な切断は、システムのスリープ、ネットワーク切り替え、省電力設定、クライアントの自動ルール、ユーザー操作によることが多く、受動的な中断は無線信号の変化、ローカル出口の再接続、経路セッションの異常、クライアントのネットワーク拡張のクラッシュなどが原因になります。画面上はどちらも「切断」と表示されることがありますが、ログの時系列は異なります。診断では、切断後のエラーだけでなく、切断前にデバイスで何が起きたかを記録してください。

切断を引き起こす条件を確認する

まず、画面ロック、スリープ、無線ネットワークの切り替え、アプリを離れた操作、外部ネットワークへの接続、システム復帰と切断が関係しているか確認します。画面ロック後に毎回発生するなら、バックグラウンド動作と省電力制限を確認します。無線からモバイルネットワークへ切り替えたときに発生するなら、基礎インターフェースの変化です。クライアントが自動再接続できるか観察してください。画面を点灯したままネットワークも変えずに周期的に切断するなら、経路、クライアントログ、システムネットワークコンポーネントを確認します。切断回数より、引き金になった操作を具体的に書く方が再現しやすくなります。

デスクトッププラットフォームでは、システムのスリープによってネットワークインターフェースが一時停止します。復帰後は古いセッションが無効になり、クライアントが接続を再確立する必要があります。画面上は接続中でもデータがない場合は、まず手動で切断してから接続し、すぐにデバイスを再起動しないでください。復帰のたびに回復できない場合は、他のネットワーク拡張が同時に動作していないか、クライアントの復帰前に別のプログラムがシステムプロキシを上書きしていないか確認します。企業管理デバイスでは、復帰後にセキュリティポリシーが再適用されることもあるため、組織の環境と合わせて判断してください。

モバイル端末のバックグラウンド設定

iOSとAndroidは、バッテリー残量、メモリ、ネットワーク状態、アプリの利用状況に応じてバックグラウンドプロセスを管理します。クライアントがシステムによって停止されると、画面には古い状態が残っていても、接続は再構築が必要になります。システム設定でクライアントが通常どおりバックグラウンドで動作できるようにし、強制終了対象のアプリ一覧に入れないでください。Android端末のメーカーごとに省電力設定は異なるため、システム設定のバッテリーとバックグラウンド管理を基準にします。基本操作はAndroid VPNのインストールから確認までも参照できます。

複数の自動接続ルールを同時に有効にしないでください。システムのオンデマンド接続、クライアント起動時の自動接続、ネットワーク切り替え時の自動接続が同時に動作すると、インターフェースの変化をきっかけに互いを呼び出し、接続と切断のループになることがあります。診断中は自動設定を1種類だけ残し、他は一時的に無効にします。手動接続が安定したことを確認してから、自動設定を1つずつ戻してください。特定の無線ネットワークだけで問題が起きる場合は、そのネットワークで再認証が必要か、アイドル時に接続が回収されるか確認します。

経路の切断とローカルインターフェースのリセットを区別する

経路が切断された場合、ログには通常、リモート接続の終了、ハンドシェイクのタイムアウト、再接続の処理が現れます。ローカルインターフェースのリセットでは、ネットワーク変更、ルート消失、アドレス更新、システムネットワークサービスの再起動を伴う可能性が高くなります。すべてのログを解釈する必要はありませんが、切断前後の連続した部分を保存してください。最後の1行だけを切り取らないでください。それは再試行の失敗にすぎず、本当の原因は前にある場合があります。

同じネットワークで経路を変更して観察できます。すべての経路が画面ロック、スリープ、ネットワーク切り替え後に切断されるなら、まずシステム設定を確認します。デバイスを操作中でも特定の経路だけ中断し、他の経路が安定している場合は、経路名を記録して一時的に別の経路を使ってください。接続ネットワークを変えると問題が消えるなら、元のネットワークの信号、認証、出口の変化を重点的に確認します。同じ接続ネットワークにある複数のデバイスが同時に中断する場合は、ローカルネットワークや上流経路が疑われます。

復旧時は接続ループを避ける

再接続が連続する場合は、まず自動接続を無効にし、手動で切断してシステムネットワークが正常に戻るまで待ってから、接続を1回だけ確立します。スイッチをすばやく何度も押さないでください。接続と切断の要求が同時に処理されると、画面の状態がシステムの状態に追いつかなくなることがあります。クライアントを停止できない場合は、アプリを通常どおり終了し、システムのVPN設定で構成が切断されていることを確認します。ネットワークインターフェースが明らかに残り、通常のWebページにも影響がある場合に限り、デバイスの再起動を検討してください。

再起動後はいったん復旧しても、特定のアプリを起動したり、特定のネットワーク環境に入ったりすると再発する場合は、引き続き発生条件を比較します。再起動はその場の状態を消しただけで、根本原因が解決したとは限りません。「再起動で復旧する」と「条件を満たすと再発する」を問い合わせに併記すると、リソースの残留、クライアントの競合、経路の問題を切り分けやすくなります。システム更新直後なら、更新前後の違いも記録しますが、具体的なバージョンの欠陥だと推測しないでください。

サブスクリプション更新失敗とデバイス状態の確認

サブスクリプションの更新失敗は、設定をダウンロードできない、経路一覧が空、更新時刻が変わらない、インポート直後に形式エラーが出る、古い経路は残るが新しい内容が表示されない、といった形で現れます。ここでは、アカウントへのアクセス、サブスクリプションURL、クライアントの解析、ローカルキャッシュ、プランの状態を区別します。サブスクリプションは設定への入口であり、経路接続そのものではありません。内容を正しく取得できていないなら、経路を試し続けても意味がありません。

入口とアカウント状態を確認する

まずユーザーパネルからサブスクリプションを取得し、チャット履歴、過去のスクリーンショット、公開ページに保存された古いURLは使わないでください。ZJVPNはメールアドレス不要で、ユーザー名とパスワードだけで登録できます。ログイン情報を忘れた場合は、パネルにあるアカウント手順に従い、重複アカウントを大量に作成しないでください。ログイン後に概要とプランの状態を確認し、クライアントのダウンロード入口から現在のプラットフォームに合う設定方法を取得します。

月額サブスクリプションには、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれます。通信量は開通日を基準に毎月リセットされ、期間途中のアップグレード差額は残りの日数に応じて計算されます。通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効かつ期限はありません。確認時は現在のプランが利用可能な状態かだけを確認し、残り期間を手動計算したり通信量の状態を推測したりしないでください。プラン情報が想定と異なる場合は、まずプランの説明と照合してから、注文に関する情報を添えて問い合わせます。

安全にサブスクリプションを再インポートする

現在の設定名を変更するかバックアップをエクスポートしてから、空の設定を新規作成し、最新のサブスクリプションをインポートします。これにより、問題が古いキャッシュにあるのか、サブスクリプション内容にあるのかを判断できます。古い設定でサーバーアドレスやプロトコル項目を手動で上書きしたり、異なるサービスのノードを同じ設定に混在させてからサポートに判断を求めたりしないでください。混在した設定では、ログからどの項目のリクエストか確認できません。

サブスクリプションURLをコピーするときは、余分な空白、改行、チャットアプリによる途中切れがないか確認します。URLはクライアントのサブスクリプションインポート欄へ直接貼り付け、ブラウザーの検索欄には入れないでください。公開ページにも掲載しないでください。クライアントがQRコードによるインポートに対応していても、ログイン済みのユーザーパネルから取得したQRコードであることを確認します。インポートに失敗したら、完全なメッセージを保存します。ネットワークリクエスト失敗、認証失敗、内容が空、形式解析失敗を区別することが重要です。

ブラウザーではユーザーパネルにアクセスできるのに、クライアントだけサブスクリプションを更新できない場合は、システムプロキシ、DNS、ファイアウォールがクライアントにだけ影響していないか確認します。現在の接続を切断し、通常のネットワークで更新してみてください。接続後でなければ更新できない場合は、現在利用できる経路を選んで再試行します。更新後は、単に「完了」と表示されただけでなく、経路一覧が実際に更新されたことを確認します。クライアントが古い設定のコピーを保持する場合があり、同じ名前でも内容が同じとは限りません。

キャッシュ、時刻、形式の問題

システム時刻のずれにより、サブスクリプション要求の安全な接続が失敗することがあります。経路のハンドシェイク問題と似た症状です。時刻を修正した後、クライアントを完全に終了して再試行します。クライアントが設定ではなくWebページのテキストをダウンロードした場合は、ログイン状態の失効、URLの不完全なコピー、リダイレクトなどが考えられます。Webページのソースを設定としてインポートしないでください。ログに形式エラーがある場合は、ユーザーパネルから元のサブスクリプションを再取得し、エンコード、引用符、インデントを手動編集しないようにします。

キャッシュの消去には範囲を設けてください。まずは対象サブスクリプションだけのキャッシュを削除し、クライアント全体のデータは先に消さないでください。他の有効な設定やルールまで失われる可能性があります。再インストールが必要な場合は、先にユーザー名とパスワードが使えることを確認し、残す必要がある機密性のない設定をエクスポートします。再インストール後は、クリーンなサブスクリプションを1つだけインポートして検証し、正常になってからカスタムルールを1つずつ戻します。

台数無制限でも、同じ設定を無制限に複製できるとは限らない

ZJVPNは同時接続デバイス数に制限がありません。ただし、各デバイスでは対応するプラットフォーム用クライアントと、現在有効なサブスクリプションを使用してください。「デバイス数の上限」といった表示が出ても、プランの制限だと自己判断しないでください。事実上、台数制限はありません。まず、その表示がZJVPNのユーザーパネル、現在のクライアント、他のサービスを混在させた設定のどこから出ているか確認します。古いクライアント、他サービスの設定、ローカルルールにも独自の制限表示がある場合があります。表示された画面と設定名を保存すると、サポートが出所を判断できます。

複数のデバイスで同時にサブスクリプションが無効になった場合は、アカウントとサブスクリプション入口を優先して確認します。1台だけ失敗する場合は、そのデバイスのキャッシュ、権限、クライアントを確認します。プラットフォームをまたいでインポートするときは、あるプラットフォームからエクスポートした完全なローカル設定をそのままコピーしないでください。特定のプラットフォームだけが認識できるパス、インターフェース名、ルールが含まれている可能性があります。ユーザーパネルからWindows、macOS、iOS、Android、Linuxそれぞれに合うインポート方法を取得してください。

特定のアプリだけプロキシを通らない：アプリの振り分けを確認

特定のアプリだけアクセスできず、ブラウザーや他のアプリが正常なら、経路全体が無効になっているとは限りません。よくある原因は、アプリがシステムプロキシを迂回する、振り分けルールがドメインを直接接続へ送る、アプリが独自DNSを使う、既存の接続が再構築されていない、対象サービスがアカウントや地域に基づいて追加判定する、といったものです。重要なのは、このアプリが実際にどの経路を使っているかを確認することであり、アカウントや経路を変え続けることではありません。

まずブラウザーで比較する

対象アプリの公式サイト、または同じサービスのWeb入口を見つけ、現在の経路でブラウザーからアクセスします。Webは正常でアプリだけ異常なら、基礎経路と対象ドメインには少なくとも部分的に到達できるため、次にアプリ自体を確認します。Webとアプリの両方が異常なら、対象地域、経路、DNS、サービス状態が関係している可能性が高くなります。アプリにWeb入口がない場合は、同種のネットワークリクエストを比較対象にしますが、無関係なサイトで結論を出さないでください。

アプリを完全に終了してから再起動します。多くのアプリは起動時に確立した接続を長時間再利用するため、経路を変更してもすぐに再構築されません。モバイル端末では、ホーム画面に戻るだけではプロセスが終了せず、バックグラウンドセッションが残ることもあります。再起動後はログイン状態とコンテンツが更新されるまで待ってからエラーを確認します。アプリの再起動で復旧するなら、接続キャッシュの問題であり、振り分けルールをさらに変更する必要はありません。

システムプロキシ、仮想インターフェース、アプリの迂回

システムプロキシモードでは、システムプロキシ設定に従うアプリだけがプロキシ経路に入ります。一部のアプリは直接ネットワーク接続を確立するため、ブラウザーは正常でもアプリは直接接続になります。仮想インターフェースモードはより多くのシステム通信をカバーできますが、除外ルール、ローカルネットワークのバイパス、アプリの許可リストの影響を受ける場合があります。クライアントにグローバル、ルール、直接接続モードがあるなら、診断中は対象範囲が明確なモードで短時間比較し、確認後に日常利用に適したルールモードへ戻します。

誤ったルールを隠すためにグローバルモードを常用しないでください。グローバルモードは正常でルールモードだけ異常なら、ログで対象ドメインがどのルールに一致したか確認します。ルールセットがキャッシュや更新時刻の違いにより新しいドメインを含んでいない場合や、コンテンツ用ドメインとログイン用ドメインが異なる経路に振り分けられている場合があります。アプリはメインドメインだけでなく、認証、API、画像、メディアのドメインにも接続することがあります。メインドメインだけを処理すると、ログインはできてもコンテンツを読み込めない場合があります。

ログで振り分け結果を確認する

クライアントのログを開いたら古い内容を消去し、対象アプリを起動して1回だけ症状を再現します。再現時刻の前後にあるドメイン、接続結果、ルール名を探します。ログが大量にある場合は、1日分を丸ごとコピーせず、アプリ起動前後の連続した部分だけを残します。アプリのリクエストがログにまったくない場合は、現在のプロキシ方式を迂回しているか、ログレベルが通信を記録していない可能性があります。リクエストがあり、直接接続と表示されるならルールを確認します。経路に入った後でタイムアウトするなら、他の経路と対象地域を比較します。

time: "REPRODUCE_TIME"
application: "TARGET_APP"
route: "RULE_OR_DIRECT"
result: "COPY_THE_VISIBLE_ERROR"

上のテキストは記録を整理するためのテンプレートであり、クライアントへインポートする設定ではありません。Web上の断片的なルールをもとに、範囲の広い一致項目を直接追加しないでください。広すぎるドメインの接尾辞やプロセスルールによって、無関係なアプリまで別経路になる可能性があります。変更前に元のルールを保存し、変更後は対象アプリだけをテストします。通常のWebページ、ローカルネットワークサービス、その他のよく使うアプリに影響がないことも確認してください。

アカウント地域、キャッシュ、対象側の制限

一部のコンテンツサービスは、現在のネットワーク地域だけでなく、アカウント地域、請求地域、アプリストアの地域、過去のキャッシュも参照します。経路を変えても元のコンテンツが表示されるからといって、振り分け失敗とは限りません。まずアカウントとアプリを完全に終了し、必要に応じてキャッシュを消去してから、対象地域に合う経路でテストします。ストリーミングについてはストリーミングページの地域と画質の判断を、AIツールについてはAIツールのアクセスガイドを参照してください。

アプリ内蔵のWebページは開けるのに、メディア、アップロード、リアルタイム機能が失敗する場合、機能ごとに異なるドメインや転送方式を使っている可能性があります。ログイン、一覧の読み込み、画像、再生、アップロード、リアルタイム接続のどの段階で失敗したかを分けて記録します。アプリ名だけを書かないでください。具体的な段階が分かれば、サポートは経路ログとルールの方向から確認でき、キャッシュ消去を繰り返し案内する必要がなくなります。

プラットフォーム権限とローカルネットワークの例外

Androidのアプリ別プロキシ、iOSのシステムネットワーク拡張、macOSのネットワークフィルター、Windowsのファイアウォールルールは、特定のプログラムだけに影響することがあります。対象アプリが除外されていないか、特定のネットワーク種別でのみアクセスを許可されていないか、セキュリティソフトに個別ルールがないか確認します。Linuxではコンテナ、サンドボックス、名前空間にも注意してください。隔離環境で動作するアプリは、ホストシステムの既定プロキシを使わない場合があります。

ローカルネットワークのアプリは、通常、直接接続のままにします。たとえばローカルストレージやプリンターへのアクセスです。インターネットアプリを解決するためにローカル通信をすべて経路へ送ると、ローカルサービスが使えなくなる可能性があります。ルールを変更するときは、対象ドメインとローカルアドレスを明確に区別してください。復旧後は対象アプリとローカルネットワークの両方を確認し、1つの問題を解決する過程で新たな経路競合を作らないようにします。

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

セルフチェックの目的は、すべての問題をユーザーだけで解決することではありません。すぐ確認できるローカル要因を除外し、サポートが再現できる条件を提供することです。アカウント、注文、サブスクリプション入口に異常がある場合、または基本的な比較を終えても問題が安定して再現する場合は、問い合わせを送ってください。有効な問い合わせでは、事実、時系列、比較結果を説明し、技術的な原因を推測する必要はありません。「サーバーが壊れた」と書くだけでは特定に役立ちません。どのプラットフォーム、経路、接続ネットワーク、対象で、どの操作の後にどのエラーが出たかを明確にすると、対応効率が大きく上がります。

すぐに問い合わせを送るべき状況

ユーザーパネルに有効なプランが正常に表示されない、注文状態と支払い記録が一致しない、サブスクリプション入口から明確な認証エラーが返る、またはユーザー名とパスワードが正しいのにアカウント手続きに異常がある場合は、直接問い合わせを送ってください。支払い方法はAlipay、WeChat、USDTのみです。支払いに関する問い合わせでは、パネルに表示された注文情報と状態のスクリーンショットを提供し、支払いパスワード、秘密鍵、リカバリーフレーズ、完全な支払い証明は送らないでください。プランを確認する場合は、まずプランページの月額サブスクリプションと通信量パックの説明を参照します。

接続問題では、切断状態で通常のWebページにアクセスでき、システム時刻と権限が正常で、クリーンなサブスクリプションを再インポートしても、経路と接続ネットワークを変えると同じエラーが出る場合に問い合わせが適しています。特定の経路群で複数のネットワークにわたり同じ異常が再現し、他の経路が正常なら、正常な経路を比較対象として記載してください。速度問題では、正常と異常の時間帯、対象の種類、選択した経路を少なくとも提供し、再現できないスクリーンショット1枚だけを送らないようにします。

特定アプリの問題では、まずブラウザーでの比較とアプリの再起動を行います。ログでリクエストが経路に入ったことを確認でき、経路を変えても同じ段階で失敗するなら、対象アプリ、失敗した機能、対象地域、秘匿化したログを送信できます。ログにリクエストがまったくない場合は、ローカルの振り分けやプロキシ適用範囲の問題が考えられるため、クライアントのモードとアプリが除外されているかどうかも説明してください。

問い合わせ情報のチェックリスト

以下のテンプレートで問い合わせ本文を整理できます。テンプレート内の大文字部分は自分の状況に置き換えますが、ユーザー名とパスワード、完全なサブスクリプションURL、その他の機密情報は入力しないでください。

問題の種類：CONNECT / DNS / SPEED / SUBSCRIPTION / APP
使用プラットフォーム：PLATFORM
クライアント：CLIENT_NAME
選択した経路：ROUTE_NAME
発生時刻：REPRODUCE_TIME
問題の症状：VISIBLE_ERROR_AND_FAILED_STEP
切断状態：NORMAL_OR_ABNORMAL
経路変更の結果：CONTROL_RESULT
ネットワーク変更の結果：CONTROL_RESULT
試したこと：ACTIONS_ALREADY_TAKEN
添付ファイル：REDACTED_SCREENSHOT_AND_LOG

ログの秘匿化方法

送信前に、ログ内のサブスクリプションURL、token、ユーザー名、パスワード、QRコードの内容、ローカルファイルのパスを検索します。サブスクリプションURLは全体を削除するか「非表示」に置き換えてください。末尾だけを隠すのは不十分です。前半にもアカウント情報が含まれる可能性があります。公開アドレスを隠す必要があるかは障害の種類によって判断します。不明な場合は、問い合わせに秘匿化済みであることを記載し、サポートから必要最小限の追加情報を確認してください。スクリーンショットでは、ブラウザーのタブ、通知バー、クリップボードのポップアップ、他のアプリのウィンドウも確認します。

ログには文脈を残す必要があります。「接続失敗」の1行だけでは原因判断に不十分なことが多いため、接続開始、経路選択、ハンドシェイク、ルート、DNS設定から失敗までの連続した過程を含めてください。問題と無関係な長時間のログもアップロードしないでください。情報が多すぎると重要なイベントが埋もれます。再現を始める前にログを消去し、1回の操作を最後まで行い、失敗直後に停止してエクスポートするのが最も適切です。

サポート回答後の確認方法

対応案を受け取った後も、一度に1項目だけ実行してください。サブスクリプションの再インポートを勧められた場合は、古い設定を残してクリーンな設定を新規作成し、テストします。経路変更を勧められた場合は、ネットワークと対象を固定します。振り分けの調整を勧められた場合は、現在のルールを先に保存します。復旧後は、元の失敗条件を逆向きに確認し、本当に問題が消えたのか、対象サービスが一時的に復旧しただけなのかを確かめてください。確認結果は元の問い合わせへ返信し、同じ内容の問い合わせを複数作って文脈を分散させないようにします。

提案が有効でなかった場合は、実行結果、時刻、新しいログを補足してください。背景を最初からすべて再送する必要はありません。症状が「接続できない」から「接続できるがDNSに異常がある」などに変わった場合は、症状が変化したことを明確に説明し、該当する章に戻って基本比較を行います。障害の変化自体が重要な手がかりです。

診断後の設定を整理する

問題が解決したら、検証中に作成した無効な設定を削除し、必要な自動接続と振り分けルールを戻します。システムプロキシ、DNS、ローカルネットワークへのアクセスが想定どおりの状態にあることも確認してください。クリーンなサブスクリプション設定を基準として1つ保存しますが、サブスクリプション本文を公開クラウド文書やチャットグループに保存しないでください。複数のデバイスで使用する場合は、Windows、macOS、iOS、Android、Linuxそれぞれに競合コンポーネントが残っていないことを確認します。

今回の問題が誤った設定に関係していた場合は、最終的に有効だった設定名、手順、発生条件を自分のメンテナンス記録に残します。次に似た症状が出たときは、同じ発生条件かどうかを先に確認し、すべての手順を機械的に繰り返さないでください。長期利用者にとって、短く正確で検証済みのローカル記録は、出所不明のネットワーク解説を大量に保存するより信頼できます。