回線とプロトコルの技術リファレンス

1回の海外接続で何が起きているか

一度のアクセスを分解すると、データはデバイスから目的のサービスまで5つの段階を経ます。デバイス上のクライアント → ローカルネットワーク(ルーター、ONU、無線アクセス)→ プロバイダの出口 → 海外区間の回線 → 出口ノード → 目的のサービス、という流れです。最初の2段階は自分でコントロールでき、3段階目はプロバイダ次第、そして4段階目と5段階目こそが加速サービスが本当に最適化できる部分です。

この点はしっかり押さえておきましょう。海外向けの加速サービスは、自宅回線の品質を変えることはできませんし、目的のサービス自体の応答速度も変えられません。できるのは「プロバイダの出口 → 出口ノード」の区間を、より制御しやすい経路に置き換えることです。だからこそ「遅い」と感じたときは、まずどの区間に問題があるのかを見極めるほうが、ノードを何度も切り替えるよりはるかに効果的です。

プロトコルと回線は別々の次元

多くの解説がこの二つを混ぜて語るため、余計に分かりにくくなります。実際にはまったく別の話です。

• プロトコルは、データをどうカプセル化し、どう暗号化し、どうハンドシェイクするかを決めます。ソフトウェア層の取り決めであり、同じプロトコルを多くの異なる回線の上で動かせます。
• 回線は、パケットが実際にどの物理経路を通り、どのデータセンターを経由し、どのホップで国外に出るかを決めます。ネットワーク層の事実であり、同じ回線の上でどんなプロトコルでも動かせます。

たとえていうなら、プロトコルは荷物を送るときの封筒と封の仕方、回線は荷物が実際に通る輸送ルートです。封筒がどれだけ立派でも、ルートが渋滞していれば遅いまま。逆にルートがどれだけ順調でも、封筒が規定に合わなければ返送されることがあります。両者は別々に評価して、はじめて組み合わせが意味を持ちます。

本サービスのクライアントでは、この区別がそのまま見えます。地域サイドバーの各行には回線タイプのバッジ(専用線 / 中継 / 直結)が付き、プロトコルは現在の回線カードの下で個別に選ぶ形です。つまり回線を固定してプロトコルだけ変える、あるいはプロトコルを固定して回線だけ変える、という形で変数を一つずつ潰していけます。回線の全リストは回線一覧にあります。

遅延は4つの要素でできている

ユーザーが感じる「速い・遅い」は、技術的には主に遅延として現れます。遅延は単一の数値ではなく、少なくとも4つの要素の重ね合わせです。

1. 物理的な伝搬遅延。光が光ファイバー中を進む速度は毎秒約20万kmで、これが上限です。中国東部から日本の東京までを例にすると、直線距離は約2000km、片道の理論下限は約10ミリ秒、往復で約20ミリ秒になります。つまりアジア域内の往復20~40ミリ秒というのはすでに物理限界に近く、これ以上縮める余地はほとんどありません。
2. 経路の回り込み。パケットは必ずしも直線的に進みません。公共インターネット上の経路は各プロバイダ間の接続関係で決まり、第三国を経由するのは日常的です。直線距離2000kmの区間が、実際には5000kmを走ることもあります。
3. 待ち行列遅延。ルーターやスイッチの出口帯域は有限で、トラフィックが多いとパケットは待ち行列に並びます。待ち行列遅延は回線利用率が7割を超えたあたりから急激に増え、これが夜間ピークに遅くなる主な原因です。
4. プロトコルのハンドシェイクコスト。接続の確立そのものに往復が必要です。TCPの3ウェイハンドシェイクにTLSハンドシェイクが加わると、通常はさらに1~2往復分のコストがかかります。これは回線品質とは無関係ですが、プロトコルの選択とコネクションの再利用で圧縮できます。

最初の2つは回線が決め、3つ目は回線品質と時間帯が決め、4つ目はプロトコルが決めます。だからこそ「プロトコル選び」と「回線選び」は別々に行う必要があるのです。それぞれが最適化する対象は違うからです。

平均遅延よりジッターとパケットロスのほうが体感に効く

平均遅延は3つの指標のうちの1つにすぎません。残り2つも同じくらい重要です。

• ジッター:遅延の振れ幅です。平均60ミリ秒・振れ幅±5ミリ秒の回線は、平均50ミリ秒・振れ幅±40ミリ秒の回線より体感はずっと良好です。ビデオ会議やリアルタイム音声はジッターの影響を最も受けます。
• パケットロス:パケットが相手側に届かないことです。TCP系のプロトコルはパケットロスが起きると再送し、送信レートを下げます。1%のパケットロスでも、ロングファットパイプ(遅延が大きく帯域が広い回線)ではスループットが半分以上落ちることがあります。

