- 公式マニュアル
- 機能と基本設定
Shadowrocketの機能
ルーティングと設定ガイド
まずGlobal Routingを確認し、次にサーバーとConfigをチェックします。接続のオン/オフ、ルール、DNS、通信量の統計はそれぞれ役割が異なります。ひとつのテスト結果だけで接続全体を判断しないでください。
iPhoneとiPad向け。システム要件と互換性はApp Storeのページをご確認ください。
Global Routingの3つのモード
Global Routingでは、リクエストのルーティング方法を選択します。まずHomeで現在のモードを確認し、Config、Proxy、Directから選びます。それぞれ設定、プロキシ、直接接続に相当します。操作時はアプリ内の英語表記で確認してください。モードの選択と接続のオン/オフは別の操作です。Proxyを選んでも接続が確立するとは限らず、Configを選んでもルールファイルが正しく有効になっているとは限りません。
普段のルール振り分けにはConfigを使います。選択中のサーバーで特定のリクエストを処理できるか確認する場合は、一時的にProxyと比較します。元のネットワークから直接アクセスできるかを調べるには、Directを使います。一度に変更する条件はひとつにし、同じ宛先とネットワークでテストを繰り返すと、モード、ルール、サーバーのどこに違いがあるか判断しやすくなります。
| 画面上の項目 | 処理方法と用途 | 設定後の確認 |
|---|---|---|
| Config(設定) | 有効なConfigのルールに従ってリクエストを振り分けます。直接接続、プロキシ、拒否を使い分ける場合に適しています。 | Configが選択されていること、ルールの順序、マッチ後のポリシーが想定した経路を指していることを確認します。 |
| Proxy(プロキシ) | リクエストをプロキシ経由で処理します。選択したサーバーの接続状況を比較する場合に適しています。 | 現在のサーバー、認証情報、通信パラメータを確認します。この結果だけでConfigのルールが有効だとは判断できません。 |
| Direct(直接接続) | リクエストを直接接続で処理します。現在のネットワークからのアクセス状況を確認する場合に適しています。 | ローカルネットワークとDNSを確認します。Directで失敗しても、すぐにサーバーの問題だと決めつけないでください。 |
比較が終わったら、普段使用しているモードに戻してください。ネットワークの挙動はシステム、DNS、接続状態などにも左右されます。Directは「すべての設定が無効になる」という意味ではなく、Proxyを選んでもすべてのアプリのリクエストが必ず成功するわけではありません。モードで決まるのはルーティングの方向です。認証情報の誤りや接続先サービスの停止は解決できません。
ルールの種類とポリシー
ルール振り分けでは、Configモードでリクエストのドメインやアドレスなどの情報に基づいて処理方法を決めます。Configで現在のファイルとルールを確認し、まずマッチ条件、次に末尾のポリシーを読みます。マッチ条件は「どのリクエストが対象か」、ポリシーは「どのように処理するか」を示します。両者を混同しないでください。一般に、より具体的なルールを先に置き、広い条件が先にマッチしないようにします。
ドメインやアドレスで条件を指定する
DOMAINは指定したドメインにマッチします。DOMAIN-SUFFIXはドメインの末尾、DOMAIN-KEYWORDはドメインに含まれるキーワードで判定します。IP-CIDRとIP-CIDR6はそれぞれアドレス範囲を指定し、GEOIPはアドレスの地域情報を使って判定します。USER-AGENTはリクエストから該当情報を取得できる場合に使います。すべてのリクエストにこの情報が含まれるとは限りません。ルールの種類は、実際に取得できるリクエスト情報に基づいて選んでください。
DIRECT、PROXY、REJECT
DIRECTは直接接続、PROXYはプロキシ経由、REJECTは拒否を表します。Configで独自のポリシー名を使っている場合は、そのポリシーが実際にどのサーバーやポリシーグループを指すかも確認してください。FINALは、それまでのルールにマッチしなかった場合の処理です。「最優先」のルールではありません。FINALを変更すると、個別に指定されていない多くのリクエストに影響することがあります。
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT
上記の例は構文と順序を示すもので、あらゆるネットワークに適した完全な設定ではありません。ルールを追加したら、宛先をひとつ決めてマッチ結果を確認してください。ドメインのルールが想定どおりに動かない場合は、IPアドレスでリクエストしていないか、DNSが想定した結果を返しているか、より前にマッチするルールがないかも確認します。詳しくはDNSのトラブル対処をご覧ください。
Subscribeとサーバーの管理
Subscribeは、すでに利用しているサブスクリプションの内容を読み込む機能です。Add Serverではサーバーを1台ずつ追加できます。どちらも、有効な接続情報をすでに持っていることが前提です。サブスクリプションURLは利用中のサービス提供元から入手してください。手動で追加する場合も、サーバーアドレス、ポート、パスワード、プロトコル、通信パラメータをサーバー側の設定と一致させる必要があります。名前や一般的な初期値から推測して入力しないでください。
Homeの追加メニューからAdd Serverを開き、手元の情報に合わせてTypeを選びます。サブスクリプションを読み込む場合はSubscribeタイプと対応する項目を使い、URLが完全であることを確認してから保存・更新します。QRコードを使う場合はScan QR Codeを利用できますが、先にコードの入手元と内容を確認してください。読み込み後はHomeに戻り、該当グループを展開して使用するサーバーを選び、Connectivity Testと実際のアクセスで動作を確認します。
サーバー一覧に項目が表示されても、クライアントが内容を読み込めたことを示すだけで、接続できるとは限りません。サブスクリプションの更新に失敗した場合は、URLの有効期限切れや欠落、現在のネットワークからURLにアクセスできるかを確認してください。パラメータを試すたびにグループを重複して作成しないようにしましょう。比較のために既存の項目を残す場合は、テスト対象が混同しないよう実際に選択したサーバーを記録してください。
サブスクリプションの読み込みとConfigファイルの読み込みも別の操作です。前者は通常サーバー項目の管理に使い、後者にはルールなどの設定が含まれます。入手したものがどちらか確認してから、対応する画面で操作してください。更新時の問題についてはSubscribeのトラブル対処もご覧ください。
各種プロトコルとパラメータの確認
ShadowrocketはShadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2など、複数のプロトコルに対応しています。プロトコルはクライアントとサーバー間のデータ通信方式を定めるもので、名前だけで「速度のランク」を選ぶものではありません。Add Serverでサーバー側と同じTypeを選び、その種類に必要な項目を入力してください。現在利用できる項目はアプリ内の表示をご確認ください。
TLSを使う接続では、サーバー名、証明書、関連設定を確認します。SNIが接続先アドレスと同じとは限らないため、手元の設定情報に従って入力してください。VMessやVLESSなどで使う識別情報や通信設定も、項目ごとに照合します。WireGuardの鍵やアドレスには固有の形式があり、他のプロトコルのパスワードをそのまま入力することはできません。読み込み後に似て見える項目でも、通信方式や認証項目が異なる場合があります。
設定後はConnectivity Testを実行し、次に必要なサービスへ実際にアクセスして確認します。テストに失敗したら複数のプロトコルを次々に切り替えず、パラメータをひとつずつ照合してください。証明書の検証を緩めることを一般的な解決策にしないでください。サーバー証明書や名前が一致しない場合は、まず設定情報とサーバー側の設定を確認します。プロトコルの設定には機密情報が含まれるため、トラブル対処時は必要なエラーメッセージだけを共有し、認証項目は隠してください。
Configファイル
Configではルールや関連設定を管理します。Configを開いてローカルまたはリモートの設定を確認し、使用するファイルが選択されていることを確かめてから、Homeに戻りGlobal RoutingをConfigに設定します。ファイルを保存しただけで有効にしていない場合や、Proxyモードのままの場合、そのファイルのルール振り分けを検証できません。
変更する前に、現在正常に使えているConfigのコピーを保管し、変更する項目を決めてください。特定のドメインの処理方法だけを変える場合は、該当するルールと順序だけを変更し、DNS、サーバー、FINALを同時に変更しないでください。保存後は同じ宛先でテストを繰り返し、結果を確認してから次の項目に進みます。変更と結果の対応がわかりやすくなり、元の状態にも戻しやすくなります。
リモートのConfigを更新すると、ルールやその他の設定が変わる場合があります。手動で加えた変更が残るかどうかは、設定の入手元と更新方法によって異なります。個人の認証情報を含むファイル全体を公開の場に貼り付けないでください。ファイル名だけで内容が適切かどうかを判断するのも避けましょう。内容や役割がわからない項目は、読んで確認してから有効にしてください。ルール構文の例は、そのまま使える完全な設定ファイルではありません。
On Demandによるオンデマンド接続
On Demandは、設定したネットワーク条件に応じて接続動作を開始する機能です。Config内でリクエストを振り分けるルールとは、設定する階層が異なります。前者は接続を試みるタイミング、後者は接続中のリクエストの処理方法を決めます。Wi-Fi、モバイル通信、特定のネットワーク条件に応じて接続を管理する場合は、SettingsのOn Demandで設定項目を確認してください。
まず手動で接続をオンにし、正常に使えることを確認してからOn Demandを設定してください。アプリで設定できる条件から必要なネットワーク範囲を指定し、保存後に該当するネットワーク環境でテストします。まずはネットワークの切り替えなど、再現できる条件をひとつだけ設定し、動作を確認してから条件を追加するのがおすすめです。基本の接続が成功していない状態で、自動接続を使ってトラブル対処しないでください。
手動で接続をオフにしても再び接続が開始される場合は、アプリを何度も再起動するのではなく、On Demandの条件を確認してください。テスト後にオンデマンド接続を止める場合は、関連設定と現在の接続状態の両方を確認します。ネットワーク切り替え後の動作は、システムの制御やネットワークの利用可否にも左右されます。条件を設定しても、どの環境でもすぐ接続できるとは限りません。接続状態が頻繁に変わる場合は、オンデマンド条件を一時的に無効にし、手動接続を基準に比較してください。
Dataで通信量を確認
Dataでは、クライアントが記録した通信量や接続の動きを確認できます。Dataを開き、現在の表示、集計範囲、分類方法を確認してから、アップロード、ダウンロード、関連項目を見ます。サーバー別やアプリ別の表示は、現在の画面で利用できる項目をご確認ください。統計値は操作前後の変化を比べるためのもので、サービス提供元の請求額やシステム全体の通信量をそのまま示すものではありません。
ルール振り分けを確認するときは、現在の数値と選択中のサーバーを記録し、特定の宛先に一度アクセスしてからDataの変化を確認します。バックグラウンド通信、接続時のオーバーヘッド、キャッシュ、集計範囲などが結果に影響します。特定の項目がほとんど増えなくても、それだけでルールが機能していないとは判断できません。現在のGlobal Routing、ルールのマッチ状況、実際のアクセス結果を合わせて確認してください。
Dataの累積値はリアルタイムの速度測定ではありません。速度低下を調べる場合は、ネットワークと宛先を固定し、サーバーのテスト結果、実際のリクエストにかかった時間、通信量の変化をそれぞれ確認します。統計を消去する前に、比較に必要な数値を記録し、削除の対象範囲を確認してください。画面を共有する場合は、サーバーアドレス、リクエスト先のドメイン、その他の個人情報を隠してください。数値の詳しい見方は技術ノートもご覧ください。
Settingsの基本項目
Settingsにはアプリ全体の設定がまとめられていますが、動作の一部は現在のConfigにも左右されます。変更前に元の値と設定範囲を確認し、一度に変更する項目はひとつにしてください。同じネットワークと宛先で再テストします。以下ではよくある目的ごとに確認ポイントを説明します。具体的な場所や選択肢は、現在のアプリ内表示をご確認ください。
DNS:名前解決の経路を確認
DNSはドメイン名をアドレスに変換する、接続前の重要な処理です。SettingsでDNS関連の項目を確認し、現在のConfigにも関連設定がないか確認してください。ドメイン名でのアクセスだけが失敗し、既知のアドレスを直接使うテストでは結果が異なる場合は、DNSの応答とリクエスト経路を重点的に確認します。先にプロトコルのパスワードを変更する必要はありません。DNSアドレスをむやみに追加せず、使いたい名前解決の方法、到達可能性、適用範囲を明確にしてから同じドメインでテストしてください。
Test Method:テスト結果を確認
Test MethodはConnectivity Testで使用するテスト方法を決めます。Settingsで現在の選択とテスト対象を確認し、比較したい状況に合っているか確かめてください。方法によって測定する処理が異なるため、結果を単純に横並びで比較できるとは限りません。テストに成功しても、すべてのサービスが使えるとは限りません。サーバーを比較する場合はTest Method、宛先、ローカルネットワークを固定し、複数回の結果を確認します。テスト条件の変化をサーバーの性能差と取り違えないようにしてください。
Today Widget:ウィジェットの入口を確認
Today Widgetは、システムが提供する対応ウィジェットと連携する機能です。まずSettingsで関連項目を確認し、次にシステムのウィジェット管理画面で追加できる内容を確認します。表示や操作方法はシステムとアプリの対応状況によって異なるため、実際の端末で利用できる項目をご確認ください。ショートカットから操作してもGlobal RoutingやConfigの意味は変わりません。ウィジェットから操作した後もHomeに戻り、サーバーと接続状態を確認してください。
iCloud:同期する内容を確認
自分のデバイス間で同期する場合は、SettingsのiCloud関連項目を確認し、システムでアプリのiCloud利用が許可されていることを確かめてください。同期できる内容の範囲を把握してから有効にするか判断します。同期は購入履歴の復元とは別の機能であり、唯一のバックアップ手段として扱わないでください。デバイス間で操作する前に、現在使えるConfigを保管しておきます。同期結果を確認してから古い項目を削除し、異なるデバイスでの変更が混在しないようにしてください。
Diagnostics:再現できる情報を記録
Diagnosticsは接続の問題を調べるための機能です。該当する画面を開き、原因を確認したい問題をひとつ決めて再現し、そのときのネットワークの種類、Global Routing、選択中のサーバー、エラーメッセージを記録します。診断情報にはアドレス、ドメイン、認証に関する情報が含まれる場合があります。共有前に項目ごとに確認し、個人情報を隠してください。サポートを求める際は、発生手順と必要な部分だけを共有し、サブスクリプションURLや設定全体を公開しないでください。