Shadowrocketのプロトコル設定
と接続タイプの選び方

Shadowsocks：シンプルなプロキシと暗号化方式

設計の背景と適用範囲

Shadowsocksは、比較的シンプルな暗号化プロキシ経路を提供することを重視して設計されています。クライアントは接続先アドレスと通信データを仕様に沿ってカプセル化し、サーバーが検証してリクエストを転送します。完全な仮想LANの仕組みではなく、Typeに選んだだけでアプリのルーティングが自動的に設定されるわけでもありません。ユーザーが押さえておくべきなのは、プロトコルの歴史より、同じプロトコル名でも暗号化方式や形式が異なる点です。サーバーが受け付ける方式と同じものをクライアントで選ぶ必要があります。名前が似ているからといって互換性があるとは限りません。

初期のストリーム暗号方式と、後に登場したAEAD方式では、データ形式と認証機能が異なります。AEADは暗号化と完全性検証を組み合わせ、改ざんされたデータを検出できます。ただし、AEADという名前を含む方式がすべて互換性を持つわけではありません。新しい方式の中には、鍵の長さやエンコード形式に特別な要件があるものもあります。入力時は手元にあるサーバー設定を基準にしてください。クライアントの一覧にない方式を、名前の似た別の方式で代用することはできません。

Address、Port、Method、Password

Add ServerでShadowsocksを選択したら、まずAddressとPortを確認します。Addressはプロキシサービスを提供するホスト名またはIPアドレスであり、サブスクリプションのURLやアクセス先Webサイトのアドレスではありません。Portはそのサービスが待ち受けるポートです。ホスト名にWebページのパス全体を含めないでください。IPv6アドレスも各フィールドの指定に従って入力します。QRコードやサブスクリプションから取得した情報は、まず自動解析された内容を維持し、元の情報と項目ごとに照合してください。手作業で分割する際にポートや追加パラメーターを落とすのを防げます。

Methodは両者が鍵と暗号文をどのように扱うかを決め、Passwordは一文字ずつ完全に一致させる必要があります。通常のパスワードから鍵を導出する方式もあれば、所定の形式の鍵情報を必要とする方式もあります。「パスワードが長いほど互換性が高い」と単純に考えることはできません。コピー時は末尾の改行、全角記号、見えない空白に注意してください。サーバーの管理画面に表示されたエンコード済み文字列を、独自に再エンコードしないでください。認証に失敗した場合は、すぐにDNSを変更するのではなく、まずMethodとPasswordの組み合わせを確認します。

UDP、追加トランスポート、iOSでの動作

ShadowsocksではTCPとUDPの経路をそれぞれ確認する必要があります。Webページが開けても、ゲームや通話のデータグラムが届くとは限りません。クライアントの設定、サーバーの転送機能、途中のネットワークがUDPを制限する場合があります。接続先アプリが別のポートを使うこともあります。サーバー情報に追加トランスポートの設定が含まれる場合は、現在のクライアントに対応する項目があることを確認し、内容を正確に入力してください。基本のプロトコル名が同じでも、追加トランスポートの互換性まで同じとは限りません。

iPhoneでは、比較的シンプルなデータのカプセル化によって処理負荷を抑えられる可能性がありますが、実際の速度は暗号化方式、デバイスの性能、ネットワーク経路にも左右されます。大容量のダウンロードを続けると処理負荷が表れやすく、メッセージをたまに開く程度なら、接続の確立や無線の起動のほうが重要な場合もあります。プロトコルの構造がシンプルだから必ず電池消費が少ないとは言えません。また、1回の速度テストで出た高いピーク値を、継続的なスループットとみなすべきではありません。

トラブル対処は三つの状況に分けて考えます。接続先への接続が常にタイムアウトする場合は、ホスト、ポート、現在のネットワークを確認します。接続直後に失敗する場合は、MethodとPasswordを確認します。Webページは正常でも一部のアプリで失敗する場合は、UDP、ルールの一致、名前解決を確認します。Subscribeから取得した項目を変更する場合は、更新で修正内容が上書きされないよう、元の値を残して複製した項目で試してください。この順序で確認すれば、関係のない設定を次々に切り替えるより効率的です。

WireGuard：鍵、アドレス、ルートプレフィックス

