Shadowrocketの機能と設定

Global Routingでは、リクエストに適用するルーティング方式を選択します。通常はHomeから設定します。選択中のサーバーとは別の設定です。サーバーを選んでも、すべてのリクエストがそのサーバーを経由するとは限りません。プロキシ経由になるかどうかは、選択中のモードとルールの適用結果によって決まります。ルールに沿って振り分ける場合はConfig、選択したサーバーの基本的な接続性を確認する場合は一時的にProxy、現在のネットワークから直接アクセスできるか確認する場合はDirectを選びます。

設定を変更する前に、現在のモードを記録します。必要なモードを選択したらHomeに戻り、サーバーと接続スイッチを確認してください。テスト後は意図した設定に戻します。モード変更が適用されるのは以降のリクエストです。既存の接続には変更前の状態が残る場合があります。確認には新しいリクエストを実行し、必要に応じて接続し直してください。開いたままのページだけで判断しないようにしましょう。

ルールは「何に一致するか」、ポリシーは「一致した後にどう処理するか」を定めます。Configで使用する設定ファイルを選び、その中のルールを確認または編集します。通常は上から順に照合され、最初に適用されたルールのポリシーが使われます。FINALは、それまでのルールに一致しなかったリクエストの最終的な処理方法を指定します。そのため、具体的なルールは、より広い範囲に一致するルールより前に配置します。ファイル内に対象ドメインがあるかどうかだけで判断しないでください。

よく使われるルールの種類

DOMAINは完全一致のドメインを対象にします。DOMAIN-SUFFIXは指定ドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで判定します。IP-CIDRとIP-CIDR6はそれぞれIPv4、IPv6のアドレス範囲を指定し、GEOIPはIPアドレスの地域情報に基づいて判定します。USER-AGENTはリクエストから該当情報を取得できる場合に使います。あらゆる暗号化通信に適用できる汎用条件ではありません。

PROXY、DIRECT、REJECT

PROXYはプロキシ経由、DIRECTは直接接続、REJECTは一致したリクエストの拒否を指定します。設定で名前付きポリシーやポリシーグループを参照している場合は、指定先が存在するか、名前が一致しているか、選択内容が意図どおりかも確認してください。画面上のProxyはモード名、ルール内のPROXYはポリシーキーワードです。編集時はそれぞれの表記をそのまま使います。

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

上記はルールの順序を示す例であり、日常利用の設定ファイルとしてそのまま置き換えられるものではありません。ここでのDOMAIN-KEYWORD,adsはキーワード判定の例にすぎず、意図しないドメインにも一致する可能性があります。変更前に一致する範囲を確認してください。元の設定を保存し、一度に変更するルールの種類は一つに絞って、新しいリクエストで結果を確認します。ルール、DNS、サーバーを同時に変更すると原因を特定しにくくなります。

サーバー情報には接続先アドレス、ポート、プロトコル、認証などの設定が含まれます。サブスクリプションは、複数のサーバー情報をまとめて管理するためのものです。ここでは、ご自身がすでにサブスクリプションまたはサーバー情報をお持ちであることを前提に説明します。Homeではサーバーの確認、選択、管理を行います。Add Serverではサーバーを追加し、Scan QR Codeでは対応するQRコードを読み取れます。読み込む前に、内容がサブスクリプションリンク、単一サーバーのURI、ルールを含む設定ファイルのどれに当たるか確認してください。見た目が似たリンクでも、これらは相互に置き換えられません。

手動で追加する場合は、まずTypeを確認し、アドレス、ポート、プロトコルに必要な項目を入力します。たとえばShadowsocks、VMess、VLESS、Trojanでは、認証やトランスポートの設定が異なります。HTTPやSOCKS5なども、サーバー情報と一致するタイプを選んでください。名称から設定項目を推測したり、保存できるようにTLS、トランスポート、証明書関連の項目をむやみに削除したりしないでください。

Subscribeと設定ファイルの違い

Config画面のSubscribeは、設定ファイルのサブスクリプション操作に使います。サーバーのサブスクリプションを管理する場合は、サーバー用のインポートメニューまたは対応しているインポート方法を使ってください。読み込み後の内容で結果を確認します。サーバー情報はHomeに表示され、ルール設定はConfigに表示され、必要に応じて有効化できます。解析に失敗した場合は、入力の種類とリンクが完全かを先に確認してください。同じ内容を異なる場所に繰り返し読み込まないようにしましょう。

