Shadowrocketのプロトコル解説：設定・速度・バッテリー消費の比較

01 / FOUNDATIONS

プロトコルのレイヤー構造とiOSでの性能

接続を確認可能な要素に分ける

Add Serverで種類を選ぶだけでは、接続の動作はすべて決まりません。プロキシ接続には、サーバーアドレス、ポート、認証、基盤となる通信方式、暗号化、接続先の名前解決、トラフィックの振り分けも関係します。プロトコルはクライアントとサーバーが合意するメッセージ形式、通信方式はそのメッセージを運ぶ経路と考えるとわかりやすいでしょう。同じプロトコルでも通信方式が異なれば、接続確立の手順、追加のオーバーヘッド、問題が起きる箇所が変わることがあります。同じ通信方式を使っても、プロトコルが異なれば認証項目を流用できるとは限りません。

たとえばVLESSはTLSやWebSocketなどと組み合わせられますが、VLESSを選ぶだけでこれらの条件が自動的に適用されるわけではありません。サーバーが特定のPathを要求する場合、プロトコル名からPathを推測することはできません。サーバーが通常のTCPのみを受け付けるなら、クライアントで別の通信方式を有効にしても互換性は得られません。入力前に、手元の情報を「接続先」「認証情報」「通信経路」「接続先の確認方法」の4つに分けて整理してください。必須項目が不足している場合は、元の設定を確認しましょう。

スループット、応答時間、安定性は別々の指標

速度には少なくとも、ページを初めて開くまでの待ち時間、ダウンロードを続けたときのスループット、通話や操作中のジッターという3つの側面があります。ハンドシェイクが多い構成では初回接続が遅くなる一方、長時間の接続は安定することがあります。帯域幅が大きくても、キューイングによって操作の応答が遅くなる場合があります。Connectivity Testは明らかな接続不能の確認に役立ちますが、テスト対象、接続の再利用、DNSキャッシュの有無によって結果が変わります。実際の用途におけるテストの代わりにはなりません。

iOSでは、アプリの通信はシステムのネットワーク拡張機能を通じて処理されます。性能はプロトコルのアルゴリズムだけでなく、無線信号、サーバーとの距離、サーバー負荷、接続先のWebサイトにも左右されます。Wi-Fiの電波が弱い場合、暗号処理よりも通信の再送が速度に影響することがあります。モバイル回線が頻繁に切り替わる環境では、継続的なスループットより再接続の待ち時間が問題になることもあります。「特定のプロトコルが必ず最速」という主張には、再現可能な技術的根拠がありません。同じ端末、同じネットワーク、同じテスト内容で比較してください。

比較では一度に変更する条件を1つに絞ります。接続先、ネットワーク、テスト時間帯をできるだけそろえ、初回応答、継続的な通信、失敗の状況をそれぞれ記録してください。プロトコル、DNS、ルール、サーバーを同時に変更すると、接続が復旧しても原因を特定できません。

バッテリー消費は接続の使われ方で変わる

バッテリー消費はプロトコル名だけで比較できません。モバイル通信モジュールの起動、電波が弱い環境での再試行、大量の短時間接続、頻繁なキープアライブ、バックグラウンドでの継続的な通信などが消費を増やすことがあります。ハンドシェイクが重くても接続を安定して再利用できる構成が、軽量でも再接続を繰り返す構成より必ず電力を消費するとは限りません。端末の発熱は画面の明るさ、アプリの負荷、充電状態も考慮して判断してください。クライアントを起動した後に発熱したという時間的な前後関係だけで、原因を特定することはできません。

バッテリー消費を測る場合は、同じ長さの動画を再生する、同じ文書を閲覧するといった代表的な使用状況を決め、システムのバッテリー画面でアクティブ時間とバックグラウンド動作を確認します。一方のテストではConnectivity Testを続け、もう一方では待機する、といった比較は避けてください。電波状況が異なる2回の結果は、参考になりにくいものです。異常がある場合は、バックグラウンドで接続失敗を繰り返していないか、サブスクリプションの更新を再試行していないか、On Demandが接続を何度も開始していないかを先に確認してください。

プロトコルの機能は接続経路全体で確認する

UDPに対応するプロトコルを使っていても、現在のサーバー、通信方式の組み合わせ、接続先でUDPを利用できるとは限りません。クライアント側の設定、サーバー側の設定、ネットワークからUDPへの到達性、出口のポリシーがすべて整っている必要があります。反対に、Webページが開けてもUDPが使える証拠にはなりません。Webページの通信はTCPだけで完結する場合があるためです。問題を報告するときは「ネットワークは正常」「プロトコルが動かない」とだけ書かず、実際の用途で使われた通信方式を明記してください。

本記事でのiOSに関する説明は、モバイル端末での動作上の違いを示すものであり、他のプラットフォームでこれらのプロトコルが利用できないという意味ではありません。具体的な設定項目は、現在のShadowrocketの画面とサーバー設定を確認してください。インストールと入手方法は全プラットフォーム版のダウンロードにまとめています。本記事ではインストール手順を繰り返さず、端末の機種だけから未確認の互換条件を推測することもありません。

02 / SHADOWSOCKS

Shadowsocks：共有認証情報と暗号化方式

設計の背景と適用範囲

Shadowsocksは、クライアントとサーバーが事前に合意した認証情報と暗号化方式を使ってプロキシデータをやり取りする、比較的シンプルな構成です。基盤となる項目を自由に入れ替えられる汎用コンテナではありません。双方が同じプロトコル形式を理解し、暗号化方式も一致している必要があります。ユーザーにとって大切なのは名前を覚えることではなく、サブスクリプションに記載された種類、サーバー、ポート、パスワード、暗号化方式が同じサービス項目に属していることを確認することです。

