VPNTC 接続トラブルの対処法

接続できないとき：診断の基本を確認

「接続できない」ときは、どの段階で問題が起きているかを確認します。管理画面が開かない、サブスクリプションを更新できない、クライアントが接続を開始できない、接続後に対象サイトでエラーが出る場合では、確認すべき経路が異なります。この項目では、クライアントの接続が確立しない場合を扱います。エラーの原文と発生した段階を記録してください。ステータスアイコンだけで判断したり、接続先、プロトコル、モードを同時に変更したりしないでください。

まず端末のネットワークを確認

クライアントの接続を停止し、普段そのまま開けるウェブサイトにアクセスします。同じように失敗する場合は、接続先を変更する前に端末側のネットワークを確認してください。公衆Wi-Fiでは、ブラウザーで接続確認を完了する必要がある場合があります。Wi-Fiに接続済みと表示されていても、インターネットに正常にアクセスできるとは限りません。

直接アクセスが正常なら、クライアントを起動し、接続状態が待機中、接続済み、失敗のどれに変わるか確認します。接続ボタンを押した直後に失敗するのか、しばらく待ってから失敗するのか記録してください。前者では権限、設定、ローカルポートを、後者では接続先への到達性やハンドシェイクを確認します。ただし、待ち時間だけで特定の接続先の障害とは判断できません。

現在の設定が管理画面のものか確認

管理画面でプランの状態と残り通信量を確認し、クライアントが使っているサブスクリプション名も照合します。古い設定と新しい設定が両方残っている場合、現在選択されているものが更新後の設定とは限りません。以前のスクリーンショットにあるサーバーアドレスを手入力したり、チャットから他人の設定をコピーしたりしないでください。検証できない要因が増えてしまいます。

接続先の一覧が空なら、サブスクリプションの項目で更新結果を確認します。一覧がある場合は、用途に合う接続先を選んで接続し、別の接続先でも比較します。比較する際はクライアント、ネットワーク、モードを同じにしてください。香港、シンガポール、日本などの地域は選択の目安にすぎず、距離が近くても現在のネットワークで最適な経路とは限りません。

権限と接続の競合を切り分ける

クライアントが初めてシステムレベルの接続を確立するとき、ネットワーク設定の権限を許可するよう求められる場合があります。以前に拒否した場合は、システム設定またはクライアントから改めて確認してください。仮想ネットワークインターフェースを使う機能にのみ、該当する権限が必要です。トラブル対応のためにすべてのプログラムを管理者として実行したり、システムのセキュリティ保護を長期間無効にしたりしないでください。

別のプロキシクライアント、企業向けネットワークツール、システムレベルのトンネルが同時に動作していないか確認します。複数のプログラムがルート、ポート、ネットワーク拡張機能を取り合うことがあります。今回のテストに関係しないツールを通常の方法で終了してから、再度試してください。組織管理の端末では管理ルールに従い、企業のセキュリティ機能を自己判断で無効にしないでください。競合が疑われる場合は、管理者に確認を依頼します。

エラーにローカルポートの競合が明記されている場合は、クライアント設定で実際に使用している待ち受けポートと、そのポートを使っているプログラムを確認します。用途が分からないプロセスを強制終了しないでください。まず、重複起動しているクライアントを終了します。ポートを変更する場合は、そのポートを参照するアプリ側の設定も合わせて変更してください。接続が復旧しても、アプリが使えないままになる可能性があります。

ネットワークを変えて原因を絞る

可能であれば、正常にインターネットへ接続できる別のネットワークに切り替え、同じ設定でテストします。特定のネットワークだけで失敗するなら、そのネットワークの接続ルール、ルーティング、プロトコルとの相性を確認します。どのネットワークでも失敗する場合は、アカウント、設定、クライアントを引き続き確認してください。ネットワークを切り替えると接続元の環境も変わるため、重要なサービスにログインする際は追加認証に注意してください。

確認の順序：直接アクセスできるか → アカウントと通信量に問題がないか → 設定が正しいか → 権限を許可したか → 接続先とネットワークを比較。各手順の結果を記録し、推測ではなく確認結果に基づいて判断します。

対応プロトコルは VLESS、Trojan、Hysteria2 です。プロトコル名だけで障害の深刻度は判断できません。クライアントで切り替えられる場合も、サブスクリプションで提供されている設定だけを使用し、サーバーのパラメーターをむやみに変更しないでください。証明書エラーが出たら、まずシステムの日付、時刻、タイムゾーンを確認します。正しくても解決しない場合はエラーを記録してサポートに連絡し、証明書検証を無効にして問題を隠さないでください。

直接アクセスと管理画面の状態に問題がなく、設定を再取得しても、複数の接続先で異なるネットワークから同じエラーが出る場合は、問い合わせを検討してください。利用中のプラットフォーム、接続が失敗する段階、個人情報を隠したエラー内容を添えてください。初回の設定手順は初めての方へで確認できます。読み込みが完了していないだけなのに、接続先が使えないと判断するのを防げます。

接続済みなのにウェブサイトが開かない：リクエストとDNS

