Shadowrocketプロトコル技術ガイド

01 / 選び方の基本

プロトコル・転送方式・ルーティングを区別する

プロトコルの種類は、まずサーバーとの互換性を決め、そのうえで性能を比較するための条件になります。サーバーがTrojanを使用しているなら、クライアントもTrojanを選びます。同じポートでTypeをHysteria2に変更しても、別の種類の接続を受け付けるようにはなりません。サブスクリプションを読み込むと、通常は種類、アドレス、ポート、認証情報が設定されています。手動で編集する場合は、サーバー側の説明に従ってください。利用できる情報が一組だけなら、新しそうな名前を探すのではなく、まずその情報を正確に設定することが重要です。

接続は少なくとも4つの階層で成り立つ

第1層は接続先への到達性です。ドメイン名の解決、接続先のポート、現在のネットワークで該当する通信が許可されているかを確認します。第2層は転送方式で、TCP、UDPベースのQUIC、TCP上で動作するWebSocketなどがあります。第3層はプロトコルの認証と暗号化です。パスワード、UUID、TLS証明書、鍵などが該当します。第4層はアプリの接続先とルーティングポリシーです。前の層で失敗すると、通常は後の層まで処理が進みません。そのため、ルールが正しく適用されていても、サーバーとのハンドシェイク成功を意味するわけではありません。

各階層は組み合わせて使えますが、自由に置き換えられるわけではありません。VMessやVLESSではTLSやWebSocketを組み合わせる構成があり、Trojanでは一般にTLSを使用し、Hysteria2はQUICを基盤とします。読み込んだ情報にType、TLS、Host、Pathが含まれていても、4種類のプロトコルから選ぶという意味ではありません。同じ接続に必要な別々の条件であり、すべてを満たす必要があります。項目名が同じでも意味が異なる場合があるため、使用するプロトコルに沿って確認してください。

速度・バッテリー消費・プライバシーは別々に考える

速度には、初回接続までの時間、小さなリクエストへの応答、連続通信時のスループットなどがあります。大きなファイルのダウンロードは速くても、ハンドシェイクや名前解決、迂回経路の影響でウェブページの初回表示が遅くなることがあります。バッテリー消費は、無線の電波状況、再送、バックグラウンド接続の維持、端末の温度にも左右されます。1回のConnectivity Testの数値から一日の使用感を判断したり、プロトコル名から消費電力の順位を決めたりすることはできません。比較する際は、サーバーの地域、ネットワーク、テスト内容をできるだけ揃えてください。

暗号化される範囲も分けて考える必要があります。クライアントからプロキシサーバーまでが保護されていても、プロキシサーバーからすべての接続先サイトまで自動的に暗号化されるわけではありません。ウェブサイト自体のHTTPSも重要です。サーバーから確認できる接続情報は、プロトコル、接続先の通信、DNSの経路によって異なります。このページでは、正しい設定と説明可能な性能を扱います。どのような状況にも通用するプライバシー保護として、特定のプロトコルを紹介するものではありません。

Shadowrocketで元に戻せる設定を残す

変更前に、項目が属するサブスクリプション、現在のType、重要な設定項目を記録し、Configをバックアップしてください。サブスクリプションの項目は更新時に再生成される場合があります。直接編集した場合は、変更が上書きされないか確認してください。テスト用の複製は、普段使う項目と区別します。ログやスクリーンショットを共有する際は、パスワード、UUID、秘密鍵、サブスクリプションのURLを隠してください。トラブル対処に必要な情報は、項目名、エラーが発生した段階、加工して伏せたホスト情報に絞ります。まず動作確認済みの設定を基準として残しておくと、その後の比較がしやすくなります。

02 / パスワードと暗号化方式

Shadowsocks：シンプルな設定手順

Shadowsocksは、クライアントとサーバーの間で保護された転送を行う軽量な暗号化プロキシとして設計されています。完全な仮想ネットワーク管理を担うものではありません。通常、アドレス、ポート、パスワード、暗号化方式を設定し、比較的シンプルに構成できます。ここでいう「軽量」は構造を指し、どのネットワークでも速いという意味でも、すべてのShadowsocks構成が互換性を持つという意味でもありません。暗号化方式、拡張機能、UDPへの対応が双方で一致している必要があります。

