Shadowrocket
Settings設定項目ガイド

1. Settingsの役割と初期状態

Settings、Config、サーバーの違い

Shadowrocketでは、Settingsでアプリの動作を管理し、Configに設定ファイルとルール振り分けを保存します。Homeではサーバーを選択し、Global Routingを確認して接続を操作します。これらは連携しますが、互いに置き換えられるものではありません。DNSを変更してもサーバーのパスワードは補われず、サーバーを切り替えても誤ったルールが自動で修正されるわけではありません。トラブル対処では、特定のドメインが開けないのか、ネットワーク切り替え後に切断されるのか、すべてのリクエストが失敗するのか、まず症状を明確にしてください。症状によって確認すべき設定箇所は異なります。

このガイドはiPhone / iPadの画面上の名称に沿って構成しています。Mac、Windows、Android、Linux版もShadowrocketですが、システム権限やバックグラウンド動作、表示される項目は異なる場合があります。項目が見当たらない場合は、ほかの端末のスクリーンショットと同じ場所を探すのではなく、プラットフォームと現在の画面をご確認ください。システムのネットワーク権限については端末の案内に従ってください。iPhone / iPadのシステム要件はApp Storeの製品ページをご確認ください。

初期値、現在値、推奨値はそれぞれ異なる

「初期値」は該当する設定を初めて作成したときの動作、「現在値」はConfigの読み込みやバックアップの復元、同期などの影響を受けた値、「推奨値」は利用目的によって異なる値です。このガイドでは、特定の端末の状態をすべてのバージョンに共通する初期値として扱いません。安定した共通の初期値がない項目は、現在の画面または有効なConfigで確認するよう案内しています。明示されていない項目も、空欄だから無効とは限りません。ガイドと照合するためだけに、すべてのデータをリセットする必要はありません。

元に戻せるよう変更内容を記録する

操作前に、使用中のConfig名、選択中のサーバー、Global Routingの状態を記録し、変更予定の項目を控えてください。バックアップが必要な場合は、ご自身で管理できる場所に保存します。Configには認証情報が含まれることがあるため、内容全体を公開の質問サイトなどに貼り付けないでください。関連する設定は一度に一組だけ変更することをおすすめします。たとえば、ルーティングはそのままにDNSだけ調整し、結果を確認してからOn Demandを設定します。複数項目を同時に変更すると、接続が復旧しても、どの変更が有効だったのか分からず、再発時の特定も難しくなります。

変更後は、新しい接続を確立してテストしてください。ブラウザーの既存の長時間接続、アプリのキャッシュ、システムのDNSキャッシュにより、以前の状態が一時的に残ることがあります。同じページを再読み込みするだけでは、新しい値が反映されたか確認できない場合があります。まず実行中のテストを停止し、切断してから再接続し、用途が明確なテスト先にアクセスしてください。改善しない場合は、次の確認に進む前に元の値へ戻します。すべてのスイッチを何度も切り替えることをトラブル対処に使ったり、出所が分からないConfig全体を読み込んで既存の設定を上書きしたりしないでください。

アプリの買い切り購入と通信サービスの契約は別です。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。このサイトではノードやサブスクリプションを提供、販売、推奨していません。アプリの設定だけでは、既存サービスの有効な認証情報や利用可能な接続を代替できません。

アプリを入手する場合はダウンロードガイドをご覧ください。iPhone / iPad版はApp Storeから入手できます。Mac版にはAppleシリコン版とIntel版があり、ほかのプラットフォームのインストーラーはすべて当サイトの/dl/shadowrocket/から提供しています。初回起動時にシステムでブロックされた場合は、先にインストールの許可方法をご確認のうえ、このページに戻って設定してください。インストールの問題とDNSやルールの問題は分けて対処します。

2. DNSの名前解決とトラブル対処

DNSはドメイン名をIPアドレスに変換する仕組み

ドメインにアクセスすると、通常はまず対応するIPアドレスを取得し、その後に接続を確立します。そのため、Connectivity Testに結果が出てもWebページが開けないからといって、接続先サーバーが正常または異常だとは断定できません。テストで確認できるのは経路の一部だけの場合があり、実際のページが別のドメインにもアクセスすることがあります。DNSは名前解決の結果を返すもので、誤ったパスワードや期限切れの認証情報、接続先サイトの問題を修正するものではありません。原因を判断するときは、名前解決、接続、アプリからの応答を分けて確認し、すべての失敗をDNSのせいにしないでください。

