VPNのトラブルシューティング

接続できない：ネットワークと設定を確認

ローカルネットワークの切断か、プロキシ接続の失敗かを見分ける

まずクライアントの接続を切り、自動再接続を一時的にオフにして、普段そのまま開けるウェブサイトにアクセスしてください。この状態でも開けない場合、国際回線の問題ではなく、ローカルネットワーク側の可能性があります。Wi-Fiの認証を済ませ、ルーターの接続状態やネットワークの利用条件を確認してください。ホテル、学校、公衆ネットワークでは、先に認証ページを開く必要がある場合があります。認証が済むまで回線を何度切り替えても、通常は状況は変わりません。

直接アクセスに問題がなければクライアントを起動し、接続ボタンを押した後の状態を記録します。接続中のまま進まない、すぐ未接続に戻る、設定エラーが表示される、接続済みなのにページが開かない、といった症状はそれぞれ確認箇所が異なります。「使えない」だけで済ませず、状態を具体的に控えましょう。クライアントが接続を確立できるかどうかと、ブラウザーがその接続を利用できるかどうかは別の問題です。接続済みと表示される場合は、次の章を確認してください。

アカウント、プラン、回線リストを確認

アカウント概要を開き、プランの状態と残りの通信量を確認してから、クライアントでサブスクリプションを手動更新してください。月額プランの通信量は契約開始日を基準に毎月リセットされます。暦月が変わったかどうかだけでは、通信量が回復するタイミングは判断できません。決済ページで完了と表示されても、クライアントに最新の設定が読み込まれたとは限りません。管理画面とクライアントをそれぞれ確認し、古いリストで何度も接続を試さないようにしましょう。

現在選択しているのが、更新したサブスクリプションのグループか、過去に追加した同名の設定かを確認してください。リストが空、または回線名が古いままの場合は、回線を手動で推測したり認証項目を変更したりせず、まずサブスクリプションの問題を解決しましょう。リストに問題がなければ、別の回線を選んで試し、元の回線名も記録しておきます。回線の種類や地域の違いは回線の説明をご覧ください。名前が似ているだけで、同じ経路を使っていると判断しないでください。

権限と同時に動作するソフトを確認

初回起動時に、VPN接続の作成、ネットワーク拡張機能のインストール、ネットワーク管理権限の付与を求められることがあります。以前に拒否した場合、クライアントで回線一覧を表示できても、システムとの接続を確立できないことがあります。システムのネットワーク設定と権限設定を開き、クライアントに必要な許可が与えられているか確認してください。組織管理の端末では、組織のポリシーが影響している場合があります。権限をむやみに引き上げたり管理機能を無効にしたりせず、端末の管理者に確認してください。

ほかのVPNクライアント、プロキシツール、ネットワーク調査用のプロキシなど、ネットワークを制御するソフトを終了してから再度試してください。システムプロキシ、ルーティング、仮想ネットワークアダプターが競合すると、画面上は正常でも通信経路が衝突することがあります。まずアプリを終了して変化を確認し、すべてのソフトをアンインストールするのは避けましょう。システムの保護機能を一括で無効にして診断するのも適切ではありません。保護ソフトにブロック記録がある場合は、対象のプロセスと記録を照合してください。

元に戻せる条件比較で原因を絞り込む

可能であれば、同じ端末でローカルネットワークだけを切り替え、クライアントの設定と選択中の回線は変えずに比較します。ネットワークを変えて解消する場合は、元のネットワークの認証、接続ポリシー、ルーター設定を優先して確認してください。解消しない場合は、別の回線でも比較します。端末、ネットワーク、回線を同時に変えると判断材料が失われます。一項目ずつ試し、結果を記録してから次へ進みましょう。

エラーに証明書、ハンドシェイク、時刻に関する記述がある場合は、システムの日付、タイムゾーン、自動時刻合わせの状態を確認してください。時刻が大きくずれていると、正常な証明書の検証に失敗することがあります。証明書エラーを無視して接続を使い続けたり、見知らぬ配布元の証明書を追加したりしないでください。特定の回線だけで同じエラーが繰り返され、ほかの回線は使える場合は、エラー全文を保存し、サポートに回線設定を確認してもらいましょう。

接続済みなのにページが開かない：振り分けとDNSを確認

接続済みの表示だけでは、通信がプロキシ経由とは限りません

クライアントに接続済みと表示されても、接続の一部が確立したことを示すだけで、ブラウザーのリクエストがその接続を通ったとは限りません。直接アクセスできるサイトと目的のサイトを別々に開き、両方とも失敗するか確認してください。直接アクセスできるサイトは正常で目的のサイトだけ開けない場合は、ルールの適用、接続先サービス、出口を確認します。すべてのページが開けない場合は、目的のサイトだけに注目せず、システムプロキシ、DNS、ルーティングを調べましょう。

