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

まったく接続できないときの確認順序

「まったく接続できない」ときは、まず状況を明確にします。クライアントが起動しないのか、購読にノードがないのか、接続を押すとすぐエラーになるのか、それとも接続中のまま止まるのかを確認してください。症状ごとに問題の階層が異なるため、最初から回線を何度も切り替えると、ローカルネットワーク、システム権限、アカウント状態が混在します。まず通常のウェブサイトに直接アクセスできるかを確認し、次にクライアントが購読を読み込めるかを確認してから、具体的な回線をテストします。各段階の結果を記録し、複数の設定を同時に変更しないでください。復旧しても、どの操作が有効だったのか分からなくなります。

問題を正しい階層に分類する

クライアントの接続を切り、ブラウザーで普段利用できるウェブサイトを開きます。ここでも開けない場合、原因はローカルネットワーク、ルーター、または現在の接続環境にあり、クライアントで復旧できる問題ではありません。既知の別のネットワークに切り替えて再テストし、システムにネットワークログインページの確認を求める表示がないかも確認します。通常のウェブサイトにアクセスできる場合は、クライアントのノード一覧を開きます。一覧が空なら、購読のインポート、更新、または設定の上書きに問題がある可能性があります。一覧はあるもののすべての回線で失敗する場合は、システムプロキシ、仮想ネットワーク権限、セキュリティソフトのブロック、システム時刻を確認します。

クライアントが起動できても、コアのネットワークコンポーネントに権限が付与されているとは限りません。初回起動、システム更新、再インストール後には、VPN構成、ネットワーク拡張、仮想ネットワークアダプターの追加許可を再び求められることがあります。一度拒否すると、接続を押しても曖昧なエラーだけが表示される場合があります。システムのネットワークまたはプライバシー権限ページで該当する許可が有効か確認し、必要なら古いネットワーク構成を削除してから、ユーザーパネルで本サービスのクライアントを取得し、購読を再インポートしてください。クライアントは必ずユーザーパネルのダウンロードページから取得し、出所の不明な設定ファイルを混在させないでください。

すぐ失敗する場合と処理中のままの場合

クリック直後に失敗する場合は、リクエストが回線側に届く前に止まっている可能性があります。設定項目の不足、システム権限の未反映、クライアントコアの未起動、デバイス時刻の大きなずれ、現在のネットワークによる接続ブロックなどが考えられます。ウィンドウを閉じるだけでなく、クライアントのプロセスを終了してから再起動してください。その後、システムの日付、タイムゾーン、自動時刻合わせを確認します。証明書の検証には正確な時刻が必要です。時刻が大きくずれていると、通常のウェブ閲覧はできても、すべての回線で同時に失敗することがあります。

接続処理が長時間続く場合は、リクエストは送信されたものの完全な応答を受け取れていない可能性があります。地域と回線タイプの異なるノードに切り替えて比較してください。同じ地域で隣接した回線を連続して試すだけでは不十分です。上流経路を共有している可能性があるためです。93VPNは110か国以上 / 240以上の回線に対応しています。回線一覧で地域と種類を確認し、経路の違いが大きい回線を選んでください。別の基本ネットワークでは接続でき、元のネットワークだけで失敗する場合は、アカウントではなく、元のネットワークのルーティング、LANポリシー、接続環境を重点的に確認します。

既存設定を壊さずに基本状態へ戻す

リセットが必要な場合は、まずクライアントに表示されたエラーと選択中の回線名を保存してから、購読を更新します。更新後も失敗する場合は、本サービスの購読を削除して再インポートできますが、クライアントの設定をすべて消去することは推奨しません。ユーザーが管理しているルールまで失われる可能性があるためです。再インポート後は、カスタムスクリプトを追加せず、ポートを変更せず、ほかのネットワークツールも重ねず、クライアントのデフォルトモードでテストします。デフォルト状態で接続できたら個人設定を1つずつ戻し、接続できない場合は、エラー原文、システム、ネットワークタイプ、回線名、再現手順を問い合わせにまとめます。

「復旧」は接続スイッチが接続済みになっただけでは判断できません。接続後に通常のウェブサイトを開き、ネットワーク確認ページで出口が変わったことを確認し、以前失敗したサービスもテストしてください。接続状態が正常でもウェブサイトが開けない場合、問題は「完全に接続できない」状態から、プロキシの適用またはDNSの層へ移っています。次の章を確認し、接続ボタンを何度も押し続けないでください。

接続できるのにサイトが開かない：プロキシ適用とDNSを確認

クライアントは接続済みなのにウェブサイトが開けない場合、トンネルの状態と実際の通信経路が一致していません。よくある原因は、システムプロキシが正しく適用されていない、ブラウザーが古い接続を保持している、振り分けルールが対象ドメインを直接接続に戻している、DNSが現在の回線に適さない結果を返している、またはウェブサイトの通信プロトコルが現在のプロキシモードを通っていないことです。「接続済み」を確認の終点にせず、ドメイン名前解決、出口アドレス、各アプリの通信経路を個別に検証します。

