Shadowrocket
プロトコル技術ガイドと設定項目の選び方

選定はサーバーの対応状況が出発点

プロトコルは、クライアントとサーバーが接続を確立し、相手を認証してデータをやり取りする方法を定めます。単独で置き換えられる見た目上の設定ではありません。サーバーがShadowsocksを受け付ける場合、クライアント側をTrojanにすると、アドレス、ポート、パスワードが同じに見えても正しく通信できません。まず名称を比較するのではなく、プロトコルの種類、認証項目、伝送方式、TLSの有無を含むサーバー情報を確認してください。サブスクリプションには通常これらの情報が含まれています。手動で編集する前に、元の設定を保存しておきましょう。

ここでいう速度は、デバイスからサーバーまでの経路、サーバーの負荷、接続先の応答、クライアントの処理負荷を含む、アクセス全体の結果です。プロトコルによってハンドシェイクの回数、通信のオーバーヘッド、パケットロス後の復旧方法は変わりますが、利用可能なネットワーク経路そのものを代替することはできません。Connectivity Testの結果をそのままWebページの読み込み速度とみなさないでください。テスト先と実際の接続先は異なる場合があり、短時間の接続テストでは、継続的な通信中の混雑や変動を捉えにくいためです。

プロトコル・伝送方式・暗号化を区別する

プロトコルはデータ形式と認証方式を定め、伝送方式はバイト列やパケットを運び、暗号化レイヤーは伝送内容を保護します。TCPを使う組み合わせもあれば、UDPを使うものもあります。WebSocketは選択可能な伝送方式、TLSはセキュリティレイヤーです。サーバー情報にはプロトコル名、伝送方式、証明書のドメイン名が同時に含まれることがありますが、それぞれ異なるレイヤーの項目です。VLESSやVMessという種類だけでは設定を再現できません。対応する伝送方式とセキュリティ設定も確認してください。

ルールは別の処理です。まずリクエストに適用するポリシーを判断し、その後、選択したサーバーを経由して対応するプロトコルで接続します。DOMAIN-SUFFIXを設定してもサーバーの認証方式は変わらず、FINALを設定してもTLS名の誤りは直りません。アクセスできないときは、リクエストが想定したポリシーを通っているかを確認してから、プロトコル接続が確立しているかを調べましょう。この2つを混同すると、実際にはDIRECTを使っているのにパスワードを何度も変更したり、認証失敗が続いているのにルールばかり変更したりすることになります。

モバイルではピーク値だけでなく継続時の負荷も確認

iPhoneやiPadのバッテリー消費は、暗号化・復号処理だけで決まるわけではありません。無線通信の頻繁な起動、電波が弱いときの再送、短時間でのハンドシェイクの繰り返し、バックグラウンド接続の維持も消費電力を増やす要因です。同じプロトコルでも、安定したWi-Fiと電波状況が変化するモバイル回線では動作が異なる場合があります。比較時はデバイス、ネットワーク、タスク、テスト時間をそろえ、発熱、読み込み待ち時間、再接続回数も記録してください。プロトコル名だけで一律の省電力ランキングを決めることはできません。

Shadowrocketに表示される項目は、選択した種類や関連オプションによって変わります。このガイドでは各項目の役割を説明しますが、すべてのプロトコルのオプションが必須というわけではありません。実際の設定は、アプリの現在の画面とサーバー情報に合わせてください。編集画面に表示されない拡張項目を、名前やパスワードに書き加えてはいけません。初めて使う場合はガイドに沿って基本的な接続を確認し、必要性が明らかな伝送設定を一つずつ追加してください。変更のたびに一つの項目だけを変えます。

以降の章では、共通の手順で確認できます。まずサーバーが実際に対応している内容を確認し、次に認証情報、伝送方式とセキュリティレイヤー、最後に実際の用途を検証します。手元の情報がアドレスとポートだけで、プロトコルの説明がない場合は、先に不足情報を確認してください。プロトコルを推測したり、セキュリティ設定を手当たり次第に切り替えたりしても、新たな失敗が起きるだけで、再現可能な診断にはつながりません。

設計上の特徴：プロキシデータをまとめて処理

