Shadowrocketのプロトコル解説

01 / Model

プロトコルの階層と選定の前提

プロトコル名だけでは接続全体を表せない

Add ServerでTypeを選ぶのは、クライアントがサーバーとどの形式で通信するかを指定する操作です。同じ接続の性能モードを切り替えるものではありません。サーバーがShadowsocksを提供している場合、クライアント側をVLESSに変更しただけで別のプロトコルが使えるわけではありません。プロトコル、ポート、認証情報、外側の通信方式がクライアントとサーバーで一致している必要があります。サブスクリプションの読み込みでは通常これらの情報も取り込まれますが、読み込みに成功したことは、接続先の設定が現在も有効であることや、利用中のネットワークから該当ポートに到達できることを意味しません。

接続は、宛先へのリクエスト、プロキシプロトコル、通信を運ぶ方式、実際のネットワーク経路に分けて考えられます。リクエストは接続先のドメインとポートを示し、プロキシプロトコルはリクエストや認証情報を表現します。一部のプロトコルは暗号化も担います。通信を運ぶ方式は、TCP、UDP、TLSなどを通じてデータを伝送します。実際の経路には、無線接続、通信事業者のネットワーク、サーバーへの接続、サーバーから宛先までの経路が含まれます。いずれかの階層に問題があっても、プロトコル名だけが原因とは限りません。切り分けでは、この流れに沿って確認範囲を絞ります。

認証・暗号化・ルーティングは別の問題

パスワード、UUID、鍵はいずれも本人確認に使われることがありますが、それぞれ意味が異なります。UUIDはドメイン名ではなく、WireGuardのPublic Keyもパスワード欄に入力する代替文字列ではありません。暗号化は通信内容を保護し、認証は通信相手や利用者を識別します。同じ仕組みが両方を担う場合もあれば、別々の階層に分かれている場合もあります。TLSの証明書検証はサーバーの身元確認の一部です。アカウント情報が正しいからといって省略できるものではありません。似た名前の項目でも、対応関係はサービス提供元のプロトコル説明に従ってください。

Global Routingは、これらとは別の判断軸です。Configは現在の設定に基づいて通信を振り分け、Proxyはプロキシポリシーに通信を渡し、Directは直接接続します。これらの切り替えで、サーバーのプロトコルが別のものに変わるわけではありません。正しいTypeを選んだうえで、リクエストが想定したポリシーに適用されていることも確認してください。DIRECTが適用されているだけでアクセスに成功したり、利用できない接続先をルールが選んで失敗したりすることもあります。用語の意味は用語集で確認できます。モードの切り替えをプロトコルの調整と混同しないようにしましょう。

実際に利用できる機能の範囲で選ぶ

選定の出発点は、プロトコル一覧で新しそうに見える名称ではなく、サーバーが実際に提供している機能です。利用可能な種類、UDP対応の有無、認証方式、必要な通信方式を記録し、クライアントに対応する項目があるか確認しましょう。同じプロトコルでも機能の組み合わせは異なります。項目が見つからない場合、別の欄に適当な値を入力して解決しようとしないでください。サブスクリプションの内容と手動の説明が食い違う場合は、ご利用のサービス提供元に現在有効な設定を確認します。不明な拡張項目は変更せず、複数の条件を一度に変えて再現可能な基準を失わないようにしましょう。

ShadowrocketはAppleプラットフォーム向けの有料アプリです。入手方法とシステム要件はApp Storeの掲載内容をご確認ください。購入先の確認にはApp Storeで正規品を確認する方法をご覧ください。アプリの買い切り購入とサーバーの利用プランは別です。アプリを購入しても、サーバーアドレス、認証情報、サブスクリプションは提供されません。この点を踏まえ、本ページでは手元にある情報に合った接続方式を選び、現在のネットワークに適しているかを実測で判断します。どの環境でも特定のプロトコルが速いと保証するものではありません。

02 / Shadowsocks

Shadowsocks：共有鍵と軽量な通信方式

設計上の特徴と適用範囲

Shadowsocksは、比較的シンプルな方法でプロキシリクエストを転送する設計です。一般的な構成では、共有パスワードと指定された暗号化方式を使います。クライアントが宛先を指定し、プロトコルに従ってデータを包んでサーバーに送信します。サーバーはその先の接続を確立します。完全な仮想ネットワークを主な前提としていないため、遠隔地のネットワークインターフェースというより、「特定のリクエストをどう転送するか」という視点で捉えると理解しやすくなります。実装や暗号化方式によって細部は異なるため、Shadowsocksと表示された設定がすべて同じとは限りません。

