Shadowrocket 使い方完全ガイド

Homeと設定の関係を確認

初回起動後は、Homeで選択するサーバー、Configで使用するルール設定、システム接続を開始するスイッチの3つを区別してください。サーバーはリクエストの転送先を決め、ルール設定はリクエストごとの処理方法を決め、スイッチは今回のネットワーク拡張を実行するかどうかを決めます。3つは関係していますが、互いの代わりにはなりません。リストにサーバーがあっても、ルールが適切とは限りません。ルールファイルがあっても、サーバーの認証情報が正しいとは限りません。スイッチをオンにした後も、実際にアクセスして結果を確認してください。

初回起動時にすべての許可を一度に求めるのではなく、機能を初めて使うときに許可を求める場合があります。表示されたダイアログの用途を読んでから、続行するか決めてください。カメラの許可は通常、QRコードの読み取りに使います。通知の許可はアプリからの通知に関するものです。システムのVPN構成の許可は接続の確立に使います。テキスト形式のリンクを追加するだけなら、カメラの許可を先に有効にする必要はありません。使わない機能の許可は、必要になった時点でシステムの手順に従って設定できます。

システムのVPN構成の許可について

初めて接続をオンにすると、システムからVPN構成の追加を許可するよう求められ、デバイスの認証が必要になる場合があります。これはネットワーク拡張の構成をシステムに登録する手順です。操作中のアプリがShadowrocketであることを確認し、システムの案内に従ってください。許可が完了したことが示すのは、システムがその構成の実行を認めたことだけです。すべてのリクエストが転送されることや、接続先のサーバーからあらゆる宛先へアクセスできることを保証するものではありません。実際の処理はGlobal Routing、ルール、リモートサービスによって異なります。

システムの案内を以前キャンセルした場合は、サーバー情報を確認してから接続を再度オンにし、表示される許可手順に従ってください。構成を作成できない状態が続く場合は、デバイスが組織によって管理されているか、関連機能を制限するポリシーがあるか、ほかのネットワーク構成が有効になっているかを確認します。組織管理のデバイスでは管理上のルールに従い、管理制限を一般的な接続障害として扱わないでください。原因を探るためにシステム構成を次々に削除するのは避けましょう。既存の業務用ネットワークに影響しないよう、まず各構成のアプリと用途を記録してください。

システムの状態とアプリの状態を分けて判断

システムにVPNの状態が表示されていれば、該当するネットワーク拡張が接続中であることを示しますが、目的のWebページが正常に読み込まれたことまでは確認できません。反対に、デバイスによってはステータスバーの表示領域が限られているため、特定のアイコンが常に見えないことだけで接続が切れたとは判断できません。アプリ内のスイッチ、選択中のサーバー、実際のアクセス結果を併せて確認してください。システム設定から切断しても再接続される場合は、On Demandなどのトリガー条件を確認します。スイッチが戻ったことだけで、システムが操作を受け付けなかったと判断しないでください。

サーバー、ルーティングのモード、ルール設定を変更しても、既存の接続が以前の経路を保つ場合があります。初回の確認では、いったん現在のアクセスを停止し、必要に応じて接続を確立し直してから、目的のページを開いてください。古いセッションを維持したまま複数の設定を変更し、ページが再生中かどうかだけで新しい設定の結果を判断しないでください。ログインが必要なアプリでは、アプリ内のキャッシュやセッション復元も影響するため、必要に応じて対象アプリを終了してから再度アクセスします。

権限の確認でわかるのは「システムがその機能の実行を許可しているか」です。接続性の確認では「現在のサーバー、認証情報、ルール、接続先サービスが正常か」も調べます。この2つは分けて記録してください。

初回操作で元に戻せる状態を用意

情報を追加する前に、Wi-Fiとモバイル通信のどちらを使っているか記録し、通常のネットワークが正常に使えることを確認します。Web認証が必要なWi-Fiでは、接続テストの前に認証を完了してください。初回設定中は自動トリガーのルールを有効にせず、接続のたびにどの手動操作がきっかけになったか分かるようにしておきます。ネットワーク経路を変更するほかの機能がデバイスで有効になっている場合も、その状態を記録してください。複数の仕組みが同時に動いた結果を、1つの設定だけが原因だと誤認しないためです。