Shadowsocksは、比較的シンプルな方法でプロキシ通信を伝送し、宛先アドレスとアプリのデータを双方で合意した暗号化形式に格納します。完全なネットワークトンネルのように、仮想ネットワークやルーティングアドレスを事前に理解する必要はありません。一般的な手動設定では、サーバーアドレス、ポート、暗号化方式、パスワードを設定します。シンプルな設計により基本設定を理解しやすくなりますが、異なる暗号化方式、プロトコルの世代、拡張機能が相互に使えるという意味ではありません。

初期のストリーム暗号方式から認証付き暗号方式への重要な変化は、受信側が内容を復元するだけでなく、データの完全性も確認できるようになったことです。AEADは暗号化と認証を組み合わせます。クライアントとサーバーは、具体的な方式と鍵情報を一致させる必要があります。名称が似ていても一文字ずつ確認し、鍵の長さや暗号方式の系統だけを根拠に互換性を推測しないでください。異なる鍵形式が必要な設定に、別の種類で使っている任意のテキストパスワードを流用することもできません。

アドレス・方式・パスワードの対応関係

サーバーアドレスは外部接続の宛先で、ドメイン名またはIPアドレスを指定します。ポートはその宛先で動作するサービスを識別します。暗号化方式はデータの処理形式を定め、パスワードまたは指定形式の鍵は認証と暗号化に必要な情報を生成します。これらの項目は一組として確認してください。ポートが正しくても方式が一致しない場合、下位レイヤーの接続は確立しても、その後のデータを相手が受け付けないことがあります。「ポートに接続できる」ことと「プロトコル認証に成功した」ことは別の証拠です。

Subscribeから読み込んだ後は、サーバーの編集画面で種類がShadowsocksになっていることを確認し、方式とパスワードが正しく入力されているかをチェックしてください。共有情報がエンコードされている場合、コピー時に末尾の文字が欠けたり、改行が混入したり、余分なデコードが行われたりすると、内容が変わることがあります。サブスクリプションを再読み込みすると正常に戻る一方、手動編集した記録で接続できない場合は、項目の差分を比較してください。手動変更でサブスクリプション内の別のサーバー情報まで上書きしないようにしましょう。

拡張パラメータが必要なのは、サーバーが明示的に対応している場合です。設定によってはプラグインや追加のカプセル化に関する情報が含まれますが、すべてのShadowsocks接続で必要な標準項目ではありません。基本プロトコルが使えるからといって、任意の追加伝送方式も使えるとは限りません。反対に、サーバーが拡張を要求している場合は、基本の4項目だけでは不十分です。不明な拡張機能は名称、対応するオプション、必要なパラメータを確認してください。TLSを有効にしたり、一般的なポートに変更したりして代用することはできません。

TCPとUDPは個別に検証

Webページを閲覧できても、確認できるのは該当するアプリ通信の経路であり、UDP転送が正常だとは限りません。UDPの動作にはクライアントのオプション、サーバーの設定、中間ネットワークが影響します。利用中のサービスがUDPに対応している場合は、UDPを必要とする実際の用途で検証し、そのリクエストに適用されたポリシーをログで確認してください。Webページは表示できるのに特定のリアルタイム通信が失敗する場合は、まずその通信の転送と対応状況を確認し、必要に応じてプロトコルを見直します。

モバイル端末でのShadowsocksの処理負荷は、暗号化の実装、通信量、ネットワーク状況によって異なります。カプセル化のオーバーヘッドが少なければ負荷を抑えやすい一方、電波が弱い場合は再送による待ち時間が暗号化処理の差を大きく上回ることがあります。設定を比較するときは同じタスクを使い、継続的な通信速度と応答の安定性を確認してください。小さなデータを一度テストしただけでは、長時間の通信が速いとも、バックグラウンド利用の消費電力が少ないとも判断できません。

ユーザーが保有するサービスで完全なShadowsocks設定が提供され、必要な用途が対応する転送方式に合っている場合に適しています。証明書による認証、特定の伝送方式、ネットワークレイヤーのアドレス管理が必要な場合は、サーバーの対応状況に基づいて別の章を確認してください。Shadowsocksの設定に対応しない項目を追加してはいけません。接続後は元の情報を保存し、問題が起きた場合はまずネットワーク環境と設定内容の変更を比較しましょう。

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

