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

02 / 共通鍵暗号を使うプロキシ

Shadowsocks：暗号化方式とパスワードはセットで確認

セッションの階層をシンプルにする設計

Shadowsocksは、プロキシ転送と共通鍵暗号を組み合わせた設計です。クライアントとサーバーは、指定された暗号化方式と鍵情報に基づいてデータをやり取りします。標準的なTLSセッションを確立してからプロキシ認証を行う方式とは異なり、基本設定では通常、アドレス、ポート、暗号化方式、パスワードを指定します。設定項目が少なくても、値を自由に入力できるわけではありません。各項目がサーバーによるデータの識別に関わるため、どれかが一致しないと接続初期に通信が終了する場合があります。

この設計を理解すると、利用上の範囲も把握しやすくなります。Shadowsocksは主にプロキシリクエストを処理するもので、完全なプライベートネットワークを自動的に構築するわけではありません。また、暗号化を行うからといって、Webサイトの証明書検証が含まれるわけでもありません。WebサイトがHTTPSを使う場合、アプリケーション層の保護はWebサイトとの接続が担い、クライアントからプロキシサーバーまでの区間はShadowsocksの方式に従って処理されます。階層ごとの保護を区別すれば、プロトコルを選んだだけで証明書やアクセス先Webサイトの警告を無視できると誤解せずに済みます。

Methodは単独で切り替える速度設定ではない

既存の設定を読み込んだら、まず暗号化方式を確認します。方式によって認証、鍵導出、データのカプセル化が異なるため、名前が新しそうだからといってクライアント側だけで変更することはできません。AEAD方式は機密性と完全性を同時に扱いますが、世代の異なるプロトコルでは鍵の形式やハンドシェイクの仕様も異なる場合があります。サーバーで指定された方式をクライアントでも使ってください。対応状況は、アプリで選択できる方式と手元のサーバー情報を確認してください。

パスワード欄に、任意の短い文字列を入力できるとは限りません。方式によっては特定形式でエンコードされた鍵を使い、別の方式ではパスワードから鍵を導出します。末尾の等号を削除したり、空白を追加したり、エンコード済みの文字列をデコードして貼り直したりしないでください。手入力では前後の空白、全角記号、改行に注意します。QRコードや共有リンクから読み込んだ場合は、一覧のメモ名だけでなく、解析後の各項目を確認してください。メモは自由に変更できますが、認証情報はメモから推測できません。

TCPで接続できてもUDP経路が使えるとは限らない

Webリクエストとリアルタイムアプリでは、異なる通信方式を使う場合があります。サーバーのTCPポートに到達できても、同じポートでUDP転送が有効とは限らず、現在のネットワークで該当データの送受信が許可されているとも限りません。Webページは開くのに音声通話やリアルタイム機能に問題がある場合は、まずサーバーが必要なUDP転送に対応しているか確認し、次にクライアントの設定とネットワーク経路を調べます。この現象だけでパスワードの誤りと判断しないでください。パスワードが完全に間違っていれば、基本的なプロキシリクエストも通常は完了しません。

既存の設定には、追加の通信方式や難読化の項目が含まれることもあります。これらはすべてのShadowsocksサーバーで必要な項目ではなく、別の設定を参考にして追加してはいけません。サブスクリプションから読み込んだ設定は動作するのに、手動で作り直すと失敗する場合は、暗号化方式、パスワード、アドレス、ポート、追加項目を2つの設定で比較してください。Global Routingを何度も切り替えても解決にはなりません。これらの項目を使う前提は、サーバー側が該当機能を有効にしていることです。クライアントの設定だけでサーバーに対応機能を追加することはできません。

iPhoneで性能の違いを考える

Shadowsocksの実際の処理負荷は、使用する暗号化アルゴリズム、端末のハードウェア、通信データ量によって変わります。外側のハンドシェイクが少ない設計は短時間の接続で有利な場合がありますが、実際のWeb閲覧には名前解決、Webサイトからの応答、複数のリソース取得も含まれます。プロトコルの階層数だけで表示速度を判断できません。長時間のデータ転送では、スループットがサーバーの帯域、無線電波、アクセス先Webサイトによって制限される場合もあります。ボトルネックが暗号化処理にない場合、方式を変更しても通信速度が自動的に上がるわけではありません。

