Shadowrocket
設定ガイド

まず設定項目の階層を確認

1回のアクセスには、複数の設定階層が影響する場合があります。システムのネットワーク設定は、Wi-Fiとモバイル通信のどちらを使うか、VPN接続が許可されているかを決めます。ShadowrocketのSettingsはアプリの動作の一部を管理し、現在有効なConfigはルールや設定値を提供します。Homeで選択したサーバーも、実際の接続情報を左右します。そのため、Settingsに表示されている値だけでは、すべてのリクエストに適用される設定を判断できません。トラブル対処を始める前に、ネットワーク、サーバー、Global Routingの状態、使用中のConfigを記録してください。無効なファイルの設定を調べてしまうのを防げます。

Settingsを開く前に、解決したい問題を明確にしましょう。たとえば「ドメインにアクセスできない」場合は名前解決とルーティング、「ネットワーク切り替え後に自動接続したい」場合はOn Demand、「デバイス間でリストが異なる」場合は同期を確認します。ネットワークに関係しそうな項目を見つけても、複数のスイッチを続けて有効にしないでください。設定の表示場所や利用できる範囲は、アプリやシステム環境によって異なることがあります。このページでは項目を見つける手がかりとして英語名を記載しています。現在の画面に該当する項目がない場合は、名前が似ていても意味の異なるスイッチで代用しないでください。

初期値と推奨値を記録する方法

このガイドでは、特定のデバイスで現在設定されている値を、すべてのユーザーに共通する初期値とは扱いません。新規作成したConfig、インポートしたファイル、アプリデータの復元後では、設定の開始状態が異なる場合があります。初期値を確認するときは、「アプリの初期設定」「現在のConfigに明示された値」「明示されていない場合の継承動作」を区別してください。初期状態を見るために、既存データを消去するのは避けましょう。既存情報を失う可能性があるうえ、インポートしたファイルに含まれていた元の設定も確認できなくなります。まず現在の状態を記録し、各項目の説明をもとに調整が必要か判断する方法が安全です。

推奨値は用途によって異なります。安定して使用できているデバイスでは、現在の設定を維持するのがおすすめです。一時的な診断では、変数を減らします。特定の名前解決、自動接続、ローカルプロキシへのアクセスが必要な場合に限り、該当する設定を行ってください。記録には数値だけでなく、設定画面、Config名、変更理由、検証結果も残しましょう。入力欄が空でも、必ずしも無効という意味ではありません。継承や自動選択を示す場合もあります。画面の説明またはConfigの仕様で意味が明確な場合に限り、空欄が特定の動作を表すと判断してください。

変更は1項目ずつ検証して完了させる

変更前に、同じWebページを開いて再読み込みするなど、繰り返し実行できる検証方法を1つ決めます。変更後は同じネットワーク、同じサーバー、同じ対象で再度試してください。既存の接続が影響している可能性を除くため、必要に応じて接続を切断し、つなぎ直します。改善が見られない場合は、記録しておいた値に戻してください。別の変更を重ねるのは避けましょう。ネットワークの切り替え、サーバーの切り替え、ルールの変更は分けて試してください。変更を同時に行うと、アクセスが回復してもどの設定が効果をもたらしたのか判断できません。

初回接続時にシステムの「VPN構成を追加」画面が表示された場合は、アプリが該当するネットワーク構成を作成するためのシステム許可と考えてください。サブスクリプションのインポート手順ではありません。許可されていない状態とサーバー設定の誤りは、別の問題です。システムの項目を削除した場合は、通常の接続手順に戻って許可をやり直してください。DNSやルールの変更で補おうとしないでください。画面表示についてはVPN構成の確認画面についてをご覧ください。購入履歴に関する問題は、正規購入の確認ページでご確認ください。

DNS設定で変わること

DNSはドメイン名を接続先のアドレスに変換しますが、プロキシ接続そのものとは異なります。サーバーへの接続に失敗して名前解決の前にアクセスが中断する場合もあれば、名前解決が成功した後、接続先との通信で失敗する場合もあります。そのため、「Webページが開かない」というだけでDNSが原因とは判断できません。まず、すべてのドメインで失敗するのか、特定のドメインだけか、特定のネットワークでのみ失敗するのか、影響範囲を確認してください。既存の接続やキャッシュが問題を見えにくくし、同じ設定でも成功したり失敗したりすることがあります。新しいアクセスの記録で現象を確認しましょう。

