Shadowrocket公式アイコン 公式マニュアル / Settingsガイド

Shadowrocket Settingsの設定ガイド

設定の範囲を確認してから、項目ごとに変更します。

このページでは、各設定がどの範囲に影響するか、反映されたかをどう確認するか、問題が起きた場合にどう戻すかを解説します。既存のサブスクリプションを初めて読み込む、サーバーを選ぶ、接続を確立するといった基本操作は、まずクイックスタートに沿って進めてから、該当する章を参照してください。画面上の場所や利用できる項目は、実際のデバイスの表示をご確認ください。

設定の適用範囲と初期状態

まず設定の階層を区別し、変更すべき場所を判断します。Settingsはアプリの設定画面ですが、接続時にはHomeで選択したサーバー、Global Routingのモード、Config内のルール、システムのネットワーク環境も影響します。スイッチがオンになっているだけでは、通信が想定どおり処理されているとは限りません。確認時には、現在のサーバー、Config、接続状態をまとめて記録し、異なる階層の問題を一つの設定項目のせいにしないようにしましょう。

アプリ設定、Configファイル、サーバー設定

アプリ設定は主にテスト方法、表示、ログ、システム連携などの動作を管理します。Configにはルールや関連するネットワーク設定が保存され、サーバーの項目にはプロトコル、アドレス、ポート、認証情報が含まれます。同じ「ポート」でも、表示される場所によって意味は異なります。Add ServerのPortは接続先サーバーのポート、ローカルProxyの待ち受けポートはデバイス上のサービス入口です。変更前に画面を確認し、説明が似ているからといって別の項目に同じ値を入力しないでください。

ユーザーがすでに利用しているサブスクリプションを読み込むと、主にサーバー項目とその更新元が追加されます。それだけで現在のルールファイルも置き換わるとは限りません。アプリのアップデート、Configの再読み込み、サーバーの切り替えもそれぞれ異なる操作です。更新後に値が変わった場合は、まずどの種類の項目が更新されたかを確認し、読み込んだ内容によって上書きされたかを調べてください。むやみに再読み込みを繰り返すと、既存の項目と新しい項目が混在して、原因を特定しにくくなります。

変更前に確認する設定の階層
場所または対象主な役割確認方法
Settingsアプリの動作、テスト、システム連携該当機能の実際の動作
ConfigルールとConfigファイル内のネットワーク設定現在有効なファイルとリクエスト記録
Add Server接続先サーバーのパラメータ元のサーバー情報と接続結果
Global RoutingConfig、Proxy、Directのモード選択実際のリクエスト処理経路

初期値はすべてのデバイスで共通とは限りません

このマニュアルでは、特定のデバイスで表示された値を恒久的な初期値とはみなしません。インストール直後、旧デバイスからの移行後、Configの読み込み後では状態が異なる場合があります。また、システムの機能やアプリの実装変更に伴い、一部の項目が変わることもあります。ここでいう初期状態の確認とは、変更前に現在の値、説明、Configを確認し、元に戻せるよう記録しておくことです。明確な必要がなければ、一覧と一致させるために項目を一つずつ変更するのではなく、現在の値を維持してください。

記録には、項目名、変更前後の値、変更理由を記載してください。項目が空欄でも、自動的にオフや無効と判断しないでください。空欄はシステムの情報を利用する意味の場合もあれば、Config側の処理を使う意味の場合もあります。具体的な意味は項目の説明で確認してください。判断できない場合は現状を維持し、条件を限定してテストします。推測した共用アドレスや数値で空欄をすべて埋めないでください。

変更と復元を再現できる手順にする

まず安定したネットワークで基準となるテストを行います。接続できることを確認し、よく使うページを開いて、Global Routingと現在のConfigを記録してください。その後、変更する値は一つだけにして、同じネットワーク、同じページで再テストします。DNS、サーバー、ルールを同時に変更すると、改善してもどの項目が効いたのか分からず、悪化した場合もどこを戻せばよいか判断しにくくなります。何度もリセットするより、一項目ずつ変更するほうが原因の特定に役立ちます。

接続の主要な設定を変更した際、画面に再接続の案内が表示されたら、その指示に従ってください。案内がない場合も、保存後に一度切断して再接続すると、古いセッションを使い続けることを防げます。変更後も旧接続が使えるからといって、新しい値が検証済みとは限りません。元に戻すときは、元の値とConfigを復元して同じテストを行います。復元後も失敗する場合は、ネットワークの切り替え、サーバーの状態、システム側の変更も確認してください。

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

