接続とトラブルシューティング

接続できない場合の段階的な確認

「接続できない」ときは、どの段階で止まるのかを確認します。クライアントが起動しない、設定が読み込まれない、接続ボタンでエラーが出る、または「接続中」のまま進まないなど、症状によって原因箇所は異なります。すべてを回線の問題と決めつけず、どこまで操作したか、画面に何が表示されたか、エラーが毎回同じかを記録してください。現在の設定名と回線名も控えたうえでクライアントを切断し、元のネットワークで普段使うサイトを開けるか確認します。基本のネットワーク接続が復旧していない状態では、接続先の回線を切り替えても原因の判断には役立ちません。

まずネットワークを確認し、次にアカウントの状態を確認

ホテル、職場、公共のWi-Fiでは、先に認証ページでの手続きが必要な場合があります。接続を切ってブラウザーを開き、ネットワーク接続用の認証ページに転送されるか確認してください。ネットワークの提供元を確認してから認証し、VPNShortのアカウントパスワードを認証ページに入力しないでください。ネットワーク自体に接続できない場合は、Wi-Fi接続、ゲートウェイ、ネットワークのメンテナンス情報を確認します。信頼できる別のネットワークでも比較できますが、テスト中は同じクライアント、設定、回線を使い、条件を一度にすべて変えないようにしてください。

基本のネットワークが正常なら、ユーザーパネルのアカウント概要でサブスクリプションの有効状態と残りの通信量を確認し、クライアントに現在のアカウントに対応する設定が読み込まれているか確認します。月額プランの通信量は利用開始日を基準に毎月リセットされ、暦月の初日を基準に計算するものではありません。通信量パックは使い切るまで有効で期限はありませんが、残量を無制限に使えるわけではありません。パネル上の状態が正常なのにクライアントに設定が表示されない場合は、サブスクリプションの項目を確認してください。設定が空のまま接続を何度も試す必要はありません。

権限の問題とリモート接続の問題を切り分ける

ネットワーク機能を初めて有効にするとき、VPN構成、ネットワーク拡張機能、仮想ネットワークインターフェースの追加許可を求められる場合があります。許可画面を閉じてもクライアントは表示されたままですが、通信経路が確立されていないことがあります。システム設定で関連する権限がブロックされていないか確認し、クライアントに戻って案内に従い再試行してください。組織が管理するデバイスでは、管理ポリシーによって権限が制御されている場合もあります。接続のために管理設定を削除せず、ネットワーク管理者に利用可能な接続方法を確認してください。

権限を許可したら、同じ地域の別の回線を試します。それでも接続できない場合は、別の地域の回線でも確認してください。VPNShortは120+か国 / 240+回線をカバーしていますが、カバー範囲が広くても、あらゆるネットワーク環境で各回線に接続できるとは限りません。特定の回線だけ失敗する場合は、回線名とエラーを記録します。すべての回線でローカルインターフェースの確立に失敗する場合は、権限やクライアントの状態を優先して確認してください。地域名だけで回線の種類を推測せず、現在の一覧に表示されている選択肢を確認します。

設定の復元とエスカレーションの判断

ほかのネットワークツールを使っていたデバイスでは、システムプロキシや仮想インターフェースが残っている場合があります。まずほかのツールを通常の方法で終了し、停止済みのローカルサービスを指すシステムプロキシが残っていないか確認してください。ネットワークインターフェースを一度にすべて削除したり、見覚えのないスクリプトを使ってシステム全体をリセットしたりしないでください。再起動が必要な場合は、作業を保存してクライアントを通常の方法で切断します。再起動後はテスト対象のツールだけを起動し、同じ段階でエラーが発生するか確認します。複数のツールを同時に動かすより、原因を特定しやすくなります。

基本のネットワークが正常で、パネルの状態も有効、設定も更新済みで権限が許可されているのに、複数の地域の回線で同様のエラーが起きる場合は、問い合わせを送信できます。OS、クライアント名、発生日時とタイムゾーン、利用ネットワークの種類、回線名、機密情報を隠したエラー文を記載してください。別のネットワークでも再現するか、接続ボタンを押した直後とインターフェース確立後のどちらで失敗するかも明記します。デバイスの管理権限が関係する場合は、まず管理者に相談してください。サポートがシステム権限を代わりに許可することはできず、アカウントの完全なパスワードを求めることもありません。

接続中なのにサイトが開かない

