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

まったく接続できない：端末側と回線側を切り分ける

クライアントを起動していない状態から確認

「接続できない」といっても、クライアントが起動しない、接続ボタンに反応がない、ノードのテストに失敗する、または特定のウェブサイトだけ開かないなど、状況はさまざまです。まず具体的な症状とエラーメッセージを記録し、VPN接続を切って、普段使うウェブサイトに端末からアクセスできるか確認してください。基本のネットワーク自体に問題がある場合は、Wi-Fiのログイン、ルーターとの接続、通信事業者側の障害を先に確認しましょう。この状態でノードを次々と切り替えても、有効な手がかりは得にくいでしょう。

公共Wi-Fiでは、利用規約に同意するために、先にブラウザーでログインが必要な場合があります。端末はWi-Fiに接続済みと表示されているのに、ブラウザーが認証ページに転送されたり、すべての通信が読み込み中のままになったりするのが典型的な症状です。ネットワーク側のログインを済ませてからクライアントを起動してください。公共Wi-Fiのログイン画面で求められた情報をVPNPutのログイン欄に入力したり、サブスクリプションのリンクをネットワーク管理画面に貼り付けたりしないでください。信頼できない接続環境では、操作を続ける前にページの提供元を確認しましょう。

設定がクライアントに読み込まれているか確認

クライアントの設定一覧を開き、空の設定、サンプル設定、別アカウントの古いファイルではなく、今回追加したVPNPutのサブスクリプションが選択されているか確認してください。ノード名が一覧に表示されていても、クライアントが設定を読み込んだことを示すだけで、サブスクリプションが有効とは限りません。続いてアカウント概要にログインし、プランの状態と残りの通信量を確認します。表示に問題がある場合は、メッセージを記録し、サブスクリプションの項目に沿って原因を調べてください。

接続スイッチをオンのまま維持できない場合は、まずシステムの権限に関する通知を確認してください。デスクトップでは、クライアントによるネットワークインターフェースの作成やプロキシ設定の変更を許可する必要がある場合があります。モバイル端末では、システムの接続設定を確認してください。権限の確認ダイアログを閉じたあとも、画面にノード名だけが残り、設定が完了したように見えることがあります。システム設定で許可の状態を確認しましょう。組織が管理する端末では、管理ルールを優先し、セキュリティ対策を勝手に無効化したり、管理設定を削除したりしないでください。

出口を切り替えるときは、回線だけを変更

クライアントのモードはそのままにして、まず同じ地域の別回線を選び、次に異なる地域の出口を試してください。同じウェブサイトにアクセスして、「すべて失敗する」のか「特定の回線だけ失敗する」のかを記録します。特定の回線だけに問題がある場合は、その経路が原因の可能性があります。すべての回線で失敗し、別のネットワーク環境では使える場合は、現在の接続ネットワークを重点的に確認してください。VPNPutは120+か国 / 220+回線に対応しています。回線の種類や選び方はノード一覧をご覧ください。

パソコンで複数のプロキシクライアントを同時に起動すると、システムプロキシや仮想ネットワークインターフェースを取り合うことがあります。使っていないクライアントを通常の手順で終了し、システムプロキシの接続先が終了済みのプログラムのままになっていないか確認してください。システムのネットワークコンポーネントをいきなり削除したり、出所の分からないリセットスクリプトをそのまま実行したりしないでください。初期設定に戻す必要がある場合は、先に現在の値をスクリーンショットで保存しましょう。企業プロキシ、開発ツール、リモートワーク用ソフトがこれらの設定を使っていることがあり、安易に消去すると別の問題につながります。

システム時刻が大きくずれていると、安全な接続の検証に失敗することがあります。日付、タイムゾーン、自動時刻設定を確認してから、クライアントを再起動し、接続し直してください。ログに証明書の検証、ハンドシェイク、設定の解析に関するエラーがあれば、そのキーワードを記録し、証明書の検証を無効にして一時的に接続する方法は避けてください。画面に表示される漠然としたエラーアイコンより、認証、設定の読み込み、リモート接続のどの段階で問題が起きたかが、診断には役立ちます。

ここまで確認して、基本のネットワークとアカウントに問題がなく、サブスクリプションも更新できるのに、複数の地域の回線で接続に失敗する場合は、サポートに問い合わせてください。クライアントがシステム接続を確立できるか、どの段階で失敗するか、接続ネットワークを変えると結果が変わるかを説明し、個人情報を伏せたログを添付します。遠隔接続で端末を保守している場合は、安易にネットワークをリセットしないでください。接続手段を失わないよう、事前に端末上での操作方法や復旧手段を用意しましょう。

接続できるのにサイトが開かない：通信経路を確認

「接続済み」でも、アクセス先への通信が成功したとは限りません