DNSはドメイン名を、後続の接続に必要なアドレスへ変換します。ルール判定に関係しますが、ルールの代わりにはならず、サーバーの認証失敗も解決できません。トラブルを調べる際は、まず症状を切り分けてください。ドメイン名の名前解決エラー、アドレス取得後の接続タイムアウト、接続後にページの内容が正しく表示されない状態は、それぞれ異なる段階の問題です。名前解決エラーは直接DNSを示しますが、残りの2つはルーティング、通信、サーバーの応答も確認する必要があります。すべてをDNSの問題として扱わないでください。

名前解決設定の参照元を確認する

まず現在有効なConfigにDNS関連の記述があるかを確認し、次にSettingsで利用できるDNS項目とその説明を確認します。画面とファイルの両方に関連項目があっても、表示場所だけを根拠に、どちらが必ず優先されるかを決めつけないでください。その項目が全体の動作、Configの補足、あるいは特定の名前解決方式のパラメータなのかを確認します。項目ごとに処理段階が異なる場合があり、名称にDNSが含まれていても同じ役割とは限りません。変更後は保存されたかだけでなく、新しいリクエストで動作を確認してください。

正常に使えているConfigは、現在の名前解決方式を維持することをおすすめします。再現できる名前解決の問題がある、自分で管理するDNSサービスを使う必要がある、または既存Configで特定の方式が明示されている場合に限り、関連項目を変更してください。アドレスを入力する前に、単一アドレス、リスト、プロトコル付きアドレスのどれが指定可能かを確認します。ブラウザで開くページのURLを、そのままDNSサーバーのアドレスとして入力してはいけません。プロトコルの接頭辞、ポート、パスも項目で指定されている形式に従ってください。

名前解決サービスへアクセスする通信も必要です。暗号化された通信を使う名前解決方式では、サービス名の解決に先にアドレスが必要になる場合があり、証明書の検証にも正しい名前とシステム時刻が必要です。そのため、「暗号化DNSに変更すれば、それまでのネットワーク条件は関係なくなる」というわけではありません。依存関係が循環したり接続に失敗したりした場合は、まず元の方式に戻して基本ネットワークを確認し、新しい方式への到達性と設定の意味を確認してください。DNSアドレスを次々と追加しないでください。

ドメインルールとアドレスルールの違い

DOMAINとDOMAIN-SUFFIXはリクエストのドメイン名に基づいて判定できます。IP-CIDR、IP-CIDR6、GEOIPはアドレスの条件に基づきます。アドレス情報が必要な場合は名前解決の結果が後続の判定に影響しますが、リクエストにドメイン名が保持されているか、先行するルールにすでに一致しているかも処理に関係します。ルールを調べるときは上から順に読み、まずどのルールに一致したかを確認してから、DNSが関与しているかを検討してください。リスト末尾のアドレスルールだけに注目しないでください。

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

上記の断片はルールの順序を示すもので、接続設定一式ではありません。既存ファイルとの置き換えも不要です。example.comは例示用ドメインです。プライベートアドレスのルールはアドレス範囲の一致を示し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。自分のConfigに追加する前に、既存ルール、ポリシー名、想定する通信経路を確認してください。例の断片が保存できたからといって、すべてのネットワークに適しているとは限りません。特にLAN内のリソースや既存の業務ルールへの影響に注意してください。

キャッシュ、ネットワーク切り替え、推奨する確認手順

DNS変更後も、ブラウザ、アプリ、既存の接続が以前の結果を保持している場合があります。テスト中のページやアプリのセッションを閉じ、必要に応じて再接続してから、同じドメイン名で新しいリクエストを送ってください。名前解決の結果が特定のアドレスでなければならないとは限りません。同じサービスでもネットワークや負荷に応じて異なるアドレスが返ることがあります。確認するのは、名前解決に成功したか、リクエストがルールに沿って処理されたか、接続結果を安定して再現できるかです。他の人とアドレス文字列が一致するかではありません。

特定のWi-Fiだけで失敗する場合は、必要なWeb認証が完了しているかを確認し、LAN内の名前解決と現在のDNS設定が競合していないかを調べてください。ネットワーク切り替え後に一時的に失敗する場合は、キャッシュの更新待ちなのか、トンネルの復旧待ちなのかを切り分けます。設定を元に戻して問題が解消したら、追加した項目を一つずつ確認してください。元の設定でも失敗する場合は、基本ネットワークと現在のサーバーを引き続き確認し、同じ場所でDNSアドレスを次々と変更しないでください。

On Demandによるオンデマンド接続

On Demandは、条件に一致したときにシステムが接続を開始または維持する方法を管理します。ドメインごとにProxyまたはDirectを選ぶルール一覧ではありません。前者が決めるのは「いつ接続するか」、後者が決めるのは「接続後にリクエストをどう処理するか」です。この2つを混同すると、ドメインルールを設定したのに接続が自動で開始されない、あるいはネットワーク条件を設定したためすべてのリクエストが必ず特定のサーバーを経由する、といった誤解につながります。

