Shadowrocket プロトコル技術ガイド

01 · プロトコルの選び方：接続の階層を理解する

利用中のサービスによって選択肢が決まる

ShadowrocketのAdd Serverでタイプを選ぶ操作は、クライアントが使用する通信形式を指定するものです。接続先が自動的にそのプロトコルに切り替わるわけではありません。同じAddressとPortで複数のプロトコルを受け付けるとは限らず、サーバー側に該当する接続口がある場合にのみ、タイプの選択が意味を持ちます。設定を始める前に、サービスの案内からプロトコル名、アドレス、ポート、認証情報、トランスポート設定を確認しましょう。Subscribeから読み込んだ場合は、まず読み込み結果を保ち、見慣れた名前だからといって認識済みのタイプを別のものに変更しないでください。

プロトコルは、クライアントとサーバーが認証情報やプロキシ要求をどのようにやり取りするかを主に定めます。トランスポートは、それらのメッセージを運ぶ経路を決めます。TLSは、その経路を暗号化し、サーバーの身元を確認する役割を担います。これらは同じ接続情報に並んでいても、それぞれ役割が異なります。たとえばVLESSとWebSocketは、どちらか一方を選ぶ関係ではありません。前者はプロキシ層を表し、後者は外側のトランスポートとして使われる場合があります。階層を分けて考えると、UUIDが正しくてもパスや証明書の問題で接続できない理由がわかります。

接続設定を確認項目ごとに分ける

これらの項目には確認する順序があります。アドレスを名前解決できない段階で認証情報を変更しても、通常は解決になりません。TLSハンドシェイク後にサーバーが認証を拒否した場合、DNSを調整してもパスワードの誤りは直りません。ログでは、最後に出る漠然としたタイムアウトより、失敗に直接関係する最初の情報が重要です。名前解決、トランスポート確立、サーバー認証、接続先へのアクセスのどの段階で失敗したかを記録すると、確認範囲を絞り込めます。

速度やバッテリー消費に一律の順位はない

iOSでの実際の使い心地は、無線の電波状況、往復遅延、パケット損失、サーバー負荷、接続先の影響を同時に受けます。プロトコルによるオーバーヘッドは要素の一つにすぎません。ハンドシェイクの少ない設計は短い接続が多い場面で差が出ることがありますが、大容量ファイルの継続転送では、回線容量や輻輳制御のほうが重要になりがちです。1回のConnectivity Testだけで経路全体のスループットを判断したり、すべての接続先で同じ性能になると考えたりしないでください。

バッテリー消費もプロトコル名だけでは判断できません。暗号化処理はリソースを使いますが、頻繁な再接続、無線通信の継続、過剰なKeepalive、再送の繰り返しも主な要因になりえます。比較する際は端末、ネットワーク、画面の明るさ、実行するタスクをそろえ、初回の読み込み、継続転送、待機中をそれぞれ観察してください。条件をそろえないまま、特定のプロトコルは必ず省電力、あるいは必ず高速だと結論づけるのは適切ではありません。

また、「あるプロトコルに対応していること」と「そのプロトコルのあらゆる組み合わせに対応していること」は分けて考える必要があります。外側のトランスポート、認証拡張、特殊な項目が利用できるかは、現在のShadowrocketの画面と利用中のサービスの案内で確認してください。案内にある項目がクライアントに見当たらない場合、メモ欄や別の入力欄に適当に入力しないでください。まず別階層の設定に該当するかを確認し、必要ならサービス提供元に問い合わせましょう。

02 · Shadowsocks：共有鍵と暗号化方式

設計の目的と接続モデル

Shadowsocksは暗号化プロキシ接続を目的とし、一般に共有鍵で通信を保護します。クライアントはアプリからのリクエストを受け取り、接続先の情報とデータを定められた形式でリモート側へ渡し、リモート側が接続先にアクセスします。これはIP層全体を扱うトンネルとは異なります。主にプロキシ転送を担うため、サーバーアドレスだけでシステム全体のルーティング、内部アドレスの割り当て、ピア間の関係まで表すものではありません。この違いにより設定項目は比較的まとまっていますが、どのリクエストをプロキシに通すかはクライアントのルーティング設定で決まります。