一般的なプロキシとは設定項目が異なる理由

WireGuardはIPパケットを運ぶトンネル方式で、固定された最新の暗号構成要素と、比較的シンプルなハンドシェイクを採用しています。ユーザー名とパスワードの入力欄で接続先を識別するのではなく、鍵で相手との身元関係を確立し、ピアを通すアドレス範囲をルーティングに関連付けます。そのため、ShadowrocketでWireGuardの項目を見るときは、鍵、トンネルアドレス、Endpoint、AllowedIPsを分けて理解してください。一般的なプロキシの「アドレスとパスワード」の入力方法をそのまま当てはめることはできません。

PrivateKeyはローカル側の秘密鍵で、PublicKeyは通常、ピアの公開鍵を指します。どちらもエンコードされた文字列に見えますが、識別する対象と方向が異なります。秘密鍵をピアの公開鍵欄に入力したり、文字列の長さが似ているからと入れ替えたりしないでください。PresharedKeyは任意の追加共有情報です。双方で使うと合意している場合にのみ入力します。独自に値を追加しても利用可能性は高まらず、かえって双方のハンドシェイク条件が一致しなくなります。

Endpointとトンネルアドレス

Endpointは、ピアがUDP通信を受け付ける実際のホストとポートです。トンネルのAddressは、ローカル側がトンネル内で使うアドレスです。両者は異なるレイヤーにあります。外部から到達できる入口があっても、内部アドレスの割り当てが正しいとは限りません。内部アドレスが正しくても、入口のポートに到達できなければ接続できません。手元の設定を画面に入力する際は、アドレスのプレフィックス長を維持し、IPv4とIPv6をそれぞれ資料どおりに設定してください。ローカルLANのアドレスを独自に置き換えないでください。

AllowedIPsは、どの宛先アドレスをピアに渡すかと、受信データがどの送信元アドレスに属するべきかの両方に関係します。広いプレフィックスはより多くの宛先を含み、狭いプレフィックスは指定されたネットワークだけを対象にしますが、一般的なWebサイトへのアクセス許可リストではありません。クライアントのGlobal Routing、Configのルール、システムのネットワーク拡張も、通信がこの項目に入るかどうかに影響します。そのため、広い範囲のプレフィックスが表示されているだけで、すべてのアプリがトンネルを使うと判断することはできません。

MTU、キープアライブ、モバイルネットワーク

MTUはトンネル内のパケットサイズ上限を決めます。下位経路が大きなカプセル化パケットを運べないと、小さなリクエストは通る一方、大きなページの読み込みやアップロードが止まることがあります。MTUの変更は、認証とルーティングの誤りを除外してから行い、元の値を残して段階的に確認してください。特定のネットワークで有効だった値を、すべてのデバイスに共通の値と考えないでください。IPv6とIPv4で経路が異なる場合も、Webページの読み込みを一度見るだけでなく、個別にテストしてください。

PersistentKeepaliveは、所定の間隔で一部のネットワークアドレス変換のマッピングを維持するために使われます。頻度を上げれば安定するというものではありません。間隔を短くするとバックグラウンド通信や無線の起動が増える場合があり、長くするとマッピングの寿命に合わない場合があります。まず、通信がない状態の後に接続を復旧できない問題が実際にあるか確認し、サーバーの推奨に従って調整してください。モバイルネットワークの切り替え時には、入口への到達性、アドレスの変更、アプリの再試行動作も復旧に影響します。

WireGuardのハンドシェイク成功は、鍵の関係と一部の通信条件が成立したことを示すだけです。内部サービスへ接続するには、ピアの転送、戻りルート、アドレス割り当て、DNSも正常である必要があります。ハンドシェイクは成功しているのに通信できない場合は、ルールの一致を調べる前に、AllowedIPs、トンネルアドレス、サーバー側の戻り経路を確認してください。各項目の詳しい説明はWireGuard設定ガイドをご覧ください。問題を共有する際は、秘密鍵と実際の内部ネットワーク情報を伏せてください。

用途別の選び方：ルールの確認とトラブルの切り分け

名称ではなく、必要な機能から選ぶ

