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

ネットワークと接続の基本

まったく接続できない：まず問題の範囲を確認

再現できる形で状況を記録する

まず「クライアントが起動しない」「接続を押すとエラーが出る」「接続中と表示されるが通信がタイムアウトする」を区別しましょう。問題が起きている段階によって原因も対処法も異なります。最後に正常に使えたときのネットワーク、接続先、端末の状態を記録し、現在どの画面で止まるかを書き留めてください。最近システムプロキシを変更した、設定を読み込んだ、ネットワーク関連ツールをインストールした場合は、その変更を別に記録し、いったん追加の変更は控えましょう。

VPNを切断し、普段アクセスできるサイトが正常に開くか、端末がネットワークアドレスを取得しているか確認します。通常のウェブサイトも開けない場合は、Wi-Fiや有線接続、ネットワークのログイン画面、ルーターを先に確認してください。公衆ネットワークでは、ブラウザーで接続確認を済ませる必要がある場合があります。基本のネットワーク接続が復旧する前に接続先を切り替えても、タイムアウトが増えるだけで、国際経路そのものに問題があるとは判断できません。

アカウント、サブスクリプション、クライアントの状態を確認

アカウント概要を開き、プランの状態、残りの通信量、サブスクリプション情報を取得できるか確認してください。クライアントに設定が残っていても、アカウントの状態が変わっている場合があります。「接続先の一覧が表示される」だけでは、有効な状態であることの確認にはなりません。管理画面も開けない場合は、まず管理画面へのアクセス失敗として記録し、クライアントの接続失敗と混同しないようにしてください。

クライアントの接続コアが実際に起動しているか、必要なネットワーク権限がシステムから許可されているか確認します。一覧に表示される接続先の名前や、アプリのホーム画面にあるスイッチは、あくまで画面上の情報です。コアの起動失敗、権限の拒否、設定の解析エラーがあると、通信は接続経路に送られません。表示されたエラー全文を確認し、スクリーンショットを保存してください。トラブルシューティングのためにシステム保護を長期間無効にしたり、見知らぬ配布元のファイルでアプリを置き換えたりしないでください。

一度に一つの条件を変えて範囲を絞る

現在の設定を残したまま別の接続先に切り替え、次に元の接続先のままローカルネットワークを変えて試します。テスト中は同じサイトを使い、アプリ、ルール、ネットワークを同時に変更しないでください。特定の接続先だけ失敗する場合は、その経路に原因がある可能性が高まります。同じネットワークでどの接続先も失敗し、ネットワークを変えると直る場合は、ローカルの接続環境を優先して確認しましょう。異なるネットワークと接続先の両方で失敗する場合は、サブスクリプション、権限、コアのエラーに戻って確認してください。

複数のネットワーク制御ツールを同時に使うと、システムプロキシ、ルーティング、仮想ネットワークインターフェースが競合することがあります。別のVPN、プロキシツール、業務用ネットワークソフトが動作していないか確認し、問題がなければ不要なツールを終了して再テストしてください。組織の管理下にある端末では管理ポリシーに従い、セキュリティ機能を自己判断で削除しないでください。ツールを終了するたびにシステムプロキシが元に戻っているか確認し、停止したプログラムを指す設定が残らないようにしましょう。

端末の日時が大幅にずれていると、証明書の検証や安全な接続に失敗することがあります。システムの日付、時刻、タイムゾーンが正しいか確認し、エラーに証明書やハンドシェイクが関係しているかを調べてください。この種の警告が出ても、検証を無視したり、安全確認を無効にしたまま使ったりしないでください。日時を直しても解決しない場合は、対象、エラー文、発生した段階を記録し、ローカル環境と接続経路のどちらに原因があるかサポートに確認してもらいましょう。

自分での確認を切り上げる目安

ログに設定の無効、コアの起動失敗、権限の拒否が繰り返し表示される場合は、接続先を切り替え続けても解決しません。まず該当するローカルエラーに対処してください。一方、コアが正常に起動し、基本のネットワークとサブスクリプションにも問題がないのに、異なるネットワークで接続タイムアウトが繰り返される場合は、問い合わせを検討しましょう。すべての接続先が不安定とだけ伝えるより、失敗する接続先と正常な接続先を比較して伝えるほうが原因を特定しやすくなります。

再インストールを最初の手段にしないでください。まず個人情報を隠したエラー情報と設定の入手元を保存しましょう。アプリをすぐに初期化すると、原因の特定に役立つ記録まで消えたり、古いシステムプロキシ設定が残ったりすることがあります。

接続が復旧したら、日常利用の設定に戻し、診断のために一時的に有効にした広範なルールを残さないようにしてください。接続先と回線タイプの違いはグローバルノードの説明を、初回の読み込みがまだ完了していない場合は使い方ガイドを確認してください。目的は再起動後にたまたま接続できることではなく、再現可能な原因を見つけることです。

通信、名前解決、ウェブサイトの読み込み

接続できるのにサイトが開かない：DNSと通信の問題を切り分ける

すべてのサイトか、特定のサイトだけかを確認