Shadowsocksでは、暗号化方式を自由に調整できる強度スライダーではなく、プロトコルの互換性を決める要素として扱うことが重要です。クライアントとサーバーで同じ方式、鍵のルール、メッセージ形式を使用する必要があります。名前が数文字違うだけに見える方式でも、設計が異なる場合があるため、名称が似ているからと交換しないでください。新しい方式の系列では、鍵の形式や長さに条件があることもあり、一般的なテキストパスワードがそのまま使えるとは限りません。

Address、Port、Passwordと暗号化方式の対応関係

Addressには、利用中のサービスが指定したホスト名またはIPアドレスを入力します。共有リンク全体をAddress欄に貼り付けないでください。Portはサービス側がそのプロトコルを待ち受けているポートであり、WebページのURLに含まれる任意の数字ではありません。Passwordは元の値をそのまま保ち、コピー時に前後の空白、改行、全角記号が混入していないか確認しましょう。暗号化方式は一文字ずつ照合してください。画面に複数の選択肢があっても、サーバー設定と異なる新しそうな名前を選ばないでください。

一般的なAEAD方式は、データの秘匿と完全性の検証を組み合わせ、検証に失敗したメッセージを受信側で拒否できるようにします。鍵や方式が一致しない場合、接続が切れる、接続先が応答しない、認証関連のエラーが出るなどの形で現れ、「パスワードが違います」と明示されるとは限りません。そのため、リモート側のポートに接続できても設定全体が正しいとは言えません。実際の接続先にアクセスできるかまで確認してください。共有リンクを読み込んだ後も、一覧に名前が表示されたかだけでなく、タイプと各項目を確認しましょう。

TCP、UDP、追加トランスポートは別々の設定

Web閲覧でよく使われるTCP通信と、UDPに依存するアプリの通信では、結果が異なることがあります。経路を成立させるには、サーバー、クライアントの設定、中間ネットワークのすべてが該当する転送を許可している必要があります。UDP関連の設定を一つ有効にしただけで、その機能に対応していないリモート側が対応するわけではありません。逆に、Webページが開けてもUDP経路が使える証明にはなりません。すべての失敗をサーバー全体の到達不能と決めつけず、実際のアプリの用途ごとに確認してください。

接続情報には追加のトランスポート設定やカプセル化設定が含まれる場合もあります。これらをShadowsocksのパスワードや暗号化方式と混同しないでください。利用中のサービスが明示し、現在の画面に該当する設定項目がある場合のみ、指定された値を入力します。読み込んだリンクに追加項目が含まれていない場合、手動で補う前に元の設定を記録し、一度に一項目だけ変更してください。方式、ポート、追加トランスポートをまとめて変更すると、何が結果に影響したのか判断できなくなります。

モバイル端末で選択を判断するには

Shadowsocksは設定項目が比較的まとまっており、「接続先・鍵・方式」の関係を理解する出発点になりますが、どのネットワークでも有利という意味ではありません。継続転送の性能はサーバー側の回線や経路上のパケット損失にも左右され、短いタスクでは名前解決や接続確立も影響します。iPhoneでWi-Fiからモバイル通信に切り替えると、既存の接続を再確立する場合があります。復旧までの時間は経路全体に依存するため、プロトコル名だけでは判断できません。

トラブルシューティングでは、次の4段階で確認範囲を絞ります。まずAddressを名前解決できるか、次にポートが現在の接続口に対応しているか、その後に方式と鍵、最後にTCPとUDPで必要なタスクの違いを確認します。接続自体は確立するのに一部のドメインだけ失敗する場合は、このページの接続確認とルール振り分けの章でルールとDNSを確認してください。一つの接続先の問題を解決するために、認証に成功しているプロトコル設定を何度も変更しないでください。

03 · VMessとVLESS：認証・トランスポート・セキュリティ層

項目が似ていても互換性があるとは限らない

VMessとVLESSはどちらもユーザー識別にUUIDを使うことが多く、読み込み後にアドレス、ポート、識別情報が似て見える場合があります。しかし、同じ通信形式ではないため、タイプだけを入れ替えて他の項目をそのまま使うことはできません。VMessは独自の認証とデータ保護の仕組みを備えています。VLESSは基本設計がよりシンプルで、VMessと同等のペイロード暗号化を単体では提供しないため、通常は正しく設定された安全なトランスポートと組み合わせます。どちらを選ぶかは、まず利用中のサーバー接続口に従ってください。

