公式マニュアル · 初回接続

Shadowrocketの使い方ガイド

既存のサブスクリプションの追加、Global Routingの選択、接続確認を解説します。5つの手順で基本を確認してから、ルールの詳細を調整します。

事前準備：アプリのインストールと接続情報
このガイドでは、App StoreからShadowrocketをインストール済みで、利用するサブスクリプションURLまたはサーバー情報を用意していることを前提とします。このサイトではサーバー情報やサブスクリプションを提供、販売、推奨していません。アプリの買い切り購入と接続情報の準備は別々に必要です。

まだインストールしていない場合は、先にApp Storeでの正規品の確認と購入方法をご覧ください。iPhoneとiPadのシステム要件はApp Storeの表示をご確認ください。以下では画面上の英語表記をそのまま記載します。表示位置は画面構成によって異なる場合があるため、項目名を目印にしてください。

まず入力情報を確認
次に通信ポリシーを選択
最後に実際のリクエストを確認

01 / INPUT

サーバーを追加またはサブスクリプションを読み込む

まず、手元の情報がどの種類に当たるか確認します。個別のサーバー設定、サーバー情報を含む共有データ、複数のサーバーを更新するサブスクリプションURLでは、入力方法が異なります。サブスクリプションは通常URL形式で、クライアントがアクセスして一覧を取得します。一方、サーバー情報には接続先が直接記載されています。元の情報はそのまま保管し、URLのパラメーターを削除したり、構成ファイルのURLをサーバーアドレスとして入力したりしないでください。

Add Server：手元の情報を入力

ShadowrocketのHomeを開き、SERVER欄のAdd Serverをタップします。追加画面でTypeを選び、選択したプロトコルに応じて項目を入力してください。右の公式スクリーンショットはHost、Port、Password、Methodを含むフォームの例で、すべてのTypeで同じ項目を使うわけではありません。たとえばShadowsocksでは、手元のアドレス、ポート、パスワード、Methodをそれぞれ対応する欄に入力します。ほかのプロトコルでは、表示中のフォームと元の情報を照合し、スクリーンショットの項目をそのまま当てはめないでください。

Hostにはサーバーのアドレスまたはドメインを入力します。パス全体を含むサブスクリプションURLは入力しないでください。Portにはポート番号を入力し、コピー時に空白が入っていないか確認します。パスワード、識別情報、暗号化オプションは大文字・小文字も含め、元の情報どおりに入力します。入力後、画面上の保存操作を行い、Homeに戻ってSERVERに追加した項目が表示されることを確認します。一覧に名前が表示されても、サーバーへの接続が成功したとは限りません。

Scan QR CodeとSubscribe：内容に合った方法で読み込む

QRコードがある場合は、Add ServerでScan QR Codeを使います。システムからカメラの許可を求められたら、必要に応じて許可してください。読み取り後、認識されたTypeとサーバー項目を確認してから保存します。QRコードは情報を格納する形式にすぎず、内容が単一サーバーの情報であることや、URLが現在も有効であることを保証しません。想定と異なる場合は、重複して保存を繰り返さず、元の情報を確認してください。

サブスクリプションURLがある場合は、内容に対応するSubscribeを使用します。ConfigページのSubscribeは、リモート構成ファイルの購読に使います。SERVER一覧を作成するサーバー用サブスクリプションは、追加画面から種類に合った方法で読み込んでください。どちらもURL形式だからといって、同じ入口を使わないようにします。貼り付けるときはクエリパラメーターを含むURL全体を保ち、前後の空白を削除して、説明文が混ざっていないことを確認します。読み込み後、サーバーの一覧を確認するにはHomeに戻り、構成ファイルを読み込んだ場合はConfigで保存されたことを確認します。

クリップボードに共有データが検出された場合も、種類を確認してから読み込みます。Import from Cloud JSONは対応する形式のデータ用で、あらゆるサブスクリプションURLに使える汎用の入口ではありません。この段階では、今回テストする項目を明確にし、サーバーやルールを一度に大量に変更しないでください。各入口の違いはサブスクリプションを読み込む4つの方法で詳しく説明しています。