接続を維持したまま、普段使える一般的なサイトと問題のあるサイトをそれぞれ開きます。前者は正常で後者だけ失敗する場合は、対象の地域、アプリ別ルール、サービス側の状態を確認してください。すべてのサイトが開かない場合は、システムプロキシ、DNS、クライアントが通信を実際に転送しているかを優先して確認します。ブラウザーのエラー文も重要です。「サーバーが見つかりません」と「接続がリセットされました」は、それぞれ名前解決と接続の段階を示すため、どちらも速度低下として扱うことはできません。

別のブラウザーまたは単独のアプリから同じサイトにアクセスしてみましょう。特定のブラウザーだけ失敗する場合は、拡張機能、ブラウザーのプロキシ、安全なDNSの設定を確認します。すべてのアプリで失敗する場合は、システムまたはクライアント側が原因の可能性があります。テストの際、閲覧履歴やログイン情報をすべて一度に削除しないでください。まず新しいブラウザーウィンドウでキャッシュや拡張機能の影響を切り分け、原因の方向がわかってから該当サイトのデータだけを削除しましょう。アカウントのセッション問題が元の障害に加わるのを防げます。

DNSが応答を返すか確認

DNSはドメイン名をネットワークアドレスに変換し、アドレスを取得した後に接続が始まります。システムで名前解決ができても、クライアント内のDNSが正常とは限りません。クライアントが独自の名前解決経路を使う場合があり、ブラウザーが独自の安全なDNSを使うこともあります。現在の設定説明とログを確認し、どこで名前解決されているかを把握してから、結果が空なのか、エラーなのか、想定する地域と異なるのかを調べてください。複数の経路で得た結果を区別せずに比較しないようにしましょう。

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

上記のコマンドは、該当するツールがインストールされた環境で利用できます。前者はそのツールが使用する名前解決経路を確認し、後者はウェブサイトへの接続を試みてレスポンスヘッダーを取得します。正常な結果が出ても、テスト対象にアクセスできることを示すだけで、すべてのアプリが現在の接続先を使っている証拠にはなりません。ツールがない場合、見知らぬソフトをわざわざインストールする必要はありません。ブラウザーのエラーとクライアントのDNSログを保存し、サポートに確認を依頼してください。

セキュリティ警告をネットワーク最適化の手段にしない

証明書エラーが出たら、まず端末の日時を確認し、ログインが必要な公衆ネットワークに接続していないか調べてください。ネットワークのログイン画面が初回アクセスに影響し、ブラウザーに証明書の警告が表示されることがあります。「使えるか確認する」ために証明書の検証を無効にしたり、出所不明の証明書をインストールしたりしないでください。証明書エラーが出たドメインを記録し、通常のネットワークに切り替えて再テストすると、ローカル接続と対象サイトの問題を区別できます。

ドメインの名前解決ができても、ウェブサイトが読み込み中のままなら、クライアントのログに対象への接続記録があるか、どのルールと接続先が使われたか確認します。対象の記録がない場合は、アプリの通信がクライアントを経由していない可能性があります。記録があるのに接続できない場合は、接続先、対象アドレス、通信経路を引き続き確認してください。拒否ルールや直接接続ルールが表示される場合は、ルールの適用が想定どおりか先に確認し、通信ルールの誤りを隠すためにDNSを変更しないでください。

システムやブラウザーのキャッシュに古い結果が残ることがあります。設定を変えても古いアドレスが使われ続ける場合に限り、該当する名前解決キャッシュの削除を検討し、削除前後の違いを記録してください。キャッシュを消しても無効なサブスクリプションは直らず、第三者サービスのアカウント地域も変わりません。システムコマンドはプラットフォームによって異なります。慣れていない場合は、システムのネットワーク設定やクライアントの復元機能を使い、ほかのネットワーク設定を誤って変更しないようにしましょう。

比較結果をもとに次の手順を決める

診断時に適当に入力したDNSアドレスを長期間使わないでください。サポートされている設定に戻して日常使うアプリを再確認し、クライアント内の通信記録も確認します。特定のネットワークでのみ問題が出る場合は、そのネットワークの種類とログインの要否を問い合わせに記載してください。異なるネットワークでも同じ名前解決エラーが出る場合は、個人情報を隠したログを添えましょう。すでに確認済みの基本条件についてサポートから何度も質問されるのを防げます。

DNSの正常動作、接続の確立、サービス側でのアクセス許可は、それぞれ別の条件です。地域制限やアカウントに関するメッセージが表示された場合は、DNSキャッシュを何度も削除するのではなく、アプリ別ルールの項目を確認してください。

通信経路と実際の使用感

速度低下と夜間の混雑：通信経路を比較して確認

まず、どの操作で「遅い」と感じるかを記録する

ウェブサイトの表示開始に時間がかかる、動画がバッファリングを繰り返す、ファイル転送が止まる、AIの応答が始まらないといった症状は、それぞれ異なります。ウェブサイトは名前解決、接続、コンテンツの取得を経て表示されます。動画はプレーヤーのバッファ、配信元、画質にも左右されます。AIツールではサービス側の処理待ちが発生することもあります。どの操作をしたとき、どの段階で遅くなったかを記録し、クライアントの接続テストだけで使用感全体を判断しないようにしましょう。

