Shadowrocketの使い方

01 · Add Server：サーバーの追加またはサブスクリプションの読み込み

まず、手元の情報が、複数のサーバーを含み更新できるサブスクリプションURLなのか、単一サーバーのアドレス、ポート、認証情報なのかを確認します。アプリへの追加方法は異なるため、サブスクリプションURLをサーバーアドレス欄に入力しないでください。Shadowrocketを開き、Homeに移動して、右上の追加ボタンからAdd Serverを開きます。保存する前にTypeを確認してください。選択したTypeによって、次に表示される項目が変わります。

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

Add ServerのTypeでSubscribeを選び、完全なサブスクリプションURLをURLに入力して、自分で判別しやすい名前を付けます。貼り付けた後、URLの先頭と末尾、クエリパラメータが欠けていないか確認してください。特に、チャットアプリからコピーした際に空白や改行、説明文が混ざっていないか注意します。サブスクリプションURLにはアクセス情報が含まれることが多いため、全体をそのまま保持し、掲示板やスクリーンショットで公開しないでください。

入力後に保存し、アプリがサブスクリプションを取得して解析するまで待ってから、Homeに戻って結果を確認します。サブスクリプションのグループと、その中のサーバーが表示されて初めて、選択可能な接続項目が追加されたことになります。名前を保存しただけでは、内容の取得に成功したとは限りません。グループにサーバーが表示されない場合は、後の接続手順に進まず、サブスクリプションの応答と有効性を確認してください。サブスクリプションの更新は接続情報を再取得する操作であり、サービス提供元側の利用権限や有効期限を延長するものではありません。

単一サーバーの情報がある場合：Typeに合わせて入力

単一サーバーのパラメータを受け取った場合は、Add Serverで該当プロトコルのTypeを選び、アドレス、ポート、認証情報を項目ごとに入力します。プロトコルによって必要な情報は異なります。たとえば、Shadowsocksでは暗号化方式とパスワード、VMessやVLESSではUUID、TrojanではパスワードとTLS関連の設定を確認します。項目名が似ていても互換性があるとは限りません。別のプロトコルの情報を入力しないでください。

提供元の情報に通信方式、パス、Host、SNIが含まれている場合は、記載どおりに入力します。サーバーアドレスとTLS検証に使うホスト名が異なる場合があります。入力欄をそろえるために独自に変更しないでください。また、パラメータの確認を省いて証明書検証を無効にすることも避けてください。保存後、Homeに戻り、新しいサーバーが表示されることを確認してから、使用する項目を選びます。この時点では情報を入力しただけで、接続可能かどうかは確認できていません。

共有リンクやQRコードをお持ちの場合は、対応するクリップボードからの読み込み、またはScan QR Codeを利用できます。読み込み後も、項目を開いてプロトコルとアドレスを確認してください。QRコードの読み取りや各項目の詳しい説明はQRコードの読み取りと読み込みの管理、プロトコルの概要は用語集をご覧ください。使用するサーバーを1つ選択したら、次に通信の処理方法を選びます。

02 · Global Routing：通信の処理方法を選択

HomeでGlobal Routingを開き、用途に応じてConfig、Proxy、Directを選択します。これらはリクエストの処理方法を決める設定であり、プロトコルや速度の段階ではありません。サーバーを選択しても、すべてのリクエストがそのサーバーを経由するとは限りません。選択したモードが意図と異なると、接続スイッチがオンでも、対象のリクエストが別の経路を通ることがあります。

Config：設定ファイルのルールに従って処理

普段からルールによる振り分けを使う場合はConfigを選びます。まずConfigを開き、使用する設定ファイルが選択されていることを確認してから、Global Routingに戻りConfigを選択します。Config画面では設定ファイルを管理し、Global RoutingのConfigは選択中の設定ファイルに従ってリクエストを処理します。サーバーのサブスクリプションを追加しただけでは、ルール設定ファイルの読み込みや有効化は完了しません。

ルールは通常、上から順に照合され、該当したルールによってPROXY、DIRECT、REJECTのいずれかで処理されます。リクエストがDIRECTに一致すれば、接続スイッチがオンでも直接アクセスする場合があります。REJECTに一致したリクエストは拒否されます。最後のルールだけを見て、すべてのリクエストの経路を判断しないでください。ルールの例とキーワードの説明はルールによる振り分けの解説をご覧ください。

Proxy：選択したプロキシ経路の確認に使用

サーバーが動作するか初めて確認する際は、一時的にProxyを選択し、対象となるリクエストをプロキシ経路に通すことで、ルールによる振り分けが結果に与える影響を抑えられます。選択後、Homeで対象のサーバーが選択されていることも確認してください。Proxyにしても、パスワードの誤り、無効なサーバー、通信上の制限は解消されません。変更されるのは通信の処理方法だけであり、サーバーの利用可能性を保証するものではありません。

