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

Shadowrocketの機能とよく使う設定

接続の処理方法を決めてから、自動接続やテスト、診断を設定します。サーバーは接続先を決め、Global Routingは処理方法を、Config内のRuleは振り分け結果を決めます。この3つは分けて確認してください。

ShadowrocketはiPhone、iPad、Mac（AppleシリコンおよびIntel）、Windows、Android、Linuxに対応しています。以下ではiPhone / iPadの画面を基準に操作方法を説明します。他のプラットフォームでは、項目の場所やシステム連携、利用できる設定が異なる場合があります。

初めて設定する場合は入門ガイドをご覧ください →

Global Routing：Config、Proxy、Direct

Global Routingでは、現在の接続に適用する全体的な処理方法を選択します。HomeでGlobal Routingを開き、用途に応じてConfig、Proxy、Directを選びます。日本語でいう「設定」「プロキシ」「直接接続」は、それぞれ英語の画面項目に対応します。これらはサーバーを選ぶ項目ではなく、不足しているサーバー情報を補うものでもありません。

画面の項目 接続の処理方法 用途 使用前の条件
Config（設定） 現在のConfigを読み込み、Ruleの一致結果に応じてポリシーを選択します。 ドメインや接続先などの条件に応じて、日常的に通信を振り分けます。 使用中のConfigと、ルールが参照するポリシーを確認してください。
Proxy（プロキシ） 通常の接続を選択中のプロキシ経由で処理します。実際の動作はシステムや関連設定にも左右されます。 現在のサーバーでリクエストを処理できるか、一時的に確認します。 有効なサーバーが選択され、プロトコルのパラメーターがすべて設定されていること。
Direct（直接接続） 選択中のプロキシサーバーを経由せず、直接接続します。 現在のネットワークから接続先へ直接アクセスした場合の状態を比較します。 現在のネットワークから接続先にアクセスできること。

普段使いでは、まずConfigを確認

接続先によってPROXYとDIRECTを使い分ける場合は、Configを選択し、Config画面で正しいファイルが有効になっていることを確認します。設定ファイルを読み込んだだけでは、現在のConfigとして有効になったとは限りません。また、サーバーを選択しても、すべてのリクエストがそのサーバーを経由するとは限りません。現在のConfig、Global Routing、選択中のサーバーをあわせて確認してください。

問題を調べるときは、一時的にProxyに切り替え、同じ接続先にアクセスできるか確認します。Proxyでは正常でConfigでは異常が起きる場合、すべてのプロトコル設定をすぐに変更するのではなく、ルールの一致状況、ポリシーの参照先、DNSを確認してください。Directは直接接続時の比較に使います。比較の際は同じ接続先とネットワークを使い、その都度リクエストをやり直してください。以前の接続結果を切り替え後の状態と取り違えないようにします。

Proxyを選んでも接続が必ず成功するわけではなく、Directにしてもシステムのネットワーク設定がすべて無効になるわけではありません。テスト後は、通常使用する予定のモードに戻してください。確認用のモードのまま使い続けると、想定とは異なる経路で通信することがあります。

Rule：条件と処理ポリシー

Ruleは「接続がどの条件に一致したら、どのポリシーで処理するか」を定める順序付きリストです。現在のConfigから確認できます。編集する場合は、まず元の設定を複製して保存し、ルールの記述を確認してください。ルールは通常、上から順に評価されます。具体的な条件を広い条件より前に置き、前のルールに一致しない接続はFINALで処理します。

よく使うルールタイプ

  • DOMAIN：指定した完全なドメイン名に一致します。特定のホスト名だけを対象にする場合に適しています。
  • DOMAIN-SUFFIX：指定したドメインとそのサブドメインに一致します。同じドメイン配下を同じポリシーで処理する場合に適しています。
  • DOMAIN-KEYWORD：ドメイン名に含まれるキーワードに一致します。対象範囲が広いため、関係のない接続まで含まれないか確認してから使ってください。
  • IP-CIDRとIP-CIDR6：それぞれIPv4とIPv6のアドレス範囲に一致します。URLの文字列を対象にするものではありません。
  • GEOIP：接続先IPアドレスの位置情報に基づいて一致します。判定結果はIPアドレス情報データベースや実際の名前解決結果に左右されます。
  • FINAL：それまでのルールに一致しなかった接続を処理します。デフォルトの通信経路が想定どおりか確認してください。

PROXY、DIRECT、REJECTの役割

ルールタイプは「どの接続を選ぶか」、ポリシーは「選んだ接続をどう処理するか」を定めます。PROXYはプロキシ経由、DIRECTは直接接続、REJECTは接続拒否です。Configが名前付きポリシーを参照している場合は、その名前が実際に何を指しているかも確認してください。ルールが記述されているだけで、設定が完成しているとは限りません。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.net,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT

以下は構文を説明するための例であり、完全なConfigでも利用可能なサーバー情報でもありません。1行目はexample.comだけに一致し、サブドメインは自動的に含みません。2行目はexample.netとそのサブドメインに一致します。最後のFINAL,DIRECTは、それ以前のルールに一致しなかった接続を直接処理するという意味で、すべての接続をデフォルトでPROXYに送る設定ではありません。

編集後は保存し、変更したConfigが使用中であることを確認してから、実際のアクセス記録でルールの一致結果を確認します。1つのページから複数のドメインにリクエストが送られることがあります。ページのメインドメインにルールが一致しても、画像やログインなどのリソースが同じ経路を使うとは限りません。ルールの構文と例はルールキーワード入門をご覧ください。

Subscribeとサーバー管理

サーバー項目には、接続先に必要なプロトコル、アドレス、ポート、認証パラメーターが保存されます。Subscribeでは、すでにお持ちの購読URLからサーバー項目を更新できます。サーバーの確認や選択は主にHomeから行い、手動で追加する場合は通常Add Serverを使います。読み込む前に、それが購読URL、単一のサーバーリンク、完全なConfigファイルのどれにあたるかを確認してください。文字列としてコピーできるからといって、同じ方法で読み込めるとは限りません。

読み込み後は構成を確認してからテスト

  1. 手元の情報に合った方法で読み込みます。単一のサーバー項目はAdd Serverでプロトコルを選んで入力し、QRコードはScan QR Codeから読み取ります。
  2. 読み込んだ項目を開き、プロトコル、アドレス、ポートに加えて、そのプロトコルに必要な認証情報や通信パラメーターを確認します。
  3. Homeで使用するサーバーを選択し、Connectivity Testを実行してから、アクセス先がわかっているサイトを実際に開きます。
  4. Configを使用する場合は、ルールが参照するポリシーが現在のサーバーまたは有効なポリシーを正しく指しているか確認します。

購読を更新すると、リモートの内容に基づいてサーバー項目が再取得されます。購読管理にあるサーバーを直接編集した場合、次回の更新で変更が上書きされることがあります。長期的に残したい変更は、あらかじめ別途バックアップしてください。複数の購読に似た名前の項目があっても、アドレスやパラメーターが同じとは限りません。提供元や用途を区別できるローカルメモを付けると管理しやすくなります。

購読にサーバー一覧が含まれていても、現在の用途に合ったRuleやDNS設定まで含まれているとは限りません。更新に失敗した場合は、まずURLが完全で有効かを確認し、現在のネットワークからそのURLにアクセスできるか調べてください。購読URLに含まれる認証情報を、公開スクリーンショットやログ、掲示板などに載せないでください。問い合わせる際は、認証情報や個人を特定できる情報を削除してください。

購読の削除やサーバーの一括整理を行う前に、現在のConfigがそれらのサーバーを参照していないか確認します。サーバーを選択できることと、実際に接続できることは別です。Connectivity Testの結果もテスト方法によって変わります。判断方法は後述します。追加と読み込みの手順は入門ガイドをご覧ください。

On Demand：条件に応じた接続

On Demandを使うと、設定した条件が満たされたときにシステムが接続を開始します。手動操作を減らしたい場合に便利です。iPhone / iPadでOn Demandを設定する際は、まず登録済みの条件を確認してから、有効にするか判断してください。条件の種類や項目の場所は、アプリとシステムの現在の画面をご確認ください。On Demandが決めるのは「いつ接続するか」であり、「リクエストをどのルールで処理するか」ではありません。

手動接続を確認してから自動接続を有効にする

まずOn Demandを無効にして、手動で接続し、サーバー、Config、DNSが正常に機能することを確認します。その後、必要な条件を一度に1つずつ追加してください。ネットワーク環境に応じた条件を設定する場合は、それぞれの環境で接続と切断の動作を確認してから、別の環境でも試します。1つのWi-Fiで成功しても、モバイル通信や他のWi-Fiで想定どおりに動作するとは限りません。

On Demandが有効な場合、手動で切断しても条件が再び満たされると、システムが接続を再開することがあります。これは接続条件に沿った動作であり、スイッチの故障とは限りません。一時的に停止するには、先にOn Demandの条件を変更または無効にしてから、現在の接続を切断してください。Global Routingを変更しただけでは、条件に応じた自動接続が停止しない場合があります。両者は別の設定です。

