Shadowrocket Settings 設定ガイド

Chapter 01

Settings の確認順序と復元可能な基準状態

まず接続状態、ルーティング方式、設定パラメータを分けて確認する

Shadowrocket の問題は、単一のスイッチだけで発生するとは限りません。Home の接続状態、Global Routing の現在の方式、選択中の Config、サーバー情報、Settings の各パラメータが組み合わさって起こることが多くあります。調整を始める前に、Home で選択中のサーバーまたは設定が想定どおりか確認し、Global Routing が Config、Proxy、Direct のどれになっているかを記録してください。Config は設定ファイルの Rule を順番に照合します。Proxy は対象の通信を現在の Proxy に渡します。Direct は直接接続します。3つは用途が異なるため、Direct で見た結果を Config の Rule が機能していない証拠とみなしたり、Proxy で特定の DIRECT Rule の適用状況を判断したりしないでください。

Settings は、名前解決、接続トリガー、テスト方法、ログ記録、同期、ローカルポートなどの動作を調整するためのものです。サーバー情報の代わりになったり、未設定のサービスを自動的に補ったりするものではありません。このガイドでは、ユーザーが自分の Subscribe アドレスまたはサーバーパラメータをすでに持ち、それらを元の提供元が管理する情報だと理解していることを前提にしています。Shadowrocket は App Store で購入する買い切り型の有料クライアントです。クライアントの買い切り ≠ 回線プランであり、アプリを購入しても利用可能なサーバー情報は含まれません。開発者名 Shadow Launch Technology Limited、アプリ ID 932747118、ストアへの入口を確認する方法は、ダウンロードガイドの正規版確認をご覧ください。

変更前に記録する4項目

設定を変更する前に、4つの基準を記録しておくことをおすすめします。1つ目は、現在の家庭用 Wi‑Fi、職場の Wi‑Fi、モバイル通信などのネットワーク環境です。2つ目は、Home で実際に選択しているサーバー項目です。3つ目は、現在の Config 名と Global Routing の方式です。4つ目は、「特定のドメインだけ名前解決できない」「モバイル通信に切り替えても自動接続しない」「Connectivity Test が途中で停止する」など、再現可能な症状です。この4項目があれば、「使えない」という曖昧な状態を検証可能な条件に分解でき、設定を戻した後に元の状態へ復帰したか判断しやすくなります。

変更時は、一度に1項目だけ調整する単一変数の方法を採用します。保存後にいったん接続を切り、再接続してから同じ検証を行ってください。DNS、Config、サーバー、On Demand の条件を同時に変えると、問題が一時的に解消しても、どの変更が作用したのか判断できません。新しい問題が起きた場合も、正確に元へ戻すことが難しくなります。DNS、IPv6、Proxy ポート、iCloud 同期のように複数の場面へ影響する項目では、単一変数での記録が特に重要です。

デフォルト値と推奨値の考え方

Settings の初期状態は、ストア版、デバイスのシステム、既存設定の移行状況によって変わる場合があります。そのため、このガイドでは特定の数値をすべてのデバイスに共通するデフォルト値として扱いません。項目を確認するときは、クライアントに現在表示されている値、再インストール後にシステムが示す状態、Config に明示されたパラメータを分けて考えてください。Config に明示された項目は、画面の慣例だけに依存するより再現しやすい傾向があります。ただし、構文が正しく、そのパラメータの適用範囲を理解していることが前提です。

推奨値は、複雑であるほど良いわけではありません。安定して使えている場合は、システムまたは Config ですでに機能している値を優先して維持してください。上書き設定を追加するのは、具体的な問題を説明できる場合に限ります。DNS の名前解決に失敗したときだけ DNS を調整し、ネットワーク切り替え時の動作が想定と違うときだけ On Demand を確認し、テスト結果と実際のアクセスが一致しないときだけ Ping または Connectivity Test の方法を見直します。この順序なら、診断機能を高速化機能と取り違えず、用途不明の設定を長期間残すことも避けられます。

Chapter 02

DNS：名前解決の経路、設定範囲、失敗箇所の特定

接続における DNS の位置づけ

ドメインへアクセスするとき、デバイスはまずドメインをアドレスに解決し、その後の接続を確立します。サーバーの遅延が返ってきても、テストで使った対象と経路がある段階で到達可能だと分かるだけで、すべてのドメインが正しく解決できるとは限りません。そのため、「Ping は正常に見えるのにページが開かない」場合は、DNS を独立した確認項目として扱います。Shadowrocket の DNS 動作は、システムネットワーク、Settings、現在の Config、個別の Rule の影響を同時に受ける場合があります。すべてのドメインで失敗しているのか、特定の末尾だけ失敗しているのか、ネットワーク切り替え後だけキャッシュの差が出ているのかを、まず確認してください。