サブスクリプションの更新では、配信元から提供されたサーバー情報が更新されます。現在のルール設定も同時に変更されるわけではありません。更新後は、選択中のサーバーが残っているか、重複した情報がないか、自分で付けたメモを引き続き判別できるか確認してください。古いサブスクリプションを削除する前に所有者を確認し、使用中の手動登録を誤って削除しないようにしましょう。認証情報を含むサブスクリプションリンク、QRコード、サーバー詳細は慎重に管理し、公開の場に貼り付けないでください。

On Demandは、設定した条件に応じて接続を開始する機能です。ルールのポリシーを選択する機能ではなく、サーバーの接続性を確認するものでもありません。SettingsでOn Demand関連の項目を探し、実際の画面で利用可能なネットワーク条件を確認してください。設定を追加する前に、手動接続でサーバーとルールが正常に動作することを確認します。その後、自動接続の条件を設定すれば、問題が起きた際にサーバー自体の不具合と接続条件の未達を切り分けやすくなります。

接続したいWi-Fiまたはモバイル通信の環境を明確にし、条件、適用範囲、保存内容を一つずつ確認してください。設定後は対象のネットワークと別のネットワークの両方でテストし、システムの接続状態が意図どおりか確認します。iPhoneとiPadではネットワーク機能が異なる場合があります。各デバイスで実際に選択できる項目を使い、別のデバイスの条件をそのまま流用しないでください。

On Demandを有効にしている場合、手動で切断しても、その後ずっと切断状態が続くとは限りません。システムが条件を再び満たすと、接続が開始されることがあります。一時的に自動接続を止めたい場合は、Homeのスイッチを何度も操作するのではなく、まずOn Demandを確認してください。電池の消耗をこの設定だけの影響と決めつけず、実際の通信量、サーバーへの再接続、電波状況、バックグラウンド動作も確認しましょう。ルールの変更や接続トラブルの調査中は自動接続を一時的に無効にし、確認後に戻す方法もあります。

Dataでは、クライアントが記録した通信量を確認できます。Dataを開いたら、まず画面に表示される集計範囲とカウント方法を確認し、送信・受信などの記録を見ます。統計値は接続後にデータが送受信されたかを確認する目安になりますが、特定のリクエストが意図したポリシーで処理されたことを単独で証明するものではありません。アクセス経路を調べる場合は、ルールの適用情報や利用可能な接続記録も確認してください。

確認する際は、現在の数値を記録してから、対象を明確にしたアクセスを一度行い、再び画面を開いて変化を確認します。バックグラウンドアプリ、システムサービス、既存の接続も通信を発生させるため、短時間の増加分すべてを直前に開いたWebページの通信量とみなさないでください。カウントをリセットする場合は、必要な記録を保存し、リセットの対象範囲を確認します。集計期間の異なる数値を単純に差し引いて比較することはできません。

Dataの数値はサーバー側のアカウント残量でも、通信事業者の請求額でもありません。サーバー側の統計には異なる課金方式、集計期間、追加の通信量が含まれる場合があります。数値が一致しない場合は、まず集計条件をそろえてください。「接続中なのに想定した通信量がない」場合は、使用中のサーバー、Global Routing、対象リクエストを新たに実行したかを順に確認します。DIRECTに一致したため、プロキシ経由になっていない可能性もあります。

Settingsには、アプリの動作やツールに関する項目がまとめられています。変更前に、現在の設定ファイルにも同じ項目が定義されていないか確認し、全体設定だけを変更して使用中の設定内容を見落とさないようにしてください。以下では用途ごとに説明します。項目の場所や選択肢は実際の画面で確認してください。変更後は保存して動作を確認し、元に戻せるよう変更前の値を記録しておきましょう。

DNS：ドメイン名の名前解決

DNSはドメイン名を接続先のアドレスに変換します。SettingsのDNS関連メニューで設定を確認し、Configで使用中のDNS設定も確認してください。トラブル時は「ドメイン名を解決できない」のか「アドレスを取得した後に接続できない」のかを切り分けます。サーバーの接続先がドメイン名の場合、サーバー名の名前解決が接続確立に影響することもあります。DNSアドレスを指定する前に、書式、到達性、利用目的を確認してください。DNSの変更をあらゆる問題に対する一律の解決策と考えないようにしましょう。

IPv6、ローカルネットワーク内のドメイン名、異なるネットワーク環境を扱う場合は、名前解決の結果が現在のネットワークに適しているかも確認してください。DNSを変更した後はリクエストを再実行し、必要に応じて再接続します。キャッシュの影響にも注意してください。名前解決の問題を解決するために証明書の検証を無効にしないでください。証明書、ドメイン名、ルーティングのエラーは、それぞれ別に対処する必要があります。