現在の構成では、機密性と完全性の検証を同時に行うAEAD暗号化方式がよく使われます。新しいプロトコルのバリエーションでは、鍵の形式、セッションの扱い、リプレイ攻撃への対策がさらに定められている場合もあります。重要なのは名称の長さではなく、クライアントで選択する方式をサーバーの設定と一字一句一致させることです。共有パスワードも、どのような文字列でもよいとは限りません。方式によっては、規定の長さや形式を満たす鍵が必要です。以前の設定のパスワードを別の方式にそのまま移し、サーバーが自動的に対応すると考えないでください。

印象で入力せず、項目ごとに確認

Add Serverでは、まずAddressとPortがサーバーの実際の待ち受け先を指していることを確認し、次にMethodとPasswordを照合します。Addressにはドメイン名やアドレスを指定できますが、名前解決の結果が正しいサーバーに到達する必要があります。Portはサーバーの待ち受けポートであり、Webサイトへのアクセスで使われる標準ポートとは限りません。Methodは端末側の安全性を調整するスライダーではなく、通信相手と共有するプロトコル設定の一部です。Passwordの大文字・小文字、末尾の空白、コピー時に混入した改行も認証失敗の原因になります。変更前の設定を保存し、情報の提供元と一つずつ照合してください。

既存の設定に追加の通信パラメーターが含まれている場合、それらも接続方式の一部として扱います。プロトコル本体と追加のカプセル化は別のものです。外側の方式を追加すると、ハンドシェイク、ドメイン名の要件、ネットワークへの適応性が変わり、切り分け項目も増えることがあります。サーバーが明確に指定し、現在のクライアントが対応している場合に限って設定してください。手動で作成した設定では接続できず、同じ提供元から読み込んだ設定なら使える場合は、まず両者の項目を比較します。先に暗号化方式を切り替えたり、意味の分からない項目を削除したりしないでください。

速度、電池消費、よくある接続失敗

iPhoneでは、カプセル化の層が少ないほど問題を切り分けやすい傾向がありますが、消費電力が少ないとは限りません。暗号化処理は電力消費の一部にすぎず、画面、無線電波、再送、バックグラウンド動作の影響がより大きい場合もあります。最近の端末では一部の暗号化アルゴリズムを効率よく処理できますが、実際の通信速度はサーバーの負荷やネットワークの混雑にも左右されます。Web閲覧や短い接続が中心なら、最初のリクエストがすぐ完了するかを確認します。長時間の通信が中心なら、安定時のスループットや端末の温度変化も観察してください。

TCPのリクエストは使えるのにUDPを使うサービスで問題が起きる場合は、クライアントの設定、サーバーの対応状況、利用中のネットワークからUDPに到達できるかをそれぞれ確認します。Webページが開いたことだけで、すべての通信が正常だとは判断できません。ドメイン名では接続できない一方、宛先アドレスを直接指定すると応答がある場合は、DNSの処理場所や名前解決結果の違いも考えられます。接続後に停止する場合は、リクエスト送信時、応答受信時、継続通信中のどの段階で起きるか記録し、同じネットワークで再確認してください。現象を分けて考えるほうが、Methodを何度も変更するより原因を特定しやすくなります。

03 / VMess · VLESS

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

2つの設計における役割の違い

VMessはユーザーの識別、リクエストのカプセル化、関連するセキュリティ機能をプロトコル内で扱います。一般的な設定では、UUIDをユーザー識別子として使います。初期のプロキシプロトコルの発展過程では、ユーザー識別と接続処理の方法が重視され、その後、認証形式にも複数のバリエーションが登場しました。利用者にとって大切なのは、古い説明から互換性のある設定を推測することではなく、サーバーが現在採用している組み合わせを確認することです。サブスクリプションに含まれる追加項目は、過去との互換性や特定の実装に関係している場合があります。提供元の値を優先してください。

VLESSはプロトコルの役割をよりシンプルに設計しており、基本プロトコル自体は通信内容を暗号化しません。適切なセキュリティを備えた通信方式と組み合わせる必要があります。認証情報は引き続き必要ですが、UUIDがあるだけで通信内容も暗号化されているとは限りません。どの仕組みで保護されているかを判断するには、TLSまたはサーバーが指定する別のセキュリティ機構が外側で使われているか確認してください。同じ名前の認証欄が画面にあっても、VMessとVLESSは互換ではありません。ハンドシェイクとカプセル化の方法が異なるため、選択した種類をサーバーがサポートしている必要があります。