初期状態を確認するには、SettingsのDNS関連項目と有効なConfigの両方を確認してください。読み込んだConfigでDNSサーバーが明示されている場合もあれば、システムのDNS経路を利用する場合もあります。項目が空欄なら、説明やLogをもとに実際の動作を判断してください。特定のパブリックDNSを使っていると決めつけないでください。初めて使う場合は、正常に動作しているDNS設定を維持することをおすすめします。名前解決の失敗を示す明確な根拠がある場合に限り、経路を調整してください。「万能の最適値」を求めてすべての項目を変更する必要はありません。

まずDNSサーバーに問い合わせが届くか確認する

次の順で確認します。現在のネットワークで基本的なサービスにアクセスできるか、サーバーのアドレス自体を名前解決できるか、DNSサーバーに想定した経路で到達できるか、返されたアドレスへの接続が成功するか。サーバーのアドレスがドメイン名の場合、接続開始前に名前解決が必要になることがあります。DNSサーバーへの到達にも、まだ確立していないProxy接続が必要だと、依存関係が循環する可能性があります。その場合は、DNSサーバーを次々に変更するのではなく、Configの設計を確認してください。アドレスを複数登録しても、期待どおりにすべて並行して使われるとは限りません。

アドレスファミリーと暗号化DNSの注意点

同じドメインからIPv4とIPv6のアドレスが返されることがあります。IPv6レコードがあっても、現在のネットワークがIPv6で完全に通信できるとは限りません。逆に、IPv6を無効にしても、すべての問題が解決するわけではありません。まず失敗した接続で実際に使われたアドレスファミリーを確認し、もう一方の経路と比較してください。関連設定を一時的に変更する場合は、元の状態を記録してください。検証後はネットワーク環境に応じて変更を維持するか判断し、特定のネットワークの問題を解決するために、ほかのネットワークで正常な動作まで長期的に変えないようにします。

暗号化DNSは主に問い合わせの通信方式を変えるもので、Web通信のルーティング方針を自動で変えるわけではありません。また、返されたアドレスが現在の経路に適しているとも限りません。設定時はDNSサーバーのアドレス、プロトコル、到達可能性をそれぞれ確認し、現在の画面が対応している場合は、その項目で指定された形式で入力してください。通常のWebページのURLをDNSサービスのアドレスとして入力しないでください。証明書の検証エラーが出た場合は、システム時刻と入力内容を先に確認し、名前解決の問題を隠すために検証を無効にしないでください。

DNSの変更を検証する方法

繰り返しアクセスできるドメインを選び、変更前の症状を記録してから、DNS設定を一か所だけ調整してください。再接続後、Logで問い合わせの成否、返されたアドレス、後続のリクエストに適用されたポリシーを確認します。ブラウザーが独自の名前解決を使ったり、アプリがアドレスをキャッシュしたりすることがあるため、クライアントの記録も合わせて確認してください。一度ページを再読み込みした結果だけで判断しないでください。特定のアプリだけで問題が起きる場合は、独自の名前解決や既存の接続を使っていないか確認します。

名前解決に成功しても接続先にアクセスできるとは限りません。接続タイムアウトも、DNSの失敗を意味するとは限りません。設定を変える前に、問題が起きている段階を特定してください。

元に戻すときは、DNSサーバー、アドレスファミリー関連のスイッチ、有効なConfigを元の状態に戻してください。最後に入力した一行を削除するだけでは不十分です。復元後も問題が続く場合は、ネットワークを切り替えていないか、別のConfigを選び直していないか確認してください。詳しい手順はDNS名前解決の失敗を解決する方法をご覧ください。すべての接続先にアクセスできない場合は、接続できないときのよくある質問も確認し、DNSだけを何度も変更しないでください。

3. On Demandの接続条件

接続を開始する条件とルーティング方針は別々に設定する

On Demandは、どの条件でシステムがVPN接続を開始または再接続するかを設定する機能です。サーバーを選ぶ機能でも、ルーティングポリシーでもありません。On Demandで接続できても、リクエストが最終的にPROXYとDIRECTのどちらを通るかは、Global Routingと有効なConfigによって決まります。この違いを理解すると、「特定のサイトをProxy経由にしたいのでOn Demandを有効にする」「ネットワーク切り替え後に接続を復旧したいのでドメインルールを何度も調整する」といった誤解を避けられます。

初期状態は、現在の端末で実際に有効になっているスイッチと保存済みの条件を確認してください。接続ボタンがオンに見えるだけで、On Demandも有効だとは判断できません。データの復元後やシステムのVPN設定を変更した後も、状態を再確認してください。On Demandを設定する前に、まず手動接続が安定して動作する状態にします。手動接続でもエラーが続く場合、自動再試行を有効にすると同じ失敗が繰り返されてLogが増えるだけで、接続先のアドレスや認証情報、ネットワーク環境の問題は解決しません。