システム DNS は基準として使いやすい方法です。Direct でも普段使うサイトが開かない場合は、複雑なパラメータをすぐ変更せず、現在の Wi‑Fi またはモバイルネットワークを先に確認します。Direct と Proxy は正常で Config だけ一部のドメインが失敗するなら、Rule の適用状況と Config の DNS 宣言を確認します。1つのドメインだけ異常な場合は、親ドメイン、サブドメイン、アドレスを直接入力した場合の結果を比較し、対象サービス自体の障害を全体的な名前解決障害と取り違えないようにします。

名前解決方式を選ぶときの3つの境界

1つ目は、名前解決のリクエストがどこから送信されるかです。システムが提供する名前解決経路を使う場合、結果は通常現在のネットワークと一致します。Config で DNS を指定する場合は、そのアドレスが現在のネットワーク環境から到達可能か確認してください。2つ目は、返された結果がどのように Rule の判定へ渡されるかです。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD はドメインに基づいて直接マッチします。一方、GEOIP、IP-CIDR、IP-CIDR6 はアドレス情報を必要とします。3つ目は、キャッシュがいつ更新されるかです。DNS を変更しても古い結果が表示される場合は、現在の接続を切り、システムのネットワーク状態が更新されるまで待ってから再接続し、同じドメインで再テストします。

日常利用では、まず安定して動作するシステムの名前解決経路を使い、たまたま起きた現象だけを理由に複数の DNS アドレスを同時に追加しないことをおすすめします。Config で指定する必要がある場合は、数を絞って順序を記録し、優先アドレスに到達できないため毎回タイムアウトを待つ状態を避けてください。暗号化された名前解決方式を使う場合も、そのサービスのドメインが初回にどう解決されるかを考慮します。初期経路が遮断されていると、「高度な設定なのにまったく解決できない」状態になることがあります。トラブルシューティングでは、まず単純な経路に戻し、条件を段階的に追加してください。

Config 内での DNS と Rule の連携

設定ファイルには DNS と Rule を明示できますが、内容をよく理解していないサンプル全体を動作中の Config にそのままコピーしないでください。まず設定を複製してテスト用コピーを作り、必要な項目だけを追加します。Rule は上から順にマッチします。より具体的なドメイン Rule は通常、前方に置くべきです。FINAL は、それまでにマッチしなかった接続を受け持ちます。DOMAIN-SUFFIX が特定のドメインを PROXY に渡した場合、後続の GEOIP Rule が同じリクエストのポリシーを書き換えることはありません。DNS を診断するときは、名前解決の成否と最終的に適用された Rule の両方を確認してください。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上記の断片は構造とマッチ順序を説明するためのものです。example.com は文書用の例示ドメインであり、実際のサービスを示しません。dns-server = system は、システムの名前解決経路から基準状態を作ることを表します。実際の Config には、プロキシグループ、リモート Rule、その他の General 項目が含まれる場合もあります。統合時は元のセクション構造を保ち、重複するセクション見出しやスペルミスを避けてください。保存後はまず Config を正常に読み込めることを確認し、名前解決に失敗している状態で DNS アドレスを追加し続けないようにします。

名前解決に失敗した場合の段階的な確認

1段階目は Direct に切り替え、関係のない2つのドメインをテストします。両方失敗するならローカルネットワークを確認し、両方成功するなら2段階目へ進みます。2段階目は同じサーバーを維持したまま Proxy に切り替えます。失敗した場合はサーバー接続とプロトコルパラメータを確認し、Rule はまだ変更しません。3段階目は Config に切り替え、問題が Rule 方式だけで起きるかを確認します。4段階目は Log を開き、対象ドメインのマッチ結果を探して、DOMAIN-SUFFIX、GEOIP、FINAL のどれが処理したか確認します。5段階目になって初めて DNS を変更し、変更のたびに再接続します。

「成功したり失敗したりする」場合は、発生時刻、ネットワークの種類、直前に Wi‑Fi を切り替えたかを記録してください。断続的な失敗は、優先 DNS アドレスのタイムアウト、ネットワーク切り替え後に接続が再構築されていないこと、複数アドレスの返却順の変化などと関係する場合があります。Ping を連続して実行するだけで結論を出さず、実際のドメインリクエスト、Log、Connectivity Test の結果を組み合わせて判断します。より詳しい層別の事例はDNS 設定と名前解決のトラブルシューティングで確認できます。

Chapter 03

On Demand：自動接続の条件とネットワーク切り替え

On Demand で解決できること

On Demand はネットワーク状態に応じて接続をトリガーする機能です。Home の手動スイッチの代わりになるものではなく、現在どのサーバーが適しているかを自動判断するものでもありません。有効にする前に、まず手動接続が安定していることを確認してください。固定ネットワークで明確なサーバーと Config を選び、手動で接続してアクセスを検証します。手動接続自体が失敗している場合、On Demand を追加すると失敗が頻繁に発生するだけで、クライアントがいつ再接続したのか分かりにくくなる可能性があります。

自動接続の主な用途は、Wi‑Fi とモバイルネットワークの切り替え後も想定した状態を維持すること、または既知のネットワークに異なる動作を割り当てることです。条件は少数で明確、かつ互いに衝突しないものから設計してください。各条件について、「どの種類のネットワークにマッチするか」「マッチした後に何をするか」「マッチしない場合のデフォルト動作は何か」の3点に答えられるようにします。同じネットワークを複数の重複条件で表現しないでください。実際の結果がマッチ順に依存し、後のトラブルシューティングが難しくなります。

