VPNZe トラブルシューティングガイド

DIAGNOSIS BASELINE

切り分けの基準を作る

まず現象を判断可能な文章にする

「ネットワークが不安定」だけでは解決策に直結しません。範囲、発生するタイミング、操作を含む説明に書き換えましょう。たとえば、クライアントが接続を完了できない、接続済みなのにすべてのウェブサイトが開けない、特定のアプリだけ失敗する、日中は正常だが混雑時間帯に遅くなる、モバイルネットワークに切り替えると復旧する、サブスクリプション更新時だけエラーが出るが既存の回線には接続できる、といった具合です。具体的であるほど、入口、回線、システム、対象サービスのどこに問題があるか判断しやすくなります。

問題が継続しているのか、断続的なのかも確認します。継続的な失敗は、設定、権限、サブスクリプションの状態、ネットワーク環境に関係することが多く、断続的な失敗は回線の一時的な変動、スリープ、ネットワーク切り替え、アプリのキャッシュが原因である可能性が高くなります。一度の失敗だけで結論を出さないでください。設定を変えずに同じ操作を繰り返し、エラー表示が一致するか確認しましょう。表示が毎回異なる場合は、クライアントをすぐ再インストールするのではなく、まずローカルネットワークの安定性を確認します。

問題の層を分ける

最小限のテスト環境を用意する

切り分け中は干渉要因を一時的に減らします。クライアント、ブラウザーのウィンドウ、確認する回線を一つずつ残し、ネットワークを継続的に使う同期、ダウンロード、更新を停止してください。複数のプロキシクライアントがシステムに入っている場合は、システムプロキシや仮想ネットワークインターフェースの競合を避けるため、ほかのクライアントを終了します。ブラウザー拡張機能がプロキシを書き換えることもあるため、拡張機能を読み込まない独立ウィンドウで再テストできます。ただし、最初から個人データをすべて消去する必要はありません。

テスト対象も段階的に確認します。まず普段安定している一般的なウェブページを開き、その後でログインが必要なサービスや特定地域に依存するサービスを試します。一般的なウェブページの時点で失敗しているなら、先にストリーミングアカウントやアプリの地域設定を確認する必要はありません。一般ページは正常で特定の対象だけ失敗する場合は、対象サービス、アプリの振り分け、アカウント地域、接続先に範囲を絞れます。

変更前の状態を記録する

モードの切り替えやDNSの変更前に、現在の回線の正式名称、クライアントモード、システムのネットワーク種別、エラー原文、発生時刻を記録します。スクリーンショットには重要な状態を含めつつ、サブスクリプション情報やアクセス認証情報は隠してください。サブスクリプションURLを公開ページに貼り付けたり、問い合わせ本文にパスワードを記載したりしないでください。VPNZeの登録に必要なのはユーザー名とパスワードのみで、メールアドレスは不要です。問い合わせには、問題を再現できる情報だけを提供してください。

クライアントの更新、ネットワークの切り替え、システムのスリープ後に問題が起きた場合は、きっかけとなった操作も記録します。最終的なエラーより、直前の操作のほうが重要な手がかりになることがあります。たとえば、スリープ復帰後に失敗しクライアントの再起動で直るなら、仮想インターフェースの再構築を優先して確認します。ネットワーク切り替え後に失敗するなら、古い接続とDNSキャッシュを確認します。サブスクリプション変更後に回線が空になったなら、サブスクリプション取得の過程を確認します。基準作りは余計な作業ではなく、一時的な問題を長期障害と誤認しないための手順です。

CONNECTION FAILURE

まったく接続できないときの確認方法

「クライアントが起動していない」と「回線のハンドシェイクに失敗している」を分ける

まったく接続できない場合、見た目が似ていても原因は大きく二つに分かれます。一つはクライアントのコアが正常に動作していないケースです。起動後すぐ停止する、システムプロキシのボタンが有効にならない、仮想ネットワークモードを確立できない、権限に関する表示が続く、といった症状が出ます。もう一つはクライアント自体は正常でも、選択した回線でセッションを確立できないケースです。接続処理が止まる、タイムアウトする、回線エラーがすぐ返るなどの症状が出ます。前者は端末の権限とソフトウェアの状態を確認し、後者で初めて回線とネットワーク環境を調べます。

クライアントを完全に終了し、再度開いて、起動中に最初に表示される異常を確認します。最後のエラーだけを見ないでください。後続のエラーは、先行する失敗の連鎖である可能性があります。システムネットワーク設定の作成を求められた場合は、システムの案内に従って許可します。許可済みなのに状態が異常な場合は、いったん切断してクライアントを終了し、再度開いてください。接続ボタンを素早く連打すると、古いセッションが解放される前に新しいセッションが作られることがあります。

基本ネットワークの入口を確認する

加速接続を切断し、現在のネットワークで普段使うページを開けるか確認します。基本ネットワーク自体が使えない場合は、ルーター、無線接続、有線接続を先に復旧してください。ウェブページでの確認が必要なネットワークなら、クライアントに接続していない状態で確認を完了します。この種の入口ページはローカル転送に依存することが多く、システムプロキシを有効にすると正しく表示されない場合があります。入口の確認未完了を回線障害と誤認しないでください。

