Shadowrocket
プロトコルの種類と設定項目

設計の背景と適用範囲

Shadowsocksは、比較的シンプルなプロトコルで暗号化されたプロキシ転送を行う設計です。クライアントが接続先をサーバーに伝え、サーバーが接続先への通信を確立します。基本認証にウェブサイトの証明書は使わず、クライアントとサーバーで共有するパスワードと暗号化方式を主に利用します。この違いを理解すると、設定項目を正しく見分けられます。一般的なShadowsocks設定ではPasswordとMethodの両方が必要です。別プロトコル用のパスワードをそのまま流用したり、ポート番号が同じだからといって異なるサービスを相互に使えると判断したりしないでください。

暗号化方式によって、メッセージ形式や鍵の要件が異なる場合があります。新しい方式と古い方式の違いは単なる「強弱」ではなく、鍵のエンコードや長さ、実装との互換性にも及ぶことがあります。サーバー側で指定された方式をクライアントでも選択してください。該当する項目が見つからない場合は、似た名前の選択肢で代用せず、情報が現在のクライアントに対応しているか確認しましょう。読み込み後も方式名を確認し、特にサブスクリプションの変換時に項目が抜けていないか注意してください。

アドレス、ポート、パスワード、方式を一つずつ確認

Serverにはサーバーのドメイン名またはIPアドレス、Portには実際に待ち受けているポート番号を入力します。通常、アドレスにウェブページのパスは含めません。ポート番号をアドレス欄に混ぜないでください。Passwordは提供された情報をそのまま保存し、コピー時の空白、改行、全角文字に注意します。Methodは具体的な暗号化方式を示す項目で、任意の好みで選ぶものではありません。アドレスの名前解決はできるのに接続に失敗する場合は、ポートと方式も確認してください。ドメインでウェブページが開けることは、プロキシ用ポートが正常である証拠にはなりません。

一部の設定には追加の通信パラメーターがありますが、すべてのShadowsocksサービスで共通して必要なものではありません。手元の情報に明記されている場合にのみ有効にし、対応する名前と値を一致させてください。別の設定で見かけた項目を、現在の接続にも追加するのは避けましょう。余分なカプセル化によって、サーバーが想定するデータ形式が変わることがあります。読み込んだ設定と手入力した設定に違いがある場合は項目ごとに比較しますが、元の情報を失わないよう、まず読み込み済みの項目を参照用に残してください。

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

ウェブ閲覧はTCPで完了することが多い一方、リアルタイム通信、一部の名前解決、QUICを使うアプリではUDPが必要になる場合があります。ShadowsocksでTCPとUDPを転送するには、それぞれ条件を満たす必要があります。サーバーが対応していること、ネットワークで該当する通信が許可されていること、クライアント設定で無効になっていないことを確認してください。ウェブは表示できるのにリアルタイム機能が使えない場合は、この経路を調べましょう。一度ウェブページが開けただけで、あらゆるアプリに適した接続と判断しないでください。逆に、一つのアプリで失敗しても接続全体が使えないとは限りません。

iPhoneやiPadでは、シンプルな転送方式は確認すべきカプセル化の層が少ないことを意味する場合がありますが、常に速く、電力消費も少ないとは限りません。端末のチップによるアルゴリズム処理効率、長時間接続の数、ネットワーク上の再送などで結果は変わります。同じ設定がWi-Fiでは正常でモバイル通信ではタイムアウトする場合は、まず接続先ポートとネットワーク到達性を比較してください。高負荷時だけ明らかに遅くなるなら、サーバー負荷と持続的なスループットも確認します。プロトコル名だけで結論を出すことはできません。

トラブルは「情報が揃っているか」「接続先に到達できるか」「認証情報が一致するか」「必要な用途に対応しているか」の四段階で確認できます。まずサブスクリプションの更新が成功しているかを確認し、次に現在選択中の項目を確認します。項目を編集したものとは別の設定をテストしていないかにも注意してください。認証エラーならパスワードと方式、タイムアウトならアドレス、ポート、現在のネットワークを確認します。一部のリクエストだけ異常な場合は、ルールとUDPを調べましょう。設定を複数同時に試行錯誤せず、原因と結果の関係を明確に保てます。