接続済みの表示は通常、クライアントがローカル転送を有効にした、または関連する通信経路を確立したことを示します。すべてのアプリがその経路を使っているとは限りません。まず、すべてのウェブサイトにアクセスできないのか、海外サイトだけに問題があるのか、特定のサイトだけなのか、サイトは開くがログインに失敗するのかを切り分けましょう。種類の異なる既知のウェブサイトを開き、ドメインを解決できない、接続がタイムアウトする、証明書の警告が出る、サイトから明確なアクセス拒否が返る、のどれに当たるか確認します。これらをひとまとめに「ネットにつながらない」と判断しないでください。

ブラウザーにプロキシサーバーへ接続できないと表示された場合は、まずクライアントが起動中か、システムプロキシが現在のクライアントを参照しているかを確認します。スリープからの復帰、プログラムの異常終了、設定の切り替え後に、システムプロキシの設定が同期されないことがあります。クライアントのシステムプロキシ切り替え機能で設定を適用し、ブラウザーを完全に終了してから開き直してください。ポートの用途が分からないまま、ネットで見つけたプロキシアドレスを手入力しないでください。誤った値を設定すると、通常のネットワークまで使えなくなることがあります。

通信振り分けモードでルールの問題を確認

クライアントが対応し、操作の意味を理解している場合は、テスト通信をすべて選択中の出口に通すモードへ一時的に切り替え、同じアクセス先を再度試す方法があります。すべての通信を出口に通すと復旧し、ルールモードでは失敗する場合は、ルールの適用、サブスクリプションルールの更新、アプリが除外されていないかを確認してください。このテストは通信経路を切り分けるためのものです。確認後は、普段の利用に適したモードに戻し、本来ローカルで使うサービスまでリモート経由にしないようにしましょう。

特定のウェブサイトだけ失敗する場合は、サイト側から地域制限、アカウント権限、リスク確認の案内が出ていないか確認してください。出口ネットワークで変わるのは接続経路であり、アクセス先サイトのアカウント資格、提供地域、利用規約を代替するものではありません。地域を切り替えたあともログインや認証ページを何度も更新するのは避けましょう。アカウントのリスク判定が強まることがあります。AIサービスの利用条件についてはAIツール特集も参考にできますが、クライアントが接続済みでも、サービスが必ず使えるとは限りません。

ブラウザー側の影響を切り分ける

別のブラウザー、または拡張機能を無効にした状態で試すと、ブラウザー拡張、キャッシュ、システムネットワークのどこに問題があるかを切り分けやすくなります。新しいセッションでは正常で、元のセッションだけ異常がある場合は、すぐにプランを変更するのではなく、プロキシ拡張、プライバシー拡張、独自のセキュリティ設定、サイトデータを確認してください。サイトデータを削除する前に、再ログインできる方法を確認しましょう。ブラウザーのデータをすべて消去したり、サイトを開くためにシステム全体のセキュリティ設定を下げたりしないでください。

ウェブサイトのトップページは開くのに、画像、ログイン用API、動画が読み込めない場合は、リソースごとに異なる経路を通っている可能性があります。現在のウェブページは複数のドメインに通信するため、ページの外枠が表示されても、依存リソースにアクセスできるとは限りません。開発者ツールに慣れている場合は、ネットワークパネルで失敗したリクエストのドメインとエラーの種類を確認してください。操作に不慣れな場合は、問題が起きたボタン、空白の箇所、エラーの位置を記録すれば十分です。スクリーンショットを共有する前に、アカウント名、個人的な内容、リクエスト内の機密パラメーターを隠してください。

すべてのブラウザーで失敗する一方、クライアントが接続済みと表示される場合は、DNSとシステムのルーティングを引き続き確認してください。ブラウザーは正常でもデスクトップアプリが失敗する場合は、アプリの項目をご覧ください。アクセス先サイト自体の一時的な障害にも注意が必要です。異なるネットワークや端末でも同じサイトで同様のエラーが出る場合、ローカルの設定を繰り返し変更する必要はありません。サイトが返したエラーメッセージを記録しておくと、サポート担当者がサイト側の応答と通信経路のエラーを区別しやすくなります。

問い合わせる場合は、アクセス先のドメイン、ページ上で行った操作、エラーの種類、ほかのウェブサイトが正常に開くかを明記してください。通常、ドメイン名だけで十分です。個人的な検索パラメーターを含む完全なURLは送らないでください。決済、本人確認、プライベートなセッションに関わるページでは、元の画面のスクリーンショットではなく、文章で状況を説明しましょう。「トップページは開くが、ログインを押すとタイムアウトする」のように正確に再現手順を伝えると、「何も開けない」より問題を特定しやすくなります。

速度低下や夜間の遅延：通信経路全体を比較

まず、何が遅いのかを明確にする

ウェブページの初回表示が遅い、ファイルのダウンロードが続けて遅い、動画が頻繁にバッファリングする、会議中に音声が途切れる、といった症状はそれぞれ異なる性能の問題です。初回表示にはDNSの名前解決や接続の確立が関係し、継続的なダウンロードは通信速度や接続先サーバーの影響を受けます。リアルタイムの音声・映像は、通信の揺らぎやパケットロスの影響を受けやすくなります。実際の使い方に合ったタスクを選んでテストしてください。ダウンロードの結果から会議の品質を推測したり、クライアントのノードテストだけで全体の使い心地を判断したりしないでください。

