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

まったく接続できない：まず基本項目を確認

まず、通常のネット接続を確認する

「接続できない」には、アプリがトンネルを確立できない場合と、アクセス先のWebサイトが応答しない場合があります。まずVPNFlatを切断し、普段そのまま開けるWebサイトにアクセスして、現在のネットワークでWeb認証が必要か確認してください。ホテル、学校、公共のネットワークでは、接続済みと表示されても、利用規約への同意が済んでいないことがあります。正規の認証を済ませてから接続し、認証ページが開かないことを回線の障害と決めつけないでください。切断後も一般的なWebサイトにアクセスできない場合は、先に通常のネット接続を復旧させましょう。

現在の接続方法がWi-Fi、有線LAN、モバイルデータのどれかを記録し、可能であれば別の方法でも試してください。アプリと選択中の回線は変えず、接続ネットワークだけを切り替えると、結果を比較しやすくなります。ネットワークを変えて解消する場合は、元の接続環境、ネットワーク機器、通信制御に原因がある可能性があります。異なるネットワークでも失敗する場合は、アカウントの状態とアプリを確認してください。ネットワーク、回線、アプリを同時に変更したり再インストールしたりすると、解消しても原因を特定しにくくなります。

アカウントと接続の状態を分けて確認する

ユーザーパネルでプランが有効か、残りのデータ通信量が十分か、サブスクリプションを現在のアプリに追加済みか確認してください。パネルにログインできても、トンネルが確立したとは限りません。月額プランのデータ通信量は契約開始日を基準に毎月リセットされるため、暦月でリセット日を推測しないでください。データパックは使い切るまで有効で、期限はありません。パネルで利用可能なデータ通信量が残っていない場合は、先にプランの状態を確認してください。接続を何度切り替えても、アカウントの利用可能量は変わりません。

アプリに戻り、問題が発生する段階を確認します。接続ボタンを押すとすぐ停止する場合は、権限、設定の読み込み、ローカルサービスの表示を確認してください。「接続中」のまま進まない場合は、ログを見て、名前解決、接続先への到達、ハンドシェイクのどこで止まっているかを確認します。エラー表示は手がかりであり、原因を断定するものではありません。たとえばタイムアウトは、ネットワークに到達できない場合だけでなく、端末の時刻がずれている場合にも起こります。システムの時刻を自動設定にしてから、現在のサブスクリプションに実際に含まれる回線で試してください。サーバーアドレスやポートを推測して入力しないでください。

権限を確認し、条件を一つずつ変えて回線を試す

システムからVPN構成、ネットワーク拡張、仮想ネットワークインターフェースの追加を求められた場合は、利用者が許可する必要があります。以前に拒否した場合は、システム設定またはアプリのヘルプから再度許可してください。設定画面の名称や場所はOSによって異なるため、現在の端末に表示される内容を確認します。デスクトップアプリがローカルのバックグラウンドサービスに依存する場合は、そのサービスが起動しているかも確認してください。管理者権限はアプリが明確に必要としている場合にのみ許可し、トラブルシューティングのためにシステム保護を常時無効にしたり、提供元不明の修復プログラムを実行したりしないでください。

権限に問題がなければ、まず同じ地域の別の利用可能な回線を選び、その後で回線の種類を比較します。これにより、特定の接続先の問題か、アプリ全体の問題かを切り分けられます。IEPL専線、中継、直結は通信経路の構成方法であり、どの環境でも接続できる保証ではありません。回線の説明はノード一覧で確認し、中国本土向けのアクセスと海外向けのアクセスで接続先地域を取り違えないようにしてください。回線を切り替えるときは、先に現在の接続を切断し、アプリの状態が更新されてから再接続します。各テストの結果も記録してください。

特定のネットワークでのみ失敗する場合は、VPN接続に関するネットワーク管理者の方針を確認してください。どのネットワークでも失敗する場合は、ほかのプロキシやネットワークトンネルアプリを終了してから、VPNFlatを再起動して試します。ここでいう「終了」には、ウィンドウを閉じるだけでなく、バックグラウンドサービスも含まれます。どの段階で失敗するか、どの条件で復旧するかを問い合わせに明記すると、「接続中」と表示された画面だけを送るより原因を特定しやすくなります。

接続済みなのにWebページが開かない：名前解決とアクセスを切り分ける

接続成功とアクセス先の利用可否は別

アプリに「接続済み」と表示されても、Webページの閲覧には、ドメイン名の名前解決、通信の振り分け、Webサイトからの応答、ブラウザーの状態が関係します。まず、通常どおり開けるWebサイト、選択中の回線を経由するWebサイト、問題が起きたWebサイトをそれぞれ開いてください。すべて開けない場合は、ローカルプロキシとDNSを優先して確認します。特定のWebサイトだけ開けない場合は、そのサイトに表示されたエラーを保存し、システム全体のネットワーク設定をすぐに変更しないでください。症状によって確認すべき点は異なります。