消費電力を比較する際は、接続方法と無線環境も含めて確認します。電波が弱いと、再送や無線モジュールの稼働がアルゴリズムの違いより目立つことがあります。頻繁なテストやサブスクリプションの更新も通信量を増やします。比較する際は同じネットワーク、同じタスク、ほぼ同じ画面状態にそろえ、接続を維持するだけの状態と継続的なダウンロードを区別してください。システムのバッテリー統計に表示されるアプリの割合を、そのままプロトコルの消費電力とみなすことはできません。集計期間やバックグラウンド処理が一致しているとは限らないためです。

Shadowsocksを使い続けるのに適しているのは、サーバーが対応方式を明示しており、設定項目がそろっていて、実際の通信でも問題がない場合です。調整が必要なら、まず設定値の整合性を確認し、次に名前解決と通信方式を確認します。共有リンクのプレフィックス、エンコード、パスワード部分を特定できない場合は、共有リンクとサブスクリプションの形式を参考に、情報の種類を確認してください。共有リンク全体をパスワード欄に入力したり、サブスクリプションURLをサーバーアドレスとして使ったりしないでください。

04 / TLSによる身元確認

Trojan：TLS接続内でパスワード認証

先に安全な接続を確立し、その後プロキシ情報をやり取り

TrojanはTLSで保護された接続を確立し、その中で認証とプロキシリクエストをやり取りする設計です。標準的なセキュア通信の機能とプロキシプロトコルを組み合わせているため、パスワードが正しいだけでは十分ではありません。証明書、名前、外側の接続も一致する必要があります。この順序を理解することが重要です。TLSのハンドシェイクに失敗している場合、プロキシのパスワードを変更しても解決しません。ハンドシェイク後に認証を拒否された場合、証明書名を何度変更しても、間違ったパスワードは修正されません。

この設計は、共通鍵でプロキシのペイロードを直接保護する方式とは異なります。TLSではサーバーが検証可能な身元情報を提示し、接続に必要なパラメーターをネゴシエートします。保護されるのはクライアントからサーバーまでの区間であり、アクセス先Webサイト自体のHTTPS検証を置き換えるものでも、サーバーからWebサイトまでのすべての動作を保証するものでもありません。エラーを読むときは、プロキシサーバーの証明書の問題か、ブラウザーに表示されたアクセス先Webサイトの証明書の問題かを区別してください。両者は別の接続です。

Server Nameは証明書に対応した値を指定

サーバーアドレスは接続先の入口を指定し、Server Nameは通常、TLSでの名前通知と証明書検証に使われます。既存の設定でアドレスを使って接続しつつ、TLSにはドメイン名を指定していても、必ずしも誤りではありません。サーバーがそのドメイン名の証明書を使っている可能性があります。反対に、アクセス先Webサイトの名前に変更しても意味はありません。どの名前が証明書の対象か、元の設定で何を指定しているかを確認してください。見慣れたドメイン名かどうかで判断しないでください。

証明書の検証結果は、有効期限、信頼チェーン、名前、端末の時刻に左右されます。端末の日付が大きくずれていると、本来有効な証明書も異常と判定される場合があります。サーバーの証明書が更新された場合や中間証明書チェーンが欠けている場合も、クライアントが接続を拒否することがあります。証明書エラーが出たら、自動日時設定、サーバー情報、証明書の状態を確認してください。安全でない接続を許可する設定を通常の修復方法にしないでください。元の設定を復元するのではなく、身元確認の前提を変えてしまうためです。

パスワードと追加項目も一つずつ確認

Trojanのパスワードはサーバーの認証情報であり、端末のロック解除用パスワードでもApp Storeの購入情報でもありません。貼り付ける際は全体を保持し、末尾に改行が入らないようにします。パスワードに特殊文字が含まれる場合、共有リンクのエンコードやデコードによって表示が変わることがあります。読み込み後は実際の設定項目を確認し、エスケープ済みの文字列を手動で再度エスケープしないでください。メモにTrojanと書かれているだけでは、リンクの内容とクライアントのTypeが一致しているか確認できません。

