接続とトラブル · ガイド

VPNのトラブルシューティング完全ガイド

症状から原因を切り分けます。ネットワーク、クライアント、接続先を確認してから、変更する設定を決めましょう。

初めて利用する場合は、まず使い方ガイドに沿ってインストール、サブスクリプションの取得、接続確認を行ってください。このページでは、基本設定が済んでいるのに問題が起きた場合の確認手順を説明します。接続が復旧したら、使い方ガイドで通常の利用手順も確認できます。接続先、ルール、DNSを同時に変更すると、どの変更が有効だったのか判断しにくくなるため、一度に変更するのは一つにしましょう。

接続できないとき:まず失敗箇所を特定する

「接続できない」といっても、クライアントが起動しない、接続ボタンを押しても反応しない、接続中の表示から進まないなど、症状はさまざまです。発生箇所が違えば対処方法も異なります。画面に表示されたメッセージをそのまま記録し、クライアントの起動時、設定の読み込み時、接続の確立時、サイトを開いた後のどこで失敗したかを確認しましょう。「使えない」とだけ記録しても、アカウントとネットワークのどちらに問題があるのか切り分けられず、同じ確認を繰り返すことになります。

プロキシを使わない状態でネットワークを確認

まずクライアントを切断し、普段使っている日本国内のサイトが開くか確認します。この状態でもアクセスできない場合は、ネットワークに接続されているか、ブラウザーでネットワーク認証が必要か、ルーターが正常に動作しているかを確認してください。公衆ネットワークでは認証ページが自動で表示されないことがあります。ネットワーク提供元の接続手続きを済ませてからプロキシを起動しましょう。クライアントが起動中と表示されても、基本のネットワークが使えるとは限りません。

可能であれば、端末、クライアント、設定を変えずに、別のネットワークから接続してみてください。ネットワークを変えると復旧する場合は、サブスクリプション自体より、元の接続経路に問題がある可能性が高くなります。どのネットワークでも失敗する場合は、同じアカウントを別の端末でも確認しましょう。こうした比較により、ネットワークに起因する問題と端末に起因する問題を切り分けられます。ソフトウェアを何度も再インストールする必要はありません。

システムの日付、時刻、タイムゾーンが正しいか確認し、必要に応じて自動時刻設定を有効にします。時刻のずれにより証明書の検証や認証に失敗すると、接続タイムアウトのように見えることがあります。問題を隠すために証明書の検証を無効にしないでください。証明書エラーが表示されたら、メッセージを保存し、ネットワーク認証が完了しているか、不明な提供元の証明書やネットワークフィルター設定がインストールされていないか確認しましょう。

設定・権限・接続先の問題を切り分ける

接続先一覧を開き、選択できる接続先が表示されているか確認します。一覧が空、インポートに失敗している、端末内の設定名しか表示されない場合は、まずサブスクリプションの更新を確認し、接続テストは後にしましょう。一覧が正常なら、別の接続先を選んで試し、地域と種類を記録します。1つの接続先だけ失敗し、ほかが使える場合、クライアント全体を初期化する必要は通常ありません。

接続ボタンを押すとすぐに未接続へ戻る場合は、ネットワーク権限が許可されていない、サービスが起動していない、設定の解析に失敗したなどのメッセージがないか確認します。モバイル端末では、システムがVPN接続を許可する必要があります。デスクトップでは、動作モードによって追加の権限や関連サービスが必要な場合があります。クライアントに表示された権限の案内に従ってください。システムに接続アイコンが表示されないだけで、接続先が使えないと判断することはできません。管理対象の端末では、組織のポリシーによる制限も考えられます。

接続中の表示が長く続く場合は、ネットワークを制御しているほかのプロキシやVPNを終了してから、もう一度試してください。複数のツールが同時にシステムのルート、プロキシ、DNSを変更すると、通信が端末内に戻ったり、停止中のサービスに送られたりすることがあります。終了するときはツールの切断機能を使い、ウィンドウを閉じるだけでバックグラウンドサービスを残さないようにします。システムのネットワーク設定を直接削除すると、使えていた接続まで失われるおそれがあります。

端末側の設定変更をやめるタイミング

一度に変更する条件は一つにし、再接続後に結果を確認して元の設定も記録しておきます。復旧した場合は、元の失敗条件でもう一度確認し、偶然の復旧を原因特定と取り違えないようにしましょう。システムサービス、管理対象端末、企業ネットワークの設定を変える前に、変更権限があることを確認してください。セキュリティソフトのルールを確認できない場合、保護機能全体を無効にして試すのは避け、ブロック記録を確認するか端末管理者に相談しましょう。

基本のネットワークが正常で、サブスクリプション一覧にも問題がなく、別のネットワークや端末でも同じ失敗を確認できたら、問い合わせを送信してください。OS名、クライアントの入手元、失敗した接続先、発生時刻、エラーメッセージ全文を添え、どのような比較確認を行ったかも記載します。パスワードやサブスクリプションリンクは添付しないでください。問題が1つの接続先に限られる場合は、動作を確認できた接続先を使いながら調査を待つことができます。

接続済みなのにページが開かない:DNSと出口を確認