手動接続を確認してから自動条件を追加する

初めて設定するときは、On Demandの現在の状態を維持し、Homeから手動で接続して、既存のサーバー情報、Config、Global Routingが正常に動作することを確認してください。手動接続が安定してから、自動接続の動作を検証します。手動接続に失敗する場合は、まず基本接続を修復してください。オンデマンド条件で開始される接続も同じ処理を行うため、無効な認証情報や到達できない接続先を補うことはできません。

On Demandの画面では、ネットワークの種類、ネットワーク名などの条件を一つずつ確認し、保存後にどのルールが実際に適用されるかを確認してください。他の人のスクリーンショットを参考にして、自分のデバイスにも同じ項目があるとは限りません。ネットワーク名は実際の表示どおりに入力してください。よく似た名前でも同じネットワークとは限りません。条件が複数ある場合は、組み合わせる前に一致条件や例外に関する画面の説明を読み、想定より広い範囲にルールが適用されないようにします。

自動接続が必要でなければ、手動操作のままにすることをおすすめします。必要な場合は、繰り返し検証できる条件を一つだけ設定してください。たとえば普段使うネットワークの種類だけを対象にして、接続時と切断時の動作を確認してから、ほかの条件を加えます。すべてのネットワークを一度に対象にすると、異常が日常の接続全体に影響し、条件判定の問題なのか接続確立の問題なのかを特定しにくくなります。

システムの許可とネットワーク切り替えの注意点

初めて接続を確立するとき、システムからVPN構成の追加許可を求められる場合があります。この許可によってシステムにネットワーク接続構成を追加できますが、サブスクリプションやサーバー情報の有効性が確認されたことにはなりません。許可後も実際に接続してテストする必要があります。以前に許可を拒否した場合は、システムの現在の案内に従って再度許可してください。On Demandを何度も切り替えることを、権限を再取得する決まった方法と考えないでください。また、ほかの用途のシステム構成を削除して解決しようとしないでください。

Wi-Fiからモバイル通信に切り替えると、以前の接続が中断され、新しいネットワーク環境で再接続が必要になることがあります。ページが一時的に待機していても、すぐにオンデマンドルールの失敗と判断しないでください。まずシステムのネットワークが実際に切り替わったことを確認し、次にShadowrocketの接続状態を見てから、新しいリクエストを送信します。ネットワークの認証中、電波が不安定、または新しいネットワークから現在のサーバーに到達できない場合、自動接続が開始されても目的のリクエストがすぐに完了するとは限りません。

バックグラウンドで許可される動作と、アプリが前面にあるときの動作は同じではありません。アプリを離れた後に画面が更新されないからといって、トンネルが必ず切断されたとは限りません。ステータスアイコンが表示されていても、すべてのリクエストが成功しているとは限りません。現在の接続状態と実際のアクセス結果を合わせて確認してください。ほかのシステムネットワーク管理設定も接続に関与している場合は、影響範囲を確認せずに複数の自動接続条件を同時に変更しないでください。

接続の停止、設定の復元、問題の切り分け

オンデマンド接続を有効にした後、手動で切断しても再び接続される場合は、ボタンが反応していないのではなく、システムが条件に再度一致した可能性があります。接続を確実に停止するには、まずOn Demandが接続を要求しているか確認し、現在の画面に従って該当するトリガールールを無効にしてから切断してください。操作後は状態が安定するまで待ち、通常のリクエストを一度送って確認します。スイッチをすばやく何度も押すと、接続と切断が交錯して最終状態が分かりにくくなります。

決まった順序で問題を切り分けます。まずオンデマンド条件を一時的に無効にして手動接続を確認し、次に条件を一つだけ戻して作動するかを確認します。起動する場合は、その状態でリクエストの経路を調べてください。起動しない場合は条件とシステムの許可を確認します。起動してもアクセスできない場合は、サーバー、DNS、ルールを確認します。頻繁に再接続される場合は、まず対象を広げるのではなく、発生時のネットワークの種類と切り替え状況を記録してください。

PingとConnectivity Test

テスト値が示すのは、特定の方法で特定の時点に行った結果にすぎず、すべての通信が利用できることを直接示すものではありません。SettingsのPing関連項目はテスト方法を調整し、HomeのConnectivity Testは該当するチェックを実行します。結果を見る前に、テスト方法、対象、選択したサーバーを経由したかを確認してください。方法によって確認できるネットワーク段階が異なるため、異なるテスト結果を単純に比較しても、実用的な意味のある順位にならないことがあります。

テスト方法ごとに確認できること