VMessは独自のプロトコル構造でユーザー認証とプロキシデータの伝送を行います。一般的な設定ではUUIDでユーザーを識別し、関連するセキュリティパラメータも使用します。VLESSはプロトコル自体の処理を一部省き、外側の仕組みに伝送のセキュリティをより多く委ねる設計です。サーバーアドレス、UUID、伝送方式の項目は似ていても、メッセージ形式とサーバー側の処理方法は異なります。編集画面で種類をVMessからVLESSに変更するだけでは、正しい変換になりません。

この違いを理解しておくと、「パラメータが同じなのに接続できない」理由を把握しやすくなります。UUIDは認証情報の一部にすぎず、すべてのプロトコルで共通に使えるログイン情報ではありません。サーバーは対応する種類を同じ接続先で設定し、伝送方式とセキュリティレイヤーの組み合わせも受け付ける必要があります。サブスクリプションに異なる種類の設定が複数ある場合は、それぞれを独立した接続情報として扱ってください。一方の設定からパスワード、ポート、伝送方式を取り出し、もう一方に組み合わせてはいけません。

接続先アドレスとサービス名を分けて考える

サーバーアドレスは接続先を指定し、TLSのサービス名は認証とハンドシェイクに使われます。WebSocketのHostとPathは、対応するアプリケーションレベルのリクエストに使われます。これらの値は同じ場合もあれば、サーバーの構成に応じて異なる場合もあります。特にアドレスにIPを使う場合でも、証明書がドメイン名に対して発行されていることがあります。サーバーの説明に従って必要な名前を設定し、証明書名を単純にIPへ変更しないでください。また、Pathをドメイン名の一部として扱ってはいけません。

WebSocketのPathは通常、先頭にスラッシュを含み、サーバーが受け付けるパスと一致する必要があります。大文字・小文字、末尾のスラッシュ、余分な空白によってリクエストが拒否される場合があります。Hostはメモ用の名前ではありません。見分けやすい日本語のタイトルを入力しても代わりにはなりません。手動で設定する場合は、アドレス、ポート、UUID、伝送方式、TLS名、Host、Pathを別々の行に整理し、アプリで選択できる項目に一つずつ対応させてください。

VMessの設定にはセキュリティ方式などのパラメータが含まれることがあります。古い資料にある項目が、現在のサービスに適用できるとは限りません。VLESSの拡張機能や伝送方式の組み合わせも、クライアントとサーバーの両方が対応している必要があります。古い説明に記載された初期値を、現在の設定にそのまま入力しないでください。該当する項目が見当たらない場合に、代わりの設定を推測することも避けましょう。サブスクリプションから読み込んだ完全な設定を保ち、必要に応じて利用中のサービス提供元に現在の設定項目を確認してください。

ハンドシェイクの段階数は短時間の操作に影響する

TCP、TLS、WebSocketを組み合わせる場合、通常は各レイヤーを順番に確立する必要があります。少量のデータを扱う短時間の操作では、その後の転送より接続待ち時間が目立つことがあります。一方、既に接続が安定している場合は異なる使い心地になることがあります。継続的なアクセスで安定していても、モバイル回線で頻繁に再接続する状況に適しているとは限りません。比較時は、初回の表示、連続アクセス、ネットワーク切り替え後の復旧をそれぞれ確認してください。

VMessの認証には時刻が関係するため、デバイスの時刻が大きくずれていると認証エラーが発生する場合があります。まずシステムの日付と時刻を確認し、その後プロトコルの項目を再確認してください。VLESSの設定で失敗した場合に、同じ原因をそのまま当てはめることはできません。ネットワークを切り替えた後に既存の接続を利用できるかどうかは、下位の伝送方式にも左右されます。TCP接続は経路の変化後に再確立が必要になることがあります。プロトコル名が似ているからといって、すべての組み合わせで同じように復旧するとは限りません。

この2種類のプロトコルは、VMessとVLESSという名称だけを比べるのではなく、利用中のサービスが指定する設定一式で選んでください。接続できても明確なエラーが表示されない場合は、接続先への到達、TLSハンドシェイク、伝送リクエスト、認証の順に確認します。各手順で判断根拠を記録し、複数の項目を同時に変えて偶然復旧したものの原因が分からなくなる事態を避けましょう。