したがって回線を評価するときは、遅延の数値だけでなく、夜間ピークの時間帯にジッターとパケットロスが安定しているかを見る必要があります。回線一覧には各回線のタイプが表示されており、タイプ自体がその安定性の傾向を示しています。この点は次の回線トポロジーの章で詳しく扱います。

6つの主要プロトコルの設計トレードオフ

プロトコルに絶対的な優劣はなく、あるのは設計目標の違いです。以下に挙げる6つは、現在のクライアントで最もよく見かける選択肢です。この6つには、他のどんな違いよりも重要な境界線が一本あります。最初の4つはTCPベース、後の2つはQUICベース(UDP上で動く)です。この境界線が、弱いネットワーク環境での挙動をまったく別物にします。

• Shadowsocks TCP / AEAD

  軽量な暗号化プロキシ。リソース消費が最も少なく、古いデバイスでも快適。

• VMess TCP / 複数のトランスポート

  機能は充実。複雑な分流に対応するが、ハンドシェイクのコストはやや大きい。

• Trojan TLS / 443

  プロキシ通信を標準的なHTTPSに見せる。特徴が目立ちにくい。

• VLESS TLS / 最小構成

  内蔵の暗号化層を外し、ハンドシェイクが軽く、スループットは上位。

• Hysteria2 QUIC / UDP

  ロスの多い回線向けに調整され、帯域の維持力が最も高い。

• TUIC QUIC / UDP

  0-RTTで復帰。モバイルでネットワークを切り替えても素早く戻る。

Shadowsocks:必要十分な軽量解

Shadowsocksの設計目標は「必要十分」です。ローカルの通信を暗号化してリモートノードへ転送する、軽量な暗号化プロキシです。複雑なハンドシェイクはなく、AEAD系の暗号アルゴリズムを使い、接続ごとのヘッダーのオーバーヘッドはごくわずかです。

利点は明確です。実装がシンプルで、CPUとメモリの消費が少なく、古いデバイスやルーターでも動き、クライアントのエコシステムも非常に成熟しています。欠点も同じところから来ています。機能が控えめなのです。ネイティブの多重化はなく、接続は1本ずつ確立します。偽装能力はプラグインやトランスポート層との組み合わせに依存し、素の状態ではトラフィックの特徴が比較的固定されます。

向いている人:ルーター、古いスマホ、古いPC、そしてWeb閲覧と軽い作業だけという用途。デバイスの性能が限られているなら、Shadowsocksは最もトラブルが少ない選択になりがちです。

VMess:機能は充実しているが重め

VMessはV2Rayプロジェクトが独自に開発したプロトコルで、設計はShadowsocksよりずっと充実しています。複数のトランスポート層(TCP、WebSocket、gRPC、HTTP/2)に対応し、完全なルーティング・分流ルールを備え、ドメイン・IP・ポートごとにどの回線を通すかを決められます。

タイムスタンプ付きの認証ハンドシェイクを使う点が最も注意すべきところです。クライアントとサーバーの時計がほぼ一致している必要があり、ずれが大きいと認証に失敗します。「昨日までは問題なく使えていたのに今日はつながらない」というケースの多くは、デバイスの時刻設定が原因です。

ハンドシェイクのオーバーヘッドはShadowsocksよりやや大きく、接続確立に必要な往復回数も増えます。複雑な分流ルールが必要な場面ではこのコストは妥当ですが、単純なプロキシ用途なら重すぎます。向いている人:ドメイン単位の分流が必要な人、複数のアウトバウンドルールを組みたい人、設定に手間をかけることを厭わない人。

Trojan:プロキシを標準的なHTTPSにする

Trojanの発想はまったく違います。新しい暗号方式を発明するのではなく、プロキシ通信を標準的なHTTPS通信に偽装し、TLSをそのまま使います。外から見ればごく普通のTLS接続です。プロトコルレベルで実際にそうなっているからです。

この設計の利点は特徴の隠しやすさです。通信の形は本物のWebサイトへのアクセスとほとんど区別がつきません。代償はデプロイ上の制約です。443番ポートを占有し、有効な証明書を設定する必要があり、他のサービスが443を取っていると競合します。

性能面では、Trojanのオーバーヘッドは主にTLS自体に由来します。現代のクライアントのTLS 1.3ハンドシェイクはすでに十分速く、実体験はVLESSに近いものになります。向いている人:プロキシ通信を普通のHTTPSと区別しにくくしたい場面、そして証明書を用意できるデプロイ環境。

VLESS:スリム版の高スループット路線