クライアントに「接続済み」と表示されても、特定の接続段階が完了したことを示すだけで、ブラウザーの通信が正しい経路を通っているとは限りません。すべてのサイトが開かないのか、特定のドメインだけ失敗するのかを確認します。前者はシステムプロキシ、ルーティング、名前解決を、後者は対象サイトのメンテナンス、アカウント権限、地域の利用条件、ブラウザーキャッシュも確認してください。

ブラウザーのエラー内容から切り分ける

ブラウザーのエラーに表示される重要な文言を記録します。名前解決エラーはDNSを、接続タイムアウトはリクエストが時間内に完了しなかったことを示しますが、原因は端末、接続経路、接続先のいずれにもあり得ます。証明書の警告では、システム時刻、ドメイン、セキュリティソフトを確認してください。異なるエラーをすべて「ネットワークが不安定」とまとめると、最も有用な手がかりが失われます。

別のブラウザーで同じURLにアクセスするか、元のブラウザーで新しいセッションを開いて比較します。新しいセッションでも、システムプロキシやブラウザー独自のDNS設定は引き継がれる場合があり、完全に独立したネットワークテストではありません。元のセッションだけで失敗するなら、拡張機能、サイトのキャッシュ、ログイン状態を確認します。削除する前にアカウントの復元方法を確認し、必要なデータを誤って消さないようにしてください。

リクエストがクライアントに届いているか確認

クライアントの接続ログで対象ドメインを探します。ウェブサイトを開いても新しいリクエストが記録されない場合、ブラウザーが現在のプロキシを使っていないか、別のネットワークツールが通信を処理している可能性があります。システムプロキシが有効か、設定先が現在のクライアントと一致しているか、クライアント終了後にプロキシ設定が残っていないか確認します。接続ボタンを何度も押すだけでは解決しません。

リクエストが記録されている場合は、適用されたルール、直接接続かプロキシ経由か、最終的に選択された接続先を確認します。ページ本体とリソースのドメインは異なることがあります。メインページは開くのに画像、スクリプト、ログイン画面が失敗する場合、それぞれのリクエストを確認してください。トップページのドメインだけにルールを追加しても、サービス全体の通信をカバーできるとは限りません。

名前解決の経路と通信経路を分けて考える

DNSはドメイン名をIPアドレスに変換し、その後の接続でそのアドレスにアクセスします。ブラウザーが独自の暗号化DNSを使う場合や、システムがネットワーク提供のDNSサーバーを使う場合、クライアントがDNSを処理する場合もあります。複数の設定を一度に置き換えるのではなく、まず現在有効な設定を確認してください。そうしないと、サイトが復旧しても、どのDNS経路が有効だったのか判断できません。

システムのターミナルでドメイン名を解決できるか確認できます。以下の例では、公開されているサンプルドメインだけを確認し、サブスクリプションやアカウント情報は扱いません。コマンドが成功しても、そのコマンドが使用したDNS経路で結果を取得できたことしか分かりません。ブラウザーやクライアントが同じDNSサーバーを使っているとは限らず、DNS経路に違いがない証拠にもなりません。

nslookup example.com

アドレスが返ってきてもサイトが開かない場合は、接続経路を確認します。名前解決に失敗する場合は、ネットワークとクライアントのDNS設定を確認してください。ウェブサイトのURLを解決後のアドレスに置き換えて最終判断しないでください。HTTPS証明書、仮想ホスト、コンテンツ配信がドメイン名に依存することがあり、アドレスへの直接アクセスは同等のテストにならない場合があります。

ルールモードとアドレスファミリーを比較

ルールモードでは失敗し、グローバルモードに一時的に切り替えると正常になる場合は、ルールの適用状況やDNSとルールの連携を確認します。グローバルモードは短時間の比較にのみ使い、問題が解決したと判断しないでください。テスト後は元のモードに戻します。直接接続すべきサービスまで接続元が変わると、新たなログイン要求や地域に関する警告が出ることがあります。

ネットワークによっては、異なるアドレスファミリーが同時に使われ、クライアントやアプリによって処理が異なることがあります。同じドメインへのアクセスが不安定な場合や、特定のアプリがプロキシを迂回する場合は、該当設定とリクエストログを確認します。アドレスファミリーの設定を一時的に変更する前に、元の値を記録してください。特定のアドレスファミリーを無効にする方法を、常に有効な対策として扱ったり、組織のネットワーク設定を一括変更したりしないでください。

サイトが開いても、すべてのDNSクエリが想定した経路を通っているとは限りません。接続元の確認とDNS経路の確認は別々に行い、クライアントの設定と実際のリクエストをそれぞれ確認してください。

ネットワーク診断で現在のブラウザーの接続元を確認し、クライアントで選択した地域と比較できます。結果が示すのは今回のブラウザー接続だけで、ほかのアプリには適用されません。名前解決が正常で、リクエストがプロキシに届いており、複数の接続先でも同じサイトにアクセスできない場合は、対象ドメインとエラーを記録し、接続先の制限か経路の問題かサポートに確認してください。

速度低下と夜間の混雑：接続先を比較

