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

通信経路を分けて確認

Webサイトにアクセスすると、ローカルネットワーク、クライアントのルーティング、接続先、DNS、Webサイトの順に通信が進みます。画面に「接続済み」と表示されても、クライアントの接続段階が完了しただけで、ブラウザー、業務アプリ、ダウンロードがすべて同じ経路を使うとは限りません。ボタンが回り続ける、接続後にすべてのWebサイトが開かない、特定のサイトだけエラーになる、画面は開くが動画が止まるなど、具体的な状況を記録してください。症状を具体的に把握するほど、変更すべき設定を絞り込み、改善したかどうかも判断しやすくなります。

トラブルシューティングを始める前に、現在の設定を復元できるように保存し、使用中の設定名、接続先の選び方、プロキシモードを記録してください。スクリーンショットには、サブスクリプションURLやアカウント情報が写らないようにします。接続先を変えながらDNSも変更し、さらにアプリのデータを消す、といった操作を一度に行わないでください。復旧しても原因がわからなくなります。ひとつ変更したら同じアクセスを試し、結果を記録してから設定を維持するか戻すかを判断しましょう。「最適化」を一度にいくつも試すより、元の状態に戻せることが大切です。

まずクライアントを経由しないネットワークを確認

現在の環境で通常の直接接続が可能なら、いったんクライアントを切断し、普段から直接アクセスできるWebサイトを開いてください。ホテルやゲスト用ネットワーク、公衆Wi-Fiの認証画面で止まっていないかも確認します。認証が必要な場合は、OSのネットワーク通知から認証ページを開き、ネットワーク提供元の手順に従ってください。不明なポップアップにサービスのアカウント情報を入力してはいけません。直接接続でも失敗する場合は、Wi-Fiの電波、ルーター、LANケーブル、通信事業者への接続を先に確認します。クライアントでローカルネットワーク自体の障害を解決することはできません。テストが終わったら、元の保護設定に戻してください。

次に、異なる環境で比較します。同じ端末を別の利用可能なネットワークに接続し、同じネットワークでは正しく設定済みの別の端末を試します。比べる目的は障害の範囲を絞ることで、どちらの端末が「速い」かを決めることではありません。特定の端末だけで失敗する場合は、システムプロキシ、権限、セキュリティソフトを確認します。同じネットワークの端末がすべて失敗する場合は、ネットワークへの接続やルーターを確認します。異なるネットワークと端末で同じ接続先だけが失敗する場合は、接続先やアカウントの状態を調べます。比較のためにソフトを追加インストールする必要はなく、認証情報を公開する必要もありません。

比較できる記録を残す

毎回同じ形式で、発生した時間帯、ローカルネットワークの種類、クライアントの表示、接続先の名前、対象アプリ、設定変更前後の結果を記録します。「夜は遅い」という状況は、「同じネットワークでWebページの文字表示は正常だが、動画は頻繁にバッファリングする。接続先を変えるとどうなるか」のように具体化できます。専門用語にこだわる必要はありません。画面に表示されたエラーをそのまま書き留めるほうが役立ちます。エラーコードがある場合は、表記を省略せずに記録してください。ネット上の似たスクリーンショットだけを根拠に原因を決めつけないでください。

このページのコマンドや比較テストは、原因を探るための手がかりであり、すべての端末に共通する修復手段ではありません。会社の管理下にある端末、業務用プロキシ、セキュリティポリシーを変更する場合は、事前に管理者の許可を得てください。

変更後に新たな問題が起きた場合は、設定をさらに追加するのではなく、直前の変更を元に戻してください。クライアントを再起動して元のアクセス先を再テストし、必要に応じて端末を再起動して、仮想インターフェースやプロキシの状態をリセットします。最初からルーターを工場出荷時の状態に戻すのは避けてください。問題と無関係な接続設定まで消えるおそれがあります。基本的な切り分けが終わったら、該当するセクションに進みます。設定をまだ正常にインポートできていない場合は、クイックスタートガイドに戻るのが近道です。

エラーが起きた段階を確認

まずクライアントの接続詳細または診断画面を開き、設定の読み込み時、仮想ネットワークインターフェースの作成時、接続先への接続時のどの段階でエラーが出るか確認します。設定の解析失敗と接続タイムアウトは別の問題です。前者はサブスクリプションが完全か、クライアントが現在の設定形式に対応しているかを確認します。後者はローカルネットワークと選択中の接続先を比較します。画面に「失敗」とだけ表示される場合は、接続ボタンを押した後の変化を記録し、エラーのスクリーンショットを保存してください。すべての失敗を「接続先が使えない」と決めつけないでください。