基本ネットワークが正常になったら、同じクライアントで別の回線を試します。地域差の影響を減らすため、まず同じ地域で異なる回線タイプを選びます。VPNZeは100か国以上、250以上の回線に対応しており、回線ページではIEPL専線、中継、直結のタイプを確認できます。比較する場合はグローバルノードページでタイプの説明を確認してください。同じ地域の別タイプに接続できるなら、クライアントとサブスクリプションは基本的に正常で、元の回線または現在のネットワークからその回線までの経路に問題がある可能性が高くなります。

サブスクリプションに有効な内容が残っているか確認する

クライアントに古い回線名が残っていても、サブスクリプションの内容が最新とは限りません。まず更新が成功しているかを確認し、回線一覧が過去のキャッシュから復元されていないか確認します。更新に失敗しても、すぐに既存の設定を削除しないでください。古い設定を残しておくと、「サブスクリプションを取得できない」問題と「回線に接続できない」問題が別々かどうか判断できます。サブスクリプション更新の手順は後述します。パネルのプラン状態を確認する場合は、同じ古いURLを何度もインポートせず、アカウント概要を開いて確認してください。

サブスクリプションを更新でき、回線一覧も完全なのにすべての回線へ接続できない場合は、異なる接続ネットワークで結果を比較します。目的はネットワークを長期的に変更することではなく、現在の入口だけで障害が起きているかを確認することです。別のネットワークで接続できるなら、クライアントやアカウントに根本的な問題はないことが多いため、元のネットワークに戻ってプロキシ制限、DNSの書き換え、ゲートウェイルール、残存セッションを確認します。どの接続環境でも同じエラーが出るなら、クライアントコア、システム時刻、サブスクリプション内容、ログにある最初の異常を重点的に確認します。

無闇に再インストールせず、残った状態を整理する

接続が強制的に切断された後は、システムプロキシ、仮想ネットワークインターフェース、クライアントプロセスの状態が同期しなくなることがあります。安全な順番は、まずクライアント内で切断し、クライアントを終了し、システムプロキシが復元されたことを確認してから再起動することです。仮想ネットワークモードに異常がある場合は、通常のシステムプロキシモードに切り替えて比較します。通常モードで接続できるなら、回線は利用可能で、問題は仮想インターフェース、権限、システムネットワークスタックに集中しています。頻繁に回線を切り替え続ける必要はありません。

再インストールは、クライアントのファイル破損やコアの起動不能を確認した後に行います。再インストール前に必要な非機密設定を保存し、ユーザーパネルからクライアントとサブスクリプションを再取得できることを確認してください。不明なページから同名プログラムをダウンロードしたり、出所の不明な設定をインポートしたりしないでください。VPNZeはWindows、macOS、iOS、Android、Linuxに対応しており、クライアントの入口はユーザーパネルのダウンロードエリアに統一されています。

セルフチェックを中止すべきタイミング

異なるネットワーク、異なる回線タイプでも接続できず、ログに同じハンドシェイクまたは認証エラーが続けて表示される場合は、問い合わせを送信してください。クライアントのプラットフォーム、接続モード、回線の正式名称、発生時刻、エラー原文に加え、「基本ネットワークは正常、回線を変更済み、クライアントを再起動済み」という結果を添えます。「接続できない」とだけ書いたり、状況説明のないスクリーンショットを何枚も送ったりしないでください。各スクリーンショットがどの手順に対応するかが分かると、サポート側で回線側の異常かローカル設定の問題かを判断しやすくなります。

WEB AND DNS

接続済みなのにウェブが開けない・DNS異常

ブラウザーの問題かシステム全体の問題かを最初に判断する

クライアントが接続済みなのにウェブページを開けない場合は、別のブラウザーやシステム標準のネットワークツールで比較します。特定のブラウザーだけ失敗するなら、独自プロキシ、暗号化DNS、拡張機能のルール、長期間残ったキャッシュを確認します。すべてのブラウザーで失敗するなら、システムプロキシが実際に設定されているかを確認します。ブラウザーは正常でほかのアプリだけ失敗する場合は、「アプリの振り分け」の章へ進み、DNSに時間をかけすぎないでください。

ブラウザーのエラーページに表示される文言は重要です。ドメインを解決できない、接続がタイムアウトする、証明書に異常がある、接続がリセットされる、という表示はそれぞれ確認すべき方向が異なります。ドメインを解決できない場合はDNS経路から確認し、接続タイムアウトは回線、接続先、振り分けが関係する可能性があります。証明書エラーではシステム時刻と対象ドメインが正しいかを確認します。接続リセットの場合は回線とネットワーク入口を比較します。すべてを「ノードの停止」と一括りにしないでください。

コマンドで名前解決とアクセスを切り分ける

公開テストドメインに対して、名前解決と応答の確認を実行できます。以下のコマンドにはサブスクリプション情報が含まれず、システム設定も変更しません。プラットフォームによってコマンド名は異なりますが、確認する目的は同じです。まずドメインが解決結果を返すかを確認し、その後HTTPSリクエストで応答を確立できるかを確認します。コマンド出力は切り分けにのみ使用し、対象サービスのアカウント状態を推測する根拠にはしないでください。

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