ドメインの問題と経路全体の問題を分ける

まず種類の異なる複数のウェブサイトをテストします。すべて失敗するなら、システムプロキシと仮想ネットワークの適用を優先して確認します。一部のドメインだけ失敗するなら、ルールとDNSを確認します。ブラウザーで開いていたページは、接続前に確立したセッションを再利用している可能性があります。該当タブを閉じて開き直し、必要ならブラウザーを完全に終了してください。その後、システム標準のコマンドで公開ドメインを問い合わせ、名前解決できるか確認します。次の例は端末の名前解決が機能しているかを確認するだけで、本サービスの認証情報は含みません。

nslookup example.com

ping example.com

nslookupが結果を返しても、リゾルバーがアドレスを返したことを示すだけで、そのアドレスに現在の回線からアクセスできるとは限りません。pingに応答がなくても、それだけでウェブサイトが利用できないとは判断できません。一部のサーバーはこの種のリクエストに応答しないためです。より確実に判断するには、ブラウザーのエラー内容も確認します。サーバーが見つからない場合はDNS、接続がタイムアウトする場合はルーティングまたは回線、証明書や時刻の異常が表示される場合はシステム時刻を確認します。ページは開くのに一部のリソースだけ欠ける場合は、同じ振り分けルールに入っていないドメインがある可能性があります。

DNSキャッシュと名前解決経路を確認する

回線を切り替えた後も、システムやブラウザーが接続前にキャッシュした名前解決結果を使い続けることがあります。まずブラウザーを完全に終了し、システムのDNS更新機能を使うか、現在のネットワークを切断して再接続します。用途が分からないまま複数のパブリックDNSを同時に設定しないでください。クライアントのリモートDNS、システムDNS、ブラウザーのセキュアDNSが異なる3つの経路を作り、メインドメインはプロキシを通るのにリソースドメインはローカルの結果で直接接続することがあります。確認中は経路を1つに絞り、クライアントのデフォルトDNSを優先し、ブラウザーがシステムの名前解決を上書きする設定は一時的に無効にします。

特定のウェブサイトだけ異常な場合は、クライアントのログでそのドメインがどのルールに一致したかを確認します。直接接続に一致しているなら、クライアントをグローバル適用モードに切り替えて比較します。グローバルモードでは使えるのにルールモードでは使えない場合、修正すべきなのはルールであり、プランではありません。グローバルモードでも使えない場合は、地域と回線タイプの異なるノードを試します。複数のノードで同じドメインだけ異常が出て、ほかのサイトは正常なら、対象サービスの地域ポリシー、アカウント地域、サービス側の状態が原因の可能性があります。単純にクライアントの障害とは考えないでください。

システムプロキシの残留と競合を確認する

クライアントが異常終了すると、システムプロキシが停止済みのローカルポートを指し続け、クライアントを閉じてもウェブ閲覧できなくなることがあります。システムのネットワークプロキシページで、自動プロキシ、手動プロキシ、VPN設定が現在のクライアント状態と一致しているか確認してください。システムプロキシを変更するソフトを複数同時に動かしている場合はすべて終了し、1つのクライアントだけでテストします。閲覧が復旧してから他のツールを1つずつ起動し、どの段階で再現するかを確認します。これにより、93VPNの回線問題と、ローカルソフトによるプロキシポートの競合を切り分けられます。

ブラウザー拡張機能、システムの保護ソフト、組織のネットワーク設定も確認してください。拡張機能によってはブラウザー自身の通信だけをプロキシし、システム設定を上書きすることがあります。また、保護ポリシーが新しい仮想ネットワークインターフェースを阻止する場合もあります。確認時は拡張機能のないブラウザー環境で比較できますが、すべての保護機能を長期間無効にすることは推奨しません。組織管理下のデバイスでは、ネットワーク拡張の追加やプロキシ設定の変更が許可されているか確認してください。最終確認では、出口IP、DNS名前解決、対象ページの3つを確認します。詳しい方法はVPNが実際に機能しているか確認する方法も参照してください。

速度低下と混雑時間帯の遅延を段階的に確認

速度の問題は、まず比較条件をそろえなければなりません。「遅い」という感覚だけで判断せず、同じデバイス、同じ基本ネットワーク、同じ対象サービスで、直接接続と接続後の状態を比較します。ページの初回表示、継続的なダウンロード、動画のバッファリング、音声の揺らぎ、アップロードの不調も分けて確認してください。ページの初回表示はDNSと接続確立、継続転送は経路容量とパケットロス、音声やリモート操作は揺らぎ、アップロード異常はローカル回線の上り品質の影響を受けやすく、ボトルネックはそれぞれ異なります。

基本ネットワークとバックグラウンド通信を先に確認

