Shadowrocket入門ガイドと接続確認
「情報を追加 → ルーティングを選択 → 接続を開始 → 結果を確認 → 問題箇所を特定」の順に操作します。本ページはiPhone・iPadを対象に、まず再現可能な接続を一度確立してから、日常的な設定を調整する手順を説明します。
スクリーンショットはApp Storeの公式素材で、画面上の項目の位置を確認するために掲載しています。具体的な項目は選択したTypeやアプリの画面によって異なります。操作時は、端末に表示される英語の項目名と実際の案内に従ってください。
STEP 01 / IMPORT
Add Server / Subscribe：既存情報を追加する
ShadowrocketのHomeを開き、画面下部のSERVERとAdd Serverを確認します。情報には、サブスクリプションURLと個別のサーバー情報の2種類があります。サブスクリプションURLはサーバー項目を取得・更新するためのアドレスです。個別のサーバー情報には、特定のサーバーに接続するためのプロトコルやパラメーターが含まれます。入力場所は異なるため、サブスクリプションURLをHostとして入力したり、通常の説明ページをサブスクリプションURLとして追加したりしないでください。
サブスクリプションURLがある場合：Subscribeを使う
HomeでAdd Serverをタップし、追加画面でTypeをタップしてSubscribeを選びます。自分が持っているサブスクリプションURLを省略せずに該当するURL欄へ入力し、保存してください。貼り付ける前後に、メッセージアプリによるURLの欠落、改行や前後の空白の混入がないか確認します。URL内のクエリパラメーターは通常アドレスの一部なので、推測で削除しないでください。サブスクリプションURLにはアクセス情報が含まれる場合があります。自分の端末内でのみ扱い、公開のコメント欄やスクリーンショットに載せないでください。
保存して情報の取得が完了したら、Homeに戻り、SERVERに目的の項目が表示されているか確認します。サブスクリプションの記録だけが表示され、サーバーが見当たらない場合は、まず更新エラーを確認してください。接続スイッチを何度も操作する必要はありません。サブスクリプションの取得失敗は「情報を取得する」段階の問題であり、その後のサーバー接続の可否とは別です。まずURLが有効で、現在のネットワークからアクセスできることを確認し、サブスクリプション項目の更新操作を使って再試行してください。
サーバー情報がある場合：Typeに合わせて入力する
個別のサーバー情報をお持ちの場合も、Add Serverから追加します。Typeは情報に記載されたプロトコルに合わせてください。次にHost、Port、およびそのTypeで必要な認証・通信項目を入力します。公式スクリーンショットは特定のパラメーター入力画面を示すものであり、すべてのTypeでPasswordとMethodを使うわけではありません。スクリーンショットに合わせるためにプロトコルを変更しないでください。Hostには通常、案内されたホスト名またはアドレスを入力し、Portには指定されたポート番号を入力します。大文字・小文字を区別する認証情報は、記載どおり正確に入力してください。
対応するQRコードがある場合は、Scan QR Codeで読み込み、作成された項目を開いて内容を確認できます。Import from Cloud JSONは、形式が一致する既存情報を追加するための機能で、任意のサブスクリプションURLに使える汎用の入口ではありません。どの方法でも、保存後はHomeに戻り、項目名とパラメーターが一致していることを確認して、今回テストするサーバーを選択してください。名前は識別用のラベルにすぎず、実際のパラメーター確認の代わりにはなりません。
STEP 02 / ROUTING
Global Routing：Config、Proxy、Directを選択する
情報を追加したらHomeに戻り、Global Routingをタップします。ここで選ぶのはリクエストの処理方法であり、サーバーの切り替えではありません。3つの選択肢はConfig、Proxy、Directとして理解してください。初めて使う際は、どれか一つを「常に選ぶべき」と覚えるのではなく、今回の確認で何の影響を切り分けたいかを考えてから選びます。
| モード | 処理内容 | 基本的な使い方 |
|---|---|---|
| Config | 現在の設定にあるルールに従って、リクエストの送信先を決定します。 | 現在のルール設定が有効だと確認できている場合に、日常的な振り分けに使います。 |
| Proxy | クライアントが処理するリクエストを、プロキシ経由で処理します。 | ルール選択の影響を抑えて、一時的な比較テストを行います。 |
| Direct | リクエストを直接接続として処理し、通常の送信先として選択中のプロキシサーバーを使いません。 | 現在のネットワークから対象サービスへ直接接続した場合の動作を確認します。 |
Configを使う場合は、Configを開き、使用中の設定ファイルを確認してから、その中のRuleを確認します。Config画面で選択中のファイルや編集内容は、ファイル名そのものより実際の動作を把握する手掛かりになります。同じ名前でもルールが異なる場合があります。スクリーンショットにあるGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは設定編集の各セクションです。初回の手順では、現在の設定とRuleを確認すれば十分です。他のセクションを一つずつ有効化・変更する必要はありません。
ルールは通常、上から順に照合され、一致するとそのルールに指定されたポリシーが適用されます。以下の2行は形式を確認するための例であり、既存ファイルと置き換えてそのまま使える完全な設定ではありません。1行目は例示ドメインとそのサブドメインをPROXYに割り当て、最後の行はそれ以前のルールに一致しなかった場合の処理を指定します。実際の結果は設定全体とポリシーの定義によって異なります。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT既存ルールの出所や役割がわからない場合は、まず元の選択を記録し、一時的にProxyに切り替えて接続を比較してください。同じサーバーでProxyならアクセスでき、Configでは特定の対象に失敗する場合は、サーバーをすぐに削除せず、ルールの一致状況と対象のポリシーを確認します。Directは「最速のサーバーを自動選択」するモードではありません。直接接続の基準として使うもので、プロキシ経由の接続が機能している証明にはなりません。
初回接続のためにAdd Ruleをむやみにタップする必要はなく、HTTPS Decryptionを有効にする必要もありません。既存の設定はそのままにして、後続の確認を終えてから、明確な必要性に応じてルールを変更してください。各機能の使い方は機能の紹介をご覧ください。今回の操作をやり直す場合は、Global Routingの選択手順に戻って一つずつ確認できます。
STEP 03 / CONNECT
Home：スイッチをオンにしてVPN構成を許可する
モードを選んだらHomeに戻り、次の3点を順に確認します。SERVERで選択中のサーバー、Global Routingの現在の設定、画面上部の接続状態です。スクリーンショットのNot Connectedは未接続を示します。最初の2点が正しいことを確認してから、画面上部の接続スイッチをオンにしてください。エラーが発生したとき、実際にどの条件でテストしたかを把握できます。
初回接続時、システムからShadowrocketによるVPN構成の追加を許可するよう求められることがあります。これはアプリがシステムのネットワーク接続を確立するために必要な許可手続きです。サブスクリプションの追加完了を示すものではなく、接続先のサーバーが利用可能だと保証するものでもありません。直前に操作したShadowrocketからの要求であることを確認し、システム画面の案内に従って許可して、端末に求められた認証を完了してください。許可後はHomeに戻り、接続状態が変化したか確認します。
許可しないを選んでいた場合は、まずアプリに戻って接続を再度開始し、システムの案内に対応してください。スイッチを素早く何度も切り替えないでください。案内が再表示されない場合や、接続を開始してもすぐに終了する場合は、システム設定のVPN関連画面で該当する構成があるか確認し、アプリのエラー情報と合わせて判断します。組織管理下の端末では、ネットワーク設定の一部が管理ポリシーによって制限されることがあります。この種の構成を変更できる端末か、あらかじめ確認してください。
iPadでも「サーバーを選ぶ、モードを確認する、接続を開始する、システムの許可を行う」の順に操作します。画面サイズやシステム画面のレイアウトは異なる場合があります。スクリーンショット上の位置を機械的に探すのではなく、HomeやGlobal Routingなどの画面名を目印にしてください。システム要件と互換性はApp Storeの掲載内容をご確認ください。
接続中はしばらく待ち、状態が安定して維持されるか確認してください。スイッチがすぐにオフになる場合は、表示されたメッセージを省略せず記録します。スイッチがオンのままでも、すべてのリクエストが想定どおり処理されているとは限りません。システムのVPN表示は、システムのネットワーク接続が該当状態にあることを示すものです。それだけで、サーバー認証、ドメイン名の解決、対象サービスへのアクセスがすべて成功したとは判断できません。次にアプリの状態と実際のアクセス結果を合わせて確認します。
STEP 04 / VERIFY
Connectivity Test：到達性と実際の動作を区別する
Homeに戻り、Connectivity Testで選択中のテスト方法による現在のサーバーの結果を確認します。テスト結果が表示された場合は、その探査に応答があったことを示します。タイムアウトした場合は、その探査が制限時間内に完了しなかったことを示します。いずれも「すべてのアプリが利用できる」「サーバーが必ず使えない」と同じ意味ではありません。Test Methodによって確認する通信経路の段階が異なる場合があるため、結果を比較するときは同じテスト方法を使ってください。
次にSafariを開き、自分に利用権限があり、正常に動作することがわかっているページにアクセスします。トップページが表示されるかだけでなく、ページ内の必要なリソースが読み込まれるか、実際のログインやサービス利用が正常に行えるかも確認してください。ページをすでに開いていた場合は、キャッシュだけで判断しないよう一度再読み込みします。あるページにアクセスできても、その1回のリクエスト経路が機能したことを示すだけで、他のドメイン、プロトコル、アプリでの動作を保証するものではありません。
Configで確認する場合は、対象への通信がPROXYとDIRECTのどちらに振り分けられる想定か、まず確認してください。一部の通信が直接接続される設定は正常な場合があります。あるサービスが従来のネットワーク経路を使っているだけで、アプリが機能していないと決めつけないでください。特定の対象だけを確認したい場合は、同じサーバーとネットワークを維持したまま一時的にProxyに切り替えて再試行し、2つのモードでの違いを記録します。テスト後は日常利用に適した設定に戻してください。
直接接続との比較もできます。接続を切った状態での対象の動作を記録し、接続後にもう一度試してください。比較中にWi-Fiとモバイル通信を同時に切り替えたり、サーバーを変更したりしないでください。変化がどの操作によるものか判断できなくなります。バックグラウンド通信の影響を減らすため、確認時は対象を絞って明確なページだけを操作してください。ログイン、決済、機密性の高いサービスについては、そのサービス自体の案内に従い、ネットワークテストの結果だけでアカウントの状態を判断しないでください。
- まず接続状態を記録：Homeで接続が維持されているか、明確なエラーが表示されたかを確認します。
- 次にテスト条件を記録：選択中のサーバー、Global Routing、Test Method、使用したネットワーク（Wi-Fiまたはモバイル通信）を記録します。
- 最後にアクセス結果を記録：対象ページが開くか、読み込みとログインのどちらの段階で失敗したか、ConfigとProxyを切り替えたときにどのような違いがあったかを記録します。
この手順の完了条件は、特定の遅延値が表示されることではありません。接続が安定して維持され、想定する対象に同じ条件で繰り返しアクセスできることです。テスト結果が表示されてもアクセスに失敗する場合は、その違いを記録し、次の手順で失敗箇所を確認してください。数値を小さくするためにプロトコルのパラメーターを何度も変更しないでください。
STEP 05 / CHECK
Settings：問題が起きた箇所からトラブル対処
設定を変更する前に、問題を具体的な段階に分類します。サブスクリプションを更新しても項目が追加されない、Connectivity Testがタイムアウトする、接続スイッチが維持されない、特定のサービスだけ開けない場合では、確認する内容が異なります。一度に変更するのは一項目だけにし、同じテストを再実行してください。改善がなければ元の値に戻してから次の項目を試します。ネットワーク、モード、パラメーターを同時に変更するより、原因を判断しやすくなります。
情報を取得できない場合：ルーティングより先にサブスクリプションを確認
SERVERに目的の項目がない場合は、サブスクリプションの記録に戻り、URLが完全か、アクセス情報が有効か、更新時にどのようなエラーが表示されたかを確認します。サブスクリプションの取得に特定のネットワーク条件が必要か確認し、情報を入手した相手に形式と有効状態を問い合わせてください。サブスクリプションURLを公開ページに掲載したり、重複したサブスクリプションを何度も追加してエラーを覆い隠したりしないでください。情報を取得できてから、個々のサーバーをテストします。
テストのタイムアウト・接続失敗：パラメーターと現在のネットワークを確認
Type、Host、Port、認証情報を一つずつ確認します。貼り付けによる空白、ポート番号の入力ミス、プロトコルの選択違いに注意してください。追加の通信パラメーターやTLSパラメーターがある場合は、元の案内と照合します。検証をむやみに無効にしないでください。さらに、端末の日付、時刻、タイムゾーンが正しいか確認します。システム時刻のずれによって安全な接続に影響が出ることがあります。
SettingsでTest Methodを開き、同じ方式の探査結果を比較していることを確認します。特定の方式でタイムアウトしても、実際のアクセスが正常なら、その結果だけを理由に項目を削除しないでください。逆に、探査に応答があっても実際のアクセスに失敗する場合は、認証、通信設定、対象までの経路を確認します。必要に応じて他の条件を変えず、Wi-Fiとモバイル通信をそれぞれ試し、接続ネットワークによる違いか判断してください。
一部のリクエストだけ失敗する場合：モードを比較してルールを特定
同じサーバーでProxyなら正常に動作し、Configでは問題が起きる場合は、まずConfigに戻り、現在のファイルとRuleを確認してください。DIRECTやREJECTに一致していないか、想定と異なるポリシーを参照していないかを確認します。ファイル末尾にルールを追加するだけで、それ以前の一致を上書きできるとは限りません。ルールの順序も結果に影響します。判断が難しい場合は元の設定を保ち、対象のドメイン名と2つのモードでの動作を記録してください。
接続状態が何度も変わる場合：On Demandと診断情報を確認
手動で切断しても再接続する場合や、ネットワークの切り替え時に状態が何度も変わる場合は、SettingsでOn Demandに接続条件が設定されているか確認します。手動接続のテスト時にその条件を記録し、必要に応じて一時的に無効にして、同じ現象が続くか確認してください。初回のトラブル対処では、Proxy、TCP、UDPなどのグループにある詳細設定をむやみに変更しないでください。これらの項目をすべて有効にすることが、接続失敗の一律の対処法ではありません。
さらに詳しく調べる場合は、SettingsのDiagnosticsを開き、問題が発生した時刻と合わせて関連情報を保存してください。診断情報を共有する前に、サブスクリプションURL、認証情報、個人のアドレスなど、機密情報を隠します。再現に必要なエラーメッセージと条件だけを共有してください。タイムアウトについてはサーバーのタイムアウトと接続失敗を確認する手順、システムの許可についてはVPN構成の追加を求める画面についてをご覧ください。