まずネットワークを分類し、その後に動作を決める

日常の環境は、信頼できる固定 Wi‑Fi、その他の Wi‑Fi、モバイルネットワークの3種類に分けられます。ここでいう「信頼できる」とは、ユーザーが慣れたネットワークで、個別の動作を割り当ててもよいと判断しているという意味に限られ、ネットワークの安全性を絶対的に保証するものではありません。固定 Wi‑Fi は通常ネットワーク名で識別し、その他の Wi‑Fi はフォールバックとして扱い、モバイルネットワークは個別に設定します。同じ名前で実体の異なるネットワークへ頻繁に接続する場合は、名前だけで複雑な判断をせず、手動確認の手順を残してください。

動作は実際の目的に合わせて選びます。特定のネットワークに入ったら Shadowrocket の接続を自動的に確立したい場合は、その条件に接続動作を指定します。手動で管理したい場合は、そのネットワークに強制的なトリガーを設定しません。設定後は、スイッチが有効になっているかだけでなく、環境ごとにテストしてください。まず1つ目のネットワークにとどまって Home の状態を記録し、2つ目のネットワークへ切り替えてシステムの変更完了を待ち、接続が再確立するかを確認します。最後に1つ目へ戻り、同じ動作を再現できるか確認します。

条件の順序と衝突の判断

範囲が具体的な条件は、範囲の広い条件より前に置きます。たとえば、特定の固定 Wi‑Fi を対象にする Rule は、「任意の Wi‑Fi」のようなフォールバック条件より前に置くべきです。広い条件が先にマッチすると、後ろの具体的な条件が適用されない場合があります。順序を変更したら、ネットワーク切り替えテストをもう一度行い、Home が想定した状態を表示しているか確認してください。接続が繰り返されたり、短時間に接続スイッチが何度も変化したりする場合は、条件同士の上書き、2つのアクセスポイント間でのネットワーク切り替え、または新しいネットワークで現在の Config が接続できない可能性を優先して確認します。

On Demand はシステムのネットワーク状態と密接に関係します。デバイスのロック解除直後、電波が弱い場合、Wi‑Fi がアドレスを取得中の場合は、接続の確立が画面の変化より遅れることがあります。このとき手動でスイッチを何度も切り替えないでください。手動操作と自動トリガーが重なる可能性があります。ネットワーク状態が安定するまで待ち、その後 Log に新しい接続処理が現れているか確認します。自動トリガー後に誤ったサーバーや Config が使われた場合は、切り替え前に Home で実際に選ばれていた項目を確認し、問題を On Demand の条件だけに帰属させないでください。

推奨する有効化手順

1段階目は On Demand を無効にし、普段使う Wi‑Fi で手動接続して DNS、Rule、アクセスがすべて正常か確認します。2段階目はサーバーと Config を変えず、モバイルネットワークで手動検証を繰り返します。3段階目は最もよく使う条件を1つだけ作り、On Demand を有効にして往復の切り替えを1回行います。4段階目は Log を確認し、ネットワークの変化ごとに明確な再接続が1回だけ発生していることを確認します。5段階目で2種類目のネットワーク条件を追加します。どこかで異常が出たら、追加した条件を元に戻し、拡張を続けないでください。

ネットワークの問題を一時的に切り分ける場合は、On Demand を無効にして自動再接続が比較テストを妨げないようにします。無効にした後も Home の現在の接続状態を確認してください。自動トリガーを止めても、すでに確立した接続が直ちに変わるとは限りません。トラブルシューティングが終わったら、まず動作する手動状態へ戻し、その後 On Demand を再び有効にします。これにより、「接続自体が使えるか」と「自動条件が正しいか」を別々の問題として扱えます。

Chapter 04

Ping と Connectivity Test：テスト結果の読み方

遅延の数値は接続品質全体を示さない

Ping は、指定したテスト方法で対象が応答するか、往復時間がおおよそどの範囲にあるかを素早く確認するためのものです。完全に到達不能、明らかなタイムアウト、同じネットワーク内で結果に大きな差がある項目を見つけるのに役立ちますが、Web、動画、その他のアプリ通信が必ず正常になることを単独で証明するものではありません。実際の接続には DNS、対象ポート、プロトコルハンドシェイク、転送パラメータ、Rule の適用、対象サービスの応答も関係します。1回の遅延値だけでサーバーを順位付けすると、一時的な揺らぎを安定した差と誤認しやすくなります。

Ping を実行する前に、同じネットワーク、同じ Global Routing の方式、同じテスト方法を固定し、スキャン中に Wi‑Fi を切り替えないようにします。結果は少なくとも2〜3回確認し、単発の最小値ではなく、継続的なタイムアウトや揺らぎの大きさに注目してください。すべての項目が同時に悪化する場合はローカルネットワークを優先して確認し、1つの項目だけが継続して異常なら、そのサーバー情報やネットワーク経路を確認します。テストデータは切り分けに使うものであり、長期的な性能の結論を作るためのものではありません。

