VPN トラブル診断ガイド

まず診断基準を作る

「使えない」を検証可能な症状に分解する

「接続できない」「遅い」「特定のアプリが使えない」は結果の説明であり、故障箇所ではありません。操作を始める前に、クライアントの表示状態、問題が起きたネットワーク環境、影響を受けるサイトやアプリ、経路を切り替えた際の変化、同じ端末が未接続時に通常のウェブサイトへアクセスできるかを記録します。クライアントが接続中のままなら、ハンドシェイク、プロトコル、ネットワーク入口の問題が考えられます。接続済みなのにドメインを開けない場合は、DNS、システムプロキシ、ルールの問題に近い状態です。動画のバッファリングやファイル転送だけが遅い場合は、経路品質、対象サービス、ローカル回線を確認します。

「すべての対象が失敗する」のか「一つの対象だけ失敗する」のかも分けて考えます。前者では、接続状態、システムプロキシ、デフォルトルート、DNSを優先して確認します。後者では、アプリがシステムプロキシに従うか、対象サービスが現在の出口地域を制限していないか、ルールがドメインを誤って直接接続に振り分けていないかを確認します。一台だけ異常で、同じサブスクリプションが他の端末で正常なら、原因はその端末のクライアント設定、権限、システムネットワークスタックにある可能性が高く、すぐにプランを変更する必要はありません。

証拠を残してからクリーンアップする

最初からクライアントを削除したり、設定を消去したり、システムネットワークをリセットしたりしないでください。完全なクリーンアップを行うと、ログ、エラー表示、比較可能な設定が同時に失われ、後から推測に頼ることになります。安全な順序は、クライアントの状態画面とエラー情報を保存し、現在の経路名とプロトコルを記録し、認証情報を含まない診断ログをエクスポートして、現在の設定を複製することです。その後で経路の切り替え、クライアントの再起動、サブスクリプションの更新を試します。

ログにサブスクリプションURL、アクセストークン、ユーザー名、その他の認証情報が含まれる場合は、送信前に該当部分を隠してください。サポートが通常必要とするのは、エラーの種類、発生時刻、プラットフォーム、クライアント画面の状態、経路名、再現手順であり、完全な認証情報ではありません。サブスクリプションURLの例には、次のように明らかなダミー値を使用します。

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

最小限の変更で比較する

テストでは、まず端末とネットワーク環境を固定し、経路だけを一つ変更します。変化がなければ、経路を固定したままプロトコルだけを切り替え、その後にネットワーク環境の変更を検討します。経路、プロトコル、クライアント、ネットワークを同時に変えると、復旧してもどの操作が有効だったのか分かりません。次に同じ問題が起きた際、また最初から試すことになります。最小変更法は一見遅く見えますが、繰り返し作業を大幅に減らせます。

問題を安定して再現できる場合は、「クライアントを起動し、特定の経路を選び、接続を押し、接続済みと表示された後、ブラウザでテスト用ドメインを開けなかった」のように、手順全体を記録します。「今日はずっと使えない」よりも診断に役立ちます。安定して再現できない場合は、発生前後のネットワーク切り替え、スリープからの復帰、クライアントのバックグラウンド状態、経路の切り替え操作を記録し、OSのライフサイクルに関する問題かを判断します。

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

まず基本ネットワークとシステム時刻を確認する

クライアントがまったく接続を確立できない場合は、まず接続状態を解除し、ブラウザで普段使えるサイトを開きます。通常のウェブサイトも開けないなら、先にローカルネットワークを復旧してください。この状態でVPNHGの経路を何度切り替えても結果は変わりません。無線ネットワークが接続済みでも、利用可能なインターネット出口を取得できているとは限らず、公共ネットワークではブラウザで認証が必要な場合もあります。まずネットワーク自体への接続手続きを完了してから、クライアントを起動します。

システム時刻が大きくずれていると、暗号化ハンドシェイクにも失敗します。証明書の検証や一部のプロトコルは現在時刻に依存するため、端末の長時間停止、タイムゾーン設定の異常、時刻の未同期が、接続直後の失敗として現れることがあります。日付、時刻、タイムゾーンを自動設定に戻したら、クライアントを完全に終了して再度開きます。ここでいう「完全に終了」とは、ウィンドウを閉じるだけでなく、トレイ、メニューバー、バックグラウンドプロセスが終了していることを確認することです。

経路とプロトコルで比較テストを行う