クライアントのリクエスト記録を開き、目的のページを再読み込みして、対応するドメインが表示されるか確認します。記録がなければ、ブラウザー独自のプロキシ設定や拡張機能、既存の接続が使われているか、現在のクライアントを経由していない可能性があります。まずブラウザーを終了して再起動し、プロキシ関連の拡張機能を一時的に無効にしてから、クライアントの説明に沿ってシステムプロキシを有効にしてください。ログインや認証のやり直しが必要になることがあるため、閲覧データをすべて消去するのは避けましょう。

ドメインの名前解決とウェブ接続を分けて考える

DNSはドメイン名をIPアドレスに変換しますが、名前解決に成功しても、その後に接続を確立する必要があります。ドメインを解決できるからといってウェブページが開くとは限らず、ページが開かない原因が必ずDNSとも限りません。「ホストが見つからない」「ドメインが存在しない」「名前解決がタイムアウトした」といったエラーは、名前解決の問題を示す可能性があります。「証明書エラー」「接続がリセットされた」「アクセスが拒否された」と表示された場合は、エラー全文を記録して次の段階を確認してください。すべてをDNSの問題と決めつけないようにしましょう。

デスクトップOSでは、次のコマンドでシステムのリゾルバーから応答があるか確認できます。例のドメインは基本的な名前解決の確認用であり、目的のサービスに実際にアクセスできることを示すものではありません。実行後は、IPアドレスが返ったか、タイムアウトしたか、明確なエラーが表示されたかを記録してください。クライアントが独自のDNS経路を使う場合もあります。システムコマンドが正常でもブラウザーで問題が起きるなら、クライアントのログも照合し、コマンドの結果だけで原因を除外しないでください。

nslookup example.com

ブラウザーとクライアントの名前解決経路を確認

ブラウザーのセキュアDNS、システムDNS、クライアント内蔵の名前解決機能、ルーターの設定が、リクエスト処理に同時に関わることがあります。まず現在の設定を記録し、クライアントの説明で推奨されている初期設定に戻してから、一項目ずつ比較してください。検索で見つけた公開DNSのアドレスをすべて設定するのは避けましょう。リゾルバーによって経路が異なるため、設定を混在させるとかえって結果が不安定になることがあります。公衆ネットワークでは認証時に指定されたDNSを使う必要がある場合もあるため、先に認証を済ませてください。

ブラウザーで独自のセキュアDNSを有効にしている場合は、一時的にシステムの名前解決を使う設定に切り替えて比較し、テスト後に元へ戻してください。変更後にそのブラウザーだけで改善した場合は、ブラウザーの名前解決経路とプロキシの組み合わせを確認しましょう。端末全体のルーティングを変更する必要はありません。すべてのアプリに影響がある場合は、システムとクライアントの設定を確認してください。設定を変えた後は、対象アプリを再起動し、新しい名前解決結果でリクエストされるようにします。

キャッシュと残存プロキシを確認する際の注意

キャッシュには古い名前解決結果が残ることがありますが、キャッシュの消去は経路を確認した後に行いましょう。まずブラウザーと対象アプリを終了し、現在のOSの公式手順に沿ってDNSキャッシュを更新してから、再接続して確認します。クライアントを終了した後もすべてのページが開けない場合は、システムにローカルホストを指す手動プロキシが残っていないか調べてください。クライアントの通常の終了操作でシステムプロキシを解除してから、アプリを終了します。設定の出所がわからない場合は、組織の設定を誤って削除しないよう、先に画面を記録してください。

ネットワークと回線を変えても同じドメインだけで名前解決の異常が続く場合や、クライアントにはリクエストがプロキシに渡ったと表示されるのにページが繰り返し失敗する場合は、対象ドメイン、エラー全文、個人情報を除いたログを添えて問い合わせてください。プライベートなパス、クエリパラメーター、ログイン情報を含むページURL全体は送らないでください。対象サイトに地域やアカウントに関する案内が表示される場合は、アプリのアクセス問題として確認し、DNSキャッシュの消去を続けないようにしましょう。

速度が遅い：回線速度、応答時間、アプリのボトルネックを切り分ける

まず、どの処理が遅いのかを確認

「速度が遅い」という症状を具体的に分けて考えましょう。ページがなかなか応答しない、画像が少しずつ表示される、ファイル転送が不安定、会議の音声が途切れる、といった違いがあります。前者は名前解決や接続確立、継続的な転送はローカル回線の帯域、通信経路、接続先サーバーが影響する可能性があります。まず何の操作が遅いのかを特定し、同じ操作で比較してください。速度測定サイトの結果だけでは、すべてのアプリでの使い心地は説明できず、各サイトの状態を示すものでもありません。