Connectivity Test の層別確認

Connectivity Test は、「接続処理がどの層で停止したか」を確認するのに適しています。テスト項目は画面やネットワーク環境によって異なる場合がありますが、確認の順序は変えません。まずローカルネットワークに基本的な接続性があることを確認し、次にサーバーアドレスへ到達できることを確認し、その後プロトコルハンドシェイクと実際のリクエストが完了するかを確認します。ある段階を通過しても、その後の段階が成功するとは限りません。たとえばサーバーアドレスへ到達できても認証パラメータが正しいとは限らず、プロトコルハンドシェイクが成功しても DNS と Rule が対象リクエストを想定したポリシーへ渡すとは限りません。

テストに失敗したときは、最終的な赤い結果だけでなく、最初に失敗した段階を記録します。最初の失敗箇所が原因に近い情報です。名前解決の段階で停止したなら DNS の章へ進み、サーバー接続でタイムアウトするならネットワーク到達性とサーバー情報を確認し、前段階を通過した後に実際のリクエストが失敗するなら Rule、FINAL、対象サービス、プロトコルの転送パラメータを確認します。変更後は同じテストを繰り返し、失敗箇所が後ろへ移ったか、消えたかを確認します。

テストの誤差を減らす方法

テスト中は大量のネットワークリクエストを継続的に発生させる前面タスクを停止すると、Log を読みやすくできます。ただし、すべてのシステム設定を変更する必要はありません。デバイスの位置とネットワーク接続先を固定し、まず動作確認済みの項目を比較対象としてテストしてから、目的の項目を確認します。モバイルネットワークでは電波状態が遅延に直接影響します。Wi‑Fi ではアクセスポイントの切り替えや LAN の混雑も揺らぎの原因になります。1回タイムアウトしただけでプロトコルパラメータを変更せず、まず再テストしてください。

サーバーを比較するときは、テスト方法が同じであることを確認します。TCP 接続だけを確認する方法もあれば、実際のリクエストを含む方法もあります。方法が違う数値は直接比較できません。Shadowrocket の現在の画面で提供される Ping 方法は、Settings に表示される項目を基準にしてください。選択肢の意味が分からない場合は、デフォルトまたは現在動作している方法を維持し、数値が小さいという理由だけで頻繁に切り替えないでください。「速度が遅い」問題は、ローカルネットワーク、サーバー、時間帯による経路、プロトコル、対象サービスを分けて確認します。詳しくは速度低下の層別トラブルシューティングをご覧ください。

テスト結果から設定項目へ戻る

Ping がすべてタイムアウトするのに Direct のアクセスが正常なら、テストが現在の Proxy を経由しているか、サーバーアドレスへ到達できるか、プロトコルパラメータが揃っているかを確認します。Ping は正常なのに Connectivity Test が名前解決の段階で失敗するなら、DNS 経路を確認します。両方正常なのに Config でアクセス結果が想定と違う場合は、Log で DOMAIN、GEOIP、IP-CIDR、FINAL のマッチ結果を確認します。Proxy では正常で Config では失敗する場合、問題はサーバーより Rule または設定に近い可能性があります。

診断が終わったら、一時的なテスト設定を長期利用に必要な状態へ戻します。比較のため Direct に切り替えた場合は、終了後に Config へ戻すことを明確に確認してください。詳細な経過を見るため Log の記録範囲を広げた場合は、終了後に日常利用に必要な範囲へ戻します。特定のサーバーをテストするため選択項目を変えた場合も、最終的に Home で想定した項目が使われているか確認します。診断の終了条件は、問題が一時的に消えることだけではなく、設定が理解しやすく再現可能な状態へ戻ることです。

Chapter 05

Log と Data：Rule の適用と通信記録を確認する

Log で確認すべきこと

Log の主な用途は、目立つエラー文字を探すことではなく、特定のリクエストがどのような判定を通ったかを復元することです。1件の記録を読むときは、時刻、対象ドメインまたはアドレス、マッチした Rule、最終ポリシー、エラーが発生した段階の順に確認します。Rule の問題では、リクエストが想定した DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6、FINAL のどれにマッチしたかが重要です。より前方の Rule にマッチしているなら、サーバーを何度も切り替えるのではなく、Config の順序を見直します。

記録を始める前に、関係のない操作を減らします。テスト対象を1つに絞り、開くまたは更新する操作を1回だけ行い、すぐに Log に戻って該当時刻を探してください。バックグラウンドアプリは大量のシステムリクエストを発生させるため、見慣れないドメインを見ただけで異常と判断しないでください。時刻、対象、同じ操作の繰り返しから対応関係を作ります。たとえば同じ例示ドメインへ2回アクセスし、近い時刻に似た記録が2件出れば、どの記録が今回のテストに対応するか確認しやすくなります。

エラー情報を層別に読む

