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

再現できる確認基準を作る

原因を急いで決めず、まず症状を説明する

有効なトラブルシューティングは現象から始まります。「サービスが壊れている」ではなく、検証できる形に言い換えましょう。たとえば、クライアントが接続を完了できない、接続済みと表示されるのにブラウザでどのサイトも開けない、特定のアプリだけアクセスできない、通常時は使えるのに混雑時間帯だけ明らかに遅い、モバイルネットワークに切り替えると復旧する、といった具合です。こうした説明なら次に確認すべき層が決まります。一方、「ノードが悪い」「プロトコルに問題がある」といった表現は結論を先取りしており、その後の操作を誤った方向へ導きます。

現象を記録するときは、利用プラットフォーム、現在のネットワーク入口、選択した地域または回線タイプ、失敗した操作の4種類の状況を残します。プラットフォームは Windows、macOS、iOS、Android、Linux と記載します。ネットワーク入口は家庭用ブロードバンド、オフィスネットワーク、公衆無線ネットワーク、モバイルネットワークの区別で十分です。回線名はクライアントに表示された完全な名称を、操作は接続、サイトを開く、コンテンツを再生する、購読を更新する、バックグラウンドから復帰するなど具体的に書きます。エラー表示は記憶で要約せず、原文をコピーするかスクリーンショットを保存してください。「認証失敗」「名前解決失敗」「接続タイムアウト」では確認すべき層がまったく異なります。

最小限の比較条件を作る

最小限の比較条件の目的は、すぐに復旧させることではなく、何が変わると症状も変わるかを確認することです。同じデバイスと同じクライアントを維持したまま、現在のネットワークだけを別の利用可能な入口に切り替えます。症状がネットワークに応じて変わるなら、ローカルネットワーク、ルーター、ネットワーク事業者を優先して確認します。どちらの入口でも失敗する場合は、別の地域の回線に変更します。特定の回線だけ異常なら原因は回線に絞られます。すべての回線で失敗するなら、アカウント状態、購読内容、クライアント設定を確認します。

次に、同じネットワークと同じ購読を使い、対応プラットフォームを別のものに変えて比較します。別のデバイスで接続できるなら、アカウントと回線はおそらく利用可能なので、元のデバイスでクライアント権限、システムプロキシ、DNS、バックグラウンド制限、古い設定の残留を確認します。別のデバイスでも失敗する場合は、再インストールを繰り返さず、まずユーザーパネルにログインして購読状態を確認し、現在の購読を再取得してください。VPNRZは Windows / macOS / iOS / Android / Linux に対応し、同時接続台数に制限がないため、通常の複数デバイス比較がデバイス数制限で無意味になることはありません。

一度に一つの条件だけ変える

トラブルシューティングで最も多い誤りは、時間を節約しようとして複数項目を同時に変更することです。たとえば設定を削除し、プロトコルを切り替え、さらにルーターを再起動する、といった操作です。最後に復旧しても本当の原因が分からず、次回は最初からやり直すことになります。より確実なのは、現在の回線、プロトコル、ネットワーク入口、結果を簡単に記録する方法です。毎回一項目だけ変更し、接続状態が安定してから同じ対象をテストします。変化がなければ元の値に戻してから次の項目へ進みます。

テスト対象も固定してください。まず、普段安定していてログイン不要の一般サイトを一つ選び、その後に実際に問題が起きているサービスを試します。一般サイトと対象サービスの両方が失敗するなら、接続、ルーティング、DNSを確認します。一般サイトは正常で対象サービスだけ失敗するなら、出口地域、アプリの振り分け、対象サービスの状態、アカウント地域を確認します。最初から複雑なアプリだけを判断基準にしないでください。アプリには独自キャッシュ、プライベートDNS、内蔵プロキシ、地域設定があるため、回線の問題とアプリの問題が混ざりやすくなります。

この章を終えるころには、問題を明確な入口に分類できるはずです。まったく接続できない、接続済みだがサイトが開かない、速度や混雑時間帯に異常がある、頻繁に切断される、購読更新に失敗する、特定アプリだけプロキシを使わない、モバイル端末がバックグラウンドで切断される、DNSに異常がある、アカウント状態が一致しない、といった分類です。以降の章でも同じ原則を使います。まず層を判断し、次に操作し、最後に元のテスト対象で再確認します。

クライアントがまったく接続できない場合の判断

「未設定」と「設定後の失敗」を分ける

クライアントに回線が一つも表示されない、または回線リストが空の場合、通常は接続プロトコル自体ではなく、購読がまだインポートされていない、インポート内容が無効、クライアントが設定を読み込めていないことが原因です。この場合は接続ボタンを何度も押さず、まずユーザーパネルから購読を再取得し、クライアントが対応する方法でインポートしてください。購読内容はアカウントに紐づく情報なので、完全なアドレスを公開の掲示板に貼ったり、検索エンジンで開いたりしないでください。初回設定に不慣れな場合はクイックスタートガイドに戻り、プラットフォームごとのインポートを完了するほうが、空の設定で接続を調べるより確実です。