Direct：直接アクセスに使用

Directは直接アクセスに使うため、プロキシサーバーが有効かどうかの確認には適していません。Directが選択されている状態でページが開けても、その条件下で直接アクセスできたことしかわかりません。ローカルネットワークとプロキシ経路を比較する際の対照として使うことはできますが、毎回選択したモードを記録し、異なる条件での結果を混同しないようにしてください。

選択後、Homeに戻り、現在のGlobal Routingの値をもう一度確認します。以降の接続と動作確認は、この設定を把握したうえで行ってください。問題の切り分けで一時的にProxyを使った場合は、確認後に必要なConfigへ戻し、ルールによる振り分けを再度確認します。

03 · Home：接続を開始してシステムの許可を完了

Homeに戻ったら、先ほど確認したサーバーを選択してから、画面上部の接続スイッチをオンにします。サブスクリプションに名前の似た項目が複数ある場合は、直近に表示された名前だけで判断せず、選択マークの位置を確認してください。サブスクリプションを更新した後も現在の選択を確認し、別のサーバーの結果をテスト対象の結果と取り違えないようにします。

初回接続時、システムにVPN構成の追加を許可する確認画面が表示されることがあります。これはアプリが該当するネットワーク接続を確立するための許可であり、アプリの購入やサブスクリプションの追加とは別の操作です。画面の内容を読み、Shadowrocketが開始した要求であることを確認したうえで、システムの案内に従って許可または認証を完了してください。許可が完了していない場合、アプリに戻ってスイッチがオフになっていても、サーバーパラメータの誤りとは限りません。

許可が完了したらアプリに戻り、接続スイッチがオンのままか確認します。システムのVPN状態とアプリのオン状態から、接続機能が起動したことは確認できますが、対象サービスへのアクセスが成功したことまではわかりません。サーバー認証の失敗、DNSの名前解決エラー、ルールの不一致は、スイッチがオンになった後にも起こり得ます。次の手順で実際のアクセスを確認してください。

スイッチがすぐにオフに戻る場合は、システムの許可が完了しているか、デバイスで別のVPN接続が動作していないか確認します。VPN構成が複数あると接続状態が競合する場合があるため、まず現在どの接続が実行中かを確認してください。管理対象デバイスでは、組織の設定による制限がある場合もあります。システムの案内に従い、デバイスのポリシーを回避するためにアプリを繰り返し削除しないでください。

初回の動作確認中は、ほかの設定を変えず、On Demandなどの自動接続条件もひとまず調整しないでください。オンデマンド接続は、その後の使い方に合わせて設定するもので、手動接続を成功させるための前提ではありません。手動スイッチ、サーバーの選択、接続モードを確認してから動作確認に進みます。こうすれば、問題が起きた際に、どの段階から想定と異なったかを特定しやすくなります。

04 · Connectivity Test：テストと実際のリクエストを確認

接続を開始したら、HomeでConnectivity Testを実行し、サーバーを確認します。まず現在選択中の項目をテストし、必要に応じてほかの項目と比較してください。最初に複数の項目をまとめてテストすると、実際に選択しているサーバーがわかりにくくなることがあります。結果はテスト方法と合わせて判断します。方法によって確認される接続段階が異なるため、どの数値もサービスへのアクセスが完全に成功した証拠とみなすことはできません。

応答があれば、その時点の条件で該当するテスト段階が完了したことを示します。ダウンロード速度を直接示すものではなく、すべてのサービスにアクセスできる保証にもなりません。タイムアウトは、設定された待機時間内にテストが完了しなかったことを示しますが、原因はサーバー、ローカルネットワーク、テスト対象のいずれにもあり得ます。1回の結果は調査の手がかりとして扱い、接続経路全体の恒久的な評価には使わないでください。テスト方法や並べ替えについて詳しくは遅延テストとサーバーの整理をご覧ください。

続けて、利用したいWebサイトやアプリを開き、同じページを更新するなど、繰り返し確認できる操作を行います。開けるか、一部のコンテンツだけ失敗するか、問題発生時のネットワーク環境も記録してください。アプリのスイッチやシステムのVPN表示だけで成功と判断しないでください。確認すべきなのは、対象のリクエストが想定どおり完了したか、その経路が現在のモードに合っているかです。