端末の日付、タイムゾーン、システム時刻の同期が正常か確認します。時刻が大きくずれていると、安全な接続で証明書の検証に失敗し、ハンドシェイクの中断や認証エラーが起きることがあります。証明書の警告が表示されても、検証を無効にしたり、出所のわからない証明書をインストールして警告を消したりしないでください。まずシステム時刻の同期を復元してから、クライアントを開き直します。会社の端末で管理ポリシーにより時刻や証明書が固定されている場合は、元の警告内容を管理者に伝えてください。業務ネットワークの信頼設定を独自に変更しないようにしましょう。

権限と重複して動作するネットワークツールを確認

モバイルOSでは、VPN設定を初めて作成するときにシステムの許可を求められます。許可しないと、クライアントが接続を確立できない場合があります。システムのVPN管理画面で現在のクライアントに対応する設定があるか、ほかのアプリが接続を使用中と表示されていないかを確認してください。デスクトップでネットワークサービスを起動できないと表示された場合は、クライアントの正式な修復または再認証の手順を使います。ネットから個別のドライバー修正ファイルをダウンロードしたり、手間を省くためにシステムのセキュリティ機能を恒久的に無効にしたりしないでください。

ほかのVPN、プロキシツール、ネットワークフィルター、企業向け接続ソフトが、同時にデフォルトルートを制御していることがあります。今回のテストに関係のない同種のツールを終了し、自動起動するプロキシサービスが残っていないか確認してください。企業向け接続ソフトを停止できない場合は、同時利用が許可されているか管理者に問い合わせます。ウィンドウを閉じただけではプロセスが終了していないことがあります。アプリの状態とシステムのネットワーク設定を見て、現在どのソフトがネットワークを制御しているかを確認してから再接続してください。

ネットワークと接続先を比較して切り分け

クライアントの設定はそのままに、別の利用可能なネットワークに接続して同じ接続先を試してください。ネットワークを変えて復旧した場合、元のネットワークで該当の接続方式が制限されている、認証が必要、またはルーティングに異常がある可能性があります。クライアントを何度も再インストールする必要はありません。ネットワーク提供元にルールを確認するか、許可された別の接続環境を使ってください。複数のネットワークで失敗する場合は、アカウントに表示される別の接続先でも比較し、同じ出口に対する操作を繰り返さないようにします。

接続先は、アカウントに実際に表示される名称と種類を基準に選んでください。VPNGlassは110+か国 / 190+回線に対応していますが、すべての接続先がどのローカルネットワークでも同じように動作するわけではありません。接続先一覧で地域と回線の説明を確認し、利用するサービスに合った接続先を選びましょう。サーバーアドレス、ポート、認証項目を独自に変更して修復しようとしないでください。これらの情報は有効なサブスクリプションから取得するもので、任意に変更すると新たな接続エラーを招くことがあります。

「接続タイムアウト」は結果を示すもので、原因を示すものではありません。特定の接続先だけ失敗する場合、すべての接続先が失敗する場合、特定のローカルネットワークだけ失敗する場合では、確認すべき点が異なります。

接続できない場合も、設定をすべて消さずに状況を確認

アカウントのプランが利用可能な状態か、通信量が残っているか、現在の設定が正しいアカウントから取得されたものか確認します。サブスクリプションの更新に失敗した場合は、サブスクリプションのセクションを確認してください。古いスクリーンショットの接続先名から現在の状態を推測しないでください。再インポートの前に、ルールとアプリの例外設定を保存します。アプリをアンインストールするとローカル設定も削除されることがあります。アカウントへのログイン方法を把握し、サブスクリプションを再取得できることを確認してから、再インストールを検討してください。

ネットワークと接続先を変えても接続できず、システムの許可、時刻、アカウントの状態も確認済みなら、問い合わせを送る段階です。エラーの原文、選択した接続先、失敗した段階、「別のネットワークでも失敗した」といった比較結果を添えてください。安全な接続に使う認証情報、サブスクリプションURL全体、アカウントのパスワードは、通常の診断スクリーンショットに含めません。クライアントが何度もクラッシュする場合は、繰り返し再試行するのをやめ、クラッシュ直前の操作を記録してから、専用の診断情報が必要かサポートに確認してください。

通信経路全体か、特定のドメインだけかを確認

接続後にすべてのWebサイトが開かない場合は、クライアントに実際の通信量の変化があるか、システムプロキシや仮想ネットワークによる通信の制御が有効かを確認します。システムプロキシを無視するアプリには適用されないモードもあれば、仮想インターフェースやルーティング権限が必要なモードもあります。接続ボタンの色だけで判断しないでください。普段問題なく開けるサイトと、現在失敗しているサイトを比較します。前者は正常で後者だけ失敗する場合は、ルール、名前解決、対象地域、Webサイト自体に原因を絞れます。

