Shadowrocket 使い方

Add Serverから追加・読み込み

Shadowrocketを開き、まずHomeに移動します。ここでの目的は、自分のサーバー情報を一覧に表示させることで、すぐに接続スイッチをオンにすることではありません。手元の情報の種類を確認しましょう。サブスクリプションURLからは複数のサーバー項目を取得でき、個別のサーバー情報にはプロトコル、アドレス、ポート、認証情報が含まれます。いずれか一方を選べばよく、同じ情報を重複して追加する必要はありません。

サブスクリプションURLがある場合：Subscribeを使用

Homeの右上にある追加ボタンからAdd Serverを開き、TypeでSubscribeを選択して、自分のサブスクリプションURLをURL欄に入力します。後で見分けやすいように用途がわかる名前を付け、保存してHomeに戻ります。貼り付ける前後にURLが完全か確認してください。末尾のパラメーターが欠けていないか、前後に空白がないか、Webページのタイトルや説明まで一緒にコピーしていないかも確認します。

保存後、サブスクリプションのグループと、その中のサーバー項目を確認します。サブスクリプションはリモートの情報を取得して解析するため、「サブスクリプション名が表示された」ことと「サーバー一覧が作成された」ことは別の状態です。グループだけ表示されて項目がない場合は、そのサブスクリプション項目にある更新操作を実行し、処理が終わってから一覧を確認してください。同じURLを続けて何度も追加するのは避けましょう。グループが重複して見分けにくくなるだけで、URLの無効化や想定外の応答は解決しません。

サブスクリプションURLには個人用のアクセス情報が含まれる場合があるため、機密情報として扱ってください。内容を確認する必要がある場合は、まず契約先にURLが有効か、Shadowrocketに対応しているか、追加の利用条件があるかを確認します。URL全体を公開コメント、スクリーンショットの説明、トラブル対応の記録に貼り付けないでください。問題を記録する際は、エラー表示と発生箇所だけで十分です。

個別のサーバー情報がある場合：Typeとパラメーターを確認

個別のサーバー情報を追加する場合も、Add Serverから始めます。Typeには、情報に指定されたプロトコル（Shadowsocks、VMess、VLESS、Trojanなど）を選択します。画面の項目に従ってアドレス、ポート、認証情報を入力してください。必要な項目はプロトコルごとに異なります。あるプロトコルのパスワード、UUID、通信パラメーターを別のプロトコルのフォームにそのまま入力しないでください。

TLS、Server Nameなどの通信設定は、手元の情報に従って入力してください。サーバーアドレスから推測して設定しないようにしましょう。アドレスはドメイン名の場合もIPアドレスの場合もあります。ポートは独立した項目なので、説明文全体を貼り付けないでください。入力後に保存し、Homeに戻って使用する項目を選びます。ここでは項目が存在し、元の情報と一致していることだけを確認します。アクセスできるかどうかは、後の接続確認でチェックします。

接続スイッチをオン

Homeに戻り、選択中のサーバー、Global Routingのモード、Configを使う場合は有効な設定ファイルを順に確認します。条件が整っていることを確かめてから、メインの接続スイッチをオンにしてください。設定の切り替え中、サブスクリプションの更新中、パラメーターの保存前に接続を何度もオン・オフすると、どの設定でテストしたのか判断しにくくなります。

初回接続時に、システムからVPN構成の追加を求められる場合があります。これはShadowrocketがシステムのネットワーク処理を利用するために必要な許可であり、利用可能な接続サービスが自動的に提供されるという意味ではありません。案内を読んで続行する場合は、システムの指示に従って許可し、デバイスで求められる認証を完了します。その後Shadowrocketに戻り、スイッチとアプリに表示される接続状態を確認してください。

