Shadowrocket プロトコルガイド

接続はプロトコル名だけでは説明できない

プロキシ接続には通常、接続先アドレス、プロキシプロトコル、通信方式、認証情報、セキュリティ設定が含まれます。接続先アドレスはどのサーバーに接続するかを示し、プロキシプロトコルはアクセス先の伝え方やユーザーの認証方法を定めます。通信方式はデータを運び、セキュリティ設定はTLSを使うか、どの証明書を検証するかを決めます。各階層を分けて考えると、「同じVLESSを選んだのに、片方の接続だけ使える」理由もわかります。名前が同じでも、ポート、通信方式、認証情報まで同じとは限りません。

TCPは順序を保った信頼性のあるバイトストリームを提供し、UDPは到達を直接保証しないデータグラム通信を行います。WebSocketは確立済みの接続上でメッセージをやり取りする方式で、Shadowsocksと同じ階層のプロキシ認証プロトコルではありません。TLSは保護された通信路を確立するもので、プロキシアカウントの代わりにはなりません。サブスクリプションにプロトコル名、WebSocket、TLSが併記されている場合は、競合する選択肢ではなく、一組の設定として理解してください。実際に選べる項目は、現在の画面と接続情報に従ってください。

アドレス、ホスト名、ポートをそれぞれ確認

サーバーアドレスにはドメイン名とIPアドレスがあります。ポートはサーバーが実際に待ち受けている接続口です。特定のプロトコルでよく使われるからといって、一般的なポート番号をそのまま設定しないでください。TLSを使う場合、接続先アドレスと証明書検証に使う名前が異なることがあります。前者はサーバーへの接続に使い、後者は接続先の身元確認に使います。情報にSNIまたはServer Nameが個別に記載されている場合は、その値をそのまま確認してください。サーバーアドレスをIPに変えても、元の証明書検証が維持されるとは限りません。

認証情報にも種類があり、パスワード、UUID、鍵ペアは互換性がありません。UUIDはランダムな文字列に見えても、任意のパスワードと同じものではありません。公開鍵は相手側に渡して本人確認に使い、秘密鍵は端末内で厳重に管理します。コピー時は前後の空白、改行、大文字・小文字、QRコードの読み取り漏れに注意してください。まず設定項目がどの階層に属するかを見極めてから、サーバー管理者への確認、システム時刻の確認、証明書名の確認のどれが必要かを判断すると、関係のない設定を何度も試す手間を省けます。

Global Routingでサーバーのプロトコルは変わらない

Global RoutingのConfig、Proxy、Directは、それぞれ設定ファイル、プロキシ、直接接続に対応します。Configでは現在の設定ファイルのルールに従ってポリシーを選択します。Proxyはクライアントが処理するリクエストをプロキシ経由にし、Directは直接接続します。ここで説明しているのはルーティングの判断であり、サーバーのプロトコルを別のものに変える機能ではありません。Proxyに切り替えると、「テスト時に想定したポリシーが使われていない」という要因を切り分けられますが、誤ったパスワード、無効な証明書、サーバー側で無効なUDP転送は解決できません。

ルール内のPROXY、DIRECT、REJECTはポリシーを表すキーワードで、画面上の接続モードとは大文字・小文字の表記が異なります。ルールは上から順に照合され、最初に一致した時点で処理が決まります。FINALは最後に置き、どのルールにも一致しない場合の既定動作にします。example.comは説明用の例であり、自分のサーバーの検証には使えません。検証には接続先がわかっている対象を選び、接続ログで適用されたポリシーを確認してください。設定ファイル内のポリシー名は、実際に定義されている名前と一致させる必要があります。例をそのまま完全な設定として使わないでください。

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

また、ドメイン名をどちら側で解決するかによって診断結果も変わります。クライアント側の名前解決失敗、サーバー側の名前解決失敗、プロキシ認証失敗は、いずれも読み込みタイムアウトのように見えることがありますが、問題の箇所は異なります。元の設定を保存し、まず接続先に到達できるか、次に認証できるか、その後に接続先の名前解決とルールを確認してください。一度に変更する項目を一つに絞れば、現象と原因を結びつけやすくなります。ルールの順序について詳しくは、カスタムルールとFINALによる既定動作の記事をご覧ください。

設計の目的と進化

