プロトコル解説:6種類のプロトコルと3つの回線トポロジ

6つのプロトコルはそれぞれ何を解決するのか

プロキシプロトコルは同時に3つの課題を処理しなければなりません。TCP と UDP のトラフィックを1本のトンネルに収めること、そのトンネルを途中の機器から見てトンネルに見せないこと、両端で認証と暗号化を完了させることです。この3つの優先順位の付け方が、プロトコルの違いを生みます。ここを押さえておけば、プロトコル名を見ても「どれが強いか」を選んでいるのではなく、「この経路に何が足りないか」を選んでいるのだと分かるはずです。

Shadowsocks:最も軽いカプセル化

Shadowsocks は最も初期の軽量設計のひとつです。中核は暗号化された SOCKS5 トンネルで、AEAD 系のアルゴリズム(AES-256-GCM、ChaCha20-Poly1305 など)でペイロードを暗号化します。プロトコルの偽装は行わず、HTTPS を装うこともありません。あくまで通信そのものに平文の特徴を残さないことだけを担います。

利点は実装が単純で、クライアントの対応範囲が最も広く、ハンドシェイクのオーバーヘッドが最小であることです。代償は通信の形が固定されることです。持続的な双方向のランダムバイト列になり、ポートも 443 とは限りません。ネットワーク機器が「非標準ポートの持続的な暗号化ストリーム」を分類しようとしたとき、依存できる外殻を持ちません。UDP の扱いも実装依存で、クライアントごとに挙動が揃いません。

VMess:プロトコルと転送を2層に分ける

VMess は UUID による身元とタイムスタンプ検証を備え、転送層は差し替え可能で、WebSocket、gRPC、HTTP/2、mKCP などの外殻をかぶせられます。これが最大の構造的な強みです。同じ認証ロジックを別の外観に載せられ、ある外観が合わなければ別のものに替えられます。

代償はプロトコル自体の複雑さです。タイムスタンプ検証は、クライアントとサーバーの時刻差が許容範囲に収まっていることを要求します。端末の時刻がずれていると認証そのものが失敗しますが、失敗の表示は「接続タイムアウト」だけであることが多く、原因を一目で判断するのは困難です。旧バージョンの AlterID は互換性のために追加の身元派生を保持していましたが、現在は不要なオーバーヘッドとリプレイの面を減らすため 0 に設定することが推奨されています。

Trojan:標準的な TLS に偽装する

Trojan の発想は最も直接的です。クライアントはまずサーバーと本物の TLS ハンドシェイクを完了し、パスワードは TLS チャネルの中で認証情報として使われます。途中の機器から見れば、この接続は普通の HTTPS サイトへのアクセスと区別がつきません。プロトコルレベルで本当にそうだからです。

代償として証明書が必須で、443 番ポートを占有する必要があり、証明書の期限切れや設定ミスがあると回線全体が使えなくなります。また「サーバー運用の質」に最も左右されるプロトコルでもあります。証明書チェーン、SNI、HTTP レスポンスの偽装のどれかひとつでも設定を誤ると、外観が破綻するか接続に失敗します。

VLESS:VMess から余分を削った版

VLESS はプロトコル層が持っていた暗号化と一部の検証を外し、安全性は外側の TLS や Reality に任せ、自身は軽い身元の受け渡しだけを行います。層がひとつ減るぶんハンドシェイクが速く、CPU 負荷も低く、XTLS の考え方と組み合わせれば転送のロスを非常に小さくできます。

代償は、それ自体が暗号化を提供しないことです。設定で TLS が正しく有効になっていなければ、安全性は完全に外層次第になります。ここが「既定で TLS を通る」Trojan との違いです。VLESS を選ぶ前提は、外層の転送がすでに正しく設定されていることを確認することであり、何もまとわずに使えるプロトコルと見なすことではありません。

Hysteria2:ロスの多い回線向けの QUIC 方式

Hysteria2 は QUIC(UDP)をベースにし、輻輳制御を内蔵しています。狙いは TCP 系プロトコルがロスの多い回線で見せる弱点です。QUIC はユーザー空間で輻輳制御を実装するため、ランダムなパケットロスに敏感でないアルゴリズムを採用できます。TCP のようにすべてのロスを輻輳の信号として扱う必要はありません。