MethodとPasswordをセットで確認

Methodはデータの暗号化と認証の方法を定める項目で、好みに応じて切り替える性能モードではありません。サーバーが特定のAEAD方式を使っているなら、クライアントでも同じ方式とパスワードを設定します。AEADは暗号化と完全性検証を同時に行います。データが改変されていたり、鍵が一致しなかったりすると、接続に失敗しても「パスワードが違います」と明確に表示されない場合があります。ハンドシェイクの中断を通信速度のせいだと決めつけると、基本的な項目の確認を見落とします。

暗号化方式によって、必要な鍵の形式が異なる場合があります。一般的なパスワードから鍵を導出する方式もあれば、特定の長さと形式の鍵が必要な方式もあります。Passwordをどれも自由に置き換えられる短い文字列と考えないでください。コピー時に改行、全角記号、先頭や末尾の空白が混入しないようにします。読み込み用リンクにエンコードされた情報が含まれている場合は、クライアントに解析させ、目で見た文字列をもとに組み立て直さないでください。サブスクリプションを正常に読み込めても、サーバー側の設定が変更されていないか確認が必要です。

TCPが使えてもUDPが使えるとは限らない

ShadowsocksのTCP転送とUDP転送では、データの経路が異なります。ウェブページを開ける場合でも、それは該当するTCPリクエストが完了したことを示すだけです。音声通話、ゲーム、一部のDNSリクエストは、UDP転送の条件が整っていないと失敗することがあります。ノードがUDPに対応しているか、クライアント側の関連設定、サーバーの待ち受け、ネットワークでの通信許可をそれぞれ確認してください。利用中のタスクでUDPを使っていないなら、そのテスト結果だけではUDPの対応状況を判断できません。

「アプリがUDPを使うこと」と「プロトコルがUDPでサーバーに接続すること」も区別してください。プロキシプロトコルによっては、アプリのデータを別の転送方式に載せることがあり、両者は必ずしも一致しません。Shadowsocksの問題を調べるときは、ウェブ閲覧、UDPを使うアプリ、すべての通信のどれが失敗するのかを具体的に記録してください。「ノードが使えない」だけでは異なる問題が混在し、その後の切り分けが難しくなります。

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

設定項目が少なければ、手入力で確認する項目も通常は少なくなります。ただし、モバイル端末の使用感はサーバーの負荷や無線環境にも左右されます。端末に該当アルゴリズム向けのハードウェア機能があれば、暗号化処理の負荷を抑えられることがあります。一方、日常のバッテリー消費は、継続的な通信、電波の弱さ、再送の影響を受けることが多くあります。CPUの暗号処理だけでなく、同じ場所でのモバイル回線とWi-Fiの電波状況も考慮してください。

サーバー側のShadowsocks設定が明確で、一般的なTCPアプリを安定して使うことが目的なら、まずその設定を基準にできます。長時間の待機後に最初のリクエストが失敗する場合は、接続の切断、DNSの変更、サーバーの状態を分けて確認してください。すぐにMethodを変更する必要はありません。追加機能が必要な構成では、現在のクライアントに対応する項目があるか確認します。項目が見つからない場合は、ご利用中のサービス提供元に確認してください。他のプロトコルのHostやPathを流用しないでください。

03 / 認証と転送方式を分けて考える

VMess / VLESS：似ていても相互に置き換えられない

VMessは、ユーザー認証、プロキシリクエスト、データ保護を一連のプロトコル機構として構成し、複数の転送方式と組み合わせられます。VLESSはよりシンプルなプロトコル層を採用し、接続の保護を外部のセキュリティ層や構成に委ねます。どちらもユーザーの識別にUUIDを使うことが多いため、Typeだけ変更すれば相互に切り替えられると思われがちです。しかし、サーバーの待ち受けタイプと転送方式が一致している必要があります。UUIDが同じでもプロトコルの不一致は解消されません。

UUIDはサーバーアドレスでも転送設定でもない

UUIDはユーザーを識別する認証情報です。長いからといって省略や変更をせず、そのままコピーしてください。AddressとPortは接続先を指定し、UUIDは使用する認証情報を指定します。TLSやWebSocketなどの設定は、接続をどのように転送するかを定めます。トラブル対処では項目ごとに分けて記録すると、UUIDを何度も貼り直す一方で、実際に接続しているポートを確認し忘れるといった事態を防げます。