既存のサーバー構成には追加の通信方式が含まれる場合があり、サーバー側も同じ設定になっている必要があります。説明がないのにWebSocketを追加したり、Pathを変更したり、用途の分からないネゴシエーション値を入力したりしないでください。外側の接続先で特定のHost、Path、ハンドシェイク条件が必要な場合、いずれかが欠けると、別のサービスがリクエストを受け取ることがあります。同じドメイン名の通常のWebページが開いても、そのことからプロキシの認証経路やポートが正しく設定されているとは判断できません。

ハンドシェイク、接続の再利用、バックグラウンド動作の違い

TLSハンドシェイクでは暗号処理とネットワーク上の往復が発生するため、新しい接続を作る際に負荷がかかります。確立済みの接続で後続データを運べるか、どのように再利用するかはプロトコルと実装によって異なります。Webページを時々開く使い方では、継続的なスループットより接続確立までの時間が目立つことがあります。長時間の動画再生やデータ転送では、ハンドシェイクはタスク全体の一部にすぎません。Connectivity Testの一度の数値だけで、動画全体の視聴感や一日のバッテリー消費を判断しないでください。

iOSのバックグラウンド通信は、アプリのタスク、システムのスケジューリング、現在のネットワークにも左右されます。頻繁に切断して再接続するとハンドシェイクが増える一方、多数のリクエストを長時間維持すると無線モジュールが稼働する時間が長くなる場合があります。適切な設定とは、常時接続または常時切断のどちらかに決めることではなく、実際の使い方に合わせて接続を管理することです。On Demandは接続を開始する条件を制御しますが、Trojanのパスワードや証明書を変更するものではなく、ハンドシェイクの負荷を自動的になくす設定でもありません。

サーバーが有効な証明書、明確なパスワード、必要な設定情報を提供している場合、Trojanは標準的なTLSによる身元確認を前提とした選択肢になります。選ぶ際は、証明書の状態を確認できるか、エラーを段階ごとに切り分けられるかを重視してください。TLSという名称だけで品質を判断してはいけません。証明書の問題とドメイン名解決の問題は、表面上似た症状になることがあります。DNS名前解決のトラブル対処も参照し、どの段階で失敗しているか確認してください。

06 / ネットワーク層トンネル

WireGuard：鍵、アドレス、ルーティングをまとめて理解

パスワードだけを置き換えるプロキシではない

WireGuardはネットワーク層の暗号化トンネル向けに設計されており、公開鍵による身元確認と固定された暗号設計を使ってピア間の接続を確立します。1回のプロキシ宛先だけを指定するプロトコルとは異なり、トンネル内のアドレス、接続相手、通信を許可するアドレス範囲も設定します。そのため、設定にアドレス範囲や鍵が含まれるのは無駄な項目ではなく、ネットワークの関係を記述するために必要です。通常、サーバーアドレスとパスワードだけではWireGuardの設定を復元できません。

この設計は、トンネルの構成が明確なネットワークに適していますが、双方でアドレスとルーティングの認識を一致させる必要があります。ShadowrocketでWireGuardを出口として使う場合も、クライアント側のルール選択とWireGuard設定内のアドレス制約を区別してください。前者はリクエストをその出口に渡すかどうかを決め、後者は該当する通信をトンネルで受け取り転送する方法に影響します。両方の制約がある場合、片方だけを確認すると矛盾した結論になることがあります。

Private KeyとPublic Keyは相互に置き換えられない

Private Keyはこの端末の身元情報にあたるため、適切に保管してください。Public Keyは相手側がその身元を識別するために使います。クライアントはサーバーの公開鍵を知る必要があり、サーバーにはクライアントに対応する公開鍵を設定する必要があります。サーバーの公開鍵を端末のPrivate Key欄に入力してはいけません。文字の見た目が似ていても、鍵を相互に置き換えられるわけではありません。設定にPreshared Keyがある場合は追加の共有情報です。双方で一致させる必要があり、根拠なく追加したり、片側だけ変更したりしないでください。