VLESSはVMessのスリム版と考えると分かりやすいでしょう。内蔵の暗号化層を外し、暗号化は完全にトランスポート層(通常はTLS)に任せます。暗号化の層が一つ減れば、データ処理も一回減り、CPUコストもハンドシェイクのサイズも小さくなります。

XTLS系のフロー制御と組み合わせると、VLESSは転送時に「復号してから再暗号化する」処理を一回減らせ、スループットは6つの中でも上位に入ります。代償はTLSとセットでしか使えないことです。素のVLESSには暗号化がなく、単体での利用には向きません。設定の形はVMessに近く、V2Ray系クライアントに慣れた人なら戸惑うことはありません。

向いている人:モダンなクライアントを使い、スループットを重視し、TLSの条件が揃っている場面。日常のブラウジングやAIツールの長い接続では、VLESSは非常に安定した既定の選択です。

Hysteria2:パケットロスの多い回線のために生まれた

Hysteria2はQUICベースで、UDP上で動きます。最も語る価値があるのは暗号化ではなく輻輳制御です。パケットロスの多い回線向けに調整された輻輳制御アルゴリズム(BBR系)を使い、長距離でロスが発生する海外回線では、従来のTCP系プロトコルより明らかにスループットを維持できます。

理由は、TCPがパケットロスを一律に「ネットワークの輻輳」と解釈して速度を落として再送するからです。しかし海外回線でのロスは輻輳とは無関係なことも多く、速度を落とすのは帯域を無駄に捨てているだけになります。QUIC系のプロトコルはユーザー空間でより賢い判断を実装でき、「本当の輻輳」と「ランダムなロス」を切り分けられます。

代償は2つあります。1つはUDPを使うため、一部のネットワーク環境ではUDPに追加の制限や速度制限があり、実際の性能が割り引かれること。もう1つは暗号化と輻輳制御をユーザー空間で行うため、CPU使用率とバッテリー消費がTCP系プロトコルよりやや高いことです。向いている人:長距離の海外回線、夜間ピークにロスが目立つ、安定した帯域が必要な場面。たとえば4Kストリーミングや大きなファイルのダウンロードです。

TUIC:接続確立を0-RTTまで圧縮

TUICもQUICベースですが、設計の狙いはより「速さ」に寄っています。接続確立を0-RTTまで圧縮し、セッション再開時には完全なハンドシェイクなしでデータを送り出せます。

この特性はモバイルで特に価値があります。スマホがWi-Fiとモバイル回線の間を行き来すると接続は切れて作り直しになりますが、TUICは再接続が速く、体感としては「ネットワークを切り替えても動画が途切れない」となります。エコシステムの規模は前述のプロトコルよりやや小さく、クライアントによっては対応が限られるので、選ぶ前に普段使うクライアントが対応しているか確認してください。

向いている人:スマホやタブレットなど、ネットワークを頻繁に切り替えるデバイス、そして接続の復帰が速いことを求める場面。

6つのプロトコル横断比較

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

「接続に1~2秒かかる」と「接続後は遅い」は別の問題です。前者はハンドシェイクのコスト、後者は回線品質に属します。この章では前者と、モバイルデバイスにおけるもう一つの側面、つまりバッテリーについて扱います。

初回接続にはいくつかの往復が必要

出口ノードまでの接続を確立するには、パケットを1つ送ればすぐデータを流せるわけではありません。TCP系プロトコルを例にすると、次のようになります。

1. TCPの3ウェイハンドシェイクで、往復時間1回分。
2. TLSハンドシェイク(TLS 1.3)で、さらに往復時間1回分。
3. プロトコル自身の認証は、通常TLSハンドシェイクに相乗りして完了できます。

つまり往復60ミリ秒の回線では、初回接続の「顔合わせのコスト」はおよそ120ミリ秒です。Webページを1つ開くだけなら気になりませんが、クライアントがリクエストごとに接続を作り直すと、積み重なって無視できない差になります。

セッション再開はコストを往復1回以内に抑える

TLS 1.3はセッション再開に対応しています。クライアントとサーバーは初回接続後に「チケット」を交換し、以降の接続はそのチケットで直接暗号化通信に入れ、ハンドシェイクは往復0回に圧縮されます。QUIC系プロトコル(Hysteria2、TUIC)はこれをネイティブにサポートし、TUICは0-RTTを中核的な売りにしています。

実際の影響としては、同じクライアントが数分以内に同じノードへ繰り返しアクセスする場合、2回目以降はハンドシェイクのコストがほとんどありません。だからこそ「接続後は快適なのに、再接続のたびに1~2秒待たされる」というケースは、回線そのものの問題ではなく、ハンドシェイク経路のどこかが遅くなっていることが多いのです。たとえばクライアントが遅延テストを行っていたり、回線リストを同期していたりします。