手元のサーバーがShadowsocksのみに対応しているなら、設定が完全に一致した接続をそのまま使えばよく、プロトコル名を変える必要はありません。複数の利用可能な設定をお持ちの場合は、同じ接続先と近い時間帯で、ウェブの初回表示、持続的な通信、バックグラウンド待機時の動作を比較しましょう。「軽量」「高速」といった評価をプロトコルに付けるより、どの段階で改善したかを記録するほうが、ネットワーク条件が変わった後の判断にも役立ちます。

証明書の識別情報とユーザーパスワードを分けて考える

TrojanはTLS接続の内側にプロキシセッションを確立します。まずTLSで保護された通信路を作り、その中でプロトコル認証と接続先の情報を送信します。ここには異なる二つの識別情報があります。証明書は接続先サーバーの検証に使い、Passwordはクライアントにアクセス権があることを示します。パスワードが正しくても証明書名の誤りは解決できず、証明書が有効でもサーバーがパスワードを受け入れたとは限りません。すべてをパスワードの誤りと決めつけず、ハンドシェイクの順序に沿って確認してください。

この方式ではTLSが多くのセキュリティ上の役割を担うため、サーバー名、証明書の有効期限、端末の信頼条件が特に重要です。ただし、TLSの設定項目をすべて手入力する必要があるという意味ではありません。サブスクリプションには通常、必要な設定が含まれています。まず読み込んだ設定を維持し、エラーに応じて不足している項目を確認しましょう。情報が揃っていない状態で名前を次々に試すと、別のサーバー接続先に到達して、原因がさらに分かりにくくなることがあります。

Server、Server Name、証明書チェーン

Serverはネットワーク接続で実際にアクセスするアドレス、Server NameはTLSハンドシェイクと名前検証で重要な役割を果たす情報です。ドメイン名で接続する場合は同じ値になることがよくありますが、IPアドレスで接続する場合も、Server Nameには元のドメイン名を保持する必要があることがあります。証明書の検証には有効期限と信頼チェーンも関わるため、名前が正しいだけでは不十分です。証明書の期限切れや中間証明書の設定不備がある場合は、クライアントのパスワードを何度も変えるのではなく、サーバー側を修正する必要があります。

端末の時刻のずれ、ネットワークの認証ページ、誤った名前解決によって、似たようなTLSエラーが発生することがあります。公共Wi-Fiのウェブ認証が済んでいないと、接続が認証ページに転送される場合があります。名前解決で誤ったアドレスが返されると、そのサービスとは無関係の証明書を持つサーバーに接続する可能性もあります。こうした問題では、まずネットワーク自体が正常に使えることを確認し、次にドメインの名前解決結果とServer Nameを調べましょう。接続先を確認する前に、認証情報を追加で送信したり、信頼する範囲を広げたりしないでください。

認証、通信方式、用途への対応範囲

TrojanのPasswordは大文字・小文字や記号も含めて正確に保持してください。サブスクリプションのURL全体をそのまま入力してはいけません。手元の情報で追加の通信方式が指定されている場合は、それもサーバー側と一致させます。一般的なTrojanでよく使われる通信方式を理由に、設定で明示された項目を削除しないでください。読み込み後は種類、アドレス、ポート、パスワード、TLS名の五項目を確認し、続けてほかの通信パラメーターを確認します。この順序で、よくある構成ミスを先に除外できます。

UDPが使えるかどうかは、サーバーの対応状況、クライアント設定、実際のネットワーク条件によって決まります。ある種のデータを転送できるプロトコルでも、すべてのアプリで同じ動作をするとは限りません。リアルタイム通信は遅延やジッターの影響を受けやすく、長時間のダウンロードはサーバーの上り帯域幅に左右されやすいものです。通常のウェブ閲覧はできるのに特定のリアルタイムアプリで問題がある場合は、その用途を個別にテストしてください。ウェブの成功を用途全体のテストの代わりにしたり、問題を隠すためにタイムアウト値をむやみに大きくしたりしないでください。