基本ネットワークが正常であることを確認したら、まずノードページでIEPL専線、中継、直結の用途を確認し、異なる地域と経路種別で比較します。一本の経路だけが失敗し、他の経路に接続できるなら、問題はその経路または現在の入口に限られる可能性が高いです。同じ端末ですべての経路が失敗し、他の端末が正常なら、その端末のクライアント権限、システムプロキシ、ネットワーク拡張機能を確認します。

プロトコルの切り替えも、一つの変数だけを変える原則に従います。経路を固定したまま、クライアントが対応するShadowsocks、VMess、Trojan、Hysteria2を切り替え、「すぐにエラーが返る」のか「待った後にタイムアウトする」のかを観察します。すぐに失敗する場合は、設定未読込、権限拒否、プロトコルパラメータの不一致がよくあります。待った後にタイムアウトする場合は、ネットワーク経路に到達できない、入口が制限されている、ハンドシェイクの応答が返っていない可能性が高いです。プロトコル名だけで速度を判断せず、現在のネットワークで安定して接続できるかを重視してください。

クライアントの権限と競合プロセスを確認する

デスクトップOSでは、仮想ネットワークインターフェースの作成、システムプロキシの変更、ルーティングテーブルへの書き込みが必要になることがあります。初回起動時に権限確認をスキップすると、クライアント画面は正常に開いても、接続操作がシステム通信に反映されない場合があります。システム設定で、ネットワーク拡張、仮想インターフェース、バックグラウンド実行の権限が許可されているか確認してください。企業管理端末でネットワーク設定が制限されている場合、クライアントだけでは修復できないため、端末管理者によるポリシー変更が必要です。

同じ端末で複数のプロキシ、フィルタリング、パケットキャプチャ、ネットワーク高速化ツールを同時に実行すると、システムプロキシのポート、仮想インターフェース、デフォルトルートを奪い合うことがあります。切り分け時は他のネットワークツールを完全に終了し、一つのクライアントだけを実行します。復旧したら、他のツールを一つずつ有効にして競合元を確認します。ウィンドウを最小化するだけではバックグラウンドサービスが停止しないことが多いため、システムトレイ、メニューバー、タスク管理画面も確認してください。

ローカルでの試行を止めるタイミング

複数のネットワーク環境、複数地域の経路、複数のプロトコルで同じ失敗が起き、基本ネットワークが正常なら、問い合わせを送ってください。プラットフォーム、クライアント名、エラー文、経路名、プロトコル、発生時刻、実施した比較テストを添付します。他の端末が正常なら、「同じアカウントは他のプラットフォームで接続できる」と明記してください。これにより、サポートが原因を端末設定に絞り込めます。認証情報は送らず、スクリーンショットに完全なサブスクリプションURLを残さないでください。

接続済みなのにウェブサイトが開かない

接続状態・ルーティング状態・名前解決状態を分けて確認する

クライアントに「接続済み」と表示されても、ブラウザの通信が必ずトンネルを通るとは限りません。ウェブアクセスには、システムプロキシ、デフォルトルート、DNS、ブラウザ固有の設定も関係します。まずドメイン名で通常のサイトを開き、コマンドでそのドメインが解決できるか確認します。名前解決に失敗するならDNSを、解決できてもアクセスできないならルート、システムプロキシ、対象サイトを確認します。

ブラウザが独自のプロキシ、拡張機能、セキュアDNSを使っているため、システム設定を利用しない場合もあります。最も分かりやすい比較方法は、ネットワーク拡張機能を入れていない別のブラウザで試すことです。新しいブラウザが正常なら、接続とシステムネットワークはおおむね利用でき、元のブラウザの拡張機能、プロキシ、キャッシュに問題があります。すべてのブラウザで失敗する場合は、システム層を確認します。

システムコマンドでDNSの動作を確認する

コマンドの目的は速度測定ではなく、ドメイン名を解決できるか確認することです。例のドメインを実際にアクセスできないドメインへ置き換えますが、認証パラメータを含むURLを公開ログに貼り付けないでください。

nslookup example.com

ipconfig /flushdns

curl -I https://example.com

nslookupでドメインの結果が返るのにブラウザが失敗する場合、DNSは少なくとも基本的な名前解決を完了しています。次にシステムプロキシと対象への接続を確認します。名前解決がタイムアウトする場合は、クライアントを切断してもう一度実行し、比較します。切断時は正常で接続後に失敗するなら、クライアントのDNSモード、仮想インターフェース、ルール設定の調整が必要な可能性があります。どちらの状態でも失敗するなら、ローカルネットワークまたはシステムの名前解決サービスを先に処理します。