名前解決に関するエラーは、DNS アドレスへ到達できない、ドメインが結果を返さない、ネットワーク切り替え後に名前解決経路がまだ復旧していない、といった状態を示すことが多くあります。接続タイムアウトは、サーバーアドレス、対象ポート、ネットワーク経路に近い問題です。ハンドシェイクまたは認証の失敗では、ユーザーが持つサーバー情報のプロトコル、パスワード、UUID、転送パラメータ、証明書関連設定が一致しているか確認します。想定と異なる Rule にマッチした場合は、Config の順序とキーワードを確認します。層が異なるエラーに同じ対処をしないでください。

エラーが1回だけ発生し、その後のリクエストが成功した場合は、ネットワーク切り替えや一時的なタイムアウトとの関係をまず観察します。同じ段階で毎回失敗するなら、その段階に絞って単一変数で確認します。大量のログを一度に出力して「error」だけを検索しないでください。直前の接続操作や、その後のフォールバックポリシーも重要です。孤立したエラー語より、時系列の記録のほうが有用です。

Data で確認できること

Data は、クライアントが記録した通信の概要と接続の利用状況を確認するためのものです。アプリやドメインが継続的にリクエストを発生させているかを把握でき、Rule の変更前後を比較する補助情報にもなります。ただし、課金、ネットワーク品質、サーバー状態を単独で判断するものではありません。システムの集計基準、接続の再利用、キャッシュにより、Data と画面で見えるページ容量が異なる場合があります。正確な請求情報ではなく、傾向を示す情報として扱ってください。

Data を確認するときは、時間範囲とテスト操作を限定します。たとえば DOMAIN-SUFFIX Rule を変更する前に、現在のポリシーで対象がどう動作するかを記録します。変更後に再接続し、同じリクエストだけを実行して、想定したポリシーで処理されたか比較してください。バックグラウンドアプリが通信を続けている場合、総量だけで単一の対象を判断しないでください。異常な増加は Log に戻り、具体的なドメインとポリシーを確認します。Data だけを根拠に Config やサーバー項目を削除しないでください。

診断情報を共有する前の整理

サーバー情報の提供元へ問題を報告する場合は、発生時刻、ネットワークの種類、プロトコル名、Connectivity Test で最初に失敗した手順、整理済みの Log 断片を伝えると役立ちます。サーバーアドレス、パスワード、UUID、Subscribe アドレスに含まれる認証情報、その他の機密パラメータは、公開スクリーンショットや公開テキストに載せないでください。ドメインの末尾、エラーが発生した段階、Rule のキーワードは、問題の層を説明するために残して構いません。

ログを整理するときは、エラーの意味を書き換えないでください。内容を隠す必要がある場合は、機密部分を同じ形式で置き換え、フィールド構造と前後の文脈を残します。たとえば「対象が DOMAIN-SUFFIX にマッチして PROXY を使用し、その後接続がタイムアウトした」という順序を残すほうが、最終的に失敗したページだけを共有するより判断しやすくなります。問題が解決したら、一時的に出力した診断ファイルを削除し、Log の記録範囲を日常利用に必要な状態へ戻してください。

Chapter 06

Widget と iCloud 同期：ショートカット操作と設定の移行

Widget はショートカット入口であり、独立した接続ではない

Widget は、システム画面からよく使う状態を確認したり操作したりするためのショートカットを提供します。ただし、Shadowrocket に登録済みのサーバー、Config、接続権限に依存します。Widget の表示に問題がある場合は、まず Shadowrocket を開き、Home が正常に読み込まれ手動接続できることを確認してから、システムが Widget の更新を許可しているか確認します。クライアントで初回接続の許可が完了していない場合、Widget だけを操作してもその手順を回避できません。

Widget には、使用頻度が高く意味の明確な動作だけを配置します。名前の似たサーバーや Config を複数置くと、ショートカット操作で選択を誤りやすくなります。項目名には用途が分かる情報を入れるとよいですが、パスワード、認証情報を含むアドレス、その他の機密情報は書かないでください。Shadowrocket 内の項目を変更した後も Widget が古い状態を表示する場合は、まずクライアントで保存が成功していることを確認し、その後システムに Widget を更新させます。現在動作している設定を何度も削除しないでください。

Widget の状態と実際の状態が一致しない

システムはバッテリーとリソースを管理するため、Widget の更新を遅延させる場合があります。そのため、表示と Home のリアルタイム状態に一時的な差が生じることがあります。接続が確立したかどうかは、Shadowrocket を開いた後の Home の状態と実際のリクエスト検証を基準にします。Widget をタップしても想定した動作をしない場合は、デバイスを再起動した直後ではないか、クライアントが権限の再確認を求められていないか、現在のネットワークが利用可能か、On Demand が別の接続動作を同時にトリガーしていないかを確認します。

確認順序は次のとおりです。まず Home から手動接続を1回完了させます。次に Widget へ戻って同じ操作を実行します。Home は成功して Widget だけ失敗する場合は、システム上の Widget を削除して再追加します。両方失敗するなら問題は Widget ではないため、サーバー情報、DNS、ネットワークテストへ進みます。Widget の障害時に Proxy ポートや Rule を変更しないでください。通常、これらはシステムのショートカット入口の更新とは直接関係しません。