名前解決コマンドが失敗しても、クライアントの回線テストやアドレスベースの別の接続に応答があるなら、問題はDNSに近いと考えられます。名前解決は成功するがHTTPSリクエストがタイムアウトする場合は、システムプロキシ、振り分けルール、対象先への経路を確認します。コマンドラインは正常でブラウザーだけ失敗するなら、ブラウザー独自のプロキシとDNS設定を優先して確認します。コマンドラインとブラウザーの両方が失敗する場合は、別の回線で同じテストを行い、障害が回線に追随するかを確認します。

「接続済みなのに失敗する」DNSの仕組みを理解する

ドメインの名前解決は、システムの標準DNS、クライアント内蔵DNS、仮想ネットワークインターフェース、ブラウザー独自のDNSのいずれかを通ります。複数の経路が同時に存在すると、「DNSがない」のではなく、通信とは異なる出口から問い合わせている、または現在の回線に適さない古いキャッシュが残っていることがよくあります。ネットワーク切り替え、スリープからの復帰、クライアントモードの変更後は、古い名前解決キャッシュが特に残りやすくなります。

影響の小さい操作から順に進めます。問題が起きたブラウザーのウィンドウを閉じて開き直し、クライアント内で切断してから再接続し、ブラウザーが現在の環境と競合する独自の名前解決を強制していないか確認します。必要に応じて、最後にシステムのDNSキャッシュを消去します。キャッシュの消去はシステムに再問い合わせを促すだけで、誤ったプロキシルールは修正しません。消去直後だけ一時的に復旧して再び失敗するなら、繰り返し消去するのではなくDNS経路を確認してください。

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

通常のシステムプロキシモードは、アプリがシステムプロキシ設定を自発的に読み取ることを前提とします。一部のコマンドラインツールや独立したアプリは設定を継承しないため、ブラウザーは正常でもコマンドラインだけ失敗することがあります。仮想ネットワークモードはより低い層で通信を引き受けますが、システム権限とインターフェースの状態に依存します。モードを切り替えると問題が消える場合、回線自体は利用可能で、違いは通信の引き受け方にある可能性が高くなります。有効なモードを維持し、元のモードのプロキシ継承や権限を確認してください。国や地域を何度も切り替える必要はありません。

システムに手動プロキシアドレスが残っていないかも確認します。クライアント終了後も手動プロキシが停止済みのローカルポートを指していると、すべてのウェブページが失敗します。自動設定、またはクライアント管理に戻してから再試行してください。ネットワーク解説記事にあるポートやアドレスを無闇にコピーしないでください。クライアントごとにローカルの待ち受け方式が異なるため、確認する場合は現在のクライアントに表示される設定を基準にします。

特定のドメインだけ失敗する場合

大半のウェブページは正常で、特定のドメインだけ失敗するなら、同じ回線でウェブ版とアプリ版を比較してから、同じ地域の別回線で再テストします。特定のサービスは、出口地域、アカウント地域、ログイン状態、キャッシュによって異なる結果を返すことがあります。この場合、DNSは原因の一つにすぎません。ブラウザー全体を消去するより、そのサイトの局所的なキャッシュを消去するほうが安全なことが多く、正式なドメインを入力しているかも確認してください。転送先ドメインや古いブックマークを本サイトと取り違えないようにします。

特定の回線だけで問題が起きる場合は、回線の正式名称、失敗するドメイン、ブラウザーのエラー原文、比較した回線を問い合わせに記載します。複数のドメインで同時に名前解決に失敗する場合は、名前解決コマンドの結果も添えます。出力にローカルユーザー名やディレクトリパスが含まれる場合は、該当部分を隠してください。サブスクリプションURLは送信しないでください。サポートがDNS経路を判断するために、認証情報は必要ありません。

SPEED AND PEAK HOURS

速度低下と混雑時間帯の遅延

「遅い」のがどの操作かを最初に定義する

ウェブページの初回表示、動画のバッファリング、ファイル転送、ビデオ会議の揺れ、AIツールの応答中断は、同じ基準で判断できません。ウェブページは接続確立と小さなリクエストへの応答を重視し、動画は持続的なスループットと地域別の利用可否に左右されます。会議では揺れとパケットロスが重要で、ファイル転送は単一接続の速度制限や対象サーバーの影響を受けやすくなります。実際の用途に合うテストを選び、一つの速度テストページだけで全体の利用感を判断しないでください。

テスト中はバックグラウンドの同期と更新を停止し、ローカルネットワーク、クライアントモード、対象サービス、操作手順を固定して、回線だけを入れ替えます。ページを開いた直後に切り替えるのではなく、安定した傾向を確認できるまで各テストを続けます。ローカルの無線ネットワーク自体が不安定なら、回線の差も大きく見えます。接続ポイントに近づく、または安定した接続に切り替えて比較できますが、一時的な比較条件をサービスの速度保証とみなさないでください。

地域と回線タイプで範囲を絞る

