Shadowrocket
Settings設定ガイド

Shadowrocketの動作は、Settingsの一つのスイッチだけで決まるものではありません。システムのネットワーク権限、選択中のサーバー、Global Routing、使用中のConfig、サーバー側のプロトコル設定が関係します。「設定を変えても変化がない」ときは項目を追加で変更する前に、どのレイヤーを確認しているのかを特定してください。本ガイドは、利用者が自分のサブスクリプションまたはサーバー情報を持っていることを前提としています。サブスクリプションリンクはサービス提供元から入手してください。インポート後は、選択中のサーバーとConfigが正しいことを確認します。

初期状態は共通のデフォルト値とは限らない

「デフォルト値」には、アプリの新規インストール時の初期状態、インポートしたConfigで明示された値、デバイスのバックアップや同期から復元された値があります。これらは一致するとは限りません。アプリのアップデートで画面が変わることもあるため、本ガイドでは未確認のポート番号、テスト先、タイムアウト秒数を固定の初期値として記載しません。設定を確認するときは、現在の画面表示と使用中のConfigをあわせて記録してください。画面に表示されない値を、他の人のスクリーンショットから推測しないでください。

調整を始める前に、現在のConfigのコピーを保存し、Global Routing、選択中のサーバー、ネットワークの種類、解決したい問題を記録します。「ネットワークが遅い」だけでなく、「同じドメインを現在のWi-Fiで開くと、最初の読み込みに失敗する」のように、再現できる現象を書きましょう。その後はサーバー、ネットワーク、アクセス先を変えず、関連する設定を一つだけ変更します。結果が悪化しても明確な開始状態に戻せるため、元のスイッチの状態を記憶に頼って推測せずに済みます。

3つのモードでルールの適用を確認

Global RoutingのConfigは、現在のConfigに従ってリクエストを処理します。Proxyは主にプロキシ経由、Directは主に直接接続で処理します。これらはトラブルの切り分けに役立ちますが、ネットワークに必ず接続できることを保証するものではありません。システムが保持する通信、アプリ内の個別処理、サーバーの稼働状況も影響します。特にProxyでルール変更を確認しても、Config内のルール順が正しいかどうかは判断できません。

通常は常にProxyへ切り替えるのではなく、現在のルールを理解したうえでConfigを使うのがおすすめです。トラブルの切り分け中は一時的にモードを切り替えてテストし、終了後に元の設定へ戻してください。切り替えても既存の長時間接続がすぐに再確立されるとは限りません。対象へのリクエストを新たに実行し、必要に応じて適切なタイミングで接続を切ってから再接続します。通話中、ファイルのアップロード中など、中断できない作業の最中に何度も切り替えないでください。テストによる中断をサービス自体の障害と誤認するおそれがあります。

ルールファイルも別の入力として確認

以下の例は処理順を理解するためのもので、完全なConfigではなく、サーバーも作成しません。PROXY、DIRECT、REJECTはルールのポリシーであり、画面上のProxy、Directとは区別してください。例のドメインは説明用です。ルールは上から順に照合され、FINALは末尾のフォールバックとして配置します。前方に置くと、後続のルールがリクエストを処理できない場合があります。変更前に、同名のバックアップではなく現在有効なファイルを編集していることを確認してください。

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

「想定する動作」と「実際の記録」を並べて確認しましょう。特定のドメインがPROXYを通る想定なら、ホーム画面の接続スイッチを見るだけでなく、リクエスト記録で対象ドメイン、適用ルール、最終ポリシーを確認します。ルールが名前解決後のアドレスに関係する場合は、DNSの章で名前解決の経路も確認してください。購入やインストールについては正規購入の確認方法をご覧ください。アプリの買い切り購入と回線プランは別のものです。設定を変更しても、サービス提供元が提供する有効な接続情報の代わりにはなりません。

DNSは、ドメイン名を接続に必要なアドレスへ変換します。名前解決に成功しても接続先へ到達できるとは限らず、名前解決の失敗がサーバーの障害を意味するとも限りません。通常のアクセスには、ドメイン名の問い合わせ、ルール判定、接続の確立、アプリケーション層の通信が含まれ、どの段階でも失敗する可能性があります。DNSを確認するときは対象ドメインを正確に記録し、ブラウザーに表示されたページエラーとShadowrocketの記録にある名前解決エラーを区別してください。証明書の問題、接続先による拒否、応答のタイムアウトを、ひとまとめにDNSの問題としないようにしましょう。

DNSの設定値はどこから取得されるか

アプリのDNS関連設定とConfig内の名前解決設定は、あわせて確認する必要があります。ファイルで名前解決元が指定されている場合、システムのWi-Fi設定でDNSだけを変更しても、現在のトンネル内の名前解決が変わるとは限りません。逆にConfigで一部の項目が指定されていないからといって、アプリが特定のパブリックDNSを使うと決めつけることもできません。まず現在のファイルに関連する項目があるか確認し、次にSettingsの表示内容を記録します。テストを元に戻すときに、どのレイヤーの変更を取り消すのか把握しておきましょう。

