回線とプロトコル:選定のための技術リファレンス

6種類のプロトコルの設計上のトレードオフ

この6種類はクライアント上ではたいてい並列の選択肢として並んでいます。新旧の置き換え関係ではなく、異なる制約に対する異なるトレードオフです。オーバーヘッドを最小に抑えるもの、互換性を最大にするもの、パケットロス環境のために設計されたものがあります。トレードオフを理解するほうが、「どれが強いか」を覚えるよりはるかに役立ちます。

Shadowsocks:軽量で直接的

Shadowsocks の設計目標はきわめて単純です。できるだけ少ないオーバーヘッドで TCP と UDP のトラフィックを暗号化して転送すること。事前共有鍵からセッション鍵を導出し、各パケットを AEAD で暗号化し、複雑な認証ハンドシェイクを内蔵せず、サーバー側のユーザー管理機構も持ちません。その結果、初回パケットのオーバーヘッドが小さく、サーバーのリソース消費も低く、1人または少数の端末での利用に向きます。代償は偽装層を持たないことです。トラフィックの形は暗号化された TCP ストリームそのもので、通常の TLS の Web トラフィックとは異なります。追加の TLS 層が必要な場合は、通常クライアントのプラグインや外側の転送で対応します。

VMess:ユーザー管理を備えたカプセル化

VMess はプロトコルヘッダーにユーザー識別子とタイムスタンプを含め、サーバーはそれによってリクエストが正当か、どのユーザーのものかを判断します。このためマルチユーザー・マルチデバイスの場面に向いており、同じ入口でもユーザーごとに振り分けたり、個別に計量したりできます。代償はヘッダーが Shadowsocks よりやや大きいこと、そして時刻に敏感なことです。クライアントとサーバーの時刻のずれが許容範囲を超えると接続できなくなり、「ノードのテストがタイムアウトする」のにネットワーク自体は正常、という形で現れます。この表示が出たら、まず端末の時刻を自動同期に設定してから再試行してください。

Trojan:標準 TLS を使うタイプ

Trojan は認証情報を TLS ハンドシェイク後のアプリケーションデータの中に置き、ポートは通常 443 を使います。ハンドシェイクの過程は HTTPS サイトへのアクセスと区別がつきません。利点は互換性の高さで、途中の機器から見えるのは標準の TLS 接続そのものです。代償は証明書とドメインの維持が必須なことで、証明書の期限切れや差し替えはそのまま接続失敗につながります。TLS ハンドシェイク自体が1回のラウンドトリップを伴うため、初回パケットの遅延は純粋な TCP の Shadowsocks よりわずかに大きくなります。

VLESS:暗号化は TLS に任せる

VLESS はプロトコル自前の暗号化層を外し、軽量なヘッダーと認証だけを残して、暗号化は完全に外側の TLS または REALITY に任せます。利点はサーバー側の CPU 消費がより小さく、ヘッダーも短いため、高スループットの場面で帯域を使い切りやすいこと。欠点は信頼できる外側の層と必ず組み合わせる必要があり、単体では意味がないことです。一般のユーザーにとっては、VLESS と Trojan の体感差は回線の差より小さいことが多く、そのために何度も切り替える必要はありません。

Hysteria2:パケットロス環境のために設計

Hysteria2 は QUIC ベースで UDP 上を走り、輻輳制御と帯域ネゴシエーションを備えています。強みは高パケットロス・長距離のリンクです。TCP はそうしたリンクでパケットロスにより輻輳ウィンドウを繰り返し縮めますが、Hysteria2 はユーザー空間でより適したアルゴリズムを使いスループットを維持できます。代償は3つ。UDP が一部のネットワークで速度制限を受けたり破棄されたりすること、モバイル回線の切り替え時に接続を張り直す必要があること、UDP 系トラフィックは MTU に敏感で、フラグメント設定を誤ると「接続はできるが大きなファイルが転送できない」形で現れることです。

TUIC:QUIC 上の多重化