クライアントを切断して基本ネットワークをテストします。直接接続自体が不安定なら、無線信号、ルーターの負荷、接続ネットワークの混雑、通信事業者の回線を優先して確認してください。テスト中はクラウド同期、システム更新、ライブ配信、大容量ファイルのダウンロードを停止し、ほかの処理が上りまたは下り帯域を使い切らないようにします。「ダウンロード速度が出ない」原因が、バックグラウンド同期による上り帯域の占有で確認パケットが遅れ、全体のスループットが下がっていることもあります。モバイルネットワークでは、信号アイコンだけでなく、位置の変化による頻繁なネットワーク切り替えも確認します。

速度テストを1回行っただけで回線を判断しないでください。速度測定サイトは距離の異なるサーバーを選ぶことがあり、実際に利用するサービスとはまったく異なる経路を使う場合もあります。より有効なのは、同じウェブページを開く、同じコンテンツを再生する、同じ開発用リソースを取得する、同じ業務システムへアクセスするといった実際の作業を繰り返すことです。対象を固定したまま、回線だけを順番に変更します。これにより、利用場面から切り離された数値ではなく、実際の使用感を比較できます。

距離・種類・用途で回線を選ぶ

通常は地理的に近い地域を選び、国際経路で不確定な区間を減らします。ただし、最寄りの回線が必ず最速とは限らず、ローカルの通信事業者から入口までのルーティングにも左右されます。近距離の直接接続が混雑時間帯に不安定なら、中継またはIEPL専線と比較してください。直接接続は経路が比較的シンプルで、ローカルネットワークから対象地域へのルーティングが良い場合に適しています。中継は追加の入口を通して一部のネットワーク間経路を最適化し、IEPL専線は経路の安定性を重視します。回線名と種類はグローバル回線ページで確認できます。

混雑時間帯の問題を有効な情報として残す方法

混雑時間帯の遅延が特定のネットワークでだけ発生する場合は、そのときの接続方式、回線の正式名称、対象サービス、具体的な症状を記録します。「速度がとても遅い」とだけ書くと、名前解決が遅いのか、接続確立が遅いのか、スループットが低下したのか、動画サービスが自動的に画質を下げたのかをサポート側で判断できません。「ページの文字は先に表示されるが画像の読み込みが続く」「再生はバッファリングするがダウンロードは正常」「リモート端末は頻繁に停止するがウェブ閲覧は正常」のように具体的に記述してください。症状が具体的であるほど、回線、プロトコル、振り分けのどの層に関係するか判断しやすくなります。

同じ時間帯に、経路の違いが大きい回線を選んで比較することも重要です。すべての回線が遅く、直接接続も同様に遅いなら、基本ネットワークに戻って確認します。ある種類の回線は安定し、別の種類だけ変動するなら、安定した種類を一時的に使い、回線に関する情報を送ってください。特定の対象サービスだけ遅い場合は、地域の選択、アカウント地域、アプリのルール、サービス側の状態を確認します。ストリーミングでは、サイトが開くことと、すべてのコンテンツの地域条件が同じであることを混同しないでください。

パネルに利用可能な通信量が正常に表示され、基本ネットワークも安定しているのに、同じ回線で複数の対象サービスに異常が続く場合は、比較結果を問い合わせに送ってください。回線を変えると問題が解消するなら、新しい回線を使い続けながら、元の回線名と発生状況を記載できます。確認の目的は、特定の回線を無理に「速い」「遅い」と断定することではなく、現在のネットワーク、地域、用途で安定する経路を見つけることです。

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

頻繁な切断では、まずどの層が切れているかを判断します。基本ネットワークの切断、デバイスのネットワーク切り替え、クライアントプロセスのシステムによる停止、トンネルの再構築、対象アプリ自身のセッションタイムアウトなどが考えられます。画面上は読み込みが続く、メッセージの更新が止まるなど似た症状でも、対処方法は異なります。最も有効なのは、切断の前後におけるネットワーク、クライアント、アプリの状態を記録することです。復旧後の正常な画面だけを保存しても十分ではありません。

固定したネットワーク環境で再現する

まず、場所と信号が安定した環境でテストし、自動的にネットワークを切り替える機能を一時的に無効にします。固定ネットワークで切断しなくなるなら、接続ネットワークの切り替えが原因である可能性が高いです。下層のアドレスが変わるとトンネルの再構築が必要になり、一部のアプリは既存の長時間接続を自動的に復旧できません。固定ネットワークでも切断する場合は、クライアントのスイッチも未接続に変わるかを確認します。スイッチが変わるならトンネルまたはクライアント層の中断、接続表示のまま特定のアプリだけ応答しないなら、アプリのセッション、振り分けルール、DNSを優先して確認します。