システムの名前解決元を使うと、デバイスが現在のネットワークでどのように動作するか比較しやすいため、トラブルシューティングの出発点として適しています。ただし、あらゆるネットワークに最適な設定というわけではありません。企業、学校、家庭のネットワーク内にあるドメインは、そのネットワークのDNSでしか解決できない場合があります。名前解決元を外部アドレスに統一すると、内部ドメインが使えなくなることがあります。サービス提供元から提供されたConfigを使っている場合は、そのDNS設計を理解してから上書きするか判断し、用途のわからない設定を混在させないでください。

以下は、Configでシステムの名前解決元を指定する書き方の例です。ファイルの残りを削除してよいという意味ではなく、すべてのリクエストに適用されることも保証しません。編集前に既存ファイルを保存し、同じセクションに同名のキーがないか確認してください。重複項目は設定内容を誤解する原因になります。現在の画面やファイルの説明で確認できない高度なパラメータは、似た表記を見て追加するのではなく、現状のままにしておくことをおすすめします。

[General]
dns-server = system

IPv4、IPv6、ドメインルール

同じドメインからIPv4アドレスとIPv6アドレスのどちらが返されるかは、状況によって異なります。デバイスがIPv6アドレスを取得できても、プロキシサーバー、接続先、現在のネットワークを結ぶ経路全体が同じ接続方式に対応しているとは限りません。特定のネットワークでのみ接続先にアクセスできない場合は、名前解決結果のアドレスファミリーと、その後に発生した接続エラーを比較してから関連項目を調整します。IPv6を無効にすることを一律の最適化策と考えないでください。他の接続経路が変わり、実際にはルーティングやサーバーパラメータの問題を見えにくくするおそれがあります。

DOMAINやDOMAIN-SUFFIXなどのルールはドメインを対象とし、IP-CIDRやGEOIPなどはアドレスの判定に関係します。名前解決結果が変わると、アドレスに依存するルールの適用結果も変わることがあります。「同じURLなのに異なるポリシーが適用された」ときは、ドメイン、解決されたアドレス、ルールの順序をあわせて確認してください。Configで特定の名前解決やマッピング機能が有効な場合、記録に現れるアドレスもその仕組みを踏まえて解釈する必要があります。アドレスの見た目だけで、リクエストが特定の経路を通ったと断定しないでください。

キャッシュと再現可能な確認

DNSを変更してすぐにページを再読み込みしても、古い結果が使われる場合があります。システム、アプリ、Webページがキャッシュや既存の接続を保持していることがあるためです。まず対象へのリクエストを新たに実行し、新しい問い合わせ記録が表示されるか確認してください。必要に応じて接続を再確立し、対象のアプリも開き直します。キャッシュを消すために複数のスイッチを続けて変更しないでください。問題が一時的に解消しても、名前解決元、接続の再確立、接続先のキャッシュのどれが影響したのか判断できなくなります。

トラブルシューティングの手順は、同じ対象を再試行、名前解決エラーを確認、現在のネットワークと別の利用可能なネットワークを比較、ConfigのDNS項目を確認、名前解決元を一項目だけ変更、接続を再確立して再テスト、の順にできます。各段階の結果を記録してください。内部ドメインだけ使えない場合は、まずローカルの名前解決が必要か確認します。すべてのドメインで失敗する場合は、ネットワークへのログインや認証が完了しているか確認してください。ネットワーク自体がまだ使えない状態では、DNSを変えても有効な比較条件を作れないことが多くあります。

暗号化されたDNSを使う場合は、DNSサービスのアドレス自体をどう解決するか、接続が現在のポリシーを通るか、証明書の検証が成功するかも確認してください。DNSアドレスを複数指定しても、問い合わせが必ず速くなるわけでも、常に同じ結果が返るわけでもありません。現在のネットワークで安定して動作し、経路を説明でき、元に戻せることを基準に設定を選びましょう。動作確認後は必要最小限の変更だけ残し、理由をメモしておくと、次にネットワークを変更するときも適切か判断しやすくなります。

On Demandは、システムが認識できる条件に応じて、接続をオンデマンドで開始する機能です。接続を試みるタイミングに関わるもので、ドメインに最終的にどのポリシーが適用されるかを決める機能でも、アプリを常に前面に表示する機能でもありません。この違いを理解しておくことが大切です。On Demandが動作したように見えても、接続先が開けない場合は、サーバー、DNS、ルールに問題がある可能性があります。手動接続は正常なのにネットワークを切り替えた後に自動接続しない場合は、条件の一致やシステム設定を確認します。

手動接続を基準にしてから条件を追加