Config内のdns-serverは、関連するDNSの参照先を指定します。例のsystemは、システムが提供するDNSを使う設定例で、基本的な比較に利用できます。すべてのインポート済みConfigの初期値を示すものではなく、あらゆるネットワークに適しているとは限りません。システムのDNS参照先は、Wi-Fi、モバイル通信、ネットワーク設定によって変わることがあります。すでにお持ちのConfigで専用のDNS動作が明示されている場合は、先に元の説明を読み、リクエストがDNSサーバーに到達する経路を理解してから変更するか判断してください。

[General]
dns-server = system

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

設定値と検証方法の選び方

特別な要件がなく、現在問題なく動作しているConfigでは、既存のDNS設定を維持してください。診断が必要な場合は、コピー上でシステムのDNSを比較対象として使用し、ほかの設定は変えずに検証できます。暗号化DNSを使用する場合は、そのDNSサービス自体のドメインがどう名前解決されるか、接続経路に到達できるか、証明書の検証に問題がないかも確認してください。入力欄にアドレスを設定しただけで、DNSリクエストが想定どおりの経路を通るとは限りません。また、DNSサーバーに接続できても、返されたすべてのアドレスに現在の出口からアクセスできるとは限りません。

DNSの適否を、参照先の地理的位置や名称だけで判断しないでください。確認すべきなのは、現在のネットワークから接続できるか、問い合わせに適切な応答があるか、応答されたアドレスがその後のルーティングに適しているかです。解析元に応じて異なるアドレスを返すサイトもあります。DNSの変更後にアクセス結果が変わっても、どちらかが必ず誤っているとは限りません。「どのアドレスが返されたか」と「そのアドレスにクライアントがどう接続するか」を分けて確認し、必要に応じてLogで同じ対象の記録を調べてください。

IPv6、キャッシュ、ネットワークの切り替え

ドメインにはIPv4とIPv6の両方のアドレスが設定されている場合があります。経路がどちらか一方のアドレスにしか対応していないと、一部のサイトが遅い、初回表示に時間がかかる、ネットワークを切り替えると復旧するといった症状が現れることがあります。この場合、すべてのルールを最初に削除・変更するのは避けてください。ローカルネットワークが実際に対応するアドレス種別、使用中のサーバーとプロトコルで到達可能な条件を確認してから、Logに記録された接続先アドレスの種類を調べます。画面にアドレスファミリーの設定がある場合は、元の値を記録してから個別に検証してください。特定のアドレスファミリーを無効にする設定を、すべてのデバイスに共通する恒久対策と考えないでください。

DNSを変更しても、実行中のアプリが既存の接続を再利用することがあります。システム、アプリ、接続先サービスがそれぞれ結果をキャッシュする場合もあります。そのため、設定を保存してすぐに一度再読み込みするだけでは、新しい設定が反映されたか十分に確認できません。Shadowrocketを一度切断してから再接続し、対象に新たにアクセスして、Logで新しいリクエストを確認してください。キャッシュへの対処としてアプリデータを何度も消去しないでください。別の要因が加わります。比較するときはWi-Fiとモバイル通信も同時に切り替えないでください。DNSの参照先とネットワーク経路の両方が変わってしまいます。

特定のドメインだけで問題が起きる場合は、スペル、該当ルール、適用されたポリシーを確認してください。すべてのドメインで失敗する場合は、DNSサーバーに到達できるかを調べます。名前解決に成功しても接続できない場合は、サーバー、接続先ポート、ルーティングを確認してください。他の人に状況を説明するときは、情報を伏せたドメイン名、テスト時刻、ネットワークの種類、エラーが発生した段階を伝えれば十分です。サブスクリプション全体やアクセス認証情報は公開しないでください。段階別の詳しい手順は接続中なのにアクセスできないときの4段階チェックをご覧ください。

まず状態を確認し、次にルールを見る

Global Routingは、現在のルーティング動作をどう解釈するかに関わります。Configは有効な設定内のルールに従ってリクエストを処理します。Proxyは通信をプロキシ経由にし、Directは直結させるために使います。これらの状態は診断時の比較に役立ちますが、名前だけですべてのシステム通信の動作を判断することはできません。システムで除外される経路、Config内のバイパス動作、接続処理の対象外となる通信も考慮する必要があります。ルールを確認する前に、現在Configが選択されていることを確認してください。Config以外の状態では、ルールを編集しても想定した変化が見られないことがあり、ルールの構文が無効だとは限りません。