ほかの端末やアプリによる継続的なダウンロード、クラウド同期、大容量ファイルのアップロードを一時停止してから、同じ対象で再テストします。家庭内ネットワークの上り回線が使われていると、ダウンロードに余裕があってもウェブのリクエストが待たされることがあります。Wi-Fiの電波状態と端末・ルーター間の接続を確認してください。可能であれば、より安定したローカル接続と比較しましょう。VPNを切断しても通常のネットワークが遅い場合は、プランを変更するのではなく、まずローカルネットワークを確認してください。

接続先を変えるときはテスト条件をそろえる

現在のネットワークで、対象の地域に適した別の接続先を選び、同じアプリ、同じコンテンツ、同じルールで試します。地域が近いからといって、実際の通信経路が短いとは限りません。ローカルの接続、回線の入口、中継経路、対象サービスの所在地がすべて使用感に影響します。接続先の提供地域はノードページで確認できます。実際に選べる接続先は管理画面やクライアントのサブスクリプションに表示される内容を基準にし、名称から帯域や品質を推測しないでください。

回線タイプは接続先を選ぶ際の参考になりますが、実際の使用結果に代わるものではありません。IEPL専線、中継、直結は通信経路の構成を示しており、すべての対象、ネットワーク、時間帯で同じ結果になるとは限りません。タイプを切り替えた後、「バッファリングが続く」状態から「再生が始まる」状態に変わったか観察し、結果を記録しましょう。一度たまたま改善したからといって、継続的な速度を保証するものとして記載しないでください。比較のために複数の速度テストを同時に実行するのも避けましょう。

夜間の問題は発生時刻とネットワークを比較して記録する

日中は使えるのに夜間に何度も遅くなる場合は、発生した時間帯、使用したローカルネットワーク、接続先を記録し、翌日に同じ組み合わせで比較します。夜間の混雑は家庭のWi-Fi、ローカルの通信事業者ネットワーク、回線の入口、対象サービスのいずれでも起こり得ます。夜に発生したという理由だけで、どの区間に原因があるかは判断できません。ローカルネットワークを変えて改善した場合は接続環境を優先して確認し、接続先を変えて改善した場合は、その違いを問い合わせに記載しましょう。

動画アプリが以前の地域判定やメディア接続を保持していることがあります。接続先を変えたら、現在の再生をいったん終了し、同じコンテンツを再び開いてください。必要に応じてアプリを再起動し、多数の接続先を続けて切り替えるのは避けましょう。プレーヤーが画質を自動調整しているかも確認してください。画質の変化は必ずしも切断を意味せず、バッファリングが続いても必ずしもサービスの地域制限とは限りません。配信作品と視聴環境については、Disney+の地域と接続安定性に関する説明も参考にしてください。

AIツールのウェブサイトは開くのに応答が遅い場合は、リクエストが送信されたか、サービスが処理中と表示しているか、ほかのウェブサイトも同時に遅いかを確認します。生成処理だけが待ち状態になる場合、サービス側の負荷、アカウントの状態、リクエスト内容が関係している可能性があり、ネットワークの切り替えだけでは説明できません。リクエストが送信されない、または接続が中断される場合は、クライアントの記録とアプリ別ルールを確認してください。利用場面の詳しい説明はAI特集をご覧ください。

通信量のプランを性能診断の代わりにしない

月額サブスクリプションの通信量プランの違いは、利用できる通信量を示すものであり、速度の保証が異なるという意味ではありません。通信量は開通日を基準に毎月リセットされ、途中でプランをアップグレードした場合の差額は残り日数分に換算されます。通信量パックは使い切るまで有効で、期限はありません。アカウントに通信量が残っていないと表示される場合は、まずアカウントの状態を確認してください。通信量に余裕があるのに特定の対象だけ遅い場合は、通信経路の確認を続けましょう。料金とプランの詳細はプラン料金をご覧ください。

比較では、接続先かローカルネットワークのどちらか一つだけを変更します。対象、ルール、操作をそろえておけば、「接続先を変えたら改善した」という結果を原因の特定に役立てられます。

速度の問題を問い合わせる際は、常に遅いのか、特定の時間帯だけなのかを記載し、正常にアクセスできる対象も比較用に添えてください。アプリのホーム画面だけが写ったスクリーンショットでは、バッファリングや待ちがどこで発生するか伝わりません。利用できる接続先が見つかった場合は、その経路を使って日常の作業を続けながら、サポートに問題の組み合わせを調べてもらえます。診断を待つ間、元の設定を何度も変更する必要はありません。

セッションとシステムのバックグラウンド動作

頻繁な切断とバックグラウンド切断：発生条件を確認

切断、ネットワーク切断、アプリの再接続を区別する

まずクライアントのスイッチがオフになるか、システムのVPNアイコンが消えるか、アプリがコンテンツを再読み込みしているだけかを確認します。クライアントは接続中の表示なのにウェブに応答がない場合は、通信経路が中断している可能性があります。スイッチが自動でオフになる場合は、コアの終了やシステム権限が関係しているかもしれません。特定のアプリだけが再接続する場合は、アプリのセッションに問題がある可能性もあります。すべての再ログインをVPNの切断とみなさず、現象を分けて記録しましょう。

