Shadowrocket
プロトコルと設定項目のガイド

プロトコルの階層：接続を4つの要素に分けて確認

プロトコル、トランスポート、セキュリティ、ルーティングは別の階層

Add Serverでプロトコルの種類を選ぶと、クライアントがサーバーに宛先や認証情報を伝え、データをやり取りする形式が決まります。トランスポートは、TCPのバイトストリーム、WebSocket、UDPベースの方式など、データの運び方を指します。セキュリティ層では通信の暗号化方法と接続先の確認方法を扱い、ルーティング層では各リクエストをその接続に送るかどうかを決めます。これらを混同すると、プロトコルを変えてもドメイン名の誤りが直らない、ルールを変更しても認証に失敗するといったことが起こります。

接続に必要な情報には、少なくともサーバーアドレス、ポート、認証方式が含まれます。組み合わせによっては、トランスポートのパス、TLSのサーバー名、その他のネゴシエーション用パラメーターも必要です。サーバーアドレスは実際の接続先で、アクセスしたいWebサイトのアドレスとは異なります。ポートは接続口を示す番号にすぎず、よく使われるポート番号だけを見てTLSが有効だとは判断できません。読み込み後は、まず種類が正しいかを確認し、次に追加項目をチェックしてください。似た項目があるからといって、情報を別のプロトコルに流用しないでください。

速度は接続確立、スループット、安定性に分けて考える

短いWebページを開く場合、本文の転送よりもDNSの名前解決、接続確立、安全なハンドシェイクに時間がかかることがあります。大きなファイルを転送し続ける場合は、輻輳制御、サーバーの送信容量、接続先の性能が重要です。音声やインタラクティブな操作では、ジッター、パケットロス、接続復旧の影響が大きくなります。1回の遅延テストで分かるのは、その一部だけです。測定値が低くてもダウンロードが速いとは限らず、帯域幅が広くても電波の弱い環境で操作が安定するとは限りません。比較するときは、接続先、ネットワーク、時間帯をできるだけ揃えてください。条件が違えば、結果の変化はプロトコル以外の要因による可能性があります。

iOSの電池消費は暗号化方式の名前だけでは判断できない

電池消費には、プロセッサーの処理、無線通信、バックグラウンドでの起動、失敗後の再試行が関係します。最新の暗号化方式による処理負荷は要因の一つにすぎません。電波が弱い場合の再送、継続的な接続確認、頻繁な再接続も確認すべき点です。電池消費を比較する際は、画面の明るさ、利用するコンテンツ、電波状況をできるだけ揃え、一定時間観察してください。1回の電池残量の変化をプロトコルのせいだと決めつけることはできません。また、Keepaliveを増やせば必ず安定するわけでもありません。再接続を減らせる一方、待機中の通信が増える場合があります。

プロトコル選びでは、速度ランキングを調べる前に、サーバーが提供する方式、現在のネットワークで利用できる方式、主な用途を確認してください。手元の情報が1種類のプロトコルだけに対応している場合は、別の方式を探すより、正しく読み込み、確実に動作を確認することが重要です。複数の設定を比較する場合は、元の情報を保存し、一度に1項目だけ変更して、失敗が名前解決、接続、認証、接続先へのアクセスのどの段階で起きたか記録します。こうしておけば、次にネットワーク環境が変わったときにも比較結果を活用できます。

プロトコルの種類は接続する双方で合意されるもので、クライアント側だけの好みで決まるものではありません。サーバーに対応する接続口がなければ、Shadowrocketで種類を切り替えても自動的に互換性が生まれるわけではありません。

Shadowsocks：共有鍵とシンプルな通信方式

設計の背景と照合が必要な設定項目

Shadowsocksは、事前共有された認証情報を使って暗号化されたプロキシ接続を確立し、宛先と以降のデータをサーバー経由で転送する方式です。Webセッションやネットワークインターフェース全体を中心とした仕組みではなく、基本設定は比較的まとまっているため、一般的にはアドレス、ポート、パスワード、暗号化方式を確認します。設定項目が少なくても確認は必要です。暗号化方式や認証情報が一致しない場合、またはサーバーの接続口が別のプロトコル用である場合は、正常な通信を開始できません。

暗号化方式はサーバー情報に記載されたとおりに設定してください。方式によって鍵の導出、データ形式、認証方法が異なり、名前が似ていても相互に利用できるとは限りません。認証付き暗号を使う設定では、データの完全性も検証されます。鍵が違う場合、分かりやすいパスワードエラーが表示されず、接続直後に切断されることがあります。認証エラーをすべて回線の不安定さのせいにしないでください。新しい方式の一部では鍵の形式に特別な条件があります。通常のパスワード入力の知識を当てはめず、その設定項目の定義を確認してください。