まず自動動作を一時的に止め、手動で安定した接続を一度確認することをおすすめします。システムの案内に従ってVPN構成の追加を許可し、現在のサーバーが有効であること、対象へのリクエストが想定したポリシーで利用できることを確認してからOn Demandを有効にします。手動接続と自動接続の両方に問題がある状態では、トリガー段階と接続段階のどちらで失敗しているのか判断しにくくなります。初回設定の画面や利用可能な条件は現在のアプリ画面に従い、古い画面の項目名がすべてのデバイスにあると決めつけないでください。

初期状態は、特にシステムのバックアップを復元したデバイスや、VPN構成がすでにあるデバイスでは、実際の画面で確認してください。アプリを再度開いても、システムに保存されたオンデマンド動作が新規インストール時の状態と同じとは限りません。変更前にOn Demandの有効・無効、既存条件の順序、対象ネットワークを記録します。一時的な切り分けであれば、条件の内容を残したまま関連する自動動作を一時停止してください。あとで職場や家庭のネットワーク設定を復元できなくなるため、構成をすべて削除しないでください。

現在の画面でWi-Fi、モバイルネットワーク、特定のネットワーク名などの条件を選べる場合は、確認しやすい条件を一つ選んで試します。一度に多くの例外を追加しないでください。ネットワーク名は実際の表示に合わせて、綴り、空白、大文字・小文字を確認します。同じ名前のネットワークでも、環境が同じとは限りません。ネットワーク名は条件の入力値であり、そのネットワークの信頼性を証明するものではありません。組織内のリソースを利用する場合は、該当するネットワークの利用ルールに従い、自動条件で必要なアクセス管理を代替しないでください。

自動再接続と手動切断の境界

手動で接続を切っても、On Demandの条件が満たされたままなら、新しいネットワークリクエストをきっかけにシステムが再接続を試みる場合があります。その際は接続スイッチを何度も押すのではなく、On Demandを一時停止する必要があるか確認してください。一時的に切断状態を保つ必要がある場合は、自動接続の条件を明確に停止してからシステムのVPN状態を確認します。テスト後は元の設定に戻し、無効のままにして自動接続が使えなくなったと誤解しないようにしましょう。この動作は、サーバー接続失敗後の再試行とは別に記録してください。

ネットワークの切り替えは、瞬時に完了するものではありません。デバイスはまずWi-Fiから切断し、その後モバイルネットワークに接続して、新しい名前解決や接続を行うことがあります。既存の長時間接続が切れる一方、新しいリクエストは新しい経路を使います。自動接続を確認するときは、切り替え時にアイコンが点滅するかだけでなく、切り替え後にリクエストを再実行できるか確認してください。接続処理に十分な時間を取り、数秒の間にネットワークを何度も切り替えないでください。頻繁な切り替えは変数を増やし、記録に関連づけにくい失敗を多数残す原因になります。

ネットワークごとにテストケースを作成

次の3つの状況をそれぞれ確認してください。現在のネットワークで手動接続する、別のネットワークへ切り替えた後に自動接続する、自動動作を一時停止して手動で切断する、です。毎回、トリガー条件、システムの状態、実際のリクエスト結果を記録します。特定のWi-Fiでのみ失敗する場合は、ログインページを開く必要があるネットワークか確認してください。認証が未完了だと自動接続が認証手順に影響する場合があります。まずネットワークへの接続を完了してから再テストし、プロトコル設定を誤って変更しないようにしましょう。

デバイスが組織の管理下にある場合、システムに別のネットワークポリシーや構成制限が設定されていることがあります。アプリの条件に問題があると判断する前に、システム設定で実際に適用されているVPN構成と管理要件を確認してください。システム構成を何度も削除して試すのは避けましょう。権限、オンデマンド条件、既存設定が同時に削除される場合があります。まず自動動作を一時停止して記録を残し、手動接続を個別に確認します。設定が無効だと確認できた場合にのみ、システムの手順に従って再度許可してください。

日常的な設定は利用スタイルによって異なります。接続するタイミングを明確に管理したい場合は、手動接続のほうが動作を把握しやすくなります。ネットワーク条件に応じて接続したい場合は、On Demandを一項目ずつ有効にしてください。「常に接続」という状態だけを目指して、説明できない条件を重ねないようにしましょう。設定後は画面をロックしてから復帰し、ネットワークを一度切り替え、対象へのリクエストを再実行して、接続の一連の動作が想定どおりか確認します。初回の許可と接続手順を確認するには、クイックスタートガイドで基本の流れを見直してください。

Ping、接続テスト、実際のページ読み込みは、それぞれ異なるものです。テストによってはサーバーアドレスの応答、ポートへの接続、指定経路を通じたテスト先へのアクセスなどを確認します。具体的な内容は現在選択しているテスト方式によって異なります。表示された時間が短くても、対象のWebサイトが必ず速く読み込まれるとは限りません。タイムアウトしただけでサーバーが完全に利用不能だとも断定できません。結果を比較する前に、テストの種類、テスト先、そのときのネットワーク条件を確認し、同じ測定方法を比べていることを確かめてください。

