Shadowrocket プロトコルの選び方と設定項目

01 / SELECTION

プロトコルの選び方：まずサーバー側の設定を確認

プロトコル、転送方式、セキュリティ、ルーティングを分けて考える

Shadowrocketでプロトコルを選ぶことは、クライアントがサーバーとどの形式で通信するかを指定することであり、自由に切り替えられる速度設定を選ぶことではありません。サーバーがShadowsocksを提供しているなら、対応するShadowsocksの種類と認証情報が必要です。サーバーがTrojanを提供している場合も、種類だけVLESSに変更して使うことはできません。アドレスとポートが同じでも、サーバーが同じハンドシェイク、認証、データ形式を受け付けるとは限りません。種類を選ぶ際は、手元の設定情報に明記されたプロトコルを基準にしてください。

接続には通常、4層の情報が関わります。1つ目は接続先を決めるアドレスとポート、2つ目はサーバーがリクエストを受け入れるかを決めるプロトコルと認証、3つ目はTLS、WebSocket、UDPなどの転送・セキュリティ設定、4つ目はどのリクエストを接続に流すかを決めるローカルルーティングです。プロトコルによっては複数の層が一体化しており、別のプロトコルではさまざまな組み合わせが可能です。トラブル時は層ごとに確認しましょう。そうしないと、DNSエラーをパスワードの誤りと取り違えたり、ルールに一致しない状態をプロトコルの非互換と誤認したりするおそれがあります。

速度や電池消費に決まった優劣はない

実際の速度は、接続ネットワーク、往復遅延、パケットロス、サーバー負荷、回線帯域、接続先のサービスなどに左右されます。カプセル化が増えるとデータ量や処理負荷は増えますが、どの環境でも必ず遅くなるとは限りません。利用中のネットワークに適した転送方式なら、再送が減ることでカプセル化の負荷を補える場合があります。逆に、同じプロトコルでもサーバーが違えば、同一サーバー上でプロトコルを変えた場合より大きな差が出ることがあります。そのため、このページではプロトコル名だけで速度の順位を決めていません。

iPhoneやiPadの電池消費も、使い方に応じて確認する必要があります。大容量通信を続けると、無線通信、暗号化・復号、アプリの処理が同時に働きます。一方、断続的なリクエストでは、接続の確立回数、バックグラウンドでの接続維持、ネットワークの再起動が影響しやすくなります。自動速度テストの頻繁な実行、短い間隔での更新、接続失敗後の再接続の繰り返しは、プロトコル自体の違いを分かりにくくします。比較する際は、端末、ネットワーク、サーバー、接続先をそろえ、画面の明るさやほかのバックグラウンド処理も考慮してください。一度の電池残量の変化だけで、特定のプロトコルが原因とは判断できません。

再現可能な比較方法を用意する

まず、正常に使える設定を基準として保存し、項目を一つずつ変更します。同じ接続先で、初回アクセス、再アクセス、継続的なデータ転送、スリープ解除後の状態をそれぞれ確認してください。各テストでDNS、プロトコル、サーバーを同時に変更しないようにします。Connectivity Testは接続状態を確認する手段の一つですが、テストに成功してもすべての用途で通信できるとは限りません。Web閲覧、動画再生、リアルタイム音声では必要な転送条件が異なるため、数値だけを比べず、実際に使うサービスで確認してください。

手元の情報で指定されているプロトコルが1種類だけなら、その情報をすべて取り込んで動作を確認してください。名称を頼りに別の種類を探す方法は適切ではありません。プロトコルを切り替える場合は、新しい種類に必要な設定一式をサーバー側から入手してください。サブスクリプションの読み込み後に一覧が空の場合は、プロトコルの選択とは別の問題です。サブスクリプションを読み込んでも一覧が空の場合の確認方法を参照してください。以降の説明では、編集可能なサーバー設定が少なくとも1件あることを前提とします。画面に表示される項目は、アプリの現在の選択肢をご確認ください。

03 / VMESS · VLESS

VMessとVLESS：認証項目が似ていても同じプロトコルではない

設計の違いとプロトコルの区別

VMessは、専用のプロキシプロトコルとして認証とデータ処理を構成します。一般的な設定にはUUIDのほか、セキュリティや転送に関する項目が含まれます。一方、VLESSはよりシンプルなプロトコル層を採用し、プロトコル自体ではデータを暗号化しません。接続全体を理解するには、セキュリティを担う転送方式と合わせて考える必要があります。どちらにもUUIDが使われ、複数の外側の転送方式と組み合わせられる場合があります。そのため、リンク内の認証項目だけではプロトコルを判別できません。元のサブスクリプションまたはサーバー側に明記された種類を確認し、同じUUIDが異なるプロトコルで共通の認証情報になるとは考えないでください。

