準備確認:入力情報がそろっているか確認する
初回操作の前に、手元の情報を2種類に分けて確認します。1つ目は単一サーバーの情報で、通常はプロトコル、サーバーアドレス、ポート、認証項目が含まれます。プロトコルによっては、トランスポート、TLS、SNI、Public Key、Private Key などの追加項目もあります。2つ目はサブスクリプションリンクです。サービス提供元から発行され、複数のサーバー情報を一括で取り込み、更新するために使います。どちらか一方の方法を選べばよく、同じ情報を重複して追加する必要はありません。
Shadowrocket を開いたら、まず Home にとどまります。この画面では、現在のサーバーの確認、接続先の選択、Global Routing の設定、接続スイッチの操作を行います。画面下部の Config はルール設定の管理、Data は接続によって生成された記録の確認、Settings は DNS、On Demand、Log などのクライアント設定に使います。これらの入口を先に把握しておくと、以降の操作で画面を間違えにくくなります。
デバイスに Shadowrocket がまだない場合は、まず本サイトの App Store ダウンロード案内で製品ページを確認してください。開発者名は Shadow Launch Technology Limited、アプリ ID は 932747118 です。iPhone、iPad、および App Store の互換性欄に記載されたその他の Apple デバイスについて、システム要件は App Store ページの表示に従ってください。このチュートリアルでは、iPhone と iPad の基本操作のみ説明します。
サーバーを追加または既存のサブスクリプションを取り込む
Home から Add Server に進みます。手元の情報に応じて操作方法を選びます。サーバー項目が明確にそろっている場合は手動追加、サブスクリプションリンクがある場合は Subscribe を開きます。どちらか一方を完了したら、Home に戻ってサーバー項目が表示されたことを確認し、その後 Global Routing を設定します。
手順1:Add Server で手動入力する
Add Server で、手元の情報と一致するプロトコルを選びます。例として Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 があります。プロトコル名は種類を選ぶための入口であり、相互に置き換えることはできません。選択後、元の情報に従ってサーバーアドレス、ポート、認証項目を入力します。追加項目が表示されても、サービス提供元から値が明示されている場合だけ入力してください。
入力時は、よくある3つの問題に注意します。1つ目は、サーバーアドレスの前後に空白を入れず、説明文まで一緒に貼り付けないことです。2つ目は、ポートをポート欄に入力し、アドレスと同じ欄に書かないことです。3つ目は、大文字と小文字を区別する認証情報を元のまま入力することです。完了したら保存して Home に戻り、SERVER リストから追加した項目を選択します。選択中のサーバーは、リスト上で状態が異なって表示されることがあります。
既存の情報を QR コードで保存している場合は、対応する入口から Scan QR Code を使えます。スキャン前に、その QR コードが自分のサーバー情報から作成されたものか確認してください。読み取り後も項目を開き、プロトコルと主要な項目を確認します。QR コードの内容が古いまま、次の手順へ進むことを避けるためです。クライアントに対応した Cloud JSON がある場合は Import from Cloud JSON を使えます。取り込み後も Home に戻り、項目を確認してください。
手順2:Subscribe から取り込む
Add Server で Subscribe を開き、自分で識別しやすい名前を付けて、既存のサブスクリプションリンクを貼り付けて保存します。保存後に更新を実行し、Shadowrocket による解析が完了するまで待ちます。更新に成功すると、Home のサーバーリストにそのサブスクリプション由来の項目が表示されます。リストに変化がない場合は、同じサブスクリプションを繰り返し作成せず、元の記録を開いてリンクが完全か確認し、更新時にエラーが表示されていないか確認してください。
サブスクリプションはサーバー情報を更新する方法であり、接続がオンになったことを意味しません。取り込み後は Home で具体的なサーバーを選び、Global Routing と接続スイッチを設定する必要があります。後でサブスクリプションの内容が変わった場合は、新しく同じリンクを作成せず、既存のサブスクリプション記録を更新してください。重複項目を減らし、現在使用している情報を把握しやすくなります。
この手順の完了条件は簡単です。Home に戻ったとき、自分の情報から作成されたサーバー項目が少なくとも1つ表示され、選択できることを確認します。Add Server の保存後に項目がない、Subscribe の更新後にリストが空の場合は、問題はまだ取り込み段階にあります。この時点で DNS や Config を先に調整する必要はありません。
Global Routing のモードを選ぶ
サーバー項目を用意したら Home に戻り、Global Routing を開きます。ここでは、通信をどのように処理するかを決めます。Shadowrocket でよく使う3つのモードは、設定の Config、プロキシの Proxy、直接接続の Direct です。それぞれ役割が異なるため、選択前に、今回はサーバー自体を確認するのか、ルールに従って継続利用するのかを決めます。
設定
Config
現在の設定ファイルにあるルールを上から順に照合します。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6、USER-AGENT などの条件に基づき、リクエストを PROXY、DIRECT、その他のポリシーへ振り分けます。日常的にルールで通信を分ける場合は、通常このモードを使います。
プロキシ
Proxy
リクエストを現在選択しているサーバーで処理します。サーバーが接続を確立できるかを確認する際に適しています。ただし、サーバー項目、ネットワーク環境、DNS の確認に代わるものではなく、Config のルールが正しいことを示すものでもありません。
直接接続
Direct
リクエストは現在のサーバーを経由しません。ローカルネットワークの状態を比較したり、問題がプロキシ経路だけで発生しているか一時的に確認したりする場合に使えます。Direct を選択して接続状態が表示されても、サーバーの利用可能性を確認できたとは判断しないでください。
初めて操作する場合は、まず Proxy で基本的な接続確認を行うことをおすすめします。現在のサーバーが動作することを確認したら Config に切り替え、ルール分岐が想定どおりか確認します。これにより、「サーバー自体に接続できない」問題と「設定ルールが想定どおり適用されない」問題を分けて確認できます。
Config を選ぶ前に、画面下部の Config を開き、使用する設定ファイルが実際に選択されていることを確認します。設定ファイルが空、未選択、またはルールの内容が用途と一致していない場合、リクエストの経路が想定と異なることがあります。ルールは通常上から順に照合されるため、具体性の高いルールを適切な位置に置き、最終的に一致しないリクエストは FINAL などのルールで処理します。ルール構文と DNS の組み合わせは多岐にわたるため、詳しくは Settings 設定マニュアルを参照してください。
接続スイッチをオンにしてシステムの許可を完了する
Home にとどまり、現在のサーバー名と Global Routing をもう一度確認してから、接続スイッチをオンにします。デバイスで初めて接続を確立するときは、システムから VPN 構成の追加を許可するよう求められます。iOS または iPadOS の画面指示に従い、デバイスが求める認証方法で操作を完了してください。システムの許可が完了していない場合、Shadowrocket は対応するシステムネットワーク構成を作成できません。
許可が完了したら Shadowrocket に戻り、接続状態が安定するまで待ちます。スイッチをオンにした直後にサーバー、Config、Global Routing を連続して切り替えないでください。複数の項目を同時に変更すると、失敗原因を特定しにくくなります。状態がすぐ未接続に戻った場合は、その時点で選択していたサーバーとモードを記録してから次の確認へ進み、スイッチの色だけで全ての通信経路が正常だと判断しないでください。
以前に許可していても、システム設定が変わると再度確認が必要になることがあります。接続スイッチをいったんオフにし、数秒待ってから再びオンにしてください。それでも接続を維持できない場合は、デバイスで Wi-Fi またはモバイル通信が利用可能か確認します。Shadowrocket は正常なローカルネットワーク上で接続を確立するため、ローカルネットワーク自体にアクセスできない場合、Global Routing を変更しても基本的な接続問題は解決しません。
接続確立後は、しばらく On Demand を有効にしないでください。On Demand は条件に応じて自動的に接続する機能で、手動操作が正常だと確認してから設定するのに適しています。初回の確認中は手動スイッチを使うと、各操作のタイミングを把握しやすくなります。On Demand を継続利用する場合は、基本手順の完了後に Settings で設定し、On Demand 設定ガイドを参照してください。
Connectivity Test で結果を確認する
接続スイッチをオンにしたまま、まず Home の状態が安定していることを確認し、現在のサーバーで Connectivity Test を実行します。サーバー項目の操作メニューから同名の機能を開けます。画面構成によって関連メニュー内に表示される場合もありますが、英語の画面用語 Connectivity Test を目印にしてください。テストはサーバー関連の接続経路を確認するためのもので、1回の結果だけで実際のアクセス確認に代えることはできません。
続いて、普段アクセスする必要があるページまたはアプリを開き、正常に読み込めるか確認します。その後 Shadowrocket に戻り、Data に新しい接続記録があるか確認します。Config を使っている場合は、リクエストが最終的にどのルールに一致し、PROXY と DIRECT のどちらが使われたかも確認します。接続記録があるのにページの読み込みが完了しない場合、システムスイッチは動作しており、問題はサーバーの応答、DNS、ルール、対象サービスのいずれかにある可能性があります。
さらに詳しく確認する場合は、Settings の Log 関連項目を開きます。Log では、ドメイン解決、ルールの適用、接続確立、失敗メッセージを確認できます。ただし、ドメインやサーバーアドレスなどの実行情報が含まれる場合があるため、他人に共有する前に内容を確認してください。確認が終わったら、日常利用で必要な範囲にログ設定を戻し、常に最も詳細な記録レベルにする必要はありません。
1つの状態だけで判断せず、次の順番で結果を確認してください。
- Home で想定したサーバーが選択され、接続スイッチがオンになっている。
- Global Routing がテスト目的と一致し、サーバー確認時に Direct になっていない。
- Connectivity Test が対応する確認を完了する、または原因特定に使える明確なメッセージを表示する。
- 実際のページが読み込まれ、Data に新しい接続記録が表示される。
- Config 使用時に、ルールの適用結果と PROXY、DIRECT の想定が一致する。
Proxy では正常にアクセスでき、Config では異常がある場合、サーバー自体は基本確認を通過している可能性が高いため、設定ファイル、ルールの順序、ポリシー名、DNS を重点的に確認します。反対に Proxy でもテストを完了できない場合は、ルールを書き直す前にサーバー項目、ローカルネットワーク、サブスクリプションの状態を確認してください。
よくある失敗箇所:層ごとに確認する
接続スイッチを維持できない、テストに失敗する、ページが読み込み中のままになる、一部のドメインだけ利用できないなど、異なる問題が似た症状を示すことがあります。外側の層から順に、一度に1つの変数だけを変更し、変更後に同じ確認をやり直すのが効果的です。以下では、初回利用でよくある確認箇所を順に説明します。
1. Home にサーバー項目がない
まず Add Server に戻り、保存が完了しているか確認します。手動入力の場合は、プロトコル、サーバーアドレス、ポートがすべて保存されていることを確認してください。Subscribe から取り込んだ場合は、既存のサブスクリプション記録を開いて更新し、解析メッセージが表示されるか確認します。同じ名前の記録を連続して作成しないでください。後で選びにくくなります。サブスクリプションリンクの失効、認証情報の変更、サービス状態については、その情報を提供したサービス提供元に確認してください。
2. サーバーは表示されるが接続スイッチを維持できない
まずデバイスのローカルネットワークが利用可能か確認し、次にシステムの許可が完了しているか確認します。スイッチをオフにし、接続状態が完全に終了するまで待ってから再びオンにしてください。素早く連続してタップしないでください。ネットワークを変更して症状が変わる場合は、Wi-Fi とモバイル通信での結果を分けて記録します。その後、現在のサーバーのプロトコル、アドレス、ポート、認証項目を確認し、特にコピー時に入った空白や欠落に注意してください。
3. Connectivity Test に失敗する
Global Routing を一時的にプロキシの Proxy に設定し、情報が完全に保存されたサーバーを選んで再テストします。複数のサーバーで失敗する場合は、まずローカルネットワーク、サブスクリプションの更新状況、共通項目の入力ミスを確認します。1つの項目だけ失敗する場合は、その項目固有のパラメータを重点的に確認してください。Connectivity Test は原因特定のための機能であり、繰り返し実行するだけでは項目の不一致を解決できません。
4. Proxy は正常だが Config でアクセスできない
Config を開き、設定ファイルが選択されていることを確認し、ルールのポリシー名が存在するか確認します。ルールが上から順に適用される場合、前方の広いルールが先にリクエストを処理し、後方の具体的なルールが適用されないことがあります。Data または Log で対象ドメインが DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL のどれに一致したかを確認してから、変更するルールを決めてください。ルール全体を一度に削除すると、変更前後を比較できなくなります。
5. テスト結果は出るがウェブページが開かない
この場合は DNS を別の層として確認します。サーバーテストが正常でも、一部の接続条件が満たされたことを示すだけで、ドメイン解決まで完了したとは限りません。すべてのドメインで失敗するのか、一部のドメインだけなのかを確認し、Log に解決関連のメッセージがないか確認します。DNS 設定、リモート解決、ルールには関係があるため、詳しい項目と確認手順は DNS 設定リファレンスを参照してください。
6. 一部のアプリは正常だが、一部のリクエストに問題がある
Config を使っている場合は、まず問題のあるリクエストに適用されたポリシーを確認します。ある接続は DOMAIN-SUFFIX に一致し、別の接続は GEOIP や FINAL に流れることがあるため、同じアプリ内でも結果が異なる場合があります。ルールを確認したら、対応するポリシーが現在利用可能なサーバーを指しているか確認します。Proxy でも特定の対象だけ異常がある場合は、テスト時刻と Log のエラー種別を記録し、対象サービスの状態とクライアント設定の問題を切り分けてください。
7. サブスクリプション更新後にサーバーが変わった
サブスクリプションを更新すると、その内容に従って関連する記録が更新されます。更新後は Home に戻って現在選択されているサーバーを確認し、Connectivity Test をもう一度実行してください。元の項目がリストから消えた場合は、古い名前を前提に確認を続けないでください。残しておきたい手動サーバーは独立した項目として管理し、手動入力で作った記録とサブスクリプション更新で作られた記録を混在させないでください。
基本接続が完了した後の設定順序
Home の接続スイッチを安定して維持でき、Connectivity Test に明確な結果が出て、実際のアクセスも正常で、Config のルール適用が想定どおりなら、基本手順は完了です。その後、必要に応じて DNS、On Demand、Ping、Log、Widget、iCloud 同期、Proxy ポートなどを設定します。基本接続を確認する前に、これらを同時に変更しないでください。
次の設定は、まず確認済みのサーバーを1つ固定し、Config のルールを確認してから DNS を確認し、最後に On Demand や Widget などの便利な機能を有効にする順序がおすすめです。各段階で比較基準を持てます。後の変更で接続に問題が起きた場合は、このチュートリアルの Proxy 確認手順に戻り、サーバーがまだ動作するかを確認してから、新しく変更した設定を調べてください。
完了チェックリスト
- 既存のサーバー情報を Add Server で保存した、または既存のサブスクリプションを Subscribe で更新した。
- Home で現在のサーバーを明確に選択した。
- Global Routing で、目的に合う Config、Proxy、Direct のいずれかを選択した。
- システムの許可が完了し、接続スイッチを安定して維持できる。
- Connectivity Test、実際のアクセス、Data、Log の結果を相互に確認できる。
- Config 使用時に、PROXY と DIRECT のルール適用が想定どおりである。