新しい認証付き暗号化方式は、データの機密性と完全性を同時に扱い、暗号化だけで確実な認証がない場合に生じる問題を防ぎます。世代や拡張によって必要な鍵の形式が異なることがあり、任意の通常のパスワードをすべての方式に貼り付けられるわけではありません。クライアントの一覧に方式が表示されていても、既存のサーバーでその方式が有効になっているとは限りません。サービス提供元が示す組み合わせを優先し、名称が新しいという理由だけで暗号化方式を変更しないでください。

Server、Port、Password、Methodの対応関係

Serverはプロキシサーバーのアドレスで、ドメイン名またはIPを指定します。Portはそのサーバーが待ち受けるポートであり、接続先Webサイトのポートではありません。Passwordは選択した暗号化方式とともに、認証または鍵の材料として使われます。大文字と小文字は区別され、末尾の空白も結果に影響することがあります。Methodはサーバー側の設定と一致させてください。方式が違っていても、基盤となる接続は確立し、有効な通信応答が得られないという症状になることがあり、「方式が一致しない」と明確に表示されるとは限りません。

インポート後に項目が表示されるのに接続できない場合は、まずこの4項目を元の情報と1つずつ照合してください。コピー時に全角記号や改行が混入していないか、途中で切れていないか、管理画面のポートをプロキシのポートとして入力していないかも確認します。特定の形式の鍵を要求する設定では、元のエンコード形式を保ち、自分で再計算したり文字を削除したりしないでください。サブスクリプションに表示される名前はメモにすぎません。地域名やプロトコル名が書かれていても、内部の設定項目が正しいとは限りません。

項目	確認する内容	よくある誤解
Server / Port	プロキシのアドレスと待ち受けポートが同じ設定項目に記載されている	アドレスを名前解決できれば、サーバーも必ず利用できる
Password / Method	パスワードの形式と暗号化方式が対応している	Methodを変更するだけでプロトコルの世代を切り替えられる
追加の通信パラメーター	クライアントとサーバーの両方で同じ組み合わせがサポートされ、有効になっている	オプション項目を増やすほど接続が安定する
UDP	クライアント、サーバー、ネットワーク経路のすべてが対応している	WebページにアクセスできればUDPにも到達できる

追加パラメーターは標準で必須ではない

一部のShadowsocks設定には、追加の通信方式や拡張パラメーターが含まれます。これらはスイッチを見つけたら有効にすべき機能ではなく、サーバー側の要件の一部です。元のサブスクリプションに記載がなければ、別の設定からコピーしないでください。特にPath、ホスト名、追加の認証情報は特定のサービス構成に結び付いていることが多く、値が違うとサーバー、パスワードが正しくても接続できないことがあります。

手動で項目を作成する場合は、まずサーバーが明示的に要求する最小限の設定を入力して接続を確認し、拡張が必要なら元の情報に沿って1つずつ追加してください。サブスクリプションからインポートした項目が正常に動作しているなら、「最適化」のために手入力し直す必要はありません。更新後に設定が元に戻る場合、その項目はサブスクリプションによって管理されています。同じ自動更新項目を何度も編集するのではなく、提供元の設定を確認してください。用途を明記したテスト項目を別に残しておくと、比較や復元が容易になります。

iOSで適しているかを判断する

電波が安定し、サーバーに十分なリソースがある環境では、Shadowsocksの比較的シンプルなデータ処理経路が追加のオーバーヘッドを抑えるのに役立つ場合があります。ただし、ダウンロード速度が保証されるわけではありません。選ぶ際は、利用中のサービスが安定しているか、UDPが必要か、短時間接続が頻繁に発生するか、実際のネットワークでパケットロスがあるかを重視してください。暗号化方式によって処理負荷は異なりますが、日常的な用途ではネットワークの遅延やサーバー負荷を先に調べる方が有効なことが多いでしょう。

待機中のバッテリー消費が増えた場合は、暗号化方式をすぐ変更するのではなく、接続の再試行が続いていないか、アプリがバックグラウンドで同期していないか、UDPのキープアライブが動作していないかを確認してください。ある用途だけ失敗して他は正常なら、接続先や通信方式から原因を絞り込みます。ルールの適用、接続先の名前解決、サーバー側の出口制限が原因であり、Shadowsocks自体に問題があるとは限りません。安定して動作する設定では、すべてのパラメーターを保つ方が、別の通信方式を独自に組み合わせるより確実です。

03 / VMESS & VLESS

VMessとVLESS：認証と通信方式を分けて考える

似た設定項目でも同じプロトコルとは限らない

VMessはユーザー認証とプロキシメッセージのカプセル化を組み合わせ、独自のデータ保護機能を備えています。VLESSはより軽量な認証・転送構造を重視し、通常は外部のセキュリティレイヤーで通信を保護します。どちらもUUIDを使い、似た通信方式と組み合わせられる場合がありますが、ネットワーク上のメッセージ形式は異なります。VMessの項目から同じUUIDをVLESSの項目へコピーしても、サーバーが自動的に互換対応するわけではありません。クライアントのTypeは、サーバーで実際に設定されている種類と一致させてください。

この役割分担の変化が示す重要なトレードオフがあります。認証、暗号化、通信経路を分離すれば一部の重複処理を減らせますが、組み合わせを設定する責任は増します。VLESSの軽量な設計は、暗号化されていない接続にも機密性があるという意味ではありません。VMessに内部保護機能があっても、外側のTLS設定を確認しなくてよいわけではありません。セキュリティの範囲を判断するには、「ユーザーを認証するのはどの層か」「サーバーを確認するのはどの層か」「データを保護するのはどの層か」をそれぞれ確認してください。プロトコル名だけですべての答えがわかるわけではありません。

UUID、Security、時刻に関する条件