この設計の違いを、そのまま性能の優劣に置き換えることはできません。VLESSでプロキシ層の一部の役割が減っても、外側のTLSなどのセキュリティ機構にはそれぞれコストがあります。VMessの実際の性能も、トランスポート、接続の多重化、経路の状態に影響されます。接続情報に「VLESS」としか記載されておらず、外側のセキュリティ設定が説明されていなければ、情報として不十分です。認証項目があるからといって、通信経路の暗号化とサーバー認証も済んでいると思い込まないでください。

UUID、時刻、認証エラー

UUIDは形式が定められた識別子です。文字と区切り記号をすべてそのまま保ち、表示名、サブスクリプションのURL、別のパスワードを入力しないでください。VMessの認証設計は時刻に関係するため、端末の時計が大きくずれていると接続に影響することがあります。認証エラーが出たら、システムの日付と時刻が正しいか確認しましょう。読み込んだ情報に互換性関連の項目がある場合は、サービスの案内と現在のクライアント設定を基準にしてください。古いガイドから数字を転記して、正常に読み込まれた値を上書きしないでください。

UUIDが正しくても、認証条件がすべて満たされているとは限りません。サーバー側でユーザーが無効化された、特定の接続口が制限された、接続情報が更新された可能性があります。サブスクリプションを更新しても失敗する場合は、名前だけでなく、新旧のプロトコルタイプ、ポート、トランスポート項目を比較しましょう。同じ名前でも別の設定につながる場合があり、名前が違っても同じ接続口のメモだけが異なる場合があります。判断は常に実際の設定項目に基づいてください。

WebSocket、Host、パス、SNI

WebSocketはプロキシデータを運ぶ外側のトランスポートとして使われ、そのパスはサーバー側のルーティング設定と一致している必要があります。パスの先頭にスラッシュが必要な場合が多く、大文字・小文字やその他の文字も照合に影響します。HostはHTTPリクエストで仮想ホストを選ぶ際に使われる場合があります。SNIはTLSハンドシェイクでサーバー名を通知します。役割の階層が異なるため、設定情報で同じ値が使われていても、常に同じ値にすべきとは限りません。

AddressにIPを使う場合でも、サービスの案内でドメイン形式のSNIが指定されることがあります。接続先アドレスと証明書上のサーバー名は別の情報です。指定され、検証に通る名前を使用し、検証を無効にしてエラーを回避しないでください。外側のトランスポートが確立していなければ、サーバーがプロキシ層のUUIDを確認する段階にすら進まない場合があります。そのため、TLSエラー、パスの不一致、認証エラーを切り分ける必要があります。

名前の順位ではなく、タスクに応じて確認する

モバイルネットワークでは、追加のカプセル化によってハンドシェイクやパケットのオーバーヘッドが増え、接続復旧の挙動も変わることがあります。実際の影響はタスクの長さを考慮して確認してください。短い接続が多いページ、長時間維持するセッション、継続ダウンロードでは、見るべき点が異なります。Wi-Fiでは動作し、モバイル通信では失敗する場合は、まず同じ接続先の名前解決、外側のトランスポート、ポートへの到達性を確認し、その後にプロトコルを調べましょう。Configの全般的な使い方は機能ガイドで確認できます。ルーティング設定の問題をプロトコルの互換性と取り違えないようにしてください。

04 · Trojan：TLSによるサーバー認証とパスワード認証

通信経路の保護とユーザー認証の役割

TrojanはTLSを使った接続方式で、保護された通信経路上でプロキシリクエストとユーザー認証を行います。理解するには、サーバーの身元とユーザーの身元を分けて考えましょう。TLS証明書は接続先のサーバーをクライアントが確認するためのものです。Passwordは、アクセス権を持つユーザーかどうかをサーバーが識別するために使います。パスワードが正しくても証明書を検証できなければ、正常な接続とは見なせません。証明書が正常でもパスワードが一致しなければ、プロキシを利用できません。

この役割分担から、TLSは「速度を試すため」に付け外しできる装飾ではないことがわかります。一般的なTrojan接続では、トラブルシューティングのためにTLSを無効にしても、リモート側が従来どおりプロトコルを認識するとは限りません。利用中の接続情報に特殊なトランスポート設定が含まれる場合は、Trojan接続には常に3つの項目しかないと決めつけず、指定された組み合わせを確認してください。基本プロトコルと追加のトランスポートを一致させる必要があり、どの階層の誤りも最終的なリクエストを妨げる可能性があります。