TUIC も QUIC ベースで、重点は多重化とコネクション移行にあります。1本の QUIC 接続の中で複数のリクエストを並行して走らせられ、ひとつのリクエストのパケットロスが他のリクエストを止めません。Wi-Fi からモバイル回線に切り替わっても、QUIC のコネクション識別子によってセッションを継続でき、ハンドシェイクをやり直す必要がありません。用途は Hysteria2 に近く、違いは主にクライアント側の輻輳制御の実装に現れます。同じく UDP の可用性に制約され、ネットワークが UDP を通さない場合はどちらも使えません。

ひとつだけ覚えるなら:TCP 系プロトコルは「安定しているか」の下限を回線が決め、UDP 系プロトコルは「パケットロスがあっても走れるか」を決めます。プロトコルを選ぶ前にまず回線を見てください。順序を逆にすると、間違った軸で延々と試すことになります。夜間ピーク時に混雑する直結回線を、Trojan から VLESS へ、さらに Hysteria2 へと変えても、体感はたいてい本質的に変わりません。

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

Web ページを開くのが遅いと、多くの人はまず帯域が足りないと考えます。実際にもっと多いのはラウンドトリップの回数です。新しい接続を張るたびにハンドシェイクが必要で、ハンドシェイクにはラウンドトリップがかかり、その時間は物理的な距離と経路の品質で決まります。帯域は「どれだけ速く送れるか」を、ラウンドトリップは「いつ送り始められるか」を決めます。

TCP と TLS を合わせた完全な接続はおおよそ次のとおりです。まずドメイン名の解決(場合によっては1往復)、TCP の3ウェイハンドシェイク(1往復)、TLS 1.3 ハンドシェイク(1往復、セッション再利用時は省略可)、次にプロトコル自体の認証、最後にようやく HTTP リクエストです。つまり、あるドメインへのコールドスタートには少なくとも数往復かかり、ページが複数の異なるドメインを参照していればそれが何度も繰り返されます。「帯域は大きいのに初回表示が遅い」という状況が珍しくないのはこのためです。

QUIC は伝送ハンドシェイクと TLS ハンドシェイクを統合し、初回接続は1往復、セッション再開時は0往復でデータを載せられます。UDP 系プロトコルが「Web ページを開く最初の一発」で速く感じられる主な理由はこれで、帯域とは関係ありません。代償は、UDP がネットワークで制限されるとその経路がそのまま使えなくなり、フォールバックの余地がないことです。

リソース消費は両端で見方が変わります。クライアント側では暗号化・復号が主な CPU コストです。AES 系はハードウェアアクセラレーションに対応したプロセッサではコストが低く、一部のモバイル向けプロセッサでは ChaCha20 のほうが省電力です。サーバー側では、同時接続数に接続あたりのメモリを掛けたもの、および UDP 系プロトコルが維持するセッションテーブルが主なコストになります。多重化は接続数を減らせますが、1本の接続でより多くの状態を維持するということでもあり、メモリとラウンドトリップの引き換えになります。

見落とされがちな点をひとつ。クライアントの「遅延テスト」が測っているのは入口までの1回のプローブの往復で、出口までの往復でも、Web ページの読み込み時間でもありません。入口が近く出口が遠い場合、テストの数字はよく見えるのに実際のページ表示は遅いまま、ということが起こります。実際の体感を判断するには、ページ全体の読み込みと動画のバッファリングを見るべきで、その1つの数字ではありません。

モバイルのバッテリーと通信量のコスト

スマートフォンの消費電力は3か所から来ます。無線機が繰り返し起動すること、暗号化・復号が CPU を使うこと、切断後の再接続です。3つともプロトコルと回線に関係しますが、重みは異なります。「暗号化が重いから電池が減る」と思われがちですが、実際に最も多い消費源はキープアライブと再接続です。

まずキープアライブ。NAT のテーブルエントリを失効させないために、クライアントは定期的に小さなパケットを送って接続を維持します。間隔が短すぎると無線機がアイドル状態から頻繁に復帰し、消費電力が目に見えて増えます。長すぎると接続が途中の機器に回収され、次に使うときに再接続が必要になり、その再接続がまた完全なハンドシェイクを引き起こします。適切な間隔は接続先ネットワークのエントリのタイムアウト時間によって変わり、家庭用ブロードバンド、社内ネットワーク、キャリア網でそれぞれ異なります。クライアントは通常、保守的な既定値を用意し、調整項目も提供しています。判断がつかないときはまず既定値のまま使い、明らかにおかしいときだけ調整してください。