基本プロトコルと追加トランスポートを分けて確認する

手元の情報にプラグインや外側の通信方式が含まれている場合、Shadowrocketの該当設定がサーバー側の設定と一致しているか確認してください。基本プロトコル、外側のトランスポート、接続ポートが揃って接続条件となるため、どれかが欠けてもタイムアウトすることがあります。古い設定を移す場合は、アドレスとパスワードだけをコピーして追加情報を見落とさないようにしてください。反対に、追加トランスポートの記載がない設定に、設定を「充実させる」ためだけに機能を追加する必要もありません。クライアントが送る形式を変えると、サーバーが認識できなくなる場合があります。

TCPとUDPの利用可否は、それぞれ確認してください。Webページが開けても、そのリクエスト経路が動作していることを示すだけで、UDPが必要なタスクにも対応しているとは限りません。サーバーがUDPを受け付けるか、接続ネットワークが該当する通信を許可するか、現在の設定がそのリクエストを運べるかによって結果は変わります。特定のタスクだけ失敗する場合は、まず使用されるトランスポートを確認し、該当する経路を調べてください。すぐにパスワードを変更するのは避けましょう。プロトコルを比較する際は、同じ接続先とテスト方法を使い、接続先自体の違いをプロトコルの差と混同しないようにします。

速度・電池消費・トラブルシューティング

ネットワークの品質が良く、サーバー負荷も適切であれば、シンプルなカプセル化によって追加処理を抑えられる可能性があります。ただし、実際の速度は経路の容量とサーバー性能の両方に左右されます。ある暗号化方式の結果を、別のデバイスにもそのまま当てはめることはできません。ハードウェアアクセラレーション、実装方法、データ量によっても変わります。モバイル利用では、起動にかかる時間だけでなく、連続したブラウジングの快適さ、ネットワーク切り替え後の復旧、待機中の不要な再接続を確認するとよいでしょう。

トラブルシューティングでは、まずアドレスとポートに到達できるかを確認し、次に暗号化方式と認証情報、最後に追加トランスポートを調べます。すべての接続先で失敗するなら、共通の接続口を優先して確認してください。特定のサイトだけ失敗するなら、ルールの適用、ドメイン名の解決、接続先からの応答を確認します。失敗しても分かりやすい認証エラーが返らない場合があります。「パスワードエラーが出ない」ことは、認証情報が正しい証拠にはなりません。元の情報から別の設定を読み込んで比較できますが、同じ名前の項目を大量に残すと、編集したものとは別の項目を選んでしまうおそれがあります。

この方式は、対応する接続口をサーバーが提供していて、比較的シンプルな設定を使いたい場合に適しています。TLS証明書の設定の代わりになるものではなく、セキュリティ上の動作がすべてTLSと同じという意味でもありません。接続先の本人確認と認証情報の管理については、そのプロトコルが何を信頼の根拠としているか理解してください。情報を受け取った後も、パスワードや鍵を適切に管理する必要があります。問題を他の人に説明するときは、種類、エラーが起きた段階、機密情報を伏せた設定項目を伝え、認証情報そのものは公開しないでください。

まず暗号化方式を確認し、次にパスワードを確認してください。暗号化方式をむやみに変更しても互換性の問題は通常解決せず、正しい設定が使えなくなるおそれがあります。

VMess：認証情報と外側のトランスポートを個別に確認

プロトコルが担う役割を理解する

VMessは、ユーザー認証、宛先の指定、データ保護をプロトコルの仕組みに組み込み、異なる外側のトランスポートと組み合わせて使えます。すべての機能を外側の通信方式に委ねず、プロトコル内にセッションと認証の仕組みを持たせる設計です。クライアントを使う際は、プロトコルの設定と通信を運ぶための設定の両方を理解する必要があります。UUIDを確認しただけでは接続情報は揃いません。トランスポートの種類やセキュリティ設定が欠けていると、認証情報が正しくても通信できない場合があります。

UUIDは認証情報であり、サーバーアドレスでもTLS証明書のサーバー名でもありません。コピーする際は形式を保ち、空白や見えない文字が混ざらないようにしてください。古い情報には以前の認証方式に関する項目が含まれる場合がありますが、経験だけで値を補わず、サーバーが現在求めている内容を確認してください。リンクから読み込むと、手作業で組み立てるより設定項目を保持しやすい場合があります。ただし、読み込みが成功しても、サーバー認証、証明書、通信経路が確認済みという意味ではありません。

