公式ガイド / 初回接続

Shadowrocketの使い方

既存サブスクリプションの追加 → Global Routingの選択 → 接続許可 → 動作確認 → トラブル対処。まず再現可能な接続を一度確立してから、ルールや自動接続の設定を調整します。

  • 操作する画面 Home / Config / Data
  • まず手動接続を確認
  • 設定は一度に1項目だけ変更

STEP 01 / 既存情報を追加

Add Server：サーバーの追加またはSubscribe

手元の情報を確認し、該当する追加方法を選びます。サブスクリプションURLは複数のサーバー情報を取得するためのアドレスで、個別サーバーのアドレスとは異なります。単一サーバーの情報には通常、プロトコル、アドレス、ポート、認証情報が含まれます。両者を混同しないでください。Shadowrocketを開き、Homeに移動して右上の追加ボタンをタップし、Add Serverを開きます。以下の2つの方法から手持ちの情報に合うものを1つ選んでください。重複して追加する必要はありません。

既存のサブスクリプションURLがある場合：Subscribeを選択

Add ServerのTypeでSubscribeを選び、自分のサブスクリプションURL全体をURLに入力し、見分けやすいメモを付けます。貼り付け後、URLの先頭と末尾が欠けていないか、改行や空白、チャットの文章が混ざっていないか確認してから保存します。URL内のクエリパラメーターが認証に使われる場合があります。短くするために削除しないでください。入力するのは既存サブスクリプションの取得URLです。サービスの案内ページやアカウントのログインページではありません。

保存後にHomeへ戻り、情報の取得が完了するまで待って、該当グループにサーバーが表示されるか確認します。サブスクリプション名が表示されても、内容の取得が完了したとは限りません。グループを展開でき、選択可能なサーバーが含まれていることを確認してください。追加後に一覧が空の場合は、表示されたメッセージを控え、URLの有効性と現在のネットワークを確認します。同じサブスクリプションをすぐに何度も追加しないでください。以後の更新は既存のサブスクリプションを更新すればよく、通常は更新のたびに追加し直す必要はありません。

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

Add Serverを開き、Typeで情報に指定されたプロトコルを選んで、サーバーアドレス、ポート、対応する認証情報を順に入力します。たとえばShadowsocks、VMess、VLESS、Trojanでは入力項目が異なります。手持ちのサーバー情報に従ってください。アドレス欄には指定されたホスト名またはアドレスだけを入力し、サブスクリプションURL全体を貼り付けないでください。名称からプロトコルを推測したり、複数の項目の情報を組み合わせて新しいレコードを作成したりしないでください。

TLS、サーバー名、トランスポート関連のオプションが情報に含まれている場合は、それらも確認してください。アドレスとポートだけでは不十分なことがあります。Scan QR Codeで既存の接続情報を読み込む場合も、保存後に解析されたタイプとアドレスを確認してください。スキャンに成功しただけでは確認は完了しません。該当する項目の明確な情報がない場合は、元の説明を確認し、暗号化や認証の設定をむやみに変更しないでください。

この手順の完了条件は、Homeに情報の出所が明確で、必要な項目がそろい、選択できるサーバーが1件表示されていることです。メモと所属グループを確認しておきます。次はGlobal Routingを選択し、接続後の通信の処理方法を決めます。初回の手動テストに自動接続が影響しないよう、On Demandはまだ有効にしないでください。

STEP 02 / 通信の経路を確認

Global Routing：Config、Proxy、Direct

サーバーを追加しても、すべての通信がそのサーバーを経由するとは限りません。Homeに戻ってGlobal Routingを開き、現在のモードを確認します。選択肢はConfig、Proxy、Directです。何を確認するかを決めてから選択してください。接続スイッチがオンであることと、すべての通信が選択したサーバーを使うことは同じではありません。