UUIDは識別子であり、完全に一致している必要があります。見た目が似ていても使い回せるとは限りません。コピー時は元の文字と区切り形式を保ってください。VMessのSecurityなどの項目は、サーバー提供元の情報に従って選びます。古い設定には過去の互換性に関する項目が含まれる場合がありますが、経験則でどの項目にも同じ値を入力しないでください。VLESSのデータ暗号化に関する選択肢にも、VMessの意味を当てはめないでください。同じ英単語でも、プロトコルによって異なるレイヤーを指す場合があります。

VMessの一部の認証処理は、クライアントとサーバーの時刻差に影響されます。設定が正しそうなのに認証に失敗する場合は、端末で日付と時刻の自動設定が有効か確認し、サービス提供元にサーバー時刻を問い合わせてください。タイムゾーン表示を変更しても実際の時刻が補正されるわけではなく、接続のために端末の地域設定を変える必要もありません。時刻を合わせても失敗する場合は、時刻設定を何度も変更せず、プロトコル、認証情報、通信方式を確認してください。

WebSocket、gRPC、TCPの違い

TCPは信頼性のあるバイトストリームを提供し、プロトコルのメッセージを直接伝送できます。WebSocketはHTTPハンドシェイクを使って確立するメッセージ通信レイヤーを追加します。gRPCは通常HTTP/2を基盤とし、サービスやストリーム処理に関する仕組みを備えています。どれを使うかはクライアントの性能上の好みだけでは決まりません。サーバーの待ち受け方式と中継条件にも左右されます。サーバーがWebSocketのみを受け付ける場合、クライアントをTCPに変更しても、追加のオーバーヘッドを省いて接続を使い続けることはできません。

WebSocketのPathとHostは、手元の設定情報に従って入力してください。Pathは通信経路のパスであり、サーバーアドレスやサブスクリプションURLではありません。大文字と小文字、スラッシュ、末尾の文字列が一致条件に影響する場合があります。gRPCのサービス名も正確に合わせる必要があり、WebサイトのトップページのPathで代用できません。中継がある場合、サーバーアドレス、HTTP Host、TLS Server Nameがそれぞれ異なる役割を担うことがあります。3つの項目を無理に同じ値にせず、それぞれの意味を確認してください。

通常の設定で証明書の検証を無効にしないでください。TLSの認証エラーが発生した場合は、Server Name、証明書の有効期限、端末時刻、接続先アドレスを先に確認します。エラーを回避して接続できても、正しいサーバーに接続できている証拠にはなりません。

TLSと特殊なストリームパラメーターの扱い

TLSのServer Nameは、接続先として想定するサーバーを示し、サーバーが証明書を選ぶ際に使われることがあります。証明書の検証では、接続先がその名前と一致するか確認します。HTTP Hostとは異なる段階で使われる項目です。サービス提供元から個別のServer Nameを指定されている場合、ServerにIPを入力したからといって消さないでください。ALPNはアプリケーション層プロトコルのネゴシエーションに関係します。現在の通信方式とサーバーの要件が明確な場合にだけ変更してください。

一部のVLESS構成では、特定のストリームパラメーターや追加のハンドシェイク情報が必要です。これらは汎用の高速化スイッチではありません。現在のクライアント画面が該当する組み合わせに対応していること、元の設定に必要な項目がすべて含まれていることを確認してください。必須情報がない場合、別のサービス項目の値で補わないでください。インポートに成功したということはテキストが認識されたというだけで、サーバー認証が完了したことや、通信が想定した経路を通ることを示すわけではありません。

iOSでの接続再利用とバッテリー消費

追加のHTTP通信レイヤーやTLSハンドシェイクは、接続確立時の処理を増やしますが、接続を再利用できればそのコストを分散できます。モバイルネットワークが切り替わると古い接続が無効になり、再接続が必要になる場合があります。これが頻繁に起きると、継続的なダウンロード速度が遅くなるのではなく、ページを開く際にときどき長く待たされることがあります。テストでは新規接続と長時間接続を分けて観察し、異なる使用感を1つの速度スコアにまとめないでください。

多重化が常に有効とは限りません。外側の接続を共有すればハンドシェイクの繰り返しを減らせますが、外側の経路でパケットロス、キューイング、リセットが発生すると、複数の通信が同時に影響を受けることがあります。サーバー提供元から明確な案内がない場合は、インポートした設定を保ち、同じ用途で接続の安定性を比較してから変更してください。UUIDや通信方式に関する基本事項は、用語解説も参照してください。画面上の名前が似ているからといって、互換性を推測しないようにしましょう。

04 / TLS & GENERAL PROXIES

Trojan、HTTP、SOCKS5の違い

Trojan：パスワード認証とTLS通信

Trojanの一般的な設計では、プロキシの認証と転送をTLS接続内で行い、確立されたTLSの仕組みで通信を保護してサーバーの身元を確認します。クライアントで重要となる設定項目は、通常、サーバー、ポート、パスワード、TLS関連情報です。パスワードはサービスを利用する権限を確認し、証明書は接続先が想定したサーバーか確認します。役割は異なり、パスワードが正しくても証明書の認証エラーを補うことはできません。

ServerにIPを指定し、証明書がドメイン名に対して発行されている場合は、元の情報に従って正しいServer Nameを入力する必要があります。「アドレスに接続できる」ことは「サーバーの身元を確認できる」ことを意味しません。証明書の期限切れ、証明書チェーンの不備、端末時刻の誤り、別のサイトの証明書がサーバーから返されるといった原因で失敗することがあります。ポートを次々と変えて試すのではなく、認証、TLS、ネットワークのタイムアウトのどこで起きているエラーか確認してから、サービス提供元に問い合わせてください。

HTTPプロキシとHTTPS接続先は別のもの