WebSocket、Host、パスの役割の違い

WebSocketを使う場合、接続には所定のアップグレード処理が必要で、パスやリクエストのHost情報がサーバーの接続先選択に使われることがあります。ここでのパスはサーバー側で定められた接続口であり、自由に指定できるWebサイトのディレクトリではありません。パスの大文字・小文字、先頭のスラッシュ、クエリ文字列の違いによって、該当プロトコルを処理しない場所にリクエストが送られることがあります。サーバーから通常のWebページやエラーページが返ると、通信自体は確立したように見えても、プロキシセッションは成立していません。「アドレスが開く」ことだけを設定が正しい証拠にしないでください。

WebSocketとTLSを併用する場合は、接続先アドレス、TLSのサーバー名、HTTP層のHostを区別する必要があります。3つが同じ場合もあれば、サーバーの構成によって異なる場合もあります。クライアントはまずアドレスに接続し、続いてセキュリティハンドシェイクで名前を確認し、アプリケーション層のリクエストで指定のサービスにアクセスします。どの段階でも設定が合わなければ失敗する可能性があります。サーバー管理記録にあるドメイン名を、すべての項目にそのままコピーしないでください。各項目の役割を把握し、元の情報に沿って設定します。

時刻と認証エラーの切り分け

VMessの認証では時刻に関する検証が行われるため、デバイスの時刻が実際と大きくずれていると接続に失敗することがあります。問題を調べる際は、システムの日付と時刻を確認してください。ただし、すべてのエラーを時刻のずれで説明することはできません。TLS証明書の有効期間も時刻の影響を受けますが、認証とは別の検証段階です。認証エラーと証明書エラーは似た症状に見えることがありますが、必要な対処は異なります。確認できるエラー情報を読み、デバイスの時刻、ユーザー認証、サーバー証明書のどれを確認するか判断してください。

性能面では、追加のトランスポートによってハンドシェイクやカプセル化の負荷が多少増えることがありますが、あらゆるネットワークに当てはまる一定の損失率があるわけではありません。長時間の転送では負荷が分散される一方、短い接続を頻繁に開く場合は、セッション確立のコストが目立つことがあります。モバイルでは、Wi-Fiからモバイル通信に切り替えた後の復旧も確認してください。古いセッションが失敗した際にすぐ再接続できるか、サーバー側に状態が保持されているかも体感に影響します。1回の遅延測定だけで、1日を通した使用感を判断することはできません。

「認証情報、トランスポート、接続口、安全設定」の順に記録して確認することをおすすめします。同じサーバーの別の設定が使える場合は、すべてを入力し直すのではなく、項目の違いを比較してください。特定の外側のトランスポートを有効にした設定だけ失敗するなら、接続パスとサーバー側の対応付けを重点的に確認します。ネットワークを変えて復旧したことは調査の手がかりになりますが、元のネットワークが特定のプロトコルを遮断していた証明にはなりません。名前解決、アドレスファミリー、接続口への到達性もネットワークによって変わることがあります。

VMessのUUID、WebSocketのパス、TLSのサーバー名はそれぞれ役割が異なります。1つの項目が正しくても、他の階層の誤りを補うことはできません。

VLESS：軽量なプロトコルとセキュリティ層の組み合わせ

プロトコルの負担が小さくても、安全性の確認は必要

VLESSは、認証情報と宛先の受け渡しを比較的シンプルに保ち、基本プロトコル自体では汎用的なデータ暗号化を担いません。そのため、通常は適切なセキュリティ層と組み合わせます。「軽量」とはプロトコルの役割分担を指し、速度を保証するものでも、サーバーの検証を省いてよいという意味でもありません。VLESSを理解するには、ユーザー認証がサーバー側でどのように確認されるか、通信中のデータをどの層が保護するかの両方を確認します。VLESSという名前だけでは、接続の安全性を判断する情報として不十分です。

手元の情報にあるUUID、アドレス、ポートは正確に一致させる必要があります。さらにトランスポートの種類、セキュリティ方式、関連する追加項目も確認してください。UUIDをTLSの代わりと考えてはいけません。認証は、サーバーが認めた情報をリクエストが持っているかを確認するものです。一方、安全なハンドシェイクはセッションの保護と接続先の確認に関わり、別の処理です。セキュリティ接続が確立した後に認証情報が拒否されることもあれば、サーバー名の誤りによって、それより前に失敗することもあります。段階ごとに切り分けると、手当たり次第の変更を減らせます。