回線は表示されるのに、クリックするとすぐ未接続に戻る場合は、クライアントログまたはエラーダイアログを確認します。認証エラーなら、現在のアカウントで生成された購読か、コピー時に文字が欠けていないか、古い設定が選択されたままではないかを優先して確認します。タイムアウトなら、ネットワーク入口と回線を先に変更します。システム権限のエラーなら、ネットワーク接続に必要なシステム許可をクライアントが取得しているか確認します。「タイムアウト」だけでアカウント無効と判断したり、「認証」だけでルーターを何度も再起動したりしないでください。エラーの種類が、より近い確認層を示しています。

アカウント、回線、ネットワーク、システムの順に確認する

まずパネルにログインできることを確認し、現在の購読がまだ利用可能な状態か確認します。月額購読の通信量は開通日を基準に毎月リセットされます。通信量を使い切っている場合、接続時の挙動が通常と異なることがあります。通信量パックは使い切るまで利用でき、期限はありません。状態を確認したら購読を再取得し、クライアントの設定を更新します。メールアドレスは不要で、ユーザー名とパスワードだけで登録できます。ただし切り分けの際は、別のユーザー名で保存した空のアカウントではなく、元のアカウントにログインしていることを確認してください。

アカウントに問題がなければ、別地域の回線に切り替えます。VPNRZは100+か国 / 220+回線をカバーしており、回線ごとに入口や中継が異なるため、一つの回線の失敗からすべての回線が使えないとは判断できません。まず現在地に近い地域を選び、その後に別の回線タイプを試します。回線リストとタイプの説明はグローバルノードページで確認できます。切り替えるときは、前の接続が完全に切れてから新しい接続を開始し、古いセッションが解放されていないことによる表示の混乱を避けてください。

複数の回線でタイムアウトする場合は、ネットワーク入口を切り替えます。家庭用ブロードバンドでは失敗し、モバイルネットワークでは正常なら、クライアントと購読には接続能力があるため、ルーター、ローカルDNS、オフィスネットワークのポリシー、現在の接続環境を重点的に確認します。オフィスや公衆ネットワークでは一部の接続方式が制限されることがあります。その環境では自分が管理していないネットワーク機器を変更せず、ログを保存して管理可能なネットワークで確認を続けてください。すべてのネットワーク入口で失敗する場合は、システム時刻が自動同期されているか、システムのネットワーク権限が無効になっていないか、セキュリティソフトが最近ネットワークルールを変更していないかを確認します。

むやみに再インストールせず、古いセッションを整理する

クライアントには、正常に終了しなかった仮想ネットワークセッションが残ることがあります。まずクライアント内で手動切断し、プログラムを完全に終了してから再起動します。システム上でプロキシまたは仮想ネットワークが有効なままなら、システムのネットワーク設定で該当項目を無効にし、クライアントを再起動します。古い設定を削除したり再インストールしたりするのは、設定をバックアップし、購読を再取得できることを確認してからにしてください。すぐにアンインストールすると、ログや状況情報まで削除され、明確だったエラーが再現できない偶発的な問題になりかねません。

再インストール後もまったく接続できない場合は、再インストールを繰り返さないでください。より有効なのは相互検証です。同じアカウントで別のデバイスを使う、同じデバイスで別のネットワークを使う、同じネットワークで別の回線を使う、という比較を行います。3つの結果から、原因をデバイス、ネットワーク、サーバー側の回線に絞れます。対応プラットフォーム、複数のネットワーク入口、複数の回線が同じ時間帯にすべて失敗するなら、その比較結果を問い合わせに添えるほうが、「接続できない」とだけ書くより正確な対応につながります。

エラーが特定のネットワークでだけ発生するなら、ネットワークの種類と再現した時間を記録します。特定の回線だけで発生するなら、回線の完全な名称を記録します。特定のプラットフォームだけで発生するなら、システムとクライアント名を記録します。サーバー側の原因を自分で推測しないでください。目的は「まったく接続できない」という状態を、設定生成、クライアントの読み込み、回線ハンドシェイク、ローカルネットワーク、システム権限のどこで失敗したか検証できる分岐に分けることです。

接続済みなのにサイトが開かない・DNS異常

「接続済み」はトンネルが確立したことを示すだけ

クライアントが接続済みと表示するのは、ローカルクライアントと選択した回線の接続処理が完了したという意味です。ドメイン名の解決、システムルーティング、対象サービスまで正常とは限りません。この場合は接続ボタンに注目し続けず、ドメイン、ネットワーク出口、アプリを分けてテストします。まずログイン不要の一般サイトを開きます。すべてのサイトが失敗するなら、コマンドラインでレスポンスヘッダーを取得できるか確認します。一般サイトがすべて失敗する場合、DNSが応答を返していない、システム通信がトンネルに入っていない、古いプロキシ設定が引き続き通信を横取りしている、接続後にローカルネットワークのルートが正しく更新されていない、といった可能性があります。

ドメインだけ開けず、既知のネットワークアドレスへ直接アクセスすると応答がある場合は、問題はDNSに近いと考えられます。ドメインは解決できるのにリクエストが待機し続けるなら、ルーティング、回線、対象側の応答に近い問題です。感覚で判断する必要はなく、システム標準のツールで確認できます。例示のドメインはテスト専用で、実際の購読情報は含みません。

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