プロキシを切断した状態でも直接アクセスが遅いか確認し、クラウドストレージの同期、システム更新、大容量ファイルの転送を一時停止してください。家庭内のほかの端末が上り・下りの帯域を使っている場合もあります。プランの通信量に余裕があるからといって、ローカルネットワークの混雑を原因から除外しないでください。利用可能な通信量は使用枠であり、現在のネットワークが提供できる転送能力とは別です。ローカルアクセスも遅い場合は、まず接続環境を確認してから国際回線を比較しましょう。

接続先を変えず、回線かネットワークだけを変更

安定して再現できるページやタスクを一つ選び、端末、アプリ、ローカルネットワークはそのままにして回線だけを切り替えます。一時的な最高速度だけを見るのではなく、ページの表示開始、転送の持続性、操作の安定性を比較してください。隣接する地域でも経路が同じとは限らず、同じ地域の回線でも種類によって結果が異なる場合があります。回線の種類はサーバー一覧を参考にしてください。一覧は選択肢を示すもので、速度を保証するものではありません。

回線を変えても違いがはっきりしない場合は、回線を固定してローカルネットワークを切り替えて比べましょう。利用できる環境であれば、有線接続でWi-Fiの電波や干渉の影響を切り分けられます。無線環境では、ルーターから離れている、障害物が多い、接続端末が多いなどの条件で通信が不安定になることがあります。テスト中に端末を移動しながら回線も切り替えると、環境の変化が回線の差を覆い、再現しにくい結果になります。

IEPL、中継、直結の違いを理解する

IEPL専線、中継、直結は経路の構成方法を表すもので、固定の速度順位に置き換えることはできません。実際の使い心地は、ローカルの通信事業者、入口への接続性、出口の場所、接続先サービスの方式にも左右されます。目的に合わせて比較してください。業務では継続的な操作や会議の安定性、動画配信ではバッファリングの継続性、ファイル転送では長時間接続の状態が判断材料になります。回線の種類だけで、あらゆるネットワークに当てはまる結論を出さないようにしましょう。

同じ接続先でも時間によって異なるコンテンツ配信ノードから応答される場合があります。ブラウザーのキャッシュ、サイト側の速度制限、サーバーの混雑も比較結果に影響します。ほかのサイトは正常なのに特定のダウンロードだけが遅い場合は、まず接続先サービス側の制限を確認してから、同じ地域の別回線を試してください。国や地域を頻繁に切り替えるとアカウントの追加認証が発生することがあり、コンテンツ配信経路も変わるため、比較しにくくなる場合があります。

クライアントと端末の負荷を確認

端末で負荷の高い処理が同時に動いていないか、省電力モードになっていないか、クライアントで再試行や名前解決エラーが繰り返されていないか確認してください。システムの負荷が高いと、ウェブ処理とネットワーク処理の両方が遅くなり、回線以外の要因が関わることがあります。不要な処理を一時停止し、標準設定のまま再度試しましょう。いわゆる高速化パラメーターをそのまま適用するのは避けてください。特に並列処理、コネクション再利用、ネットワークスタックの設定は、クライアントの実装によって適切な値が異なります。

特定の接続モードを有効にした場合だけ問題が起きるなら、すぐにOSの再インストールが必要だと決めつけず、モード名と変更後の状態を記録してください。仮想ネットワークアダプター、システムプロキシ、アプリ専用プロキシでは通信を制御する範囲が異なり、既存のセキュリティソフトと干渉することもあります。以前使えていたモードに戻すことは原因の確認に役立ちますが、必要なアクセス制御を無効にしないでください。組織管理の端末では、ネットワークソフト間の互換性を管理者に確認しましょう。

サポートへの相談が必要な場合は、遅いと感じる具体的なタスク、対象ドメイン、発生する時間帯、利用中の回線、試した比較方法を伝えてください。「同じネットワークでほかのサイトは正常だが、このサイトだけ読み込みが続く」といった情報は、速度測定のスクリーンショットだけよりも役立ちます。特定の時間帯に限って発生する場合は夜間の章を、転送中に接続が切れる場合は切断の章を確認してください。

夜間に遅くなる：同じ条件で比較する

時間帯によって変化する問題か確認

夜に使いづらくなっても、特定の回線の混雑が原因とは限りません。家庭内のネットワーク利用の増加、Wi-Fiの干渉、接続先サービスの混雑、ローカル通信事業者の経路変更などが、近い時間帯に重なることがあります。普段問題なく使える設定を記録し、症状が出たときに同じタスクを繰り返してください。端末、ネットワーク、接続先、回線がほぼ同じ条件であれば、時間帯による差を判断材料にできます。条件を一度にすべて変えると、原因を特定しにくくなります。