画面ロック、ネットワークの切り替え、省電力モードへの移行、ノートパソコンの蓋を閉じたとき、スリープから復帰したときに毎回問題が起きるか振り返ってください。ネットワークを切り替えると基盤となる接続が変わり、既存のセッションを再確立する必要があります。スリープ中はアプリの動作が停止するため、復帰後に再開するまで遅れることもあります。発生条件を再現できる場合は、ランダムに接続先を変えるのではなく、その条件に沿って確認してください。発生前後のログ、特にコアの終了、ネットワークの変化、再接続に関する記録を保存しましょう。

モバイル端末でバックグラウンド動作とネットワーク権限を確認

Androidでは、システムのVPN許可が有効か確認してから、クライアントのバッテリー管理とバックグラウンド動作の設定を確認します。設定メニューの名称は端末によって異なりますが、通常はアプリ情報、バッテリー、バックグラウンド管理などにあります。接続を維持する必要のあるクライアントだけを適切に調整し、すべてのアプリを無制限にする必要はありません。設定後に画面をロックして再テストし、システムがクライアントのプロセスを終了するか記録してください。

クライアントがバックグラウンドで現在のネットワークを使えるか、省電力設定によってバックグラウンド動作が制限されていないかも確認してください。端末によっては、アプリの終了操作で接続コアも停止し、画面に戻ると「勝手に切断された」ように見えることがあります。まず手動終了の影響をなくし、それから回線の問題かどうか判断しましょう。接続手順の詳細はAndroidクライアントとサブスクリプションのガイドをご覧ください。

iOSでは、システムのVPN設定に構成が存在するか、接続状態がクライアントの表示と一致しているか確認してから、クライアントに戻って現在の選択を確認してください。別のアプリが作成したVPN構成と、今回使っている構成を混同しないようにしましょう。画面ロック後に対象アプリのセッションだけが終了し、システムの接続が維持されている場合は、対象サービスのセッションポリシーを確認します。初回の許可設定とサブスクリプションの読み込みはiPhone接続ガイドをご覧ください。

パソコンのスリープとネットワーク切り替えを確認

Windows、macOS、Linuxでは、スリープ、ネットワークアダプターの再有効化、Wi-Fiの切り替えによって既存の接続が変わることがあります。まず通常のネットワークが復旧したことを確認し、クライアントを手動で再接続して安定するか調べてください。セッション維持のために省電力機能をすべて無効にしたままにせず、まず復帰時だけ問題が起きるか確認しましょう。再接続で復旧する場合は、スリープからの復帰が発生条件であると問い合わせに記載すると、関係のない回線テストを減らせます。

Wi-Fiの電波が弱い場所では、切断と再接続が繰り返され、端末が複数のアクセスポイント間を移動することもあります。同じ場所、同じネットワークで再テストし、ほかのリアルタイムアプリも同時に切断されるか確認してください。すべてのアプリに影響する場合は、まずローカルネットワークを調べます。通常のネットワークは正常なのにクライアントのコアが繰り返し終了する場合は、エラー記録と実行権限を確認してください。異なるローカルネットワークでも同じコアエラーが再現する場合は、早めに問い合わせましょう。

設定を戻してから、症状が続くか確認

クライアントによっては、自動再接続、オンデマンド接続、接続維持などの機能があります。名称や動作は実装によって異なるため、有効にする前に説明を読み、接続の復旧機能なのか、ルールの切り替えなのかを確認してください。自動再接続で復旧しやすくなることはありますが、無効なサブスクリプション、使い切った通信量、誤った設定は修復できません。再接続を繰り返してもアクセスできない場合は、繰り返し試行による影響を止め、接続できない場合の項目に戻って基本条件を確認しましょう。

証明書の検証を無視したり、システム保護を停止したり、プロセスを強制終了し続けたりして接続を維持しないでください。まずバックグラウンド権限とコアの状態を確認してから、回線側の中断について検討しましょう。

テストで一度復旧したら、画面ロック後にアプリを開き直す、スリープから復帰して同じサイトにアクセスするなど、問題が起きたときの操作で再確認します。切断が続く場合は、再現する操作、端末のOS、クライアント名、接続先を記録し、切断前後の個人情報を隠したログを添えてください。サポートが必要とするのは、単に「切断」と表示された画面ではなく、切断を引き起こす一連の条件です。

設定の取得とアカウントの状態

サブスクリプションの更新に失敗：取得と解析を切り分ける

まず、どの段階で失敗したか確認

サブスクリプションの更新では、通常、まず外部から内容を取得し、次にクライアントが解析して、最後に接続先一覧を更新します。ネットワークのタイムアウト、権限エラー、設定の解析失敗はそれぞれ別の段階の問題です。更新結果に表示されたメッセージ全文を確認し、内容を取得できなかったのか、取得後に認識できなかったのかを見極めてください。一覧に変化がなくても、サーバー側の内容に変更がなかった可能性があります。クライアントの表示もあわせて確認しましょう。