「接続済み」は、クライアントが何らかの接続状態になったことを示すだけで、ブラウザーの通信が正しい経路を通ったことや、接続先サイトへのアクセスが許可されたことまでは意味しません。問題をドメイン名の解決、接続の確立、暗号化セッション、サイトからの応答に分けて確認します。「サーバーが見つかりません」「接続がタイムアウトしました」「証明書に問題があります」「アクセスが拒否されました」は、それぞれ異なる箇所を示します。画面が真っ白と説明するより、エラーの原文を保存する方が役立ちます。

いきなりDNSを変更せず、失敗する範囲を確認

普段使っている国内サイトとアクセスしたい海外サイトをそれぞれ試し、特定のドメインだけ失敗するか確認しましょう。すべてのサイトが開かない場合は、クライアントの動作モードとシステムプロキシを確認します。国内サイトは正常で海外サイト全般が開かない場合は、プロキシ経路と接続先を確認してください。特定のサイトだけ失敗する場合は、サイト側の状態、アカウントの地域設定、アプリのキャッシュが原因かもしれません。システムのネットワーク設定をすべてリセットするのは避けましょう。

保存してから時間が経った深い階層のリンクだけでなく、同じサイトの通常のページもブラウザーで開いてみてください。古いリンクの無効化、ログイン状態の期限切れ、ブラウザー拡張機能によるブロックでも、ページが開かないことがあります。新しいブラウザーセッションを比較に使う方法もありますが、プライベートブラウズでもすべての拡張機能が無効になるとは限りません。また、OSのDNSキャッシュが自動的に消去されたり、接続先アカウントの地域設定が変わったりするわけではありません。

DNSは、ドメイン名を接続に必要なアドレスへ変換します。名前解決に失敗すると、接続先が確立されていてもアクセス先を特定できません。ただし、DNSから結果が返ってもサイトに接続できるとは限りません。逆に、クライアントが独自の名前解決を行う場合、システムのコマンドで確認した結果がアプリの実際の動作を示すとは限りません。ブラウザー、システム、クライアントそれぞれがどこで名前解決を行うか確認しましょう。

コマンドで確認する際は、結果の解釈に注意

以下のコマンドはサンプルのドメイン名を使い、名前解決やウェブリクエストの基本的な動作を確認する例です。Windowsでは通常 nslookup を使用でき、macOSとLinuxでは該当コマンドが利用可能な環境で実行できます。curl がプロキシを通るかどうかは、環境変数と現在の通信制御モードによって異なります。コマンドが失敗してもサービスの障害とは限らず、成功しても対象アプリでの動作確認の代わりにはなりません。

nslookup example.com
curl -I https://example.com

名前解決の結果が返らない場合は、まず現在のネットワークでDNSが利用できるか確認し、次にクライアントに専用のDNS処理が設定されているか調べます。知らない設定からDNSアドレスを安易にコピーしないでください。ブラウザー独自の名前解決、システムへの手動DNS設定、複数のクライアントDNSルールを同時に有効にするのも避けましょう。設定が増えても、アプリごとに同じドメインの通信経路が異なり、問題を再現しにくくなる可能性があります。

名前解決に成功してもウェブリクエストがタイムアウトする場合は、クライアントの接続記録を確認し、リクエストが想定したルールに一致しているか、利用可能な接続先が選ばれているかを調べます。設定によっては内部用のアドレスを使うため、アドレスの見た目だけで誤りと判断しないでください。DNSで取得したアドレスを使ってHTTPSのドメイン名を置き換えるのも避けましょう。証明書の検証やサイトの選択にはドメイン名が必要です。アドレスへのアクセスに失敗しても、元の名前解決に問題があるとは限りません。

残った設定を確認し、サイト側の問題を見分ける

クライアントを終了した後にすべてのサイトが開かなくなった場合は、停止したローカルプロキシをシステムが引き続き参照していないか確認します。まず元のクライアントを再起動し、通常の切断手順で接続を解除してから、システムプロキシの設定を確認してください。DNSを手動で変更した場合は、元の値を記録してから、以前使えていた設定に戻します。キャッシュの削除で解消するのは古い結果が残っている場合だけです。誤ったルールや利用できなくなった接続経路は修復できません。

証明書の警告、地域による利用制限、アカウントの認証、アクセス拒否は、それぞれ別の問題です。ブラウザーの証明書警告を無視して、アカウント情報を入力しないでください。接続先サイトのアカウント制限を、すべての接続先が利用できない問題と混同しないようにしましょう。接続経路を変えても、サイトがアカウント情報、支払い地域、過去のセッションをもとに利用可否を判断する場合があります。動画配信については動画配信の地域選択ガイドもご覧ください。

問い合わせの際は、失敗したドメイン、ブラウザーに表示されたエラーの原文、特定のアプリだけで起きるか、接続先の変更前後でどう違うかをお知らせください。スクリーンショットではアカウント情報とリクエストの詳細を隠してください。VPNTextのプライバシーに関する説明は「匿名・ログなし」です。トラブルシューティングの資料も必要最小限にとどめましょう。状況の説明に必要なドメインだけで十分なことが多く、閲覧履歴全体や個人情報を含むページをアップロードする必要はありません。

速度低下や混雑時間帯の不安定さ:経路を比較

