このVPN初心者向けFAQでは、用語の説明から始めず、実際の利用で生じやすい疑問を解説します。複数デバイスでの共有、通信量、速度変化、常時接続、サブスクリプションURLの導入など、クライアントをインストールした後に直面しやすい問題を整理します。アカウント、クライアント、プロトコル、回線の役割を理解すれば、再インストールを繰り返さずに原因を切り分けられます。
複数デバイスと通信量の計算方法
質問：1つのアカウントを複数のデバイスで利用できますか？
複数デバイスで利用できるかどうかは、プロトコル名ではなく料金プランの規則で決まります。VPNHJは台数制限なしで利用できるため、パソコン、タブレットなどの個人デバイスで同じアカウントの設定を使えます。ただし「台数制限なし」は、各デバイスに個別の通信量が付与されるという意味ではありません。同じプランのデバイスは通常、プランの通信量を共有し、どのデバイスで発生したアップロードとダウンロードも同じ残量に加算されます。
複数デバイスで共有する場合は、各デバイスのクライアント設定に、プラットフォームや用途が分かる名前を付けると便利です。回線の変更、サブスクリプションの更新、接続トラブルの確認時に、どの設定を使っているか迷わずに済みます。アカウントのパスワードとサブスクリプションURLは、利用者以外に共有しないでください。サブスクリプションURLには設定取得に必要な認証情報が含まれることが多く、漏えいするとデバイスが1台増えるだけでなく、ノード情報を継続的に取得されるおそれがあります。
質問：通信量はどのように計算され、クライアントと管理画面で表示が異なるのはなぜですか？
通信量には通常、プロキシやトンネルを通過するアップロードとダウンロードが含まれます。ウェブ閲覧、動画再生、ファイル同期ではダウンロードが発生し、添付ファイルの送信、クラウドバックアップ、ビデオ通話ではアップロードも発生します。システム更新、写真の同期、バックグラウンドアプリの更新でも通信量を消費するため、「自分でファイルをダウンロードしていない」ことは、通信が発生していないという意味ではありません。
クライアント、OS、サービス管理画面では、集計範囲が異なる場合があります。OSのネットワーク統計はデバイス全体の通信を記録することがあり、クライアントは自身の接続を通過した通信だけを記録する場合があります。サービス管理画面は、サーバーが実際に受信・転送したデータを基準に計算します。プロトコルのカプセル化、再送、接続維持にも追加通信が発生するため、複数の数値が完全に一致するとは限りません。プラン残量はサービス管理画面を基準にし、どのアプリが多く消費したかはOSまたはクライアントのアプリ別統計で確認してください。
| 利用操作 | 通信量が発生するか | 見落としやすいポイント |
|---|---|---|
| ウェブ閲覧とストリーミング | アップロードとダウンロードの両方で発生 | 先読み、自動再生、キャッシュ更新 |
| ファイル同期 | アップロードとダウンロードの両方で発生 | バージョン同期、サムネイル、失敗時の再送 |
| ソフトウェア更新 | 主にダウンロード通信が発生 | クライアントやシステムがバックグラウンドで更新する場合がある |
| ビデオ通話 | 双方向の通信が継続的に発生 | カメラ映像は継続的なアップロードにあたる |
速度制限の判断と常時接続
質問：速度が遅くなったら、サービスによる速度制限ですか？
必ずしもそうとは限りません。実際の速度は、利用中のアクセス回線、無線信号、デバイス性能、プロトコルの実装、ノードの負荷、回線トポロジーの影響を受けます。同じ地域を選んでも、直接接続、中継、IEPL専線では経路が異なります。ノードが同じでも、自宅回線の出口や国際ネットワークの経路は時間帯によって変化します。1回のダウンロード結果だけでは原因を判断できません。
切り分けるときは、変更する要素を1つに絞ります。クライアント、プロトコル、ノード、ネットワークを同時に変えると、結果を再現できません。まず接続を切ってローカルネットワークが正常か確認し、近い地域のノードに接続します。それでも問題があれば、同じ地域の別の回線に切り替え、最後にプロトコルを比較します。ブラウザーのダウンロード、動画のバッファリング、速度測定ツールは利用するサーバーが異なるため、結果をそのまま同じ条件で比較しないでください。
- ✅ 未接続時のローカルネットワークを確認し、パケットロスや無線信号の問題がないか確かめます。
- ✅ デバイスとネットワークを固定し、ノードだけを1つずつ変更して、ウェブ閲覧、ダウンロード、リアルタイムアプリが同時に改善するか観察します。
- ✅ ノードの変更で改善しない場合は、プロトコルとクライアントのカーネルを比較し、問題を再現できる設定を残します。
- ❌ 一時的な1回の結果だけで回線を判断したり、すべての項目を同時に変更したりしないでください。
質問：VPNは常に接続しておく必要がありますか？
常時接続が必要かどうかは利用場面によります。公共Wi-Fi、特定地域の出口を必要とするアプリ、国際サービスへの継続的なアクセスでは、接続を維持すると頻繁な切り替えを減らせます。一方、特定のアプリだけに国際回線が必要な場合、全体を常時接続すると、国内サイト、プリンター、LANストレージ、システム更新まで不要な経路を通ることがあります。この場合は、機械的に接続をオン・オフするより、分割トンネリングを設定する方が適切です。
モバイルプラットフォームでは、OSのバックグラウンド制御の影響も受けます。デバイスがスリープしたり、Wi-Fiを切り替えたり、省電力状態になったりすると、OSがクライアントを一時停止し、ネットワーク復旧時にトンネルを再構築することがあります。ステータスバーに接続アイコンが表示されていても、実際の接続確認の代わりにはなりません。常時接続する場合は、クライアントが切断時の再接続に対応しているか、ネットワーク切り替え後にDNSとルーティングがトンネルとともに復旧するか確認してください。
サブスクリプションURLとデバイス移行
質問：サブスクリプションURLとは何ですか？どのように導入しますか？
サブスクリプションURLは、クライアントがノード設定を取得するための入口です。通常のウェブページや、ブラウザーで読むファイルではありません。対応クライアントがURLにアクセスし、ノードのアドレス、ポート、プロトコル、接続パラメーターを解析して、選択可能なノード一覧を生成します。サーバー側でノードが調整された場合も、サブスクリプションを更新すれば新しい設定を取得でき、項目ごとの手動変更は不要です。
導入方法はクライアントによって異なります。一般的には「サブスクリプションを追加」「URLからインポート」「リモート設定」などの項目を使います。管理画面からURL全体をコピーし、クライアントのサブスクリプションURL欄に貼り付けて更新します。ノード名、サーバーアドレス、ブラウザーの検索欄に貼り付けても、正しい設定は取得できません。導入後は、ノード一覧が表示されたことを確認してからノードを選び、接続してください。
サブスクリプションURLはアカウントの認証情報と同じように管理してください。チャットグループ、スクリーンショット、公開メモ、問い合わせ本文に掲載しないでください。サポートに不具合を伝える際は、クライアント名、OS、エラーメッセージ、再現手順を伝えれば十分で、URL全体を添付する必要はありません。漏えいが疑われる場合は、管理画面で利用可能なリセット方法を使い、すべてのデバイスで設定を更新してください。
質問：パソコンやOSを変更した場合、どのように移行しますか？
最も確実な移行方法は、クライアントのフォルダー全体をコピーすることではありません。新しいデバイスに対応するクライアントをインストールし、管理画面からサブスクリプションURLを再取得してください。クライアントの設定ファイルには、旧OSのパス、ネットワークインターフェース名、キャッシュされたノード、ローカルの分割トンネリングルールが含まれることがあり、そのまま移すと旧環境の問題まで引き継ぐおそれがあります。
- 旧デバイスで使用中のプロトコル、よく使うノード、カスタム分割トンネリングルールを記録し、公開共有されたサブスクリプションURLはコピーしません。
- 新しいデバイスにOSに合ったクライアントをインストールし、サブスクリプション内のプロトコルに対応していることを確認します。
- 管理画面からサブスクリプションURLをもう一度コピーし、新しいクライアントのサブスクリプション欄に導入して更新します。
- まずデフォルトルールで接続をテストし、その後、カスタムDNS、分割トンネリング、起動オプションを少しずつ戻します。
- 新しいデバイスが正常に動作することを確認したら、使用しなくなった古い設定とローカルキャッシュを削除します。
移行後に「ノードはあるのに接続できない」場合、よくある原因は、新しいクライアントが該当プロトコルに対応していないこと、OSの権限が許可されていないこと、古い分割トンネリングルールの形式が合わないこと、ローカルネットワークがプロトコルの通信方式を制限していることです。最初から高度な設定をすべて導入するより、まずクライアントのデフォルト設定で試す方が原因を見つけやすくなります。設定の移行は作業台の引っ越しに似ています。まず道具を移し、引き出しの中の過去の設定は後から確認しましょう。
プロトコルの選択と回線トポロジー
質問：Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはどう選びますか？
プロトコルは、クライアントとサーバーが接続を確立し、データをカプセル化して転送する方法を決めますが、プロトコル名だけで回線品質が決まるわけではありません。Shadowsocksは軽量な暗号化プロキシ方式で、対応クライアントが多く、ルールによる分割に適しています。VMessは成熟したプロキシ環境でよく使われ、設定項目が比較的豊富です。VLESSはプロトコル層の負荷を一部減らし、さまざまな転送方式やセキュリティ層と組み合わせて使われます。TrojanはTLSに近い形で通信を運びますが、実際の性能は証明書、転送方式、サーバー設定に左右されます。
Hysteria2とTUICはQUICおよびUDPを軸に設計され、高遅延、ジッター、パケットロスがある環境での転送効率を重視します。ただし、すべてのネットワークで高速になるわけではありません。ローカルネットワークがUDPに対応していない場合、接続が不安定になったり確立できなかったりするため、TCPベースの方式が適することもあります。プロトコルは、現在のネットワークとの互換性、クライアントの対応状況、安定して再現できるかを基準に選びましょう。
| プロトコル | 主な特徴 | 選択時の確認事項 |
|---|---|---|
| Shadowsocks | 軽量なプロキシで、対応クライアントが多い | 暗号化方式と分割トンネリング設定の互換性 |
| VMess | 設定の組み合わせが多く、エコシステムが成熟している | 転送層のパラメーターが完全に導入されているか |
| Trojan | 通常はTLSと組み合わせて転送する | ドメイン、証明書、システム時刻が正常か |
| VLESS | プロトコル層が簡潔で、異なる転送方式と組み合わせられる | クライアントがサブスクリプション内の組み合わせに対応しているか |
| Hysteria2 | QUICおよびUDP転送向け | 現在のネットワークがUDPを安定してサポートしているか |
| TUIC | 同じくQUICを軸とした転送設計 | クライアントのカーネルとサーバー側パラメーターが一致しているか |
質問：直接接続、中継、IEPL専線にはどのような違いがありますか？
直接接続は、デバイスが海外のノードに直接接続する方式です。経路が単純で中継が1段少ない一方、現地の通信事業者から対象地域までの公衆ネットワーク経路に左右されやすくなります。中継では、まず近い入口に接続し、入口から出口ノードへ通信を転送します。好ましくない公衆ネットワーク経路を避けられる場合がありますが、転送が1段増えるため、入口の品質、内部回線、出口の状態も結果に影響します。
IEPL専線は通常、専用の国際接続リソースで国際区間の通信を運ぶ方式を指し、一般的な公衆ネットワークの直接接続や通常の中継とは経路の構成が異なります。経路をより管理しやすい点に価値がありますが、どの時間帯、どのローカルネットワークでも混雑しないという意味ではありません。デバイスから入口までの区間はローカルネットワークを通り、出口から対象サービスまでの最後の区間も対象サイトや地域ネットワークの影響を受けます。
選び方はシンプルで構いません。まず近い地域で安定する回線を試し、リアルタイム通話やリモート操作などジッターに敏感な用途では中継やIEPLと比較します。大容量ファイルの転送では、継続的なスループットと再送も確認してください。同じ地域名でもトポロジーが同じとは限らず、ノードの備考にある直接接続、中継、専線の情報の方が、旗印より判断材料になります。
DNS、分割トンネリング、プラットフォーム別クライアント
質問：DNSリークとは何ですか？分割トンネリングが原因になることはありますか？
DNSはドメイン名をネットワークアドレスに変換します。接続後、ウェブ通信はトンネルを通っているのに、ドメインの問い合わせだけがローカルネットワークのリゾルバーに送られると、DNSリクエストとプロキシ経路が一致しない状態になることがあります。一般にDNSリークと呼ばれる状態です。必ずしもウェブサイトが開けなくなるわけではありませんが、ドメインの名前解決が想定外の経路に露出し、解決地域の違いによって適切でないアドレスが返される可能性があります。
分割トンネリング自体はリークではありません。ドメイン、アドレス、アプリ、ルールセットに応じて、通信をプロキシ経由にするか直接接続にするか決める仕組みです。問題は、DNSの名前解決と分割の判断が一致しない場合に起こりやすくなります。クライアントがドメインに対応するアドレスを取得する前にルールを正しく照合できなかったり、ブラウザーのセキュアDNSがクライアント設定を迂回したり、ネットワーク切り替え後にOSがローカルリゾルバーへ戻ったりすることがあります。
切り分けでは、クライアントのDNSモード、システムDNS、ブラウザーのセキュアDNS、分割トンネリングルールが互いに整合しているか確認します。接続後は、公開ネットワークアドレスとDNSリゾルバーが想定地域になっているかを確認し、プロキシルールと直接接続ルールに含まれるドメインへそれぞれアクセスします。特定のブラウザーだけに問題がある場合はブラウザーの名前解決設定を、すべてのアプリに問題がある場合はクライアントとシステムのネットワーク設定を確認してください。
- ✅ DNSの処理方法を分割トンネリングのモードに合わせ、ドメインが分類される前に誤った経路へ送られないようにします。
- ✅ ネットワークの切り替えやデバイスの復帰後に接続を再確認し、ルーティングとDNSが復旧しているか確かめます。
- ✅ ルールを変更した後は古いDNSキャッシュを削除し、以前取得したアドレスを使い続けないようにします。
- ❌ 「ウェブサイトが開く」ことだけを、DNS経路が正しい唯一の根拠にしないでください。
質問：Windows、macOS、iOS、Androidのクライアントで動作が異なるのはなぜですか？
各プラットフォームでは、利用できるネットワークインターフェース、バックグラウンド実行権限、システムプロキシ機能が異なるため、同じサブスクリプションでもクライアントによって動作が変わることがあります。デスクトップでは通常、ルーティング、システムプロキシ、仮想ネットワークアダプター、ログの項目が細かく、複雑な分割トンネリングの調整に向いています。モバイルプラットフォームではOSのVPNインターフェースへの依存が大きく、スリープ、省電力、バックグラウンド制御の制限も受けます。
システムプロキシモードは、システムプロキシ設定に従うアプリに主に影響します。仮想ネットワークアダプターやシステムVPNモードでは、より広い範囲のネットワーク通信を処理できます。一部のコマンドラインツール、ゲーム、独自にネットワーク接続を確立するアプリはシステムプロキシを無視する場合があるため、ブラウザーが正常でもすべてのプログラムが同じ経路を使うとは限りません。その場合はノードだけを切り替えず、クライアントが現在、システムプロキシ、仮想ネットワークアダプター、アプリ単位のプロキシのどれを使っているか確認します。
iOSとAndroidでは、バックグラウンド接続、アプリ別の分割、常時接続オプションにもそれぞれ制限があります。デスクトップの設定がそのままモバイルで使えるとは限らず、逆も同様です。ルーター側では、ファームウェア、処理性能、プロトコル対応状況に左右され、サブスクリプションURLを貼り付ければ必ず使えるわけではありません。クライアントを選ぶ際は、対応プロトコル、エラーログの表示、必要な分割方式への対応を、ボタンの多さより重視してください。
この10の疑問は、1つの切り分け手順にまとめられます。まずアカウントとサブスクリプションが有効か確認し、次にクライアントがプロトコルに対応しているかを確認します。その後ノードと回線を確認し、最後にDNSと分割トンネリングを調整します。デバイス数、通信量の統計、速度、プラットフォームの違いはそれぞれ別の階層に属するため、混同するとトラブルが不規則に見えてしまいます。