公式ガイド / 機能と基本設定

Shadowrocketの設定方法

まずGlobal Routingの動作を確認し、次にConfigのルールとポリシーを確認します。その後、オンデマンド接続、DNS、テスト設定を調整してください。一度に変更するのは1項目だけにし、同じ接続先で検証すると、変更による影響を切り分けやすくなります。

ルーティング設定 Global Routing
設定ファイル Config
通信量の確認 Data

前提条件と購入対象

以下の手順はiPhoneとiPadを対象としており、利用者が自身のサブスクリプションまたはサーバー情報を用意していることを前提としています。ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。システム要件はApp Storeの製品ページをご確認ください。アプリの買い切り購入と接続サービスの契約は別です。アプリを購入しても、接続に必要な情報は別途ご用意ください。

このページでは機能と設定を解説します。接続先やサブスクリプションの提供・販売・推奨は行っていません。アプリをまだ入手していない場合は、App Storeで正規品を確認して入手する方法をご覧ください。初めて使う場合は、使い始めるための手順ガイドに沿って進めてください。

機能から設定を探す

以下はページ内の各章へのリンクです。本文の表示・非表示は切り替わりません。項目名はデバイス上のアプリに表示される名称をご確認ください。場所が異なる場合は、まず英語名で探し、別の設定項目と取り違えないようにしてください。

Global Routing：Config・Proxy・Direct

概要：Global Routingでは、リクエストを処理するルーティング方式を選びます。主なモードはConfig（設定）、Proxy（プロキシ）、Direct（直接接続）の3つです。速度の段階ではなく、設定ルールに基づいて接続先を振り分けるかどうかを決めるモードです。

場所と設定方法：HomeでGlobal Routingを開き、使用するモードを選んで、画面に表示された設定を確認します。ドメインやアドレスなどの条件に応じて日常的に振り分ける場合はConfigを使います。選択中のプロキシが利用できるか一時的に確認する場合はProxyを使います。プロキシを経由しない場合の接続状況を比較するにはDirectを使います。

画面上の項目	動作	使用例	最初に確認すること
Config（設定）	現在有効な設定ファイルのルールとポリシーに従ってリクエストを処理します。	通常の利用で、直接接続・プロキシ・拒否を振り分ける場合。	有効なファイル、ルールの順序、ポリシー名。
Proxy（プロキシ）	クライアントが処理するリクエストをプロキシ経由で処理します。アプリやシステム側の処理条件も考慮する必要があります。	ルールの影響を切り分け、選択中のプロキシが使えるか確認する場合。	選択中のサーバー、接続パラメータ、テスト先。
Direct（直接接続）	クライアントが処理するリクエストを直接接続で処理します。	ローカルネットワークとの比較や、プロキシ経路に問題があるかの確認。	現在のネットワークから同じ接続先にアクセスできるか。

注意点：Directはクライアントの接続を終了するモードではありません。また、Proxyでもシステム上のあらゆる通信が必ず同じ経路を通るわけではありません。モードを切り替えた後も、既存の長時間接続は切り替え前の状態を維持することがあります。確認時は新しいリクエストを実行し、必要に応じて該当する接続を終了してから再テストしてください。トラブル対処のため一時的にProxyに切り替えた場合は、必要なConfigモードに戻してください。

ルール分岐：一致条件とポリシーの振り分け先

概要：ルールは、一致条件と処理ポリシーで構成されます。一致条件は「どのリクエストか」を示し、ポリシーは「一致したリクエストをどこへ送るか」を指定します。Configモードでは一般にルールを上から順に判定し、先に一致したルールによって後続のルールが適用されないことがあります。そのため、範囲が明確で限定的な例外を、広い条件より前に置きます。

場所と設定方法：Configで現在有効なファイルを確認し、該当する編集画面でルールを確認します。対象を完全なドメイン名、ドメインのサフィックス、IPアドレスの範囲のどれで照合するかを決めてから、ルール値とポリシーを入力してください。保存後は、編集したファイルが有効になっていることを確認し、同じ接続先へのリクエストを再実行します。

ルールキーワード	照合対象	確認ポイント
`DOMAIN`	完全なドメイン名。	ドメイン名のみを入力し、パスやプロトコルの接頭辞は含めません。
`DOMAIN-SUFFIX`	ドメインのサフィックスと、そのサブドメイン。	サフィックスの範囲によっては複数のサービスに一致します。
`DOMAIN-KEYWORD`	ドメイン名に含まれるキーワード。	一致範囲が広いため、意図しない一致がないか確認します。
`IP-CIDR` / `IP-CIDR6`	IPv4 / IPv6アドレスの範囲。	アドレスの種類、プレフィックス長、名前解決の条件を確認します。
`GEOIP`	IPアドレスの地理情報。	地理情報上の所在は、サービスが実際に利用する地域と一致するとは限りません。
`FINAL`	それ以前のルールに一致しなかった場合の最終的な振り分け先。	フォールバックとしてルールの末尾に配置します。