Address、Port、Password、SNIの入力範囲

Addressはネットワーク接続先を指定します。サービスが指定するドメイン名または明示されたIPアドレスを入力してください。PortにはTrojanの接続口のポートを指定します。TLSを使うからといって、特定の固定ポートだと推測しないでください。Passwordは元の情報をそのまま入力し、コピー時に見えない改行が混じっていないか確認します。SNIにはサービスの案内にあるサーバー名を指定します。Addressと同じ場合もあれば、AddressがIPのときに別のドメイン名を使う場合もあります。

証明書の検証では、名前の一致、有効期間、信頼チェーン、端末の時刻などが関係します。SNIは任意のドメイン名を入力すれば有効な証明書が得られるという機能ではありません。接続先に期待する名前を通知し、その名前に対応する検証を行うためのものです。証明書名が一致しない場合は、入力ミス、サービス情報の期限切れ、サーバー側の証明書設定を確認してください。端末の日付に問題があれば、まずシステム時刻を修正します。検証を無効にすると接続の安全性が変わるため、恒久的な解決策にしないでください。

接続失敗が起きた順序を読み解く

Addressを名前解決できない場合、サーバーに到達する前の段階で問題が起きています。リモート側に接続を拒否された場合は、まずポートと待ち受け状態を確認します。TLSの名前や信頼に関するエラーが出た場合は、サーバー認証層を重点的に調べましょう。TLSの通信経路が確立して初めて、サーバーはTrojanの認証と接続先への転送を処理できます。この順序で確認すれば、証明書が検証される前にPasswordを繰り返し変更したり、根拠なく設定の組み合わせを試したりするのを防げます。

通信経路と認証が完了しても、接続先のWebサイトが開かない場合があります。その場合は、接続先ドメインの名前解決、リモート側から接続先への到達性、ローカルのリクエストが実際にこの接続を選んでいるかを確認してください。一つのWebサイトだけ失敗しても、Trojanの接続口全体の問題とは限りません。アクセス可能な別の接続先を比較に使い、リクエスト記録でエラーの段階を確認しましょう。Homeの接続スイッチの状態だけで判断しないでください。

モバイルネットワークでの動作と利用時の確認

TLSでは接続確立にハンドシェイクが必要で、往復遅延が大きい場合や接続を頻繁に再確立する場合に、そのコストが表れやすくなります。セッション確立後の転送性能は、主に回線容量、輻輳、接続先の応答に左右されます。TLSを使っているから必ず遅いとは限らず、1回のテストが短時間で終わったからといって、その後も安定するとは限りません。iOSでは無線ネットワークの切り替え、スリープ、復帰によって既存接続の状態が変わることがあるため、復旧の様子を個別に確認してください。

Trojanの設定情報がそろっている場合は、証明書を検証できるか、AddressとSNIが明確か、ネットワーク切り替え後に復旧できるかを重点的に確認しましょう。用途不明の設定をむやみに追加する必要はありません。項目ごとの確認方法はTrojanの設定項目ガイドをご覧ください。正常に使える設定を保存してから、そのコピーでテストします。サブスクリプション更新後は、古い手動コピーではなく、現在有効な設定を確認しているかも確認してください。

05 · HTTPとSOCKS5：汎用プロキシの機能範囲

HTTPプロキシとHTTPSサイトは別の概念

HTTPプロキシは汎用プロキシのアクセス方式であり、規定に沿ったリクエストを処理し、CONNECTなどの仕組みで接続先への通信経路を確立します。よくある誤解は、接続先URLがHTTPSなら、クライアントとプロキシサーバーの間も必ずTLSで保護されるというものです。実際には、2つの通信区間を分けて考える必要があります。WebサイトのHTTPSは、クライアントと接続先サイトの間のアプリケーションデータを主に保護します。プロキシ接続口自体がTLSで保護されるかは、プロキシの種類と接続口の設定によって決まり、接続先URLから推測することはできません。

CONNECT後の接続先データがHTTPSで保護されていても、プロキシは接続先を把握し、通信を中継します。そのため、接続先データの暗号化が、プロキシ認証情報やすべての接続メタデータにも同じ保護を与えるわけではありません。利用中のサービスが暗号化されたHTTPプロキシ接続口を提供している場合は、案内に従ってタイプとセキュリティ設定を選んでください。通常のHTTP接続口を別タイプに変更し、ハンドシェイクの失敗をユーザー名の誤りだと考えないでください。