iOSで接続の再利用と再接続を確認する

TLSハンドシェイクではデータ交換と計算が発生するため、初回接続と、その後の安定した通信では負荷が異なります。短い接続を頻繁に作る場面ではハンドシェイクの回数が応答時間や電力消費に影響することがあります。一方、長時間接続を維持する場面ではこの負荷が分散され、回線品質のほうが重要になる傾向があります。関連する接続再利用の仕組みをサーバーとクライアントが使うかどうかでも結果は変わります。テストでは初回表示と連続アクセスを別々に記録し、確立済みセッションの速度を初回接続の性能と混同しないでください。

Wi-Fiからモバイル通信に切り替えると、端末のアドレスや到達経路が変わり、既存のTCP接続は再確立が必要になることがあります。切り替え後も長時間復旧しない場合は、現在の処理を止めて新しいネットワークが正常か確認してから、再接続にかかる時間を測ってください。すぐに設定を消去する必要はありません。バックグラウンドで接続に失敗し続けると、再試行と無線通信の稼働時間が増えて、バッテリー消費が増えることがあります。この場合はまず失敗の原因を調べ、暗号処理を消費の原因と決めつけないでください。

すでに安定して使えるTrojan設定をお持ちの場合、日常利用では証明書検証と認証の設定を正しく保ち、サブスクリプション更新後に意図せず上書きされていないか確認することが重要です。ほかのプロトコルと比較する場合は、ネットワーク経路、接続先、テスト時間をできるだけ揃え、接続全体を比較していることを明記します。プロトコルの説明はトラブルの特定に役立ちますが、サーバーの稼働状況や接続先への到達性の確認に代わるものではありません。

まずネットワーク層のデータを扱う仕組みと理解する

WireGuardはネットワーク層のトンネルとして設計されており、特定の接続先へのプロキシ接続とは考え方が異なります。接続先アドレスのほかに、端末側のアドレス、鍵による識別情報、トンネルに流すアドレス範囲が必要です。アプリで接続を一元管理しても、こうしたネットワーク層の条件はなくなりません。ドメイン名とパスワードだけをもとに設定を組み立てず、完全な設定情報を入手してください。トンネルアドレスやピアの公開鍵がなければ、通常、想定どおりの通信は確立できません。

WireGuardでは公開鍵で通信相手を識別します。端末側の秘密鍵は自分の身元を証明し、ピアの公開鍵は接続先の身元を指定します。これらは入れ替えて使える二つの文字列ではありません。端末側の秘密鍵は外部に漏らさず、サーバー側にはそのクライアントに対応する公開鍵を設定する必要があります。端末に新しい鍵を入力しただけで、サーバーが自動的にその鍵を認識するわけではありません。管理者から設定が提供されている場合は、両者で合意済みの鍵の組み合わせを保持し、むやみに再生成して上書きしないでください。

Endpoint、Address、Allowed IPs

Endpointはトンネルの接続先を示し、通常はホスト名とUDPポートで構成されます。Addressはトンネル内で端末側に割り当てられるアドレスで、サーバーのグローバルアドレスではありません。WireGuard本来の意味では、Allowed IPsは宛先のルーティング範囲と、ピアに許可するアドレス範囲の両方に関係します。アプリへの統合後の具体的な処理は、アプリの設定も踏まえて確認してください。それぞれの役割を理解していれば、「ハンドシェイクには成功したのにアクセスできない」場合を切り分けやすくなります。認証のハンドシェイクが成功しても、すべての接続先に正しい経路があるとは限りません。