モード意味初回確認のポイント
Config現在有効な設定のルールとポリシーに従ってリクエストを処理します。Configで有効なファイルと、ルールの処理先を確認します。
Proxy通信をプロキシ経由で処理し、サーバーへの接続状況を比較します。現在選択されているサーバーまたは関連するポリシーを確認します。
Direct通信を直接接続で処理します。基本ネットワークの確認に適していますが、サーバーが利用可能である証明にはなりません。

ルールを使う場合：まずConfigを確認

Configを使う場合はConfig画面を開き、現在有効な設定と、その中のルールやポリシーを確認します。Subscribeの読み込みとConfigの有効化は別の操作です。サブスクリプションは主にサーバー一覧の更新に使い、Configは条件に一致した通信の処理先を決めます。Homeにサーバーが表示されても、Config内のすべてのポリシー参照が自動的に置き換わるわけではありません。内容を理解していない設定は、出所と内容を確認してから適用してください。

たとえば、DOMAIN-SUFFIX,example.com,PROXYは、ドメイン末尾がexample.comに一致する場合、PROXYが示すプロキシ経由で処理するという意味です。IP-CIDR,192.168.0.0/16,DIRECTは、該当するアドレス範囲をDIRECTで処理します。これらはルール構文の例です。入門手順を完了するために、現在の設定へそのままコピーする必要はありません。ルールは記述順に評価されます。先に一致したルールが適用されると、後続のルールは処理に使われないことがあります。

比較のためにProxyを使った場合は、終了後に元へ戻す

既存サーバーに接続できるかをまず確認する場合は、一時的にProxyを使うとルール選択による影響を抑えられます。テスト前に元のモードを控え、Homeでテスト対象のサーバーが選択されていることを確認してください。テスト後はConfigに戻します。Directは、デバイスから通常アクセスできる対象に直接接続できるかを確認する方法です。リモートサーバーの動作確認の代わりにはなりません。

この手順の終了時には、「現在どのモードで、どの設定またはサーバーを使っているか」を説明できる状態にします。まだ確認できない場合は、DNSとOn Demandを同時に変更しないでください。ルールの優先順位やポリシー参照などの詳しい内容はルールによる振り分け設定をご覧ください。ここでは経路を明確にしたうえで、次の接続手順に進みます。

STEP 03 / 手動接続を確立

Home：接続スイッチをオンにしてVPN構成を許可

Homeに戻り、サーバーの選択状態とGlobal Routingをもう一度確認します。似た名前のサーバーがある場合は、グループとプロトコルも確認して取り違えを防いでください。準備ができたら画面上部の接続スイッチをオンにし、アプリに表示される接続状態を確認します。初回はシステムの許可を求められる場合があります。許可が完了する前にスイッチの一時的な変化だけを見て、サーバーのエラーと判断しないでください。

初回にVPN構成の追加を求められた場合

システムがVPN構成の追加を求めるのは、Shadowrocketがデバイスの通信を処理するためのシステム接続を確立できるようにするためです。Shadowrocketで自分が接続を開始したことを確認したうえで、システムの案内に従って許可し、デバイスが求める認証を完了してください。これはサーバーの追加とは別の段階です。システムの許可はアプリが接続を確立できるかを決め、サーバー情報はその後の通信が成功するかを左右します。

許可したらShadowrocketに戻り、接続が続いているか確認します。途中でキャンセルした場合、必要な許可が完了していないため、接続を再度開始して案内に従ってください。サーバーのパスワードを何度も変更する必要はありません。システム設定のVPN項目で構成の状態を確認できます。設定画面の場所はシステムのバージョンによって異なる場合があるため、設定内の検索でVPNを探してください。復旧手順が増える可能性があるため、システム構成の削除を最初の対処として行わないでください。

接続状態と実際のアクセス結果を分けて確認