VMessの認証機構は時刻に関係するため、端末の時刻が大きくずれていると接続に失敗することがあります。認証関連の詳細設定をむやみに変更せず、まずシステムの時刻を自動設定にし、タイムゾーンを確認してください。サブスクリプションに追加項目がある場合は、サーバーの現在の設定に従って保持します。過去のチュートリアルから初期値をコピーすると、読み込みはできても接続できないことがあります。VLESSも「認証なし」の方式ではありません。認証の構成が異なるだけで、身元の確認は必要です。

WebSocketのHostとPathが重要な理由

サーバーがWebSocketでリクエストを受け付ける場合、Pathは入口のパス照合に使われることがあり、HostはHTTPのホストルーティングに使われる場合があります。Pathの大文字・小文字、先頭のスラッシュ、パスの内容をサーバー側の設定と一致させてください。Hostに任意のウェブサイトのドメインを入力しても、速度が上がるわけではありません。サーバーがWebSocketを使っていない場合、設定を有効にすると正常な接続が互換性のないリクエストに変わることがあります。

TLSのServer Nameは、通常、サーバー名表示と証明書名の検証に使われます。WebSocketのHostと同じものだとは限りません。多くの構成で両者は同じですが、役割を担う階層は異なります。AddressにIPアドレスを設定し、Server Nameには証明書に対応するドメイン名を設定する場合もあれば、すべて同じドメイン名を使う場合もあります。サーバー側から明示された組み合わせに従い、3か所の内容が重複して見えるからといって項目を削除しないでください。

速度とバッテリー消費は組み合わせごとに評価する

「VMessの速度」は一定の値ではありません。同じプロトコルでも、直接TCPで接続するか、WebSocketや中継を追加するかによって、ハンドシェイクの回数や通信経路が変わります。接続確立後のダウンロードは正常なのに、初回アクセスが遅い場合は、暗号化処理がスループットを低下させているとすぐ判断せず、DNS、TLS、接続入口を確認してください。転送の追加処理でデータ量や処理負荷が増える場合はありますが、実際のネットワークで常に最大のボトルネックになるとは限りません。

VLESSのプロトコル層がシンプルでも、バッテリー消費が少ないとは限りません。サーバーまでの距離が長かったり、無線ネットワークでの再送が多かったりすると、プロトコル処理の削減分を通信経路の負荷が上回ることがあります。比較する際は、サーバーの条件とアプリのテスト内容をできるだけ揃え、初回リクエスト、連続アクセス、バックグラウンドからの復帰を別々に記録してください。接続前後に1回ずつ測定しても、一日の使用状況は判断できません。

読み込み後に優先して確認する項目

Homeで対象項目の編集画面を開き、Type、Address、Port、UUIDの順に確認します。次に転送方式、TLS、Host、Pathと、サーバー側で指定されたその他の項目を確認してください。設定を1つ変更するたびに再接続し、以前のセッションが結果に影響しないようにします。同じサブスクリプションの複数の項目で認証エラーが発生する場合は、サブスクリプションが更新されているか、端末の時刻が正しいかを先に確認します。特定の接続先だけ失敗する場合は、その接続先に固有のPathや証明書設定を優先して確認してください。

04 / 証明書とユーザー認証

Trojan：TLSの設定を漏れなく確認する

Trojanでは一般に、TLS接続を通じてプロキシリクエストを転送し、パスワードでユーザーを認証します。広く使われているTLSの仕組みを利用して、クライアントからサーバーまでの保護された接続を確立するため、証明書、名前、時刻も接続条件に含まれます。設定項目がアドレス、ポート、パスワードだけに見えても、TLSを省略できるわけではありません。「パスワードは正しいのに接続できない」場合、サーバーがパスワードを確認する前のTLS処理で失敗していることもあります。

Address、Server Name、証明書を理解する

Addressはサーバーを特定し、Server Nameは通常、TLSのサーバー名表示や証明書の検証に関わります。サーバーは受け取った名前に応じて証明書や接続先を選ぶ場合があります。クライアントは、受信した証明書が信頼できるか、有効期限内か、接続先の名前に対応しているかを確認します。AddressをIPアドレスに変更してServer Nameを正しく設定しないと、正しいサーバーに接続しているのに検証に失敗することがあります。