TLS、REALITY、flowの設定

TLSを使う設定では、サーバー名と証明書の検証条件を確認してください。手元の情報でREALITYが指定されている場合は、クライアントの対応状況、サーバー設定、必要な公開鍵などが一致しているか確認します。REALITYは、任意のTLS接続口に追加できる汎用オプションではありません。セキュリティ方式ごとに必要な項目は異なり、互いに代用できません。重要な情報が不足している場合は、ご自身の元の資料から補ってください。インターネット上で使えそうな値を探しても、特定のサーバー設定に対応した情報でなければ利用できません。

組み合わせによっては、データの処理方法を制限するflowなどの項目が含まれます。速度を自動で上げるスイッチではないため、速さを求めてむやみに追加しないでください。サーバーの対応、選択したトランスポートとの適合性、クライアントの実装条件によって接続できるかが変わります。読み込んだ設定の値を維持し、手動で入力する必要がある場合は一つずつ照合するのが確実です。意味の分からない項目を、名前が似た別の入力欄に入れるのではなく、まずアプリ内で利用できる項目を確認してください。

速度と電池消費は利用条件を踏まえて判断する

プロトコル自体が担う処理が少なくても、接続全体の電池消費が必ず抑えられるわけではありません。安全なハンドシェイク、外側のトランスポート、輻輳制御、無線通信も影響し、長時間接続を再利用するかどうかでも負荷は変わります。動画を連続して見る場合は、最初のハンドシェイクより安定したスループットが重要です。断続的にアクセスする場合は、デバイスの起動や接続確立が目立つことがあります。サーバーの場所、帯域幅、安全方式が異なる設定を比較しても、結果をVLESSと別のプロトコルの違いだけに帰することはできません。

「テスト結果は出るのにWebサイトが開かない」場合は、テスト対象と実際のリクエストが同じ経路を通っているか確認してください。テストによっては、接続口への到達性や特定の接続先だけを調べます。一方、Webサイトの閲覧にはドメイン名の解決、新しい接続の確立、複数のリソースの取得が必要です。Global Routingが想定どおりのモードか、選択中の設定が確認済みのサーバーを使っているかも確認してください。実際の接続記録と、条件を揃えたアクセスを組み合わせて原因を調べます。検証をすべて無効にして、表面上の成功を目指すのは避けてください。

利用を検討するには、手元の情報に必要な項目が揃っていることが前提です。サーバーが完全な組み合わせを提供し、クライアントで必要な項目をすべて設定でき、接続先の本人確認もできる場合に、初めて性能を比較できます。情報が断片的なら、セキュリティ方式を何度も切り替えるより、不足している説明を確認する方が有効です。サブスクリプションを読み込み直す場合はサブスクリプションを読み込む4つの方法を参照できますが、読み込み操作によってサーバーが提供していない情報が補われるわけではありません。

Trojan、HTTP、SOCKS5：認証と暗号化を分けて理解する

Trojanで必要となるTLSの条件

Trojanは一般に、TLS接続上でプロキシ通信を行い、安全な通信路の中で認証と宛先情報の伝達を行います。すべての項目に暗号化の役割を持たせるのではなく、実績のあるセキュリティ層を利用する設計です。利用者にとって、パスワードが正しいことは必要条件の一つにすぎません。サーバー証明書、サーバー名、接続口も正しく設定する必要があります。ドメインの証明書が有効でも、別の接続口につながればプロキシセッションを確立できません。接続口が正しくても証明書の検証に失敗すれば、単なるパスワードの問題とは言えません。

サーバー名は安全なハンドシェイクと接続先の確認に使われ、アクセス先のWebサイト名とは関係ありません。証明書には確認対象の名前が含まれている必要があり、デバイスの時刻も適切でなければなりません。環境によってはアプリケーション層のプロトコルネゴシエーションなどを設定しますが、手元の情報に基づいて入力し、むやみに追加しないでください。証明書エラーが出た場合は、名前の綴り、デバイスの時刻、サーバー側の証明書チェーンを確認したうえで、ご自身のサーバー管理者に問い合わせてください。検証を無効にすると接続先の確認が弱くなるため、通常の修復方法として使うべきではありません。

HTTPプロキシには自動的にTLSが付くわけではない