速度が遅くなるのは、接続の確立、ウェブページの初回表示、画像の読み込み、動画のバッファリング、ファイル転送など、さまざまな場面です。まずどの段階で遅いのかを記録してから、接続先を変更する必要があるか判断しましょう。ページの応答まで時間がかかっても、転送開始後は正常な場合と、ダウンロードが終始遅い場合は別の問題です。ブラウザーのキャッシュ、接続先サーバー、Wi-Fiの電波、ほかの端末の通信も体感速度に影響するため、一度の結果だけで接続先全体を判断しないでください。

比較する条件をそろえる

まず、プロキシを使わない状態でもネットワークが遅いか確認します。進行中のシステム更新、クラウド同期、大容量ファイルの転送を一時停止し、Wi-Fiの電波が安定しているか確認してください。可能であれば、より安定した接続方法と比較します。日常的な作業を長時間止める必要はなく、ここでは一時的に影響要因を減らします。国内サイトと海外サイトの両方が遅い場合は、まず接続ネットワークを確認してください。共有帯域が使われている問題は、接続先を変えるだけでは解決しないことがあります。

接続先を比較するときは、同じ端末、同じアプリ、同じコンテンツを使い、接続先だけを変えましょう。動画配信サービスはキャッシュや画質設定によって通信量が変わるため、別の動画の再生状況をそのまま比較することはできません。「ページを開くのが遅い」のか「再生開始後もバッファリングする」のかを記録し、そのときの接続ネットワークと地域も控えておきます。条件がそろっていない結果は参考情報にとどまり、速度の保証を示すものではありません。

クライアントに表示される遅延は、主に応答を確認した結果であり、実際のダウンロード速度や接続先サイトの処理速度を示すものではありません。測定先とアクセス先が異なる場合があり、通信中の経路、混雑、サーバー側の制限も影響します。一覧の数字が小さい順に並べて、最適な接続先だと決めつけないでください。普段の作業が問題なく行えるかどうかを、選択時の判断材料として確認しましょう。

接続方式と夜間の混雑を理解する

VPNTextでは、IEPL専用線、中継、直結の接続方式を利用できます。方式は通信経路の構成を示すもので、名称だけから特定の時間帯の速度を判断することはできません。夜間に問題が起きる場合は、クライアントで利用できる接続先から異なる方式を比較し、現在の作業に使えるものを記録しましょう。利用できる地域や選択肢はクライアントの表示をご確認ください。接続先の選び方はノードと接続経路のガイドをご覧ください。

確認できた症状優先して確認する項目次に行うこと
国内サイトも海外サイトも遅い接続ネットワーク、バックグラウンド通信接続先を変えずにネットワークを比較
同じ地域の一部の接続先だけ遅い特定の接続経路クライアントに表示される別の接続先と比較
特定のサイトだけ遅い接続先サービス、アカウント、キャッシュ別のサイトでも接続全体を確認
特定の時間帯だけ遅いネットワークの混雑、接続経路時間帯と方式を記録して問い合わせ

夜間だけ遅くなる場合は、接続ネットワークの混雑と海外への通信経路の変化を切り分けます。接続先を変えずに同じ時間帯でネットワークを切り替えると、問題がネットワークに起因するか判断しやすくなります。同じネットワークで利用可能な接続先を比べると、経路ごとの違いを確認できます。自動切り替えを続けて最後の結果だけ記録すると、どの接続先でどの症状が出たのか分からなくなります。

接続地域は、地理的な距離だけでなく、利用するサービスに合わせて選びましょう。近い地域は試す際の目安になりますが、実際の通信経路は異なることがあります。アプリによっては接続地域を一定に保つ必要もあります。AIツールで生成処理を行っているときや、動画配信アカウントの確認中は、地域を頻繁に切り替えないようにしましょう。画像生成ツールの利用についてはMidjourneyの地域選択ガイドを参考にし、実際のタスクで確認してください。

技術的な確認の代わりにプランを変更しない

データ通信量の残りと現在の速度は別のものです。バッファリングが発生しても、まず残りの通信量、接続先の状態、接続ネットワークを確認しましょう。料金の高いプランが必要だとすぐに判断する必要はありません。月額プランの通信量は契約日を基準に毎月リセットされ、暦月の初日にリセットされるわけではありません。上限に達している場合は、ユーザーパネルで状態を確認してから対応してください。プランのルールと永久データパックの違いは料金ページでご確認ください。

同じネットワークでほかの接続先が正常なのに、特定のサービスだけ遅い状態が続く場合は、サービスのドメイン、タスクの種類、発生時刻を問い合わせに記載してください。異なる端末やネットワークで同じ接続先に似た症状が出る場合も、その比較結果を添えましょう。大量の速度テストを繰り返して通信量を消費する必要はありません。一度の測定結果を、すべての地域や時間帯に当てはまる結論として記載しないでください。

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

まず、クライアント自体が切断されたのか、特定のアプリだけ通信が途切れたのかを確認しましょう。動画の停止、チャットの再接続、ウェブページの再読み込み失敗は、プロキシ接続が続いている間にも起こることがあります。クライアントの状態が未接続に変わった、システムの接続アイコンが消えた、サービスの終了メッセージが表示された場合は、接続全体が切断された可能性が高くなります。アプリとクライアントの両方を確認して、それぞれの状態を記録し、接続先サービスのセッション切れとネットワーク全体の切断を区別しましょう。

切断が起きる条件を探す