Test Method：接続テスト方式

Test Methodでは、接続テストに使用する方式を選択できます。Settingsで項目を確認してください。設定後はHomeに戻り、Connectivity Testを実行して、選択した方式に応じて結果を判断します。方式ごとに確認する通信経路が異なるため、所要時間を方式間で直接比較するのは適切ではありません。テスト対象、現在のネットワーク、サーバーの状態も結果に影響します。

テストが成功しても、そのテスト条件で対応する経路が利用できたことを示すだけです。すべての対象サイト、DNS、ルールが正しいことを意味するものではありません。テストに失敗した場合は、選択した方式とテスト対象が適切かを確認し、続いてサーバーの設定とネットワークの状態を調べます。比較する場合は同じネットワーク、同じ方式でテストしてください。複数の設定を続けて変更した後、最後の結果だけで判断しないようにしましょう。

Today Widget：すばやく確認・操作

Today Widgetの設定では、システムのウィジェットに表示または操作できる項目を管理します。まずSettingsで関連する項目を確認し、システムでウィジェットを追加できる場所から設定してください。追加できるか、表示形式、更新のタイミングは、システムやデバイスの対応状況によって異なります。ウィジェットは日常の簡単な操作に便利ですが、詳細な設定はアプリ内で行ってください。

ウィジェットの表示はシステムの更新間隔に左右されます。古い状態が表示されている可能性があるため、現在の接続状況をウィジェットだけで判断しないでください。状態に食い違いがある場合はHomeを開いて、接続状況とサーバーを確認します。ロック画面に表示する内容は、プライバシーに配慮して選んでください。

iCloud：同期と機種変更の準備

SettingsでiCloud関連の項目を確認し、システムのiCloud権限から、アプリに必要な機能の使用が許可されているか確認します。同期する前に、画面で明示されている同期対象を確認してください。サーバー、設定、すべてのオプション、利用記録が一括で同期されるとは限りません。機種変更前に、重要な内容が移行先のデバイスに実際に表示されることを確認し、必要なバックアップを保存してください。

iCloudの同期とApp Storeでの購入済みアプリの復元は別の操作です。前者はアプリのデータに関わり、後者はアプリを入手する権利の復元に使います。機種変更後は、サーバー情報、有効な設定、システムの接続許可も確認してください。購入履歴と復元の手順は、購入済みアプリの復元方法をご覧ください。

Diagnosticsは問題の切り分けに役立つ診断機能です。Settingsでメニューを確認してください。実行前に、問題が発生したネットワーク環境、使用中のサーバー、Global Routing、設定名を記録し、実際に利用できるチェックを実行します。診断結果は原因を絞り込むためのもので、自動修復を保証するものではありません。表示された一行だけで設定全体が正常だと判断せず、実際のアクセス結果と照らし合わせてください。

以下の手順で、最小限の確認経路を作れます。一度に変更する要素は一つにし、変更前後の結果を記録してください。一時的にProxyへ切り替えるとアクセスでき、Configでは失敗する場合は、ルール、ポリシーの指定先、設定内容を優先して確認します。どちらでも失敗する場合は、サーバー情報、名前解決、現在のネットワークを調べてください。Directの結果が示すのは直接接続の状況だけであり、プロキシサーバーが正常だとは判断できません。

1. 基本状態を確認します。現在のネットワークで接続できること、システムの許可が完了していること、Homeで意図したサーバーが選択されていることを確認します。
2. サーバーを確認します。同じTest MethodでConnectivity Testを実行し、アドレス、ポート、認証、プロトコルの設定を確認します。
3. ルーティングを確認します。Global Routingを確認し、Configで有効な設定ファイル、ルールの順序、FINALの指定先を調べます。
4. DNSを確認します。名前解決の失敗と接続の失敗を切り分け、現在のDNS設定を記録してから、必要な項目だけ変更します。
5. アクセスを再試行します。Dataと利用可能な記録で結果を確認し、既存の接続やキャッシュによる誤判定を避けます。

診断情報を外部に送る前に、サブスクリプションのリンク、認証情報、サーバーの詳細、アクセス記録が含まれていないか確認し、機密情報を削除してください。問題を報告する際は、「実行前の状態、操作手順、実際の結果、期待した結果」を記載すると、「接続できない」とだけ書くより再現・特定しやすくなります。