テスト方式と測定範囲

テストが基本的なネットワーク応答だけを確認する場合、アプリケーションプロトコルの認証や、その後のデータ転送までは検証できないことがほとんどです。ポートに接続できても、パスワード、TLS、SNIなどの設定が正しいとは限りません。プロキシ経路全体を通して対象にアクセスするテストは、より多くの段階を確認できますが、テストサイトの状態にも左右されます。まず基本テストでアドレスやポートへの到達性を確認し、次に実際のリクエストで経路全体を検証してください。最初のテストに成功しただけで「すべての設定が正常」と判断しないようにしましょう。

テスト先とタイムアウト設定の初期値は、現在の画面で確認してください。既存のConfigや過去の設定に古い値が残っている場合もあるため、デバイスごとの結果を数値だけで並べて比較することはできません。まずは現在使えている初期設定を基準として残すことをおすすめします。テスト先を変更する必要がある場合は、用途を説明でき、現在の環境からアクセスできるものを選んでください。測定方法の変化をサーバー性能の変化と誤認しないよう、一度に変更するのはテスト先かタイムアウトのどちらか一つにします。

テスト先には、安定して応答し、内容が単純で、確認の目的に合ったものを選びましょう。ログインやリダイレクトが必要な場合、アクセス頻度の制限がある場合、ネットワークによって異なる内容が返る場合は、結果に別の条件が加わります。リスト内の多数のサーバーを短時間に繰り返しテストし、一時的な待ち行列やレート制限を継続的な障害とみなさないでください。現在利用しているサブスクリプションがある場合も、実際に使う少数の項目で比較すれば十分です。リストのすべての行に似た数値が出ることを目指す必要はありません。

タイムアウトを短くすれば精度が上がるわけではない

待ち時間が短すぎると、初回の名前解決、接続の確立、暗号化通信が完了する前にタイムアウトになる場合があります。長すぎると障害の検出に時間がかかります。まず現在の値を保ち、少数回のテストを繰り返して結果が安定するか確認してから、実際の使い方に応じて調整してください。タイムアウトを延ばしても待ち時間が増えるだけで、アドレスの誤りや認証失敗は解決しません。数回の結果に大きな差がある場合は、最小の値をすぐに選ぶのではなく、ネットワークの負荷や切り替え状況を確認してください。

遅延が示すのは主に特定の通信にかかった時間です。実際の使い心地は、スループット、パケット損失、混雑、接続先サーバーの応答にも左右されます。小さなページは開けるのに大きなファイルの転送が中断する場合や、テキストメッセージは使えても音声・動画が不安定な場合は、実際の利用に近い方法で確認する必要があります。同じデバイス、同じネットワーク、近い時間帯、同じテスト先を使って比較し、その後に実際のタスクでも確認してください。異なる時間やテスト方式で得られた数値は、それぞれの状況の記録として扱います。

異常な数値から具体的な設定を確認

サーバーが一つだけ失敗する場合は、そのアドレス、ポート、プロトコルをサービス提供元の情報と照らし合わせます。同じネットワークで複数の項目が同時に失敗する場合は、ネットワークへの接続とテスト先が利用可能か確認してください。基本テストに成功しても実際の接続に失敗する場合は、パスワード、TLS、SNI、システム時刻、証明書の検証を確認します。証明書の検証を無効にしてテストを成功させないでください。セキュリティ上の境界が変わるうえ、元の設定が正しいことの証明にはなりません。サービス提供元が案内する正しいパラメータに修正してください。

テスト前後のデータ通信量とデバイスの状態にも注意してください。大量のテストは追加の接続を発生させ、モバイルネットワークではデータ通信量にも加算されます。バックグラウンドで同期やダウンロードが動作していると、アイドル状態とは異なる結果になる場合があります。記録には「他の通信があったか」も含めてください。比較的安定した環境で数回試し、傾向と失敗パターンを確認しましょう。たまたま得られた最小値を長期的な結論にしたり、テスト結果の順位をサーバー品質の保証として扱ったりしないでください。

関連するトラブルシューティングはサーバーのタイムアウトを確認する手順をご覧ください。数値と実際の使い心地の違いについては、遅延、地域、プロトコルの選び方で解説しています。本章では測定条件を揃え、数値を手がかりとして実際のリクエストで確認することをおすすめします。サーバーパラメータが変わった場合は、新しい基準を取り直してください。以前のテスト結果を使って新しい設定を判断しないでください。

Logは接続時のエラーを特定するのに役立ち、Dataでは関連するデータやリクエスト情報を確認できます。具体的な画面や表示項目は現在のアプリに従ってください。これらの目的は、数値を増やし続けることではなく、発生した問題を対象、ポリシー、エラーの段階と関連づけることです。問題を調べる前に、まず具体的な疑問を一つ決めてから関連する記録を確認しましょう。過去の項目を大量に眺めていると、バックグラウンドアプリのリクエスト失敗を、現在表示中のページの問題と誤認するおそれがあります。