Shadowsocksは、プロキシリクエストを暗号化された接続に載せ、比較的シンプルなやり取りで接続先を伝えてデータを転送することを重視しています。ネットワーク層全体を扱うトンネルではなく、通常はTCP接続とUDPデータグラムを使ったプロキシ機能を提供します。この範囲を理解しておくことが重要です。アプリの通信をクライアントが処理するか、ドメイン名をどこで解決するか、LAN内のアドレスを直接接続するかは、システムへの接続方法とShadowrocketの設定によって決まり、プロトコル名だけでは判断できません。

暗号化方式は進化を重ねてきました。現在よく使われるAEAD方式は、機密性と完全性の検証を組み合わせ、データが改ざんされた場合に受信側が検出できるようにします。世代の異なる方式では、鍵の形式やデータグラムの構造も異なることがあります。選択時は名前が似ているかではなく、サーバーが指定したMethodに完全に合わせてください。クライアントの一覧に方式があるからといって、サーバー側で有効とは限りません。別の方式に変更すると、認証や復号に失敗することがあります。

Method、Password、追加設定

基本の確認項目はAddress、Port、Method、Passwordです。Methodは一文字も違わないようにし、Passwordも元の文字列を保持してください。新しい暗号化方式の一部では指定された長さのエンコード済み鍵が必要です。任意の短い文字列で代用したり、接続情報で明示されていないのにエンコード済みの鍵をデコードして貼り付けたりしないでください。インポート用リンクに追加オプションが含まれる場合は、まず全体をインポートし、手動設定で表示される項目と一つずつ照合して、サーバーが必要とする設定の漏れを防ぎます。

接続情報には追加のカプセル化方式や拡張設定が記載されていることもあります。これらはShadowsocksという名称だけで自動的に備わる機能ではなく、すべてのプラットフォームやクライアントの画面で同じように表示されるとも限りません。サーバー側で実際に使われている組み合わせと、現在のShadowrocketの画面で対応する項目があるかを確認してください。情報にShadowsocksとしか記載されておらず、Methodや認証情報がない場合は、接続設定として不十分です。一般的な値を推測せず、利用中のサーバー管理者に確認してください。

速度とiOSのバッテリー消費の見方

Shadowsocksは比較的シンプルなやり取りで動作しますが、どの状況でも最速とは限りません。最近の端末では一部の暗号化アルゴリズムがハードウェアアクセラレーションに対応していますが、チップによって効率は異なります。データグラムのサイズ、接続数、無線の電波状況も実際の負荷に影響します。短いウェブ閲覧では名前解決や接続確立の時間が主な要因となり、長時間のダウンロードでは回線容量やサーバー負荷の影響が大きくなります。端末、接続先、ネットワーク条件が揃っていない場合、速度測定の差をすべて暗号化方式の違いに結びつけることはできません。

UDPは個別に検証する必要があります。サーバーがTCPしか開放していない、ファイアウォールがUDPを許可していない、中間ネットワークがUDPを異なる方法で処理している、といった可能性があります。その場合、ウェブページは表示できるのにリアルタイムアプリで問題が起きても不思議ではありません。UDPのテストに失敗しても、すぐにパスワードを変更しないでください。TCPで認証が安定して成功しているなら、認証済みの設定を何度も編集するより、UDP転送の対応状況、ポート、サーバー側のポリシーを確認するほうが有効です。プロトコルがデータグラムを扱えるからといって、アプリの通信が必ず想定どおりに流れるわけではありません。

iOSでバッテリー消費に影響する主な要因は、ネットワーク拡張が処理するデータ量、接続の再確立、無線ネットワークの品質、バックグラウンドでの起動です。短時間の接続を頻繁に繰り返すと、安定した長時間接続よりハンドシェイクの負荷が目立つことがあります。電波が弱いと再送が発生し、暗号化方式の差が見えにくくなります。Shadowsocksは、利用中のサーバーが提供する軽量プロキシの選択肢として評価し、固定的な省電力ランキングを想定しないでください。使える設定を保存し、安定性を確認してから性能を比較すると、トラブルシューティングと速度測定の干渉を抑えられます。

VMessがプロトコル内で多くの処理を行う理由

VMessは、ユーザー認証、リクエスト情報、データ保護をプロトコルの仕組みに含めて設計されています。クライアントは定められた形式でリクエストを作成し、サーバーがユーザーを識別して接続先へ転送できるようにします。さまざまな通信方式と組み合わせられるため、VMessの接続情報にはサーバーアドレスとUUIDのほかに、セキュリティ方式、通信方式、TLSの設定が含まれることがあります。以前の設定に互換性のための項目があるからといって、任意に追加・削除しないでください。現在のサーバー設定と、利用できるインポート情報に従ってください。