ネットワーク条件ごとにルールを設定する

Settings › On Demandを開き、現在の画面で選択できる条件を確認してから、必要な項目だけ設定してください。Wi-Fiネットワーク名で動作を分ける場合は、名前の大文字・小文字、空白、同名のネットワークに注意して、正確に確認します。ネットワーク名は照合条件の一つにすぎず、そのネットワークが信頼できることを証明するものではありません。同じ名前だから安全な環境も同じだと判断したり、ローカルProxyポートのアクセス範囲を広げたりしないでください。

まず、現在のWi-Fiとモバイルネットワークを明確に区別するなど、検証しやすい条件を一つ設定します。システムで実際の動作を確認してから、ほかの条件を追加してください。条件には順序や優先関係がある場合があるため、現在の画面の説明に従って配置します。条件に一致しない場合は、すべての条件をすぐに削除するのではなく、ネットワークインターフェイスと名前が一致しているか確認してください。テストでは、切り替え前後のネットワーク、発生時刻、接続状態を記録します。「ときどき切れる」という説明よりも原因を特定しやすくなります。

手動で切断した後に再接続される理由

手動でオフにしてもすぐに再接続される場合は、アプリの不具合と決めつける前に、On DemandとシステムのVPNオンデマンド設定を確認してください。次のネットワークリクエストやネットワークの変化をきっかけに、システムが再接続を開始することがあります。切断状態をテストするには、関連する接続条件を一時停止してからシステムの状態を確認します。接続スイッチを何度もタップしても、自動接続が停止した証明にはなりません。条件が保存されていれば、端末の再起動後に同じ現象が再発することもあります。

接続状態とアプリの通信が途切れないことは別です。Wi-Fiからモバイルネットワークに切り替わると、基盤となるアドレスや通信経路が変わるため、進行中のダウンロード、通話、長時間接続はアプリ側で再接続が必要になる場合があります。On Demandはすべてのアプリのセッション維持を保証するものではなく、バックグラウンド動作やネットワーク権限に関するシステムの制限を回避するものでもありません。検証では新しいリクエストを使い、既存セッションの切断と、新しい接続の失敗を分けて記録してください。

おすすめの順序：手動接続が正常に動作することを確認 → On Demandの条件を一つ追加 → ネットワークを切り替えて確認 → 必要に応じて条件を追加。条件を一つ追加するたびに、元に戻せるよう以前の状態を記録してください。

条件が正しく見えるのに接続が始まらない場合は、システムのVPN構成がShadowrocketに対応しているか、ほかの接続が使用中でないか、端末が管理ポリシーによる制限を受けていないかを確認してください。トラブル対処のために、システム構成をすべて削除しないでください。まず必要な情報を保存し、明らかに関連する項目だけを変更します。初回の権限設定とHome画面については初回起動時の設定をご覧ください。自動接続後の通信経路については、このページのConfig › Ruleも確認してください。

4. PingとConnectivity Testで確認できる範囲

どの区間を測定しているか確認する

Pingは関連するテスト設定を確認するための項目名です。選択できる方法は現在の画面で確認してください。テスト方法によって確認できる範囲は異なります。ネットワークの往復を主に測る方法、接続先ポートへの接続を試す方法、アプリケーション層のリクエストを含む方法などがあります。数値が表示されただけで、認証、名前解決、ルールの適用、すべてのサイトへのアクセスが成功したとは判断できません。テスト結果は選択した方法と合わせて記録してください。方法が異なる数値をそのまま比較しても、通常は診断に役立ちません。

初期のテスト方法、タイムアウト、接続先はSettings › Pingで確認してください。端末や復元したデータによって、独自の値が設定されている場合があります。このガイドでは、すべてのネットワークに適した固定のタイムアウト値を定めていません。最初は現在利用できる方法を維持し、実際のアクセスを確認することをおすすめします。複数のサーバーを比較する場合は、ネットワーク、テスト方法、接続先を固定して複数回測定し、Wi-Fiの電波状況の変動と接続先の違いを混同しないようにします。

テスト方法に応じて成功・失敗を判断する

画面にTCP系のテスト方法がある場合、成功は通常、該当ポートへの接続が確立できたことを示しますが、アプリケーション層の認証が成功したことまでは示しません。HTTP系のテスト方法では、接続先からの応答、リダイレクト、証明書、名前解決も関係する場合があります。ネットワーク機器が特定のテスト方法を制限したり、フィルタリングしたりすることがあるため、テストが失敗しても実際の通信が正常に動作する場合があります。結果が今回の問題に関係するか判断する前に、テスト方法の定義を確認してください。