設定項目の対応関係を確認する

UUIDは引用符や説明文、余計な区切り文字を加えずにそのままコピーしてください。サーバーアドレスとTLSのServer Nameは異なる場合があります。前者は接続先を指定し、後者はTLSハンドシェイクで提示する名前や証明書の検証に使われます。提供元が異なる値を指定している場合は、それぞれ対応する項目に入力してください。指定がなければ、別のアクセス可能なドメイン名で置き換えないでください。端末の日時も確認しましょう。時刻が誤っていると証明書の有効期間を正しく判定できず、時刻に依存する認証にも影響することがあります。

通信方式の設定によって、プロトコルのリクエストをどう運ぶかが決まります。WebSocketを使用する場合、Pathはサーバー側で入口を識別するパスで、Hostは外側のリクエストのルーティングに使われることがあります。どちらもメモ欄ではありません。スラッシュ、大文字・小文字、パスの接頭辞が結果に影響することがあります。同じアドレス上の複数サービスをリバースプロキシで振り分ける構成では、ポートに到達してもパスが一致しなければ、プロトコルのハンドシェイクではなくWebページが返る場合があります。その場合、UUIDを調整するのではなく、まず通信方式と入口の項目を確認してください。

拡張項目を単独で流用しない

一部のVLESS設定にはFlowなどの追加項目や、セキュリティハンドシェイクの設定が含まれます。これらは特定の接続構成に必要な項目であり、汎用的な高速化スイッチではありません。サーバー側で利用できる組み合わせでも、現在のクライアントが必要な機能をすべて備えているとは限りません。Add Serverで使用できる項目と提供元の説明を確認してください。必要な設定が見つからない場合は、互換性を先に確認し、値をメモ欄や似た名前の別項目に入力しないでください。読み込み後も設定を開き、重要な項目が正しく認識されているか確認しましょう。項目名だけが保存されている可能性もあります。

速度については、追加のハンドシェイクや通信のカプセル化により、最初のリクエストに時間がかかることがあります。一方、安定した接続が確立すれば、ボトルネックはネットワークやサーバーに移ることがあります。WebSocketが他の通信方式より常に速いわけではなく、VLESSの設計がシンプルだからといってVMessより電池を節約できるとも限りません。電波が弱い状態で再接続を繰り返す影響は、2つのプロトコル間の処理負荷の差より大きい場合があります。比較するときは同じネットワーク、近い条件の宛先、同じ用途を使い、接続直後と継続利用を分けて記録してください。一度のConnectivity Testだけで結論を出さないようにしましょう。

問題の切り分けは、「アドレスとポート、外側のハンドシェイク、通信の入口、認証、宛先へのアクセス」の順に進めます。外側の証明書エラーは端末の時刻とServer Nameを確認します。通常のWebページは表示されてもプロキシとして使えない場合は、入口のパスを確認します。接続後に特定のサービスだけ失敗する場合は、UDP対応とルーティングを確認してください。長時間使わなかった後の最初のリクエストだけ遅い場合は、接続が再確立されたかも記録しましょう。設定項目以外のよくある現象についてはトラブルシューティングをご覧ください。前段のエラーを隠すために証明書検証を無効にしないでください。

04 / TLS · Proxy

Trojan、HTTP、SOCKS5

TrojanはTLSで通信を保護する

Trojanは一般に、最初にTLS接続を確立し、その保護された通信路で認証とリクエストの転送を行います。設定項目が多層構成より少なく見える場合でも、TLSの認証要件は変わりません。サーバー証明書、接続先アドレス、Server Nameが適切に対応している必要があります。パスワードが正しくても、証明書名の誤りは解消されません。「TLSが成功したか」と「プロトコル認証が成功したか」に分けて考えると、すべてをパスワードの誤りとして扱うより原因を特定しやすくなります。

Addressはサーバーのアドレスを指定し、Server Nameはサーバーの要件と証明書に合った値を指定します。アドレスを直接指定して接続する場合でも、TLS検証用のドメイン名が別途必要なことがあります。証明書の期限切れ、証明書チェーンの不備、端末の日時の誤り、名前の不一致は、いずれもハンドシェイクを妨げる原因になります。検証を無効にすると、通信相手の確認が弱まるため、日常的な対処法として使わないでください。サーバーに特別な信頼設定がある場合は、明確な管理者の案内に従い、公共のネットワークで一時的に検証を切って接続することは避けてください。