エラーが名前解決の前に起きるのか、Webページの読み込み後に起きるのかを確認してください。「サーバーが見つかりません」「名前を解決できません」と表示される場合は、通常DNSの経路を確認します。Webページが表示され、地域、権限、アカウントに関するエラーが出る場合は、リクエストがアクセス先のサービスまで届いている可能性があります。DNSキャッシュの削除だけでは解決しないことがあります。ログイン状態、サービスの地域ルール、Webサイト側の一時的な障害でもアクセスに失敗するため、アクセス拒否をすべてVPNFlatの回線切断と判断しないでください。

DNSリクエストの経路を確認する

DNSはドメイン名をネットワークアドレスに変換します。OS、ブラウザー、アプリがそれぞれ別のキャッシュを保持したり、異なるDNSの入口を使ったりする場合があります。ブラウザーで独自の暗号化DNSを有効にし、アプリが同時にOSのDNSを引き受けていると、想定とは異なる経路でリクエストが送られることがあります。まず現在の設定を記録し、比較のため一時的にブラウザーをシステム設定に従わせてください。組織の管理端末の場合は、管理ポリシーを自分で解除せず、使用可能なDNSの方式を管理者に確認してください。

アプリにDNSモードの選択肢がある場合は、Web上の設定一覧をそのままコピーするのではなく、まず推奨設定に戻してください。ドメイン名をトンネル経由で解決する設定もあれば、ルールに応じてローカルとリモートを使い分ける設定もあります。どちらの場合も、通信経路と整合している必要があります。名前解決で返されたネットワークアドレスへ、現在のルーティングで到達できることも重要です。hostsファイルを変更してWebサイトのアドレスを固定しないでください。サービスのアドレスは変わることがあり、誤った固定設定は一時的な問題を長引かせる原因になります。

システムのツールで確認し、一つの結果だけで判断しない

デスクトップOSでは、ターミナルで次の読み取り専用の問い合わせを実行し、システムが名前解決の結果を返すか確認できます。例のドメイン名はコマンドの書式を示すためのものです。実際に調べる際は、問題が起きたWebサイトのドメイン名に置き換えてください。ログイン情報を含む完全なURLは貼り付けないでください。表示内容はOSによって異なります。DNSサーバー、アドレスが返されたかどうか、エラーの原文を記録しましょう。問い合わせに成功しても、そのとき名前解決できたことが分かるだけで、ブラウザーが同じ経路を使っていることや、Webページが開けることまでは確認できません。

nslookup example.com

システムの問い合わせでは正常なのにブラウザーで失敗する場合は、まずブラウザーを終了してから再起動し、プライベートブラウズウィンドウでも比較して、古いキャッシュや拡張機能の影響を切り分けます。プライベートブラウズウィンドウでも、一部の拡張機能が実行を許可されている場合があります。アプリのログに名前解決の失敗が続く場合は、接続ネットワークを変え、DNSを既定の設定に戻してから再度比較してください。ネットワークの確認リクエストに応答がないだけで回線が使えないと判断しないでください。アクセス先がその種類の確認を受け付けていない場合があります。

アプリを切断してもWebページにアクセスできない場合は、システムプロキシにローカルアドレスが残っていないか確認してください。まずアプリを正しく終了してプロキシ設定を復元します。自動で戻らない場合は、システム設定から手動プロキシと自動構成スクリプトを確認し、先に現在の値を記録してください。企業ネットワークで使用しているプロキシは、許可なく削除しないでください。特定の回線だけで名前解決に問題が起きる場合は、回線名と問い合わせ結果を保存してサポートに送ります。特定のWebサイトだけの問題であれば、ドメイン名とエラーの種類だけで十分です。閲覧履歴を送る必要はありません。

速度低下や夜間の混雑：通信経路ごとに比較する

まず、どの場面で遅いのかを特定する

Webページの初回表示、ファイルのダウンロード速度、ライブ配信の停止、ゲームの応答の遅れは、それぞれ異なる性能上の問題です。Webページの表示が遅い場合、名前解決や接続確立に時間がかかっている可能性があります。ダウンロードの遅さには継続的な通信速度がより影響し、ライブ配信ではバッファリング、コンテンツ配信、再生端末も関係します。どのアプリのどの操作が遅いのか、問題が継続して起きるのかを記録してください。一つのダウンロードだけでネットワーク全体を評価したり、アクセス先サービスの速度制限を回線の帯域不足と決めつけたりしないでください。