遅くなり始めた時間と回復した時間をおおまかに記録し、セッション全体が不安定なのか、一時停止の後に再開するのかを分けて考えてください。帯域が継続的に不足している場合と、短時間の揺らぎがある場合では、確認する箇所が異なります。動画はバッファリングできるのに会議の音声が何度も途切れる場合、通信の揺らぎがリアルタイムのタスクに表れている可能性があります。アプリごとに異なる経路を使っている場合もあります。動画が再生できることだけで、会議アプリにネットワーク上の問題がないとは判断できません。

ローカルネットワークを確認してから国際経路を調べる

問題が起きたら、まず直接アクセスやローカルネットワーク上の利用にも影響があるか確認します。ほかの端末での大容量ファイル転送を止め、Wi-Fiはできるだけ同じ場所でテストしてください。有線接続にすると明らかに改善する場合は、まずローカルの無線環境を見直します。回線を変えずに同じ端末で別のネットワークへ接続すると回復する場合は、元のネットワークの接続品質や経路が有力な手がかりです。サブスクリプションを何度も追加し直す必要はありません。

直接アクセスは正常で国際ネットワーク上の接続先だけ遅い場合は、経路の異なる回線を比較します。地域やコンテンツ配信の差を抑えるため、まず同じ地域の別回線を試し、その後にほかの地域を検討してください。回線を切り替えたら、対象アプリのセッションを新しく確立し直します。古い接続が元の経路を使い続けることがあります。クライアントの回線名が変わっただけで対象タスクを再起動しないと、以前のセッションの結果を新しい回線の結果と誤認する場合があります。

会議、ドキュメント、動画で確認するポイント

動画ではバッファリングが継続して進むか、会議では音声が途切れないか、映像が断続的に止まらないか、オンラインドキュメントでは入力後に反映されるまでの時間を確認してください。進行中の会議で何度も回線を切り替えてテストするのは避けましょう。切り替えによって接続が切れることがあります。会議の前に、機密情報を含まないテストセッションで使える経路を確認し、検証済みの代替回線を控えておくと、必要なときに計画的に切り替えられます。

リモートワーク用ツールを使う場合は、組織のプロキシ、企業VPN、セキュリティゲートウェイが接続に関与していないかも確認してください。業務によっては組織のネットワーク経由での接続が必須です。一般向けのプロキシを、組織指定の接続方法の代わりに使わないでください。管理者には発生する時間帯やエラーの内容を伝え、組織のポリシーに変更がないか確認しましょう。回線を選ぶ際の考え方はリモートワーク向け回線選びガイドも参考になりますが、実際の環境では組織のルールと動作確認を優先してください。

一時的に効いた対処を恒久的な結論にしない

動画の画質を下げる、同期を一時停止する、検証済みの経路に切り替えるといった方法は、その場の対処として役立ちます。ただし、利用負荷を下げたり経路を変えたりするものであり、根本原因を特定したことにはなりません。タスクが終わったら、比較可能な条件に戻して引き続き確認してください。一度のテスト結果を求めてDNS、接続パラメーター、ルーティングルールをまとめて変更すると、次回の問題でどの変更が影響したのか分からなくなります。

同じ問題が決まった時間帯に繰り返し起き、ローカルネットワークの比較でも説明できない場合は、記録をサポートに送ってください。影響を受ける回線、接続先サービス、時間帯、ほかの回線の状態を伝えます。これらの情報があれば、該当する経路を確認できます。「夜はいつも遅い」という説明だけでは範囲が曖昧です。特定のアプリだけで起き、時間帯を変えても続く場合は、すべてを夜間の混雑と考えず、アプリの振り分けを確認してください。

頻繁な切断やバックグラウンドでの切断：システムの接続制御を確認

接続そのものの切断と、アプリのセッション終了を見分ける

異常が起きたとき、クライアントが本当に未接続になっているのか、それともクライアントは接続中のまま会議、チャット、ウェブのセッションだけが終了したのかを確認してください。前者はローカルネットワークの切り替え、プロセスの動作、システム権限を優先して調べます。後者ではアプリ独自のタイムアウト、認証、ルールも確認します。クライアントを再度開いてすぐ回復しても、回線が復旧したとは限りません。システムによってバックグラウンドのプロセスが再開しただけの場合もあります。前面に戻す前後の状態を記録しましょう。

画面ロック、端末のカバーを閉じる、Wi-Fiの切り替え、スリープ、バッテリー残量の低下の後に切断が起きるか確認してください。ネットワークインターフェイスが切り替わると、既存の接続を再確立する必要があり、アプリがすぐに再試行しない場合があります。まず画面を点灯したまま、同じネットワークを使う条件で試し、ロック時と比較しましょう。問題を避けるために端末のロックを恒久的に無効にするのはやめてください。画面ロックは診断の条件であり、普段の端末のセキュリティ設定を犠牲にする必要はありません。