VMessの認証では時刻の同期が必要です。接続先に到達できるのに端末を変えてから認証に失敗し続ける場合は、システムの日付、時刻、タイムゾーンを確認し、自動設定を優先してください。「ポートに接続できる」ことは認証の成功を意味しません。ネットワーク接続の確立は最初の段階で、その後にプロトコルヘッダーや認証がサーバーに拒否される場合もあります。テストを繰り返しても時刻のずれは直りません。認証エラーを不安定なネットワークと誤認しないようにしてください。

VLESSが簡略化する部分と、依存する部分

VLESSは軽量な認証とリクエスト転送を重視し、データ保護の多くを外部のセキュリティ機構に委ねます。UUIDは引き続き識別に使いますが、プロトコル層には汎用的なデータ暗号化機能が組み込まれていません。だからといって「接続全体が保護されない」とは限りません。外側で適切に設定されたTLSを使えば、通信路は保護されます。逆に、外側にセキュリティ機構がなければ、VLESSを選んだだけでデータが暗号化されるわけではありません。セキュリティは組み合わせ全体を確認してください。

UUIDをそのままにしてTypeだけ切り替えても、VMessとVLESSを相互に変換することはできません。サーバーが該当するプロトコルで待ち受けている必要があり、外側の通信方式も一致させる必要があります。接続情報に追加のフロー制御やセキュリティ設定が含まれることがありますが、すべての通信方式に適用できるわけではありません。画面に項目が表示されない場合は、まず選択中のType、サーバー側の要件、対応範囲を確認してください。項目を表示させるためだけに別のプロトコルに切り替えると、正しかった接続設定まで対応しなくなるおそれがあります。

WebSocket、Host、Pathの関係

WebSocketを使う場合、Pathは対応するリクエストを受け付けるためのサーバー側のパスです。通常は先頭のスラッシュを含め、すべての文字をそのまま設定します。HostはHTTPリクエストのホスト情報で、SNIはTLSハンドシェイクや証明書の選択に使います。同じ値であることは多いものの、別の階層に属するため、常に同一の項目とは限りません。サーバーの前段にリバースプロキシがある場合、PathやHostが一致しないと、プロキシプロトコルの認証が始まる前にHTTPエラーが返ることがあります。その場合、UUIDを変更しても解決しません。

ドメイン名の証明書を使う場合は証明書検証を有効にし、Server Nameが証明書の対象名と一致することを確認してください。証明書エラーが発生したら、まずシステム時刻、名前のつづり、証明書の有効性、証明書チェーンを確認します。証明書検証の無効化は接続先の身元確認を弱めるため、通常の解決方法として使わないでください。管理者からIPアドレスの接続先と個別の検証用ドメイン名が指定されている場合は、その役割分担を保ち、すべての名前をIPアドレスに置き換えないでください。

iOSでのVMessとVLESSのバッテリー消費の違いは、プロトコルヘッダーのサイズだけでは判断できません。外側のTLSハンドシェイク、WebSocketのカプセル化、接続の再利用、サーバーまでの距離も結果に影響します。頻繁に再接続する場合は、安定した通信中のプロトコル差より接続確立の負荷が目立つことがあります。利用中のサーバーが一方だけを提供している場合は、その組み合わせを正しく使ってください。両方を利用できる場合は、接続先とテスト条件を揃え、初回の読み込み、連続転送、ネットワーク切り替え後の復旧を比較します。一度の最高速度だけで判断しないでください。

Trojanではセキュアな通信路が先に確立される

Trojanは通常、TLS接続内でパスワード認証とプロキシリクエストの転送を行うため、証明書の検証が接続の仕組みを理解するうえで重要です。クライアントはまずサーバーに接続してTLSを確立し、その後にプロトコルの認証情報を送ります。ハンドシェイクで失敗した場合、パスワードの検証はまだ正常に始まっていません。TLSが正常でも認証に失敗する場合は、パスワードとサーバー側のプロトコル設定を確認してください。エラーを分けて考えると、証明書の問題に対してパスワードを何度も変更する無駄を減らせます。