代償は UDP の特徴がはっきり出ることです。ネットワークによっては UDP が帯域制限や優先度低下の対象になり、その場合の挙動は急に悪化します。しかもこれは環境に起因するもので、パラメータを変えても解決しません。またユーザー空間のプロトコルスタックはカーネル内 TCP より CPU 負荷が高く、低消費電力の端末ではこの差が増幅されます。

TUIC:よりミニマルな QUIC プロキシ

TUIC も QUIC をベースにし、設計はより「ミニマルな QUIC プロキシ」に近く、0-RTT の復帰ハンドシェイクに対応します。接続確立の往復が少なく再接続が速いため、切断と再接続を繰り返すモバイル環境に向いています。

代償はエコシステムが Hysteria2 よりやや狭く、一部のクライアントやパネルがまだ対応していないことです。選ぶ前に、手元のクライアントのバージョンが認識できるか確認してください。そうでないと「設定は合っているのにクライアントが受け付けない」という状況になります。

ハンドシェイク、オーバーヘッドと接続確立の速さ

プロトコル間で最初に測れる違いは「1本の接続を確立するのに何往復必要か」です。この数字がファーストビューの速度を直接左右します。特に国際回線では、1往復が100ミリ秒以上になります。

1本の接続にかかる往復回数

「接続」を押してから最初のバイトが出るまでには、避けられない手順があります:

1. 名前解決:クライアントがドメイン名でサーバーに接続する場合、まずアドレスを解決します。IP 直結ならこの手順を省けます。
2. TCP の3ウェイハンドシェイク:1往復、例外はありません。
3. TLS ハンドシェイク:TLS 1.3 は1往復、TLS 1.2 は2往復です。この層があるのは Trojan、VLESS over TLS、そして TLS をかぶせた VMess だけです。
4. プロキシプロトコル自身の認証:多くのプロトコルは認証を最初のデータパケットに載せるため、往復は増えません。
5. 接続先サイト自身のハンドシェイク:プロキシはバイトを届けるだけで、接続先サイトの接続コストはそのまま残ります。

1往復150ミリ秒の国際回線では、TCP と TLS 1.3 だけで300ミリ秒かかります。これはソフトウェアが遅いのではなく、物理的な距離が決めていることです。クライアント側の最適化が削れるのはソフトウェア層のコストだけで、光がファイバーの中を走る時間は削れません。

この時間軸での各プロトコルの位置

Shadowsocks は TLS 層を持たず、認証と最初のデータパケットが統合されるため、理論上は1往復でデータを送れます。VMess も認証を最初のパケットに載せるので往復は増えませんが、最初のパケットでタイムスタンプと UUID を解析するぶん CPU を使います。Trojan と VLESS over TLS は完全な TLS ハンドシェイクが必要で、Shadowsocks より1往復多くなります。その代わりに「HTTPS に見える」外観を得ます。

Hysteria2 と TUIC は QUIC を使います。QUIC は転送ハンドシェイクと暗号ハンドシェイクを統合し、初回接続は1往復です。TUIC は 0-RTT 復帰に対応し、セッションチケットが有効な間は再接続に追加の往復が要りません。これは「切断と再接続が多い」場面における QUIC 系の実際の優位であり、マーケティングの言葉ではありません。

CPU とメモリの実際のコスト

暗号化と復号は無料ではありませんが、現代の CPU では安価です:

• AES-GCM は AES-NI を備えた x86 プロセッサではハードウェア支援が効き、スループットは数 GB/s 規模に達します。プロキシ接続1本では到底使い切れません。
• ARM デバイス(スマートフォン、ルーター、テレビボックス)では AES 命令セットの対応が揃っておらず、ChaCha20-Poly1305 のほうが速いのが普通です。モバイルで ChaCha20 が推奨されるのはこのためです。
• QUIC 系プロトコルはプロトコルスタックをユーザー空間で実装するため、パケットごとにユーザー空間とカーネル空間を往復します。CPU 負荷はカーネル内 TCP より明らかに高く、低消費電力の端末では「ファンが回り出す」「電池の減りが速い」といった形で増幅されます。
• メモリについては、主なコストは接続ごとのバッファです。多重化を使えば複数の接続を1本のトンネルにまとめられ、ハンドシェイクとバッファを減らせますが、代わりにヘッドオブラインブロッキングが発生します。