テスト先とタイムアウトの選び方

テスト先を指定できる場合は、用途が明確で安定して応答する接続先を使い、一連の比較では同じ接続先を維持してください。ログインが必要なページ、頻繁にリダイレクトするページ、自動リクエストを厳しく制限するページを通信品質の基準にしないでください。接続先自体に問題があれば、すべてのサーバーで失敗することがあります。接続先を変更して回復しても、通信経路が修復されたとは限りません。記録するのはテスト先が変わったかどうかと、名前解決、ハンドシェイク、応答のどの段階で失敗したかです。

タイムアウトが短すぎると、一時的な通信の揺らぎを失敗と判定することがあります。長すぎると、到達できないテストの待ち時間が延びます。まずは現在の初期設定のまま確認し、ネットワークの状況から待ち時間を延ばす必要があると分かった場合にだけ調整することをおすすめします。継続的な失敗を隠すために、タイムアウトを極端に長くしないでください。同時に複数のテストを実行すると、ネットワークや端末のリソースを消費します。電波が弱い場合やバックグラウンド処理が多い場合は、測定自体が結果に影響することがあります。比較するときは不要な大容量通信を停止し、条件をそろえてください。

実際のアクセス結果と照らし合わせる

HomeでConnectivity Testを実行した後、具体的な通信先を一つ選んで確認します。ドメイン、Global Routingの状態、選択中のサーバーを記録し、新しいリクエストに対応するLogを確認してください。テストが成功してもページが開かない場合は、そのページに別のルールが適用されていないか、別のドメインにもアクセスしていないか、証明書や認証のエラーがないかを確認します。サーバー一覧の並び順だけを見て何度も切り替えないでください。並び順から、各アプリの実際の通信要件は分かりません。

1回の検証では、テスト方法、テスト先、実際のアクセス結果の3点を記録してください。遅延は帯域幅を示すものではなく、1回の成功も継続的な利用可能性を保証しません。

すべてのテストが同時に失敗する場合は、まず端末の基本的なネットワーク接続と権限を確認してください。特定のサーバーだけで失敗する場合は、アドレス、ポート、プロトコルのパラメータを確認します。プロトコルにはShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardがあり、それぞれ必要な項目が異なります。テストが失敗したからといって、プロトコルを安易に入れ替えないでください。パラメータは、ご自身が利用しているサーバー情報と一致させます。具体的な追加手順はAdd Serverの操作方法をご覧ください。テスト設定で不足している認証情報を補うことはできません。

5. Logの記録範囲と原因特定に必要な情報

再現できる操作から始める

Logは接続や処理の経過を確認するためのもので、すべてのエラーの原因を自動で判断する画面ではありません。同じ「タイムアウト」でも、DNSサーバー、サーバーのポート、最終的な接続先など、発生箇所は異なります。前後の状況と合わせて判断してください。まず、接続後に指定したドメインを一つ開くなど、問題を一回の操作に絞り、その前後の記録を確認します。複数のアプリを同時に開いたり、サブスクリプションを更新しながら複数のテストを実行したりすると、さまざまなイベントが混在して因果関係を特定しにくくなります。

ログを有効にするかどうか、記録の詳細度、保存できる範囲は、現在のSettings › Logに表示される項目で確認してください。すべてのプラットフォームで同じ詳細度が選べるとは限りません。初期状態は以前の設定に影響される場合があります。通常は、基本的な原因特定に必要なレベルを維持し、問題を再現するときだけ一時的に詳細度を上げることをおすすめします。詳細な記録を続けると、保存容量や処理負荷が増えるだけでなく、ドメイン、アドレス、接続情報も蓄積されます。調査が終わったら、元のレベルに戻してください。

エラーの文字列だけでなく、接続の段階を確認する

まず、リクエストに含まれるドメインまたはIPアドレスを探し、次に適用されたルール、その後に接続の確立と応答を確認します。リクエストが記録にまったく見当たらない場合、アプリが既存の接続を使っている、リクエストが現在の経路を通っていない、対象のイベントが記録範囲に含まれないなどの可能性があります。だからといって、ネットワークにリクエストがなかったとは断定できません。REJECTが明確に記録されている場合は、まずルールを確認してください。接続先が常にサーバー自体であれば、Webサイトのドメインルールを変更する前に、プロトコルと認証情報を確認します。

最小限の再現手順を記録する

開始前に端末の時刻と現在のネットワークを記録し、役立つ可能性のある既存のLogを残してから、画面にある方法で記録を消去するか、確認開始位置を決めます。その後は操作を一度だけ行い、結果を記録して、ほかのテストを止めてください。整理するときはエラーの単語だけを切り取らず、問題の前後が分かる連続した記録を残します。直前の行に接続先のアドレス、次の行に再試行の結果が記録されていることがあります。前後の情報がないと、同じメッセージが接続のどの段階で発生したのか判断しにくくなります。