多重化:1本の接続ですべてのリクエストを流す

多重化とは、確立済みの1本の接続の中で複数のリクエストを同時に流すことです。利点はハンドシェイクが1回で済み、以降のリクエストはそのまま再利用できること。欠点は、その接続に問題が起きるとすべてのリクエストが一緒に影響を受けることです。

Shadowsocksにネイティブの多重化はなく、VMessとVLESSは対応し、QUIC系プロトコルはトランスポート層で自然に対応します。日常的な利用では、多重化が主に改善するのは「小さなリクエストが多いWebページを開く」場面です。数十のリソースを読み込む必要があるファーストビューでは、接続を再利用したほうが明らかに滑らかになります。

モバイルのバッテリー:実際に効いてくる3つの要因

スマホのバッテリー消費は主に3か所から来ており、プロトコル選択との関連度はこの順に下がります。

1. ハートビートとキープアライブ。接続を維持するため、クライアントは定期的に小さなパケットを送ります。頻度が高いほど消費が増えます。妥当なのは数十秒に1回程度で、頻繁すぎる場合(たとえば毎秒1回)は待ち受け時間に明らかな影響が出ます。
2. UDPと無線モジュールの起床。QUIC系プロトコルはUDPを使うため、モバイルOSによってはUDPの電源管理がより積極的で、無線モジュールの起床が増えることがあります。これがHysteria2とTUICがモバイルでTCP系プロトコルよりやや電力を食う主な理由です。
3. 暗号化・復号と輻輳制御の計算。どちらもユーザー空間で行うため、CPU使用率が少し高くなればバッテリーも少し多く減ります。現代のモバイルチップならこの負荷は軽く、実際の影響は3つの中で最も小さい項目です。

実践的な指針としては、待ち受け中心でたまにメッセージをやり取りする程度ならTCP系プロトコル、長時間の動画視聴やダウンロードが中心なら、QUIC系プロトコルの帯域面の利点がバッテリーのコストを上回るのが普通です。

リソース消費の比較

表の往復回数はプロトコル原理のレベルでの相対的な記述であり、実測値ではありません。実際の体験はクライアントの実装品質、回線の往復時間、そしてデバイス自体の性能にも左右されます。プロトコルを変える前に、自分のクライアントが本当に対応しているか確認してください。対応が不完全なまま変えると、「変えないほうがマシだった」という結果になりかねません。

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

回線トポロジーとは、パケットがクライアントから出口ノードまでにどのノードを経由し、どんなリンクを通るかという話です。これが夜間ピークの時間帯の安定性を決め、「昼は快適なのに夜は使いにくい」という問題の本当の答えになることが多いのです。

直結:経路は最短だが、品質は最も読めない

直結は最もシンプルなトポロジーです。クライアントが海外の出口ノードに直接接続し、途中の各ホップはすべて公共インターネットの経路に委ねられます。

利点は経路が短く、コストが低く、展開が柔軟なことです。欠点も直接的で、海外区間が公共インターネットの混雑と経路変動に完全にさらされます。同じ直結回線でも、未明は快適に走り、20時を過ぎると使いものにならないほど落ちることがあります。性能はプロバイダ同士の接続品質と、その時間帯に同じ経路を使っている人の数に左右されます。直結を選ぶときは、安定性を求める選択肢ではなく「必要十分」な選択肢として捉えてください。

中継:制御できる区間と引き換えに安定性を得る

中継の発想は、クライアントと出口ノードの間に入口ノードを1つ挟むことです。クライアントはまず自分に近い入口に接続し、そこから最適化された経路で出口ノードへトラフィックを送ります。

この方法の利点は、クライアントから入口までの区間が通常は同じ地域か同じプロバイダのネットワーク内に収まり、経路が短く品質が良いことです。入口から出口までの区間はサービス側が自分で設計でき、公共インターネット上で混雑の激しい接続点を避けられます。ユーザーが体感する遅延 = クライアントから入口 + 入口から出口となり、どちらの区間も元の制御不能な直結経路より予測しやすくなります。

代償はホップが1つ増え、理論上は遅延が少し増えることです。ただし夜間ピークの時間帯には、この「増えた1ホップ」が混雑点を迂回するため、かえって総遅延を下げることがよくあります。中継回線のもう一つの利点は入口を近くから選べることです。同じ中継回線でも、地域ごとにユーザーが別々の入口を選べるので、サービス側が地域ごとに出口を一式用意する必要がありません。