クライアントに「接続済み」と表示されても、通常はローカルの接続処理やトンネル状態が変化したことを示すだけです。ブラウザーのリクエストが通信経路を通ったことや、接続先のサイトが現在の出口を受け入れたことまでは意味しません。すべてのサイトが開かないのか、海外サービスだけが開かないのか、特定のサイトだけエラーになるのかを切り分けます。エラーページの文面をそのまま記録してください。名前解決エラー、接続タイムアウト、証明書の警告、アクセス拒否では、問題のある箇所が異なります。真っ白な画面だけを撮影しても、リクエストがどこで止まったのか判断しにくくなります。

比較用のリクエストで問題の範囲を特定する

クライアントを接続した状態で、普段使えるサイトと問題のある接続先サービスにそれぞれアクセスし、さらに別のブラウザーでも同じURLを試します。特定のブラウザーだけで失敗する場合は、ブラウザーのプロキシ拡張機能、安全なDNS、キャッシュを優先して確認してください。どのブラウザーでも失敗し、クライアントのログに該当リクエストがない場合は、システムプロキシが実際に有効か確認します。ログに接続先へのリクエストがあり、外向きの接続も成功している場合は、接続先サービス、アカウントの状態、アプリ自体に問題がある可能性があります。回線だけに原因を求めないようにしましょう。

システムプロキシと仮想ネットワークインターフェースは、通信を取り込む別々の方式です。システムプロキシを参照するアプリもあれば、直接接続するアプリもあります。クライアントによっては、指定したアプリだけをプロキシ経由にできます。接続に成功していても、アプリに合った通信の取り込み方式が有効でなければ、ブラウザーが元のネットワークを使い続けることがあります。クライアントの説明に従って現在のモードを確認し、システム設定に根拠のないプロキシポートを入力しないでください。ポート番号は実際に動作しているクライアントの画面で確認します。古い設定に記載されたポートが、現在も有効とは限りません。

サイト側の拒否とネットワーク障害を切り分ける

ページに地域、アカウント認証、アクセス制限に関する明確な案内が表示される場合、リクエストはサービス側に到達している可能性があります。接続先サービスの地域別ルール、アカウントの登録地域、ブラウザーのログイン状態を確認してください。ChatGPT、Claude、Gemini、動画配信サービスにはそれぞれ利用条件があり、出口を切り替えてもアカウントの利用権限を代替することはできません。拡張機能を使わないブラウザーで比較できますが、テストのために接続先サービスの本人確認や利用資格の要件を回避しないでください。

証明書エラーを、単純に回線の問題と決めつけることもできません。まずシステムの日付、時刻、タイムゾーンを確認し、特定のサイトだけで発生するかを調べてください。公共ネットワークの認証、企業ネットワークの検査、ブラウザー拡張機能、デバイスのセキュリティソフトが証明書チェーンに影響する場合があります。証明書の警告を無視してアカウントのパスワードを入力したり、提供元が不明なルート証明書をインストールしたりしないでください。管理対象デバイスの場合は、エラー表示を保存して管理者に確認します。信頼できるネットワークに切り替えると正常になる場合は、元のネットワーク環境を重点的に調べてください。

接続アイコンだけでなく、修正後の動作を確認する

設定を変更するたびに、同じテスト用URLを再読み込みし、エラーの種類が変わったか確認してください。必要に応じてブラウザーを終了して再起動し、以前の接続を閉じてから新しいリクエストを確認します。プライベートブラウジングではシステムのDNSキャッシュは自動的に消去されず、ブラウザーのネットワーク設定をすべて回避できるわけでもありません。目的は条件を減らすことであり、プライベートブラウジングを万能の修復手段として使うことではありません。復旧したら、問題と関係のない一時設定を元に戻し、管理しにくい設定の組み合わせを残さないようにしてください。

すべてのリクエストがクライアントに届いているのに特定のドメインだけ失敗し続ける場合は、問い合わせにドメイン名、エラー文、選択中の回線、ほかのサイトが使えるかを記載してください。ログイン情報を含む完全なURL、セッションCookie、ブラウザーからエクスポートしたネットワーク記録一式は送らないでください。接続先サービスからアカウント資格に関する案内が表示された場合は、そのサービスに問い合わせます。回線の範囲に関する問題は、回線一覧で選択肢を確認し、正常な回線と問題のある回線を伝えてください。

速度低下と夜間の遅延