デバイスのスリープと復帰も重要な境目です。カバーを閉じる、画面をロックする、省電力状態に入ると、システムがネットワーク拡張を停止したり、バックグラウンド動作を制限したりすることがあります。復帰後にウェブページは表示できるのにメッセージアプリだけ新しい内容を受信しない場合、古い接続が再構築されていない可能性があります。アプリを開き直すか、一度切断して再接続してください。スリープのたびにクライアントが完全終了する場合は、回線を何度も変えるのではなく、システムのバックグラウンド権限、バッテリー最適化、自動起動設定を確認します。

モバイル端末ではなぜバックグラウンド切断が起きやすいのか

モバイルOSは、バッテリー、メモリ、バックグラウンド動作のポリシーに応じてアプリを停止することがあります。クライアントをバックグラウンドに移した後もトンネルが動作し続けるかどうかは、システムから付与されたVPN構成権限とバックグラウンドポリシーによって決まり、アプリのウィンドウが残っているかどうかとは別です。クライアントが厳しいバッテリー制限の対象になっていないか、画面ロック後もシステムステータスバーのVPN表示が残るか、無線接続からモバイル接続へ切り替えた際に自動復旧できるかを確認します。システムによって設定名が異なるため、実際のネットワーク管理とバッテリー管理ページの表示を基準にしてください。

バックグラウンドに移してしばらくしてから切断し、画面を表示したままなら安定する場合は、バックグラウンド制限を確認します。ネットワークを切り替えた瞬間に切断するなら、トンネルの再接続を確認します。対象アプリをバックグラウンドに移したときだけ内容を受信できず、ブラウザーは利用できるなら、対象アプリの通知、バックグラウンド更新、長時間接続の復旧を確認します。すべてのバックグラウンド問題を回線のせいにしないでください。回線では、OSが特定のアプリプロセスを停止することを防げません。

デスクトップのスリープ、仮想ネットワークアダプター、ソフトウェア競合

Windows、macOS、Linuxでは、スリープから復帰した後に仮想ネットワークインターフェースの番号が変わったり、準備完了まで遅延したりすることがあります。クライアントが接続済みなのに通信できない場合は、いったん切断して再接続します。それでも改善しない場合は、クライアントを完全に終了して起動し直してください。仮想マシン、コンテナ、リモートワーク用のセキュリティソフト、ほかのVPNが同時に動作していると、それぞれがルートやDNSを追加することがあります。確認中は通信経路を変更するほかのツールを停止し、93VPNクライアントだけを残します。安定した後、1つずつ有効にして競合の発生箇所を確認します。

セキュリティソフトによるブロックは、クライアントのアップグレード、システム更新、ネットワークインターフェースの変更後に、突然接続を維持できなくなる形で現れることがあります。セキュリティソフトのイベント履歴を確認し、クライアントプロセスや仮想ネットワークコンポーネントがブロックされていないか確認してください。本サービスのクライアントに、ローカルのセキュリティポリシーに沿った許可ルールを設定することはできますが、すべての保護機能を長期間無効にすることは推奨しません。組織管理下のデバイスでは、ポリシー更新後にネットワーク権限が取り消される場合もあります。この場合はデバイス管理者に確認してください。サポート側でローカルの管理ポリシーを回避することはできません。

回線切り替えと自動復旧の境界

回線を頻繁に自動切り替えしても、安定性が向上するとは限りません。アプリが長時間接続を維持している場合、出口が変わると既存セッションが無効になり、メッセージの中断、会議の再接続、ダウンロード失敗につながります。継続的な作業では、安定した回線を1つ選び、出口を変えないことを優先します。回線自体が使えないと確認できてから、手動で切り替えてください。セッションの地域を固定する必要があるサービスでは、作業中に地域を何度も変更しないことが重要です。

固定ネットワークで複数の回線が似たパターンで切断する場合は、クライアントログで切断時のエラー種類を確認し、問い合わせを送ってください。1本の回線だけ異常なら正式名称を記録して一時的に切り替えます。ネットワーク切り替えやスリープ後だけ発生するなら、システムポリシーを重点的に調整します。発生条件を切り分けると、再インストールを繰り返すより早く対処でき、再現可能なシステム動作をランダムな障害と誤認せずに済みます。

購読の更新失敗とノード一覧の異常

購読の更新では、アカウントで現在利用できる回線設定をクライアントへ渡します。更新に失敗しても、すべての回線が故障しているとは限らず、プランを再購入しなければ復旧できないわけでもありません。まず、購読アドレスを読み取れないのか、クライアントの解析に失敗したのか、古い設定が置き換わっていないのか、アカウント状態に問題があるのか、ローカルキャッシュの問題なのかを分けます。ノード一覧が空、回線名が長期間変わらない、更新時に形式エラーが出る、といった症状はそれぞれ異なる段階を示しており、同じ方法で処理できません。

まずユーザーパネルでアカウントとプランを確認する