自動接続を有効にしても、期限切れの購読、パスワードの誤り、接続できないサーバーは解決しません。ルールとサーバーが安定してから有効にすると、基本設定を確認できていない段階で、再接続の繰り返しと設定ミスが混在するのを避けられます。バッテリーへの影響は、ネットワークの切り替え頻度、接続時間、実際の通信量を踏まえて確認してください。スイッチの状態だけでは判断できません。

Data：通信量の確認と注意点

Dataでは、アプリに記録された通信量を確認できます。継続的な通信の有無、操作によるデータ通信、長期的な使用傾向を把握する際に役立ちます。Dataを開いたら、まず集計範囲と表示期間を確認してから数値を見てください。表示の細かさはプラットフォームや画面によって異なり、すべての端末で同じ項目が表示されるとは限りません。

再現できる簡単な操作で比較する

特定の操作を確認する場合は、まず現在の統計値を記録します。接続先を開いて明確な操作を1回行い、Dataに戻って変化を確認してください。画面にリセット機能がある場合、残しておきたい記録を保存してからリセットし、新たに計測します。統計のリセットはローカルの確認基準を消去するだけで、利用中のサービスの通信量をリセットするものではありません。

Dataの統計は、通信事業者の請求明細や、利用中のサービスの課金記録とは異なります。トンネルのオーバーヘッド、再送、バックグラウンド通信、集計方法によって差が生じることがあります。通信量が増えた場合、記録対象の範囲内でデータが送受信されたことはわかりますが、その数値だけでWebページが完全に読み込まれたか、想定したサーバーからコンテンツを取得したかは判断できません。

待機中も通信量が増え続ける場合は、システムのバックグラウンド動作、On Demandの条件、リクエスト記録をあわせて確認してください。特定の統計値を下げるために、複数のシステム機能を同時に無効にするのは避けましょう。まず接続元を特定してから設定を調整すると、比較可能な状態を保てます。

Settings：よく使う項目と設定方法

Settingsには、テスト、システム連携、診断に関する項目があります。ネットワークの動作は現在のConfigにも左右されることがあるため、変更前に設定の適用範囲を確認してください。全体設定、現在のConfig、個別サーバーのパラメーターのどれに該当するかを見極めます。変更前の値を記録し、一度に1項目だけ変更して、同じ接続先で再テストしてください。

DNS：名前解決を確認してから経路を判断

DNSはドメイン名をIPアドレスに変換します。DNSの設定はSettings内の項目にある場合と、現在のConfigのDNS項目で定義されている場合があります。まずConfigにDNSの設定があるか確認し、次に指定したアドレスへ接続できるか、意図した設定かを確認してください。Webページが開かないからといってDNSを繰り返し変更したり、DNSを変更すればGlobal Routingも自動で変わると思い込んだりしないでください。

ドメインルールとアドレスルールは、判定対象が異なります。ドメインが正しくルールに一致していても、名前解決後の接続先に到達できないことがあります。サーバーへの接続が正常でも、ドメインの名前解決に失敗する場合もあります。問題を調べる際は、ドメイン名、名前解決の結果、エラーが発生した段階を記録すると、DNS、ルール、サーバーのどこに原因があるか判断しやすくなります。変更後はリクエストを再実行し、必要に応じて実際の画面にある方法でキャッシュを処理してください。以前の名前解決結果で新しい設定を検証しないよう注意します。

Test Method：テスト結果の意味を確認

SettingsのTest Methodでテスト方法を選ぶと、接続テストの動作に影響します。サーバーの結果を比較する前に、選択中の方法で何をテストし、どの条件で判定するのか確認してください。方法の異なるテスト結果を同列に比べたり、テスト値をブラウザーのダウンロード速度と同じものとみなしたりすることはできません。

比較する際は、テスト方法、ネットワーク、接続先を統一してください。サーバーのテストに失敗しても実際のアクセスが正常な場合は、まずテスト方法がその接続に適しているか確認します。テストに成功してもページに問題がある場合は、接続先のサービス、DNS、ルールを引き続き確認してください。Connectivity Testは原因を絞り込むための機能であり、すべてのアプリのリクエストを保証するものではありません。

Today Widget：システムのショートカット

Today Widgetは、システムが対応するウィジェット機能で利用できます。関連項目はSettingsで確認できますが、追加できるか、どのように表示されるかはシステムとアプリが提供する機能によって異なります。まずアプリ内でサーバーを選択し、手動接続を確認してから、システムのウィジェット編集手順に従って追加してください。システムに該当する項目が表示されない場合は、実際に利用できる機能をご確認ください。

ウィジェットは状態の確認や簡単な操作に適しています。複雑な編集はアプリ内で行ってください。ウィジェットとアプリ内の表示が一時的に異なる場合は、設定を削除したり購読を読み込み直したりする前に、アプリで接続状態を確認し、システム側の更新状況を調べます。

