プロトコルと回線の技術ガイド

接続の階層と切り分けの順序

アプリのリクエストから出口まで

ブラウザーでページを開く際は、通常、まずドメイン名を解決し、次に通信接続を確立してから、アプリケーション層の安全な通信を確立し、コンテンツをリクエストします。プロキシを使う場合、クライアントはどのリクエストをプロキシ経由にするか判断し、データをリモート側の入口に送ります。その後、リモート側から目的のサービスにアクセスします。ここには、端末、接続ネットワーク、プロキシの入口、出口側のネットワーク、目的のサービスなど、複数の区間があります。どこか一つに問題が起きても、ページの読み込みが続くように見えることがありますが、対処すべき場所はそれぞれ異なります。通信の流れを理解しておけば、アカウントの問題、名前解決の問題、目的のサービスの障害を、すべて回線の遅さとして扱うことを避けられます。

プロトコル名は、クライアントとリモート側が認証、データのカプセル化、通信処理をどのように取り決めるかを示します。伝送層は、データの到達や再送を担います。たとえば、TCPによる信頼性の高いバイトストリームや、UDP上に構築されたQUICがあります。ネットワーク経路は入口から出口までの経路を示し、クライアントのモードはアプリの通信がその経路に入るかどうかを決めます。これらは連携しますが、互いに置き換えられるものではありません。プロトコルを切り替えても、接続先サイトのアカウント地域が自動的に変わるわけではありません。また、全通信をプロキシ経由にしても、物理的に遠い経路が短くなるわけではありません。

接続できない・表示が遅い・途中で止まる場合の違い

接続できない場合は、まず接続が確立しているか確認します。クライアントに認証エラーが表示されたら、アカウントのサブスクリプション状態と設定が最新か確認してください。入口への接続がタイムアウトする場合は、ローカルネットワークと現在の回線を確認します。表示が遅い場合は、最初のリクエストだけ遅いのか、その後も遅いのかを切り分けます。初回の表示だけが遅く、その後の操作はスムーズなら、名前解決、ハンドシェイク、または新規接続の確立に時間がかかっている可能性があります。毎回の操作が遅い場合は、継続的な往復遅延、通信待ち行列、アプリ自体が原因かもしれません。通信中に何度も止まる場合は、パケットロス、混雑、クライアントのリソース消費を確認しましょう。

1つのページが1つのリクエストだけで構成されているとは限りません。テキスト、画像、スクリプト、動画が異なるドメインから読み込まれたり、別々のプロキシルールに適用されたりすることがあります。そのため、トップページが開いても、すべてのリソースが同じ出口を使っているとは限りません。切り分けでは、固定したページを開いて同じ機能を使うなど、繰り返し実行できる操作を選び、クライアントの接続ログを確認します。画面上の接続スイッチを見るだけでは、クライアントが動作中であることしか確認できず、特定のアプリの通信が正しく処理されているかは分かりません。

比較できる条件を整える

比較する際は、ほかの条件をできるだけそろえることが大切です。同じ接続先、同じネットワーク、同じクライアントモードで試し、まず回線だけを変更し、次にプロトコルだけを変更します。地域、プロトコル、名前解決の方式、ルールセットを同時に変更すると、使い心地が改善しても、どの変更が効果をもたらしたのか分かりません。記録は簡単で構いません。対象の機能、発生した症状、ネットワークの種類、回線名、変更内容を書き留めましょう。背景の分からない速度のスクリーンショットより、クライアントログに表示されたエラーの種類のほうが、問題の再現に役立ちます。

クライアントに表示される遅延、アプリの応答時間、実際のダウンロード速度は区別して考えましょう。遅延の測定では1つのテスト用アドレスにアクセスするだけの場合がありますが、アプリのリクエストには認証、データベース、コンテンツ配信が関係します。ダウンロード速度も、接続先による速度制限、ローカル回線の帯域幅、無線電波、同時に実行中のタスクに左右されます。各指標は互いを補うものですが、どれか1つだけで全体的な使い心地を判断することはできません。特に、テストに成功したからといってすべての接続先にアクセスできるとは限りません。また、短時間のダウンロード速度のピークを、終日維持できる性能と見なさないでください。

本ページで比較するのは技術的な仕組みであり、VPNXBが提供するプロトコルの一覧ではありません。実際に利用できるプロトコル、伝送方式、回線名は、ログイン後に取得するサブスクリプションとクライアントの表示をご確認ください。ここで紹介するプロトコルが、VPNXBのすべての回線で選べるとは限りません。

セキュリティも階層ごとに考える必要があります。サービスが「銀行レベルの暗号化」をうたっていても、サイトの証明書、アカウント権限、端末の安全性を気にしなくてよいわけではありません。プロキシ接続で保護される範囲と、アプリ自体のHTTPSによる保護範囲は異なります。通常の利用では証明書の検証を有効にし、トラブルシューティングのために安全性の確認を長期間無効にしないでください。証明書エラーが発生した場合は、検証を回避して速度を上げようとするのではなく、まずシステム時刻、接続先ドメイン、サブスクリプション設定を確認しましょう。