ブラウザーに「サーバーが見つかりません」と表示される場合はDNSが関係していることがあります。一方、「接続がリセットされました」「証明書が無効です」「アクセスが拒否されました」は、DNSの問題と決めつけられません。証明書の警告が出た場合は、まずドメイン名とシステム時刻を確認します。アクセス拒否は、プラットフォームのアカウント、接続元の地域、リスク判定が原因かもしれません。見知らぬIPアドレスを入力したり、証明書の警告を無視したりして、サイトが復旧したか確認しないでください。現在のWebサイトは通常、ドメイン名と証明書の一致を前提としているため、アドレスを直接指定しても正確に確認できず、無関係なサービスに接続するおそれもあります。

コマンドで名前解決の結果を確認

次のコマンドは例のドメインを照会するだけで、ネットワーク設定は変更しません。Windowsでは標準の名前解決ツールを使います。macOSでは現在のシステムリゾルバーを確認してからドメインを照会します。Linuxでは該当する名前解決サービスを使用している場合、その状態も確認できます。これらのツールがインストールされていないシステムもあり、コマンドが見つからないからといってDNSが壊れているわけではありません。問題が起きている公開ドメインを使う場合は、ドメイン名だけを入力してください。アカウント識別情報、認証情報、個人用のパスを含む完全なURLは貼り付けないでください。

# Windows: ドメインの照会例
nslookup example.com

# macOS: システムの名前解決設定を確認してドメインを照会
scutil --dns
dscacheutil -q host -a name example.com

# systemd-resolved を使用する Linux: ドメインの照会と状態の確認
resolvectl query example.com
resolvectl status

名前解決がタイムアウトした場合、問い合わせに時間内に応答がなかったことを示します。IPアドレスが返ってきても、名前解決が完了したというだけで、Webサイトにアクセスできるとは限りません。ネットワークごとに異なるIPアドレスが返るのは、コンテンツ配信や最寄りのサーバーへの振り分けによる正常な動作の場合もあります。アドレスが違うだけで異常と判断しないでください。同じ端末とドメインを使い、クライアントの接続前後で名前解決できるか、名前解決の失敗とアプリのアクセス失敗が同時に起きるかを確認するほうが有効です。出力を共有する場合は、必要に応じてプライベートネットワーク名や内部アドレスを隠してください。

複数の名前解決方式が競合していないか確認

システムの手動DNS、ブラウザーのセキュアDNS、クライアントのDNS、既存のネットワークフィルターツールを確認します。それぞれ異なる経路で名前解決し、システムの照会は成功してもブラウザーでは失敗することがあります。クライアントの推奨設定を維持し、ブラウザーに一時的なDNS設定を追加している場合は元に戻してから、同じドメインを再度開いてください。出所不明のパブリックDNSを設定したり、関連するすべてのオプションを一度に有効にしたりしないでください。設定名はOSによって異なります。実際にどの仕組みが照会を処理しているかを把握することが大切です。

hostsファイル、ドメインの書き換え、ルールを以前変更したことがある場合は、古いアドレスの設定が残っていないか確認します。設定を修正しても、ブラウザーやアプリがキャッシュや既存の接続を使い続けることがあります。アプリを完全に終了して開き直し、必要に応じてOSがサポートする方法でキャッシュを消去してください。キャッシュの消去を毎回の決まりきった対処にしないでください。元のエラーを記録する前に消去すると、調査の手がかりが失われることがあります。消去後は、同じアクセス先を使って本当に改善したか確認します。

DNSの照会が成功しても、すべてのアプリの通信がプロキシを経由するとは限りません。実際に有効かどうかは、接続元、ルールの適用状況、アクセス結果を組み合わせて確認します。名前解決を一度試しただけでは判断できません。

特定の経路だけに起きる問題を切り分け

通常のWebページは開くのに、一部のリソース、ログイン画面への転送、画像だけが失敗する場合は、メインドメインとリソース用ドメインがクライアントのルールによって別の経路に振り分けられていないか確認します。OSとクライアントでIPv6の扱いが異なると、一部の接続が想定どおりにルーティングされない場合もあります。ネットワークプロトコルを一括削除するのではなく、クライアントがサポートする方法で通信の制御状態を確認してください。詳しい確認方法は接続元IP、DNS、アプリごとの通信を確認する記事を参照してください。対象サービス自体に障害がある場合、DNSを何度も変更しても解決しません。

「遅い」の症状を具体化

Webページの表示開始が遅い、ファイルのダウンロードが遅い、動画が途中で止まる、会議の音声が途切れるなど、原因となる箇所は症状によって異なります。どの段階で遅くなるか記録してください。ページを開いてから長く応答しないのか、転送開始後に速度が変動するのかを確認します。前者はDNS、接続の確立、接続先の応答が関係する場合があります。後者はローカルの帯域競合、Wi-Fiの干渉、国際通信経路を確認します。クライアントの一覧に表示される一度の測定結果は、実際の利用経路すべてを反映するとは限りません。