VLESSの構造がシンプルだからといって、接続全体のリソース消費が必ず少ないわけではなく、セキュリティ層を省略してよいという意味でもありません。TLS、WebSocketなどの転送方式を組み合わせる場合、実際のデータ量やハンドシェイクの流れは構成全体によって決まります。VMessの動作も、プロトコル名だけでなくサーバー設定やネットワーク状況に左右されます。種類を選ぶ際は、プロトコル、転送方式、セキュリティ層の3つを記録してから、互換性や用途を検討してください。1つの要素だけを取り出して比べると、実際の動作と異なる結論になりやすくなります。

UUID、転送方式、パス

UUIDは、サーバーが許可するユーザーを識別します。コピーする際は、すべての文字と区切り形式を保持してください。設定名で代用することはできません。設定名はユーザーが項目を見分けるためのもので、プロトコル認証には使われません。VMessの一部の項目は、プロトコル実装や過去の設定形式にも関係するため、ネット上の一つのスクリーンショットを基に一括変更しないでください。認証に時刻が関わる場合、端末の時刻が大きくずれていると接続に失敗することがあります。まずシステムの日付と時刻が正しいことを確認し、その後でサーバーが認証を拒否しているかを調べます。

転送設定は、プロトコルのデータをどのように運ぶかを決めます。WebSocketを使う場合、Pathはハンドシェイクのリクエストパス、HostはHTTP層のホスト情報に関係します。どちらも設定名ではなく、完全なURLを任意に分割して入力する項目でもありません。パスの先頭のスラッシュ、大文字・小文字、クエリ部分を残す必要があるかは、サーバー情報に従って確認してください。ほかの転送方式を選ぶと項目も変わることがあります。WebSocketの設定を別の転送方式にそのまま入力しないでください。画面に表示されない項目を、名前の似た別の項目で置き換えることもできません。

TLSの名称と追加の設定項目

接続先アドレスはサーバーへの接続に使います。TLSのServer Nameはハンドシェイクで名前を伝えるために使われ、証明書の名前の検証にも関係します。両者は同じ場合もあれば、サーバー情報で異なる値が指定される場合もあります。Hostはさらに別の層に属します。どれもドメイン名に見えるからといって、互いに置き換えることはできません。追加のセキュリティ拡張や特殊なハンドシェイク設定が指定されている場合は、現在のアプリがその組み合わせに対応しているか確認してください。入力欄があるというだけでは、任意の組み合わせでサーバーと通信できるとは限りません。

設定に含まれるFlowなどのオプションは、特定のプロトコル構成で使うもので、汎用の速度向上スイッチではありません。サーバーが明確に要求し、クライアントに互換性のある選択肢がある場合に限り有効にします。元の情報を確認せずに複数のセキュリティ設定を試すと、ハンドシェイク条件が同時に変わり、原因を特定するための基準がなくなります。サブスクリプションから読み込んだ設定は、まず元の状態を保存してから、独立したテスト用コピーを作成してください。読み込み時の情報不足か、後からの編集が接続に影響したのかを見分けやすくなります。

モバイルネットワークで比較する方法

iPhoneやiPadでこれらの接続を評価する際は、初回のハンドシェイクと、接続確立後のデータ転送を分けて確認します。ハンドシェイクの層が多いと、短いリクエストは往復遅延の影響を受けやすくなります。一方、長時間の転送では帯域や輻輳が主な要因になることがあります。ネットワークの切り替え後に古い接続が無効になり、アプリが接続を再確立する間、一時的に待ち時間が生じることもあります。特定の転送方式だけ復帰が遅い場合は、画面ロック解除後、Wi-Fi切り替え時、通常の連続利用時のどのタイミングで起きたかを記録してください。VMessとVLESSの全般的な違いとすぐに結びつけるべきではありません。

接続に失敗した場合は、アドレスとポート、プロトコルとUUID、外側の転送方式、セキュリティ層、接続先へのアクセスの順に一つずつ確認します。接続履歴にそのサーバーが選択されていないと表示される場合は、まずGlobal Routingと現在の設定を確認してください。よくある症状についてはトラブルシューティングも参照できます。ルーティングが確認できる前に、認証情報を何度も変更しないようにしましょう。

05 / HTTP · SOCKS5

HTTPとSOCKS5：プロキシの入口を確認し、保護される範囲を把握する

2種類の汎用プロキシインターフェースの基本

HTTPプロキシは、HTTPリクエストを転送する仕組みとして発展しました。Webリクエストではプロキシ形式のリクエスト先を使い、HTTPSなどではCONNECTリクエストで接続先へのトンネルを確立することがあります。SOCKS5は、接続先のアドレス、ポート、接続リクエストを指定する、より汎用的なプロキシセッションのネゴシエーションを提供します。どちらもプロキシの入口で使うプロトコルの取り決めであり、同じ暗号化、認証方式、UDP機能が標準で備わっているわけではありません。サーバーにHTTPと指定されている場合、アドレスが同じだからといってSOCKS5を選ばないでください。