セキュリティレイヤーも接続構成の一部

TrojanはTLS接続の中でプロキシリクエストとパスワード認証を行い、成熟したTLSの仕組みを使ってクライアントとサーバー間の通信を保護します。そのため、Trojanを理解するにはパスワードだけでなく、サーバー証明書、サービス名、ハンドシェイクも確認する必要があります。外側のセキュリティ接続が確立していない段階では、通常、アプリケーションレイヤーの認証はまだ行われていません。パスワードを繰り返し変更しても、証明書の期限切れ、名前の不一致、ハンドシェイクのネゴシエーション失敗は解決しません。

ここでのTLS接続が保護するのは、プロキシサーバーまでの通信です。接続先のWebサイトがHTTPSを使用する場合は、アプリから接続先までの独立したセキュリティ接続もあります。この2つは同じ証明書ではなく、混同してはいけません。サーバーへの接続は成功しているのに特定のWebサイトで証明書エラーが出る場合は、どのレイヤーからのエラーかを確認してください。エラーメッセージにTLSとあるだけでTrojanサーバーの名前を変更すると、正しい設定を壊すおそれがあります。

接続先・SNI・証明書の役割

アドレスは接続先を示し、SNIはハンドシェイク中に接続するサービスを指定し、証明書はサービスの身元を確認するために使われます。シンプルな構成では同じドメイン名が使われることがありますが、接続先を分けた構成では異なる場合もあります。サーバーの説明に従って各項目を設定し、証明書が想定するサービス名をカバーしていることを確認してください。接続先がIPで示されていても、証明書にそのIPが含まれるとは限りません。指定されたTLS名を先に確認しましょう。

パスワードはサーバーに登録された内容と完全に一致している必要があります。前後の空白、改行、文字の置き換えによって認証に失敗することがあります。ポートはサービスの接続先を示すだけです。よく使われるポートだからといって、そこでTrojanが動作していることや、証明書が正しく設定されていることは証明できません。サーバーが追加の伝送方式を許可している場合は、該当する項目も確認してください。サーバーが明示的に要求していない限り、一般的なTrojanの設定に別の伝送方式のPathやHostを追加しないでください。

ALPNなどの高度な項目は、アプリケーションプロトコルをネゴシエーションしたり、ハンドシェイクの詳細を変更したりするために使われます。両者が後続の処理に合意するための設定であり、汎用的な高速化スイッチではありません。対応する説明がない場合は、読み込んだ設定の値を維持してください。他の設定で見た値をコピーすると、外側の接続は成功しても誤ったサービスにつながったり、サーバーが処理を拒否したりする場合があります。診断では、まず正常に動作していた既知の設定に戻し、項目ごとに違いを特定してください。

証明書エラーは原因ごとに確認

証明書名が一致しない場合は、アドレスとTLS名を取り違えていないか確認し、サーバーが想定した証明書を実際に提示しているか調べます。有効期限のエラーが出た場合はデバイスの時刻を確認し、サーバー証明書の更新が必要か確認してください。信頼チェーンの問題では、サーバー側で必要な証明書チェーンを設定するか、既定の信頼方式を確認します。証明書検証を無効にすると身元確認ができなくなるため、通常の接続復旧手順として使わないでください。

iOSでのTLSの計算負荷やハンドシェイク時間は、全体の使い心地を左右する要素の一部です。安定した接続で多くのリクエストを処理する場合、接続確立の負荷は分散されます。一方、モバイル回線が頻繁に切断されると、ハンドシェイクの繰り返しによって待ち時間と無線通信が増えます。Trojanを一律に「電池を消費する」「速い」と評価することはできません。同じネットワークで実際のタスクを比較し、初回の接続時間と接続確立後の通信性能を分けて確認してください。

ユーザーが保有するサービスでTrojanが明示的に提供され、証明書名と認証情報がそろっている場合に適しています。同じサービスに複数の接続先がある場合は、証明書情報が明確で、現在のネットワークから到達できる設定を優先して確認してください。特定の接続先だけ失敗する場合は、まずルールとDNSを確認し、すぐにTLS設定を作り直さないでください。すべての接続先で失敗し、ログがハンドシェイクを示している場合は、この章の手順に沿って各レイヤーを確認します。名前解決の問題については、DNS設定と名前解決のトラブルシューティングをご覧ください。