Address、Port、Password、TLSに使う名前をまとめて確認してください。SNIはサーバーが適切な証明書と接続先を選ぶために使いますが、自由に入力できる飾りの項目ではありません。接続情報にドメイン名が指定されている場合は、まず元の値のまま基本的な検証を行ってください。アドレスと検証用の名前を変更するのは、サーバーの構成を把握している場合に限ります。TLSを使うからといって、TLS対応のサーバーがすべてTrojanの接続先になるわけではありません。サーバーがTrojanのプロキシサービスと認証アカウントを実際に提供している必要があります。

HTTPプロキシとHTTPサイトへのアクセスは別

HTTPプロキシはHTTPの仕組みで転送リクエストを受け付けます。HTTPSサイトにアクセスする際は、CONNECTを使ってバイトストリームの通信路を確立することがよくあります。ここでは、クライアントからプロキシサーバーまでと、プロキシサーバーから接続先サイトまでの2つの区間を区別してください。接続先サイトがHTTPSでも、最初の区間が暗号化されたプロキシ接続になるとは限りません。プロキシの接続先自体が対応するTLSなどの保護を使う場合に限り、最初の区間も保護されます。プライバシーの保護範囲を判断する際、ブラウザーのアドレスバーに鍵マークがあるかだけで判断しないでください。

HTTPプロキシではUsernameとPasswordが必要な場合もあれば、サーバー独自のアクセス制御で認証する場合もあります。認証情報は利用中のサーバー情報から取得してください。ウェブサイトのアカウント情報をプロキシ認証欄に入力しないでください。TLSで保護されたHTTPプロキシの接続情報がある場合は、対応する種類と証明書名を確認してください。通常のHTTPポートとしてテストしただけで、サーバーの障害と決めつけないでください。HTTPリクエストが受け付けられても、あらゆるCONNECT先やポートへの接続が許可されるとは限りません。

SOCKS5の汎用性と明確な制限

SOCKS5は認証方式と接続先アドレスをネゴシエーションで指定する汎用プロキシプロトコルです。ドメイン名とIPアドレスのどちらも接続先として指定でき、UDP関連の仕組みも定義されています。ただし、基本プロトコル自体には汎用的な通信暗号化機能がありません。ユーザー名とパスワードは認証に使うもので、その後のデータ通信を自動的に暗号化するものではありません。クライアントからサーバーまでの区間を保護する必要がある場合は、実際の外部セキュリティ機構と信頼できるネットワーク環境をあわせて判断してください。「パスワードがある」ことを「通信全体が暗号化されている」ことと混同しないでください。

SOCKS5のUDPが使えるかどうかは、クライアント、サーバー、中間ネットワークのすべてが条件を満たす必要があります。サーバーがTCP転送しか実装していない場合や、UDPアソシエーションで返されるアドレスにネットワーク上から到達できない場合もあります。ドメイン名をどちら側で解決するかは、リクエスト形式とクライアント設定に応じて確認してください。IPアドレスでは成功してドメイン名では失敗する場合は、まず名前解決の経路を確認します。TCPは通るのにリアルタイムアプリが失敗する場合はUDPを確認し、すべての問題をアカウントエラーと見なさないでください。

この3種類のプロトコルは、利用中の接続先に合わせて選んでください。職場のネットワークにHTTPプロキシが用意されている場合は、その認証方式とアクセス範囲に合わせて設定します。実験環境やローカルネットワークにSOCKS5サーバーがある場合は、保護範囲を把握して使います。Trojanの接続情報がある場合は、TLS設定をすべて保持してください。名前が複雑に聞こえるからといって、種類を置き換えないでください。iOSでの速度やバッテリー消費の違いは、単独のプロトコル名より、プロキシリクエストの方式、ハンドシェイクの頻度、ネットワーク品質から説明できることがよくあります。

アプリケーション層のプロキシとの違い

WireGuardはIPパケットを暗号化トンネルに通すためのプロトコルです。シンプルな構造と固定された最新の暗号スイートで、設定の複雑さを抑えています。接続リクエストを主に転送するプロキシプロトコルとは異なり、自分側のインターフェースアドレス、接続先の識別情報、接続先に送るアドレス範囲を指定する必要があります。そのため、WireGuardの設定には通常、サーバーアドレスとパスワードだけでなく、自分側のPrivateKey、接続先のPublicKey、トンネルアドレス、ルーティング関連の設定も含まれます。項目名を一つずつ暗記するより、これらの関係を理解することが大切です。