HTTPプロキシは、所定のリクエスト形式やCONNECTメソッドで接続先へのアクセスを処理します。既存のプロキシゲートウェイでよく使われ、仕組みが分かりやすく設定情報を見分けやすい一方、「HTTPプロキシ」という名称だけでは、クライアントとプロキシの間が暗号化されているとは限りません。接続先のWebサイトがHTTPSを使っていれば、Webサイトの内容はエンドツーエンドのTLSで保護されることがありますが、プロキシから接続先や通信に関するメタデータが見える場合があります。クライアントからプロキシまでをTLSで接続する場合とは、別のセキュリティ境界です。

設定する際は、プロキシの接続口が安全な接続を必要とするか、ユーザー名とパスワードを使うか、必要な接続先ポートが許可されているかを確認してください。一部のゲートウェイは利用方法が限られているため、あるWebページを開けても、すべてのタスクで使えるとは限りません。認証の失敗、接続先ポートの拒否、上流への接続不能はそれぞれ別の問題です。失敗した場合は、テストを繰り返すだけでなく、失敗した段階とステータス情報を記録してください。Webサイト自身が返すログイン画面や拒否ページを、クライアントのプロトコル認証エラーと取り違えないようにします。

SOCKS5のネゴシエーション機能とセキュリティ境界

SOCKS5は、接続先アドレスと認証方式をネゴシエーションし、異なる種類のリクエストに対応します。ただし、基本プロトコルだけで通信全体を暗号化するわけではありません。ユーザー名とパスワードによる認証を、暗号化された通信路と同じものと考えてはいけません。手元のゲートウェイが特定のセキュリティ方式を組み合わせるよう求めている場合は、その条件に従ってください。そうでない場合も、接続ネットワークと接続先との間でどのような信頼関係が必要かを理解する必要があります。種類はサーバーが実際に提供するインターフェースに合わせて選び、HTTPとSOCKS5を互換性のある名称として扱わないでください。

SOCKS5でのドメイン名の処理やUDP対応は、リクエストの形式、クライアントの動作、サーバーの実装にも左右されます。プロトコルで機能が定義されていても、現在の接続口でその機能が利用できるとは限りません。特にリアルタイム通信では、Webブラウジングができるかだけで判断せず、実際に使う通信をテストしてください。ドメイン名をどちら側で解決するかも、プロトコル名だけでは分かりません。クライアントのDNS設定とリクエスト経路を確認しないと、リモート接続の問題を調べる際にローカルの名前解決を見落とす可能性があります。

速度と電池消費を比較する際は、名称だけでなく実際の通信方式を確認してください。安全なハンドシェイク、接続の再利用、ゲートウェイの応答時間は短いリクエストに影響し、連続した通信は接続口の容量やネットワーク品質に左右されます。既存のHTTPまたはSOCKS5ゲートウェイに接続するなら、サポートされていない構成を追加するより、指定されたインターフェースに合わせて設定する方が確実です。認証要件が明確な場合は、ハンドシェイクを1回減らす効果を考える前にセキュリティ境界を確認してください。わずかな起動時間の差を、必要な本人確認の代わりにすることはできません。

WireGuard：宛先プロキシからネットワーク層のトンネルへ

設計モデルによって設定項目の意味が決まる

WireGuardはネットワーク層のトンネルを構築し、公開鍵による認証と暗号化されたデータグラムでIP通信を運びます。特定の宛先への接続だけを扱うプロキシプロトコルとはモデルが異なるため、設定にはインターフェースアドレス、対向ピアの公開鍵、エンドポイント、許可するアドレス範囲などが含まれます。暗号方式を固定してネゴシエーションを簡素化していますが、暗号方式の選択がシンプルでも、ネットワーク設定まで簡単になるわけではありません。アドレスの割り当て、対向ピアに送る宛先、デバイスへの戻り通信を理解する必要があります。

秘密鍵は自分側の認証に使い、公開鍵は相手側を識別するために使います。入力を逆にしないでください。エンドポイントは相手に接続するためのアドレスとポートを示し、インターフェースアドレスはトンネル内で使用するアドレスです。混同しないようにします。事前共有鍵が必要な場合は、双方で同じ値を設定してください。読み込み後、同じ認証情報や内部アドレス一式を複数のデバイス間で安易にコピーしないでください。サーバー側で特定のピアに紐付けて管理されている場合、使い回すとセッションの競合や戻り経路の問題が起きることがあります。

AllowedIPs、ルーティング、MTU