2種類の汎用プロキシがリクエストを転送する仕組み

HTTPプロキシは、Webリクエストを集約して転送する用途から生まれました。HTTP形式でプロキシリクエストを受け付け、トンネルが必要な接続では一般にCONNECTを使います。一方、SOCKS5は、ユーザーがどの種類のWebコンテンツにアクセスしているかに依存せず、より汎用的な接続先アドレスと接続リクエストを扱います。両者は設計上の重点が異なりますが、いずれもサーバーが該当プロトコルに対応している必要があります。アドレスとポートしか分からないからといって、どちらかを任意に選んで試すことはできません。

HTTPプロキシ、TLSで接続するHTTPプロキシ、HTTPプロキシ経由でHTTPSサイトに接続することは、それぞれ異なる概念です。最後のケースで、接続先サイトのHTTPSがプロキシ接続先までのすべての通信も同様に保護するわけではありません。SOCKS5自体も暗号化トンネルではありません。セキュリティ上の範囲を判断するときは、外側の接続が保護されているか、アプリの通信内容がエンドツーエンドのセキュリティプロトコルを使っているかを分けて確認してください。

アカウント認証と通信の保護を分けて確認

この2種類の設定では、一般にアドレス、ポート、ユーザー名、パスワードを使います。ただし認証の有無や対応方式は、サーバーの設定によります。ユーザー名が空欄でも匿名で利用できるとは限らず、任意の文字を入力してもサーバーに受け入れられるわけではありません。手元の情報に認証付きのプロキシアドレスしか記載されていない場合は、プロトコルの説明に沿って項目を分けてください。ユーザー名をアドレス欄に残したり、ポートをパスワードの一部と誤認したりしないようにしましょう。

SOCKS5のユーザー名とパスワードによる認証は、データ全体の暗号化を提供するものではありません。外側の接続を保護する必要がある場合は、名称が似たオプションを探すのではなく、サービスが実際に対応するセキュリティ機能を確認してください。HTTPプロキシも同様です。接続先サイトの証明書が正常でも、確認できるのはその接続先に関する検証です。プロキシ接続先の身元や通信方式の確認には代わりません。

プロキシへの転送時にドメイン名をローカルとプロキシ側のどちらで処理するかによって、名前解決の結果とトラブルシューティングの方針が変わります。クライアントからドメイン名をプロキシへ渡す場合もあれば、設定やリクエスト形式によって先にIPアドレスを取得する場合もあります。ドメイン名でアクセスできない一方、既知のアドレスでは正常に見える場合は、DNSの経路とログに記録された宛先の形式を確認してください。すぐにアカウント認証の問題だと判断しないでください。2つのテストは異なる名前解決経路を通っている可能性があります。

UDP対応は種類の名称だけでは判断できない

SOCKS5の規格にはUDPに関する仕組みが含まれますが、実際に利用できるかはクライアントの実装、サーバーの能力、ネットワーク経路の到達性に左右されます。HTTP CONNECTの一般的な用途は主にTCPトンネルです。その接続先であらゆるUDP通信ができるとは限りません。リアルタイムの音声・映像やその他のUDP通信が主な用途の場合は、その接続設定が対応しているかを明確に検証してください。ブラウザーでWebページを開けただけでは、すべての要件を確認したことにはなりません。

iPhoneやiPadでの性能も、接続経路によって変わります。シンプルな接続先が特定のネットワークで直接的に動作する場合もあれば、遠隔地での処理、同時接続数の制限、認証方式によって待ち時間が発生する場合もあります。歴史の長いプロトコルだから必ず遅い、設定項目が少ないから必ず省電力、とは限りません。失敗と再試行を繰り返すと、シンプルな設定でも無線通信が増えてバッテリー消費が目立つことがあります。

ユーザーが保有するHTTPまたはSOCKS5のサービス情報が明確な場合や、既定のネットワーク内にあるプロキシ接続先を利用する場合に適しています。まず信頼できる範囲を確認し、必要な通信と名前解決の方法を検証してください。デバイスから接続先までのデータを保護したい場合、これらの名称を選ぶだけでは設定は完了しません。接続先のセキュリティレイヤーを確認できない場合は、サービスの説明を確認してください。ブラウザーのアドレスバーにあるセキュリティ表示から、経路全体が保護されていると推測してはいけません。