自分だけが保管する操作記録を用意し、現在のサーバー名、設定名、Global Routingのモード、今回変更した内容を記録しておくことをおすすめします。パスワードやサブスクリプションの認証情報は記録しないでください。初回接続に成功したら、この記録を復旧時の基準として使えます。サービス情報をまだ追加していない場合、この段階で止まっていても問題ありません。次の章に進み、ご自身がすでにお持ちの情報を追加してください。手順を短く確認したい場合は入門ガイドに戻り、権限設定を終えてから本ページの各項目を参照できます。

ルーティングのモードとルールの処理を区別

Global Routingはリクエストの処理方法を決めます。Configでは現在の設定に含まれるルールに照合します。Proxyではクライアントの処理対象となるリクエストをプロキシ経由にします。Directでは直接接続します。これらは動作モードであり、異なるサーバーを指すものではありません。モードを切り替えても、誤ったパスワードは直らず、利用中のサービスの有効期限も延長されません。特にProxyを、デバイスのすべての通信が必ずリモート経由になると単純に捉えないでください。システムのネットワーク動作、処理対象の範囲、プロトコルの機能にはそれぞれ制約があります。

ルール内の PROXY、DIRECT、REJECTは処理方法を示すキーワードであり、Global Routingの画面表示と混同しないでください。ルールのPROXYは、現在の選択や設定内のポリシー定義と併せて解釈する必要があります。カスタムのポリシーグループを使う設定では、ルールの末尾に固定のPROXYではなくグループ名を指定することがあります。初めて確認する場合は、既存設定の参照関係を把握してください。ルール末尾の文字だけを変更しても、ポリシーの調整が完了したとは限りません。

上から順に照合し、FINALは末尾に置く

Configでは、ルールを上から順に確認し、一致した時点で対応するポリシーを適用します。具体的な例外ルールは、関連する広範なルールより前に置く必要があります。先に別のルールに一致すると、後ろの例外は適用されません。前のルールに一致しなかったリクエストを処理するFINALは末尾に配置してください。順序を調べるときは、追加した行だけでなくルールの先頭から確認します。実際に適用されているのは、より前にある別のルールかもしれません。

以下は .conf 内のルール断片の例です。構造と照合順序を示すもので、完全な設定ではなく、すべてのネットワークに適用できるものでもありません。example.comは説明用のドメインです。使用前に、ご自身の宛先と既存のポリシー定義に合わせて調整してください。編集前に元の設定をバックアップし、変更した設定ファイルが選択されていることを確認してください。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAINは完全一致するドメイン名、DOMAIN-SUFFIXは指定したドメインとそのサブドメイン、DOMAIN-KEYWORDはドメイン名に含まれるキーワードで照合します。想定以上に広い範囲に一致する場合があります。IP-CIDRとIP-CIDR6はIPアドレスの範囲に使い、GEOIPはIPアドレスの地域データベースに基づいて判定します。ドメインのリクエストから実際の接続先アドレスに至るまでには名前解決があるため、ドメインルールとアドレスルールでは参照する情報が異なります。最終的に表示されたアドレスだけから、照合全体の過程を推測することはできません。

1つの宛先で変更を確認し、設定全体を一度に変更しない

ルールを変更する前に、どの宛先にどのポリシーを適用したいのか、現在の動作がなぜ要件に合わないのかを明確にします。対象に一致するルールを1つ追加したら、リクエストを再実行し、利用可能な記録に表示されるポリシーを確認してください。動作が変わらない場合は、設定が保存されているか、選択中の設定か、より前のルールが一致していないか、古いセッションが継続していないかを確認します。DNS、サーバー、大量のルールを一度に変更すると、正常に戻っても何が効いたのか分からなくなります。

宛先をDIRECTにしても、その宛先に必ずアクセスできるとは限りません。ローカルネットワークの名前解決と接続性に依存します。PROXYにしても、リモート側からその宛先へ必ずアクセスできるとは限りません。REJECTはリクエストを明示的に拒否し、ページのリソース、ログイン手順、アプリの通知に影響する場合があります。使う前に対象の用途を確認してください。ルールは明確な要件に沿って作成し、項目数の多さで品質を判断しないようにしましょう。順序の詳しい例はカスタムルールの優先順位とFINALの解説をご覧ください。