証明書のドメイン名が一致しない、証明書チェーンが不完全、端末の時刻がずれているといった問題は、TLSハンドシェイクの失敗につながります。まずエラーがどの段階で発生したか確認してください。TLSが完了していないなら、Passwordを繰り返し変更する必要はありません。TLSが成功してから認証が拒否された場合は、パスワード、アカウントの状態、サーバーの待ち受けタイプを確認します。エラーの詳細が不十分な場合は、正常に動作するネットワークで同じ項目を再テストし、ネットワーク経路の違いか固定設定の誤りかを判断してください。

検証の無効化を通常の修正方法にしない

証明書検証はサーバーの身元を確認するためのものです。検証を無効にすると一時的にエラーが消える場合がありますが、確認条件がなくなるだけで、設定が正しく修復されたとは限りません。構成上、特定の信頼情報が必要な場合はサーバー側の案内に従って設定してください。接続ボタンを成功表示にするために、一般利用者が名前や証明書のエラーを恒久的に無視するべきではありません。エラーの内容を記録し、サーバーの証明書設定を確認するほうが、検証を回避するよりトラブルの原因を特定しやすくなります。

接続の再利用とネットワーク切り替えの影響

TLSハンドシェイクには処理時間がかかりますが、確立済みのセッションと初回接続は分けて考える必要があります。ブラウザーやアプリは一部の接続を再利用し、システムもDNSの名前解決結果をキャッシュすることがあります。そのため、2回目のページ表示は初回より速くなる場合があります。これは特定のプロトコルが特別に高速化していることを示すものではありません。比較する場合は、新しい接続でのアクセスと連続アクセスを分けて記録し、確立直後の接続と、すでに準備が整った接続を比べないようにしてください。

iPhoneでWi-Fiからモバイル通信に切り替えると、送信元アドレスや既存の接続状態が変わります。TCPベースのセッションでは、接続を再確立する必要があり、ページ表示が一時的に止まることがあります。On Demandは接続を開始するタイミングに関わる設定であり、ネットワークが変わっても既存のTCPセッションをすべてそのまま維持するものではありません。復帰できない状態が続く場合は、システムのネットワーク権限、現在のノード、アプリが再接続を正しく試みているかを確認してください。

利用条件と実際の選択基準

利用中の構成でTLS名、有効な証明書、パスワードが明確に指定されている場合、Trojanは設定を確認しやすく、一般的なウェブ閲覧やアプリ通信の候補になります。TLSを使っているから他の方式より必ず速いわけではなく、ハンドシェイクがあるから必ずバッテリー消費が大きいわけでもありません。電波が弱い状況での再接続、サーバーの混雑、バックグラウンドでの接続維持は、1回のハンドシェイクより実際の消費に大きく影響することがあります。

一部のアプリだけ失敗する場合は、すぐにプロトコルを変更せず、アプリごとに必要な通信を切り分けてください。UDPが必要なアプリ、DNSの結果が異なるアプリ、RuleによってDIRECTに送られているリクエストなどがあります。該当するリクエストが実際にTrojanの項目を経由していることを確認してから、サーバーが必要な通信に対応しているかを調べます。接続タイムアウトの基本的な確認順序は、遅延テスト・プロトコル設定・システム時刻の確認をご覧ください。

05 / 汎用プロキシインターフェース

HTTP / SOCKS5：転送機能と暗号化の範囲

HTTPプロキシはアプリケーション層での転送を目的として生まれ、ブラウザーや組織のネットワークで広く使われています。SOCKS5は、より汎用的なプロキシのネゴシエーションと転送の仕組みを提供します。どちらもインターフェースが明確で多くのソフトウェアで利用できますが、標準で完全な暗号化を提供するわけではありません。選択する前に、クライアントからプロキシ入口までにTLSや信頼できるネットワークによる保護があるか、認証方式は何か、UDP転送が必要かを確認してください。ユーザー名とパスワードがあるだけでは、これらの疑問には答えられません。

HTTP CONNECTはプロキシ経路の暗号化を意味しない