比較する際は、端末、アプリのモード、アクセス先のコンテンツを同じにして、時間帯、接続ネットワーク、回線をそれぞれ比べます。一度に変更する条件は一つだけにしてください。通常のネット接続自体が遅い場合は、Wi-Fiの電波、ルーター、バックグラウンドの通信を先に確認します。通常のアクセスは問題なく、特定の回線でのみコンテンツが遅い場合は、地域と回線の種類を確認してください。速度テストはデータ通信量を消費するため、何度も実行した後に残量が減ったことを根拠に、異常な消費と判断しないでください。

夜間は継続的な使用感を比較する

夜間の速度低下や途切れは、家庭内のWi-Fi、接続先の通信事業者、国際回線、アクセス先のプラットフォームのいずれでも発生する可能性があります。まず端末の同期、OSのダウンロード、大容量ファイルの転送を一時停止し、可能であればWi-Fiアクセスポイントに近づくか、有線接続に切り替えてください。家のほかの端末でも同時に遅くなる場合は、まずローカルネットワークの混雑を確認します。特定の時間帯だけVPN通信が遅くなる場合は、同じ回線の通常時と問題発生時の状態を記録し、再現条件をそろえて比較してください。

回線は、地域名や一度の測定結果だけで選ばないでください。地理的に近いと通信経路が短くなる可能性はありますが、ルーティング、接続品質、接続先のコンテンツ配信も重要です。中国本土向けのコンテンツでは回線の用途と出口地域を確認し、海外サービスでは対象サービスが対応する地域に合わせて選びます。回線の種類は比較の条件として使えますが、実際の使用感に代わるものではありません。選び方が分からない場合は、用途に合わせたVPN回線の選び方をご覧ください。

再生の問題と回線の問題を切り分ける

動画配信が途切れる場合は、まず同じプラットフォームの別のコンテンツを再生し、次にWeb版とアプリ版を比較します。特定の番組だけで問題が起きる場合は、コンテンツ配信や再生元に原因があるかもしれません。画質を下げると改善する場合、現在の継続的な通信能力が元の画質の要件に合わないことは分かりますが、経路のどこに問題があるかまでは特定できません。地域に関するアクセスエラーと再生の途切れも分けて考えましょう。前者はサービスのルールと出口地域を、後者は接続環境と通信経路の品質を確認します。

開発ツールやAI APIのリクエストが遅い場合は、ネットワークだけでなく、サーバー側の処理待ち、利用枠、リクエスト内容が原因でないかも確認してください。リクエストのどの段階で、どの種類のタイムアウトが起きたかを記録し、APIキー、リクエスト本文、プロジェクト情報は公開しないでください。Web版は正常でコマンドラインだけ失敗する場合、開発ツールがシステムプロキシを参照していない可能性があります。詳しくはAI API利用時の回線選びとクライアント設定を参照し、アプリごとの通信振り分けの章で実際の経路を確認してください。

特定の回線と時間帯でのみ遅さを再現できる場合は、テスト対象と比較結果を問い合わせに記載してください。「サーバー負荷」を推測して伝える必要はありません。VPNFlatは90+か国、180+回線をカバーしていますが、これは選択肢の範囲を示すものであり、すべての接続先で同じ経路を利用できるという意味ではありません。トラブルシューティングのためにデータ容量の大きいプランへ変更する必要はありません。データ容量と現在の通信速度は別の指標です。プランの違いはプラン一覧の説明をご確認ください。

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

トンネルの切断とアプリの再接続を切り分ける

アプリに「再接続中」と表示されても、VPNトンネルが切断されているとは限りません。画面ロック、Wi-Fiの切り替え、端末のスリープ、アクセス先サービスのセッション切れによって、アプリが接続をやり直すことがあります。まずクライアントが接続状態を維持しているか確認し、切断の前後にトンネル停止、ネットワーク変更、権限エラーの記録があるかログを確認してください。クライアントが接続を維持しているのに特定のアプリだけ再ログインを求められる場合は、VPN設定を削除するのではなく、アプリのセッションとルーティングを確認しましょう。

問題が発生したときの操作を記録します。バックグラウンドへの移行、画面ロック、Wi-Fiの切り替え、アクセスポイントからの移動、端末の復帰など、きっかけを明確にすると再現しやすくなります。同じ回線を使い、アプリを前面に表示した場合とバックグラウンドにした場合をそれぞれ比較してください。テスト中に省電力設定と回線を同時に変更すると、OSの制限と通信経路の変化を区別できません。スリープから復帰した直後は、ネットワークインターフェースとクライアントサービスの状態が再確立される場合があるため、処理が終わってから結果を確認してください。

Android：バックグラウンド動作とバッテリー設定を確認