リクエストのプロキシからネットワークパケットの転送へ

WireGuardは、簡潔なプロトコル構造でネットワークレイヤーのトンネルを確立し、公開鍵で相手を識別して、UDPで暗号化パケットを伝送します。接続先ごとにプロキシリクエストを構成する前述の種類とは異なり、接続先だけでなく、トンネル内で使う自分のアドレス、相手の鍵、その経路に通すアドレス範囲も設定する必要があります。「パスワードだけを入力する別のサーバー種類」と理解すると、重要な項目を見落とします。

WireGuardは固定された最新の暗号方式を採用し、ユーザーが暗号化方式をメニューから選ぶ必要を減らしています。方式の組み合わせを設定する手間は抑えられる一方、鍵、アドレス、ルーティングの関係を正しく設定することが重要です。プロトコルがシンプルだからといって、ネットワーク設定を省略できるわけではありません。鍵が正しくても、トンネルのアドレスや許可範囲が合っていないと、ハンドシェイクが成立しても通信が戻ってこないことがあります。

自分の秘密鍵と相手の公開鍵は入れ替え不可

秘密鍵は自分の身元を証明するために使うため、適切に保管してください。公開鍵は相手を識別するために使います。クライアント設定に必要な相手の公開鍵は、サーバーが実際に使用する秘密鍵に対応していなければなりません。サーバー側もクライアントに対応する公開鍵を認識する必要があります。双方が別々に鍵をランダム入力すれば動作するものではありません。事前共有鍵を使う設定では、その値も両側で一致させてください。公開鍵や秘密鍵とは別に保存し、相互に代用してはいけません。

Endpointは外側のサーバーアドレスとポート、トンネルのAddressはトンネルに入った後の自分のアドレスを示します。これらは異なるネットワークレイヤーの項目です。Endpointには外部から到達可能なドメイン名を指定できますが、トンネルのAddressには指定された内部ネットワークの範囲が使われることがあります。EndpointのIPをトンネルアドレスに入力しても、通常は正しい設定になりません。ユーザーが保有する設定を読み込むときは、アドレスに付くプレフィックス長を保ち、IPv4とIPv6を区別してください。IPらしく見える部分だけを残すことはできません。

AllowedIPsはアドレス範囲を相手の接続先に割り当てます。完全な設定では、ルーティング先と許可する送信元範囲の両方に関係します。Shadowrocketには独自のルールポリシーもあるため、サーバー側のトンネル設定とクライアント側の通信振り分けは別の制約として理解してください。「すべてのリクエストを通す」ためにアドレス範囲をむやみに広げないでください。特にLANや複数の内部ネットワークにアクセスする場合は、元のネットワーク設計に基づいて必要な宛先を確認しましょう。

KeepaliveとMTUも適切な範囲で設定

PersistentKeepaliveは必要に応じて中間機器のマッピングを維持し、アイドル状態の後に相手から接続される特定のケースを助けます。間隔を短くするほど信頼性が上がる万能設定ではありません。間隔が短いと定期的なパケットが増え、モバイル回線では無線通信の頻度が上がることがあります。必要性と値はネットワーク状況や既存の設定に応じて決めてください。通信中にときどき再接続するだけなら、まず実際にアイドル時の接続やマッピングに問題があるかを確認します。

MTUは、一度に伝送するデータサイズの上限を示します。トンネルのカプセル化によって利用できるサイズは変わります。経路上で大きなパケットを正しく処理できないと、小さなリクエストは成功するのに、大きなページやファイルの読み込みが止まることがあります。この症状だけでMTUの問題と断定せず、パケットロスや接続先の応答も確認してください。調整が必要な場合は元の値を保存し、同じネットワークと接続先で一度に一つずつ検証します。DNS、ルール、鍵を同時に変更しないでください。

iOSではWireGuardのUDP通信と接続先の更新機能により、一部のネットワーク変化に対応できますが、ネットワーク切り替え時に常に接続が途切れないわけではありません。利用中のネットワークがUDPを制限している場合や、マッピング、ルーティング、戻りの経路に問題がある場合は、通信に影響します。完全なトンネル設定を保有し、特定の内部ネットワークにアクセスする必要がある場合に適しています。シンプルな設計だけを根拠に、速度や省電力の優位性が常にあると判断しないでください。

