公式マニュアル · 機能と設定

Shadowrocketの設定
ルーティングモード・ルール・接続の確認

まずGlobal Routingを確認し、次にConfigとサーバーを確認します。一度に変更する項目は1つに絞り、同じリクエストで検証すると、設定が接続に影響したか判断できます。

ルーティングモードを確認初回利用の手順

設定項目から探す

まずモード・設定ファイル・接続を区別する

以下の画面操作は主にiPhone / iPadを基準にしています。他のプラットフォームではレイアウトや表示項目が異なる場合があります。実際のアプリ画面を確認し、特定の画面での手順をすべてのデバイスに当てはめないでください。

Home

Global Routing：Config・Proxy・Direct

モードによって通信を処理する方針が決まります。ルールを調べる前に、まずここを確認してください。

概要：Global Routingは、接続の処理方法を切り替える設定です。Configは現在の設定ファイル内のルールに従ってポリシーを決定します。Proxyは、クライアントが処理するリクエストをプロキシ経由にします。Directは、クライアントが処理するリクエストを直接接続します。ここでいう「すべて」は、クライアントの処理対象となる通信を指します。デバイス上のあらゆるシステム通信が同じ経路を通るとは限りません。

場所と設定方法：HomeでGlobal Routingを開き、Config、Proxy、Directのいずれかを選択してから、現在のサーバーを確認します。日常的にドメインやIPアドレスで接続経路を振り分ける場合はConfigを使います。ルールのポリシーが誤っているか調べるには、一時的にProxyまたはDirectに切り替えて比較できます。比較中は対象URL、ネットワーク、サーバーを変えないでください。そうしないと、結果の違いがモードによるものか、ネットワークによるものか判断できません。

モード	処理方針	使用する場面	確認する項目
Config（設定）	現在のConfigに設定されたルールとポリシーに従います。	日常的なルール振り分け。特定のドメインやネットワーク帯の接続経路を確認するとき。	選択中の設定ファイル、ルールの順序、ポリシーの適用先。
Proxy（プロキシ）	対象のリクエストをプロキシ経由で処理します。	ルール振り分けの影響を一時的に除外し、登録済みサーバーへの接続を確認するとき。	現在のサーバーが有効か、認証情報と通信パラメーターが一致しているか。
Direct（直接接続）	対象のリクエストを直接接続で処理します。	ローカルネットワークでのアクセス結果と比較し、プロキシ経由の問題かどうかを判断するとき。	ローカルネットワーク、接続先サービス、DNSが正常か。

注意：Proxyに切り替えても、サーバー設定の誤りは修正されません。Directもクライアントの接続を停止する設定ではありません。モード変更後は新しいリクエストを送り、ログを確認してください。既存の長時間接続は、切り替え前の経路を使い続ける場合があります。比較が終わったら、普段使うモードに戻してください。確認用の設定をそのまま使い続けないようにしましょう。画面上のConfigモードとConfigページは同じ名前ですが、前者はルーティングモード、後者は設定ファイルの管理画面です。

Config

ルール振り分け：条件とポリシーを分けて確認

概要と場所：ルールは一致条件と処理ポリシーで構成されます。Configで選択中の設定ファイルを確認してください。DOMAINはドメイン全体、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはドメイン内のキーワードに一致します。IP-CIDRとIP-CIDR6はIPアドレスの範囲、GEOIPはIPアドレスの地域データベース上の判定に基づきます。USER-AGENTは、該当するリクエスト情報を取得できるかどうかに依存します。あらゆる暗号化リクエストに有効な識別条件として扱わないでください。

設定方法：まず、どの接続先の経路を変更するかを決め、最も具体的な条件を選びます。ルールは通常、上から順に評価され、最初に一致したルールのポリシーが適用されます。そのため、特定のドメインのルールは、該当する可能性のある広範なルールより上に配置してください。どのルールにも一致しないリクエストを処理するFINALは末尾に置きます。変更後は設定ファイルが選択されたままか確認し、新しいリクエストで検証してください。テキストが保存されたことだけで判断しないでください。

ルール例とポリシーの意味

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