Androidでは、システム設定とメーカー独自の管理画面で、バックグラウンド動作がそれぞれ制御されていることがあります。まずクライアントのバッテリー使用設定を開き、バックグラウンド動作が制限されていないか確認します。端末に自動起動やバックグラウンド実行の管理項目がある場合は、現在の設定も確認してください。クライアントに直接関係する項目だけを変更し、端末全体の省電力機能を無効にする必要はありません。バックグラウンド動作を許可したら再接続し、元と同じ画面ロックの操作を繰り返して結果を確認します。設定画面で「許可」と表示されるだけでは不十分です。

一部のシステムには、VPNを常時接続にする設定や、VPNを経由しない通信を遮断する設定があります。これらの設定は、トンネル切断時の動作を変えます。トンネルが停止した後にアプリの通信がすべて遮断され、端末全体がオフラインになったように見える場合があります。元の設定を記録し、実際の用途に合わせて使用するか判断してください。保護機能による通信遮断を、ローカルネットワークの故障と誤認しないようにしましょう。仕事用プロファイルと個人用プロファイルでネットワーク設定が異なる場合もあります。管理端末では管理ポリシーに従い、管理設定を削除して問題を解決しようとしないでください。

iOSとデスクトップのスリープ：システムの動作を確認する

iOSのVPN接続はシステムのネットワーク拡張機能で管理されるため、Androidのバックグラウンド実行許可の方法をそのまま適用できません。システムに正しいVPN構成が残っているか、別のアプリが作成したオンデマンド接続ルールがないか確認してください。接続するたびに別の構成へ切り替わる場合は、構成の管理元と用途を確認します。構成プロファイルをまとめて削除しないでください。学校や職場の構成に必要なネットワーク設定や証明書が含まれている場合があるため、先に管理者へ確認してください。

Windows、macOS、Linuxでは、スリープからの復帰時にネットワークインターフェース、アドレス、デフォルトルートが変わることがあります。まず通常のネット接続が復旧したことを確認し、クライアントを切断してから再接続します。問題が復帰直後に限られるかを確認してください。有線接続は正常で、Wi-Fiでの復帰時だけ問題が起きる場合は、システムのネットワークアダプターの電源管理を確認します。OSでサポートされている設定を使い、根拠なくドライバーの詳細設定を変更したり、提供元不明のスクリプトでネットワークを一括リセットしたりしないでください。

アプリを前面に表示していてもバックグラウンドでもランダムに切断される場合は、端末を動かさず、接続ネットワークと同じ地域の別回線を比較します。特定のネットワークでのみ切断されるなら、接続環境やネットワークの切り替えが関係している可能性があります。異なるネットワークでも同じようなシステムイベントの後に切断されるなら、クライアントサービス、権限、別のトンネルアプリを重点的に確認してください。ログにあるネットワーク変更の記録は発生時刻と合わせて判断します。一度インターフェースが変わっただけで原因と決めつけず、システムの正常な再接続をすべて障害とみなさないでください。

この種類の問題を問い合わせる際は、画面がロックされていたか、クライアントが前面に表示されていたか、接続方法が変わったか、復旧にアプリの再起動が必要だったかを記載してください。問題が起きた時間帯のログを添付する場合は、アカウント情報とサブスクリプション情報を隠してください。Androidの初期設定ではバックグラウンド権限を見落としやすいため、Androidクライアントのインストールと動作確認も参照してください。システムの管理ポリシーで設定を変更できない場合は、端末の管理者に確認しましょう。

サブスクリプションを更新できない、回線一覧に異常がある

サブスクリプションの取得と回線への接続を分けて確認する

サブスクリプションは、回線と関連設定をクライアントに提供します。サブスクリプションの更新と回線への接続は、別々のネットワークリクエストです。以前の回線には接続できるのに更新できない場合は、サブスクリプションの取得経路に問題があるかもしれません。更新は成功しても接続可能な回線がない場合は、アカウントの状態や設定の使用方法を確認する必要があります。まずクライアントに表示されたエラーの原文を記録し、パネルで現在のサブスクリプションの取得先を確認してください。古い名称が一覧に残っているだけで更新済みと判断したり、同じ設定を何度も追加したりしないでください。

ユーザーパネルからサブスクリプションを取得する際は、現在表示されているコピーまたはインポート機能を使ってください。古いチャット、ブックマーク、別の端末のクリップボードから探すのは避けましょう。サブスクリプションのURLにはアカウントへのアクセス情報が含まれる場合があるため、パスワードと同じように管理してください。スクリーンショットを共有する場合は、アドレス欄、QRコード、クリップボードのプレビュー、設定本文をすべて確認します。文字を隠してもQRコードが残っていれば、同じ情報が漏れる可能性があります。漏えいが疑われる場合は、パネルで利用できる機能に応じてサブスクリプションの認証情報を変更し、自分の端末で更新してください。