同じ端末、同じ接続ネットワーク、同じアクセス先を使い、異常が発生した時間帯を記録してから、出口ごとの結果を比較します。テスト中はシステムの更新、クラウドストレージの同期、ほかの大容量通信を一時停止してください。家庭内の別端末がアップロード中の場合も、応答速度に影響することがあります。Wi-Fiの電波が強くても、電波干渉がないとは限りません。可能であれば有線接続にするか、アクセスポイントの近くで再テストしてください。そのためだけに新しい機器を購入する必要はありません。

回線の種類は選ぶ際の目安であり、結果を保証するものではありません

IEPL専線、中継、直結は、それぞれ異なるネットワーク経路を表します。実際の通信品質は、端末側の接続、経由するネットワーク、アクセス先のサービスによって変わります。距離の近い出口が必ず速いとは限らず、地理的な距離が同じような回線でも経路が異なる場合があります。まずアクセス先サービスが求める地域条件を満たしてから、実際の用途で比較してください。「専線」だからどの環境でも混雑しないと考えたり、現在のネットワークで特定の直結回線の結果が良くないからといって、すべての直結回線が不適切だと判断したりしないでください。

夜間の速度低下では、時間帯との関連性を確認しましょう。昼間は同じタスクが正常なのに、夜間に複数の回線が一斉に遅くなり、接続ネットワークを変えると大きく改善する場合は、ローカルの出口や上流の共有経路が混雑している可能性があります。同じ時間帯に特定の回線だけ遅くなる場合は、その回線名を添えて報告してください。発生した時間帯とタスクの内容を記録しておくと、サポート担当者が回線のメンテナンスやアクセス先サービスの障害と照らし合わせて確認できます。

何度も切り替えるのではなく、状況を観察

出口を切り替えても、すでに確立された接続は古い経路を使い続けることがあります。動画プレーヤーもキャッシュや以前のセッションを使う場合があります。テスト中のタスクをいったん終了し、新しい出口から新たにリクエストが送られるよう、再度開いて比較してください。決済、フォームの送信、ファイルのアップロード中は回線を切り替えないでください。出口が変わるとアクセス先サービスでセッションの再認証が必要になる場合があり、切り替え前後の結果も比較しにくくなります。

ゲームやビデオ会議では、ダウンロードとは異なるネットワーク品質が重要です。操作が突然止まる、音声が途切れるといった症状では、単にダウンロード速度を上げても改善しないことがあります。まずパケットロスや端末内の通信競合を確認しましょう。指標の違いについてはレイテンシ、パケットロス、通信高速化サービスの違いをご覧ください。仕事で利用する場合はビデオ会議・共同作業ツール向けの回線選びも参考になります。

回線を変更することで特定のタスクが安定して改善する場合は、テスト画面の数値を追いかけて何度も切り替えず、利用できる出口をそのまま使ってください。どの地域の回線でも遅く、クライアントを経由しないローカルの通信も遅い場合は、基本のネットワークから確認し直しましょう。端末の過熱、プロセッサーの高負荷、ディスクへの書き込みの遅延も、ダウンロードや動画の異常につながる場合があります。システムリソースの状態を確認し、端末側のボトルネックを回線の問題と誤認しないようにしてください。

速度に関する問い合わせには、アクセス先サービス、タスクの種類、接続方法、発生した時間帯、同じ条件で試した他の回線の結果を添えてください。個人情報を伏せた速度テストのスクリーンショットを添付できますが、1回の結果をサービスの恒常的な性能とみなさないでください。比較できるテストを実施できていなくても、実際の影響を正確に説明すれば問い合わせできます。たとえば「会議の音声が途切れる」「ページの保存がタイムアウトする」といった情報は、漠然とした「速度が足りない」より役立ちます。

頻繁に切断される：発生条件を特定

通信トンネルの切断とアプリの再接続を区別

アプリに「再接続中」と表示されても、クライアントの通信経路が切断されたとは限りません。システムの接続アイコン、クライアントの状態、ほかのウェブサイトを同時に確認してください。特定のアプリだけ中断し、ほかの通信は正常なら、アクセス先サービスのセッションやアプリ自体に問題がある可能性を優先して考えます。すべての通信が止まり、クライアントが接続を再確立している場合は、端末のネットワーク変更、システムのスリープ、回線の安定性を確認しましょう。中断の範囲を明確にしてから、次の確認方法を選んでください。