HTTPプロキシはもともとHTTPリクエストの転送を目的に作られています。HTTPS接続先にアクセスする場合は通常、CONNECTで接続先へのトンネルを確立し、その後、アプリとWebサイトの間でTLS通信を行います。「WebサイトがHTTPSであること」と「クライアントからプロキシまでの経路がTLSで保護されていること」は別の事柄です。プロキシの入口が通常のHTTPであれば、接続先がHTTPSだからといって、入口までの経路で認証情報やすべてのメタデータが同等に保護されるとは限りません。

現在の画面とサーバーがHTTPSプロキシに対応している場合は、該当する種類として外側のTLSを設定してください。通常のHTTPのポートを一般的なTLSポートに変更するだけでは設定できません。ユーザー名、パスワード、認証方式、サーバーの待ち受け設定を一致させる必要があります。CONNECTで接続できるポートが制限されるサービスもあります。一部のWebサイトだけ使える、または特定のポートだけ使えない場合は、DNSやルールを原因と決めつける前にサーバー側の許可範囲を確認してください。アプリケーション層の拒否応答と、基盤接続のタイムアウトも分けて記録しましょう。

SOCKS5：汎用プロキシネゴシエーション、暗号化なし

SOCKS5は接続先を指定できる汎用的なプロキシネゴシエーション方式です。サーバーの設定に応じて、ユーザー名とパスワードによる認証も利用できます。プロトコル自体はTLSと同等の通信暗号化を提供しません。ユーザー名とパスワードによる認証は利用権限を確認するものであり、自動的に通信を保護するものではありません。現在のネットワーク、外部の保護レイヤー、サーバーの構成を踏まえて適切か判断してください。設定項目が少ないからといって、セキュリティ上の境界が単純になるとは限りません。

SOCKS5にはUDPリレーの仕組みが定義されていますが、実際に利用できるかはクライアントの対応状況、サーバーで有効かどうか、ネットワーク経路によって異なります。SOCKS5経由でWebページを開けても、成功が確認できるのは主に一部のTCPリクエストです。ゲーム、音声通話、その他のUDP通信も使えるとは限りません。サーバーがTCP転送のみを提供する場合は、それをサービスの条件として扱い、クライアントのUDP設定を何度も切り替えないでください。サーバーにない機能をクライアントのスイッチで追加することはできません。

種類	一般的な保護範囲	優先して確認する項目
Trojan	一般的な構成ではTLSでプロキシ通信を保護	パスワード、Server Name、証明書、通信方式の組み合わせ
HTTP	通常の接続口にはTLS保護がない	接続口の種類、認証、CONNECTの許可範囲
SOCKS5	プロキシネゴシエーション自体は暗号化を提供しない	認証、接続先の名前解決方法、UDP対応

名前解決がどこで行われるかを個別に確認する

HTTP CONNECTとSOCKS5では、接続先をドメイン名で指定できますが、最終的にどこで名前解決するかは、クライアントの処理、ルールの要件、サーバーの実装によって異なります。クライアントがIPルールとの照合のためにローカルで名前解決している場合、その後でドメイン名をプロキシに渡しても、「すべての名前解決がリモートで行われる」とは言えません。サーバーアドレスの名前解決、接続先の名前解決、ルール照合に伴う名前解決を区別し、「リモートDNS」という1つのラベルで処理全体をまとめないでください。

iOSでこれらのプロトコルの使用感が異なる主な要因は、追加のTLSハンドシェイクの有無、接続の再利用、サーバーとの距離、実際の負荷などです。HTTPやSOCKS5は設定項目が少なくても、必ず省電力とは限りません。TrojanがTLSを使用していても、必ず大きく電力を消費するわけではありません。接続が安定している場合、プロトコルの違いより使い方の方が大きく影響することがあります。テストではサーバーの身元が正しく確認されているかも確認してください。必要な保護を犠牲にしてハンドシェイクを1回減らすことは避けましょう。

選択は既存サービスの実際の種類に合わせてください。サービス提供元がTrojanを指定しているなら、対応する認証とTLSの条件を保ちます。管理されたネットワーク内でHTTPまたはSOCKS5を提供しているなら、その接続口の信頼範囲と用途を先に確認してください。3種類を同じサーバー項目で切り替えられるメニューのように扱わないでください。基本操作はよくある質問で確認できます。証明書や認証に関する具体的なエラーを調べる場合は、認証情報を取り除いたエラー内容を用意してください。

05 / WIREGUARD

WireGuard：鍵による認証とIPトンネル

アプリケーションプロキシとは異なる仕組み

WireGuardは暗号化されたIPトンネルとして設計され、公開鍵方式で相手を識別し、主にUDPで通信します。汎用アプリケーションプロキシのように特定の接続をネゴシエーションするのではなく、トンネル内のIPパケットを扱います。そのため、アドレス、ルーティング範囲、対向側の鍵が重要な設定項目です。プロキシの「パスワード、サーバー、ポート」という考え方をそのまま当てはめると、トンネル内のローカルアドレスや、対向側を経由する宛先の範囲を見落とすことがあります。

ShadowrocketでWireGuardの項目を使うときは、クライアント側のトラフィック選択と、WireGuardの対向側に設定されたルーティング制約を区別してください。前者はどの通信をこの項目に振り分けるかを決め、後者はトンネルに渡されたパケットが対向側で許可される範囲に含まれるかを決めます。両方が正しく設定されて初めて、通信が完了する可能性があります。ハンドシェイクに成功したWireGuard項目を選んでも、任意の宛先に必ず接続できるとは限りません。既存のルールが自動的に置き換わるわけでもありません。

Private Key、Public Key、事前共有鍵

Private Keyはローカルの秘密鍵、Public Keyは対向側を識別する鍵です。クライアントに入力する対向側のPublic Keyはサーバーから取得してください。ローカルで生成したPublic Keyを代わりに使うことはできません。サーバー側にもクライアントの公開鍵が登録されている必要があります。設定に事前共有鍵が含まれている場合、それは双方が追加で合意する情報であり、Private Keyと混同しないでください。鍵の見た目が似ていても役割は異なります。文字列の長さではなく、元の項目名を基準にしてコピーしてください。