Settingsのアプリ単位のオプションとConfig内の設定は、別々に接続動作へ影響する場合があります。一方に表示された値だけで、有効な設定全体を判断しないでください。ファイルをインポートした後は、どのファイルが現在有効かを確認し、[General]と[Rule]を調べます。リスト内の別のファイルを編集しても、現在のConfigが自動で置き換わるわけではありません。想定と異なる動作が起きた場合は、ファイル全体を再インポートするより、まず有効なファイル名と実際に適用されたルールを記録し、各設定の意味を確認する方が、動作中の状態を保ちやすくなります。

Generalの設定とルールの順序

bypass-systemはシステム通信のバイパス動作に関係します。skip-proxyには、プロキシ処理を経由させないアドレス範囲を指定します。以下のプライベートアドレス範囲の例は構文を理解するためのものです。既存のリストを確認せずに置き換えないでください。利用するネットワークにほかのアドレス範囲があったり、特定のアクセス要件があったりする場合があります。DNS、バイパスリスト、ルールは異なる階層の条件です。あるドメインにPROXYを設定したからといって、関連するすべての通信がほかの条件を無視するとは限りません。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system

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

ルールは通常、上から順に照合されます。先に一致した条件によって、以降の判定が変わることがあります。例では、まずexample.comとそのサブドメインを処理し、次に指定したアドレス範囲を処理して、最後にFINALで残りを処理します。DOMAINは完全一致するドメインに、DOMAIN-SUFFIXはドメインのサフィックスに使用します。DOMAIN-KEYWORDはより広く一致するため、意図しない対象に適用されないよう注意してください。IP-CIDRとIP-CIDR6はアドレス範囲を対象とするため、ドメイン名をそのままアドレスルールに指定しないでください。

変更が有効かを確認する方法

最初から長いルールリストをインポートするのではなく、最小限のルールで比較するのがおすすめです。指定したサイトだけをプロキシ経由にする場合は、上記のDOMAIN-SUFFIXとFINAL,DIRECTを使用できます。ほかのフォールバック動作が必要であれば、目的に合わせて調整してください。ポリシー名は現在のConfig内で有効なものを使う必要があります。定義されていない名前を任意に入力しないでください。変更後は、Configが保存されて有効になっていることを確認し、新しいリクエストを発生させて適用されたルールを調べます。先にある別のルールに一致した場合は、同じドメインを重ねて追加するのではなく、ルールの順序を修正してください。

ルールの判定は、リクエストから識別できる情報にも左右されます。接続先アドレスしか利用できない場合、ドメインベースのルールが想定どおりに再現されないことがあります。同じWebページが複数のドメインにアクセスする場合もあり、ページ本体は表示されても画像が読み込まれないときは、関連する接続を個別に確認する必要があります。1回のページ読み込みだけで、すべてのルールが正しいと判断しないでください。対象のドメインを1つ決め、そのリクエスト、適用されたルール、ポリシーを確認してから、テスト範囲を広げます。一部のサイトだけをプロキシ経由にする場合は、DOMAIN-SUFFIXとFINALの設定方法もご覧ください。

「いつ接続するか」と「どう振り分けるか」を区別する

On Demandは、設定した条件に応じてシステムに接続動作を開始させる機能です。接続をいつ開始または維持するかに関わります。一方、Configのルールは、処理対象となるリクエストにどのポリシーを適用するかを定めます。両者は別の機能です。On Demandを有効にしても、サーバー情報が自動で補われたり、すべてのサイトが特定の経路に変更されたりするわけではありません。すでにお持ちのサーバーに接続できない場合は、まず手動接続で問題を解決してから自動接続を設定してください。先に自動接続を設定すると、システムが繰り返し接続を試み、問題の確認が難しくなります。

On Demandの現在値を確認するときは、アプリ内で有効かどうかだけでなく、システムのVPN構成の状態や関連条件も確認してください。既存の構成、データの復元、以前の設定によって、現在の状態が異なることがあります。そのため、すべてのデバイスでオンまたはオフを初期値とすることはできません。初回接続時やトラブル対処中は、手動で制御できる接続手順を維持するのがおすすめです。手動接続が安定し、対象となるネットワーク条件が明確になってから、実際の要件に合うOn Demandのルールを設定してください。

ネットワーク条件を1つずつ検証