アカウント概要を開き、プランの有効状態、通信量、サブスクリプションの取得先を確認して、リセット済みまたは無効になった古い情報を使い続けないようにしてください。メールアドレスは不要で、ユーザー名とパスワードで登録できます。ログイン情報はアカウントへのアクセスに使い、サブスクリプション情報はクライアントへの接続設定に使うため、互いに代用できません。ログインパスワードをサブスクリプションの入力欄に入れたり、アカウント確認のために完全なサブスクリプションURLを問い合わせに貼り付けたりしないでください。

コピー内容、入手元、クライアントとの適合性を確認

管理画面からサブスクリプションを再取得するときは、対応するコピーまたは読み込みの入口を使い、チャットアプリやテキストエディターによってURLに改行が挿入されていないか確認します。手動で貼り付けた場合は前後の空白とコピー範囲を確認しますが、内容全体を第三者に送って確認を頼まないでください。クライアントによって対応する設定形式が異なるため、現在のクライアントに合った入口を選びます。設定ファイル、ウェブページのアドレス、サブスクリプションURLは、見た目だけで相互に置き換えられません。

ブラウザーで管理画面を開けるのにクライアントの更新がタイムアウトする場合は、サブスクリプションの取得がブラウザーとは異なるネットワーク経路を使っているか確認してください。更新時にシステムネットワークを使うクライアントもあれば、現在の接続経由で取得できるものもあります。詳しくは設定説明を確認しましょう。現在の接続先が使えない状態で、その経路を使って更新しようとすると悪循環になることがあります。基本のネットワークが正常な状態で、サポートされている更新方法を試し、URLを根拠なく書き換えないでください。

更新時にクライアントの設定ではなくウェブページ、ログイン画面、エラーメッセージが返されると、解析に失敗します。管理画面内の有効な入口を使っているか、公衆ネットワークのログイン画面が影響していないか確認してください。返されたページを設定ファイルとして保存して何度も読み込んだり、ネット上の汎用変換サイトにサブスクリプションをアップロードしたりしないでください。アカウントへの接続情報が見知らぬサービスに渡るおそれがあります。

元の設定を残し、形式の問題を切り分ける

現在の設定が使えている場合は、まずその設定を残してください。クライアントが対応する方法でテスト用設定を新規作成し、更新を試します。これにより、古い設定にあるローカル上書きルールと新しいサブスクリプション内容を切り分けられます。テスト用設定をすぐに自動起動にしたり、元の設定から必要な項目を削除したりしないでください。新しい設定だけが成功する場合はローカルの変更を重点的に確認します。両方で同じ解析エラーが出る場合は、エラーに記載された項目名をサポートに伝えましょう。

クライアントが未対応の項目や設定形式を示した場合は、項目を削除する前に、取得元の入口とクライアントが合っているか確認してください。その項目がDNS、ルール、接続方法に関係していることがあります。削除すれば読み込めても、日常の通信経路が変わる可能性があります。クライアントは管理画面のダウンロードページから入手してください。ログイン後にサブスクリプションを取得できます。実際に取得できるクライアントは、管理画面に表示されるプランの状態によります。

通信量のリセット、プラン変更、一覧更新を区別

月額サブスクリプションの通信量は開通日を基準に毎月リセットされるため、暦月が変わっただけで通信量が回復したと判断しないでください。途中でプランをアップグレードした場合の差額は残り日数分に換算され、アカウントの表示が基準になります。通信量パックは使い切るまで有効で、期限はありません。ただし、通信量を使い切った後も接続できるという意味ではありません。サブスクリプションの更新は接続設定を再読み込みする操作であり、通信量の追加や注文状態の修正は行いません。請求に関する問題は、アカウントと注文情報を確認してください。

サブスクリプションURLは機密性の高い接続情報です。ログ、スクリーンショット、公開の質問では、URL全体、トークン、QRコードを隠してください。実際のサブスクリプションをオンラインの設定解析ツールに入力しないでください。

更新が完了したら、クライアントで更新した設定が選択されていることを確認し、接続先一覧と現在の接続先を見直してください。設定が複数あると、更新に成功したのが現在使っているものではない場合があります。管理画面の状態が正常でも、ネットワークを変えて再取得した後に更新が失敗する場合は、失敗した段階、クライアント名、使った入口の種類、個人情報を隠したエラーメッセージを添えて問い合わせてください。アカウントや注文に関する質問は、該当する注文情報を添えて別途問い合わせましょう。

アプリ、ルール、接続元の地域

特定のアプリでプロキシを使えない：適用ルールを確認

まずアプリの通信がクライアントに届いているか確認

ブラウザーでは海外のウェブサイトにアクセスできるのに、特定のアプリだけ使えない場合は、そのアプリの通信がクライアントの接続記録に表示されるか確認します。記録がない場合は、アプリが独自のネットワーク設定を使っている、システムプロキシが適用されない、またはより前の段階でルールによって除外されている可能性があります。記録がある場合は、適用されたルールと選択された接続先を確認してください。接続アイコンやブラウザーでのアクセス結果だけでは、別のアプリも同じ経路を使っているとは判断できません。

