サブスクリプション Subscribe
既存のサブスクリプションを読み込みます。更新されるのはサーバーの項目であり、振り分け設定全体が自動的に置き換わるわけではありません。
Appleプラットフォーム向けクライアント
App Store限定配信
買い切り
ルールによる振り分け
システム要件はApp Storeの表示をご確認ください
CONFIGURATION / MATCH / POLICY
サブスクリプション・ルール・ポリシーの違い
まず接続情報を確認し、そのうえでリクエストの経路を決めます。Subscribeは既存のサーバー情報を管理し、Configは振り分け設定を保存し、Ruleはリクエストに適用するポリシーを決定します。それぞれ役割が異なり、読み込みが完了しても接続確認が済んだことにはなりません。
ルール Rule
条件を上から順に確認します。具体的な例外が先にある広いルールに上書きされないようにします。
ポリシー Policy
PROXYはプロキシ経由、DIRECTは直接接続、REJECTはリクエストを拒否します。ポリシーを設定しても接続先への到達が保証されるわけではありません。
サーバー情報と設定ファイルを区別する
サーバー情報では「どのプロトコルを使い、どのアドレスに接続し、どう認証するか」を指定します。設定ファイルでは「どのリクエストをプロキシ経由にするか、どれを直接接続するか、ドメインをどう解決するか」を指定します。既存のサブスクリプションは通常、サーバー項目をまとめて管理するためのもので、ファイル名だけではルールが含まれているか判断できません。読み込み後は、Homeで選択中のサーバーと、Configで現在有効な設定をそれぞれ確認してください。
右上のルール作業スペースは、テキストの照合方法を示す例であり、そのまま使える設定ではありません。たとえば、exampleを含む広い条件が先にあると、後ろにあるad.example.comの例外が適用されない場合があります。実際に変更する際は、まず適用したいポリシーを決め、条件の範囲と順序を確認してください。ファイル末尾にルールを追加し続けるだけの調整は避けましょう。
FUNCTION INDEX
設定項目ごとの用途と注意点
以下の項目を選ぶと説明を確認できます。コードは構文やフィールドを部分的に確認するための例です。予約ドメインとドキュメント用アドレスを使用しており、接続情報としては使えません。
Global Routing：リクエストの振り分け方法を選ぶ
HomeでGlobal Routingを確認します。Configモードでは現在の設定に従って振り分け、Proxyモードでは通常のリクエストを選択中のプロキシに送信し、Directモードでは直接接続します。ドメインやアドレスごとに経路を分ける場合は、まずConfigを選び、Configで有効になっているファイルを確認してください。モードを切り替えてもサーバーの認証情報は補われず、サーバーが利用可能になるわけでもありません。トラブルシューティングでは一度に一つの条件だけを変更し、同じ接続先で結果を比較してください。サーバー、ルール、DNSを同時に切り替えると、原因を特定しにくくなります。以下の例は、対応するルール設定を使う場合の振り分け方針を示します。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTOn Demand：条件に応じて接続を開始する
On DemandはSettingsにあり、設定した条件に応じてシステムに接続を要求させる機能です。サーバーを利用可能にする機能ではありません。設定する前に手動で接続し、実際のアクセスを確認してから、対象となるネットワーク条件を確認してください。有効にしたあと、手動で切断しても再接続される場合は、設定を何度も削除するのではなく、まずOn Demandを確認します。ネットワークごとの動作はシステムの状態にも左右され、すべてのリクエストが必ずプロキシ経由になるわけではありません。一時停止するには、関連する条件を無効にしてから接続を切断してください。以下はトラブルシューティング時の確認順序であり、読み込み用の設定ではありません。
Settings → On Demand
手動接続を確認 → 条件を確認 → ネットワークを切り替えて再テストSubscribe：既存のサーバー項目をまとめて管理する
既存のサブスクリプションリンクを使うと、サーバー情報をまとめて読み込み、更新できます。通常はHomeの追加操作から進みます。読み込み前に、クリップボードにリンク全体がコピーされていることを確認してください。読み込み後はグループと項目を確認し、その中から一つ選んでテストします。更新によってアドレス、認証パラメーター、項目名が変わる場合があるため、サブスクリプション管理対象の項目に手動変更を混在させないようにしましょう。サブスクリプションリンクにアクセス情報が含まれることがあるため、問い合わせ時はリンク全体と認証情報を隠してください。このサイトでは既存情報の読み込みと管理方法のみを説明し、サブスクリプションは提供しません。以下は予約ドメインとダミー値を使ったリンク形式の例です。
https://example.com/sub?token=xxxxConfig：動作設定を項目ごとに保存する
Configの設定ファイルには、General、Rule、Host、URL Rewriteなどのセクションが含まれ、それぞれ異なる動作を設定します。エディターにファイルの内容が表示されても、ファイルが存在することを示すだけです。現在有効な項目とGlobal Routingモードも確認してください。変更前に復元可能なコピーを保存し、一度に一か所だけ変更してテストすると、問題の原因を特定しやすくなります。サブスクリプションの更新と設定の切り替えは別の操作です。サーバー項目の増減を、ルールが更新された証拠と考えないでください。以下は有効なルール行を二つだけ示した例であり、実際の要件に合わせて確認する設定全体の代わりにはなりません。
[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXYRule：最初に一致したルールでポリシーを決定
Ruleは条件を上から順に確認し、一致した行に指定されたポリシーを適用します。DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲に一致します。名前が似ていても、異なるキーワードを置き換えて使うことはできません。例外を設定する場合は、その例外を上書きしうる広い条件より前に、対象範囲の狭い条件を置きます。最後のFINALは、それ以前のルールに一致しなかったリクエストを処理します。診断時は、実際の接続先、一致した行、最終的なポリシーを確認してください。ファイルにドメインが記載されているかだけでは判断できません。以下の例では、特定ドメインの例外を先に置き、その他の例示ドメインへのリクエストを拒否します。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXYDNS：名前解決の失敗と接続の失敗を区別する
DNSはドメイン名をIPアドレスに変換する、接続プロセスの一部です。ドメインではアクセスできずIPアドレスには到達できる場合、名前解決を確認する必要がある可能性はありますが、特定のDNSリゾルバーに問題があると断定はできません。現在のConfigのDNS設定を確認し、実際の名前解決結果、キャッシュ、リクエストの経路もあわせて判断してください。出所の分からないアドレスを大量に設定せず、内容を把握できる設定を保ったうえで、同じドメインに再度アクセスして確認します。変更後はリクエストを再実行し、結果が変わるかを確認してください。以下はGeneralの設定構文の一部です。systemはシステムのDNS設定を使うことを示すもので、すべてのネットワークに適した固定の設定ではありません。
[General]
dns-server = systemURL Rewrite：条件に応じてURLを処理する
URL Rewriteは、条件に一致するURLに指定した処理を適用します。プロキシ接続か直接接続かを選ぶRuleとは役割が異なります。編集前に対象リクエストの範囲を決め、式が広すぎないか確認してください。暗号化されたリクエストで確認できる範囲は、接続方式や関連設定によって異なります。一つの書き換えルールですべてのアプリの通信を制御できるわけではありません。アクセスに問題が起きた場合は、追加した書き換えを無効にして再確認できます。設定全体を同時に削除しないでください。以下は予約ドメインを使ったリダイレクト構文の例です。このページを読むために証明書をインストールする必要はなく、実際のサイトに汎用的に適用できる書き換え方法でもありません。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302Host：ドメインマッピングの適用範囲を明確にする
Hostは指定したドメインにローカルのマッピングを設定します。接続先のアドレスが分かっている場合に、名前解決の差を確認する用途に使えます。サーバーのサブスクリプションではなく、プロトコル認証の代わりにも、接続先サービスの変更にもなりません。マッピングを追加した後は、リクエストが実際にそのアドレスを使っているか確認してください。接続先サービスがドメインと証明書の一致を必要とする場合もあります。古いアドレスを長期間残すと一部のアクセスに問題が起きることがあるため、各マッピングの用途と元に戻す方法を明確にしてください。以下はドキュメント用アドレスを使った例で、実際のアクセスには使用できません。固定マッピングが必要な接続先がなければ、設定を充実させるためだけにこのセクションを追加する必要はありません。
[Host]
example.com = 192.0.2.10Proxy：プロトコルのパラメーターをサーバー情報に合わせる
Add ServerでTypeを選び、既存のサーバー情報に基づいてHost、Portと、プロトコルに必要な認証フィールドを入力します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardのパラメーターは相互に流用できません。プロトコルによっては、トランスポート方式、TLS、サーバー名も確認が必要です。プロトコル名だけで速度やバッテリー消費を判断しないでください。ネットワーク品質、トランスポート設定、サーバー側の性能も影響します。共有リンクを読み込むと手入力によるミスを減らせますが、読み込み後の各フィールドも確認してください。以下はフィールド確認用の一覧です。実際の値は、すでにお持ちのサーバー情報を使用してください。
Type → Host → Port
認証情報 → トランスポート設定 → TLS（必要な場合）Diagnostics：接続段階ごとに原因を絞り込む
HomeのConnectivity TestとSettingsのDiagnosticsは、接続状態の判断に役立ちます。ただし、一度のテスト結果だけで、すべての接続先やプロトコルの動作を判断することはできません。現在のネットワーク、サーバー、Global Routingを記録し、同じ接続先で再テストして、名前解決、サーバー接続、認証、ルールの経路を切り分けます。遅延の数値は、選択したテスト方法での応答時間や接続処理を示すもので、継続的な通信速度ではありません。診断情報を共有する前に、サブスクリプションリンク、認証情報、個人のアクセス履歴を削除してください。以下は順番に確認する項目であり、診断結果をあらかじめ決めるものではありません。
現在のネットワーク → DNS → サーバーへの到達性
認証とトランスポート → 一致したルール → 接続先への実アクセスData：通信量の集計範囲を確認する
Dataの通信量情報では、クライアントの集計範囲内にある接続状況を確認できます。数値を見る前に、集計期間、リセットの有無、現在のリクエストに適用されているポリシーを確認してください。送受信量をサービス提供元の請求量とそのまま同一視することはできません。プロトコルのオーバーヘッド、集計方法、期間によって差が生じることがあります。通信量が急増した場合は、一つの累計値だけで原因を決めず、バックグラウンド同期や継続中の転送がないか確認し、接続記録もあわせて調べてください。前後の差を記録する場合は、同じ時間帯で測定し、異なる集計期間のデータを混ぜないようにします。以下は確認する項目の例です。
Data
集計期間 / アップロード / ダウンロード / 現在の接続とポリシーiCloud：同期と復元は分けて確認する
iCloud関連の同期や読み込み機能を使う前に、デバイスのサインイン状態、システムの権限、クライアントで利用できる項目を確認してください。アプリの購入記録、サーバー情報、設定ファイル、接続の認証は、それぞれ別のデータです。アプリを再ダウンロードしても、すべての設定が自動的に復元されるとは限りません。重要な設定は復元できるコピーを別途保管し、認証情報が含まれる場合は適切に保護してください。別のデバイスで同期した後も、現在の設定とサーバー選択を確認し、システムの案内に従って接続します。以下では復元時に確認する二つの項目を分けて説明します。同期の対象範囲は、クライアントの現在の画面で確認してください。
App Store → 購入済み項目を確認
iCloud / クライアントから読み込み → 設定とサーバー情報を確認FIRST CONNECTION
初回接続：読み込み・モード選択・確認
始める前に、すでにお持ちのサブスクリプションリンクまたはサーバー情報をご用意ください。アプリの購入で入手できるのはクライアントであり、実際の接続には有効なサーバーパラメーターが必要です。初回は変更を最小限にし、接続できることを確認してから、ルールや自動接続の条件を順に追加してください。
既存のサーバーまたはサブスクリプションを追加
Homeから追加操作に進みます。共有リンクをお持ちの場合は、最初にリンク全体をコピーし、読み込み結果を確認してください。手動入力する場合は、先にTypeを選び、Host、Port、認証フィールドの順に確認します。QRコードはご自身がすでにお持ちの情報から取得し、読み込み後に内容を確認してください。
サブスクリプションを読み込んだら、グループが表示されているか、項目が揃っているかを確認してから、サーバーを一つ選びます。パラメーターを確認する前に、複数の詳細設定を同時に有効にしないでください。読み込みに失敗した場合は、まずリンクが改行で分割されていないか、内容が空でないかを確認し、形式が対応しているか判断します。
Config・Proxy・Directを選択
ルールで振り分ける場合はConfigを選び、Configで現在有効なファイルを確認します。ProxyとDirectはリクエストの経路を比較するためのモードであり、接続を自動修復するスイッチではありません。モードを変更したら、同じ接続先に再度アクセスして結果を比較してください。
あるWebサイトにはアクセスできても別のサイトに失敗する場合は、まず両者に異なるポリシーが適用されていないか確認します。想定したサーバーと設定が使われていることを確かめてから、DNS、認証、ルールを調べてください。Homeに項目が表示されているだけでは、設定が有効になったとは判断できません。
接続を開始し、実際のアクセスを確認
接続を開始するときは、システムの案内に従ってVPN構成の追加を確認し、許可してください。この許可はシステムネットワークへの接続のみに必要です。すでにお持ちのサブスクリプションのサーバー認証は別途確認してください。接続後、まずConnectivity Testを実行し、次に実際にアクセスしたい接続先を開いて、想定どおりか確認します。
システムに「接続済み」と表示されても、接続構成が動作中であることを示すだけで、すべての接続先への到達を保証するものではありません。失敗した場合は、ネットワークとモードを記録し、まずサーバーパラメーターを確認してから、リクエストに適用されたポリシーを調べてください。一度に一項目だけ変更し、変更前後を比較できる状態を保ちます。
設定を一度に変更せず、順番に確認する
初回接続が想定どおりでない場合は、まず元の情報を保存し、サブスクリプションやサーバーパラメーターの入力ミスがないか確認してください。続いて、クライアントで対象の項目が選択されているか、Global Routingが想定どおりか、現在のConfigが有効かを調べます。基本項目を確認してから、名前解決と具体的なリクエスト記録を確認してください。テストがタイムアウトしただけでは、原因がルールかサーバーかは判断できません。
別のネットワークに切り替えた場合は、同じ接続先で再度確認し、一部のリクエストだけに問題が起きるか記録してください。これにより、環境の変化と設定の変更を切り分けやすくなります。サポートを依頼する際は、モード、エラーの内容、試した手順を伝えれば十分です。サブスクリプションリンク全体、パスワード、その他の認証情報は公開しないでください。
DEVICES & APP STORE
iPhone・iPadでの入手方法
入手先はApp Storeのみです。両デバイスでの購入対象、システム要件、互換性はApp Storeの表示をご確認ください。購入済みのデバイスでも、それぞれのアカウントと接続設定を確認する必要があります。
iPhone
まずApp Storeの製品情報を確認してから、購入とインストールを進めてください。初回接続時はシステムの案内に従って許可し、その後Homeに戻って既存のサーバーを選択します。ネットワークや設定を変更した場合は、実際にアクセスできるか再確認してください。
ストアで検索結果が表示されない場合は、アカウントの国または地域と、製品ページの表示内容を確認してください。検索結果に表示されない問題と、クライアントの接続障害を混同しないようにしましょう。
iPhoneでの入手手順を見る →iPad
同じApple IDで購入済み項目を確認してください。購入対象はストアページの表示をご確認ください。iPadでも、設定の読み込み、現在のサーバー、Global Routingを確認する必要があります。別のデバイスで接続できたことは、このiPadでの確認結果にはなりません。
画面が広いと設定ファイルを読みやすくなりますが、ルールの照合方法は画面サイズによって変わりません。既存の設定を復元した後は、内容が揃っているか確認してから接続し、リクエストの経路を確認してください。
iPadでの入手手順を見る →Mac / Apple TVでも同じApp Storeから入手できます。互換性はストアページの表示をご確認ください。
入手手順を見る →PRODUCT IDENTITY & PURCHASE
正規版の確認と買い切りの対象
当サイトはShadowrocketの公式サイト・公式マニュアルです。購入前に、検索結果のタイトルだけで判断せず、Shadowrocketの製品名、開発者名、公式アイコン、アプリIDを照合してください。
Shadowrocket
Shadow Launch Technology Limited
アプリID 932747118
クローズドソースの商用アプリ
アイコン、デベロッパ、製品ページURLに含まれるIDを照合してください。三つの情報が一致することを確認します。
製品ページで三つの情報を確認
App Storeの製品ページを開き、アプリ名とアイコンを確認してから、デベロッパがShadow Launch Technology Limitedであることを確認してください。製品ページのURLにあるid932747118がアプリIDです。アイコンが似ているだけでは確認できません。同じ名前やよく似た名前も、これら二つの文字情報の代わりにはなりません。
検索結果から製品ページを開いた場合も、詳細ページで改めて確認してください。このサイトに掲載している公式アイコンは外観の照合に使えます。最終的な価格、互換性、購入情報はApp Storeの表示をご確認ください。クライアントのアップデートもApp Storeで管理されます。変更内容を確認する場合は、チュートリアルの画面外観から推測せず、ストアのアップデート情報をお読みください。
価格・購入と接続サービスは別
Shadowrocketは有料アプリです。米国ストアでの参考価格は2.99米ドルで、買い切りです。各ストアでは現地通貨で表示され、最終価格は購入確認画面をご確認ください。買い切りで入手できるのはクライアントアプリです。サーバーへの接続性、利用期間、アクセス環境を保証するものではありません。
クライアントの買い切り ≠ 接続サービスのプラン。このサイトでは、ノードやサブスクリプションを提供・販売・推奨していません。接続機能を使うには、すでにお持ちのサブスクリプションまたはサーバー情報をご用意ください。既存サービスの有効期限、アドレス変更、認証情報は、利用中のサービスの条件に従います。クライアントを再インストールしても、自動的に復元または延長されることはありません。
ストアの表示とアカウントの地域
App Storeでは、アカウントの国または地域に応じて製品が表示されます。検索結果や購入の可否が異なる場合があります。Shadowrocketが検索結果に表示されない場合は、まずアカウント設定で現在のストアを確認し、このページから製品ページを開いて表示内容を確認してください。検索できないからといって、アプリ名が変更されたとは限らず、購入済み項目が無効になったとも判断できません。
アカウントを確認するときは、デバイスのサインイン状態とApp Storeで購入するアカウントを区別してください。地域、支払い方法、購入制限については、アカウント設定とストアの案内をご確認ください。クライアントの接続障害を調べるために購入設定を何度も変更しないでください。ストアからの入手とネットワーク接続は別の手順であり、前者で既存サーバーの認証エラーは解決できません。
機種変更時の復元と複数デバイスでの購入
機種変更や再インストールの際は、以前購入したアカウントでApp Storeの購入済み項目を確認し、Shadowrocketの製品ページも確認してください。iPhoneとiPadで共通の購入が適用される範囲や、その他の対応デバイス、ファミリー共有などの条件は、App Storeの表示をご確認ください。再購入を求める画面が表示された場合は、すぐに再購入せず、まずアカウントと購入記録を確認してください。
アプリの復元と設定の復元は別に行います。購入記録からアプリを再入手し、サーバー情報や設定ファイルは、ご自身のバックアップまたは既存の同期データから復元してください。復元後は現在のサーバー、Config、Global Routingを再確認し、このデバイスのシステムの案内に従って接続します。別のデバイスの認証やテスト結果で、このデバイスの確認を代用することはできません。
日常の管理：コピーを保管してから小さく変更する
安定して使えるようになったら、「サーバー情報」「振り分け設定」「自動接続条件」を分けて管理します。サブスクリプション更新後は項目の変化を確認し、ルール変更後は一致結果を確認し、On Demandの変更後はネットワークを切り替えて動作を確認してください。操作を分けると、問題が起きた際に原因となった手順を特定しやすくなります。重要な設定は復元可能なコピーを保管し、認証情報も適切に保護してください。
Shadowrocketが接続できない場合は、現在のネットワーク、選択中の項目、Global Routing、具体的なエラーを記録してください。「スイッチがオン」の画面だけを共有するより、トラブルシューティングに役立ちます。ログを共有する前に、サブスクリプションリンク全体、サーバーのパスワード、個人のアクセス履歴が含まれていないか確認してください。診断の目的は、再現可能な失敗箇所を見つけることです。テストの数値を上げようとして、すべての設定を何度も変更することではありません。
よくある質問
読み込み後にサーバーを選択する必要があるのはなぜですか？
読み込み操作で情報がクライアントに保存されます。その後、Homeで使う項目を選択し、Global Routingと現在の設定を確認してから接続してください。項目が存在すること、テストに成功すること、実際の接続先に到達できることは、それぞれ別の確認結果です。順番に確認しましょう。読み込みと接続の手順を見る →
遅延が小さいのに、実際のアクセスが不安定なのはなぜですか？
遅延テストで分かるのは、特定の方法で測定した接続時間や応答時間です。通信速度、パケットロス、接続の継続性、接続先サービスの応答までは確認できません。同じサーバーとモードを保ち、実際の接続先で再テストしてから、ネットワークの変化によるものか判断してください。接続確認とトラブルシューティングを見る →
ルールを追加してもリクエストの経路が変わらないのはなぜですか？
Global RoutingがConfigになっているか、変更したファイルが有効かを確認してから、ルールの順序と実際のリクエストのドメインを確認してください。先にある広い条件に新しいルールが上書きされると、そのルールはポリシーを決定しません。確認後、リクエストを再実行して結果を比較します。ルール設定の説明を見る →
アプリを再ダウンロードすると、すべてのサーバー情報が復元されますか？
購入記録と設定データは分けて確認してください。App Storeから購入済みアプリを再入手し、設定はご自身のバックアップ、既存のサブスクリプション、またはクライアントで利用できる同期データから復元します。復元後も情報が揃っているか確認し、接続を再テストしてください。購入済みアプリの復元方法を見る →
TECHNICAL NOTES
技術ノート：仕組みと操作上の注意
基本の手順を確認した後は、問題に応じて各記事をお読みください。以下のノートでは、ルールによる拒否の範囲、ストア表示とアカウント地域の関係、遅延テストで分かることを解説します。読む前に、問題が購入、設定、接続のどの段階にあるか確認してください。
ShadowrocketのREJECTポリシー：ルールによるブロックの仕組みと限界
照合条件と拒否ポリシーをもとに、ドメイン単位でリクエストを処理できる範囲を解説します。同じドメイン内のコンテンツやアプリ内のリクエストなど、ドメインルールだけでは細かく分けられないケースも取り上げます。
中国本土のApp StoreでShadowrocketが見つからない場合：Apple IDの地域とストア表示について
手順に沿ってアカウントのストア地域を確認し、検索結果、製品ページの表示、購入済み項目を区別します。購入に関する問題はストア情報を確認し、クライアントの接続障害と混同しないようにしてください。
Shadowrocketでサーバーを選ぶ方法：遅延テスト・地域・プロトコルと、数値が実際の使い心地を示すとは限らない理由
すでにお持ちのサーバー項目をもとに、テスト方法、地域、プロトコル設定が結果に与える影響を説明します。条件をそろえて比較する方法も紹介します。接続サービスの推奨は行いません。