HTTPとSOCKS5の基本的な役割

HTTPプロキシはアプリケーション層でのプロキシ利用を想定したもので、一般的なCONNECTメソッドでは、プロキシに宛先までの通信路を確立するよう要求します。名称にHTTPとあっても、クライアントとプロキシの間でTLSが使われるとは限りません。HTTPSサイトへのアクセスでは、宛先とのTLSとプロキシまでの通信保護は別のものです。宛先が暗号化されていても、どの設定でもプロキシ認証情報が同じように保護されるわけではありません。通常のHTTPプロキシと、TLSを使ってプロキシに接続する構成を区別し、サーバーの実際の機能に合わせて設定してください。

SOCKS5は汎用性の高いリクエスト形式を使い、宛先アドレスとポートを指定できます。また、認証やUDPアソシエーションなどの仕組みも定義されています。ただし、プロトコル自体が汎用的な通信内容の暗号化を保証するわけではありません。ユーザー名とパスワードによる認証も、通信の暗号化と同じではありません。信頼できるネットワーク内、または別途保護手段が明確に用意された環境での利用が想定されます。選択前に、クライアントからサーバーまでのデータを何が保護するのか確認してください。UDPへの対応も、規格で許可されていることだけでは判断できません。サーバーの実装、認証方式、クライアントが対応する組み合わせを個別に確認する必要があります。

プロキシ認証と宛先の認証を混同しない

プロキシのユーザー名とパスワードは、プロキシサービスへの接続に使うもので、接続先Webサイトのアカウント情報ではありません。接続先で認証が必要な場合、情報が空欄だと拒否されることがあります。サーバー側で認証が無効なら、適当なアカウント情報を入力しても保護は強化されません。認証エラーが返された場合は、その応答がプロキシとWebサイトのどちらから来たのか確認してください。一般的なWebページは開けても一部のアプリが失敗する場合、アプリのリクエスト方式、宛先ポート、UDPの必要性、ルールが原因のこともあります。ユーザー名とパスワードが一部のサイトだけに適用されるとは限りません。

iPhoneでの実際の消費電力は、これらのプロトコルではハンドシェイクの回数、接続の再利用、無線通信の状況によって変わります。TLSの確立には追加の処理と通信の往復が必要ですが、確立後はその接続を後続のリクエストに利用できます。頻繁に切断して再接続するほうが、適切に接続を維持するより電力を使うこともあります。一方、接続維持のために無線通信を頻繁に起こすことにもコストがあります。「TLSを使うから電池を多く消費する」とは限りません。また、暗号化のない方式を安易に選ぶのではなく、まず安全性と互換性の条件を満たしてください。

トラブルシューティングでは、まずサーバーがどのプロキシ方式を提供しているかを確認し、TLS、認証、UDPが必要かを調べます。Trojanの証明書エラーはTLSの問題として確認します。HTTPプロキシから拒否された場合は、認証やCONNECTの利用許可を確認します。SOCKS5でセッションを確立できても特定のサービスが使えない場合は、コマンド対応やデータグラムの経路を確認してください。職場などのネットワークに既存のプロキシがある場合は、ネットワーク管理上のルールに従い、認証方式や宛先ポートの制限を勝手に変更しないでください。性能テストは許可された範囲で行い、利用権限の制限をプロトコルの速度問題と誤認しないようにしましょう。

05 / WireGuard

WireGuard：鍵、アドレス、トンネルルーティング

個々のリクエストではなく仮想ネットワークとして考える

WireGuardは暗号化されたレイヤー3トンネルを基本とし、これまでのように宛先へのリクエストごとにプロキシセッションを作る方式とは異なります。公開鍵と秘密鍵で通信相手を識別し、UDPでカプセル化したネットワークパケットを送ります。プロトコルの構成要素を絞り、暗号方式を多数の候補からユーザーが個別に選ばなくてよい設計です。クライアントで選択する暗号方式が少ない一方、鍵の所有者、トンネルアドレス、接続先のEndpoint、ルーティング範囲が重要になります。どの項目に誤りがあっても、最終的な通信に影響することがあります。