現在の画面にWi-Fi、モバイル通信、ネットワーク識別子などの条件がある場合は、まずそれぞれの適用範囲を確認してください。Wi-Fiのネットワーク名が同じでも環境が同一とは限りません。また、公衆Wi-Fiでは、先にWeb認証が必要な場合があります。見覚えのあるWi-Fi名が表示されているだけで、自動接続が成功すると判断しないでください。設定後は、モバイル通信からWi-Fiへの切り替え、Wi-Fiからモバイル通信への切り替え、一時的な切断からの復帰をそれぞれ試し、システムとアプリの状態が一致するか記録します。

単純な条件から順にテストしましょう。まず明確なネットワーク条件を1つ設定し、想定どおりに接続が開始することを確認してから、例外を追加します。条件が複数ある場合は、現在の画面で順序、照合、動作の説明を確認してください。リストの表示位置だけから優先順位を推測しないでください。適用範囲が広すぎる条件が、後の例外を無効にすることもあります。1項目追加するたびに、少なくとも接続が開始するはずの状況と、開始しないはずの状況を1つずつ検証してください。スイッチがオンになることだけでなく、条件の境界まで確認できます。

ネットワークが変わると、既存の接続が切断され、再接続することがあります。あるアプリの古い接続が失敗しても、On Demandが動作していないとは限りません。新しい接続は復旧していても、以前のセッションを継続できない場合があります。アクセスを新たに開始し、VPNの状態を確認してください。一方、システムでVPN接続済みと表示されても、選択したサーバーから対象にアクセスできるとは限りません。自動接続の起動、トンネルの確立、対象へのアクセスは連続していても別々の段階です。確認内容をそれぞれ記録し、後の段階の問題を起動条件のせいにしないようにしましょう。

接続の停止と切り戻し

On Demandを有効にすると、手動で接続を切っても条件が満たされ、システムが再接続を開始することがあります。ボタンが機能していないと決めつけないでください。一時的に接続を停止する場合は、まず該当する自動接続条件を一時停止してから、現在の接続を切断します。ほかに有効な自動接続構成が残っていないかも確認してください。具体的な操作場所は、現在のシステムとアプリの表示に従ってください。一時的に切断するために、VPN項目を何度もすべて削除・追加するのは避けましょう。許可、条件、接続の問題が混在してしまいます。

事前にネットワーク認証が必要なWi-Fiでは、自動接続を有効にする前に、ローカルネットワーク自体が利用可能であることを確認してください。そうしないと、名前解決、認証ページ、接続先への通信が同時に待機し、すべてのネットワークで問題が起きているように見える場合があります。トラブル対処では一時的に手動接続へ戻し、ネットワーク認証を済ませてから再度確認できます。これはネットワーク準備段階の切り分けであり、On Demandを恒久的に無効にする指示ではありません。会社や学校で管理されているデバイスでは、管理ポリシーに従ってください。管理上の要件を回避するためにシステム構成をむやみに削除しないでください。

最終的に維持する設定は、たとえば「検証済みのネットワーク条件で接続し、診断時は一時停止する」のように、目的を一文で説明できる状態にしてください。各条件の用途を明確に説明できない場合は、条件を減らすことを優先します。変更のたびに起動結果、選択したサーバー、再許可の要否を記録し、想定と異なる場合は、直前に検証済みの設定に戻してください。自動接続は繰り返しの操作を減らす機能であり、接続品質を保証するものではありません。サーバーの利用可否、サブスクリプションの有効性、現在のConfigは、ご自身で個別に確認してください。よくあるケースについてはよくある質問もご覧ください。

Pingの数値は実際の通信速度ではない

画面上では、Pingは接続テストを指す一般的な名称として使われることがありますが、実際の測定方法は異なる場合があります。すべての結果を同じ往復時間として扱わず、まず現在のテスト方法を確認してください。サーバーアドレスへの応答確認、ポートへの接続、プロキシ経由で指定URLへアクセスするテストでは、検証する段階が異なります。サーバーが応答してもプロトコル認証の成功を示すわけではありません。ポートに接続できても、アプリケーション層の設定、証明書、接続先へのアクセスがすべて正しいとは限りません。

数値が小さいからといって、ダウンロード速度が速いとは限りません。短時間のテストでは、主に接続の確立と応答までの過程を確認します。継続的なデータ転送には、ローカルネットワーク、サーバーの負荷、経路の状態、接続先サイトなども影響します。1回のテストに失敗しても、サーバー全体が利用できないとは限りません。現在の経路がそのテスト方法に対応していない可能性もあります。結果を読む際は、少なくともテスト方法、対象、ネットワークの種類、テスト時刻を記録してください。これらの条件がないままリストの2つの数値だけを比べると、異なる測定対象を同じ品質指標として誤認しやすくなります。