切断の直前に行った操作を記録してください。たとえば、パソコンのふたを閉じた、画面を復帰させた、Wi-Fiを切り替えた、会議に参加した、別のネットワークソフトを起動した、といった操作です。一見ランダムに見える問題も、こうした操作と強く関連している場合があります。復旧後のスクリーンショットだけでなく、ログに記録された切断前後の連続した部分が重要です。クライアントにログレベルの設定がある場合は、まず初期設定のまま使ってください。詳細レベルを上げるのは、サポート担当者から明確な指示があった場合に限りましょう。機密情報や無関係な記録が増えるのを防げます。

接続ネットワークを切り替えると、既存のセッションに影響します

端末がWi-Fiから別の接続方式に切り替わると、ネットワーク上のアドレスやルーティングが変わり、既存の接続を再確立する必要があります。クライアントが自動で復旧しても、アクセス先のアプリが無効になった長時間接続を保持している場合があります。まずクライアントの状態が安定するまで待ってから、対象のアプリを開き直してください。ネットワークの切り替えが完了する前に、接続ボタンを何度も押さないでください。切り替えのたびに復旧できない場合は、システムとクライアントの情報を記録し、自動接続やネットワーク変更に関連する設定を確認します。

デスクトップ端末がスリープすると、システムがネットワークインターフェースを一時停止する場合があります。また、クライアントの復帰がブラウザーやメッセージアプリより遅れることもあります。そのため、復帰直後に短時間アクセスできなくても、すぐにリモート回線の障害と判断しないでください。端末をスリープさせない場合にも切断が起きるか比較し、省電力設定を確認しましょう。長時間のタスクでは、端末の安全要件に沿った電源設定を使用し、省電力機能やセキュリティ機能をすべて無効にすることは避けてください。

元に戻せる設定の範囲を保つ

複数のネットワークツールが同時に有効だと、システムプロキシ、仮想インターフェース、ルーティングが繰り返し変更される場合があります。クライアントには接続済みと表示されていても、別のプログラムが通信を引き継いでいることがあります。また、プログラムを終了した後に無効なプロキシ設定が残る場合もあります。不要なツールを順番に終了し、現在どのクライアントがネットワークを管理しているかを確認してから再接続してください。ネットワーク全体を制御するツールを複数同時に有効にして「高速化を重ねる」のは避けましょう。安定性が向上するどころか、競合が増える可能性があります。

特定の出口だけで切断される場合は、クライアントと接続方法を変えずに、別の地域または種類の回線で引き続き確認してください。回線を変更して問題が解消した場合は、利用可能な回線を使い、問題が起きた回線名、時間帯、発生時のタスクを報告します。回線を変えても改善せず、接続ネットワークを変えると改善する場合は、ローカルのルーター、Wi-Fiの通信範囲、通信事業者の経路を重点的に確認してください。たまたま一度復旧しただけで、問題が完全に解消したと判断しないでください。

長時間アイドル状態のあとに切断される場合と、使い続けている最中に切断される場合は、分けて報告してください。前者には、システムの省電力機能、ネットワーク機器によるセッションの終了、アクセス先アプリのアイドル時の動作が関係している場合があります。後者では、Wi-Fiの干渉、負荷、通信経路の変化をより詳しく確認する必要があります。接続が復旧したら、アクセス先アプリで再ログインやタスクの再実行が必要かを確認してください。ファイルのアップロード、リモート端末、会議のセッションは、クライアントの状態が戻っただけでは自動的に再開できないことがあります。

切断が繰り返されても、まずクライアントを再インストールするのは避けてください。再インストールすると、最も重要なログが消え、自動接続、ルール、権限も別の状態になる可能性があります。まず認証情報を含まない診断情報をエクスポートし、現在の設定を記録してから、更新や再設定を検討しましょう。クライアントをユーザーパネル以外から入手した場合は、問題を解決するために不明な改変版を使うのではなく、クライアントのダウンロードページで入手先を確認してください。

サポートが必要な場合は、切断がスリープ、ネットワークの切り替え、アイドル状態、特定のアプリと関連しているか、自動で復旧するかを伝えてください。「ネットワークを切り替えるとクライアントは復旧するが、会議には入り直す必要がある」のように説明すると、「よく切れる」より正確です。システムエラー、ネットワークインターフェースの消失、端末の予期しない再起動を伴う場合は、OSやハードウェアの問題も確認してください。回線のサポートで端末自体の保守を代替することはできません。

サブスクリプションを更新できない：リンクとアカウントを分けて確認

サブスクリプションの更新でできること

サブスクリプションのリンクを使うと、クライアントがアカウントに対応した設定と回線一覧を取得できます。更新に成功したということは、クライアントが読み込み可能な設定を取得したことを示しますが、すべてのウェブサイトにアクセスできることを意味しません。更新に失敗しても、現在の回線がすべて使えないとは限りません。まず現在の設定で接続できるか確認し、次に更新時に返されたエラーを確認してください。設定の取得と回線の利用を分けて考えると、ネットワークがまだ使えるのに、すべてのノードを誤って削除することを防げます。