ユーザーパネルの概要にログインし、現在のプランと通信量の状態を確認します。月額購読は¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は開通日を基準に毎月リセットされ、途中のアップグレード差額は残り日数に応じて計算されます。ほかに、期限がなく使い切るまで利用できる通信量パックとして、¥158/300GB、¥358/1000GB、¥658/3000GBがあります。パネルの状態が予想と異なる場合は、まず注文またはアカウントの問題を処理します。パネルが正常なのにクライアントの更新に失敗する場合は、購読のインポートを確認します。

登録にメールアドレスは不要で、ユーザー名とパスワードだけで登録できます。そのため、アカウントの復旧や確認では、元のユーザー名でログインしているかを先に確認してください。似たユーザー名が複数ある場合や、ブラウザーが別アカウントを保存している場合、「パネルにはプランがあるのにクライアントにはない」と誤認することがあります。購読リンクを公開チャット、スクリーンショット、文書にコピーしないでください。購読リンクは認証情報として管理します。詳しい安全対策はVPN初心者向け安全ガイドをご覧ください。

ダウンロード失敗・解析失敗・上書き失敗を見分ける

更新時にネットワークリクエストの失敗が表示される場合、クライアントが購読内容を取得できていません。まず通常のウェブサイトにアクセスできるか確認し、未接続状態で更新を試します。現在のネットワークで読み取れない場合は、別の基本ネットワークに切り替えてください。形式エラーや解析エラーが表示される場合、クライアントがログインページ、エラーページ、互換性のない内容を読み込んでいる可能性があります。購読本文を手動で編集せず、ユーザーパネルから再コピーするか、パネルのインポート入口を使い、本サービスが対応するクライアント方式を選んでください。

更新成功と表示されたのにノード一覧が変わらない場合、クライアントが古い設定を表示している、同名の別購読を更新している、現在の設定グループに切り替わっていない、といった可能性があります。購読名、更新時刻、現在有効な設定グループを確認し、重複項目を削除する前にどれが93VPN由来か確認してください。個人ルールの誤削除を避けるため、本サービスの古い購読だけを削除して再インポートし、クライアント全体のデータは消去しないでください。再インポート後はデフォルトルールで接続を確認し、正常になってから個人設定を統合します。

キャッシュ・システム時刻・証明書エラーを確認する

購読リクエストではHTTPS検証が行われます。システムの日付、タイムゾーン、証明書環境に異常があると、クライアントが購読の読み込みを拒否することがあります。まずシステムの自動時刻合わせを有効にしてクライアントを再起動し、証明書関連のエラーが残るか確認します。企業ネットワーク、公共ネットワークのログインページ、ローカルのセキュリティソフトがリクエストを書き換え、購読内容以外をクライアントに返すこともあります。別の信頼できるネットワークで比較してください。別のネットワークでは更新でき、元のネットワークではできない場合、問題は元の接続環境にあります。

キャッシュに異常がある場合は、クライアントに備わった更新または再インポート機能を優先し、内部ファイルを直接変更しないでください。キャッシュを手動で置き換えると、設定インデックスと実際の内容が一致しなくなり、その後の更新にも失敗しやすくなります。クライアントに「購読を更新」と「設定を更新」という別の入口がある場合は、本サービスの購読に対応する操作を選びます。ソフトウェアコアの更新、ルールの更新、ノード購読の更新を混同しないでください。

購読の問題で問い合わせるタイミング

パネルのプランが正常で、複数のネットワークから更新できず、同じ購読を再インポートしても失敗する場合は、問い合わせを送ってください。システム、クライアント名、エラー原文、実行した操作、ユーザーパネルを開けるか、購読一覧が空かどうかを添付します。スクリーンショットでは購読リンクやログインに使える情報を隠してください。特定のクライアントだけでエラーが起きる場合は、ほかのプラットフォームで正常かどうかも記載します。アカウント内容、ネットワーク要求、クライアント解析のどこに差があるか判断しやすくなります。

問い合わせに完全な購読アドレスを貼り付けないでください。通常、サポートに必要なのはエラー本文、プラットフォーム、ネットワーク環境、再現手順だけです。アカウント確認が必要な場合は、ログイン済みのパネルから問い合わせを開始してください。更新が復旧した後も、ノード一覧が表示されたことだけで終わらせず、実際に回線へ接続して出口を確認します。

特定のアプリだけプロキシを通らない：通信振り分けと適用モードを確認

ブラウザーは使えるのに特定のアプリだけ使えない場合、回線全体が無効なのではなく、そのアプリの通信がクライアントに入っていない、直接接続ルールに一致している、現在のモードで適用されないプロトコルを使っている、または接続前のセッションを保持している可能性があります。確認の重点を「さらに多くの回線を試す」ことから、「このアプリが実際にどの経路を使っているか確認する」ことへ移します。同じデバイスの別アプリを比較対象にし、クライアントログと適用モードを確認してください。

単一アプリの問題か、単一ドメインの問題かを確認する

