公式マニュアル · iPhone・iPad
Shadowrocketの使い方:
サブスクリプションの追加と初回接続
初回は5つの手順で進めます。まず手持ちの情報をHomeに追加し、Global Routingを選択してシステムの許可を完了した後、実際にアクセスできるか確認します。最初に接続を確立してからルール、DNS、On Demandを調整すると、各設定による変化を把握しやすくなります。
このページでは、初回接続の操作手順を説明します。設定ファイルの各項目やルールの詳しい書き方は設定項目リファレンスをご覧ください。症状ごとの対処方法はよくある質問とトラブル対処をご確認ください。iPhoneとiPadでは同じ手順で操作できます。画面の配置は実際のデバイス表示に従ってください。
手順1:Add Serverで追加、またはSubscribeで読み込み
まず、手元の情報の種類を確認します。サブスクリプションURLは複数のサーバー項目を取得するためのもので、通常は提供元によって更新されます。個別のサーバー情報には、プロトコル、アドレス、ポート、認証情報が含まれます。両方を重複して追加する必要はありません。実際にお持ちの情報に合った方法を選んでください。操作前に元の情報が揃っていることを確認します。ウェブページの紹介URLをサブスクリプションURLとして使ったり、設定ファイルのURLとサーバーのサブスクリプションURLを取り違えたりしないようにしてください。
サブスクリプションURLをお持ちの場合:Subscribeを選択
Shadowrocketを開いてHomeに移動し、追加ボタンからAdd Serverを開きます。種類の一覧からSubscribeを選び、手持ちのサブスクリプションURLを省略せずURL欄に入力します。内容を見分けやすい名前を付けて保存してください。Homeに戻り、取得が完了したらサブスクリプションのグループにサーバー項目が表示されているか確認します。名前だけが表示され、項目が追加されていない場合は、接続スイッチをオンにする前に取得が完了しているか確認してください。
URLをコピーするときは、疑問符以降のパラメーターも含めてください。引用符、空白、改行は追加しないでください。URLによっては個人用のアクセス情報が含まれます。ご自身のデバイスだけで使用し、URL全体が写った公開スクリーンショットや問い合わせ文を共有しないでください。エラーが表示されたら編集画面に戻り、元のURLと照合します。同じサブスクリプションを何度も登録しても、URLの誤りは解消されず、項目の選択が分かりにくくなります。サブスクリプションの内容を更新する場合は、登録済みの項目を更新して、結果が変わったか確認してください。
サーバー情報をお持ちの場合:実際のプロトコルに合わせて入力
個別のサーバー情報をお持ちの場合は、Add Serverで情報と一致するプロトコルを選び、アドレス、ポート、対応する認証情報を入力します。たとえばShadowsocks、VMess、VLESS、Trojanでは認証情報が異なります。アドレスが似ているからといって、別のプロトコルの設定を流用しないでください。TLSなどのトランスポート設定がある場合は、関連項目も確認します。各項目には元の情報を入力し、推測で補わないでください。
サーバーアドレスには、該当欄で指定されているホスト名またはアドレスを入力し、ポートはポート欄に入力します。ユーザー名、パスワード、UUID、TLS名などはそれぞれ用途が異なるため、互いに代用できません。QRコードで情報を受け取った場合は、Scan QR Codeで読み取れます。読み込み後も項目を開いて種類や重要な情報を確認し、内容が揃ってから保存してください。QRコードにもサブスクリプションURLと同様に認証情報が含まれる場合があるため、公開しないでください。
追加したらHomeに戻り、SERVERの一覧から今回使用する項目を選びます。「項目が保存されていること」と「項目が選択されていること」は別です。複数のサーバーが一覧にある場合は、接続時に使うものを明確に選択してください。選択した項目の名前を控えておき、次の手順でGlobal Routingを切り替えて結果を確認するときも同じサーバーを使います。複数の条件を同時に変えないようにしましょう。
手順2:Global Routingのモードを選択
サーバーの追加と選択が完了したら、HomeでGlobal Routingを開きます。ここではリクエスト全体の処理方法を指定します。サーバー情報を補完する機能ではありません。サーバー情報が正しくても、別のモードでリクエストが処理されると、実際の動作が想定と異なることがあります。このガイドでは3つのモードをConfig / Proxy / Directと表記します。デバイス上では英語の表示を確認してください。
| モード | リクエストの処理方法 | 初回利用時の目的 |
|---|---|---|
| Config | 現在有効な設定ファイルとルールに基づいてポリシーを決定します。 | 既存の設定による振り分け結果を確認します。 |
| Proxy | リクエストをプロキシ経由で処理します。システムやアプリ固有の例外については、実際の設定も確認してください。 | まず、選択したサーバーのプロキシ経路を確認します。 |
| Direct | 接続先に直接接続します。選択したサーバーを経由した結果の確認には使えません。 | ローカルネットワークからの直接アクセスと比較します。 |
サーバーのサブスクリプションだけをお持ちで、ルール設定の準備がまだできていない場合は、Proxyを選んで制御されたテストを行えます。ルール選択による変数を一時的に減らせますが、すべてのアプリやシステムのリクエストが同じように処理されるわけではありません。テストでは接続先のページを明確に決め、実際のアクセスと接続ログを合わせて確認してください。モード名だけで、リクエストがサーバーを経由したと判断しないでください。
Configを使う場合は、まずConfigを開き、実際に有効になっている設定ファイルを確認します。Global RoutingのConfigはルーティングモード、画面下部のConfigは設定ファイルの管理画面です。両者は関連しますが、同じ操作ではありません。サーバーのサブスクリプションを読み込んでも、ルール設定が切り替わるわけではありません。振り分け結果が想定と異なる場合は、有効な設定ファイルを確認してください。サーバーを何度も追加する必要はありません。
ルールは通常、上から順に照合され、条件に一致すると対応するポリシーが適用されます。まずはこの点をトラブル対処の基本として押さえておけば十分です。初回接続前にルール全体を編集する必要はありません。PROXY、DIRECT、REJECT、FINALの意味を確認する場合は、ルールと設定のリファレンスをご覧ください。モードを選んだらHomeに戻り、先ほど選択したサーバーがそのまま選ばれていることを確認してから、接続スイッチを操作します。
手順3:接続スイッチをオンにしてシステムの許可を完了
次の3点を確認します。Homeに使用可能なサーバー項目があること、今回使う項目が選択されていること、Global Routingが先ほど決めたモードになっていることです。確認後、Homeの接続スイッチをオンにします。このデバイスで初めて接続を確立するときは、システムにVPN構成の追加を許可する案内が表示される場合があります。これはシステムのネットワーク接続構成を作成する操作であり、Subscribeによるサーバー一覧の取得とは別のものです。
システムの案内を読み、Shadowrocketで行った直前の操作によって表示されたことを確認してから許可し、画面の指示に従ってデバイス認証を行います。許可が完了したらアプリに戻り、接続スイッチとステータスが接続済みの状態を保っているか確認してください。案内を以前キャンセルした場合は、接続を再度開始して許可を完了します。スイッチを何度も押しても、未完了のシステム確認の代わりにはなりません。
スイッチをオンにしてもすぐにオフへ戻る場合は、アプリまたはシステムに表示されたエラーを確認します。構成が正しく作成されたか、ほかのネットワーク接続構成が優先されていないか、デバイス管理ポリシーで操作が制限されていないかを確認してください。状況を記録する前に、すべての構成を削除しないでください。まず使用中のほかの接続を通常の方法で切り、Shadowrocketだけで再度テストすると、状態の切り替わりによる影響を減らせます。
システムにVPN接続と表示されても、ネットワーク接続構成が動作中であることを示すだけです。リモートサーバーの認証成功や、すべてのウェブページへのアクセスを保証するものではありません。次に接続先へのリクエストを確認してください。特にConfigでは、ルールにより一部の接続先がDIRECTになる場合があります。これを接続スイッチが機能していない状態と同一視しないでください。
初回のトラブル対処中は手動で接続スイッチを操作し、On Demandは同時に変更しないでください。On Demandは条件に応じて接続の開始や再接続に影響するため、条件を把握していないと、接続をオフにしたのに再び接続したように見えることがあります。まず次の手順で安定した状態を確認し、実際の使い方に応じてOn Demandの機能説明をお読みください。テストを終了するにはHomeに戻って接続スイッチをオフにし、状態が変わったことを確認します。
手順4:Connectivity Testと実際のアクセスを確認
接続が確立したら、まずConnectivity Testを実行し、結果が表示されたか、エラーが出たかを記録します。次にSafariを開き、アクセスできると分かっているページを表示します。テストと実際のアクセスは別の確認です。テスト結果はテスト方法と接続先に基づき、実際のアクセスでは接続先ドメインの名前解決、接続、TLS、ページリソースの読み込みが関係します。テストで数値が表示されても、すべての接続先にアクセスできるとは限りません。一度のタイムアウトだけで、すべてのリクエストが失敗すると判断することもできません。
再現できる条件で比較する
接続先のページを一つ決め、使用ネットワーク、サーバー、Global Routingを記録します。ページの読み込み完了を待ち、再読み込みするか、アクセス可能と分かっている別のページを開いて、結果を再現できるか確認してください。テスト中にサブスクリプションを更新したり、サーバーを切り替えたり、DNSを変更したりしないでください。結果が変わった場合に原因を特定しにくくなります。Wi-Fiとモバイル通信を比較する場合は、現在のネットワークでの記録を済ませてから、ネットワークだけを切り替えて再テストします。
Proxyでは正常にアクセスでき、Configでは同じ接続先に問題が起きる場合は、サーバーを変えずに現在の設定とルールの適用状況を確認してください。逆に、どちらのモードでもアクセスできない場合は、ルール全体を書き換える前に、サーバー情報、接続先の稼働状況、ローカルネットワークを確認します。Directはローカルからのアクセスとの比較に使えますが、Directで成功してもプロキシ経路が使えるとは限りません。
全体の状態だけでなく、リクエストごとに結果を確認
特定の接続先にどのポリシーが適用されたか確認するには、アプリ内の接続ログを開き、ドメイン名またはアドレスで今回のリクエストを検索して、表示されるポリシー、ルール、エラー情報を確認します。ログの場所や表示項目はバージョンによって異なる場合があります。実際の画面表示に従ってください。まず新しいリクエストを明確に発生させてから対応する記録を見ると、大量の履歴から推測するより照合しやすくなります。
DIRECTが表示されたら、まず現在のルールに沿った結果か確認します。REJECTの場合は、想定した拒否ルールに一致したかを確認してください。PROXYの場合は、選択中のサーバーと接続結果を確認します。ページでは複数のドメインへのリクエストが発生するため、メインページが開いても、画像、ログイン、その他のリソースが読み込まれるとは限りません。一部だけ失敗する場合は、サイト全体を利用不可と決めつけず、失敗したリソースのドメインを記録してください。
確認が済んだら、Global Routingを日常の用途に合わせて調整します。Configを使う場合は、確認済みのサーバーと設定ファイルを維持し、その後は変更を一度に一つだけにしてください。これで初回接続の手順は完了です。問題が残る場合は、次の節で発生箇所に近いところから確認します。
手順5:失敗した箇所からトラブル対処
まず、どの手順で失敗したかを明確にしてから、該当する設定を確認します。サブスクリプションの内容を取得できない、接続スイッチがオンのままにならない、テストがタイムアウトする、ウェブページの一部しか読み込まれない状態は、それぞれ異なります。すべてを「接続できない」とまとめると、正しい設定まで何度も変更してしまいがちです。以下ではローカルネットワークから順に確認範囲を絞ります。各項目を確認したら、同じ接続先で再テストしてください。
サブスクリプションを読み込めない、または一覧に項目が表示されない
まず、デバイスがアクセス可能なネットワークに接続されているか確認します。現在の接続がネットワーク状態の判断に影響している場合は、Shadowrocketを通常の方法でオフにし、基本的なアクセス状況を比べてください。次に、サブスクリプションURLが完全か、有効期限内か、返された内容が認識可能なサブスクリプションデータかを確認します。ウェブページが開けても、サブスクリプションURLから正しい内容が返されるとは限りません。
URLが元の情報から取得したもので、コピー時に説明文が混入していないことを確認します。提供元がURLを変更した場合は、古いURLを繰り返し更新するのではなく、該当するサブスクリプションのURLを更新してください。更新後はグループ内に実際の項目が表示されているか確認し、サーバーを選択します。取得に失敗している場合、後からGlobal Routingを切り替えても通常は解決しません。
サーバーは追加できたが、認証またはテストに失敗する
現在選択されている項目を開き、プロトコルの種類、アドレス、ポート、認証情報、TLSとトランスポートの設定を元の情報と照合します。パスワード末尾の空白、UUIDが欠けていないか、TLS名が正しい欄に入力されているかを特に確認してください。表示名を変更しても接続パラメーターは変わりません。項目の名前を付け直しても認証エラーは解消されません。
同じ手持ちの情報に、利用可能だと明確に分かっている別の項目がある場合は、ほかの設定を変えずにサーバーだけ切り替えて比較できます。複数の項目で失敗する場合は、ローカルネットワークの変化と提供元からの稼働状況に関する情報を確認してください。テストに通すためだけに証明書の検証を無効にしないでください。まずデバイスの時刻、接続先の名前、元のTLS設定が一致しているか確認します。
接続済みでテスト結果も表示されるが、ウェブページが開かない
まず、ドメイン名の名前解決失敗、接続タイムアウト、ルールによる拒否を区別します。現在の設定で、DNSが意図した内容になっているか確認し、接続ログと照らし合わせて対象ドメインを特定してください。特定のドメインだけ開けず、ほかのページにはアクセスできる場合、接続全体が機能していないとすぐに判断しないでください。複数のドメインを名前解決できない場合は、DNSの経路と現在のネットワーク環境を優先して確認します。
出所の分からないDNSアドレスを一度に複数設定しないでください。まず現在の値を記録し、使えると分かっている設定に戻してからリクエストを再実行し、結果を比較します。Proxyでは正常でConfigでは問題が起きる場合は、対象がDIRECTまたはREJECTに振り分けられていないか、FINALが想定したフォールバックとして機能しているかを確認します。詳しい設定と症状別の対処方法はDNSと接続のトラブル対処をご覧ください。
変更後に状況が分かりにくくなった場合:最後に使えた状態に戻す
元のサブスクリプション情報と、正常に使えた設定のコピーを保管し、直前に加えた変更を一つ戻してから再テストします。サブスクリプションの更新でサーバー一覧が変わり、設定ファイルの切り替えでポリシーが変わり、ネットワークの切り替えで名前解決に影響が出る場合があります。アプリをすぐに再インストールするより、変更を行った順に確認するほうが原因を特定しやすくなります。アプリを再取得する必要がある場合は、App Storeで購入済みアプリを復元する方法をご確認ください。再インストールをネットワークの一般的な修復方法と考えないでください。
初回接続の確認では、サーバー情報が正しく保存され選択されていること、ルーティングモードが用途に合っていること、システム接続が確立していること、接続先へのリクエスト結果を説明できることの4点を確認します。確認後にOn Demandや詳細なルーティング設定を少しずつ追加すれば、後で変化があった際も同じ手順で見直せます。