Private Keyを含む設定全体を、スクリーンショット、ログ、公開の場での質問に貼り付けないでください。トラブルシューティングでは「同じ設定から鍵をインポートしたか」「対向側にクライアントの公開鍵が登録されているか」を説明すれば十分です。実際の値を示す必要はありません。ローカルの鍵を再生成するとクライアントの識別情報が変わります。サーバー側に新しい鍵が登録されなければ、自動的にアクセスできるようにはなりません。問題が起きたら、鍵の対応関係を先に確認し、何度も鍵を再生成することを一般的な修復方法にしないでください。

Endpoint、Address、Allowed IPs

Endpointは接続可能な対向側の外部アドレスとポート、Addressはトンネル内でローカルに割り当てるアドレスです。両者は置き換えられません。Allowed IPsはその対向側を経由するアドレス範囲を表し、一般的な実装では対向側の選択や受信アドレスの制約にも使われます。範囲が狭すぎると一部の内部リソースしか利用できないことがあります。範囲を広げても、サーバーがすべての宛先への転送に対応するとは限りません。「全体を接続する」という直感で一律に範囲を広げず、提供された設定を保ってください。

ハンドシェイクは成功しても通信できない場合は、トンネルアドレスの重複、接続先が許可範囲に含まれているか、サーバーが転送と戻り経路に対応しているかを確認してください。内部IPにはアクセスできるのにドメイン名では失敗する場合は、次にDNSを確認します。特定のネットワーク範囲だけ失敗する場合は、ルーティングまたは接続先側の権限が原因かもしれません。クライアントに接続済みと表示されても、わかるのは特定のレイヤーの状態だけです。アドレスやサーバー出口の確認を省略しないでください。スイッチがオンかどうかだけを見るより、各レイヤーを分けて確認する方が効果的です。

ハンドシェイクの成功と通信の成功は分けて記録してください。前者は、ある時点で対向側の認証とUDP経路が成立したことを示します。後者には、トンネルアドレス、ルーティング、DNS、転送、接続先の応答も正常である必要があります。トラブルシューティングでは、どのレイヤーで失敗したかを明記してください。

MTU、キープアライブ、モバイルネットワークの切り替え

MTUはトンネル内で扱うパケットのサイズ上限を決めます。カプセル化によってデータが追加されるため、実際の経路でそのサイズを通過させられず、経路上の情報が適切に伝わらない場合、小さなリクエストは成功しても大きなページやデータ転送が止まることがあります。任意の小さい値をすべての環境に最適な値として設定しないでください。サーバーの推奨値や実際の症状に基づいて変更し、元の値も記録しておきましょう。MTUを下げて一部の問題が改善しても、その原因を引き続き確認してください。すべての接続に同じ値を使うべきとは限りません。

Persistent Keepaliveなどのキープアライブは、一部のNATマッピングを維持するためのものであり、帯域幅を増やす設定ではありません。モバイルネットワークではアイドル状態のマッピングが早く破棄されることがありますが、キープアライブの頻度を上げると送信回数や無線モジュールの動作も増えます。必要性は、サーバーへの接続方法、アイドル後の復旧状況、元の設定を踏まえて判断してください。アイドル時に切断される問題がなければ、「常時オンライン」のために間隔を短くする必要はありません。省電力設定の確認に、ハンドシェイクを絶えずテストすることも避けてください。

WireGuardはアドレスの変更に対応しやすく、一部のモバイル利用に適していますが、Wi-Fiとモバイル回線の切り替えで中断が一切起きないとは限りません。切り替え後にUDP経路、システムのネットワーク拡張機能の状態、接続先のセッションが変わることもあります。テストでは、新しいリクエストが復旧するか、既存の通信を再確立する必要があるかをそれぞれ確認してください。古い通話だけが切れて新しいWebページは開ける場合は、セッション継続性の問題として記録し、トンネル全体が使えないと一括りにしないでください。

06 / HYSTERIA2

Hysteria2：UDP経路と輻輳制御

QUICベースの通信方式を使う理由

Hysteria2はQUICベースの通信方式を採用しています。QUICは一般にUDP上で動作し、信頼性のあるストリーム、暗号化ハンドシェイク、接続管理などの仕組みを統合しています。設計の目的の1つは、品質の異なるネットワークで通信を制御することであり、TCPのデータをUDPに置き換えれば自動的に高速化するというものではありません。UDPが提供するのは通信の土台です。信頼性、輻輳制御、アプリケーション通信への対応は上位レイヤーが担うため、「UDPを使うから再送が不要」「パケットロスの影響を受けない」と考えるのは誤りです。

単一のTCP接続を使った多重化と比べると、QUICはトランスポート層で複数のストリームをそれぞれ独立して扱いやすく、1つのストリームでのパケットロスが他のストリームの配信を直接妨げる状況を減らせます。ただし、共有する経路の帯域幅、輻輳状況、端末のリソースに変わりはありません。1つの接続で大量に通信すれば、他の用途にも影響することがあります。実際の効果はネットワーク、サーバー設定、用途によって異なり、すべてのWebページ、ダウンロード、リアルタイム通信で同じ改善が得られるわけではありません。

Server、認証、TLSでのサーバー確認

Hysteria2のサーバーアドレス、ポート、認証情報、TLS条件は、同じ設定から取得してください。認証文字列は利用権限を証明し、TLSによるサーバー認証は接続先を確認するもので、互いに代替できません。ServerにIP、Server Nameにドメイン名を指定する場合は、元の設定どおりに役割を分けてください。証明書エラーが発生したら、ドメイン名、有効期限、端末時刻を確認します。スループットを調べるために検証を長期間無効にすると、同じセキュリティ条件での比較ではなくなります。