一つのリクエストから時系列を確認

開始前に、デバイスの時刻、ネットワークの種類、Global Routing、現在のConfig、選択中のサーバーを記録します。その後、指定したページを開くなど対象の操作を一度だけ再現し、すぐに同じ時間帯の記録を確認してください。対象ドメインが記録に現れるか、名前解決結果が得られたか、どのルールが適用されたか、どのポリシーを使ったか、最終的なエラーは何かを優先して確認します。複数のドメインに同時にアクセスするアプリもあるため、ページのメインドメインへの接続に成功しても、すべてのリソースが成功したとは限りません。

ログの詳細度、記録の有効・無効、保存方法は、すべてのデバイスで共通の初期値だと考えないでください。日常利用では必要な範囲の記録を残し、問題を調べる場合に限って一時的に詳細度を上げることをおすすめします。詳細な記録はストレージや処理の負荷を増やし、より多くの閲覧情報を含む場合もあります。記録を有効にした後は、スイッチがオンになっただけで診断が完了したと考えず、対象の操作に関連する内容が実際に記録されたか確認してください。

現在の画面で記録を消去できる場合、消去前に障害の前後の情報が必要か判断してください。必要な情報を保存してから、新しい再現用の記録期間を始められます。ログを消去しながら接続を繰り返すと、最初に発生したエラーが後続の再試行に埋もれるおそれがあります。断続的に発生する問題では、エラー一行だけを切り取るより、ネットワーク切り替えの前後を含む少量の記録を残すほうが役立つ場合があります。単独のエラーは、それ以前の失敗から連鎖して発生したものかもしれません。

段階ごとにエラーを読み解く

名前解決エラーではまずDNSを確認します。接続拒否は対象のポートとサービスの状態を確認します。応答待ちのタイムアウトはネットワーク経路、待ち時間、接続先の応答を調べます。TLSや証明書に関するエラーは、SNI、システム時刻、証明書の条件を確認してください。エラーの段階に関する情報が失われないよう、表示された文言はできるだけ原文のまま記録します。異なる原因から同じ現象が起こることもあります。timeoutと表示されたからといってDNS、ポート、ルールを同時に変更すると、次の記録を比較できなくなります。

ルールを診断するときは、「適用される想定だったルール」と「実際に適用されたルール」を区別します。たとえば、あるドメインにDIRECTを適用する想定なのに、記録でFINALに一致している場合、ルールの対象が合っていない、順序が正しくない、実際のリクエストが別のサブドメインを使っているなどの原因が考えられます。推測したドメインのルールを追加する前に、実際の接続先を使って照合してください。上から順に適用される仕組みや最終ルールの位置については、カスタムルールの優先順位を参照し、現在のConfigで確認しましょう。

通信量の数値と記録の範囲

Dataの通信量は、集計対象と期間を踏まえて解釈してください。アプリに記録される通信量がサービス提供元の請求内容と完全に一致するとは限りません。プロトコルのオーバーヘッド、課金方法、再送、統計のリセットによって差が生じる場合があります。累計値をそのまま当月の残り容量とみなさないでください。利用量を確認する場合はサービス提供元の課金説明を参照し、デバイスの集計がいつから始まったか記録します。数値を何度もリセットして請求状況を推測しないでください。

リクエスト記録で確認できる範囲にも限りがあります。アプリのキャッシュ、既存の長時間接続、システムの動作、記録の詳細度によって表示内容は変わります。記録が見当たらないからといって、リクエストがなかったと断定することはできません。接続の記録があっても、実際の通信が成功したとは限りません。クライアントの記録と対象アプリの結果を並べて確認し、必要に応じて新しい接続を確立してから再度調べてください。暗号化通信では、記録から確認できる情報がアプリの内容全体を示すわけではありません。

トラブルシューティングが終わったら、一時的に上げたログの詳細度を元に戻し、機密情報を含むコピーは必要に応じて削除してください。発生したエラー、変更した項目、再テストの方法、元の値に戻したかどうかを短く記録しておきます。整理していない大量のログを長期間保存したり、Config全体とすべてのアクセス記録を一緒に送信したりしないでください。再利用できるメモには、秘密情報ではなく操作と結果を残します。次に似た問題が起きたとき、以前の認証情報を公開せずに手順を再現できます。

Widgetは、システムが提供する場所から状態を確認したり操作画面へ移動したりするためのショートカットであり、独立した接続サービスではありません。アプリの設定、システムの許可、システムが割り当てる更新タイミングに依存します。使用前にShadowrocketで手動接続を一度完了させてから、Widgetを追加または設定してください。初回の許可が済んでいない場合、ショートカットから操作しても、アプリやシステムの案内に戻って確認が必要なことがあります。これはサーバーパラメータが有効かどうかとは別の問題です。