注意したいのは、中継ノードの品質が回線全体の上限を決めるという点です。入口自体が過負荷なら、その先の経路をどれだけ最適化しても意味がありません。これはサービスを評価するときにも見るべきポイントです。回線一覧で中継と表示される項目は、数よりも入口が分散しているかどうかが重要です。

専用線:海外区間を固定する

専用線(IEPL、国際イーサネット専用線)は3つのトポロジーの中で最も「重い」ものです。海外区間は公共インターネットを通らず、サービス側が通信事業者から借りた専用リンクを通ります。このリンクには取り決められた帯域と品質の指標があり、他人のトラフィックと同じ出口を取り合うことがありません。

そこから直接得られるのは安定性です。遅延の変動が小さく、夜間ピークの影響をほとんど受けず、パケットロス率も長期的に低い水準に保たれます。接続を長時間維持する必要がある用途(ビデオ会議、リモートデスクトップ、AIツールの長いセッション、大容量ファイル転送)では、専用線の価値は「突然落ちないこと」に現れ、「ピークがどれだけ速いか」ではありません。

代償はコストとカバレッジです。専用線は帯域あたりのコストが公共インターネットよりはるかに高いため、通常は需要が最も大きい地域と都市にしか展開されません。数は直結のように広くはなりません。本サービスの回線一覧では、IEPL専用線と表示される項目は日本、シンガポール、アメリカ、香港、イタリアなどよく使われる出口地域に集中しており、これも専用線の展開の考え方に沿っています。ユーザーが最もよく行く場所を優先するのです。

3つのトポロジーをどう選ぶか

選ぶ順番としては、既定では中継を使い、安定性が強く求められる作業のときは専用線に切り替え、直結は遅延に敏感でない軽い用途に残す、というのが実用的です。本サービスのクライアントは地域サイドバーから回線タイプを直接切り替えられ、サブスクリプションを再インポートする必要はありません。まず回線の全リストを見たい場合は、回線一一覧から地域別に閲覧できます。

パケットロスと夜間ピーク混雑の原因

夜間ピークに遅くなるのは海外アクセスで最もよく聞く不満であり、最も誤解されやすい現象でもあります。多くの場合「サービス側の速度制限」ではなく、いくつかの説明可能な仕組みが重なった結果です。これらの仕組みを理解しておけば、回線を変えるべきか、プロトコルを変えるべきか、それとも時間帯を変えるべきかを判断できます。

出口帯域は共有されている

プロバイダ同士の接続帯域は有限で、しかもすべてのユーザーで共有されています。20時から23時は家庭用回線の利用ピークで、大勢が同時に動画を見たり、ダウンロードしたり、ゲームをしたりするため、海外方向のトラフィックも一斉に増えます。ある接続リンクの利用率が7割を超えると待ち行列遅延が目立ち始め、9割を超えるとパケットロスが発生し始めます。

これはよくある現象を説明します。同じ回線でも、昼は遅延が安定していて、夜は何倍にも跳ね上がる。回線自体は変わっていません。変わったのは、他人と共有しているそのパイプがどれだけ混んでいるかです。

パケットロスで速度が想像以上に落ちる理由

TCPの設計では、パケットロスは輻輳のシグナルとして扱われます。ロスを検知すると送信側は送信ウィンドウを半分に切り、そこからゆっくり戻していきます。この仕組みはLANでは非常に有効ですが、遅延の大きい海外回線では問題を増幅させます。

原因は「ロングファットパイプ」効果にあります。往復遅延が大きく帯域が広い回線では、送信側は帯域を使い切るために大量のデータを送信中に保つ必要があります。1回のロスでウィンドウが半分になり、それを戻すのにかかる時間は往復遅延に比例します。往復200ミリ秒の回線では、ウィンドウの回復に数秒かかることもあります。その数秒間、スループットはピークの半分以下に落ちます。

つまり1%のパケットロスが、遅延の大きい回線では3割以上のスループット損失をもたらし得ます。これがQUIC系プロトコル(Hysteria2、TUIC)が海外アクセスでより良い結果を出す根本的な理由です。ユーザー空間でより細かい輻輳判断を実装でき、ランダムなロスと本当の輻輳を切り分け、ロスが1回起きただけで大きく速度を落とすことを避けられます。

無線アクセス区間もパケットロスに寄与する

すべてのパケットロスが海外区間で起きるわけではありません。無線アクセスは最も見落とされやすい部分です。