Androidのバックグラウンド制限とVPNの権限

Androidのアプリ設定で、クライアントのバックグラウンド動作が許可されているか、バッテリー最適化の対象になっているか、システムがバックグラウンドのプロセスを終了していないか確認してください。設定メニューの名称は端末によって異なるため、現在のOSの説明に沿って該当項目を探します。必要なクライアントだけ権限を調整し、すべてのアプリを制限なしにする必要はありません。仕事用プロファイルや組織管理のポリシーが設定された端末では、現在のVPN設定が許可されているかも確認してください。

バックグラウンドでほかのアプリがVPN接続を確立しようとしていないか確認します。新しい接続要求によってシステムのVPN接続先が変わり、元のクライアントが制御を失うことがあります。まず同種のネットワークアプリを終了し、画面ロック後も切断するか確認してください。初回の追加手順や権限設定はAndroidのサブスクリプション追加・動作確認ガイドをご覧ください。追加が済んでいる場合は、本章ではプロセスと権限を確認します。アカウントを作り直す必要はありません。

iOSとデスクトップOSの違い

iOSでは、システムのVPN状態、クライアント設定、端末の管理要件に食い違いがないか確認し、自動接続する設定を複数残して切り替わらないようにしてください。ほかのプラットフォームにある省電力設定の名称を、そのままiOSに当てはめないでください。アプリの復元後に新しい権限の確認が表示された場合は、表示元を確かめ、クライアントの説明に沿って対応します。ネットワークを切り替えた直後だけ一時的に失敗する場合は、まず手動で再接続し、その後も安定するか確認してから追加の調査が必要か判断しましょう。

Windows、macOS、Linuxでは、スリープや復帰後のネットワークアダプターの状態も確認してください。端末のカバーを閉じるとシステムがスリープに入り、ネットワーク処理が一時停止することがあります。これはクライアントが通常動作中に予期せず終了するのとは異なります。復帰後に直接アクセスもできない場合は、まずローカルネットワークを復旧してください。プロキシだけ使えない場合は、クライアントの接続を確立し直します。復帰の問題を解決するために、よく分からないシステムサービスを変更したり、ネットワークドライバーを削除したりしないでください。

切断の前後を続けて記録

ログは再接続に成功した行だけでなく、切断の前後を含めて保存してください。ネットワークの変化、プロセスの終了、権限の失効、再接続の試行に関する記述を確認します。前面表示中でネットワークを固定していても特定の回線だけ切断し、別の回線に変えると回復する場合は、回線や経路の問題が考えられます。すべての回線が画面ロック後に失敗する場合は、端末のバックグラウンド動作の設定が関係している可能性があります。こうした切り分けで、端末の問題とサービスの問題を混同しにくくなります。

権限を確認し、ほかのクライアントとの競合がないのに、通常の前面使用中に何度も切断する場合や、ネットワークを切り替えた後に復旧せず、アプリの再起動が必要な場合は、問い合わせをご検討ください。端末のプラットフォーム、画面ロックの有無、ネットワークを切り替えたか、スリープを経たか、再接続後にどの程度使えるかを伝えてください。再インストールを繰り返して記録の代わりにしないでください。設定やログなど、役立つ手がかりが消えることがあります。

サブスクリプションの更新に失敗する：取得元と形式を確認

取得の失敗と設定の解析エラーを見分ける

サブスクリプションの更新には、内容の取得と読み込みの二つの段階があります。取得に失敗すると、タイムアウト、接続エラー、アクセス拒否などが表示されることがあります。解析エラーは、内容を取得できたものの、クライアントが有効な設定として認識できない状態を示すのが一般的です。ネットワークと設定のどちらを調べるべきか判断するため、まずエラーの全文を記録してください。更新に失敗したからといって、現在のサブスクリプションをすぐ削除しないでください。元の設定がまだ使えるなら、接続を復旧する手段として残せますし、比較材料にもなります。

ユーザーパネルを開き、現在のアカウントとプランの状態を確認してから、パネルに用意された入口で、使用中のクライアントに対応するサブスクリプションを取得し直してください。サブスクリプションの取得にはログインが必要です。公開記事、グループチャット、ほかの人のスクリーンショットからコピーしないでください。クライアントによって対応する読み込み形式が異なるため、URLのパラメーターを手動で編集するより、パネルの該当する入口を使うほうが確実で、コピー間違いも防げます。

コピーした内容を確認し、サブスクリプションのURLは公開しない