nslookup が名前解決結果を返すのに curl がリクエストを確立できない場合、少なくとも解決処理は応答しているため、システムプロキシ、ルーティング、回線を確認します。名前解決コマンド自体が失敗するなら、まずシステムのDNSキャッシュを消去し、クライアントを切断して再接続します。コマンド実行時は完全な出力を保存してください。最後の1行だけではなく、前半のサーバー情報、タイムアウトの説明、エラー種別も役立つ可能性があります。

キャッシュを消去する前に影響範囲を確認する

ブラウザだけサイトを開けず、他のアプリは正常なら、まずブラウザのプライベートウィンドウで試し、ブラウザ内に個別設定されたプロキシ拡張機能を一時的に無効にします。ブラウザには古いDNS、証明書状態、プロキシルールがキャッシュされていることがあり、すぐにシステム全体を変更する必要はありません。ブラウザ、コマンドライン、他のアプリがすべて失敗する場合に、システムレベルのDNSとプロキシを確認します。まずクライアントを切断し、接続していない状態でローカルネットワークから一般サイトへ正常にアクセスできるか確認します。ローカルネットワーク自体に問題があるなら、先に基本ネットワークを復旧してから接続を確認します。

DNSキャッシュの消去方法はシステムによって異なります。以下のコマンドはいずれも一般的なシステム操作ですが、実行後は再接続し、同じドメインをもう一度テストしてください。Linuxでは、具体的なサービスがディストリビューションとネットワーク管理方式によって異なります。コマンドが使えない場合は、実際に有効な名前解決サービスを確認し、ネット上から合わない設定ファイルをコピーしないでください。

システムプロキシとアプリ独自の名前解決経路を確認する

システムプロキシと仮想ネットワークモードが同時に存在する場合があります。以前にプロキシアドレスを手動入力し、その後クライアントのグローバル接続モードへ変更した場合、古いアドレスがブラウザのリクエストを横取りしている可能性があります。システムのネットワーク設定を開き、現在のプロキシ状態とクライアントの動作方式が一致しているか確認します。企業管理設定や見覚えのないシステム設定を勝手に削除しないでください。組織管理のデバイスなら、まず管理者に確認します。個人所有のデバイスなら、元の値を記録したうえで手動プロキシを一時的に無効にし、クライアントを再接続して確認できます。

一部のブラウザやアプリは独自のセキュアDNSやプライベート名前解決を有効にするため、システムコマンドが正常でもアプリが同じ経路を使うとは限りません。特定のブラウザだけ失敗するなら、そのブラウザの設定で独自DNSが指定されていないか確認します。特定のアプリだけ失敗するなら、後述のアプリ振り分けの章を確認してください。複数のDNSアドレスを無計画に一つずつ試さないでください。頻繁に変更すると、キャッシュ、システム設定、クライアント設定が同時に変わり、どの項目が作用したのか分からなくなります。

もう一つよくある現象として、一般サイトは開くのに特定地域の出口を必要とするサービスが地域不一致と表示する場合があります。これはDNS障害ではないため、現在選択している回線地域を確認し、対象アプリを再起動して古いセッションを消去します。対象サービスはアカウント地域、キャッシュ、出口地域、独自ポリシーからコンテンツ範囲を判断することがあり、一つの表示だけで回線全体が使えないとは判断できません。同じ回線で一般サイトを確認してから、条件に合う別地域の回線と比較してください。

キャッシュ消去、古いプロキシの無効化、回線とネットワーク入口の切り替え後もすべてのドメインが解決できない場合は、名前解決コマンドの完全な出力、プラットフォーム、回線名、ネットワーク種別を添えて問い合わせてください。対象サービスだけが異常なら、一般サイトは正常だった比較結果も添えます。これにより、トンネルは確立しており、問題が名前解決、ルーティング、対象サービスの層にあることをサポートへ明確に伝えられます。

速度低下と混雑時間帯の遅延を切り分ける

スループット、応答時間、アプリのバッファリングを分ける

「遅い」という表現には、サイトの初回表示に時間がかかる、ファイル転送速度が継続的に低い、動画や通話が断続的にバッファリングする、という3つの異なる現象が含まれます。サイトの初回表示は名前解決と応答経路の影響を受けやすく、継続転送はローカル帯域、回線混雑、対象側の制限に左右されます。動画や会議では、ジッター、パケット損失、アプリの適応処理も影響します。確認前にどの現象かを明確にし、速度テストのスクリーンショットだけを送らないでください。スクリーンショットは、あるテスト対象を特定のセッションで測った結果にすぎず、実際のアプリが遅延する理由を単独では説明できません。

まずクライアントを切断し、ローカルネットワーク自体に明らかな異常がないか確認します。基本ネットワークが混雑している場合、国際回線もその条件の上で動作するしかありません。次にデバイス、ネットワーク、テスト対象を固定し、近い地域の回線に接続して実際の利用場面を繰り返します。クラウド同期、システム更新、大容量ファイル転送を同時に実行しないでください。これらのバックグラウンド処理が上り下りの帯域を奪います。会議の問題では特に上り方向を確認してください。映像の送信が滞ると、相手側での遅延がより目立つことがあります。