テスト方法とURLの選び方

Settingsの関連テスト項目の値は、実際のデバイスに表示されている内容を確認してください。他のユーザーが共有したスクリーンショットを、共通の初期値とみなさないでください。現在のテスト結果が安定し、実際の利用状況に合っていれば、そのまま維持できます。診断時は問題が発生する段階に合った方法を選んでください。サーバーのポートを確認する場合は接続段階を、プロキシ経由のアクセスを調べる場合は対応するURLテストを使います。選択できる方法は現在の画面に従ってください。表示される数値を小さくするために方法を次々に変えないでください。過去の結果と比較できなくなります。

URLを指定できるテストでは、安定していて、ご自身でアクセス可能と確認したうえで、テストに期待される応答形式に適したURLを選んでください。リダイレクト、ログインページ、証明書の問題、アクセス頻度の制限によってテストが失敗しても、通常のブラウジングでは異なる結果になることがあります。ガイドのexample.comは形式の説明用です。長期利用できる速度測定サービスを保証するものではありません。ログに表示される可能性のあるテスト欄には、アクセス用の秘密情報を含むURLを入力しないでください。後で診断情報を共有したときに情報が漏れるおそれがあります。

比較できるテスト記録を作る

まずサーバーとテスト対象を1つずつ決め、同じネットワーク上で少数回テストを繰り返し、継続して失敗するか、結果が大きく変動するかを確認してください。1回の異常値だけで結論を出す必要はありません。短時間にすべてのサーバーを何度もテストするのも避けてください。テスト機能にタイムアウトのしきい値が表示される場合、それは待機の上限です。ネットワーク品質の目標値ではありません。しきい値を短くすると、遅い応答がより早く失敗と判定されるだけで、実際の接続が速くなるわけではありません。待機時間を延ばしても、アドレス、ポート、プロトコル認証情報の誤りは直りません。

リスト上のテストは正常でもWebページを開けない場合は、ページのリクエストで同じサーバーを使用しているか、Configによって別のポリシーが適用されていないか、読み込みに失敗した別のリソース用ドメインがないかを確認してください。反対にテストが失敗しても実際にはアクセスできる場合は、すぐに設定全体を置き換えるのではなく、テスト対象と方法を調べます。Connectivity Testの結果も、何を測定したのかを踏まえて解釈してください。テストツールは問題がある段階を特定するための手がかりです。実際のアクセス確認に代わるものではなく、1つの成功表示だけで、すべてのアプリが正常に動作すると証明することもできません。

最後にローカルネットワークを比較するときは、Wi-Fiとモバイル通信だけを切り替え、サーバー、プロトコル、DNSは同時に変更しないでください。ローカルネットワークによって結果が変わる場合は、ネットワークの制限とアドレスへの到達条件を確認します。どのネットワークでも結果が同じ場合は、サーバーの設定値と接続先までの経路を引き続き確認してください。テスト後は必要なGlobal Routingの状態に戻し、不要な一括テストを停止します。速度低下を段階的に調べる方法は、速度が遅いときのネットワーク・プロトコル・経路の確認をご覧ください。遅延の数値を帯域幅の測定値と混同しないでください。

役立つLogを取得する方法

Logは記録量が多いほど有用になるわけではありません。特定の操作と対応づけられることが重要です。トラブル対処を始める前に、ネットワーク、サーバー、Global Routing、有効なConfigを記録してください。次に、現在の画面にあるログ機能で必要な記録を有効にして、問題が発生したアクセスを1回行い、直後に該当時刻付近の内容を確認します。記録範囲を選べる場合は、問題を確認できる範囲を指定してください。長時間にわたって蓄積した、さまざまな接続のログには無関係な情報も多く含まれるため、直前の操作に対応するエラーを特定しにくくなります。

ログのスイッチや記録範囲の初期状態は、現在のデバイスの表示で確認してください。普段は必要な範囲の設定を維持し、問題を再現するときだけ一時的に記録範囲を広げ、終了後に元へ戻す方法がおすすめです。詳細ログを常時有効にしても接続品質は向上しません。観察できる情報が増えるだけです。古い記録を消去する場合は、診断に必要な情報が残っているか先に確認してください。関連部分を情報が特定できないようにして保存し、対象期間が明確な新しいテストを行う方が安全です。記録を消去しながら何度も操作を繰り返すのは避けてください。