ハンドシェイクのコストが増幅される理由

ハンドシェイクの所要時間は「新しい接続を開く」ときに一度だけ払うものです。ブラウザは同じサイトに対しては接続を再利用しますが、現代の Web ページは複数のドメインにまたがります。解析、フォント、画像、API がそれぞれ別のドメインにあり、1回のページ読み込みで十数本の新しい接続が発生することがあります。ここでハンドシェイクの往復が十数倍に増幅され、「プロトコルがファーストビューの速度に影響する」という体感の本当の理由になります。

逆に、動画再生や大容量ファイルのダウンロードのような長い接続では、ハンドシェイクは一度しか起きないため、プロトコル間のハンドシェイクの差はほとんど見えません。同じプロトコルでも場面によって体感がまったく変わるのはこのためで、「どのプロトコルが速いか」を論じる前に、どんな場面かをはっきりさせる必要があります。

モバイルのバッテリー収支

スマートフォンの消費電力は4つで構成されます。CPU の暗号化・復号、無線の送受信、システムのウェイクアップ回数、画面とハードウェアデコードです。プロトコルが影響するのは最初の3つですが、多くのユーザーが感じる「プロキシを入れると電池が減る」の実体は3つ目、ウェイクアップ回数です。

無線のウェイクアップのコスト

モバイル回線の無線状態機械にはいくつかの段階があります。アイドル、低電力、高電力です。アイドルから高電力への切り替えには数百ミリ秒かかり、その間の消費電力はピークの数倍になります。接続が10秒ごとにハートビートを送ると、無線は10秒ごとに起こされ、1日で8,000回以上のウェイクアップになります。

• TCP 系プロトコルのキープアライブは通常設定可能で、システムレベルの TCP keepalive の既定間隔は非常に長く(時間単位)、アプリケーション層でハートビートを送らない構成も十分可能です。
• QUIC 系プロトコルは NAT マッピングを維持するため、既定で周期的な keep-alive を行い、間隔は通常十数秒から数十秒です。これが QUIC がモバイルで電力消費の大きい主な理由のひとつであり、暗号化・復号そのものが原因ではありません。

ですから「プロトコルを変えれば省電力になる」という言い方の正確な形は、「周期的なハートビートをやめれば省電力になる」です。同じ QUIC 接続でも、ハートビート間隔を十数秒から2分に伸ばせば、消費電力の差ははっきり表れます。

暗号化・復号が実際に占める割合

AES 命令セットを備えたスマートフォンでは、AES-GCM のスループットはモバイル回線の帯域上限をはるかに超え、暗号化・復号に使う CPU 時間は無視できます。実際に CPU を食うのは QUIC のユーザー空間プロトコルスタックです。パケットごとにユーザー空間とカーネル空間の間のコピーが発生し、常時フルスピードでダウンロードしている間は CPU が高い周波数に張り付きます。

逆に、Web を見たりメッセージを読んだりする使い方で通信量そのものが少なければ、QUIC の CPU コストは表に出ようがなく、消費電力の差は他の要因に埋もれます。

バックグラウンドの維持と「つながっているように見える」状態

iOS も Android もバックグラウンドのアプリを回収します。プロキシ系のアプリは通常システムの VPN フレームワークを通して動作し、この経路は比較的安定していますが、アプリ内のタイマーはシステムによって間引かれます。症状としては、しばらくロックしてから解除すると、接続は残っているように見えるのに最初のリクエストだけ明らかに遅くなります。トンネルの再構築か再ネゴシエーションが必要な状態です。

この「つながっているように見える」状態は、完全に切れているより厄介です。クライアントの自動再接続のロジックが働かないからです。ロック解除後に最初のページが数秒白くなる現象がよく起きるなら、クライアントの「切断時に自動再接続」を有効にするか、長く使わないときは手動で切断してしまいましょう。

省電力のための実践的なポイント

• スマートフォンでは TCP 系プロトコルを優先し、QUIC 系は電波状況が悪い場面に取っておく。
• 遅延の小さい近い回線を選ぶ。ハンドシェイクの往復が短いほど、無線が高電力状態にある時間も短くなる。
• 不要なアプリ別プロキシは切る。必要なアプリだけをトンネルに通し、常時接続の本数を減らす。
• ハートビート間隔を長くする。ただし、NAT のタイムアウトでマッピングテーブルが消えないネットワーク環境であることが前提。
• 長時間の動画視聴では、消費電力の差は主に画面とハードウェアデコードによるもので、プロトコル間の差は薄まる。

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