SOCKS5のネゴシエーション、認証、UDP

SOCKS5は汎用的な接続転送プロトコルで、ネゴシエーションによって認証方式とリクエスト操作を決定します。接続先のアドレスとポートを指定でき、UDPアソシエーションの仕組みも定義されていますが、プロトコル自体はTLSのような通信経路の暗号化を提供しません。ユーザー名とパスワードはアクセス制御に使うもので、暗号化機能と同じではありません。認証情報を入力しても、クライアントからプロキシまでの区間がどのように保護されるか、サーバー側でどの機能が有効かを確認する必要があります。

SOCKS5の仕様にUDP関連機能が含まれていても、すべてのサービス接続口やネットワーク経路で使えるとは限りません。サーバーの実装、アクセス方針、中間ネットワーク、クライアントの現在の設定が結果に影響します。TCPによるWeb閲覧は成功するのにUDPを使うアプリが失敗する場合は、まずサービスがUDPを許可しているか確認し、その後に転送経路を確認しましょう。プロトコル名がSOCKS5だからといって、失敗がプロトコルや接続口の機能に関係する可能性を排除しないでください。

項目が少なくても正確な照合が必要

HTTPとSOCKS5の接続でよく使われる項目はAddress、Port、およびサービスが求める場合のユーザー名とパスワードです。認証が必要かどうかは利用中の情報に従い、ユーザー名を空欄にすることと、任意の文字を入力することを同じ扱いにしないでください。認証情報に特殊文字が含まれる場合は、信頼できる読み込み方法を使うか、項目ごとに入力して、共有リンクを手作業で組み立てる際のエンコードミスを避けましょう。メモ名は端末内で接続を見分けるためのもので、認証項目の代わりにはなりません。

名前解決と実際の利用場面

リクエストにはドメイン名が含まれる場合もあれば、ローカルで名前解決した後のIPアドレスが含まれる場合もあります。これにより、名前解決が行われる場所や、その後のルール判定が変わります。「HTTP」または「SOCKS5」というラベルだけを見て、すべてのドメインが必ずリモート側で名前解決されると判断しないでください。トラブルシューティングでは、ShadowrocketのDNS設定、接続先へのリクエスト形式、有効なルールをあわせて確認します。同じ接続先がドメイン名では失敗し、既知のIPアドレスでは接続できる場合は、ユーザー名やポートをすぐに変更せず、名前解決の経路を調べましょう。

設定済みの社内プロキシ、テスト環境、または汎用プロキシ接続口が明示的に提供されている場面では、既存の環境との接続にこれらのタイプが役立ちます。ただし、他のプロトコルを何でも置き換えられるわけではありません。iPhone・iPadでの実際の動作は、認証、通信経路の保護、接続先への到達性、システムネットワークに左右されます。元のルーティング設定に戻す必要がある場合に備え、変更前のGlobal Routingの状態とConfigを記録してください。一度のテストが以降のすべてのアプリに影響するのを防げます。よくある操作上の問題はトラブルシューティングで症状別に確認できます。

06 · WireGuard：ピア、鍵、トンネルアドレス

プロキシリクエストからIP層トンネルへ

WireGuardはIP層のトンネル向けに設計されており、公開鍵でピアを識別し、ネットワークパケットをUDPにカプセル化して転送します。アドレスとパスワードだけを入力するプロキシ接続口とは異なり、トンネル内のアドレス、ピアの識別情報、処理を許可するアドレス範囲も設定する必要があります。これらを理解すると、設定情報がそろっているか判断できます。リモート側のIPとポートだけでは正しい接続関係を作れません。サーバー側でもクライアントの公開鍵を認識し、対応するアドレスと転送動作を設定する必要があります。

WireGuardをShadowrocketで使う際は、アプリがシステムの通信を取り込む仕組みと、リモート側のプロトコルをカプセル化する仕組みを区別してください。iOSにVPN関連の状態が表示されるのは、クライアントがシステムのネットワーク処理機能を利用していることを示します。すべての送信接続がWireGuardを通っているという意味ではありません。選択中のサーバータイプ、Global Routing、Configを確認してください。システムのVPNアイコンだけを見て、トンネル内のアドレスとリモート側のピアが正常に通信していると判断することもできません。