HTTPプロキシは通常のHTTPリクエストを受け付けるほか、CONNECTを使って指定した接続先へのトンネルを確立できます。HTTPSサイトへの接続では、通常、そのトンネル内でサイトとのTLS接続が確立されます。しかし、クライアントとプロキシ間のネゴシエーションが暗号化されるかどうかは別の条件です。接続方式によっては、接続先サイトがHTTPSでもプロキシの認証情報が同じように保護されるとは限りません。サイトとのTLSと、プロキシ入口への接続で使用するTLSを区別してください。

サーバーがTLSで保護されたHTTPプロキシを明示的に提供している場合は、サイトのURLがHTTPSで始まるという理由だけで関連項目を有効にするのではなく、指定されたアドレス、ポート、証明書名、認証情報を設定してください。反対に、通常のHTTPプロキシ入口でクライアント側のTLSを勝手に有効にしても、接続が自動的にTLS対応になるわけではありません。双方の設定が一致しないと、ハンドシェイク失敗や接続切断が起きることがあります。

SOCKS5の認証・DNS・UDP

SOCKS5では認証方式をネゴシエーションでき、接続先をドメイン名またはIPアドレスで指定できます。ドメイン名をローカルで解決するか、プロキシ側に解決を任せるかによって、名前解決の結果や障害箇所が変わります。実際の経路にはShadowrocketのDNS設定やルーティングの動作も影響するため、プロトコル名だけでは判断できません。リクエストにドメイン名とIPアドレスのどちらが含まれているか、ログで名前解決と転送がどの順に行われたかを確認してください。

SOCKS5の規格にはUDP ASSOCIATEが含まれていますが、すべてのサーバー、アカウント、ネットワークでUDP転送が利用できるわけではありません。制御用の接続が確立しても、その後のUDPポートに現在のネットワークから到達できるとは限りません。一般的なHTTP CONNECTは通常TCPトンネル向けで、汎用的なUDP機能として扱うべきではありません。音声通話やリアルタイム通信では、サービスが実際に提供する機能を確認してください。「プロキシ対応」という表示だけから対応範囲を推測しないでください。

モバイル端末での利用判断

組織のネットワークからHTTPまたはSOCKS5の入口が提供されている場合は、管理者の案内に従って設定してください。プロトコル名が違うという理由だけで、独自に変更する必要はありません。モバイル通信ではネットワークが頻繁に切り替わり、組織の入口が特定のネットワークからの接続だけを許可していることもあります。オフィスのWi-Fiでは使えてモバイル通信では使えない場合でも、クライアントのパスワード設定が間違っているとは限りません。入口の接続許可範囲、名前解決、認証条件を確認してから、プロトコル処理の負荷を比較してください。

これらのインターフェースではネゴシエーションが比較的シンプルな場合もありますが、実際の速度はサーバーから接続先までの通信にも左右されます。プロキシ入口が端末の近くにあっても、遠い出口まで迂回すれば応答に時間がかかることがあります。バッテリー消費についても、「プロトコル独自の暗号化がなければ必ず省電力」とは言えません。切断と再接続の繰り返しは端末の動作を増やし、不適切な接続維持の設定が計算処理の少なさを相殺することもあります。

認証に失敗した場合は、サーバーが要求する認証方式、ユーザー名の形式、パスワード、アカウント権限の順に確認してください。ドメイン名を使う接続だけ失敗し、IPアドレスなら正常な場合は、DNSの経路を調べます。UDP通信だけ失敗する場合は、転送機能とネットワークのポートを確認します。3つの原因を分けて記録すると、Global Routingを頻繁に切り替えるよりも問題を特定しやすくなります。

06 / 3層トンネル

WireGuard：鍵・アドレス・ルートをまとめて確認

WireGuardは、シンプルな構成の3層暗号化トンネルを確立することを目的とし、公開鍵でピアの身元を識別して、UDPでIPデータを転送します。リクエスト単位で転送するアプリケーションプロキシとは考え方が異なるため、トンネルアドレス、ピア、ルーティング範囲を理解する必要があります。Shadowrocketで利用する際は、WireGuardのピア設定とクライアント側のRuleも区別してください。判断する階層が異なるため、一方をもう一方の代わりとして扱うことはできません。

Private KeyとPublic Keyの向き