DNSキャッシュの消去は古い名前解決結果を削除するだけで、誤ったルートや使えない経路を修復するものではありません。実行後はブラウザまたは影響を受けたアプリを再起動してください。アプリのプロセスが独自のキャッシュを保持している場合があるためです。消去コマンドを何度も実行し、偶然の復旧を根本原因と判断しないでください。消去前後の名前解決結果を記録します。

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

システムプロキシモードでは、ブラウザは通常OSのプロキシ設定を読み取ります。クライアントを終了した後もプロキシアドレスが残っていると、プロキシポートを待ち受けるプロセスがなく、すべてのウェブアクセスが失敗します。この場合はクライアントを再度開き、「切断」または「システムプロキシを復元」の操作で設定を消去してください。詳しく分からないネットワークインターフェースを手動で削除しないでください。復元後、通常のウェブサイトにアクセスできることを確認してから再接続します。

仮想インターフェースモードでは、ルーティングテーブルを通じて通信を制御します。スリープからの復帰、無線から有線への切り替え、別のネットワークプログラムによるデフォルトルートの書き換え後に、古いインターフェースだけが残ることがあります。まず切断し、システムネットワークが復旧するまで待ってから再接続します。それでも無効なら、クライアントを完全に終了して再起動します。ログを残してから、OSのネットワークリセット機能を検討してください。リセットにより他のネットワーク設定も消える可能性があります。

DNS異常に対する分岐対応

異なる経路で同じドメインの名前解決結果が変わっても、不明なアドレスを手動で固定しないでください。対象サービスが動的に振り分けている可能性があり、古いアドレスを固定すると一時的に使えても再び失敗します。クライアントとシステムの通常の名前解決経路を復元し、経路を切り替えて出口地域が対象サービスの要件に合うか確認する方が安全です。

DNSの名前解決が正常なのにウェブサイトが接続中のままなら、別の対象サイトも同時に試します。関係のない複数のサイトが失敗するなら、ルートとプロキシを引き続き確認します。一つのサイトだけ失敗するなら、そのサイトが特定地域の出口を要求していないか、現在の振り分けルールが不適切な経路へ送っていないかを確認します。一つの対象だけの異常でクライアント全体を再インストールしないでください。

速度低下と混雑時間帯の遅延

ボトルネックがローカル、入口、出口のどこにあるかを判断する

速度は、端末からルーター、ローカル通信網、経路の入口、国際回線、出口地域、対象サービスまでの経路で最も弱い部分に左右されます。一度のピーク速度だけでは安定性を判断できません。同じ端末、同じ対象、同じ方法で、未接続時、現在の経路、別地域の経路を比較し、ページの初回表示、継続ダウンロード、動画のバッファリング、操作遅延にどのような違いが出るかを観察する方が有効です。

未接続時から不安定なら、まず無線信号、ルーターの負荷、ローカルネットワークを確認します。アクセスポイントに近づく、バックグラウンドの大容量同期を止める、有線ネットワークで比較することで、ローカル側の変数を除外できます。ローカルネットワークが正常で、遠距離の経路だけが遅く近隣地域が安定しているなら、経路距離や現在のネットワーク入口が原因かもしれません。一つの経路だけ低下するなら、同じ地域の別の経路種別を優先して試します。

用途に合わせて経路を選び、一度のピーク値を追わない

IEPL専線、中継、直結はそれぞれ異なる経路を使用します。安定した操作、動画再生、長時間接続が必要な場合は、一度の測定値ではなく、継続性、切断、バッファリングを確認します。直結は経路が比較的直接的ですが、実際の動作は現在のネットワーク環境に左右されます。中継は入口の経路を調整できます。IEPL専線は安定性を重視する用途に適しています。利用可能な経路はノード一覧を確認してください。

地域間の距離も操作感に影響します。対象サービスが特定地域にある場合、近い出口を選ぶと余計な迂回を減らせることがあります。ただし、対象サービスが出口地域によって異なるコンテンツを提供する場合は、地域要件も考慮します。ストリーミングの問題はストリーミングの利用地域に関する説明を、AIツールの接続問題はAI高速化の説明を参照してください。これらの特集では対象サービスごとの差異を扱い、本章では一般的な経路の切り分けに集中します。