秘密鍵・公開鍵と任意の事前共有鍵

クライアントの秘密鍵は、この端末の識別と鍵交換に使用します。自分の端末やバックアップ内で安全に保管してください。サーバーの公開鍵はリモート側のピアを識別するためのものです。この2つの項目を逆にしたり、同じ値をすべての鍵欄に入力したりしないでください。クライアントの公開鍵は対応する秘密鍵から生成され、リモート側はその公開鍵でクライアントを識別します。クライアントの秘密鍵を変更してリモート側の設定を更新しなければ、Endpointが変わらなくても従来の認証関係が無効になることがあります。

サービスによっては、公開鍵の仕組みに共有情報を加えるための事前共有鍵を提供しています。これはクライアントの秘密鍵でもサーバーの公開鍵でもないため、案内に従って別々に入力してください。実際の鍵を公開スクリーンショット、エラーレポート、記事のコメントに貼り付けないでください。トラブルシューティングでは項目の有無や形式を説明できますが、元の値を公開してはいけません。端末移行の際は、バックアップファイルにこれらの機密情報が含まれる場合があるため、通常のルールファイルと同じように扱わないでください。

Endpoint、アドレス範囲、DNS

Endpointは、実際に到達できるリモート側のアドレスとUDPポートを指定します。トンネル内アドレスはトンネル内で使うネットワーク上の識別情報であり、異なる階層に属します。トンネル内アドレスをインターネット上の接続先として入力したり、Endpointをトンネル内アドレス欄に入力したりすると、接続が正しく動作しません。アドレス範囲の設定は、処理を許可する接続先アドレスやピアとの関係を表します。実際の役割はクライアントのルーティング連携の方式にも左右されるため、Shadowrocketのドメインルール一覧と単純に同じものと考えないでください。

IPv4とIPv6はそれぞれ確認する必要があります。一方のアドレスファミリーの経路を設定しても、もう一方も同じように接続できるとは限りません。ドメインの名前解決でIPv6が優先される一方、トンネルやリモート側の転送がIPv6に対応していないと、一部の接続先だけ失敗する場合があります。DNSサーバーに到達できるかも重要です。トンネル内のDNSアドレスを指定した場合は、既存のトンネルを通じて実際にアクセスできるか確認してください。設定情報にDNSの記載があるだけで、名前解決の経路が自動的に正常になるとは限りません。

Keepalive、MTU、モバイルネットワークの切り替え

Keepaliveは、中間機器がアイドル状態のUDPセッションを削除する環境などで、必要に応じてネットワーク上の対応関係を維持するために使われます。ただし、頻度を上げると無線通信の起動回数が増える場合があるため、「常時接続」を目的に間隔をむやみに短くしないでください。必要性と値は利用中のサービスの案内や実際のネットワークに基づいて判断します。モバイルネットワークを切り替えると、クライアントから見える外部アドレスも変わります。WireGuardは認証済みの通信後にピアのアドレス変更へ対応できる設計ですが、復旧には新しい経路でデータを転送できる必要があります。

MTUは1つのパケットで運べるデータ量に影響します。大きすぎると経路によってはフラグメント化やパケット損失が発生し、小さすぎるとカプセル化の割合とパケット数が増えます。小さなリクエストは成功するのに大きなページや継続転送が止まる場合、経路MTUを確認項目に加えることはできますが、あらゆるタイムアウトの原因と決めつけないでください。まず鍵とハンドシェイクを確認し、トンネル内アドレス、DNS、接続先への転送を検証してから、根拠に基づいてMTUを調整します。設定のバックアップと端末移行については設定移行ガイドをご覧ください。

07 · Hysteria2：QUIC、UDP経路、輻輳制御

設計の背景と互換性の範囲

Hysteria2はQUICベースのトランスポートを使用し、UDP経路に依存します。認証やTLS関連の仕組みと組み合わせてプロキシ通信を確立します。複雑な経路でのデータ転送と輻輳処理を考慮した設計ですが、どのネットワークでも速度が上がるとは限りません。まずUDP経路が利用できる必要があります。現在のネットワークからリモート側の該当ポートに到達できない場合、帯域幅の設定やパスワードを変更しても、この基本的な制限は解消できません。