組織内ネットワークにアクセスする場合は、対象のネットワーク範囲が提供された設定と一致し、サーバー側に転送経路と戻り経路がある必要があります。端末が接続中のWi-Fiと接続先の内部ネットワークでアドレス範囲が重複していると、ルートの選択に曖昧さが生じることもあります。この場合、鍵を何度も変えても解決しません。まず宛先アドレスが実際にどの経路へ向かうか確認してください。IPv6を使う場合も、対応するアドレスとルートがあるか確認します。IPv4が使えるからといって、もう一方のアドレス空間も使えるとは限りません。

Keepaliveとモバイル通信のバランス

WireGuardはUDPを使います。モバイル端末がアドレス変換装置を経由して接続先にアクセスする場合、アイドル状態のマッピングが期限切れになることがあります。Persistent Keepaliveは、定期的なパケットを送ってそのマッピングを維持するための機能の一つで、帯域幅を増やすものではありません。Keepaliveの頻度を上げると無線通信が増え、頻度を下げると一部のネットワークでアイドル後の復旧に時間がかかる可能性があります。手元の設定に従い、アイドル後に復旧できない問題が実際にある場合に限って調整を検証してください。すべての端末に共通する固定間隔を当てはめないでください。

ネットワークを切り替えると、下位の通信経路のアドレスが変わることがあります。WireGuardには条件が整えばピアのアドレス変更に対応できる仕組みがありますが、実際の動作は新しいネットワークでのUDP到達性、アドレス変換、サーバー側のポリシーにも左右されます。Wi-Fiでは使えてモバイル通信では接続できない場合は、まずUDPの到達性を比較し、その後モバイル通信事業者のネットワークと接続先の制限を確認しましょう。アドレス変更への対応機能があっても、あらゆる切り替えで接続が中断しないとは限りません。一度すぐに復旧できたからといって、どのネットワークでも接続を維持できると判断しないでください。

MTUとDNSを分けて確認する

トンネルのカプセル化ではパケットの一部がヘッダーに使われます。経路で運べる実効サイズとMTUの設定が合わないと、小さなリクエストは通るのに大きな応答が止まることがあります。ただし、パケットロスやサーバー側の問題でも同じ症状が起きるため、変更前に元の値を保存し、一度に一項目だけ変えて同じリクエストを再テストしてください。ネット上のMTU値を共通の正解とみなしたり、ウェブページが開かないからといってすぐに極端に小さくしたりしないでください。不必要にスループットが低下するおそれがあります。

DNSはドメイン名からアドレスを取得し、ルーティングはデータの送信先を決めます。トンネルを使う場面では同時に関係することがありますが、役割は異なります。既知の内部アドレスには直接アクセスできるのに名前では失敗する場合は、まず内部DNSとその接続経路を確認してください。内部ネットワークへの接続が必要な場合は、プロトコルの速度テストよりアドレス設計の確認が重要です。通常のウェブ閲覧では、Shadowrocketの実際のポリシーに従ってリクエストが想定した接続に流れているかを確認します。

同じ条件で基準となる結果を取る

プロトコルを比較する目的は、実際の用途に役立てることです。普段のウェブ閲覧では初回応答と連続表示、ファイル転送では安定したスループットと途中切断、リアルタイム通信では遅延・ジッター・UDPの動作、内部ネットワークへの接続ではアドレス設計・DNS・戻り経路を確認します。複数の設定をお持ちの場合は、まず用途を完了できる設定を基準として選び、ほかの設定と比較してください。すべての設定で失敗する場合は、テスト環境が整っていない可能性を考え、プロトコルについて結論を出す前に現在のネットワークと接続先を確認しましょう。

有効な比較にするには、端末、ネットワーク、接続先、ルールモード、テスト時間をできるだけ揃え、バックグラウンドの大容量通信を停止し、初回接続かどうかを記録します。各設定を数回テストし、最良の一回ではなく一般的な結果を参考にしてください。Connectivity Testは、明らかに到達できない項目を見つけるのに役立ちますが、ウェブ閲覧の全体的な体験を示すものではなく、UDP、内部ネットワーク、長時間接続の正常性も証明しません。接続テスト、実際のアクセス、継続的なデータ転送を分けて確認することで、差がどの段階で生じたのか分かります。