混雑時間帯の特徴を見分ける

混雑時間帯の遅延は、同じ端末と同じ経路で特定の時間帯だけ速度が継続的に低下し、それ以外の時間帯に戻る形で現れます。確認には同じ条件で異なる時間帯の結果を残す必要があり、端末、無線位置、対象を変えて比較してはいけません。近隣地域の経路も同時に低下し、別の入口や経路種別に替えると改善するなら、まず経路を調整します。未接続時の通常アクセスを含め、すべての通信が遅いなら、ボトルネックはローカル接続にある可能性が高いです。

動画再生では、再生を開始できるかだけを見ないでください。再生開始までの時間、画質が繰り返し低下するか、シーク後に読み込みが続くか、しばらく停止した後にバッファが回復するかを観察します。ファイル転送では継続速度の安定性を、インタラクティブなアプリでは操作への反応と長時間接続の維持を確認します。異なる状況を一括して「遅い」と表現すると、本当のボトルネックを見逃します。

クライアント以外の干渉を減らす

システム更新、クラウド同期、メディアのバックアップ、他の端末による大容量通信は、ローカルの出口帯域を消費します。VPNHGは同時接続台数に制限がありませんが、「接続台数無制限」でも共有ネットワークの帯域が他の端末に使われないわけではありません。切り分け時は既知の大容量通信を停止し、ルーターで通信の優先度を変更するルールが有効になっていないか確認します。特定のアプリだけが遅い場合は、アプリが独自のダウンロードノードを使っていないか、バックグラウンド転送を制限していないかも確認します。

プロトコル設定も、特定のネットワークでの動作に影響することがありますが、無秩序に切り替えないでください。経路を固定し、クライアントが提供する各プロトコルを個別に試し、現在のネットワークでどれが速く接続でき、どれが安定して継続するかを記録します。一つのネットワーク環境でだけ差が出るなら、プロトコルとそのネットワーク経路の適合性に違いがあります。すべての環境で同じように遅いなら、経路と対象サービスを引き続き確認します。

速度の問題で問い合わせる際は、端末のプラットフォーム、基本ネットワークの種類、経路名、プロトコル、影響を受けた具体的な用途、発生時間帯、経路変更後の比較を明記します。速度測定のスクリーンショット一枚だけでは、対象、地域、バックグラウンド通信、継続的な安定性が分かりません。再現手順が詳しいほど、入口、経路、端末設定のどれを調整すべきか判断しやすくなります。

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

経路の中断とシステムによる停止を区別する

頻繁な切断には、接続経路そのものが中断する場合と、OSが画面ロック、スリープ、ネットワーク切り替え後にクライアントを停止する場合があります。前者は前面で使用中にも起こり、経路やプロトコルの切り替えで変化することがあります。後者は画面オフ、省電力、アプリのバックグラウンド移行、無線ネットワークの切り替え後に起こりやすいです。切断した時刻だけでなく、直前に行った操作を記録してください。

デスクトップ端末がスリープ復帰後に戻らない場合は、まず基本ネットワークが再接続されていることを確認し、その後VPNHGを切断して再接続します。システムがネットワークを復旧するには時間がかかるため、クライアントが早く試行すると、無効なインターフェースや古いルートが残ることがあります。毎回の復帰で再現するなら、クライアントログを保存し、ログイン後もクライアントのバックグラウンド実行が許可されているか確認します。

モバイル端末ではまずバックグラウンドと省電力設定を確認する

モバイルOSは、電池残量、温度、バックグラウンド活動、ネットワーク切り替えに応じてアプリを管理します。クライアントがバックグラウンドへ移ると停止され、画面には前回の接続状態が残っていても、実際のトンネルが切れていることがあります。システム設定でクライアントのバックグラウンド活動を許可し、厳しい省電力や休止の対象から外し、システムのVPN設定が他のネットワークアプリに置き換えられていないか確認します。

無線ネットワークとモバイルネットワークを切り替えると、端末の出口が変わり、既存の接続を再確立する必要があります。切り替え後も古い状態のままなら、クライアントで状態を確認し、いったん切断してから接続します。ネットワークが安定する前に接続ボタンを連打しないでください。再試行が増え、ログが読みにくくなります。特定の種類のネットワークだけで切断するなら、同じ経路とプロトコルを固定して個別に試し、そのネットワーク入口が原因か確認します。