iCloud 同期の適用範囲

iCloud 同期は、条件を満たす Apple デバイス間でアプリデータを保存または同期するためのものです。同期される内容や表示方法は、現在の Shadowrocket の画面を基準にしてください。すべてのデータがリアルタイムかつ双方向に、衝突なく複製されることを意味するものではなく、手動バックアップの代わりにもなりません。有効にする前に各デバイスで使っている iCloud の状態を確認し、どのデバイスの設定を基準にするか決めてください。複数のデバイスで同名の Config を同時に編集すると、古い内容が新しい内容を上書きしたり、判別しにくいコピーが作られたりする場合があります。

「メインデバイスで変更し、他のデバイスで確認する」順序をおすすめします。まずメインデバイスで Config を変更して動作を確認し、設定名と重要な Rule を記録します。同期を待ってから別のデバイスで Shadowrocket を開き、サーバー項目、Config の内容、Global Routing が想定どおりか確認します。更新されていない場合、すぐに2台目で同名項目を再編集しないでください。新たな衝突につながる可能性があります。まず iCloud の状態、ネットワーク、クライアントの読み込み完了を確認します。

インポート、同期、Subscribe 更新の違い

Import from Cloud JSON は1回のインポート操作、iCloud 同期はデバイス間でデータを同期する仕組み、Subscribe 更新はユーザーが持つ Subscribe アドレスに基づいて該当項目を更新する機能です。3つを混同しないでください。JSON をインポートして得られるのは、インポート時点のデータコピーです。その後変化するかどうかは、ユーザーがどのように管理するかに左右されます。Subscribe 更新では通常、提供元に基づいて関連項目が再生成されます。手動で変更したフィールドが保持されるかは、実際の結果を確認してください。iCloud はローカルの変更を他のデバイスへ反映する場合があります。

いずれかの一括変更を行う前に、動作する Config を残し、現在選択しているサーバーを記録します。更新後は古い項目をすぐに削除せず、新しい項目のプロトコル、アドレス、ポート、名前が揃っているか確認します。その後 Ping または Connectivity Test を実行し、最後に Config で Rule を検証します。重複項目が見つかった場合は、まず入手元を特定してから残すものを決めてください。名前が同じという理由だけで一括削除すると、Config が参照している項目まで削除する可能性があります。

デバイス間利用の確認リスト

iPhone と iPad の間で移行した後は、少なくとも5項目を確認します。Home の現在のサーバー、Global Routing の方式、Config が存在して開けるか、On Demand がそのデバイスのネットワーク環境に適しているか、Widget が有効な項目を指しているかです。デバイスの用途が違えば、On Demand の条件を完全に同じにする必要はありません。たとえば頻繁に移動する iPhone と、固定 Wi‑Fi に長時間接続する iPad では、基礎となる Config を共有しつつ、自動接続条件は個別に管理できます。

Mac、Apple TV、Apple Vision の互換性情報は同じ App Store 製品ページで確認できます。システム要件は App Store ページの記載を基準にしてください。データを同期できた場合でも、各デバイスでネットワーク権限、利用可能な画面項目、実際の接続結果を個別に確認します。同期完了はデータが届いた可能性を示すだけで、接続環境まで完全に一致したことを意味しません。

Chapter 07

Proxy ポート：ローカル待受、LAN アクセス、競合の確認

Proxy ポートとは

Settings の Proxy ポートは、指定した HTTP または SOCKS5 の入口を通じて、本体のアプリから Shadowrocket へ接続を渡すために使います。ポートはデバイス上のローカル待受番号であり、リモートサーバーのポートでも、プロトコル設定にあるサーバーポートでもありません。数字が偶然同じでも意味は異なります。Proxy ポートを変更しても、サーバーのパスワード、UUID、転送パラメータの誤りは直らず、Config の Rule のマッチ順も変わりません。

普段システムの接続スイッチだけを使う場合、ローカル Proxy ポートを頻繁に変更する必要は通常ありません。アプリが HTTP または SOCKS5 Proxy の手入力に対応している場合や、ローカルでデバッグする場合に限り、これらの値を確認します。入力時は Shadowrocket の現在の Settings に表示されるアドレスとポートを基準にし、別のデバイスの数字をそのまま使わないでください。ポートは有効な範囲に収め、デバイス上で別のサービスが使用中のポートと競合しないようにします。

ローカルアドレスと LAN アドレスの違い

本体のアプリがローカル Proxy に接続するときは、通常ループバックアドレスまたは Settings に表示される本体の入口を使います。ループバックアドレスは現在のデバイスだけを指すため、別のデバイスが自分のループバックアドレスをこの iPhone や iPad のものとして使うことはできません。LAN 内の別の管理対象デバイスからアクセスする場合は、Shadowrocket が対応する LAN 待受を有効にしているか、システムが LAN アクセスを許可しているかを確認し、サービスを提供するデバイスの現在の LAN アドレスを使います。