Wi-Fiの切り替え後にだけ問題が起きる場合は、切り替え前後のLogを分け、新しい接続で経路が変わったか確認します。特定のConfigでだけ問題が起きる場合は、サーバーを変えずに有効なファイルと適用されたルールを比較してください。原因を設定まで絞り込むため、比較ごとに変更する項目は一つだけにします。同じエラーが繰り返されても、すぐにすべてのデバッグ項目を有効にする必要はありません。自動再試行やOn Demandによる再接続が記録されていないか、まず確認してください。

共有前にプライバシー情報を削除する

Logには、アクセスしたドメイン、サーバーのアドレス、アカウント項目、サブスクリプションのURLなど、個人を特定できる情報が含まれる場合があります。共有する前に、認証パラメータ、パスワード、個人情報を削除してください。アドレスを置き換える場合は、記録全体で同じアドレスに同じ仮名を使います。そうしないと接続の関連性が分からなくなります。問題の説明の代わりにConfig全体をアップロードしたり、認証情報を含むスクリーンショットを公開したりしないでください。パスワードが直接表示されていなくても、認証パラメータ付きのURLは機密情報として扱ってください。

Logは原因特定の根拠を集めるために使うもので、特定の通信経路が「絶対に正常」だと証明するものではありません。接続段階、ルール、結果を残し、認証情報と個人情報を削除したうえで、再現手順を記載してください。

トラブル対処が終わったら、ログの詳細度を元に戻し、必要に応じてローカルにエクスポートしたファイルを削除してください。テストのために変更したDNSやルーティングが残っていないことも確認します。引き続き原因を調べる場合は、問題を名前解決、認証、ルール、システム権限のいずれかに分類し、接続トラブルのQ&Aをご覧ください。Logを増やすだけでは原因が明確になるとは限りません。再現条件と前後のつながりが分かる記録が、次の判断に役立ちます。

6. Widgetの表示、ショートカット、状態確認

ショートカットは設定画面の代わりにはならない

Widgetは、システムが提供する場所に情報を表示したり、現在対応しているショートカット操作を実行したりする機能です。形式、サイズ、操作できる内容は、システムとShadowrocketの現在の画面によって異なります。ある端末のWidgetの配置を、すべてのプラットフォーム共通の機能として扱わないでください。アプリを開く回数を減らすのには便利ですが、Configの編集、プロトコルの設定確認、Logの分析の代わりにはなりません。状態に問題がある場合は、Widgetの表示だけで判断せず、HomeとシステムのVPN状態を確認してください。

初期の表示内容はSettings › Widgetとシステムの追加画面で確認してください。ホーム画面にWidgetを追加していなくても、アプリの接続機能が無効になっているわけではありません。まずアプリ内で接続と切断が正常に動作することを確認し、必要なWidgetを追加してください。システムに該当する種類がない場合は、現在利用できる入口をご利用ください。同じ見た目を探すためにDNSを変更したり、サーバーを再読み込みしたりする必要はありません。Widgetが表示されない問題は、多くの場合、システムの表示や権限に関するもので、ドメインルールの正しさとは直接関係ありません。

追加後に関連づけられた状態を確認する

システムのWidget追加画面でShadowrocketを選択し、画面に表示される手順で配置と設定を完了します。初めて使う場合は、先にアプリを開き、表示する情報が保存されていることを確認してからWidgetに戻ります。表示項目を選べる場合は、現在使用中の項目に関連づけられているか確認してください。サーバーの削除や名前変更、Configの変更後は、ショートカットが引き続き有効な項目を参照しているかも確認します。以前と同じタイトルが表示されていても、関連づけが変わっていないとは限りません。

更新、バックグラウンド動作、ネットワーク切り替え

システムによってWidgetの更新頻度が制限されることがあり、表示がアプリと常に同じ状態とは限りません。Widgetは便利なショートカットと状態の参考として使い、連続したネットワーク監視には使わないでください。画面ロック、低電力状態、バックグラウンド処理、ネットワークの変化によって、表示の更新タイミングが変わる場合があります。古い状態が表示されたら、まずアプリを開いて確認し、システムによる更新を待ってください。まだ更新されていない表示に合わせるために、Configを何度も削除したりサーバーを切り替えたりしないでください。