おすすめの手順は、検証済みのサーバーを維持し、Proxyでプロキシ経路を確認した後、Configに戻ってルール振り分けを検証することです。一時的なモードでの比較が終わったら、普段使う設定に戻してください。

ProxyではアクセスできるのにConfigで失敗する場合は、ルール、ポリシーの参照関係、設定に関連するDNSの動作を優先して確認します。どちらでも失敗する場合は、サーバーの認証、通信方式、ネットワークからの到達性を確認してください。むやみにモードを切り替えるより、このように問題を分類する方が有効です。次章の接続確認を再現できるよう、最終的に使用する設定名とGlobal Routingのモードを記録してください。

デバイス上の統計はサービス側の残量とは異なる

Dataでは、クライアントから確認できる通信量や関連記録を確認できます。表示項目は現在のアプリ表示に従ってください。まず統計が現在の接続、一定期間、累計のどれを示すのかを確認してから数値の変化を判断します。クライアント側の通信量を、サービス側で差し引かれた通信量と同じものとして扱わないでください。両者で集計期間、単位、プロトコルのオーバーヘッド、料金計算方法が異なる場合があります。利用中のサービスの残量を確認するには、ご自身のサービスアカウント情報を参照し、クライアントの累計値から推測しないでください。

アップロードとダウンロードの方向は、デバイスから見たものです。Webページへのリクエスト、ファイルの送信、クラウド同期はアップロードを発生させることがあります。ページのコンテンツ、動画、ファイルの受信はダウンロードにあたります。Webページを開いていなくても、バックグラウンド同期やアプリ通知で通信が発生する場合があります。そのため、通信量が少しずつ変化しているだけでは異常とは判断できません。前面での操作、バックグラウンドの動作、記録対象の範囲を併せて確認してください。単位を調べずに通信速度と累計量を混同しないようにしましょう。

速度、累計量、集計期間を区別

速度は単位時間あたりのデータ変化量、累計量は特定の集計期間における総量を表します。短時間のピークから長時間の転送能力は判断できません。また、累計量が増えても、現在も転送が続いているとは限りません。比較する前に単位を確認し、バイトとビットの違いにも注意してください。画面によって単位の表示方法が異なる場合があるため、問題を記録するときは、文脈のない数字だけでなく画面に表示された単位全体を書き留めます。

再接続、記録の消去、統計のリセットによって、表示対象が変わる場合があります。操作前に現在の項目が何をするか確認してください。数値をゼロにするためにサーバーやサブスクリプションを削除しないでください。管理対象が異なります。2回のアクセスで通信量を比較する場合は、同じ宛先に近い操作を行い、開始時と終了時の数値の差を記録します。ブラウザーのキャッシュが使われたかも考慮してください。2回目のページ表示で通信量が減っても、キャッシュが原因であって、ネットワーク経路が変わったとは限りません。

リクエスト記録でルールの適用状況を確認

アプリに接続記録が表示される場合は、宛先のドメインまたはアドレス、適用されたルール、ポリシー、結果を照らし合わせてリクエストの経路を判断できます。まず直前に自分がどのリクエストを実行したか確認してから、該当する記録を探してください。リストにはバックグラウンド処理や他のアプリの通信が含まれる場合もあります。ドメインとアドレスは必ずしも一対一で対応しません。アドレスを直接使う接続もあれば、以前の名前解決結果を使うリクエストもあります。目的のドメインが見つからないだけで、対象がネットワークリクエストを一切送信していないと判断しないでください。

記録にあるポリシーは、特にConfigの動作確認に役立ちます。まず一致したのが具体的なドメインルール、アドレスルール、FINALのどれかを確認し、参照先のポリシーが想定どおりか調べてください。DIRECTと表示されても、リクエストがサーバーを使用していない可能性があるため、サーバーだけを変更しないでください。REJECTと表示された場合は、明示的に拒否されていないか確認します。記録が想定と異なるときは、第4章に戻ってルールを上から順に確認し、現在選択中の設定と編集中のファイルが一致することも確かめてください。

通信量の数値は「どれだけ観測されたか」を示し、リクエスト記録は「そのリクエストがどう処理されたか」を調べるのに役立ちます。併用できますが、どちらも接続先サービスから応答が得られたことの実地確認には代わりません。