エラーの種類に応じて対応し、URLをむやみに変更しない

URLの形式エラーが出た場合は、コピーが完全か、空白、改行、全角の句読点が混ざっていないか確認します。認証失敗やアクセス拒否の場合は、URLのパラメーターを書き換えず、アカウントの状態とパネルに表示されている現在の取得先を確認してください。リクエストがタイムアウトする場合は、まず通常のネットワークからパネルにアクセスできるか確認し、現在のプロキシ設定が更新リクエストに影響していないかを調べます。名前解決の失敗はDNSの章に戻って確認します。設定の読み込みエラーでは、インポートした形式がクライアントに対応しているかを確認してください。更新を繰り返すだけでは解決しません。

一部のクライアントには、プロキシ経由でサブスクリプションを更新する設定があります。現在のプロキシが使えない状態だと、更新リクエストも利用できない経路に送られ、「接続するには更新が必要だが、更新には接続が必要」という状態になることがあります。まず元の設定を記録し、通常のネットワークから取得先にアクセスできることを確認したうえで、一時的にプロキシを介さず更新を試してください。接続環境から直接アクセスできない場合は、設定を何度も切り替えず、エラーを保存して問い合わせてください。取得経路はサポートに確認し、第三者の変換サイトを自分で探さないでください。

更新後は、実際に使用中の設定も確認する

クライアントに複数の設定が保存されている場合があります。新しい設定を更新しても、古い設定を使い続けていると、「更新されていない」ように見えることがあります。現在有効な設定、直近の更新結果、回線一覧を確認してから接続してください。設定管理画面にエラーの詳細や更新日時が表示される場合は、更新処理が完了したか確認できます。確認のために設定ファイル全体を公開しないでください。回線名、エラーの種類、現在有効な設定が分かれば、初期確認には十分です。

更新後に一覧の項目が急に減った場合は、地域、お気に入り、検索条件による絞り込みが有効になっていないか確認し、アカウントの状態も調べます。設定テンプレートとクライアントの互換性によって一覧の表示が変わる場合もあるため、行数だけを見てサービスの対象地域が変わったと判断しないでください。VPNFlatは90+か国、180+回線をカバーしています。実際のトラブルシューティングでは、パネルと現在のサブスクリプションに表示された内容を確認してください。以前使っていた回線が表示されない場合は、その名称を記載して問い合わせます。接続先のアドレスを自分で補わないでください。

設定の読み込みに失敗した場合は、エラーが発生した項目名を記録してもかまいませんが、認証情報を含む設定本文をそのまま送らないでください。手動で設定を編集する前にバックアップを取り、パネルから復元できることを確認します。サブスクリプションを更新すると、ローカルでの編集内容が上書きされる場合があるため、自動生成された内容に一時的な修正を長期間書き込まないでください。独自ルールが必要な場合は、クライアントがサポートする上書き機能を使い、独自の設定とサブスクリプション本来の設定を分けて管理します。更新後の問題がどちらに由来するか判断しやすくなります。

トラブルシューティングのためにアカウントを作り直す必要はありません。VPNFlatはメールアドレス不要で、ユーザー名とパスワードで利用できます。アカウントにアクセスできるからといって、設定の問題を避けるために別のアカウントを作る必要はありません。再インポートする場合は、ユーザーパネルの概要から現在のサブスクリプションを取得し、使い方ガイドに沿って確認してください。パネルとアカウントに問題がなくてもクライアントを更新できない場合は、エラーの原文、クライアント名、接続ネットワークを変えた比較結果を添えて問い合わせてください。

特定のアプリがプロキシを使わない：通信振り分けを確認

まずアプリがシステムプロキシを参照しているか確認する

ブラウザーではアクセスできるのに、ほかのアプリでは失敗するのは、よくある通信振り分けの問題です。システムプロキシが影響するのは、通常その設定を参照するアプリだけで、端末上のすべての通信を自動的に引き受けるわけではありません。コマンドラインツール、ゲーム、ダウンローダー、一部のデスクトップアプリは、独自のネットワーク機能を使っている場合があります。まずクライアントがシステムプロキシと仮想ネットワークインターフェースのどちらを使用中か確認し、対象アプリがプロキシ設定に対応しているか調べてください。ブラウザーでアクセスできるようになっただけで、すべてのアプリが同じ回線を使っているとは限りません。