LAN アクセスを有効にすると待受範囲が広がるため、明確な必要性があり、ネットワーク環境とアクセス元を把握できる場合だけ有効にしてください。デバッグが終わったら元の状態へ戻します。公共 Wi‑Fi や同じネットワーク上のデバイスを確認できない環境は、長期的な共有入口には適しません。待受を有効にしても、別のデバイスがサービス提供デバイスへ到達できる必要があります。ネットワーク分離、ゲストネットワーク、ルーターのポリシーによって接続が遮断される場合があります。

ポート競合の症状と対処

ポート競合は、待受を開始できない、アプリの接続がすぐ拒否される、正しいアドレスを入力してもアクセスできない、といった症状で現れます。まず Shadowrocket の元のポートへ戻して再接続します。元の値は使えるのに新しい値が使えない場合は、新しいポートが使用中か、入力内容が一致していない可能性があります。変更後は、そのローカル Proxy を使うすべてのアプリも更新する必要があります。古い設定は自動的に追従しません。HTTP と SOCKS5 の2つのポートを同時に変更しないでください。どちらが競合したのか分からなくなります。

プロトコル種別の確認も重要です。アプリが HTTP Proxy を要求する場合は HTTP の入口を入力し、SOCKS5 を要求する場合は SOCKS5 の入口を入力します。種別とポートを取り違えると、接続に失敗したりリクエストの動作が異常になったりします。アプリが認証フィールドに対応していても、Shadowrocket の現在のローカル入口が同じ方式を要求するとは限りません。クライアントの実際の設定に従い、リモートサーバーの認証情報を独自に追加しないでください。

LAN デバッグの最小手順

まずサービスを提供するデバイスで、Shadowrocket の手動接続が正常であることを確認します。次に必要な LAN アクセス設定だけを有効にし、現在のネットワークアドレスと対応する Proxy ポートを記録します。同じ管理下のネットワークにある別のデバイスで、そのアドレス、ポート、正しい HTTP または SOCKS5 の種別を入力し、テスト対象へ1回だけアクセスします。失敗した場合は、2台のデバイスが本当に同じネットワークにあるか、システムの LAN 権限、ルーターによるデバイス分離、ポート入力の一致を順番に確認します。

別のデバイスがポートには接続できても対象リクエストに失敗する場合は、Shadowrocket の Log に戻り、リクエストが到達したか、どの Rule にマッチしたか、どのポリシーを使ったかを確認します。Log に該当時刻のリクエストがまったくない場合は、LAN 経路または入力ミスに近い問題です。リクエストが表示され、その後タイムアウトする場合は、DNS、サーバー、Rule の順に確認します。テスト終了後は、不要になった LAN 待受を無効にし、別のデバイスに入力した一時的な Proxy 設定を削除してください。

Proxy ポートを変更すべきでない場合

Subscribe を更新できない、サーバーの Ping がタイムアウトする、特定の DOMAIN-SUFFIX が誤ってマッチする、On Demand が起動しない、DNS の名前解決に失敗する、といった問題では、ローカル Proxy ポートは通常最初に確認する項目ではありません。ポート設定が影響するのは、その入口を使うアプリだけであり、すべてのネットワーク問題を一括で直すものではありません。まず障害の場面が本当にローカル HTTP または SOCKS5 入口を使っているか確認し、その後で調整を判断します。

iPhone や iPad で Shadowrocket を通常利用したいだけなら、まず Home の接続、Global Routing、Config、実際のアクセスを確認してください。Proxy ポートは手動プロキシが明確に必要な場合の拡張設定です。動作している現在の値を維持するほうが、ランダムな数字を試すより安全です。変更が必要な場合は元の値を記録し、検証後に長期的に残すか判断します。

Chapter 08

Config の管理：Rule の順序、バックアップ、完全なトラブルシューティング手順

Config の役割と範囲

Config は General 設定、Rule、プロキシグループ、その他の接続動作を整理するためのものです。リクエストを分類し、PROXY、DIRECT、REJECT のどれへ渡すかを決めますが、誤ったサーバー情報を自動修正するものではありません。Config を管理するときは、「サーバーへ接続できるか」と「Rule が想定したポリシーを選ぶか」を分けて検証します。まず Proxy 方式で現在のサーバーが使えることを確認し、その後 Config 方式へ戻って Rule を確認します。Proxy ですでに失敗している場合、DOMAIN-SUFFIX や GEOIP を調整しても診断上の意味はありません。

Rule は上から下の順にマッチします。DOMAIN は完全なドメイン、DOMAIN-SUFFIX は指定した末尾とそのサブドメイン、DOMAIN-KEYWORD はドメイン内のキーワード、USER-AGENT はリクエストの特徴、GEOIP はアドレスの所属、IP-CIDR と IP-CIDR6 はアドレス範囲に基づいてマッチします。範囲の広い Rule はリクエストを先に取り込む可能性が高いため、通常は明確で具体的な Rule を広い Rule より前に置き、FINAL は末尾でフォールバックを担わせます。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この例はキーワードと順序を示すものであり、ユーザーが現在使っている Config をそのまま上書きするものではありません。アドレスは文書用の例なので、実際の管理では自分の対象とサービス情報に合わせて記述してください。DOMAIN-SUFFIX,example.com,PROXY は、より広い DOMAIN-KEYWORD,example,DIRECT より前にあるため、該当する末尾は先に PROXY が適用されます。順序を入れ替えると、キーワード Rule が先にマッチして結果が変わる可能性があります。Log で「どの Rule にマッチしたか」を記録しなければならない理由もここにあります。