AllowedIPsは対向ピアとのアドレス対応付けや通信先の選択に使われ、単純なWebサイトの許可リストではありません。クライアントに組み込まれた環境では、アプリのルーティング方針と合わせて理解する必要があります。一方の層ではリクエストを該当する接続に送るかを決め、もう一方ではトンネル内でどのアドレスを対向ピアに関連付けるかを制限します。範囲を狭くしすぎると必要な接続先への経路がなくなり、広くしすぎると本来のアクセス範囲から外れる場合があります。サーバー情報に記載されたネットワーク設計を維持し、経験だけでアドレス範囲を最大に広げないでください。

MTUは、該当するインターフェースで転送できるパケットの最大サイズを示します。外側のカプセル化にも容量が使われるため、基盤となる経路で大きなパケットを処理できない場合、小さなリクエストは通るのに大きな応答が止まることがあります。ただし、これは原因の一つにすぎません。ページの読み込みが不完全だからといって、すぐMTUを変更しないでください。接続先のサービス、DNS、パケットロスを先に確認し、再現性のあるテストで少しずつ調整して元の値も記録します。むやみに小さくすると、分割や処理の負荷が増えることもあります。

ネットワークの切り替えとKeepaliveは別のもの

WireGuardは、認証済みのデータ交換の中で対向ピアのアドレス変更を認識できるよう設計されており、モバイルネットワークで役立つ場合があります。ただし、実際に復旧できるかは、接続ネットワーク、アドレス変換の状態、サーバーへの到達性に左右されます。Wi-Fiからモバイル通信に切り替えると、以前のマッピングが無効になり、新たに利用可能な経路を確立する必要が生じることがあります。すべての切り替えが途切れずに行われるとは限りません。また、1回切り替えに失敗しただけで鍵の誤りと判断しないでください。まず固定したネットワークで安定しているかを確認し、次に切り替え後の復旧を調べます。

PersistentKeepaliveは、一定間隔で通信して一部のアドレス変換マッピングを維持するために使われ、速度を上げる機能ではありません。待機中にも通信を続けると無線の使用が増えますが、Keepaliveを行わない場合、特定のネットワーク環境で受信を再開するまで時間がかかることがあります。必要性や間隔は、ご自身のサーバー情報とネットワーク環境に基づいて判断してください。通常の通信中は動作するのに、長時間待機した後の最初のリクエストだけ失敗する場合は、マッピングとKeepaliveを確認する価値があります。すべての設定で一律に有効にする必要はありません。

性能上の利点は、実際のタスクと利用条件に照らして評価してください。暗号設計が固定され、データ経路がシンプルであることは、負荷を予測しやすくする一方、UDPの到達性、経路のパケットロス、サーバーの転送性能がボトルネックになることがあります。大きなファイルを1回転送しただけでは、バックグラウンドの待機中に電池を節約できるか分かりません。モバイル端末では、連続したタスク、短時間の待機、複数回のネットワーク切り替えを観察してください。同じテスト中に複数のトンネル設定を変更すると、改善の理由を特定できなくなります。

秘密鍵を公開したり、トンネル設定一式を通常のスクリーンショットとして共有したりしないでください。トラブルシューティングの記録には、項目名、伏せ字にしたアドレス範囲、失敗した段階だけを残します。

この方式は、完全なトンネル設計があり、内部アドレスと対向ピアの認証情報を適切に管理できる環境に適しています。通常のプロキシアドレスとパスワードしか手元にない場合、それをWireGuardの設定に変換しようとしないでください。また、ハンドシェイクが成立しても確認できたのは条件の一部だけです。実際にアクセスできることを確かめるには、宛先アドレスのルーティング、DNS、サーバーからの戻り経路も確認する必要があります。

Hysteria2：QUICの通信方式と帯域設定の考え方

まずUDPと安全なハンドシェイクの条件を確認

Hysteria2はQUICをベースとする通信方式を採用しています。QUICはUDP上で動作し、接続の仕組みに安全なハンドシェイクとストリーム管理を組み合わせます。この設計は不安定な経路において、従来のTCPベースの構成とは異なる特性をもたらしますが、電波の弱さ、経路の混雑、サーバーの容量不足を解消するものではありません。速度を比較する前に、クライアントからUDPの接続口に到達できる必要があります。現在のネットワークで該当するデータグラムが適切に処理されない場合、このプロトコルに切り替えても使い勝手が改善するとは限りません。