ここでは、接続先サイトがHTTPSを使うことと、クライアントからプロキシ入口までの通信でTLSを使うことを区別する必要があります。HTTPSサイトでは通常、接続先サイトまでコンテンツが保護されます。一方、TLSを使わないHTTPプロキシとの接続では、プロキシのネゴシエーション情報や一部の認証情報が保護される範囲は、暗号化されたプロキシ入口とは異なります。接続先サイトが安全な通信を使っていても、外側のプロキシ経路のすべてが同じように保護されるわけではありません。保護範囲はブラウザーのアドレスバーやサーバーの設定名だけで判断せず、接続経路ごとに確認してください。

アドレス、ポート、認証方式

HTTPとSOCKS5の基本設定には、通常、サーバーアドレスとポートのほか、必要に応じてUsernameとPasswordが含まれます。認証の要否はサーバー側で決まります。空欄のままで接続できると決めつけたり、別のプロトコルのUUIDをユーザー名に入力して互換性を期待したりしないでください。認証エラーとネットワーク到達不能は似た症状になる場合があるため、接続エラーと手元の設定情報を照らし合わせます。アカウントにドメインなどの接頭辞が含まれる場合もあります。残すべきかどうかは、サーバーが提供した完全な形式を確認してください。

プロキシ入口でTLSが必要な場合は、対応するセキュリティ設定を選び、証明書名を確認してください。ポート番号だけでは、その入口が暗号化通信か平文通信か、CONNECTを受け付けるかは分かりません。サーバーによっては、接続可能な宛先、ポート、認証方式が制限されています。入口への接続に成功しても、その後のリクエストが拒否されることがあります。一部の宛先ポートだけ失敗する場合は、アクセス権の範囲とサーバー側の方針を先に確認してください。ローカルDNSを何度も変更したり、すべてのHTTPプロキシがWebページにしか接続できないと考えたりしないようにしましょう。

DNS名前解決とUDPの条件

SOCKS5では接続先をドメイン名で指定できますが、実際のリクエストでドメイン名がプロキシ側に渡されて名前解決されるかどうかは、クライアントの処理、DNSポリシー、接続先情報がすでにIPアドレスに変換されているかによって異なります。SOCKS5を選んだだけで、すべてのDNSリクエストがリモート側で処理されるとは限りません。HTTPプロキシもリクエストから接続先のホスト名を取得できる場合がありますが、アプリが発生させるほかのDNSクエリは個別に確認する必要があります。ドメイン名の問題を調べるときは、サーバーの種類だけでなく、実際の接続先とDNSの結果を確認してください。

SOCKS5の仕様にUDP ASSOCIATEが含まれていても、すべてのサーバー、接続ネットワーク、クライアントの組み合わせでUDP転送ができるわけではありません。通常、制御用の接続や転送先アドレスも関わり、ネットワーク側でその一部が制限される場合があります。TCPを使うサービスは利用できるのにUDPを使うサービスが失敗する場合は、サーバー側でUDPが有効か、返されたアドレスに到達できるか、同じ設定がルールで選択されているかをそれぞれ確認します。Webページのテスト結果を音声通話、ゲーム、その他のUDP通信にそのまま当てはめないでください。

利用場面とモバイル端末での確認

これらのプロキシ入口は、組織の既存プロキシ、認証が必要なネットワーク、汎用プロキシプロトコルを明示して提供する環境などで使われます。項目が少ないから長期利用に適していると考えず、管理者が指定した種類とセキュリティ要件に合わせて設定してください。iPhoneやiPadでの接続安定性は、ネットワークの切り替え、認証の有効期限、サーバー側の制限にも影響されます。認証エラーが繰り返し表示される場合は、頻繁に再接続するのではなく、認証情報の状態と利用権限を先に確認してください。

低遅延やUDPの通信が必要な場合は、プロキシ入口がその要件に実際に対応しているか確認します。許可された特定のリソースだけにアクセスする場合は、宛先のルーティングと認証の範囲を重視してください。プロトコルの選択は、手元にある接続条件に合わせるものであり、サーバーが提供していない機能を追加するものではありません。設定名には用途やネットワーク条件を記載できますが、パスワードは含めないでください。複数の接続先を切り替える際に用途を見分けやすくなり、一覧のスクリーンショットで認証情報が漏れるのを防げます。

07 / HYSTERIA2

Hysteria2：QUIC転送を使う前にUDPの条件を確認

設計の目的とネットワークの前提