地域名だけでなく、目的に合う回線を選ぶ

対象がアジアにある場合は近隣地域から試し、欧米のサービスへアクセスする場合は対象サービスの地域と実際の結果を考慮して選びます。地理的に近いほど経路が短くなる傾向はありますが、国際経路は入口、通信事業者間接続、中継方式にも左右されます。地図上の距離だけで判断しないでください。VPNRZは IEPL 専線、中継、直結などの回線タイプを提供しており、用途と経路構成が異なります。グローバルノードで回線の説明を確認し、固定した対象で一項目ずつ比較してください。

IEPL 専線は国際経路の安定性を重視する場面に適しています。中継回線は追加の入口を使って国際経路を構成し、直結回線はより直接的な経路を使います。ただし実際の結果はローカルネットワークと対象側にも左右されます。これらの名称は回線の構成方式を示すもので、場所や時間帯を問わず同じ結果を保証するものではありません。最も確実なのは、同じデバイス、同じネットワーク、同じ対象を維持し、利用可能なタイプを順番に試して実際のアプリ動作を記録する方法です。

混雑時間帯の問題は時間帯比較で確認する

通常時は正常で混雑時間帯に繰り返し遅くなる場合は、混雑がローカル接続と国際経路のどちらで起きているかを判断します。同じデバイスと同じ回線を維持して別のネットワーク入口で確認します。別の入口で明らかに正常なら、元のネットワーク接続を優先して調べます。異なる入口でも近い時間帯に似た現象が起きるなら、回線タイプまたは地域を変更します。時間が大きく離れた、対象も異なるテスト結果を直接比較しないでください。対象サービスの負荷やローカルのバックグラウンド処理も変化するためです。

混雑時間帯に遅延しているとき、大量の回線を連続して切り替えると判断が難しくなります。まず現在の回線を基準にし、近隣地域の回線を一つ、異なるタイプの回線を一つ選び、それぞれで実際の作業を最後まで行います。動画では再生開始、シーク、継続再生を確認します。会議では音声の連続性、映像の復帰、再接続を確認します。AIツールではページ読み込み、リクエスト送信、応答の継続出力を確認します。どの段階で異常が起きるか分かれば、名前解決、初回応答待ち、継続転送、セッション維持を切り分けられます。

プロトコルの変更は回線とネットワークの後に行う

プロトコルはハンドシェイク方式、通信特性、ネットワーク環境への適応性に影響しますが、速度問題に対する最初の答えとは限りません。まずアカウント、基本ネットワーク、回線が利用可能であることを確認し、その後にクライアントが提供する別の互換プロトコルを試します。変更前の値を記録し、変更後は同じ対象だけをテストします。プロトコル変更で接続成功率だけが改善し、継続転送が改善しないなら、回線とローカル帯域を引き続き確認します。特定のネットワーク入口だけがプロトコルの影響を受けるなら、ネットワーク種別とエラーログを併せて記録します。

一度のピーク値を追うあまり、安定性を無視しないでください。国際アクセスでは、サイトが安定して読み込めるか、会議が頻繁に再接続しないか、ストリーミングが何度も画質低下しないか、AIの応答が途中で止まらないかが重要です。ブログの接続成功率と切断率の確認方法も参考にし、単発のピーク値ではなく、繰り返しの作業で回線を判断してください。年間プランの比較軸が必要なら、速度・安定性・サポートの比較をご覧ください。

複数の回線で特定の対象サービスだけが遅く、一般サイトと他のアプリが正常なら、対象側の状態、アカウント地域、アプリキャッシュを検討します。すべての対象が遅いなら、基本ネットワークと回線を確認します。混雑時間帯だけ異常なら、異なるネットワーク入口と回線タイプで混雑箇所を分けます。パフォーマンス確認の核心は、最高値を一つ見つけることではなく、条件によってどの経路が変化するかを特定し、現在のネットワークと作業に安定した組み合わせを選ぶことです。

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

どの側がセッションを終了したかを先に確認する

頻繁な切断は、ローカルネットワークの一時的な切り替え、システムによるバックグラウンド処理の終了、クライアント自身の再接続、回線セッションのタイムアウト、無線ネットワークからモバイルネットワークへの切り替えなどで起こります。すぐに再インストールするより、切断前後のシステム状態を観察するほうが有効です。画面ロックのたびに起きるなら、バックグラウンド動作と省電力設定を確認します。移動中にネットワークが切り替わると起きるなら、切り替え後の再接続を確認します。デバイスを静置し、ネットワークが安定していても周期的に切断される場合に、回線とプロトコルを比較します。

まず基本ネットワークも同時に切断されていないか確認します。切断時に無線ネットワークの表示が消えていないか、他のデバイスも一時的にアクセスできなくなっていないか、ルーターが再接続していないかを観察します。LAN全体に異常があるなら、先に基本ネットワークを処理します。クライアントだけが切断され、通常のネットワークは正常な場合に限り、回線、プロトコル、バックグラウンド権限を確認します。二つの問題を混同すると、存在しない回線障害をサポートが繰り返し確認することになります。

モバイル端末ではバックグラウンド設定とネットワーク切り替えを確認する