ShadowrocketのAdd Server画面。Type、Host、Port、Password、Methodのほか、Scan QR CodeとImport from Cloud JSONの入口を表示 — Add Server：先にTypeを選び、対応する項目を確認します。スクリーンショットの項目はすべてのプロトコルに当てはまるわけではありません。

02 / ROUTING

Global Routingを選択

サーバーを保存したら、すぐにルールを変更するのではなく、まず通信に適用するポリシーを決めます。Homeに戻ってGlobal Routingを開き、現在の選択状態を確認します。選択肢は構成（Config）、プロキシ（Proxy）、直接接続（Direct）の3つです。これはSERVERで選んだサーバーとは別の設定です。前者はリクエストの振り分け方法を決め、後者は接続先として使うサーバーを指定します。

構成（Config）：現在のルールに従って処理

特定のサイトをプロキシ経由にし、それ以外を直接接続にする場合は、構成（Config）を選び、Configで使用中の構成ファイルを確認します。ファイルを開くとGeneral、Rule、Hosts、URL Rewriteなどのセクションがあります。まずRuleを確認し、初回接続に関係のない機能は有効にしないでください。ルールは通常、上から順に確認され、最初に一致した項目でポリシーが決まります。そのため、同じドメインに関するルールをどこに配置するかで結果が変わります。

以下はルール構造の例であり、あらゆる環境でそのまま使える完全な構成ではありません。example.comは説明用のドメインです。使用する際は、実際に処理する対象に置き換えてください。PROXYを使うには、現在の構成に対応する利用可能なポリシーが必要です。1行目はこのドメインとサブドメインを処理し、最後の行は一致しないリクエストにDIRECTを指定します。編集前に現在の構成をバックアップし、Add Ruleを使う場合も、キーワードの綴りだけでなく挿入位置を確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

プロキシ（Proxy）と直接接続（Direct）：通信方向を明示

プロキシ（Proxy）は、対象となる通信をプロキシポリシーに渡します。選択中のサーバーがリクエストを処理できるか一時的に比較する場合に使えます。直接接続（Direct）は対象の通信を直接接続します。プロキシが有効になった証拠として扱わないでください。比較する際は元の選択を記録し、Global Routingだけを変更して同じ宛先にアクセスします。テスト後は、継続して使う予定の設定に戻し、切り替え忘れによってルールが効かないと誤認しないようにします。

初回操作では「モード」と「サーバー」を区別できれば十分です。すぐに複雑な構成を書く必要はありません。信頼でき、自分の用途に合う構成をすでに持っている場合は、それを使い、選択状態を確認してください。DOMAIN、GEOIP、IP-CIDR、FINALの違いを詳しく学ぶ場合は、ルールマニュアルをご覧ください。この手順を終えたら、選択中のモードとConfigで使用しているファイルを説明できる状態を目指します。

ShadowrocketのConfig構成ファイル編集画面。General、Rule、Hosts、URL Rewrite、HTTPS Decryptionの各セクションとAdd Ruleを表示 — Config：構成ファイルの内容を表示します。Global Routingの選択画面はHomeにあります。初回はRuleを重点的に確認してください。

03 / CONNECT

サーバーを選択して接続を許可

モードを確認したらHomeに戻り、SERVER一覧から今回使うサーバーを選びます。一覧がサブスクリプション由来の場合は、グループ名だけでなく、必要なパラメーターが揃ったサーバー項目を選んでいることを確認してください。初回の確認ではサーバーを一つに固定します。接続中に項目を頻繁に変えると、問題の原因がサーバー、ルール、現在のネットワークのどれなのか分かりにくくなります。

HomeでGlobal Routingが前の手順で選んだものと一致することを確認し、画面上部の接続スイッチを操作します。未接続の場合はNot Connectedと表示されることがあります。接続状態は現在の画面表示で確認してください。初めて接続するときは、システムからVPN構成の追加を求められます。これはShadowrocketがデバイスのネットワーク通信を処理するために必要なシステムの許可であり、フォームにサブスクリプションのパスワードを追加する操作ではありません。確認画面でアプリの提供元を確認して許可し、システムの案内に従ってデバイス認証を完了します。