iCloud：同期範囲とバックアップの手順

iCloudの同期設定は、システムアカウント、iCloudの利用状況、アプリの設定をあわせて確認してください。有効にする前にSettingsで同期対象を確認し、すべてのサーバー、Config、統計、接続状態が同期されると決めつけないようにします。端末ごとのローカル設定やシステム権限も、同期によって引き継がれるとは限りません。

別の端末で初めて使う前に、両方の端末で重要な設定をバックアップし、どちらの内容を残すか確認してください。不足している項目がある場合は、まず同期を待ち、アカウントとネットワークを確認します。同じ名前のファイルを続けて複数読み込むのは避けてください。同期は設定内容を転送する機能で、接続確認の代わりにはなりません。同期後も各端末でGlobal Routing、現在のConfig、サーバーを確認してください。

Diagnostics：問題の段階ごとに情報を集める

Diagnosticsでは、現在のバージョンで利用できる診断項目を確認または実行できます。通常はSettings内の関連項目から開きます。「接続できない」という状態を、サーバーに接続できるか、ドメインを名前解決できるか、どのルールに一致するか、特定の接続先だけで起きるか、といった確認可能な問題に分けるために使います。実際に画面で利用できる項目を確認し、情報収集のためにすべての診断機能を常時有効にする必要はありません。

診断時は4種類の状況を記録

  1. 環境：Wi-Fiとモバイル通信のどちらを使用中か、問題が特定のネットワークだけで起きるか。
  2. モード：Global RoutingがConfig、Proxy、Directのどれか、どのConfigを使用中か。
  3. 対象：購読の更新、サーバーのテスト、特定の接続先への実際のリクエストのうち、どれが失敗したか。
  4. 症状：画面に表示された具体的なエラー、発生時刻、再現可能な操作手順。

すべての接続先に接続できない場合は、まず現在のネットワーク、サーバーのアドレスとポート、認証パラメーター、システム時刻を確認します。特定の接続先だけで問題が起きる場合は、その接続先のDNS、ルールの一致状況、サービスの状態を確認してください。Configだけで問題が起き、Proxyでは正常な場合は、再インストールから始めず、Configの参照先と振り分けルールを確認します。

診断情報を共有する前に、購読の認証情報、パスワード、個人用アクセスドメインなどの機密情報を削除してください。診断後は不要になった詳細記録を無効にし、書き出したファイルも適切に管理します。タイムアウトや接続失敗の確認手順は接続タイムアウトのトラブル対処ガイドをご覧ください。プロトコルの各項目についてはプロトコル技術リファレンスをご確認ください。

よく使う設定の確認手順

すべての項目を一度に変更するのは避けましょう。まず最小限の設定で接続を確認し、その後ルール、自動接続、システムのショートカットを段階的に追加すると、変更の影響を特定しやすくなります。以下の手順は、使用中の設定で突然問題が起きた場合の確認にも使えます。

  1. 入力情報を確認：手元のサーバー情報または購読情報の種類を確認し、プロトコル、アドレス、ポート、認証パラメーターがそろっているか調べます。
  2. サーバーを確認：Homeで想定した項目を選択し、同じTest MethodでConnectivity Testを実行してから、実際にアクセスします。
  3. モードを確認：Global Routingを確認します。ルールに従って処理する場合はConfigを選択し、現在のファイルを確認してください。
  4. ルールの一致を確認：Ruleの順序、ポリシーの参照先、FINALを確認し、リクエスト記録から接続先への経路を判断します。
  5. 名前解決を確認：DNSの設定元と適用範囲を確認し、名前解決の失敗とサーバーへの接続失敗を混同しないようにします。
  6. 自動接続を設定：手動接続が安定してからOn Demandを有効にし、ネットワーク環境ごとに動作を確認します。
  7. 基準を保存：Configのコピーを保存し、DataとDiagnosticsでその後の変化を比較してから、ウィジェットや同期の設定を検討します。

各項目を変更するたびに同じ接続先を再テストし、変更前後の結果を記録してください。新しい設定で問題が起きた場合は、設定を追加して対処するのではなく、直前に変更した項目を元に戻します。これにより、正常に動作する設定を保ち、次回の確認も明確な状態から始められます。

このページでは、各機能の役割と設定範囲を解説しています。初回の読み込みがまだの場合は入門ガイドに沿って操作してください。入手方法、各プラットフォームへのインストール、購入の復元については全プラットフォーム対応ダウンロードガイドをご覧ください。具体的な問題はFAQから種類別に探せます。