DIRECT、PROXY、REJECT

DIRECTは直接接続、PROXYはプロキシポリシーの使用、REJECTは拒否を表します。設定によっては独自のポリシーグループ名を参照することもあります。その名前が設定ファイル内で定義されていることを確認してください。名前だけで実際の接続先を推測することはできません。ルールキーワードの大文字・小文字と区切り文字は正しい形式を保ってください。

以下はルール構文の例であり、アプリ画面の表示ではありません。また、既存の設定ファイルにそのまま上書きできる完全な設定でもありません。例にあるexample.comは、サフィックス照合の説明にのみ使用しています。

DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

注意点：ルールが想定どおりに動作しない場合は、まず前にあるルールに一致していないか確認し、リクエスト記録に表示された実際のドメイン名とIPアドレスを確認します。1つのページでも複数のドメインにアクセスすることがあるため、メインのドメインだけにルールを追加しても、すべてのリソースをカバーできるとは限りません。広い範囲に一致するキーワードを追加し続けて、本当の一致条件の問題を覆い隠さないようにしてください。

Subscribe：既存のサブスクリプションとサーバー管理

概要：Subscribeは、利用者がすでに持っているサブスクリプションURLからサーバー情報を取り込み、更新する機能です。通常、サブスクリプションでは複数のサーバーを管理します。サーバーを個別に追加する場合は、各パラメータを利用者自身で管理します。サブスクリプションの更新とApp Storeでのアプリ更新は別の操作であり、一方を更新しても、もう一方が自動的に更新されることはありません。

場所と設定方法：Homeの追加メニューからAdd Serverを開き、画面にSubscribeの項目がある場合は、自分のサブスクリプションURLとメモを入力します。保存して更新を実行した後、グループと項目が表示されていることを確認してください。QRコードをお持ちの場合は、Scan QR Codeから読み込めます。読み込み後は、メモの名前だけで判断せず、タイプ、アドレス、ポートも確認してください。

サーバーを手動で管理する場合は、Add Serverで正しいプロトコルタイプを選び、アドレス、ポート、対応する認証情報を入力します。メモは項目の識別に使うもので、接続動作には影響しません。用途や任意の名前を使って項目を区別し、同じ名前の項目を誤って選ばないようにしましょう。

注意点：サブスクリプションURLには個人用のアクセス情報が含まれることがあります。公開スクリーンショット、ログ、問い合わせ文に記載しないでください。更新後に項目名、グループ、件数が変わる場合があります。サブスクリプション項目へのローカルでの変更が次回の更新で影響を受けることもあるため、変更前に必要な情報を記録してください。更新に失敗した場合は、URLの無効、リクエストのタイムアウト、内容の解析失敗を切り分けます。まだ使える項目一式をすぐに削除しないでください。

このサイトでは、すでにお持ちの情報を取り込んで管理する方法を解説します。サブスクリプションの有効性、複数デバイスでの利用可否、サービス期間については、利用中のサービスの案内をご確認ください。アプリの購入履歴からこれらを判断することはできません。

複数プロトコル：タイプを確認してからパラメータを入力

概要：プロトコルは、クライアントとサーバーの接続方法やデータの送受信方法を定めます。Shadowrocketは複数のプロトコルに対応しており、Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2などを利用できます。選択できるタイプとパラメータは、アプリ内のAdd Serverに表示される内容をご確認ください。

場所と設定方法：Add Serverのタイプ選択画面で、手元にあるサーバー情報に合ったプロトコルを選びます。続いて、アドレス、ポート、認証情報に加え、そのタイプで必要なTLSやトランスポート関連の項目を確認します。インポート用リンクも正しいタイプである必要があります。あるプロトコルの項目を別のタイプにそのまま流用しないでください。

注意点：同じサーバーアドレスでも、異なるプロトコルを置き換えて使えるとは限りません。表示名だけではパラメータの正しさも判断できません。ドメイン名、TLSの検証名、トランスポートパスなどはそれぞれ用途が異なるため、入力前に手元の接続情報と照合してください。接続に失敗した場合は、まず不足項目や入力ミスを確認します。証明書の検証を無効にすることを通常のトラブル対処にしないでください。プロトコル名だけで特定のネットワークにおける速度や安定性が保証されるわけではありません。

Config：設定ファイルの有効化と変更