モバイルOSは省電力状態、バックグラウンド活動の権限、ネットワーク品質に応じてアプリを管理します。画面ロック後に接続が消えるなら、クライアントのバックグラウンド実行が許可されているか、システムが厳しい省電力制限を適用していないか、仮想ネットワーク接続が引き続き許可されているかを確認します。変更後すぐに結論を出さず、再接続して画面をロックし、前面に戻して同じサイトまたはアプリで確認します。長時間静置した後だけ切断されるなら、バックグラウンド移行前後のクライアント状態とシステム表示を記録します。

無線ネットワークからモバイルネットワークへ切り替えると、既存の接続経路が変わるため、クライアントは通常セッションを再確立する必要があります。切り替え後も「接続中」のままなら、いったん手動で切断してから再接続します。スイッチを連続して操作しないでください。モバイルネットワークから無線ネットワークへ戻る場合も同様に確認します。一部の公衆無線ネットワークでは、先にウェブ認証が必要です。基本ネットワークが実際にはオンラインになっていなければ、クライアントは安定した接続を確立できません。クライアントを切断してネットワーク認証を完了してから、再接続してください。

モバイル端末で特定のアプリだけ前面復帰後にアクセスできず、ブラウザは正常なら、アプリのセッションキャッシュまたは振り分けルールの可能性が高くなります。対象アプリを完全に終了して再起動し、復旧するか確認します。復旧するなら、回線全体が切断されたわけではありません。すべてのアプリが失敗するなら、クライアントが接続済みと表示しているか、システムに仮想ネットワークの表示が残っているか、DNSが再割り当てされているかを確認します。アプリ自身のログイン期限切れを回線切断と誤認しないでください。

デスクトップではスリープ、ネットワークアダプター、古いプロキシを切り分ける

Windows、macOS、Linuxでは、スリープと復帰の後にネットワークアダプターの状態、ルーティングテーブル、DNSが変わることがあります。復帰後だけ問題が起きるなら、クライアントを切断し、基本ネットワークが復旧してから再接続します。基本ネットワークがまだアドレスを取得していない状態で、接続を連続して開始しないでください。外付けネットワークアダプター、ドッキングステーション、無線ネットワークの切り替えでも既存セッションが無効になることがあります。スリープ、アダプター切り替え、ネットワーク入口の変更が直前にあったかを記録します。

デスクトップでデバイスを継続稼働させているのに繰り返し切断される場合は、クライアントログを開き、各切断の直前に同じエラーがあるか確認します。エラーが同じで特定の回線だけに起きるなら、同じ地域の別回線と比較します。異なる回線でも同じネットワーク上で切断されるなら、ネットワーク入口を変更します。特定のデバイスだけ切断されるなら、その端末のセキュリティソフト、ネットワークドライバー、システムプロキシを確認します。最初からすべてのコンポーネントを更新したりドライバーを変更したりせず、影響の大きい操作は比較後に行ってください。

状態ランプだけでなく、安定した作業で確認する

クライアントの状態ランプが接続中でも、アプリのセッションが中断していないとは限りません。状態ランプが一時的に再接続しても、復旧機能を持つアプリなら影響がない場合があります。確認は作業を基準に行います。ブラウジングでは同じサイトを開き続け、会議では音声と映像が復旧するか、ターミナルでは長時間接続が切れないかを確認します。長時間維持したい作業中は、ネットワーク入口や回線を手動で切り替えないようにしてください。

ストリーミングだけが再生開始からしばらくしてバッファリングする場合、すぐに接続切断と分類せず、パフォーマンスの章に戻って継続スループットと対象側のポリシーを確認します。ページに名前解決エラーが表示されるなら、DNSの章に戻ります。クライアントが明確に接続済みから未接続へ変わり、ログにもセッション終了が記録されている場合に、回線、プロトコル、システムのバックグラウンド処理を重点的に調べます。正しく分類すれば、誤った章で同じ操作を繰り返さずに済みます。

ネットワーク、回線、デバイスの比較でも切断を特定できない場合は、切断前後のログ断片、プラットフォーム、回線名、ネットワーク入口、画面ロックやネットワーク切り替えの有無、通常のネットワークも同時に切断されたかを添えて問い合わせます。ログから個人の購読内容を隠すことはできますが、エラー時刻付近の前後関係を切り取らないでください。サポートには、どの層がセッションを終了したかが必要であり、切断後の最終画面だけでは不十分です。

購読更新に失敗し、特定のアプリがプロキシを使わない場合

購読更新の失敗は、まず取得経路を確認する

購読更新には、正しいアカウントへのログイン、現在の購読の取得、クライアントによる読み取り、設定の解析、ローカルの回線リストの置き換えという連続した工程があります。どこか一つが失敗しても「更新失敗」と表示されるため、どの段階で止まったかを確認する必要があります。パネルにログインできないなら、まずアカウント情報を確認します。パネルにはログインできるのにクライアントがアドレス無効と表示するなら、現在の購読をコピーし直します。クライアントが読み取れるのに解析エラーが出るなら、使用中のクライアントが購読内容に対応しているか確認します。更新成功後も回線が変わらないなら、古い設定グループを表示していないか確認します。