以前に許可を拒否した場合は、アプリに戻って接続を再度開始し、システムの案内に従って該当するVPN設定を確認します。確認画面を何度もキャンセルし、スイッチの位置だけで接続成功と判断しないでください。許可後にHomeへ戻り、接続状態が維持されるか確認します。オンにしてすぐ未接続に戻る場合は、ルールを追加して直そうとせず、ここで原因を調べます。接続が確立したら次の手順に進み、実際の通信で転送結果を確認します。

次の2つは区別して確認してください。VPN構成がシステムに許可されたことは、クライアントによる対象通信の処理がデバイスで許可されたことを示します。一方、リモートサーバーに接続できるかどうかは、アドレス、ポート、認証情報、プロトコル設定、現在のネットワークにも左右されます。スイッチがオンのままでも、直接接続は正常でプロキシ経由の通信は失敗することがあります。VPNの表示が出たからといって、すべての宛先に想定どおりアクセスできるとは限りません。

初回の操作中は、On Demandなどの自動接続条件を変更せず、手動で接続から切断まで一度行います。別のVPN構成が接続状態を同時に使用しないようにしてください。切断するにはHomeに戻り、画面上部のスイッチをオフにして状態が変わったことを確認します。これにより、どの構成が現在のリクエストを処理しているかを把握でき、次の手順で接続前後を比較しやすくなります。

この手順の完了条件
Homeでサーバーを選択し、Global Routingが意図した設定になっていて、システムの許可が完了し、接続状態が維持されていること。続けてリクエストを確認し、「スイッチがオン」というだけで完了と判断しないでください。

ShadowrocketのHome画面。上部にNot Connectedのスイッチがあり、その下にGlobal RoutingのConfig、Connectivity Test、SERVER一覧、Add Serverを表示 — Home：同じ画面でサーバー、Global Routing、接続状態を確認してからConnectivity Testを開きます。

04 / CHECK

Connectivity Testで確認

接続状態が維持されていることを確認したら、HomeでConnectivity Testを実行します。テスト前に、先ほどと同じサーバーが選ばれていることと、SettingsのTest Methodを確認してください。テスト方法によって確認できる内容は異なります。テストが応答した場合でも、その時点でそのテストが成功したことを示すにとどまり、すべてのサイト、プロトコル、ルールが正常とは限りません。テストに失敗しても、実際のリクエストがすべて失敗するとは限りません。

続いてブラウザーを開き、プロキシ経由になる想定の宛先と、直接接続になる想定の宛先にアクセスします。キャッシュが接続状態の変化を隠すことがあるため、すでに開いているページを見るだけでなく、新しいリクエストをそれぞれ送信してください。構成（Config）を使っている場合は、実際のリクエストが想定したルールに一致し、最終ポリシーがPROXYまたはDIRECTになっているか確認します。プロキシ（Proxy）を一時的に使っている場合は、選択したプロキシポリシー経由でリクエストが完了するかを確認します。

以下の3項目を最低限の確認記録として使えます。記録するのは今回実際に確認した結果だけで十分です。認証情報全体や大量のテスト数値を記録する必要はありません。3項目は互いを補うもので、一つの結果でほかを代用することはできません。

確認項目	操作	確認内容
接続状態	Homeに戻ってスイッチと状態を確認	システムの許可後、接続状態が維持される
実際のリクエスト	プロキシ経由になる想定の宛先にアクセス	キャッシュ表示だけでなく、新しいリクエストが完了する
ルールの結果	該当するリクエスト記録を確認	一致したルールと最終ポリシーが想定どおり

ページが開いてもポリシーが想定と異なる場合は、すぐにサーバーを変更せず、まずGlobal RoutingとRuleの順序を確認します。たとえば、先にある広範囲なルールが一致すると、後の詳細なルールはそのリクエストの判定に使われません。一方、ポリシーがすでにPROXYなのに接続できない場合は、そのポリシーに対応するサーバーとプロトコル設定を確認し、接続の問題をドメインルールの問題と取り違えないようにします。

完了後、いったん切断して再接続し、同じ宛先で再度確認します。以前の接続が偶然残っていたための結果ではないことを確かめてください。ネットワーク環境を変えた場合も、特にサブスクリプションの更新後やサーバー設定の変更後は、改めて確認します。ドメイン解決、ポリシーの参照、ルールの優先順位を詳しく調べる場合は、ルールと構成のリファレンスをご覧ください。この入門ガイドでは、まず再現可能な確認手順を確立します。