WireGuardは外側の通信にUDPを使うため、現在のネットワークでUDPを安定して送受信できることが前提です。ウェブサイトに直接接続できても、UDPトンネルの接続先に到達できるとは限りません。エンドポイントの名前解決、ポートの開放、サーバーからの応答経路も正常である必要があります。ハンドシェイクが成功した後は、接続先の通信が正しくルーティングされるか、サーバーが必要な転送を許可しているかも確認してください。「ハンドシェイクが表示された」ことと「すべての接続先にアクセスできる」ことは別です。

PrivateKey、PublicKey、アドレスの割り当て

PrivateKeyは自分側で秘密に保管し、PublicKeyは接続先が自分を識別するために使います。サーバーの公開鍵とクライアントの公開鍵は別の項目であり、入れ替えることはできません。事前共有鍵が別途指定されている場合、それは両側で一致させる必要がある追加の設定で、公私鍵の代わりになる汎用パスワードではありません。スクリーンショットやトラブルログでPrivateKeyを公開しないでください。接続情報に一般的なPassword欄がなくても、接続に使える機密情報が含まれていることがあります。

Addressはトンネルインターフェースの自分側のアドレスです。サーバーのグローバルIPアドレスでも、任意のLANアドレスでもありません。通常はサーバー管理者から割り当てられ、接続先の設定と対応しています。外部から到達するサーバーの接続先を指定するのはEndpointです。AddressにサーバーのIPアドレスを入力すると、トンネル内部と外部ネットワークを混同することになります。別の端末のインターフェースアドレスや識別情報をそのまま使うと、アドレスの競合や接続先での割り当て変更につながる場合もあります。現在の端末用にサーバーから割り当てられた情報を使ってください。

AllowedIPs、MTU、接続維持

AllowedIPsは、どの宛先アドレスをその接続先に送るかを判断するとともに、受信データのアドレスの割り当てを確認するために使われます。ドメイン名を並べるウェブサイト用ルールではありません。Shadowrocketのポリシールーティングとどのように連携するかは、現在のインポート方法と画面上の機能に応じて確認してください。設定情報が特定のネットワーク範囲だけを対象としている場合、互換性向上を目的にすべてのアドレス範囲へ変更しないでください。アクセス範囲が変わるおそれがあります。イントラネットにアクセスできない場合は、トンネルアドレス、接続先の範囲、サーバーの戻り経路をあわせて確認してください。

MTUはトンネルインターフェースで運べるデータパケットのサイズ上限を決めます。外側のカプセル化が領域を使う一方、経路によってフラグメントや大きなUDPパケットの処理方法が異なるため、小さなリクエストは成功するのに大きなレスポンスが止まることがあります。問題を調べる際は、まず大きなデータ転送だけで起きるか確認し、サーバーの推奨に従って調整してください。どんな状況にも当てはまる小さな値はありません。MTUを下げると同じデータ量に必要なパケット数が増え、下げすぎても負荷が増します。変更ごとに結果を記録してください。

PersistentKeepaliveは一部のネットワークでアドレス変換のマッピングを維持するのに役立ちますが、定期的なパケット送信によって無線が動作し続ける時間が延びることもあります。iOSではサーバー側の要件と、実際にアイドル時の接続が切れるかどうかをもとに使うか判断してください。間隔をむやみに短くする必要はありません。WireGuardの計算効率が、そのまま端末全体の省電力につながるわけでもありません。トンネルを通る通信量、接続維持、電波状況、ネットワーク切り替えも結果に影響します。ネットワーク層のアドレスや特定のネットワーク範囲へのアクセスが必要な環境に適していますが、接続先に対応した設定情報一式が必要です。

通信方式から設計の特徴を把握する

Hysteria2はQUICをベースにしたプロキシ通信で、遅延やパケットロスがあるネットワークでのデータ転送を考慮しています。QUICはUDP上で接続管理、信頼性のあるデータ転送、輻輳制御などを行うため、「外側にUDPを使う」からといって、アプリケーションデータの信頼性を扱わないわけではありません。一方で、利用可能なUDP経路が必要です。ネットワークが該当するパケットを継続的に破棄する場合、プロトコル内部の仕組みだけで接続可能になることはありません。帯域幅の値を何度も変更するより、まずこの条件を確認してください。

QUICのストリーム機構は、ストリーム間の一部のブロッキングを抑えられますが、無線の電波が弱い、共有回線が混雑している、サーバーの容量が不足しているといった問題は解消しません。単一接続の実際の動作も、クライアントの実装、接続先の応答、経路の変化に左右されます。Hysteria2という名前が別世代のプロトコルと似ていても、接続情報をそのまま共用できるわけではありません。Type、認証方式、追加設定をサーバーに合わせてください。インポートに成功しただけでは接続情報を解析できたことしか確認できません。ハンドシェイクとアクセスも検証してください。