通信量に異常がある場合は、差分を確認

通信量が大きく増えた場合は、動画の再生、システムアップデート、クラウド同期など、大きな通信を伴う作業をいったん停止し、増加が緩やかになるか確認してください。その後、作業を1つずつ再開し、増加と関係する活動を特定します。サーバー名だけを根拠に通信元を判断したり、統計の増加をそのまま認証情報の漏えいと解釈したりしないでください。前面の作業を止めても増加が続く場合は、バックグラウンドアプリの動作と利用可能な記録を確認し、原因の範囲を絞ります。統計期間に停止前の履歴が含まれているかも確認してください。

サービス側の残量が減っているのにデバイス上のDataがあまり変わらない場合は、同じサービスを使っている別のご自身のデバイスがないか、双方の集計期間が一致しているか、サービス側で異なる計算方法が使われていないか確認してください。事実を確認してから、利用中サービスのサポート窓口に計測方法を問い合わせます。通常、クライアントからサービス側のすべての差し引きの詳細を確認することはできません。アカウントの残量の問題を解決するためにローカル統計を何度もリセットしないでください。リセットで変わるのはデバイス上の表示だけで、サービス側の記録ではありません。

診断情報を共有する前に必要最小限にする

リクエスト記録には、アクセスしたドメインやパス、デバイスのネットワーク情報、個人識別情報が含まれる場合があります。問題を外部に伝える前に、関連する内容だけを選び、サブスクリプションURL全体、パスワード、個人を特定できるパラメーターを伏せてください。スクリーンショットの背景に機密情報が表示されていないかも確認します。不要になった記録は、アプリで利用できる機能に従って管理してください。記録を保存する期間は、ご自身のトラブル対処に必要な範囲で十分です。履歴をすべて長期間ためる必要はありません。日常のメンテナンスでは、再現条件、重要なエラー、有効だった対処を残してください。

この段階の目的は、数値を常に監視することではなく、判断の手掛かりを把握することです。統計がどの範囲を対象とするか、失敗したリクエストをどう見つけるか、デバイス上の記録とサービス側のアカウント情報をどう区別するかを理解してください。これらを把握してからSettingsの関連項目を調整すれば、根拠のない操作を減らせます。

アプリのアップデートとサブスクリプションの更新を分ける

アプリのアップデートはApp Storeから行い、主にクライアント自体を更新します。サブスクリプションの更新は、ご自身がすでに利用しているサービスからサーバーリストを再取得する操作です。両者は別のものです。サブスクリプションの更新に成功してもアプリがアップデートされたことにはならず、アプリを更新してもサービス情報の有効性が保証されるわけではありません。日常的にはApp Storeのアプリの状態と、ご自身のサブスクリプションの状態を別々に確認してください。確認できていないバージョン情報を追いかける必要はありません。問題の対処中に更新する場合は、更新前に再現条件を記録し、比較材料を失わないようにしましょう。

サブスクリプションの更新頻度は、利用中サービスの案内と実際の必要に合わせてください。1回のリクエストが遅かっただけで、何度も続けて更新する必要はありません。更新後は、選択中の項目が残っているか、名称が変わったか、ルールから参照されるポリシーに影響がないかを確認します。リストの更新に失敗しても既存の項目が使える場合は、取得処理の問題を調べる前に、まず現在の動作状態を維持してください。通常の利用とメンテナンス作業を分けることで、接続が必要なときに一度の整理で利用可能な情報をすべて失うのを防げます。

アプリだけでなく必要な情報もバックアップ

アプリの購入履歴、サーバー情報、サブスクリプションURL、ルール設定は、それぞれ別のものとして扱います。App Storeからアプリを再入手できても、ローカルの内容がすべて自動で復元されるとは限りません。デバイスのバックアップでどこまで復元できるかも、実際の復元結果を確認してください。機種変更前に、アプリのエクスポートまたはバックアップ機能を確認し、必要な設定が含まれるか確かめます。手動で追加した項目は、表示名だけでは接続を再設定できないため、元の情報を保管しておくことが特に重要です。