Private Keyは端末側の身元を示す情報なので、秘密に保ってください。Public Keyは対応する相手を識別するために使います。設定を入力するときは、元の設定における「自分側」と「相手側」がそれぞれ誰なのかを確認してください。サーバーのPublic Keyを端末のPrivate Key欄に入力してはいけません。任意のPreshared Keyは追加の共有情報であり、公開鍵・秘密鍵の代わりとなる通常のパスワードではありません。設定やサブスクリプションに情報が記載されている場合は、そのまま保持してください。問題の調査記録を共有するときは、秘密鍵などの認証情報を削除します。サーバー名を隠すだけでは不十分です。

Endpoint、Address、Allowed IPs

Endpointは相手に到達するためのアドレスとUDPポートです。トンネルのAddressは、端末がトンネル内部で使うアドレスであり、別のネットワーク階層に属します。公開サーバーのアドレスをトンネルアドレス欄に入力したり、トンネル内部のアドレスをEndpointとして使ったりすると、接続できない場合があります。Endpointにドメイン名を使う場合、トンネルの起動前に名前解決できる経路も必要です。有効にした直後にEndpointを名前解決できない場合は、鍵を調整する前に、名前解決が依存関係のループを起こしていないか確認してください。

Allowed IPsは相手に関連するアドレス範囲を表し、WireGuardではルーティング先の選択と受信元アドレスの検証にも関わります。Webサイトの許可リストではなく、範囲を広げれば接続しやすくなるというものでもありません。これらの範囲をクライアントのポリシーとどう組み合わせるかは、現在の設定に基づいて確認してください。範囲が狭すぎると必要な通信先が含まれず、広すぎると関係のない通信までトンネルに入る可能性があります。トンネルのハンドシェイクが成功していても、サーバーが必要な転送機能を提供していなければ、宛先にはアクセスできません。

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

モバイル端末がWi-Fiとモバイルネットワークを切り替えると、外部アドレスやNATマッピングが変わることがあります。WireGuardは認証済みのパケットを受信すると、相手のEndpoint情報を更新できる設計ですが、すべての切り替えが瞬時に完了するわけではありません。新しいネットワークがUDP通信を許可し、サーバーが有効な通信を受信できる必要があります。長時間使わなかった後に最初のアクセスが遅い場合、NATマッピングの期限切れや通信の再確立が関係していることがあります。継続利用、アイドル状態からの復帰、ネットワーク切り替え後の復帰を別々に記録し、一つの安定性評価にまとめないでください。

Persistent Keepaliveは必要に応じてネットワークのマッピングを維持しますが、定期的なデータ送信を伴います。送信間隔は短ければよいというものではなく、すべての設定に同じ値を適用すべきでもありません。モバイル回線の電波が弱い場所では、小さなパケットでも無線通信を発生させ、待機中の電力消費に影響する場合があります。外部からの接続を維持する必要がなければ、追加のKeepaliveが役立つとは限りません。サーバーの要件と実際のネットワークに合わせて設定し、同じ時間だけアイドル状態にした後の復帰を比較してください。設定を有効にした直後の電池消費だけで判断しないようにしましょう。

ハンドシェイクは正常でも一部のページが止まる場合は、ルーティング、DNS、MTUを確認してください。トンネルのカプセル化はデータ量を増やすため、経路が大きなパケットを適切に扱えないと、小さなリクエストは成功しても大きな応答が停止することがあります。MTUを調整する場合は、元の値を記録して少しずつ検証しましょう。経験則で極端な値を設定すると、通信速度が低下する可能性があります。WireGuardは、完全なトンネル設定があり、アドレス層での接続が必要な場面に適しています。別のプロトコルのサーバー情報しかない場合、鍵のペアを独自に作成してもWireGuardのサービスに変換できるわけではありません。

06 / Hysteria2

Hysteria2：QUICとパケットロスのある通信経路

QUICはどの層を変えるのか

Hysteria2はQUICを基盤にしたプロキシ通信方式です。QUICは通常UDP上で動作し、セキュアなハンドシェイク、ストリーム管理、輻輳制御を組み合わせています。利点を理解するには、実際の通信環境を考える必要があります。往復遅延が大きい場合、パケットロスがある場合、利用可能な帯域が変動する場合、トランスポート層の復旧方法や送信タイミングが使い心地に大きく影響します。TCPのデータを単にUDPに載せ替えれば自動的に速くなるわけではなく、物理的な帯域の制限を超えられるわけでもありません。サーバーへの接続、無線品質、宛先からの応答が引き続き上限になります。