次に再接続。モバイル環境で最もコストが高い操作が再接続です。Wi-Fi からモバイル回線への切り替え、エレベーターの出入り、地下鉄のトンネル、いずれも引き起こします。TCP 系プロトコルはネットワーク切り替え後に必ずハンドシェイクをやり直します。QUIC 系はコネクション識別子でセッションを移行できますが、新しい経路に到達できること、途中の機器が UDP を遮断していないことが前提です。したがって「モバイルでは UDP 系のほうが省電力」という説は条件付きでしか成り立ちません。切り替えが頻繁で UDP が使えるなら成り立ち、そうでなければ再接続が増えて逆に電力を食います。

OS のバックグラウンド制限も考慮に入れる必要があります。iOS も Android も、画面が消えてしばらくするとバックグラウンドアプリをサスペンドし、サスペンドされたクライアントの接続は自然に切れます。これはプロトコルの問題ではなく、どのプロトコルでも同じです。常時接続が必要な場面では、OS のオンデマンド接続系の機能を使ってネットワーク変化時に OS からクライアントを起動させるべきで、クライアントをずっと動かしたまま待たせるべきではありません。

通信量の面では、プロトコルヘッダー自体の割合はごくわずかで、実際に効くのは再送とキープアライブです。パケットロスが深刻な回線では、再送によって実消費が想定を大きく超えます。キープアライブは1回あたりは小さくても、1日に数百回となれば無視できません。従量制のプランではこの2つに注意が必要です。VPNWu のトラフィックパックは使い切るまで有効で期限はなく、月額プランの通信量は契約日ごとに毎月リセットされます。どちらの方式でも、クライアントで実際の使用量を確認し、自分の見積もりと突き合わせることをおすすめします。

自己点検の方法。OS 標準のバッテリー使用量の統計で、「接続した状態で一定時間待機」と「未接続の状態で同じ時間待機」の消費差を比べます。次にクライアントの接続ログで、その間に何回再接続したかを数えます。再接続が多いなら、プロトコルを変えるより回線タイプを変えるほうがたいてい効果的です。まず経路を安定させ、それからカプセル化の方式を論じてください。

回線トポロジー:直結、中継、専用線

回線はこのページの中で体感への影響が最も大きいのに、最も議論されない部分です。プロトコルはカプセル化の方式を決め、回線はデータが実際にどの道を通るかを決めます。同じ家庭用ブロードバンドでも、回線が違えば夜間ピーク時の体験は桁違いになりえますが、クライアントのプロトコル設定は何ひとつ変わっていません。

直結

直結とは入口と出口が同じ場所にあることを指し、データはユーザー側から直接、出口のデータセンターへ届きます。経路が最短で、理論上は遅延が最小です。弱点は品質がこの公共リンクの状況に完全に依存することです。夜間ピーク時に混雑すると、直結回線は通常の国際アクセスと一緒に待たされ、ジッタが明らかに大きくなります。直結が向くのは遅延に敏感だが夜間ピーク時の安定性までは求めない場面、たとえば日中の業務や一時的な調べものです。

中継

中継はユーザーと出口の間に入口ノードを1つ挟みます。ユーザーはまず自分に近い入口につなぎ、入口がサービス提供者の自前のリンクでトラフィックを出口まで運びます。ホップが1つ増えるので理論上は数ミリ秒増えますが、行きの区間がより品質を制御できるリンクに置き換わるため、夜間ピーク時のジッタは直結より小さくなるのが普通です。中継型の回線同士の差は主に中継ノードの帯域とスケジューリング方針にあり、選ぶときに見るべきはノード数ではなく運営側の容量です。

専用線

