Shadowrocket ガイド · はじめての使い方

Shadowrocket サブスクリプションの追加と初回接続

「追加 → ルーティング選択 → 接続 → 確認 → トラブル対処」の順に進めます。まず再現可能な接続を一度確認してから、ルールや自動接続の設定を調整します。

操作を始める前に:App StoreからShadowrocketを入手済みで、使用するサブスクリプションURLまたはサーバー情報をお持ちであることが前提です。当サイトではサーバーやサブスクリプションを提供・販売・推奨していません。アプリの買い切り購入と接続サービスの契約は別です。アプリを購入しても接続サービスは付属しません。

まだ入手していない場合は、先にApp Storeでの正規入手方法を確認し、デベロッパ名がShadow Launch Technology Limited、アプリIDが932747118であることを確認してください。システム要件はApp Storeの製品ページをご確認ください。

ここでは主にiPhone・iPadでの操作を説明します。画面上の項目名は英語のまま記載しています。手元にある情報に合った追加方法を確認してください。二つの方法を両方行う必要はありません。ボタンの位置は画面レイアウトによって異なることがあるため、名称を目印にしてください。

手順 01 · 接続情報を追加

Add Server:サーバーまたはサブスクリプションを追加

まず手元の情報を確認します。サブスクリプションは通常、複数のサーバー情報を取得できる完全なURLです。個別のサーバー情報には、プロトコル、アドレス、ポート、認証情報が含まれます。この二つは入力方法が異なります。サブスクリプションURLをサーバーアドレス欄に入力しないでください。また、URLのように見えるという理由だけでブラウザから開かないでください。サブスクリプションURLには個人の認証情報が含まれる場合があるため、パスワードと同様に慎重に管理してください。

サブスクリプションURLがある場合:Subscribeを選択

ShadowrocketのHomeを開き、右上の追加ボタンからAdd Serverに進みます。TypeでSubscribeを選び、手元にあるサブスクリプションURLをURL欄にすべて入力します。後で見分けやすい名前も設定できます。貼り付けた後、URLの先頭や末尾に空白・改行がないこと、チャットアプリによって途中で切れていないこと、説明文まで一緒にコピーされていないことを確認してください。

保存後にHomeへ戻り、サブスクリプションの読み込み結果を待ちます。サブスクリプション名だけが表示され、選択できるサーバーがない場合は、そのサブスクリプションの操作メニューから更新し、エラーメッセージを確認してください。保存ボタンを押せたことではなく、サブスクリプション内に実際のサーバーが表示されたことが成功の目安です。まず一つ選択し、読み込み結果を確認する前に同じURLを繰り返し追加しないでください。

サブスクリプションの更新には、現在のネットワークから内容を取得できる必要があります。読み込みに失敗しても、必ずしもURLが無効とは限りません。ネットワーク、ドメインの名前解決、応答形式に問題がある場合もあります。元のURLを残し、エラーを記録したうえで、トラブル対処の手順を順に確認してください。サブスクリプション内のサーバー名は識別用です。名前だけで利用可否を判断しないでください。

サーバー情報がある場合:プロトコルに合わせて入力

同様にHomeからAdd Serverを開き、Typeで手元の情報に合うプロトコルを選びます。例:Shadowsocks、VMess、VLESS、Trojan。続けて、サーバーアドレス、ポート、対応する認証情報を入力します。プロトコルによって必要な項目は異なります。パスワードとUUIDは代用できません。項目名が似ているからといって、別のプロトコルの情報を流用しないでください。

TLS、Server Name、転送方式、Host、Pathなどの情報が明記されている場合は、それらも確認して入力します。サーバーアドレスとTLS検証に使う名前が異なることがあります。自己判断で同じ値にせず、元の情報に従ってください。アドレスの入力時は「ホスト名」と「完全なURL」を区別します。ホスト名だけを求められる欄にはパスを追加しないでください。保存後にHomeへ戻り、サーバーが表示されたことを確認して選択します。

自分のサーバーのQRコードがある場合は、Homeのスキャン機能からScan QR Codeを使用できます。読み取り後もプロトコルと重要な設定項目を確認してください。「スキャン成功」は「接続確認済み」を意味しません。iPadではウィンドウのレイアウトによって項目の位置が異なる場合があります。Add Server、Type、Subscribeなどの名称を目印に探してください。