「速度が遅い」という症状を、再現できる操作に分けて考えます。ページの表示に時間がかかる、動画がバッファリングする、ファイルのダウンロードが途切れる、AIの応答が始まらないなど、用途によって関係する要因が異なります。動画は配信拠点や画質、ウェブページは名前解決、AIへのリクエストはサービス側の待ち時間や生成時間の影響を受けることがあります。特定のアプリの待ち時間を回線全体の速度とみなしたり、接続アイコンだけで通信品質を判断したりしないでください。

比較できる条件をそろえる

まずデバイス上の大容量ファイルの同期、システム更新、ほかのダウンロードを一時停止し、同じネットワーク内で帯域を大きく使っているものがないか確認します。Wi-Fiの電波が弱い、アクセスポイントから遠い、ローカルネットワークが混雑しているといった要因で、リモート回線が遅く見えることがあります。位置を変えずに有線と無線を比較するか、同じWi-Fi環境で別のデバイスを試してください。テストでは一度に一つの条件だけ変え、接続先サービス、操作の種類、発生した時間帯を記録します。印象だけで判断しないようにしましょう。

次に接続先サービスとクライアントを変えず、現在の回線と別の回線を比較します。ブラウザー、地域、ネットワークモード、動画の画質を同時に切り替えると、復旧しても何が有効だったか分からなくなります。特定のサービスだけが遅い場合は、サービスの稼働状況やアカウントの制限を確認します。複数のサービスで同時に遅くなる場合は、回線またはローカルネットワークを調べてください。ダウンロードサイトの個別ファイルは配信元による速度制限を受けることがあるため、サービス全体の性能を判断する唯一の指標には適しません。

夜間の遅延は時間帯と通信経路を比較する

夜間の遅延は、アクセスネットワーク、国際経路、接続先プラットフォームのいずれでも発生する可能性があります。夜に起きたというだけで原因を決めつけないでください。同じ回線を異なる時間帯に使った結果を記録し、同じ時間帯に別の地域の回線も比較します。ローカルネットワークを変えると明らかに改善する場合は、元のネットワーク経路を優先して確認してください。特定の地域の回線だけに問題がある場合は、接続先サービスに適した別の出口を試します。地域間の距離を固定的な優先順位とせず、実際の利用可否と継続的な状況を基準に選んでください。

IEPL専線、中継、直結は、それぞれ異なる経路構成を表すもので、あらゆる環境で優劣が固定されるわけではありません。専線という名称でも接続先サービスへの通信が常に保証されるわけではなく、中継が直結より必ず遅いとも限りません。実際の結果は、入口への接続性、出口から接続先サービスまでの経路、現在のネットワーク状態にも左右されます。現在選択できる回線は回線一覧で確認してください。種類の表示を速度保証とみなしたり、すべての地域で全種類が利用できると推測したりしないでください。

アプリに合わせて確認し、根拠なく設定を変えない

動画がバッファリングする場合は、同じコンテンツを画質固定で再生し、再生開始だけが遅いのか、再生中も繰り返し止まるのか確認します。AIツールでは、ページの読み込み、リクエストの送信、サービス側の生成を区別してください。APIの呼び出しでは、接続確立、応答待ち、ストリーミング内容の受信も分けて確認します。ネットワークの問題を覆い隠すためにタイムアウトを際限なく延ばしたり、同じリクエストを何度も再試行したりしないでください。開発者はAI API向け回線の選び方を参考に、アプリのログとネットワークログを分けて記録できます。

問題の箇所を特定する前に、MTU、同時接続数、転送パラメーターをむやみに変更しないでください。同じ名称のパラメーターでも、クライアントによって適用範囲が異なります。不適切な変更で一部のサイトが開かなくなる場合もあります。まずデフォルト設定を維持し、問題が安定して再現することを確認してから、明確な手順に従って一項目ずつ変更し、元の値を記録してください。同じ時間帯、同じ操作で複数の回線に問題が続く場合は、タイムゾーン付きの発生日時、回線名、タスクの種類、ローカルネットワークとの比較結果を添えて問い合わせます。誇張した速度測定の結論ではなく、確認できた事実を伝えましょう。

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

切断が起きたら、通信経路自体が切れたのか、経路は残っているのにアプリの接続だけが中断したのかを区別します。クライアントの接続状態、システムのVPN表示、接続先アプリのエラーを確認し、画面ロック、ネットワーク切り替え、PCのふたを閉じる、アプリに戻る、省電力モードに入るなど、直前の操作を記録してください。毎回同じ操作の後に起きる場合は、リモート回線よりもシステムのライフサイクルやネットワーク切り替えを優先して確認します。アプリの読み込み表示だけでクライアントが終了したと判断しないでください。

ネットワークの切り替えとスリープからの復帰を確認する