エラー用語だけで検索せず、リクエストの段階を追う

ログは「対象の識別、ルールの適用、アドレスの名前解決、接続先との接続、プロトコルのやり取り、データ転送」の順に手がかりを探すと読みやすくなります。実際のログには各段階がすべて表示されるとは限らず、順番どおりに並ばない場合もあります。確認できる記録に基づいて判断してください。タイムアウトがある場合は、どの対象への処理がタイムアウトしたかを確認します。DNSサーバー、プロキシサーバー、接続先サイトでは、それぞれ対処方法が異なります。同じエラー用語が表示されたからといって、一律にDNSを変更したり、すべてのサーバー情報を入れ替えたりしないでください。

リクエストにDIRECTが適用された記録がある場合は、まずルールとローカル直結の経路を確認してください。想定したプロキシポリシーが適用されている場合は、サーバーへの接続とプロトコル設定を確認します。認証エラーでは、ご自身がお持ちの情報にあるパスワード、識別子、関連設定を確認してください。証明書エラーでは、接続先の名称、時刻、証明書の条件を確認します。検証を無効にする方法を一般的な対処法として使わないでください。想定したリクエストが記録されていない場合は、ログの範囲、新しい接続が発生したか、そのリクエストが現在の処理対象に含まれるかを確認してください。これだけでアプリが動作していないと判断しないでください。

Dataの数値の見方

Dataは累積値の変化を確認するのに適しており、単一の接続が成功したかを証明するものではありません。アップロード、ダウンロード、累積値を読む前に、現在の表示で何を集計しているか、集計開始時点はいつかを確認してください。サーバー別またはアプリ別に表示できる場合は、それぞれの分類基準を理解して使います。特定のサーバーに過去の通信量が記録されていても、直前の通信で使用されたとは限りません。特定のアプリの数値が増えていなくても、接続の再利用、統計の更新、処理対象の範囲などが関係する場合があります。Logと実際の操作も併せて確認してください。

集計期間、通信量の分類、接続時のオーバーヘッド、対象範囲が異なるため、Dataの統計とシステムの通信量統計が一致しないことがあります。比較する前に、観察する期間をそろえ、異なる時点からの合計値ではなく、操作の前後で増えた量を記録してください。リセット機能がある場合も、変更されるのは該当する統計記録だけで、接続が修復されるわけではありません。基準値を保存せずにリセットすると、判断材料を失います。サーバー別とアプリ別の表示については、Data画面の通信量表示についてをご覧ください。

診断情報を共有する前に個人情報を伏せる

LogやConfigには、サブスクリプションのURL、サーバー情報、認証情報、アクセス先が含まれる場合があります。共有前に1か所のパスワードだけでなく、すべての情報を確認してください。URLのクエリ部分、QRコードの内容、リクエストヘッダー、Configのコメント、スクリーンショットの端にも機密情報が含まれることがあります。通常は、発生時刻、情報を伏せたエラー部分、現在の状態、再現手順を伝えれば十分です。前後の経緯を判断できる情報は残しつつ、問題の存在を示すためにConfig全体を公開する必要はありません。診断後は、一時的に書き出したファイルもご自身の情報管理方法に従って処理してください。

Widgetの表示を確認する

Widgetは状態の確認や操作に使うショートカットです。利用できる表示や動作は、現在のシステムとアプリが提供するものに従います。システムのバックグラウンド更新が制限される場合があるため、Widgetの表示が直近の変更と同時に更新されるとは限りません。古い状態が表示されている場合は、まずShadowrocketのHomeを開いて実際の接続状態と選択中のサーバーを確認し、新しいアクセスを行って確かめてください。Widgetの表示だけで接続が確立したと判断しないでください。更新が遅いからといって、プロトコル、ルール、DNSを変更するのも避けましょう。

Widgetを追加または調整した後は、意図した内容に関連づけられているかを確認してください。次に、アプリ内で状態を変更した場合、システムのWidgetから操作した場合、デバイスのロック解除後の表示をそれぞれテストします。操作にアプリの起動やシステムの確認が必要な場合は、現在の画面に従って完了してください。システムの許可、On Demandの条件、実際のサーバーの利用可否は引き続き適用されます。Widgetから操作しても、これらの手順を省略することはできません。異なる時点の状態が複数の入口に表示され、誤解が生じないよう、用途を説明できるWidgetだけを残すのがおすすめです。