一部の構成では追加の通信パラメーターや難読化関連の項目が必要です。これらは双方で一致させてください。省略と空文字列が同じ扱いとは限りません。名前が似た別世代のプロトコルを、設定項目が似ているというだけで流用しないでください。インポート時には、サーバーが実際に使うプロトコルとして認識されているか確認します。手動入力後にまったく応答がない場合は、パスワードだけでなく、現在のネットワークから必要なUDPポートに到達できるかも確認してください。

帯域幅の設定は速度の保証ではない

設定によっては、特定の輻輳制御モードでの推定や制限に使う上り・下りの帯域幅パラメーターがあります。大きな値を設定するほど良いわけではなく、サーバーが利用者に固定速度を割り当てる値でもありません。実際の回線容量を大きく超える値を指定すると、キューイング、パケットロス、通信の競合が発生することがあります。短時間のダウンロード速度が上がっても、操作時の応答性が悪くなる場合があります。現在のモードで各パラメーターがどう使われるかを確認し、他人の高速回線の設定値をコピーするのではなく、サーバーの推奨を優先してください。

単位も正しく確認してください。帯域幅と1秒あたりに転送するバイト数は同じではありません。設定画面や構成ファイルで指定された単位を、一般的なダウンロードアプリの表示から推測しないでください。上りの輻輳も下りの使用感に影響します。リクエスト、確認応答、制御情報の送信にも帯域が必要だからです。ダウンロードの開始直後は速いものの、その後に遅延が大きくなる場合は、サーバー負荷に加えて、ローカルの経路で継続的なキューイングが起きていないかも調べてください。下りのパラメーターをさらに上げるだけでは解決しません。

UDPに到達できない場合は、まず到達性を確認してください。現在のネットワークで必要なUDP通信が許可されていなければ、認証、DNS、帯域幅の推定を変更しても基盤経路は改善しません。利用が許可された別のネットワークで比較し、サーバーの待ち受けとファイアウォールの設定を確認してください。

iOSで速度とバッテリー消費のバランスを取る

パケットロスや遅延の変動がある経路では、適切な輻輳制御によって継続的な通信が改善することがあります。一方、低遅延で品質の良いネットワークでは、追加の効果がほとんどない場合もあります。通信経路を積極的に利用する方式は、データ処理や無線モジュールの動作を増やすことがあるため、スループットが高いほど省電力とは限りません。バッテリーを重視する場合は、一時的なピーク速度ではなく、同じ作業を完了するまでの時間、バックグラウンド通信、端末温度を比較してください。

音声通話、操作、リモートアクセスが目的なら、ダウンロード速度だけでなくジッター、切断、キューイングを確認してください。並行利用の状況を評価する場合を除き、大容量ファイルの転送と操作のテストを同時に実行して互いに影響させないようにしましょう。Wi-Fiとモバイル回線を切り替えた後は、UDP経路もあらためて確認してください。あるネットワークで正常に動作しても、別のネットワークで同じパケットサイズ制限、NATの動作、アイドル接続の維持時間が適用されるとは限りません。

すべての種類を置き換えるのではなく、利用条件に合わせる

サーバーがHysteria2を明示的に提供し、現在の経路でUDPが使え、主な問題が実際に通信品質や輻輳に関係している場合は、比較対象として検討する価値があります。既存のTCP系接続が安定しているなら、切り替えは必須ではありません。ルールによって接続先が誤ったポリシーに振り分けられている場合や、DNSから到達できないアドレスが返されている場合、Hysteria2に切り替えても自動では修正されません。まず問題がトランスポート層にあることを確かめてから、プロトコル変更の効果を評価してください。

テスト結果を保存するときは、ネットワーク、用途、帯域幅設定を元の値から変更したか、再接続やバックグラウンド動作が発生したかを記録してください。「速い」「遅い」というメモだけでは条件が変わったときに再現できません。既存の項目は残し、テスト用の項目には別の名前を付けます。サブスクリプションが更新されたら設定の違いを確認し、更新後の変更を同じプロトコルの性能変化と取り違えないようにしましょう。

07 / ROUTING & DNS

Global Routing、DNS、プロトコルの関係

選択したプロトコルに通信が実際に流れているか確認する

Global Routingはトラフィック全体の振り分け方法を制御する機能であり、あるプロトコルを別のプロトコルに変換するものではありません。Configは現在の設定に基づいてルールを適用します。Proxyは対象となる通信をプロキシ経路へ送ります。Directは直接接続します。画面上のモードとルールのポリシーを区別してください。Proxyは画面上のモード、PROXYはルールで使われるポリシー名です。関連はありますが、同じ項目ではありません。文字が似ているだけで、現在のリクエストが実際にどの経路を通るか判断しないでください。

プロトコルをテストする前に、対象の項目が選択されていることを確認し、該当リクエストに適用されたルールと最終ポリシーも確認してください。ConfigでWebサイトに直接接続できても、選択したプロキシ項目が利用可能だとは証明できません。Proxyで失敗しても、プロトコル設定の誤りとは限りません。サーバー側の出口や接続先の応答が原因のこともあります。Directは、接続先へローカルネットワーク経由でアクセスできるかを判断するのに役立ちます。ただし、その結果が有効なのは現在のネットワーク条件に限られ、すべての接続に当てはまるわけではありません。

モード	主な役割	テスト時の注意点
Config（設定）	現在の設定にあるルールに従って経路を選択	まず、リクエストにどのルールが適用されたか確認する
Proxy（プロキシ）	対象となる通信をプロキシ経路に送る	項目とサーバー側の出口も確認する
Direct（直接接続）	直接接続の経路を使う	プロキシプロトコルが利用できる証拠にはならない