「速度が遅い」には、ページの初回応答が遅い、ダウンロード速度が低い、動画がバッファリングする、リアルタイム通信が途切れるなど複数の症状があります。症状ごとに関係する要因は異なります。ダウンロード速度だけで会議やチャットの使い心地は判断できません。また、接続先一覧の参考レイテンシは、対象サービスの応答速度を示すものではありません。数値だけで接続先を選ばず、どの操作が遅いかを明確にしてから比較しましょう。

端末やネットワークの負荷を確認

テストと関係のない同期、更新、大容量ファイルの転送を止め、タスクマネージャーやシステムのネットワーク使用状況を確認します。同じネットワークの別の端末が帯域を使っている場合もあります。直接アクセスするサイトも遅いなら、まずネットワーク環境を確認してください。Wi-Fiの電波が強くても干渉が少ないとは限りません。可能であれば有線接続と比較するか、アクセスポイントの近くで再試行します。

端末の負荷も確認してください。ブラウザー拡張機能、バックグラウンドスキャン、ストレージの高負荷、動画のデコード処理が、ネットワークの遅延のように見えることがあります。コンテンツのダウンロードは完了しているのに画面の動作が遅い場合は、接続先ではなくアプリや端末を確認します。セキュリティソフトを長期間無効にしてトラブルを調べないでください。比較のため設定を変更した場合は、通常の設定画面から行い、確認後に元へ戻してください。

対象をそろえて接続先を比較

比較する際は、同じ対象、同じネットワーク、同じ操作手順を使います。異なる速度測定サイト、動画、ダウンロードサーバーの結果は直接比較できません。まず同じ地域の別の接続先を試し、その後、用途に合う別の地域も試します。ページの応答と継続利用時の状況を記録してください。地域を頻繁に変えて対象サービスへログインすると、追加認証が発生し、比較の妨げになることがあります。

VPNTCは 90+ か国・地域、190+ の接続先に対応していますが、すべての接続先があらゆるネットワークや時間帯で同じように動作するわけではありません。接続先を選ぶ際は、種類と用途の両方を考慮してください。IEPL専線、中継、直接接続は経路の構成方法であり、対象プラットフォームでの利用を一律に保証するものではありません。実際のアクセス確認も必要です。

夜間の問題は発生時刻を記録

夜間だけ通信が途切れたり遅くなったりする場合は、通常の時間帯と問題が起きる時間帯に同じサイトへアクセスし、現地時刻とタイムゾーンを記録します。すべての海外サイトが遅いのか、特定のプラットフォームだけかを確認してください。同じ地域の別の接続先や、別のネットワークで改善するかも比較します。こうした情報がないと、「夜になると遅い」という報告だけでは、端末側の混雑、経路の混雑、接続先の負荷を区別しにくくなります。

動画ではトップページだけでなく、再生が続くかを確認します。再生開始後の画質変更、シーク、再生の再開では、別のリソースにアクセスする場合があります。高画質のときだけバッファリングするなら、まず画質を下げて再生が続くか確認し、その後でネットワーク経路を調べます。プラットフォームが自動で選ぶ画質は、端末、アカウント、コンテンツにも左右されます。すべてをサブスクリプションの問題と決めつけないでください。

AIツールの応答待ちには、サービス側の計算や処理待ち時間も含まれます。ページがすぐ開き、メッセージも送信できるのに、回答の生成だけが遅い場合は、通信の問題とは限りません。ログインページ、過去の会話の読み込み、ほかの軽いページと比較し、生成中だけ遅いなら対象サービスの案内を確認します。接続元とログイン環境の違いについては、AIツールのアクセスガイドをご覧ください。

通信量やプロトコルは速度調整のつまみではありません

通信量を使い切った状態でネットワーク品質をテストしないよう、管理画面で残量を確認します。プランの変更は通信量のニーズに対応するもので、速度の改善が確認済みという意味ではありません。ネットワークによってプロトコルの動作が異なる場合がありますが、サブスクリプションで提供されている設定だけを使用してください。速度を上げるために、サーバーのパラメーター、転送設定、証明書の検証を自己判断で変更しないでください。

信頼できる比較では、対象、接続ネットワーク、操作を同じにし、接続先だけを変更します。接続先を変えても時間帯に応じて問題が起きる場合は、時間帯とネットワークの比較結果も合わせて共有してください。

継続してテストした後、現在の用途に合う接続先を選べば十分です。参考値を追いかけて頻繁に切り替える必要はありません。地域とタイプの説明はサーバー一覧をご覧ください。同じネットワークで利用できるどの接続先も遅く、別のネットワークでは改善するなら、まず接続環境を確認します。複数のネットワークで同じ問題が起きる場合は、影響を受けるサイトと時間帯をまとめて問い合わせてください。

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

切断時は、クライアント自体が切断されたのか、特定のアプリだけ通信できなくなったのかを確認します。クライアントに戻ると接続済みのままなのに、チャットや会議が切れている場合は、アプリの長時間接続、ルール、ネットワーク切り替えが関係している可能性があります。クライアントの接続が実際に停止している場合は、システムがバックグラウンドプロセスを終了していないか、ネットワークが変化していないか、明確なエラーがないかを確認します。

切断のきっかけとなった操作を記録

