Shadowrocket
追加と接続の手順
設定済み情報 → モード選択 → 接続 → 確認 → トラブル対処
このページではiPhoneとiPadを対象に、初回利用の流れに沿って、操作する場所や確認事項、次の手順へ進むタイミングを説明します。スクリーンショットはApp Store公式のものです。実際の画面はお使いのデバイスでご確認ください。
STEP 01 / IMPORT
サーバーの追加とサブスクリプションの読み込み
まず、手元の情報がどちらに当たるか確認します。サーバー一覧を更新するためのURLだけがある場合は、通常サブスクリプションです。プロトコル、サーバーアドレス、ポート、認証情報が含まれている場合は、サーバーを個別に追加できます。両方の方法を重ねて行う必要はありません。サブスクリプションがある場合は、同じ配信元から一覧を更新できるため、サブスクリプションでの追加がおすすめです。サーバーのパラメーターしかない場合は、項目ごとに入力してください。
既存のサブスクリプション：Subscribeを選択
Shadowrocketを開いてHomeに移動し、右上の追加ボタンまたはリスト内のAdd Serverをタップします。追加画面でTypeをタップし、Subscribeを選択します。ご自身のサブスクリプションURLを対応するURL欄に入力して保存してください。スクリーンショットはサーバーを個別に追加する画面です。Typeを切り替えると入力項目も変わるため、スクリーンショットに表示されているHost欄にサブスクリプションURLを入力しないでください。
貼り付ける前後にURL全体が正しく入力されているか確認してください。特に疑問符以降のパラメーター、末尾の文字、チャットアプリからコピーした際に混入する空白や改行に注意しましょう。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開コメントやスクリーンショットに載せないでください。保存後にHomeへ戻り、読み込みが終わるまで待ちます。サブスクリプショングループの下にサーバーが表示されていることを確認してください。サブスクリプション名が増えただけでは、サーバー一覧の読み込みが完了したとは限りません。
リストが空のままの場合は、サブスクリプションを正常に更新できるか、URLが有効か、現在のネットワークからURLにアクセスできるかを確認してください。更新の失敗とサーバー接続の失敗は別の段階です。前者はまだ一覧を取得できていないため、接続スイッチを何度も操作しても解決しません。エラーの詳しい意味はトラブルシューティングをご覧ください。
既存のサーバーパラメーター：Add Serverに入力
Add Serverで、まず手元の情報に合ったTypeを選択し、HostとPortを入力します。スクリーンショットのPasswordとMethodは、そのTypeにおける項目例です。ほかのプロトコルでは、異なる認証項目や通信設定が表示される場合があります。入力欄をすべて埋めようとして値を推測したり、あるプロトコルのパスワードを別のプロトコルに流用したりしないでください。
Hostにはサーバーのドメイン名またはアドレスを、Portには対応するポート番号を入力します。ほかの項目は、契約先またはサーバーの設定情報と照らし合わせて確認してください。TrojanなどTLS設定があるTypeでは、サーバー名などの関連パラメーターも確認が必要です。アドレスとパスワードだけでは不十分な場合があります。QRコードの情報はScan QR Codeで読み取れますが、読み取り後もTypeと接続先サーバーが正しいか確認してください。
保存してHomeに戻り、SERVERリストに新しい項目があることを確認します。次に、使用するサーバーを一つ選択してください。リストに表示されていることは情報が保存されたことを示すだけで、接続が確立したことを意味しません。この手順の後で、リクエストをどのモードで処理するかを決めます。
STEP 02 / ROUTING
Global Routingを選択
Homeに戻り、Global Routingをタップします。ここではリクエストに適用する接続方針を選びます。サブスクリプションの配信元を選ぶ画面ではありません。まずはConfig・Proxy・Directの3つのモードを理解しましょう。どれを選ぶかは今回確認したい内容に応じて判断し、常に特定のモードが適切だと決めつけないでください。
Config：現在の設定に基づいて処理
Configでは、現在の設定ファイル内のルールに従ってリクエストの接続先が決まります。アプリのConfigページを開き、使用する設定ファイルが追加され、選択されていることを確認してください。契約先からサーバーのサブスクリプションを受け取っただけで、ルール設定も同時に読み込まれているとは限りません。サーバーリストは接続先を提供し、設定ファイルはリクエストの処理方法を定めます。
右側の公式スクリーンショットは、設定編集画面のGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionの各セクションを示しています。初回接続時に、各セクションを編集する必要はありません。サブスクリプションURLをRuleに貼り付けたり、この手順を完了させるためだけに現在の目的に関係のない機能を有効にしたりしないでください。
たとえば、次のルールは「example.comおよびそのサブドメインに一致する場合はPROXYを使用し、それ以外のリクエストはDIRECTにする」という意味です。これは構文の一部を理解するための例であり、既存のファイルを置き換える完全な設定ではありません。また、すべてのWebサイトに同じ方針を適用すべきという意味でもありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTConfigモードでは、一部のリクエストが直接接続され、別のリクエストがProxyを使用することがあります。これはルールの想定どおりの動作かもしれません。マッチ順、ポリシー名、フォールバックルールを調整する場合は、ルールと設定ファイルの総合ガイドをご覧ください。初回接続時に設定全体を一度に変更しないでください。
ProxyとDirect
Proxyでは通常のリクエストを選択したプロキシに送ります。原因を一時的に絞り込むために、まずサーバー経由でアクセスできるかを確認し、その後Configに戻ってルールの違いを調べる際に利用できます。Directは選択したプロキシサーバーを経由せず、直接接続します。そのため、接続スイッチがオンでも、そのサーバーを使用しているとは限りません。
モードを選んだらHomeに戻り、Global Routingに選択したモードが表示されていることを確認してください。Proxy接続だけを確認したい場合は、元のモードを控えてから一時的にProxyを選択します。確認が終わったら、通常利用するConfigに戻してください。次に接続を開始します。「情報の保存」「モードの選択」「接続の確立」を混同しないよう、順番に確認しましょう。
STEP 03 / CONNECT
スイッチをオンにしてシステムの許可を完了
Homeに戻り、SERVERで接続するサーバーが選択されていることをもう一度確認します。サーバー項目の編集画面を開いただけでは選択したことになりません。続けてGlobal Routingを確認し、最後に画面上部の接続スイッチをオンにします。右側のスクリーンショットに表示されているNot Connectedは未接続時の状態です。スクリーンショットが現在のデバイスの状態を示しているわけではありません。
初回接続時、システムからVPN構成の追加許可を求められます。システムのダイアログを読み、今回の操作によって表示されたことを確認したうえで許可し、案内に従ってデバイスのパスコードなど、システムが求める認証を完了してください。ここで行うのは、アプリによるシステムのネットワーク接続設定を許可することです。サーバーのパスワード入力とは別の操作です。システム認証はシステム画面で行い、Add ServerのPassword欄には入力しないでください。
システムの許可を取り消した場合は、アプリに戻って接続をもう一度開始し、確認画面が再び表示されるか確認してください。許可が完了していない状態で、スイッチが自動的にオフになることをサブスクリプションの無効化と判断したり、すべてのサーバーをすぐ削除したりしないでください。まず必要な許可を完了し、その後の状態を確認すれば、不要な変更を減らせます。
接続状態はHomeに戻って確認
許可が完了したらShadowrocketに戻り、画面上部の状態がNot Connectedから変わったか、スイッチがオンのままか、エラーが表示されていないかを確認してください。システムのVPNアイコンはトンネルの状態を確認する手がかりになりますが、特定のWebページに適用された方針を示すものではなく、すべてのサーバー項目が正しいことを証明するものでもありません。
スイッチがすぐにオフになる場合は、表示されたメッセージを記録し、アプリにシステム権限があることを確認してから、ほかのVPN接続が今回のテストに影響していないか調べてください。スイッチを短時間に何度も切り替えないでください。接続が安定する前にサブスクリプションの更新、モードの変更、設定の編集を同時に行うと、どの操作が結果に影響したのか分かりにくくなります。
スイッチがオンのままになったら、選択中のサーバーとモードをそのまま保ち、次の手順で確認します。接続を終了するときはHomeに戻り、同じスイッチをオフにしてください。初回テストが完了するまでは、On Demandを有効にする必要はありません。オンデマンド接続の条件によって、手動テスト時の状態が分かりにくくなるのを防げます。
STEP 04 / VERIFY
接続と実際のアクセスを確認
確認は3段階に分けて行います。サーバーテストに結果が出るか、実際のWebページが読み込めるか、リクエストが想定した方針で処理されるかを確認します。3つは関連していますが、互いに代用できません。スイッチがオンであることやテスト結果の数値だけを見ると、名前解決、認証、ルール、接続先サイト自体の問題を見落とすことがあります。
Connectivity Testで接続性を確認
HomeでConnectivity Testをタップし、テストの完了を待って、選択したサーバーの結果を確認します。現在到達できない接続先を見つける手がかりになりますが、結果はテスト方法やネットワーク環境によって変わります。数値が小さくてもすべてのWebページが開けるとは限りません。テストに失敗した場合も実際のアクセス結果と合わせて判断し、サブスクリプションの内容がすべて無効になったと決めつけないでください。
同じサブスクリプションに複数のサーバーがある場合は、ネットワーク、モード、設定を変えずに別のサーバーを選んで再テストできます。条件をまとめて変更せず、一つの要素を比較する方法です。テスト数値を上げるためにプロトコルの項目を頻繁に変えないでください。パラメーターの正しさは、ご自身のサーバー情報を基準に確認してください。
実際のリクエストでアクセス結果を確認
接続をオンにしたままブラウザーに切り替え、普段利用していてアクセス権のあるWebページを開きます。タイトルだけでなく本文まで読み込まれることを確認し、通常利用する別のページでも同様に試してください。一つのWebサイトだけが開けない場合、そのサイト自体やアカウントの状態、該当するルールに問題がある可能性があります。接続全体の失敗とすぐに判断しないでください。
Configを使用している場合は、アプリ内のリクエスト記録で対象ドメイン、適用されたルール、ポリシーを確認します。Proxyを使う想定のリクエストには、対応するProxyポリシーが適用される必要があります。直接アクセスする想定のリクエストはDIRECTに一致する場合があります。記録の内容は現在のアプリの表示を確認してください。Directモードでアクセスに成功しても、プロキシサーバーの動作確認ができたことにはなりません。
必要に応じて現在の設定を控え、一時的にProxyに切り替えて同じ接続先を再確認し、その後Configに戻します。Proxyでは成功しConfigで失敗する場合は、ルール、ポリシーの参照先、名前解決の違いを優先して確認してください。両方のモードで失敗する場合は、サーバー情報とネットワークを優先して確認します。テスト後は通常利用するモードに戻し、動作確認済みの設定を以降のトラブル対処の基準として残してください。
STEP 05 / DIAGNOSE
接続に失敗した場合の確認手順
失敗したときは、まず現象を具体的に記録します。サブスクリプションの更新に失敗するのか、スイッチがオンのままにならないのか、Connectivity Testに結果が出ないのか、Webページだけが開かないのかを確認してください。現象によって問題が起きている段階は異なります。以下の順に一つずつ確認し、設定は一度に一つだけ変更して、手順4の方法で再テストします。原因が分からないまますべてを作り直さないでください。
ローカルネットワークを確認してから接続情報を確認
Shadowrocketの接続をオフにし、現在のWi-Fiまたはモバイル通信で基本的なアクセスができるか確認します。ローカルネットワーク自体が使えない場合は、ネットワークへのログイン、電波状況、通信許可を先に確認してください。その後Homeに戻り、テストするサーバーが選択されていることを確認します。サブスクリプションの内容が最近変更された場合は、既存のサブスクリプションを更新して結果を確認してください。同じURLを何度も追加して項目を重複させないでください。
サーバーを個別に追加した場合はAdd Serverに戻り、Type、Host、Port、認証情報を一つずつ照合します。コピーした情報に空白が混じっている、ポートが違う、プロトコルの選択が一致していない場合、保存できても接続に失敗することがあります。TLSや追加の通信設定があるサーバーでは、関連パラメーターも確認してください。エラーを回避するために検証設定を安易に無効化せず、まずサーバー情報とデバイスの時刻が正しいか確認します。
テスト結果は出るがWebページが開かない
現在のGlobal Routingを記録し、同じリクエストをProxyとConfigで比較してください。Configだけで失敗する場合は、対象に適用されたルール、そのポリシーが利用可能なサーバーを参照しているか、FINALのフォールバックが想定どおりかを確認します。両方のモードで失敗する場合は、テスト結果に数値が表示されていても、サーバーの有効性、名前解決、実際のアクセス経路を確認してください。
DNSの問題とルールの問題は、似た症状になることがあります。エラー表示とリクエスト記録を確認し、アドレスが解決されているか、接続がタイムアウトしているか、REJECTに一致しているかを判断してください。ネット上で見つけたDNS設定全体を既存のファイルにそのまま上書きしないでください。まず元の設定を保存し、判明した原因に対して必要最小限の変更を行います。詳しくは接続と名前解決のトラブルシューティングをご覧ください。
Settingsを確認し、まとめて変更しない
Settingsを開くと、Test Method、On Demand、Diagnosticsのほか、Proxy、TCP、UDPなどの項目を確認できます。Test Methodはテスト方法に影響するため、結果を比較する際は同じ方法を使ってください。On Demandは条件に応じた接続に関係します。手動でトラブルを調べる場合は、接続が再度開始される条件になっていないか確認してください。SettingsのProxy項目とGlobal RoutingのProxyモードを混同しないでください。
さらに詳しく原因を調べる場合は、Diagnosticsに表示される項目を確認してください。エラーが発生した時刻、使用中のネットワーク、選択したモード、再現手順を記録すると、「接続できない」だけを記録するより役立ちます。利用中のサービスの提供元に問い合わせる前に、サブスクリプションURL、認証項目などのアクセス情報を隠し、問題に関係する状態とエラー情報だけを共有してください。
同じ条件で別のサーバーは使えるのに、現在のサーバーだけが繰り返し失敗する場合は、使える状態を保ったうえで、契約中のサービスの提供元に対象サーバーの状況を確認してください。すべての接続先で問題が起きる場合は、ローカルネットワーク、システムの許可、現在の設定を引き続き確認します。問題の種類についてはトラブルシューティング、ルールの書き方とファイル構成については設定の総合ガイドをご覧ください。これでサブスクリプションの追加から接続、確認までの初回手順は完了です。