3種類の名前解決を区別する

1つ目はプロキシサーバーアドレスの名前解決です。Serverにドメイン名を入力した場合、クライアントは接続先のサーバーを見つける必要があります。これはプロキシ接続を確立する前の条件です。2つ目は接続先ドメインの名前解決です。プロトコルや設定に応じて、ローカルで解決する場合と、ドメイン名のままリモートに渡す場合があります。3つ目はルール照合に必要な名前解決です。IPベースのルールを適用するため、先にアドレスを取得する場合があります。これらは発生するタイミングが異なり、必ずしも同じ経路を使うわけではありません。

そのため、「DNSは正常」という場合も、どの名前解決が正常なのかを明確にしてください。サーバーのドメイン名を解決できても、接続先のWebサイトを解決できるとは限りません。接続先を解決できても、そのアドレスに現在の出口から到達できるとは限りません。IPv6の接続先だけ失敗する場合は、すべてのDNS機能をすぐ無効にするのではなく、現在のネットワークと出口がIPv6に対応しているかを確認してください。IPアドレスではアクセスできるのにドメイン名では失敗する場合は、まず名前解決やサーバー認証の項目を確認します。ただし、HTTPS接続先ではドメイン名によるサーバー認証が必要なことがあります。IPアドレスを直接入力するテストが、実際の用途と完全に同等とは限りません。

ルールの順序によって確認結果が変わる

ルールは通常、上から順に評価され、最初に一致したルールがポリシーを決定します。DOMAIN-SUFFIXはドメインのサフィックスに一致し、GEOIPはアドレスの地域情報データベースに基づいて判定します。FINALは他のルールに一致しないリクエストのフォールバックとして使われます。以下は順序を説明する部分的な例であり、現在の設定をそのまま置き換えるためのものではありません。PROXYを使うには、実際の設定で有効な意味を持たせる必要があります。例のドメイン名は説明用で、アクセスすべきサービスを示すものではありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、まずドメインのサフィックス、次にアドレスの地域情報を確認し、最後にフォールバックを適用します。FINALを先に置くと、それ以降のルールが意図どおりに評価されなくなります。プロキシ経由にする対象が先にDIRECTに一致すれば、プロトコルのテストが実際にはプロキシを迂回します。DOMAINとDOMAIN-SUFFIXも自由に置き換えられるものではありません。前者はドメインの完全一致、後者はサフィックスの範囲を表します。より詳しい記述方法と順序については、カスタムルールの優先順位とFINALをご覧ください。

設定ファイルとサブスクリプション項目は別のもの

サブスクリプションには主にサーバー項目と関連設定が含まれます。設定ファイルはルール、DNS、その他の処理に影響することがあります。新しいサーバー項目をインポートしても、古い設定ファイルを使い続けていれば、プロトコル名が変わっただけでルールが自動的に書き換わることはありません。反対に、サーバーを変更しなくても、設定ファイルを差し替えると接続経路が変わる場合があります。問題を記録する前に、サーバー項目と設定ファイルをそれぞれ更新したか確認してください。同じ日に起きたルール変更を、誤ってプロトコルのせいにしないためです。

.confを編集した後は、保存されていること、目的の設定ファイルが選択されていること、画面の指示に従って関連する状態を再適用したことを確認してください。テスト中は元の設定ファイルを残し、通常利用と試験的な変更を混在させないようにしましょう。構成についてはGeneral、Rule、Host、URL Rewriteの各セクション解説をご覧ください。サブスクリプションのインポート場所はSubscribeなどのインポート方法で確認できます。

On Demandとプロトコルの接続状態を分けて確認する

On Demandはシステムの条件に応じて接続を開始するタイミングを決める機能であり、認証、証明書、サーバーへの到達性を修復するものではありません。ネットワーク切り替え時に接続動作が繰り返される場合は、起動条件とプロトコルの再接続結果を分けて確認してください。起動条件を一時的に無効にして手動でテストすると、「システムが接続を繰り返し開始していること」と「個々の接続自体が失敗していること」を切り分けやすくなります。テスト後は元の設定に戻し、必要な接続条件を忘れずに再設定してください。

最終的な記録には、現在のGlobal Routing、設定名、選択した項目、接続先、適用されたポリシー、DNSまたはUDPが関係したかを含めてください。これらの情報があれば、同じ項目を2台の端末で使っても結果が異なる理由を説明できます。クライアントのスイッチがオンになっていることが示すのは、ネットワーク拡張機能が特定の状態で動作しているということだけです。リクエストの経路、名前解決の場所、使用するプロトコルは、現在の設定と個々の接続を踏まえて判断してください。

08 / SELECTION & DIAGNOSIS

用途に応じた選び方と段階的なトラブルシューティング

選び方の順序：性能の好みより互換条件を優先

まず、速そうな名前を選ぶのではなく、利用中のサービスが実際に提供するプロトコルと完全な設定情報を整理します。次に、現在のネットワークで必要な通信方式が使えるか確認します。たとえばUDP経路が利用可能かを確認してください。その後で用途に応じて比較します。短時間のWeb閲覧では初回応答、継続的なダウンロードでは安定したスループット、通話や操作ではジッターと切断、内部リソースへのアクセスではアドレスとルーティング範囲を確認します。最初の2段階を満たしてからでなければ、3段階目の比較に意味はありません。

サービス提供元が1種類のプロトコルだけを提供している場合、クライアント側で別の種類に変更することはできません。複数の項目があっても、それぞれサーバーや負荷が異なる可能性があり、テスト結果の違いをすべてプロトコルのせいにはできません。適切に比較するには、サーバーの場所とネットワーク条件をできるだけ近づけ、一致させられなかった条件も記録します。多くの場合、利用中の完全で安定した設定を用途に合わせて使う方が、慣れていない通信方式を追加するより管理しやすいでしょう。