デバイスがWi-Fiから別のネットワークに切り替わると、ローカルアドレスや出口の経路が変わり、既存の接続がそのまま維持されないことがあります。長時間接続するアプリではセッションの再確立が必要になり、クライアントも利用可能な入口を選び直す場合があります。ネットワークの切り替え後に自動で復旧するか確認してください。復旧しない場合は、通常の方法で切断してから再接続し、接続先アプリも開き直します。デバイスがネットワークを繰り返し検索している間に接続ボタンを連打しないでください。操作が重複し、ログの判断が難しくなります。

デスクトップ端末がスリープから復帰した後は、仮想ネットワークインターフェースとシステムプロキシの復旧順序が異なる場合があります。まず元のネットワークが再び利用できることを確認し、クライアントが接続状態を維持しているか確認してください。システムプロキシだけが残り、クライアントのサービスが復旧していない場合、ブラウザーが待ち受けていないローカルアドレスにリクエストを送ることがあります。ネットワーク設定をすべて消去するより、クライアントを通常の方法で終了して再起動するほうが適切です。復帰後に毎回問題が起きる場合は、スリープ前後の状態を記録してください。

モバイル端末のバックグラウンド権限はOSごとに確認する

Android端末では、バッテリー最適化、バックグラウンド動作の制限、メーカー独自の管理機能がネットワークサービスに影響する場合があります。システム設定で、クライアントに必要なバックグラウンド動作が許可されているか確認し、省電力モードの説明も読んでください。設定画面の項目名は端末によって異なるため、別メーカーの手順をそのまま当てはめないようにします。バックグラウンド動作の許可に、無関係な権限まで必要なわけではありません。ネットワークサービスの維持に関係する項目だけを調整し、画面ロックと復帰で動作を比較してください。

iOSのネットワーク接続はシステムが管理するため、アプリがバックグラウンドに移行したからといって、通信経路が停止したとは限りません。アプリが前面に表示されているかだけでなく、システムのVPN状態と実際のリクエストを確認してください。ほかのVPN構成、デバイス管理構成、オンデマンド接続ルールがある場合、別の構成に接続が引き継がれることがあります。プロファイルを区別せずすべて削除しないでください。管理対象デバイスでは、現在の接続方法を変更する前に管理ルールを確認します。

発生前後の情報を保存する

使用中にランダムに切断される場合は、まずデバイスとネットワークを動かさず、別の回線でも同じ現象が起きるか比較します。特定の回線だけで問題が起きる場合は、回線名と切断前後のエラーを記録してください。画面ロック後にどの回線でも切断される場合は、システムのバックグラウンド制限を重点的に確認します。アプリのログイン状態が失効した場合も切断のように見えることがあり、特に再認証を求めるページが表示される場合は注意が必要です。アプリのセッション状態を確認し、不明なポップアップにパスワードを繰り返し入力しないでください。

問い合わせでは、切断が前面表示中、バックグラウンド中、スリープ復帰後のどのタイミングで起きるか、手動での再接続が必要か、元のネットワークも同時に切れたかを説明してください。ログは最後のエラーだけでなく、発生前後の関連部分を含めてください。ログにサブスクリプションのURLやアクセス情報が含まれる場合は、先に隠します。企業管理デバイスの権限制限は管理者に確認してください。同じネットワークで特定の回線だけ切断が続く場合は、回線情報とともにサポートへ問い合わせます。

サブスクリプションのインポート・更新に失敗する

サブスクリプションリンクは、アカウントで利用できる回線設定をクライアントに取り込むためのものです。一般的なウェブサイトのURLではなく、公開して共有できる情報でもありません。更新に失敗した場合は、クライアントが内容を取得できなかったのか、取得した内容を解析できなかったのかをまず切り分けます。前者は通信経路、リンクの状態、アカウント権限が関係することがあります。後者は内容の形式やクライアントの対応状況が原因の可能性があります。現在の設定を削除してから再インポートすると、まだ使える回線も失われるため、先に設定名とエラー情報を保存してください。

パネルでサブスクリプションの取得元を確認する

ユーザーパネルにログインし、現在のアカウントとサブスクリプションの状態を確認してから、パネルに表示されたインポートまたはコピーの操作を使ってください。チャット履歴、公開投稿、見覚えのない変換サイトからサブスクリプションリンクを取得しないでください。コピー時に空白、改行、句読点が含まれていないか確認し、説明文を一緒に貼り付けないようにします。パネルにクライアントごとの入口がある場合は、現在使用しているクライアントに合った形式を選んでください。見た目が似ているだけで別の形式を使い回さないでください。