本体の設定後にショートカットを追加

まず、表示または操作したい内容を決めましょう。現在の状態を確認したいのか、接続を操作するためにアプリをすぐ開きたいのかを明確にします。システムで利用できるWidgetのサイズ、配置場所、操作方法はデバイスの環境によって異なる場合があるため、実際の追加画面を確認してください。本ガイドでは特定のサイズ、ボタン、レイアウトがすべてのデバイスで使えるとは説明しません。現在のシステムに項目が表示されない場合は、サーバーパラメータを何度も変更するのではなく、アプリとシステムが対応しているか確認してください。

Widgetの初期表示を接続のデフォルト状態とみなすことはできません。追加時にキャッシュされた情報、未読み込みの内容、前回のセッション情報が表示される場合があります。追加後はメインアプリを一度開いて、現在のサーバーと接続状態を確認してからWidgetに戻ってください。表示内容を選べる場合は、まず最もシンプルなレイアウトで比較します。複雑な表示の一項目が更新されないからといって、接続全体が無効になったとは限りません。サーバーを自動的に切り替える唯一の根拠にもしないでください。

デバイスのホーム画面を整理するときは、周囲の人に直接見える情報も考慮してください。サーバーのメモに用途、組織、個人を特定できる情報が含まれていると、パスワードがなくても利用状況がわかる場合があります。機密情報を含まないメモを使い、デバイスの共有状況やロック画面での表示を考慮して配置してください。Widgetの利便性と情報の見えやすさは、あわせて検討する必要があります。ロック画面でのアクセスや表示は、他のデバイスのスクリーンショットから推測せず、システムで実際に設定できる項目を確認してください。

表示の更新と接続状態を別々に確認

Widgetの更新タイミングはシステムによって管理されるため、メインアプリの状態より表示が遅れることがあります。表示が一致しない場合は、まずShadowrocketを開いて現在の接続を確認し、次にシステムのVPN状態を確認してから、実際のリクエストを実行します。同期を強制しようとWidgetを連続してタップしないでください。短時間に繰り返し操作すると、接続と切断が交互に起きて、別の問題を引き起こすおそれがあります。文字表示の更新が遅れているだけなら表示の問題として扱い、すぐにConfig全体を作り直さないでください。

ショートカットを操作した後は、接続処理が終わるまで待ってから結果を判断してください。サーバー認証、名前解決、トンネルの確立には時間がかかります。Widgetを一度タップしただけで対象サイトが利用可能になったとは限りません。アプリに移動した場合は、まずシステムの許可やエラー表示を確認し、次に関連するLogを確認します。対象を一つ決めて検証し、ショートカットが想定した操作を実行したことを確認してください。アイコンの見た目の変化だけで通信全体をテストしたと判断しないでください。表示から得られる状態情報には限りがあります。

On Demandとの組み合わせ

On Demandが有効な場合、Widgetから手動で切断しても、その後ずっと切断状態になるとは限りません。トリガー条件が満たされていると、システムが再接続を試みることがあります。一時的に自動接続を止める必要がある場合は、ショートカットを操作する前にOn Demandの条件を確認してください。Widgetで何度も切断すると、ボタンが機能していないと誤解する場合があります。「タップした操作が実行されたか」と「その後に自動接続が起きたか」を別々に記録し、一つの結果にまとめないでください。

サーバーの変更、Configの編集、バックアップの復元後は、Widgetに表示される情報も確認し直してください。古いメモや状態が一時的に残っていても、実際のリクエストが以前のサーバーを使っているとは限りません。メインアプリを開いて選択中の項目を確認し、新しいリクエストを実行して記録から経路を確認します。メインアプリでの操作は正常なのにWidgetが長時間更新されない場合は、システムの手順に従ってWidgetだけを削除して再追加できます。この操作は表示に関するものであり、アプリ内のConfigも同時に削除する必要はありません。

Widgetはアプリを開く手間を減らす補助として使い、重要な変更はメインアプリで行うことをおすすめします。サブスクリプションの更新、ルール編集、プロトコルパラメータの調整では、画面全体と必要な案内を確認してください。トラブルシューティングが終わったら、自分に合った表示に戻し、わかりやすいメモを設定し、システムのプライバシー設定が利用状況に適しているか確認します。ショートカットの便利さを活用しながら、更新が遅れることのある小さな表示領域だけに、完全な診断や状態の証明を任せないようにしましょう。

iCloud関連の機能は、対応する範囲内でアプリのデータを保存または同期します。ただし「iCloudを有効にした」だけで、すべてのサーバー、Config、履歴、システムの許可が完全に同期されたとは限りません。実際の同期範囲は、現在の画面と復元結果を見て確認してください。購入履歴、アプリデータの同期、システムのVPN構成はそれぞれ別のものです。App Storeから購入済みアプリを再入手できても、接続情報が復元されたとは限りません。データが表示されても、システムの許可を省略できるわけではありません。

