Shadowrocket 使い方ガイド

Global Routingモードの選択

サーバーのレコードはプロキシ接続で使うパラメーターを決め、Global Routingはリクエストの経路選択を決めます。この2つは個別に確認する必要があります。一覧でサーバーが選択されていても、すべてのリクエストがそのサーバーを経由するとは限りません。Homeに戻り、Global Routingをタップして現在の選択を確認し、今回のテスト目的に応じてConfig、Proxy、Directを選びます。変更後はHomeに戻り、モード名をもう一度確認してください。メニューを開いただけで選択が完了していないことがあります。

Config：現在の設定に従ってリクエストを処理

ルールに応じて通常の通信経路を振り分ける場合はConfigを使います。現在有効な設定を読み込み、ルールの一致順に従って、リクエストをプロキシに送るか、直接接続するか、その他の処理を行うかを決めます。そのため、Configを選ぶ前にConfigを開き、ファイルが一覧に「存在する」ことだけでなく、どの設定が現在使われているかを確認してください。インポートしたばかりのファイルと有効になっているファイルが異なる場合があります。別のファイルを編集しても、現在の接続動作は変わりません。

自分の設定がある場合は、バックアップを取ってから有効にしてください。ウェブ上のルールをむやみに末尾へ追加しないでください。DOMAIN-SUFFIX、GEOIP、FINALなどのルールキーワードは一致範囲が異なります。先にあるルールでリクエストが処理されると、後続のルールには一致しません。このページでは有効化の状態と基本的な経路の確認のみを扱います。構文や用語の詳細は用語ガイドをご覧ください。

ProxyとDirect：経路を明確に比較する方法

Proxyは、選択したプロキシ経路が利用できるか一時的に確認する場合に適しており、通常のルールごとの振り分けには依存しません。ただし、サーバーへの到達性を保証するものではなく、すべてのアプリの動作が同じように機能するとも限りません。Directはリクエストを直接接続の経路に送り、ローカルネットワークの結果と比較する場合に使います。Directを選択した場合、「アプリのスイッチがオンだからリクエストもプロキシを使っている」と考えないでください。

初回の問題確認では、Proxyを使って明確な対象を比較できます。プロキシ経路が使えることを確認したら、Configに戻して振り分けを確認します。一時的な問題確認用のモードを、ルール設定が完了した状態として使い続けないでください。モードを切り替えるたびに同じページをテストして差を記録すると、次に問題が起きた際、サーバー自体が使えないのか、ルールが別の経路を選択したのかを切り分けやすくなります。

スイッチをオンにして接続し、システムの許可を完了

Homeで想定したサーバーが選択され、Global Routingも今回の目的に合っていることを確認したら、Home上部の接続スイッチをオンにします。初回接続時、iPhone / iPadにVPN構成を追加するシステムの確認が表示される場合があります。Shadowrocketからの要求であることを確認して追加を許可し、システムの指示に従ってデバイスのパスコードまたは認証で操作を完了します。システムの許可は接続に必要な権限であり、購入の確認ではありません。また、サーバー情報の不足項目を補うものでもありません。

許可が完了したらShadowrocketに戻り、スイッチがオンのままか確認します。スイッチがすぐにオフになる、接続中のまま変わらない、または権限の確認が再び表示される場合は、何度もタップするのをやめてください。表示内容を確認し、前回のシステム許可が本当に完了したか確認します。前回キャンセルした場合は、もう一度接続を開始して許可を完了してください。用途がわからないままデバイス上の構成を削除しないでください。特に職場や学校で管理されているデバイスでは、まず管理上の制限を確認してください。

接続をテストする間は、システムのVPN接続を使用する可能性がある他のサービスを停止し、Shadowrocketだけを有効にして切り替えによる干渉を減らします。システム設定とアプリで接続状態が同期しない場合は、まずアプリ内で接続をオフにし、状態が戻るのを待ってから再度オンにします。操作の間に状態が切り替わる時間を設けてください。スイッチを素早く何度も切り替えると、失敗箇所が特定しにくくなります。

システムのVPN表示は、該当するネットワーク接続が確立したことを示すだけで、目的のウェブページが想定したルールを通ったことまでは証明しません。デバイスによって状態表示の位置や見え方は異なります。アイコンを探すために何度も再接続する必要はありません。次に、スイッチの色だけで判断せず、アプリのテストと実際のリクエストを照らし合わせてください。

初回確認ではOn Demandを追加で調整しないでください。On Demandは条件に応じて接続を開始する機能であり、サーバーアドレス、認証情報、ルールの誤りを修正するものではありません。まず手動でオン・オフする流れを確認してから、自分のネットワーク利用状況に合わせて自動接続の条件を設定します。そうすれば、後で自動接続に問題が起きても、確認済みの手動操作と直接比較できます。

Connectivity Testと実際のリクエストで確認

接続をオンにしたまま、HomeでConnectivity Testを実行し、選択中のサーバーに基本的な到達性があるかを確認します。テスト結果は明らかな失敗の発見に役立ちますが、テスト方法や対象、実際のアプリのアクセス方法は完全には一致しません。そのため、テストに成功してもすべてのウェブサイトが開くとは限りません。テストに失敗した場合も実際のリクエストと合わせて判断し、結果だけを根拠にサブスクリプション全体を削除しないでください。

続いてブラウザーを開き、普段使っていて、読み込みが完了したか判断しやすいページにアクセスします。キャッシュされた内容を見て接続成功と判断しないよう、ページの本文が表示されるかを確認してから、サイト内のリンクを開くか再読み込みを試します。テスト対象のサイトがメンテナンス中の場合は、利用できるとわかっている別の対象で再テストしてください。出所が不明な検査ページを使ったり、サブスクリプションリンクやサーバーの認証情報を検査サービスに送信したりしないでください。