プロトコルは「どう包むか」を決め、トポロジは「どの道を通るか」を決めます。国際的な場面では、トポロジのほうがプロトコルより体感への影響が大きいのが普通です。同じプロトコルでもトポロジの違う回線に変えれば、プロトコルを3回変えるより体感差が大きいことがあります。

直結

クライアントが海外のデータセンターのグローバルアドレスに直接接続し、通信は事業者の国際出口を通ります。

• 構造が最も単純で中間段階がなく、基準の遅延は最も低くなります。
• ただし国際出口は共有資源です。夜のピーク時間帯には出口のキューが長くなり、パケットロスと遅延が同時に増えます。しかもこの混雑はサービス提供側では制御できません。
• 向いている用途:軽い Web 閲覧、ピークを外した時間帯、コストを重視する場面。

直結の問題は「遅い」ことではなく「予測できない」ことです。ピーク外なら中継より速いこともあり、夜のピークにはまったく使えないこともあります。しかもその2つの状態の間に、何の前触れもありません。

中継

クライアントはまず国内の中継入口に接続し、その中継入口から海外の出口へ接続します。

• 「ラストワンマイル」の不確実性を、制御可能な区間に収めます。クライアントから中継入口までは国内バックボーンを通るため通常は安定し、中継入口から出口までは最適化された国際ルートを通ります。
• 代償はホップが1つ増え、基準の遅延が上がることです。中継ノード自体の処理能力もボトルネックになり、帯域が足りない中継は直結より悪くなります。
• 重要な指標は「中継があるかどうか」ではなく、「中継区間の国際ルートが最適化されているか」です。同じ中継でも、公衆網の出口を通るのと最適化ルートを通るのとでは別物です。

サービス提供者によって中継回線の体感差が大きいのもこのためです。名前は同じでも、背後にあるルーティング戦略はまったく違います。見分け方はひとつだけ、夜のピーク時間帯に実際に使ってみることです。

専用線

端から端までの論理専用線(IEPL や MPLS など)で、帯域は専有または準専有、公衆網出口の混雑点を通りません。

• 遅延が安定しパケットロスが少なく、夜のピーク時間帯の挙動がピーク外とほぼ変わりません。
• コストが高く総帯域も限られるため、通常は重点地域にのみ配備され、すべての国をカバーすることはできません。
• 向いている用途:リアルタイム性が求められる場面。会議、ゲーム、リモートデスクトップ、安定性に敏感な業務など。

専用線は「速い」のではなく「安定している」のです。絶対的な遅延は直結より低いとは限りませんが、夜8時に測った数字と深夜2時に測った数字がほぼ同じであること、そこに価値があります。

遅延は何で構成されるか

1. 物理的な伝搬:光はファイバー中を1ミリ秒あたり約200キロ進みます。上海からロサンゼルスまでは直線で約10,500キロ、片道の光路を1.4倍の迂回係数で見積もると約14,700キロ、片道で約73ミリ秒、往復で約146ミリ秒です。これが物理的な下限で、どんな最適化でも超えられません。
2. ルートの迂回:実際のルートは最短経路とは限らず、迂回によって数十ミリ秒が上乗せされます。
3. 待ち行列の遅延:出口が混雑すると、パケットはキューで待ちます。これは夜のピーク時間帯に数倍になり、最も制御しにくい項目です。
4. プロトコルのハンドシェイク:前章のとおり、層がひとつ増えるごとに往復が1回増えます。

ですから「この回線は遅延40ミリ秒」という言い方が意味を持つのは、起点と終点がはっきりしている場合だけです。同じノードでも、広州から測るのとハルビンから測るのとでは、数字が倍違うことがあります。

パケットロス、ジッターと夜間ピーク

「夜のピーク時間帯に遅くなる」は国際アクセスで最もよく聞く不満であり、最も誤解されやすい現象です。それは原因ひとつではなく、連鎖反応の結果です。

パケットロスはどこから来るか