許可をキャンセルした場合は、アプリに戻って接続を再度開始し、表示された案内に従ってください。デバイスが管理対象になっている場合や、システム設定による制限がある場合は、該当する制限を確認します。確認せずに何度もタップしても解決にはなりません。システム設定内のVPN項目名や場所は画面の構成によって異なる場合があるため、デバイスの現在の表示を確認してください。このガイドのために、今回の接続に関係のない設定を変更する必要はありません。

接続が確立すると、システムにVPNの表示が出ることがあります。この表示が示すのはシステム上のネットワーク接続状態であり、実際のアクセスによるサーバー確認が済んだことや、すべてのリクエストがプロキシを経由していることを意味しません。特にConfigやDirectでは、VPN表示だけをルールによる振り分けが正しい証拠にしないでください。設定を維持して次の確認に進み、「スイッチがオンになった」だけで確認を終えないようにしましょう。

接続とルールを確認

確認するのは3点です。サーバーがテストに応答するか、必要なサービスを利用できるか、リクエストが想定したポリシーで処理されるか。それぞれ関連はありますが、互いに置き換えることはできません。以下の順に確認すると、基本ネットワーク、接続先サービス、ルールの問題を混同せずに済みます。

まずConnectivity Testを実行

HomeでConnectivity Testを実行し、選択中のサーバーのテスト結果を確認します。接続経路に到達できるかを判断する手がかりになりますが、テストの接続先や方法は、各アプリが実際に行うリクエストとは異なります。テストに成功してもすべてのWebサイトやアプリが使えるとは限らず、失敗した場合もテスト方法、現在のネットワーク、サーバー情報を合わせて確認する必要があります。

結果は成功、失敗、または表示されたエラーだけ記録すれば十分です。テストにかかった時間だけでサービス品質を判断しないでください。すべての項目で失敗する場合は、デバイスの基本ネットワークでアクセスできることを確認してから、サブスクリプションと接続パラメーターを確認します。特定の項目だけ失敗する場合は、その項目のパラメーターと対応するサーバーの状態を優先して確認してください。

次に実際のアクセスを確認

接続をオンにしたままブラウザを開き、実際に使うサービスへアクセスして、ページの読み込みや必要な操作ができるか確認します。すでに開いているページを見るだけでなく、新しいリクエストを実行してください。ページのキャッシュによって、新しい通信が発生していないのに表示が成功したように見える場合があります。特定のアプリだけで失敗する場合は、そのアプリのログイン状態、権限、サービスの稼働状況も切り分けて確認しましょう。

接続前後を比較する場合は、同じデバイス、同じネットワーク、同じ接続先を使い、一度に変更するのは接続状態かルーティングモードのどちらか一つにします。ネットワークとサーバーを切り替えながらルールも変更すると、比較になりません。アクセスに成功しても、ルールによる振り分けが意図どおりか確認が必要です。ページを開けることはサービスを利用できた証拠ですが、ポリシーが適用されたことを完全に示すものではありません。

最後にDataと適用ポリシーを確認

Dataを開いて現在表示されるリクエスト情報を確認し、接続先、時刻、ポリシーから処理経路を判断します。表示される情報はアプリで現在確認できる記録に従ってください。まず、直前に実行したリクエストを見つけ、Configのルールと照らし合わせます。該当する記録がない場合は、すぐルールを変更せず、リクエストが実際に再送信されたか確認しましょう。

DIRECTになる想定の接続先では、実際に該当するポリシーが使われたか確認します。PROXYになる想定の場合は、現在のサーバーとポリシーの参照先も確認してください。REJECTは一致したリクエストを拒否することを示しますが、アプリ内の似た内容がすべて消えるとは限りません。ルールが通常の機能に影響する場合は、該当するリクエストとマッチした項目を特定してから、変更範囲を最小限にします。設定ファイル全体を削除しないでください。

リクエスト記録にはドメインなどの個人利用情報が含まれる場合があります。トラブル対応の資料を保存する際は、問題の特定に必要な内容だけを残し、共有前に個人用の認証情報や無関係なリクエストを削除してください。3つの観点を確認した後は、実際のサービスを利用でき、ルーティングモードが目的に合い、代表的なリクエストに想定したポリシーが適用されていることが目安です。

