VPNトラブルシューティング大全

再現可能な確認基準を作る

原因を推測する前に症状を整理する

接続トラブルが長引く最大の原因は、最初から回線、クライアント、アカウントのせいだと決めつけ、複数の設定を続けて変更してしまうことです。変更箇所が多いと、接続が戻っても本当に効果があった手順が分かりません。まず、クライアントが接続済みと表示するか、ブラウザーで通常のウェブページを開けるか、国際サービスだけが失敗するのか、すべてのサイトが失敗するのか、他のデバイスでも同時に起きるのか、回線を切り替えると結果が変わるのかを記録しましょう。症状を具体的にするほど、次に進む分岐を減らせます。

確認時は、追加拡張機能や複雑な振り分けルールのないテスト環境を用意します。ブラウザーは新しい一時ウィンドウ、クライアントはデフォルトルールを使い、システム上で通信経路を変更する他のツールは一時的に終了します。目的は利用方法を恒久的に変えることではなく、単純な基準を作ることです。基準環境でアクセスできるなら、問題はブラウザー拡張機能、カスタムルール、アプリのプロキシ、複数のネットワークツール間の競合にある可能性が高くなります。基準環境でも失敗する場合は、ネットワークとサブスクリプションを続けて確認します。

問題を1つの層まで絞り込む

接続には複数の段階があります。ローカルネットワークがリクエストをクライアントへ送り、クライアントがルールに従って直接接続かプロキシかを決め、サブスクリプション内の回線でセッションを確立します。さらにドメインはDNSで解決され、最後に対象サービスがコンテンツを返します。どこか1つに異常があるだけでも「開けない」という症状になります。したがって、クライアントの接続アイコンだけを見てはいけません。アイコンが示すのはセッションの確立であり、ブラウザー、システムプロキシ、DNS、個別アプリが同じ経路で動作していることまでは意味しません。

一度に変更する変数は1つだけにする

比較は「ネットワーク、回線、モード、アプリ」の順に行うことをおすすめします。まずクライアントと回線を固定してローカルネットワークだけを変更し、次にネットワークを固定して回線だけを切り替えます。その後でルールモードを調整し、最後に個別アプリを確認します。各操作の後は同じアクセス手順を繰り返し、結果を記録してください。クライアントの再インストール、DNSの変更、回線の切り替え、ルーターの再起動を同時に行うと、有効な結論を残せません。

テスト対象も固定します。通常のウェブページ、国際回線が必要なウェブページ、普段使うアプリを1つずつ固定サンプルにするとよいでしょう。メンテナンス中、再ログインが必要、地域によって異なるページを返すサービスを唯一の判断材料にしないでください。通常のページは開けるのに国際ページだけ失敗するなら、まずルールと回線を確認します。両方失敗するなら、システムプロキシとDNSを優先します。ページは開けるのにアプリだけ失敗するなら、問題はアプリ層にある可能性が高いです。

まずアカウントとサービスの事実を確認する

ZVVPNはユーザー名とパスワードだけで登録でき、メールアドレスは不要です。ユーザーパネルにログインしたら、まずプランまたはデータパックがまだ利用可能か確認し、現在のサブスクリプションを取得します。月額サブスクリプションには複数のデータ容量があり、データは開通日を基準に毎月リセットされます。データパックは使い切るまで利用でき、期限はありません。ページに表示されたサブスクリプションの状態とクライアントのキャッシュが一致しない場合は、ユーザーパネルを基準に再インポートし、古いキャッシュで接続を繰り返さないでください。

回線は 120+か国 / 170+回線をカバーし、Windows、macOS、iOS、Android、Linuxに対応しています。利用デバイス数に制限はありません。ただし、1台のデバイスで複数のプロキシクライアントを同時に動かしてよいという意味ではありません。複数のクライアントがシステムプロキシや仮想ネットワークインターフェースを奪い合うことは、よくある競合原因です。プラン内容を比較する場合はプランとデータルールを、地域と回線タイプを確認する場合はグローバル回線ガイドをご覧ください。

まったく接続できない場合の判断手順

「クライアントが開かない」と「回線に接続できない」を分ける

クライアントが起動しない、起動後に画面が空白になる、システムがネットワーク権限の不足を通知する場合と、接続をクリックした後に回線がタイムアウトする場合は別の問題です。前者はインストールの完全性、システム権限、セキュリティポリシーを先に確認し、後者でネットワークと回線の診断に進みます。クライアントにサブスクリプション内の地域が正常に表示されるのに、どの回線にも接続できない場合、少なくともサブスクリプションは読み込まれています。この場合は、現在のネットワークが接続方式を制限していないか、別のクライアントがネットワークインターフェースを使用していないかを優先して確認します。

他のプロキシ、ネットワークフィルター、企業接続、通信分析ツールを完全に終了してから、ZVVPNクライアントを再起動します。ウィンドウを閉じただけではバックグラウンドサービスが終了しない場合があるため、システムトレイ、メニューバー、プロセス管理画面で関連プログラムが終了していることを確認してください。その後はデフォルトルールを使い、追加設定を読み込まず、異なる地域の回線を選んでテストします。1本が失敗して別の1本が成功するなら、クライアントの基本機能は正常で、問題は回線の到達性に絞られます。すべて失敗するなら、ローカル接続ネットワークを変更します。