クライアントが仮想ネットワークインターフェースによる通信の引き受けに対応している場合、より広い範囲の通信を扱えますが、追加の権限と正しいルーティングが必要です。クライアントの説明に沿って有効にしてから、対象アプリを再起動して試してください。すでに確立した接続は、以前の経路を使い続ける場合があります。業務アプリ、ローカルネットワーク機器へのアクセス、リモートデスクトップは、ルーティングの変更で影響を受けることがあります。有効にする前に作業を保存し、元の設定へ戻す方法を確認してください。特定のアプリを使えるようにするために、よく分からない通信の引き受け設定をすべて有効にしたままにしないでください。

ルールモードでは一致した条件を確認する

ルールモードは、ドメイン、アドレス、アプリ、その他の条件に応じて通信経路を選択します。一つのアプリが複数のドメインにアクセスし、ログイン、コンテンツ、更新、支払いでそれぞれ異なるリクエストを送る場合があります。メインのドメインだけにルールを追加しても、必要な通信すべてをカバーできるとは限りません。クライアントに接続履歴がある場合は、問題が発生したときに実際にアクセスしたドメインと適用されたルールを確認してから、設定を変更してください。ドメイン名とルール名を記録し、アカウント情報や一時的な認証情報が含まれる可能性のある完全なリクエストURLは収集しないでください。

ルールモードと、クライアントにあるグローバルプロキシモードを一時的に比較すると、通信振り分けの違いを確認できます。ただし、「グローバル」はクライアント内のルーティング設定の名称であり、必ずアプリの通信を引き受けることや、アクセス先のプラットフォームがアクセスを受け入れることを意味しません。グローバルモードで復旧し、ルールモードでは失敗する場合は、ルールとの一致条件とDNSを重点的に確認します。どちらのモードでも失敗する場合は、アプリのプロキシ設定、アクセス先の地域、アカウントの状態を確認してください。テスト後は元の動作モードに戻します。

開発ツールとバックグラウンドプロセスは個別に確認する

ターミナルのツールは、環境変数、ツールの設定、起動パラメーターからプロキシを読み取ることがよくあります。GUIアプリが使えても、ターミナルから起動したプログラムが同じように使えるとは限りません。逆に、ターミナルで設定した変数が、すでに起動中のGUIアプリに影響するとも限りません。プロキシアドレスが終了済みのローカルプログラムを指していないか、ポートが現在のクライアント画面に表示されているものか確認してください。ほかの端末のローカルポートをそのまま使ったり、例示されたアドレスをVPNFlatの固定設定とみなしたりしないでください。

コンテナ、仮想マシン、リモート開発環境には、それぞれ独立したネットワーク環境があります。環境内のループバックアドレスはその環境自身を指すため、ホスト端末を指すとは限りません。ホストのブラウザーでは正常でも、コンテナからのリクエストが失敗する場合、プロキシに到達できないか、名前解決の設定が異なる可能性があります。開発環境の公式ドキュメントに従ってホストへアクセスする方法を設定し、アクセス範囲も確認してください。テストのためにローカルプロキシをすべてのネットワークインターフェースに公開しないでください。端末の公開範囲が変わるため、対象アプリの問題を解決することとは別の問題です。

アプリが出口地域、名前解決のキャッシュ、以前の接続を保持している場合があります。回線を変更したら、まずアプリを正常に終了して再起動し、結果を確認してください。特定のアカウントだけが失敗し、ほかのアクセスは正常な場合は、アプリのデータをすぐにすべて消去しないでください。ローカルのコンテンツが失われることがあります。先にエラー表示を保存し、再ログインできることを確認してから、アプリの公式ヘルプに従ってキャッシュを処理してください。動画配信の地域ごとの利用状況は利用地域の対応状況も参照できますが、実際の利用可否は選択した地域で確認してください。

アプリが特定の通信方式を使用し、現在のクライアントやネットワーク環境で処理できない場合は、ログに記録されたプロトコルや接続エラーを保存し、サポートに判断を依頼してください。保護設定の例外を自分で広げないでください。問い合わせには、アプリ名、失敗した操作、クライアントのモード、ルールを変えた比較結果を記載します。AIのWebサービスと開発用APIでは確認点が異なります。ChatGPTの通信速度に関する説明も参考にしてください。どのアプリの場合も、アカウントのパスワードや開発用のキーを問い合わせに添付する必要はありません。

端末数の警告とOSの不整合：端末の環境を確認

「接続台数無制限」の意味を確認する

VPNFlatは同時接続台数に制限がありません。クライアントに「端末数の上限を超えました」などと表示されても、プランで利用台数が決められているとは限りません。別のサービスの設定、クライアント固有のアカウント体系、システムの管理ポリシー、現在有効な設定がVPNFlatのサブスクリプションではないことなどが原因の可能性があります。どの画面に表示されたメッセージか、現在の設定がどのサービスのものかを確認してから、パネルで状態を確認してください。曖昧なメッセージだけを根拠に、すべての端末からログアウトしたりプランを変更したりしないでください。