この手順の完了条件:Homeに実際のサーバーが一つ以上表示され、そのうち一つが選択されていること。次に、リクエストのルーティング方法を決めます。Settingsの項目をすぐに大量変更する必要はありません。

手順 02 · ルーティング方法を決定

Global Routing:Config、Proxy、Direct

HomeでGlobal Routingをタップし、今回の接続で使うモードを選びます。選択肢はConfig(設定)/Proxy(プロキシ)/Direct(直接接続)です。この設定はリクエストの処理方法を決めるもので、サーバー情報を補ったり、無効な認証情報を修正したりするものではありません。初回は「サーバーに接続できるか」と「ルールが意図どおりか」を分けて確認してください。

Config:現在の設定にあるルールに従う

Configでは、現在使用中の設定に基づいてリクエストの処理方法が決まります。Config画面を開き、使う設定が選択されていることを確認してから、HomeのGlobal RoutingでConfigを選択します。サーバーのサブスクリプションを追加することと、ルール設定を選ぶことは別の操作です。サブスクリプションに複数のサーバーが表示されても、現在の設定で意図どおりにルーティングされるとは限りません。既存の設定を初めて使う場合は、提供元、用途、参照されるポリシーを確認してください。

ルールでよく使われるポリシーには、DIRECT、PROXY、REJECTがあります。Configを選んだとき、一部のリクエストが直接接続されるのはルールの結果かもしれません。それだけで接続に失敗したと判断しないでください。特定のドメインが現在のポリシーになった理由がわからない場合は、確認手順で該当リクエストを調べてから、ルールの順序を確認します。ルールの優先順位については初心者から応用までのマニュアルをご覧ください。まずはこのページで基本の接続確認を完了します。

Proxy:選択したサーバー経由の接続を確認

サーバーが利用できるかを先に確認する場合は、一時的にProxyを選ぶと、ルールによる振り分けの影響を抑えてテストできます。クライアントが処理するリクエストをプロキシ経由で処理しますが、端末上のすべての通信が必ず同じ経路になるという意味ではありません。テストでは宛先を明確にし、実際のリクエスト結果を確認してください。サーバーが使えることを確認したらConfigに戻り、通常のルールを確認します。

Direct:通常のネットワーク接続との比較

Directでは対象のリクエストを、選択したプロキシサーバーを経由せずに直接接続します。通常のネットワークが動作しているか比較するのに使えますが、サーバーへの接続を確認する方法ではありません。DirectでWebページが開いても、直接アクセスが成功したことしかわかりません。選択したサーバーを確認するにはProxy、または明確なプロキシルールを設定したConfigに戻り、実際のアクセスを再テストしてください。

選択後は、現在のモードとサーバー名を控えておきます。テストに失敗した場合は、原因がサーバーかルールかを判断できるよう、一度に一つの条件だけ変更して再試行してください。同じテスト中にサーバーの切り替え、DNSの変更、設定の変更を同時に行わないでください。

手順 03 · 接続を開始

Home:接続スイッチとVPN構成の許可

Homeに戻り、選択中のサーバーとGlobal Routingのモードをもう一度確認してから、上部の接続スイッチをオンにします。初回接続時は、ShadowrocketによるVPN構成の追加をシステムから求められる場合があります。これはクライアントがシステムのネットワーク接続構成を作成するための許可であり、サブスクリプションの有効性とは別の手順です。直前に自分で行った操作によって表示されたことを確認し、画面の案内に従って許可と端末認証を完了してください。

許可後にShadowrocketへ戻り、スイッチと接続状態を確認します。先ほどキャンセルした場合は接続を続けられないことがあります。接続スイッチを再度オンにして、案内に従ってください。確認画面が再表示されない場合は、端末のSettingsにあるVPN関連の設定で構成を確認できます。設定画面の階層はシステムのバージョンによって異なります。端末の画面に従って探し、決まった経路を探すために構成を何度も削除しないでください。