Config、Subscribe、手動項目の関係

ユーザーが持つ Subscribe は該当するサーバー項目を提供し、Config は Rule とポリシーを記述します。両者は関連付けられますが、同じ内容ではありません。Subscribe を更新すると、項目名、順序、利用可否が変わる場合があります。Config が特定の名前を参照している場合は、その参照先がまだ存在するか確認してください。手動で追加した Add Server 項目は、ユーザーが入力したプロトコルパラメータに依存します。入手元にかかわらず、更新後はまずプロトコル、アドレス、ポート、必要なフィールドを確認してからテストします。

唯一動作している Config を直接大幅に書き換えることはおすすめしません。まずテスト用コピーを作り、その中で関連する Rule を1組ずつ変更し、元のファイルを復元用に残してください。ユーザーが信頼し、自分で選んだ提供元の設定であれば、更新時刻とローカルで変更した位置を記録し、次回更新で手動変更が上書きされても判別できるようにします。このサイトは Shadowrocket のインポートと管理方法のみを説明し、サーバー情報や Subscribe の内容は提供しません。

最小構成から段階的に戻す

複雑な Config で原因を特定しにくい問題が起きた場合は、テスト用の設定をコピーし、必要な General、少数の明確な Rule、FINAL だけを残します。まず1つの DOMAIN Rule を検証し、次に DOMAIN-SUFFIX、続いて GEOIP やアドレス範囲の Rule を追加します。追加するたびに再接続して Log を確認します。こうすれば、数百件の Rule の位置を無作為に動かすのではなく、どの Rule グループ、リモートリソース、General 設定が問題を引き起こしたか特定できます。

最小構成が正常で元の Config が失敗する場合は、両者の DNS、Rule の順序、プロキシグループの参照、重複セクションを比較します。最小構成も失敗する場合は、Proxy 方式に戻ってサーバーを確認し、その後 Direct でローカルネットワークを確認します。完全な手順は常に、環境から接続へ、接続から設定へ、設定から単一の対象へ進めます。最終ページだけを見て逆向きに判断しないでください。

完全なトラブルシューティングの順序

1. ローカルネットワークを確認：Direct で関係のない複数の対象へアクセスし、Wi‑Fi またはモバイルネットワークに基本的な接続性があるか判断します。
2. サーバーを確認：Proxy に切り替え、1台のサーバーを固定して、Ping、Connectivity Test、実際のリクエストで相互に検証します。
3. Config を確認：Config に戻り、対象リクエストがマッチした Rule と最終ポリシーを確認します。
4. DNS を確認：ドメインを解決できない場合は、システム経路で基準状態を作り、Config 内の上書き設定を確認します。
5. 自動トリガーを確認：手動接続が安定してから On Demand を有効にし、ネットワーク切り替えテストを行います。
6. 拡張機能を確認：最後に Widget、iCloud 同期、Proxy ポートを確認し、補助機能が本線の診断を妨げないようにします。

上記の手順を終えても判断できない場合は、FAQの「Rule とトラブルシューティング」から具体的な症状を探してください。問題を報告するときは、最小限の再現条件、失敗した段階、整理済みの Log を提示し、サーバーの認証情報は公開しないでください。初めて使う場合は、クイックスタートガイドに戻り、Add Server、Subscribe、Global Routing、接続確認の基本手順をもう一度確認することをおすすめします。このガイドは設定の詳細を説明するもので、初回操作の順序に代わるものではありません。

管理後の最終確認

大きな調整を終えるたびに、Home の現在のサーバー、Global Routing、Config、On Demand、DNS、Widget、ローカル Proxy ポートを確認し、一時的なテスト値が元に戻っていることを確認します。Config は検証済みのコピーを1つ残し、正式設定とテスト設定を分かりやすい名前で区別してください。Subscribe を更新したり Import from Cloud JSON でデータを取り込んだりした後は、参照関係をもう一度確認し、古い名前が必ず維持されるとは考えないでください。

Shadowrocket のアプリ更新は App Store から提供されます。iPhone、iPad、およびストアの互換性欄に記載されたその他の Apple デバイスについて、システム要件は App Store ページの記載を基準にしてください。購入情報、購入済みアイテムの復元、デバイスの説明を再確認する場合は、当サイトのApp Store ダウンロードガイドから製品ページへ進んでください。設定管理の目的は、各パラメータの用途を説明でき、再現でき、問題発生時に復元できる状態にすることです。説明できないスイッチや Rule を長期的に積み重ねることではありません。