通常は、対象サービスの地域に近く、ローカルの入口からの経路も合理的な回線を選びます。距離だけが決定要因ではありませんが、経由するネットワークが増えるほど不確定要素も増えます。特定地域のコンテンツを利用するなら対応地域を優先し、地域に依存しない用途なら近隣地域を比較します。回線タイプも考慮してください。IEPL専線、中継、直結では経路構造が異なり、接続環境によって結果が変わることがあります。

有効な比較は、多数の国を無作為に切り替えることではありません。近い地域で異なるタイプを比較するか、同じタイプで近隣地域を比較します。これにより、地域の出口、回線タイプ、対象サービスのどれが影響しているか判断できます。ノードページには地域、都市、回線タイプ、ストリーミングのタグがあるため、グローバルノードで絞り込んでからクライアントでテストしてください。回線名に「専線」や「直結」とあるだけで絶対的に判断せず、最終的には現在の接続環境と実際の用途を基準にします。

混雑時間帯特有の遅延に対処する

日中は安定しているのに混雑時間帯だけ明らかに遅くなる場合は、同じ時間帯にローカルの接続ネットワークも遅くなっていないか確認します。クライアントを切断して普段使うコンテンツにアクセスし、基本ネットワークで遅延やパケットロスが同時に発生していないか確認します。基本ネットワークも影響を受けているなら、回線の切り替えで改善できるのは一部だけです。基本ネットワークが正常で特定の回線だけ遅いなら、同じ地域で異なるタイプを比較し、発生時間帯を記録します。

混雑時間帯の問題は、持続的なスループット低下または断続的な停止として現れることが多くなります。前者は動画の画質を上げたときやファイルを継続転送するときに目立ち、後者は会議、ゲーム、短いリクエストで感じやすくなります。問い合わせでは両者を分けて説明してください。「混雑時間帯は使えない」だけでは、安定した速度不足、一時的な揺れ、対象サービスの混雑のどれか判断できません。影響を受ける操作、すべての回線で起きるか、どのタイプに切り替えると変化したかを記載します。

速度テストが結論に与える影響を避ける

速度テストの対象はそれぞれ異なるネットワークにあるため、結果がすべてのウェブサイトを直接示すわけではありません。ブラウザーでのテストは、ページのスクリプト、拡張機能、端末性能、同時接続の影響も受けます。より実用的なのは、実際の作業を基準に比較することです。同じ動画を同じ画質で継続再生できるか、同じファイルを安定して転送できるか、同じ会議環境で再接続が頻発しないかを確認します。速度テストは補助として使い、唯一の証拠にはしないでください。

複数の速度テストを同時に実行しないでください。同時実行すると帯域を奪い合い、回線が実際より悪く見えます。テスト後はページを閉じ、バックグラウンドで転送が続かないようにします。クライアントに接続ログの表示機能がある場合は、遅延中に再接続や回線切り替えが起きていないか確認できます。ただし、一瞬の情報だけで結論を出さず、時間と繰り返し発生する現象を合わせて判断してください。

端末のリソースとモードを確認する

端末が省電力状態にある、バックグラウンド処理が多い、仮想ネットワークインターフェースに異常がある、セキュリティソフトが通信を詳細検査している、といった状況でも速度は低下します。不要な処理を停止してから、通常のシステムプロキシと仮想ネットワークモードを比較します。一方のモードは安定し、もう一方だけ遅延が続くなら、差は端末内の通信処理経路にある可能性が高くなります。使えるモードを維持し、問い合わせにはモードによる違いを記載すると、「もっと速い回線に変えてほしい」とだけ伝えるより有効です。

特定のアプリだけ遅く、ブラウザーやほかのアプリが正常なら、アプリの振り分けの章へ進みます。すべてのアプリがすべての回線で遅く、基本ネットワークが正常なら、回線と環境の情報を添えて問い合わせてください。VPNZeの月額サブスクリプションの通信量は、開通日を基準に毎月リセットされます。プラン状態を確認する場合はパネルを開いてください。速度テストを繰り返して大量の通信量を消費したり、プランの残量と特定回線の性能を混同したりしないでください。

DISCONNECTION AND SLEEP

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

切断がいつ発生するかを確認する

頻繁に切断される場合は、まずきっかけを探します。よくあるきっかけは、端末のスリープ、画面オフ、Wi-Fiとモバイルネットワークの切り替え、電波の弱い場所からの復帰、クライアントのバックグラウンド移行、省電力機能の実行です。毎回同じ操作の後に起きるなら、ランダムな切断より原因を特定しやすくなります。再びアプリを開いたときの状態だけでなく、切断直前の最後の操作を記録してください。

端末を放置したときだけ切断され、使用中は安定するなら、バックグラウンド実行権限と省電力設定を優先して確認します。ネットワーク切り替え後だけ切断されるなら、クライアントがセッションを再確立できるか、古い仮想インターフェースが解放されているかを確認します。使用中に明確なきっかけなく頻繁に切断されるなら、同じ地域の別回線を比較し、問題が回線に追随するかを確認します。三つのケースでは対応順序が異なります。

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