主なプロトコルの設計と選び方

ShadowsocksとVMess：データのカプセル化方式の違い

Shadowsocksは、暗号化されたプロキシ通信のカプセル化を中心とするプロトコルです。通常、クライアントがアプリの接続を受け取り、接続先アドレスとデータをサーバーに送ります。外側の伝送方式の組み合わせは、すべての実装で同じとは限りません。暗号化方式、追加の伝送プラグインを使うかどうか、UDPの処理方法は、設定を確認する必要があります。カプセル化が比較的シンプルであれば処理経路を抑えやすくなりますが、シンプルだからといって、どの端末でも速くなるわけではありません。実装の品質、ハードウェアアクセラレーション、リモート側の負荷も実際の動作に影響します。

VMessは独自の認証とデータのカプセル化の仕組みを備え、さまざまな伝送方式と組み合わせて使われます。利用者が感じる接続時の負荷には、プロトコルの認証だけでなく、外側の安全な通信の確立や追加のカプセル化が関係する場合があります。比較する際に「VMessだから」とだけ考えるのではなく、基盤となる伝送方式、追加の入口を経由するか、クライアントが接続をどのように再利用するかも確認しましょう。一部の実装では時刻に関係する認証条件があります。端末のシステム時刻がずれている場合は、回線の障害と判断する前に時刻を修正してください。

TrojanとVLESS：外側の設定も重要

Trojanは通常、TLSで暗号化された通信を確立し、その接続内でプロキシ認証を行います。利用者にとっては、サーバーアドレス、ポート、認証情報、サーバー名、証明書の検証が設定の一部です。TLSを使うことで、実績のある安全な通信方式を利用できますが、毎回のハンドシェイクが速くなるとは限りません。初回接続、セッション再開、長時間接続の再利用では、使い心地が異なります。クライアントの実装やサーバー設定によっても、実際の負荷は変わります。

VLESSは、軽量なプロキシ認証とリクエストのカプセル化を重視しています。VLESS自体はデータを暗号化しないため、通信を保護するには組み合わせる安全レイヤーが必要です。安全性と性能を判断するにはプロトコルと外側の仕組みを合わせて見る必要があり、「カプセル化が軽い」からといって「安全レイヤーを省ける」と考えてはいけません。同じVLESSでも、伝送方式の組み合わせ、フロー制御、入口の処理は異なる場合があります。サブスクリプションに設定が含まれている場合は、組み合わせ全体を維持してください。意味が分からない項目を削除して、設定を単純化しようとしないでください。

プロトコル名を性能ランクと見なさない

TCPによる通信はデータを順番に届けます。一部のデータが失われると、後続データがすでに届いていても、欠けたデータが補われるまで待つことがあり、操作の滑らかさに影響します。待ち時間が目立つかどうかは、パケットロスの発生箇所、往復時間、バッファー、接続の再利用方式にも左右されます。そのため、ネットワークが安定しているときはスムーズなプロトコルでも、電波が不安定な無線ネットワークでは何度も止まることがあります。矛盾ではなく、プロトコル自体ではなく通信条件が変わった可能性があります。

追加の伝送レイヤーは、互換性や導入環境への適応に役立つことがありますが、ヘッダー、メモリバッファー、処理負荷が増える場合もあります。「レイヤーが少ないほど使いやすい」とは限りませんし、「カプセル化が多いほど高機能」とも限りません。現在のネットワークとサーバーの条件を満たす、必要最小限の組み合わせを使うのが適切です。サーバー側に対応する待ち受け設定がないのに、利用者側で伝送方式を変更すると、通常は接続に失敗し、性能を比較できる結果は得られません。

実際に選ぶ際は、まずクライアントがサブスクリプションの項目を正しく読み込めるか確認し、次に目的の機能を試します。プロトコルの項目が追加後に消えたり、「非対応」と表示されたりする場合は、クライアントの対応状況とインポート形式を確認してください。認証情報を手作業で組み立てて無理に接続しないでください。項目が表示されても接続できない場合は、エラーの種類を記録し、利用できることが分かっている別の項目と比較します。プロトコルの仕組みを知る目的は、効果のない設定変更を減らすことであり、利用者がサーバーの導入設定をすべて設計し直すことではありません。

Hysteria2とTUICの適用範囲

QUICによって変わる通信の仕組み

Hysteria2とTUICは、どちらもQUICの機能を利用したプロキシ通信を構築します。QUICはUDP上に構築されますが、アプリのデータを無責任に送信する方式ではありません。安全な通信の確立、信頼性の高いデータ転送、輻輳制御、ストリーム管理などの仕組みを備え、1つの接続内で複数のデータストリームを扱えます。ここを理解しておくことが重要です。UDPは通信の基盤となる方式、QUICはその上で動作する伝送方式、プロキシプロトコルは認証、接続先アドレス、アプリのデータ転送などを担います。