VPNPutのユーザーパネルにログインし、アカウント概要でサブスクリプションの入手先を確認してください。チャット履歴に残った古いリンク、他人から転送された設定、不明なガイドに付属するサブスクリプションは使わないでください。コピーする際はパネルの案内を使い、クリップボードの内容がすべて含まれているか、前後に空白、改行、説明文が混ざっていないかを確認しましょう。サブスクリプションはアカウントへのアクセス情報です。公開フォーラム、オンライン変換ツール、公開コードリポジトリに貼り付けて確認しないでください。

エラーの種類に応じて原因を確認

接続できない、またはリクエストがタイムアウトする場合は、まずサブスクリプションの取得に使ったネットワーク経路を確認してください。クライアントによっては、現在のプロキシを経由してサブスクリプションを更新するため、現在の設定が使えないと循環して失敗することがあります。クライアントに更新時のプロキシ選択機能がある場合は、用途を理解したうえで比較テストしてください。サブスクリプションのドメインをむやみに変更したり、安全な接続を示す先頭部分を削除したり、証明書の検証を無効にしたりして解決しようとしないでください。

設定ではなくウェブページの内容が返ってくる場合は、パネルのページURLをコピーした、ネットワークのログインページに応答を置き換えられた、またはクライアントがエラーページを取得した可能性があります。形式を解析できないというエラーが明確に表示された場合は、ファイルのインポートや別形式の設定ではなく、サブスクリプションに適したインポート方法か確認してください。クライアントによって設定の文法が異なるため、あるツールで読み込めた内容が、すべてのプラットフォームに対応するとは限りません。

アカウントの有効期限切れ、通信量の状態、サブスクリプションのリセットも、設定の取得に影響する可能性があります。クライアントに残っている古いノード名ではなく、パネルの状態とエラーメッセージを確認してください。月額サブスクリプションの通信量は利用開始日を基準に毎月リセットされます。追加のデータパックは使い切るまで有効で、期限はありません。料金と請求の詳細はプラン一覧をご覧ください。支払い後もパネルの状態が想定どおりでない場合は、注文の状態を記録して問い合わせてください。

修復する際は、元の設定を残す

現在使えている設定を直接上書きせず、まず新しい設定を追加してテストすることをおすすめします。新しい設定に期待する回線が表示され、接続でき、ルールも意図どおりに動作することを確認してから、古い設定を整理してください。クライアントで置き換えしかできない場合は、先に内蔵のバックアップ機能を使い、バックアップファイルを安全に保管しましょう。バックアップにサブスクリプションのURLやアカウント情報が含まれる場合もあります。公開クラウドストレージに安易にアップロードしたり、他人と共有したりしないでください。

更新に成功しても回線一覧が変わらない場合は、一覧を変更する必要がないか、クライアントが別の設定を表示している可能性があります。何度もインポートし直すのではなく、現在の設定名、有効状態、更新結果を確認してください。似た設定を誤って複数追加した場合は、まず入手元を確認し、実際に有効な設定を特定してから、不要な項目を削除しましょう。設定名は整理できますが、サブスクリプションキーを名前やスクリーンショットのタイトルに含めないでください。

更新の頻度は、パネルの案内、回線の変更、実際の利用状況に応じて決めましょう。クライアントを開くたびに更新する必要はありません。自動更新の設定が使えるか、どのように実行されるかは、クライアントとシステムのバックグラウンド動作によって異なります。取得、インポート、リセットの関係を詳しく知りたい場合はサブスクリプションリンク完全ガイドをご覧ください。初めて追加する場合は使い方ガイドに戻り、手順に沿って進めてください。

更新に失敗した場合の問い合わせには、クライアント名、プラットフォーム、インポート方法、エラーメッセージ、パネル上のアカウント状態、既存の回線が使えるかどうかを記載してください。サブスクリプションの完全なURLは、問い合わせ内容やログのスクリーンショットに含めないでください。サポート担当者がアカウントの確認を求める場合は、ログイン済みの問い合わせ窓口で必要最小限の情報を伝えます。通常の診断情報として、ユーザー名、パスワード、サブスクリプションの認証情報を一緒に送らないでください。

アプリがプロキシを使わない・モバイル端末でバックグラウンド切断

アプリによってネットワークへの接続方法が異なる

ブラウザーは使えるのに特定のアプリが使えない場合は、そのアプリがシステムプロキシを参照するか確認してください。システムプロキシは通常、該当する設定を読み込むプログラムに影響しますが、すべてのプロセスに自動で適用されるわけではありません。アプリによっては独自のプロキシ設定があり、クライアントが提供する、より広範囲なネットワーク制御モードが必要な場合もあります。現在のクライアントと対象アプリの設定説明を確認してから、適切な方法を選んでください。ブラウザーが正常だからといって、すべてのアプリが同じ出口を使っているとは限りません。