変動のあるネットワーク経路を想定した設計

Hysteria2はQUICを使って伝送を構成し、UDPを下位の通信に利用しながら、認証と輻輳制御の仕組みでプロキシ通信を処理します。高遅延、パケットロス、スループットの変動がある経路を想定した設計ですが、あらゆるネットワークで性能を保証するものではありません。まず現在のネットワークで必要なUDP通信が許可されているか確認してください。外側のパケットがサーバーに届かない場合は、帯域幅や認証項目を変更しても解決しません。

QUICでは1つの接続内で複数のストリームを扱えるため、パケットロスによってストリーム間の配信が妨げられる一部の状況を軽減できます。ただし、すべてのストリームが実際の経路容量を共有し、輻輳や無線信号の制約がなくなるわけではありません。Hysteria2もアプリの通信を独自のプロトコル構造にカプセル化するため、QUICの特性だけからあらゆる用途が必ず速くなるとは言えません。瞬間的な転送ピークだけでなく、実際のタスクが完了するまでの時間も確認してください。

認証・TLS・追加項目を分けて入力

基本設定には、サーバーアドレス、ポート、認証情報、サービスが要求するTLS設定が必要です。認証情報は手元の設定に合わせて正確に入力してください。テキスト形式だからといって、別のプロトコルのパスワードを流用することはできません。証明書名の確認方法は前述と同じです。接続先のアドレスとTLSのサービス名は異なることがあるため、サーバーの証明書が想定した身元をカバーしていることを確認し、検証を有効に保ってください。

サービスによっては追加の偽装設定も提供されます。種類とパスワードはクライアントとサーバーで一致させる必要があります。ユーザー認証とは別の項目なので、2つのパスワードをまとめたり、クライアントだけで有効にしてサーバーが自動的に認識すると考えたりしないでください。サブスクリプションに記載がない場合、性能向上に必須の設定とはみなさないでください。不明な拡張機能は、まず現在のアプリが対応しているか確認してから使用を判断しましょう。

帯域幅パラメータは、速度制限を解除するボタンではありません。該当するモードでは送信方法や輻輳制御に関わる場合があり、入力値は期待する最高速度ではなく、経路の妥当な処理能力を反映する必要があります。過大な値を設定すると実際の容量を超えて送信し、キューの増加、パケットロス、ほかの通信の応答悪化につながることがあります。値が低すぎるとスループットを制限する場合があります。入力の必要性と単位を、アプリの画面とサーバーの説明で個別に確認してください。

速度と応答の遅延を合わせて確認

同じデバイスで大きなファイルを高速に転送していると、ほかのページでタップしたときの応答が遅くなることがあります。これは通常、キューイングや帯域幅の競合に関係します。Hysteria2を評価するときは、最も速かった1回の結果だけでなく、継続的なダウンロードと軽いリクエストの両方を確認してください。設定変更でピーク速度は上がってもページが停止しやすくなった場合は、設定を戻し、より控えめな値が現在のネットワークに適しているか比較します。

モバイル回線の電波状況が変化すると、利用できる通信速度も変わります。固定の帯域幅推定値が常に正確とは限りません。Wi-Fiで得た値をモバイル回線にそのまま適用したり、空いている時間のテストだけで一日の状況を判断したりしないでください。頻繁な再試行、長時間の高速通信、無線通信の稼働は、発熱やバッテリー消費につながる場合があります。バックグラウンドで長時間接続する場合は、実際の利用時間にわたって確認し、一度の速度結果だけで長期設定を決めないでください。

利用中のサービスがHysteria2を明示的に提供し、現在のネットワークでUDP通信が安定して行えることが前提です。この条件を満たさない場合は、提供されているほかの接続設定を検証してください。帯域幅の数値をむやみに上げ続けないでください。選定結果は「このネットワークと用途では適している」と表現し、一度の使用感をプロトコルの固定ランキングにしないようにしましょう。

プロトコル名の順位ではなく、必要な機能で選ぶ