PROXYはプロキシ経由、DIRECTは直接接続、REJECTは一致したリクエストの拒否を指定します。カスタムポリシー名を使う場合は、対応する定義が必要です。

DOMAIN IP-CIDR IP-CIDR6 REJECT

注意：上記の例はルールの順序を説明するもので、すべてのネットワークに適しているわけではありません。IPアドレスに基づく判定では、DNSによる名前解決が関係する場合があります。ドメインの実際の接続先が変われば、通信経路も変わる可能性があります。REJECTが拒否するのは一致したリクエストのみです。画面上の特定領域のコンテンツを削除したり、不要なリソースをすべてブロックしたりする機能ではありません。ルールに正しく一致してもアクセスできない場合は、同種のルールを追加し続けるのではなく、ポリシーの接続先サーバーを確認してください。

Home · Add Server · Subscribe

サブスクリプションとサーバーの管理：情報の入手元を確認

概要と場所：個別のサーバー項目には、プロトコル、アドレス、ポート、認証情報などの接続パラメーターが保存されます。Subscribeは、利用者自身が持つサブスクリプションURLから項目を取得・更新する機能です。Homeでサーバー一覧を確認し、手動で追加する場合はAdd Serverを使います。QRコードがある場合はScan QR Codeから読み込めます。サーバー一覧とConfigファイルは別々に管理されます。サーバー一覧を更新しても、現在のルールファイルが更新されるわけではありません。

設定方法：利用中のサービス提供元から必要な情報を入手し、実際に提供されている種類に応じてShadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2などのプロトコルを選択します。アドレスとポートだけでなく、認証、TLS、通信方式、関連する追加パラメーターも1つずつ確認してください。アドレスが同じでも、複数の項目で設定を共用できるとは限りません。読み込み後は項目数と名前を確認し、項目を1つ選んでConnectivity Testを実行します。最後に実際の接続先へのリクエストで検証してください。

サブスクリプションを更新するときは、Homeで該当するサブスクリプションを手動更新し、結果を確認します。更新に失敗する場合と、更新後に一覧が空になる場合は、別々の問題です。前者はURLにアクセスできるかを確認し、後者は取得した内容が有効か、アプリが認識できる形式かも確認してください。URLの一部が欠けている、コピー時に空白が混入している、ログインページが返されるなどの理由で読み込みに失敗する場合があります。読み込みが成功するまでは既存の利用可能な項目を残し、比較できる状態を保ってください。

注意：サブスクリプションから生成された項目を手動で変更すると、次回の更新で上書きされることがあります。変更を維持する必要がある場合は、ローカル項目とサブスクリプション項目の関係を確認してください。サブスクリプションURLには個人用のアクセス情報が含まれる場合があります。公開コメント、スクリーンショット、診断ログに貼り付けないでください。プロトコル名が同じでも具体的な設定が同一とは限りません。また、Connectivity Testの結果だけでは、認証や接続先へのアクセスを確認できません。

Settings · On Demand

On Demand：条件に応じて接続

概要と場所：On Demandは、設定したネットワーク条件に応じて接続を開始する機能です。SettingsからOn Demandを開き、現在の有効状態と設定済みの条件を確認します。制御するのは接続を開始するタイミングであり、個々のリクエストに適用するポリシーではありません。ドメインやIPアドレスごとの振り分けは、引き続きGlobal RoutingとConfigで設定します。

設定方法：まず手動で接続し、設定が使えることを確認します。その後、アプリで実際に設定できる条件に応じて、接続を開始する範囲を設定してください。Wi-Fiに関する条件では、ネットワーク識別情報と条件の順序をよく確認します。保存後は、条件に合うネットワークと合わないネットワークの両方でテストし、接続状態が想定どおりか確認してください。テスト中はネットワーク条件を1つずつ切り替え、ルールやサーバーを同時に変更しないようにします。

注意：On Demandは、バックグラウンドで接続が常時維持されることを保証する機能ではありません。ネットワークの切り替え、システム権限、システムの動作方針が接続に影響します。有効にした後で接続回数やバッテリー消費に変化があった場合は、そのときのネットワーク切り替え状況を記録してください。不要な接続条件を減らしてから、他の設定を調整する必要があるか判断します。利用できる条件はプラットフォームごとの実際の画面で確認してください。