ショートカットで接続を切った後に再び接続された場合は、Widgetが動作しなかったと考える前に、On Demandの条件を確認してください。操作は成功していても、その後システムが条件に応じて接続を再開した可能性があります。逆に、Widgetに接続中と表示されていても、対象のリクエストに正しいルールが適用されているとは限りません。ConfigのDIRECTやREJECTが適用されることもあります。検証には実際のアクセスを新たに行い、Logで経路を確認してください。アイコンやスイッチの表示だけを通信経路の根拠にしないでください。

表示情報とプライバシーへの配慮

Widgetがホーム画面やほかの人にも見えるシステム領域にあると、サーバーのメモ、Config名、接続状態が見られることがあります。アカウント、メールアドレス、認証情報を含まない短いメモを使うことをおすすめします。画面を投影したり共有したりする機会が多い場合は、Widgetの表示内容を事前に確認してください。名前を変更しても、元の接続パラメータは変わりません。サブスクリプションのURLをメモとして登録したり、見分けやすくするためにパスワードを名前に入れたりしないでください。名前と認証情報は分けて管理します。

おすすめの設定方針：日常的に必要な情報だけを表示し、用途が明確なショートカットだけを使ってください。システム表示と実際のリクエストの結果が異なる場合は、アプリ、システムのVPN状態、新しいリクエストを合わせて確認します。

Widgetを利用できない状態が続く場合は、まずアプリが正常に開くか、システムがWidgetの追加を許可しているか、関連づけられた項目が残っているかを確認します。その後、システムの方法でWidgetを一度削除し、追加し直してください。表示の問題を直すために、バックアップなしでアプリをアンインストールしないでください。ローカルのConfigも失われる可能性があります。アプリ自体も接続できない場合はWidget以外の問題です。Settingsの概要に戻って変更範囲を確認し、DNS、権限、サーバー設定の該当する項目を調べてください。

7. iCloud同期、データ移行、上書きのリスク

データ同期、購入履歴、システム権限を区別する

iCloud関連の機能は、対応環境でアプリのデータを扱うためのものです。App Storeの購入履歴に代わるものではなく、システムのVPN権限が端末間で移行されることを保証するものでもありません。新しい端末にConfigが表示されても、ネットワーク権限の初回確認が完了しているとは限りません。同じ購入アカウントでアプリを入手しても、別の端末の設定がすべて表示されるとは限りません。ストアのアカウント、システムのクラウドサービスのアカウント、アプリで実際に同期される範囲をそれぞれ確認し、ひとつのスイッチの状態として混同しないでください。

同期が初期状態で有効か、どの項目が同期されるかは、Settings › iCloudとシステムの関連設定で確認してください。このガイドでは、すべての項目が同期されるとも、ほかのプラットフォームで同じクラウドサービスが使われるとも想定していません。同期を初めて有効にする前に、ローカルで復元できるコピーを保存し、画面に表示される同期範囲を確認することをおすすめします。Configを一つだけ移行する場合は、すべての同期を有効にするのではなく、明確なエクスポートと読み込みの手順を使ってください。

まず、どのデータを残すか決める

2台の端末で設定が異なる場合は、どちらのデータを残すか決め、もう一方の重要な差分を別に記録してください。両方の端末で名前の変更、削除、項目の追加を大量に行ってから、システムが適切なデータを自動で判断することに期待しないでください。同期は状態を転送しますが、操作の意図までは判断しません。競合が起きた場合は、現在の画面に表示される案内を読んでください。置き換えや上書きの確認が表示されたら、バックアップを確認するまで操作を止め、確認を続けてタップしないでください。

同期後も実際の接続を検証する

移行先の端末でアプリを開き、まず項目がそろっているか確認してから、有効なConfig、Global Routing、選択中のサーバーを確認してください。名前が同じか確認するだけでは不十分です。ポート、プロトコル、追加パラメータも接続に影響します。次に手動で接続し、権限に関する案内に対応したことを確認してから、実際の接続先を一つテストします。その後でOn DemandとWidgetを設定すると、データ移行の問題と自動接続や表示の問題を切り分けやすくなります。

サブスクリプションの同期と更新は別の操作です。同期によって既存の項目が別の端末に表示される場合がありますが、更新ではご自身が利用しているサブスクリプションのURLにアクセスし、返された内容に応じてデータを処理します。新しい端末の項目数や名前が異なる場合は、更新が成功したか、同じURLを使っているか、ローカルで編集されていないかを確認してください。古いデータをすぐに削除して何度も更新すると、正常に使えるローカルの記録と比較に必要な情報を同時に失う可能性があります。

アカウントと機密データの取り扱い

