Shadowrocket
機能と基本設定
まずGlobal Routingを確認し、次にサーバーとルールをチェックします。画面上の場所や設定手順、注意点を機能別に確認し、一度に複数の項目を変更しないようにしましょう。
Global Routingの3つのモード
Config、Proxy、Directはそれぞれ設定に従った振り分け、プロキシ経由、直接接続を表します。まずモードを確認してから、ルールの動作を判断しましょう。
概要：Global Routingは、アプリのルーティング処理対象となる通信の扱い方を決めます。Home上部の接続スイッチとは別の設定です。スイッチは接続の有効・無効を切り替え、Global Routingは接続中のルーティングモードを選びます。スイッチがオンでも、すべてのリクエストが現在のサーバーを経由するとは限りません。
設定場所：HomeでGlobal Routingを開き、Config、Proxy、Directから選択します。ドメイン、IP、地域に応じて通信を振り分ける場合は通常Configを使います。サーバー経由の通信に問題がないか一時的に比較するにはProxy、ローカルネットワークを確認するにはDirectを短時間使ってみてください。
| モード／画面上の表記 | 通信の扱い | 主な用途 | 注意点 |
|---|---|---|---|
| 設定／Config | 現在有効な設定ファイルのルールに従って通信を振り分けます。 | 日常的な振り分けや、ドメイン・IPごとの接続先の使い分け。 | 実際に有効な設定ファイルとルールの順序を確認してください。 |
| プロキシ／Proxy | 対象となる通信をプロキシ経由で処理します。 | 現在のサーバーを一時的に確認し、ルールの影響を切り分けます。 | サーバーのタイムアウトを解消する機能ではなく、すべてのシステム通信が対象になるわけでもありません。 |
| 直接接続／Direct | 接続先へ直接アクセスします。 | ローカルネットワーク経由とプロキシ経由の違いを比較します。 | 直接接続が正常でも、サーバーが正常とは限りません。 |
設定方法：まず現在の選択を記録し、モードを1つ選んで、同じ接続先・同じネットワークで繰り返しテストします。Proxyでは正常でConfigでは異常なら、設定ファイルのルールとポリシーを優先して確認します。どちらも異常なら、サーバー接続とDNSを確認してください。サーバー、ネットワーク、モードを同時に切り替えると、原因を特定できなくなります。
注意点：テスト後は本来使うモードに戻してください。トラブル確認に使ったProxyからConfigへ戻し忘れると、直接接続したい通信の経路も変わることがあります。Directのまま使い続けると、元のルールが機能していないと誤解するおそれがあります。
ルールの種類とポリシーの選択
概要：ルールはマッチ条件と処理ポリシーで構成されます。DOMAIN、DOMAIN-SUFFIXなどのキーワードが「何にマッチするか」を決め、PROXY、DIRECT、REJECTが「マッチ後にどう処理するか」を決めます。この2つは別の要素です。ルールによる振り分けには、Global RoutingがConfigであり、Configで意図したファイルが有効になっていることも必要です。
設定場所：Configを開き、現在有効な設定ファイルと[Rule]セクションを確認します。通常、ルールは記載順に評価され、先にマッチすると後続のルール（フォールバックを含む）は使われません。対象を絞ったドメインルールは、それを上書きする可能性のある広範なルールより前に置き、FINALは通常最後に配置します。
| キーワード | マッチ対象 | 設定時の確認ポイント |
|---|---|---|
DOMAIN | 完全一致するドメイン。 | このドメインだけを対象にすればよいか。 |
DOMAIN-SUFFIX | ドメイン本体とサブドメイン。 | 想定より広い範囲に適用されていないか。 |
DOMAIN-KEYWORD | ドメインに含まれるキーワード。 | キーワードが短すぎて、意図しない対象にもマッチしないか。 |
GEOIP | IPアドレスの地域情報。 | 地域情報のデータベースと実際の接続元が異なる場合があります。 |
IP-CIDR / IP-CIDR6 | IPv4 / IPv6のアドレス範囲。 | アドレスの種類とネットワーク範囲が正しいか。 |
FINAL | 前のルールにマッチしなかったリクエスト。 | フォールバックのポリシーが意図どおりか。 |
設定方法：まず元の設定を保存し、対象を1つに絞ってルールを追加します。以下は構文例です。example.comは説明用のドメインで、サーバーやサブスクリプションのアドレスではありません。この例では該当ドメインとサブドメインをPROXYに割り当て、GEOIPでCNにマッチするリクエストをDIRECTにし、それ以外はFINALで指定したポリシーに従って処理します。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY注意点：PROXYを使うには利用可能なサーバーまたは該当ポリシーが必要です。DIRECTはそのプロキシ経路を通らず、REJECTはマッチしたリクエストを拒否します。REJECTを接続失敗時の自動フォールバックと考えないでください。編集後はファイルにルールが記載されているかだけでなく、実際にどのルールがマッチしたかを確認します。DNSの名前解決結果、IPv6接続、先行ルールもマッチ結果に影響することがあります。
USER-AGENTなど、リクエスト内容に依存する条件は、通信内容を確認できる範囲にも左右されます。暗号化されたすべての接続をアプリ単位で識別できるわけではありません。また、対象のアプリが複数のドメインを使う場合、1つのドメインルールだけで通信経路全体を判断することはできません。
サブスクリプションとサーバー管理
サーバー情報、サブスクリプション一覧、ルール設定はそれぞれ役割が異なります。インポートできても、接続確認が完了したとは限りません。
概要：個々のサーバー情報には接続先アドレス、ポート、プロトコル、認証情報などが保存されます。Subscribeは既存のサブスクリプションに含まれるサーバー一覧を更新し、Configはルールと共通設定を保存します。サーバー一覧を更新しても現在のルールファイルが更新されるとは限らず、設定ファイルを切り替えても既定のサーバーが切り替わるとは限りません。
設定場所：Homeでサーバー一覧を確認します。Add Serverから既存のサーバー情報を手動で追加するか、Scan QR Codeでご自身の情報を読み込みます。サブスクリプションを追加する場合は、画面のSubscribeを選び、ご自身のサブスクリプションURLを入力してください。画面上の場所はプラットフォームによって異なります。操作後はHomeに戻り、一覧に反映されているか確認します。
設定方法：手動入力では、サーバー側の情報に従ってプロトコルを選び、アドレス、ポート、認証情報を順に確認します。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では入力項目が異なります。TLS、通信方式、サーバー名も既存の情報に合わせてください。ポート番号だけからプロトコルを推測しないでください。
- サブスクリプションURLが完全か確認し、余分な空白や改行が入ったり、クエリパラメーターが欠けたりしないようにします。
- インポート後に更新し、想定したサーバーが一覧に表示されるか確認します。更新に失敗しても、すぐに古い一覧を削除せず、まずエラーを記録してください。
- Homeで既定のサーバーを選択し、選択マークを確認してからConnectivity Testを実行します。
- 動作を確認済みの設定を基準として残し、ほかのサーバーを1つずつ比較します。一括変更すると元に戻せなくなるおそれがあります。
注意点：サブスクリプションURLにはアカウントを識別できる情報が含まれる場合があります。スクリーンショットやログを共有する前に隠し、URL全体を公開コメントに貼り付けないでください。更新によってグループ内の情報が上書きされることがあります。手動で変更する前に、次回の更新で置き換わらないか確認してください。Connectivity Testの結果は、そのテスト方法での到達性を示すものです。実際に接続先を開いて確認する必要があります。
On Demandによるオンデマンド接続
概要：On Demandは、システムがサポートするネットワーク条件に応じて接続を開始する機能です。「いつ接続するか」を制御するもので、接続後の振り分けを決めるGlobal Routingの代わりにはなりません。利用できないサーバーや期限切れのサブスクリプションを自動で修復する機能でもありません。
設定場所：SettingsでOn Demandと関連する条件設定を確認します。利用できる条件はシステムによって異なります。まず現在の選択肢を読み、必要に応じて有効にしてください。あるプラットフォームの条件一覧を、別のプラットフォームにそのまま当てはめないでください。
設定方法：まず手動接続でサーバーとルールが正常に動作することを確認し、その後、接続を開始するネットワーク条件を設定します。条件は一度に1つだけ追加し、Wi-Fiとモバイル通信を切り替えて、想定どおりに接続・切断されるか確認してください。特定のネットワークを例外にできる場合は、例外と通常の条件を合わせて確認し、互いに上書きしないようにします。
注意点：手動で接続を切っても自動で再接続される場合、オンデマンド条件が引き続き成立している可能性があります。スイッチの不具合とは限りません。自動接続を一時停止するには、Homeのスイッチを繰り返し操作するのではなく、On Demandの設定も確認してください。ネットワークが頻繁に切り替わる場合は再接続の回数も確認し、オンデマンド接続、システムのスリープ、サーバー切断を切り分けます。ステータスバーのアイコンだけで原因を判断しないでください。
Dataの通信量統計
接続の変化や通信量の傾向を確認する機能です。通信事業者やサーバー側の計測値とは異なります。
概要：Dataには、クライアントが記録できる範囲の通信量や接続情報が表示されます。通信が発生した時間や、接続後にアップロード・ダウンロードがあったかを確認する手がかりになります。すべての端末の通信をまとめた請求情報ではありません。システムを経由しない通信や集計方法の違いが結果に影響します。
表示場所：Dataを開き、最初に集計対象と時間を確認してから、表示可能な詳細を確認します。バージョンやプラットフォームによって表示項目が異なる場合があります。データを比較するときは同じ範囲を使い、1回の接続の値と累計値を直接比較しないでください。
確認方法：特定の接続先を調べるときは、まず現在の数値を記録してから、その接続先に一度だけアクセスし、増加分を確認します。統計のリセット機能がある場合は、必要な記録を保存してからリセットしてください。再接続しても累計値がすべて消えるとは限りません。リクエスト記録で適用されたポリシーも確認すると、通信が想定した経路を通ったか判断できます。
注意点：アップロードやダウンロードの数値が増えても、Webページの読み込み完了を示すとは限りません。テスト、バックグラウンド同期、再試行でも通信量は発生します。再試行が続くのにページが表示されない場合は、DNS、接続エラー、ルールも確認してください。電池消費や通信量に異常がある場合は、まずバックグラウンドタスクを停止した状態と比較し、その後、具体的な接続を調べます。単一のスイッチだけを原因と決めつけないでください。
Settingsの基本項目
変更前の値を記録してから項目を1つずつ調整し、現在の設定ファイルにある関連パラメーターも確認してください。
DNS：名前解決の失敗を確認
概要と設定場所：DNSはドメイン名を接続先のアドレスに変換します。SettingsでDNS関連の項目を確認し、Configの[General]にdns-serverなどのパラメーターが含まれているかも確認してください。設定画面と設定ファイルの両方に関連項目がある場合は、どの設定が実際に有効かを確認します。一方を変更すればすべてに反映されると決めつけないでください。
設定方法：現在の値を記録し、複数の具体的なドメインでテストしてから、名前解決方法を変更する必要があるか判断します。どのサーバーでもドメイン名でアクセスしたときだけ失敗する場合は、DNSを重点的に確認してください。特定の接続先だけに問題がある場合は、その接続先のルールやサービス状態も確認します。変更後は同じ接続先を再テストし、キャッシュが結果に影響していないか注意してください。
注意点：DNSリゾルバー自体にも到達できる必要があります。見つけたアドレスを無作為に設定へ入力しないでください。また、DNSは認証エラーやポートのタイムアウトを解決する万能な方法ではありません。IPv6を使う場合は、取得したアドレスの種類と、現在のネットワークでIPv6に到達できるかを合わせて確認します。
Test Method：テスト条件をそろえる
概要と設定場所：SettingsのTest Methodでは、接続テストの方法を選択します。方法によって確認する通信経路の区間が異なるため、テスト方法を考慮せずに数値を比較することはできません。ある方法で失敗しても、実際のリクエストがすべて失敗するとは限りません。
設定方法：現在の確認目的に合い、画面で利用できる方法を選択してから、HomeでConnectivity Testを実行します。複数のサーバーを比較する場合は、テスト方法、ネットワーク、接続先をそろえてください。必要に応じて再テストし、実際にアクセスした結果でも確認します。
注意点：テストの所要時間はダウンロード速度ではなく、1回の所要時間から長期的な安定性を判断することもできません。数値を小さくするために方法を何度も変え、実際に接続できるかどうかを見落とさないでください。
Today Widget：ショートカットと状態確認
概要と設定場所：Today Widgetは、システムで利用できる場合に使えるクイック操作の入口です。まずSettingsで関連項目を探し、次にシステムのウィジェット画面で追加できるか確認します。ウィジェットの形式やバックグラウンド操作の制限は、システムのバージョンによって異なります。
設定方法と注意点：現在のシステムで該当する入口が提供されている場合にのみ追加し、操作後はHomeに戻って実際の状態を確認してください。ウィジェットの表示更新には遅れが生じる場合があるため、古い表示を現在の接続状態と見なさないでください。同じ入口が見つからない場合は、現在のシステムでの対応状況に従ってください。そのために設定を繰り返しリセットする必要はありません。
iCloud：同期前にローカル設定を保護
概要と設定場所：iCloudに対応するAppleデバイスでは、Settingsの関連項目から、アプリが対応する範囲のクラウド同期を管理できます。すべての設定、接続状態、ログが別のデバイスに完全にコピーされるわけではありません。
設定方法：重要な設定を保存し、想定したアカウントにシステムでサインインしていること、iCloudが利用可能なこと、アプリの権限が有効になっていることを確認します。別のデバイスで初めて使うときは、同期完了後にファイルの内容、有効な項目、既定のサーバーを確認してください。既存のローカルファイルをすぐに上書きしないでください。
注意点：同期は独立したバックアップではなく、削除や上書きも同期される場合があります。デバイス間で内容が異なる場合は、まず両方のコピーを保存してから比較してください。同じファイルを両方のデバイスで続けて編集しないでください。異なるプラットフォーム間の設定移行が、すべてiCloudで自動的に行われるわけではありません。
Diagnostics：再現可能なエラーを記録
概要と設定場所：SettingsでDiagnosticsと利用可能な診断機能を探し、接続問題に関する情報を収集します。ログは問題を明確に再現したときの記録を中心に確認してください。長時間にわたるログには複数の事象が混在し、どのエラーが現在の問題に対応するのか特定しにくくなります。
確認方法：ネットワークの種類、Global Routing、使用中のサーバー、接続先を記録してから問題を一度再現し、近い時刻の名前解決、接続、ルールの記録を確認します。まずDNSの失敗、接続タイムアウト、認証エラー、ルールのマッチ異常を切り分け、その内容に応じて確認を進めます。
注意点：診断情報を送信する前に、サブスクリプションURL、認証情報、その他の個人情報を隠してください。診断後は、日常利用に必要な記録レベルに戻し、不要なログが長期間蓄積しないようにします。症状別の詳しい説明はトラブル対処ガイドをご覧ください。
設定後の確認手順
機能間には依存関係があります。サーバーに接続できない場合、ルールを変更しても通常は解決しません。Global RoutingがConfigでなければ、[Rule]だけを変更しても期待した結果にならない場合があります。以下の順に確認すると、各結果を特定の設定に結びつけやすくなります。
- ネットワークを確認する。Wi-Fiかモバイル通信かを記録し、まずネットワーク自体が使えることを確認します。比較中にネットワークを切り替えないでください。
- サーバーを確認する。Homeで既定のサーバーと接続情報を確認し、Connectivity Testの結果を記録してから、実際の接続先にアクセスします。
- ルーティングモードを確認する。Global Routingを確認します。Configを使う場合は、設定ファイルが存在するかだけでなく、意図したファイルが有効かも確認してください。
- 名前解決とルールの適用結果を確認する。DNSの結果、ルールの順序、最終的なポリシーを確認します。関連するルールを1つだけ変更し、保存してから再テストしてください。
- 自動動作を確認する。手動接続が正常に動作した後で、On Demand、同期、ショートカットをテストします。複数の自動動作が原因の切り分けを妨げないようにしてください。
- 有効だった変更を記録する。正常に戻った具体的な変更を記録します。改善しない場合は、次の項目を試す前に元に戻し、不確かな設定を重ねないでください。
初めて操作する場合は使い方ガイドに沿ってインポートと初回接続を行ってください。再現性のあるエラーが発生した場合は、症状に合わせてトラブル対処ガイドを確認します。設定に関するよくある質問はFAQにまとめています。1つの接続先を調べるために、すべての機能を設定し直す必要はありません。