ネットワークを変更してローカル接続の問題を判定する

家庭のブロードバンド、オフィスネットワーク、公共ネットワーク、モバイルネットワークでは、出口のポリシーが異なる場合があります。接続に失敗したとき、回線を大量に切り替え続けるより有効なのは、クライアントとサブスクリプションを固定したまま別のネットワークで比較することです。ネットワークを変えると接続できる場合、元のネットワークにルーティング異常、ゲートウェイキャッシュ、企業ポリシー、ローカル機器の設定問題がある可能性があります。この場合は、クライアントの再インストールより、ネットワーク機器の再起動、ネットワーク設定の再取得、システム時刻の確認が有効なことがあります。

システム時刻のずれは安全なセッション確立に影響します。日付、時刻、タイムゾーンを自動同期に設定し、クライアントを完全に終了してから起動してください。企業管理環境のデバイスでは、組織が配布したネットワークプロファイルや証明書ポリシーがインストールされていないかも確認します。業務用デバイスの管理設定を勝手に削除せず、利用可能な範囲をネットワーク管理者に確認してください。個人デバイスで古いクライアントを使っていた場合は、古い仮想ネットワークインターフェースが有効なままになっていないかも確認します。

権限と仮想ネットワークインターフェースを確認する

WindowsとLinuxでは、ネットワークインターフェースの作成やルート変更に必要な権限がクライアントにあるか確認します。macOS、iOS、Androidでは、通常、初回接続時にネットワーク設定の追加を求められます。一度拒否すると、クライアント画面では接続をクリックできても、システムは実際のインターフェースを作成しません。システムのネットワークまたはプライバシー設定で、ZVVPN関連のネットワーク設定が存在し、有効になっているか確認してください。設定が重複している場合は、クライアントを終了し、旧インストールに明確に属する重複項目だけを削除してから、現在のクライアントで再度認証します。

サブスクリプションと回線を分けて検証する

サブスクリプションを更新できても、現在のネットワークからすべての回線に接続できるとは限りません。特定の回線に接続できなくても、サブスクリプションが無効になったとは限りません。まずクライアントに回線名が表示されるかを確認し、次に更新時刻や更新結果を見て、最後に異なる地域を個別にテストします。リストが空、または更新エラーが出る場合は、このページのサブスクリプション章へ進みます。リストが完全なのにすべて接続できない場合は、ネットワークと権限を確認します。一部の回線だけ失敗する場合は、別の回線を使いながら、失敗した回線名を問い合わせ用に記録してください。

チャット履歴や古いデバイスから期限切れのサブスクリプションテキストをコピーして、現在の設定を上書きしないでください。ユーザーパネルのダウンロードまたはサブスクリプション入口から再取得し、クライアントのインポート機能で読み込みます。形式を理解するための例示URLであり、実際のサブスクリプションには使用できません：

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

インポート後は、まずクライアントが生成したデフォルトグループを使い、複雑なルールをすぐに追加しないでください。デフォルト設定で接続できたら、個人ルールを少しずつ戻します。これにより、障害がサービス設定にあるのか、ローカルのカスタム内容にあるのかを判断できます。サブスクリプションリンクはパスワードと同様に管理し、スクリーンショット、公開文書、複数人で共有する設定リポジトリに載せないでください。

接続済みなのにウェブページが開かない

接続状態は、通信が回線に流れていることと同じではない

クライアントに接続済みと表示されても、通常はクライアントといずれかの回線との間にセッションが確立したことを示すだけです。ブラウザーのリクエストがそのセッションに入るかどうかは、システムプロキシ、仮想ネットワークモード、ブラウザー自身の設定、振り分けルールにも左右されます。まずクライアントの接続ログまたはステータス画面を開いて表示したまま、通常のウェブページにアクセスします。アクセスしても新しい記録がない場合、ブラウザーの通信がクライアントに入っていない可能性があります。リクエストが記録されても直接接続または拒否と表示されるなら、ルールを確認します。リクエストが転送済みなのに応答がない場合は、DNSと回線を確認します。

一部のブラウザーでは個別にプロキシを設定でき、拡張機能が通信を引き継ぐ場合もあります。確認時は拡張機能を読み込まない一時的なブラウザー環境を作り、ブラウザーがシステムのネットワーク設定に従うようにします。一時環境で正常なら、拡張機能を1つずつ戻し、一度にすべて有効にしないでください。以前にプロキシアドレスを手動入力したブラウザーでは、古い設定を削除し、存在しないローカルポートへ送信されないようにします。

ドメイン解決とウェブリクエストを分けて確認する

ウェブアクセスには、「ドメインをアドレスに解決する」段階と「対象アドレスへリクエストを送る」段階があります。解決に失敗すると、ブラウザーにはサーバーが見つからないと表示されることが多く、リクエスト段階の失敗では、待ち続ける、接続がリセットされる、証明書ページに異常が出るといった症状が見られます。システムのターミナルで次の一般的な確認を実行できます。例示ドメインにアカウント情報は含まれません：

nslookup example.com
curl -I https://example.com