Hysteria2の数字はプロトコル名の一部であり、このページで案内するShadowrocketアプリのバージョンではありません。読み込み時には、近い名前だけを見てタイプを選ばず、サービスの案内がHysteria2を明示しているか確認してください。プロトコルの世代、トランスポート形式、追加設定には互換性の制約がある場合があります。同じアドレスと認証情報が異なるタイプでも自動的に使えるとは限りません。現在のアプリに特定の追加項目があるかどうかは、実際の画面と利用中のサービスの案内で確認してください。

接続先・認証・証明書を個別に確認する

まずリモート側のAddressとUDPポートを確認し、次に認証情報とTLSのサーバー名を確認します。Addressは実際の通信接続口を指定します。SNIはサーバー名の通知と証明書検証に関わります。サービスの設定により異なる値を指定する場合がありますが、推測で入力しないでください。IPで接続しながらドメイン名の検証が必要な場合は、サービスが明示したドメイン名を使います。情報不足を補うために証明書検証を無効にしないでください。

接続情報に、難読化やその他の追加項目が含まれる場合があります。これらは認証パスワードの代わりではなく、常に有効にすべき設定でもありません。サーバー側に該当機能が設定されている場合のみ、クライアントにも一致する情報を入力してください。設定の不足、入力ミス、不要な有効化によって、認証段階に到達する前にパケットを正しく処理できなくなる場合があります。トラブルシューティングでは案内の各項目と照合し、認証・セキュリティ・追加設定を同時に変更して当てずっぽうに試さないでください。

帯域幅の入力で接続の実効性能が決まるわけではない

現在の設定に上り・下りの帯域幅や輻輳関連の項目がある場合、まず、それらはトランスポート制御に関する情報であり、サーバーの容量を保証するものではないと理解してください。帯域幅の推定を参照する制御方式もあれば、実装側が自動で判断する方式もあります。具体的な適用条件は該当設定の説明に従ってください。大きな数値を入力しても、無線の電波状況、サーバー側の回線、接続先の性能は向上しません。かえってパケット損失や待ち行列が増え、同じネットワーク上の他のタスクに影響する場合があります。

入力時はビットとバイトを区別し、画面で指定されている単位を確認してください。家庭向け回線の公称速度は、iPhoneの現在の無線接続で安定して使える速度とは異なり、モバイル通信の上り速度とも別です。信頼できる測定値がない場合は、一時的なピーク値を根拠にするのではなく、既存の案内値や明示された自動設定を優先してください。変更前後を比較する際は、瞬間的なピークだけでなく、タスクの完了時間、失敗率、他のアプリへの目立った影響も確認しましょう。

パケット損失、ネットワーク切り替え、バッテリーの確認

QUICはUDP上で接続と信頼性のある転送を管理し、データストリームごとの制御機構を備えていますが、物理経路のパケット損失をなくすことはできません。ネットワーク品質が低下すれば再送と輻輳制御が働き、無線状態が頻繁に変化すると、それまでの推定が当てはまらなくなることもあります。ネットワークによってUDPの扱いはTCPと異なるため、同じ端末でTCP方式の接続口が使えても、Hysteria2のUDP経路が使えるとは限りません。

iOSでは継続的な送信、再送、ネットワークの維持がバッテリーに影響する場合があります。継続転送中とアイドル時を分けて観察し、画面、バックグラウンド同期、端末温度の影響をできるだけ除いてください。Wi-Fiとモバイル通信を切り替えた後、QUICの一般的な機能だけを根拠にセッションが必ず継続すると考えることもできません。結果にはサーバーとクライアントの実装、新しい経路の状態が関係します。短時間の閲覧が主な用途で、現在の別の接続が安定しているなら、プロトコル名だけを理由に設定全体を変更する必要はありません。

同じネットワーク、同じ接続先、近い時間帯で基本的な接続を確認してから、複数回のタスク完了状況を比較してください。UDP接続口だけが失敗する場合は、まずポートへの到達性と経路に関する情報を集めます。すべての接続口が失敗する場合は、端末のネットワークと接続先を確認します。「トランスポートを確立できない」問題と「確立できたがタスクが遅い」問題を分けて対処すると、関係のない設定変更で原因を見失うのを防げます。

08 · プロトコルから実際のリクエストへ：確認・ルール・トラブルシューティング

再現可能な確認手順をまず整える