トンネル内アドレスはサーバーの公開アドレスではありません。前者はトンネル内のネットワーク構成に使い、後者はUDPデータを実際に受信するEndpointを指定します。アドレスを入力する際は、元の設定にあるプレフィックス長を維持してください。トンネル内アドレスをEndpointに誤って入力すると、クライアントが現在のネットワークから接続先に到達できない場合があります。ポートもEndpointの構成要素であり、一般的な例から推測してはいけません。元の設定でドメイン名を使っている場合は、接続前にそのドメインを名前解決できる必要があります。

Allowed IPsと接続維持設定の範囲

Allowed IPsは、ピアに関連する許可アドレス範囲を指定し、ルーティングや送信元の制約にも関わります。実際の表示や動作は実装によって異なります。範囲が狭すぎるとトンネル経由でアクセスする必要がある宛先を除外することがあり、広すぎると既存のネットワーク設計と競合する場合があります。「すべて使えるようにする」ために、元の値を無造作に置き換えないでください。プライベートアドレスにアクセスする場合は、ローカルネットワークに重複するアドレス範囲がないかも確認します。アドレスの重複で通信経路が誤ることはありますが、鍵の認証失敗とは別の問題です。

Persistent Keepaliveは必要に応じてNATのマッピングを維持する機能で、特に端末が一部の変換装置の背後にあり、相手からのデータを受信する必要がある場合に使われます。間隔を短くするほど確実になる汎用設定ではありません。間隔が短すぎると、アイドル状態でもデータ通信が増え、モバイルネットワークでは無線の休止に影響することがあります。元の設定で指定されていない場合は、まずマッピングの期限切れによる復旧問題が実際にあるか確認し、ネットワークの状態に応じて設定してください。決まった間隔を無条件に追加しないでください。

MTUと「一部のWebページが止まる」問題

トンネルではデータのカプセル化によるオーバーヘッドが加わるため、実際の経路で扱えるパケットサイズを考慮する必要があります。MTUが適切でないと、小さなリクエストは通る一方で、大きな応答や特定のサイトで読み込みが止まることがあります。その場合、すぐに鍵を変更せず、まず経路とカプセル化の条件を確認してください。MTUの調整は元の値を基準に再現性のあるテストを行い、小幅な変更ごとに記録します。根拠なく数値をコピーすると、問題を見えにくくしたり、別のネットワークで断片化や効率低下を招いたりすることがあります。

WireGuardはUDPを使うため、ネットワークが該当する通信の往復を許可していることが前提です。Wi-Fiとモバイルネットワークを切り替えると、Endpointやマッピングの状態が変わり、復旧の状況もネットワークの方針に左右されます。UDPで接続できない場合、Persistent Keepaliveを追加しても、遮断された経路が使えるようにはなりません。まずEndpoint、ポート、ネットワークの状態を確認し、その後ハンドシェイクと実際の通信を確認します。クライアントが接続中と表示されても、トンネル内のルーティングが成功したとは限りません。

速度と消費電力の面で、簡潔なプロトコル設計が処理上有利なことはありますが、端末全体の負荷にはユーザー空間での処理、無線通信、接続維持、実際の通信量も含まれます。あらゆる状況でアプリケーション層のプロキシより優れているわけではありません。すでにネットワークで鍵とアドレスが正しく設定されている場合は、その構成に沿って使えます。一般的なプロキシの共有リンクを読み込むためだけにWireGuardへ変更する必要はありません。選定は項目数や知名度ではなく、サーバーの対応状況とネットワークの目的を優先してください。

08 / 選定と再確認

既存の条件に合うものを選び、実際の通信で確認

まずサーバーが対応していない組み合わせを除外

プロトコルを選ぶ際は、名前を比較する前に、既存のサーバーが実際に提供している接続先を整理します。Shadowsocksの設定情報しかない場合は、まず指定された方式を確認します。WireGuardの設定がそろっている場合に初めて、トンネル内アドレスや鍵を検討できます。サブスクリプションに複数の種類が含まれていても、すべての設定でサーバー、経路、通信条件が同じとは限りません。比較結果にはサーバー構成全体の違いが反映されることがあり、すべてをプロトコルだけの違いとみなすことはできません。