画面ロック、Wi-Fiの切り替え、スリープからの復帰、省電力モードの有効化、別のネットワークツールの起動に続いて問題が起きるか確認します。毎回同じ操作で発生するなら、その原因に沿って調べ、すぐにプロトコルを変更しないでください。明確なきっかけがない場合は、アプリを前面に表示した状態で比較します。前面では安定し、バックグラウンドで失敗するなら、システムのバックグラウンド管理とアプリの接続維持機能を確認します。

ネットワークを切り替えると、既存の接続経路が変わり、クライアントは利用可能な接続を再確立する必要があります。対象アプリでも再ログインやセッションの復元が必要になる場合があります。クライアントが自動復旧しても、アプリの状態は古いままのことがあります。新しいリクエストを送信できるか確認してから、問題のあったページを再度開いてください。古いセッションのエラーだけで、接続先が復旧していないと判断しないでください。

Androidのバックグラウンド管理を確認

システム設定でクライアントのバッテリー管理、バックグラウンド実行、ネットワーク利用権限を確認します。設定項目の名称や場所は端末によって異なるため、特定の機種のメニュー手順をそのまま当てはめず、機能を確認してください。必要に応じてクライアントのバックグラウンド実行を許可し、画面ロック時と前面に戻した後の状態を比較します。すべてのアプリのバックグラウンド制限を一度に解除しないでください。

タスクの一括終了、自動最適化、メーカー独自のバックグラウンド管理がクライアントのプロセスを終了する場合があります。システムによっては、ネットワーク接続とアプリのプロセスが別々に表示されます。通知が残っていても、プロセスが正常に動いているとは限りません。前面に戻した後に再起動していないか、設定が以前選択していた項目のままか確認します。必要に応じてシステムの通知を記録し、再起動後の状態を切断前の証拠と混同しないようにしてください。

iOSのネットワーク拡張機能とスリープを確認

システムのネットワーク設定で現在の接続構成を確認し、古い構成や別のツールが作成した項目が選択されていないかを確認します。スリープ、ネットワークの切り替え、アプリの動作によってシステムが接続状態を変更することがあります。ステータスバーのアイコンが消えたかどうかだけで判断しないでください。復帰後はまず一般的なウェブページを開き、クライアントと対象アプリがそれぞれ復旧しているか確認します。

画面ロック後に特定のアプリだけコンテンツを受信できなくなる場合は、そのアプリのバックグラウンド設定と通知権限を確認します。プロキシ接続が復旧しても、アプリ内のすべてのセッションが自動で再開するわけではありません。オンデマンド接続などの機能は、クライアントに実際に備わっている設定を使用してください。該当する項目がない場合、機能を補うために出所不明の構成プロファイルをインストールしないでください。

パソコンのスリープと長時間接続

Windows、macOS、Linuxでも、スリープやネットワークインターフェースの切り替え後に、古いルート、名前解決結果、無効になったセッションが残ることがあります。まずクライアントを通常の方法で停止し、接続を再確立してから対象アプリを開き直します。復帰後だけ問題が起きる場合は、スリープ前後のネットワークと接続状態を記録してください。すぐに再インストールするより、インターフェースの変化を特定する手がかりになります。

会議、コラボレーションツール、Discordなどの長時間接続アプリは、一時的な切断の影響を受けやすい場合があります。ウェブページが開いても、新しいリクエストが完了したことを示すだけで、既存の長時間接続が維持されたとは限りません。テストでは、ページの表示、メッセージの送信、セッションの継続をそれぞれ確認してください。Midjourney関連の接続については、AI画像生成とDiscordの接続ガイドをご覧ください。

再接続を繰り返して原因を見失わない

手動で何度も再接続すると一時的に直ることがありますが、役立つエラー情報が消えたり、対象プラットフォームで再認証を求められたりする場合があります。再接続する前に、エラーと発生のきっかけを記録してください。特定の接続先だけで起きるなら、同じネットワークで別の接続先と比較します。どの接続先でも画面ロック後に切断するなら、地域を何度も変えるのではなく、端末のバックグラウンド設定を優先して確認してください。

「画面ロック後に切断する」場合は、クライアントのプロセス、システムの接続、対象アプリのセッションをそれぞれ確認します。復旧するタイミングは個別に異なるため、いずれか一つの状態だけで全体を判断しないでください。

画面を前面に表示した状態では安定するか、画面ロックや復帰後に毎回起きるか、ネットワークの切り替えで発生するか、再接続後に復旧するかを問い合わせに記載します。必要な情報だけを個人情報を隠して添付し、端末のバックアップ全体は送らないでください。組織管理の端末では、バックグラウンド設定が管理者によって適用されている場合があります。サポートは状況の特定を支援できますが、管理者に代わって端末のポリシーを変更することはできません。

サブスクリプションの更新失敗と通信量の状態

サブスクリプションの更新と実際の接続は、別々の処理です。保存済みの接続先を利用できても、新しいサブスクリプションを取得できるとは限りません。更新に成功しても、対象サイトへアクセスできるとは限りません。まず管理画面の状態を確認し、更新エラーを確認してから、読み込み形式を調べてください。更新の失敗だけでアカウントが無効になったと判断しないでください。