同期を有効にする前に、Configにサーバーアドレス、パスワード、認証情報、サブスクリプション情報が含まれる可能性を理解してください。データにアクセスできる人は、端末とアカウントを誰が管理しているかによって異なります。共有端末にConfig全体を保存する場合は慎重に扱ってください。端末を売却、譲渡、または使用停止にする際は、システムとアプリの方法に従って個人データを処理します。ホーム画面からWidgetを削除してもConfigは削除されず、同期スイッチをオフにしても保存済みのコピーがすべて消えるとは限りません。

同期は単独のバックアップではありません。削除や誤った変更が同期される場合もあります。重要な変更の前には、リアルタイム同期に依存しない、復元可能なコピーを保存してください。

同期がなかなか反映されない場合は、クラウドサービスへのログイン、利用可能な容量、ネットワーク、アプリの権限を確認してから、アプリの案内を確認してください。同期を促すために、2台の端末ですべての設定を何度も切り替えないでください。状態の差が広がるおそれがあります。復元が必要な場合は、まず編集を止め、両方の端末の状態を保存してください。確認済みのコピーから一方を復元し、動作を検証します。購入済みアプリの再入手については機種変更と再インストールの手順をご覧ください。データの復元は、アプリの購入や入手手順の代わりにはなりません。

8. Proxyのローカルポートとアクセス範囲

ローカル待受ポートと接続先サーバーのポートは別

Proxy関連の設定には、本機のアプリが接続するためのローカルHTTPまたはSOCKSプロキシポートが含まれる場合があります。該当する項目は現在の画面で確認してください。これらのポートはクライアントがローカルに用意する入口で、Add Serverに入力する接続先サーバーのポートとは異なります。ローカルポートを変更しても、サービス提供元のサーバー設定は変わらず、ほかのアプリが自動的にProxyを利用するわけでもありません。利用するアプリが対応するProxy方式をサポートし、ローカルアドレスとポートを明示的に設定する必要があります。

初期ポートと待受アドレスは現在の設定で確認し、インターネット上の例をもとに固定値を推測しないでください。ローカルProxyを使う必要がなければ、設定を変更せず、最適化のためだけに待受を追加で開かないことをおすすめします。必要な場合は、ポート、プロトコル、アクセス範囲を記録してください。待受アドレスを指定できる場合は、本機だけで使う入口をローカルに限定します。LAN内に公開すると、この入口に接続できる端末が変わるため、ネットワークの信頼性、アクセス制御、システムのファイアウォールも考慮してください。

アドレス、ポート、プロトコルを正しく対応させる

ループバックアドレス127.0.0.1は現在の端末自身を指し、同じWi-Fiにつながった別の端末を指すものではありません。パソコンにこのアドレスを入力すると、スマートフォンのShadowrocketではなく、そのパソコン自身に接続します。別の端末から接続する場合は、サービスを提供する端末の実際に到達可能なアドレスを使い、待受範囲も確認してください。これは追加のネットワーク管理が必要な設定です。ポートが開いているだけで、ほかの端末から接続できるとは限りません。

ポートの競合と接続失敗を見分ける

ほかのプロセスがポートを使用中の場合、クライアントが対応する待受を開始できないことがあります。画面の案内とLogで、どのローカル入口が失敗したかを確認してください。サーバーのパスワードを変更する必要はありません。ポートを変更する場合は、現在使われておらず、画面で設定できる値を選び、そのProxyを利用するアプリ側の設定も更新します。クライアントだけ変更して利用アプリを更新しないと、設定が食い違います。テスト後は新しい値を記録し、次に古い設定へ戻したときに再び問題が起きないようにしてください。

ローカルの入口に接続できても対象のリクエストが失敗する場合は、クライアントの接続状態、Global Routing、有効なルールを確認します。アプリからローカルProxyへリクエストを渡せても、その後のサーバー認証や接続先への通信で失敗することがあります。逆に、アプリでローカル接続が拒否された場合は、クライアントが動作中か、該当する入口が有効か、アドレスとポートが正しいかを確認してください。この2種類の問題を切り分けると、すべてを通信経路の異常として扱わずに済みます。

システムVPNトンネルと明示的なProxy設定の違い

システムVPNトンネルと、アプリに手動で入力するProxy設定は、異なる通信の取り込み方法です。すべてのアプリがシステムの明示的なProxy設定に従うわけではなく、ローカルポートを一つ開いただけですべてのアプリを対象にできるわけでもありません。通信経路を把握せずに複数のProxyを重ねると、ループや二重処理が起きたり、Logが読みづらくなったりすることがあります。まず一つの方法で動作を確認し、もう一方も本当に必要か判断してください。経路を複雑にすることを機能の追加と考えないでください。