ドメイン検索に失敗してもクライアントの回線接続が安定しているなら、まずDNSを確認します。ドメインを解決できるのにリクエストが失敗する場合は、システムプロキシ、回線、ブラウザーを確認します。コマンドラインのリクエストは正常でブラウザーだけ失敗するなら、ブラウザー拡張機能、キャッシュ、独立したプロキシ、セキュリティポリシーが原因の可能性が高くなります。コマンドラインツールの対応状況はシステムによって異なります。ツールがない場合に無理に追加インストールする必要はなく、2種類のブラウザーで同じ比較を行うこともできます。

ルールモードと対象ドメインを確認する

ルールモードは、ドメイン、アドレス、アプリに応じてリクエストの経路を決めます。古いルール、順序の誤り、デフォルトルールを上書きするカスタム項目があると、対象サイトが誤って直接接続されることがあります。一時的にテスト通信をすべて回線経由にするモードへ切り替え、ウェブページを開き直します。これで復旧するなら、回線とウェブサイトには到達でき、問題はルールのマッチングにあります。確認後はテストモードをそのまま常用せず、対象ドメインがどのルールに属するかを特定して修正し、通常モードに戻してください。

ウェブページは、メインドメイン、静的リソースのドメイン、認証ドメイン、メディアドメインを同時に読み込むことがあります。メインドメインだけにルールを追加すると、ページの枠組みは開くのに画像、ログインボタン、本文エリアが空白になる場合があります。ブラウザーの開発者ツールにあるネットワーク一覧で、失敗したリクエストのドメインを確認できます。ただし、ログインパラメーター、セッション識別子、サブスクリプション内容を含む完全なリクエストURLを公開しないでください。問い合わせにはドメインだけを残し、クエリパラメーターは隠します。

接続切り替え後のキャッシュ状態を整理する

直接接続とプロキシを頻繁に切り替えると、ブラウザーが古い接続、DNSキャッシュ、サイトセッションを保持することがあります。まず対象サイトのタブを完全に閉じ、ブラウザーを終了してから再起動します。それでも異常が続く場合は、すべての閲覧履歴を最初から消去するのではなく、そのサイトのキャッシュとサイトデータだけを削除します。サイトデータを消すと再ログインが必要になることがあるため、アカウント情報が安全に保存されていることを先に確認してください。

システムがスリープから復帰したとき、有線から無線へ切り替えたとき、別のアクセスポイントへ移動したときには、古い接続が無効な経路を使い続ける場合があります。この場合はクライアントをいったん切断し、システムのネットワークが通常のアクセスに戻るのを待ってから再接続します。システムが有効なネットワークを取得する前に接続ボタンを連続して押さないでください。未完了のセッションが繰り返し作成され、ログが判別しにくくなります。

単一のページに頼らず出口の変化を確認する

回線が有効か確認するときは、クライアントのアイコンだけを見るのも、地域情報がキャッシュされている可能性のある1つのサイトだけに頼るのも避けます。接続前後の出口情報を比較し、DNSリクエストが想定した経路を通っているか確認できます。詳しい確認方法は出口IPとDNSの完全な確認方法をご覧ください。出口が変わっているのにウェブページが開かないなら、「回線をまったく経由していない」問題ではありません。ルール、対象サービスの状態、ブラウザー層に戻って判断します。

対象サイトは、アカウントの地域、ブラウザーの保存データ、コンテンツの利用許可に応じて異なる結果を返すことがあります。回線地域が正しくても、古いセッションがすぐに変わるとは限りません。対象アカウントからログアウトし、そのサイトのデータを削除して再度アクセスできますが、確認のためにアカウント情報を頻繁に変更しないでください。同じ回線で異なるデバイスの結果が一致し、回線を変えると復旧する場合は、対象ドメインと回線地域を記録して回線側の分析を依頼します。

速度低下とピーク時の遅延

まずローカル接続と国際経路のどちらが遅いか判断する

速度の問題には比較条件が必要です。まずクライアントを切断し、現在のネットワークで通常のウェブページや一般的なコンテンツのダウンロードが正常か確認します。次に同じデバイス、同じネットワーク、同じ対象で回線に接続して繰り返しテストします。直接接続自体が不安定なら、無線信号、ルーター、ブロードバンドの出口、システムのバックグラウンド通信を優先して確認します。国際回線はローカル接続層のパケットロスや干渉を解消できないため、むやみに回線を変えると本当の原因が隠れます。

無線ネットワークは、距離、遮蔽物、同一周波数帯の干渉、省電力設定の影響を受けやすいものです。確認時はアクセスポイントに近づき、クラウド同期、システム更新、動画アップロードなど帯域を継続的に使う処理を一時停止します。可能なら有線ネットワークでも比較してください。特定の速度数値を追う必要はなく、ページの初回表示、継続ダウンロード、動画のバッファリングが同時に改善するかを見ます。ローカルの基準が安定して初めて、回線同士の比較に意味が生まれます。

回線を比較するときはタスクをそろえる

回線は地理的な近さだけで選ばないでください。ユーザーから入口、入口から出口、出口から対象サービスまでの経路が結果に影響します。まず地理的に近い地域を選び、次に対象サービスの地域と一致する回線を選び、同じタスクでテストします。回線を切り替えたら古いダウンロードや再生セッションを終了し、対象コンテンツを開き直します。古い接続が前の経路を使い続けるのを防ぐためです。