デスクトップではスリープ、仮想インターフェース、競合ソフトを確認する

WindowsとmacOSでは、スリープ、ユーザーの高速切り替え、ネットワークインターフェースの変化後に、古いプロキシやルートが残ることがあります。ネットワーク設定を変更するプログラムをすべて終了し、VPNHGクライアントだけを残します。その後クライアントを再起動し、スリープやネットワーク切り替えを再現します。問題が消えたら、他のプログラムを一つずつ戻します。これにより、クライアント自身の復帰失敗か、複数ツールによるネットワーク制御の競合かを確認できます。

Linux環境では、仮想インターフェース、ルート、サービスログを重点的に保存します。デスクトップのネットワーク管理サービスがインターフェース切り替え時にデフォルトルートを書き換えたり、ローカルファイアウォールがネットワーク領域の変化後に別のルールを読み込んだりすることがあります。クライアント画面だけでなく、システムのネットワーク状態も確認します。スクリプトやサービスがクライアントを自動起動する場合は、古いプロセスが終了してから新しいプロセスを起動し、複数インスタンスがポートやインターフェースを奪い合わないようにします。

一見ランダムな断続的切断を調べる

断続的な問題は、証拠が不足していると再試行の繰り返しになりやすいです。切断前に端末がネットワークを切り替えたか、スリープに入ったか、大容量通信が始まったか、クライアントが自動で経路を切り替えたか、切断後も通常ネットワークにアクセスできたかを記録します。通常ネットワークも同時に切れるなら、まずローカルネットワークを処理します。通常ネットワークが正常でトンネルだけが失効するなら、他の経路とプロトコルを比較します。

自動再接続によって問題が見えなくなっただけなのに、解決済みと判断しないでください。自動再接続で利用を復旧できても、切断が続くなら発生条件を特定する必要があります。オンライン会議、リモート端末、継続転送では、短い再接続でもセッションが中断します。より安定した経路種別を選び、競合ツールを終了し、バックグラウンド実行を許可し、作業中に端末がスリープしないようにする方が、再試行回数を増やすより有効です。

サブスクリプション更新に失敗する

まず取得したものがサブスクリプション入口で、ウェブページの内容ではないことを確認する

サブスクリプションのインポートは、ユーザーパネルのダウンロードまたはサブスクリプション欄から行います。マーケティングページのURL、ブラウザのログイン画面、第三者の共有ページをサブスクリプションURLとして使わないでください。VPNHGのクライアントとサブスクリプション入口はユーザーパネルから提供されます。静的ページにはインストーラーへの直リンクや実際のサブスクリプションURLを掲載していません。初回インポートがまだなら、使い方ガイドで取得手順を確認してください。

クライアントに内容の形式エラーが表示されたら、まずパネルからサブスクリプション入口を再コピーし、前後の空白、改行、説明文が混ざらないようにします。実際のURLを公開ページや共有スクリーンショットに貼り付けないでください。文書形式のテストには、明らかなダミー値だけを使用します。

subscription:
  source: "https://example.com/sub?token=YOUR_TOKEN"
  update: manual

ブラウザで開いた結果がログインページ、エラーページ、通常のHTMLなら、クライアントはサブスクリプションの内容として解析できません。この場合は、アカウントのログイン状態、取得入口、クライアントが対応するインポート方法を確認します。返された内容を手動で書き換えないでください。

取得失敗・解析失敗・適用失敗を分ける

サブスクリプションの更新には、クライアントがリクエストを送信し、サーバーが内容を返し、クライアントがノードを解析し、新しい設定を現在の設定セットへ書き込むという段階があります。取得失敗はネットワークエラー、タイムアウト、認証無効として現れます。解析失敗では形式、フィールド、設定のエラーが表示されます。適用失敗では更新成功と表示されても一覧が変わらない、または新しい設定が現在の設定にならないことがあります。

まずエラーの原文を記録します。取得失敗なら基本ネットワークを切り替え、ユーザーパネルを正常に開けるか確認します。解析失敗ならパネルから入口を再コピーし、クライアントが対応する方法でインポートします。適用失敗ならクライアントで現在選択されている設定セットを確認し、更新後の設定が古い設定に上書きされていないか確認します。「ノード一覧が変わらない」だけで、サービスがデータを返していないと判断しないでください。

キャッシュ、古い設定、重複した設定セットを確認する