購読をコピーするときに文字を手動で削除したり書き換えたりせず、第三者の短縮URLサービスも使わないでください。購読はアカウント認証情報なので、自分のクライアントとユーザーパネルの間だけで扱います。購読が漏えいした疑いがある場合は、パネルでアカウントの提供情報を再処理し、問い合わせ本文に完全なアドレスを貼らないでください。「購読の読み込みで認証エラーが返る」と書くか、機密部分を隠したスクリーンショットを添えれば十分です。サポートが完全な認証情報を公開で確認する必要は通常ありません。

クライアントに複数の設定がある場合、更新ボタンは現在選択されているグループだけを更新することがあります。操作対象の設定名を確認してから更新し、完了後に回線リストが変わったか確認します。編集した設定のコピーを複数のクライアント間で何度もインポートしないでください。どれが現在の情報源か分からなくなります。購読の取得、インポート、漏えい時の対応については購読リンクの完全ガイドをご覧ください。

明らかなダミーアドレスで入力形式を確認する

入力欄が完全なURLを受け付けるか確認する場合は、文書の例で形式を確かめます。ただし例を実際の購読として使わないでください。以下のアドレスは公開の例示ドメインとダミートークンを使用しており、クライアントが途中で切れた文字列ではなく完全なリンクを必要とすることを確認するためだけのものです。

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

クライアントがアドレスを検索語として認識したり、自動的に空白を追加したり、文字の一部だけを残したりする場合は、システムクリップボードから貼り直し、入力欄が「URLからインポート」であって「ローカルファイル」ではないことを確認します。QRコードのインポートに失敗した場合も、カメラ権限の問題を購読の問題と誤認しないよう、テキスト方式に戻って確認します。更新完了後はまず回線を一つ選んで接続し、その後にアプリを確認します。回線リストが表示されるだけでは、接続が確立したとは限りません。

特定のアプリが動かない場合は、まずブラウザと比較する

ブラウザは正常なのに特定のアプリへアクセスできない場合、アカウント、回線、基本的な名前解決は少なくとも一部が利用可能です。ここでは、アプリがシステムプロキシに従うか、独自のネットワークスタックを使うか、振り分けルールで直結に設定されていないか、起動時に接続をキャッシュしていないかを確認します。対象アプリを完全に終了し、クライアントが接続済みであることを確認してから再起動します。復旧するなら、古いセッションが原因の可能性が高くなります。失敗が続くなら、変更前のモードを記録したうえで、クライアントのルールモードとグローバルモードを比較します。

ルールモードは、ドメイン、アドレス、アプリに基づいて通信を振り分けます。ルールの不足、古さ、対象サービスによる新しいドメインの追加により、メインページは開いても一部のリソースだけ読み込めないことがあります。グローバルモードでは正常でルールモードだけ失敗するなら、ルールセットとアプリが使うドメインを確認します。両方のモードで失敗するなら、回線地域、対象サービスの状態、アカウント地域を確認します。グローバルモードを唯一の恒久的な解決策にせず、振り分け層を特定するための比較手段として使ってください。

一部のアプリは従来のシステムプロキシを読み取らず、システムが確立した仮想ネットワークには従います。別のアプリは独自DNSや接続最適化を有効にすることもあります。プラットフォームによって動作も異なります。AndroidとLinuxにはアプリ単位の振り分け設定が存在する場合があり、macOSとWindowsではシステムプロキシと仮想ネットワークモードが併存することがよくあります。確認時は、まずクライアントが現在どの方式で通信を取り込んでいるかを確認し、対象アプリが除外されていないかを見ます。別のプラットフォームのメニュー名や設定経路をそのまま当てはめないでください。

対象アプリが特定地域の回線でだけ失敗し、他地域では正常なら、回線名とアプリ名を記録します。すべての回線でそのアプリだけ失敗するなら、アプリ起動後のエラー原文、ルールモードとグローバルモードの比較、ブラウザが正常かどうかを添えてください。購読更新に失敗する場合は、パネルにログインできるか、再取得後も失敗するか、クライアントの解析表示、古い設定が接続できるかを伝えます。購読の問題とアプリ振り分けの問題を分けて説明すると、サポートが別々の障害を一つの現象として扱わずに済みます。

デバイス数超過の表示とアカウント状態の確認

まず表示元を確認する

VPNRZは同時接続台数に制限がないため、「デバイス数超過」または類似の表示を見ても、本サービスの制限だと直接判断しないでください。まず、その表示がユーザーパネル、クライアント、OS、対象アプリのどこから出ているかを確認します。クライアントによってはローカル設定のインスタンス数を制限し、アプリによっては独自アカウントのログインデバイスを制限します。企業ネットワークが同時セッションを制限することもあります。表示文が似ていても、対処する場所はまったく異なります。スクリーンショットではウィンドウのタイトルと表示元を残し、中央の一文だけを切り取らないでください。

表示が対象のストリーミングサービス、AIツール、その他の第三者アカウントから出ているなら、そのサービス独自のアカウントルールを確認してください。本サービスが対象サービスのログイン制限を変更することはできません。クライアントからの表示なら、重複設定をインポートしていないか、古いプロセスがバックグラウンドで動いていないか、同じ設定を複数のローカルインスタンスとして認識していないかを確認します。VPNRZのパネルまたは回線接続中の表示なら、完全な原文を記録して問い合わせてください。同時接続台数無制限という仕様と一致しないため、アカウントセッションの状態を確認する必要があります。