複数の通信を1つのTCP接続で多重化する方式では、基盤となるデータの損失が後続データの受け渡しに影響することがあります。QUICのストリーム機構は、信頼性のある通信で順序を保つために生じるストリーム間のブロッキングを減らせます。ただし、信頼性が必要な個々のストリームでは引き続きデータの復旧が必要であり、輻輳制御も共有接続に影響します。アプリ自体が信頼性のある通信を必要とする場合は、カプセル化後に複数層の制御が働くこともあります。「QUICベース」だからパケットロスの影響がなくなるわけではなく、プロトコルの説明だけで特定のページの読み込み時間を予測することもできません。

認証、証明書、帯域幅の設定

手動で確認する場合は、まずAddress、Port、認証文字列、TLSのServer Nameを確認してください。Hysteria2に対応するプロトコルをサーバーが実際に提供している必要があります。名前が似ている別の設定をそのまま使うことはできません。証明書の検証も重要です。証明書名の誤り、期限切れ、端末の日時の異常は接続に影響します。提供元がobfuscationなどの追加項目を指定している場合は、クライアントとサーバーの両方で有効になり、設定値も一致しているか確認してください。これらはパスワードの代わりになる欄ではありません。設定の漏れや不一致があると、認証に進む前に通信が想定と異なることがあります。

設定によっては、輻輳制御の動作に使用する上り・下り帯域幅を指定できます。この値は通信制御への入力であり、速度制限を解除した後の目標値を保証するものではありません。実際の回線を大きく上回る値を設定すると、混雑、パケットロス、再送が続き、ほかのアプリの使い心地まで悪化することがあります。輻輳制御の方式によって値の扱いは異なるため、提供元の説明とクライアントで選択できる項目を確認してください。初回のテストでは、控えめで根拠を説明できる設定から始め、継続して観察したうえで変更が必要か判断しましょう。

UDPに到達できることは前提条件であり、成功を保証するものではない

ネットワークによってはUDPが制限され、通信品質が不安定になったり、TCPとは異なる扱いを受けたりします。同じ場所で通常のWebページを直接開けても、QUICの経路が使えるとは限りません。ポートから明確なエラーが返らなくても、プロトコルのハンドシェイクが完了したとは言えません。Hysteria2が特定のWi-Fiでだけ失敗する場合は、まず手元にある別の利用可能な種類と経路を比較し、サーバーにリクエストが届いているか確認します。認証、Server Name、帯域幅の設定を同時に変更すると、ネットワークの制限と設定ミスを区別できなくなります。

iPhoneでは、スループットが高いと無線通信とプロセッサーが活発に動作し、消費電力が増えることがあります。一方、同じタスクを短時間で終えれば、端末が動作する時間も短くなる場合があります。そのため、通信中の温度だけでなく、タスク完了後の総消費電力とアイドル状態に戻るまでの時間も比較してください。パケットロスが多い環境では、積極的な送信制御がスループットを改善する一方、消費電力を増やすこともあります。結論はテストした端末、ネットワーク、用途の範囲に限ってください。「Hysteria2は常に電池を多く消費する」「QUICなら必ず省電力」と一般化することはできません。

Hysteria2を試す前提は、利用可能なHysteria2サーバーがあり、現在のネットワークでUDP通信が安定し、高遅延やパケットロスが実際の課題になっていることです。ネットワークが安定し、短いリクエストが中心なら、継続的な通信ほど効果を感じられないことがあります。詳しい仕組みはHysteria2とQUICの技術解説をご覧ください。テスト中に断続的な停止が起きた場合は、ネットワークの種類、切り替えの有無、アイドル状態から復帰した直後かどうかを記録し、パケットロス、輻輳、サーバー負荷を確認してください。帯域幅の設定不足だけが原因と決めつけないようにしましょう。

07 / Measurement

iOSで速度と電池消費を検証する

まず測定するタスクを決める

「速い」には、最初の応答、継続的なスループット、操作中の安定性という少なくとも3つの要素があります。最初の応答は新しいページを開くまでの待ち時間に、継続的なスループットは大容量データの転送に、操作中の安定性はリアルタイム通信や短いリクエストの停止頻度に関わります。Connectivity Testの結果が示すのは、テスト方法に含まれる通信経路の一部だけです。すべての宛先、UDP通信、長時間の使用を代表するものではありません。比較を始める前に、同じページを続けて閲覧する、同じテスト用データを転送するなど、測定するタスクを決めましょう。操作が毎回異なる状態で感覚だけを比較しないでください。