一部のクライアントはサブスクリプションの結果をキャッシュしたり、同名の設定を複数保持したりします。更新後も古い経路が表示される場合は、まず現在有効な設定セットと設定元を確認し、すべてを直接削除しないでください。古い設定を一時的に無効にしてから再インポートすれば、切り戻し用の経路を残せます。新しい設定が正常に動作することを確認してから、不要な古い項目を削除します。

自動更新タスクは、端末がスリープ中、クライアントが未起動、ネットワークが利用できない場合に失敗することがあります。クライアントを手動で開いて一度更新すると、スケジュールタスクの問題かサブスクリプション入口の問題かを分けられます。モバイル端末でバックグラウンド活動が制限されている場合、自動更新が想定どおり実行されないことがあります。接続のバックグラウンド切断と同様に、システムによるクライアント管理を確認します。

アカウント状態と通信量の期間を確認する

サブスクリプションを突然更新できなくなった場合は、ユーザーパネルでプラン状態と通信量を確認します。月額サブスクリプションの通信量は開通日を基準に毎月リセットされ、途中でのアップグレード差額は残り日数に換算されます。通信量パックは使い切るまで有効で、永久に期限切れになりません。暦月の日付からリセット日を推測したり、何度もインポートしてアカウント状態を変えようとしたりしないでください。パネルの注文情報とサブスクリプション状態を診断の基準にします。

VPNHGの登録にメールアドレスは不要で、ユーザー名とパスワードで完了します。アカウント関連の問い合わせでは、ユーザー名、注文状態画面のスクリーンショット、エラー発生時刻を提示し、パスワードは送らないでください。クライアントが認証失敗を報告してもパネルにログインできる場合は、サブスクリプション更新のエラー文を添付します。パネルにも入れない場合は、ユーザー名の入力とパスワードの管理記録を確認します。

複数のクライアントが同じサブスクリプションに対して同じエラーを返し、パネルのプラン状態が正常なら、設定の削除を繰り返さず問い合わせを送ってください。どのプラットフォームで試したか、取得段階が成功したか、ネットワークエラーか解析エラーかを説明します。一つのクライアントだけが失敗するなら、そのクライアントのログを優先してエクスポートし、別の対応プラットフォームと比較します。

特定のAppがプロキシを経由しない

まずアプリがシステムプロキシに従うか確認する

ブラウザはアクセスできるのに特定のAppだけアクセスできない場合、経路の故障ではなく、アプリがシステムプロキシを読み取らないことがよくあります。アプリによっては直接ネットワーク接続を確立したり、独自のネットワークスタックを使ったり、起動時だけプロキシ設定を読み取ったりします。VPNHGに接続した後、影響を受けるアプリを完全に終了して再度開き、システムネットワークの状態を再取得させます。ウィンドウを閉じるだけではバックグラウンドプロセスが残り、古い接続を使い続けることがあります。

クライアントにシステムプロキシと仮想インターフェースのモードがある場合、現在の経路を維持したままモードを切り替えて比較します。システムプロキシはOSのプロキシ設定に従うアプリに適しています。仮想インターフェースはシステムプロキシを読まない通信もより広く扱えますが、システム権限、ルート、DNS設定への依存も大きくなります。切り替え後はまず通常のウェブサイトを確認し、その後に対象アプリを試して、追加されたシステム問題をアプリの問題と取り違えないようにします。

振り分けルールが実際に何へ適用されたかを確認する

ルールモードでは、ドメイン、アドレス、アプリのプロセスに応じて直接接続とプロキシを決めます。対象サービスが複数のドメインを使う場合、メインページがプロキシを通っていても、ログイン、メディア、API、ファイル用のドメインが同じ経路を使うとは限りません。クライアントに接続ログやルール適用記録があれば、対象アプリを開いたときに現れるリクエストを観察し、関連ドメインがどのルールに振り分けられたかを確認します。

ルールは通常、より具体的な条件から広い条件へ順に照合されます。カスタムルールの位置が不適切だと、前にある一般的な直接接続ルールが先に適用されることがあります。変更前に現在の設定をエクスポートして切り戻せるようにします。変更後はアプリを完全に再起動し、アプリ自身が保存した接続状態を消去します。ドメインの用途が分からないまま、すべての通信を長期的に同じ経路へ変更しないでください。まず明確な対象だけを解決します。