05 / REVIEW

よくある問題と確認の順序

問題が起きたら、まず失敗した段階が読み込み、接続の確立、実際のリクエストのどれかを特定します。SettingsにはTest Method、On Demand、Diagnostics、Proxy、TCP、UDPなどの関連項目があります。それぞれ用途が異なり、同時に有効にすれば直る「修復スイッチ」ではありません。まず現在の設定を保ち、一度に一項目だけ変更して、同じ宛先を再テストしてから変更を維持するか判断します。

サブスクリプションの読み込みに失敗する：URLと応答内容を確認

更新に失敗したり、読み込み後にサーバーが表示されなかったりする場合は、元の情報に戻り、URLが完全か、改行、空白、チャットの文章などが混ざっていないか確認します。URLのクエリパラメーターはサブスクリプションの識別に使われる場合があり、削除すると内容を取得できなくなることがあります。次に、現在のネットワークからそのURLにアクセスできるか、クライアントが対応するデータが返されているか確認します。ログインページ、エラーの説明、ウェブページ本文が返されている場合もあります。構成用とサーバー用のサブスクリプションで入口を間違えると、「保存されたのに一覧が変わらない」ことがあります。

問題を切り分けるために、まだ使える古い項目を繰り返し削除しないでください。まずエラーメッセージを記録し、手元の接続情報を提供した相手にURLの状態、データ形式、利用条件を確認します。サブスクリプションURLには個人用のアクセス情報が含まれることがあるため、公開の場に貼り付けたり、トラブル画面にURL全体を写したりしないでください。読み込みの問題を解決したら、DNSの変更に進むのではなく、最初の手順に戻って保存結果を確認します。

スイッチが戻る、またはリクエストが失敗する：システムとサーバーを分けて確認

接続スイッチがオンのままにならない場合は、VPNの許可が完了しているか、ほかのVPN構成が現在の接続に影響していないかを確認し、アプリに表示されたエラーも確認します。スイッチがオンのままでもリクエストが失敗する場合は、Host、Port、Typeと対応する認証情報を確認します。プロトコルによっては追加の転送設定やTLS設定が必要です。手元の情報と一致させてください。アドレスとポートが同じだけでは、構成が完全とは限りません。ネットワークと設定を同時に変えず、同じサーバー、同じネットワークで再試行します。

特定のドメインだけ失敗し、ほかの宛先は正常な場合は、該当するルールと名前解決の結果を確認します。広範囲に一致するルールで問題を覆い隠したり、理由が分からないままHTTPS Decryptionを有効にしたりしないでください。初回接続では通常、暗号化通信の復号は必要ありません。関連設定を誤って変更すると新たな要因が加わり、単純なサーバー接続の問題も特定しにくくなります。

テストに失敗してもアクセスできる：Test Methodを確認

Connectivity Testとブラウザーでのアクセスでは、リクエスト方法が完全に同じとは限りません。実際のアクセスが正常でテストだけ失敗する場合は、Test Methodとテスト条件を確認し、一つのテスト結果だけを理由にサーバーを削除しないでください。ウェブページは表示できても一部のアプリのリクエストが失敗する場合は、TCP、UDP、ドメイン解決、サーバー側の対応状況を分けて確認します。一種類のリクエストが成功しても、ほかの種類もすべて使えるとは限りません。

さらに詳しく調べる場合はDiagnosticsを使い、共有する前にサーバーアドレス、サブスクリプションのパラメーター、アカウント情報などの機密情報を削除してください。On Demandは条件に応じて接続を開始する機能であり、無効な認証情報を修正するものではありません。まず手動接続と接続確認が正常に完了することを確かめてから、利用状況に合わせて自動動作を設定します。Settingsの各項目について詳しく知りたい場合は、機能と設定の説明をご覧ください。

正常に動作した状態を保存する
読み込み、接続、確認がすべて完了したら、現在の構成をバックアップし、Global Routingの設定と使用中のサーバーを記録します。今後ルールを変更するときは、この再現可能な状態を比較の基準にしてください。ルールの構造とバックアップ時の注意点は、ルールマニュアルをご覧ください。