概要：Configは設定ファイルを管理する画面です。設定ファイルにはルール、ポリシー、その他の関連項目を含められます。一方、サーバーのサブスクリプションは、主に接続先の追加と更新に使います。用途が異なるため、サブスクリプションを読み込んだだけで、ルールが希望どおりに設定済みだと考えないでください。

場所と設定方法：Configでファイル一覧を開き、現在有効な項目を記録してから、変更するファイルを開きます。編集前に元のファイルを複製し、既存のルールとポリシーグループの関係を確認してください。保存後は該当ファイルを選択し、有効になっていることを確認します。リモートのファイルを使う場合は、内容の用途と信頼性を確かめてから更新してください。

注意点：リモートファイルを更新すると、ルールの順序、ポリシーグループ名、名前解決の設定などが変わり、ローカルで想定していた動作に影響することがあります。参照関係を確認せずに、異なるソースのルールを直接結合しないでください。問題が起きたときは、変更を重ねるより、直近に動作確認したファイルへ戻すほうが原因を特定しやすい場合があります。設定に個人用のアドレスや認証情報が含まれる場合は、バックアップや同期の際にも機密情報として扱ってください。

On Demand：条件に応じた接続

概要：On Demandは、条件に応じてシステムのVPN接続を開始・維持するための機能です。ルール分岐とは設定の階層が異なります。On Demandは「いつ接続するか」を扱い、Configのルールは「接続後にリクエストをどこへ送るか」を扱います。オンデマンド接続を有効にしても、サーバーの設定が修正されたり、ルールが補われたりするわけではありません。

場所と設定方法：アプリ内のOn Demand設定を開き、まず既存の条件を確認してから、画面で設定できるネットワーク条件を追加します。Wi-Fi、モバイル通信、ドメインに関する条件などを使って動作を設定できます。具体的な動作や入力項目はアプリ内の表示に従ってください。初めて設定する場合は、明確な条件を1つだけ設定し、動作を確認してから条件を追加しましょう。

まず手動接続で、既存のサーバーと設定が正常に使えることを確認します。
テストに使うネットワークを記録し、対応する条件と動作を追加して、ルールの順序を確認します。
条件に合うネットワークに切り替え、システムのVPN状態と実際のリクエストを確認します。
次に条件に合わない状況でもテストし、意図しない再接続や切断が起きないことを確認します。

注意点：Wi-Fi名が正確に一致しているかを確認し、複数の条件が重なる場合は適用順も確認してください。On Demandを有効にした後、手動で切断しても、条件を満たすと再接続することがあります。トラブル対処では、まずこの動作を確認してください。比較テストを行う際は、オンデマンド接続を一時的に無効にし、自動動作の影響を避けます。テスト後に元の設定へ戻してください。オンデマンド接続はバックグラウンド通信を停止する機能ではありません。バッテリー消費は、実際のリクエスト、ネットワーク状況、再接続の頻度によって異なります。

Data：通信量の統計とリクエスト確認

概要：Dataでは、クライアントが記録した範囲の通信量を確認できます。アップロード、ダウンロード、関連するリクエストの変化を把握するのに役立ちます。「いつ通信が発生したか」「どのリクエストを詳しく確認するか」を調べるための機能であり、モバイル通信の請求額や利用中サービスの通信量記録の代わりにはなりません。

場所と設定方法：Dataを開き、まず集計対象の範囲と表示方法を確認してから記録を確認します。接続先をテストするときは開始時刻を控え、新しいリクエストを少数実行して、その後の通信量の変化を比較します。ルーティング結果も確認したい場合は、アプリで確認できる接続記録と照合し、接続先と振り分け先を確認してください。統計をリセットする前に、比較に必要な数値を記録しておきます。

注意点：アプリの記録、システムの統計、接続先サービス側の使用量は、集計期間、プロトコルのオーバーヘッド、集計範囲の違いによって一致しないことがあります。ダウンロード量が多いというだけでルールの誤りとは判断できません。また、テスト中に他のアプリが行ったバックグラウンド通信を対象のリクエストと混同しないでください。テスト条件をできるだけそろえ、同期やメディア再生などの並行通信が結果に影響しないようにします。

Settings：名前解決・テスト・ウィジェット・同期

Settingsの各項目は、それぞれ異なる動作に影響します。解決したい問題を明確にしてから対応する設定を変更してください。機能名、利用範囲、設定画面は、現在のアプリとシステムに表示される内容をご確認ください。

DNS：名前解決と接続の問題を切り分ける

概要と設定場所：DNSはドメイン名をIPアドレスに変換します。SettingsのDNS関連項目を確認するときは、現在のConfigにも名前解決の設定が含まれているか確認し、実際には使われていない項目だけを変更しないようにしてください。