• Wi-Fiの電波が弱い。耐力壁を1枚挟んだり、ルーターから離れすぎたりすると、無線の再送が明らかに増えます。症状は安定して遅いのではなく、遅延が高くなったり低くなったりすることです。
• 2.4GHz帯の混雑。同じ帯域の機器が多いと、チャネルの取り合いでランダムなロスが発生します。5GHz帯に切り替えると、たいていはすぐに効果が出ます。
• モバイル回線の切り替え。スマホが基地局間を移動すると接続が一時的に途切れます。QUIC系プロトコルのほうが復帰は速くなります。
• ルーターの性能不足。古いルーターは暗号化通信を処理するときにCPUが飽和し、それ自体がボトルネックになります。症状は「接続すると全体が遅くなる」です。

切り分けは簡単です。同じデバイス、同じ回線で、有線LANとWi-Fiをそれぞれ試してください。有線で明らかに良ければ問題は無線アクセス区間にあり、回線を変えても解決しません。

実行できる切り分けの順序

1. 範囲を確認する。すべてのサイトが遅いのか、特定の1つだけか。1つだけなら、問題は目的のサービスかその接続経路にある可能性が高く、自分の回線ではありません。
2. 回線タイプを変える。中継からIEPL専用線に切り替えます。明らかに改善すれば、元の回線が夜間ピークの混雑の影響を受けていたということです。
3. プロトコルを変える。TCP系からQUIC系(Hysteria2 / TUIC)に切り替えます。改善が明らかなら、ボトルネックはリンク自体ではなく、パケットロスによる速度低下にあります。
4. 接続方法を変える。Wi-Fiから有線LANへ、あるいは5GHz帯へ切り替えます。この手順でローカルの無線区間の影響を排除します。
5. 時間帯を変える。ここまでで効果がなければ、その時間帯全体の混雑が原因かもしれません。空いている時間帯に試すことで、その判断を確認できます。

この5つの手順には順序の意味があります。「影響範囲が最も大きく、操作が最も簡単」なものから始め、少しずつ範囲を絞っていくのです。多くの場合、最初の3手順以内で問題を特定できます。切り分けの途中でサブスクリプションを再インポートする必要がある場合、手順は使い方ガイドにあります。

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

ここまでの章で仕組みを説明しました。この章ではそれらを、そのまま使える対照表にまとめます。選定の核心は、その用途が「遅延 / 帯域 / 安定性」のどれに最も敏感かを見てから、プロトコルと回線の組み合わせを決めることです。

Web閲覧とドキュメント作業

この種の用途の特徴は、リクエストが多く、1つ1つが小さく、最初のバイトまでの時間に敏感なことです。プロトコルはVLESSかTrojanを推奨します。TCPベースでハンドシェイクのコストが抑えられ、セッション再開と組み合わせれば繰り返しのアクセスはほとんど意識されません。回線は中継で十分です。ただし、お住まいの地域の中継入口が夜間ピークに厳しい場合は除きます。

開くのが共同編集ドキュメントやオンライン表計算のように接続を維持し続けるアプリなら、IEPL専用線への切り替えをおすすめします。こうしたアプリの体験上のボトルネックはピーク速度ではなく「編集中に一瞬止まらないか」であり、専用線の低ジッターがまさに効いてきます。

AIツールと開発用途

AIチャットツールとコード補完ツールに共通するのは、1つのセッションが数分から数十分続くことがあり、その間に小さなリクエストが大量に往復し、接続が切れるとセッション全体のコンテキストをやり直すことになりかねない点です。こうした用途では、ピーク速度より安定性が優先されます。

おすすめの組み合わせはVLESS + IEPL専用線です。VLESSは長い接続でのリソース消費が少なく、専用線がセッションの中断を防ぎます。利用中のネットワークがUDPに寛容なら、Hysteria2も試す価値があります。長距離回線でのスループット維持に優れています。コマンドラインツールや開発環境のプロキシ設定については、プログラマー向けの記事でより詳しく説明しています。

4Kストリーミング

ストリーミングが求める帯域は継続的です。4K再生には通常25 Mbps以上を安定して確保する必要があり、しかも再生中ずっとその帯域を維持し、上下してはいけません。プロトコルはHysteria2が第一候補で、その輻輳制御は長距離回線で帯域を守る力がより強いです。回線はIEPL専用線か品質の良い中継を使ってください。

もう一つ見落とされやすいのが出口地域の選択です。ストリーミングプラットフォームの地域ライブラリは出口IPの所在地に紐づくため、地域を間違えると「接続はできるが中身が違う」ということが起こります。地域を選ぶときは、まずそのプラットフォームがどの地域にコンテンツを持っているかを見て、次にその地域に専用線ノードがあるかを見てください。地域と回線の対応は回線一覧で1件ずつ確認できます。

モバイルデバイスとネットワークを頻繁に切り替える場合

