公式ガイド / クイックスタート
Shadowrocketのクイックスタート
既存の設定を追加し、Global Routingを選んでから接続と通信を確認します。
この記事では主にiPhone / iPadでの操作を説明します。システム要件と対応デバイスはApp Storeの製品ページをご確認ください。画像は画面の見分けにお使いいただき、項目の表示はご利用のデバイスでご確認ください。
初めて操作する場合は順番にお読みください。使用できる項目がすでにある場合は、モード選択から始められます。設定、ルール、日常的な管理についてはシステムチュートリアルをご覧ください。
STEP 01 / IMPORT
Add Server:追加・読み込み
手元にある情報を確認してから適切な追加方法を選びます。サブスクリプションURLと個別サーバー情報は、入力方法が異なります。
Shadowrocketを開き、HomeのSERVERグループにあるAdd Server、または画面上の追加ボタンをタップします。まず情報の種類を確認してください。サブスクリプションURLは複数の項目を取得・更新するためのものです。個別の共有リンクには通常、1台のサーバー情報が含まれています。手動で入力する場合は、プロトコル、アドレス、ポート、認証情報をそれぞれ指定します。サブスクリプションURLをHostに入力しないでください。また、URLの長さだけで種類を判断しないようにします。
既存のサブスクリプションURL:Subscribeを使用
Add ServerでTypeを開き、Subscribeを選択して、既存のサブスクリプションURLをURL欄に入力します。メモには用途や情報の入手元など、見分けやすい名前を付けてください。認証情報はメモに記載しないでください。貼り付けた後、先頭や末尾に空白、改行、引用符が入っていないか確認します。コピー時にURL末尾のパラメーターが欠けていないかも確認してください。保存したらHomeに戻り、サブスクリプションの読み込みを待ちます。
保存できても、内容の取得に成功したとは限りません。リストに戻り、サブスクリプショングループまたはサーバー項目が表示されることを確認します。グループ名だけが表示され、選択できる項目がない場合は、まずサブスクリプションを更新し、エラーが表示されていないか確認してください。更新は項目情報を再取得する操作であり、各サーバーへの接続を保証するものではありません。サブスクリプションの期限切れ、権限の変更、または内容が空の場合は、元のサービス提供元に登録情報をご確認ください。
既存のサーバー情報:Typeと各項目を確認
手動で入力する場合は、まずTypeで手元の情報に合ったプロトコルを選び、Host、Port、必要な認証項目を入力します。画像にはPasswordやMethodなどが表示されていますが、Typeによって必要な項目は異なります。同じ項目をすべてのプロトコルに当てはめないでください。Hostには通常、ドメイン名またはIPアドレスを入力し、Webページのパスは付けません。Portは手元の情報どおりに入力します。PasswordやUUIDなどの認証値は、大小文字や記号も含めて正確に入力してください。
使用できるQRコードがある場合は、Scan QR Codeで読み込み、解析されたTypeとアドレスを確認できます。Import from Cloud JSONは対応する形式のデータを読み込む機能で、一般的なサブスクリプションURLの入力欄ではありません。どの方法で読み込んでも、保存前にプロトコルが手元の情報と一致しているか確認してください。形式を認識できない場合は、Typeを次々に変更するのではなく、まず情報の用途を確認します。
STEP 02 / ROUTING
Global Routing:モード選択
サーバーはプロキシ接続に使う出口を決め、Global Routingはリクエストの振り分け方法を決めます。それぞれ別に確認してください。
サーバーを選択したらHomeに戻り、Global Routingを開きます。ここではConfig(設定)/ Proxy(プロキシ)/ Direct(直接接続)の3つを区別してください。モードを切り替えてもサーバー情報は補完されず、無効なサブスクリプションが復旧するわけでもありません。最初に現在のモードを把握しておくと、その後の接続確認やトラブル対処を同じ条件で行えます。
Config(設定):現在の設定に従ってリクエストを処理
Configでは、選択中の設定ファイルとそのルールに基づいてリクエストの送信先が決まります。画面下部のConfigを開き、ファイルが選択されていることを確認して、該当する設定のRuleを確認します。画像のGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは設定ファイル内の各セクションです。クイックスタートでは項目を一つずつ変更する必要はありません。特に接続のためだけに、用途に関係のない機能を同時に有効にしないでください。
サブスクリプションを読み込んでも、振り分けルールが選択されているとは限りません。サーバー一覧と設定ファイルは別々に管理されます。前者には接続情報があり、後者はリクエストのマッチング方法を決めます。Configを使う前に、現在の設定ファイルが存在し、ルール内のポリシーが使用可能なサーバーまたはポリシー設定に対応していることを確認してください。振り分け設定がまだない場合は、まずProxyで基本的な接続性を確認してからConfigに戻ります。
Proxy(プロキシ)とDirect(直接接続):通信経路を指定
Proxyでは、このモードで処理されるリクエストが選択中のプロキシ経路に送られます。初回にサーバーで実際の通信ができるか確認する際に便利です。ただし、すべてのアプリ、プロトコル、ネットワークリクエストで同じ結果になるとは限りません。Directではリクエストを直接接続で処理し、端末本来のネットワークが正常か比較できます。このモードで接続スイッチをオンにしても、選択中のプロキシサーバーを使用していることにはなりません。
Configのルールを簡単に示すと、次のようになります。example.comとそのサブドメインだけをPROXYに送り、ほかの一致しないリクエストはFINAL,DIRECTで処理します。example.comは説明用のドメインで、接続先サーバーのアドレスではありません。この例は通信経路の説明用であり、初回の操作で設定全体を置き換える必要はありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
ルールは上から順に照合され、一致した時点で該当するポリシーが適用されるため、FINALは具体的なルールの後に置きます。RuleでAdd Ruleを使う場合は、元の設定を残したまま、今回のテストに関係するルールだけを追加してください。詳しい構文とポリシーの設定方法はシステムチュートリアルのConfigとルールの説明をご覧ください。このページでは引き続き接続を確認します。
STEP 03 / CONNECT
Home:接続スイッチをオン
システムの許可を行う前に、サーバーとモードを確認します。接続状態は確認の出発点です。
Homeに戻り、次の2か所を確認します。SERVERグループで選択されている項目がテスト予定のサーバーか、Global Routingが予定どおりConfig、Proxy、Directのいずれかになっているかを確認してください。サブスクリプションの更新後は一覧の項目が変わることがあるため、前回の記憶だけで判断しないでください。初回接続では現在のWi-Fiまたはモバイル通信を維持し、ネットワークの変更によって比較が難しくならないようにします。
Connectivity Testを実行し、現在のテスト方法での接続結果を確認できます。失敗した場合は、接続スイッチを何度も切り替えず、項目に戻って情報が揃っているか確認し、最後のセクションを参考に原因を調べてください。応答があれば、Home上部の接続スイッチをオンにします。Connectivity Testの結果は指定されたテスト方法に限られます。一度のテストだけで、すべてのWebサイト、DNSの名前解決、アプリのリクエストが正常だと判断することはできません。
初回接続:システムのVPN構成追加を確認
初めて接続を開始すると、ShadowrocketによるVPN構成の追加を許可するようシステムから求められる場合があります。これはアプリがシステムのネットワーク接続を確立するために必要な許可です。表示されたアプリ名を確認し、システムの案内に従って許可して、デバイスで求められる認証を完了してください。この認証はデバイスのシステム上の手続きです。アプリにサブスクリプションのパスワードを入力するものではなく、デバイスのロック解除情報を他人に知らせる必要もありません。
許可が完了したらShadowrocketに戻り、画面上部の接続状態が変わるまで待ちます。許可を取り消した場合は通常、接続は完了しません。スイッチをもう一度オンにして、表示された案内に従ってください。許可や構成のエラーが表示された場合は、まず内容を確認し、デバイスに管理上の制限があるか、ほかのVPN構成が接続に影響していないか調べます。管理対象のデバイスでは所定の管理ルールに従い、不明な構成をむやみに削除しないでください。
接続済み:テスト条件を維持
画面上部の状態がNot Connectedから接続済みに変わったら、選択したサーバー、モード、ネットワークをそのまま維持します。システムにVPN状態が表示されるのは、関連する接続構成が有効になったことを示します。ただし、対象サイトが必ずプロキシ経由で通信していることや、サーバーがすべての接続先にアクセスできることを保証するものではありません。次に新しいリクエストを実行し、現在のモードに沿った結果になるか確認してください。
今回の手動確認中は、On Demandを追加で変更しないでください。On Demandは今後の自動接続に関する機能であり、サーバー情報を読み込む手順ではありません。接続をオフにした後でアプリが再接続する場合は、接続スイッチの不具合と決めつけず、現在のOn Demand設定を確認してください。
STEP 04 / VERIFY
通信確認:実際の経路を確認
「スイッチがオン」「テストに応答がある」「目的のサイトにアクセスできる」は分けて確認し、一つの状態だけで判断しないでください。
接続が確立したら、ブラウザーまたはネットワークを使うアプリを開き、事前に選んだ宛先へ新しいリクエストを送ります。表示済みのページはキャッシュから読み込まれている場合があるため、今回の接続成功を示す根拠にはなりません。ページを再読み込みするか、該当コンテンツを開き直し、タイトルが表示されるだけでなく、文章、画像、その後のリクエストまで読み込まれるか確認してください。
確認時は、現在のサーバー名、Global Routingのモード、実際にアクセスできたかの3点を記録します。必要に応じてDataを開き、今回発生した接続または通信の記録を確認してください。記録される範囲は、現在のアプリ設定と表示内容によって異なります。通信量のカウントが増えただけでは、目的のリクエストに想定したポリシーが適用されたとは限りません。リクエストのドメイン、確認できる処理情報、実際のアクセス結果を合わせて判断します。
Configモード:プロキシ経由と直接接続の宛先を個別に確認
Configを使う場合は、プロキシ経由にするルールが明確な宛先と、直接接続する想定の宛先を一つずつ選び、それぞれ確認してください。直接接続する宛先が開けても、プロキシサーバーが正常とは限りません。プロキシ経由の宛先にアクセスできても、ほかのリクエストが正しく振り分けられているとは限りません。ルールとの照合では実際のリクエストドメインを確認します。アドレスバーのドメインだけでは、ページ内のすべてのリソースを示していない場合があります。
ProxyではアクセスできるのにConfigで失敗する場合は、サーバーを変えずにモードの違いだけを比較します。設定ファイルの選択ミス、先行するルールへの一致、最終ポリシーが想定どおりかを確認してください。両方のモードで失敗する場合は、ルール全体を書き直す前にサーバー情報、接続性、DNSを確認します。Directでアクセスできる場合も、現在の直接接続条件でその宛先が利用可能だとわかるだけです。
ネットワークを変更:同じ条件で再確認
現在のネットワークでのテストが終わったら、日常的にWi-Fiとモバイル通信を切り替えて使う場合は、もう一方のネットワークに切り替え、同じサーバーと宛先で再テストします。切り替え後に問題が出たら、特定のネットワークだけで起きるか記録し、そのアプリに対するシステムのネットワーク権限を確認してください。ネットワーク変更と同時にサブスクリプション更新、サーバー切り替え、DNS変更を行うと、原因を特定しにくくなります。
最後に接続をオフにし、通常のネットワーク通信が想定どおりか確認してから、再接続してもう一度テストします。これにより、一時的なキャッシュやネットワークの揺らぎと、再現性のある接続結果を区別できます。設定が正常に動作している場合は、まず現在の内容を維持してください。より詳しい振り分け設定は基本的な確認が終わってから調整できます。初回からすべての機能を設定する必要はありません。
STEP 05 / DIAGNOSE
よくある失敗:項目ごとに確認
一度に変更する条件は一つだけにし、同じ宛先でテストします。改善したら変更を維持し、改善しなければ元に戻してください。
サブスクリプションを保存したがサーバー項目がない
まずTypeがSubscribeになっているか、URLが完全か、更新時に明確なエラーが表示されたか確認します。この段階の問題はサブスクリプション内容を取得する処理にあり、サーバーの接続可否はまだ判断できません。デバイスの基本的なネットワーク接続を確認し、既存のサブスクリプションが有効かどうかも確認してください。削除して再追加を繰り返しても、更新が成功した証明にはなりません。認証情報を含むURL全体を公開ページに貼り付けないでください。
Connectivity Testが失敗する、または結果が一致しない
SettingsでTest Methodを開き、結果を判断する前に現在の方法を記録します。テスト方法によって確認する内容が異なるため、異なる方法の結果を同じ遅延や利用可否の指標として比較することはできません。対象を一つに絞って再テストし、Host、Port、プロトコルの種類、認証値を確認します。ほかに使用可能な項目がある場合は、モードとテスト対象を変えずに切り替えて比較できます。特定の項目だけが失敗する場合は、その項目の情報を優先して確認してください。
接続済みだがページを開けない
まずGlobal Routingを確認します。Directの場合、選択中のプロキシサーバーはProxyモードでリクエストを処理していません。Configの場合は、設定ファイルとルールのポリシーを確認してください。次にProxyで比較し、Configモードのときだけ問題が起きるか確認します。モードを変えても失敗する場合は、ドメインの名前解決、サーバーの状態、接続先自体の利用可否を確認し、複数の設定を同時に変更しないでください。
DNSのトラブル対処は、まず現在の設定を確認することから始めます。システムの名前解決方法や設定内のDNS項目を記録してください。試しに複数の出所不明なアドレスを一度に入力しないでください。一部のドメインだけ失敗し、ほかのリクエストは正常な場合は、Dataの新しいリクエストと実際のエラー情報を合わせて原因を絞り込みます。名前解決とルールの詳しい関係はシステムチュートリアルをご覧ください。変更後は同じ宛先に新しいリクエストを送り、古いテスト数値の更新だけで判断しないでください。
接続の動作が手動スイッチと一致しない
SettingsでOn Demandに自動接続の条件が設定されているか確認します。ネットワークの変更後や条件を満たしたときの接続動作に影響するため、手動でオフにした後に再接続する場合は、まず条件を確認してください。初回のトラブル対処では自動動作と手動テストを分けて記録し、どの操作で接続が開始したかを確認してから設定を変更します。原因が特定できていない問題に対して、Proxy、TCP、UDPなど複数の項目を同時に変更しないでください。
原因を特定できない場合:Diagnosticsの情報を整理
必要に応じてSettingsのDiagnosticsを開き、利用できる診断項目を確認します。問題が起きたときのネットワークの種類、選択中のサーバー、Global Routing、Test Method、再現可能な操作手順を記録し、関連する情報を収集してください。診断ファイルがすべての機密情報を自動で隠すとは限りません。関係するサポート窓口に送る前に、サブスクリプションURL、パスワード、認証パラメーター、公開する必要のないアクセス記録を確認して削除してください。
元のサービス提供元にサーバーの状態を問い合わせる場合は、該当項目に関する情報だけを送り、機密値は削除してください。アプリの入手、購入済みアプリの復元、デバイスの互換性についてはアプリの入手方法をご覧ください。基本的な接続が復旧したら、通信確認に戻って再テストし、最後に使用できる設定を保存します。以後の変更時に比較できるため、最初からやり直す必要がありません。