スイッチがオンのまま、またはシステムにVPN状態が表示されていれば、システム接続は確立しています。ただし、それだけでは確認は完了していません。選択したサーバーに到達できない場合や、対象の名前解決に失敗する場合、現在のルールで対象がDirectになる場合もあります。接続後も同じ設定のまま動作を確認してください。状態表示だけで完了と判断したり、結果が分からないまま複数のモードを次々と切り替えたりしないでください。

初回の手動テスト中は、VPN接続を管理する他の設定を一時停止し、同じネットワーク環境を保ってください。On Demandの条件が設定されている場合は、条件を控えてから自動接続を一時停止します。手動でオフにしたあと自動で再接続すると、スイッチが効かないように見えることがあります。テストを成功したように見せるためだけに、用途が分からないシステム設定を削除しないでください。

この時点で、Wi-Fiとモバイル通信のどちらを使っているか、Homeで選択したサーバー、Global Routingのモードの3点を記録しておくことをおすすめします。次の手順でアクセスに失敗しても、テスト条件を明確にして原因を絞り込めます。複数の設定を同時に変えるより、接続が安定してから自動化の設定を少しずつ追加するほうが原因を特定しやすくなります。

STEP 04 / 段階的に動作を確認

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

確認する項目は、システム接続が確立しているか、選択したサーバーに現在のテスト方法で到達できるか、実際の対象に想定どおりアクセスできるかの3つです。どれか1つの結果で、ほかの項目を判断することはできません。まずHomeでConnectivity Testを実行し、使用したテスト方法と各結果を確認します。続いて、普段使うアプリまたはブラウザーでアクセスしたい対象を開きます。

テスト結果を確認してから実際の通信を試す

Connectivity Testの結果は、テスト方法、テスト対象、現在のネットワーク、サーバーの処理方法によって変わります。数値が表示されても、それは今回のテストで結果が得られたことを示すだけで、すべてのWebページやアプリが正常に動作する保証にはなりません。タイムアウトの場合もテスト対象を考慮し、すべての通信が失敗したと即断しないでください。複数のサーバーを比較する場合は、同じテスト方法とネットワークを使います。条件が違うと数値を比較できません。

実際にアクセスする際は、まず普段から問題なく開けるページを基準として確認し、その後に本来使いたい対象を試します。特定のアプリだけ失敗する場合は、ブラウザーで同じサービスのページを開き、アプリ側の問題か接続の問題かを切り分けてください。テスト対象を一定にし、試すたびに別のページへ変えないでください。すでに開いている古いページだけで新しい接続の成功を判断するのも避けてください。キャッシュが表示され、新たな通信が発生していない場合があります。

Dataで接続記録を確認

Dataを開き、現在表示されるリクエストや接続情報から、先ほど試した対象の記録を探します。リクエストが記録されているか、対象のドメインまたはアドレスが想定どおりか、表示されるポリシーや処理先が適切かを確認してください。表示される項目はアプリ内の情報に従います。必要な情報が記録されていない場合は、履歴から適当な記録を選んで判断せず、対象を指定して新しいリクエストを発生させてください。

Configを使っている場合は、一致したルールと想定していたルールが合っているかを確認します。Directになるはずの対象がプロキシポリシーに一致した場合は、有効な設定とルールの順序を確認してください。Proxyになるはずの対象がDIRECTに一致した場合は、まず該当したルールを特定します。FINALの処理先を変更するだけでは解決しないことがあります。リクエストがそれより前のルールですでに処理されている場合、フォールバック先を変えても影響しないためです。

接続状態が正常で、実際の対象への新しいリクエストが想定どおり成功し、表示された処理先も現在のルーティング選択と一致すれば、確認完了です。テスト中にProxyを一時使用した場合は、Configに戻して同じ対象を再度確認してください。その後、利用状況に合わせてOn Demandを設定します。条件と優先順位についてはOn Demandの設定方法をご覧ください。

STEP 05 / 1項目ずつトラブル対処

接続できない場合：ネットワークからルールまで確認