ブラウザは正常でデスクトップアプリだけ異常な場合

デスクトップアプリが独自のプロキシ設定を持つことがあります。アプリ内部に古いアドレス、古いポート、「直接接続」が設定されていると、システム設定が上書きされます。アプリのネットワーク設定を確認し、「システムに従う」または現在のクライアントモードに合う設定を優先します。以前にプロキシアドレスを手動入力した場合は元の値を記録してから、自動またはシステムモードに戻して試します。

アプリの更新後にネットワークコンポーネントが変わり、古いルールのプロセス名と一致しなくなることもあります。この場合、プロセス名だけに依存するより、ドメインルールの方が確認しやすいです。プロセスルールが必要なら、システムのタスク情報で実際に通信を開始しているプロセスを確認します。アプリのウィンドウ名だけを根拠にしないでください。補助プロセス、更新プロセス、メインプロセスがそれぞれ接続を作る場合があります。

モバイルアプリと埋め込みウェブページを確認する

モバイルアプリには、ネイティブAPI、埋め込みウェブページ、メディアリクエストが同時に含まれることがよくあります。ログインページは開くのに内容の読み込みだけ失敗する場合、異なるリクエストが別のルールを通っているか、出口地域が対象サービスの要件に合っていない可能性があります。まず対象サービスに合う地域の経路を選び、ルールログでドメインを確認します。地域を変えると復旧するなら有効な地域を記録します。すべての地域で同じように失敗するなら、アプリのバージョン、キャッシュ、システムDNSを確認します。

アプリがバックグラウンドから復帰すると、切断前の長時間接続を使い続けることがあります。前面に戻っても読み込みが続く場合は、アプリのプロセスを完全に終了して再度開きます。モバイルOSのバックグラウンド制限がVPNクライアントも停止させることがあるため、まずシステムVPNの状態が有効か確認してから、対象アプリ自体を判断します。

制御範囲を広げず、最小限のルールで修正する

ルールの問題を調べるときは、対象アプリの明確なドメインまたはプロセスから始めます。最初から範囲の広いルールを追加すると、本来直接接続すべきローカルサービスまで経路が変わり、ログイン、地域、速度に新たな問題が起きる可能性があります。一度に追加するのは説明可能な条件の一種類だけにし、成功後に用途を記録します。後で対象サービスのドメインが変わっても、どのルールを更新すべきか分かります。

対応プラットフォームすべてで同じアプリに問題が起き、ブラウザではそのウェブサイトが正常なら、対象サービス側のアプリAPIポリシーも考慮します。具体的な失敗画面、エラー文、出口地域を提示する方が、「Appが使えない」とだけ説明するより有効です。サポートはその情報をもとに経路側のアクセス状況を確認できますが、アプリ名だけでは実際のリクエストを推測できません。

端末数の表示、アカウント確認、問い合わせ

端末数の表示が出たら、まず表示元を確認する

VPNHGは同時接続台数に制限がありません。クライアントに「端末数が多すぎる」「セッションが制限されています」などの表示が出ても、すぐにVPNHGのプラン制限だと判断しないでください。表示元がVPNHGのユーザーパネル、本サービスのクライアント、OS、別のアプリのどれかを確認します。第三者クライアントがローカル設定、同期アカウント、接続セッションに独自の制限を設けている場合があり、その表示はサーバー側の端末数制限を意味しません。

複数のクライアントインスタンスを重複起動していないか、古いプロセスがバックグラウンドで接続を保持していないかも確認します。同じ端末上の重複インスタンスは、ポート、システムプロキシ、仮想インターフェースを奪い合い、端末数に関係するように見えるエラーを出すことがあります。クライアントを完全に終了し、残ったプロセスを停止してから、一つのインスタンスだけを起動して接続を試します。表示が続く場合は、エラー文全体と表示場所を保存します。

ユーザー名、プラン、注文状態を確認する

アカウントの異常はユーザーパネルから確認します。VPNHGの登録にメールアドレスは不要で、ユーザー名とパスワードで登録できるため、アカウントの復旧や確認では実際のユーザー名を基準にします。パネルに入り、プランが有効か、サブスクリプション入口が表示されるか、通信量が正常か、注文状態が完了しているかを確認します。支払い方法はAlipay、WeChat、USDTに対応しています。注文状態と実際の支払い状況が一致しない場合は、問い合わせに注文ページの情報を添付し、区別できない注文を繰り返し作成しないでください。