パネルにはアクセスできるのにクライアントの更新がタイムアウトする場合、サブスクリプション取得時にクライアントが別の通信経路を使っている可能性があります。クライアントによっては、現在のプロキシ経由または元のネットワーク経由で更新する設定があります。説明に従って確認してください。現在の設定が使えないのに、その同じ設定に頼って更新しようとすると、復旧できない状態に陥ることがあります。信頼できるネットワークで再試行し、ほかの設定は変えないでください。更新機能の名称はクライアントによって異なります。システム設定でプロキシアドレスをむやみに変更しないでください。

取得した内容と解析エラーを確認する

解析に失敗しても、サブスクリプションの内容自体が壊れているとは限りません。クライアントがログインページ、ネットワーク認証ページ、エラーページを取得している場合、回線設定として読み込むことはできません。エラーに形式、フィールド、認証に関する記載があるか確認し、基本ネットワークの接続認証が未完了でないか調べてください。取得した内容全体を公開フォーラムに貼り付けたり、見覚えのないオンライン解析ツールに送信したりしないでください。画面を撮影する場合はエラー表示だけにし、URLの機密部分を隠します。

クライアントがインポートに対応していても、一部のフィールドを認識できない場合は、クライアントの提供元とメンテナンス状況を確認し、ユーザーパネルのクライアント案内から現在のプラットフォームに合う選択肢を確認してください。不明なフィールドを変更して設定を無理に通さないでください。解析に成功しても、ルーティング、DNS、外向きの通信が正しいとは限りません。設定を手動で変更したことがある場合は、サービス提供の内容と自分で追加したルールを切り分け、ローカルの設定ミスをサブスクリプションの問題と誤認しないようにします。

更新後に実際に適用されている設定を確認する

「更新成功」と表示されても、クライアントの更新処理が完了したという意味にすぎません。現在有効になっている設定が更新後のものかも確認してください。デバイスに似た名前の設定が複数残っている場合、古い設定が選ばれたままだと回線一覧が期待どおりに変わりません。設定の選択、回線の選択、接続状態を確認してからテスト用サイトを開きます。手動で選んでいた古い回線が現在の一覧にない場合は、現在表示されている選択肢から選び直してください。無効になった名称を維持するために古い項目をコピーしないでください。

月額プランの通信量は利用開始日を基準に毎月リセットされ、途中でアップグレードした場合の差額は残りの日数に応じて換算されます。残量や期間に疑問がある場合は、まずパネルで状態を確認し、プランの説明を参照してください。クライアントにキャッシュされた古い表示から、現在の利用条件を判断しないでください。通信量パックは使い切るまで有効で期限はありませんが、残量を使い切った後は利用量への対応が必要です。サブスクリプションの更新はプランの状態を変更するものではなく、使い切った通信量が自動で戻ることもありません。

リンクが漏えいした疑いがある場合は、パネルに該当する操作があればリセットし、各デバイスのクライアントで新しい設定を取得してください。該当する操作が見つからない場合は、問い合わせて確認します。リセットによって既存の接続がすべて直ちに終了するとは限りません。以降の状態はパネルの案内を確認してください。取得、インポート、更新、漏えい時の対応については、サブスクリプションリンク完全ガイドもご覧ください。相談する際は、クライアント名、取得方法、エラーの種類、パネルにアクセスできるかを伝え、完全な認証情報は送らないでください。

特定のアプリだけプロキシを経由しない

同じデバイスでブラウザーは使えるのに特定のアプリが使えない場合は、サブスクリプションをすぐに切り替えるのではなく、アプリの通信が取り込まれているか確認します。アプリがシステムプロキシを参照しない場合や、独自のネットワーク設定、バックグラウンドプロセス、特定の通信方式を使う場合があります。まずアプリ名、使用した機能、エラーを記録し、アプリ全体が読み込めないのか、ログイン、画像、音声、同期など一部の機能だけが失敗するのかを説明してください。機能によって異なるドメインを使うことがあります。トップページが開けても、すべてのリクエストが同じ経路を通っているとは限りません。

リクエスト記録からルーティングの結果を確認する

クライアントで利用できる接続記録やログを開き、失敗する操作を一度だけ実行します。アプリに関連するリクエストが表示されるか、どのルールに一致したか、どの出口が使われたかを確認してください。ログに記録がない場合は、通信の取り込みモードとアプリ独自のプロキシ設定を確認します。記録はあるものの元のネットワークに向かっている場合は、ルーティングルールを確認してください。想定した出口が選択されているのに失敗する場合は、回線と接続先サービスを調べます。アプリに表示される地域や言語だけで出口を判断しないでください。アカウントの設定が反映されている可能性もあります。