QUICは、ストリーム間でデータを順番に届けることによるブロッキングを軽減できますが、各ストリーム内ではパケットロスやデータの順序を処理する必要があります。ローカルの無線ネットワークでパケットロスが続いたり、リモート側の出口が混雑していたりする場合、QUICでも問題はなくなりません。異なる回復・スケジューリングの仕組みによって、特定のネットワークで使い心地が改善する可能性はありますが、帯域幅が無限に増えるわけではありません。ウェブページのリクエストが直列に続きすぎる場合や、接続先サービスの応答が遅い場合も、伝送方式を変えるだけでは完全には解決できません。

Hysteria2：帯域幅の設定には根拠が必要

Hysteria2の性能を考える際は、帯域幅の推定や輻輳制御がよく話題になります。実際に使われる方式は実装と双方の設定によって異なります。帯域幅の設定値に応じて送信動作が変わる場合があるため、実際の環境を大きく上回る値を入力しても、速度が上がるとは限りません。送信が積極的すぎると、ローカルの上りキューがいっぱいになり、ウェブ閲覧、音声通信、ほかの端末まで遅くなることがあります。利用できる帯域幅は、回線の共有状況、無線電波、時間帯によって変わります。通信事業者の料金プラン名だけを基準に設定しないでください。

一般の利用者は、サブスクリプションに含まれる設定とクライアントのデフォルト動作を使うのが無難です。設定の意味、サーバー側の制約、ローカル回線の能力を把握している場合に限り、関連する項目の調整を検討してください。調整後はダウンロードだけでなく、アップロード中のウェブ応答や操作への影響も確認します。表示速度が上がっても操作の遅延が明らかに悪化した場合は、元の設定に戻しましょう。設定調整の目的はアプリを安定して使えるようにすることであり、短時間だけ速度表示を大きくすることではありません。

TUIC：ストリーム管理と互換性をあわせて確認

TUICもQUICを利用してプロキシ接続を構築し、対応する認証・転送の仕組みを提供します。接続の再利用やストリーム管理により、基盤となる接続を繰り返し作る負荷が減る場合がありますが、具体的な効果はクライアントの実装、接続先のリクエスト方式、ネットワーク条件によって異なります。UDP転送を利用するには、双方が対応している必要があります。同じ名称のプロトコルでも、すべてのクライアントが同じ設定項目に対応しているとは限りません。追加後に未対応の項目が表示されていないか確認し、すべての設定が意図どおりに適用されると思い込まないでください。

QUICの接続移行機能は、モバイルネットワークの切り替えに関してよく取り上げられますが、「ネットワークを切り替えても絶対に切断されない」という保証ではありません。クライアントが接続を再構築する場合や、接続ネットワークによってUDPのマッピングが変わる場合、リモート側が以前の経路を継続できない場合もあります。Wi-Fiとモバイルネットワークを切り替えた後は、プロキシ接続だけでなく、アプリのセッションが復旧したかも確認しましょう。アプリの再認証、動画の再バッファリング、プロキシの再接続はそれぞれ異なる処理なので、分けて観察してください。

UDPが通らない場合、帯域幅の設定だけを変更しないでください。まず現在の接続ネットワークが必要な伝送方式に対応しているかを確認し、サブスクリプション内で利用できる別のプロトコルと比較します。基盤となる接続が確立できない場合、スループットの設定は主な問題ではありません。

同じネットワークでTCPベースの項目には接続できるのに、QUICの項目が常にタイムアウトする場合は、まず通信を支える環境、マッピング、クライアントの互換性を疑いましょう。どちらの項目も接続できるものの、継続的な通信の使い心地に差がある場合は、パケットロスからの回復処理とリソース消費を比較します。同じ接続先を使い、時間帯も近づけてテストしてください。QUICの接続が一度速かったからといって、すべての地域・ネットワークで唯一の選択肢にするのは避けましょう。接続条件に応じて使える回線を複数残しておくほうが実用的です。

トンネルの方式と実際のアプリの違いにも注意が必要です。UDPを使うアプリをプロキシ経由で転送できても、UDPを使うプロキシの伝送方式が必ず適しているとは限りません。アプリ自体がジッターに敏感だったり、接続先サービスの接続方針に左右されたりする場合があります。Hysteria2やTUICを選ぶ際は、接続成功率、操作の滑らかさ、端末への負荷を実際に確認して判断してください。プロトコル名が用途に合うことを保証するわけではありません。

接続確立の速さとリソース消費

初回接続と再利用される接続は別々に測定する