画面ロック、接続ネットワークの切り替え、端末のスリープや復帰後に、異常が繰り返し起きるか確認しましょう。Wi-Fiから別の接続方式に切り替わると、既存の接続を再確立する必要があり、進行中のタスクが中断されることがあります。再接続で復旧する場合は、ネットワークを切り替えた操作と復旧方法を記録してください。同じネットワークを使い続けても頻繁に切れる場合は、接続先、バックグラウンド管理、ローカルサービスとの競合を確認します。

デスクトップ端末がスリープすると、一部のネットワーク通信が停止し、復帰後もクライアントの表示が実際の接続状況に追いつかないことがあります。まず通常の手順で切断してから再接続し、影響を受けたウェブページやタスクを開き直してください。ルーターの設定変更やシステムコンポーネントの再インストールをすぐに行う必要はありません。スリープ後にだけ問題が起きる場合は、端末をスリープさせないときの状態と比べ、発生条件を確認しましょう。偶発的な失敗をすべて同じ接続先の問題と決めつけないでください。

Wi-Fiの電波が不安定、公衆ネットワークで再認証が必要、ルーターが一時的に再接続する、といった理由でも接続が中断されることがあります。同じ時間にほかのアプリもネットワークにつながらなくなったか、別の端末でも同じ症状が起きたか確認しましょう。すべての端末に影響がある場合は、接続ネットワークを優先して確認します。特定の端末だけクライアントが終了する場合は、その端末のシステム管理、バックグラウンドサービス、エラー記録を確認してください。

プラットフォームごとのバックグラウンド動作を確認

Android端末では、クライアントのバックグラウンド動作、バッテリー使用、自動起動がシステムによって制限されていないか確認してください。設定メニューの名称は端末によって異なるため、実際のシステムに表示される設定を使いましょう。ほかのメーカーの画面を見て、同じ項目を無理に探す必要はありません。バックグラウンド動作を許可したら、再接続して元の画面ロックの状況を再現します。まだ失敗する場合は終了時のメッセージを保存し、すべてのアプリの権限を一度に変更するのは避けてください。

プラットフォーム確認ポイント確認方法
Windowsスリープからの復帰、ネットワークサービス、残存するプロキシ設定スリープ前後の状態を比較
macOSネットワーク拡張の許可、スリープ、ネットワーク切り替え再接続後に対象アプリを確認
iOSシステムのVPN状態、ほかのネットワーク設定画面ロック前後の接続状態を比較
Androidバックグラウンド制限、バッテリー設定、サービス終了前面表示と画面ロック中の状態を比較
Linuxプロセス、サービスログ、スリープからの復帰サービスが動作中で、ルートが有効か確認

iOSでは、まずシステムのVPN状態を確認し、ネットワークを制御している別の設定がないか調べます。システムの接続状態とクライアントの表示をあわせて確認してください。アプリに戻ったときに見えた表示だけで判断しないようにしましょう。内容が分からない管理対象の設定は削除しないでください。組織管理の端末は管理者に相談します。クライアントの入手と利用はユーザーパネルから行い、iOSで利用できるかどうかはアカウントの状態によります。

Windows、macOS、Linuxでは、ウィンドウが閉じているかどうかより、バックグラウンドのネットワークサービスが動作しているかどうかが重要です。クライアントによって、ウィンドウを閉じてもサービスが残る場合と、接続が終了する場合があります。実際の動作を確認してから、起動時の自動実行やサービスの復旧が必要か判断しましょう。セキュリティソフトのフィルターや、ほかのプロキシツールの常駐プロセスも確認対象です。ただし、具体的な競合を調べ、セキュリティ保護全体を無効にする方法を日常的な解決策にしないでください。

一時的な再接続と継続的な異常を区別

ネットワークが復旧しても、元のアプリのセッションが自動的に戻るとは限りません。ブラウザーは再読み込みできますが、長時間接続を使うアプリではページを開き直すか、アプリを再起動する必要があります。アップロード中のタスクは送信済みか確認し、重複送信を避けてください。クライアントが復旧し、ほかのサイトも正常なのに元のタスクだけ進まない場合は、地域を繰り返し切り替えるのではなく、アプリのセッションを確認しましょう。新たなログイン確認や状態の変化を招くことがあります。

切断と特定の接続先との関連が明確な場合や、複数の端末で同じ時間に接続が中断された場合は、時刻、接続先の地域と種類を問い合わせに記載してください。特定のモバイル端末で画面ロック後に失敗する場合は、バックグラウンド制限の設定と、前面表示では正常に動作することをあわせて説明します。個人的な通知が映る録画を送らないでください。簡潔な説明と、必要な部分を隠したスクリーンショットの方が、サポート担当者による原因の特定に役立ちます。

サブスクリプションを更新できない:取得元とアカウント状態を確認

サブスクリプションは、クライアントが接続設定を取得するためのもので、通常のウェブページや公開してよい案内リンクではありません。更新に失敗する箇所は、リクエストの送信前、アカウントの確認中、クライアントによる設定の読み込み時などに分かれます。まずエラーメッセージ全文を保存し、タイムアウト、認証失敗、内容が空、解析失敗のどれに当たるか確認しましょう。エラーごとに対処は異なります。更新ボタンを何度も押しても、同じ失敗が繰り返されるだけです。

まずユーザーパネルで取得元を確認