月額サブスクリプションは¥9.9/月・60GB、¥18/月・250GB、¥28/月・500GBで、通信量は開通日を基準に毎月リセットされ、途中のアップグレード差額は残り日数に換算されます。通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効で永久に期限切れになりません。通信量や期間の問題を調べる際は、月額サブスクリプションか通信量パックかを先に確認し、月額サブスクリプションのリセット規則を通信量パックに当てはめないでください。詳しい規則はプランページで確認できます。

そのまま問い合わせるべきケース

比較テストを行っても原因を特定できない場合、または注文、アカウント状態、サブスクリプションの返却内容、複数経路の同時異常に関わる場合は、問い合わせを送ります。技術的な問題では、少なくともプラットフォーム、クライアント、経路、プロトコル、ネットワーク環境、エラー原文、発生時刻、再現手順を記載します。アカウントの問題では、ユーザー名、注文状態、パネルに表示された結果を記載します。経路、プロトコル、端末の比較を済ませている場合は、それぞれの結果も書き、同じテストを繰り返さないようにします。

次のような場合は、無秩序な再試行を続けないでください。複数のネットワーク環境で接続できない、複数のクライアントで同じサブスクリプションを解析できない、パネルの状態とクライアントの認証結果が一致しない、同じ障害を安定して再現できログも保存済み、注文完了後にパネルの状態が更新されない場合です。設定を削除し続けると証拠が壊れる可能性があるため、構造化した情報を送る方が有効です。

問い合わせに添付するもの

問題の種類：接続 / ウェブアクセス / 速度 / 切断 / サブスクリプション / アプリ振り分け
端末のプラットフォーム：
クライアント：
経路名：
プロトコル：
ネットワーク環境：
発生時刻：
エラー原文：
再現手順：
実施したテスト：
比較結果：

スクリーンショットにはエラー表示とクライアント状態を含めますが、パスワード、完全なサブスクリプションURL、アクセストークン、その他の認証情報は隠します。ログにはエラー前後の接続過程を残せば十分で、問題と無関係な全履歴をアップロードする必要はありません。ファイルに機密項目が含まれる場合は、コピーを作成してからマスキングし、唯一の元ログを直接編集して文脈を失わないようにします。

断続的な問題と性能問題の説明方法

断続的な問題には時系列が必要です。問題が起きる前に端末で何をしていたか、ネットワークを切り替えたか、スリープしたか、通常ネットワークも同時に異常だったか、自動再接続が成功したかを記載します。性能問題では、影響を受けた用途、経路の地域、経路種別、発生時間帯、比較した経路を明記します。「とても遅い」と一言書くだけでは、ローカル無線、国際経路、対象サービス、バックグラウンドタスクを区別できません。

特定のウェブサイトやAppだけに影響する場合は、対象名、エラー画面、ブラウザとアプリの比較、選択した出口地域、ルールの適用結果を提示します。ストリーミングの地域コンテンツの違いなら、作品名だけでなく、対象プラットフォーム、選択地域、クライアント状態を説明します。AIツールの接続異常なら、ウェブ版とアプリ版で同じか、経路を切り替えると変化するかを記載します。

対応後の回帰確認

問題が復旧したら、現在のページが開くことだけを確認せず、最初に記録した再現手順をもう一度実行します。接続の問題では切断と再接続を、DNSの問題では元の対象ドメインを再解決します。切断の問題では画面ロック、スリープ、ネットワーク切り替えを再現します。サブスクリプションの問題では更新後の新しい設定が実際に有効か確認します。アプリ振り分けの問題ではアプリを再起動し、関連機能を検証します。

特定のカスタムルール、プロトコル、経路種別で修復できた場合は、有効な設定と適用場面を記録します。OSの更新、クライアントの再インストール、サブスクリプションの再インポート後にすぐ復元できます。同時にデフォルト設定のコピーも残し、新しい問題が起きたときに初期状態と比較できるようにします。変更を長期的に積み重ねて相互に影響させないことが重要です。

トラブル解決のゴールは、「何度か試したら一時的に復旧した」ではありません。障害がどの層にあり、どの操作で結果が変わり、サーバー側の確認が必要かを説明できることです。本ガイドに沿って基準を残し、一つの変数ずつ比較し、必要な情報をそろえて問い合わせれば、繰り返しのやり取りを減らし、同じ問題が再発した際にも結論を再利用できます。