初回接続では通常、ドメイン名の解決、入口までの通信確立、安全な通信の確立、プロキシ認証が行われます。さらに接続先サイトでも接続の確立が必要になる場合があります。これらの処理は並行して進むこともあれば、前の処理が終わるまで待つこともあります。そのため、プロトコル名だけから処理全体にかかる時間を推測することはできません。利用者が感じるページの初回表示時間には、リモート側の処理とコンテンツの転送も含まれます。接続確立の速さを比較する際は、新規接続を比べているのか、クライアントがセッションと基盤となる接続を保持した後の繰り返しリクエストを比べているのかを確認しましょう。

接続を再利用すると、複数のリクエストで確立済みの通信経路を共有でき、再度のネゴシエーションや一部のリソース確保を減らせます。細かなリクエストが多いウェブページでは役立つ場合がありますが、再利用した接続に問題が起きると、複数のリクエストが同時に影響を受けます。接続の混雑、再送、切断が起きた場合、独立した接続よりも影響範囲が広がる可能性があります。有効にするかどうかは、クライアントのデフォルト設定と接続先のリクエスト方式を踏まえて判断してください。単純に常時有効にすれば速くなる設定とは言えません。

CPU・メモリ・接続数の関係

クライアントは暗号化・復号、データのコピー、ルール判定、ドメイン名の解決、ログ記録などを処理します。端末のハードウェアアクセラレーションによって、同じ暗号化アルゴリズムでもプラットフォームごとに負荷が異なります。ダウンロードを続けると、バッファーと同時接続数も増える場合があります。CPU使用率が上がったときは、データ処理が増えたことによる通常の負荷なのか、プロセスが何度も再接続しているのか、大量のデバッグログを書き込んでいるのか、設定を繰り返し解析しているのかを切り分けましょう。ある瞬間の使用率だけでは、長期的なリソース消費は判断できません。

メモリ使用量もプロトコルの順位だけでは判断できません。接続数が多い場合、バッファーが大きい場合、セッションを長時間保持する場合は、使用量が増えることがあります。OSがリソースをキャッシュするため、タスクの終了後も数値がすぐ下がらない場合があります。実際に確認したいのは、使用量が増え続けているか、端末の動作が遅くなっているか、クライアントがOSによって終了させられているかです。切り分けの際は、不要な大量同期やダウンロードを停止し、同じアプリの負荷を保った状態で別の項目に切り替えたときの変化を観察します。ブラウザー自体の使用量をプロキシの負荷と混同しないようにしてください。

効果のない設定変更を減らす

タイムアウト設定は、接続を諦めるまでの待ち時間を決めるものであり、データの伝送速度を決めるものではありません。短く設定しすぎると、一時的な通信の乱れでも再接続が起きます。長く設定しすぎると、障害発生時の待ち時間が目立つ場合があります。同時接続数は、同時に処理する作業量を決めます。増やしすぎると、ローカルの帯域幅、リモート側のリソース、端末のメモリを奪い合うことがあります。バッファーの設定も、スループット、応答速度、リソース消費のバランスに影響します。ネットワーク条件を問わず使える最適値はありません。まずデフォルト設定を維持し、症状から特定の設定が原因と考えられる場合に限り調整してください。

ハンドシェイクを短縮するために証明書の検証を無効にしたり、認証情報を削除してテストを続けたりしないでください。セキュリティの確認に失敗した場合は、接続条件が満たされていないのであり、省略できる作業が増えたわけではありません。システム時刻、サーバー名、サブスクリプションが最新か確認すれば、期限切れの設定とネットワークの問題を切り分けやすくなります。サブスクリプションで管理されている回線では、項目を一つずつ推測して変更するより、設定全体を再取得するほうが確実です。変更前の状態を保存しておけば、誤った変更を元に戻せます。

リソースをきちんと比較するには、待機中、通常のウェブ操作、継続的な通信をそれぞれ確認します。待機中はバックグラウンドでの活動頻度、操作中はリクエストへの応答と動作の遅れ、継続的な通信中は発熱、リソース消費、速度の安定性を確認します。定義のない総合スコアに、これらの結果をまとめないでください。利用者が知りたいのは、自分の端末のどこがボトルネックなのか、プロトコルの変更、同時接続の削減、回線の変更のうち、どれが現在のタスクを最小限の負担で改善するのかです。

直結・中継・専用回線の経路

直結だからといって最短経路とは限らない

直結とは通常、クライアントが海外の入口に直接接続すること、または入口と出口の間に追加の中継サービスがないことを指します。構造は比較的分かりやすいものの、インターネット上の経路は地図上の直線どおりには進みません。通信事業者間の接続、トラフィックの振り分け、戻りの経路によって、データが遠回りすることがあります。往路と復路が異なる場合もあります。そのため、距離の近い地域でも実際の往復時間が短いとは限りません。また、入口の名称がシンプルだからといって、混雑時に共有ボトルネックがないとは言えません。

直結は追加の処理区間を減らせる可能性がありますが、ローカルの通信事業者や地域をまたぐ公共ネットワークの接続状況に直接左右されることがあります。自宅ではスムーズでも、オフィスのネットワークでは使いにくいということも起こり得ます。比較する際はローカルの接続方式を一定にし、実際の接続先で確認してください。国や地域間の距離だけで優先順位を決めないでください。ノードページにある地域情報は候補を絞るのに役立ちますが、ローカルネットワークや利用時間帯の確認に代わるものではありません。