コピー時にスペース、改行、引用符、説明文が混ざったり、ログインページのURLをコピーしたりすることがあります。内容に欠けがないか端末上で確認してもかまいませんが、実際のURLを公開ページ、オンライン変換ツール、見知らぬ診断サービスに貼り付けないでください。サブスクリプションのURLは保護が必要なアクセス情報です。通常、サポートへの連絡では取得元のページと追加方法を伝えれば十分です。情報の提出が必要な場合は、管理されたサポート手順で求められたときに限り、案内に従ってください。

サブスクリプションの認証情報をリセットしたことがある場合、以前保存したURLは無効になっている可能性があります。古いURLを何度も更新するのではなく、クライアントの取得元を新しいものに変更してください。同じアカウントを複数の端末で使っている場合は、それぞれで現在の取得元を確認します。ブラウザーのブックマーク、クリップボードの履歴、古いメモには以前の内容が残りがちです。見た目が似ているというだけで、同じ状態のURLだと判断しないでください。

更新リクエストがどのネットワークを経由するか確認

サブスクリプションの更新リクエストをプロキシ経由にできるクライアントもあれば、システムネットワークや独自設定を使うものもあります。現在の回線が使えず、更新リクエストもその回線を経由する必要があると、自力で復旧できない状態になることがあります。クライアントの説明に沿って更新リクエストの経路を確認し、ローカルネットワークが正常であることを確認した上で、適切な方法を試してください。変更前に元の設定を記録し、完了後に回線リストを確認します。ネットワーク設定を一度にすべて変更しないでください。

取得した内容がウェブページのように見える場合、サブスクリプション設定ではなく、ネットワークの認証ページ、ログインページ、エラーページの可能性があります。公衆ネットワークで認証が済んでいない場合は特に注意してください。ページの文章を設定ファイルとして保存して無理に読み込ませたり、証明書の検証を無視して内容を取得したりしないでください。まずネットワークの認証を完了し、パネルの入口を確認してから再度更新します。エラーが続く場合は、応答の種類と表示内容を記録すれば十分です。返された内容をそのまま公開する必要はありません。

追加後は選択状態と保存状態も確認

追加に成功しても、クライアントが新しい設定に切り替わったとは限りません。現在有効な設定名、回線リスト、更新日時を確認し、新しいサブスクリプションが選択されているか確かめてください。同名のグループがある場合は、判別しやすいローカル名に変更してから接続を試します。アプリによっては以前選択した回線が残るため、新しい設定でその回線が変わっている場合は選び直してください。成功の表示だけを見て、その後の接続に新しい設定が使われていると決めつけないようにしましょう。

アプリの再起動後に設定が消える場合や、追加した設定が保存されない場合は、ローカルストレージの権限、アプリデータの保存場所、端末の管理制限を確認してください。これはサブスクリプションの提供側ではなく、クライアントの保存機能に関する問題の可能性があります。デスクトップOSで異なるアカウントを使い分けてクライアントを起動すると、設定フォルダーが別々に見えることがあります。アプリデータを削除するクリーナーを使う場合は、実行前に削除対象を確認してください。

パネルには正常にアクセスでき、正しい入口から取得し直しているのに複数のネットワークで更新に失敗する場合や、クライアントが形式エラーを繰り返し表示する場合は、問い合わせてください。クライアント名、OSの種類、エラー全文、追加方法、ほかの端末では更新できるかを添えます。特定のクライアントだけで失敗する場合は、その範囲を明記してください。アカウントの状態が想定と異なる場合は、パネルの表示内容も伝え、課金の問題と解析エラーを混同しないようにしましょう。

特定のアプリがプロキシを使わない：制御範囲を確認

ブラウザーが使えても、すべてのアプリが接続対象とは限りません

システムプロキシは、システム設定に従うアプリで使われますが、すべてのソフトがその設定を読み取るわけではありません。独自のネットワークスタックやプロキシ設定を使うアプリ、直接接続するアプリもあります。ブラウザーが正常でも、そのアプリの通信がクライアントを経由している証拠にはなりません。まず問題が特定のアプリだけで起きているか確認します。クライアントのリクエスト記録を開き、アプリを起動したときや対象の操作を行ったときに通信が記録されるか確認してください。回線の不具合だとすぐに決めつけないようにしましょう。

記録がない場合は、アプリ独自のプロキシ設定、クライアントの接続モード、プロセスの除外ルールを確認してください。記録がある場合は、実際に適用されたポリシーと選択中の出口を確認します。アプリはログイン、コンテンツ、更新、通知など、複数のドメインへ接続することがあります。ホーム画面のドメインだけを確認しても、機能が使えない原因を説明できない場合があります。問題が起きる具体的な操作を行いながら確認し、用途が分からないまますべてのドメインに同じポリシーを適用しないでください。