Private Keyは現在のピアに属する秘密情報なので、安全に保管してください。Public Keyは、それを識別する必要がある相手に共有できます。クライアント設定の対向Public Keyにはサーバーの鍵を指定し、サーバー側にはクライアントのPublic Keyを登録します。両側の公開鍵を逆に入力したり、秘密鍵を変更した後に対応する公開鍵を同期しなかったりすると、ハンドシェイクを確立できません。鍵は通常のパスワードではないため、文字数が似ているからといって入れ替えないでください。

設定にPreshared Keyが含まれている場合は、双方で共有する別の認証情報です。両端で一致させてください。Endpointは接続先の外部アドレスとポートであり、トンネル内部のアドレスではありません。インターフェースのAddressは、トンネル内で端末に割り当てるアドレスで、Endpointをそのまま入力する場所ではありません。サーバーがピアごとに使用できる送信元アドレスを制限している場合もあります。「ハンドシェイク成功後に通信できない」ときは、アドレスの割り当ても確認してください。

Allowed IPsとRuleの役割

WireGuardのAllowed IPsは、ピアの選択や受信元の制限に関わり、通常のプロキシにおけるドメインルールとは異なる意味を持ちます。クライアントへの組み込み方によって、どの通信がトンネルに入るかも変わります。ネットワーク全体の範囲が指定されているからといって、Shadowrocketのすべてのリクエストが必ずWireGuardを通るとは限りません。まずGlobal RoutingとRuleで選択されているポリシーを確認し、そのうえでWireGuardに渡された通信がピアの設定に合っているかを確認してください。

トンネル経由で内部ネットワークに接続する場合は、そのネットワークのアドレス範囲が現在接続しているWi-Fiのローカルアドレスと重複していないか確認してください。同じプライベートアドレス範囲が自宅と接続先の両方で使われていると、ルーティングの判断が曖昧になります。実際のネットワーク構成に基づいて調整し、すべてのローカルネットワークを単純にリモート側へ送らないでください。LAN内の機器へのアクセスやローカルDNSの動作が変わる可能性があります。

Keepaliveとモバイル通信時のバッテリー消費

Persistent KeepaliveはNATのマッピング維持に使うもので、ダウンロード速度を上げる設定ではありません。外部からの接続が必要な場合や、アイドル状態のマッピングがすぐ破棄されるネットワークでは役立つことがあります。一方、頻繁にKeepaliveを送ると、無線モジュールが動作する機会も増えます。フォアグラウンドでリクエストを送るだけの使い方なら、根拠なくKeepaliveの間隔を極端に短くしないでください。まずアイドル状態からの復帰に実際の問題があるかを確認します。

WireGuardは、有効な認証データをもとにピアのアドレスを更新できるため、一定のアドレス変更に対応します。ただし、すべてのアプリのセッションが途切れずにネットワークをまたいで継続するわけではありません。Wi-Fiとモバイル通信の切り替え後に、新しいUDP経路へ到達できるか、NATマッピングが更新されるか、アプリが再試行するかによって復帰状況が変わります。まずハンドシェイクと送受信の状態を確認し、トンネル層とアプリ層のどちらで止まっているか判断してください。

MTUは大きければよいわけではない

トンネルのカプセル化には追加のデータ領域が必要で、実際の通信経路で許容されるパケットサイズがローカルインターフェースの上限より小さい場合もあります。MTUが適切でないと、小さなリクエストは正常でも大きな応答が止まったり、特定のウェブサイトが繰り返し読み込み中になったりします。まずサーバーの負荷とパケットロスを確認し、サーバー側の案内に沿って変更内容を記録しながら調整してください。一度に変更する値は1つにして、同じタスクで再テストします。別のネットワークの数値をそのまま使ったり、大きなファイルの速度低下をすべてMTUの問題だと決めつけたりしないでください。

WireGuardの設定一式があり、特定のトンネルネットワークや常時接続が必要な用途なら、元の設定を基準に構成できます。通常のプロキシ用サブスクリプションしかない場合、鍵、インターフェースアドレス、ルートを推測して設定することはできません。「3層トンネル」だからアプリケーションプロキシより高機能と考えるのではなく、サーバーの実際の機能と利用目的に基づいて選んでください。