クライアントが仮想ネットワークインターフェースモードに対応している場合、追加のシステム権限が必要になったり、組織のネットワークツールやほかのネットワーク拡張機能と競合したりすることがあります。有効にする前に現在の設定を保存し、元のモードに戻せることを確認してから、同じアプリでテストしてください。対象アプリに独自のプロキシ設定がある場合は、互いに矛盾するアドレスを同時に設定しないようにしましょう。組織が管理する端末では管理ルールに従い、必要に応じて管理者に相談してください。端末のポリシーを回避しないでください。

通信振り分けルールがアプリの通信先をカバーしているか確認

アプリのログイン、コンテンツの読み込み、ファイルのアップロード、通知では、それぞれ異なるドメインへ通信することがあります。メインのドメインがプロキシ経由でも、関連するすべてのリクエストに同じルールが適用されるとは限りません。クライアントの接続ログで、失敗したリクエストが直結とプロキシのどちらのルールに適用されたかを確認し、ルールの更新が必要か判断してください。見慣れないドメインをすべてプロキシのリストに追加するのは避けましょう。ローカルサービス、更新確認、障害と無関係なリクエストが含まれている可能性があります。

モードや出口を切り替えたあと、古い接続が以前の経路を使い続けないよう、対象アプリを完全に終了してから開き直してください。ファイルのアップロード、通話、コンテンツの送信中は、先にタスクを終了しましょう。アプリに地域やアカウントに関する案内が引き続き表示される場合は、アクセス先サービスの利用条件を確認してください。ネットワークの制御ではアカウントの利用資格は変わりません。通知の遅延については、システムのプッシュ通知やバックグラウンド処理も考慮が必要です。通知の到着時刻だけで回線の接続状態を判断しないでください。

画面ロック後の異常はシステムの処理を確認

モバイル端末では、画面ロック後にシステムがバックグラウンド動作を制限したり、接続ネットワークを切り替えたり、アプリのプロセスを終了したりする場合があります。まず画面を点灯した状態では正常に動作するかを比較し、ロック後にクライアントの接続状態が実際に消えるか確認してください。Androidでは、クライアントのバッテリー最適化、バックグラウンド動作、ネットワーク権限を確認します。メニュー名は端末によって異なるため、システムの説明に沿って操作してください。問題の切り分けのために、すべてのアプリへ一律にバックグラウンド動作を許可しないでください。

iOSでは、クライアントが最近使ったアプリの一覧に残っているかではなく、システムの接続状態で通信経路の有無を確認してください。Wi-Fiの切り替え、画面の復帰、別のネットワーク設定の利用後に接続状態が異常になった場合は、まず再接続し、同じ問題を繰り返し再現できるか観察しましょう。システム設定を何度も削除しないでください。元の許可状態や診断の手がかりを失うことがあります。ほかのネットワークツールがインストールされている場合は、実際に有効になっている設定を確認してください。

特定のアプリだけがバックグラウンドで失敗し、前面に戻すと正常になる場合は、そのアプリのバックグラウンド権限とシステムのデータ節約設定も確認してください。クライアントの通信経路が正常でも、対象アプリのバックグラウンド動作が許可されているとは限りません。逆に、画面ロック後にすべてのアプリで通信できなくなる場合は、クライアントのプロセス、システムの接続状態、接続ネットワークを優先的に確認してください。この2つの原因を分けて考えると、アプリの問題なのにサブスクリプションを何度も再設定する事態を防げます。

問い合わせには、アプリ名、前面とバックグラウンドでの違い、画面ロックやネットワーク切り替えがきっかけか、復旧時にクライアントの再接続が必要かを記載してください。システムの権限設定を示すスクリーンショットを添付する場合は、ほかのアプリや個人情報を隠しましょう。組織のソフトウェアや業務上の個人情報に関わる問題では、ネットワーク上の症状と必要なドメインだけを伝えてください。サポート担当者が業務画面の全体を見る必要は通常なく、対象アプリのログイン情報も必要ありません。

DNSの異常：名前解決と出口の経路を確認

名前解決の問題と接続エラーを切り分ける

DNSはドメイン名を接続に必要なアドレスへ変換する仕組みです。ブラウザーにドメインを解決できないと表示される場合、通常はアクセス先サービスにリクエストが届く前の段階で問題が起きています。接続がタイムアウトする場合は、アドレスを取得した後の通信経路で失敗している可能性があります。ウェブページが空白というだけでDNSの問題と決めつけないでください。まずエラーメッセージを保存し、複数のドメインで同じ問題が起きるか、クライアントの接続を切った場合と有効にした場合で結果が異なるかを比較します。

デスクトップでは、システムツールを使って名前解決の結果を確認できます。次のコマンドは、サンプル用のドメインを照会します。アカウント情報は含まれず、ネットワークの自動修復も行いません。コマンドが成功しても、現在の照会で応答を取得できたことを示すだけで、対象サイトのコンテンツが使えるとは限りません。コマンドに失敗した場合も、ネットワーク環境、システムのポリシー、ツールが利用可能かどうかを併せて確認する必要があります。ウェブサイトから取得したアドレスを長期利用する設定に直接書き込まないでください。