接続台数に制限がなくても、すべての端末の設定が同じとは限りません。サブスクリプションのコピー、ルール、接続ネットワークが端末ごとに異なると、動作にも違いが出ます。正常に接続できる端末を比較対象にし、回線、モード、ネットワークを記録してから、問題がある端末の設定を一つずつ比べてください。正常な端末から設定全体をエクスポートして公開したり、端末固有のパスをそのまま別のOSに上書きしたりしないでください。別のOSへ移行する場合は、パネルから該当する設定を再度インポートしてください。

OSごとに通信を引き受ける設定を確認する

Windowsでは、クライアントのウィンドウとバックグラウンドサービスを区別してください。ウィンドウを閉じてもシステムプロキシが残ったり、別のサービスがローカルの待ち受けアドレスを使用し続けたりする場合があります。テストを終える際はクライアントの終了と復元機能を使い、その後システムプロキシが元のネットワーク要件に合っているか確認してください。セキュリティソフトがブロックを報告した場合は、該当プログラムのパスとイベントを確認し、保護機能全体を無効にしないでください。パネルの正規の入口から取得したファイルであることを確認してから、システムの指示に従って権限を設定します。

macOSでは、ネットワーク拡張がシステムで許可されているか、ほかのVPNやフィルタリング用拡張も有効になっていないか確認してください。許可設定を変更した後は、システムの指示に従ってクライアントを再起動するか、接続し直します。メニューバーの項目を何度もクリックするだけでは不十分です。Appleのサービスに関する問題を、端末のチップだけが原因と決めつけないでください。プロキシモード、名前解決の方法、ネットワーク拡張を順に比べます。互換性について詳しく知りたい場合は、macOSのネットワーク拡張と互換性の選び方をご覧ください。

Linuxと管理端末では既存のポリシーを維持する

Linuxはデスクトップ環境、ネットワーク管理サービス、名前解決の管理方法が環境ごとに異なります。まずクライアントがどの方式で通信を引き受けているか確認し、関連サービスが動作しているか調べてください。名前解決の管理方法が分からないまま、システムの名前解決ファイルを上書きしないでください。ネットワークサービスが自動生成している場合があり、手動での変更は再接続後に消えることもあります。ターミナルのプロキシ環境変数とデスクトップ設定は別々に確認します。管理者権限で実行したプロセスが元の環境変数を引き継ぐとは限らないため、権限をむやみに増やさず、ツールのドキュメントで確認してください。

職場や学校で管理されている端末では、証明書、プロキシ、DNS、VPN設定が組織のポリシーで制御されている場合があります。設定を変更できない、変更後に元へ戻る、接続が別の設定に切り替わる場合は、まず管理者に確認してください。個人用クライアントを使うために管理コンポーネントを削除してはいけません。業務用トンネル、リモートサポート、セキュリティ接続のプログラムが動作中の場合は、停止してよいか確認してから切り分けます。プロセスをそのまま終了すると、業務接続が切れたり、コンプライアンス要件に影響したりする可能性があります。

ソフトウェアの競合を調べる場合は、「作業を保存する、接続を切る、別のプログラムを終了する、再テストする、元の状態に戻す」の順に行います。候補を一つずつ除外し、復旧したか記録してください。複数のネットワークツールを同時に使う必要がある場合は、明確にサポートされているルーティングとプロキシの方式で調整します。複数のプログラムにシステム設定を上書きさせないでください。自動修復ツールは多くの項目を変更することがあるため、証拠がない段階で最初に使う方法には適しません。復元ポイントや設定のバックアップの代わりにもなりません。

クライアントはユーザーパネルのダウンロードページから入手してください。Windows、macOS、Android、Linuxのクライアントはログイン後に取得できます。iOSの入口はパネルの利用資格に応じて表示され、サブスクリプションはログイン後に取得できます。インストールや権限設定で問題が起きた場合は、OS、クライアント名、エラーの表示元、管理端末かどうかを問い合わせに記載してください。端末数に関する表示が出た場合は、個人情報を隠したうえでメッセージの原文を添付し、サポートに確認を依頼してください。端末上の表示をプランの制限と誤読しないようにしましょう。

問い合わせ、設定の復元、動作確認

問題を再現できる条件を整理してから問い合わせる

通常のネット接続とアカウントが有効で、サブスクリプションと権限を確認しても問題が明確な条件で再現する場合は、ユーザーパネルから問い合わせてください。すべての詳細設定を試すまで待つ必要はありません。アカウントの状態に矛盾がある、パネルの表示がおかしい、サブスクリプション認証に失敗する、同じ回線で何度もエラーが起きる場合も、むやみな設定変更は中止してください。サーバー側の状態はサポートによる確認が必要です。端末を何度再インストールしても、有効な証拠が増えるわけではありません。