実際の選定では、まず用途上の条件を整理します。利用中のサービスが対応する種類、現在のネットワークでTCPとUDPを使えるか、内部ネットワークへのアクセスが必要か、主な用途が短いページの表示、継続的なデータ転送、リアルタイム通信のどれかを確認してください。完全な設定情報と安定した接続性は、プロトコルの知名度よりも重要です。有効な設定が1つしかない場合は、まずその設定を十分に検証します。複数の設定がある場合は、同じ条件で比較してください。特定の名称を使うために設定を組み合わせ直す必要はありません。

日常的なWeb閲覧では、設定項目がそろい、ハンドシェイクが安定している登録済みの接続設定を使い、最初のページと連続して表示するページの応答を確認します。指定された内部ネットワークのアドレスが必要な場合は、WireGuardなどの既存のトンネル設定でアドレスとルートを確認してください。UDP通信が必要な場合は、プロトコル、サーバー、経路がすべて対応していることを確認します。継続的なデータ転送では、スループット、ほかのリクエストの待ち時間、デバイスの発熱も同時に確認し、単発のピーク値だけで結論を出さないでください。

プロトコルを変更する前にGlobal Routingを確認

Global RoutingにはConfig、Proxy、Directの3つのモードがあります。Configは現在の設定に基づいてルールでポリシーを選びます。Proxyは該当する通信をプロキシ経由で処理し、Directは直接接続します。Proxyに切り替えると、ルールの影響の一部を比較できますが、それだけでは診断になりません。実際のリクエストがどの経路を通ったかはログで確認してください。テスト後は普段使うモードに戻し、一時的なトラブルシューティング設定を長期的なルールとして残さないようにしましょう。

以下の例はルール構文と記述順を示すもので、完全な設定やサーバー情報は含みません。ルールは上から順に照合され、最後のFINALが、それまでに一致しなかったリクエストを処理します。例のPROXYは、実際の設定で利用可能なポリシーに対応させる必要があります。設定ファイルの構成は.confファイルの構造、ルールの適用順はカスタムルールとFINALをご覧ください。

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

問題があるレイヤーを一つずつ検証

まったく接続できない場合は、まず現在のネットワークが利用可能か確認し、次にサーバーアドレス、ポート、プロトコルの種類を確認します。その後、エラーがTLS、認証、タイムアウトのどれを示しているかを調べます。接続はできてもWebページが開かない場合は、DNSと接続先リクエストに適用されたポリシーを確認してください。一部の通信だけ異常がある場合は、UDPが必要か、接続先が異なるか、大きなパケットや同時通信で問題が起きるかを調べます。DNSの変更、証明書検証の無効化、ルールの変更、サーバー設定の作り直しを同時に行わないでください。

ネットワークの種類、選択した接続設定、Global Routingのモード、テスト対象のタスク、エラーが起きた段階を簡潔に記録します。Wi-Fiとモバイル回線を切り替えるときは、ほかの設定を変えずに比較してください。プロトコルを比較する際も、接続先とタスクをできるだけそろえます。バッテリー消費を確認する場合は、通常の利用時間を十分に含め、画面の明るさ、バックグラウンドのタスク、電波の強さも考慮してください。短時間のバッテリー残量の変化だけでは、特定のプロトコルが本質的に電力を多く消費するとは証明できません。

ログやスクリーンショットを共有する前に、サブスクリプションのURL、認証パスワード、秘密鍵、設定を復元できる情報を削除してください。該当する時間帯、接続先の種類、エラー内容だけを残し、設定全体を外部に共有しないでください。サブスクリプション更新後に差分が生じた場合は、種類、アドレス、伝送方式、認証項目を比較します。すべてのローカル設定をすぐに上書きしないでください。購入済みアプリの復元は別の手順です。購入済みアプリの復元方法をご覧ください。プロトコル設定を作り直して対応するものではありません。

最後に、再現できる手順として確認結果を整理します。有効な接続設定を確認し、元の情報を保存して、普段使うルールに戻した後、実際の用途で検証してください。問題が続く場合は、接続済みなのにインターネットに接続できない場合の確認手順またはよくある質問をご覧ください。読み込み手順をやり直す場合はクイックスタートガイドに戻ってください。プロトコルの選定は、設定情報が正しいこと、経路に到達できること、ポリシーが想定どおりであること、実際の用途で検証できることを確認して完了です。