• ビット誤り:ファイバーのビット誤り率は極めて低く、正常な回線ではビット誤りによるロスは無視できます。例外は無線区間(4G、5G、Wi-Fi)で、電波が弱いとビット誤り率は明らかに上がります。
• キューのあふれ:ルーターのバッファがいっぱいになり、後から来たパケットが捨てられます。国際回線で最も主要なロスの発生源です。
• ポリシーによる破棄:ネットワーク機器によっては、特定の種類の通信に帯域制限をかけたり破棄したりします。QUIC 系プロトコルが一部のネットワークで不安定になる原因でもあります。

3種類のロスは対処法がまったく違います。ビット誤りは無線環境を変えるしかなく、キューのあふれはトポロジを変えるか時間帯をずらすことで避けられ、ポリシーによる破棄はプロトコルかポートを変えるしかありません。発生源を区別せずにパラメータをいじっても、ほぼ無駄に終わります。

夜のピークはどうやって生まれるか

午後7時から11時にかけて、家庭用ブロードバンドの同時利用が増え、国際出口の総通信量が設計容量に近づくか超えます。出口の機器が待ち行列を作り始め、そこから連鎖が起きます:

1. キューが長くなり、遅延が上がる。
2. キューがあふれ、パケットが落ち始める。
3. TCP はロスを輻輳の信号と見なし、輻輳ウィンドウを半分にし、スループットが急落する。
4. ユーザーは遅いと感じて再読み込みや再試行をし、新しい接続が押し寄せ、混雑がさらに悪化する。

これは正のフィードバックなので、夜のピークの体感低下は線形ではなく、ある点を超えると急に悪くなります。「8時前は普通だったのに、8時5分に急にダメになった」と感じる人が多いのは、ここに理由があります。

なぜ1パーセントのロスが帯域の半分を壊すのか

TCP のスループットは、おおよそ「セグメントサイズ ÷(往復時間 × ロス率の平方根)」に比例します。往復150ミリ秒、ロス率1パーセントのとき、TCP 接続1本の理論スループットはピークのごく一部まで落ちます。「速度テストでは満速なのに、Web ページを開くのが遅い」が同時に起きるのはこのためです。速度テストはマルチスレッドで並列に測り、Web ページは接続1本で読むからです。

ここが分かると、多くの「謎」が説明できます。同じ時間、同じ回線で、ダウンローダーはフルスピードなのにブラウザは引っかかる。これはブラウザの問題ではなく、並列のモデルが違うからです。

QUIC 系がロスの多い回線で強い理由

QUIC はユーザー空間で輻輳制御を実装し、よく使われるアルゴリズムは帯域と往復時間のモデルに基づいて、すべてのロスを輻輳の信号としては扱いません。ランダムなロスが主体の回線では、これによってスループットをより良く保てます。代償として「本当の輻輳」への反応も鈍くなり、実際に帯域が足りない場面では公平性を欠く挙動になります。

言い換えれば、QUIC 系は「速い」のではなく「ロスに寛容」なのです。回線自体がロスを出していないときは TCP 系と目立った差はなく、ロスが出始めてから差が開きます。

バッファブロート

家庭用ルーターや一部の事業者設備は大きなバッファを使います。バッファが大きいことはバースト時には良いことですが、常時飽和していると待ち行列の遅延が数百ミリ秒まで跳ね上がります。症状は、速度テストは正常なのにクリックのたびに少し待たされる、動画は再生できるのにシークバーを動かすとくるくる回る、といったものです。

見分け方:ローカルゲートウェイと海外の宛先の往復時間を同時に観察します。ゲートウェイ自体が揺れていれば問題はローカルにあり、ゲートウェイが安定していて海外の宛先が揺れるなら問題は国際区間にあります。この一手間で、切り分けの範囲を半分に減らせます。

遅延よりジッターのほうが体感を左右する

遅延が高くても安定していれば、ユーザーは慣れます。遅延がさほど高くなくてもジッターが大きいと、動画は頻繁にバッファリングし、音声は途切れ、ゲームではキャラクターがワープします。回線を選ぶときは、平均遅延よりジッターを重く見るべきです。多くのクライアントは「遅延」の数字をひとつだけ表示しますが、それは数回の計測の平均値であることが多く、ジッターは分かりません。自分で連続して測り、変動幅を見る必要があります。

用途別に選ぶ

