まず判断方法を固定する
トラブルシューティングは、回線を何度も切り替えたり、クライアントを繰り返し再インストールしたりすることではありません。アカウントとサブスクリプション、クライアントのコア、システムネットワーク、現在の接続ネットワーク、対象Webサイトやアプリに分けて確認する方が効果的です。まず1台のデバイスだけで発生しているか、次に1本の回線だけに影響しているか、最後に1つの対象サービスだけに影響しているかを確認します。範囲を絞るほど、本当の原因を見つけやすくなります。
EQVPNは Windows / macOS / iOS / Android / Linux に対応し、90+か国 / 200+回線をカバーしています。プラットフォームによって権限管理、バックグラウンド動作、DNSの挙動が異なるため、同じサブスクリプションでもデバイスによって結果が異なる場合があります。以下ではクライアント内の問題、システム設定の問題、外部ネットワークの条件を明確に分け、すべての異常を回線のせいにしないようにします。
まったく接続できない:失敗した場所を特定する
接続ボタンがすぐ元の状態に戻る、接続中のまま長時間進まない、ハンドシェイクやタイムアウトの表示が出る、またはすべての回線で接続できない、といった症状が典型的です。
アカウント、サブスクリプション、回線の問題を切り分ける
クライアントを開いても、すぐに大量の回線を次々と切り替えないでください。まず回線一覧が正常に表示されるか、サブスクリプション名が表示されるか、通信量を読み取れるか、サブスクリプションが無効と明確に表示されていないかを確認します。回線一覧が完全に空の場合は、まずサブスクリプションのインポートや更新を確認します。回線は表示されるもののすべて接続できない場合は、ネットワーク権限と接続プロトコルを確認します。一部の回線だけ失敗する場合は、回線選択の問題に絞り、クライアント全体をリセットする必要はありません。
ユーザーパネルにログインして現在のサービス状態を確認し、パネルが最新に提供しているサブスクリプションをインポートしているか確認します。サブスクリプションの内容をチャット履歴や古いデバイスから手作業でコピーしないでください。古いテキストには、その後に追加・調整された回線情報が含まれていない場合があります。プランを変更した直後は、クライアントでサブスクリプションを手動更新してから、回線を選び直します。EQVPNの月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中でのアップグレード差額は残り日数に応じて換算されます。プランの状態とローカルクライアントのキャッシュは別物であり、パネルが正常でもクライアントが最新情報に同期済みとは限りません。
システム権限とローカルネットワークを確認する
クライアントが接続を確立する際は、システムネットワークインターフェースの作成やプロキシ設定の書き込みが必要です。WindowsとmacOSではシステム権限の確認が求められる場合があり、モバイル端末ではネットワーク構成の許可が表示されます。以前に許可を拒否した場合、接続ボタンを繰り返し押しても自動的には復旧しません。システム設定で該当する権限を確認し、クライアントを完全に終了してから再度起動してください。Linuxでは、ネットワーク設定に必要な権限が現在のアカウントにあるか確認し、クライアントログにインターフェース作成失敗、ルート書き込み失敗、権限拒否などの記録がないか確認します。
続いて、基礎となるネットワーク自体が利用できるか確認します。いったん高速化接続を切断し、普段直接アクセスできるWebサイトを開いてください。通常のWebページも開けない場合は、サブスクリプションの設定を変更する前に、現在のWi-Fi、有線ネットワーク、モバイルネットワークを復旧させます。公共ネットワークでは、ブラウザーで先に認証が必要な場合があります。認証ページが表示されない場合は、いったん切断してネットワークに再接続し、通常のWebページを開いて入口を表示させます。会社、学校、ホテルのネットワークでは一部の接続方式が制限されることもあります。その場合は、既知の正常な別ネットワークに切り替えて比較する方が、クライアントのパラメーターを変更し続けるより有効です。
単一回線のテストから範囲を広げる
回線を選ぶ際は、一覧から用途に合い、地域的にも無理のない回線を使ってください。名前だけで判断しないようにします。クライアントが成功または失敗を明確に返すまで待ってから、次を試します。接続後はまず通常のWebページで確認し、データ量の多いアプリや高画質動画を最初のテスト対象にしないでください。通常のWebページが利用できたら、実際の利用シーンを段階的に確認します。これにより「接続できない」と「接続後に特定のサービスだけ利用できない」を分けて扱えます。
同じデバイスで、異なる接続ネットワークを使ってもすべての回線が失敗し、別のデバイスでは同じアカウントで接続できる場合、問題は元のデバイスのクライアント権限、残存プロキシ、セキュリティソフトのルールに集中している可能性があります。まず他のネットワークツールを終了し、システムプロキシを自動設定に戻してから、クライアントを再起動します。設定が明らかに壊れている、回線一覧を読み込めない、ログにローカルファイルエラーが継続して記録される場合に限り、サブスクリプションの再インポートを検討します。アンインストールと再インストールは後の手順にしてください。問題の判断に使えるログや設定状況が消えてしまうためです。
| 確認結果 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| 回線一覧が空 | サブスクリプションのインポートと更新状態 | ユーザーパネルからサブスクリプションを再取得 |
| 一部の回線だけ失敗 | 回線の現在の状態と用途 | 同じ地域の別回線に切り替えて再テスト |
| すべての回線が失敗 | システム権限、接続ネットワーク、残存プロキシ | 接続ネットワークを変更し、ログを保存 |
| 他のデバイスは正常 | 元のデバイスのクライアントとシステムネットワーク | 権限を確認してからサブスクリプションを再インポート |
上記の比較を終えても接続できない場合は、クライアントに表示された元のエラー、利用プラットフォーム、接続ネットワークの種類、試した回線名、他のデバイスが正常かどうかを記録してください。「接続できない」だけでは、失敗した段階が分からず、サポートがサブスクリプション、権限、ネットワーク制限、回線異常を区別できません。
接続済みなのにWebページを開けない
クライアントの「接続済み」は、ローカルインターフェースまたはプロキシポートが確立したことを示すだけです。ブラウザーのリクエストが正しい経路を通ることや、ドメイン名の解決が完了していることまで保証するものではありません。
すべてのWebページか、特定の対象だけかを確認する
接続後、通常のWebページ、異なるドメインの別サイト、元の対象サイトの順にテストします。すべてのWebページが開けない場合は、システムプロキシ、DNS、クライアントの動作モードを優先して確認します。1つのWebサイトだけ失敗する場合は、対象サービスの状態、地域要件、ブラウザーキャッシュ、現在の回線が用途に合っているかが原因である可能性が高くなります。1つのサイトが失敗しただけでサブスクリプションを削除したり、ブラウザーの証明書エラーを速度問題として扱ったりしないでください。
同じWebサイトは、ブラウザーのプライベートウィンドウでも比較してください。通常のウィンドウには、以前のログイン地域、サイトキャッシュ、サービスワーカー、拡張機能のルールが残っている場合があります。プライベートウィンドウで正常なら、そのサイトのデータを削除し、ネットワークリクエストを変更する可能性のある拡張機能を無効にします。すべてのブラウザーで失敗する場合は、システムネットワーク層に戻って確認します。ブラウザーによって結果が異なる場合、通常は高速化回線自体は確立しており、問題が回線そのものとは限りません。
システムプロキシが上書きされていないか確認する
クライアントにはシステムプロキシを利用するものと、仮想ネットワークインターフェースで通信を引き受けるものがあります。別のネットワークツール、ブラウザー拡張機能、企業管理ソフトが同時にプロキシ設定を変更すると、クライアントが接続済みでもリクエストが古いポートへ送られる場合があります。他のプロキシ系ツールを完全に終了し、システムプロキシが現在のクライアントによって管理されているか確認してください。出所の分からないローカルアドレスを手動入力したり、複数の自動構成スクリプトを同時に有効にしたりしないでください。
Windowsではシステムのネットワーク設定でプロキシ状態を確認できます。macOSでは、現在のネットワークサービスの詳細設定でプロキシ項目を確認します。Linuxのデスクトップ環境では、デスクトップのプロキシ設定とターミナルの環境変数が同時に存在する場合があります。ターミナルでは接続できるのにグラフィックアプリではできない、またはその逆の場合は、2つのプロキシ入口が一致していない可能性があります。クライアントがシステムプロキシ、仮想インターフェース、アプリ内プロキシのどれを使うかを明確にし、対象プログラムも同じ方式に合わせてください。
最小限のリクエストで名前解決と通信を確認する
コマンドラインツールを使うと、ブラウザー画面に含まれる複雑な要素を一時的に切り離せます。以下のコマンドは例示用ドメインにのみアクセスし、アカウント情報や実際のサブスクリプションアドレスは含みません。ドメインを解決できない場合はDNSの章へ進みます。解決できても接続がタイムアウトする場合は、回線、システムプロキシ、接続ネットワークを確認します。コマンドラインは正常でブラウザーだけ失敗する場合は、ブラウザーキャッシュ、拡張機能、セキュリティポリシーに絞って確認します。
nslookup example.com
curl -I https://example.com
コマンドの実行前後で接続状態をそろえてください。回線を切り替えながらコマンドを繰り返すと、どの条件に対応する結果か分からなくなります。コマンドが返す具体的なアドレスはネットワーク環境によって変わるため、アドレスを覚えることではなく、名前解決が完了したか、接続がタイムアウトしたか、証明書やプロキシ関連のエラーが出たかを確認します。ターミナルが古いプロキシ環境変数を引き継いでいる場合は、いったん閉じて新しく開いてから再テストし、すでに閉じたローカルポートを古いセッションが使い続けないようにします。
接続モードと振り分けルールの影響
ルールモードでは通常、条件に一致するリクエストだけが国際回線に入り、それ以外は元の経路を維持します。グローバルモードは、ルールに一致していないことを確認するために使います。ルールモードでは開けず、グローバルモードで開ける場合は、基礎接続はおおむね正常で、ルール、ドメインの一致、アプリの接続方式を確認すべきです。グローバルモードは短時間の診断用にし、影響範囲を理解しないまま長期的に依存しないでください。診断後は元のモードに戻し、必要な対象に正常にアクセスできるか再確認します。
Webページを開いた後も空白のまま、画像が読み込まれない、ログインページが繰り返し表示される場合は、ページのリソースが複数のドメインから取得され、その一部だけが正しい経路に入っている可能性があります。ブラウザーの開発者ツールで失敗したリクエストのドメインを確認できますが、Webサイトのコードを変更する必要はありません。失敗したドメインとエラーの種類を記録し、ルールで関連ドメインが一貫して処理されているか確認します。ストリーミングでは回線ページで用途に合う地域を選び、AI ツールの長時間接続に問題がある場合はCursorの回線選びガイドを参照してください。
これらの手順を行っても通常のWebページ、別のブラウザー、コマンドラインのリクエストがすべて失敗し、クライアントログだけが接続確立を示している場合は、ログを保存して問い合わせを送ってください。接続モード、影響範囲、利用回線、元のエラーを添えることで、サポートはローカルリクエストがプロキシに入っていないのか、DNSが応答していないのか、回線から対象サイトまでの経路に問題があるのかを判断できます。
速度低下と夜間の混雑を見分ける
速度の問題は、1回のダウンロード結果だけで判断できません。Webページの初回表示、動画の継続転送、会議の安定性、開発ツールの長時間接続では、必要なネットワーク性能が異なります。
まず「遅い」と感じる作業を特定する
Webページの表示は遅いのに大容量ファイルのダウンロードが安定している場合、ドメイン解決、最初の接続確立、対象サイトの応答速度が原因として考えられます。ダウンロード開始は速いのにその後低下する場合は、接続ネットワークの揺らぎ、対象サービスの速度制限、経路の混雑が考えられます。動画は読み込めても画質が頻繁に下がる場合、継続転送が安定しているか確認します。会議の映像が止まる、音声が途切れる場合は、最大帯域幅よりもジッターとパケットロスを重視します。まず作業の種類を明確にし、すべての体感を一つの「速度低下」にまとめないことが重要です。
テスト中は、ファイル同期、システム更新、動画再生を行っている他のアプリを停止します。EQVPNは台数無制限ですが、複数のデバイスで大量の通信を同時に行えば、家庭、オフィス、モバイルネットワークの出口帯域を共同で使います。台数無制限は利用条件を示すものであり、接続ネットワーク自体に容量の上限がないという意味ではありません。他の通信を止めて改善するなら、まずローカルネットワークの利用状況を整理してから、回線変更の必要性を判断します。
再現可能な比較条件を作る
速度を確認するときは、デバイス、接続ネットワーク、対象作業、テスト時間帯を固定し、回線だけを切り替えます。まず近い地域で用途に合う回線を使って作業を1回行い、同じ地域の別回線に切り替えて比較します。異なる大陸、異なる対象サイト、異なるデバイスを連続して切り替えて比較しないでください。条件が多すぎると、どの結論も信頼できません。回線名が似ていても実際の経路が同じとは限らないため、同じ作業での安定性を重視します。
昼間は正常で夜間に明らかに遅くなる場合は、ローカルの接続ネットワークと国際回線を分けて確認します。まず高速化接続を切断し、同じ時間帯に通常のネットワークでも読み込みが遅くなるか確認します。基礎ネットワークも同時に悪化しているなら、家庭用回線、無線環境、上流側の混雑が主な要因かもしれません。基礎ネットワークが正常で特定の回線だけ遅い場合は、同じ用途の別回線に切り替え、発生時間帯を記録します。一度だけの断続的な遅延では回線の長期状態を判断できません。同じ条件で連続して再現できる場合に、回線に関するフィードバックを送るのが適切です。
| 利用シーン | 優先して確認する点 | 推奨する対応 |
|---|---|---|
| 通常のブラウジング | ドメイン解決と初回表示までの待ち時間 | ブラウザーとDNSを比較し、距離の妥当な回線を選ぶ |
| ストリーミング再生 | 継続転送と地域の適合性 | 用途に合う回線を選び、バックグラウンド通信を抑える |
| ビデオ会議 | 音声の途切れ、映像の停止、再接続 | 安定した経路を優先し、大容量ファイルの同期を停止する |
| AI と開発ツール | 長時間接続、応答の中断、コマンドラインリクエスト | 回線を固定して再テストし、セッション中の頻繁な切り替えを避ける |
無線環境とデバイスの状態が誤った印象を生むこともある
無線信号が最大に見えても、干渉が少ないとは限りません。接続ポイントからの距離、壁による遮蔽、Bluetooth機器の集中、バックグラウンドの省電力設定、ネットワークアダプターのドライバー状態などが継続転送に影響します。同じ場所で有線ネットワークや別のデバイスと比較してください。別のデバイスが同じ回線で正常なら、サブスクリプションを何度も切り替える前に、元のデバイスの無線環境、システム更新、省電力モード、セキュリティソフトを確認します。
モバイルネットワークは、場所や基地局の負荷によっても変化します。確認時は屋内のモバイルネットワークと固定回線の結果を直接比較せず、移動中の一時的な切り替えを回線障害とみなさないでください。固定した場所でも変動が続く場合は、接続ネットワークを切り替えて再テストします。クライアントログにインターフェースの再構築やネットワーク変化が頻繁に記録される場合は、速度比較を続けず、頻繁な切断の章を確認してください。
通信量の状態とプラン選び
クライアントの動作に異常がある場合も、パネルにログインして通信量の状態を確認してください。月額サブスクリプションは ¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBが含まれ、通信量は開通日を基準に毎月リセットされます。途中でのアップグレード差額は残り日数に応じて換算されます。使い切りで有効期限のない通信量パックもあり、¥158/300GB、¥358/1000GB、¥658/3000GBです。利用条件を比較する場合は料金プランページを確認し、クライアントに残った古い表示から現在の状態を判断しないでください。
特定の用途だけが継続的に遅く、通常のブラウジングが正常なら、回線ガイドを参考に地域と用途に合わせて回線を変更してください。リモート会議や共同作業についてはリモートワーク向け回線の選び方も参照できます。速度に関する問い合わせには、再現可能な作業、発生時間帯、比較した回線を添えてください。「何もかも遅い」のように範囲を絞れない表現は避けます。
頻繁な切断とモバイル端末のバックグラウンド切断
切断は、接続ネットワークの切り替え、省電力機能、クライアントの終了、回線の再接続、デバイスのスリープなどが原因で発生します。まず、切断が前面表示での利用中に起きたのか、バックグラウンドに切り替えた後に起きたのかを確認します。
本当の切断とアプリのセッション中断を区別する
クライアントが接続済みのままでも、特定のアプリが再ログインを求めることがあります。これは必ずしも高速化接続の切断を意味しません。回線の切り替え、出口地域の変化、アプリ側のタイムアウト、サーバー状態によってアプリのセッションが終了する場合があります。まず通常のWebページを開いて全体の接続を確認し、クライアントに再接続の記録があるか確認します。Webページと他のアプリが正常なら、対象アプリのログインや地域設定を確認します。すべてのリクエストが同時に中断し、クライアントの状態も変化した場合に限り、ネットワーク切断として扱います。
頻繁な切断があるときは、自動切り替えを有効にしたまま観察をやめないでください。自動切り替えにより表面上はすぐ復旧しても、元の回線、接続ネットワーク、システムインターフェースが繰り返し再構築される問題を隠す可能性があります。診断中は1本の回線に固定し、接続から中断までに何が起きたかを記録します。デバイスがロックされたか、Wi-Fiが切り替わったか、屋内から屋外へ移動したか、スリープから復帰したか、他のネットワークツールを同時に起動したかを確認してください。イベントの順序は、「いつも切れる」という一言より有用です。
モバイル端末のバックグラウンド設定
iOSとAndroidはいずれもバックグラウンド動作を管理しますが、具体的な設定場所はシステムや端末メーカーによって異なります。クライアントが必要なネットワーク設定を維持できるようにし、そのクライアントに対する過度な省電力制限を解除し、画面ロック後にシステムが自動終了していないか確認してください。確認のために端末全体のセキュリティ機能や省電力機能を無効にするのではなく、現在のクライアントに直接関係する項目だけを調整します。変更後はクライアントを開き直して接続し、実際の利用に必要な時間だけ画面をロックしてから、状態を確認します。
前面表示では安定し、画面ロック後に切断する場合は、バックグラウンド設定が重点確認箇所です。画面が点灯していても切断する場合は、ネットワークの切り替え、回線、システムインターフェースを確認します。モバイルネットワークとWi-Fiを切り替えると基盤となるアドレスが変わり、元の接続を再確立する必要があります。短時間の中断は、まず観察すべきネットワークイベントです。クライアントが自動復旧できない場合は、ネットワーク切り替えが完了してから手動で再接続し、その条件を問い合わせに記載してください。モバイル端末全体が利用できないと一括りにしないことが重要です。
デスクトップのスリープ、ネットワークアダプター、セキュリティソフト
デスクトップデバイスがスリープから復帰した後、ネットワークインターフェースの復旧がクライアントより遅れる場合があります。クライアントは古い状態を保持していても、実際の経路はすでに無効になっている可能性があります。まずシステムネットワークが復旧するまで待ち、その後切断して再接続します。毎回復帰時に再現する場合は、クライアントを終了してから起動し直して比較します。Windowsではネットワークアダプターの省電力設定も確認し、macOSでは他の設定ツールが現在のネットワークサービスを書き換え続けていないか確認します。Linuxではシステムネットワークマネージャーのログを確認し、切断時にインターフェースが再接続されていないか調べます。
セキュリティソフトは、ネットワーク環境の変化後にクライアントが作成したインターフェースを再評価する場合があります。セキュリティツールのインストールや更新後に切断が頻発し始めた場合は、すべての保護機能を停止するのではなく、ネットワークルールとイベント記録を確認します。現在のクライアントに必要なネットワークアクセスを許可して再テストし、変更前後の結果を保存してください。企業管理デバイスでは管理者がルールを一括配布していることがあり、自分で変更できない場合は、管理ポリシーが対象接続を許可しているか確認します。
接続ネットワークの変化を除外する
固定した場所で安定した接続ネットワークを使い、デバイスを移動したりネットワークを切り替えたりせず、実際の作業を長時間行います。固定条件で安定し、移動中に切断するなら、主な原因はネットワーク切り替えです。固定条件でも中断する場合は、同じ地域の別回線で再テストします。複数の回線が似た操作で中断するなら、クライアントログとシステムイベントを確認します。この順序で、モバイルネットワークの切り替え、単一回線の異常、ローカルクライアントの問題を段階的に切り分けられます。
切断が特定のアプリで通話、ライブ配信、長時間接続を行ったときだけ発生する場合は、通常のWebページと別の継続接続タスクも確認します。単一アプリの切断は、アプリ独自のネットワーク実装、振り分けルール、バックグラウンド制限が原因かもしれず、直接回線障害と判断すべきではありません。すべてのアプリが同時に中断し、ログに接続終了、インターフェース消失、ネットワーク変化が記録されている場合は、該当箇所をそのまま提出してください。最後の1行だけを切り取らないでください。
サポートに連絡する際は、プラットフォーム、接続ネットワーク、回線名、前面表示かバックグラウンドか、画面ロックやスリープを経たか、他の回線でも再現するか、クライアントログの完全なエラー部分を提供してください。ログに個人のサブスクリプション情報が含まれる場合は、ユーザーパネルの問い合わせから送信し、公開しないでください。EQVPNのユーザーパネルには問い合わせ入口があり、ログイン後のサポートエリアから資料を送信できます。
サブスクリプション更新の失敗と回線一覧の異常
サブスクリプションの更新は、パネルにある回線設定をクライアントへ同期する処理です。更新に失敗しても、キャッシュ済みの回線がすぐにすべて無効になるとは限りません。ただし古いキャッシュを使い続けると、トラブルシューティングの結果が不正確になります。
取得元とアカウント状態を確認する
サブスクリプションはユーザーパネルから取得してください。ログインにはユーザー名とパスワードが必要ですが、登録にメールアドレスは必要ありません。古いメモ、ブラウザー履歴、他のデバイスから転送されたものを使っている場合は、パネルに戻って再度コピーするか、クライアントが対応するインポート入口から取得します。公開ページ、フォーラム、スクリーンショットに完全なサブスクリプション内容を表示しないでください。アカウントの提供に関わる情報が含まれている可能性があります。
パネルが正常に開けることを確認し、現在のプランと通信量の状態を確認します。パネル自体にログインできない場合は、まずアカウントの問題を解決します。パネルは正常なのにクライアントの更新だけ失敗する場合は、ローカルキャッシュ、サブスクリプションアドレスの読み取り、クライアントのネットワーク権限、現在の接続ネットワークに問題が絞られます。月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中でのアップグレード差額は残り日数に応じて換算されます。クライアントの古いキャッシュからプランの変更時期を判断せず、パネルの表示を基準にしてください。
よくある失敗段階を理解する
更新処理は、サブスクリプションアドレスの読み取り、ネットワークリクエストの送信、設定の受信、内容の解析、ローカル設定への書き込みという段階に分けられます。ネットワークタイムアウトが表示される場合は、現在の接続ネットワークと、クライアントがサブスクリプションへアクセスできるかを確認します。形式エラーや解析エラーの場合は、コピー内容が不完全、クライアントの種類が不一致、ローカルキャッシュが破損している可能性があります。書き込み失敗の場合は、ストレージ権限、設定ディレクトリ、システム容量を確認します。元のエラーを発生段階と対応づける方が、更新ボタンを繰り返し押すより効果的です。
古い回線がまだ接続でき、更新リクエストだけ失敗する場合は、現在利用できる回線を維持したまま更新を試します。更新リクエストが現在の振り分けルールによって誤処理されている場合は、診断のために短時間だけ接続モードを切り替えます。完了後は元の設定に戻してください。完全に接続できない場合も、通常のネットワークでユーザーパネルを開けるか確認します。実際のサブスクリプションアドレスをコマンド履歴や公開問い合わせに残さず、クライアントがURL形式を受け入れるか確認するときは明らかなダミー値を使います。
https://example.com/sub?token=YOUR_TOKEN
キャッシュを消去する前に状況を保存する
多くのクライアントは、上書き更新、再インポート、削除後の再インポートに対応しています。まずは既存の設定とログを保持できる上書き更新を選びます。上書き更新で解析に失敗し続ける場合は、機密情報を含まないエラーログをエクスポートし、独立した新しい設定を作ってインポート結果を比較します。新しい設定が正常なら、古い設定にキャッシュや手動ルールの競合がある可能性があります。新しい設定も失敗するなら、クライアントの互換性、接続ネットワーク、サブスクリプションの取得元を確認します。
エラーを記録しないまま、すべての設定を直接削除しないでください。削除すれば画面はきれいに見えますが、解析失敗、書き込み失敗、古いルールの競合のどれかを判断する材料をサポートが失います。本当にクライアントを再インストールする必要がある場合は、プラットフォーム、クライアント名、インポート方法、完全なエラーメッセージを先に記録し、ユーザーパネルからサブスクリプションを再取得できることを確認します。本サイトでは、マーケティングページ上の静的なサブスクリプションアドレスやインストールパッケージへの直リンクは提供していません。提供はすべてユーザーパネルで行われます。
更新に成功したのに回線が変わらない
クライアントに更新成功と表示されても、メモリ上の古い回線一覧を使い続ける場合があります。クライアントを完全に終了して再起動し、サブスクリプションの更新時刻と回線名を確認してください。複数の設定に対応するクライアントでは、別の同名設定ではなく、更新したサブスクリプションが現在有効になっているか確認します。設定名が同じだと誤認しやすいため、テスト用設定には一時的に区別しやすいローカル名を付けても構いません。ただし回線の内容自体は変更しないでください。
更新後に一部の回線しか表示されない場合は、クライアントでフィルター、利用不可項目の非表示、キーワードによるグループ化が有効になっていないか確認します。ローカルフィルターを無効にして比較し、回線ページに記載された地域が表示対象になっているか確認してください。EQVPNは90+か国 / 200+回線をカバーしています。具体的な一覧は現在のサブスクリプションと回線ページを基準とし、クライアントのフィルター後の件数だけでサービスの対応範囲を判断しないでください。
サブスクリプション更新について問い合わせる際は、プラットフォーム、クライアント、インポート方法、更新時のネットワーク環境、エラー全文、パネルが正常か、古い回線がまだ接続できるか、再インポートで違いがあったかを添えてください。特定の接続ネットワークでだけエラーが発生する場合は、ネットワークを変更した結果も記載します。これらの情報により、パネルからの提供、ローカル解析、権限、ネットワークアクセスの問題をすばやく区別できます。
特定のアプリだけプロキシを経由しない:通信の入口から確認する
ブラウザーは正常なのに特定のアプリだけアクセスできない場合、基礎接続はすでに確立していることが多いです。問題はアプリ独自のプロキシ設定、振り分けルール、プロトコルの種類、システムインターフェースの適用範囲にある可能性が高くなります。
アプリが本当に現在の経路を迂回しているか確認する
まず同じデバイスのブラウザーで、そのアプリに関連する公式Webサイトへアクセスし、同じネットワーク条件が必要な別サービスも確認します。ブラウザーは正常でアプリだけ失敗するなら、回線が完全に使えないわけではありません。次に、アプリにプロキシ設定が内蔵されているか、常に直接接続する設定になっていないか、起動時のシステムプロキシを読み取るかを確認します。一部のデスクトップアプリは起動時にだけネットワーク環境を読み取るため、接続確立後はアプリを完全に終了して再起動してください。ウィンドウを閉じるだけでは、バックグラウンドプロセスが残る場合があります。
コマンドラインツール、開発環境、ゲームプラットフォーム、ダウンロードツールには独自のプロキシ設定があることがよくあります。システムプロキシを有効にしてもターミナルが自動的に引き継ぐとは限らず、ターミナルに環境変数を設定してもグラフィックアプリが使うとは限りません。対象アプリがシステムプロキシ、仮想インターフェース、アプリ内プロキシのどれに属するかを明確にします。現在のクライアントモードが分からない場合は、短時間だけグローバルモードで比較します。グローバルモードで使えてルールモードで失敗するなら、重点はルールの確認です。両方で失敗するなら、アプリのプロトコルと回線の用途を確認します。
ルールの一致とドメインチェーンを確認する
現代のアプリは通常、ログイン、API、静的リソース、プッシュ通知、コンテンツ配信など複数のドメインへ接続します。メインドメインだけを回線に入れると、ログインは成功しても内容が空白になる、文字は表示されても画像が失敗する、メイン画面は使えてもアップロードがタイムアウトする、といった問題が起きます。クライアントの接続ログやルール一致の記録を確認し、失敗したリクエストがプロキシ、直接接続、拒否のどれになったかを調べます。ルールを変更するときはドメイン群として処理し、一時的な1つのアドレスだけを固定しないでください。
アプリが独自DNS、暗号化された名前解決、直接アドレス接続を使う場合、ドメインルールが想定どおり一致しないことがあります。この場合、単純なシステムプロキシの適用より、仮想インターフェースモードの方が広く対応できる場合がありますが、採用するかどうかはクライアントの機能とシステム権限を踏まえて判断します。モードを変更した後は、対象アプリを再起動して古い接続を閉じ、同じ操作で比較します。DNS、回線、ルールを同時に変更しないでください。復旧しても、どの変更が有効だったか分からなくなります。
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- MATCH,DIRECT
上記の断片はルールの順序を示すためだけのもので、ドメインは例示値です。実際の設定はクライアントとサブスクリプションが対応する形式に従い、例を完全な設定へ直接上書きしないでください。ルールは通常上から順に一致します。広範囲の直接接続ルールが対象ルールより前にあると、後続ルールが機能しません。変更前に元の設定を保存し、テスト後は他のWebサイトやローカルサービスに影響がないか確認します。
アプリのプロトコルとセキュリティポリシー
アプリによっては、通常のWebリクエストだけでなく、リアルタイム通信、プッシュ通知、長時間接続も確立します。システムプロキシがWebリクエストを対象にしていても、他の通信まで対象になるとは限りません。アプリにネットワーク診断機能がある場合は、ログイン、同期、音声、画像、更新のどの段階で失敗したかを記録します。音声や会議だけで失敗するなら、継続接続とネットワーク切り替えを確認します。更新だけで失敗するなら、ダウンロード用ドメインとバックグラウンドサービスを確認します。ログインだけで失敗する場合は、アプリキャッシュに残る地域情報やアカウントセッションも考慮します。
企業管理デバイスでは、管理ポリシーがアプリのネットワークを制限している場合があります。セキュリティソフトが新しく作成された仮想インターフェースに別のルールを適用することもあります。個人デバイスでは正常で管理対象デバイスだけ失敗する場合は、回線を何度も切り替える前にデバイス管理者へポリシーを確認してください。セキュリティソフトのログが対象アプリを明確にブロックしている場合は、通常の許可手順で通過させます。すべての保護機能を長期的に無効にすることは推奨しません。
開発ツールとAIアプリで起きやすい特殊なケース
Cursor、Copilot、コマンドラインのパッケージマネージャー、その他の開発ツールは、システムプロキシ、環境変数、エディター内部の設定をそれぞれ参照する場合があります。エディター画面でログインできても、統合ターミナルが同じ経路を使うとは限りません。ターミナルのコマンドが使えても、拡張機能ホストプロセスが設定を再読み込み済みとは限りません。エディター画面、統合ターミナル、独立したターミナルを分けてテストし、プロキシを変更した後は該当プロセスを再起動します。長時間接続やコード補完については、Cursor高速化ガイドの回線選びも参照してください。
特定のアプリだけ失敗する場合、問い合わせにはアプリ名、失敗する機能、ブラウザーとの比較結果、接続モード、ルールの一致記録、利用回線を添えてください。「このアプリは使えない」だけでは不十分です。アカウントのパスワードや完全なサブスクリプション内容も送らないでください。サポートには、リクエストが回線に入ったか、どの機能段階で失敗したかが必要です。
DNS異常:名前解決の失敗、キャッシュ、漏洩を確認する
DNSはドメイン名を接続に必要なアドレスへ変換します。名前解決に失敗すると、Webサイトが存在しない、読み込みが止まる、一部のリソースだけ欠落するといった症状が出ますが、回線を確立できない問題とは異なります。
症状から名前解決が関係しているか判断する
ブラウザーにサーバーが見つからない、ドメインを解決できないと明確に表示される場合や、コマンドラインでドメインが見つからないと返される場合は、まずDNSを確認します。ドメインからアドレスを取得できても接続がタイムアウトするなら、名前解決の段階は通過しており、プロキシ、回線、対象サービスに問題がある可能性があります。Webサイトのメインページは開けるのに画像だけ失敗する場合も、画像ドメインの名前解決異常が考えられます。アドレスバーのメインドメインだけでなく、失敗したドメインを個別にテストしてください。
まず接続を切断した状態で通常のドメインをテストし、接続後に同じテストを繰り返します。接続後だけ失敗する場合は、クライアントのDNSモードとシステムプロキシを確認します。接続前後の両方で失敗する場合は、現在の接続ネットワーク、ルーター、システムDNSを確認します。特定のドメインだけ失敗する場合は、ローカルキャッシュ、対象ドメインの状態、振り分けルールが原因かもしれません。比較時は同じデバイスと同じ接続ネットワークを使い、Wi-Fiを切り替えながら結論を出さないでください。
システムキャッシュを確認・更新する
システムとブラウザーはいずれも名前解決の結果をキャッシュします。回線やネットワーク環境が変わった後も、古いキャッシュが現在の経路に合わないアドレスを返し続ける場合があります。WindowsではシステムのDNSキャッシュを確認・更新できます。macOSとLinuxのキャッシュ管理はシステムネットワークサービスによって異なるため、基本的にはブラウザーを完全に終了し、ネットワークを切断して再接続してから再テストするのが安全です。いわゆるネットワーク修復ツールを頻繁にインストールしないでください。プロキシ、ネットワークアダプター、DNSを同時に変更し、問題の範囲を広げる可能性があります。
nslookup example.com
ipconfig /flushdns
dig example.com
利用できるコマンドはプラットフォームによって異なります。Windowsでは通常 nslookup と ipconfig、macOSとLinuxでは dig または nslookup がよく使われます。例示ドメインは本サイトの設定とは関係ありません。テストでは、「結果が返らない」「結果は返るが接続に失敗する」「ネットワークによって結果が異なる」のどれかを記録します。返されるアドレスが異なっても、それだけで異常とは限りません。コンテンツ配信サービスはネットワーク環境に応じて異なるアドレスを返すことがあります。
クライアントのDNSモードと振り分けの整合性
ルールモードでは、判断にドメイン情報が必要です。システムが先にドメインをアドレスへ解決し、クライアントがアドレスしか認識できない場合、ドメインに基づく一部のルールが一致しないことがあります。クライアントによっては拡張名前解決や仮想インターフェースによってドメインとの関連を保持しますが、具体的な機能はクライアントの実装によって異なります。ルールモードでは失敗し、グローバルモードでは正常で、ログに対象リクエストが直接接続されたと記録される場合は、DNSとルールが連携しているか確認します。単にDNSサーバーを変更するだけでは解決しません。
インターネットで見つけた公共DNSアドレスをむやみに入力しないでください。DNSサービスへの到達性、プライバシーポリシー、地域別の応答が結果に影響し、誤った選択によって現在の回線に合わないアドレスが返される可能性があります。まずはクライアントの推奨設定またはシステムの自動設定を使います。現在の名前解決に明確な失敗がある場合だけ、変更を一つに絞り、変更前後を比較します。変更後は関連アプリを再起動し、古い接続がキャッシュを使い続けないようにします。
| 症状 | 考えられる層 | 確認方法 |
|---|---|---|
| すべてのドメインを解決できない | システムDNS、接続ネットワーク、クライアントDNS | 接続を切断して通常のドメインと比較 |
| 接続後だけ失敗 | クライアントのDNSモードまたはルール | 回線を固定し、接続モードを比較 |
| 一部のリソースだけ失敗 | リソースのドメイン、キャッシュ、振り分け | 失敗したリソースのドメインを記録し、経路の一致を確認 |
| 名前解決は成功するが接続がタイムアウト | プロキシ、回線、対象サービス | 接続と回線のトラブルシューティングへ進む |
DNS漏洩と地域判定
WebツールでDNSリクエストの送信元を確認するユーザーもいます。ただし、この結果はブラウザー、システム、クライアントモード、接続ネットワークの影響を受けるため、1つの地域名だけで回線の失敗を判断できません。まず出口接続が選択した回線に合っているか確認し、次にクライアントがDNSの引き受け機能を明確に提供しているか確認します。ブラウザー内蔵の安全な名前解決がシステム設定を迂回することもあります。確認時はそのブラウザー独自の名前解決機能を一時的に無効にして比較し、完了後は自身のプライバシー要件に応じて戻してください。
複数のブラウザーで結果が異なる場合は、ブラウザー独自の名前解決設定と拡張機能を確認します。すべてのアプリで同じ異常が起きる場合は、クライアントとシステムを確認します。DNSについて問い合わせる際は、失敗したドメイン、名前解決コマンドの結果、接続前後の違い、クライアントのDNSモード、ブラウザー独自の名前解決が有効かどうか、特定の接続ネットワークだけで起きるかを添えてください。スクリーンショットに完全なサブスクリプション情報やアカウント認証情報を含めないでください。
DNSの変更が複数のアプリに影響する場合は、まずクイックスタートガイドを読み、クライアントが採用する標準的な接続方式を確認してから、局所的な変更を行ってください。確認が終わったら一時的なルールを削除し、説明と保守が可能な設定に戻します。複数回のトラブル対応で、互いに競合するDNS設定を残さないようにしてください。
デバイス数の表示、設定の競合、問い合わせ資料
EQVPNは Windows / macOS / iOS / Android / Linux に対応し、利用条件は台数無制限です。クライアントにデバイス関連の表示が出た場合は、まずそれがOS、クライアント、その他のローカルネットワークツールのどこから出ているかを確認します。
「台数無制限」とローカルリソースは別の概念
台数無制限とは、本サービスが固定のデバイス数を利用条件にしていないことを示します。ただし、複数のデバイスが同じ家庭、オフィス、モバイルネットワークを共有すると、現在の接続ネットワークの品質、無線環境、同時に実行する通信の影響を受けます。デバイスを増やした後に速度が変化した場合は、まず他のデバイスの同期、更新、動画再生を停止し、同じ回線で再テストします。ローカルの出口混雑をアカウントのデバイス制限と誤認しないでください。
クライアントにデバイス数の上限超過などの表示が出た場合は、まずその表示が現在のサブスクリプションのクライアントから出ているのか、アプリストアのアカウント、システムネットワーク設定の数、企業管理ポリシー、他のソフトウェアから出ているのかを確認します。表示の原文と出現場所を記録し、ユーザーパネルにログインしてアカウント状態を確認してください。他のデバイス設定を削除して試すのは避けてください。本サイトのサービス条件は台数無制限であり、矛盾する表示はクライアントの出所とローカル環境を合わせて判断する必要があります。
複数のデバイスで相互検証する
相互検証の目的は、どのデバイスが速いかを証明することではなく、障害の範囲を絞ることです。同じアカウント、同じ接続ネットワークで、一方のデバイスは正常でもう一方が失敗するなら、失敗したデバイスの権限、クライアントモード、システムプロキシ、セキュリティルールを確認します。同じネットワークで全デバイスが失敗するなら、別の接続ネットワークで比較します。同じデバイスで特定の回線だけ失敗するなら、回線の問題へ進みます。デバイス、ネットワーク、回線の3つの軸を一つずつ入れ替えることで、障害がどの層で止まっているか判断できます。
異なるプラットフォームで設定画面を完全に同じにする必要はありません。WindowsとmacOSでは、システムプロキシ、ターミナルの環境変数、仮想インターフェースが同時に存在しやすく、iOSとAndroidではバックグラウンド設定の影響を受けやすくなります。Linuxでは、デスクトップのネットワークマネージャー、権限、環境変数にも注意が必要です。比較するときは設定画面に同名のボタンがあるかではなく、同じ作業を完了できるかを比べます。
問い合わせ前に最小限の再現条件を整理する
有効な問い合わせは症状から始め、いつ発生したか、どの対象に影響したか、安定して再現できるかを説明します。続いて、プラットフォーム、クライアント、接続ネットワークの種類、接続モード、回線名、サブスクリプションを更新できるか、他のデバイスや回線との比較結果を記載します。最後に元のエラーメッセージと関連ログを添えます。順序の整理された資料があれば、サポートは基本環境を何度も確認することなく、すぐ判断に入れます。
上下の文脈を切り取ったエラー画面を1枚だけ送らないでください。スクリーンショットにはエラーのタイトル、発生場所、クライアントの現在の状態を残しつつ、ユーザー名、完全なサブスクリプション内容、トラブル解決に関係しない個人情報は隠します。検索にはテキストログの方が適している場合、障害の前後を含む段落をそのままコピーしてください。エラーの表現を編集したり、自分の推測で元の文字を置き換えたりしないでください。
環境
プラットフォーム、クライアント、現在の接続ネットワーク、接続モード、システムプロキシやネットワークインターフェースを変更する他のツールをインストールしているかどうか。
再現手順
正常な状態から問題が発生するまでの操作、発生した時間帯、影響を受けたWebサイト、アプリ、具体的な機能。
比較
他の回線、他のネットワーク、他のデバイスが正常かどうか、ルールモードとグローバルモードの短時間テスト結果。
証拠
元のエラーメッセージ、関連ログ、機密情報を隠したスクリーンショット、サブスクリプション更新の成否。
設定を復元し、再発を防ぐ
問題が解決したら、診断中に追加した一時的なルール、独自DNS、グローバルモードを解除し、長期的に保守できる標準設定へ戻します。たとえば、特定の接続ネットワークだけで発生した、特定のアプリはシステムプロキシを読み込むために再起動が必要だった、といった有効な変更を記録します。出所が不明で同じ名前のサブスクリプション設定を複数残さないでください。次回の更新時に、実際にどれが有効なのか分からなくなります。
ユーザーパネルから定期的にサブスクリプションを更新し、プランの変更、クライアントの再インストール、主要デバイスの変更後には、通常のWebページ、実際のアプリ、DNSを再確認します。クライアントとサブスクリプションの取得はすべてユーザーパネルを通じて行い、静的なインストールパッケージへの直リンクは使用しません。インストールとインポートの手順を確認し直す場合はクイックスタートガイドへ、対応地域と用途を比較する場合は回線ページへ、月額サブスクリプションと有効期限のない通信量パックを確認する場合は料金プランページへ進んでください。
EQVPNは30日間返金保証を提供し、支払い方法はAlipay / WeChat Pay / USDTです。返金条件と手順は返金ポリシーに従います。確認の結果、現在の利用条件が要件に合わないと分かった場合は、ポリシーページの説明に沿って手続きしてください。技術的な問題については、ユーザーパネルの問い合わせから必要な資料をまとめて送信し、複数の窓口で同じ内容を繰り返して文脈を失わないようにします。
再現条件と変数が明確なトラブル記録は、クライアントを何度も再インストールするより早く結論にたどり着けることが多いです。アカウントとサブスクリプション、クライアント、システムネットワーク、接続ネットワーク、回線、対象アプリのどこに問題があるかを確認してから、その層だけを最小限変更します。復旧後は元の作業を再テストし、一時的な設定が削除されていることを確認して、初めて一連のトラブルシューティングが完了します。