画面でTCPテストを選べる場合、主に指定したアドレスとポートへの接続を確認します。ポートに接続できても、プロトコル認証、暗号化のネゴシエーション、接続先へのアクセスまで成功したとは限りません。HTTPテストがある場合は、対象アドレスとリクエストがProxy経由かどうかも確認します。応答があればより多くの段階を確認できますが、それでも対象とその時点のリクエストに限られます。名前の似たテストでも、経路や条件の確認を省略しないでください。

タイムアウトが発生したら、テスト対象への通信とサーバーへの接続のどちらで起きたかを切り分けます。接続先サーバーには到達できても、テスト対象が一時的に応答しない場合があります。対象が正常でも、現在のネットワークからサーバーへの経路に問題があることもあります。一度の失敗だけでサーバーが恒久的に使えないと判断しないでください。同じ方法で再テストし、基本ネットワークと対象を確認したうえで、実際のリクエスト結果と照らし合わせると、一時的な問題か継続的な障害かを区別しやすくなります。

テスト結果の解釈に関する注意
観測結果確認できることそれだけでは確認できないこと
ポートへの接続成功その時点でトランスポート層の接続を確立できたプロトコル認証とページ表示の成功
テスト対象からの応答そのテスト経路で応答を受け取れたすべての対象とすべてのプロトコルが利用可能
テストのタイムアウト制限時間内にテストが完了しなかった問題が必ずサーバー側で発生している

対象、タイムアウト、再試行回数の選び方

テスト対象には、現在の確認可能な設定を維持するか、自分で安定してアクセスでき、目的が明確な対象を使うことをおすすめします。数値を小さく見せるために対象を次々と変えると、前後の比較ができなくなります。対象がドメイン名の場合、名前解決もテストの一部になることがあります。ページがリダイレクトされたり認証を求めたりすると、単純な応答を想定した場合と結果が異なる可能性があるため、現在のテスト方法に適した対象か確認してください。

すべてのネットワークに最適なタイムアウト値はありません。短すぎると、遅延が大きくても利用可能な接続を失敗と判定することがあります。長すぎると、明らかに利用できない経路の検出が遅れます。初回の切り分けでは現在の値を維持し、安定したネットワークで様子を見てから、実際の失敗状況に応じて調整してください。リクエストがしばしば設定値の直前までかかる場合は、タイムアウトを延ばして問題を覆い隠すのではなく、まずネットワークとサーバーを確認します。

再試行の間隔と条件を揃え、端末で大量のアップロードやダウンロードを行っているとき、またはネットワークの切り替え中に順位を測定しないでください。短時間に複数の項目をまとめてテストすると、同時負荷によって普段の利用時と異なる結果になる可能性があります。既存の項目を少数選び、同じネットワークで繰り返し確認し、実際の通信が安定しているかも合わせて判断してください。一度の測定値が小さかっただけで、長期的な優先先を決めないでください。

テストは成功するのに実際のアクセスが失敗する

まず実際のリクエストに適用されているGlobal Routingを確認します。特定のサーバーをテストしても、実際のリクエストがそのサーバーを使うとは限りません。Configモードでは、リクエストがDIRECTに一致したり、別のポリシーで処理されたりする可能性があります。次にConfig内で対象に関係するルールを確認し、名前解決とリクエスト記録を調べてください。ルールに一致したかを確認せずにサーバーだけ切り替えると、そのリクエストに使われていない項目を比較し続けることになります。

プロトコルの設定によっても、「基本テストは正常なのにアプリの通信は失敗する」ことがあります。たとえばTLSを使う接続では、正しいサービス名と証明書検証が必要です。UDPを使う通信は、一度のTCP接続結果だけでは判断できません。既存のサーバー情報を元の内容と照合し、テストを通すために検証を安易に無効にしないでください。Trojanの各項目についてはPassword、SNI、Allow Insecureの設定方法をご覧ください。

テスト設定を戻すときは、対象、方法、タイムアウトを記録した値に戻し、同じ項目を再テストしてください。復元後も結果が変わる場合は、ネットワーク状態や接続先の応答も変化しており、差のすべてを直前の設定変更のせいにはできません。ネットワークの種類、テスト方法、成功の有無、実際のリクエスト結果を簡潔に記録しておきましょう。条件の説明がない数値のスクリーンショットより、後の切り分けに役立ちます。

LogとDataによる診断

Logはイベントやエラーの確認に、Dataは通信量の確認に使います。両者は補完関係にあり、代わりにはなりません。通信量が増えても、該当する集計範囲でデータが流れたことしか分からず、ページが完全に読み込まれたとは限りません。ログに接続確立が記録されても、その後の通信が成功したとは限りません。診断時は「このドメインがDirectルールに一致したか」のように具体的な問いを決め、それに関係する記録だけを確認します。目的なく詳細ログを長時間有効にしないでください。