07 / QUICと輻輳制御

Hysteria2：まずUDP経路を確認

Hysteria2はQUICをベースにプロキシ通信を行い、パケットロスや長い往復遅延がある環境での接続を重視します。QUICはUDP上で動作し、TLSベースのセキュアなハンドシェイクと多重ストリーム転送を組み込んでいます。この設計は、単一のTCPバイトストリームとは異なる処理方法を提供しますが、効果は実際のネットワーク環境に左右されます。ネットワークで該当するUDP通信が許可されていなければ、輻輳制御を工夫しても基本的な到達性の問題は解決できません。

多重ストリームで軽減できる待ち時間

1本のTCP接続では、前方のデータが失われると、そのデータを再取得するまで後続のバイト列を順番に渡せないことがあります。QUICでは、異なるストリームのデータを比較的独立して渡せるため、ストリーム間で発生する順序待ちを減らせます。ただし、同じストリーム内では信頼性の高い転送が必要であり、各ストリームは基盤となるネットワーク容量を共有します。「多重ストリームならパケットロスの影響を受けない」と考えたり、すべてのウェブページが速くなると期待したりしないでください。

QUICには暗号化、輻輳制御、パケット処理も必要で、モバイル端末の処理負荷や動作回数は実装とタスクによって変わります。電波が弱く再送が増えると、バッテリー消費が増えることがあります。高スループットのタスクが早く完了すれば、通信が続く時間を短縮できる場合もあります。1回のダウンロード速度だけで一日のバッテリー消費を判断せず、短いリクエスト、長時間のダウンロード、待機後の復帰を別々に比較してください。

認証・TLS・難読化の項目を個別に確認

Hysteria2の設定には通常、サーバーアドレス、ポート、認証情報、TLS関連の条件が含まれます。Server Nameはサーバー証明書と接続入口の設定に合わせてください。パスワードや認証文字列は変更せず、そのまま設定します。構成で別途難読化を使っている場合は、その種類とパスワードもクライアントとサーバーで一致させる必要があります。難読化は、どのサーバーでも任意に有効化できる追加機能ではありません。設定が一致しないと通信に影響します。

プロトコルの世代も一致させる必要があります。名前が似ている異なる世代でも、認証形式やハンドシェイクが同じとは限りません。表示名を変えるだけでは変換できません。まずサーバーから提供された読み込み用情報を使い、読み込み後のTypeがHysteria2に対応しているか確認してください。サブスクリプションの解析後に用途が分からない項目があっても、設定を「すっきり」させるために削除せず、項目の役割とクライアントの対応状況を確認します。

帯域幅の設定は通信速度を購入する項目ではない

設定に上り、下り、輻輳制御に関する項目がある場合は、まず単位と役割を確認してください。設定によってはアルゴリズムに帯域幅の想定値を伝えるもので、物理的な通信容量を増やすものではありません。実際より高い値を設定すると、通信経路の能力を超える送信につながり、キューイングやパケットロスが発生したり、他のアプリの使用感が悪くなったりすることがあります。低すぎる値はスループットを制限する場合があります。サーバー側の制限と、現在のネットワークのボトルネックも残ります。

モバイル通信で利用できる帯域幅は、電波状況、場所、混雑によって変わります。固定回線に適した設定がモバイル通信にも適しているとは限りません。ダウンロードが速いのにウェブページへの応答が悪くなる場合は、通信帯域を継続的に使い切っていないか確認し、数値をさらに上げることは避けてください。応答性が重要な用途では、ピーク時のスループットより、待ち時間が安定していることが重要な場合があります。速度測定画面の一つの結果ではなく、実際のタスクをもとにプロトコルを選んでください。

失敗時は経路と認証を分けて確認

同じ端末で特定のWi-Fiでは接続できず、モバイル通信に切り替えるとすぐ接続できる場合は、UDP経路とネットワークポリシーを優先して確認します。両方のネットワークで同じハンドシェイク段階に失敗する場合は、Type、認証、証明書、システム時刻を確認してください。接続後の大容量通信に問題がある場合は、パケットロス、サーバー負荷、パケットサイズを続けて調べます。症状と変更内容を記録しておくと、偶然の成功を安定した動作と誤認せず、Hysteria2が現在の環境に合うか判断できます。