Configを使う場合は、実際のリクエスト記録で、適用されたルールと処理結果も確認します。対象のリクエストがDIRECTに一致しても、プロキシの不具合とは限りません。設定どおりの動作である可能性があります。REJECTに一致した場合は、まずルールの意図を確認してください。ルールの影響が疑われる場合は、一時的にProxyに切り替え、同じサーバーと同じローカルネットワークで同じリクエストを再試行し、その後Configに戻して結果を比較します。比較中にサーバーの変更とDNSの変更を同時に行うと、結果を判断しにくくなります。

今回の確認結果は、選択したサーバー名、Global Routingの値、ローカルネットワーク、対象の操作、成功または失敗の状況を簡潔に記録できます。サブスクリプションURL、パスワード、UUIDを記録する必要はありません。実際のリクエストが正常に動作することを確認したら、日常使用の設定を1項目ずつ元に戻してください。変更のたびに同じ方法で確認すれば、その後の不具合と変更内容を関連付けやすくなります。

05 · よくある問題：発生した段階から確認

すべてのパラメータを同時に変更せず、問題を段階ごとに切り分けます。「追加した情報は完全か → システムが接続を確立したか → サーバーテストに応答があるか → 実際のリクエストがルールどおりか」の順に確認し、最初に失敗する段階を特定してください。元の利用可能な設定は残し、一度に変更するのは1項目だけにして、4番目の手順と同じ操作を繰り返します。以下の順序は初回利用時だけでなく、サブスクリプションの更新後やローカルネットワークの切り替え後の確認にも使えます。

サブスクリプションを保存してもサーバーが表示されない

サブスクリプションの項目に戻り、TypeがSubscribeであること、URLにサービス提供元の管理ページではなく完全なサブスクリプションURLが入力されていることを確認します。引用符や空白が混入していないか、クエリパラメータが欠けていないかを調べ、アプリに表示された取得または解析の案内も確認してください。ブラウザーでWebページが開けても、その応答をサブスクリプションとして読み込めるとは限りません。内容が空だったりアクセス権が無効だったりする場合は、ご利用のサービス提供元に元のURLを確認してください。無作為にパラメータを変更して直そうとしないでください。

接続スイッチがオンのままにならない

まず、システムのVPN構成に対する許可とデバイス管理の制限を確認し、ほかのVPN接続の状態も調べます。アプリに構成エラーが表示された場合は、直近に変更した設定に戻り、具体的な内容を確認してください。システムの接続自体が確立されていない段階では、サーバーをまとめて入れ替えても原因の特定にはつながりません。スイッチが正常にオンになってから、サーバーの認証情報と通信パラメータを確認します。

Connectivity Testがタイムアウトし、実際のアクセスも失敗する

まず、デバイスが現在のネットワークを正常に利用できることを確認してから、サーバーアドレス、ポート、パスワードまたはUUID、TLS、通信設定を確認します。入力に余分な文字が1つあるだけでも、認証やハンドシェイクに失敗することがあります。サーバー名だけで判断せず、サービス提供元の元の情報と項目ごとに照合してください。Wi-Fiとモバイル通信を切り替えて比較する方法もあります。結果がローカルネットワークによって変わる場合は、設定全体をすぐに書き換えるのではなく、そのネットワークのアクセス条件を詳しく確認してください。

テストには応答するが、一部のサービスだけ利用できない

「サーバーテストに応答があること」と「目的のサービスが利用できること」を分けて考えます。まずGlobal Routingを確認し、対象リクエストに適用されたルールとDNS関連の状態を調べてください。Proxyでは正常でConfigでは失敗する場合は、現在の設定ファイル、ルールの順序、ポリシーの振り分け先を優先して確認します。どちらのモードでも失敗する場合は、対象サービスの状態、サーバーの接続先の条件、プロトコルパラメータを確認してください。部分的な失敗をすべて遅延の高さのせいにしないでください。

サブスクリプションの更新後やネットワーク切り替え後に問題が発生する

更新後は、選択中のサーバーが引き続き存在するか、パラメータが変わっていないか、グループ内に名前の似た項目が追加されていないかを確認します。ネットワークを切り替えた場合は、同じサーバーをもう一度テストし、以前のネットワークでのテスト値を現在の判断に流用しないでください。更新や一括切り替えを繰り返すのは一旦やめ、条件を固定して実際のリクエストを一度確認すると、接続情報とローカル環境のどちらに原因があるか判断しやすくなります。

基本的な接続を確認したら、サブスクリプションの更新、複数のサブスクリプションの整理、サーバーの削除やバックアップなどの操作についてサーバー管理マニュアルを続けてご覧ください。見慣れないプロトコルやルールキーワードがある場合は、パラメータを変更する前に用語集を確認してください。このチュートリアルの完了目安は、何を選択したか、リクエストがどのように処理されるかを説明でき、再現可能な実際のアクセスで結果を確認できることです。