用途	優先して確認すること	確認方法の例
日常的なWeb閲覧と文書の利用	初回応答、名前解決、再接続	新規接続と確立済みの接続を分けてテストする
大容量ファイルの継続的な転送	スループット、キューイング、発熱	ファイルとネットワークを固定し、他のタスクを同時に実行しない
音声通話と操作	UDP、ジッター、セッションの復旧	経路全体を確認し、ネットワーク切り替え前後を観察する
内部IPアドレスのリソース	アドレス範囲、戻り経路、DNS	トンネルのハンドシェイク、IPアドレス、ドメイン名でのアクセスを個別に確認する

接続できない状態からアプリケーション層まで、段階を飛ばさず確認する

接続をまったく確立できない場合は、まずServerとPort、現在のネットワーク、サーバーの待ち受け状態を確認します。ドメイン名の名前解決に失敗しているなら接続の入口に問題があります。基盤接続がタイムアウトする場合は、経路や待ち受け状態を優先して調べてください。すぐにUUIDを再入力しても解決しないことがほとんどです。ネットワーク接続後に明確な認証エラーが出た場合は、パスワード、UUID、鍵の対応関係、時刻を確認します。TLSエラーならServer Name、証明書、端末時刻に絞って確認し、DNSやルーティングを同時に変更して問題を隠さないでください。

認証に成功しても通信できない場合は、次の段階として通信パラメーター、接続先アドレス、サーバー側の転送を確認します。WebSocketのPath、gRPCのサービス名、特殊なストリームパラメーター、WireGuardのルーティング範囲が、基盤接続の確立後に通信を妨げていることがあります。一部の接続先だけ失敗する場合は、ルールの適用、接続先の名前解決、サーバー側の出口を確認してください。UDP通信だけ失敗する場合は、Webページのテストで「すべて正常」と判断するのではなく、クライアント、サーバー、ネットワークを順にたどってUDPを確認します。

一時的に使えた後で切断する場合は、状態の変化を確認する

しばらくアイドル状態にした後で接続が失敗する場合は、NATマッピング、キープアライブ、サーバーのアイドル時ポリシーが関係することがあります。Wi-Fiからモバイル回線に切り替えた後で失敗する場合は、古い接続が再確立されるか、UDP経路が変わるか、On Demandが作動するかを確認してください。大きなリクエストだけ止まり、小さなリクエストは正常なら、MTUや経路情報のフィードバックが関係する可能性があります。高負荷時だけ失敗する場合は、キューイング、帯域幅の推定、端末リソース、サーバー負荷を調べましょう。単に「いつも切断される」と記録するより、各症状を具体的に残す方が原因を特定しやすくなります。

キープアライブ、MTU、接続再利用、帯域幅の設定を一度に複数変更しないでください。まず元の値を記録し、現在の症状に最も関係する項目を1つだけ変更して、同じ作業を繰り返します。効果がなければ元に戻し、試験的な値を追加し続けないでください。サブスクリプション管理の項目は、自動更新で設定が上書きされることにも注意してください。用途を明記したテスト項目を別に作成すれば、次の更新後も手動で変更した値と提供元の設定を区別できます。

有効なトラブルシューティング記録に含める情報：ネットワークの種類、通信の用途、プロトコルと通信方式の組み合わせ、Global Routing、エラーが発生した段階、UDP通信だけに影響するか、ネットワーク切り替え後の変化、最後に変更した内容。パスワード、Private Key、サブスクリプションURL全体、認証文字列は記録から削除してください。

バッテリー消費の異常は、名前から推測せず同じ作業で比較する

バッテリー消費を抑えたい場合は、プロトコルを比較する前に、バックグラウンドでの継続動作、接続失敗の再試行、キープアライブの頻度、無線信号を確認してください。テスト中は画面、作業時間、ネットワークをできるだけ同じ条件にし、一方だけ充電中、もう一方だけ低バッテリー状態といった差を避けます。システムのバッテリー統計は手掛かりになりますが、短時間の残量変化は温度や推定の影響を受けやすいため、複数回のテスト結果と合わせて判断してください。高速ダウンロードで作業を早く終える方が、低速で再試行を続けるより総稼働時間を抑えられる場合もあります。

待機時のテストで、探査リクエストを継続的に送信する必要はありません。観察対象の状態そのものが変わってしまいます。クライアントに関連するバックグラウンド動作が増えている場合は、他のアプリが接続経由で継続的に通信していないか、直接アクセスできる頻繁な通信がルールによって遠回りの経路に送られていないかを確認します。プロトコルの変更より、通信経路の修正が有効な場合があります。ただし、ルールは実際の用途に合わせて調整し、バッテリー統計を改善するためだけに必要な接続を減らさないでください。

テスト後は理由を説明できる設定を残す

最終的な選択では、次の3点を説明できることが大切です。サーバーと互換性がある理由、現在の用途に適している理由、問題が起きた際の復元方法です。検証済みの設定を残し、必要な項目の入手元と適用するネットワークを記録して、無効と確認された試験変更は削除してください。検証を一時的に無効にした設定、範囲を一時的に広げた設定、極端な帯域幅の値を日常利用の設定として残さないでください。元の設定から変更する必要がある項目については、理由を記録し、適用範囲をサービス提供元に確認してください。

基本操作に戻る場合はShadowrocket クイックスタートをご覧ください。入手方法の確認は全プラットフォーム版のダウンロードページをご利用ください。Mac版はAppleシリコンとIntelの2種類です。その他のデスクトップ版とAndroid版のインストール時に表示される案内も、ダウンロードページにまとめています。本記事の目的は特定のプロトコルを常に優先するよう勧めることではありません。選択の条件を確認でき、問題が起きたときに次の手順を判断できるようにすることです。