ルールの順番によって、リクエストの処理結果が変わることがあります。範囲の広い直接接続ルールが先に適用されると、後続の特定ドメイン向けルールが実行されない場合があります。まず現在の設定に記載されたルールの説明を読み、クライアントが対応する上書き方法を使って調整してください。サブスクリプション本体を直接編集すると、次回の更新で変更が失われることがあります。ルールを追加する際は、確認済みのドメインまたはプロセスだけを対象にします。特定のアプリを直すために、未知のリクエストすべてを同じ出口に渡し続け、影響を確認しないままにしないでください。

システムプロキシと仮想インターフェースを別々に確認する

システムプロキシは、プロキシ設定を参照するアプリに適しています。仮想ネットワークインターフェースはより広い範囲の通信を取り込むために使われますが、追加の権限が必要なことが多く、企業VPN、ローカルネットワークのサービス、ほかの仮想インターフェースと干渉する場合もあります。有効にするかどうかは、クライアントの対応状況とデバイス環境に基づいて判断し、必須の設定とみなさないでください。テスト前に元のモードを記録し、一時的に切り替えて対象アプリを確認します。その際、ローカルネットワークのプリンターや業務サービスなど、直接接続が必要なリソースに引き続きアクセスできるかも確認してください。

アプリによっては、独立した補助プロセスからリクエストを送信します。メインアプリだけをプロセスルールに指定しても不十分な場合があります。また、起動時にプロキシ設定を読み込み、その後は自動更新しないアプリもあります。設定を変更したら、ウィンドウを閉じるだけでなく、アプリを通常の方法で終了してから再起動してください。ターミナルのプログラムは環境変数や専用設定を使う場合があり、デスクトップブラウザーとは動作が異なります。管理対象の開発環境では、プロジェクトのドキュメントを先に確認し、ほかのプロジェクトに影響する全体設定を変えないようにしてください。特定のターミナル変数をシステム全体のプロキシと混同しないでください。

サービス側の制限とルーティングの問題を切り分ける

AIツールや動画配信アプリでは、アカウントの地域、利用資格、接続元の出口に応じて機能が制限されることもあります。リクエストがプロキシ経由になっていても、すべての機能が必ず使えるとは限らず、ウェブ版とアプリ版で結果が異なる場合もあります。同じアカウントのウェブ版と比較し、サービスから明確な案内が表示されるか確認してください。診断の代わりに地域を何度も切り替えないようにしましょう。AI関連はChatGPTの高速化ガイド、動画配信関連はDisney+の地域設定と視聴の安定性も参考にし、接続先サービスの最新ルールに従ってください。

サポートに相談する場合は、失敗する機能、アプリの実行環境、現在の通信取り込みモード、機密情報を隠したルール適用記録、ブラウザーとの比較結果を伝えてください。ドメイン名は説明できますが、アクセストークンを含む完全なリクエストURLを送ったり、アプリのセッション全体をエクスポートしてアップロードしたりしないでください。アプリ独自のプロキシ設定が原因の場合は、既知の設定に戻します。組織のネットワークリソースが関係する場合は、管理者にルーティングの範囲を確認してください。修復後は一時的に有効にした全体モードを元に戻し、よく使うアプリで再確認します。

DNSの問題と名前解決の経路

DNSは、ドメイン名を接続に必要なアドレスに変換します。名前解決に失敗する、不適切な経路から得た結果が使われる、ブラウザーとクライアントで異なる方法を使うといった場合、サイトを開けなくなることがあります。DNSはネットワーク経路の一部にすぎません。ドメイン名を解決できても接続先ポートに接続できるとは限らず、解決結果が変わっても必ず異常とは限りません。エラー、リクエスト記録、アプリごとの動作を合わせて確認し、アドレスが表示されたからといってDNS設定をすべて置き換えないでください。

現在、どこで名前解決が行われているか確認する

名前解決は、システム、ブラウザー、クライアント、アプリ内で行われる場合があります。ブラウザーで安全なDNSが有効だと、システム設定がそのまま使われないことがあります。クライアントがリモートで名前解決する場合も、システムの検索結果が最終的なリクエスト経路を示すとは限りません。現在の設定を確認し、どの層で独自の名前解決が有効かを記録してから、一つずつ比較してください。システム、ブラウザー、クライアントで異なるDNS方式を同時に指定しないでください。結果の原因を判断しにくくなり、キャッシュが競合するおそれもあります。