前の章までは原理の話でした。この章では結論を示します。前提として、以下の提案はすべて「回線自体が使える状態」であることが条件です。夜のピーク時間帯に回線がすでにひどく混雑しているなら、プロトコルを変えても緩和はできても治癒はできません。

日常の Web とオフィス作業

VLESS over TLS または Trojan がおすすめです。

理由:Web ページの読み込みでは多数の短い接続が発生し、ハンドシェイクの往復回数が増幅されます。この2つは標準の TLS を通り、接続の再利用と組み合わせてファーストビューの体験が安定します。また通信の外観が普通の HTTPS なので、さまざまなネットワーク環境で互換性が最も高いのも利点です。オフィス用途で QUIC 系はおすすめしません。短い接続が中心の場面では QUIC のハンドシェイクの利点は目立たず、ユーザー空間プロトコルスタックの CPU コストが低スペックのノート PC では体感されるからです。

4K 動画配信

VLESS または Trojan に、中継または専用線を組み合わせるのがおすすめです。

理由:動画配信は長い接続で大流量が続くため、帯域の安定性が優先です。TCP 系プロトコルは帯域が十分ならフルスピードを出せますし、専用線や最適化された中継は夜のピークの出口混雑を避けられます。利用しているネットワークが UDP に寛容なら、Hysteria2 も選択肢です。ロスのある回線でもビットレートを保ちやすく、プレーヤーの画質落ちを招きにくくなります。サイト内の動画配信の視聴ページには配信サービス別の回線の提案と、ビットレートと帯域の関係の詳しい解説があります。

オンラインゲーム

Trojan または VLESS で、近いノードを選び、多重化はオフにします。

理由:ゲームは遅延とジッターに敏感で、帯域には敏感ではありません。TCP 系プロトコルの遅延曲線はより平坦です。多重化は複数の接続を1本のトンネルに詰め込むため、トンネルでロスが出るとすべての接続が一緒に詰まります(ヘッドオブラインブロッキング)。「試合の途中で全員が一斉にラグる」という形で現れます。

ゲーム自体が UDP 転送を必要とする場合は、クライアントとサーバーの両方で UDP が有効になっているか確認してください。そうでないと「ログインはできるが対戦に入れない」状況になります。遅延とロスの実測の考え方はゲームでの遅延とパケットロスの分析で詳しく扱っています。

大容量ファイルのダウンロードと更新

Hysteria2 がおすすめです。

理由:ダウンロードは純粋なスループットの場面で、遅延には敏感ではありません。ロスの多い回線では QUIC 系のスループットの優位が最もはっきり出ます。代償は CPU 負荷の高さで、低消費電力の端末では逆にボトルネックになることがあります。ダウンロード中に速度が伸びないのに CPU が張り付いているなら、端末の処理能力が先に上限に達しています。

モバイルでの長時間待機

Trojan または VLESS がおすすめです。理由はバッテリーの章のとおりで、QUIC 系の周期的なキープアライブが無線を起こし続けます。Android のバックグラウンド維持と省電力の仕様には別の細かい話があり、Android での実測比較も参考になります。

電波状況が悪い環境

Hysteria2 または TUIC がおすすめです。

理由:弱い回線の典型的な特徴はロス率の高さとジッターの大きさです。TCP 系プロトコルはこうした状況で輻輳ウィンドウを何度も縮め、「速度が上がったり下がったりする」挙動になります。QUIC 系の輻輳制御はランダムなロスに敏感でなく、速度がより安定します。公共施設の Wi-Fi、電波が1～2本しか立たないモバイル回線、新幹線の中などがこれに当たります。

AI ツールを併用する場合

AI ツールの API 呼び出しは短いリクエストですが、1回の応答が長くなることがあります(生成系の返答はストリーミングで返ります)。こうした場面は最初のパケットの遅延に敏感で、帯域の要求は中程度です。VLESS または Trojan に中継回線を組み合わせるのがおすすめです。詳しくはサイト内のAIツール特集をご覧ください。

段階的な切り分けとセルフチェック

切り分けの核心は層別です。「つながるか」と「速いか」を分け、さらに「速いか」を遅延、ロス、帯域の3つに分解します。各層で変数をひとつだけ変えるからこそ、どの手順が効いたのかが分かります。

第1層:通信が本当にトンネルを通っているか確認する