ユーザーパネルのアカウント概要で現在のアカウントとサブスクリプションの状態を確認し、パネルに表示される取得またはインポートの入口を使ってください。過去のチャット履歴、見知らぬガイド、他人から転送された内容からアドレスをコピーしないでください。VPNTextではメールアドレスなしでアカウントを作成でき、ユーザー名とパスワードで利用できます。異なるユーザー名を使ったことがある場合は、利用中のサービスに紐づくアカウントでログインしているか確認しましょう。

サブスクリプションの内容を手動でコピーした場合は、空白や改行、説明文が混じっていないか、チャットアプリで途中までしかコピーできていないか、パネルのページURLをサブスクリプションのアドレスと取り違えていないか確認してください。転記の手間を減らすため、まずパネルから直接インポートしましょう。アドレスを確認するときは自分の端末だけで操作してください。完全なリンクを公開の検査サイトに貼り付けたり、公開の掲示板にスクリーンショットを投稿したりしないでください。

古い設定で接続できているのに更新だけ失敗する場合は、古い設定を残しておき、すぐに削除しないでください。更新リクエストは、利用中の接続先とは異なる経路を通る場合や、一時的なキャッシュやネットワークの問題が発生している場合があります。基本のネットワークが使えることを確認したうえで、別の接続ネットワークから更新結果を比べてみましょう。クライアントを先に空にすると、復旧に使える接続手段まで失われるおそれがあります。

エラーメッセージに合わせて対処を選ぶ

タイムアウトは、クライアントの待機中にリクエストが完了しなかったことを示しますが、この表示だけでサーバー側か接続ネットワーク側かを特定することはできません。まずユーザーパネルが正常に開くか確認し、システムプロキシの設定が残っていないか、ネットワーク認証が必要か、ほかのネットワークツールが干渉していないかを調べます。パネルは開くのにサブスクリプション更新だけがタイムアウトする場合は、その違いを記録してください。ページへのアクセスと設定の取得で経路が異なる可能性を、サポート担当者に伝えられます。

認証失敗やアクセス拒否が表示された場合は、アドレスのパラメーターを繰り返し変更するのではなく、パネルに戻ってアカウント状態を確認します。パネルにサブスクリプションのリセット機能があり、実際に漏えいのおそれがある場合は、画面の案内に従ってください。リセット後は自分のクライアントも更新する必要があり、古い入口は使えなくなる場合があります。トラブルシューティングのために、パスワード、認証情報、サブスクリプションの内容を誰かに送らないでください。

解析エラーは、クライアントが受け取った内容を想定どおりに読み取れなかったことを示します。インポート形式が合わない場合や、ネットワーク認証ページ、エラーページを取得した場合があります。まず、現在のクライアント向けにパネルが案内している方法を使い、設定項目を独自に書き換えないでください。クライアントによって対応する設定形式は異なります。ガイドに掲載された一般的な設定例を、パネルが作成した内容の代わりに使うことはできません。

通信量、利用可能な状態、更新の動作を区別

月額サブスクリプションの通信量は契約日を基準に毎月リセットされ、暦月の初日にリセットされるわけではありません。永久データパックは、使い切るまで利用でき、期限はありません。サブスクリプションを更新しても設定を再取得するだけで、通信量はリセットされず、アカウント状態も変更されません。パネルで通信量の上限に達していると表示された場合は、接続先一覧を更新して自動的に復旧することを期待せず、パネルのルールに従って対応してください。料金の詳細はプランページでご確認ください。

クライアントとサブスクリプションはどちらもユーザーパネルから取得します。Windows、macOS、Android、Linuxのクライアントはログインして取得でき、iOSで利用できるかどうかはユーザーパネルに表示されるアカウント状態によります。クライアントの入手と利用可能なサブスクリプションの取得は、関連はありますが別の手順です。ソフトウェアをインストールしただけでは、現在のアカウント設定が正しく取り込まれたとは限りません。初回のインポート方法が分からない場合は、サブスクリプションリンク入門ガイドをご覧ください。

問い合わせの際は、更新に失敗したプラットフォーム、エラーメッセージ、現在パネルにアクセスできるか、古い設定で接続できるか、ネットワーク切り替え後の結果をお知らせください。リセットや再インポートを行った場合も記載できますが、変更前後の実際のアドレスは添付しないでください。1つのクライアントだけで失敗し、ほかの端末では正常に更新できる場合は、正常な端末を比較対象として残し、その違いを明記しましょう。アカウント全体の問題と誤解されにくくなります。

特定のアプリがプロキシを経由しない:ルールとモードを確認

ブラウザーでは正常なのに特定のアプリだけアクセスできない場合、通信の振り分けに問題があることがよくあります。アプリがシステムプロキシを参照しない、独自の接続や名前解決を行う、バックグラウンドの補助プロセスを使う場合があるため、「システムプロキシが有効」でも、すべてのアプリが対象とは限りません。まず同じ端末、同じ接続先でほかのアプリが使えるか確認し、問題のアプリがリクエストを送ったときに、クライアントの接続記録が残るか調べましょう。

現在のモードでどの通信が制御されるか確認

システムプロキシの影響を受けるのは、通常、その設定に従うアプリだけです。一部のコマンドラインツール、ゲーム、独自のネットワーク設定を持つプログラムでは、アプリ側での設定が必要な場合や、クライアントが対応していればトンネルモードで通信を制御する方法があります。トンネルモードはより広範囲の通信に影響し、追加の権限が必要になることもあります。モードの有無やメニュー名は、現在使用しているクライアントの画面で確認してください。別のソフトウェアの設定をそのまま当てはめないようにしましょう。