iCloud同期は接続状態の同期ではない

iCloud同期は、同期可能なデータの保存や転送に関する機能です。2台のデバイスが同時に接続することや、システムの許可、現在のネットワーク、一時的な状態まで同一になることを意味しません。同期対象はShadowrocketで現在提供されているオプションを確認してください。リストに項目が表示されたからといって、すべての設定が複製されたとは限りません。同期を確認するときは、サーバーリスト、Config、選択中の項目、アプリ単位の設定をそれぞれ調べてください。特に、移行先デバイスでどのConfigが実際に有効か確認しましょう。

同期スイッチの初期状態は、使用中のデバイスで確認してください。すでにお持ちのデータを複数のデバイスで管理する場合は、システムに使用する個人アカウントでサインインしているか、iCloudが利用可能か、Shadowrocketの同期オプションがどう設定されているかを確認します。複数のデバイスで使う必要がなければ、現在の設定を維持できます。同期を有効にする前に、ローカルのコピーを残しておくのがおすすめです。同期は、一定期間の履歴を保証するバックアップではありません。誤削除、上書き、競合への対応が別のデバイスにも反映される可能性があります。もう一方のデバイスを、常に独立した復元元として扱うことはできません。

同期の遅延や競合への対処

2台のデバイスでリストが一致しない場合は、まずアカウントと同期範囲を確認し、両方のネットワークが正常であることを確かめてから、同期に必要な時間をおいてください。同じConfigを両方のデバイスで同時に編集したり、同期を何度もオフ・オンにして強制更新したりしないでください。状況が分かりにくくなります。今回は一方のデバイスを編集元に決め、その内容を記録してから、もう一方のデバイスに変更が反映されたか確認してください。現在の画面にインポート、書き出し、復元の入口がある場合は、実行前に統合されるのか置き換えられるのかを確認します。

競合に対処するときは、Configの名前だけでは判断できません。同じ名前でも内部のルールが異なる場合があります。主要な設定値、ルールの順序、ご自身で記録した変更内容を確認してください。直接上書きするより、コピーを2つ残して比較した方が元に戻しやすくなります。同期後は移行先のデバイスで、選択中のサーバー、Global Routing、VPNの許可、On Demandを改めて確認し、個別にアクセスを検証してください。元のデバイスで正常に動作していても、移行先の状態まで確認できたことにはなりません。

すでにお持ちのサブスクリプションとローカルのConfigは、別々に考えてください。サブスクリプションの項目が同期されても、その内容が再取得されたとは限りません。リモートのサブスクリプション更新とiCloudデータの同期は別の処理です。項目はあるのにリストの内容が古い場合は、システムの同期を待つだけでなく、該当するサブスクリプションの更新結果を確認してください。サブスクリプションURLにはアクセス認証情報が含まれるため、機密情報として管理してください。2台の内容を比べるために、URL全体を公開の掲示板に投稿しないでください。ここでは、すでにお持ちの情報の管理方法のみを説明しており、サービスの提供や推奨は行っていません。

デバイスの移行時は購入とデータを分けて確認

App Storeでの購入資格、アプリデータの復元、ネットワーク接続の許可は、それぞれ別の項目です。購入済みアプリを再入手できても、ローカルのConfigがすべて復元されるとは限りません。Configが復元されても、新しいデバイスで初回のVPN許可が完了しているとは限りません。デバイスの移行時は、「アプリを入手、データを確認、Configを選択、許可を完了、アクセスを検証」の順に確認してください。購入済みアプリの復元については、購入済みアプリの復元方法をご覧ください。元のデバイスがまだ使える場合は、新しいデバイスが正常に動作すると確認できるまで元のデータを残してください。移行中に、復元可能な唯一のコピーを失うのを防げます。

2種類のポートを混同しない

Add Serverのポートは、すでにお持ちのサーバーへの接続情報の一部であり、リモート側で実際に待ち受けているプロトコルとポートに一致させる必要があります。SettingsにローカルProxyポートがある場合は、本機のプロキシサービスの待ち受け設定であり、対応する用途のクライアントからの接続に使います。ローカルポートを変更してもリモートサーバーの設定は変わらず、リモート側のポートの入力誤りも修正できません。確認時は「どちらからどちらへ接続するか」を明確にしてください。Shadowrocketがサーバーに接続するのか、同じデバイス上のリクエスト元がローカルのプロキシ入口に接続するのかを区別します。