「接続済み」の表示は、通信が本当に回線を通っていることを意味しません。確認方法は3つあります:

1. 出口 IP を確認する:接続の前後でそれぞれ確認し、値が変わり、かつ帰属先が回線の地域になっているべきです。
2. DNS を確認する:名前解決のリクエストはトンネル内のリゾルバで処理されるべきで、ローカルの事業者のものではありません。DNS がローカルを通っていると「接続はできるのに一部のサイトが開けない」状態になります。
3. アプリ別に確認する:アプリ別プロキシを有効にしている場合、対象のアプリがプロキシのリストに入っているか確認します。

詳しい手順はサイト内の記事VPN が本当に効いているか確認する方法にあります。コマンドラインでは次のように確認できます:

# 1. 現在の出口 IP を確認(サンプルアドレス。プレーンテキストで IP を返す任意のサービスに置き換えてください)
curl -s https://example.com/ip

# 2. 現在使用中の DNS サーバーを確認
nslookup example.com
# 出力の "Server:" の後ろが、実際に使われているリゾルバのアドレス

# 3. 連続して計測し、平均値だけでなくジッターを見る
ping -c 20 example.com

ping は ICMP を通るため、回線によっては ICMP の優先度が TCP と異なります。ping が正常でも TCP が正常とは限らず、逆もまた同じです。TCP の往復を測るには、curl で各段階の所要時間を見ます:

curl -o /dev/null -s -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total}\n" https://example.com

これらの数字は、時間がどの区間に費やされたかを直接教えてくれます。time_namelookup が大きければ DNS の問題、time_connect が大きければ TCP ハンドシェイクか回線の問題、time_appconnect が time_connect よりずっと大きければ TLS ハンドシェイクが遅く、通常は回線の往復が長すぎるか証明書チェーンが長すぎることが原因です。

第2層:接続できない

順番に確認し、手順を飛ばさないこと:

• サブスクリプションの期限切れ:通信量を使い切るか期限が切れると、クライアントは「接続済み」と表示したまま、すべてのリクエストが拒否されます。最も多く、最も見落とされやすい項目です。
• 端末の時刻:VMess はタイムスタンプ検証に依存するため、時刻のずれが大きいと認証そのものが失敗します。自動時刻合わせを有効にしてください。
• プロトコルとポートの一致:サーバー側の設定が変わったのにクライアントのサブスクリプションが更新されていない、というのがよくある原因です。サブスクリプションを取得し直してください。
• ローカルのファイアウォール:セキュリティソフトが非標準ポートの外向き接続を遮断し、すべての回線につながらないように見えることがあります。
• 証明書:Trojan と VLESS over TLS は証明書に依存します。証明書が期限切れのとき、クライアントは「接続タイムアウト」ではなく TLS ハンドシェイクの失敗を報告します。

第3層:つながるが遅い

1. 回線を変える:同じ回線でも時間帯によって挙動が大きく変わります。まずトポロジの違う回線に変えて比較します。
2. プロトコルを変える:同じ回線でプロトコルを変えます。TCP 系が遅く QUIC 系が正常なら、回線にロスがあるということです。
3. 時間帯を見る:遅くなる時刻を記録します。夜間に固定されているなら出口の混雑、一日中そうなら回線自体の問題です。
4. 単一接続で見る:シングルスレッドのダウンロードで試します。マルチスレッドは速くシングルスレッドが遅いなら、ロスかバッファブロートがあります。
5. MTU を見る:QUIC は MTU に敏感です。経路 MTU ブラックホールの症状は「ハンドシェイクは成功し、小さいリクエストは通るが、大きいリクエストで止まる」です。MTU を下げて(たとえば 1280)試してください。

第4層:一部のアプリだけ不具合が出る

• アプリ別プロキシのリストに対象のアプリが入っているか。
• アプリが独自の DNS や暗号化 DNS を使い、トンネル内の解決を迂回していないか。
• アプリが IPv6 を強制しているのに、トンネルが IPv4 しかプロキシしていないのではないか。
• アプリが証明書ピンニングを使っていて、中間プロキシと互換性がないのではないか。

この層の切り分けは最もコストがかかります。アプリごとにネットワークの挙動が違うからです。有効な方法は、まずブラウザでトンネル自体に問題がないことを確認し、それからアプリを1つずつ確認することです。