ログの範囲と有効にする方法

まずSettingsでLog関連の項目を確認し、現在の有効状態、記録の詳細度、閲覧できる内容を区別します。利用できる項目は画面で確認し、特定のデバイスのログレベルをすべてのデバイスの初期値だと考えないでください。通常は基本的な切り分けに必要な現在の設定を維持し、再現できる問題があるときだけ必要なログを一時的に増やします。調査後は元に戻し、記録量や不要なローカルの機密情報が残るのを抑えてください。

問題を再現する前に、現在時刻とアクセスする対象を記録し、ページを一つ開いて結果を待つなど、明確な操作を一組だけ行います。記録量が多い場合は、画面で可能な方法で古い記録を消してからテストを始めます。証拠を残す必要があれば、消去前に機密情報を削除したバックアップを取ってください。複数のサーバーをまとめてテストしながら一つのページの問題を再現すると、テスト通信と実際の通信が交錯し、どのエラーが対象の操作に関係するか分かりにくくなります。

エラーを確認するときは、最後の失敗メッセージだけを検索するのではなく、発生順に読み進めます。名前解決の失敗によって後続の接続が始まらないこともあれば、認証失敗が通信確立後に起きることもあります。リモート側からの切断が、さらに前のエラーの結果という場合もあります。記録が簡略な分類だけを示す場合は前後のイベントと合わせて読み、似たエラーをすべて同じ設定項目の問題と判断しないでください。変更後の再テストでも、同じ順序で操作します。

Dataでリクエスト経路を照合する

Dataのアップロードとダウンロードは、一定期間の通信量を確認する入口として使えますが、現在の表示、集計範囲、リセット状態と合わせて読み取る必要があります。表示ごとに分類方法が異なる場合もあり、2つの数値をそのまま引き算して正確な結論を出すことはできません。テスト前に基準値を記録し、対象のリクエストだけを送信して関連する数値の変化を確認してください。長期間蓄積された合計値と比べるより、状況を判断しやすくなります。

デバイス上のほかのアプリが同期、メッセージ受信、バックグラウンドアクセスを行うことがあります。そのため、テスト中に通信量が増えても、直前に開いたページだけが原因とは限りません。特定のサーバーが使われたかを確認するには、そのサーバーに関連付けられた統計またはリクエスト記録を確認し、ルールの一致状況と照合してください。合計通信量が増えただけでは、対象がProxyを使ったとも、特定のルールが想定どおり動作したとも証明できません。

ページが表示されなくても通信量が少し増えることはあり、矛盾ではありません。接続の確立、認証のやり取り、失敗応答、再試行でも通信が発生します。ページの内容が完全に返されたかどうかは別の問題です。反対に、ローカルキャッシュからページが表示され、新しいリクエストが発生していないこともあります。ルールを検証するときは新しいリクエストが実際に送られたことを確認し、必要なら制御可能な別のページにアクセスしてください。同じキャッシュを何度も再読み込みしないでください。

機密情報の削除、共有、診断の完了

ログやConfigには、サブスクリプションのURL、認証情報、サーバーアドレス、アクセスしたドメイン、検索内容が含まれる場合があります。共有する前に、認証情報や不要な個人情報を削除してください。特にリンクのクエリ部分に認証情報が含まれている場合があります。パスワード欄だけを隠せば十分とは考えず、Config全体をそのまま公開しないでください。構造を示す場合は、必要に応じてサービスのドメインをexample.comに置き換え、エラーの種類やルール種別など必要な情報だけを残します。

有効なトラブル報告には、想定した動作、実際の症状、ネットワークの種類、Global Routing、現在のConfig、一項目だけ変更した結果を含めます。機密情報を削除した関連記録を添付しても構いませんが、過去の記録をすべて提示する必要はありません。アプリの入手方法やシステムとの互換性についてはApp Storeのページを確認してください。接続先アカウントの有効性は、ユーザーがすでに利用しているサービスの管理情報で確認します。ログから権限を推測しないでください。

Widgetとシステム上の入口

Widgetは、状態の確認やよく使う操作へのアクセスに使うシステム上の入口です。具体的な形式はアプリが提供するコンポーネントと、システムが現在対応している機能によって異なります。独立したProxy設定ではなく、Homeのサーバー選択やGlobal Routingの代わりにもなりません。初めて使うときは、まずアプリ内で接続を確認してからWidgetを追加してください。問題が起きた場合に、Widgetの表示と接続そのものを区別しやすくなり、複数の入口から同じ状態を繰り返し変更せずに済みます。

Widgetの設定とシステムへの追加は別の操作