ルールモードは、クライアントに届いたリクエストの経路を振り分けます。リクエストがクライアントに届くことと、プロキシ経由に振り分けられることは別の段階です。接続記録がない場合は通信の制御方法を確認し、記録があるのに想定外の経路を通る場合はルールを確認しましょう。最初からルール全体を削除しないでください。既存のルールは国内サイト、LAN内の端末、日常的なアプリに使われている場合があり、すべて置き換えると別のアクセス問題を招くことがあります。

クライアントに全通信をプロキシ経由にするテストモードがある場合は、一時的に使って振り分けが原因か確認できます。テスト後は元のモードに戻し、診断用の設定をそのまま使い続けないようにしましょう。全通信モードでは復旧し、ルールモードでは失敗する場合は、アプリに関係するドメインとルールの判定結果を記録します。どちらのモードでも失敗する場合は、ルールの順序だけでなく、アプリの設定、接続先の地域、接続先サービスの状態を確認してください。

アプリのアクセス手順全体を確認

アプリは複数のドメインへアクセスすることがあります。メイン画面、ログイン、画像、ファイルのアップロード、リアルタイム通信で別々のサービスが使われるため、ホーム画面が開いても全機能が使えるとは限りません。実際の操作を再現して失敗した箇所まで進み、その時点の接続を確認しましょう。アプリのブランド名だけから必要なドメインを推測したり、インターネットで見つけた大量のルールをまとめて追加したりすると、後から原因を確認しにくくなります。

デスクトップアプリでは、バックグラウンドの補助プロセスがリクエストを送信する場合があります。プロセス単位で通信を振り分けるときは、実際にネットワークへ接続しているのがメインのプログラムか補助プロセスか確認してください。ドメイン単位の場合は、ドメインの判定とDNS処理が連携しているか調べます。アプリの更新後に動作が変わることもあるため、古いルールは手がかりとして扱いましょう。インストール先やウィンドウのタイトルから推測するより、クライアントで実際に確認したリクエストを記録する方が確実です。

ブラウザー独自のプロキシ拡張機能、アプリ内のプロキシ設定、システムプロキシを同時に使うと、アプリごとに通信経路が異なることがあります。まず、どの設定が通信を制御しているのかを確認し、必要な設定だけを残しましょう。アプリを終了して開き直すと、一部の古い接続は解消できますが、アカウントの地域設定やサーバー側のセッションは変わりません。保存していない作業がある状態でプロセスを強制終了しないでください。特に、アップロードやコンテンツ生成中のタスクには注意が必要です。

ネットワークエラーとプラットフォーム側の制限を分ける

AIツールに地域制限、アカウント確認、権限不足などのメッセージが表示された場合は、まず対象プラットフォームの案内を確認してください。ネットワークの接続先を変えても、プラットフォーム独自のアカウント要件や利用ルールを満たせるとは限りません。既存のセッションに以前の地域情報が残る場合もあるため、接続先を切り替えた後に改めて確認し、複数の国へ続けて切り替えるのは避けましょう。接続先を一定に保つと確認条件を絞れますが、各プラットフォームの利用を保証するものではありません。

動画配信では、接続できない、再生できてもコンテンツが異なる、アプリにプロキシに関するメッセージが表示される、といった症状を区別しましょう。配信作品や再生条件は、アカウント、著作権上の地域、プラットフォームの方針に左右される場合があり、すべてを接続経路の問題と考えることはできません。同じ接続先でウェブ版とアプリ版を比較し、違いを記録してください。特定のアプリだけ失敗する場合は、システムのネットワーク設定をすぐリセットせず、まずアプリのキャッシュとネットワーク設定を確認しましょう。

問い合わせには、アプリ名、失敗した操作、クライアントのモード、該当する接続記録があるか、モードを一時的に変更した結果を記載してください。ログには必要なドメインとルールの判定結果だけを残し、クエリパラメーターや個人情報は隠しましょう。例外ルールを追加する必要がある場合は、元の設定をバックアップし、「このアプリを選択中の接続先経由にする」のように、実現したい動作を説明してください。出所の分からない設定だけを送って、意図の推測をサポート担当者に任せないようにしましょう。

対応後は、ログイン、コンテンツの表示、送信操作など、元のタスク全体を確認し、国内サイトとLAN内の端末にも引き続きアクセスできるか調べてください。アプリの起動画面が表示されるだけでは、通信の振り分けが直ったとはいえません。設定変更によって問題が別の箇所へ移っただけなら、元の設定に戻して原因の調査を続けましょう。説明でき、元に戻せるルールを保つ方が、一時的な例外を増やすより日常利用に適しています。

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

VPNTextでは同時接続台数に制限はありません。画面に「端末数の上限」のようなメッセージが表示されても、本サービスに非公開の端末数制限があると決めつけたり、トラブルシューティングのために追加の端末枠を購入したりしないでください。まず、表示元がクライアント、システム、接続先アプリ、ユーザーパネルのどれかを確認し、メッセージの原文を保存します。似た表現でも、アカウントへのログイン、ソフトウェアのライセンス、接続先プラットフォーム独自の利用ルールなど、原因は異なります。