スマホやタブレットはWi-Fiとモバイル回線の間を行き来し、基地局間も移動します。こうした用途では「接続の復帰速度」が何よりも重要です。プロトコルはTUICが第一候補で、その0-RTT復帰により切り替え後の再接続がほとんど意識されません。クライアントがTUICに対応していなければ、次点でVLESSを選びます。

回線については中継で十分です。モバイル回線自体の品質変動がすでに大きく、専用線の安定性の利点はモバイルではそれほど際立ちません。バッテリーを気にする方はTCP系プロトコルを優先すると、待ち受け時のハートビートのコストが低くなります。

ルーターと複数デバイスでの共有

ルーター上でプロキシを動かす場合、CPUとメモリが厳しい制約になるため、プロトコルは軽ければ軽いほど良いです。Shadowsocksはこの用途で最も堅実な選択です。実装がシンプルで、リソース消費が少なく、クライアントの対応も広い。ルーターの性能が良ければ、VLESSも検討できます。

本サービスのプランはデバイス台数が無制限なので、ルーター、スマホ、PCを同時にオンラインにでき、デバイスごとに別途購入する必要はありません。通信量は共有で、開通日を基準に毎月リセットされます。ルーターにすべてのデバイスを接続すると、通信量の消費は単体利用よりずっと速くなります。この点は想定しておいてください。

用途別早見表

クライアントでの回線とプロトコル設定

本サービスのクライアントは、ここまでの選択をいくつかのスイッチにまとめており、設定を手書きする必要はありません。この章では、各スイッチがどの層に対応し、いつ動かすべきかを説明します。

地域サイドバーと回線タイプのバッジ

クライアントの左側は地域リストで、各行に地域と都市が表示され、回線タイプのバッジが付きます。

• IEPL専用線 海外区間は専用リンクを通り、安定性が最も高く、長い接続やストリーミングに適しています。
• 中継 最寄りの入口を経由して転送。日常利用の既定の選択肢です。
• 直結 出口ノードに直接接続。経路は最短ですが、品質は公衆網の変動に左右されます。

同じ地域で複数の回線タイプが提供されることもあります。その場合は前の章の用途別対照表に従って選んでください。回線の切り替えにサブスクリプションの再インポートは不要で、クライアントが直接接続を再構築します。

現在の回線カードと自動回線選択

メインエリア上部の現在の回線カードには3つの情報が表示されます。出口都市、回線タイプ、現在使用中のプロトコルです。カード右側の「自動回線選択」スイッチをオンにすると、クライアントは選択した地域の範囲内で、現在状態の良い回線を自動で選びます。

自動回線選択が向いているのは「毎回手動で選びたくない」場合です。向いていないのは「出口IPを固定したい」場合です。たとえば一部のサービスはログイン地域を記憶しており、頻繁に変わると追加の確認が発生することがあります。固定が必要なときは自動回線選択をオフにし、回線を手動で指定してください。

プロトコルの切り替え

現在の回線カードの下にはプロトコルのチップ行があり、その回線が対応するプロトコルが並びます。クリックするだけで切り替えられます。プロトコルを切り替えると接続が再構築され、確立済みのセッションは一時的に中断するため、会議中やダウンロード中に気軽に切り替えないでください。

あるプロトコルが利用中のネットワーク環境でつながらない場合、原因は通常2つです。1つはそのプロトコルが依存するトランスポート層がローカルネットワークで遮断されていること(たとえばUDPが制限されているとQUIC系プロトコルは失敗します)。もう1つはクライアントのバージョンが古くて対応していないことです。後者はクライアントを更新すれば解決します。クライアントはパネルのダウンロードページで入手でき、ログイン後に取得できます。

デバイス一覧とサブスクリプションの同期

ウィンドウ下部のデバイス一覧には、同じサブスクリプションを使っているデバイスが表示され、各行にプラットフォームのアイコンと同期状態が付きます。本サービスはデバイス台数が無制限なので、一覧の長さに上限はありません。どのデバイスが使っているかを把握するためのものです。

サブスクリプションの同期は自動です。回線が調整されると、クライアントは次の同期で新しいリストを取得するため、手動で更新する必要はありません。下部の等幅フォントの行には、サブスクリプションの状態と通信量のリセット規則が表示されます。通信量は自然月ではなく、開通日を基準に毎月リセットされます。この点はプランページにも記載があります。

手動設定で注意すべきこと

サードパーティ製のクライアントを使う場合は、サブスクリプションのリンクを手動でインポートする必要があります。サブスクリプションのリンクはパネルで取得でき、ログイン後に表示されます。公開の場に貼らないでください。アカウントの認証情報と同等です。形式の例は以下のとおりです(形式の説明用であり、有効なアドレスではありません)。

https://example.com/sub?token=YOUR_TOKEN&flag=clash