中継・専用回線が改善する区間

中継では、クライアントと出口の間に転送用の入口を追加します。リクエストをまず接続地点に送り、そこから先の経路を通って出口に届けます。ノードが増えると処理や伝送にかかる時間も増えますが、その先の経路が適切であれば、全体的な使い心地が改善する場合があります。中継の価値はノード数の多さではなく、もともと適さない相互接続経路を、より適切な組み合わせに変えられることです。判断する際は入口に接続できるかだけでなく、中継後の継続的な通信も確認してください。クライアントから入口までの遅延だけでは判断できません。

専用回線とは通常、ある区間で専用または明確に管理されたリソースを持つネットワーク接続を指します。IEPLは、その種の回線を説明する際によく使われる分類の一つです。サービス説明で専用回線と記載されていても、利用者の端末から接続先サイトまでの全経路が専用回線になるわけではありません。ローカルの無線接続、入口までの公共ネットワーク、出口から接続先サービスまでの相互接続も、使い心地に影響する可能性があります。途中の区間が安定していても、ローカルの電波の弱さ、接続先の速度制限、アカウントの地域設定の不一致までは解消できません。

入口の地域・出口の地域・コンテンツの地域

入口はクライアントが接続するサーバーアドレス、出口は接続先サイトから見えるリクエスト元の位置です。両者は同じとは限りません。サブスクリプションの地域名は、クライアントの説明とあわせて確認してください。コンテンツを利用できる地域は、アカウント情報、支払い地域、過去のセッション、プラットフォームのルールにも左右される場合があります。特定地域のコンテンツを利用したい場合は、回線名に地域名が含まれているだけで条件を満たすと判断せず、まず出口とアカウントの条件を確認しましょう。詳しくは動画配信サービスの利用に関する説明をご覧ください。

いわゆるネイティブIPも、何を基準にするかを明確にする必要があります。IPアドレスの登録情報、データベース上の地域判定、ネットワークの帰属、接続先プラットフォームの不正利用対策の結果は、それぞれ異なります。あるデータベースに表示された地域だけで、接続先プラットフォームがそのIPを現地ユーザーと認識するとは限りません。ラベルを万能の証明と見なすのではなく、実際の目的を達成できるかを基準に回線を選びましょう。VPNXBの対応地域と回線の入口はノードページをご覧ください。回線の種類はクライアントに表示される情報をご確認ください。

経路を切り分ける際は、同じ出口で入口を変えて比較できます。接続先と出口がほぼ同じなのに入口によって使い心地が大きく違う場合は、接続区間や中継経路を重点的に確認しましょう。複数の入口から同じ接続先への通信が遅い場合は、出口または接続先サービスが原因かもしれません。サブスクリプションに比較可能な組み合わせがない場合、名前だけから内部の経路を推測しないでください。検証していないノードに専用回線や直結のラベルを付けるより、ローカルネットワークの種類、時間帯、回線名を記録するほうが役立ちます。

VPNXBは100+か国、180+回線をカバーしています。対応範囲は選択できる地域を示すもので、すべての地域で同じ経路構成や用途への適性があることを意味しません。まず目的の地域に対応する回線を選び、次に接続のしやすさと継続利用時の使い心地を比較してください。目的に合う安定した回線が見つかったら、日常的に地域を切り替え続ける必要はありません。出口を頻繁に変えると、アプリで再認証が必要になったり、障害の原因を特定しにくくなったりする場合があります。

パケットロス・ジッター・混雑時の問題

同じような途切れでも原因は異なる

パケットロスはデータが想定どおりに届かないこと、ジッターはデータの到着時間にばらつきがあること、混雑はネットワークのある区間に処理能力を超えるデータが流れ込むことです。混雑は待ち行列やパケットロスを引き起こす場合がありますが、パケットロスは無線干渉や端末の問題が原因のこともあります。これらは関係していますが、同じものではありません。ウェブページの短い停止、動画のバッファリング、音声の途切れはいずれも影響を受ける可能性があります。原因を見極めるには、どの種類のタスクで症状が出るのか、ほかのアプリも遅くなるのか、接続ネットワークを変更すると改善するのかを確認しましょう。

バッファーが大きすぎると、ダウンロードのスループットは高く表示されても、操作時のリクエストが待ち行列で待たされることがあります。ダウンロードに問題はないのに、ウェブページや音声通信の反応が明らかに遅い場合があります。このような症状は送信を強めるだけでは解決できず、同時接続数を増やすと待ち時間がさらに長くなることもあります。まずアップロード、同期、ほかの継続的な通信を一時停止して、操作への応答が戻るか確認してください。その後、接続機器のキュー管理や回線の選択を検討しましょう。ネットワークの使い心地は、運べるデータ量だけでなく、小さなリクエストが処理されるまでの時間にも左右されます。