Windowsでは、コマンドプロンプトから公開されているサンプルドメインを照会し、名前解決エラーが出るか、どのリゾルバーが使われたかを確認できます。macOSとLinuxでは、システムに該当ツールが用意されている場合、ターミナルから照会できます。以下のコマンドにアカウント情報は含まれず、ネットワーク設定も変更しません。システムの名前解決で結果が得られるかを確認するためのもので、クライアントによるリモート名前解決を完全に検証するものではありません。ツールが見つからない場合は、見覚えのないサイトから実行ファイルをダウンロードせず、システムが認める配布元またはグラフィカル画面を利用してください。

nslookup example.com

ローカルのターミナルでは成功してブラウザーで失敗する場合は、ブラウザー独自のDNS設定と拡張機能を確認します。ブラウザーでは成功し、特定のアプリだけ失敗する場合は、アプリのキャッシュや専用のネットワーク設定を確認してください。クライアントのログに利用可能なアドレスを取得できなかったと表示される場合は、現在の通信取り込みモードに合った名前解決方式が設定されているか確認します。テストドメインを個人情報を含む内部アドレスに置き換え、その結果を公開しないでください。企業内ドメインやリゾルバー情報から、業務ネットワークの構成が分かる場合があります。

経路を特定してからキャッシュを消去する

名前解決の設定を変えた後も、古いキャッシュが残って結果がすぐには変わらない場合があります。まず対象のアプリを通常の方法で再起動し、新しい接続を確立させてください。必要であれば、システムの公式手順に従って名前解決キャッシュを消去します。キャッシュを消去しても、使えなくなった回線や接続先サービスの地域ポリシーは変わりません。キャッシュの消去、ネットワークのリセット、インターフェースの削除、クライアントの再インストールを一度に行わないでください。ほかのアプリにも影響し、原因の層を特定できなくなります。

設定によっては合成アドレスへのマッピングを使い、クライアントがドメイン名と内部アドレスを関連付けます。その場合、システムで照会したアドレスが、リモートサイトの実際のパブリックアドレスとは異なることがあります。照会結果を別のデバイスにコピーしたり、hostsファイルに長期間追加したりしないでください。アドレスを手動で固定すると、必要なドメインルールが適用されず、証明書、コンテンツ配信、サイト更新に問題が起きる場合があります。以前にhostsファイルを変更した場合は、まずバックアップを取り、該当する行を確認してから、対象を明確にして変更を元に戻します。

ローカルネットワークのドメインと暗号化DNSの競合に対処する

社内ネットワーク、家庭内のデバイス、ローカルネットワークのサービスでは、ローカルのリゾルバーが必要な場合があります。すべてをリモートDNSに切り替えると、こうしたリソースを見つけられなくなることがあります。ローカルドメインに適切な経路を維持し、クライアントが対応する方法で例外を設定してください。管理対象ネットワークでは、管理者にポリシーを確認します。暗号化DNSは層を増やせばよいというものではありません。まだ確立されていないプロキシ接続にリクエストが依存しないか確認し、「DNSにはプロキシが必要だが、プロキシの入口にはDNSが必要」という循環を避けてください。

DNSに関する問い合わせでは、エラーが起きた公開ドメイン、エラー全文、OS、現在の通信取り込みモード、システムとブラウザーの照会結果が一致するかを添えてください。必要な照会部分だけを共有し、内部リゾルバー、個人のパス、サブスクリプションの認証情報は隠します。職場のネットワークだけで起きる場合は、まずネットワークポリシーを確認してください。信頼できるネットワークや複数のアプリでも再現し、特定の回線と関連する場合は、比較結果を添えてサポートに相談します。DNSの問題を理由に証明書検証を無効にしたり、見覚えのない証明書をインストールしたりしないでください。

デバイスの警告と適切な問い合わせ

VPNShortは同時に接続できるデバイス数に制限がなく、Windows / macOS / iOS / Android / Linuxに対応しています。クライアントに「デバイス数の上限を超えています」などの警告が表示されても、現在のプランにデバイス数の上限があるとすぐに判断したり、ほかのデバイスを先に削除したりしないでください。古い設定、別のアカウント、クライアント独自の機能、サードパーティ製の接続コンポーネントが原因の可能性があります。警告文と表示場所を保存し、ユーザーパネル、システムのポップアップ、クライアント内部からの応答のどれか確認してください。

