サブスクリプションの追加 → Global Routingの選択 → 接続許可 → 動作確認。まず一連の流れを完了してから、ルールやSettingsを調整します。
以下の手順はiPhoneとiPadを対象としています。スクリーンショットは該当画面の例です。表示される項目は選択したプロトコルによって異なる場合があります。入力する情報は、必ず手元の設定資料で確認してください。
どちらか一方の方法で追加してください。同じ情報を重複して登録する必要はありません。
Shadowrocketを開いてHomeを表示し、SERVERグループ付近のAdd Serverをタップして追加画面を開きます。TypeでSubscribeを選び、手元にあるサブスクリプションURLをURL欄に入力します。サブスクリプションURLはサーバー項目を取得するためのアドレスで、通常の案内ページとは異なります。サービス提供元に元のURLを確認し、ブラウザーのアドレス欄に表示された任意のページURLをサブスクリプションとして使わないでください。
貼り付けた後、URLの先頭から末尾まで確認します。前後に空白がないか、引用符や日本語の説明文が混ざっていないか、改行で内容が途切れていないかをチェックしてください。サブスクリプションURLには設定情報へアクセスするための認証情報が含まれる場合があります。信頼できるデバイスだけに保存し、公開スクリーンショット、チャットグループ、トラブルシューティングの記録には載せないでください。入力内容を確認して保存したらHomeに戻り、該当するグループとサーバー項目が表示されたことを確認します。
サブスクリプション名だけが表示され、選択できるサーバーがない場合は、接続スイッチをオンにしないでください。「URLを保存した」ことと「内容を取得して解析できた」ことは別です。現在のネットワークからURLにアクセスできるか、サブスクリプションが有効か、返された内容が要件を満たしているかを確認してから更新してください。同じサブスクリプションを何度も新規追加しても項目が重複するだけで、取得できないURLの問題は解決しません。
個別のサーバー情報を使う場合も、Add Serverを開き、資料と同じTypeを選んでからHost、Portと、そのプロトコルで必要な認証項目を入力します。スクリーンショットの項目を例にすると、PasswordとMethodはサーバー側の設定と一致させる必要があります。別のプロトコルを選ぶと表示項目も変わるため、前のプロトコルと同じ要領で入力しないでください。Hostには通常、サーバーのドメイン名またはIPアドレスを入力します。Webページのパスを勝手に追加しないでください。
Port、暗号化方式、Password、UUID、TLS、SNIなどの項目はそれぞれ用途が異なります。現在のTypeで必要な項目だけを入力してください。不明な項目がある場合は、よくある値を推測して入力せず、元の資料を確認します。QRコードがある場合はScan QR Codeで読み取り、認識されたTypeと各項目に誤りや不足がないか確認してください。Import from Cloud JSONは対応形式の設定情報を読み込む機能で、任意のサブスクリプションURLを読み込む汎用の入口ではありません。
保存してHomeに戻り、新しい項目が想定したSERVERグループにあることを確認して、使用するサーバーを選択します。表示名は項目を見分けるためのもので、接続が有効であることを示すものではありません。ここまでで完了したのは「情報を追加し、選択できる状態にする」ことです。次に、その情報をどのように使うかを決めてから接続します。プロトコルの項目がわからない場合はプロトコル用語集をご覧ください。初回設定ですべてのプロトコルを学ぶ必要はありません。
モードは通信の処理方法を決め、サーバー項目はプロキシ接続に使用する情報を決めます。
Homeに戻ってGlobal Routingをタップし、現在の選択を確認します。3つのモードはConfig、Proxy、Directです。Global Routing内のConfigと、設定ファイルを管理する画面下部のConfigを混同しないでください。前者はルーティングモードの選択、後者は設定ファイルの確認に使います。サーバーを正しく選んでも、通信の処理方法まで正しく選ばれているとは限りません。両方を確認してください。
利用可能な設定ファイルが手元にあり、ドメイン名やIPアドレスに応じて通信を振り分ける場合はConfigを選択します。続けてConfig画面を開き、使用中のファイルが想定したものか確認してからRuleを確認してください。設定ファイルとサブスクリプションは別のものです。サブスクリプションは主にサーバー項目を提供し、設定ファイルにはルール、DNSなどの処理設定が含まれる場合があります。サブスクリプションを更新しても、ルールが希望する設定ファイルに自動で切り替わるわけではありません。
スクリーンショットのGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは、設定編集画面の各セクションです。初回接続では、現在のファイルとRuleの用途を確認するだけで十分です。「設定を完了する」ために各項目を変更する必要はありません。Add Ruleではルールを追加できますが、動作はルールの順序やポリシー名に左右されます。関係を理解していない段階で、Web上で見つけた複数の設定をそのまま貼り合わせないでください。通常の接続確認にHTTPS Decryptionを有効にする必要もありません。
追加したサーバーが使えるか確認するだけなら、一時的にProxyを選んで、まずサーバー経由の接続経路を確認できます。利用できることを確認したら、Configに戻してルールによる振り分けを確認してください。Directのままでは、Webページが開いても選択したプロキシが動作している証拠にはなりません。選択後はHomeに戻り、Global Routingに表示される値をもう一度確認します。ルールの書き方や一致する順序についてはルールキーワードとポリシーを、設定ファイルの管理についてはConfig設定の詳細をご覧ください。
選択中の項目を確認してからスイッチをオンにします。初回の許可はシステム設定の手順です。
Homeに戻ります。接続する前に2点確認してください。SERVERでテストする項目が選択されているか、Global Routingが前の手順で決めたモードになっているかを確認します。サブスクリプションを更新した場合、項目名やグループが変わることがあるため、更新前の記憶に頼らず選択中の項目を確認してください。初回の確認ではサーバーを1つに絞り、テスト中に何度も切り替えないようにします。そうすることで結果と設定情報を対応付けやすくなります。
Home上部の接続スイッチをタップします。未接続の場合、画面上部にNot Connectedと表示されます。初回使用時に、システムからShadowrocketによるVPN構成の追加許可を求められることがあります。これはアプリがシステムのネットワーク拡張機能を使って接続するために必要な手順です。操作に応じて表示された案内であることを確認し、システムの手順に沿って許可して、デバイスで求められる認証を完了してください。ここで確認するのはデバイスの許可であり、サーバーのPasswordを入力する手順ではありません。
許可した後、Shadowrocketに戻り、スイッチと接続状態が維持されているか確認します。スイッチがすぐに戻る場合は、まずシステムの許可が完了しているかを確認し、その後、後述する接続の切り分けに進みます。根拠がないままサブスクリプションを何度も削除しないでください。システムのVPN表示が出ていても、次のテストを行ってください。この表示が示すのはシステムの接続状態であり、すべてのサーバーに到達できることや、すべてのWebページが想定どおりのポリシーで処理されたことを意味しません。
接続中にサーバー情報や設定ファイルを変更する場合は、どの層に対する変更かを明確にしてください。比較しやすくするには、いったん切断し、変更を保存してから再接続し、同じ対象で確認します。使用後はHome上部のスイッチで切断できます。切断後に再接続される場合は、On Demandが有効になっているか確認してください。詳しくはOn Demandの設定方法をご覧ください。オンデマンド接続の作動を、スイッチ操作が保存されていない状態と混同しないでください。
テスト結果、実際のアクセス、ルールに基づく通信経路をそれぞれ確認します。
HomeでConnectivity Testをタップし、結果が表示されるまで待ちます。テスト方式によって結果の意味は異なるため、SettingsのTest Methodで使用中の方式を確認できます。数値が表示されても、確認できるのはそのテスト条件で応答があったことだけです。すべてのプロトコル、接続先、アプリが正常だとは判断できません。
失敗した場合は、サーバーとモードを変更せず、どのネットワーク環境で失敗したかを記録します。1回タイムアウトしただけで設定全体を削除したり、数値の大小だけで実際の利用に最適な接続を判断したりしないでください。テスト方式の違いについてはPingとテスト設定をご覧ください。
実際に使うWebページやアプリを開き、もう一度リクエストを行って読み込みが完了するか確認します。キャッシュ済みのページだけで判断せず、新しいリクエストを試してください。必要に応じてページを再読み込みするか、開き直します。1回の成功が示すのは、その対象がその時点で利用できたことだけであり、ほかの通信の確認にはなりません。
アプリに戻り、現在のモード、設定、利用可能な通信ログを照らし合わせて経路を判断します。Configでは、リクエストがDirectのポリシーに一致する場合があります。Proxyで通信に成功しても、Configのルールが正しく書かれているとは限りません。
確認結果を、説明可能な一連の情報として整理します。選択中のサーバー、Global Routingのモード、テストの応答、目的の接続先が利用できるか、そのリクエストにどのポリシーが適用される想定かを確認してください。いずれか1つしか確認できていない場合は、DNSをすぐに変更したりルールを追加したりせず、残りの情報をそろえます。ログを確認する場合は、切り分けに必要なドメイン名、時刻、エラーの種類だけを記録してください。共有前にサブスクリプションURL、サーバー認証情報、その他の個人情報を削除します。
Configで「一部の接続先は使えるが、ほかは失敗する」場合、同じ接続先を使って一時的にProxyへ切り替えて再試行できます。モードによって結果が変わる場合は、設定ファイルと適用されたポリシーを優先して確認します。どちらのモードでも失敗する場合は、サーバー、現在のネットワーク、接続先を引き続き確認してください。これは原因を絞り込むための比較方法であり、恒久的な設定変更を推奨するものではありません。テスト後は必要な元のモードに戻し、一時的な切り分け設定を日常設定のままにしないでください。
一度に変更するのは1項目だけにし、同じ接続先で再テストします。サーバー、ルール、DNSを同時に変更しないでください。
Add Serverで設定したサブスクリプションを開き、TypeがSubscribeになっているか、URLが完全か確認します。サブスクリプションが有効で、ログインページや案内ページ、エラーメッセージではなく解析可能な設定内容が返されることを確認してください。元のURLが変更された場合は、利用中のサービス提供元から案内された有効な情報に更新します。この段階の問題はサーバー情報を取得する前に起きているため、通常はGlobal RoutingやDNSの変更を最初に行う必要はありません。
選択した項目の編集画面を開き、Type、Host、Portを元の資料と照合してから、認証情報とトランスポート層の項目を確認します。入力時に文字が抜けていないか、プロトコルを間違えていないか、別用途のポートを入力していないか、TLSやSNIが資料と一致しているかを特に確認してください。証明書やホスト名の確認の代わりに、Allow Insecureをむやみに有効にしないでください。関連するエラーが出た場合は、サーバーの情報とデバイスの時刻が正しいかを先に確認します。
同じ項目で現在のネットワークから接続できない場合は、使用が許可されている別のネットワーク環境でもテストし、ほかの設定は変えないでください。これにより、特定のネットワークだけで起きる問題か、すべてのテスト環境で起きる問題かを切り分けられます。ただし、結果だけで具体的な原因を断定することはできません。サーバーの状態をさらに確認する必要がある場合は、利用中のサービス提供元に必要なエラー情報を伝えてください。認証情報全体を送る必要はありません。
接続スイッチをオンにしてすぐオフになる場合は、まずシステムのVPN構成が許可されているかを確認し、システム上で別のVPN接続が使用中でないかを確認します。手動で切断した後に再接続される場合は、SettingsでOn Demandを確認してください。切り分け中は、設定済みのオンデマンド接続を一時的に無効にし、手動で接続を操作できます。元の設定を記録し、テスト後に戻してください。各オプションの条件と作動の仕組みについてはOn Demandのリファレンスをご覧ください。
まず前の手順と同じ方法でConfigとProxyを比較します。Configだけで問題が起きる場合は、Configに戻り、現在の設定ファイル、Ruleの順序、ポリシーの参照先を確認します。広範囲に一致するルールが前にあると、後続の詳細なルールより先に適用されることがあります。FINALはそれ以前のルールに一致しなかったリクエストに適用されます。ルールを追加しただけで、そのリクエストに必ず適用されると考えないでください。
ドメイン名の解決エラーが発生する場合は、現在の設定にあるDNS項目と、その接続可否を確認します。DNSはドメイン名からアドレスを取得する方法に影響し、プロキシサーバー情報は接続の確立方法に影響します。互いに代用できるものではありません。出所のわからないDNS設定を複数まとめて貼り付けないでください。元の値を記録し、変更するたびに同じドメイン名で再テストします。設定の詳しい仕組みはDNS設定の詳細をご覧ください。
SettingsでDiagnostics関連の診断項目を確認し、Test Methodでテストの前提条件を確認します。現在のモード、接続状態、問題が発生する接続先、おおまかな操作手順を記録すると、「使えない」とだけ説明するより原因を特定しやすくなります。スクリーンショットにあるToday Widget、Proxy、TCP、UDPなどはそれぞれ別の設定範囲です。特定の問題を解決するために、すべてを変更する必要はありません。症状との関係が明確な場合にのみ、該当する項目の説明を確認してください。
ここまでで、問題が「情報をインポートできない」「サーバーに接続できない」「システム接続が確立されない」「特定のリクエストでルールまたは名前解決に問題がある」のどこで起きているかを整理できるはずです。特定できない場合は、再現できる最小限の操作手順を記録し、よくある質問から症状に合う項目を探してください。初回設定では、動作を確認できる接続経路を1つ確立すれば十分です。基本の流れが安定してから、Widget、iCloud同期、詳細な設定項目をSettings設定の詳細で確認してください。