同じアプリでも複数のドメインにアクセスすることがあります。メイン画面、ログイン、画像、音声、更新サービスがそれぞれ異なるアドレスを使う場合もあります。アプリにログインできるのに一部の内容だけ読み込めないなら、アプリ全体がプロキシを通っていないのではなく、リソースドメインが別のルールに一致している可能性があります。アプリが完全にネットワークへ接続できず、ブラウザーは正常な場合は、アプリ独自のプロキシ設定、システムプロキシの回避、特定のネットワークインターフェースだけを信頼する設定を確認します。ブラウザーでアプリの公式サイトを開けても、アプリ内部のリクエストが同じ経路を使うとは限りません。

アプリを終了します。ウィンドウをバックグラウンドに移すだけでは不十分です。回線に接続してからアプリを再起動し、新しいネットワークセッションを確立させます。アプリによっては起動時にネットワークインターフェースを決めるため、接続後に再起動しないと古い接続を使い続けます。再起動で復旧した場合は、セッションの再構築が原因です。それでも失敗する場合は、クライアントをルールモードから一時的にグローバル適用モードへ切り替えて比較します。グローバルモードでは使えるのにルールモードでは使えない場合はルールの一致を確認し、どちらも使えない場合は回線地域、アプリのアカウント地域、サービス側の状態を確認します。

システムプロキシ・仮想ネットワーク・アプリ内プロキシの違い

システムプロキシは、システムのプロキシ設定に従うアプリに主に影響しますが、直接接続を確立してシステムプロキシを無視するアプリもあります。仮想ネットワークによる適用は通常より広い範囲をカバーしますが、アプリ単位の設定、除外リスト、システム権限の影響を受けることがあります。アプリ内プロキシは独立した設定であり、無効なローカルアドレスが入力されていると、クライアントの通常の経路を迂回する可能性があります。確認時はアプリのネットワーク設定を一時的にデフォルトへ戻し、システムプロキシとアプリ内プロキシによる二重転送を避けてください。

推測ではなくログで実際の一致を確認する

クライアントログには通常、対象ドメイン、接続結果、選択された経路が表示されます。アプリで再現操作を1回行い、ログから該当ドメインを探してください。ドメインが直接接続に一致しているなら、対象を絞ったルールを作成できます。プロキシに一致しても接続がタイムアウトするなら、地域の異なる回線を試します。ログに関連リクエストがまったくない場合、アプリが現在の適用範囲に入っていないか、別のプロセスがリクエストを発行している可能性があります。アプリの補助プロセスとシステムのネットワーク権限も確認してください。

開発ツール、コマンドライン、コンテナ環境は、デスクトップのシステムプロキシと分離しやすい領域です。ターミナルのプロセスは起動時の環境変数だけを読み取ることがあり、コンテナには独立したネットワーク名前空間があり、仮想マシンは別のゲートウェイを使う場合があります。システムプロキシを変更した後は、ターミナルを開き直すか関連環境を再起動してからリクエストを実行します。実際の購読アドレス、アカウントパスワード、アクセストークンをコマンド履歴に書き込まないでください。教材の設定では明らかなダミー値を使います。

export HTTPS_PROXY=http://127.0.0.1:YOUR_PORT
export HTTP_PROXY=http://127.0.0.1:YOUR_PORT

curl -I https://example.com

上記のポートはプレースホルダーです。クライアント画面に表示される実際のローカルポートへ置き換えてください。ローカルプロキシポートではなく仮想ネットワークによる適用を使う場合、環境変数をそのまま記載する必要はありません。コマンドがウェブページの応答を返しても、現在のターミナル経路が使えることを示すだけで、アプリ自身の検証にはなりません。OpenAIまたはClaude APIを使う開発では、ウェブアクセスとAPI呼び出しの接続特性も分けて考えてください。詳しくは開発者向け回線選びのヒントをご覧ください。

復旧後は、クライアントを日常の用途に合うモードへ戻し、アプリのログイン、コンテンツ読み込み、継続接続を最後まで実行します。起動画面だけの確認では問題が解決したとはいえません。新しいルールを追加する場合は用途を明記し、広すぎる一致を避けます。本来直接接続すべきローカルサービスまでプロキシに送ると、新たなアクセス異常が起きる可能性があります。

デバイス数上限の表示とアカウント状態の確認

93VPNのプランは台数無制限に対応しています。そのため、「デバイス数上限」または同様の表示が出ても、プランに有限のデバイス枠が設定されていると直接判断しないでください。別のサービスやアカウントにログインしている、クライアントに古い購読が残っている、同名設定の出所が混在している、アプリ自身に設定数の制限がある、または表示が93VPNのプランではなくセッションや接続設定を指している可能性があります。まず表示の出所を確認し、アカウント対応が必要か判断します。

表示の出所と原文を確認する

表示は、OS、クライアント、アプリストアのアカウント、別の購読サービス、対象ウェブサイトから出ている可能性があります。スクリーンショットにはウィンドウタイトルと周辺の文脈を残し、「上限」という一文だけを切り取らないでください。ユーザーパネルに表示された場合は、ページと操作内容を記録します。クライアントに表示された場合は、現在の購読名を記録します。対象アプリ内だけで表示される場合は、対象サービス自身のアカウント制限であり、VPNプランのデバイス数とは無関係である可能性が高くなります。