専用線は入口から出口までを拠点間の専用チャネルで結び、公衆網のトラフィックと輻輳を共有しません。特徴は遅延が安定し、ジッタが小さく、パケットロス率が低いこと。代償はコストの高さで、通常は人気のある出口にだけ用意されます。ビデオ会議、リアルタイムの共同作業、長時間の安定接続といった場面では、専用線の価値はピーク帯域ではなく「夜間ピークでも落ちない」ことにあります。たまに動画を見るだけなら、専用線による改善を体感できないこともあります。

回線選びの順序としては、まず出口の地域を決め(コンテンツやサービスがどこにあるか)、次に回線タイプを決め(夜間ピーク時に安定している必要があるか)、最後にプロトコルです。逆にプロトコルから選ぶと、もともと混雑している回線の上でカプセル化を何度も変えることになり、時間ばかりかかって効果が出ません。回線ページでは各回線にタイプのラベルが付いており、そのラベルは上の3種類のいずれかを示しています。「中継」を見て「遠回りするから遅い」と理解しないでください。中継が最適化しているのは行きの区間です。

パケットロスと夜間ピークの輻輳が起きる理由

パケットロスは故障ではなく常態です。リンクのどこか1区間でキューがあふれれば、後から来たパケットは捨てられます。無線環境では干渉もパケットロスを起こします。問題はパケットロスがあるかどうかではなく、どの区間で、どれくらい続き、プロトコルがどう対処するかです。

よくある発生源は4種類です。ローカルの無線:Wi-Fi の干渉、距離、チャネルの混雑で、すべての回線が遅くなり、回線を変えても効果がありません。家庭用:アップロードを使い切ると下りにも影響します。確認応答が送れなくなるためで、ダウンロード中の引っかかりとして現れます。国際リンクのピーク:夜間に国境をまたぐ方向のトラフィックが集中し、公共リンクが渋滞します。決まった時間帯に遅くなり、それ以外は正常という形で現れます。出口データセンターの出口:出口側の帯域が埋まると、特定の回線だけ遅くなり、同じ地域の別の回線は正常という形で現れます。

TCP のパケットロスへの反応は激しいものです。パケットロスを検出すると輻輳ウィンドウを半分にし、そこからゆっくり戻します。影響が最も大きいのは短い接続です。1つの Web ページの十数個のリクエストが1本の接続に詰め込まれていると、1回のパケットロスで接続全体が再送を待つことになります。QUIC はこの問題をストリームごとに分けます。1本のストリームでパケットロスが起きても、他のストリームはそのまま進みます。だから UDP 系プロトコルはパケットロス環境での体感がたいてい滑らかです。

夜間ピーク時の状態は「まったく使えない」ではなく、遅延の上昇、ジッタの増大、動画の自動的なビットレート低下です。この時間帯に最も効果的なのは、プロトコルを変えることではなく回線タイプを変えること(直結から中継や専用線へ)です。ボトルネックは経路の輻輳にあり、カプセル化にはないからです。プロトコルを変えても並び方の種類が変わるだけで、列そのものは短くなりません。

層別の切り分け手順

近い側から遠い側へ。まずローカルゲートウェイが安定しているか、次に入口に到達できるか、最後に出口を見ます。3区間のどこかで持続的なパケットロスが始まれば、問題はその区間より先にあります。コマンドラインの mtr はホップごとのパケットロスを一覧できるので、1回だけより数十回連続で走らせるほうがはるかに意味があります。

# 1. まずローカルゲートウェイが安定しているか確認(例のアドレスは自分のルーターのアドレスに置き換える)
ping -c 20 192.168.1.1

# 2. 次に国境をまたぐ経路のホップごとのパケットロスと遅延を、50回連続でサンプリング
mtr -rwzc 50 example.com

# 3. 別の回線で上の2手順を繰り返し、同じ時間帯の差を比較する

サンプリングの方法も統一します。同じ時間帯、同じターゲットで最低3ラウンド、各ラウンド50回。平均値、最大値、パケットロス率を記録します。1回の結果だけを見ると瞬間的なジッタに惑わされます。異なる時間帯の2つの回線をそのまま比べるのも避けてください。夜間ピーク時と未明の差は、2つの回線の差より大きいことがあります。

用途別にプロトコルを選ぶ