プロトコル設定を確認したら、Homeに戻って接続を検証する項目を選び、Global Routingを確認します。Configは現在の設定にあるルールに基づいて処理方針を決めます。Proxyは関連する通信を選択中のプロキシ経路に通すための設定です。Directは主に直接接続に使います。これらはルーティングの状態であり、リモート側のプロトコルの違いではありません。DirectでWebサイトが開いても、先ほど設定したTrojanやShadowsocksの接続を確認したことにはなりません。

テストの前に元の状態と現在のConfigを記録し、同じWebページを開いて最後まで読み込めるか確認するなど、明確なタスクを選びます。Connectivity Testは接続状態を把握する手がかりになりますが、テスト方法、接続先、その時点のネットワークに左右されるため、実際のタスクに代わるものではありません。システムの接続スイッチがオンでも、クライアントが通信を取り込んでいることを示すだけで、すべてのリクエストがリモート側を通って成功したとは限りません。「正しい接続を選択する」「リクエストが想定したルールを使う」「接続先にアクセスできる」の3点を確認してください。

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

Configのルールは上から順番に評価され、最初に一致したルールで処理方針が決まります。PROXYはプロキシ方針で処理し、DIRECTは直接接続、REJECTはリクエストを拒否します。プロトコル設定が正しくても、接続先がDIRECTに一致すれば想定したプロキシ経路を通りません。先にREJECTに一致した場合、後ろにPROXYがあっても処理は続きません。トラブルシューティングでは実際に一致したルールを確認し、すでに認証を通過している接続情報をすぐに変更しないでください。

以下はルールの順序を説明するためのShadowrocket .confの例で、サーバー情報は含みません。例外ドメインを範囲ルールより前に置き、プライベートアドレス範囲はDIRECTにし、最後にFINALでそれ以前のルールに一致しなかったリクエストを処理します。例のドメインは説明用であり、実際のサービスを示すものではありません。すべての環境に適した完全な設定として、そのまま使わないでください。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

DOMAIN-SUFFIXを先に置くと、ads.example.comが範囲ルールに先に一致し、その後の個別の拒否ルールは適用されません。IPルールが判定に使われるかどうかは、リクエストで利用できるアドレス情報や名前解決の動作にも左右されます。ルールの記述だけを見て、すべてのドメインが特定のアドレス範囲に一致すると推測しないでください。ルールの並べ方はルールの順序とFINALの解説で確認できます。初回設定はクイックスタートガイドを基本に進めてください。

問題の階層に応じて次に確認する項目を選ぶ

一度に変更するのは1項目だけにし、変更前後の具体的な結果を記録してください。Subscribeの更新後に設定が変わった場合は、想定した接続口が現在選択されているかを確認します。手動で作成したコピーがサブスクリプションの更新に追従するとは限りません。問題を報告する際は、プロトコル名、エラーが発生した段階、ネットワークの種類、機密情報を伏せた設定項目の構成を共有できます。ただし、完全なサブスクリプションURL、Password、UUID、秘密鍵などは必ず削除してください。ログにアクセス先が含まれる場合もあるため、共有前に確認しましょう。

実際のタスクをもとに最終的な接続を選ぶ

既存の汎用プロキシ環境と接続する場合は、HTTPまたはSOCKS5の認証、通信経路の保護、必要な機能を確認します。Shadowsocks、VMess、VLESS、Trojanの接続口を利用する場合は、方式、トランスポート、TLSの設定が一致しているかを重点的に確認してください。WireGuardの情報がある場合は、ピア、トンネル内アドレス、許可範囲を確認します。Hysteria2の接続口を利用する場合は、UDP経路と制御項目を優先して確認してください。これらは確認ポイントであり、性能ランキングではありません。

最終的に使う接続は、設定情報がそろい、サーバー認証を想定どおり確認でき、普段のタスクを繰り返し完了でき、実際のネットワーク切り替えや待機時にも許容できる動作をするものを選びます。1回のテストで数字を小さくするために、正しい証明書検証を犠牲にしたり、安定している設定を何度も変更したりしないでください。アプリの購入、システム互換性、再入手についてはApp Storeでの正規版入手ガイドをご覧ください。接続時の症状や画面操作はトラブルシューティングで確認できます。このページでは判断の根拠を説明し、チュートリアルではその判断を初回設定の手順としてまとめています。