端末でバックグラウンド同期、システム更新、クラウドストレージへのアップロードなど、ネットワークを継続的に使用するタスクが動いていないか確認します。アップロードが混雑すると、ダウンロードだけでなくWebページや会議にも影響します。不要なタスクを停止したうえで、同じネットワーク、同じ場所、同じ対象で再テストしてください。Wi-Fiの電波が不安定な場合は、可能ならアクセスポイントの近くで試すか、有線接続と比較します。ここでの目的はローカル側のボトルネックを除外することで、端末の買い替えや新しい通信プランの契約を求めるものではありません。

夜間の速度低下は時間帯と通信経路を比較

特定の時間帯だけ遅くなる場合は、同じ接続先で時間帯を変えたアクセス記録を残し、同じ時間帯に別の接続先も比較します。日中の軽いWeb閲覧と夜間の大容量ファイルのダウンロードを比べても、ネットワークと作業のどちらが原因か判断できません。同じネットワークで直接接続した場合も遅いなら、まずローカル側の混雑を調べます。直接接続は正常で、接続元によって差が大きい場合は、国際通信経路や出口の負荷などを確認します。一度成功した、または失敗しただけでは、長期的な傾向はわかりません。

接続先を変えるときは、まず利用するサービスに適した地域を選び、アカウントで利用できる複数の経路を比較します。地理的に近い接続先が常に速いとは限らず、測定遅延が小さくても通信が安定するとは限りません。回線名に含まれる種類の表示は、実際の説明に沿って理解してください。特定の回線種別があらゆる状況で優れた結果を保証するわけではありません。接続先や回線の範囲を絞るには接続先と回線の説明が参考になります。実際の結果は、ローカルネットワーク、利用するサービス、その時点の経路によって異なります。

再生画質とサービスの対象地域は別に確認

動画配信サービスは、アカウント、コンテンツ、端末の性能、ネットワークの状態に応じて画質を自動で選ぶことがあります。テストするコンテンツと再生設定を固定し、バッファリングが減るか確認してください。サービス側が画質を自動的に下げたことを、接続先が復旧したと誤認しないようにしましょう。対象地域外、プロキシ経由のアクセス制限、アカウントが利用できないといった表示がある場合は、サービスのルールに従って対処してください。単純な速度不足とは別の問題です。動画配信に関する注意点は動画配信の特集をご覧ください。ログイン確認が繰り返し発生する原因になるため、接続先の地域を何度も切り替えないでください。

速度測定やダウンロードテストは多くの通信量を使うことがあり、測定サーバーの場所も実際の利用先に近いとは限りません。補助的な確認にとどめ、日常の作業に影響するほど繰り返さないでください。月額プランの通信量は契約開始日を基準に毎月リセットされ、追加データパックは使い切るまで有効期限がありません。これらは料金上のルールであり、速度を保証するものではありません。通信量を使い切った場合は、夜間の混雑が原因と判断する前に、アカウントの状態を確認してください。各プランの内容はプランページをご覧ください。

設定変更をやめるタイミング

複数の接続先やネットワークを使っても同じ作業に明らかな問題が起きる場合は、接続先のサービスに障害がないか、端末が過熱していないか、リソースが不足していないかを確認し、そのうえで問い合わせを検討してください。よくわからないガイドから汎用の通信パラメーターをコピーしないでください。特にセキュリティ検証を弱めたり、システムのネットワーク設定を広範囲に変更したりするのは避けましょう。速度測定のスクリーンショットだけを送るより、「正常な作業」と「異常な作業」を具体的に伝えるほうが役立ちます。十分な根拠がない場合は、安定して使える設定を維持し、数値を追い求めて設定全体を崩さないでください。

何が切断されたのかを確認

システムのVPN接続状態が消えたのか、クライアントが未接続に戻ったのか、それとも利用中のアプリだけが応答しなくなったのかを確認します。接続は維持されているのにダウンロードだけが中断する場合、接続先サービスのセッションがタイムアウトした可能性があります。すべてのアプリでアクセスできなくなった場合は、接続とローカルネットワークを確認します。画面ロック、Wi-Fiの切り替え、省電力モード、PCのふたを閉じた、別のアクセスポイントに移動したなど、切断直前の操作を記録してください。切断後のスクリーンショットより、発生のきっかけのほうが原因の特定に役立つことがあります。