モバイルOSは、バッテリー残量、メモリ、バックグラウンド活動に応じてアプリを一時停止します。クライアントがバックグラウンドに入ると、画面に「接続済み」と表示され続けても、実際のセッションがシステムによって終了されていることがあります。フォアグラウンドに戻したら、自動再接続するか、システムステータスバーのネットワーク表示が復旧しているか、対象アプリでリクエストを再実行する必要があるかを確認します。タスク一覧にアプリカードが残っているだけで、継続実行中とは判断しないでください。

システム設定でクライアントに必要なバックグラウンド活動を許可し、過度に制限された省電力設定の対象から外します。システムごとに画面名は異なるため、固定のメニュー手順ではなく、「バックグラウンド実行」「ネットワーク接続」「省電力制限」を手がかりに探してください。変更後は画面をロックしてから復帰し、切断のきっかけとなった操作を再現します。問題が起きなくなればきっかけを確認できたことになります。まだ切断される場合は、回線とネットワーク切り替えを確認します。

ネットワーク切り替え後に残る古いセッションを処理する

端末が一つの接続ネットワークから別のネットワークへ切り替わると、ローカルアドレス、ゲートウェイ、DNS経路が変化します。古いセッションをそのまま再利用できるとは限らず、クライアントは接続を再確立する必要があります。切り替え後にすべてのページが停止した場合は、設定をすぐ消去せず、クライアント内で切断して再接続します。再接続で復旧するなら、サブスクリプションと回線は有効で、問題はネットワーク切り替え後のセッション復旧にあります。

ネットワークを切り替えるたびに端末の再起動が必要なら、仮想ネットワークモードを確認します。一時的に通常のシステムプロキシモードへ変更して比較してください。通常モードで正常に復旧するなら、仮想インターフェースの状態を重点的に調べます。反対に、通常モードで特定のアプリだけ切り替え後に使えなくなるなら、アプリがシステムプロキシを再読み込みしていない可能性があります。このモード差を問い合わせに記載すると、サポート側の重複質問を減らせます。

回線切断とアプリのフリーズを分ける

アプリをフォアグラウンドに戻した後に読み込めなくても、回線が切断されたとは限りません。まずブラウザーで一般的なページを開きます。ブラウザーが正常ならシステム接続は維持されており、アプリが古い接続、古いDNS結果、古いセッションを保持している可能性が高くなります。回線を切り替えるより、アプリを完全に終了して開き直すほうが適切な場合があります。すべてのアプリが失敗するなら、クライアントの接続状態とログに戻って確認します。

動画や会議アプリは特に長時間接続を保持しやすくなります。ネットワークが変わった後も古い接続がすぐ再構築されず、映像が止まる、メッセージが更新されない一方で、新しく開いたウェブページは正常という状態になることがあります。この場合は対象アプリを再起動して確認します。アプリの再起動で直らず回線切り替えで復旧するなら、元の回線と対象サービスを記録します。クライアントの再起動だけで復旧するなら、クライアントモードときっかけとなった操作を記録します。

デスクトップのスリープと復帰

デスクトップ端末がスリープすると、ネットワークインターフェースとクライアントコアが異なる順序で復旧することがあります。復帰直後は回線を連続して切り替えず、まず基本ネットワークが復旧するのを待ってからクライアントの状態を確認します。システムプロキシが有効なままクライアントコアだけ復旧していないと、ウェブページが一時的にすべて失敗します。この場合はクライアント内で再接続し、直らなければクライアントを終了してシステムプロキシが復元されたことを確認してから開き直します。

スリープ後の失敗が長期的に続く場合は、通常のプロキシモードと仮想ネットワークモードを比較し、復帰後のログで最初に出る異常を確認します。障害付近のログだけを切り取り、履歴ファイル全体を送る必要はありません。ログにローカルディレクトリやアカウント識別子が含まれる場合は隠してください。サポートには「継続使用中は安定するが、スリープ復帰後に失敗する」と伝えるほうが、「たまに切断される」より正確です。

ランダムな切断を比較する手順

明確なきっかけがない場合は、まず一つの回線を固定して観察し、切断を確認したら同じ地域の別タイプへ切り替えます。元の回線に切断が追随するなら回線情報を添えて問い合わせます。すべての回線で切断されるなら、接続ネットワークとクライアントモードを比較します。一つの端末だけで起きるなら、その端末の権限、省電力、システムネットワーク状態を確認します。VPNZeは接続台数無制限に対応しているため、固定の台数制限を推測するのではなく、異常なセッションやクライアント状態を確認してください。

SUBSCRIPTION UPDATE

サブスクリプション更新失敗と回線一覧の異常

まず現在使える設定を保護する

サブスクリプションの更新に失敗したときは、既存の設定を先に削除しないでください。古い設定でまだ接続できるなら比較に使え、クライアントコアとローカル権限が基本的に正常であることも確認できます。削除して再インポートすると、「更新失敗」が「使える回線が一つもない」問題に広がります。安全な方法は、現在の設定名と最後に使えた状態を記録し、更新だけを個別に実行することです。