SettingsにWidget関連の項目がある場合、まずWidgetの内容、表示方法、ショートカット操作のどれに影響するのかを確認します。アプリ内で関連項目を設定していても、システムの手順に沿って、対応する場所にWidgetを追加する必要があります。逆に、システム上にWidgetがあっても、すべての操作が初期化済みとは限りません。初めて使う前にアプリを開き、現在のConfigとシステムの許可が利用可能な状態か確認してください。

システム画面に表示される入口の名称が、常に固定されているとは限りません。システムによって、サイズや配置の異なるWidgetが用意され、表示できる情報量や操作方法も異なる場合があります。現在のデバイスで追加できる項目を確認し、日常の確認に必要な範囲でシンプルなレイアウトを選んでください。デバイスに項目が表示されない場合、ネットワーク設定を変更して探すのではなく、システムの互換性とアプリ内の機能入口を確認します。

まずは既定の表示内容を維持し、必要に応じて不要な情報を減らすことをおすすめします。人目に触れやすい場所にWidgetを置く場合は、サーバー名、状態表示、統計情報から利用状況が分からないか検討してください。項目名を分かりやすく変更しても、パスワード、サブスクリプションのURL、認証情報を名前に記載しないでください。表示項目は操作を便利にするためのものであり、機密性の高い接続情報を保存する用途ではありません。

状態の更新と操作結果を確認する

システム上のWidget表示は、アプリの前面画面と完全に同時に更新されるとは限りません。ネットワーク切り替え、接続確立、システムの処理中は、以前の状態が一時的に表示されることがあります。表示が異なる場合は、まずShadowrocketを開き、Homeで実際の接続状態を確認してからリクエストを送ってください。Widgetの表示だけを見て接続成功と判断せず、更新が遅れているからといって反対の操作を続けて実行しないでください。状態が頻繁に切り替わる原因になります。

Widgetから操作すると、システムがアプリを開いたり確認画面を表示したりする場合があります。途中の画面を失敗とみなさず、現在の案内に従ってください。操作が完了したかは、実際の接続結果で確認します。On Demandが接続を要求している場合、Widgetで切断しても再び接続されることがあります。その場合はオンデマンドルールを確認してください。Widgetを何度も削除して追加し直しても、接続のトリガー条件は変わりません。

Widgetに想定した内容が表示されない場合は、正しいWidgetとサイズを追加したかを確認してから、アプリ内のWidget設定を調べてください。その後アプリを開き、初期化が完了するまで待ってから、システムの手順でWidgetを再読み込みします。アプリ内の接続にも問題がある場合に限り、DNS、サーバー、ルールを調べてください。表示の問題とネットワークの問題を分けることで、正常な接続設定を表示のずれを直すために変更せずに済みます。

バックグラウンド動作、バッテリー消費、システム権限の注意点

Widgetが表示されていること、アプリがバックグラウンドにあること、システムのネットワーク接続が動作していることは、それぞれ別の状態です。アプリが前面にないからといって接続が停止したとは限りません。また、Widgetを更新するために接続を何度も作り直す必要もありません。バックグラウンド更新はシステム独自のスケジュールで行われ、アプリ内のネットワーク記録は実際のリクエストを示します。特定の時間に何が起きたか確認するには、LogとDataを参照し、アプリが画面に表示されているかだけで判断しないでください。

バッテリー消費を一つのスイッチだけで説明することもできません。頻繁な再接続、大量のリクエスト、弱い電波、詳細ログの記録などが活動量を増やす場合があります。比較する際はネットワークと使い方を揃え、一度に変更する条件を一つにしてください。ネットワークが頻繁に切り替わるときや、バックグラウンド同期が多いときに、WidgetやPingの設定だけを原因として消費電力を判断しないでください。変更後に異常が起きたら、その変更を戻して再テストしてから、継続的な関連があるかを判断します。

iCloud同期とConfig

同期、バックアップ、読み込み、サブスクリプションの更新は、別の操作として考えてください。同期は同期に対応した内容をデバイス間で共有するもの、バックアップは復元可能なコピーを保管するもの、読み込みは外部の内容を現在のアプリに取り込むものです。サブスクリプションの更新は、登録済みの参照元から該当項目を更新します。これらは近い場所に表示されていても、同じデータを置き換えるとは限りません。機種変更前に、保存するサーバー、Config、ローカル設定を整理し、それぞれに適した方法を選んでください。

同期の対象範囲とシステム条件を確認する

iCloud関連機能を使う前に、想定しているApple Accountにデバイスがサインインしているか、システムでアプリのクラウド機能が許可されているか、現在のネットワークで同期できるかを確認します。続いてShadowrocketの画面で、同期対象についての説明を読んでください。すべてのSettingsの値、接続状態、システムのVPN許可、過去のログが同期されるとは限りません。対象として明記されていない内容は、新しいデバイスで一つずつ確認してください。