複数デバイスで使うときはアカウントの取得元を統一する

家庭や個人で複数のデバイスを使う場合、起こりやすい問題はデバイス数ではなく、各デバイスが異なる時点で取得した購読を保存していることです。あるデバイスが古い設定を使い、別のデバイスが現在の設定を使っていると、「新しいデバイスが古いデバイスを追い出した」ように見えることがあります。正しい方法は、同じアカウントにログインし、パネルから現在の購読を再取得し、各デバイスで設定元を確認することです。メールアドレスは不要で、ユーザー名とパスワードだけで登録できます。そのため、似たユーザー名の別アカウントに入らないよう、正確なユーザー名を管理してください。

パスワードの変更、アカウント情報のリセット、購読の更新後も、古いクライアントにキャッシュが残ることがあります。まず問題のデバイスで購読を更新し、その後に切断して再接続します。同期のために設定ファイルを公開経路で他人へ送ったり、購読アドレスを共有ドキュメントに置いたりしないでください。複数人で使う場合は、誰がアカウント情報を更新するかを決め、各デバイスで別々に設定を編集しないようにします。

新しいデバイスだけ接続できず、元のデバイスは正常なら、アカウントと回線には通常利用可能な経路が残っています。2台のクライアントタイプ、設定グループ、回線名、ネットワーク入口を比較します。まず新しいデバイスを元のデバイスと同じネットワークで使い、同じ回線を選びます。それでも失敗するなら、新しいデバイスの設定またはシステム権限に近い問題です。新しいデバイスがネットワーク変更で復旧するなら、デバイス数ではなく元のネットワークを確認します。

アカウントにログインできても、購読状態が完全に正常とは限らない

ログイン成功は認証情報が有効だという意味にすぎません。現在のプラン、通信量、購読がそのアカウントに属しているかも確認してください。月額購読には ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれ、通信量は開通日を基準に毎月リセットされます。途中でアップグレードした場合は、差額が残り日数に換算されます。通信量パックは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、期限はありません。プラン状態が予想と異なる場合は、クライアントを変更し続けるのではなく、現在のユーザー名と注文を確認します。

途中でアップグレードした後に残り時間が変わった場合は、差額が残り日数に換算されたものとして理解し、アカウント異常と誤認しないでください。月額購読の通信量は開通日を基準にリセットされ、暦月単位で一律に変化するわけではありません。通信量の確認ではパネルの表示と開通日を基準にします。プランを選び直す必要がある場合は、料金ページでルールを確認し、ユーザーパネルから処理してください。Alipay / WeChat / USDT に対応しています。支払い後のアカウント状態に問題がある場合は、注文状態のページを保存し、同じ操作を何度も作成しないでください。

アカウント、購読、対象サービスのアカウントを分ける

一度の国際アクセスには、VPNRZアカウント、クライアントのローカル設定、対象サービスのアカウントが同時に関係することがあります。VPNRZのユーザー名は購読の取得に使い、クライアントは購読を読み込んで接続を確立し、対象アプリは独自のログイン方式を使います。対象アプリが再ログインを求めても、VPNRZアカウントからログアウトしたとは限りません。クライアントが設定の期限切れを表示しても、対象アプリのアカウントが無効になったとは限りません。切り分けでは3者を分けて記録し、誤った認証情報をリセットしないようにします。

購読情報を誰かが取得した疑いがある場合は、まずVPNRZアカウントを保護し、関連する提供情報を更新してから、各デバイスに再インポートします。アカウントの安全性が確認できないまま、同じ購読をさらに多くのデバイスへコピーしないでください。家庭内共有のデバイス管理が問題なら、複数デバイスのアカウントと同時接続ガイドを参考にし、ログイン数、同時接続、クライアントのローカルインスタンスを区別してください。

問い合わせには、現在のユーザー名を一部確認できる情報、表示元、プラットフォーム、クライアント名、新しいデバイスだけが失敗するか、元のデバイスが正常か、購読を再取得した後の結果を記載します。パスワードや完全な購読アドレスは送らないでください。注文に関係する場合は、パネルに表示された注文状態と予想との違いだけを説明します。サポートが確認するのはアカウントの帰属と購読状態であり、秘密の認証情報は必要ありません。

いつ問い合わせるべきか、問い合わせに含める情報

このような場合は直接問い合わせる

基本的な比較を終えても原因を特定できない場合、またはアカウント、注文、購読生成、複数回線の同時異常が明らかな場合は、問い合わせを送ってください。代表的なケースは、パネルのプランや通信量が実際の注文と一致しない、購読を再取得しても認証エラーが出る、複数の対応プラットフォーム、異なるネットワーク入口、複数の回線が同時に失敗する、同じ回線で再現可能なエラーが続く、クライアントログに明確なサーバー応答がある、VPNRZパネルに同時接続台数無制限と一致しない制限表示が出る、といった場合です。