混雑時の問題は経路全体を比較する

混雑する時間帯は、ローカル接続、通信事業者間の相互接続、プロキシの入口、中継、出口のいずれでも、共有リソースの競合が起こる可能性があります。特定の時間帯だけ遅くなるからといって、サービス側に問題があるとは限りません。すべての回線と通常のローカルアプリに影響する場合は、まず接続ネットワークを確認しましょう。ローカルの通信は正常で、特定の出口だけ遅い場合は、ほかの地域や経路構成と比較してください。同じ接続先で時間帯ごとの状況を記録し続けると、一時的な障害と時間帯によって繰り返し発生するボトルネックを区別しやすくなります。

比較テストで余計な負荷を発生させないようにしましょう。複数の回線で同時に大容量ファイルをダウンロードすると、ローカルの帯域幅を奪い合うだけでなく、テスト自体がリモート側の出口を遅くすることがあります。同じタスクを順番に実行し、通信速度が頻繁にゼロになるか、操作への応答が遅くなるか、再接続が増えるかを確認するのが適切です。特定の接続先だけが遅い場合は、接続先サービスのメンテナンス、コンテンツ配信元の障害、アカウントの状態も確認しましょう。回線の障害と判断するには、再現可能なネットワーク上の根拠が必要です。アプリに表示された一般的なエラーメッセージだけでは判断できません。

測定結果が誤解を招くことがある理由

Pingや経路トレースは手がかりになりますが、アプリの通信全体をそのまま示すものではありません。ネットワーク機器によっては、測定用パケットの処理優先度を下げたり、応答を返さなかったりします。中継地点が応答しなくても、その先のデータを転送している場合があります。中間の経路でパケットロスが表示されても、最終的な接続先が正常なら、その地点がボトルネックとは限りません。逆に測定がスムーズでもアプリが遅い場合は、アプリが別の伝送方式、別のルール、別の接続先アドレスを使っている可能性があります。

一般の利用者がトラブル診断のために、多数のシステムネットワーク設定を変更する必要はありません。まずローカル接続の品質を確認し、大容量通信を一時停止して、サブスクリプションを更新します。次に同じ用途の別の回線を選び、同じアプリの操作をもう一度試してください。さらに調べる必要がある場合は、クライアントで接続エラー、接続先ドメイン、適用されたルールを確認できます。ログを共有する際は、アカウント情報、サブスクリプションURL、認証情報を隠し、必要なエラーの種類と症状だけを残してください。トラブル対応の資料から認証情報が漏れることを防げます。

スループットが上がっても操作が遅くなれば、全体が改善したとは言えません。継続的な通信と操作への応答をあわせて確認してください。特にアップロードが混み合っている場合は、ほかの通信を減らしてからプロトコルと回線を比較しましょう。

経路上のMTUが合わない場合、小さなリクエストは正常でも大きなデータ転送に問題が生じることがあります。カプセル化によって追加のデータが必要になる一方、ネットワークによっては実際に運べるデータ量が小さい場合があります。特定のネットワークで大容量ファイルの転送が止まったり、ページ内の一部リソースが読み込めなかったりする場合は、カプセル化と経路の互換性も原因の候補です。ただし、ほかの要因も考えられるため、決まったMTU値をそのまま設定しないでください。まずデフォルト設定を維持して別の回線で確認し、明確なクライアントの説明書に基づいて対応しましょう。

サポート窓口に問題を伝える際は、アプリの機能、ローカルネットワーク、発生した時間帯、項目名、エラーメッセージ、実施した比較を記載してください。お問い合わせはユーザーパネルから送信できます。「速度が遅い」とだけ書く必要はありません。また、閲覧履歴をすべて送る必要もありません。再現可能な最小限の状況を伝えることで、回線、クライアント、接続先サービスを切り分けやすくなり、何度も確認を繰り返す手間を減らせます。その後の調整結果を確かめる基準にもなります。

モバイル端末の電池消費とOSによる違い

電池は処理だけでなく、ネットワーク通信でも消耗する

モバイル端末の電池消費は、暗号化アルゴリズムだけで決まるわけではありません。通信を続けると無線通信が稼働し、頻繁な再接続ではハンドシェイクと名前解決が繰り返されます。また、頻繁なキープアライブやバックグラウンドでの接続確認も、端末の起動回数を増やす可能性があります。電波が弱い環境では、端末の通信負荷がさらに大きくなります。そのため、同じプロトコルでも、安定したWi-Fiとモバイルネットワークでは電池消費が異なる場合があります。消費電力を判断する際は、画面、アプリ、電波状況、通信量も考慮してください。端末が熱くなっただけで、プロキシプロトコルに問題があると決めつけないでください。