ある回線でウェブの応答は速いのに大容量ファイルの継続転送が遅い場合、経路は安定していても利用可能な帯域が制限されている可能性があります。ダウンロードはまずまずなのにウェブページが頻繁に止まる場合は、パケットロス、DNS待ち、接続再利用の異常が考えられます。動画の画質だけが下がる場合は、対象プラットフォームのビットレート、適応方式、地域判定も確認します。ストリーミング画質の確認方法は画質が低下する原因と回線選びの指標をご覧ください。

ピーク時は一度の結果ではなく継続性を見る

ピーク時の遅延には、時間帯による明確な傾向が見られることがあります。問題が起きている時間に現在の回線を保持し、別地域の回線を選んで比較します。同時に、ローカルの通常ネットワークも同じ時間帯に遅くなっていないか確認してください。すべての回線と直接接続のタスクが遅いなら、ローカル事業者の出口や家庭ネットワークを優先します。特定の回線だけが決まった時間帯に低下するなら、別の回線に切り替え、繰り返し発生する時間帯と回線名を記録します。

短時間にページを連続更新して安定性を判断しないでください。ページ更新はキャッシュに当たる可能性があり、速度テストのページも異なる対象を選ぶことがあります。一定時間の動画再生、継続ダウンロード、オンライン会議、AIツールでの連続対話に規則的な停止が起きるかを観察する方が有益です。テストは普段の用途に近づけますが、複数の大容量処理を同時に行わないでください。どの処理が他の接続に影響したのか判断できなくなります。

プロトコル、モード、デバイス性能を確認する

接続方式によって、システムリソース、ネットワーク環境、ルーティングポリシーへの適応性は異なります。クライアントに選択可能な接続方式がある場合は、デフォルト設定が失敗した後に1項目ずつ比較しますが、記録なしに頻繁に切り替えないでください。性能の低いデバイス、長時間再起動していないシステム、バックグラウンドで多数のネットワークフィルターが動く環境では、暗号化や転送がボトルネックになることもあります。この場合は、不要なプログラムを閉じてクライアントを再起動する方が、回線を何度も変更するより効果的です。

ルーターが家庭内全体の転送を担う場合、処理能力、ファームウェアのネットワークスタック、ルールの複雑さが速度に直接影響します。単独デバイスのクライアントは正常なのに、家庭全体の構成だけ明らかに遅い場合は、問題を回線ではなくルーターに絞ります。家庭全体の高速化構成の実測比較を参考に、ファームウェア要件、振り分けの保守、デバイス負荷のバランスを確認してください。

データ使用状況も判断に影響する

月額サブスクリプションのデータは開通日を基準に毎月リセットされ、プランは ¥9.9/月で 60GB、¥18/月で 250GB、¥28/月で 500GBです。途中でアップグレードすると、差額は残り日数に応じて換算されます。データパックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、期限はありません。接続が突然停止したり処理を続けられなくなったりした場合は、まずユーザーパネルで現在の利用状態を確認し、プランの状態を回線速度の変動と取り違えないでください。

プランを変更する場合はプランページで元のルールを確認します。支払い方法はAlipay、WeChat、USDTで、7日間の無条件返金に対応しています。速度の問題だけを理由に一度のテストでプランを変更するのはおすすめしません。まずローカルネットワーク、対象サービス、回線の差を確認し、データ容量の必要量自体が変わった場合にプラン変更を検討してください。

頻繁な切断と自動再接続

まず、どの操作の後に切断されるか観察する

頻繁な切断の原因は、回線の変動だけではありません。デバイスのスリープ、画面オフ、無線ネットワークの切り替え、システム更新、ルーターの再接続、クライアントのバックグラウンド終了などもセッションを中断させます。「また切れた」とだけ記録せず、切断前に何が起きたかを記録してください。デバイスがスリープから復帰した直後か、別のアクセスポイントへ移動したか、有線と無線を切り替えたか、特定のアプリが大量転送を始めたかを確認します。

スリープから復帰するたびに失敗し、通常利用中は安定しているなら、システムがネットワークを復旧する順序とクライアントの自動再接続を優先して確認します。何も操作せず静置していても規則的に切断されるなら、省電力、バックグラウンド制限、回線を確認します。移動中だけ切断されるなら、ネットワークの切り替えが主因である可能性が高くなります。条件を明確にすると、長時間待たずに同じ操作で再現できます。

ネットワークを切り替えたらセッションを再確立する

デバイスが家庭のネットワークから別のネットワークへ移ると、ローカルアドレス、デフォルトゲートウェイ、出口経路が変わります。古いセッションは通常、新しい経路へそのまま移行できないため、クライアントは変化を検知して再接続する必要があります。クライアントが接続済みと表示するのに実際はアクセスできない場合は、手動で切断し、通常のネットワークが復旧したことを確認してから再接続します。ネットワーク切り替え中にクライアントのオン・オフを連続して行わないでください。システムに短時間だけ存在する複数のインターフェース状態が残ることがあります。