クライアント内の購読の出所を確認することも重要です。同じクライアントに複数の購読を保存し、似た名前を付けていることがあります。現在選択中の設定が93VPNのものではなければ、表示されるエラーは本サービスのルールの対象外です。ユーザーパネルと照合して本サービスの購読名を変更し、出所が分かるようにしてください。古い設定を削除する前に必要な個人ルールを保存し、誤削除を避けます。本サービスの実際の購読はユーザーパネルからのみ取得し、検索結果や他人の共有情報で出所を判断しないでください。

アカウント・プラン・通信量を分けて確認する

パネルへのログイン時に、ユーザー名が一致しているか確認します。93VPNはメールアドレス不要で、ユーザー名とパスワードだけで登録できます。そのため、ブラウザーが別のユーザー名を自動入力すると、ページは正常に開いても異なる注文やプランが表示されることがあります。アカウント概要でプラン、注文、通信量を確認してください。月額購読の通信量は開通日を基準に毎月リセットされ、通信量パックは使い切るまで有効で期限がありません。利用可能な通信量を使い切った場合、通常は新しいデバイスを追加することで復旧するのではなく、回線が利用できない、またはアカウント状態が表示される形になります。

プランの価格と容量はプランページを基準にしてください。¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GB、通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBです。支払い方法はAlipay、WeChat、USDTに対応しています。第三者のスクリーンショット、古いキャッシュ、口頭の説明でアカウントの権利を判断しないでください。途中でアップグレードした場合、差額は残り日数に応じて計算されます。クライアント自身はこの状態を計算しないため、パネルの注文結果を基準にします。

古いセッションと重複設定を整理する

クライアントに同名の設定が複数ある場合、1つを更新しても現在有効な設定が更新されるとは限りません。現在使っている回線とルールを記録し、接続を切って、不要だと確認できた重複購読を削除してから、パネルで再インポートします。操作後は、現在の設定の出所、ノード一覧、更新時刻を確認し、購読名だけで判断しないでください。システムのネットワーク設定に古いVPN構成が複数残っている場合は、現在有効なのが本サービスのクライアントが作成した構成かどうかも確認します。

一部のシステムでは、アプリを再インストールしても古いネットワーク構成が残り、新しいクライアントの接続要求と競合することがあります。システムのVPN構成一覧で使われていない古い項目を確認して削除し、現在のクライアントから権限を再申請できます。ただし、出所を確認できる構成だけを対象にしてください。組織管理下の構成や、別の業務ソフトが作成した構成は、むやみに削除しないでください。判断できない場合は、まずスクリーンショットを保存してデバイス管理者に相談します。

プラットフォーム間の比較と問題の境界

93VPNはWindows、macOS、iOS、Android、Linuxに対応しています。同じアカウントで、あるプラットフォームは正常なのに別のプラットフォームだけ異常が表示される場合、最初に疑うべきは通常アカウントやプランではありません。2つのプラットフォームで購読の出所、クライアント権限、設定の更新時刻を比較してください。すべてのプラットフォームで同じパネル状態が表示される場合は、アカウントと注文を確認します。この比較により、サービス側のアカウント状態と単一デバイスの設定問題をすばやく切り分けられます。

問い合わせには、「表示はパネルとクライアントのどちらに出たか」「ほかのプラットフォームは正常か」「現在のユーザー名はプラン開通時と同じか」「重複購読があるか」を記載してください。サポートにパスワードや完全な購読アドレスを送る必要はありません。注文に関する場合は、パネルで確認できる注文情報と支払い方法だけを記載します。支払い方法はAlipay、WeChat、USDTに対応しています。問題が解決したら、確認のため一時作成した重複設定を削除し、出所が明確な設定を1つ残します。

サポートへ連絡するタイミングと問い合わせに添付する情報

ローカルでの確認は、ユーザーに無限の試行を求めるためではなく、合理的な範囲で問題の階層を特定するためのものです。基本ネットワークが正常で、システム権限も有効、購読状態も正常であり、異なる回線やネットワークでも安定して再現する場合は、問い合わせを送ってください。複数の回線で同じサービス側エラーが出る、パネルのプラン状態と注文が一致しない、複数のプラットフォームで購読を読み取れない、特定の回線だけ異常が続き明確な比較結果がある、といった場合も同様です。再インストールを続けても有効な情報は増えにくいでしょう。

すぐに問い合わせるべきケース

アカウントの注文、プラン状態、通信量表示、支払い結果に関するエラーは、ユーザーパネルの問い合わせ入口からサポートへ連絡してください。公開ページに注文情報を貼り付けないでください。93VPNはAlipay、WeChat、USDTに対応しています。支払いの問題を説明する際は、利用した方法、パネル上の注文状態、実際に行った操作を記載すれば十分です。返金について問い合わせる場合、サービスの返金条件は60日間の無条件返金です。具体的な申請方法と処理は返金ポリシーをご確認ください。