設定方法と注意点：まず現在の値を記録し、同じドメイン名で名前解決できるかを確認してから、利用中のネットワーク要件に応じてシステムDNSまたはカスタムDNSを選びます。DNS over HTTPSを使う場合は、DNSサービス自体に接続できるかも考慮してください。名前解決のリクエストが、まだ確立していない接続経路に依存すると、起動時に問題が起きることがあります。Webページが開かない原因がDNSとは限りません。アドレスの誤り、サーバー認証、ルールの振り分け先を個別に確認してください。詳しくはDNSの設定方法をご覧ください。

Test Method：同じ方法でテストして比較

概要と設定場所：SettingsのTest Methodは、Connectivity Testで使うテスト方法に影響します。テスト結果は選択した方法、テスト先、その時点のネットワーク状況を反映するもので、サーバーのあらゆる利用状況を保証するものではありません。

設定方法と注意点：画面に表示される項目からテスト方法を選び、テスト先とネットワークを変えずに既存の項目と比較します。方法が異なる数値を単純に順位づけすることはできません。また、テストがタイムアウトしても、すべてのアプリから接続できないとは限りません。実際に利用する接続先でも確認し、ハンドシェイクの失敗、名前解決の失敗、接続先の応答遅延を切り分けてください。何度もテストして、一時的な最小値を安定した性能とみなさないようにしましょう。

Today Widget：ショートカット操作後の状態確認

概要と設定場所：Today Widgetは、システムウィジェットから機能をすばやく利用するための入口です。関連する項目はSettingsで確認し、ウィジェットの追加はシステムのウィジェット編集画面で行います。利用できる形式は、デバイスとシステムの表示内容によって異なります。

設定方法と注意点：まずメインアプリでサーバーとルーティングモードを設定してから、必要なウィジェットを追加します。ウィジェットから操作した後は、Homeに戻って接続状態と選択項目を確認してください。システムウィジェットの表示には更新の遅れが生じることがあります。古い表示だけで現在の接続状態を判断しないでください。操作が反映されない場合は、まずメインアプリを開き、許可設定と状態を確認します。

iCloud：同期範囲とデバイスごとの差

概要と設定場所：iCloud関連の項目では、アプリが対応する範囲のデータを同期できます。Settingsでアプリの同期設定を確認し、システム側のiCloudアクセス権も確認してください。アプリの購入履歴と設定の同期は別の仕組みです。混同しないようにしてください。

設定方法と注意点：元のデバイスで同期状態を確認してから、別のデバイスで実際に同期された項目を確認します。変更前に、復元できるよう設定のコピーを保存してください。ローカルのすべての履歴、システムのVPN許可、デバイスの状態が完全に移行するとは限りません。同期データに個人用のサーバー情報が含まれることもあるため、アカウントとデバイスへのアクセス権を適切に管理してください。新しいデバイスで初めて接続する際は、システムの案内に従って必要な許可を設定します。

Diagnostics：比較記録を使った原因の特定

概要：Diagnosticsは、トラブル対処に必要な情報を確認・収集するための機能です。すべての設定を一度に変更するのではなく、問題がローカルネットワーク、サーバー接続、ドメインの名前解決、ルール処理のどの段階にあるかを特定するために使います。

場所と設定方法：SettingsからDiagnosticsを探し、画面に表示されるツールで接続や記録を確認します。問題が起きた接続先、ネットワークの種類、Global Routingのモード、有効なConfigを記録してから、同じ問題を一度再現してください。診断のために記録を一時的に有効にした場合は、再現後すぐに無効にし、書き出す内容に機密情報が含まれていないか確認します。

基本ネットワークを確認。デバイスのネットワーク自体が利用できることを確認し、ネットワーク全体の問題と特定の接続先だけの問題を切り分けます。
サーバーを確認。手元の接続情報を確認し、Connectivity Testを実行します。数値だけでなく、テスト方法も記録してください。
モードとルールを確認。一時的にProxyに切り替えてConfigと比較します。結果が異なる場合は、ルールの一致状況とポリシーの参照先を確認してください。
名前解決を確認。ドメイン名の名前解決に問題がある場合に限りDNSを確認し、サーバー認証の失敗を名前解決の問題と混同しないようにします。
テスト用の変更を元に戻す。元のモード、オンデマンド条件、記録設定に戻し、一度に1項目だけ変更して得られた確認結果を記録します。

注意点：診断記録には、アクセス先のドメイン名、サーバーアドレス、サブスクリプションのパラメータ、認証情報が含まれることがあります。問題を共有する際は、エラーの種類と必要な状況だけを残し、個人情報に関する項目を伏せてください。設定ファイル全体やサブスクリプションURLを公開しないでください。ツールの出力は判断材料の一部です。実際のリクエストと現在の設定もあわせて確認します。