Wi-Fiから別の接続方式に切り替えると、端末のアドレスや利用できる経路が変わり、既存の接続を再確立する必要が生じることがあります。まず端末の場所とネットワークを変えずに状態を観察し、その後、切り替え操作だけを個別に試します。移動中の一時的な再接続を、回線全体の障害と判断しないでください。クライアントに自動再接続やネットワーク変更後の復旧機能がある場合は、説明に従って有効にできます。有効にした後は、通知領域のアイコンが戻っただけで判断せず、実際にサービスへアクセスできるか確認してください。

Android：バックグラウンド制限と動作状態

Androidでは、バッテリー最適化、バックグラウンド動作の制限、メーカー独自のタスク管理がクライアントの継続動作に影響することがあります。システムのアプリ設定で、使用中のクライアントのバックグラウンド権限、バッテリー管理、ネットワーク権限を確認し、OSが正式に用意しているバックグラウンド実行許可を使用してください。設定項目の名称は端末ごとに異なるため、ほかの機種のメニュー手順をそのまま使わないでください。システムにVPNの常時接続設定がある場合も、ネットワーク切断時の動作を先に確認してから有効にします。通信を保護するための切断動作を、新たな障害と誤認しないようにしましょう。

最近使ったアプリからの終了、システムのメモリー整理、一部の省電力ツールによってプロセスの状態が変わることがあります。まずこうした自動終了を止め、クライアントを通常どおり動作させたまま、画面ロック前後のアクセス結果を比べてください。接続を保つために、端末全体の省電力機能を無効にする必要はありません。現在のクライアントに関係する設定だけを変更しましょう。初期設定がまだ終わっていない場合は、Androidのインストール、権限設定、接続確認ガイドを参照し、設定や権限に漏れがないか確認してください。

iOSとデスクトップ：スリープからの復帰は別々に確認

iOSでは、システムのVPN設定が残っているか、別のネットワークアプリによって接続が置き換えられていないか、ネットワーク切り替え後にシステムが接続を再確立したかを確認します。オンデマンド接続を使っている場合は、ルールが現在のネットワーク環境に合っているか確認してください。画面ロックのたびに起きる問題に対処するため、システム設定を何度も削除しないでください。比較できる状態を維持できなくなります。再現状況を伝えるときは、「画面が消えた後に失敗する」と「アプリをバックグラウンドにした後に失敗する」を分けてください。関係する仕組みが異なる場合があります。

デスクトップ端末がスリープから復帰した後、物理ネットワークアダプターが先に復旧し、仮想インターフェースやシステムプロキシが後から準備されることがあります。復帰のたびに異常が起きる場合は、端末を再起動せずにクライアントを切断して再接続し、復旧するか確認してください。クライアントを終了した後もネットワークに影響が残る場合は、システムプロキシが残っていないか確認します。会社の端末では、管理対象のネットワークサービスを独自に無効にしないでください。Windows、macOS、Linuxでは電源やサービスの管理方法が異なるため、実際のシステムの表示に従ってください。

発生パターンをサポートに伝える

端末を使用中の状態に保ち、ネットワークを固定し、バックグラウンド制限も確認したのに不規則に切断される場合は、別の接続先や端末と比較します。特定の接続先だけで起きる場合は、その名称と発生時刻を伝えます。特定の端末だけで起きる場合は、システムの状態とエラー表示を添えてください。VPNGlassでは同時接続台数に制限はありません。別の端末で利用を始めたことだけを理由に、現在の接続が必ず切断されたと判断する必要はありません。画面にデバイス制限の表示が出た場合は、サブスクリプションとデバイスのセクションで設定の取得元を確認してください。

バックグラウンド設定を変更した後は、元と同じ画面ロックやネットワーク切り替えの操作を行って再テストします。使用中に接続が維持されても、バックグラウンドの問題が解決したとは限りません。

サブスクリプションはアプリのインストーラーでも、公開用のURLでもありません

クライアントのインストールが完了しても、現在のアカウントの接続設定を取得したことにはなりません。サブスクリプションはユーザーパネルから取得し、現在のクライアントが対応している方法でインポートしてください。サブスクリプションURL全体には認証情報が含まれることがあるため、アカウントの秘密情報と同様に保管します。公開コメント、スクリーンショット、オンラインの形式確認サイトに貼り付けないでください。コピー後に更新できない場合は、空白や改行、チャットアプリが追加した記号が含まれていないか確認します。URLを手作業で分割して再結合しないでください。

設定のダウンロード中と、ダウンロード後の解析中のどちらで失敗したか確認します。ダウンロードがタイムアウトする場合は、ローカルネットワークと更新要求の経路を確認します。ダウンロード済みなのに形式エラーが表示される場合は、インポート先、クライアントの互換性、認証ページの内容で上書きされていないかを確認してください。公衆ネットワークでは、接続案内のページにリクエストが転送され、クライアントがWebページを取得する場合があります。まずネットワークの認証を済ませてから設定を再取得してください。Webページの内容を接続設定としてインポートしようとしないでください。