認証、TLS、任意のカプセル化設定

基本の確認項目はAddress、Port、認証情報、TLSの名前です。認証文字列は利用中のサーバーから取得し、区切り文字も含めて完全に保持してください。パスワードに見える部分だけをコピーしないでください。TLSの証明書チェーン、有効性、名前も正しく検証する必要があります。証明書エラーが表示されたら、まずシステム時刻と名前の設定を確認し、次にサーバーの証明書を調べてください。検証を常に無効にして設定ミスを隠すと、接続先の確かな本人確認ができなくなります。

接続情報に任意の難読化関連設定が記載されている場合があります。これらはユーザー認証やTLS証明書とは別の階層に属し、双方で互換性のある設定を使う必要があります。サーバーから指定されていない項目を追加すると、サーバーがデータを認識できなくなることがあります。指定されていない項目は初期値のままにし、明示されている項目は一つずつ確認してください。特定のネットワークだけで失敗する場合は、同じ接続情報のままネットワークを切り替えて試すほうが、条件がわからない状態で認証、難読化、帯域幅を一度に変更するより原因を特定しやすくなります。

帯域幅の値をむやみに大きくできない理由

設定によってはアップロードとダウンロードの帯域幅を入力し、特定の輻輳制御モードで速度を推定したり、上限の調整に使ったりします。実際の効果はクライアントとサーバーの設定によって変わり、大きな値を入力すれば大きなスループットが得られるわけではありません。実際に使える容量を大きく上回る値を入力すると、キューの増加、パケットロス、他の通信との競合が起こることがあります。低すぎる値はスループットを制限する可能性があります。まず単位を確認し、bitとbyteを区別したうえで、現在の回線とサーバーの推奨値に合わせてください。他の人の速度測定のスクリーンショットをそのまま参考にしないでください。

モバイル回線の容量は電波状況、位置、基地局の混雑によって変化するため、固定値がすべての時間帯に適するとは限りません。安定したWi-Fiからモバイル通信に切り替えた後に大きく速度が変動した場合は、まずネットワーク自体の利用可能な容量を比較し、その後で帯域幅設定が過剰でないか判断してください。初期設定や自動ネゴシエーションを使う場合も、短いリクエストと連続転送を実際に確認し、設定項目が少ないからといって必ず優れていると考えないでください。性能調整では現象を明確にし、一度に一つだけ変更して、元に戻せるよう記録してください。

iOSでは積極的なデータ送信、パケットロスからの復旧、大容量データの連続転送によって、無線の動作時間や発熱が増えることがあります。一度のダウンロードが速くても、終日使った場合に省電力になるとは限りません。逆に、同じ作業を短時間で終えれば総稼働時間が減る場合もあり、実測が必要です。作業時間、失敗率、近い使用時間でのバッテリー消費をあわせて比較し、単一の現象だけで結論を出さないでください。テスト中は関係のない大容量通信を止め、バックグラウンドのダウンロードをプロトコルの影響として扱わないようにします。

適した状況は、「利用中のサーバーがHysteria2を提供し、現在のネットワークでUDPを利用でき、パケットロスがある場合の動作を評価する必要がある」と説明できます。すべてのTCP方式を無条件に置き換えるものではありません。同じサーバーの別の接続先は正常で、特定のネットワークでこの接続先だけ失敗する場合は、まずその経路でUDPがどう扱われているか確認します。すべてのネットワークで失敗する場合は、サーバーの待ち受け、認証、証明書を確認してください。条件から問題を絞り込むほうが、帯域幅をむやみに上げて試すより有効です。

「速さ」を測定できるプロセスに分ける

ウェブページの表示には、名前解決、接続確立、プロキシのハンドシェイク、接続先とのハンドシェイク、コンテンツ転送が含まれます。初回の読み込みが遅い場合は、前半の処理に時間がかかっている可能性があります。大容量ファイルのダウンロードが遅い場合は、持続的なスループットが制限されている可能性があります。Connectivity Testの結果は、そのテスト方式と接続先における結果であり、あらゆるアプリの総合的な速度や、基盤ネットワークの往復遅延と同じとは限りません。プロトコルを比較する前に、テストで何を調べるのかを決め、それに合った現象を記録してください。