複数の無線アクセスポイントがある環境では、信号強度が近いとデバイスが頻繁にローミングすることがあります。無線アイコンは変わらなくても、内部の接続が切り替わっている場合があります。一時的に1つのアクセスポイントの近くでテストするか、別のネットワークで比較してください。固定環境で安定し、移動時だけ切断されるなら、遠隔回線を替え続けるのではなく、ローカル無線のカバレッジとローミングを優先して改善します。

ネットワークインターフェースを奪うプログラムを終了する

複数のプロキシクライアント、企業接続ソフト、保護フィルターツール、仮想マシンのネットワークコンポーネントが同時にルートを変更する場合があります。前面に表示されなくても、バックグラウンドサービスがネットワークの変化に応じてシステム設定を書き換えることがあります。確認中は1つのクライアントだけを残し、他の関連プロセスが終了していることを確認してください。競合プログラムを終了すると安定するなら、日常利用で残すツールを決めます。複数のツールを起動順に依存させて設定を上書きさせるのはおすすめしません。

ブラウザー拡張機能が基盤のセッションを直接切断することは通常ありませんが、「ウェブページが突然すべて失敗した」ように見せることがあります。本当に切断されたか判断するには、クライアントの状態と他のアプリを同時に確認します。クライアントに正常なリクエストがあり、ブラウザーだけ失敗するならブラウザー設定に戻ります。すべてのアプリが同時に中断し、クライアントの状態も変わった場合に接続層の切断と判断します。

省電力とバックグラウンド設定が接続を終了させる

ノートパソコンやモバイルデバイスは、電池を節約するため画面オフ後のネットワーク動作を制限することがあります。クライアントをバックグラウンドで実行できる対象に追加し、バックグラウンドを自動停止する設定を避けてください。システム更新後は、以前の権限が再確認される場合もあります。ロック画面後に必ず切断されるなら、まずバックグラウンド権限を確認し、次にクライアントの自動再接続機能を確認します。接続を保つためにシステム全体のセキュリティロックを無効にせず、クライアントのバックグラウンド通信に関係する項目だけを調整してください。

デスクトップシステムでも、アイドル状態の無線アダプターや仮想ネットワークインターフェースが停止する場合があります。電源とネットワークの設定で省電力項目を確認し、電源接続時とバッテリー使用時で比較します。バッテリー時だけ頻繁に中断するなら、省電力ポリシーの可能性が高くなります。両方で同じなら、回線とネットワークを確認します。

ログで意図的な切断とタイムアウトを区別する

クライアントログのエラー原文は、画面に表示される「接続失敗」より有用です。意図的な切断には、システムのスリープ、インターフェースの停止、権限の取り消し、ユーザー操作が伴うことがあります。タイムアウトは、ネットワークに到達できない、回線の応答が途切れるといった状況と関係することが多く、認証やサブスクリプションのエラーはサブスクリプション章で確認します。ログをコピーするときは障害の前後に関係する部分だけを残し、サブスクリプションリンク、トークン、アカウント情報を隠してください。

ログ量が多い場合は、安全に削除できる古いログを整理してから、障害を1度再現し、すぐにエクスポートします。再現手順はできるだけ単純にします。例えば、固定したウェブページを表示し続け、切断を引き起こすことが分かっているロック画面、ネットワーク切り替え、スリープ操作を行います。時間の流れが明確なログなら、システムイベントと切断の前後関係をサポート担当者が判断しやすくなります。

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

まずダウンロードできないのか、解析できないのかを判断する

サブスクリプションの更新失敗は通常、2つの段階に分かれます。クライアントがサブスクリプション内容を取得できない場合と、取得済みの内容を解析できない場合です。前者ではネットワークリクエストの失敗、URLの無効、アクセスのタイムアウトがよく見られます。後者では設定形式のエラー、空の内容、未対応フィールドなどが表示されます。両者で対応順は異なります。ダウンロードできない場合は、まずユーザーパネルの現在のサブスクリプション入口とローカルネットワークを確認します。解析できない場合は、インポート方法、クライアントの種類、古い設定の残りを確認します。

サブスクリプションリンクの文字を手動で編集したり、スクリーンショットからリンクを読み取ったりしないでください。コピー時に空白、改行、句読点が混入しやすく、特にチャットアプリを経由すると起きやすくなります。ユーザーパネルから直接コピーまたはインポートし、クライアントに新しいサブスクリプション項目を作成してください。新しい項目が正常なら古い項目を削除します。比較対象がなくならないよう、唯一の有効な設定を先に削除しないでください。

現在のアカウント状態とサブスクリプションの取得元を確認する

ZVVPNの登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。デバイスに複数のユーザー名が保存されている場合は、プランまたはデータパックを開通したアカウントでログインしているか先に確認します。似たユーザー名、ブラウザーに保存された古いセッション、別アカウントのサブスクリプションを使うクライアントは、パネルとクライアントの状態が一致しない原因になります。ユーザーパネルからログアウトして再度ログインし、現在のページからサブスクリプションを取得すると、アカウントの混同を減らせます。