現在の接続が使えず、更新要求にも影響している可能性

クライアントによっては、現在のプロキシを経由してサブスクリプションを更新します。現在の設定が使えない場合、更新要求も失敗し、「接続するには更新が必要だが、更新には接続が必要」という状態になることがあります。クライアントにサポート対象の更新経路を選択する機能があるか確認し、利用が許可されたネットワーク環境で公式の手順に従ってください。更新のためにセキュリティ検証をすべて無効にしたり、見知らぬ相手から代替のサブスクリプションを受け取ったりしないでください。確認すべき設定の取得元は、アカウント内の正規のページです。

再インポートする前に、カスタムルール、アプリの例外、現在の設定名を保存します。新しい設定の読み込みが完了したら、古いコピーではなく新しい設定が選択されていることを確認してください。ソフトによっては複数のサブスクリプショングループが保存されるため、名前が似ていると選択を間違えやすくなります。更新に成功しても、すべてのアプリがすぐに新しい経路を使うとは限りません。接続を再確立し、決まった対象で動作を確認してから古い設定を削除してください。問題が解決する前に、元に戻す手段を失わないようにしましょう。

プランの状態と通信量のリセットルールを確認

アカウントでプランが利用可能か、通信量が残っているか、注文の状態が更新済みかを確認してください。月額プランは¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は契約開始日を基準に毎月リセットされ、暦月の初日に一律リセットされるわけではありません。契約途中でアップグレードした場合、差額は残り日数に応じて計算されます。支払額から新たな契約期間を独自に推算しないでください。表示内容に差がある場合は、注文の状態とアカウント画面の個人情報を隠したスクリーンショットを保存し、サポートに確認を依頼してください。

追加データパックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効期限はありません。追加データパックと月額プランではルールが異なります。月額プランの通信量リセット日を追加データパックに適用したり、追加データパックの無期限ルールを月額プランに適用したりしないでください。詳しくはプランと追加データパックの説明をご覧ください。支払い後に状態が一致しない場合は、既存の注文を確認してください。支払いボタンを繰り返し押すと注文が重複するおそれがあります。注文確認の代わりにサブスクリプションを何度もインポートしないでください。

「デバイス数の上限」と表示されたら、まず表示元を確認

VPNGlassでは同時接続台数に制限はありません。クライアント、アプリストアのアカウント、第三者の設定にデバイス制限が表示された場合は、VPNGlass側で新たに台数制限が設けられたと決めつけず、どこからの表示か確認してください。現在ログインしているアカウント、選択中の設定、サブスクリプショングループがVPNGlassのものか、ほかのサービスの古い設定が残っていないかを調べます。台数無制限というルールは本サービスのデバイス利用に関するもので、対象のプラットフォームが独自に設けているセッション数やデバイス管理の要件までなくなるわけではありません。

現在のサービスの設定であると確認できてもデバイス制限のエラーが続く場合は、元の表示内容と表示箇所を保存して問い合わせてください。上限数を推測するために、ほかのデバイスを独自に削除しないでください。アカウントへのログインにメールアドレスは不要です。ユーザー名とパスワードを安全に保管してください。調査の際にパスワードをサポートへ送る必要もありません。サブスクリプションURLが公開された疑いがある場合は、ユーザーパネルの認証情報管理機能を使って対処し、各端末の設定を更新してください。対処後は、古い設定が使われなくなったことを確認し、新旧の状態が混在しないようにしましょう。

設定のダウンロード失敗、設定の解析失敗、注文の未更新、デバイス表示の異常は、それぞれ具体的な証拠を添えて報告してください。「サブスクリプションがおかしい」とだけ伝えると、追加情報の確認に何度もやり取りが必要になります。

システムプロキシと全通信の制御は別の仕組み

システムプロキシに従うアプリ、独自のプロキシ設定を使うアプリ、専用のネットワークコンポーネントで接続するアプリがあります。ブラウザーで対象サイトを開けても、デスクトップアプリ、コマンドラインツール、バックグラウンドサービスの動作を確認したことにはなりません。まずクライアントがどの方式で通信を制御しているか確認し、失敗するアプリがその対象に含まれるかを調べます。アプリ別プロキシを使う場合は、リストが「選択したアプリのみをプロキシ経由にする」のか、「選択したアプリを対象外にする」のかを確認してください。設定を逆にすると、結果も逆になります。