メッセージの表示元を確認

接続先のウェブサイトやアプリにメッセージが表示された場合は、そのサービスのアカウント管理と端末ポリシーを確認してください。接続先サービスのセッションや端末に関する要件は、VPNTextの同時接続台数無制限とは別のルールです。ネットワークが正常でも、接続先のアカウントをどの端末でも無制限に使えるとは限りません。対象アプリの端末管理ページを本サービスのアカウントページと混同したり、そこでのログアウトをプロキシの切断と取り違えたりしないようにしましょう。

クライアントに表示された場合は、ソフトウェアをユーザーパネルから取得したか、現在のアカウントの設定をインポートしたかを確認してください。古い端末には別のアカウント、別のサービス、過去の設定が残っていることがあります。また、一覧の名前が手動で変更されている場合もあるため、名前だけで取得元を判断できません。まずパネルで確認して、パネルのインポート機能を使いましょう。古い設定は記録として残し、テスト時には現在確認する設定を選んでください。

システムからのメッセージであれば、管理対象端末のポリシー、ネットワーク拡張の権限、ほかに動作中のVPNとの関係を確認します。システム側の制限は、サービスプランにおける端末数の制限とは異なります。組織が管理するPCやモバイル端末では、ネットワーク設定が許可されているか管理者に確認してください。管理設定の削除、セキュリティポリシーの無効化、システム保護の変更によってメッセージを回避しようとすると、安全に原因を調べられなくなるおそれがあります。

アカウント概要で利用状態を確認

パネルで現在のユーザー名、サービス状態、通信量を確認してください。複数の端末で異なるユーザー名を使ったことがある場合は、サービスを利用できるアカウントを確認しましょう。メールアドレスなしで作成したアカウントでも、ユーザー名とパスワードを適切に保管する必要があります。ログイン情報を忘れた場合は、パネルに表示される手順に従ってください。パスワードを問い合わせに送ったり、元のサービス情報を確認せずに新しいアカウントを作成したりしないでください。

月額プランは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は契約日を基準に毎月リセットされます。これらのプランの違いを端末数の違いと解釈しないでください。接続に失敗した場合は、通信量を利用できるか、現在のアカウントに対応した設定かを確認してから、使い方を調整する必要があるか判断しましょう。端末を増やしただけでプランが不足していると決めつけないでください。

永久データパックは、¥158/300GB、¥358/1000GB、¥658/3000GBです。使い切るまで利用でき、期限はありません。期限がないという説明は、使い切った後も通信量を追加できるという意味ではありません。課金方式の詳細はパネルの表示をご確認ください。アカウント状態と購入済みの注文内容が一致しない場合は、注文に関する情報を添えて問い合わせ、確認を依頼しましょう。状況を確かめるために、新たな支払いを繰り返す必要はありません。

共有環境での安全性とリソースの問題

同時接続台数に制限がなくても、サブスクリプションを公開してよいわけではありません。自分のアカウントに関わる情報なので、信頼できる端末だけで保管し、端末を譲渡する前に関連設定を削除してください。サブスクリプションが漏えいした疑いがある場合は、パネルの管理機能から対応し、自分の端末の設定も更新します。「匿名・ログなし」というプライバシー方針は、アカウント情報の管理に代わるものではなく、公開共有のリスクをなくすものでもありません。

複数の端末で同時に大容量のデータを転送すると、接続ネットワークとアカウントの通信量を共有して使います。そのため、バッファリングや応答の遅れが起きることがありますが、サービスが端末数を理由に接続を拒否しているわけではありません。ほかの端末で通信量の多いタスクを一時停止し、現在の作業が改善するか確認しましょう。改善する場合は、タスクの同時実行数やネットワークリソースを調整してください。存在しない端末解除の上限を探す必要はありません。

途中でプランを変更した場合の差額は残り日数に応じて換算されます。別の期間単位に独自に換算しないでください。支払い方法はAlipay、WeChat、USDTです。注文状態はパネルで確認してください。VPNTextは30日間の返金保証を提供しています。詳細は返金ポリシーをご覧ください。料金や返金に関する質問は、技術的な問題とは分けて説明しましょう。技術情報だけでは注文を確認できず、注文情報だけでは特定の接続先で失敗した理由は分かりません。

端末に表示されたメッセージについて問い合わせる場合は、表示された画面、端末のプラットフォーム、設定の取得元、パネルの状態を記載し、アカウントの機密情報は隠してください。特定の端末だけで起き、同じアカウントを使うほかの端末では正常な場合は、その違いを明記します。クライアントやシステムの問題を優先して確認でき、正常なプランや通信量の状態を何度も調べる手間を減らせます。

問い合わせの送信と復旧後の確認

トラブルシューティングでは、設定をできるだけ多く変更するのではなく、問題の範囲を絞り、原因を説明できる接続状態へ復旧することが大切です。基本のネットワークが正常で、設定の取得元も正しく、問題を再現できる場合は、ユーザーパネルから問い合わせを送信してください。技術用語がすべて分かるまで連絡を遅らせる必要はありません。必要な情報をそろえるために、現在の接続を損なうおそれのあるシステム操作を続けるのも避けましょう。

再現できる手順として症状を伝える