サブスクリプションアドレスは機密性の高い認証情報であり、公開スクリーンショット、フォーラムの添付ファイル、共有文書で送らないでください。アドレスが漏えいした可能性がある場合は、ユーザーパネルで利用可能なセキュリティ管理機能を使い、再インポートします。問い合わせに完全なアドレスを送る必要はありません。更新エラー、クライアントのプラットフォーム、エラー原文だけを伝えてください。アカウント確認が必要な場合は、問い合わせ内のアカウント情報を使って対応し、公開認証情報を求めることはありません。

古いキャッシュを消去し、重ねてインポートしない

同じサブスクリプションを繰り返しインポートすると、同名のグループが複数作られ、クライアントが古いグループを使い続けるため、更新が反映されていないように見えることがあります。現在選択中のグループの取得元を記録してから手動更新し、回線リストが変わったかを確認します。複数の重複サブスクリプションが表示される場合は、パネルから直近にインポートした項目を残し、古い項目を無効にしてテストします。新しい項目が使えることを確認してから古い項目を整理してください。

一部のクライアントは、前回正常に更新した内容をキャッシュします。今回のダウンロードに失敗してもリストは残りますが、更新時刻は変わりません。「回線がまだ見える」だけで更新成功と判断せず、更新結果またはログを確認してください。キャッシュされた回線に接続できるなら一時的に使いながら更新リクエストを確認します。キャッシュも使えない場合は、アカウント状態とネットワークを同時に確認します。

基盤ネットワークでサブスクリプションのリクエストを確認する

サブスクリプションの更新もネットワークリクエストの1つです。現在のシステムプロキシが壊れていると、クライアントが誤ったプロキシ経由で自分のサブスクリプションを更新しようとし、循環的な障害になることがあります。いったん接続を切り、システムを通常のネットワークに戻してから更新します。別の利用可能なネットワークで試す方法もあります。切断後に更新できるなら、サブスクリプションアドレスは正常で、問題は現在のプロキシまたはルールにあります。ネットワークを変えても失敗するなら、パネルの入口とクライアントのインポート方法を再確認します。

ブラウザーでユーザーパネルを開けても、クライアントがサブスクリプションをダウンロードできるとは限りません。両者でネットワーク経路や証明書環境が異なる可能性があるためです。逆に、クライアントの更新に成功しても、ブラウザーのプロキシが正常とは限りません。更新テストは個別に記録し、ウェブアクセスの結果と混同しないでください。

カスタム設定は最小限の内容から戻す

デフォルトのサブスクリプションは解析できるのに、個人ルールを追加するとエラーになる場合は、カスタム内容を最小限まで減らし、少しずつ戻します。よくある問題には、インデントの不一致、同名フィールドの重複、存在しないグループを参照するルール、不可視文字の混入があります。設定ファイルがスペースや階層に敏感な場合は、リッチテキストエディターで編集せず、プレーンテキストエディターを使い、変更前のコピーを残してください。

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
test-domain: example.com

以上は構造を示すための例であり、どのクライアントの完全な設定でもなく、実際の認証情報も含みません。実際の利用ではクライアント内蔵のインポート手順を優先し、本サービスのサブスクリプション内容を自分で組み立てないでください。クライアントが未対応フィールドを通知した場合は、何度もサービス側のサブスクリプションを編集せず、そのクライアントに対応したインポート入口へ戻ります。

プランの状態とクライアントのエラーを分ける

月額サブスクリプションのデータは開通日を基準に毎月リセットされ、データパックは使い切るまで利用でき、期限はありません。プランを途中でアップグレードすると、差額は残り日数に応じて換算されます。パネルの状態が想定と異なる場合は、まずプランのルールと注文履歴を確認してから、請求に関する問い合わせを送るか判断します。クライアントの解析エラーは支払いを繰り返しても解決せず、請求状態が正常でもローカルの形式エラーは直りません。両者を分けて対応してください。

本サービスは利用デバイス数に制限がありません。ただし各デバイスでは、現在のアカウントから取得した有効なサブスクリプションを使い、複数人に公開して拡散しないでください。デバイス数に制限がなくても、サブスクリプションの管理要件は変わりません。新しいデバイスでインポートに失敗した場合は、まず正常に動作しているデバイスでパネルの入口がまだ利用できるか確認し、2台で使っているクライアントとインポート方法を比較します。

特定のアプリがプロキシを使わない、モバイルのバックグラウンド切断

ウェブは正常でアプリだけ失敗する場合、まずアプリの通信方式を確認する

ブラウザーにはアクセスできるのに特定のアプリにアクセスできない場合、基盤の回線が完全に停止している可能性は低いです。アプリが独自のプロキシ設定、固定インターフェース、特殊なドメイン、長時間接続、システムプロキシに従わないリクエスト方式を使っている可能性があります。まず、そのアプリを起動したときにクライアントへリクエスト記録が出るか確認します。記録がまったくなければ、アプリの通信が現在のプロキシモードを迂回している可能性があります。記録があって直接接続と判定されるなら振り分けルールを確認し、回線を通っているのに応答が異常なら地域、キャッシュ、アカウント状態を確認します。

テスト前には、デスクトップへ戻るだけでなく、アプリのプロセスを完全に終了します。多くのアプリは古い接続を保持するため、回線を切り替えても以前の経路を使い続けることがあります。終了後に再起動し、同じ操作を行います。アプリにウェブ版がある場合は、同じサービスをブラウザーで開いて比較します。ウェブ版は正常でクライアントだけ失敗するなら、アプリ自体を重点的に確認します。両方失敗するなら、回線、DNS、対象サービスに戻ります。