接続後、システムのVPNアイコンは状態を確認する目安になります。ただし、ネットワーク構成が動作中であることを示すだけで、サーバー認証、DNS、Webページへのアクセスがすべて正常とは限りません。接続状態が維持されていても、実際のアクセスに失敗することがあります。次の手順で確認してください。状態の変化が遅いからといって、スイッチをすばやく何度も切り替えず、今回の接続結果が出てから再試行を判断します。

端末で別のVPN接続が有効になっている場合や、職場・学校のネットワーク構成がある場合は、今回の接続に影響することがあります。現在有効な接続を確認し、端末の管理ルールに従ってください。用途がわからない管理構成をむやみに削除しないでください。初回のテストではOn Demandを設定せず、手動で切断した後に自動接続条件が作動して結果がわかりにくくなるのを避けることをおすすめします。

この手順の完了条件:システムの許可が済み、Shadowrocketに接続中と表示されていること。次の手順で実際のアクセスを確認します。スイッチの状態だけでテスト結果を判断しないでください。

手順 04 · 結果を確認

Connectivity Testと実際のアクセスを確認

まずHomeでConnectivity Testを実行し、登録済みサーバーを初期確認します。結果からわかるのは、そのテスト方法での到達状況であり、Webページへのアクセス全体を確認できるわけではありません。応答時間が表示されても、すべてのドメイン、プロトコル、宛先にアクセスできるとは限りません。タイムアウトした場合も、テスト方法や実際の利用状況と合わせて判断し、一度の結果だけでサーバーをすべて削除しないでください。

続いてブラウザを開き、アクセス権があり、正常な内容を確認できるページにアクセスします。同じサーバーとルーティングモードのまま再読み込みし、ページ内の別のリンクも開いて、キャッシュだけを表示していないことを確認してください。特定の宛先だけ失敗する場合は、別の明確な宛先でも比較します。「すべてのアクセスに失敗する」のか「特定のサイトだけ失敗する」のかを先に切り分けてください。対処方法が異なります。

Dataで今回のリクエストを確認

Shadowrocketに戻り、Dataで現在確認できる通信量とリクエスト記録を確認します。直前にアクセスした時刻と対象ドメインを手がかりに記録を探し、表示されるポリシー、エラー、接続情報をもとに判断します。Configを使用中の場合は、そのリクエストが意図どおりPROXY、DIRECT、REJECTのどれで処理されたかを確認してください。通信量の合計が増えただけでは、目的のページが開いた証拠にはなりません。バックグラウンドのアプリが通信した可能性もあります。

記録に十分な情報がない場合、ルールが適用されたと推測で決めつけないでください。まずProxyでサーバー経由の接続を比較し、Configに戻して同じ宛先を再テストします。ProxyではアクセスできるのにConfigで意図どおりにならない場合は、サーバー情報をすべて入力し直すのではなく、現在の設定、ルールの順序、ポリシーの参照先を確認してください。どちらのモードでも失敗する場合は、サーバー情報、基本ネットワーク、名前解決を引き続き確認します。

直接接続と比較する場合は、短時間Directに切り替えるか、今回の接続を停止して同じ宛先をテストし、その後、元の設定に戻します。比較テストではネットワーク経路が変わるため、直接接続に適した宛先だけにアクセスし、操作前に必要なアクセス条件を確認してください。「どの宛先で、どのモードを使い、成功したか」を記録し、「ネットワークにつながらない」とだけ書かないようにします。

初回の確認が済んだら、Wi-Fiとモバイル通信を一度切り替えて再テストすると、特定のネットワークでのみ発生する問題を見つけやすくなります。端末でモバイル通信を利用できない場合は、この手順を省略してください。普段使う前に、必要なConfigなどのモードに戻っていることを確認します。サブスクリプションの更新後にサーバー名や項目が変わった場合も、選択中のサーバーとポリシーの参照先を再確認してください。

手順 05 · 問題箇所を確認

サブスクリプションの読み込み、接続、Webページ表示の問題

トラブル対処では、現在の設定とエラーメッセージを残し、以下の順で原因を切り分けます。各項目を確認するたびに、その項目に関係する内容だけを変更し、同じ宛先で再テストしてください。最初に再インストールすると、サーバーの選択、設定、許可状態まで変わり、原因を特定しにくくなるため、最初の対処としてはおすすめしません。