プロトコルの違いだけを比較する理想的な条件は、サーバーの場所、リソース、サーバーから宛先までの経路が近いことです。異なるサーバーを使う2つの設定で差が出た場合、それは接続方式全体の差であり、厳密にプロトコルだけが原因とは言えません。同じアドレスでも、入口ごとにサーバー側のリソース配分が異なる可能性があります。条件をそろえられない場合でも、実用上の選択はできます。ただし、「この設定は現在のネットワークに適している」と表現し、特定のプロトコルが常に高性能だと結論づけないようにしましょう。

再現できる測定手順を作る

同じ端末、ネットワーク、場所、なるべく近い時間帯を使い、結果に大きく影響するバックグラウンド通信を一時停止します。まず基本のネットワークが正常か確認し、次に一つの設定でタスクを完了してから、別の設定に切り替えて同じテストを行います。テスト順を入れ替えると、時間の経過に伴うネットワークの変化による偏りを減らせます。各条件で複数回測定し、最速の値だけではなく結果の幅を記録してください。接続直後と接続が温まった状態も分けて測ります。前者には名前解決とハンドシェイクが含まれ、後者は接続の再利用やキャッシュの影響を受けるため、同じ列にまとめて平均しないでください。

Wi-Fiとモバイルネットワークは別々に記録してください。移動中は電波の変化が判断を妨げやすくなります。テスト中に場所を移動しながら設定も変更しないでください。ネットワーク切り替え後の復帰を検証する場合は、それを独立したタスクとして扱い、切り替え後にリクエストが再開するまでの時間と手動再接続の要否を記録します。まれな失敗が起きても、すぐ複数の項目を変えず、元の条件で再度試してください。ときどき高いピークが出ても頻繁に止まる設定より、数回続けて安定して完了できる設定のほうが、日常利用に適しています。

電力比較では動作中と待機中を分ける

バッテリー残量のパーセント表示は大まかな値です。数分間のわずかな変化だけでプロトコルの差を証明することはできません。画面の明るさ、端末の温度、電波強度、バックグラウンドアプリがプロトコルによる負荷を上回ることもあります。動作中の消費電力を比較するときは、画面とタスクをそろえ、同じ作業を完了するまでの全体的な消費を確認してください。待機中を比べる場合は、アイドル時間とネットワーク環境をそろえ、継続的な通信や頻繁な復帰がないかを観察します。一方の設定では長時間の動画再生を行い、もう一方では待機させた状態を比べて、どちらが省電力かを判断しないでください。

システムのバッテリー統計やShadowrocketのData表示は参考になりますが、集計方法はそれぞれ異なります。通信量のバイト数から消費電力を直接計算することはできません。また、システム上の拡張機能やアプリの活動の分類が、特定のプロトコルの負荷を正確に示すとは限りません。異常に気づいたら、大量の再試行、定期的なリクエスト、Keepalive、頻繁な切断がないかを確認し、次にOn Demandの発動条件を調べましょう。用途に合った自動接続設定は役立ちますが、ルールが複雑なほど省電力になるわけではありません。実際の動作を検証してください。

問題の調査記録には、ネットワークの種類、プロトコルの種類、発生した時間帯、リクエストの段階、対処結果など、必要な情報だけを残してください。ログを共有する前に、サブスクリプションのURL、認証情報、アクセス先のドメイン、個人のネットワーク情報が含まれていないか確認します。サブスクリプションのリンクはアクセス用の認証情報として扱われる場合があるため、そのまま貼り付けないでください。複数の設定を整理する方法は複数のサブスクリプションを分類・整理する方法をご覧ください。まずテスト対象のサーバーが特定できていることを確認してから性能を比較しましょう。設定名が重複していると、気づかないうちに比較対象が変わることがあります。

08 / Decision

用途に応じた選び方と最終確認

まず条件を満たさない組み合わせを除外する