同期スイッチがオンでも、最新の内容がクラウドに保存済みとは限りません。変更後はシステムによる転送を待ち、別のデバイスで該当項目が表示され、内容も一致しているかを確認してください。システムからストレージやネットワークの問題が通知された場合は、同じファイルを繰り返し読み込むのではなく、まずその条件を解決します。読み込みと同期が並行して何度も行われると、同じ名前の項目が増え、どれが最新で使用対象なのか分かりにくくなることがあります。

大規模な編集を行う前に、用途と保存時のConfigの状態が分かる名前を付けてバックアップを作成することをおすすめします。誤削除や誤編集も同期される可能性があるため、同期だけで過去の状態を保存することはできません。認証情報を含むバックアップは自分で管理できる場所に保管し、公開リンクで共有しないでください。ファイル名にもサブスクリプションのURLを含めないでください。復元テストは少数の項目から始め、構造と内容が正しいことを確認してから続けます。

Configファイルの選択と読み込み後の確認

Configを読み込んだら、ファイルが完全か、ルールを読み取れるか、ポリシー参照先が現在の環境にあるかを確認し、実際に使用中のファイルとして選択されているかも確認してください。ファイルが一覧にあることと、有効になっていることは別です。旧デバイスの動作を再現する場合は、Global RoutingがConfigモードかどうかも確認します。ファイルが同じでも、Configモードでなければ実際のリクエストが以前のルール判定を通らない場合があります。

Configを読むときは、全体の構造から個別項目へ進み、まずルールの順序と最終処理を確認してから、ドメイン、アドレス範囲、関連するネットワーク設定を読みます。ほかから抜き出した一行をそのままファイル末尾に追加しないでください。FINALより後ろに置かれ、想定した動作にならない可能性があります。編集前に元ファイルをコピーして復元用にし、編集後は保存して、変更したコピーが有効になっていることを確認してください。同じ名前のファイルを切り替えているのに、変更が反映されていないと思い込むことを防げます。

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

この例では、より具体的なルールを先に置いています。example.com自体はDOMAINに一致し、関連するサブドメインはDOMAIN-SUFFIXで処理し、それ以外のリクエストはFINALに渡します。これはルールの断片であり、サーバー情報一式の代わりにはなりません。実際に使うときは、各ルールの目的を明確にし、既存のポリシーと対象ドメインの範囲を確認してください。ユーザーがすでに利用している参照元から取得したConfigも、ファイル名だけで用途を判断せず、適用前に変更内容を確認します。

複数デバイスでの競合と復元の順序

2台のデバイスで同じ内容を同時に編集する場合、まずどちらの内容を残すかを決め、同期が安定するまで待ちます。両方で編集を続けながら削除と作成を繰り返すと、最終結果を特定しにくくなります。ほかのデバイスでの編集を一時停止し、1台で内容を確認してから、もう1台で照合してください。復元時は特に、同じ名前のサーバーについてアドレスとプロトコルの設定を確認します。表示名だけで同一の内容だと判断しないでください。

機種変更は「アプリを入手、データを復元、現在のConfigを確認、システムの許可を完了、実際にテスト」の順に進めることをおすすめします。アプリの購入資格とConfigデータは別の対象です。前者はApp Storeの購入済み項目と互換性に従い、後者は実際のバックアップまたは同期範囲に基づいて復元します。復元後もローカルのSettingsとOn Demandを確認してください。旧デバイスのすべての動作が複製されているとは限りません。購入済み項目の復元方法は購入済みアプリの復元方法をご覧ください。

サブスクリプション更新後に項目が変わった場合は、まず更新元と項目の所属を確認し、手動で変更した内容が維持されているかを調べてください。接続先の項目が更新されたからといって、iCloudで競合が起きたとは限りません。また、ローカルの名前を残すために認証情報をむやみに変更しないでください。整理する必要がある場合は先にバックアップを取り、既存のサブスクリプションが管理する内容と自分で管理する内容を明確に分けます。こうすることで、次回の更新後も変更を追跡しやすくなります。

Proxyポートと確認手順

Proxyポートは、まずローカルと接続先を区別します。サーバー項目のPortは接続先サーバーのポートで、ユーザーがすでに持っているサーバー情報と一致している必要があります。SettingsにローカルHTTPまたはSOCKS5サービスのポートがある場合は、デバイス上のローカルProxyサービスの待ち受け口です。両者を同じ値にする必要はなく、相互に置き換えることもできません。ローカルProxyを使う必要がなければ関連機能は現在の状態を維持し、「速度向上」を目的に不要な待ち受けを有効にしないでください。