一時的なモード変更でルールの影響を比較

個人の端末で、利用環境の要件に反しない場合は、クライアントが対応するプロキシモードに一時的に切り替えて比較できます。モードを変えてアプリが使えるようになった場合、元のルールや接続制御の範囲を確認する必要があります。すべての通信を同じ経路に通し続けるべきという意味ではありません。テスト後は元のモードに戻し、対象ドメイン、プロセス、ルールの順序を確認してください。組織のイントラネット、ローカルネットワーク機器、業務システムに関わる場合は、先に組織の要件を確認しましょう。

ルールには適用順があり、広い範囲を対象とするルールが具体的なルールより先に適用されることがあります。変更前に、対象の通信に実際に適用されたルールを記録してください。ルールファイルに対象ドメインが書かれているだけで、設定が正しいとは限りません。サブスクリプションの更新でルールの一部が置き換わることもあるため、ローカルの変更にはクライアントが対応する上書き機能やカスタム設定を使います。管理が難しい生成済み設定ファイルを直接編集すると、次回の更新後に問題が再発する可能性があります。

長時間接続、UDP、キャッシュされたセッションに注意

アプリによっては接続を長時間維持するため、クライアントで回線を切り替えても、既存のセッションがすぐに移行するとは限りません。アプリを終了し、バックグラウンドのプロセスも停止したことを確認してから起動し直すほうが、画面を再読み込みするだけよりも切り分けに役立ちます。作業中のアプリを終了する場合は、データを失わないよう先に保存してください。再起動後に使えるようになった場合は、すぐにアカウントや接続先サービスの制限と決めつけず、回線の切り替え後にだけ再発するか確認しましょう。

会議、音声通話、リアルタイムの共同作業では、ウェブページとは異なる通信方式を使うことがあります。ウェブページが使えても通話に問題がある場合は、クライアントがそのアプリに必要な通信の制御に対応しており、有効になっているか、ローカルネットワークのポリシーに問題がないかを確認してください。出所が分からないポート一覧をそのまま使ったり、セキュリティルール全体を緩めたりしないでください。組織管理の会議システムでは、公式のネットワーク要件を確認し、管理者に許可されている接続方法を問い合わせましょう。

ネットワーク障害とサービス側のアクセス拒否を区別

アプリに地域、アカウント、支払い、認証に関する案内が明確に表示される場合、リクエストは接続先サービスに到達している可能性があります。その場合、DNSを変更しても解決しないことがあります。ChatGPT、Claude、Geminiなどのツールが利用できるかどうかは、接続先サービスの地域やアカウントのポリシーにも左右されます。動画配信サービスも、コンテンツやアカウントの状態に応じてアクセスを判断する場合があります。回線の対応地域は、個々の第三者サービスが常に利用できることを保証するものではありません。接続先サービスの最新ルールと実際の結果を確認してください。

テスト中は出口の地域を固定してから、同じ地域の別回線と比較し、地域を頻繁に切り替えて追加認証を招かないようにしてください。同じアカウントを使っていても、ブラウザーでは利用できてアプリでは失敗する場合は、アプリのキャッシュ、認証セッション、公式の稼働状況も確認します。診断のために個人アカウントを他人に使わせないでください。AIの利用についてはAI利用のネットワーク特集をご覧ください。本章の接続制御の確認と併せて、回線選びの参考にしてください。

サポートへの問い合わせには、アプリ名、影響を受ける機能、OSの種類、クライアントのモード、対象ドメイン、適用されたルールを添えてください。スクリーンショットでは会話の内容、個人情報、アクセス認証情報を隠します。特定の接続モードだけで問題が起きる場合は、正常なモードとの違いを明記してください。接続先サービスに明確な拒否メッセージが表示された場合は、メッセージの原文を記録します。ルールファイル全体を送るよりも原因を特定しやすく、不要な情報の開示も避けられます。

Windowsのデスクトップアプリで、システムプロキシ、タスクトレイでの常駐、スタートアップの関係を確認するには、Windowsのシステム全体のプロキシと通信振り分けガイドも参考になります。本章では起動中の通信経路を扱います。スタートアップが成功しただけで接続確認まで完了したとは限りません。起動方法を変更した後も、現在の設定と対象リクエストが実際に反映されているか確認してください。

端末の警告と問い合わせ：再現できる情報をまとめる

接続端末数の上限と表示されたら、まず表示元を確認

I8VPNでは同時接続台数に制限はありません。端末数の上限に関する表示が出ても、追加の端末枠を購入する必要があるとは限りません。I8VPNのユーザーパネル、クライアント自体、アクセス先の第三者アプリのどこに表示されたか確認してください。第三者サービスのアカウントには独自のセッション管理ルールがあり、端末のOSが特定のネットワーク設定を制限する場合もあります。こうした制限は、本サービスの同時接続ポリシーとは別のものです。