Hysteria2はQUICを基盤にしたプロキシ転送方式で、複雑なネットワーク環境でのデータ転送と輻輳制御を重視しています。QUICはUDP上で動作し、TLSと組み合わせて安全なハンドシェイクを行います。一つの接続内に複数のデータストリームを構成でき、単一のTCPバイトストリームとは異なる方法で処理されます。ただし、共有する接続は全体の帯域、輻輳、サーバーのリソースの影響を受けます。複数ストリームがあるからといって、ほかの通信の影響を一切受けないわけではありません。プロトコル名だけから実際の通信速度を推測しないでください。

利用前に最も重要なのは、UDPの経路が使えることです。Webページを正常に閲覧できるネットワークでも、UDPの入口が制限されたり、異なる方法で処理されたりすることがあります。TCPを使う設定が正常だからといって、Hysteria2の入口も使えるとは限りません。接続できない場合は、まずドメイン名の解決、ポート、UDPの到達性を確認し、その後で認証とTLSを調べてください。基盤となる経路が確立していない場合、帯域の設定やKeepaliveを追加しても、足りないネットワーク条件を補うことはできません。

認証、TLS、難読化の設定

手元のHysteria2設定には通常、サーバーアドレス、ポート、認証情報、TLS関連の項目が含まれます。認証情報はサーバー側の指定どおりにすべて入力してください。別のプロトコルのパスワードをそのまま試すことはできません。TLSの名前と証明書の確認方法は前述のとおりです。接続先、Server Name、証明書に含まれる名前の関係が正しい必要があります。UDPを使っていても、証明書の有効期限、名前、信頼チェーンは重要です。ハンドシェイクの失敗をすべてUDPの制限と決めつけないでください。

サーバー側で難読化が有効になっている場合は、クライアントでも対応する種類やパスワードなどを設定します。難読化、認証、TLSは別の層でそれぞれ役割が異なります。一つの項目が正しいからといって、ほかの項目を無視しないでください。難読化を使わない入口に、不明な設定を追加する必要もありません。読み込み済みの設定と手動で作り直した設定で結果が異なる場合は、項目を一つずつ比較してください。特に、簡略化された情報では省略されやすいオプションを確認します。

帯域の設定値は速度テストの結果ではない

設定によっては、上り・下りの帯域を指定する項目があり、特定の輻輳制御方式の動作に関わる場合があります。ここに入力する値はクライアントがリアルタイムで測定した速度ではなく、サーバーがその速度を継続して提供するという意味でもありません。サーバー側の方針やネゴシエーション方法によって、値が反映されるかどうかが変わることがあります。数値を大きくしても実際の帯域は増えません。入力時はアプリの項目で使う単位を確認し、バイト毎秒とビット毎秒を混同したり、自分の下り速度を上りの欄に入力したりしないでください。

実際の接続速度を大幅に上回る値を設定すると、該当する方式ではキューイング、パケットロス、不安定な通信につながることがあります。低すぎる値は、利用可能な転送能力を制限する可能性があります。実際のネットワーク状況とサーバーの説明に基づいて設定し、元の設定は基準として保存してください。テストではダウンロードの継続性、操作への応答時間、ほかのアプリにキューイングの影響が出ていないかも確認します。一度だけ短時間に高い速度が出ても、設定が適切とは限りません。ある程度の時間をかけて安定性を確認してください。

iPhoneとiPadでのリソース消費を確認する

QUICの処理、暗号化、データの送受信には端末のリソースが使われます。実際の電池消費は、実装、通信量、パケットロス、無線信号の強さによって変わり、すべての端末に当てはまる結論はありません。大容量の通信テストではアプリの処理と無線通信が同時に続くため、端末が熱くなっただけで設定ミスとは判断できません。同じ通信量を使ったときの持続的な動作、バックグラウンドで再接続を繰り返していないか、電波の弱い場所や画面ロック解除後に異常が出ないかを確認すると、より参考になります。

特定のWi-Fiだけで接続できない場合は、利用が許可された別のネットワークで経路の違いを確認できます。すべてのネットワークで失敗する場合は、元の認証情報、TLS、サーバーの状態を調べてください。接続は確立するものの大容量通信が止まる場合は、すぐ別の種類に切り替えるのではなく、経路上のパケットロス、データサイズ、帯域設定、リモート側のリソースを確認します。切り替えが有効なのは、サーバーが新しいプロトコルを実際に提供している場合だけです。「使えない」だけで済ませず、どの段階で失敗したかと簡潔なエラー内容を残すと、後から原因を判断しやすくなります。

テストが終わったら、繰り返しの速度テストや不要な継続通信を停止し、普段の設定に戻して電池の状態を確認してください。サブスクリプションの更新後だけ問題が起きる場合は、設定項目の変更を比較し、サーバー側の変更とローカルネットワークの変化を切り分けます。サブスクリプションから読み込んだ設定を手動で修正しても、次回の更新で上書きされることがあります。テスト用コピーとサブスクリプション管理下の設定を区別し、同じ問題が更新後に再発しないようにしてください。