おすすめの方針：本機だけで使う場合はアクセスを本機に限定し、ほかの端末から使う場合はアクセス範囲を明確にします。管理できないネットワークにローカルProxyポートを公開したり、外部に接続を提供するサービスとして使ったりしないでください。

テストを終えるときは、Shadowrocketのポートと待受状態を元に戻すだけでなく、ほかのアプリに一時的に入力したProxyアドレスも削除してください。アプリを停止した後も、これらのアプリが利用できないローカル入口に接続し続け、端末全体のネットワーク異常に見えることがあります。デスクトップでシステムProxyも変更した場合は、記録した元の状態に戻してください。通常のネットワークが復旧したことを確認してから、必要な設定だけを一つずつ有効にします。ルールの適用結果に問題がある場合は、ローカルポートを変更し続けず、次の章でConfigを確認してください。

9. Global Routing、ルール、設定の連携

まず現在のルーティングモードを確認する

Global RoutingのConfig、Proxy、Directは、それぞれConfig、プロキシ接続、直接接続に対応します。Configでは有効な設定に基づいてリクエストを振り分け、Proxyはプロキシ経由、Directは直接接続として動作します。ルールを確認する前に、現在Configが選択されていることを確認してください。そうでない場合、ルールの構文が正しくても、想定どおりリクエストに適用されないことがあります。初期状態はHomeの現在の表示で確認し、ガイドのある手順で選択したモードを、すべての端末で変わらない初期値として扱わないでください。

ルールの順序とFINALの位置

ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。そのため、通常は具体的な条件を広い条件より前に置きます。DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはドメインのサフィックスに、DOMAIN-KEYWORDは指定キーワードに一致します。IP-CIDRとIP-CIDR6はIPアドレスの範囲を対象とし、GEOIPはアドレスの地域データに基づいて判定します。ルールごとに必要な情報は異なります。ドメインが存在しても、名前解決なしでIPアドレスのルールを判定できるとは限りません。

FINALは、それより前のルールに一致しなかったリクエストに適用されるフォールバックで、通常はルール一覧の最後に置きます。ほかのルールより前に置くと、後続のルールは一致する機会を失います。以下は構文を理解するための最小限の.confの断片です。Config全体ではなく、すべての環境に適した推奨ルール一覧でもありません。例に使うドメインとローカルネットワークの範囲は順序の説明用です。読み込む前に、ご自身のConfigに適しているか確認してください。

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

この例では、example.comとそのサブドメインは先にDOMAIN-SUFFIXに一致するため、後続のキーワードルールには進みません。PROXY、DIRECT、REJECTは、それぞれProxy経由、直接接続、拒否を表します。画面上のモード名と大文字・小文字の書き方を混同して、意味の代わりに使わないでください。特定の接続先をブロックする場合は、まず影響範囲を明確にします。一つのページが複数のドメインを使うことがあり、そのうち一つを拒否すると、目に見えるボタンだけでなく、ページ全体の表示が変わることがあります。

設定の影響を比較して切り分ける

Configでは失敗しProxyでは成功する場合は、サーバーをすぐに変更せず、適用されたルール、有効なファイル、DNSの経路を確認してください。どちらのモードでも失敗する場合は、接続先サーバーの設定と基本接続を確認します。Directの結果から分かるのは、現在の直接接続の状態だけです。ほかの経路にも問題があるとは限りません。モードを切り替えた後は、新しいリクエストで検証してください。以前のルーティングを使う既存接続が残っていると、比較結果が矛盾して見えることがあります。

サブスクリプションの更新、Configファイルの更新、手動編集は分けて管理してください。サブスクリプションは主に、ご自身が利用しているサーバー情報を扱います。Configは設定内容を管理するため、一方を更新しても、もう一方も同期して変更されたとは限りません。編集前に、対象が有効なファイルか確認します。更新前に重要なカスタムルールを保存してください。外部のConfigを再読み込みした後は、ローカルの変更が上書きされていないか確認します。ファイル名が同じでも、中身が変わっていないとは限りません。

日常利用では、内容を確認済みのConfigを使うことをおすすめします。トラブル対処では、ProxyとDirectを短時間比較してください。テスト終了後は元のモードに戻し、DNS、On Demand、有効なルールを再確認して、一時的な設定を残さないようにします。

ルールとDNSの連携はLogで確認します。対象を探し、最初に一致したルールを確認してから、後続の接続を調べてください。ルールの優先順位を詳しく知りたい場合は、カスタムルールの優先順位とFINALをご覧ください。読み込み手順を確認する場合は、Subscribeの操作方法に戻ってください。Configの変更、一つのリクエスト、対応する記録を結びつけて確認すると、ルールを増やすだけより安定した管理につながります。