ローカルProxy関連の項目名、利用可能なプロトコル、アクセス範囲は、現在の画面の説明を確認してください。デバイスの状態、既存の設定、機能の状態によって異なるため、このページでは共通の初期ポートを記載しません。ローカルのプロキシ入口を使う明確な必要がなければ、現在の設定を維持してください。通常のVPN接続のために、追加の待ち受けをむやみに有効にする必要はありません。必要な場合は、待ち受けアドレス、ポート、プロトコル、ほかのデバイスからのアクセスを許可するかを記録し、接続する側のプロトコルが入口と一致することを確認してください。

待ち受けアドレスでアクセス可能な範囲が決まる

本機だけに許可する範囲と、ローカルネットワークからのアクセスを許可する範囲は異なります。ループバックアドレスの場合、通常は本機からのみアクセスできます。ネットワークインターフェースまで待ち受け範囲を広げると、同じネットワーク上の別のデバイスから接続を試みられる可能性があります。ポート番号が同じというだけで、両端が通信できるとは限りません。デバイスが通信可能な同じネットワークに接続されているか、ネットワークでクライアント間の通信が制限されていないか、現在のアドレスが変わっていないか、システムとアプリが該当する接続を許可しているかも確認します。アクセス範囲は、現在の機能の説明と実際のテスト結果に基づいて判断してください。

アクセス範囲を広げる前に、本当に必要かを確認し、現在の機能が提供するアクセス制御を使用してください。待ち受け範囲を広げることを、本機から接続できない場合の最初の対処法にしないでください。慣れていないネットワークでは、アクセス範囲を狭め、無関係なデバイスがプロキシ入口を使えないようにしてください。使用しなくなった待ち受けやアクセス設定は停止し、接続する側から古い設定が削除されたことも確認します。アプリの状態が変わっても、接続する側が古いアドレスを参照し続けると、リクエストが失敗し、ネットワーク全体の問題に見えることがあります。

ポートの競合と到達不能を区別する

通常、同じ待ち受けアドレス上の同じポートを、複数のサービスが任意に重複して使用することはできません。画面やLogにバインド失敗が表示された場合は、リモートのプロトコルを続けて変更するのではなく、競合の有無とポート値が入力条件を満たしているかを確認します。サービスが待ち受け中なのに接続側からアクセスできない場合は、アドレス、ネットワーク経路、プロトコルを調べてください。HTTPとSOCKS5では接続方法が異なります。接続側で誤ったプロトコルを指定すると、接続自体は確立してもリクエストが完了しない場合があります。ポートに接続できるだけで、設定が正しいとは判断できません。

ローカルの入口を調べるときは、最小限のアクセス範囲で検証してから、必要に応じて範囲を広げてください。リモートサーバーとGlobal Routingは変えず、ローカルの設定を1項目だけ変更して、接続する側の対応する値も更新します。ポートを変更しても接続する側を更新していない場合、テストの失敗は両端の情報が一致していないためです。新しいポートが使えないことを示すものではありません。記録には、少なくとも待ち受け範囲、両端のポート、接続プロトコル、エラーが起きた段階を含めてください。ネットワークアドレスは情報を伏せて保存できますが、本機とリモート側の役割を区別するための情報は残してください。

変更を元に戻せる状態に整理する

診断を終えたら、記録をもとに項目ごとに後片付けをします。不要なテスト状態を元に戻し、一時的に広げた記録範囲や待ち受けを停止し、On Demandの条件が引き続き必要な状態か確認します。現在有効なConfigを調べ、既知の対象へアクセスして再検証してください。影響するデータを把握し、完全なコピーを保存している場合を除き、「すべての設定をリセット」で個別の切り戻しを代用しないでください。有効な診断の結果は、不確かな項目が減ることであり、説明できないスイッチが増えることではありません。

原因を特定できない場合は、現在のネットワーク、選択中のサーバー、状態、Config名、再現手順、情報を伏せたLogをまとめ、サーバー、名前解決、ルール、システムの許可の順に確認してください。問題が新たに発生した場合は、直近の変更を優先して調べます。設定を変えていないのに突然失敗した場合は、ローカルネットワークと既存サービスの状態を確認してください。操作手順を最初から確認する場合は使い方ガイドに戻ってください。症状から解決方法を探す場合はよくある質問をご覧ください。確認済みの変更を重ねるより、問題を再現できる最小限の状態を保つ方が原因を判断しやすくなります。