システムプロキシは、設定に従うアプリに接続経路を提供するもので、すべてのプログラムを自動的に経由させるわけではありません。独自のネットワーク接続を管理するアプリもあり、クライアントによって対応する接続モードも異なります。現在のモードの説明を読み、設定変更が必要か判断してください。権限やルーティングへの影響がわからないまま、広範囲の通信制御を有効にしないでください。業務用端末や管理対象ネットワークでは既定のポリシーに従い、組織が定める通信経路を独自に変更しないようにしましょう。

一時的な比較で通信ルールを確認

クライアントでルールモードを切り替えられる場合は、元の設定を保存してから、診断に適した全通信プロキシモードを短時間だけ選び、対象アプリを再起動してテストします。この状態で復旧した場合、元のルールを調べる手がかりになりますが、回線に問題があると証明されたわけではありません。テストが終わったら元のモードに戻し、接続記録を見て、適用漏れや誤判定がないか確認してください。一時的な診断設定を常用すると、ほかのアプリの通信経路が変わるおそれがあります。

アプリはログイン、コンテンツ、メディア、リソース用の複数のドメインに接続することがあるため、ホームページのドメインだけを対象にしても不十分な場合があります。ログインは成功するのに画像が表示されない、ホーム画面は開くのに再生できないなど、失敗する操作に対応する通信を確認し、関連するルールを探してください。キーワードだけを頼りに広範囲のルールを追加したり、見知らぬ配布元からルールセット全体を置き換えたりしないでください。どの種類の通信が想定した接続先に送られていないか確認してから、サポートされている方法で修正しましょう。

ローカルの上書きルール、ユーザー設定のルール、サブスクリプション内のルールには、優先順位がある場合があります。特定のドメインにプロキシを使う表示なのに実際の記録が直接接続になっている場合は、より優先順位の高いルールに上書きされていないか確認してください。ルール名は実際の適用結果と同じではありません。接続記録のほうが実際の動作を反映します。変更前後のルールとテスト結果を保存し、競合が解消しない場合は個人情報を隠したルール部分を問い合わせに添えてください。サブスクリプションやアカウント情報を含む設定全体はアップロードしないでください。

地域制限と接続エラーを分けて確認

対象サービスから地域、アカウント、利用資格に関するメッセージが返された場合、通信はサービスに届いているものの、利用条件を満たしていない可能性があります。これはネットワークのタイムアウトとは異なる問題です。サービスは接続元の地域、アカウント設定、支払い情報、既存のセッションなどをもとに利用環境を判定することがあります。VPNFZの接続先を選んでもサービス側のルールを変更することはできません。地域を切り替える前に対象サービスの要件を確認してください。第三者のアプリや配信作品が必ず利用できるとは限りません。

AIツールのウェブサイトへのアクセスと、アカウント機能の利用可否も別の確認項目です。サイトは開くのに機能が使えない場合は、アカウントのメッセージ、サービスの提供地域、アプリの権限を確認してください。リクエストがタイムアウトする場合は、接続記録と回線の確認に戻りましょう。地域判定と利用環境についてはClaudeの接続先選びに関する説明をご覧ください。診断に余計な条件が加わらないよう、テスト中は接続元の環境をできるだけ一定に保ちましょう。

キャッシュと古いセッションが以前の経路を保持していることがある

ルールや接続先を変更しても、対象アプリが以前の接続を使い続ける場合があります。まず現在の処理を停止し、アプリを終了して開き直してから、新しい接続記録を確認してください。必要な場合に限り、該当アプリのキャッシュだけを削除します。ログイン情報を消す場合は、再度ログインできることを先に確認してください。すべてのアプリやブラウザーのデータを一度に消すと、元のネットワーク問題が新たなログイン認証の問題に置き換わり、変更の効果を判断できなくなります。

アプリ別ルールを確認するには、具体的な操作、対応する通信、適用ルール、選択された接続先、サービスからの応答が有効な手がかりになります。「ブラウザーは正常で、アプリは使えない」とだけ伝えても、どこで問題が起きているか特定するには不十分です。

同じ対象でもブラウザーとアプリで結果が異なる場合は、両者の違いを問い合わせに記載し、失敗した操作の前後にある個人情報を隠した記録を添えてください。すべての接続先で同じアカウント関連のメッセージが返される場合は、サービス側のルールに従って対応しましょう。特定のルールを使ったときだけ通信が拒否される場合は、適用されたルールの情報を送ってください。動画配信については動画視聴に関する特集も参考になりますが、実際のアクセス結果とサービスのポリシーが優先されます。

プラットフォームの違いとアカウント共有

プラットフォームと複数端末：端末ごとの問題を切り分ける

「デバイス数の上限」メッセージは、まず表示元を確認

VPNFZでは台数無制限で同時に利用できます。デバイス数に関するメッセージが表示された場合は、アカウントの管理画面、クライアント、アクセス先の第三者サービスのいずれが表示したものか確認してください。対象サービスには独自のセッションや端末に関するルールがあり、VPNFZの制限と同じとは限りません。メッセージが表示された画面、操作、個人情報を隠したスクリーンショットを保存してください。表示にデバイスと書かれているだけで、すぐにプランを変更したり、ほかの端末の設定を削除したりしないでください。