通常、アドレス、ポート、認証情報、セキュリティ上のサーバー名、その他の条件を確認します。Hysteria2は、名前の似た以前のプロトコルと同じものとは限りません。ラベルが似ているからといって互換性があると考えず、読み込み後に実際の種類を確認してください。ポート番号が一般的なWebサービスと同じでも、通信方式が同じとは限りません。トラブルシューティングではTCPの到達性を調べているのか、UDP上で実際にハンドシェイクしているのかを明確にしてください。TCPで接続できてもUDPの確認にはならず、Webページが開くかどうかも、この接続口の利用可否を証明しません。

帯域幅の設定値は動作に影響する入力であり、速度測定の結果ではない

設定によっては、上り・下りの帯域幅などを指定します。これらの値は、クライアントが使うモードやサーバー側の制限を踏まえて理解してください。送信や輻輳制御の方針に使われることがありますが、値を大きくすれば同じ容量を得られるわけではありません。実際の容量は接続ネットワーク、共有回線、サーバー、接続先によって制限されます。目標値を継続的に利用できる帯域幅と誤解すると、キューイング、パケットロス、再送が増え、ダウンロードは進んでいるように見えても操作への応答が遅くなることがあります。

特に上り容量の小さいネットワークでは、アップロードとダウンロードを分けて考えてください。大量のアップロードで上り回線が埋まると、他の接続の確認応答や制御データも待ち行列に入り、全体の使い勝手に影響する場合があります。そのようなときは、まず同時に行うタスクを減らし、通信のない状態と通信中の状態を比べてから、帯域幅の設定を確認します。サーバー、複数の帯域幅の値、接続先のファイルを同時に変えないでください。結果が改善しても、どの変更が効いたのか分からなくなります。

電波の弱い環境ではスループットとジッターの両方を確認する

パケットロスや遅延の変動がある経路では、QUICのストリーム管理や接続の仕組みが異なる復旧特性を示すことがあります。ただし、「電波の弱い環境に適しているか」は条件に基づいて検証する必要があります。ダウンロードを続けたときのスループットと、短いリクエストへの応答速度は別の指標です。テストでは、まず軽い操作を試し、次に連続したタスクを加えて、同時に使ったときに待ち時間が増えるか観察してください。実際の用途に近いテストで初めて、現在のネットワークに合うかを判断できます。

電池消費についても慎重に判断する必要があります。データグラムの再送、継続的な送信、暗号化処理、無線モジュールの稼働時間が消費に影響します。同じタスクを短時間で終えられれば稼働時間が減る一方、高負荷の通信や頻繁な失敗で電池消費が増えることもあります。基盤の通信がUDPだから省電力だと決めつけたり、端末が熱くなったからといってすぐにプロトコルのせいにしたりしないでください。画面、メディアのデコード、バックグラウンド同期、電波の変化をできるだけ揃え、十分な時間、再現可能な条件で観察します。

ハンドシェイクに失敗した場合は、まずアドレス、ポート、UDPの到達性を確認し、次に認証情報とセキュリティ上のサーバー名を調べます。接続できても転送中に不安定になる場合は、帯域幅の設定、同時接続数、接続ネットワークの容量変化を確認してください。特定のWebサイトだけ失敗するなら、DNSとルールの経路を見直します。設定情報に専用の難読化パラメーターが含まれる場合は、サーバー側が要求し、一致する情報が提供されているときだけ入力してください。認証情報や証明書の誤りを直す万能な項目ではありません。

Hysteria2を比較する際は、現在の経路で実際のタスクがどう動くかが重要です。帯域幅の設定値が大きいことやテスト項目への応答が速いことだけでは、継続的なアクセスが安定する証拠にはなりません。

試す前提として、該当するサーバー情報と完全なセキュリティ設定があり、接続ネットワークが必要なUDP通信を許可している必要があります。これらを確認できない場合は、検証済みの接続を使って基準となる結果を取ってください。元の設定情報を復元できるように保存し、一度に1項目だけ変更して比較する方が、何度も読み込み直して記憶に頼って比較するより確実です。

DNS、ルール、利用シーンの選び方：結果を再確認できる手順にする

ドメイン名の解決が、その後の接続先を決める

DNSはドメイン名を接続可能なアドレスに変換し、アクセス先だけでなくプロキシサーバーへの接続にも影響することがあります。この2つは分けて確認してください。Webサイトの名前解決に失敗しても、サーバーの接続口に到達できないとは限りません。一方、サーバーアドレスにドメイン名を使っている場合は、名前解決の失敗ですべてのリクエストが失敗することがあります。暗号化DNSを設定しても、その後のWebサイトへのリクエストが必ずプロキシ経由になるわけではありません。名前解決の経路とアクセス経路は、それぞれの設定やルーティング条件に左右されます。名前だけで結果を判断せず、実際の経路を確認してください。