接続に関する問題も、次の条件なら問い合わせに適しています。通常のウェブサイトへの直接接続は正常、クライアント権限も確認済み、購読を再インポートしてもノードがない場合。経路の異なる複数の回線で接続時に同じエラーが出る場合。同じ回線で異なるネットワークから再現する場合。または、ほかの回線では正常という比較により、特定の回線の異常を明確に特定できる場合です。単一のウェブサイトだけ一時的に利用できない場合は、対象サービスの状態、地域ポリシー、DNSを先に確認し、対象サービス側の障害を回線全体の問題として報告しないでください。

診断に役立つ問い合わせに必要な情報

タイトルには症状とプラットフォームを直接記載します。たとえば「macOSで接続後にウェブサイトの名前解決ができない」「Androidでバックグラウンド中にネットワークを切り替えると自動復旧しない」のように書き、「使えない」だけにしないでください。本文では、まず発生した状況、次に実施済みの確認手順と各結果を書きます。システム、クライアント名、接続ネットワークの種類、回線の正式名称、対象アプリまたはウェブサイト、エラー原文、ほかの回線で再現するか、ほかのネットワークで再現するか、発生前にシステム更新、クライアント再インストール、ネットワーク切り替えを行ったかを含めてください。

スクリーンショットには、完全なエラーウィンドウと必要な周辺情報を含めます。ただし、ユーザー名、購読リンク、注文の機密情報、その他の認証情報は必ず隠してください。ログは障害の前後に関係する部分だけを切り取り、個人ディレクトリ、アクセストークン、他サービスの設定を含むファイル全体を公開しないでください。ログが長い場合は、実行した操作とエラーのキーワードを記載します。問い合わせにパスワードを書かないでください。ネットワーク障害の判断にパスワードは必要ありません。

問題の症状：
システム：
クライアント：
現在のネットワーク：
回線名：
対象サービス：
エラー原文：
ほかの回線での結果：
ほかのネットワークでの結果：
実施済みの確認：
安定して再現できる操作：

再現可能なテストを記録する方法

再現手順はできるだけ短くし、毎回同じ条件を保ちます。まずネットワークに干渉するほかのツールを終了し、基本ネットワークが正常であることを確認します。クライアントを開き、購読を更新して指定の回線を選択します。対象ウェブサイトを開く、アプリの内容を更新するなど、明確な操作を実行してエラーを記録します。その後、回線または基本ネットワークの変更など、1つの変数だけを変えて同じ操作を実行します。この比較により、問題が回線、ネットワーク、デバイス、アプリのどれに付随するかを判断できます。大量のランダムな操作を続けるより有効です。

時間帯が関係する場合は、発生した時間帯だけを記録し、利用率やユーザー数を自分で作らないでください。地域が関係する場合は、回線に表示された国、地域、都市を記載します。開発ツールだけで発生する場合は、使ったプロキシモードと、機密情報を除いたリクエストエラーを添付し、実際のAPIキーは送らないでください。特定のアプリだけで発生する場合は、ブラウザーやほかのアプリが正常かどうかを記載し、振り分けの範囲を判断できるようにします。

復旧後の振り返り

復旧後すぐにすべての記録を削除しないでください。まず接続スイッチ、出口IP、DNS、対象ウェブサイト、対象アプリがすべて戻ったことを確認し、実際に有効だった操作を問い合わせに記載します。回線の切り替えで解決した場合は元の回線名を残し、ルール変更で解決した場合は一致したドメインと変更理由を記録します。バックグラウンド権限で解決した場合は、システムで変更した設定を記録します。購読の再インポートで解決した場合は、古い設定が整理されていることを確認します。次回、似た問題が起きても、確認済みの境界から調査を始められます。

一時的な変更は、長期利用に適した状態へ戻してください。確認中に有効にしたグローバルモードは必要なルールモードへ戻し、一時停止したセキュリティソフトは再び有効にします。テスト用の環境変数はターミナル設定から削除し、重複購読と古いVPN構成は出所を確認して整理します。1回の障害を理由に、広すぎるルールや二重プロキシを長期間残さないでください。後から新たな競合を引き起こす可能性があります。

このページの手順でも問題を特定できない場合は、比較結果をすべて添えて問い合わせてください。93VPNは110か国以上 / 240以上の回線を提供し、Windows、macOS、iOS、Android、Linuxに対応しています。台数制限はありません。サービス情報はアカウントと回線の範囲を確認するためのものですが、具体的な障害はローカルネットワーク、システム権限、クライアント状態、対象サービスを段階的に確認する必要があります。層ごとに記録し、一度に1つの変数だけを変えることが、トラブルシューティング全体で最も重要な原則です。