最初からすべての通信を別のモードに切り替え、そのまま使い続けないでください。クライアントが一時的にプロキシの対象を広げられる場合は、原因の切り分けに利用できます。対象を広げて復旧するなら、元のルールを見直します。それでも失敗する場合は、アプリ独自のプロキシ、DNS、アカウント、プラットフォーム側の制限を確認してください。テスト後は元のルールに戻します。特に社内ネットワーク、LAN上のデバイス、ローカル開発サービスに影響が出ないようにしてください。外部アクセスを直すために、正常な内部接続まで変えないようにしましょう。

実際のプロセスとドメインに沿ってルールを確認

アプリのメイン画面、ログイン画面、アップデーター、メディアコンポーネントが、それぞれ別のプロセスで通信することがあります。アプリ別のリストにメインプログラムしか登録されていない場合、ログイン画面への転送が別の経路を使うことがあります。クライアントに接続ログがある場合は、失敗操作を行ったときに関連するプロセス、接続先ドメイン、適用ルールを確認し、どの接続が失敗しているか特定してください。診断ログ全体を公開しないでください。個人のドメイン、内部サービス名、アクセス経路が含まれることがあります。今回の問題に関係する部分だけを残し、個人情報を隠して共有してください。

同じサービスでも、ログイン、静的リソース、実際のサービスに異なるドメインを使うことがあります。トップページは開くのにログインできない場合は、トップページのドメインだけにルールを追加するのではなく、失敗した段階の接続を確認してください。カスタムルールがサブスクリプションの既定ルールを上書きしている場合もあるため、最近追加した例外を優先して調べます。一時的にルールを外して復旧した場合は、すべてのドメインを恒久的に同じ経路へ送るのではなく、より限定的な条件に変更してください。アプリの更新後に挙動が変わった場合も、プロセスとドメインを改めて確認します。

コマンドラインと開発ツールは個別に確認

ターミナルのプログラムは、デスクトップOSのシステムプロキシを自動で読み込むとは限りません。環境変数やアプリ固有の設定を使うツールもあり、起動時にしか読み込まない場合は変更後に新しいターミナルを開くか、プロセスを再起動する必要があります。異なるガイドにあるプロキシポートを、そのままこの端末に設定しないでください。実際の待ち受けアドレスとポートは、現在のクライアント設定を確認します。以下のコマンドは、現在のシェルにプロキシ環境変数が設定されているか確認するもので、新しいプロキシは設定しません。出力に認証情報が含まれる場合があるため、元の結果を公開の場に貼り付けないでください。

# Windows PowerShell: 一般的なプロキシ環境変数を確認
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY -ErrorAction SilentlyContinue

# macOS / Linux shell: プロキシ関連の環境変数を確認
printenv | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

古い環境変数が見つかった場合は、会社のポリシー、開発環境、現在のプロジェクトによって設定されたものか確認してから変更を判断します。用途がわからないまま、すべての変数を削除したり、システム全体の設定を直接書き換えたりしないでください。環境変数とツール固有の設定が競合する場合は、そのツールのドキュメントで優先順位を確認します。テスト時はターミナルとブラウザーの結果をそれぞれ記録し、使用しているプロキシ方式も説明してください。「PCはインターネットに接続できるのに、アプリはできない」とだけ伝えるより、原因を特定しやすくなります。

対象プラットフォームのルールと接続障害を分けて確認

AIツール、動画配信サービス、業務サービスでは、アカウントの地域、ログインセッション、接続元の判定に独自の要件が設けられている場合があります。ネットワークに接続できても、アカウントでの利用が許可されるとは限りません。対象外の地域、アカウント確認、アクセス拒否が表示された場合は、元のメッセージを保存してプラットフォームのルールを確認してください。接続元を頻繁に切り替えることを、標準の解決方法にしないでください。ChatGPTの場合は、AIツールの利用に関する特集とChatGPTの接続先選びと自己診断ガイドをご覧ください。動画配信については、動画配信ページを参照してください。

ルーティング、アプリのプロキシ、名前解決、アカウントを確認しても特定のアプリだけで失敗する場合は、問い合わせにアプリ名、失敗する操作、ブラウザーが正常か、通信制御の対象を一時的に広げた場合の結果を記載してください。障害の証拠として、個人的な会話、業務文書、セッション認証情報全体を送る必要はありません。アプリが企業のネットワークポリシーや証明書の固定を使っている場合は、許可される接続方法を管理者に確認してください。クライアントは対象アプリの利用権限に代わるものではなく、あらゆる業務が同じ通信経路で動作することを保証するものでもありません。

この段階に達したら問い合わせ