QUICベースの接続は、状況によって接続を再構築する負荷を軽減できることがありますが、通信の継続、パケットロスからの回復、実装方式も電池消費に影響します。TCPベースの接続も、セッションの再利用によって繰り返し発生する処理を減らせる場合があります。ネットワーク条件にかかわらず使える、電池消費の固定的な順位はありません。同じアプリのタスクを実行したとき、特定の候補で再接続が繰り返されないか、端末が異常に熱くならないか、タスクの終了後にネットワーク通信が速やかに減るかを確認するほうが有益です。バックグラウンドでの待機と動画の連続再生を直接比較しないでください。

アプリの通信がプロキシを経由するかは、OSがどこまで通信を処理するかで決まる

デスクトップOSのシステムプロキシは、通常、アプリが該当する設定に従うかどうかに左右されます。アプリによっては独自に接続を確立するため、自動的にシステムプロキシを経由しないことがあります。TUNなどの仮想ネットワークインターフェースは、より低いレイヤーで通信を処理しますが、権限、ルーティング、DNS、ほかのネットワークソフトとの連携も関係します。モバイルOSでは通常、ネットワーク拡張やVPNインターフェースを使って通信を処理しますが、バックグラウンドの制御方針やシステム権限も動作の継続に影響します。クライアントが起動していても、すべてのOSで同じ方式が使われるとは限りません。

VPNXBはWindows / macOS / iOS / Android / Linuxに対応しています。各OSで読み込めるプロトコルや利用できるモードは、ログイン後に取得するクライアントとサブスクリプションをご確認ください。ダウンロード先はユーザーパネルのクライアントページにまとめています。不明な配布元からインストーラーを入手しないでください。macOSのインストールと権限設定についてはMacでVPNを使う方法：初心者向け完全ガイドをご覧ください。本ページでは権限と接続の関係を説明します。

ネットワークの切り替え、スリープ、バックグラウンドからの復帰

端末がスリープすると、以前の接続がローカルネットワークやリモート側によってすでに終了している場合があります。復帰時にはクライアントがインターフェースを再開し、名前解決や接続の再確立を行う必要があり、アプリも自動的に再試行することがあります。復帰後にだけ問題が起きる場合は、まず再接続によって復旧するかを確認し、古いプロキシ設定、名前解決のキャッシュ、インターフェースのルート情報が残っていないか調べましょう。すぐにアカウントを変更したり、すべてのソフトを再インストールしたりする必要はありません。接続経路の復旧とサブスクリプションの失効では、対処方法が異なります。

Androidではバックグラウンド動作の設定が異なる場合があり、制限が強すぎるとクライアントが接続を維持できなくなります。iOSのネットワーク拡張機能もOSによって管理されているため、アプリの画面を常に表示しておくことを一般的な解決策と考えないでください。クライアントとOSの権限に関する説明に従い、必要な許可が与えられているか確認し、画面を消した後に何が起こるかを観察しましょう。省電力設定を変更する場合は、接続への影響が確認できた項目だけを対象にしてください。

VPNXBでは同時接続台数に制限はありませんが、それぞれの端末が同じネットワーク環境を共有するわけではありません。デスクトップ端末は安定しているのにモバイル端末で不安定な場合は、まず接続ネットワークと通信を処理するモードを比較してください。すべての端末で同じ接続先に問題が起きる場合は、出口または接続先サービスを確認しましょう。大容量通信を同時に実行すると、同じ家庭内ネットワークのリソースを奪い合うこともあります。接続端末数の制限とローカルネットワークの処理能力は別のものです。接続台数が無制限でも、ローカルの帯域幅に制限がないわけではありません。

モバイル端末の日常設定は、変更を最小限にし、元に戻せる状態を保つのが基本です。信頼できるサブスクリプションを使い、不要な接続確認を頻繁に実行せず、ネットワークインターフェースを奪い合うソフトを同時に動かさないようにしましょう。一時的に接続が切れた場合は、画面のロック、ネットワークの切り替え、電波の低下と同時に起きたか記録してから、バックグラウンド設定を確認するか回線を変更するか判断します。原因をシステム上のイベントと関連付けるほうが、プロトコルを何度も切り替えるより効果的です。接続を安定させるために、不要なバックグラウンド通信を常時有効にすることも避けられます。

用途に合わせたプロトコルと回線の選び方

ウェブ閲覧・AIツール：リクエスト全体が継続できるか確認

一般的なウェブ閲覧とAIツールでは、リクエストのパターンが異なります。ウェブページは多くのリソースを分けて読み込む場合があり、AIの会話では応答の接続が長時間続くことがあります。ファイルのアップロードは上り通信の負荷を増やします。回線を選ぶ際は、トップページが開くかだけではなく、ログイン、リクエストの送信、応答全体の受信まで完了するか確認してください。応答が途中で止まる場合は、接続が再確立されたか、ネットワークが切り替わったか、アプリにアカウントやサービスのエラーが表示されていないかを調べましょう。これらの症状すべてを、プロトコル名のせいにしないでください。

