Shadowrocket
機能と設定
まず Global Routing を設定し、ルール、サーバー、DNS を確認します。一度に変更するのは1項目だけにして、同じリクエストで結果を検証してください。
iPhone、iPad、Mac、Windows、Android、Linux に対応しています。以下では iPhone／iPad の英語表示を例に説明します。他のプラットフォームでは、設定項目の場所や利用できる機能が異なる場合があります。
- Global Routing → ルール → ポリシー
- 設定を1項目ずつ変更
- ログと実際のリクエストで検証
Global Routing の3つのモード
モードは、リクエストを設定済みルールで判定するかどうかを決めます。接続先サーバーを選ぶ設定ではありません。
概要：Global Routing は全体のルーティング方式です。Home で Global Routing を開き、Config、Proxy、Direct を選択します。通常のドメイン・アドレス別振り分けには Config を使います。ルールの影響を切り分ける場合に限り、一時的に Proxy または Direct と比較してください。「モードの切り替え」と「接続の開始」は別の操作です。モードを選んだ後、Home で接続状態も確認しましょう。
| 画面上の選択肢 | リクエストの処理方法 | 適した用途 | 確認するポイント |
|---|---|---|---|
| Config · 設定 | 現在の設定にあるルールに従ってポリシーを決定します。 | 通常の振り分け、LAN への直接接続、特定ドメインへのポリシー指定。 | 現在の設定、ルールの順序、FINAL。 |
| Proxy · プロキシ | 引き継いだリクエストをプロキシ経由で処理し、通常の振り分けルールでは個別に判定しません。 | ルールによる経路の違いかどうかを一時的に切り分ける。 | 選択中のサーバーと実際に接続できるかどうか。 |
| Direct · 直接接続 | 引き継いだリクエストを直接接続で処理します。 | ローカルネットワークから対象にアクセスできるか比較する。 | 現在のネットワーク、対象サービス、DNS。 |
設定方法：まず Config で使用する設定を確認します。次に Home に戻り、Global Routing を Config にして、登録済みサーバーを選択してから接続を開始します。同じ対象に新しいリクエストを送り、ログで一致したルールとポリシーを確認してください。検証中はネットワーク条件を変えずに保ちます。Wi-Fi とルーティングモードを同時に切り替えると、どちらの変更が影響したか判断しにくくなります。
注意点：Proxy にすればすべての接続問題が解決するわけではありません。また、Direct はシステムの VPN 接続を無効にする設定ではありません。モードが示すのはルーティング処理です。システムが通信を引き継ぐ範囲、設定内の例外、プラットフォームのネットワーク機能も結果に影響します。切り分けが終わったら元のモードに戻し、一時的な設定を残さないようにしてください。
ルールの種類とポリシー
ルールは「何に一致するか」を、ポリシーは「一致後にどう処理するか」を決めます。
Config で現在の設定を編集
概要：ルール振り分けでは、リクエストのドメインやアドレスなどの条件に応じて処理方法を選びます。Config で現在使用中の設定を開き、編集画面から [Rule] セクションを確認します。ルールは上から順に評価され、一致した行のポリシーが適用されます。そのため、より具体的な例外は、通常、範囲の広いルールより前に置きます。
設定方法：DOMAIN は完全一致するドメイン、DOMAIN-SUFFIX はドメインとそのサブドメイン、DOMAIN-KEYWORD はドメインに含まれるキーワードに一致します。IP-CIDR と IP-CIDR6 は、それぞれ IPv4 と IPv6 のネットワーク範囲に一致します。GEOIP は IP アドレスの位置情報データに基づいて一致します。USER-AGENT はリクエスト情報を取得できる場合に限られるため、すべての接続で利用できるとは限りません。
注意点：PROXY はプロキシ経由、DIRECT は直接接続、REJECT はリクエストの拒否を指定します。画面上の Proxy とルールポリシーの PROXY は大文字・小文字が異なります。設定を編集するときはキーワードをそのまま記述してください。FINAL はそれ以前のルールに一致しなかった場合のフォールバックです。末尾に置いてください。前の方に置くと、その後のルールが適用されません。
上記は構文の例であり、すべてのネットワークで使える完成済み設定ではありません。変更前に元の設定を複製して保存し、変更後は新しいリクエストを送り、一致記録を確認してください。既存の接続では以前の経路が再利用されることがあるため、長時間接続中の通信を更新しただけで新しいルールが反映されていないと判断しないでください。セクション構成や一致条件について詳しくは、設定リファレンスをご覧ください。
サブスクリプションとサーバーの管理
サーバー情報、サブスクリプション元、設定ファイルは別々の項目として管理します。
Home、Add Server、Subscribe
概要：サーバー項目にはアドレス、ポート、プロトコル、認証情報を保存します。Subscribe は、ユーザー自身が持つサブスクリプション URL からサーバー一覧を取得する機能です。Config にはルーティングルールなどを保存します。サブスクリプションを読み込んでも、用途に合った振り分けルールが自動的に設定されるわけではありません。また、Config を切り替えてもサーバー一覧は置き換わりません。
場所と設定方法：Home で Add Server を選び、情報の提供元が指定したプロトコルに従って項目を入力します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard では必要な項目が異なります。名前が似ているからといって、別のプロトコルの設定を流用しないでください。QR コードがある場合は Scan QR Code、サブスクリプション URL がある場合は Subscribe を選択します。URL を確認して保存し、更新を実行した後、一覧から項目を選択してください。
- 読み込み前に、内容が単一のサーバー情報、サブスクリプション URL、設定ファイルのどれかを確認し、対応するメニューを選んでください。
- 保存後、項目数と名前が想定どおりか確認してから Connectivity Test を実行します。
- 項目を1つ選んで接続し、通常の通信を試します。使えることを確認してから古い項目を整理してください。
注意点：サブスクリプションを更新すると、その配信元から作成された項目が上書きされる場合があります。手動で変更する前に、次回更新への影響を確認してください。サブスクリプション URL にアクセス情報が含まれる場合があります。公開スクリーンショットやチャット、問い合わせ内容には載せないでください。Connectivity Test の結果は選択したテスト方法での状態を示すもので、実際のアクセス確認の代わりにはなりません。更新に失敗しても、保存済みのサーバーがすべて同時に使えなくなったとは限りません。
設定を移行する場合は、設定の書き出しとサーバー情報の書き出しを区別してください。認証情報を含む内容を、通常のルール設定のように公開しないよう注意が必要です。見慣れない設定ファイルは、用途をファイル名だけで判断せず、ルール、DNS、書き換え設定を確認してから有効にしてください。
On Demand によるオンデマンド接続
まず手動接続を確認してから、自動接続の条件を追加します。
概要：On Demand は、設定したネットワーク条件に応じてシステムに接続の開始を要求し、手動操作の手間を減らします。制御するのは接続を開始するタイミングです。ドメインごとに PROXY と DIRECT のどちらを使うか判断する機能ではありません。接続後のリクエストは、Global Routing と現在の設定に従って処理されます。
場所と設定方法：Settings で On Demand を開き、画面に表示される Wi-Fi、モバイル通信、ネットワークの例外条件を確認します。まず手動接続が成功することを確かめてから、必要な条件を1つだけ有効にします。保存後、該当するネットワークに切り替えてシステムの接続状態を確認し、同じリクエストで検証してください。特定の Wi-Fi に例外を設定する場合は、ネットワーク名が正確か、条件同士が打ち消し合っていないかを確認します。
注意点：On Demand が有効な場合、手動で切断しても条件に一致するとシステムが再接続することがあります。これは接続スイッチの故障とは限りません。自動接続を一時停止するには、関連する条件を無効にしてから切断してください。Web 認証が必要な Wi-Fi では、まずネットワークにログインしてからテストします。システム権限、スリープ、ネットワーク切り替えのタイミングも動作に影響するため、どの状況でも即座に再接続するとは限りません。
Data の通信量統計
まず集計範囲を確認してから数値を比較します。アプリの記録はサービス提供元の請求額ではありません。
概要：Data では、アプリが記録できる通信量を確認できます。接続中のアップロード・ダウンロード量の変化や、リクエストが継続して発生している状況を把握するのに役立ちます。集計対象と期間は画面に表示される範囲によって異なります。ある画面の合計を、端末全体の通信量と同一視しないでください。
場所と使い方：Data を開き、表示中の集計範囲と利用できる絞り込み項目を確認します。通信量の異常を調べるときは、操作前の数値を記録し、関係のないアプリのバックグラウンド動作を止めて、対象の操作を1回だけ実行します。その後 Data に戻って変化を比較してください。リセット機能がある場合は、必要な記録を残してから、前後の比較に使う情報を失わないことを確認してリセットします。
注意点：プロトコルのオーバーヘッド、再試行、集計期間、計測方法の違いにより、アプリの数値とシステムやサービス提供元の記録は異なることがあります。サブスクリプションに表示される使用量は、通常、応答に含まれる情報に基づくもので、Data のローカル集計とは別です。使用量が表示されないからといって、サブスクリプションが無効とは限りません。通信量の増加はデータ転送があったことを示すだけです。通信が正常に完了したかどうかは、リクエストの結果とログも確認してください。
Settings の主な項目
設定の場所は現在のプラットフォームの画面で確認してください。Config 内の設定もあわせて確認が必要です。
DNS：ドメイン名の解決と設定元
概要と場所：DNS はドメイン名を IP アドレスに変換します。接続先だけでなく、アドレスに基づくルール判定にも影響することがあります。Settings で DNS 関連項目を探し、現在の Config で名前解決の設定が指定されているかも確認してください。一方だけを変更して、実際に適用される設定を見落とさないようにします。
設定方法と注意点：まず現在の動作する設定を保存し、問題がドメイン名の解決と、その後の接続のどちらで発生しているか確認してから、名前解決方式を変更するか判断します。変更後は同じドメインを再テストしてログを確認し、必要に応じて画面にある操作で関連するキャッシュを消去します。DNS、サーバー、ルールを同時に変更しないでください。暗号化 DNS を使う場合も、接続できるネットワーク経路が必要です。DNS サーバーのアドレスを入力しただけで、必ずアクセスできるわけではありません。
Test Method：Connectivity Test のテスト方法
概要と場所：Settings の Test Method では、Connectivity Test で項目を確認する方法を選びます。方法によって検証する階層が異なります。基本的な到達性に近い結果を示すものもあれば、テスト先からの応答にも左右されるものもあります。異なる方法の結果を同じ指標として比較しないでください。
設定方法と注意点：複数の項目を比較する際は、Test Method、テスト先、ローカルネットワークを固定し、複数回テストして結果を確認します。タイムアウトはサーバー、テスト先、現在のネットワークが原因の可能性があります。到達可能と表示されても、すべてのサービスにアクセスできるとは限りません。テストで問題の範囲を絞った後、実際に使うサービスへのアクセスを確認してください。遅延の数値だけで結論を出さないようにしましょう。
Today Widget：状態の確認とクイック操作
概要と場所：Today Widget は、システムが対応するウィジェット画面から状態を確認したり、簡単な操作を実行したりする機能です。まず Settings で関連項目を確認し、システムのウィジェット管理方法に従って追加します。表示内容や操作できる範囲は、システムと現在のアプリ画面に準じます。
設定方法と注意点：アプリ本体の権限と接続設定を済ませてから、ウィジェットを設定して動作を確認します。表示の更新タイミングはシステムに左右されるため、更新されていない状態だけで接続結果を判断しないでください。表示が想定と異なる場合は Home に戻って現在の状態を確認します。ウィジェットを繰り返しタップするだけで確認を済ませないようにしてください。
iCloud 同期：デバイス間の設定管理
概要と場所：この項目に対応する Apple デバイスでは、Settings の iCloud 関連設定から、アプリが同期に対応している内容を管理できます。同期にはシステムの iCloud 状態、アカウント、アプリの権限が必要です。サーバー、設定、履歴などすべての項目が同期されるとは限りません。
設定方法と注意点：まず、2台のデバイスで使用する iCloud アカウントが想定どおりか確認し、画面に表示される同期範囲を読みます。初めて有効にする前に、それぞれのデバイスでローカルコピーを保存してください。片方のデバイスで変更を完了して同期を待ち、もう一方で内容を確認します。同時編集による上書きや競合を避けるためです。同期は独立したバックアップではなく、App Store の購入記録とも別です。設定の移行とアプリの再入手は別々に行ってください。
Diagnostics：トラブル対処用の情報を収集
概要と場所：Diagnostics では、接続問題の調査に使う診断情報を確認できます。Settings で該当する項目を探してください。名前解決、接続の確立、その後のリクエストのどの段階で失敗したかを特定するためのもので、自動修復機能ではありません。
設定方法と注意点：問題が起きたときのネットワーク種別、Global Routing、現在の設定を記録してから、画面の案内に従って診断を実行するかログを確認します。分析しやすいよう、問題の操作は1回だけ再現し、大量のテストを同時に行わないでください。共有前にサーバーアドレス、サブスクリプション URL、認証情報、不要なアクセス履歴を削除します。エラーの種類と操作手順を残すだけで十分です。機密情報を含むログ全体をそのまま公開しないでください。
設定後の確認手順
「接続できるか」「通信をどう振り分けるか」「自動的に接続するか」を分けて確認します。
- ネットワークの基本状態を確認。現在の Wi-Fi またはモバイル通信が使えることを確認します。Web 認証が必要な場合は先に認証を済ませ、テストに使ったネットワークを記録してください。
- サーバー情報を確認。プロトコル、アドレス、ポート、認証項目を確認してから Connectivity Test を実行します。テストに失敗しても、すぐにルールが原因だと決めつけないでください。
- Global Routing を確認。ルールで振り分ける場合は Config を選び、名前が似た別の設定ではなく、編集した設定が有効になっていることを確認します。
- 新しいリクエストを確認。対象に新しいリクエストを送り、一致したルールとポリシーを確認します。名前解決に失敗する場合は DNS を、ルールの一致が想定と異なる場合は順序と条件を確認してください。
- 最後に自動接続を確認。手動接続が安定してから On Demand を有効にし、ネットワーク切り替え、Today Widget の状態、Data の変化を確認します。
変更後に問題が起きたら、直前に変更した項目を元に戻し、同じテスト条件でもう一度確認してください。複数の設定を一度に変えるより、繰り返し確認できる変更前後の差のほうが参考になります。初めて使う場合は使い方ガイドを、ルールを1行ずつ確認する場合は設定リファレンスをご覧ください。インストールや入手方法については全プラットフォームのダウンロード案内をご確認ください。
Proxy では使えるのに Config では使えない場合、まず何を確認すればよいですか？
まず現在の設定を確認し、同じ対象へのリクエストが Config でどのルールとポリシーに一致するか比較します。先に評価される REJECT、DIRECT、範囲の広いルールに一致していないか、ドメインの名前解決結果も確認してください。一致記録を確認する前に設定全体を置き換えないでください。
切断しても自動的に再接続されます。停止するにはどうすればよいですか？
まず On Demand に現在のネットワークで有効な接続条件が残っていないか確認します。該当する条件を一時停止してから切断し、システムの状態を確認してください。それでも再接続を繰り返す場合は、システム内のほかの自動接続設定も確認します。