Shadowrocket
追加と接続の手順
5つの手順で初期設定を行います。既存の情報を追加し、モードを選択して接続を開始し、動作を確認した後、失敗した段階に応じて原因を調べます。iPhoneとiPadでの操作を説明します。まず接続を一つ確立してから、細かなルールを調整してください。
- 既存のサブスクリプションまたはサーバー情報
- Add Server / Subscribe
- Config / Proxy / Direct
- Connectivity Test
掲載している画像はすべてApp Storeの公式スクリーンショットで、画面や項目の確認に使用しています。画像内の情報は接続に使用できません。実際の選択肢は現在のアプリ画面でご確認ください。
Add Server / Subscribeで追加・インポート
サーバー情報には接続に必要なパラメータを保存し、サブスクリプションでは複数のサーバー情報を取得・更新します。まず手元の情報の種類を確認してください。完全なサブスクリプションURLがある場合はSubscribeを使います。プロトコル、アドレス、ポート、認証情報がある場合はAdd Serverで手動入力します。両方を同時に設定する必要はありません。また、サブスクリプションURLをHostに入力しないでください。
サブスクリプションリンクがある場合:Subscribeを選択
ShadowrocketのHomeを開き、SERVER欄のAdd Serverを選択します。Typeを開いてSubscribeを選択し、該当するURL欄にご自身のサブスクリプションリンクを貼り付けます。見分けやすいメモを入力して保存してください。Subscribeは既存のサブスクリプションを追加する画面で、アプリの購入画面ではありません。保存後にHomeへ戻り、リクエストが完了するまで待ってから、サブスクリプショングループとサーバー情報が表示されるか確認します。サブスクリプション名だけが表示され、サーバー情報がない場合は、取得結果も確認してください。
貼り付ける前に、URL全体が正しくコピーされているか確認してください。特に疑問符以降のパラメータ、大文字・小文字、末尾の文字に注意します。チャットの文章に含まれる改行、前後の空白、句読点をURLに混ぜないでください。以下はURLの形式を示すだけで、接続には使用できません。ご自身のアドレスを使い、実際の認証情報を含むリンクを公開ページや相談用スクリーンショットに載せないでください。
https://example.com/sub?token=xxxx
サブスクリプションを更新できるかどうかは、リンクの有効性、現在のネットワーク、サブスクリプションURLの応答によって変わります。更新に失敗した場合は、既存の情報を残したまま、ご自身のサブスクリプションが有効か確認してから再読み込みしてください。同じURLを何度も追加しても重複グループが増えるだけで、リクエストの失敗は解決しません。ルール設定も必要な場合は、別途Configを確認してください。サーバー一覧が表示されても、現在のルール設定が準備できているとは限りません。
単一のサーバー情報がある場合:Add Serverに入力
Add Serverで最初にTypeを選び、プロトコルに対応する項目を入力します。スクリーンショットの画面では、Hostはサーバーアドレス、Portはポート番号です。PasswordとMethodは、手元の情報と一致させてください。Typeを切り替えると項目が変わる場合があります。たとえばVMessやVLESSでは認証や転送に関するパラメータが異なるため、あるプロトコルの項目を別のプロトコルにそのまま流用しないでください。分からない項目は用語解説で確認してから、このページに戻ってください。
手動入力では、アドレスに余分なパスが含まれていないか、ポート番号が揃っているか、認証情報に空白を誤ってコピーしていないかを一つずつ確認します。TLS、転送方式、関連するホスト名も既存の情報に合わせて入力してください。入力欄を埋めるために値を推測しないでください。情報が不足している場合は、情報の提供元に確認してください。Typeを変えるだけでは、不足しているパラメータは補えません。
対応するQRコードがある場合はScan QR Codeでインポートし、追加後に各項目を確認してください。Import from Cloud JSONは、既存の対応形式の設定を取り込むためのもので、一般的なサブスクリプションURLの代わりにはなりません。保存したらHomeに戻り、SERVERに情報が表示されることを確認します。ここまでで完了したのは「接続情報の保存」です。次に、通信をどのように処理するかを選ぶ必要があります。
Global Routingの3つのモード
サーバー情報を保存したらHomeに戻り、Global Routingを開きます。ここで選ぶのは通信全体の処理方法であり、サーバーのプロトコルやサブスクリプションの更新方法ではありません。このチュートリアルでは、Config、Proxy、Directの3つの表記を使用します。括弧内の名称はアプリ画面の表示と同じです。目的を確認してから選ぶことで、モードの変更をサーバーの不具合と誤認しにくくなります。
| モード | 処理方法 | 今回の操作での用途 |
|---|---|---|
| Config | 現在の設定にあるルールとポリシーに従って通信を処理します。 | 利用可能な設定がある場合に、ルールによる振り分けが意図どおりか確認します。 |
| Proxy | Proxy経由で通信を処理します。実際の処理範囲はアプリとシステムの仕様に従います。 | 選択したサーバーで実際にアクセスできるか、一時的に確認します。 |
| Direct | 通信を直接処理します。 | 現在のネットワークでの通常のアクセス状況と比較します。 |
Configを使う前に現在の設定を確認
利用するルール設定がある場合は、まずConfigを開き、使用する設定が選択または有効になっていることを確認します。ファイルをリストに保存しただけでは不十分です。該当する設定を開き、Ruleのルールと参照先のポリシーを確認してください。公式スクリーンショットにはGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionなどのセクションが表示されています。初めて使う際は、主にGeneralとRuleを確認すればよく、すべての項目を変更する必要はありません。
Configモードでは、リクエストがDirectになるのがルールの想定どおりという場合もあります。ルールは通常、上から順に照合され、先に一致したリクエストは後続の最終ルールでは処理されません。以下は構文の説明用です。DOMAIN-SUFFIXはドメインのサフィックスに一致し、FINALはそれまでのルールに一致しなかった通信を処理します。PROXYは、現在の設定にある利用可能なポリシーまたはポリシーグループに対応している必要があります。この例を、ご自身の設定を確認せずにそのまま使わないでください。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
サーバー情報しかなく、ルール設定をまだ確認できていない場合は、一時的にProxyを使って選択したサーバーを確認し、その後Configに戻って通信の振り分けを確認できます。Directは通常のネットワークとの比較に使えますが、Directを選択してページが開いても、選択したサーバーが動作している証明にはなりません。モードを切り替えたらHomeに戻り、表示を確認してください。接続中にモードを変更した場合は、実際にアクセスし直して確認し、前回のテスト結果だけで判断しないでください。
初回の動作確認では、Add Ruleの編集もHTTPS Decryptionの有効化も必要ありません。まず現在の設定の動作を把握し、その後で項目を一つずつ調整してください。ルールのキーワードは用語解説で確認できます。3つのモードの詳細はGlobal Routingモードの解説をご覧ください。モードを確認したら、次にシステム接続を確立します。
Homeでサーバーを選び、接続スイッチをオン
Homeに戻り、SERVERで保存またはサブスクリプションから追加したサーバーを選択します。テストするサーバーが選択されていることを確認してください。サブスクリプションに複数の情報がある場合は、まず一つに絞って確認します。サーバー、モード、設定を同時に変更すると、どの変更が結果に影響したのか分かりにくくなります。Configでポリシーグループを使う場合は、実際に使用するポリシーも確認してください。Homeで選択したサーバーが、すべてのルールで最終的に使用される接続先とは限りません。
Global Routingの表示をもう一度確認し、前の手順で選んだモードと一致していることを確かめてから、Home上部の接続スイッチをオンにします。初回接続時に、ShadowrocketによるVPN構成の追加を許可するようシステムから求められる場合があります。自分の操作で表示された確認画面であることを確かめ、案内に従って許可し、デバイスで指定された方法で本人確認を行ってください。これはシステム接続に必要な許可であり、サーバーのパスワードをインポートする手順ではありません。
許可が完了したらShadowrocketに戻り、上部の表示がNot Connectedから接続状態に変わったか確認します。スイッチがすぐにオフに戻る、または未接続のままの場合は、まずシステムの許可が完了しているか確認し、次に現在のサーバー情報と設定を確認してください。システムの確認画面を閉じた後に接続済みと思い込んだり、スイッチが一度点灯しただけで確認を終えたりしないでください。
iPhoneとiPadで操作の順序は同じですが、画面のレイアウトはデバイスによって異なる場合があります。システム上のVPN状態は補助的な確認に使えますが、それだけでは接続先サーバーへの到達、ドメインの名前解決、ルールの一致を証明できません。続けてConnectivity Testを実行し、実際のページにアクセスしてください。デバイスで別のVPN接続が動作中の場合は、システムで実際に有効になっている接続を確認し、複数の接続操作が影響し合わないようにしてください。
サーバー情報を変更する場合は、先に接続を切って編集し、保存後に接続し直してテストできます。初めて使う際はOn Demandの調整も後回しにしてください。まず手動で接続と切断を行い、基本動作を確認してから自動接続の条件を設定します。選択中のサーバーとモードを変えずに次へ進み、テストと実際のアクセスの両方で動作を確認してください。
Connectivity Testと実際のアクセスを確認
確認する項目は3段階に分かれます。システムが接続済みか、サーバーテストに成功したか、実際のリクエストが想定どおり処理されたかです。これらは関連していますが、互いに代用できません。システム上は接続済みでもサーバーテストに失敗することがあります。テスト結果が出ても、ページが開かない場合は、名前解決、ルール、アクセス先、転送方式などが関係している可能性があります。
まずHomeでConnectivity Testを実行し、結果を待って、どのサーバーが成功または失敗したか記録します。テスト結果はSettingsのTest Methodや現在のネットワークに左右されるため、あらゆるアクセス状況を保証するものではありません。テスト方式によって確認する到達性の範囲が異なる場合があります。初回は現在の方式を維持し、数値を得るために設定を何度も切り替えないでください。
次にブラウザーを開き、普段アクセスできることが分かっているページにアクセスして再読み込みし、実際に内容が表示されるか確認します。テスト対象には、キャッシュ済みのページだけを選ばないようにしてください。アプリアイコン、通知、読み込み中の表示だけで成功と判断しないでください。特定のページだけに問題がある場合は、別の確認済みページと比較し、接続全体の失敗か特定の接続先の問題かを切り分けます。
Configを使う場合は、現在のルールと接続ログを照合して、リクエストがどのルールに一致したか確認します。ページが開いていても、ログにDIRECTと表示されていれば、Directルールに一致した可能性があり、そのリクエストはProxyサーバーを経由していません。反対にページが開かない場合も、まず一致したルールと使用されたポリシーを確認してから、サーバーを切り替えるか判断してください。ログでは時刻と接続先ドメインに注意し、前回のリクエストを今回の結果と取り違えないようにします。
比較するには、現在のモードとテスト結果を記録し、一時的にProxyへ変更して同じ接続先に再度アクセスします。Proxyでは正常でConfigでは問題がある場合、次にルールとポリシーの参照を確認します。両方で問題がある場合は、サーバー情報とネットワークを優先して確認してください。通常のネットワークを確認するには、接続を切るか一時的にDirectを使います。元の設定を記録しておき、確認後に使用予定のモードへ戻してください。
確認が終わったら、普段使うアプリを開いて実際の動作を確認します。アプリによっては既存の接続やキャッシュが残るため、必要に応じてリクエストをやり直してから確認してください。利用中に問題が起きた場合は、その時のモード、サーバー、テスト方式、エラーメッセージを記録します。「接続できない」とだけ伝えるより、次の原因調査に役立ちます。
Settingsとよくある失敗の切り分け
まず失敗した段階を特定してから、Settingsで関連する項目を調整します。サブスクリプションから情報を取得できない、接続スイッチが維持されない、テストに失敗する、特定のページだけ開かない、といった問題はそれぞれ異なります。現象ごとに切り分けるほうが、Proxy、TCP、UDPなどを次々に変更するより原因を見つけやすくなります。用途が分からない項目は、まず元の値のままにしてください。
追加に失敗する場合:URLと入力項目を確認
Subscribeを保存してもサーバー情報が表示されない場合は、URLが完全にコピーされているか、サブスクリプションが有効か、現在のネットワークからそのURLにアクセスできるかを確認します。更新時にはまずURL自体にリクエストを送るため、一覧内のサーバーがそのリクエストを完了させるとは限りません。確認後に再度更新してください。利用可能な情報がすでにある場合は、更新失敗によってすべての情報を失わないよう、先に保持しておきます。
手動で登録した場合は、Add Serverを開き、元の情報とType、Host、Port、認証情報を一つずつ照合してから、TLSと転送に関する項目を確認します。パスワード、UUID、ホスト名、パスを記憶だけで入力しないでください。QRコードからインポートした場合も、取り込み後の内容を確認します。情報を保存できても、アプリが入力を受け付けたというだけで、接続先のパラメータが正しいとは限りません。
テストに失敗する場合:テスト方式と実際の接続状況を区別
SettingsでTest Methodを確認し、現在のテスト方式を把握してからConnectivity Testを再実行します。ある方式のテストに失敗しても、すべての接続が使えないとすぐに判断せず、実際のページへのアクセスも確認してください。利用可能なWi-Fiとモバイル通信を比較する方法もあります。その際はサーバーとモードを変えずに確認します。ネットワークによって結果が変わる場合は、すべての入力項目を同時に変更するのではなく、ネットワークの到達性や関連する制限を確認してください。
スイッチがすぐにオフになる場合は、システムの許可と現在の設定を確認します。接続状態が維持されても複数のテストに失敗する場合は、既存のサーバー情報が有効か確認し、Diagnosticsの関連情報を確認してください。Diagnosticsは原因調査の補助であり、誤ったパラメータを自動で補う機能ではありません。正確なエラー内容と発生時刻を記録し、現象に応じて確認を続けてください。
Configに問題がある場合:ルールの順序とポリシーの参照を確認
ProxyではアクセスできるのにConfigではできない場合は、Configに戻り、使用中のファイル、Ruleの順序、ポリシーグループを確認します。よくある原因として、別の設定ファイルを選択している、リクエストが不適切なルールに先に一致している、ルールが参照するポリシーに利用可能なサーバーがない、といった可能性があります。Rule全体を削除して復旧させようとせず、まずテスト対象に一致した結果を確認し、一項目ずつ変更して再テストしてください。
特定のドメインだけに問題がある場合は、接続ログを確認し、実際の接続先、名前解決の結果、適用されたポリシーを調べます。DNSとルールの問題は似た症状になることがあり、ページのエラーだけでは区別できません。元の設定を比較用に残し、一つずつ確認してください。サブスクリプションを何度も切り替える必要はありません。ルールのキーワードとプロトコル項目の詳しい説明は用語解説をご覧ください。症状の詳しい分類はFAQで確認できます。
接続が自動で変わる場合:On Demandを確認
手動で切断した後に再接続する場合や、ネットワークを切り替えた際に接続動作が変わる場合は、SettingsでOn Demandが有効か、どの条件で動作するか確認してください。On Demandは条件に応じて接続を開始する機能で、サーバー自体の到達性を保証するものではありません。初回のトラブル対応では、元の条件を記録してから関連する自動接続設定を一時的に停止し、手動スイッチで再確認します。基本接続が安定した後、必要な条件を戻してください。
調査に必要な情報を共有する場合は、サブスクリプションURL内の認証情報、サーバーの認証情報、個人を特定できる記録を隠し、必要な画面表示、エラー内容、操作順だけを残してください。「追加方法 → 現在のGlobal Routing → システムの接続状態 → Test Methodと結果 → 実際のアクセス状況」の順にまとめると整理しやすくなります。完全な接続情報を公開資料に載せないでください。
5つの手順を終えたら、正常に動作する設定を保ち、必要に応じてほかの機能を確認してください。購入、ストアの国や地域、購入済みアプリの復元は別の手順です。詳しくは正規購入ガイドをご覧ください。このページでは、ご自身の接続情報、モード、実際のアクセス結果が一致することを確認します。