まずアカウントと設定のひも付けを確認する

複数のデバイスを使っていると、似た名前の設定が残ることがあります。各デバイスで現在の設定名、取得元、アカウントの状態を確認し、以前に試した別の設定ではなく、同じ有効なサブスクリプションを使っていることを確かめてください。完全なリンクをデバイスのグループに送って比較する必要はありません。自分のパネルから設定を再取得し、各デバイス上で確認できます。特定のクライアントだけに警告が表示され、ほかのプラットフォームでは正常な場合は、アカウントを何度もリセットして解決を試みるのではなく、そのクライアントのエラー文を保存してください。

デバイス数無制限は同時接続できるデバイス数のルールを示すもので、各デバイスに別々の通信量が割り当てられるという意味ではありません。使用量と残量はパネルの表示を確認してください。同じサブスクリプションを複数のクライアントで使っていても、キャッシュされた残量を合算することはできません。すべてのデバイスで同時に使えなくなった場合は、まずプランの状態と通信量を確認します。特定のデバイスだけ使えない場合は、権限、サブスクリプション、ルーティングの項目を確認してください。月額プランと通信量パックのルールはプランページで確認できます。理由を問わない30日間の返金の具体的な手続きは、利用規約をご覧ください。

セルフチェックを切り上げて問い合わせるタイミング

基本のネットワーク、アカウントの状態、設定の更新、別の回線との比較を済ませても問題が安定して再現する場合、設定を手当たり次第に変更しても効果はほとんどありません。状況を記録してサポートに連絡するか、ユーザーパネルの問い合わせから送信してください。請求の状態、サブスクリプションの権限、サーバー側の回線に関する問題も、直接問い合わせるのが適切です。管理対象デバイスの権限、組織が設定した証明書、ローカルネットワークの認証失敗については、責任範囲を混同しないよう、それぞれの管理者に先に確認してください。

問い合わせの件名には、「デスクトップのスリープ復帰後、ブラウザーが接続できない」のように症状と範囲を書きます。「使えない」だけでは不十分です。本文では、期待する動作と実際の動作を先に説明し、再現手順、発生日時とタイムゾーン、OS、クライアント名、回線名、ネットワークの種類を記載してください。最後に、試したこととそれぞれの結果をまとめます。問題が時々しか起きない場合は、画面ロック、ネットワーク切り替え、特定の時間帯との関係を説明してください。すでに復旧している場合も、復旧直前に変更した条件を記録しておきます。

ログとスクリーンショットで隠す情報

スクリーンショットは関連するウィンドウだけを残し、アカウントのパスワード、サブスクリプションリンク全体、アクセストークン、支払いに関する個人情報、無関係なアプリの内容を隠してください。ログは問題の前後に必要な部分だけを切り出し、ブラウザーのプロファイルフォルダー全体や未確認の完全な設定ファイルを送らないでください。ドメイン名は調査に役立ちますが、クエリパラメーターを含む完全なURLに認証情報が入っている場合があります。機密パラメーターを先に削除してください。サポート用の情報を公開コメントに投稿しないでください。認証情報をすでに公開した場合は、問題の調査を続ける前に、パネルで可能な方法を使ってリセットしてください。

返答を待つ間は、再現に使える設定をできるだけ維持し、大幅な変更を続けないでください。作業を一時的に復旧させる必要がある場合は、テスト用の設定を別に保存し、変更前後の違いを記録します。サポートから確認手順が示されたら、一つずつ試して結果を伝えてください。「変わらない」だけでなく、エラーに変化があったか、影響範囲が狭まったかを説明すると、次の判断に役立ちます。明確な許可がない限り、面識のない相手にリモート操作を許可したり、見覚えのないページにアカウント情報を入力したりしないでください。安全な管理方法はアカウントとサブスクリプションリンクのセキュリティガイドをご覧ください。

復旧後の最終確認

接続が復旧したら、普段使うブラウザー、対象アプリ、ローカルネットワークのリソース、バックグラウンド動作を改めて確認し、一時的な全体モードや無関係な名前解決の変更を元に戻します。現在使っている設定が引き続き更新できることを確認してから、不要になったことが明らかな古い設定を削除してください。有効だった手順は、症状と効果があった条件を短く記録します。パスワードやサブスクリプションの認証情報は記録しないでください。次に似た症状が出たときは、前回の設定をすべて再適用するのではなく、条件を改めて確認します。デバイスを再設定する場合は、クイックスタートに戻り、案内に沿って設定してください。