待ち受けアドレス、ポート、アクセス範囲

ポートは待ち受けアドレスと合わせて確認します。ローカル端末だけがアクセスできる入口と、LAN内のほかのデバイスにも許可する入口では、公開範囲が異なります。設定前にバインド範囲とアクセス権限に関する画面の説明を読み、ほかのデバイスから接続させる必要が本当にあるか確認してください。ポート番号が分かるだけで、ほかのデバイスから必ずアクセスできるとは限りません。ネットワーク分離、アドレス変更、システムの制限、サービスの稼働状態も影響します。

ローカルポートを手動で指定する場合は、画面で利用でき、ほかのサービスに使われていない値を選び、元の値を記録してください。接続先サーバーのPortをそのまま入力したり、すべての接続エラーを数字の変更で解決しようとしたりしないでください。保存後はまずサービスが起動することを確認し、利用予定のクライアントから正しいプロトコルで接続します。HTTPとSOCKS5は異なるプロトコルです。ポートを入れ替えただけでは、利用側が自動的に対応するとは限りません。

ローカルサービスのテストは、まずアクセス範囲を最小限にして行い、動作を確認してから範囲を広げる必要があるかを検討します。デバイスのネットワークアドレスが変わると、利用側に保存したアドレスが使えなくなる場合があります。アドレスの変化をサーバーの故障と誤認せず、アクセス制御を理解しないまま信頼できないネットワークに公開しないでください。使い終わったら、実際の入口に応じてサービスを停止し、ほかのデバイスから接続が試みられていないか確認します。

Global Routingが以降のリクエストを処理する

ローカルProxyが接続を受け付けても、その後のリクエストが選択した接続先サーバーを経由するとは限りません。Global Routingと現在のConfigも確認が必要です。Config、Proxy、Directはそれぞれ異なるモードで、Configは設定に基づく処理、ProxyはProxy経由、Directは直接接続です。日常的に通信を振り分ける場合は、通常、ルールが正しいことを確認したうえでConfigを使います。ProxyとDirectは、影響範囲を理解し、一律の経路が必要な場合や一時的な診断に使うのが適切です。

Global Routingの3つのモード
画面上の用語日本語での説明確認するポイント
ConfigConfigモード。現在のConfigに基づいてリクエストを処理有効なファイル、ルールの順序、ポリシー参照先
ProxyProxyモード。Proxy経由でリクエストを処理選択中のサーバーと実際の接続結果
DirectDirectモード。選択したProxyサーバーを経由せずに接続現在のネットワークから接続先へ直接到達できるか

特定のドメインを調べる場合は、元の状態を記録してから、一時的にDirectとProxyをそれぞれ試し、最後にConfigへ戻ってルールを確認できます。ただし、比較結果は原因を絞るためのものです。Directで成功してProxyで失敗しても、Proxy経由の名前解決、認証、接続先の応答を確認する必要があります。両方で失敗する場合は、接続先自体や現在の基本ネットワークも確認してください。テスト後は必ず元のモードに戻し、一時的な診断状態を日常の通信設定として残さないでください。

すべての設定を同時に変えず、段階ごとに切り分ける

まず接続が確立するか、次にドメイン名が解決されるか、その後ルールに一致しているか、最後に接続先が応答するかを確認します。サーバーに接続できない場合は、Address、Port、プロトコル、認証情報を優先して確認してください。接続済みでも一部のドメインだけ失敗する場合は、DNSとルールを確認します。特定の通信だけ失敗する場合は、通信方式とサーバー側の要件を調べます。WireGuardの各項目を一般的なパスワード方式と同じように扱うことはできません。Private Key、Peer、MTUの設定ガイドをご覧ください。

MTU、UDP、特殊な通信パラメータを変更する場合は、問題の特徴が明確で、比較できる条件があるときだけ調整し、それ以外は既存Configの値を維持することをおすすめします。数値を小さくしたりスイッチを増やしたりすれば、必ず安定するわけではありません。変更ごとに「特定のネットワークで特定の種類のリクエストだけが失敗するか」のような検証可能な仮説を立ててください。改善が見られなければ元に戻します。試行錯誤の結果、理由を説明できない設定の組み合わせを残さないでください。

変更後は、日常の利用に必要な内容を一通り確認します。現在のサーバーとConfig、Global Routing、On Demand、一時的に変更したログ設定を確認し、よく使うページ、必要なLAN内のリソース、ネットワーク切り替えをそれぞれテストしてください。有効だった結果と元に戻すための記録を残し、不要な一時ファイルは削除します。問題が続く場合は、機密情報を削除した症状とテスト条件をもとにルール振り分けと接続トラブルのFAQをご覧ください。原因を特定せず、リセットを繰り返して隠さないでください。