アカウントの状態は管理画面で確認

管理画面にログインし、現在のプラン、有効状態、残り通信量を確認します。ログインできない場合は、古い記録からプランの状態を推測せず、まずアカウントへのアクセスを確認してください。VPNTCはメールアドレス不要で、ユーザー名とパスワードだけで利用登録できます。アカウントに問題があるときに、元のアカウントを確認する代わりに複数のアカウントを作成すると、注文とサブスクリプションの紐付けが分かりにくくなります。

月額サブスクリプションは、¥9.9/月で 60GB、¥18/月で 250GB、¥28/月で 500GBです。通信量は開通日を基準に毎月リセットされます。通信量が戻る時期を確認する際は、暦月から推測せず、管理画面の開通日とリセット情報を確認してください。途中でプランを変更した場合の差額は残り日数に応じて計算されます。変更後のアカウント状態も管理画面で確認してください。

通信量パッケージは ¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで利用でき、有効期限はありません。「有効期限なし」は通信量が無制限という意味ではありません。使い切った場合は管理画面の表示に従ってください。詳しい比較はプラン一覧をご覧ください。トラブルの切り分けでは、まずプランの種類を確認し、有効期間、利用量、設定のどれに問題があるかを判断します。

コピーと読み込みの内容を確認

管理画面から現在のサブスクリプションを取得し直し、クライアントで使用している設定を確認してください。コピー時に空白や改行が混ざったり、チャットアプリによってリンクが別のURLで包まれたりすることがあります。正しい形式を保ちやすいよう、管理画面が提供する読み込み方法を使います。URLを手作業で組み立てたり、ウェブページのタイトルや管理画面のURLをサブスクリプション欄に入力したりしないでください。

サブスクリプションURLにはアカウントへのアクセス情報が含まれるため、認証情報として保護してください。スクリーンショットを撮る前にURL全体を隠します。ドメイン名だけでなく、その後ろのクエリパラメーターも見えないようにしてください。説明資料では明らかなダミー値を使えますが、実際の接続には使用できません。以下は入力欄の形式を示すだけです。実際のサブスクリプションは本人の管理画面から取得し、公開ページで探さないでください。

https://example.com/sub?token=YOUR_TOKEN

エラーの種類から取得経路を確認

更新時にネットワークタイムアウトが表示されたら、現在のネットワークから管理画面にアクセスできるか確認します。次に、プロキシを停止した状態で更新し、結果を比較します。クライアントによってはサブスクリプション取得時にプロキシを経由するか設定できます。設定が実際にどう動作するか確認してください。まだ正常に接続できない古い接続先を使って新しいサブスクリプションを更新しようとすると、相互依存が発生し、更新が失敗し続ける場合があります。

形式エラーが表示された場合、クライアントが期待したサブスクリプションではなく、ウェブページ、ネットワーク接続確認ページ、対応していない形式の設定を受け取った可能性があります。まず公衆ネットワークの接続確認を完了し、管理画面から読み込み先を取得し直してください。アカウントの設定やサーバーパラメーターが含まれる可能性があるため、取得内容を公開フォーラムに貼り付けないでください。

証明書エラーでは、システム時刻とネットワーク上のセキュリティチェック機能を確認します。認証エラーの場合は、URL全体が正しいか、現在のアカウントから取得したものかを優先して確認してください。エラーの原文を見ずに、サーバーの応答を推測しないでください。エラーを送る際は個人情報を隠し、完全なサブスクリプションURLではなく、失敗の種類をサポートに伝えます。

更新後に選択中の設定を確認

更新後は一覧に変化があるか、現在の設定が選択されたままか、以前の接続先が無効になっていないかを確認します。クライアントが古い項目を保持したり、別の接続先を自動選択したりする場合があります。「更新成功」の表示だけで確認を終えないでください。有効な接続先を選び直して接続し、実際に利用するサービスへアクセスします。

古い設定の名前と項目を記録してから、再読み込みを試してください。設定全体を公開の場所へ書き出さないでください。古い項目を削除する前に、新しい項目で接続できることと、参照先が移行済みであることを確認します。

支払いが完了しているのに管理画面の状態が想定と異なる場合は、同じ内容を繰り返し支払わず、注文履歴を確認してください。Alipay / WeChat Pay / USDTに対応しています。注文に問題がある場合は、管理画面から問い合わせて確認できます。VPNTCは 7 日間の無理由返金に対応しています。詳細は利用規約をご覧ください。トラブルの説明と返金の申請は分けて記載すると、内容を確認しやすくなります。

特定のアプリだけプロキシを使えない：ルール分岐を確認

ブラウザーではアクセスできるのに特定のアプリだけ使えない場合は、すべての接続先が使えないと判断する前に、そのアプリのリクエストがクライアントに届いているかを確認します。アプリによって、システムプロキシ、独自のプロキシ設定、直接接続を使う場合があります。デスクトップとモバイルでは通信を処理する方法も異なります。別のプラットフォームでの操作結果をそのまま当てはめず、実際の通信経路を確認してください。

リクエストが記録されるか確認