公平に比較するには、端末、接続ネットワーク、サーバーの地域、接続先サービス、テスト時間をできるだけ揃えます。同じ名前のサーバーでも異なる経路を使うことがあり、負荷は時間とともに変化します。テストを続けて端末が熱くなると、後半の結果に影響することもあります。一方を連続してテストしてからもう一方を試すのではなく、使用可能な2つの設定を交互に切り替え、短いリクエストと連続転送を繰り返してください。差が小さい場合は変動幅を残し、どちらかのプロトコルが常に優れていると無理に結論づけないでください。

バッテリー消費は暗号化計算だけでは決まらない

iOSでのプロキシ処理には通常、ネットワーク拡張、データパケットの処理、システムによる無線接続の管理が関わります。暗号処理もリソースを消費しますが、画面、モバイル通信の電波、再送、バックグラウンド処理、接続維持も大きく影響することがあります。システムのバッテリー画面に表示される使用量は総合的な結果であり、特定のプロトコルの処理コストを個別に示すものではありません。プロキシ使用中に動画を見たり、ダウンロードしたり、画面を長時間表示したりしている場合、その間のバッテリー消費をすべてShadowrocketのプロトコル処理によるものと考えないでください。

アイドル時と使用中を分けて観察してください。アイドル時は、頻繁な起動、再接続、Keepaliveの送信がないか確認します。使用中は、同じ作業にかかる時間、発熱、失敗後の再試行を確認します。On Demandは条件に応じて接続を開始する機能で、プロトコルの負荷を減らすボタンではありません。設定によってネットワーク切り替え時に接続を何度も再確立すると、常時接続より使い勝手が悪くなることがあります。まず自動接続が必要かを判断し、トリガー条件が日常のネットワーク環境に合っているか確認してください。省電力のためにかえって切り替えを増やさないようにしましょう。

TCP、UDP、ネットワーク切り替えの実際の影響

TCPはパケットロスが発生した際、順序どおりのバイトストリームを復元する必要があるため、回線品質が悪いと待ち時間が長くなることがあります。UDPを使う上位プロトコルも独自の復旧や輻輳制御を行うため、待ち時間がないとは限りません。リアルタイムアプリでは、継続的な遅延の揺れやパケットの到達が重要です。ウェブ閲覧では短い通信処理の完了時間が重視されます。大容量ファイルのスループットだけでは通話や操作の快適さを評価できません。同様に、特定のリアルタイムアプリで問題が起きても、プロキシのTCP転送に問題があるとは限りません。実際の用途に合ったタスクを選んでください。

Wi-Fiとモバイル通信の切り替えで、外部アドレス、利用できる帯域幅、経路上のMTUが変わり、既存の接続が切れることがあります。通信方式に接続移行の機能があっても、全体の復旧はクライアントの実装、サーバー、接続先アプリに依存します。テストでは「切り替え後の新しいリクエストが成功するか」と「元のリクエストを継続できるか」を記録してください。この2つは別の指標です。継続的なやり取りが必要な用途では、一時的な最高速度よりも、予測可能な復旧のほうが重要なことがよくあります。

ルーティングが一致しているかも確認してください。一方の設定では大半のリクエストが直接接続され、もう一方では同じリクエストが遠隔の接続先へ送られる場合、速度やバッテリー消費の違いはプロトコルだけの差ではありません。Configでテストする際は、同じルールとポリシーを使ってください。必要に応じてProxyに一時的に切り替えて条件を揃えて確認し、終了後は元のモードに戻します。Dataのサーバー統計は、通信が想定した接続先を経由しているか確認する参考になりますが、カウンターの値は成功率ではなく、それだけですべてのドメインルールが有効だと証明するものでもありません。

詳しい読み取り方はDataの通信量統計の記事をご覧ください。テストを記録するときはタスク、ネットワーク、ルーティングモード、接続を切り替えたかを書き、アカウント情報は伏せてください。再確認できる結論は「この条件では、この設定のほうが安定してタスクを完了できた」という形にし、「このプロトコルは常に速い」としないでください。2つの方法の結果に大きな差がなければ、設定項目が揃っていて管理しやすく、復旧手順が明確であることのほうが、小さな速度差を追うより実用的です。

選ぶ順番：性能の好みより対応状況を優先