nslookup example.com

システムによっては、別の名前解決ツールも用意されています。ただし、コマンドラインツール、ブラウザー、クライアントが同じ経路で名前解決するとは限りません。ブラウザーでセキュアDNSが有効になっていたり、クライアントがプロキシ経由のリクエストに対して別の方法でドメインを処理したり、システムキャッシュに古い結果が残ったりする場合があります。比較する前に、どのレイヤーの状態を確認しているかを明確にしましょう。ツールの出力は手がかりとして扱い、ブラウザーの実際のアクセス経路と同じだと決めつけないでください。

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

特定のブラウザーだけでドメインのエラーが発生する場合は、セキュアDNSとプロキシ拡張機能の設定を確認してください。企業や学校のネットワークでは指定の名前解決ポリシーがある場合があるため、ネットで勧められているアドレスに勝手に変更しないでください。比較のために、ブラウザーの元の設定またはシステムの初期設定に一時的に戻し、変更前の状態を記録できます。特定の出口だけで問題が起きる場合は、DNSサーバーを複数同時に変更するより、ブラウザーの設定を変えずに回線を切り替えてテストするほうが原因を特定しやすくなります。

クライアントにリモートDNS、ドメインの通信振り分け、仮想アドレスに関する設定がある場合は、サブスクリプションの初期設定を維持してください。モードによって、ドメインを出口へ渡す方法や、アプリに表示されるアドレス形式が変わります。パラメーターの意味が分からない場合は、別のクライアント向けガイドから設定例をコピーしないでください。特に、不明なDNSアドレスやルールを現在のサブスクリプションに追加するのは避けましょう。設定の文法が正しくても、現在のルーティングとの互換性があるとは限りません。

キャッシュ、暗号化された名前解決、ローカルリソース

名前解決の方法を変更した後も、古い接続やキャッシュが結果に影響する場合があります。まず対象のアプリを完全に終了し、クライアントを再接続してから再テストしてください。必要な場合に限り、システムの公式な手順に沿ってキャッシュを削除しましょう。出所不明のネットワークリセットコマンドを続けて実行しないでください。端末が社内ドメイン、プリンター、業務ネットワークに依存している場合は、削除や設定変更の前に復旧方法を確認してください。海外のウェブサイトが開くようになっても、ローカルのリソースにアクセスできなくなる可能性があります。

DNSリークで確認するのは、ウェブページに表示される出口アドレスだけではなく、名前解決のリクエストが想定した経路を通っているかどうかです。ブラウザーの通信とシステムの名前解決は異なる仕組みを使う場合があり、1つのウェブサイトの検査結果で分かるのは、一部の状態に限られます。まず自分のIPアドレスで現在の出口を確認し、クライアントの設定や名前解決の結果と併せて判断してください。出口情報だけでプライバシー全体を確認することはできません。

匿名性とログを保存しないことは、VPNPutがサービスのプライバシーについて掲げている説明です。ただし、ブラウザー拡張機能、アクセス先サイト、端末上のほかのソフトウェアがデータを処理しないという意味ではありません。DNSの問題を調べる際も、この点を区別してください。回線サービスと端末全体のプライバシーは同じではありません。サービスの説明と情報の最小化について詳しくはログを保存しないという説明の確認ガイドとプライバシーポリシーをご覧ください。

名前解決の結果が返ってきても、証明書の警告が表示された場合は、サイトを開き続けたり検証を無効にしたりしないでください。システム時刻、公共Wi-Fiのログイン状態、ドメイン名が正しいか確認し、必要に応じて別の接続ネットワークで再テストします。証明書の異常は、ネットワークによるリダイレクトやアクセス先サービスの設定が関係している可能性があり、DNSを変えるだけでは原因を判断できません。特にログインや決済のページでは、安全な接続を確認してからアカウント情報を入力してください。

DNSの問い合わせには、失敗したドメイン、ブラウザーのエラー、クライアントのモード、ブラウザー独自の名前解決を有効にしているかを記載し、個人情報を伏せたコマンド出力を添付してください。出力にはローカルネットワーク名、DNSサーバー、内部アドレスが含まれる場合があります。共有前に内容を確認しましょう。サポート担当者が必要とするのは、変更前後の比較とエラーの種類です。システムのネットワーク情報一式を送る必要はありません。社内ネットワークのドメインだけで問題が起きる場合は、ネットワーク管理者にも相談してください。

デバイスの警告、アカウントの状態、問い合わせ情報のまとめ方

デバイス数の上限表示がプランの制限とは限りません

VPNPutは同時接続台数無制限です。クライアントにデバイス数の上限が表示された場合は、まずその表示がどこから出ているか確認してください。サードパーティ製クライアントのアカウントシステム、アクセス先サイトのデバイス管理、別のサブスクリプションによるもので、VPNPutのプランとは関係がない場合があります。表示を見てすぐにほかの端末を削除したり、原因が分からない制限を解除するために再度支払ったりしないでください。現在の設定とログイン中のアカウントを確認し、どの画面がエラーを出しているのか特定しましょう。