Global Routingの三つのモードで条件を切り分ける

Configは現在の設定ルールに従って接続ポリシーを決めます。Proxyは対象の通信をプロキシ経由にし、Directは直接接続します。Configで問題が起きてもProxyでは正常な場合は、パスワードをすぐに変えるのではなく、ルールとポリシーの参照先を確認しましょう。Proxyが必要な二つのモードでどちらも失敗する場合は、接続先、認証、通信方式を調べます。Directでのテストはローカルネットワークの基準を確認するもので、直接接続で到達できない接続先があるからといって、プロキシプロトコルに問題があるとは限りません。

以下の例では、ドメインのサフィックスに応じたポリシーの選択、アドレス範囲に対する直接接続、その他のリクエストに対する最終ルールの基本構造を示します。例はShadowrocketの.confルールであり、接続可能なサーバー設定ではありません。認証情報も含まれていません。PROXYは実際の設定内に有効なポリシーが必要です。読み込みや編集の前にバックアップを取り、現在のConfigで編集対象のファイルが選択されていることを確認してください。ルールは通常、上から順に照合されます。上位にある広すぎる条件によって、下位の具体的な条件が適用されない場合があります。

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

ドメインルールは適切な段階でクライアントがドメイン情報を把握できることを前提とし、IPルールはアドレスに一致させます。両者を単純に置き換えることはできません。ウェブサイトが複数のリソース用ドメインを使う場合や、アプリがIPアドレスを直接使う場合もあるため、「トップページに想定したポリシーが適用された」からといって、関連するすべてのリクエストが同じになるとは限りません。GEOIPの結果も、アドレスデータベースや接続先アドレスの変更に影響されます。特定のウェブサイトだけをプロキシ経由にしたい場合は、指定サイトだけをPROXY経由にするルールの解説を参照し、用途に合わせて条件を追加してください。

症状に応じて確認する階層に戻る

完全なタイムアウトでは、まずネットワーク、アドレス、ポートを確認します。明確な認証エラーならパスワード、UUID、鍵の組み合わせを調べます。TLSエラーではシステム時刻、Server Name、証明書を確認してください。ハンドシェイクは成功するのに用途を実行できない場合は、接続先への到達性、DNS、UDP、ルーティングを調べます。一つのドメインだけで失敗するなら、まず既知の別の接続先をテストします。すべてのドメインで失敗し、既知のIPアドレスには到達できる場合は、DNSを重点的に確認しましょう。一度に変更する設定グループは一つにし、結果を記録してください。複数の推測を同時に設定へ反映しないでください。

再現できる記録を残してから、プロトコル変更を検討する

トラブルの記録には、端末のネットワーク、接続先の種類、Global Routingのモード、エラーが発生した段階と条件を含めてください。サブスクリプションのURL、パスワード、秘密鍵を公開する必要はありません。スクリーンショットやテキストを共有する前に、認証情報と個人を特定できる情報を削除し、再現に役立つプロトコルの種類と機密性のない項目だけを残しましょう。サブスクリプションの更新後に問題が起きた場合は、種類、通信方式、名前に関する項目を比較します。新しい設定が使えると確認できるまでは、元の項目を残し、動作する基準を失わないようにしてください。

最終的な選択では互換性と再現性のある結果を重視します。用途を完了できること、ネットワーク切り替え後に復旧すること、継続利用中に異常な再試行がないことは、テストで一度だけ記録した最高値より参考になります。読み込みや接続でよくある問題はクイックスタートのトラブル対処、画面に出る用語は用語の早見表、機能の動作は機能ガイドをご覧ください。サーバー側の認証、証明書、ルーティング範囲に関する問題は、手元の情報を提供した相手に該当設定を確認してください。関係のない項目をクライアント側で次々に変更しないようにしましょう。