クライアントが複数の設定に対応している場合は、古い設定を残してテスト用設定を新しく作成します。対応していない場合も、ユーザーパネルにログインしてサブスクリプションを再取得できることを先に確認します。サブスクリプションの内容はアカウントに紐づく提供情報なので、公開ツール、検索ボックス、第三者の検査ページに貼り付けないでください。例示形式は構造を理解するためだけのもので、パネルが生成した実際の内容の代わりにはなりません。

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

「取得できない」のか「解析できない」のかを判断する

更新失敗は通常、リクエスト段階と解析段階に分かれます。リクエスト段階の失敗では、クライアントがサブスクリプションの応答を取得できず、タイムアウト、ネットワークエラー、アクセス拒否などが表示されます。解析段階の失敗では、リクエスト自体は返っていても、現在のクライアントが受け付けない形式のため、設定が無効、回線が空、フィールドエラーなどが表示されます。必要な証拠も異なります。前者ではネットワークエラーの原文を残し、後者では解析メッセージとクライアントの種類を残します。

まず基本ネットワークが正常であることを確認し、クライアントで更新を試します。クライアントが現在の回線経由でサブスクリプションにアクセスする必要があり、その回線が停止していると依存関係が循環することがあります。その場合はクライアントを切断し、基本ネットワークから更新します。基本ネットワークでも完了しないなら、ユーザーパネルから再取得します。ネットワークを連続して切り替えながら更新ボタンを押すと、どのリクエストが結果を返したのか分からなくなります。

サブスクリプションURLを手作業で修正せず、再取得する

サブスクリプションURLにはアカウントを識別する情報が含まれることがあります。文字を手作業で削除・変更したり、別サイトの形式を当てはめたりしないでください。アカウント概要にログインしてサービス状態を確認し、パネルのダウンロードまたはサブスクリプション入口から最新の内容を取得します。VPNZeはメールアドレス不要で、ユーザー名とパスワードで登録できます。ユーザー名を忘れたり混同したりした場合は、パネルの既存の手順で対応し、同じサブスクリプションを試すために複数のアカウントを作らないでください。

コピー時は、前後の空白、改行、引用符、チャットアプリが付加した文章を一緒に貼り付けないよう注意します。クライアントがQRコードと貼り付けに対応しているなら、内容を壊しにくい方法を選びます。貼り付け後は設定名が表示されているかを確認してから更新します。インポートに成功しても回線が空なら、クライアントの表示を記録し、サブスクリプションURLに自分でパラメーターを追加しないでください。

更新成功なのに内容が変わらない場合の対処

クライアントに更新完了と表示されても、古い回線が表示され続けることがあります。キャッシュ、設定の未切り替え、画面の未更新、同名の別設定への更新などが原因です。まず現在有効な設定名を確認し、設定画面を閉じて開き直します。似た名前の設定が複数ある場合は、区別しやすいようテスト用設定の名前を一時的に変更できますが、回線フィールドは変更しないでください。

回線一覧に内容があるのに選択後も古い回線へ接続される場合は、現在のセッションを切断してから設定と回線を切り替えます。一部のクライアントは既存セッションが終了するまで元の接続を保持するため、一覧の選択だけでは使用中の出口がすぐ変わらないことがあります。切断、選択、再接続の手順を最後まで行って再テストし、画面上の選択と実際のセッションがずれていないか確認します。

プラットフォームによる違い

サブスクリプションの問題について問い合わせる

問い合わせには、プラットフォーム、クライアントの種類、更新方法、エラー原文、発生時刻、古い設定でまだ接続できるかを記載します。更新に成功しても回線が空の場合は、設定名と画面に表示された現象を説明します。機密情報を隠したスクリーンショットは添付できますが、サブスクリプションURL、パスワード、完全な設定ファイルは添付しないでください。サポートに必要なのは提供状態と互換性の判断であり、アカウントを操作することではありません。

プラン状態に関係する場合は、パネルに表示された状態も記載します。月額サブスクリプションは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれ、通信量は開通日を基準に毎月リセットされます。途中でアップグレードした場合の差額は残りの日数に応じて計算されます。通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、永久に失効しません。残りの期間を自分で換算せず、パネルに表示された実際のプランを基準に確認してください。

APPLICATION ROUTING

特定のアプリがプロキシを通らない場合

まずシステム接続が正常であることを確認する

特定のアプリにアクセスできない場合は、同じ端末、同じ回線でブラウザーから一般的なウェブページを開きます。ブラウザーも失敗するなら、ウェブとDNSの章に戻ります。ブラウザーが正常なら、回線と基本プロキシは少なくとも一部が利用できるため、対象アプリ、振り分けルール、プロキシ継承、アプリキャッシュに範囲を絞れます。一つのアプリが失敗しただけで、サブスクリプション全体を削除しないでください。

次に、そのサービスのウェブ版とアプリ版を比較します。ウェブ版は正常でアプリ版だけ失敗する場合、アプリがシステムプロキシを読み取っていない、接続前に作られた古いセッションを保持している、独立したネットワークインターフェースを使っている、振り分けルールで直結と判定されている、といった原因が考えられます。ウェブ版とアプリ版の両方が特定のサービスだけで失敗するなら、回線地域、対象サービスの状態、アカウント地域を確認します。

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