ブラウザ拡張機能の一つだけが動かない、対象アプリ独自のアカウント制限が表示される、基本ネットワーク自体が切断されている、といった場合は、通常それぞれの製品やネットワーク環境で先に対応します。サポートは回線と購読の判断を支援できますが、第三者アプリのアカウントや本サービスに属さないネットワーク機器を変更することはできません。問題の範囲を明確に書くことで、どの側が対応すべきかを早く確認できます。

問い合わせの件名に症状と範囲を書く

件名に「使えない」「遅い」「急ぎ」だけを書かないでください。より有効なのは「プラットフォーム + 症状 + 影響範囲」の構成です。たとえば「Windowsクライアントで複数回線がタイムアウト」「iOSで画面ロック後に接続が切れる」「購読更新で解析エラー」「ルールモードで特定アプリにアクセスできない」などです。件名でサポートに障害層を伝え、本文で再現手順を説明します。無関係な問題を一つの件名に詰め込まず、アカウント状態とアプリの振り分けが同時にある場合も分けて書くと追跡しやすくなります。

本文はまず期待する結果を書き、その後に実際の結果を書きます。期待する結果は、接続後に一般サイトと対象アプリの両方へアクセスできることです。実際の結果は、クライアント状態、エラー原文、影響を受ける対象まで具体的に記載します。続いて、どの回線タイプを試したか、ネットワーク入口の変更で復旧したか、他のデバイスは正常か、一般サイトと対象アプリの結果が一致したかを列挙します。「全部試した」とだけ書かないでください。サポートには、その「全部」に何が含まれるのか分からないためです。

十分な状況を残しつつ、機密情報を隠す

スクリーンショットにはクライアント名、回線名、状態、完全なエラーを含めますが、ユーザー名、購読トークン、注文識別情報、その他の個人情報は隠してください。ログはエラー発生前後の一部を切り取り、最後の一文だけを残したり、問題と無関係なシステム情報全体をアップロードしたりしないでください。コマンドラインの出力は検索しやすいようテキストでコピーできます。ローカルのユーザー名やディレクトリが含まれる場合は、エラーの前後関係を壊さない範囲で隠します。

購読アドレスとパスワードを問い合わせ本文に書かないでください。アカウント確認が必要な場合、サポートは通常、ログイン済みのパネルから問い合わせに紐づく情報を確認できます。ログインできない場合も、ユーザー名とエラーの現象だけを伝え、パスワードは送らないでください。VPNRZはメールアドレス不要で、ユーザー名とパスワードだけで登録できます。そのためユーザー名は切り分けの状況を追跡する重要な手掛かりですが、公開ページには表示しないでください。

再現可能な手順を説明する方法

再現手順は、既知の状態から始めます。たとえば「基本ネットワークは正常で、クライアントは切断状態」と書きます。次に「特定の回線を選んで接続する」「一般サイトを開く」「対象アプリを起動する」と操作を記載します。最後に「クライアントは接続済み、一般サイトは正常、対象アプリは待機し続ける」と観察結果を書きます。この順序なら、サポートが近い条件で再確認できます。毎回起きるわけではない場合は、画面ロック後、ネットワーク切り替え後、購読更新後、混雑時間帯などの発生条件を記載します。

確認していない原因で現象を置き換えないでください。「回線サーバーが壊れた」より「この回線は接続がタイムアウトし、別の回線は正常」と書きます。「DNS汚染」より「ドメイン解決コマンドがタイムアウトし、直接接続テストは応答した」と書きます。「速度制限」より「通常時は正常で、混雑時間帯に継続転送が低下し、ネットワーク入口の変更で復旧した」と書きます。控えめな説明とは情報を減らすことではなく、事実と推測を分けることです。

返信を受け取った後の再確認方法

サポートから回線、設定、クライアントに関する提案を受けたら、まず元の基準に戻って確認します。返信で求められた変更だけを実行し、ネット上で見つけた別の設定を同時に追加しないでください。復旧した場合は、どの手順の後に戻ったか、元の問題を再現できるかを返信します。失敗した場合は新しいログとエラーを送り、古いスクリーンショットを繰り返し貼らないでください。これにより問い合わせに明確な変化の履歴が残り、最初から再確認する必要がなくなります。

アカウントや支払いに関する問題では、パネルの注文状態を保存してください。VPNRZはAlipay / WeChat / USDTに対応し、60日間の無理由返金を提供しています。具体的な申請はユーザーパネルの問い合わせから行います。問い合わせには確認したい注文と現在の状態だけを記載し、支払い情報を公開経路に表示しないでください。プラン内容を確認する場合は先に料金プランを見て、月額購読のリセットルール、通信量パックの期限なし、途中アップグレードの換算を一つの項目として混同しないようにします。

システム確認の終点は、すべての設定を一度ずつ変更することではありません。問題がアカウント、デバイス、ネットワーク、回線、時間帯、DNS、クライアント設定、対象アプリのどの変化に追随するかを明確にすることです。ローカルで解決できるなら、有効な設定と理由を保存します。サポートが必要なら、最小限の再現手順を問い合わせに渡します。次に似た症状が起きたときは、構築済みの基準から始め、影響の大きい操作を一式繰り返す必要はありません。