問題が起きたら、まず状況を記録してから確認する箇所を決めます。「サブスクリプションを取得できない」「スイッチがオンの状態を保てない」「テストがタイムアウトする」「特定の対象だけ開けない」は、それぞれ異なる問題であり、同じ方法で対処するのは適切ではありません。現在の設定とエラーメッセージを残し、条件を一度に1つだけ変更して同じ対象で再テストしてください。以下のように外側から順に確認すると、無駄な操作を減らせます。

第1段階：基本ネットワークとサブスクリプション

まず接続をオフにし、デバイスから普段アクセスできるページを開けるか確認します。Wi-Fiでネットワークへのログインが必要な場合は、先にログインを完了してください。モバイル通信では、通信サービスとアプリの利用許可を確認します。基本ネットワークが使えない場合は、まずその問題を解決してください。Wi-Fiとモバイル通信を切り替えて比較する場合は、それぞれの結果を別々に記録し、切り替え前後のテストを混ぜて比較しないでください。

Subscribeの更新に問題がある場合は、URLが完全か、既存のサブスクリプションが有効か、現在のネットワークからそのURLを取得できるかを確認します。更新に成功しても一覧を取得できたことを示すだけで、含まれるすべてのサーバーが正常とは限りません。更新に失敗しても、保存済みのサーバー情報がすぐに無効になるとは限りません。まず表示されたメッセージを確認し、自分のサブスクリプション情報を見直してください。問い合わせを公開する場合は、認証情報を含むURL全体を表示しないでください。

第2段階：サーバー情報とシステムの許可

一覧にサーバーがあるのにテストに失敗する場合は、プロトコル、サーバーアドレス、ポート、認証情報を1つずつ確認します。TLSやトランスポートの設定がある場合は、それらも元の情報と一致しているか確認してください。デバイスの日付や時刻が正しくないと、安全な接続に影響することがあります。システム時刻も確認してください。同じサブスクリプションに手持ちの別サーバーがある場合は、同じ条件で比較できますが、内容が分からない項目を元の情報で書き換えないでください。

スイッチをオンにしてすぐオフになる場合や、許可の画面から進まない場合は、システムでVPN構成の追加が許可されているか、ほかの接続管理設定が影響していないかを確認します。システム構成が削除されている、または再作成が必要だと確認できた場合に限り、アプリの案内に従って再設定してください。システムの許可に関する失敗とリモート側の認証失敗を混同しないでください。前者は通常、接続確立前に発生します。後者では実際の接続情報とエラー記録を確認します。

第3段階：ルーティング、ルール、DNS

Proxyでは対象にアクセスできるのにConfigでは失敗する場合は、現在のConfig、ルールの一致結果、ポリシー参照を優先して確認します。Directでは正常でプロキシ経由で失敗する場合は、選択中のサーバーとリモート側との通信を確認してください。この比較で確認範囲を絞れますが、それだけで原因を特定できるわけではありません。モードを切り替えた後は毎回新しいリクエストを発生させ、既存の接続が再利用されて確認に影響しないようにします。

一部のドメインだけにアクセスできない場合は、Dataの情報も参考に、DNSと対象に関連する記録を確認します。DNSの変更、認証確認の無効化、ルールの変更、サーバーの切り替えを同時に行わないでください。一時的に復旧しても、どの変更が有効だったか分からなくなります。DNSの仕組みや詳しいエラーの見方はよくある質問をご覧ください。App Storeのアカウント、購入済みアプリの復元、購入確認についてはApp Storeからの入手ガイドをご確認ください。接続のトラブル対処中に購入手続きをやり直す必要はありません。

これで初回利用の手順は完了です。手持ちの情報を追加し、ルーティングを選択し、システムの許可を済ませ、実際のリクエストで動作を確認できました。今後も、変更前の状態を記録し、設定を1項目ずつ変更して、同じ対象で確認してください。続けて設定する場合は、該当する項目を設定ガイドで確認できます。入門手順を最初からやり直す必要はありません。