システムプロキシモードは、システム設定に従うアプリにだけ有効です。ブラウザーは通常読み取りますが、一部のアプリ、コマンドラインツール、ゲーム、独自ネットワークスタックを持つソフトウェアは無視することがあります。仮想ネットワークモードはより低い層で通信を引き受けるため、対応範囲は一般に広くなりますが、システム権限が必要で、セキュリティソフト、ルーティングテーブル、スリープ復帰の影響も受けやすくなります。

最も直接的な比較方法は、回線を固定して通信の引き受けモードだけを切り替えることです。切り替え前に切断し、切り替え後に再接続してから、対象アプリを完全に終了して開き直します。仮想ネットワークモードでアプリが復旧するなら、元の問題はプロキシ継承に近いと考えられます。どちらのモードでも失敗するなら、振り分けルール、DNS、対象サービスを引き続き確認します。モード切り替えと同時に回線を変えないでください。どの変更が効果を生んだか分からなくなります。

振り分けルールが何に適用されているか確認する

ルールモードは、ドメイン、アドレス、アプリ、ルールセットに応じて通信をプロキシ経由にするか直結にするか決定します。対象サービスがメインドメイン、ログインドメイン、静的リソース用ドメイン、APIドメインを同時に使う場合、その一部だけがプロキシ対象になると、ページは開くのにログインできない、画像が読み込まれない、メッセージを送信できないといった不完全な障害が起きます。クライアントの接続記録で対象アプリがアクセスしたドメインと、それぞれに適用された経路を確認してください。

ルールが原因か確認するには、一時的にグローバルプロキシモードで再テストします。グローバルモードは切り分け専用で、長期設定に適しているとは限りません。グローバルモードで正常、ルールモードで失敗するなら、適用されたルールを確認します。どちらも失敗するなら、単純な振り分けの問題ではありません。テスト後は元のモードに戻して結果を記録し、意味を理解しないままルールを一括削除しないでください。

アプリのキャッシュと古い接続を処理する

加速サービスに接続する前にアプリが確立したセッションは、元の経路を使い続けることがあります。デスクトップに戻るだけでは接続が再構築されない場合があるため、アプリを完全に終了して再起動します。アプリにログアウトやキャッシュ消去の機能があっても、まずは影響の小さい再起動から始め、アカウントセッションの異常を確認してから再ログインします。最初からローカルデータをすべて削除すると、新たなログインや同期の問題が起きるおそれがあります。

ネットワーク切り替え後は、古いDNS結果が残ることもあります。ブラウザーは正常でアプリだけ失敗し続ける場合は、クライアントを切断してアプリを閉じ、再接続してからアプリを起動します。この順番なら、アプリは新しいネットワーク経路で初回接続を作成できます。それでも失敗する場合は、同じ地域の別回線を比較します。回線変更で復旧するなら元の回線と対象アプリを記録し、アプリの再インストールだけで復旧するなら、アプリのローカル状態が原因である可能性が高くなります。

地域と対象サービスの関係

一部のストリーミングやオンラインサービスは、出口地域、アカウント地域、コンテンツのライセンス、ログイン状態に応じて異なる結果を返します。回線で一般的なウェブページを開けても、すべての地域コンテンツが利用できるとは限りません。対象サービスに応じて地域を選び、ノードページのストリーミングタグを参考にしてください。Netflix、Disney+、YouTubeなどのタグは回線の絞り込みに使えますが、最終的にはアカウントやコンテンツ自体の条件も影響します。

アプリに地域やコンテンツが利用できないと表示された場合は、接続タイムアウトと混同しないでください。地域に関する表示は、アプリが何らかの応答を受け取ったことを示します。回線地域、アカウント状態、キャッシュを確認してください。接続タイムアウトなら、まず振り分けとネットワークを確認します。エラー原文は正確に記載し、「利用できない」とだけ書かないでください。正確なエラー種別は、対象サービスの制限、回線タグの変化、ローカルルールの問題を判断する助けになります。

コマンドラインツールと開発環境

コマンドラインツールは通常、デスクトップアプリのプロキシ設定を自動的に継承しません。現在のクライアントが提供するローカルプロキシ情報を確認し、ツール自身のドキュメントに従って環境変数やパラメーターを設定します。別のクライアントの待ち受けアドレスをそのまま使ったり、サブスクリプションURLをプロキシアドレスとして扱ったりしないでください。一時的なテストなら、まずシステムプロキシに対応するブラウザーで回線を確認してから、ツールの設定に進みます。

開発ツールは起動時にプロキシ環境を読み込むことがあり、実行中にシステム設定を変更してもすぐ反映されない場合があります。ターミナルや開発ツールを閉じて開き直し、テストコマンドを実行します。ブラウザーは正常でコマンドラインだけ失敗し、再起動後に復旧するなら、プロセスが古い環境を継承していたと考えられます。それでも失敗する場合は、ツールがプロキシを回避していないか、証明書チェーンを独自設定していないか、DNS問い合わせをどのコンポーネントが実行しているかを確認します。

ACCOUNT AND SUPPORT

デバイスの状態、プラン確認、問い合わせ送信

「デバイス数の上限」と表示された場合の判断方法

