Shadowrocketの使い方
追加、モード選択、接続、確認、トラブル対処の順に進めます。まず再現性のある接続を確認し、その後で自動接続や複雑なルールを調整します。
このページでは、iPhoneまたはiPadでの初回操作を説明します。まず、Wi-Fiまたはモバイル通信に接続し、通常のWebページが開けることを確認してから、サービス提供元から受け取った情報を用意してください。サブスクリプションURLには認証情報が含まれることがあるため、アプリ内でのみ入力してください。手動入力の場合は、プロトコル、サーバーアドレス、ポート、認証項目が明確に分かっている必要があります。サーバー名だけでは設定を開始できません。
説明は、アプリに現在表示されている内容を基準にしてください。画面上の項目名は英語のまま記載しています。掲載しているApp Store公式スクリーンショットは画面の確認用であり、サーバー設定値をそのまま入力するためのものではありません。iPadではウィンドウ幅によって画面の配置が変わることがありますが、操作の基本はHome、Config、Settingsです。対応デバイスとシステム要件はApp Storeの記載をご確認ください。
01 サーバーを追加する、またはサブスクリプションを読み込む
サブスクリプションの追加と手動入力は、どちらか一方で構いません。同じ情報を重複して追加する必要はありません。まずHomeを開き、Add Serverまたは画面上の追加ボタンからAdd Serverを開きます。最初にTypeを確認してください。選択したTypeによって、以降に入力する項目が変わります。スクリーンショットは一例です。別のプロトコルでは必要な認証情報や通信設定が異なる場合があるため、すべてのプロトコルに共通する入力画面として扱わないでください。
手持ちのサブスクリプションを使う場合：Subscribeを選択
サブスクリプションURLをお持ちの場合は、TypeでSubscribeを選び、完全なURLをURL欄に入力します。提供元が分かる名前を付けて保存してください。貼り付け後は、先頭や末尾に空白、改行、チャットの文章が混ざっていないか確認します。サービス提供元のログインページのURLをサブスクリプションURLと間違えないようにしてください。URL内の認証情報を削除すると、内容を取得できなくなる場合があります。
保存したらHomeに戻り、サブスクリプションのグループとサーバー項目が表示されているか確認します。グループ名だけが表示される場合は、サブスクリプションの更新結果を確認し、必要に応じて更新操作を行ってください。追加が完了したかどうかは、保存操作だけでなく、選択可能な項目が実際に表示されているかで判断します。取得に失敗した場合は、まずエラー内容を記録し、ネットワークとURLの有効性を確認してください。同じサブスクリプションを何度も追加するのは避けてください。
手動入力：Typeを選んでから各項目を入力
サーバー情報が1件だけの場合は、まず資料に記載されたTypeを選び、Host、Port、プロトコルに必要なPassword、Methodなどの認証項目を入力します。Hostには通常、サーバーのドメイン名またはIPアドレスを入力します。WebページのURL全体を貼り付けないでください。Portはサービス提供元の指定と一致させます。Passwordの大文字・小文字や記号はそのまま入力し、Methodもサーバー側の設定と一致させてください。名前が似ているからといって、別の値に置き換えないでください。
TLS、サーバー名、通信設定についても、手元のサーバー情報に従ってください。接続できないからといって、検証を無効にしたり、必要な項目を削除したりしないでください。Scan QR Codeは、出所を確認済みの手持ちのQRコードを読み取るための機能です。Import from Cloud JSONは別の読み込み方法で、該当する形式の情報がある場合にのみ使用します。どのサブスクリプションでもここから読み込めるという意味ではありません。
保存してHomeに戻ったら、SERVERから今回テストする項目を選択します。まず1つの項目だけで次の手順を進め、自動切り替えや複雑なポリシーは追加しないでください。問題がどの段階で起きているかを判断しやすくなります。この手順の完了条件：Homeに保存済みのサーバー項目が表示され、そのうち1つが選択されていること。次に通信の処理方法を選択します。
02 Global Routingのモードを選択する
Global Routingは通信全体の処理方法を決めます。サーバーを選択しただけでは、通信の振り分け方法は決まりません。HomeでGlobal Routingを開き、Config、Proxy、Directのどれが選択されているか確認してください。3つは用途が異なり、接続品質の段階を表すものではありません。ルールに従った通常利用なのか、サーバー経由の経路を一時的に確認するのかを明確にしてから選択します。
Config：選択中の設定ファイルのルールに従って処理
適切な設定ファイルをお持ちの場合は、Configを選択できます。次にConfigを開き、使う予定の設定ファイルが実際に選択されていることを確認してください。ファイルを以前読み込んだことがあるだけでは不十分です。設定画面のGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは、それぞれ異なる項目です。初回接続では、主に選択中の設定とRuleを確認します。他の項目を一つずつ変更する必要はありません。
Ruleは条件に基づいて、リクエストをどのポリシーで処理するか決めます。通常は上から順に確認され、先に一致したルールが最終的な処理先に影響します。末尾のFINALは、他のルールに一致しない場合の処理先です。たとえば、あるドメインがDIRECTに一致した場合、そのリクエストは直接接続されます。Homeでサーバーを選択していても、そのリクエストが自動的にPROXYへ切り替わるわけではありません。この仕組みを理解しておくと、「ルールどおりに直接接続された」状態を「アプリが動作していない」と誤解せずに済みます。
Proxy：プロキシ経由の処理を確認
初回のトラブル対処では、Proxyを使うとルールの影響を切り分けやすくなります。同じサーバーを選び、同じ接続先でテストしてください。ただし、すべての接続先にアクセスできるとは限りません。サーバーの接続性、DNS、接続先のサービス、関連設定も結果に影響します。テスト後、普段ルールを使っている場合はConfigに戻し、正しい設定が選択されていることを再確認してください。
Direct：直接接続の経路を確認
Directは、通常、選択中のプロキシサーバーを経由せずに直接接続します。プロキシ経由の経路と比較する際に使えますが、プロキシサーバーが利用可能であることを示すものではありません。Directに切り替えた後で通常のWebページが表示された場合、今回のリクエストが直接接続で完了したことだけが分かります。サーバーと設定ファイルは引き続き確認し、2つの経路のテスト結果を混同しないでください。
この手順では、目的を明確にしてモードを1つ選び、現在の選択を覚えておきます。ルール、サーバー、DNSを同時に変更すると、結果が変わっても原因を特定できません。この手順の完了条件：現在のモードと、Configに対応する設定ファイルが選択されているかを説明できること。購入、ストアの地域、購入済みアプリの復元については、App Storeで正規版を入手するための完全ガイドをご覧ください。ここでルールを変更して解決する問題ではありません。
03 接続を開始して状態を確認する
サーバーとモードを確認してから、Home上部の接続スイッチをオンにします。Homeに戻り、SERVERで選択中の項目とGlobal Routingを確認してください。直前にサーバーを編集した場合は、保存して編集画面を閉じたことを確認します。上部にNot Connectedと表示されている間は接続されていません。サーバー一覧に項目があるだけで、接続が始まったと判断しないでください。
上部のスイッチをオンにすると、初回はシステムからVPN構成の追加を求められることがあります。これは、アプリのネットワーク構成を作成するために必要なシステムの許可手順です。使用中のShadowrocketからの要求であることを確認してから、デバイスの案内に従って許可し、必要な認証を完了してください。以前に拒否した場合は、もう一度接続を開始してシステムの表示を確認します。用途が分からないまま、デバイス上の他のネットワーク構成を削除しないでください。
許可後にHomeへ戻り、上部の状態が接続済みに変わったか確認します。スイッチがすぐに戻る、または未接続のままの場合は、表示されたエラーを記録し、トラブルの原因を確認してください。スイッチを何度も素早く切り替えるのは避けてください。システム設定に他のVPN構成がある場合は、現在実際に有効になっている構成も確認し、別の構成の状態を今回の接続結果と取り違えないようにします。
重要な点として、システムのトンネルが接続済みであることは、該当するネットワーク構成が起動したことを示すだけです。選択中のサーバーがすべてのリクエストを正常に処理したことや、特定のWebサイトにアクセスできることを保証するものではありません。サーバーとモードはそのままにして、次の手順で実際のリクエストを確認してください。上部のスイッチやデバイスのステータスバーにあるネットワーク表示だけでは、接続を検証できません。
テスト中に接続を停止する場合は、Homeに戻ってスイッチをオフにし、未接続になったことを確認してください。オフにしても自動的に再接続する場合は、スイッチを何度も押さず、SettingsでOn Demandの条件を確認します。この手順の完了条件：許可の確認画面の意味を理解し、Homeで接続状態の変化を確認できること。次にテストと実際のアクセスの両方で確認します。すぐに設定を追加する必要はありません。
04 テスト結果と実際のアクセスを確認する
接続状態、サーバーのテスト、接続先へのアクセスは、それぞれ分けて確認してください。互いに代用することはできません。先ほどと同じサーバーとGlobal Routingのまま、HomeでConnectivity Testを実行します。テスト結果が返るか、タイムアウトするかを確認し、続けて普段から使っていて、表示を確認できるWebページを開き、最後まで読み込まれるか確認してください。特定の数値だけを見たり、キャッシュに残っているページを新しいリクエストの成功と見なしたりしないでください。
Connectivity Testの結果は、現在のテスト方法によって意味が異なります。成功しても、すべてのプロトコル機能や任意のWebサイト・アプリが正常に動作するとは限りません。タイムアウトの場合も、使用中のテスト方法と実際のリクエストを合わせて判断してください。テストが正常でも特定の接続先だけ失敗する場合は、その接続先、DNS、ルールの経路を確認します。すべてのサーバーが使えないとすぐに判断しないでください。
Configを使う場合は、リクエストに適用されたポリシーを確認
Configを使用している場合は、アプリ内で確認できる接続ログから対象のリクエストを確認します。接続先のドメイン、一致したルール、適用されたポリシーに注目してください。直接接続する想定のリクエストはDIRECTに、プロキシ経由の想定のリクエストは該当するプロキシポリシーに一致している必要があります。Dataの通信量の変化は参考になりますが、通信量の合計だけでは特定のリクエストがどのルールに一致したか分かりません。
比較する場合は、現在のConfigを記録してから一時的にProxyへ切り替え、同じサーバーを使って同じ接続先にアクセスします。Proxyでは成功し、Configでは失敗する場合は、設定ファイルの選択、ルールの順序、ポリシーとの関連付けを優先して確認してください。どちらも失敗する場合は、サーバー情報とネットワーク経路を確認します。比較後は元のモードに戻し、一時設定のままにならないようにしてください。
1回のテストで変更する条件は1つだけ
現在のネットワーク、選択中のサーバー、Global Routing、エラー内容の4項目を簡単に記録しておくと便利です。次のテストでは、そのうち1つだけを変更して同じテストを行います。たとえば、Wi-Fiとモバイル通信だけを切り替え、PasswordやDNSは同時に変更しません。こうすることで違いから原因を絞り込みやすくなり、サービス提供元に状況を伝える際にも役立ちます。
この手順の完了条件：実際のリクエストが完了し、想定した経路で処理されていること。特定のアプリ、ドメイン、種類のリクエストだけに問題がある場合は、その範囲を具体的に記録してからトラブル対処に進みます。部分的な失敗を「すべて接続できない」とまとめないでください。初回の手順を確認できたら、個別のルールを少しずつ元に戻すか追加します。
05 よくある失敗の原因を順に確認する
ネットワーク、追加情報、サーバー設定、ルール、名前解決の順に確認し、すべての設定を一度にリセットしないでください。まず今回の接続を停止し、Wi-Fiまたはモバイル通信が使える状態か確認します。ネットワークへのログインが必要な場合は、先に接続を完了してください。ネットワークの基本状態を確認する前に、サブスクリプションを何度も更新したり、サーバー項目を作り直したりしても、原因を特定する手がかりにはなりません。
サブスクリプションに項目がない場合：取得状況を確認
保存済みのSubscribeを開き、URLが完全で有効か、更新時にどのようなメッセージが表示されたかを確認します。サブスクリプションを取得できない問題と、サブスクリプション内の特定サーバーに接続できない問題は別です。前者ではURLの取得状況と内容の形式を、後者ではサーバーの設定と利用可能性を確認します。更新前に現在使える情報を残し、原因が分からないまますべての項目を削除しないでください。
項目はあるのに接続できない場合：各項目を照合
該当するサーバーの編集画面を開き、元の情報とType、Host、Port、認証項目、通信設定を一つずつ照合します。TLSを使用している場合は、サーバー名と関連設定も確認し、システムの日付と時刻が正しいか確認してください。Passwordだけを確認しても不十分です。プロトコル、ポート、必須の通信項目が一致していない場合も、タイムアウトや接続失敗が起きることがあります。サーバー情報が変更されている場合は、サービス提供元から受け取った最新情報を使って再確認してください。
一部のリクエストだけ失敗する場合：ルールとDNSを確認
まずGlobal Routingが一時的なテストモードのままになっていないか確認します。Configを使用している場合は、選択中の設定ファイルと一致するルールを確認してください。特定のドメインだけに問題がある場合は、そのリクエストに想定したポリシーが適用されているかを重点的に確認します。DNSを変更する際は現在の設定を残し、「ドメインを名前解決できない」場合と「名前解決後に接続できない」場合を区別してから、1項目ずつ変更してください。DNS設定の変更を、すべての問題に対する一般的な解決策として扱わないでください。
Settingsでテスト方法と自動接続の設定を確認
Settingsを開き、Test Method、On Demand、Diagnosticsなどの項目を確認します。Test Methodによってテスト結果の解釈が変わるため、2回の結果を比較する場合は同じ方法を使ってください。On Demandは条件に応じて接続を再開することがあります。手動でオフにしても再接続する場合は、画面上部のスイッチの故障と判断する前に、その条件を確認してください。初回のトラブル対処では関連する自動接続条件を一時的に無効にし、手動接続を確認してから元に戻す方法もあります。
Diagnosticsを使う場合は、直近に発生した1回の失敗に絞って情報を確認し、時刻、ネットワーク環境、サーバーの種類、エラー内容を記録してください。スクリーンショットや診断情報を共有する前に、サブスクリプションURL全体、Password、認証情報、その他の機密情報を隠し、問題の特定に必要な部分だけを残します。システム上は接続済みなのに対象のリクエストが失敗する場合、具体的な記録が「使えない」という説明より役立ちます。
修正後は接続を開始し、動作を確認して、同じ手順を繰り返し、結果が変わったことを確認します。その後、普段使うConfigとOn Demandの設定に戻してください。購入アカウント、ストアでの表示、機種変更後のアプリ復元については、正規版ガイドをご覧ください。これらはサーバー情報の確認とは別の手順であり、ネットワークルールを書き換えて解決する問題ではありません。