基本ネットワークが正常で、アカウントが利用可能、権限と設定も確認済みなのに、ネットワークや接続先を変えても解決しない場合は、ユーザーパネルの問い合わせフォームからサポートに相談してください。設定の解析エラーが続く、接続サービスが起動しない、注文とアカウントの状態が一致しない場合も、直接問い合わせることをおすすめします。「十分に調べた」と証明するために、危険な操作をしたり、端末を工場出荷時の状態に戻したりする必要はありません。関係のない試行を大量に並べるより、どこまで確認したかを明確に伝えましょう。

会社が管理する端末、業務用の証明書、LANへの接続に関する問題は、サポートとローカル管理者で担当範囲が異なります。まず管理者に現在の接続方式がネットワークポリシーで許可されているか確認してもらい、許可される範囲と具体的なエラーをサポートに伝えてください。特定のプラットフォームがアカウントを拒否している場合、サポート側で制限を解除することはできません。サービスの接続、システム管理、第三者アカウントの問題を分けて伝えることで、問い合わせが無関係な方向に繰り返し進むのを防げます。

「症状・範囲・比較結果」の順に問い合わせを書く

件名には「画面ロック後に切断され、ロック解除後に再接続する」「サブスクリプションのダウンロードは成功するが、解析エラーが出る」など、症状をそのまま記載します。本文には、発生し始めた時間帯、端末のOS、クライアント名を書き、続けてローカルネットワークの種類、使用中の接続先、具体的なエラー、影響範囲を説明してください。クライアントのバージョンは端末の画面からそのまま記載し、ネット上のガイドをもとに推測しないでください。わからない項目は、未確認と明記すれば十分です。正確に未記入とするほうが、見た目を整えるために不確かな情報を書くより役立ちます。

次に、試した比較方法と、その都度何をひとつだけ変更したかを説明します。同じ端末でネットワークを変えると復旧するか、同じネットワークで端末を変えると復旧するか、接続先を変えると症状が変わるか、ブラウザーとアプリの結果が一致するかを記載します。起きた順に短い文で並べれば十分です。長文にする必要はありません。サポートが次の案内を出せるよう、現在維持している設定も伝えてください。特に一時変更したDNS、システムプロキシ、バックグラウンド権限、ルールを明記すると、すでに変わった環境を前提にした案内を避けられます。

ログとスクリーンショットは必要な部分だけ共有

VPNGlassのプライバシー方針は匿名・ログなしです。一方、クライアントのローカル診断情報に端末情報、接続先ドメイン、アカウント関連の項目が含まれる場合があります。公開しても問題ないとは限りません。まずクライアントがサポートする方法で情報をエクスポートし、個人情報を隠して内容を確認してください。アカウントのパスワード、サブスクリプションURL全体、ログイン情報、決済情報の機密項目、問題と無関係な閲覧履歴は送らないでください。サポートから詳しい情報を求められた場合は、設定フォルダー全体を送るのではなく、必要な項目と用途を確認してください。

スクリーンショットにはエラーの文言と必要な周辺情報を含め、アカウント識別情報、プライベートネットワーク名、その他の機密情報は隠してください。支払いに関する問題では、ユーザーパネルの注文状況と必要な注文識別情報を共有すれば十分です。決済アカウントの情報をすべて表示する必要はありません。画面録画には通知、クリップボード、バックグラウンドのウィンドウが意図せず映ることがあります。送信前に最初から最後まで確認してください。診断に役立つため、接続先の名前と発生時刻はできるだけ残します。情報を隠すために、診断に必要な内容まですべて消さないでください。

復旧後も確認を完了し、すぐに記録を消さない

案内を受けたら、まず元の設定を保存してから、提案された操作をひとつずつ試してください。接続が復旧した後は、最初に失敗した操作を改めて行い、当時の条件も再現します。画面ロックの問題なら再度ロックし、ネットワーク切り替えの問題なら同じ切り替えを行い、アプリのログイン問題ならログイン手順を最後まで実施します。プロキシ対象を一時的に広げてアクセスできても、元のルールが修復されたとは限りません。接続先を変えて使えるようになっても、元の接続先の問題が解消したとは限りません。再テストの結果は元の問い合わせに返信し、引き続き原因を確認できるようにしましょう。

安定したことを確認してから一時的な設定を削除し、診断と関係のないセキュリティ設定を元に戻します。最終的に有効だった設定は記録しておいてください。利用への影響が続く場合は、問い合わせで引き続き相談できます。VPNGlassは30日間の無理由返金に対応しています。申請条件は利用規約をご確認ください。プラン、追加データパック、支払い方法はプランページをご覧ください。Alipay / WeChat Pay / USDTに対応しています。トラブルシューティングの目的は、問題を正確に伝えてネットワークを復旧することであり、同じテストを何度も繰り返させることではありません。

最後に、元の症状、効果があった変更、元に戻した設定をまとめておきます。次に同じ問題が起きても、最初から推測を繰り返すことなく、確認済みの結果から対応できます。