VPNZeは接続台数無制限に対応しているため、通常の利用で固定のデバイス数を接続上限とはしません。クライアントにセッション異常、認証失効、重複ログインのような表示が出ても、固定の台数制限と推測しないでください。同じアカウントの有効なサブスクリプションを使っているか、端末の時刻が正常か、サブスクリプションが更新済みかを確認し、過去の設定や別アカウントの内容をインポートしていないかも確認します。

複数のデバイスで同時に問題が起きた場合は、「同じサブスクリプションの提供異常」と「同じネットワーク環境の異常」を分けます。すべてのデバイスが同じ接続ネットワークにあり同時に失敗するなら、まず別のネットワークで比較します。異なるネットワークにあるデバイスでも同じサブスクリプションエラーが出るなら、アカウントと設定を確認します。一台だけ失敗するなら、その端末のクライアント、権限、システムネットワークを優先して確認します。接続台数無制限でも、端末ごとのローカル設定の違いを無視できるわけではありません。

プランと通信量の状態を確認する

接続失敗がプランの状態と混同されることがあります。ユーザーパネルで現在のサービス状態、通信量、期間を確認し、クライアントに残った回線一覧だけで判断しないでください。月額サブスクリプションは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれ、通信量は開通日を基準に毎月リセットされます。途中でアップグレードした場合の差額は残りの日数に応じて計算されます。通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、永久に失効しません。

パネルの状態が正常なのにクライアントがサブスクリプション無効と表示する場合は、サブスクリプションを再取得して設定を更新します。パネルの状態に継続利用の手続きが必要な場合は、プランページで選択内容を確認し、ユーザーパネルから処理してください。支払い方法はAlipay、WeChat、USDTに対応しています。プランの問題と回線障害は分けて説明します。前者ではパネルの状態と注文、後者では回線、ネットワーク、エラーログを確認します。二つを曖昧な説明に混ぜると、確認に時間がかかります。

最小限の確認を終えてから送信する

問い合わせ前に、少なくとも次の点を確認します。未接続時の基本ネットワークは正常か、すべてのアプリに影響するか特定のアプリだけか、同じ地域の別回線を試したか、システムプロキシと仮想ネットワークモードを比較したか、サブスクリプションを更新できるか、スリープ、ネットワーク切り替え、混雑時間帯がきっかけか。すべての設定を変更する必要はなく、症状に関係する比較だけを行います。

まったく接続できない場合は、クライアントの起動状態、回線名、最初のエラーを添えます。ウェブが開けない場合は、ブラウザーのエラーとDNS確認結果を添えます。速度が遅い場合は、実際の用途、時間帯、比較した回線を添えます。頻繁に切断される場合は、きっかけとなった操作と復旧方法を添えます。サブスクリプションの更新に失敗する場合は、リクエストまたは解析エラーを添えます。特定のアプリだけ失敗する場合は、ブラウザー版とアプリ版の比較結果を添えます。

対応可能な問い合わせに必要な内容

パスワード、サブスクリプションURL、完全な設定ファイル、アクセス認証情報を含むスクリーンショットは送信しないでください。ログは障害付近だけを切り取り、それぞれの内容に対応する操作を記載します。一つの問い合わせに無関係な問題が複数ある場合は、症状ごとに分け、どの問題を個別に再現できるか説明します。サポートは再現経路で判断するため、端末の遠隔操作やアカウントのパスワードは必要ありません。

早めにサポートへ連絡すべきケース

複数の接続ネットワーク、複数のプラットフォーム、複数の回線で同じエラーが出る、パネルとクライアントの状態が明らかに一致しない、サブスクリプションを継続して取得できず古い設定も使えない、特定の回線が異なる端末でも同じように異常を示す、権限を確認してもクライアントコアが起動しない、といった場合は、設定を無作為に変更し続ける効果は低く、直接問い合わせを送信してください。

単一ブラウザーのキャッシュ、単一アプリの古いセッション、スリープ後にインターフェースが復旧しない問題なら、まず該当する章の手順を試します。特定の時間帯だけ発生する障害は、その時間帯を記録してから問い合わせてください。通常の時間帯では再現できない可能性があります。問い合わせの入口はユーザーパネルにあります。登録にメールアドレスは不要で、ユーザー名とパスワードでアカウントを利用できます。

切り分け後の仕上げ

問題が復旧したら、一時的に変更した項目を一つずつ元に戻し、効果を確認できた設定だけを残します。一時的にグローバルモードを使った場合は、普段必要なモードに戻します。テスト用設定を作った場合は、メイン設定が安定したことを確認してから整理します。ほかのネットワークツールを停止していた場合は、一つずつ戻し、問題が再発しないか確認します。これにより、一時的な変更を複数重ねたまま本当の原因を見失うことを防げます。

短い記録も残しておくと便利です。元の症状、確認できた原因、有効だった操作、現在の回線タイプを記録します。次に似た問題が起きたときは、きっかけが同じかを先に確認し、すべての手順を機械的に繰り返さないでください。ネットワーク障害は似た見た目でも根本原因が異なることがあります。信頼できる方法は、まず層を分け、最小限の変更で比較することです。