Data

Data：通信量の変化から状況を確認

概要と場所：Dataには、クライアントが処理した通信の統計が表示されます。分類、集計期間、確認できる詳細は現在の画面で確認してください。テストの前後でリクエストや通信量に変化があったかを見るのに役立ちますが、サービス提供元の請求額を示すものではありません。また、デバイス上のすべての通信が集計されているとは限りません。

使い方：Dataを開き、集計範囲と現在の数値を確認します。次に対象のアプリに戻り、同じ条件で繰り返せるリクエストを1つ実行してから、Dataの変化を確認してください。リクエストや接続のログも表示される場合は、対象ドメイン、発生時刻、適用されたポリシーを合わせて確認します。累計値だけで判断しないでください。システムのバックグラウンド通信が同時に発生する可能性があり、大きな増加が直前にテストしたWebページによるものとは限りません。

注意：クライアントとサービス提供元では、プロトコルのオーバーヘッド、集計期間、アップロードとダウンロードの計算方法が異なる場合があります。そのため、数値が完全に一致する必要はありません。ログの消去や統計のリセット前に、今回の確認に必要な情報を保存してください。ログにはドメイン、アドレス、アクセス時刻が含まれる場合があるため、共有する前に個人情報を取り除いてください。Dataに通信量が表示されても、データが転送されたことを示すだけで、接続先から正しい応答があったことや通信速度を保証するものではありません。

Settings · Config

DNS：名前解決の経路を確認してから設定を変更

概要と場所：DNSはドメイン名をIPアドレスに変換します。名前解決の結果は後続の接続に影響し、IPアドレスに基づくルール判定に関係する場合もあります。SettingsのDNS関連項目を確認し、現在のConfigにDNS設定が含まれているかも調べてください。設定ファイルが実際の動作に影響する場合もあるため、1つの画面だけを変更して、すべてのリクエストに新しい設定が使われると思い込まないでください。

設定方法：まず、問題が本当に名前解決の段階で起きているか確認します。対象ドメインのスペルが正しいか、複数のドメインで失敗するか、ローカルネットワークが正常かを調べてください。現在のDNS設定を記録し、名前解決に関する項目を一度に1つだけ変更します。その間、サーバーとルーティングモードは変えないでください。入力するアドレスは、該当フィールドが受け付ける形式に合わせます。特定のプロトコル形式が必要な欄には、通常のIPアドレスとプロトコルを含む完全なアドレスを混在させないでください。

変更後は新しいリクエストでテストを繰り返し、既存のキャッシュや長時間接続の影響も考慮してください。ドメインを名前解決できても接続がタイムアウトする場合は、サーバー、ルール、接続先サービスを確認します。一部のドメインだけ失敗する場合は、適用されたポリシーと名前解決の結果を比較してください。IPv4とIPv6では到達性が異なる場合があります。問題が断続的に起きるときは、すぐにどちらかのアドレス形式を無効にせず、実際に使われたアドレスの種類を記録してください。

注意：DNSはプロキシ通信そのものではありません。DNSを変更しても、パスワードやポートの誤りは修正できません。暗号化DNSは、名前解決リクエストの通信方式を指すもので、すべてのアプリ通信のプライバシーを示すものではありません。名前解決の設定、ルーティングモード、サーバーを同時に変更しないでください。接続が回復しても、どの変更が有効だったか判断できなくなります。

Settings

Test Method、Today Widget、iCloud

これらの設定はそれぞれテスト、クイック操作、データ同期に関係します。接続品質を切り替える設定と混同しないでください。

Test Method：テスト結果が示す範囲を確認

概要と場所：SettingsでTest Methodを確認します。この項目はConnectivity Testで使うテスト方法に影響します。方法によって確認する接続段階が異なるため、結果をそのまま比較することはできません。ある方法でテストが完了しても、認証、接続先Webサイトの応答、継続的なデータ転送まで確認できたとは限りません。