設定項目の早見表とよくある誤解

最後の章では、クライアントにあるスイッチをひとつずつ説明し、よくある誤解をいくつか挙げます。この章はツールページのように使ってください。判断に迷った項目があれば戻って確認できます。

クライアントのスイッチ類

• TLS:有効にすると通信の外観が HTTPS になります。Trojan と VLESS では必須です。Shadowsocks と VMess にも TLS をかぶせられますが、往復が1回増えます。
• XTLS と Reality:VLESS の2つの転送最適化です。前者は暗号化層のコピーを減らし、後者はサーバーが自前の証明書を持たなくても本物の TLS の特徴を示せるようにします。どちらもサーバー側の対応が必要で、クライアントだけ有効にしても効きません。
• 多重化:複数の接続を1本のトンネルにまとめます。ハンドシェイクの回数は減りますが、ロスのある回線ではヘッドオブラインブロッキングが発生します。Web 閲覧ではオン、ゲームと音声通話では非推奨です。
• UDP 転送:UDP の通信をトンネル経由にするかを決めます。ゲーム、音声通話、一部のビデオ通話がこれに依存します。オフにすると、これらのアプリは直接接続になるか使えなくなります。
• 輻輳制御:QUIC 系プロトコルでは通常選択できます。帯域モデルに基づくアルゴリズムはロスの多い回線でスループットが良くなりますが、本当の輻輳時には他の通信に対して優しくありません。
• アプリ別プロキシ:指定したアプリだけをトンネルに通します。省電力で干渉も減りますが、設定を誤ると「特定のアプリがつながらない」状態になります。
• サブスクリプションの自動更新:最新の回線を定期的に取得します。有効にすることをおすすめしますが、頻度を上げすぎると更新のたびに短時間の切断が起きます。

よくある6つの誤解

誤解1:新しいプロトコルほど速い。プロトコルが決めるのはオーバーヘッドとロスへの耐性で、帯域の上限は回線と出口が決めます。ロスの少ないきれいな回線では、6種類のプロトコルのスループット差は回線間の差よりはるかに小さいものです。

誤解2:暗号化が強いほど遅い。AEAD 系の暗号化は現代のプロセッサではコストがごく小さく、本当のボトルネックは回線です。暗号化を AES-256 から ChaCha20 に変えると、スマートフォンでは計測できる差が出ることがありますが、デスクトップではほとんど体感できません。

誤解3:遅延が低ければ必ず速い。遅延が影響するのは「始まり」の速さで、スループットはロスと輻輳ウィンドウにも左右されます。往復40ミリ秒でもロスが2パーセントある回線は、往復80ミリ秒でもほとんどロスのない回線よりダウンロードが遅いことがあります。

誤解4:UDP は必ず帯域制限される。ネットワーク環境次第で、一概には言えません。見分け方は簡単です。同じ回線で TCP 系と QUIC 系のプロトコルをそれぞれシングルスレッドでダウンロードし、結果を比べます。

誤解5:多段プロキシのほうが安全。層を重ねても遅延と故障点が増えるだけで、1層の暗号化の強度は上がりません。必要なのは正しいプロトコルの設定であって、層の数ではありません。

誤解6:接続数が多いほど速い。ブラウザの同時接続数には上限があり、超えた分は待ち行列に入ります。クライアントを複数立ち上げ、トンネルを複数張っても、帯域を取り合うだけです。

このハンドブックを活用する

まず試してみようと決めた方は、料金プランページでプランを確認してください。月額プランは月額¥9.9で60GB、¥18で250GB、¥28で500GB。通信量は開通日を基準に毎月リセットされ、途中でアップグレードした場合は差額を残りの日数で按分します。ほかにデータパックとして¥158/300GB、¥358/1000GB、¥658/3000GB があり、使い切るまで有効で期限はありません。すべてのプランで台数は無制限、Alipay・WeChat・USDT に対応しています。登録にメールアドレスは不要で、ユーザー名とパスワードだけで始められます。初回のお支払いから7日以内なら、理由を問わず返金を申請できます。

すでに購入済みの方は、使い方ガイドに沿ってインポートの手順を一度済ませてから、戻ってきて用途別にプロトコルを選んでください。サービス自体の位置づけと方針を先に知りたい方は当サービスについてをご覧ください。