AIツールでは、最低遅延の回線を頻繁に探すより、出口の一貫性が重要になる場合があります。利用中に地域を変更すると、再認証が求められたり、現在の接続が終了したりすることがあります。まずプラットフォームのルールと実際の利用条件に合う回線を選び、長い応答が途切れずに受信できるか確認してください。プロトコルは接続ネットワークでの動作に合わせて選べばよく、特定のプロトコル名を特定のツールと固定して結び付ける必要はありません。アプリ側の条件について詳しくはAIツールの通信に関する説明をご覧ください。アカウント、プラットフォームのルール、ネットワーク接続は分けて判断してください。

動画・ライブ配信・データ転送：それぞれの途切れにくさを確認

オンデマンド動画はバッファーで一部のジッターを吸収できますが、ライブ配信やリアルタイムのやり取りでは、長いバッファーで変動を隠すことが難しくなります。動画を視聴する場合は、対象コンテンツの地域、アカウントの権限、画質設定を確認してから、通信が継続できるか調べましょう。ライブ配信では、重要な場面で何度も止まらないかも確認してください。低遅延の測定結果は通信が続けてスムーズに流れる保証にはならず、ダウンロード速度のピークもライブ配信の安定性を保証しません。混雑時の回線選びとリアルタイム視聴については、スポーツ中継を視聴するためのVPN回線の選び方もご覧ください。

大容量ファイルの転送では、継続的なスループットと端末への負荷が表れやすくなりますが、すべての用途でそれを基準に回線を選ぶ必要はありません。ある回線でダウンロードはスムーズでも、アップロード中にウェブ閲覧が遅くなる場合は、上り側の待ち行列が原因かもしれません。あるプロトコルで高速に転送できても、モバイル端末が使い続けて熱くなる場合は、日常の標準設定には適さないことがあります。すべての用途を満たす一つの最適解を探すより、普段の操作用と継続的な転送用に候補を分けるほうが現実的です。用途が変わったときに切り替えればよく、問題のないタスク中に何度も試す必要はありません。

元に戻せる手順で最終的な設定を選ぶ

サブスクリプションに含まれるデフォルトの候補から試すとよいでしょう。まず目的のアプリで実際の操作を行い、次に同じ接続ネットワークで、同じ用途の別の回線に切り替えます。回線による違いを確認してから、利用できるプロトコルの組み合わせを比較してください。変更する条件は一度に一つだけにし、元の候補も残しておきましょう。新しい設定で明確な改善がない場合はデフォルトに戻し、理由を忘れた変更を積み重ねないでください。サブスクリプションにない伝送方式を独自に組み合わせないでください。有効に比較するにはサーバーとクライアントの対応が必要です。

トラブルが起きたら、階層ごとに切り分けましょう。アプリの操作が完了しない場合は、アカウントと接続先サービスを確認します。プロキシに接続できない場合は、サブスクリプションの状態、入口、ローカルネットワークを確認します。継続的な通信に問題がある場合は、競合する通信、パケットロス、端末のリソース消費を調べましょう。候補の一つが使えない場合は、地域、プロトコル、モードを同時に変更するより、同じ種類の別の候補に切り替えるほうが原因を特定しやすくなります。お問い合わせに記載するのは必要な条件だけにし、サブスクリプションURL全体をアップロードしないでください。アカウントや通信量に関する初心者向けの質問は、VPN初心者によくある質問をご覧ください。

技術面の選択は、実際の利用量も踏まえて行いましょう。VPNXBの月額プランは、¥9.9/月で60GB、¥18/月で250GB、¥28/月で500GBです。通信量は利用開始日を基準に毎月リセットされます。利用途中でアップグレードする場合は、差額を残り日数に応じて計算します。追加通信量パックは¥158/300GB、¥358/1000GB、¥658/3000GBで、使い切るまで有効期限はありません。プロトコルのテストや継続的なダウンロードでも通信量を消費します。プランを選ぶ前に主な用途を確認してください。料金の詳細は料金プランページをご覧ください。プロトコルを試すためだけに、上位プランへ変更する必要はありません。

最終的に選ぶのは、目的を達成できる組み合わせです。接続を確立できること、必要な機能を使えること、継続利用時の使い心地が適切なこと、端末への負荷が許容範囲であることは、根拠のないプロトコルの順位よりも判断材料になります。

VPNXBは60日間の無理由返金に対応し、Alipay / WeChat Pay / USDTでお支払いいただけます。アカウントの作成にメールアドレスは不要で、ユーザー名とパスワードを使います。返金条件は返金ポリシーをご覧ください。これらのサービス内容とプロトコルの技術的な特性は、分けてお考えください。返金制度は性能の測定結果ではなく、対応地域もすべての接続先が利用できる保証ではありません。設定を選んだ後は、安定して使える候補とトラブル時の記録を残しておきましょう。ネットワーク環境が変わったときに、接続、経路、アプリの各レイヤーを順番に確認でき、すべての設定を一から推測せずに済みます。