一時的なグローバルテストで振り分けエラーを特定する

ルールモードでは、アプリが複数の関連ドメインへアクセスし、一部のリクエストだけが正しくマッチすることがあります。一時的にテスト通信をすべて回線経由にし、アプリを再起動します。復旧するなら、回線とアプリサービスは通信できており、問題はルールの適用範囲にあります。その後、クライアントログのドメインとルールのヒット結果を確認し、必要なドメインを正しいグループに入れて通常モードへ戻します。一時テストは切り分け用であり、長期的に不明瞭な振り分け設定の代わりにしないでください。

アプリ名だけからすべてのドメインを推測しないでください。ログイン、コンテンツ、画像、更新、プッシュ通知で異なるドメインを使うことがあり、アプリの更新で変わる場合もあります。失敗した操作の際に新しく発生したリクエストを記録する方が、ネット上から出所不明のルール一式をコピーするより確実です。ルール追加後は、ログイン、コンテンツの読み込み、アップロードを個別に確認し、トップページが開くだけで判断しないでください。

アプリ内のプロキシ設定がシステム経路を上書きすることがある

一部のデスクトップアプリには、「システムに従う」「プロキシを使用しない」「手動プロキシ」といった項目があります。以前にローカルアドレスを入力していた場合、システムプロキシをZVVPNが管理していても、アプリが古いアドレスへ接続しようとすることがあります。確認時はシステムに従う設定または自動モードを優先し、無効になった手動設定を削除します。変更後はアプリを完全に再起動し、ネットワーク設定を読み直させてください。

コマンドラインツールや開発環境も環境変数を読み取ることがあります。古い変数があると、リクエストが別のローカルポートへ送られ続ける可能性があります。現在のターミナルでプロキシ関連の環境を確認できますが、認証情報を含む環境全体を問い合わせに貼らないでください。検証が必要なら、カスタム起動スクリプトのない新しいターミナルを開き、通常のリクエストを実行します。開発ツールのプロジェクト単位の設定も個別に確認します。システムやターミナルの設定を上書きしている可能性があるためです。

モバイルのバックグラウンド切断はシステムのスケジュール設定から確認する

モバイルデバイスは画面オフ後のバックグラウンド動作を制限します。特に省電力中、電池残量が少ない場合、アプリを長時間開いていない場合に起こりやすくなります。ZVVPNクライアントのバックグラウンド実行を許可し、システムが自動停止しないようにしてください。設定名はデバイスによって異なりますが、確認方法は同じです。クライアントを前面に表示した状態でテストし、ロック画面後にもう一度テストします。前面では安定し、バックグラウンドで中断するならシステムのスケジュール設定に絞られます。前面とバックグラウンドの両方で中断するなら、回線とネットワーク切り替えを確認します。

システムのネットワーク設定を使うアプリを複数同時に有効にしないでください。モバイルOSでは通常、この種類の接続を1つしかアクティブにできず、別のクライアントを起動すると現在の接続が置き換えられます。ステータスバーのアイコンが消える、または他のサービスに接続を引き継がれたと表示される場合は、競合するアプリを終了して再接続します。再起動後も異常が続く場合は、旧クライアントに明確に属するネットワーク設定だけを削除できます。ただし現在使っている項目は残し、名称を確認してください。

プッシュ通知、音声、リアルタイム接続には連続した経路が必要

インスタントメッセージ、音声通話、リモートデスクトップ、オンライン共同作業は長時間接続に依存します。ネットワークの切り替え、バックグラウンド停止、回線の変化によってセッションの再確立が必要になります。テキストメッセージは正常なのに通話が切れやすい場合は、固定ネットワークでテストし、自動的に回線を切り替える設定を一時的に無効にします。プッシュ通知だけ遅れる場合は、まずアプリの通知とバックグラウンド権限を確認し、すぐに回線障害と判断しないでください。

AIツールは、ウェブリクエストと連続出力用の接続を同時に使うことがあります。ページは開くのに回答が途中で止まる場合は、まずローカルネットワークが切り替わっていないか、ブラウザーがスリープしていないか、回線が安定しているかを確認し、同じ地域の別回線と比較します。同じテスト中にページ更新、回線切り替え、再ログインを同時に行わないでください。セッション失効とネットワーク中断を区別できなくなります。

DNS異常、デバイスの競合、問い合わせ

DNS異常に特徴的な症状を見分ける

DNS異常は、ドメインを解決できない、初回表示に長時間かかる、同じサイトが開いたりサーバーが見つからないと表示されたりする、回線接続後もローカルネットワークの解決結果が返る、といった形で現れます。回線に完全に到達できない場合との違いは、クライアントが接続を維持し、キャッシュ済みアドレスを使う一部のアプリは動作する一方、新しく開くドメインだけが失敗することです。ドメイン検索とウェブリクエストを分けてテストすると、問題がどの段階で止まっているかを確認できます。