クライアントの接続ログを開き、対象アプリで一覧の更新やページの読み込みなど、具体的な操作を行います。関連するドメイン、アプリのプロセス、接続情報が記録されるか確認してください。記録がないからといって、アプリが通信していないとは限りません。現在のプロキシ経路を通っていない可能性があるため、アプリのプロキシ設定とクライアントの接続対象範囲を確認します。

記録がある場合は、適用されたルール、接続方法、接続先を確認します。ルールが直接接続を選んでいる場合、それが意図した動作か確認してください。対象アプリはログイン、コンテンツ、リソース、認証などに別々のドメインを使うことがあります。一部のリクエストだけがプロキシを通ると、トップページは表示されるのにログインできない、テキストは表示されるのに添付ファイルを読み込めない、といった問題が起こります。

システムプロキシと仮想ネットワークインターフェース

システムプロキシの影響を受けるのは、通常、その設定に従うアプリだけです。端末のすべての通信が自動的にクライアント経由になるわけではありません。独自のプロキシ設定を持つアプリもあれば、システムプロキシを使わないアプリもあります。クライアントに仮想ネットワークインターフェースモードがある場合、接続対象を広げられますが、ルーティング、権限、ほかのネットワークツールとの互換性にも関わります。何でも解決するスイッチとして扱わないでください。

仮想ネットワークインターフェースモードをテストする場合は、先に元の設定を記録し、競合するツールを通常の方法で終了してから、クライアントの案内に従って権限を許可します。対象アプリが復旧するかに加えて、一般的なウェブサイトやLAN上のリソースも正常に使えるか確認してください。組織の端末、リモートワーク環境、企業用トンネルでは特別なルーティングが使われている場合があります。既存の設定を上書きせず、先に管理者へ相談してください。

グローバルモードはルールの切り分けに限定

グローバルモードに一時的に切り替えてアプリが使えるようになった場合、ルールの適用範囲、DNSとの連携、接続先の選択に問題がある可能性があります。復旧時のリクエストログを保存し、ルールモードに戻して差を確認してください。グローバルモードでも、クライアントが通信を処理する範囲には制限があります。アプリがプロキシに接続していない場合、モードの変更だけでは通信を取り込めないことがあります。

ルールを追加する場合は、クライアントが対応する形式を使い、ルールの順序を確認してください。前方にあるルールが先に適用されることがあり、後から追加したルールが反映されない場合があります。広い範囲のドメインサフィックスやIPアドレス範囲を安易にプロキシルールへ追加しないでください。関係のないサービスの経路まで変わる可能性があります。変更後は対象のリクエストと、もともと正常だったアクセスの両方を確認します。

ターミナルや開発ツールは個別に確認

コマンドラインツールは独自の環境変数や設定ファイルを使う場合があり、ブラウザーと同じプロキシを自動的に使うとは限りません。現在のターミナルに古いプロキシ設定が引き継がれていないか、停止済みのクライアントを参照する設定がないか確認してください。アプリの設定と環境変数は別々に変更してテストします。両方の設定を重ねたままにすると、どちらが有効なのか分からなくなります。

以下のコマンドは、対応するターミナル環境で一般的なプロキシ環境変数を確認するためのものです。出力に内部アドレスや認証情報が含まれる場合があるため、共有する前に隠してください。環境変数が空でも、ツールが独自設定を使う可能性があるため、直接接続している証拠にはなりません。値があっても、クライアントがそのアドレスで接続を提供している証拠にはなりません。

printenv http_proxy
printenv https_proxy
printenv all_proxy
printenv no_proxy

地域に関する表示とネットワークエラーは分けて確認

アプリに地域制限、アカウント制限、認証の要求が明示されている場合は、対象サービスのルールを確認してください。接続先を変えても、アカウントの利用資格が解決するとは限りません。特にAIツールと動画配信では、ウェブサイトにアクセスできることと、アカウントを利用できることは別の問題です。用途を示すラベルが、すべてのプラットフォームや地域で利用できる保証になるわけではありません。

ChatGPTなどのサービスでは、適切な接続元の環境を保ち、目的のない地域変更を避け、ログインページとチャットページで同じように動作するか確認します。詳しい利用方法はChatGPTのログインと継続利用ガイドをご覧ください。動画配信については動画配信の特集を参考にし、コンテンツへのアクセスとアカウントの認証を分けて確認してください。

アプリのリクエストがクライアントに届いていない場合は、通信を取り込む経路を修正します。リクエストは届いているのに誤った接続先が選ばれる場合は、ルールを確認してください。正しい接続先を経由しているのにプラットフォームの制限が表示される場合は、対象サービスの利用条件を確認します。

アプリに関する問い合わせでは、アプリ名、プラットフォーム、失敗する具体的な操作、ブラウザーとの比較、モードの比較を記載します。関連するドメインと適用されたルールを残し、会話内容、仕事のファイル名、アカウント情報は隠してください。サポートに必要なのはリクエスト経路の情報であり、閲覧履歴全体ではありません。個人情報を含まない操作で再現するようにしてください。

プラットフォームの違いと「端末数の上限」表示