前の章までは分けて解説しましたが、この章はまとめて使います。選定の順序は、用途 → 回線タイプ → プロトコル → クライアント設定です。順序を逆にすると単純な問題が複雑になります。たとえば先に使うプロトコルを決め、それを動かせる回線を探し、最後にその回線が夜間ピーク時には耐えられないと分かる、という流れです。

Web と業務

Web 閲覧の特徴は短い接続の多さです。1つのページで十数個の接続が開かれ、それぞれにハンドシェイクが必要です。このとき重要なのは帯域より初回パケットの遅延、ピーク速度より回線のラウンドトリップ時間です。プロトコルとしてはヘッダーのオーバーヘッドが小さいもの(Trojan、VLESS)を選び、体感差は主に回線から来ます。業務システムで小さなファイルのアップロード・ダウンロードが多い場合は、上りも確認してください。上りが詰まると下りも連動して影響を受けます。

ビデオ会議とリアルタイム音声

会議のトラフィックは双方向で継続的で、帯域よりもジッタに敏感です。ジッタが大きいと音声が途切れ、映像が止まってから追いつきます。UDP 系プロトコルはパケットロス時の滑らかさに優れ、専用線や品質の良い中継回線と組み合わせると、この種の用途で第一候補になります。ネットワークが UDP を通さない場合は TCP 系プロトコルでも使えますが、パケットロス時にまとめて引っかかりやすくなります。

AI ツールの常時接続

こうしたツールの多くはストリーミング応答を使います。1回のリクエストが数十秒から数分続き、その間ずっとデータが返ってきます。接続が切れると回答が中断し、やり直すコストは大きなものです。したがってピーク速度より安定性が優先です。TCP 系プロトコルと中継回線を選ぶほうが、「テストの数字が小さい」UDP の組み合わせより実用的です。同じ理由で、この種の用途はノードの頻繁な切り替えに向きません。

大容量ファイルとバックアップ

ダウンロードとバックアップで見るのは持続的なスループットです。この場面ではプロトコルヘッダーのオーバーヘッドはほぼ無視でき、速度を決めるのは回線の帯域と両端の CPU です。VLESS は暗号化を TLS に任せプロトコル層のオーバーヘッドが小さいため、高スループットで帯域を使い切りやすくなります。あわせて通信量の仕組みも確認してください。月額プランの通信量は契約日ごとに毎月リセットされ、トラフィックパックは使い切るまで有効で期限はありません。時間が不定のバックアップ作業にはトラフィックパックのほうが向いています。

よくある誤解は3つ。第一に、新しいプロトコルが必ずしも速いわけではありません。プロトコルはカプセル化を決めるだけで、ボトルネックはたいてい経路にあります。第二に、1つの数字ですべてを表すことはできません。クライアントの遅延は入口までのプローブ値です。第三に、異なる時間帯は比較になりません。夜間ピーク時と未明の差は、2つの回線の差より大きいことがあります。この3つを覚えておけば、試行錯誤の時間を大幅に節約できます。

自己点検と検証:接続したあとに

つながることは正しく通っていることを意味しません。出口がどの国にあるか、ドメイン解決がトンネルを通っているか、大きなパケットが通るか。この3つは個別に確認する必要があります。それぞれまったく異なる症状に対応するので、まとめて切り分けると遠回りになります。

出口アドレスと所在地

最も簡単な検証は出口アドレスを見ることです。接続後に本サイトのネットワーク検査ページを開くと、現在の出口と所在地が表示されます。切断してもう一度調べ、2回の結果が違えばトラフィックが確かに回線を通っている証拠です。2回が同じなら、クライアントが全体のトラフィックを引き受けていないか、現在のアプリが直接接続のルールに該当しています。ここまで済ませてから、速度の話をする意味が出てきます。

ドメイン解決と振り分けルール

解決がトンネルの中を通っているかどうかで、「解決結果」と「実際の出口」が一致するかが決まります。振り分けルールで一部のドメインだけをプロキシしていると、解決はローカルのままになり、一部のサイトが開けず一部は正常、という形で現れます。切り分けは簡単です。一時的にグローバルモードに切り替えて試し、問題が消えれば振り分けルールの問題なので、ルール一覧を確認すれば済み、プロトコルを変える必要はありません。