バックアップにはパスワード、サブスクリプションの認証情報、その他の接続パラメーターが含まれる場合があるため、ご自身で管理できる保護された場所に保管してください。設定全体を公開メモ、共有フォルダー、トラブル相談に掲載しないでください。バックアップには用途と設定名を付け、利用できることを確認済みの版を少なくとも1つ残しておきましょう。ルールを大幅に変更する前に、元の内容をエクスポートしてください。バックアップの有効性はファイルが存在するかではなく、必要な情報を読み出して復元できるかで決まります。適切なタイミングで、保存範囲を確認してください。

機種変更後は依存関係に沿って復元

新しいデバイスでApp Storeを開き、以前の購入履歴と商品情報を確認してから、ストアの条件に従ってアプリを入手します。システム要件、ユニバーサル購入、ファミリー共有の適用条件は、すべてApp Storeの商品ページの記載を基準にしてください。次に、ご自身のサーバーまたはサブスクリプション情報を復元し、ルール設定を戻してから、システムのVPN構成の許可を再確認します。新しいデバイスでは個別に権限の案内が表示される場合があります。以前のデバイスで許可済みでも、この手順を省略しないでください。購入済み項目の復元手順は購入済みアプリの復元方法をご覧ください。

復元後すぐにすべての自動トリガーや高度な設定を有効にしないでください。まず既知の項目を1つ手動で選択し、接続と普段使う宛先へのアクセスを確認します。Configで正常に振り分けられることを確認してから、On Demandを再設定してください。デバイス名、Wi-Fi環境、システム設定、アプリの権限は以前のデバイスと異なる場合があるため、まったく同じ設定でもトリガー条件の動作が変わることがあります。移行中に問題が起きたら、すべてを最初からやり直すのではなく、直近で検証済みの段階に戻ってください。

決まった手順で問題から復旧

日常の不具合は、次の4段階で対処できます。基本ネットワークの確認、現在の選択内容の確認、直近の変更の確認、動作確認済みの状態への復帰です。まずWi-Fiの認証とネットワーク自体の利用可否を確認します。次にサーバー、設定、Global Routingを確認します。その後、サブスクリプションの更新、ルールの変更、自動トリガーの有効化などを最近行っていないか調べます。最後に、関連する変更だけを元に戻してください。証拠を残しながら、関係のない操作を減らせます。対象が破損したことが明らかで、復元情報もある場合に限り、削除して作り直すことを検討してください。

問題が特定のネットワークでのみ起きる場合は、設定を変えずに、利用可能な別のご自身のネットワークで比較します。1台のサーバーだけ異常な場合は、他の項目を残したまま該当サーバーの情報を確認します。特定の宛先だけ失敗する場合は、リクエスト記録と関連ルールを確認してください。サービスの利用資格や通信量の問題は、利用中のサービスのサポート窓口に問い合わせます。購入履歴の問題はApp Storeのアカウント記録から確認してください。問題に応じた窓口で対応し、アカウント側の問題をアプリの設定で解決しようとしないでください。

復旧時の基準記録には、利用可能なサーバーの出所、設定名、Global Routingのモード、必要な設定、最後に正常動作を確認した操作を残します。認証情報は別に保護し、公開のトラブル記録には書かないでください。

試行錯誤を繰り返さず、簡潔に記録

メンテナンスのたびに、変更内容、変更理由、比較に使った操作、結果、復旧方法を記録してください。未確認の推測を確定したルールのように残したり、一時的に成功しただけで既存のバックアップを削除したりしないでください。重複項目や不要な記録を定期的に整理するときは、現在の依存関係を確認します。特に、サブスクリプションから作成された項目と手動で追加した項目を区別してください。整理の目的は混乱を減らすことであり、リストを短く見せることではありません。

これで一連の使い方を確認できました。App Storeで商品と購入を確認し、システムの許可で接続を認め、ご自身の情報からサーバーを追加し、Global Routingで処理方法を選び、実際のアクセスで結果を確かめます。Dataと記録で状況を確認し、Settingsで具体的な問題に対処し、メンテナンス手順で復元できる状態を保ちます。短い手順を最初から確認したい場合は入門ガイドを、設定の仕組みを確認したい場合は本ページの目次から該当する章を参照してください。正常に動作している箇所を一から作り直す必要はありません。