Shadowrocket
プロキシモードと設定方法
まずGlobal Routingの動作モードを選び、次にサーバーと設定を確認します。接続のオン・オフ、ルールによる振り分け、オンデマンド接続はそれぞれ別の機能です。設定後は個別に動作を確認してください。
- Home
- Config
- Data
- Settings
Global Routingの3つのモード
通常のルール振り分けにはConfig、プロキシ経由の通信を一時確認する場合はProxy、直接接続との比較にはDirectを使います。HomeでGlobal Routingを開き、目的に合ったモードを選択します。この設定はクライアントに入るリクエストの処理方法を決めるもので、接続スイッチとは別です。また、サーバーアドレスや認証情報、DNS設定を自動で修正するものではありません。
| モード | 処理方法 | 用途 | 確認するポイント |
|---|---|---|---|
設定Config |
現在有効な設定内のルールに従ってポリシーを選択します。 | ドメインやアドレスごとに異なるポリシーを適用したい場合。 | 設定が有効か、ルールの順序、最後に適用されるフォールバックポリシー。 |
プロキシProxy |
クライアントに入る通信をプロキシモードで処理します。対象となるシステム通信の範囲や、アプリ内の例外設定にも注意してください。 | ルールによる振り分けが原因か、一時的に切り分ける場合。 | 選択中のサーバーが利用可能か、目的の接続先にそのサーバー経由で接続できるか。 |
直接接続Direct |
クライアントに入る通信を直接接続モードで処理します。 | 現在のネットワークから直接接続した場合の結果を比較するとき。 | 現在のネットワークから接続先にアクセスできるか、DNSが正常に動作しているか。 |
Config:ルールで接続先を決める
Config画面で使用中の設定を確認し、Homeに戻ってGlobal RoutingをConfigにします。設定内で一致したルールのポリシーは、PROXY、DIRECT、REJECT、または設定で定義されたポリシーグループの場合があります。Homeでサーバーを選択していても、すべてのリクエストがそのサーバーを経由するとは限りません。ルールの指定がDIRECTなら、リクエストは直接接続として処理されます。
ProxyとDirect:原因を切り分ける
同じ接続先がProxyでは開けるのにConfigでは失敗する場合、サーバー設定を一括変更する前に、一致したルールとポリシーの参照先を確認してください。Directでは接続できてProxyでは失敗する場合は、選択中のサーバー、認証情報、通信方式の設定を確認します。モードの比較は原因を探る手がかりであり、1回の結果だけで原因を特定できるものではありません。
モードを切り替えたら、テストページを閉じて開き直し、必要に応じてクライアントの接続も再確立してください。以前の接続が確認結果に影響する場合があります。テスト後は通常使用するモードに戻してください。Proxyをトラブル対処用の一時設定のまま使い続けると、本来のルール振り分け結果が変わります。
ルールの種類とポリシー
ルールは「何に一致するか」、ポリシーは「一致した後にどう処理するか」を決めます。Configで使用中の設定を開き、Rule部分を確認または編集します。通常、ルールはファイル内の記載順に評価され、先に一致したルールが結果を決定します。個別のルールは適切な位置に置き、FINALは最後のフォールバックとして設定してください。
| ルールの種類 | 一致する対象 | 設定時の注意 |
|---|---|---|
DOMAIN | 指定した完全一致のドメイン。 | 特定のドメインだけを対象にする場合に適しています。 |
DOMAIN-SUFFIX | ドメイン本体とそのサブドメイン。 | ドメイン欄に完全なWebアドレスやパスを入力しないでください。 |
DOMAIN-KEYWORD | ドメインに含まれるキーワード。 | 想定より広い範囲に一致する場合があるため、誤一致に注意してください。 |
GEOIP | IPアドレスに対応する地域分類。 | 分類結果は使用するIPアドレスデータベースによって異なります。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6のアドレス範囲。 | アドレスの種類とプレフィックス長を確認してください。 |
USER-AGENT | 識別可能なUser-Agent情報。 | リクエスト内の該当情報を参照できるかどうかによって、一致するかが決まります。 |
FINAL | それ以前のルールに一致しなかったリクエスト。 | ルールの最後に置き、最終的な接続先を明示してください。 |
PROXY・DIRECT・REJECTの違い
PROXYはプロキシ経由で処理し、DIRECTは直接接続、REJECTはリクエストを拒否します。これらの大文字のキーワードは設定の構文であり、Global RoutingのProxyやDirectという画面上の選択肢とは階層が異なります。前者は個々のルールの処理結果、後者は全体の動作モードです。独自のポリシー名を使う場合は、その名前が設定内に定義されていることも確認してください。
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY
これは構文例であり、すべてのネットワークに適した完全な設定ではありません。1行目はexample.comのみ、2行目はexample.orgとそのサブドメインに一致します。キーワードルールはより広い範囲に適用されるため、コピーする前に影響するリクエストを確認してください。ルール数を増やすためだけに同じ内容を重複して追加したり、有効にしたいルールより前にFINALを置いたりしないでください。
編集前に設定のバックアップを保存し、一度に変更するルールは少数に絞って、対象ドメインで実際のポリシーを確認してください。General、Rule、Host、URL Rewriteの構成を項目ごとに確認するには、ルールと設定の総合ガイド →をご覧ください。
サブスクリプションとサーバーの管理
サーバーの記録には接続パラメータが保存され、サブスクリプションを使うと記録をまとめて取得・更新できます。自分のサブスクリプションまたはサーバー情報があることを前提に、HomeでAdd Serverを使って追加します。Subscribeを選ぶ場合は自分のサブスクリプションURLを入力してください。手動で追加する場合は、正しいプロトコルを選び、元の情報に従って各項目を入力します。
Add Server:プロトコルに応じた項目を入力
Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では、必要なパラメータがそれぞれ異なります。アドレスとポートが同じでも、記録をそのまま置き換えられるとは限りません。パスワード、UUID、TLS、通信方式などの項目は、自分のサーバー情報に従って入力してください。プロトコルや通信方式を選択した後に表示される項目もあります。
1件分の共有情報がある場合は、アプリのインポート機能を利用できます。QRコードがある場合はScan QR Codeを使います。インポート後も記録を開き、プロトコル、アドレス、ポート、認証情報を確認してください。表示名だけで正しく取り込めたと判断しないでください。名前は識別用で、接続を決めるのは記録内のパラメータです。
Subscribe:更新とローカル編集の違い
サブスクリプションを更新すると、URLから内容を再取得します。サブスクリプションで管理されている記録は、ローカルで編集しても次回更新時に上書きされることがあります。変更を維持する必要がある場合は、記録の取得元と現在の保存方法を先に確認してください。複数のサブスクリプションがある場合は、識別しやすいメモを付け、グループを確認してから無効な項目を削除すると、名前が似た記録を誤って重複扱いするのを防げます。
サブスクリプションの更新成功は、内容の取得と解析が完了したことを示すだけで、すべてのサーバーに接続できることを保証しません。一方、更新に失敗しても、保存済みの記録がただちに使えなくなるとは限りません。URLからの取得結果とサーバーへの接続結果を分けて確認してください。
On Demandによるオンデマンド接続
On Demandは設定した条件に応じてシステムに接続を要求する機能で、ルールによる振り分けを置き換えるものではありません。SettingsでOn Demandを開き、アプリに表示される条件とスイッチを確認してください。選択できる条件は現在のアプリ画面で確認できます。まず手動接続が正常に動作することを確かめてからオンデマンド接続を有効にすると、接続自体の問題と起動条件の問題を切り分けやすくなります。
設定と確認の手順
- HomeでサーバーとGlobal Routingのモードを選び、手動で接続してテスト対象にアクセスします。
- On Demandを開き、現在の条件がどのように動作するかを確認してから必要な項目を有効にします。ネットワーク名に関する条件は、デバイスが実際に接続しているネットワークと一致している必要があります。
- 対象のネットワークに切り替えるか、起動条件を再度満たし、システムの接続状態とリクエストの成否を確認します。
- 想定どおりに動作しない場合は、まずOn Demandを一時的にオフにして手動接続を確認してください。ルールとサーバーパラメータを同時に変更しないでください。
On DemandとConfigは併用できます。前者は接続を開始するタイミング、後者は接続後のリクエストに適用するポリシーを制御します。システムに接続中の表示があっても、すべてのリクエストがプロキシ経由とは限りません。ConfigにDIRECTやREJECTのルールが含まれている場合があります。
手動で切断した後に接続が再開する場合は、設定を何度も削除するのではなく、On Demandの条件が有効なままになっていないか確認してください。初回接続時のシステムVPN構成の許可はシステム側の手順です。許可した後もアプリ内の設定を確認してください。デバイスのネットワーク変化、システムのスケジュール、条件との一致が確認結果に影響します。オンデマンド接続は、アプリごとのリクエストを個別に切り替える機能ではありません。
Dataの通信量統計
Dataで確認できるのはクライアントが記録した通信量であり、サービス提供元の請求額ではありません。Dataを開き、画面に表示される集計範囲に応じてアップロード、ダウンロード、関連記録を確認します。テスト前後を比較する場合は、まず現在の値を記録し、目的を一つに絞った操作を行ってから再度確認してください。リセット機能を使う場合は、既存の統計を残す必要がないか先に確認します。
通信量の数値からわかること
数値が増えていれば、その集計基準でクライアントがデータ通信を記録したことがわかります。ただし、特定のWebページが完全に読み込まれたことや、どのサーバーを使用したかまでは数値だけで判断できません。バックグラウンドアプリ、同期処理、再試行されたリクエストも通信量に含まれる場合があります。接続先への経路を確認するには、合計値だけでなく、現在のモード、一致したポリシー、接続記録も確認してください。
サービス提供元の記録と異なる理由
集計期間、リセット時刻、プロトコルのオーバーヘッドの計算方法、課金ルールが異なる場合があります。クライアントの統計とサービス提供元の記録は別々に確認してください。残りの利用可能量は、利用中のサービス提供元の案内をご確認ください。アプリ内の統計をリセットしても、サービス提供元側の使用量がリセットされるわけではありません。
トラブル対処には、一定の手順でテストすると便利です。不要なバックグラウンド処理を一時停止し、Dataの現在値を記録してから、接続できることがわかっている対象にアクセスし、数値の変化を比較します。これにより影響を抑えられますが、回線の課金量を正確に測定できるわけではありません。統計記録に接続先の情報が含まれる場合は、共有前に個人のアクセス内容が含まれていないか確認してください。
Settingsの設定
Settingsでは、テスト方法、補助機能、同期、診断などの項目を管理します。ネットワークの動作の一部は、現在の設定のGeneral部分で制御されます。同じ問題でも、まず設定がどこにあるかを確認してから該当箇所を変更してください。設定名が似ていても、同じ通信経路に作用するとは限りません。項目の表示や具体的な場所は、現在のアプリ画面で確認してください。
DNS:名前解決の経路を確認する
DNSはドメイン名を接続に必要なアドレスへ変換します。SettingsのDNS設定と、現在のConfigのGeneralの内容を照らし合わせ、どのリゾルバーを使うか、リクエストがどの経路を通るか、設定で別途指定されている項目がないかを確認してください。まず現在の値を記録し、利用中のネットワークと設定の要件に応じて変更します。保存して再接続した後、同じドメインで結果を比較してください。
Connectivity Testに数値が表示されたというだけで、DNSが正常だと判断しないでください。テストによってはサーバーエンドポイントへの到達性のみを確認し、Webサイトのドメイン名解決とは別の処理です。ドメイン名でのアクセスだけ失敗する場合は、まず名前解決を確認します。名前解決は成功しても接続できない場合は、対象のポリシー、サーバーへの経路、TLSなどを確認してください。内容を理解せずにDNS設定を重ねると、原因の特定が難しくなります。
Test Method:テスト対象を確認する
Test MethodではConnectivity Testのテスト方法を選択できます。Settingsで項目を開き、画面に表示される方式と説明を確認して選択した後、Homeに戻って登録済みのサーバーをテストします。記録を比較するときは、なるべく同じ方法、接続先、ネットワーク環境を使ってください。条件が異なると数値を比較できません。
テスト結果が示すのは、その時点での到達性や応答状況であり、通信速度やすべてのWebサイトへのアクセスを保証するものではありません。数値が表示されてもページを開けない場合は、ページのドメイン、ルール、DNSを確認してください。テストに失敗した場合も、テスト対象に到達できないのか、実際のプロキシ接続が失敗しているのかを切り分け、使用できる可能性のある記録をすぐに削除しないでください。
Today Widget:補助操作への入口
Today Widgetでは、システムが対応するウィジェット機能に関する設定を確認できます。Settingsで該当項目を開いてください。追加できるか、どの操作が表示されるか、ウィジェットをどこから開けるかは、現在のシステムとアプリの対応状況によって異なります。デバイスに表示されるウィジェット一覧に従って操作してください。まずアプリ内で接続を確認してから、ウィジェットを試します。
ウィジェットは補助的な操作入口であり、サーバーパラメータ、Global Routing、システムVPNの許可に代わるものではありません。ウィジェットの表示と実際のアクセス結果が異なる場合は、見た目だけで通信経路を判断せず、Homeに戻って現在の接続状態とモードを確認してください。
iCloud:同期とローカル保存を個別に確認
iCloud関連の機能では、アプリが対応する範囲でデータを保存または同期できます。SettingsでiCloudの項目を確認し、デバイスで自分のApple Accountにサインインしていること、システムでアプリのiCloud利用が許可されていることを確認してください。有効にする前に重要な設定のバックアップを保存し、操作後はアプリに表示される同期対象と結果を確認します。
有効にすると、すべてのサーバー、認証情報、設定、統計、一時的な状態が完全に同期されるとは限りません。複数のデバイスで使う場合は、項目ごとに内容を確認し、特に有効な設定とサーバーの選択をチェックしてください。アプリの購入履歴、iCloudで同期するデータ、利用者自身のサービス提供元アカウントは、それぞれ別のものです。同期後も接続を改めて確認してください。
Diagnostics:情報を集めてから変更する
Diagnosticsでは、動作上の問題に関する診断情報を確認または収集できます。Settingsで該当項目を開き、画面の案内に従って確認してください。問題発生時のネットワーク環境、Global Routingのモード、対象、操作手順を先に記録してから診断出力を確認すると、記録と実際の失敗を照らし合わせやすくなります。
警告を一つ見ただけで、それを原因のすべてと判断しないでください。診断内容はConnectivity Test、DNS、ルールの結果とあわせて確認します。情報を外部に共有する前に、サブスクリプションURL、サーバーの認証情報、個人のドメインなど機密情報を削除してください。設定を変更する前に元の値を記録しておくと、変更が有効だったか確認できます。
設定の確認とトラブル対処の手順
一度に変更する条件は一つにして、同じ接続先で繰り返し確認してください。サーバー、モード、設定、DNSを同時に変更すると、アクセスが回復しても何が有効だったのか判断できません。まず再現可能な最小限のテストを用意し、次の順番で確認することをおすすめします。
- 現在のネットワークを確認します。デバイスが正常にインターネットへ接続できる状態かを確認してください。Wi-Fiとモバイル通信を切り替える場合は、それぞれの結果を記録し、ネットワークの変化を設定変更と混同しないようにします。
- サーバーの記録を確認します。プロトコル、アドレス、ポート、認証情報、必要な通信方式の項目を確認し、選択中の記録が想定したサブスクリプションから取得したものか確認してください。
- 接続状態を確認します。Homeで接続操作とシステムの許可状態を確認してください。サーバーを選択しただけで、接続が確立したと判断しないでください。
- モードを比較します。同じ接続先でProxyとConfigを比較してください。Configだけ失敗する場合はルールとポリシーの参照先を確認し、両方失敗する場合は通信経路と名前解決を確認します。
- DNSと診断情報を確認します。名前解決の失敗、接続確立の失敗、接続後のリクエスト失敗を切り分け、すべての現象を一つのルールの問題と決めつけないでください。
- 通常の設定に戻します。有効性を確認できた変更だけを残し、一時的に切り替えたモードを元に戻してから、On Demandと補助機能をテストしてください。
Configモードで一部のリクエストがプロキシを経由しないのはなぜですか?
Configは現在の設定に基づいてポリシーを選択します。リクエストがDIRECTに一致したり、直接接続の選択肢を含むポリシーグループに振り分けられたりする場合があります。有効な設定、ルールの順序、実際に一致した結果を確認してください。Homeで選択中のサーバーだけを見ても、すべてのリクエストの接続先は判断できません。
On Demandを有効にした後も、Global Routingの設定は必要ですか?
必要です。On Demandは接続を開始する条件を制御し、Global Routingは通信の処理方法を制御します。まずサーバーとモードを手動で確認してからOn Demandを有効にし、条件に応じて接続されることを確認してください。それぞれ個別に確認する必要があります。
Connectivity Testは正常なのに、Webページを開けないのはなぜですか?
テストとWebページへのアクセスでは、接続先や通信経路が異なる場合があります。ページのドメイン名解決、Configのポリシー、選択中のサーバーから接続先までの通信、診断記録に示された失敗箇所を確認してください。テストの数値だけで実際のアクセスを確認したことにはなりません。
初回接続までの手順はインポートと接続のチュートリアルをご覧ください。ルールを一つずつ確認する場合は設定の総合ガイド、購入、インストール、よくある接続の問題はトラブル対処ガイドを項目別にご覧ください。