設定方法と注意点：現在の画面で選べる方法を設定します。複数のサーバーを比較する場合は、同じ方法を使ってください。テスト対象を設定できる場合は、対象も同じにします。結果に異常があるときは、まずテスト対象にアクセスできるかを確認し、その後サーバー設定を確認してください。実際の利用状況を調べるには、対象アプリからリクエストを送る必要があります。テスト時の数値だけで、継続的な速度や長期的な安定性を判断しないでください。

Today Widget：操作後にアプリで状態を確認

概要と場所：Today Widget関連の設定は、システムウィジェットからのクイックアクセスに使います。Settingsで該当項目を確認し、システムの案内に従って利用可能な場所に追加してください。ウィジェットの表示位置や操作方法は、システムのバージョンによって異なる場合があります。

設定方法と注意点：追加後に一度操作し、Homeに戻って接続状態と選択中のサーバーが想定どおりか確認します。ウィジェットの表示はシステムによる更新タイミングの影響を受けるため、古い表示だけで接続が続いているか判断しないでください。表示されない、または更新されない場合は、システムでウィジェットの利用が許可されているか、アプリを初回起動済みかを先に確認します。そのためにルールファイルを書き換える必要はありません。

iCloud：同期・バックアップ・選択状態を区別

概要と場所：iCloud関連の項目は、アプリが対応するデータの同期や読み込みに使います。Settingsの該当項目を確認し、システムのiCloudにサインインしてアプリの利用が許可されていることも確認してください。Import from Cloud JSONが表示される場合は、その項目で読み込める形式のファイルを使います。任意のサブスクリプションテキストを同じ種類のファイルとして扱わないでください。

設定方法と注意点：同期先のデバイスでデータが受信されたことを確認してから、現在選択中のConfigとサーバーを確認してください。選択状態、システムの接続権限、すべてのローカル設定まで同じように同期されるとは限りません。同期の前後に利用可能な設定ファイルのコピーを保存し、競合が発生した場合は、どちらの内容を残すか先に確認します。サーバーの認証情報やサブスクリプションURLは機密情報です。クラウドアカウントへのアクセス権限にも注意してください。プラットフォーム間で同期できるデータの範囲は、実際の機能に従います。

Settings · Diagnostics

Diagnostics：症状を検証可能な手順に置き換える

概要と場所：Diagnosticsは診断機能への入口で、アプリが提供するネットワーク確認情報を収集または表示します。SettingsでDiagnosticsを開き、現在の画面で利用できる項目を選択してください。診断ログは特定のテスト時点の環境を記録したものです。古いログを現在のネットワーク状況の判断に使わないでください。

使い方：まず、症状を具体的に記録します。スイッチを入れても接続できないのか、すべての接続先で失敗するのか、1つのドメインだけ失敗するのか、サブスクリプションを更新できないのかを整理してください。そのときのネットワーク、Global Routing、選択中のサーバー、Configを記録してから、問題を1回だけ再現します。発生時刻に沿ってログを確認し、名前解決の失敗、接続タイムアウト、認証失敗、ルールの選択違いを区別します。先に設定をまとめて変更してからログを集めると、ログと元の症状が対応しなくなります。

まず基本のネットワークを確認。条件をそろえてローカルネットワークからのアクセスと比較し、ネットワーク未接続や認証が必要な状態を除外します。
次に接続情報を確認。サーバーアドレス、ポート、プロトコル、認証パラメーターを確認します。必要に応じて、登録済みの別項目と比較してください。
次にモードとルールを確認。現在のConfigが選択されていることを確認し、ルールのテキストだけでなく、リクエストに実際に適用されたポリシーを確認します。
最後に設定を戻して再テスト。検証できていない一時変更を元に戻し、同じ接続先に再度リクエストを送り、復旧前後の違いを記録します。

注意：ログを共有する前に、サブスクリプションURL、認証情報、その他の個人情報を削除してください。エラーの種類、発生順序、必要な環境情報を残せば十分です。設定の更新や切り替え後に問題が起きた場合は、すぐにすべてのデータを消去せず、保存してある以前の設定ファイルと比較してください。症状別の詳しい手順はトラブルシューティングガイド、初回接続の手順は使い方ガイドをご覧ください。