DNSには、名前解決のための事前条件もあります。DNSサーバー自体がドメイン名を使っている場合、最初の名前解決や接続経路が必要です。設定を誤ると依存関係が循環し、起動直後からすべてのドメイン名を解決できなくなることがあります。すべてのDNS設定を一度に変更せず、まず動作している状態を保ち、選択した設定がサーバー名と接続先の名前をどう処理するか確認してください。IPv4とIPv6の応答で経路が異なることもあります。一部の接続先がタイムアウトする場合は、アドレスファミリーと実際の到達性を調べ、名前解決の結果があるだけで調査を終わらせないでください。

Global Routingで選択した接続を使うかどうかが決まる

設定モードはConfig、プロキシモードはProxy、直接接続モードはDirectです。Configでは現在の設定にあるルールに従ってポリシーを選択します。Proxyは対象となる通信をプロキシ経由にし、Directは直接接続します。このルーティング設定を変えても、サーバーが要求する認証情報やセキュリティ設定は変わらず、証明書の誤りも修正されません。プロトコルを比較する前に、両方のタスクで想定した経路が使われていることを確認してください。一方が直接接続で、もう一方がプロキシ経由では公平に比較できません。Sceneを使う場合はシーン設定も関係するため、これら3つの基本モードと混同しないでください。

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

上の例はルールの構文を示すものです。例示ドメインにはPROXYを使い、該当するアドレス範囲へのリクエストはDIRECT、それ以外はFINALで処理します。これは完全な設定ではなく、手元のサーバー情報の代わりにはなりません。ルールは通常、設定された順に照合されるため、広い範囲を対象とするルールの位置によって、より具体的なルールが適用されるかどうかが変わります。指定したWebサイトだけをプロキシ経由にする方法は、DOMAIN-SUFFIXとFINAL,DIRECTの設定方法をご覧ください。Configモードで実際に適用されたルールも確認します。

利用シーンに合わせて選ぶ

日常のブラウジングでは、接続開始までの待ち時間、名前解決の安定性、ネットワーク切り替え後の復旧を重視します。継続的な転送では、持続可能なスループット、同時利用時の待ち行列、サーバーの容量を確認します。リアルタイム通信では、ジッター、パケットロス、タスクに必要なUDP対応が重要です。長時間のモバイル利用では、待機中の通信と電池消費も確認します。既存のHTTPまたはSOCKS5ゲートウェイを使う場合は、そのインターフェースとセキュリティ条件を最優先で満たしてください。WireGuardのネットワーク設計がある場合は、アドレスと戻り経路を先に確認します。他のプロトコルも、名前のランキングではなく、必要な設定がすべて揃っているかから判断してください。

接続ネットワーク、テスト対象、使用した設定、Global Routing、ネットワーク切り替えの有無、失敗した段階を簡単な記録に残すことをおすすめします。まず安定した環境で短いリクエストと連続したタスクを試し、次に条件を管理しながらネットワークを切り替えます。一度に変更する項目は1つだけにし、失敗したら元に戻してください。Connectivity Testは問題を調べる手がかりであり、すべてのアプリの使用感を保証するものではありません。操作手順は接続確認の手順を、よくある疑問は初心者向けよくある質問10選をご覧ください。

設定情報の保管とトラブル記録で気をつけること

サブスクリプションの更新によってサーバーの設定や一部の項目が変わる場合があります。変更前に、サブスクリプション由来の設定とローカルで変更した項目を区別してください。手動で修正した項目が更新後に上書きされた場合は、プロトコルが自動的に変わったと思い込まず、設定情報の管理方法を確認します。ご自身のサービス提供元に問い合わせる際は、最初に失敗した段階、特定の接続先だけに影響するか、ネットワークを変えた後の結果を伝えてください。パスワード、UUID、秘密鍵、サブスクリプションのURLは伏せます。「接続できない」とだけ示す画像より、再現できる状況を伝える方が原因を特定しやすくなります。

選び方の結論は、「この設定情報、この接続ネットワーク、この用途では、この組み合わせが適している」という条件付きでまとめてください。ネットワークやサーバーの条件が変わったら再確認し、1回のテスト結果を常に正しい順位として使い続けないようにします。