MTU とフラグメンテーション

UDP 系プロトコルは MTU に敏感です。典型的な症状は、Web ページは開けてチャットも正常なのに、動画が止まる、大きなファイルが転送できない、特定のアプリがずっと読み込み中のまま、というものです。原因は大きなパケットが経路上で破棄され、小さなパケットは正常に通ることです。対処はクライアントで MTU を下げるかフラグメンテーションを有効にすることです。項目名はクライアントごとに異なり、通常はプロトコル設定の中にあります。調整後は大きなファイルで再テストしてください。Web ページが開けるかだけを見てはいけません。

# 現在の出口アドレスを確認(例のドメインは任意のエコーサービスに置き換える)
curl -s https://example.com/ip

# 経路 MTU を確認:まず 1500 で試し、失敗したら段階的に下げる
ping -c 3 -M do -s 1472 example.com

そのまま書き写せる記録表

切り分けで最も怖いのは記憶に頼ることです。次の項目を3日間続けて記録すれば、問題はたいてい自然と浮かび上がってきます。

切り分けの順序を一文にまとめると、まず出口が正しいか(回線を通っているか)を確認し、次に安定性(同じ時間帯に複数回サンプリング)を確認し、最後にプロトコルを調整する。順序を逆にすると、回線の問題をプロトコルの問題と取り違え、調整するほど混乱します。3つとも合わない場合は、まずチュートリアルページに戻って本筋どおりにインポート手順をやり直してください。それでも合わなければ、記録表のデータを持ってサポートに連絡するほうが、「つながらない」とだけ伝えるよりはるかに役に立ちます。

用語早見表とよくある質問

この章は後から参照するためのものです。用語は出現頻度の順に並べ、後半の Q&A では最もよく聞かれる5つの質問を扱います。答えは結論よりも判断材料を示すようにしています。

RTTラウンドトリップ時間

パケットを送ってから応答が返るまでの時間。対話的な体験の多くは帯域ではなくこれで決まります。

JITTERジッタ

複数回のラウンドトリップ時間のばらつき幅。会議と音声はジッタに最も敏感で、ピーク帯域にはむしろ鈍感です。

LOSSパケットロス率

一定期間に破棄されたパケットが送信パケットに占める割合。短い接続はパケットロスに敏感で、1回のロスで再送を1往復待つことになります。

MUX多重化

1本の接続の中で複数のリクエストを並行して走らせること。ハンドシェイクの回数を減らせますが、その分より多くの接続状態を維持する必要があります。

0-RTTゼロラウンドトリップ再開

セッション再開時にハンドシェイクの往復を省き、最初のリクエストを再開パケットと一緒に送ること。事前にセッションを確立していることが前提です。

MTU最大転送単位

1回で転送できる最大のパケットサイズ。UDP 系プロトコルはこれに追加の要件があり、設定を誤ると大きなパケットが通らない形で現れます。

QUIC

UDP ベースの伝送プロトコル。伝送ハンドシェイクと TLS を統合し、ストリーム単位の再送とコネクション移行をサポートします。

AEAD認証付き暗号

関連データ付きの認証付き暗号。機密性と完全性を同時に保証し、現代のプロトコルの基本的な構成要素です。

CC輻輳制御

送信側がパケットロスと遅延に応じて送信レートを調整するアルゴリズム。TCP と QUIC で実装方針が異なり、弱い回線での挙動も変わります。

EDGE入口と出口

入口はユーザーが接続する最初のサーバー、出口は最終的に外部サービスへアクセスする際の出口です。両者の距離が遅延の下限を決めます。

よくある質問

関連ページ:初回の設定はチュートリアルページ、地域と回線タイプから回線を選ぶなら回線ページ、プランとトラフィックパックの具体的な価格は料金プランページ、速度測定の流れを自分で再現したいならアクセラレーターの速度実測方法、まったくのゼロから始めるなら海外アクセラレーター入門の完全ガイドをご覧ください。