同期前に範囲と元のコピーを確認

同期を始める前に、デバイスで使用中のiCloudアカウント、システムでアプリのiCloud利用が許可されているか、クラウドの空き容量、ネットワークの状態を確認します。App Storeの購入に使うアカウントと、iCloudデータに使うアカウントを混同しないでください。用途が異なります。アプリを正常に入手できても、同期に使うアカウントが同じだとは限りません。まず機密情報を含まない、見分けやすいConfigのメモを使って同期経路を確かめてから、大切なデータを扱ってください。確認していない完全な復元に最初から依存しないようにしましょう。

同期スイッチの初期状態や同期対象はデバイスごとに異なるため、本ページでは一律に有効または無効とはしません。同期を有効にする前に、自分で管理できるConfigのバックアップを保存し、そのコピーを実際に読み取れることを確認してください。バックアップにサーバーの認証情報が含まれる場合があるため、保存先とアクセス権には注意が必要です。デバイス内に保存されたファイルがすべて安全なバックアップとは限りません。編集中のファイルとバックアップが実際には同じものなら、誤って変更しても独立した復元元として使えません。

主に編集するデバイスを決めておくことをおすすめします。複数のデバイスで同じConfigを同時に変更すると、内容の差異、同期の遅延、競合が起こる場合があります。実際の結果は同期の仕組みによって異なります。最後にアプリを開いたデバイスが必ず正しいバージョンになるとは限りません。一台で変更したら、もう一台に内容が反映されるまで待ち、重要なルールを個別に確認してください。ファイル名が同じなのは名前が一致していることを示すだけで、ルール、サーバー参照、変更内容がすべて同一とは限りません。

機種変更後は段階ごとに復元

復元は4段階に分けて確認できます。まずApp Storeから購入済みアプリを入手し、アプリのデータが表示されるか確認し、現在のサーバーとConfigを確認してから、最後にシステムの案内に従って接続を許可します。各段階を個別に検証してください。データが同期されても接続できない場合は、クラウドのデータをすぐ消去してやり直すのではなく、まずパラメータと権限を確認します。購入済みアプリの再入手と互換性については、機種変更・再インストールの案内をご覧ください。システム要件はApp Storeのページをご確認ください。

サブスクリプションを復元した場合も、更新が成功したか、サーバーのメモとパラメータがサービス提供元の最新情報と一致するか確認してください。同期されたリストが古い一方で、サブスクリプションの内容がすでに変更されていることがあります。サブスクリプションリンクはサービス提供元から入手し、認証情報として保護してください。公開メモ、スクリーンショット、共有ドキュメントに貼り付けないでください。特定のサーバーだけにパラメータが不足している場合は、その項目の入手元を確認します。プロトコル情報を直すためにiCloudのオン・オフを繰り返さないでください。

同期内容が一致しないときの確認手順

2台のデバイスで内容が異なる場合は、まずアカウント、アプリのiCloud利用許可、ネットワーク、空き容量を確認し、同じ対象を比較しているか確かめます。同期に十分な時間を置いてからアプリを再度開き、エラーや競合の案内があるか確認してください。両方のデバイスで同時に何度も編集、削除、同名ファイルの再作成をしないでください。違いの原因を特定しにくくなります。まず編集を停止し、両方の内容を個別に保存してから、残すバージョンを決めます。判断にはファイル名ではなく実際の内容を使いましょう。

オフラインだったデバイスが再接続すると、古い内容が再び同期に加わる可能性にも注意してください。重要なConfigを復元する前に、どのデバイスに古いコピーが残っているか把握し、それらがネットワークに接続した後の結果も確認します。現在の画面で削除範囲が明示されていない限り、一方のデバイスで削除すれば「そのデバイスだけの整理」になると決めつけないでください。機密データを削除する場合は、ローカルファイルの削除とクラウド上のコピーの処理を分けて確認します。一つの画面を消しただけですべてのコピーが消えたと思い込まないようにしましょう。

日常利用では「使いやすさのための同期」と「復元しやすさのための独立したバックアップ」を組み合わせる方法がおすすめです。バックアップには必要なConfigと復元手順を残し、不要な過去のログは含めず、新しいデバイスで再確認が必要な権限を記録します。復元のテストは途中で中断できる時間に行い、成功を確認してから一時コピーを整理してください。iPadでのレイアウトや設定移行についてはiPadで使う際のポイントもご覧ください。どのデバイスでも、最終的には実際の復元結果を確認してください。

Proxyポートについて確認する際は、リモートサーバーのポートとローカルのプロキシ待ち受けポートを区別してください。Add Serverに入力するポートは、サービス提供元のリモートサービスへ接続するためのものです。ローカルの待ち受けポートは、対応するプロキシ方式の接続を受け付けます。別の項目なので、「同じ数値に揃える」必要はありません。ローカルポートを変更しても、リモートサービスが待ち受けるポートは変わりません。リモートポートを変更しても、デバイス上のポート競合は解消されません。