表示が出た場所、文面全体、表示につながった操作を記録し、現在ログインしているアカウントと有効なサブスクリプションを確認してください。古い設定、別サービスのサブスクリプション、クライアント独自のアカウント機能が原因で、表示元を誤認することがあります。原因を調べるためにすべての端末から一括でログアウトしたり、アカウント情報を公開したりしないでください。本サービス関連の画面であることが確認できた場合は、スクリーンショットと再現手順を添えてサポートに問い合わせましょう。追加料金が必要だと自己判断する必要はありません。

調査内容を簡潔にまとめる

有効な問い合わせでは、まず期待した結果と実際の結果を説明します。たとえば、「クライアントを起動すると対象ページが開くはずだが、クライアントは接続済みなのにブラウザーで名前解決のタイムアウトが表示される」といった形です。続けて、発生日時とタイムゾーン、OSの種類、クライアント名、ローカルネットワークの種類、回線名、現在のモードを記載します。最後に試した変更とその結果を書き、特に変えていない条件を明記すると、比較結果を把握しやすくなります。

エラーの原文は要約より役立ちますが、ログ全体を貼り付ける必要はありません。発生時刻の前後に関係する箇所を抜き出し、エラーの種類と順序を残しながら、サブスクリプションのURL、ログイン情報、個人用ディレクトリ、無関係なアクセス内容を隠してください。I8VPNはログを保存しない方針ですが、ユーザーが自分で提出する診断資料も必要最小限にしてください。この方針があるからといって、端末上の記録を確認せずにすべて送ってよいわけではありません。

自分での変更を止めるべきケース

システムのネットワーク機能の削除、出所不明の証明書の追加、組織管理ポリシーの変更、セキュリティルール全体の緩和が必要になったら、操作を止め、適切なサポートを求めてください。こうした変更は、この問題とは無関係なアプリにも影響し、正常だった環境を損なうことがあります。組織の端末であれば、まず管理者に相談してください。特定の回線だけでエラーが続き、ほかの回線は使える場合は、使用可能な経路を残し、問題のある回線の情報を本サービスのサポートに送ってください。

すでに多くの変更を行った場合は、追加の「修復ツール」を試すのではなく、変更内容を一覧にし、確認できる順に元へ戻してください。クライアントを初期設定に戻す前に必要なローカルルールを保存し、バックアップに機密情報が含まれていないか確認します。システムネットワークのリセットは影響範囲が大きく、最初に行うべき操作ではありません。変更の影響が分からない場合は、すべて初期設定だと伝えるより、現在の状態と行った操作を説明したほうが調査に役立ちます。

料金と接続の問題は分けて確認

月額プランの通信量は契約開始日を基準に毎月リセットされ、月の途中でプランを上げた場合の差額は残りの日数分で計算されます。通信量パックは使い切るまで有効で、期限はありません。クライアントの接続異常と通信量不足の表示が同時に出た場合は、まずパネルで残量とプランの状態を確認し、利用プランを変更する必要があるか判断してください。価格と請求方法の詳細はプラン・通信量パックの説明をご覧ください。ネットワークの診断の代わりに、繰り返し支払いを行わないでください。

本サービスでは、理由を問わず7日間の返金に対応しています。条件の詳細は利用規約をご確認ください。調査中に注文や返金について手続きが必要な場合は、希望する内容を問い合わせに明記し、注文の確認に必要な情報だけを添えてください。決済情報の全文は公開しないでください。支払い方法はAlipay / WeChat Pay / USDTです。第三者アプリが求める支払い方法と本サービスの支払い方法を混同せず、ウェブページの表示だけで注文が無効になったと判断しないでください。

復旧後は必要最小限の設定を基準として残す

問題が解決したら、正常に使えた回線、接続モード、必要な権限、原因と修正内容を記録します。テスト用に追加した一時的なルールを削除し、普段使う設定に戻してください。その後、直接アクセス、対象アプリ、画面ロックからの復帰、サブスクリプションの更新を確認し、新たな問題が起きていないか確かめます。記録は自分で管理できる場所に保存し、認証情報を含めないでください。次に問題が起きたとき、この状態と比較すれば、見慣れないパラメーターを一から試すより確実です。

初期設定がまだの場合は、かんたんスタートガイドに戻って手順を進めてください。簡単な質問を確認したい場合はヘルプセンターをご覧ください。このページの目的は「使えない」という状態を、具体的に切り分けることです。どの端末、どのネットワーク、どの回線、どのアプリで、どの操作が失敗するのかを確認しましょう。状況の境界が明確になるほど、次の手順を選びやすくなり、不要な変更も減らせます。