ルールによる振り分けを確認するには、Configに戻り、現在有効な設定を確認してから新しいリクエストを送ります。アプリで確認できるリクエスト記録を照合し、対象ドメイン、一致したルール、実際の処理経路を確認してください。直接接続する想定のリクエストはDIRECTによる処理と一致し、プロキシを使う想定のリクエストは、現在の設定にあるプロキシ処理と一致する必要があります。ルールがポリシーを参照している場合は、ルール名だけでなく、最終的に選択されるポリシーも確認してください。

「接続をオフにした場合のローカル接続、Proxyでの結果、Configでの結果」を簡単に比較できます。毎回変更する条件は一つにし、同じデバイス、同じネットワーク、同じテスト対象を使います。Proxyは正常でConfigが失敗する場合は、まずルールと設定を確認します。両方とも失敗する場合は、ルールを増やすのではなく、サーバーのパラメーターとネットワークを確認してください。比較が終わったら、普段使うモードに戻します。

最後に接続を一度オフにしてから再度オンにし、動作を確認します。接続をオフにした状態でローカルネットワークが正常であることを確認してから、再接続して実際のアクセスを繰り返してください。最初は正常でもネットワーク切り替え後に失敗する場合は、問題がWi-Fiとモバイル通信のどちらで起きたか記録します。速度や安定性は利用状況に応じて判断してください。Connectivity Testの一度の結果をダウンロード速度に換算したり、長期的な安定性の結論にしたりすることはできません。

複数の項目を同時に変更せず、失敗箇所から確認

トラブルシューティングはアプリの再インストールではなく、ローカルネットワークの確認から始めます。Shadowrocketの接続をオフにして、デバイス自体が正常にインターネットへ接続できるか確認します。Wi-Fiのネットワーク認証が完了していない場合は、先に認証ページで手続きをしてから再接続します。ローカル接続に問題がある場合、サーバーのパスワード、ルール、DNSを変更しても根本原因は解決しないことがほとんどです。モバイル通信の利用が許可されている場合は、比較のために一度ネットワークを切り替えても構いませんが、データ通信量に注意してください。

インポートに失敗する場合：内容と更新結果を確認

Subscribeを保存してもサーバーが表示されない場合は、リンクが途中で切れていないか、空白が混入していないか、サービス側で更新できる状態かを確認します。既存グループの古い項目が表示されていても、今回の更新が成功したとは限りません。更新通知を確認し、内容が想定どおりか確かめてください。リンクからログインページやエラーテキストが返される場合は、まずリンクへのアクセス条件を確認します。サービス提供元へ問い合わせる際は、エラー内容と発生時刻を伝え、公開の場に個人用URL全体を掲載しないでください。

接続に失敗する場合：項目を照合してからネットワークを確認

特定のサーバーだけ失敗する場合は、そのレコードを開き、手元の情報とプロトコル、アドレス、ポート、パスワードなどの認証項目を照合します。TLSを使用する場合は、サーバーが要求する関連名とトランスポートの選択肢も確認してください。すべてのオプションを有効にして試すことは避けてください。同じサブスクリプション内の複数項目が同時に失敗する場合は、異なるローカルネットワークでの結果を比べてから、利用中のサービス提供元への問い合わせを検討します。一度のテスト失敗だけを理由に何度も削除・再追加しないでください。

スイッチがオンでもページを開けない場合：ルールとDNSを切り分ける

まずGlobal RoutingがDirectになっていないことを確認し、ProxyとConfigでの動作を比較します。Configだけ失敗する場合は、正しい設定が有効になっているか、対象が先行するルールで処理されていないか、参照先のポリシーが利用できるかを確認します。ドメインを解決できない場合は、現在のDNS設定とネットワークの状態を確認し、複数のアドレスをむやみに入力しないでください。変更前に元の値を保存し、一度に変更するのは一項目だけにします。元に戻した後、問題が再現するかどうかも、変更の効果を判断する重要な手がかりです。

ブラウザーでは正常でも特定のアプリだけ失敗する場合は、そのアプリのキャッシュ、接続の再利用、サービスの状態、アクセス要件も考慮してください。対象アプリを完全に終了して再度開き、新しいリクエストを送ります。接続全体が失敗したとすぐに判断しないでください。反対に、すべての対象で失敗する場合は、個別アプリの設定を見続けるのではなく、サーバー、システムの許可、ローカルネットワークという基本条件に戻って確認します。

再現に必要な情報を記録してから詳しく調べる

有効なトラブルシューティング記録には、Wi-Fiとモバイル通信のどちらを使ったか、現在のGlobal Routing、インポートと実際のアクセスのどちらで失敗したか、すべてのサーバーで同じか、直近で変更した項目を含めます。記録を共有する前に、サブスクリプションの認証情報、パスワード、個人を特定できる情報を隠してください。エラーメッセージの詳しい説明はよくある質問をご覧ください。複数のサブスクリプションの整理、更新、バックアップについては、サブスクリプションガイドをご覧ください。

この5段階を終えると、現在選択中のサーバー、使用しているモード、システム接続が確立しているか、実際のリクエストが想定どおりかを把握できます。今後、設定を変更したりサブスクリプションを更新したりした場合も、同じ順序で再テストしてください。まず動作確認済みの設定を一つ保存してから、ルールを詳しく調整します。複数の設定を同時に変更するより、安定した状態を基準として維持しやすくなります。