一般的なWeb閲覧や日常的なアプリには、手元の情報に設定項目が揃っていて、安定して接続できるものを選びます。プロトコル名だけを理由にサーバーを変更する必要はありません。内部ネットワークやアドレスのルーティングが必要な場合は、WireGuardのピアと許可されたネットワーク範囲を確認します。組織からHTTPまたはSOCKS5の入口が提供されている場合は、認証とアクセス権を確認してください。UDPを使うアプリでは、必要な機能を個別にテストします。必要な条件を満たさない場合、設定の問題か、サーバーの機能か、ネットワークの制限かを判断します。

VMess、VLESS、Trojanを選ぶ際は、それぞれに必要なトランスポートとTLSの組み合わせを維持してください。Shadowsocksでは暗号化方式とデータグラムへの対応を確認し、Hysteria2ではUDP経路と速度設定を確認します。Typeを切り替えるだけで、別のプロトコル向けのサーバーを使えるようにすることはできません。手元のサブスクリプションに複数のタイプがある場合は、元の項目を残して一つずつテストしてください。UUID、パスワード、トランスポートの設定を混ぜて、サーバー側で用意されていない組み合わせを作らないでください。

まず、ルールが実際にそのプロトコルを使っているか確認する

プロトコルの確認とルールの確認は、分けて行います。まず、明確なテストリクエストでサーバーが使えることを確認し、その後Configで対象が想定したポリシーに振り分けられているか確認してください。以下はマッチ順序を説明するためのShadowrocket .confルール例で、完全な設定ではありません。使用する前に、現在の設定で使えるPROXYポリシーが定義されていることを確認してください。例にあるドメインは説明用の文字列であり、アクセスすべきサービスを示すものではありません。

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

ルールは通常、上から順に照合され、一致した時点で該当するポリシーが適用されます。DOMAIN-SUFFIXは指定したドメインとサブドメインに一致します。IP-CIDRはアドレス範囲を示します。no-resolveは、ルールの照合のためにドメイン名を積極的に解決することを避ける指定ですが、すでに接続先アドレスがある場合は、アドレスによる照合に使われる可能性があります。GEOIPはIPアドレスの位置情報データベースに基づいて判定するもので、Webサイトの所属地域と同じ意味ではありません。FINALは最後のフォールバックとして使います。先に判定したいルールより後に置かないと、後続のルールが意図どおり動作しないことがあります。

対象がREJECTに一致した場合、ポリシーの段階で接続がブロックされているため、プロトコルを変更しても解決しません。DIRECTに一致した場合は、意図した動作かどうかを先に確認してください。拒否ポリシーの役割と同じドメインの内容に関する範囲は、REJECTルールの解説をご覧ください。ルールを調整する際は設定を複製してから行い、一つの接続先を確認するために、ほかのアプリの既存の経路まで変えてしまわないようにしてください。

失敗した段階から確認範囲を絞る

ドメイン名でのアクセスだけが失敗し、接続先を直接指定したテストが正常な場合は、名前解決を行う場所、戻りアドレスの種類、DNSリクエストのルーティングを確認してください。証明書の検証を変更するだけで、すべての問題を解決しようとしないでください。IPv6ネットワークでのみ問題が起きる場合は、サーバーの入口、接続先アドレス、トンネルアドレスがそれぞれ対応しているか確認します。使える設定に戻してから必要なルールを一つずつ追加すると、どの変更が障害を引き起こしたか特定できます。原因の説明しにくい設定を残さずに済みます。

再現できる結果を記録する

トラブル対処が終わったら、使用したプロトコル、外側のトランスポート、成功したテスト内容、残っている制約を記録し、不要になった検証用の項目を削除してください。Subscribeの更新でサーバー設定が変わったり、システムのネットワーク環境が変わったりすると、以前の結果が当てはまらなくなることがあります。新たな問題が起きた場合は、以前の変更を機械的に繰り返すのではなく、現在の情報を確認してください。設定、QRコード、ログには機密情報が含まれる場合があります。共有前に一つずつ確認し、エクスポートしたファイルをそのまま公開しないでください。

操作手順を最初から確認する場合は使い方ガイドへ、現象から簡単な回答を探す場合はよくある質問をご覧ください。このマニュアルでは、タイプの選択をサーバー情報に基づいて行い、設定変更のたびに検証できる理由を持つことを目指しています。プロトコル名だけで接続条件の確認を済ませることはできません。