利用中のサブスクリプションが1つだけなら、まず全体をインポートし、種類を確認してください。先に好きなプロトコルを決める必要はありません。サーバー側で提供されていない種類をクライアントだけで有効にすることはできません。手動入力が必要な場合は、接続先、認証、通信方式、セキュリティ、追加設定を揃えてからAdd Serverで該当する種類を選びます。サブスクリプションと手動入力の違いはSubscribe、QRコード、手動インポートの説明をご覧ください。基本的な使い方は使い方ガイドを参照してください。

利用中の環境から複数の接続先を使える場合は、用途ごとに確認項目を絞ります。一般的なウェブ閲覧では短いリクエストの安定性を確認します。連続ダウンロードではスループットと発熱を見ます。リアルタイムアプリではUDP対応と遅延の揺れを確認します。特定のイントラネットにアクセスする場合は、WireGuardのトンネルアドレスやネットワーク範囲の設定が必要かを確認してください。プロトコル名は設計の目安にはなりますが、端から端までのテストの代わりにはなりません。証明書の更新、鍵の管理、設定の更新も含め、正確な情報を維持できる組み合わせを選びます。項目が多い組み合わせが最適とは限りません。

最小限の接続設定を作り、後からルールを戻す

元の接続設定を保存し、テスト用に複製します。まず端末がネットワークに接続できることを確認し、次に接続先のアドレスとポート、認証とTLS、最後に既知の接続先へのアクセスを検証します。ルールの影響を切り分ける必要がある場合は、Global RoutingのProxyモードを一時的に使います。テストが終わったら想定する設定に戻してください。接続が安定してからConfigを有効にし、使用中の設定ファイル、ルールの順序、FINALを確認します。DNS、プロトコル、通信方式、ポリシーを同時に変更すると、元に戻してもどの変更が影響したのかわかりにくくなります。

「特定のウェブサイトだけ失敗する」場合は、まずそのサイトにそもそもアクセスできるかを確認し、次に適用されたルール、選択されたポリシー、名前解決を調べます。「すべての接続先で失敗する」場合は、接続先と認証を優先して確認します。「小さなリクエストは通るが、大きなレスポンスが止まる」場合は、経路、MTU、通信方式を確認します。「ネットワーク切り替え後に失敗する」場合は、新しいネットワークから接続先に到達できるか、接続が再確立されるかを調べます。現象ごとに調査範囲を絞るほうが、あらゆる問題をプロトコルの不適合と決めつけるより効果的です。

サブスクリプションの更新、機密情報、入手方法

Subscribeを更新するとアドレスやポート、登録項目が変わることがあり、手動で変更した内容が新しいサブスクリプションの内容で上書きされる場合もあります。「以前は使えたのに更新後に失敗する」場合は、変更された項目を比較し、想定した接続先を使っているか確認してください。すべての全体設定をすぐに変更しないでください。利用中のサーバー管理者に連絡する場合は、プロトコルの種類、エラーが起きた段階、接続ネットワーク、再現の有無を伝えます。サブスクリプションのリンク、UUID、パスワード、PrivateKey、認証情報を含むQRコードは隠し、アクセス権を持つ情報をログと一緒に公開しないでください。

クライアントの入手や初回起動時に問題が起きている場合は、まずインストールと実行許可の説明を確認し、インストールの問題とプロトコルのテストを混同しないでください。MacではAppleシリコンとIntelを区別します。初回起動がブロックされた場合は、入手元を確認したうえで、システムの「プライバシーとセキュリティ」で対応してください。WindowsのSmartScreen、Androidのインストール権限、Linuxの実行権限についても、ダウンロードページの説明に従ってください。他のプラットフォームのインストーラーは当サイトの/dlから入手できます。プロトコル情報から別のインストール先を探さないでください。

iPhone / iPadでは、App Storeの製品ページで開発元のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。システム要件はApp Storeの製品ページに記載された内容に従ってください。入手方法は2種類です。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。クライアントを購入してもサーバー接続情報は含まれません。クライアントの入手と、利用中のサブスクリプションのインポートは別の操作です。接続に失敗してもクライアントを再購入する必要はありません。

検証済みの設定を一つ保存し、利用できるネットワークと用途を記録してください。以降は一度に一つの項目だけを変更し、アクセス、ルール、復旧動作を確認してから次に進みます。問題が解決しない場合は、このページの該当するプロトコルの章に戻って設定項目を確認し、ダウンロードとインストールに関するよくある質問を参考に、入手の問題と接続の問題を切り分けてください。適切なプロトコルの判断基準は新旧ではなく、サーバーが対応していること、設定が一致していること、検証結果が明確なこと、日常のネットワークで安定して再現できることです。