台数無制限でも、アカウントやサブスクリプションを誰でも閲覧できる状態で共有してよいわけではありません。端末が増えるほど、古い設定、誤ったパスワード、漏えいしたリンクの管理が難しくなります。複数の端末で同時に通信すると、アカウントの通信量も共通で消費します。端末を交換したり紛失したりした場合は、サブスクリプションやログイン状態が残っていないか確認してください。認証情報が漏えいした可能性がある場合は、パネルで利用できる管理方法に沿って対応しましょう。アカウントの安全管理についてはアカウントとサブスクリプションの管理ガイドをご覧ください。

料金の問題とネットワークの問題を切り分ける

アカウントを利用できない場合は、決済アプリの引き落とし通知だけを見るのではなく、注文、プランの有効状態、通信量を確認してください。決済の完了とパネル上の注文確認は別の段階です。状態が一致しない場合は、ログイン済みの問い合わせ窓口から確認を依頼してください。VPNPutはAlipay / WeChat Pay / USDTに対応しています。確認のために決済画面を添付する場合は、対象の注文に関係のないアカウント情報や取引情報を隠してください。決済パスワードや個人の取引明細全体は送らないでください。

プランは実際の通信量に合わせて選んでください。月額プランは¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は利用開始日を基準に毎月リセットされます。途中で上位プランに変更する場合は、差額を残り日数に応じて換算します。データパックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効です。期限はありません。詳しい比較はプラン一覧をご覧ください。プラン変更を、すべての接続トラブルに対する一般的な解決策と考えないでください。

スクリーンショットを増やすのではなく、再現できる情報をまとめる

まず、期待する結果と実際に起きたことを一文で説明し、発生時の環境、操作手順、エラーメッセージ、すでに行った比較を添えてください。たとえば、基本のネットワークは正常でサブスクリプションも更新できるが、特定の出口から特定のドメインにアクセスするとタイムアウトし、別の出口では使える、といった説明です。これだけでも問題の範囲を絞り込めます。すべてのテストを実施できていない場合も、実際の状況をそのまま伝えてください。問い合わせのために何度も再インストールしたり、理解していないパラメーターを変更したりする必要はありません。

症状：
期待する結果と実際の結果：
発生した時間帯とタイムゾーン：
システムとクライアント：
接続方法：
現在の回線と接続モード：
再現手順：
ほかの回線またはネットワークでの比較結果：
エラーメッセージ：
試した操作：
添付ファイル：個人情報を伏せたスクリーンショットまたは関連ログ

ログの一部を添付する場合は、障害の前後に関連するイベントを含め、順序と時間の関係が分かるようにしてください。最後の「失敗」という1行だけでは、実際の原因となった上流のエラーを見落とすことがあります。一方、長期間分のログ全体をアップロードすると、個人のドメインやアカウント情報が混ざりやすくなります。送信前にユーザー名、サブスクリプションのアドレス、認証情報、プライベートなページの内容を検索してください。機密部分を隠しつつ、エラーの種類は残しましょう。回線名、エラーが発生した段階、時間をすべて消してしまうと、診断に必要な情報まで失われます。

次のような場合は、サポートへの問い合わせをご検討ください。パネルの状態が完了済みの注文と一致しない、異なるネットワークでもサブスクリプションを取得できない、基本のネットワークが正常なのに複数地域の回線で接続に失敗する、このページの手順で確認しても原因を特定できない場合です。問題がアクセス先サイトのアカウント資格、組織のネットワークポリシー、端末のハードウェアに限られる場合は、該当するサービス提供元や管理者にも確認してください。問い合わせでは問題の範囲を切り分けられますが、第三者によるアカウント審査や端末の保守に代わるものではありません。

返金とトラブルの診断は別の手続きです。VPNPutは30日間の無条件返金に対応しています。詳しい条件は利用規約をご覧ください。返金を希望する場合は、パネルの問い合わせで希望を明確に伝えてください。長いログの中に返金の申請を埋もれさせる必要はありません。引き続き問題の切り分けを希望する場合は、再現できる症状を先に伝えることもできます。テスト結果を待つ間も、必要なアカウント上の手続きを後回しにしないでください。注文の処理状況はパネルの記録に基づきます。

案内を受け取ったら、元の設定を残しながら項目ごとに試し、それぞれの結果を返信してください。問題が解消した後は、普段使うルールモード、ローカルリソース、よく使うアプリが正常に動作することを確認し、最後に不要なテスト設定を整理しましょう。診断の目的は、特定のウェブサイトを一時的に開けるようにするだけではありません。内容を把握でき、元に戻せる利用環境を維持することも大切です。似た症状が再発した場合、これまでの比較記録を使えば、同じ問題かどうかをより早く判断できます。