同じアカウントでも端末によって動作が異なる場合は、同じ有効なサブスクリプションを使っているか、選択中の設定と接続先が一致しているか確認してください。特定の端末だけ古い入口を使っていたり、異なるローカルルールが動作していたりする可能性があります。アカウントの状態が同じでも、ローカルの接続設定まで同じとは限りません。正常な端末を比較対象にする場合は、設定の入手元、ルールモード、ネットワーク環境を比較し、システム設定を一式そのままコピーしないようにしましょう。

端末とネットワークを組み合わせて比較

問題のある端末を正常な端末が使っているネットワークにつなぎ、次に正常な端末を問題のある端末が使っていたネットワークにつなぎます。対象と接続先は同じにしてください。問題がネットワークに追随する場合は接続環境を優先して確認します。端末に追随する場合は、権限、クライアントのコア、システムプロキシを調べましょう。家庭内のすべての端末を再インストールしたり、一斉に接続先を切り替えたりする必要はありません。動作している条件を比較対象として維持できます。

複数端末で同じローカルネットワークを使うと、継続的なアップロード、クラウド同期、動画再生などがネットワークを共有します。台数無制限という案内は、同時利用のポリシーを示すものであり、ローカルルーター、Wi-Fi環境、対象サービスのリソースまで無制限という意味ではありません。複数端末を同時に使うと遅くなる場合は、不要な通信を一時停止し、単独利用と同時利用を比較してください。家庭内共有の範囲と端末の扱いについては複数端末での利用ガイドをご覧ください。

プラットフォームごとにシステムへの接続方法を確認

Windowsでクライアントを終了した後、通常のウェブサイトも開けなくなった場合は、システムプロキシが停止済みのローカルプログラムを指していないか確認してください。クライアントの通常の終了または復元機能を使い、システムのネットワーク設定を確認します。macOSでは現在使用中のネットワークサービスを確認し、使っていないインターフェースだけを変更しないようにしてください。ネット上にある固定のポート番号をそのままローカルプロキシに設定せず、現在のクライアントの実際の設定に従いましょう。

Linuxではデスクトップアプリ、ターミナルのプロセス、システムサービスがそれぞれ異なるプロキシを使う場合があります。ターミナルのプログラムは独自の環境変数を参照することもあるため、ブラウザーが正常でもコマンドラインの処理が同じ経路を通っているとは限りません。アプリのドキュメントと現在のプロセス設定を確認し、必要に応じて環境の違いを記録してください。診断用プロキシをグローバルな起動ファイルに残したままにせず、認証情報を含む環境変数をそのまま問い合わせに貼り付けないでください。

設定はそろえつつ、別のプラットフォームへそのまま適用しない

モバイル端末ではシステムの許可、ネットワーク切り替え、バックグラウンドでの動作が主な確認点です。デスクトップでは複数のプロキシ入口が同時に存在することがあります。同じサブスクリプションでも、クライアントによって表示方法や対応する設定が異なる場合があります。設定を同期するときは各プラットフォームでサポートされている読み込み方法を使い、別のOSの設定ファイルの場所や権限項目をそのままコピーしないでください。初回インストールと読み込みは使い方ガイドに従ってください。

アカウントを共有する場合は、ログイン情報とサブスクリプション情報を適切に管理し、信頼できる端末だけで使用してください。情報が漏れた可能性がある場合は、管理画面で利用できる機能を使ってアカウントの安全性とサブスクリプションを確認し、ほかの端末で有効な設定を再取得します。家庭内での利用確認を、サブスクリプション情報の公開につなげないでください。スクリーンショットではパスワードだけでなく、QRコード、リンク、アカウント識別情報も隠し、接続情報が漏れないようにしましょう。

VPNFZの管理画面に表示された案内で、「台数無制限で同時利用可能」というポリシーと一致しない場合は、上限の意味を推測せず、メッセージのスクリーンショットと発生までの手順を添えて問い合わせてください。サポートが確認します。

複数端末に関する問い合わせでは、どの端末が正常でどの端末に問題があるか、ネットワーク、サブスクリプション、接続先を共有しているかを明記してください。「パソコンは使えるが、ほかの端末は使えない」だけでは重要な違いがわかりません。比較テスト後も特定の端末で問題が起きる場合は、その端末のOS、クライアント、コアのエラーを添えてください。特定のネットワークで問題が起きる場合は、ネットワークの種類と再現条件を記載しましょう。

証拠の整理とサポートへの引き継ぎ

問い合わせと対応：再現できる情報を伝える

切り分けの範囲を超えたらサポートに相談

基本のネットワークが使え、プランの状態も正常で、クライアントのコアも起動するのに、異なるネットワークや接続先で同じ接続エラーが繰り返される場合は、問い合わせを検討してください。サブスクリプションの入口から再取得しても解析に失敗する、管理画面と注文の状態が一致しない、または台数無制限のポリシーと矛盾するメッセージが表示される場合も、サポートによる確認が必要です。「もう一度試す」ために設定を変更し続けず、問題が起きた状態を保つことが大切です。