次に、実際の用途を明確にします。主にWebサイトを閲覧する場合は、初回表示、名前解決、短い接続の動作を重視します。継続的なデータ転送では、安定したスループットと端末温度を確認します。リアルタイムアプリではUDPや該当する転送機能への対応も必要です。既存のプライベートネットワークに接続する場合は、1回の遅延時間よりアドレス設計とルーティングが重要になることがあります。あらゆる用途を網羅する順位を追うのではなく、検証できるタスクに沿って選んでください。

再現可能なテスト手順を作る

現在正常に動作している設定を保存し、テスト中にどのSERVERを選択しているか確認します。ネットワーク、Global Routingのモード、アクセス先を固定し、関係のない大容量通信は停止してください。まず基本的な接続を確認し、次に実際のWebサイトやアプリを開き、最後に継続的なデータ転送を行います。各回について、成功したか、初回の応答に問題があったか、しばらくして切断されたかを記録します。単独の最小遅延値を追う必要はありません。偶然の最良結果より、繰り返し観察できる現象のほうが参考になります。

消費電力をテストする際は、アイドル状態で接続を維持する場合と、継続的に利用する場合を分けてください。画面の明るさ、電波の状態、タスクの時間をできるだけそろえ、端末の温度も確認します。システムのバッテリー統計は確認の手がかりであり、実験室の電力計ではありません。集計時間にはほかのバックグラウンド処理が含まれ、割合は全体の消費電力にも左右されます。条件をそろえられない場合は「現在のタスクで観察された動作」として記録し、特定のプロトコルの固定的な性質として扱わないでください。

失敗した段階に応じて切り分ける

まったく接続できない場合は、まずサーバーアドレスの名前解決とポートへの経路を確認し、次にプロトコル、認証情報、外側の通信方式を調べます。証明書エラーが明確に表示される場合は、名前、端末時刻、信頼チェーンを確認します。認証が拒否される場合は、パスワード、UUID、鍵の対応を確認してください。接続後、一部の宛先だけ失敗する場合は、ルールの一致、DNSの結果、アクセス先の状態を調べます。しばらくして接続が切れる場合は、ネットワーク切り替え、マッピングの期限切れ、継続的な大容量通信との関連を記録します。毎回パスワードから入力し直さないようにしてください。

Connectivity Testの結果は、実行されたテストの範囲を示すもので、すべての用途を確認するものではありません。テスト結果が出てもWebページが開かない場合は、複数のドメインを比較し、名前解決と最終ポリシーを確認してください。Configでのみ失敗する場合は、一時的にProxyモードと比較し、ルールによる振り分けが関係するかを判断できます。比較後は元の設定に戻し、有効性を確認できた変更だけを残してください。手順を追って設定する場合はクイックスタートガイドに戻り、複数の画面で一度に設定を変えないでください。

記録を残し、設定のずれを防ぐ

サブスクリプションの更新で接続先、設定項目、メモが変更される場合があります。更新後に問題が起きた場合は、まず設定が置き換わったか、現在どの設定を選択しているかを確認してください。サブスクリプションから作成された設定を手動で編集していると、次回の更新で変更が上書きされることもあります。機密情報を含めずに、項目の種類と発生した現象を記録できます。ただし、パスワード、秘密鍵、認証情報を含むサブスクリプションURLを公開のトラブル相談に載せないでください。画面のスクリーンショットを共有する前にも、これらの情報が写っていないか確認します。

最終的には、用途が明確で、設定の根拠をたどることができ、実際の通信で確認済みの構成を残してください。説明できない試行設定を大量に蓄積しないようにします。プロトコルは通信形式、通信方式はデータの運び方、TLSは該当する階層の保護、ルールは出口の選択を担い、どの要素もほかの役割を代替しません。購入や復元については購入済みアプリの復元方法、接続時の症状についてはよくある質問をご覧ください。設定ファイルの構造については、関連する解説記事を参照してください。この役割分担に沿って確認すれば、根拠のある範囲に変更を限定できます。