問い合わせの冒頭で影響範囲を説明します。まったく接続できない、特定の接続先だけ失敗する、特定のアプリが開かない、画面ロック後だけ起きる、など具体的に記載してください。次に発生させる手順、実際に起きた結果、期待する結果を説明します。たとえば、現在のネットワークから指定の接続先につなぎ、特定のドメインを開くとタイムアウトするが、別の接続先に切り替えると復旧する、といった形です。「ネットワークが遅いので直してください」よりも、再現方法が明確な説明の方が調査に役立ちます。

発生した時刻、タイムゾーン、接続ネットワークの種類、OS名、クライアントの入手元を記載します。時刻は問題の発生状況を照合するための情報です。正確に見せるために、覚えていない詳細を記入する必要はありません。不明な場合はおおよその時間帯を伝えてください。クライアント画面に実際のバージョン情報があれば記載できますが、ガイドをもとに推測しないでください。管理対象端末の場合は、自分で変更できないシステム設定についても説明しましょう。

試した操作とそれぞれの結果を記載し、特にネットワーク、端末、接続先、動作モードを変更したかどうかを明確にします。「全部試した」とだけ書いたり、複数の条件を同時に変えた結果を混同したりしないでください。試していない項目は未確認と明記しましょう。比較結果があれば問題を切り分けやすくなります。実施していない確認も、次の手順をサポート担当者が決めるうえで役立ち、すでに確認済みのことを繰り返す手間を減らせます。

必要な情報を伝えながらアカウント情報を保護

エラーのスクリーンショットにはメッセージの原文と必要な画面だけを残し、パスワード、サブスクリプションリンク、QRコード、個人的な内容を隠してください。ログは失敗した操作に関係する部分だけを切り出しましょう。ログ全体にはドメイン、リクエストの詳細、端末内の情報が含まれる場合があります。アップロード前に内容を確認してください。トラブルシューティング資料を公開した後で、その公開ページを問い合わせに送るのは避けましょう。パネルから必要な資料を直接提出する方が、共有範囲を管理しやすくなります。

問題の範囲:クライアント接続後も、指定したアプリでコンテンツを開けない
端末のプラットフォーム:使用中のOS名を記入
接続ネットワーク:ネットワークの種類を記入し、個人用の接続情報は記入しない
接続先の選択:クライアントに表示される地域と種類を記入
発生させる操作:実際に行った順番で説明
エラーメッセージ:原文を残し、機密情報を隠す
比較確認:ネットワーク、接続先、端末を変えた後の結果を説明
現在の状態:利用可能な接続先または端末があるかを説明

注文に関する問題の場合は、パネルに表示される該当の注文番号と状態をお知らせください。支払いアカウントのパスワード、ウォレットの秘密情報、注文と関係のない取引履歴は提出不要です。支払い済みなのに状態が反映されていない場合は、パネルの表示と支払い結果の違いを説明し、確認をお待ちください。支払いを繰り返したり、技術ログと注文情報を読みにくい大量のスクリーンショットにまとめたりしないでください。

サポート担当者から追加確認を依頼された場合は、実行前に何が変更され、どう元に戻せるか確認してください。設定のエクスポート、ネットワーク権限、システムサービスに関わる操作では、先に現在の設定を保存します。案内内容が現在のクライアント画面と一致しない場合は、名前の似た別のボタンを探すのではなく、実際に表示されている画面を共有してください。不明なコマンドをまとめて一度に実行するより、結果を確認できる小さな手順で調べる方が確実です。

接続状態だけでなく、タスク全体を復旧後に確認

復旧後はまずクライアントの状態を確認し、以前失敗した実際のタスクを試します。同時に、国内サイト、普段使うアプリ、LAN内の端末にも引き続きアクセスできるか確認してください。ウェブページが開くのは確認の出発点です。必要に応じてログイン、コンテンツの読み込み、送信操作まで試します。画面ロック後やネットワーク切り替え後に発生した問題なら、同じ条件を再現し、前面表示中だけ一時的に使える状態ではないことを確認しましょう。

一時的なテストモードを普段の設定に戻し、不要と確認できた一時的な例外を削除して、利用できる設定を一つ残します。診断のために変更した設定を長期間重ねると、次に問題が起きたとき、どの設定が原因なのか判断できません。自動更新される設定は、パネルやクライアントの機能を使って管理しましょう。変更履歴を追えないコピーを繰り返し手動で編集すると、端末ごとに動作が異なることがあります。

問い合わせには、復旧に有効だった操作と残っている問題を追記します。たとえば、接続先を変更すると復旧したが元の接続先はまだ失敗する、バックグラウンド権限を変更すると画面ロック中も正常になった、などと説明してください。一時的な代替手段と根本的な修復を区別できます。再発した場合は、前回の確認結果を参照し、変化した点を記載すれば、操作を最初からすべて繰り返す必要はありません。明確な記録があれば、同じ問題が再発したか判断しやすくなります。

日常利用の手順は使い方ガイドを、接続先の選び方はノードガイドを、料金に関する疑問はプランのルールをご確認ください。このページでは問題を切り分ける方法を説明していますが、すべての外部ネットワークや接続先プラットフォームの状態を、端末の設定だけで解決できると保証するものではありません。変更を止めるタイミングを判断し、利用できる接続を残して必要な情報を正確に伝えることも、トラブルシューティングの大切な手順です。