ポートとプロトコルを対応させる

HTTPとSOCKS5は異なるプロキシ通信方式です。リクエストを送信する側と受信側で対応する方式を一致させる必要があります。数値を一つ入力するだけでは正しい接続を確立できません。アドレス、プロトコル、必要な認証情報も正しく設定してください。機能の利用可否、LANからのアクセス許可、項目名は現在のSettings画面で確認します。画面に特定の待ち受け機能がない場合、他のアプリの使い方からShadowrocketにも同じ項目があると推測しないでください。

ローカルポートの初期値は現在の画面で確認し、よく使われる数値をアプリの固定デフォルトだとみなさないでください。接続先からの要求がなければ、現在の値を維持することをおすすめします。必要な場合に限り、使用中ではない有効なポートを選び、リクエストを送る側にも同じ値を設定します。変更後は設定が保存されたことだけでなく、実際に待ち受けが開始されたか確認してください。ポートが使用中と表示された場合は、既存の用途を特定してから別のポートを使い、繰り返し再起動して競合を隠さないでください。

ループバックアドレスとLANアドレスも異なります。デバイス上のループバックアドレスが指すのはそのデバイス自身であり、別のデバイスから自分のループバックアドレスを使ってアクセスすることはできません。LANからのアクセスには、ネットワーク上での到達性、正しいデバイスアドレス、明示的に許可された待ち受け範囲が必要です。デバイスのアドレスはネットワークの切り替えで変わることがあります。一度使えた設定が、別のネットワークでも有効とは限りません。古いアドレスをそのまま使わず、まず両方のデバイスが相互に通信できるネットワークに接続していることを確認してからポートをテストしてください。

待ち受け範囲はアクセス境界の一つ

現在の機能でLANへの公開が可能な場合は、通常のパフォーマンス設定ではなく、新たなアクセス経路として扱ってください。明確に必要な場合だけ有効にし、利用できる認証とアクセス制限を確認することをおすすめします。公共のネットワークで待ち受け範囲をむやみに広げないでください。使用後は一時的な入口を閉じます。他のデバイスからアクセスできるかどうかは、ネットワーク分離やシステムの動作にも左右されます。一度のテストに失敗したからといって入口が公開されていないとは限らないため、設定範囲自体からリスクを確認してください。

テストでは、まずデバイス上の接続が正常であることを確認し、次にリクエスト送信側から待ち受けアドレスへ到達できるか確認します。その後、プロキシ方式と認証を確認し、最後に対象のリクエストが記録に現れるか確認してください。デバイス上のアクセスがすでに失敗している場合、待ち受けポートを調整しても通常は解決しません。デバイス上では正常なのにリクエスト送信側の記録がまったくない場合は、アドレス、ポート、ネットワーク分離を優先して確認します。リクエストが記録されているのにエラーが返る場合は、Logを見て認証、名前解決、ルール、リモート接続の問題を切り分け、順序立てて確認しましょう。

変更点を最小限に記録して完了

本ページの設定を変更したら、対象へのリクエストを新たに実行し、実際に適用されたポリシーを確認し、新しいエラーがないか調べてから、他のよく使うタスクにも影響がないことを確認します。ポートや待ち受け範囲を変更した場合は、一時的なアクセス経路が予定どおり閉じられていることも確認してください。「問題が解決した」という結論だけでなく、変更前後の値と検証条件も記録します。ネットワーク環境が変わったときに設定を戻すべきか判断できるようにし、新たな例外を重ねないでください。

以下は個人のトラブルシューティングメモに使える形式で、インポート可能なConfigではありません。パスワード、サブスクリプションリンク、鍵を記録する必要はありません。WireGuardなどのプロトコル項目の意味については、WireGuardのパラメータ解説をご覧ください。設定がサーバープロトコル、トンネルアドレス、ローカル待ち受けのどれに属するか確認してから該当するレイヤーを変更します。名前が似ていても役割が異なる設定を、同じテストで混同しないようにしてください。

確認対象：example.com
ネットワーク条件：現在のWi-Fi
Global Routing：Config
変更範囲：設定項目を一つ
変更前の値：デバイスに保存
確認方法：新しいリクエストを実行してLogを確認
復元方法：今回の変更を戻して再テスト

問題を特定できない場合は、最小限の基準に戻ってください。有効なサーバー、明確なConfig、利用可能なネットワーク、必要なシステムの許可、最小限のカスタム設定を用意します。その後、すべてのデータをリセットするのではなく、DNS、接続、ルール、アプリの通信の順に条件を一つずつ追加します。購入については価格と買い切り購入の案内を、初回接続についてはクイックスタートガイドをご覧ください。本ページでは設定と確認方法を説明します。接続サービスは提供せず、サーバーの状態やパラメータについてサービス提供元が行う確認に代わるものでもありません。