Shadowrocket 設定・機能ガイド
まず接続が確立する条件を確認し、次にリクエストの処理方法を設定します。Global Routing、Config、On Demand、Dataの順に確認すると、モード選択、ルール判定、結果の検証を分けて進められます。
操作説明は主にiPhoneとiPadを対象としています。アプリの更新により画面の項目が変わる場合があるため、名称は現在のアプリ内表示をご確認ください。システム要件はApp Storeページの記載をご確認ください。初回接続の手順は入門ガイドをご覧ください。
Global Routing:Config・Proxy・Direct
Global Routingは、リクエスト全体の処理方法を決める設定です。サーバーのプロトコルを選ぶ項目でも、接続全体のオン/オフでもありません。
HomeでGlobal Routingを開き、Config、Proxy、Directから選択します。選ぶ前に、Homeでサーバーが選択されていることと、Configで使用する設定ファイルが有効になっていることを確認してください。モード変更後は、新しく送信したリクエストで確認します。既存の接続は変更前の経路を使い続ける場合があるため、ページを一度更新しただけでは設定の反映を判断できません。
| 画面上のモード | 処理方法 | 確認する場面 | 注意点 |
|---|---|---|---|
| Config | 現在の設定ファイル内のルールに従って、リクエストの処理方法を決めます。 | ドメインやアドレスなどの条件に応じて、日常的に通信を振り分ける場合。 | 現在有効なConfigと、編集しているファイルが同じであることを確認してください。 |
| Proxy | プロキシ経由の通信を全体のルーティング方法として使用します。 | 選択中のサーバーで実際に接続できるか、一時的に確認する場合。 | すべてのルールにあるPROXY項目を個別に選び直すモードではありません。 |
| Direct | 直接接続します。 | 現在のネットワークから直接アクセスできるか、一時的に確認する場合。 | システムの接続設定をオフにしたり、On Demandを無効にしたりする操作とは異なります。 |
通常はConfigを選択
リクエストごとに異なる処理を適用する場合はConfigを選び、ルールの順序を確認します。Homeでサーバーを選択していても、すべてのリクエストがそのサーバーを経由するとは限りません。DIRECTに一致したリクエストは直接接続し、REJECTに一致したリクエストは拒否され、PROXYに一致したリクエストは該当するプロキシポリシーで処理されます。ルールが特定のポリシーグループを参照している場合は、そのグループで現在選択されている項目も確認してください。
ProxyとDirectで問題の範囲を絞り込む
Configで特定の接続先だけに問題がある場合は、ProxyまたはDirectに一時的に切り替え、同じ接続先で比較すると、ルール経由の経路が関係しているか確認できます。モードは一度に一つだけ変更し、結果を記録したら元の設定に戻してください。この比較だけでDNS、サーバー、接続先の正常性が証明されるわけではありません。モード名は全体のルーティング設定を示すため、個々のリクエストは接続ログも確認してください。
ルールによる振り分け:マッチ条件と処理ポリシー
ルールの左側にマッチ条件を記述し、末尾で処理ポリシーを指定します。ルールタイプとポリシーは別のものです。PROXYはドメインのマッチ方法ではありません。
Configで現在使用しているファイルを選び、Ruleの項目を確認します。ルールは通常上から順に評価され、最初に一致した項目でリクエストの行き先が決まります。設定する際は、対象範囲の狭い例外を先に記述し、より広い範囲に適用するルールを後に配置します。先行ルールに一致しなかった場合の最終ポリシーとして、最後にFINALを設定します。編集して保存した後、そのファイルが有効になっていることも確認してください。
| キーワード | マッチ対象・意味 | 確認ポイント |
|---|---|---|
DOMAIN | 完全一致するドメイン。 | パスを付けず、ドメインだけを記述します。 |
DOMAIN-SUFFIX | 指定したドメインとそのサブドメイン。 | 単一の完全一致ドメインより広い範囲に適用されます。 |
DOMAIN-KEYWORD | ドメインに含まれるキーワード。 | 短いキーワードは意図せず広い範囲に一致する場合があります。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6のアドレス範囲。 | アドレス範囲とマスクは、対応する形式で記述してください。 |
GEOIP | IPアドレスの地理的な分類。 | 分類結果は、接続先の実際の運営場所を示すものではありません。 |
USER-AGENT | 識別可能なUser-Agent情報。 | リクエスト情報の見え方に左右されるため、唯一の判断材料には適しません。 |
FINAL | 先行するルールに一致しなかった場合に適用する最終ポリシー。 | 後続のルールを先に適用してしまわないよう、末尾に配置します。 |
PROXY / DIRECT / REJECT | プロキシ経由/直接接続/リクエスト拒否。 | マッチ条件ではなく、処理ポリシーです。 |
簡単なルールで順序を確認
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
この例は構文の説明用です。account.example.comへのアクセスは最初のルールに一致し、DIRECTで処理されます。その他のexample.comドメインは2番目のルールに一致し、それ以外のリクエストにはFINALが適用されます。2番目のルールを最初のルールより前に移動すると、完全一致の例外より先にサフィックスルールが一致します。この例は、あらゆるネットワークに使える完成済みの設定ではありません。
振り分け結果が想定と異なる場合は、まずGlobal RoutingがConfigになっているか確認し、次に一致したルールとポリシーを調べます。マッチ結果を確認する前に、DNS、サーバー、ルールの順序を同時に変更しないでください。設定ファイルの構成、アドレス範囲の書き方、優先順位については設定項目リファレンスをご覧ください。
サブスクリプションとサーバーの管理
Subscribeでは更新可能なサーバー情報をまとめて管理できます。サーバーを個別に追加する場合は、接続パラメーターを一つずつ保存します。どちらもルールによる通信の振り分け設定の代わりにはなりません。
Subscribe:登録済みのサブスクリプションを追加
HomeでAdd Serverを開き、Subscribeタイプを選択します。サービス提供元から取得済みのサブスクリプションURLを該当欄に入力してください。保存後に更新し、サーバー項目が表示されたことを確認してから、使用する項目を選びます。サブスクリプションURLには認証情報が含まれる場合があります。機密情報として扱い、URL全体を公開スクリーンショットや問い合わせ内容に載せないでください。
サブスクリプションの更新が成功しても、内容を取得して処理できたことを示すだけで、登録されたすべてのサーバーが利用可能とは限りません。更新後は、選択した項目が残っているか、名称が変わっていないか、接続パラメーターが本来の用途に合っているかを確認してください。サブスクリプションで管理されている項目は次回更新時に再作成される場合があります。一時的な手動変更だけを長期保存の手段にせず、必要に応じて設定内容を別途記録してください。
Add Server:サーバー情報を個別に入力
手動で追加する場合は、Add Serverで正しいプロトコルタイプを選んでから、アドレス、ポート、認証情報を入力します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどでは使用する項目が異なるため、あるプロトコルのパラメーターを別のプロトコル用フォームに入力しないでください。TLS、トランスポート方式、公開鍵などの項目は、サーバー情報を確認しながら入力します。サーバー名から推測して入力しないでください。
保存前にメモを付けて用途を区別できますが、メモ自体はリクエストの経路に影響しません。保存後にサーバーを選び、Connectivity Testを実行してから実際のアクセスも確認してください。似た項目が複数ある場合は、名前だけでなくアドレスとプロトコルも照合し、古い項目を誤って選ばないようにします。
Connectivity TestとTest Methodの確認範囲
Connectivity Testでは、指定したテスト条件での結果を確認できます。テスト方法はTest Methodなどの設定に左右されます。テスト値はすべての接続先へのアクセス時間を示すものではなく、実際の通信速度を表すものでもありません。テストに成功してもアクセスできない場合は、ルール、DNS、認証情報、接続先を引き続き確認してください。テストに失敗した場合も、現在のネットワークに適したテスト対象と方法かどうかを先に確認します。
On Demand:ネットワーク条件に応じた接続
On Demandは接続を開始する条件を管理します。Global RoutingとConfigは、接続後のリクエスト処理を管理します。
SettingsでOn Demandを開き、現在設定されている接続条件と例外を確認してから、利用状況に応じて有効化または変更します。設定できるネットワーク条件は、アプリ内に表示される項目をご確認ください。初めて設定するときは簡単な条件から試し、動作を確認しながらネットワーク例外を一つずつ追加します。接続動作が想定と異なる場合に、どの条件が影響したか特定しやすくなります。
特定のネットワーク環境で自動接続したい場合は、まず通常の手動接続が正常に動作することを確認してから、該当するオンデマンド条件を有効にします。その後、条件に合うネットワークに一度切り替え、システムとアプリ内の接続状態を確認してください。On Demandはサーバーの不具合を解決する機能ではありません。誤ったパスワード、証明書、ルールを補うことはできません。
手動で切断しても接続が再開する場合は、On Demandが有効のままか、現在のネットワークが接続条件を満たしているかを確認します。自動接続を一時停止するには、まずオンデマンド設定を変更し、その後で接続スイッチを確認してください。Global RoutingをDirectに変更しても、自動接続条件が無効になるわけではありません。
Data:通信量の確認と読み取り
Dataではクライアントが記録した通信量を確認できます。サービス提供元の利用明細ではなく、ルール設定の正しさを単独で判断できる情報でもありません。
Dataを開き、表示中の統計カテゴリ、集計対象の期間、アップロード/ダウンロードの方向を確認してから、対象サーバーの変化を確認します。アプリ別の分類が表示される場合は切り替えて確認できます。アプリの識別や分類はシステムとリクエスト情報に左右されるため、未分類の通信をそのまま異常な接続と判断しないでください。操作の前後を比較する際は、同じカテゴリと集計期間を使用します。
特定の接続先で通信が発生するか確認するには、最初の数値を記録してから明確な操作を一度行い、画面が更新された後に増加分を比較します。バックグラウンド同期、メディアの先読み、ほかのアプリの動作でも通信が発生するため、増加分のすべてを開いたばかりのページに結び付けることはできません。統計をリセットする場合は、必要な数値を先に記録し、アプリ内のリセット項目を使用して、確認画面に表示される対象範囲を確かめてください。
クライアントとサービス提供元の数値は、集計の開始・終了時刻、接続時の通信量、単位、課金基準の違いにより一致しない場合があります。クライアント側でリセットしても、サービス提供元の使用量はリセットされません。また、サービス提供元の新しい課金期間が始まっても、Dataの数値が自動的に消去されるとは限りません。残りの利用量はご自身のサービス提供元の記録で確認し、通信状況の調査にはクライアントの接続記録を使用してください。詳しくはDataの通信量統計に関する解説をご覧ください。
Settings:主な項目と変更時の注意
すべての設定がSettingsだけで決まるわけではありません。DNSなどは現在のConfigにも影響される場合があるため、変更前に実際に適用されている設定を確認してください。
DNS:名前解決と接続経路を確認
DNSはドメイン名を接続に使うアドレスへ変換します。Settings内の関連項目と現在のConfigでDNS設定を確認し、設定ファイルで指定された名前解決の項目があるかを確認してから、変更する場所を決めてください。ドメインにアクセスできないからといって、複数のDNSアドレスを続けて変更しないでください。まずサーバーへの接続を確認し、名前解決の成否と結果が想定どおりかを調べます。
DNSサービスを設定する場合は、ご自身で到達可能性を確認し、用途に合った設定を使用して、元の値も記録しておきます。DNSリクエストの経路と最終的な接続ポリシーは別の概念です。ドメイン名を解決できても、接続先に接続できるとは限りません。変更後は新しいリクエストで確認し、必要に応じて接続を確立し直します。キャッシュや既存の接続が確認結果に影響する場合があるため注意してください。各パラメーターの意味は設定項目をご覧ください。
Test Method:テスト条件をそろえる
Test Methodはサーバーテストの方法を選ぶ設定です。Settingsで該当項目を開き、現在の画面で選択できる方法を指定します。複数のサーバーを比較する際は、同じ方法とテスト対象を使ってください。方法を変更すると、以前の結果をそのまま比較できなくなります。テスト結果は特定の条件での状態を示すものであり、単一の数値だけで接続品質全体を判断しないでください。
テスト結果と実際のアクセスが一致しない場合は、テスト方法、対象、現在のGlobal Routingを記録してから、実際のリクエストでもう一度確認します。より小さいテスト値を得るために条件を何度も変えると、問題を調べるための手掛かりが失われます。テストは診断の一部です。認証情報、ルール、DNSはそれぞれ個別に確認してください。
Today Widget:便利な操作への入口
Today Widgetは、操作や状態確認へのショートカットとして利用できます。Settingsで関連項目を確認し、システムが用意する編集画面から利用可能なウィジェットを追加します。表示形式や利用可否は、現在のシステムとアプリ内の説明をご確認ください。追加後は、現在使用中のConfigまたはサーバーに対応していることを確認してください。ウィジェットに表示されるだけで、接続先に接続できたと判断しないでください。
ウィジェットから接続を開始して状態がすぐに更新されない場合は、アプリに戻って実際の状態を確認します。On Demandの条件に応じて接続が再開する場合があるため、ウィジェットで一度切断しても、自動接続が継続的に無効になるとは限りません。ネットワークの動作は、アプリの状態と実際のリクエストで確認してください。
iCloud:同期と個別バックアップ
iCloud同期では、対応するアカウントとシステムの条件下で、アプリが対応するデータを同期します。SettingsでiCloud関連のスイッチとアプリ内の説明を確認し、システム設定でiCloudが利用可能か確認してください。有効にする前に現在の設定を整理し、有効化した後は別のデバイスで同期された内容を確認します。すべてのサーバー、サブスクリプション、ルール、ローカル統計が同じ方法で同期されるとは限りません。
同期は過去のバージョンを保存する機能ではありません。削除や誤った編集がほかのデバイスにも反映される場合があります。重要なConfigは別途書き出し、安全に保管してください。設定にサブスクリプションURLや認証情報が含まれる場合、バックアップファイルも保護が必要です。機種変更時は、アプリの入手、同期、設定の復元がそれぞれ完了したことを確認してから接続します。内容を確認せずに既存の設定を上書きしないでください。
Diagnostics:仮説を一つずつ検証
Diagnosticsでは接続問題に関する情報を収集・確認できます。Settingsから該当項目を開き、現在利用できるツールでネットワーク、名前解決、接続状況を調べます。テスト前に「同じサーバー、Configモードで特定のドメインにアクセスできない」のように再現条件を明確にしてください。サーバー、DNS、ルールを同時に変更すると、結果を比較できなくなります。
診断結果を保存する場合は、問題に関係する箇所だけを残し、サブスクリプションの認証情報、接続認証情報、アクセス履歴、個人のアドレスが含まれていないか確認します。他の人に状況を説明する際は、ドメイン名や項目名で現象を示し、機密情報をそのまま公開しないでください。診断後は一時的な変更を元に戻し、通常のアクセスを再確認します。
変更後の確認手順
複数の項目を同時に切り替えるより、決まった順序で再確認するほうが原因を特定しやすくなります。まず基本的な接続を確認し、その後ルールと自動接続を確認します。
- 入力した情報を確認。サブスクリプションが正常に更新されたか、手動で追加したサーバーのプロトコル、アドレス、ポート、認証情報が一致しているかを確認します。メモの名称だけで判断せず、パラメーターも照合してください。
- モードとファイルを確認。HomeでGlobal Routingを確認し、Configで有効なファイルを確認します。設定ファイルを編集しても、そのファイルが現在有効になったとは限りません。
- 新しいリクエストでテスト。Connectivity Testを参考にしながら、実際の接続先へのアクセスも確認します。以前の接続が判断に影響しないよう、テスト方法と結果を記録してください。
- 一致したポリシーを確認。リクエストに対応するルールと最終ポリシーを確認し、DIRECT、PROXY、REJECTを区別します。特定のドメインだけに問題がある場合は、完全一致ルールと名前解決の結果を優先して確認してください。
- 最後に自動接続と統計を確認。通常のアクセスができることを確認した後、On Demandの接続条件、Dataの集計範囲、iCloudの同期結果を確認します。
元に戻す場合は、今回変更した項目を変更前の値に戻します。出所の分からない設定ファイルを複数再インポートしないでください。動作確認済みのConfigと簡単な変更記録を保管しておくと、同じ問題の再調査を減らせます。画面の項目、初回の許可、購入の復元については、以下の公式マニュアルをご覧ください。