08 / 実測と選定

同じタスクで比較し、階層ごとにトラブル対処

プロトコルを選ぶ際の最終的な判断材料は、同じ端末で実際のタスクを繰り返したときの結果です。候補となる項目の設定が正しく、サーバーが正常であることを確認したうえで、ウェブページの初回表示、連続アクセス、長時間の通信、待機後の復帰をそれぞれテストしてください。各回ではプロトコルまたはノードの主要な条件を1つだけ変更し、ネットワーク、電波状況、テスト内容を記録します。地域や負荷が異なるサーバーを比較しても、特定のプロトコルが本質的に速い証明にはなりません。

Global Routingとプロトコルの種類は別々に設定

Global RoutingのConfig、Proxy、Directは、リクエストをどの経路に送るかを決めるもので、サーバーのプロトコルは変更しません。Configは現在の設定のルールに従って振り分けます。Proxyは対象となる通信をプロキシポリシーに送ります。Directは直接接続します。ルールの影響を切り分けるために一時的にProxyを使う方法はありますが、システム上のすべての通信、LAN向けの例外、DNSの動作が一律に変更されるわけではありません。実際の設定とログも合わせて確認してください。

以下はRuleの構文を示す独立した例であり、既存ファイルと置き換えて使える完全な設定ではありません。ルールは上から順に判定され、FINALはそれまでに一致しなかったリクエストを処理します。ここでPROXYはプロキシポリシー、DIRECTは直接接続を意味します。変更前にConfigをバックアップし、使用するポリシーが現在の設定で有効かを確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

ルールの照合はDNSと関係します。IP関連のルールには接続先のIPアドレス情報が必要で、ドメインルールは照合できるドメイン名がリクエストに残っている必要があります。ログでリクエストがDIRECTに送られている場合は、まずRuleの順序を確認してください。その結果だけをもとにプロキシの性能を評価しないでください。照合対象と順序について詳しくは、ルールキーワード入門をご覧ください。

4種類のテスト結果を記録

1つ目は、接続できるかどうかと失敗した段階。2つ目は、同じ小さなリクエストに対する応答の安定性。3つ目は、連続通信中に大きな変動がないか。4つ目は、画面ロック、ロック解除、ネットワーク切り替え後の復帰です。Connectivity Testは素早く状況を把握する手がかりになりますが、テスト先や方法がすべてのアプリと同じとは限りません。一度の低遅延で連続リクエストの失敗を覆すことはできず、1回のタイムアウトだけでサーバーが恒久的に使えないとも言えません。

バッテリー消費を比較する場合は、画面の明るさ、電波状況、端末温度、アプリ、通信量をできるだけ揃え、十分な時間をかけて観察してください。システムのバッテリー使用状況では、一部の負荷が前面のアプリやネットワーク関連のプロセスに計上されることがあります。そのため、Shadowrocketの割合だけに注目しないでください。端末が熱くなった場合は、大容量通信の継続や電波の弱さを先に確認します。安定した条件で測定できていないのに、プロトコルごとの消費電力を厳密に順位付けしないでください。

失敗した段階から範囲を絞り込む

接続が完全にタイムアウトする場合は、アドレス、ポート、ネットワークの到達性、TCP / UDPの条件を確認してください。TLSエラーが出る場合は、名前、証明書、システム時刻を確認します。認証拒否の場合は、パスワード、UUID、鍵の向きを確認してください。接続後に一部のアプリだけ失敗する場合は、DNS、Rule、UDPへの対応、接続先のサービスを調べます。毎回変更するのは1項目にして、再接続後に同じタスクを繰り返してください。改善しない場合は基準となる設定に戻し、誤りが重ならないようにします。

日常的なウェブ閲覧では、まず既存設定が完全で安定しているか確認します。UDPが必要なアプリでは、通信経路の両端が対応しているかを確認してください。内部ネットワークへの接続では、トンネルアドレスとルートを確認します。大容量通信では、連続使用時の状態を比較します。それでも原因を特定できない場合は、機密情報を隠した症状の記録を添えてFAQをご覧ください。操作の流れを最初から確認するには初期設定ガイドに戻り、プロトコルを頻繁に切り替えるのではなく、階層ごとに確認してください。