管理対象の端末、システム権限、組織のネットワークポリシーに関わる問題は、管理者に相談し、管理対象のコンポーネントを自己判断で削除しないでください。対象サービスからアカウントや地域に関するメッセージが表示された場合は、サービスの要件に従い、ネットワーク接続とアカウントの問題を分けて説明しましょう。サポートは接続経路の確認を支援できますが、第三者サービスによるアカウント審査を代行したり、すべてのサービスが現在の接続環境を常に受け入れると保証したりすることはできません。

決まった形式で情報を整理

問い合わせ窓口はユーザーパネルにあります。ログインして送信してください。まず「画面をロックした後もクライアントは接続中と表示されるが、対象のウェブサイトがタイムアウトする」のように、症状を一文で説明します。次に発生時刻、端末のOS、クライアント名、現在の接続先、ルールモード、ローカルネットワークの種類を記載してください。実施した比較テストと結果も列挙し、サポートが同じ基本テストを繰り返す必要がないようにしましょう。

症状：接続後に発生する具体的な問題
環境：端末のOS、クライアント名、ローカルネットワークの種類
設定：現在の接続先、ルールモード、サブスクリプションの状態
発生条件：対象を開く、ネットワーク切り替え、画面ロックや復帰などの操作
比較結果：接続先、ネットワーク、端末を変更した後の結果
エラー：画面に表示された内容と個人情報を隠したログ
希望する対応：接続の復旧、サブスクリプションの確認、注文内容の確認

クライアント情報は、アプリ内に表示されている名称と実際の情報を記載し、記憶で推測しないでください。発生時刻は確認した時刻とタイムゾーンを記載すると、ログと照合しやすくなります。ローカルネットワークは家庭のWi-Fi、公衆ネットワークなど種類を説明すれば十分で、詳しい住所は不要です。対象アプリは名称と失敗した操作だけを記載し、問題に関係のない個人情報、会話、ファイルを送らないでください。

ログとスクリーンショットは個人情報を隠してから送信

問題の前後に関係するログだけを切り出せば十分です。最初からすべての履歴をエクスポートする必要はありません。ログにはドメイン、ネットワークアドレス、サブスクリプションの入口、アカウント識別情報が含まれることがあります。送信前に項目ごとに確認し、パスワード、トークン、サブスクリプションURL全体、QRコード、その他の接続認証情報を隠してください。エラーの種類、接続先の名前、発生順序は残しましょう。エラーの前後の情報まで削除すると「失敗」という表示だけになり、原因を特定できません。

スクリーンショットにはエラーが表示された画面と、必要な前後関係を含め、無関係なウィンドウや個人情報は閉じてください。アプリ別ルールの問題では適用ルールと接続先を、サブスクリプション更新の問題では取得または解析の段階を示すメッセージを、注文状態の問題では管理画面にある該当注文の情報を残します。公開コメント欄にサブスクリプションURL全体を追加したり、サポートのためにアカウントのパスワードを伝えたりしないでください。

問い合わせ内でテスト結果を継続して共有

問い合わせ後も確認を続ける場合は、同じ問い合わせに新しい結果を追加し、変更した条件と復旧状況を明記してください。サポートから設定変更を提案されたら、まず現在の状態を保存してから指示に従って再テストし、改善した操作を伝えます。テスト中に再インストール、ネットワーク変更、接続先変更、対象変更を同時に行うと、何が原因で直ったのかわからなくなり、同じ問題が起きたときにも結果を活用できません。

一時的に利用できる接続先が見つかった場合は、その経路で日常の作業を続けながら、元の問題が起きた条件の情報を保存してください。問題が解消しても、診断用の設定をすべて長期間使うのが適切とは限りません。一時的なルールを戻し、通常の検証設定を復元して、ほかのアプリも想定どおりアクセスできるか確認しましょう。問い合わせを終える際は「直りました」だけでなく、最終的な接続先、設定の復元状況、問題が再発するかを伝えてください。

料金と返金は別途確認

接続の診断と料金の確認は関連する場合がありますが、必要な情報は異なります。料金の問題では注文、管理画面の状態、確認してほしい内容を記載し、ネットワークエラーだけを添付しないでください。VPNFZは理由を問わない7日間返金に対応しています。申請方法は返金ポリシー、利用条件は利用規約をご覧ください。接続を何度も試したからといって利用を続ける必要があると考えず、返金にかかる期間を独自に推測しないでください。

問い合わせでは接続情報ではなく、「環境、発生条件、比較結果、エラー、希望する対応」を伝えましょう。必要な情報をそろえながら、情報の安全も守れます。

最後に、元の症状、正常と確認できた条件、原因、効果のあった対応を簡潔に記録しておきましょう。同じ問題が再び起きたら、まず条件が同じか確認してから対処法を再利用します。新しい段階のエラーが発生した場合は該当する項目から確認し、前回の修正を万能な解決策と考えないでください。一般的な使い方の質問はよくある質問をご覧ください。サポートへの問い合わせはお問い合わせページからユーザーパネルの問い合わせフォームに進んでください。