問い合わせには、まず症状、次に発生する範囲、最後に試した比較結果を記載します。クライアントが接続できるか、どのWebサイトやアプリにアクセスできないか、特定のネットワークや時間帯に限られるかを説明し、ネットワークや回線を変えた結果、既定の設定に戻した結果も記載してください。「使えない」とだけ書いたり、確認せずログ全体を貼り付けたりしないでください。推測を事実のように書くのも避けましょう。「同じ地域の別の回線では正常」と記載すれば十分で、「特定のサーバーが壊れている」と断定する必要はありません。

必要な情報を残し、機密情報は最小限にする

記録の照合に使えるよう、発生日時には日付、現地時刻、タイムゾーンを含めてください。端末情報にはOSとクライアント名を記載します。パネルまたはクライアントにビルド情報が表示される場合は、実際の表示どおりに記載し、バージョンを推測しないでください。回線名はクライアントに表示された完全な名称を使います。接続環境は家庭のWi-Fi、有線、モバイルデータ、管理ネットワークなどと記載すれば十分です。アクセス先のサービスはドメイン名と失敗した操作を記載してください。閲覧履歴、アカウントのパスワード、支払い情報の全文、問題に関係のない個人情報を送る必要はありません。

症状：クライアントは接続済みだが、Webページで名前解決エラーが表示される
発生日時：実際の日時とタイムゾーンを記入
端末環境：OSとクライアント名を記入
接続ネットワーク：種類を記入し、ネットワークを変えて比較したか記載
選択中の回線：クライアントに表示された回線名を記入
比較結果：正常時と異常時の条件を記入
エラーの原文：必要な箇所をコピーし、アカウントとサブスクリプションの情報を隠す
実施した操作：変更内容と復旧したかどうかを記入

ログは、問題が起きる前後の関連箇所を切り出し、エラーの原文を残してください。送信前に、サブスクリプションURL、トークン、パスワード、キー、個人情報を含むパスを検索して削除します。スクリーンショットではQRコード、通知のプレビュー、ほかのウィンドウも確認してください。どの項目が機密情報か分からない場合は、公開せず、問い合わせで必要な範囲を確認してください。診断データ全体を公開ストレージにアップロードして広く共有しないでください。適切な窓口を利用し、必要最小限の情報を提供しましょう。

設定を変えた後は、元の場面を再現して確認する

「Webページが開いた」だけでは、すべて復旧したとは限りません。元の問題が起きた操作を再現して確認してください。画面ロック後に切断された場合は、ロック後の操作を同じように試します。サブスクリプションを更新できなかった場合は、更新が完了し、現在の設定が有効になっているか確認してください。特定のアプリが失敗していた場合は、同じモードで同じ操作をやり直します。テストではアクセス先とネットワークの条件をそろえ、通常の直接アクセス、ローカルネットワーク、ほかのよく使うアプリも正常か確認してください。一つの状況を直したことで、新たなルーティングの問題が起きていないか確かめます。

復旧後は、一時的なグローバルプロキシ、独自DNS、アプリごとのプロキシ設定、バックグラウンド動作のテストなど、診断用に変更した設定を一つずつ元に戻します。有効だった組み合わせを記録してから戻し、それぞれの変更後に動作を確認してください。必要な設定は用途を理解したうえで残してかまいません。証明書の検証を無効にする、待ち受け範囲を広げる、システム保護を無効にする設定は残さないでください。設定を長期的に維持する必要がある場合は、影響と復元方法を記録します。不明な点はサポートに確認し、一時的な対処を既定の設定にしないでください。

プランや請求に関する問題は、接続の診断と分けて確認してください。月額プランは¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。データ通信量は契約開始日を基準に毎月リセットされ、契約期間中のアップグレードでは差額を残り日数に応じて計算します。データパックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効、期限はありません。支払い方法はAlipay / WeChat Pay / USDTです。具体的な記録はパネルの注文履歴で確認し、入金状況を推測して接続エラーを判断しないでください。

VPNFlatは60日間の無条件返金に対応しています。申請方法と条件は返金ポリシーをご確認ください。アカウントに関するその他の問題はヘルプセンターをご覧ください。トラブルシューティングの目的は、すべての問題を利用者自身で解決してもらうことではなく、検証できる範囲まで原因を絞り込むことです。元の設定を残し、条件を一つずつ変え、同じ状況で再テストして、必要な情報をサポートに伝えることが、何度も再インストールしたり手当たり次第に設定を変えたりするより、通常の利用状態への復旧につながります。