VPNTCは Windows / macOS / iOS / Android / Linux に対応し、同時接続端末数に制限はありません。そのため、「端末数の上限」と表示されても、すぐに本サービスのプラン制限と決めつけないでください。表示が管理画面、クライアント、システム、対象プラットフォームのどこに出たのかを確認し、表示場所と原文を記録してから、該当する制限元を調べます。

制限を設定している主体を区別

対象サービスがアカウントのセッション数や再生端末数を制限している場合、OSが同時に有効にできるネットワーク設定を制限している場合、ほかのツールに独自の利用条件がある場合があります。これらはVPNTCの同時接続端末数のルールとは別です。似た表示が出たからといって上位プランを購入せず、まずどの製品の警告かを確認してください。無関係な通信量のアップグレードでは解決できません。

VPNTCの管理画面、または本サービスの設定を使用するクライアントに表示された場合は、前後の状況を記録して問い合わせてください。現在使っているプラットフォームと、再現する操作を伝えます。端末一覧に表示された個人名を公開しないでください。端末数に制限がなくても、アカウント情報を公開してよいわけではありません。アカウントとサブスクリプションは適切に管理してください。

同じ設定で端末を比較

別の端末で正常に使える場合は、まずネットワーク、サブスクリプションの更新時期、選択中の接続先、モードを比較します。これらの条件が近い場合に限り、システムの違いを比較する意味があります。端末ごとに異なるネットワークや接続先を使っている場合、その結果から特定のOSに問題があるとは判断できません。両方でアカウントの状態が同じである証拠にもなりません。

同じネットワークで一台だけ失敗する場合は、権限、システムプロキシ、バックグラウンド設定、競合するソフトを優先して確認します。同じネットワークで全端末が失敗し、別のネットワークでは復旧する場合は、接続経路を確認してください。端末間の比較は現在の症状に関係する範囲で行えば十分です。すべての端末を再インストールする必要はありません。正常な端末を比較対象として残すほうが役立ちます。

デスクトップに残った設定

Windowsでは、システムプロキシが起動中のクライアントを参照しているか確認します。古いプログラムを終了してもプロキシアドレスが残り、すべてのブラウザーが接続できなくなることがあります。macOSでは、ネットワーク拡張機能の許可状態と、現在使っているネットワークサービスの設定を確認してください。使っていないインターフェースを変更しないようにします。どちらのOSでも、まず接続を通常の方法で停止し、終了後に直接アクセスできるか確認します。

Linuxでは、デスクトップのプロキシ設定とターミナルの環境設定が別々の場合があります。GUIアプリは使えるのにターミナルで失敗するなら、ツールの環境を確認します。ターミナルは使えるのにブラウザーで失敗する場合は、デスクトップのプロキシとブラウザー設定を調べてください。すべてのツールの診断を全体環境ファイルで代用したり、接続をそろえるためにシステムのルート設定ファイルを直接上書きしたりしないでください。

モバイル端末とLAN内リソース

モバイル端末では、接続権限、バックグラウンド設定、対象アプリの権限は別々に管理されています。クライアントに接続権限があっても、対象アプリがバックグラウンド通信を許可しているとは限りません。端末の検出、LAN上のファイル、画面共有に影響がある場合は、LAN向けのバイパス設定を確認してください。海外へのアクセスが正常でも、LAN内の通信経路が従来どおりとは限りません。

LANのルールを変更する場合は、現在のネットワークと実際の利用要件に基づいてください。知らないネットワークのアドレス範囲をそのまま使ったり、リモートワークのネットワークを家庭用ネットワークと同じように扱ったりしないでください。社内リソースでは組織のルーティングルールに従い、管理設定に関わる場合は、どの接続先を直接接続にし、どれを企業ネットワーク経由にするか管理者に確認します。

端末に関するVPNTCの仕様は、同時接続端末数に制限がないことです。アプリのセッション数制限、システムのネットワーク設定の競合、アカウントの通信量はそれぞれ別に切り分け、「端末数の上限」と一つの問題にまとめないでください。

クライアントの入手先は管理画面のダウンロードに統一されています。このページでは公開インストーラーを配布していません。再インストールは、設定、権限、競合の確認後に行ってください。再インストールが必要な場合は、必要なエラー情報と設定を個人情報が分からない形で記録してから、本人のサブスクリプションを読み込み直します。再現に役立つ証拠をすべて消してからサポートに連絡しないでください。

問い合わせに必要な情報、復旧確認、設定の切り戻し

問い合わせでは、スクリーンショットをまとめて送るのではなく、再現可能なトラブルの経路を伝えます。通常の使い方、現在失敗する操作、すでに行った比較とそれぞれの結果を説明してください。サポートはその情報から、アカウント、接続ネットワーク、接続先、クライアント、対象サービスのどこに問題があるか切り分けやすくなり、追加のやり取りを減らせます。

サポートへの問い合わせが適切なケース

管理画面のアカウントや注文の状態に問題がある、本人のサブスクリプションを取得できない状態が続く、複数のネットワークで複数の接続先に同じ接続エラーが出る場合は、問い合わせに適しています。証明書エラー、不審な権限要求、設定内容の漏えいが疑われる場合も、繰り返し試すのをやめて確認してください。組織が管理する端末の権限に関する問題は、管理者にも状況を伝える必要があります。