選ぶ順序は、利用可能か、安全性の条件を満たすか、用途に対応するかを確認したうえで、速度と電池消費を比較します。利用中のサーバーが実際に対応している種類を一覧にし、現在のネットワークで使えないものや、クライアントに必要な設定項目がないものを除外してください。次に認証と証明書検証が正しく行われること、利用するサービスがUDPやトンネル内部のアドレスを必要とするかを確認します。これらの条件を満たして初めて速度比較に意味が生まれます。設定項目が少ないから信頼性が高いとは限らず、複雑な構成だから安全とも限りません。各階層の役割を説明でき、正しく検証できることが重要です。

日常的なWeb閲覧や一般的なアプリの利用では、設定の情報源が明確で、すでに安定して使えている方式を維持しましょう。プロトコル名が変わっただけで、すべての設定を作り直す必要はありません。アドレス層のトンネルや特定の内部ネットワークが必要な場合は、完全なWireGuard設定が用途に合います。パケットロスや遅延が多い環境では、利用可能なHysteria2サーバーを候補として実測できます。HTTPまたはSOCKS5の情報だけをお持ちの場合は、通信経路の保護と対応する用途を理解してから使ってください。名称がシンプルだからといって、あらゆる重要な通信に適するとは限りません。

プロトコルの検証とルールの確認をつなげる

読み込み後、Homeで選択中のサーバーを確認し、次にGlobal Routingを確認します。一時的にProxyを使うと、問題の一部が振り分けに由来するかを判断しやすくなりますが、最終的なConfigの確認は省略できません。Configに戻り、想定したファイルが有効になっていることと、宛先へのリクエストに最終的にどのポリシーが適用されるかを確認してください。ルールは上から順に評価され、最初に一致した項目で処理が決まります。先に広い範囲のルールが一致すると、後続の詳細なルールは評価されません。プロトコルが利用可能かどうかと、ルールが正しいかどうかは別々に確認する必要があります。

以下はShadowrocketのテキスト形式の設定におけるルール例です。ルールの役割を説明するものであり、サーバー設定ではありません。既存の完成済みファイルをそのまま置き換えないでください。例のドメイン名は説明用で、PROXY、DIRECT、REJECTはそれぞれ異なる処理を示します。IP-CIDRはLANのアドレス範囲を表し、FINALはそれ以前のルールに一致しなかった通信を処理します。これらの例を使う前に、既存の設定で指定されているポリシーが実際の用途に合っているか確認してください。プロキシ接続の失敗を隠すためにDIRECTの範囲をむやみに広げたり、すべてのローカル通信を遠隔地に送ったりしないでください。

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

最後にDNSも確認してください。ドメインルールとアドレスルールでは参照する情報が異なります。名前解決の結果、キャッシュ、IPv4・IPv6への到達性によって、ルールの適用結果が変わることがあります。特定のドメインがときどき別のアドレスに向かっても、プロトコル設定が変化したとは限りません。ログに記録されたドメイン名またはアドレス、実際に一致したルール、適用されたポリシーを確認してから、ルールの変更が必要か判断してください。詳しい順序はルールの優先順位とFINALによるフォールバックをご覧ください。プロトコル解説の接続テストを、ルール設定の手順と混同しないようにしましょう。

元に戻せる日常用の設定を整える

最終的には、検証済みの基準となる設定を一つ維持します。プロトコルの種類と主要な設定項目の情報源が明確で、日常的な宛先にアクセスでき、アイドル状態やネットワーク切り替え後も想定どおりに復帰できることが基準です。新しい方式を試すときは設定を複製し、分かりやすい名前を付けてください。唯一使える設定を直接上書きしないようにしましょう。サブスクリプションを更新した後は、選択中の設定を再確認してください。サーバーのアドレスや項目が変更される場合があり、同じ名前の設定を誤って選ぶこともあります。機種変更の前に必要な設定をバックアップし、復元後は利用権限、現在のConfig、実際に適用されるポリシーを再検証してください。アプリの購入履歴と一緒にすべてのローカル状態が復元されるとは限りません。

原因を特定できない場合は、「基本のネットワークは正常か、接続先に到達できるか、TLSは成功したか、認証は通ったか、宛先に想定したポリシーが適用されたか」の順に整理してから、トラブルシューティングをご覧ください。読み込みや初回接続からやり直す場合は、使い方ガイドに戻ってください。最終的に目指すのは、説明でき、再検証でき、元に戻せる設定です。ネットワーク条件を無視したプロトコルのランキングではありません。クライアントとシステム要件はApp Storeの掲載内容を、サーバーの設定はご利用のサービス提供元に確認してください。この2種類の情報を混同しないようにしましょう。