よくある問題の切り分け

問題が起きたら、まずエラーが発生した段階を確認し、すべての情報を最初から削除しないでください。以下に操作の順に確認するポイントをまとめています。一度に変更するのは一項目だけにし、変更のたびに再テストしてください。直前に使えていた設定を残しておけば、どの変更が結果に影響したか特定できます。

サブスクリプションを保存したのに一覧が空

サブスクリプション項目に戻り、URLが完全か確認します。ログインが必要な案内ページではなく、サブスクリプションのデータを取得するURLであることも確認してください。次に更新を一度実行し、アプリに表示されたメッセージを記録します。Webページやアクセスエラー、想定外の内容が返されると、一覧が作成されないことがあります。その場合はURLの有効性と返される形式を契約先に確認し、Subscribeを適当なサーバープロトコルに変更しないでください。

更新に失敗した場合と、既存の項目が消えた場合は別の問題です。既存の項目が残っている場合はそのままにして、失敗したタイミングを記録してください。再試行のためにすべての情報をすぐ消すのは避けましょう。サブスクリプションの内容が変わった後は、現在選択中の項目が引き続き使いたいものか確認します。グループ名が変わっていないことだけで判断しないでください。

サーバー項目はあるがテストに失敗

まずデバイスが現在のネットワークに接続できることを確認し、Type、アドレス、ポート、認証情報が手元の元データと一致するか確認します。指定されたTLSや通信パラメーターがある場合は、それらも項目ごとに確認してください。すべてのスイッチを何度も切り替えて試すのは避けましょう。明確だったパラメーターの誤りが、複数の不明要因に変わってしまいます。

ほかの既存項目が使える場合は、比較対象として試します。同じ項目が特定のネットワークでだけ失敗する場合は、ネットワーク環境とエラー表示を記録し、ネットワーク制限や名前解決の違いを確認してください。Connectivity Testの一度の結果は手がかりにすぎません。実際のサービスへのアクセス結果も合わせて判断しましょう。

スイッチはオンだが接続先にアクセスできない

まずシステムの許可が完了していることと、アプリがすぐに切断されていないことを確認します。次にGlobal Routingがテストに必要なモードになっているか確認してください。Directでは、サーバーが選択されていてもリクエストがそのサーバーを経由するとは限りません。Configの場合は、同じ名前のファイルを開いて内容を見るだけでなく、実際に有効になっている設定を確認します。必要に応じて一時的にProxyに切り替えて比較し、テスト後に元の選択に戻してください。

Proxyでは利用できるのにConfigでは利用できない場合は、ルールの順序、ポリシーの参照、接続先に関係する設定を重点的に確認します。どちらも失敗する場合は、サーバー、基本ネットワーク、接続先サービス自体を確認してください。VPN表示があるだけで、これらの要因を除外しないようにしましょう。

更新後に動作が変わった、または切断後も変化が続く

サブスクリプションの更新でサーバー項目が変わり、設定の更新でルールが変わる場合があります。それぞれ別に記録してください。まずどちらを更新したのか確認し、現在の選択が更新前と同じか確認します。手動で切断しても接続が再開する場合は、On Demandの有効状態とトリガー条件を確認してください。ページの表示だけが変わらない場合は、新しいリクエストを実行してキャッシュを確認します。古いページの内容を新しい接続結果と混同しないでください。

続けて問題を調べる場合は、失敗した手順、現在のGlobal Routingモード、特定の接続先だけに影響するか、直前に変更した唯一の項目の4点をまとめれば十分です。サブスクリプションURL全体、パスワード、その他の認証情報は添付しないでください。購入、ストアの国・地域、購入済みアイテムの復元についてはApp Storeでの入手ガイドを、プロトコルやルールキーワードの詳しい説明については用語集を参照してください。初回接続を完了するために、すべての設定を一度に変更する必要はありません。