まずクライアントを切断し、通常のネットワークでドメイン解決が正常か確認します。次に接続して同じ検索を繰り返します。切断中は正常で接続後に失敗するなら、クライアントのDNSモード、システムネットワーク設定、カスタムルールを確認します。両方の状態で失敗するなら、まずローカルネットワークを修復します。システム、ブラウザー、クライアント、ルーターで異なるDNSを同時に複数指定しないでください。リクエストの経路が判断しにくくなります。

古い解決状態を消去してネットワークを再確立する

ネットワークや回線を切り替えた後も、システムやブラウザーが古いキャッシュを使い続けることがあります。まず対象アプリを終了し、クライアントを切断して通常のネットワークが復旧するのを待ち、その後で再接続します。システムにDNSキャッシュの消去機能がある場合は、標準の方法を使います。コマンドに慣れていなければ、ネットワーク接続とアプリを再起動して比較環境を作ることもできます。出所不明のスクリプトから、システム変更権限を含むコマンドをコピーしないでください。

ブラウザーで独自のセキュアDNSが有効になっていると、システムやクライアントの設定に従わないことがあります。確認中は一時的にブラウザーをシステム設定に従わせ、問題が消えるか確認します。復旧した場合は、クライアントの対応方式に応じて長期設定を決めます。企業管理デバイスのDNSは組織ポリシーで管理されている可能性があるため、勝手に変更せず、失敗した検索の症状をネットワーク管理者に確認してもらいます。

デバイス数に制限がなくても、設定が競合することはある

ZVVPNは利用デバイス数に制限がないため、現在のアカウントをWindows、macOS、iOS、Android、Linuxで利用できます。ただし各デバイスには、それぞれ異なるクライアント、システム権限、キャッシュ、ネットワーク環境があります。1台は正常で別の1台だけ失敗する場合、まずアカウントのデバイス上限を疑わず、2台のサブスクリプション更新時刻、クライアントモード、ローカルネットワーク、システムプロキシを比較します。

同じデバイスで複数のクライアントを動かすことと、複数のデバイスでサービスを使うことは別です。前者はシステムプロキシや仮想ネットワークインターフェースを奪い合う可能性がありますが、後者でローカル設定が共有されることはありません。デバイス間で差がある場合は、問題のデバイスを正常なデバイスと同じネットワークに接続し、同じ地域の回線でテストします。それでも結果が異なるならデバイス側、ネットワークを変えると結果も変わるなら接続環境を確認します。

ローカルでの試行錯誤を続けなくてよいタイミング

基盤ネットワーク、別の回線、システム権限、サブスクリプション更新、DNSを確認しても問題を安定して再現できるなら、問い合わせを送ります。特に複数のデバイス、異なるネットワーク、異なる地域の回線で同じエラーが出る場合、再インストールやキャッシュ消去を続けても有効な情報は増えにくいものです。問い合わせの目的は「多くの方法を試した」と証明することではなく、サポート担当者が再現して判断できる経路を提供することです。

請求や返金の問題も、直接問い合わせで対応します。サービス本文では7日間の無条件返金を案内していますが、具体的な申請は返金ポリシーに従ってください。支払い方法はAlipay、WeChat、USDTです。注文については、注文ページで確認できる状態と支払い方法を添え、支払い認証情報、完全な取引キー、問題に関係しないアカウント資料は送らないでください。

有効な問い合わせに含める情報

タイトルには症状を直接書きます。例えば「サブスクリプションは更新できるが、すべての回線に接続できない」「ロック画面後にシステムが接続を終了する」などです。本文では、プラットフォーム、使用ネットワークの種類、クライアントに表示されたエラー原文、障害が起きた回線名、対象ウェブサイトまたはアプリ、最初に発生した操作、実施済みの比較を順に説明します。ネットワークや回線を変えて結果が異なった場合は、その差も記載してください。

ログは障害の前後に関係する部分だけを切り取ります。スクリーンショットにはクライアントの状態とエラーを含めますが、ユーザー名、完全なサブスクリプションアドレス、トークン、注文に関する機密情報、その他の個人情報は必ず隠してください。文脈の分からない赤い通知だけを送ったり、障害と無関係なチャット画面全体をアップロードしたりしないでください。エラー原文は画像より検索しやすいため、スクリーンショットとは別にテキストでもコピーすると便利です。

復旧後は最小限の記録を残す

問題が復旧したら、最後に効果があった操作と、復旧前の重要な症状を記録しておくことをおすすめします。例えば「重複したクライアントを終了すると復旧した」「サブスクリプションを再インポートすると回線リストが更新された」「バックグラウンド実行を許可するとロック画面後も中断しなくなった」などです。機密性の高いログ全体を保存する必要はありませんが、問題の種類と解決の方向は残してください。似た症状が起きたとき、すべての設定を最初から変更せず、同じ分岐を先に確認できます。

復旧した原因が明確でない場合は、関係のない変更を少しずつ元に戻し、本当に残す必要のある設定を確認します。一時的なルール、手動DNS、重複したサブスクリプションを長期的に積み重ねると、次の障害を判断しにくくなります。安定した設定とは、選択肢が最も多い設定ではありません。ネットワーク経路が明確で、サブスクリプションの取得元が分かり、システム上で接続を担当するクライアントが1つだけで、各カスタム項目に説明可能な用途がある設定です。