特定のサイトやアプリだけで失敗する場合は、ブラウザー、接続先、モードを比較してから問い合わせます。特定のネットワークだけで失敗する場合は、ネットワークの種類と接続確認の状態を記録してください。画面ロック後だけ失敗する場合は、前面表示中に安定しているか記録します。すべての項目を最後まで試す必要はありません。明確な情報がすでにある場合は、絞り込んだ結果を添えて相談してください。

必要な情報を伝え、認証情報を保護

管理画面の問い合わせフォームから送信し、公開コメント欄にアカウント情報を投稿しないでください。プラットフォーム、クライアントに表示される名前、選択中の接続先、利用モード、問題が起きた時刻とタイムゾーン、対象ドメイン、エラーの原文を伝えられます。端末情報は原因の特定に必要な範囲にとどめ、ハードウェアのシリアル番号一式は不要です。

サブスクリプションURL、パスワード、アクセス認証情報、支払いに関する個人情報、設定全体をスクリーンショットやログに含めないでください。隠すときは本文だけでなく、ブラウザーのアドレスバー、QRコード、設定の詳細、クエリパラメーターも確認します。リクエスト内容がログに含まれる場合は、接続段階やルール適用部分だけを切り出し、仕事の資料や個人的な会話を一緒に送らないでください。

断続的な問題や夜間の遅延では、時間の情報が特に重要です。問題が発生した現地時刻とタイムゾーン、Wi-Fi、有線、その他のどの接続方法を使っていたかを記載します。接続先の名前はクライアントに表示されるとおりに記入し、独自のニックネームで置き換えないでください。そうしないと、サポートが問題を該当する接続先や時間帯と照合しにくくなります。

決まった形式で再現手順を説明

再現手順には、操作、期待した結果、実際の結果を記載します。たとえば、クライアントを起動し、接続先とモードを選んでから対象ページを開き、表示されたエラーを説明します。「使えない」とだけ書かないでください。毎回同じように再現しない場合も、直近の発生時の条件を説明できます。ただし、記録で確認した情報と記憶に基づく情報を分けてください。

問い合わせの記載項目：症状と発生のきっかけ、プラットフォームとネットワークの種類、接続先とモード、エラーの原文、発生時刻とタイムゾーン、実施した比較、現在も再現するか。

添付ファイルには、原因の特定に必要な情報だけを残します。送信前に、サブスクリプションURL、QRコード、アカウント認証情報、個人用ドメイン、業務ファイルの情報を隠したか確認してください。

問い合わせのために、仕事やアカウントへ影響する操作を再度行わないでください。会議の切断、支払い手続き、機密情報を扱うログインは、何度もテストする材料として適しません。個人情報を含まない一般的なページや操作で経路を確認できます。サポートに必要なのは明確なネットワークの状況であり、実際の会話、会議の録音、業務リクエスト全体ではありません。

復旧後は実際の使い方で再確認

接続に成功したら、まずウェブサイトを開き、その後、以前失敗した接続先と操作を確認します。バックグラウンド動作やスリープ復帰時に問題があった場合は、その条件を再現してください。ルールモードで問題が起きた場合は、ルールモードに戻して確認します。グローバルモードでトップページが開いただけでは、アプリのルール分岐、バックグラウンド接続、リソースの読み込みが直ったとは限りません。

接続元の地域、対象サービスの表示、リクエストに適用されるルールが想定どおりか確認し、継続して利用できるか観察します。復旧後の接続先は元と異なっていても構いませんが、現在利用できる設定の組み合わせを記録してください。ログイン環境の変化に敏感なプラットフォームでは、「完全に復旧した」と確かめるために複数の地域へ次々と切り替えないでください。新たなアカウント認証の要因が加わります。

設定を元に戻せる状態を保ち、不要な変更を取り消す

トラブル対応中に一時変更したDNS、アドレスファミリー、グローバルモード、バックグラウンド権限、アプリのプロキシ設定を、一つずつ見直してください。効果があり、目的も理解している変更は維持できます。改善しなかった変更は元の値に戻します。最終的な設定に一時的な対策をいくつも残すと、次の問題が起きたときに必要な設定が分からなくなります。

一時的な対策に依存して復旧した場合は、問題が完全に解決したとして処理せず、問い合わせにその旨を追記してください。その対策が有効だったネットワーク、プラットフォーム、接続先を記録し、「一時的に利用できる」状態と「原因を特定できた」状態を区別します。サポートから追加の変更を案内された場合も、一度に変える要素は一つにし、変更前後を比較して、元に戻せる設定を残してください。

基本用語が分からない場合は、サブスクリプション、接続先、プロトコル、ルール分岐の用語ガイドをご覧ください。利用手順を最初から確認する場合は、初めての方へに戻ります。このページはトラブルの切り分けを説明するもので、アカウント管理画面や対象プラットフォームの利用ルールに代わるものではありません。アカウントの状態、実際のリクエスト経路、復旧後の確認結果を合わせて判断してください。