サブスクリプションは保存できたが、サーバーが表示されない

Add Serverからサブスクリプションの編集画面を開き、TypeがSubscribeになっていること、URLに手元のリンクがすべて入力されていることを確認します。ページタイトルを一緒にコピーしていないか、URL末尾のパラメーターが欠けていないか、空白や改行が混ざっていないかを確認してください。次にネットワークが正常に使えることを確認し、サブスクリプションをもう一度更新してエラーを記録します。クライアントが読み込めるサブスクリプションではなく、ログイン画面や案内ページが表示される場合は、利用中のサービスの管理者にURLの用途と形式を確認してください。

サブスクリプションURL全体を公開の掲示板に貼り付けないでください。原因を調べるために、含まれるパラメーターをむやみに削除するのも避けてください。個人の利用資格を識別するパラメーターが含まれる場合があり、変更するとURLが開けても正しい内容が返らないことがあります。利用中のサービスからURLの変更を案内された場合は、既存のサブスクリプション情報を更新し、古い項目を複数残して選び間違えることを防ぎます。

サーバーは表示されるが、正常にアクセスできない

まず、想定しているサーバーが実際に選択されていることを確認し、プロトコル、ポート、認証情報、TLSなどの設定を見直します。サーバー名や証明書の問題を隠すために証明書検証を無効にせず、Server Name、サーバーアドレス、端末の時刻が正しいかを確認してください。次にProxyを一時的に選び、同じ宛先をテストします。それでも失敗する場合はサーバーへの接続性や設定を優先して確認します。Proxyでは正常でConfigでは失敗する場合は、設定とルールを確認してください。

接続スイッチがオンのままにならない、またはシステムの許可が完了しない

システムのVPN設定で現在の接続状態を確認し、構成追加の許可が完了していること、別の接続が切り替わっていないことを確認します。端末が管理対象の場合は、管理上の制限も確認してください。手動で切断しても自動接続される場合は、On Demandの条件が設定されているか確認します。これは「スイッチが動作しない」状態とは異なります。変更前に元の条件を記録し、普段必要な自動接続まで変えてしまわないようにしてください。

Connectivity Testは応答するが、Webページを開けない

まず複数の宛先への実際のアクセス結果を比較し、Dataに失敗した宛先の記録があるか確認します。考えられる要因には、ドメインの名前解決、ルールの選択、サーバーから宛先への接続、宛先側の応答などがあります。十分な根拠がないままDNSの問題と決めつけないでください。名前解決のエラーが確認できた場合は、まず現在の設定で使われているDNSを確認します。複数のDNSアドレスを同時に変更すると比較できなくなるため避けてください。

特定のWi-Fiだけで失敗する場合は、通常の接続認証が必要なネットワークかどうかを確認してください。別の利用可能なネットワークに切り替えて復旧する場合は、元のネットワークの条件を引き続き確認します。特定のアプリだけで失敗する場合は、ブラウザで同じサービスの利用可能なページにアクセスして比較し、アプリのセッション、対象サービス、クライアントの接続を切り分けます。すぐにすべてのルールを変更しないでください。

必要最小限の記録を残してから次の対処へ

端末の種類、現在のネットワーク、Global Routingのモード、選択中のサーバーのカスタム名、失敗した宛先、エラーの内容を記録します。診断情報を共有する場合は、完全なサブスクリプションURL、パスワード、UUID、個人のアドレスなど、認証情報を削除してください。名前を隠すだけでは認証情報を削除したことになりません。変更後は「サーバーを選択 → 接続 → 宛先にアクセス → 記録を確認」の順に再度試し、同じ結果が再現することを確認してください。

基本操作の完了条件:手元の情報を追加し、現在のGlobal Routingの選択理由を説明でき、接続の許可を済ませ、実際のアクセスで結果を確認できていること。続けて初心者から応用までの総合マニュアルでConfigのルール、On Demand、Data、日常の管理方法を確認できます。機能の詳細は機能紹介をご覧ください。

アプリの日常的なアップデートはApp Storeから行います。アプリのアップデート、サブスクリプションの更新、ルール設定の変更はそれぞれ別の操作です。一つずつ行って確認すると、変化があった際に原因を特定しやすくなります。