インポート時によくある問題をいくつか挙げます。

1. インポートしてもノードがない。多くはサブスクリプションのリンクが不完全にコピーされ、末尾が切れています。もう一度最後までコピーし直してください。
2. ノードはあるが接続できない。クライアントのプロトコル対応状況を確認してください。インポートした設定にHysteria2やTUICのノードが含まれていて、クライアントのバージョンが対応していない場合、それらのノードは表示されても接続できません。
3. 接続はできるが速度がとても遅い。まずどの回線を通っているかを確認し、前の章の切り分け手順に沿って対処してください。
4. サブスクリプションを更新したらノードが減った。サブスクリプションのリンクが期限切れになっていないか、異なるプランのサブスクリプションを混在させていないかを確認してください。

用語集と関連情報

最後に、本ページで使った用語をまとめて説明します。後から見返すのに便利です。

よく使う用語

往復時間(RTT)

データがクライアントから相手側へ送られ、戻ってくるまでにかかる時間。単位はミリ秒。遅延の最も主要な構成要素です。

ジッター

往復時間の振れ幅。ジッターが大きい回線は、平均遅延が少し高くても安定している回線より体感が悪くなります。

パケットロス

送信したパケットが相手側に届かないこと。TCP系プロトコルはロスが起きると速度を落として再送し、QUIC系プロトコルはユーザー空間でより細かい判断ができます。

ロングファットパイプ

往復遅延が大きく帯域が広い回線。こうした回線ではTCPのウィンドウ回復が遅く、パケットロスによるスループット損失が増幅されます。

多重化

確立済みの1本の接続の中で複数のリクエストを同時に流し、ハンドシェイクの繰り返しを省きます。欠点は、1本の接続に問題が起きたときの影響範囲が大きくなることです。

0-RTT

セッション再開時に完全なハンドシェイクなしで直接データを送り、接続確立のコストを最小まで圧縮します。TUICはこれを中核的な特性としています。

輻輳制御

送信側がネットワークからのフィードバックに基づいて送信レートを調整するアルゴリズム。アルゴリズムによってパケットロスの解釈が異なり、ロスの多い回線での実際のスループットを直接左右します。

IEPL専用線

国際イーサネット専用線。海外区間は専用リンクを通り、公共インターネットのトラフィックと出口を取り合わないため、安定性とジッターの面で最も優れます。

中継

クライアントがまず最寄りの入口ノードに接続し、そこから最適化された経路で出口ノードへ送ります。制御できる区間と引き換えに安定性を得る方式です。

直結

クライアントが出口ノードに直接接続し、全区間が公共インターネットの経路を通ります。経路は最短ですが、品質は公衆網の変動に左右されます。

出口ノード

トラフィックが最終的に出ていくサーバーの位置。目的のサービスから見えるIPの所在地を決めます。

通信量のリセット日

本サービスの通信量は自然月ではなく、開通日を基準に毎月リセットされます。開通日が8日なら、次の周期の起点は翌月の8日です。

関連情報

本ページは体系的なリファレンスです。別の角度からさらに深く知りたい場合、サイト内には以下のコンテンツもあります。

• 使い方ガイド——登録からクライアントへのインポートまでのメインの流れ。初めて使う方はここから始めるのがおすすめです。
• 回線一覧——地域と回線の完全なリスト。地域別にグループ化し、回線タイプとストリーミング対応状況を表示しています。
• プランページ——3段階の月額プランと通信量パックの詳細、およびすべてのプランに共通して含まれる内容。
• 回線の選び方——地域、回線タイプ、用途の3ステップでノードを選ぶ入門記事。
• 初心者向け10のQ&A——複数デバイス、通信量の計算、速度制限、サブスクリプションのリンクなど、最もよく聞かれる質問。
• VPN選びで失敗しないために——申し込む前に確認すべきこと、返金保証や支払い方法といった細部の判断材料。
• ChatGPTの高速化——AIツールのアクセスと安定性の特集。長い接続の設定のヒントも掲載。

本ページについて

本ページで扱っているのは、プロトコルと回線の一般的な原理です。文中の往復回数やハンドシェイクのコストといった記述は、プロトコル原理のレベルでの相対比較であり、特定のネットワーク環境での実測結果ではありません。実際の体験は、お使いの回線品質、お住まいの地域、目的のサービスの位置、そして利用する時間帯によって変わります。

本サービスに関する具体的な数字は次のとおりです。110+カ国 / 150+回線、デバイス台数無制限、月額プランは¥9.9から、通信量パックは無期限、7日間の返金保証、Alipay / WeChat / USDTに対応、メールアドレスなしで登録可能。これ以外の数字は本サービスの約束を示すものではありません。