Shadowrocket使い方完全ガイド

02 / FIRST LAUNCH

初回起動とVPN構成の権限

Homeを確認してから接続を開始

Shadowrocketを初めて開いたら、接続スイッチを入れる前にHomeを確認してください。Homeには接続状態、Global Routing、Connectivity Test、SERVERなどの項目があります。SERVERに使用可能な情報があり、Global Routingでルーティング方法を選び、接続スイッチでシステムのネットワークトンネルを開始します。それぞれ役割が異なります。サーバーが一覧にあっても選択されているとは限らず、選択されていてもトンネルが確立しているとは限りません。

HomeにNot Connectedと表示されている場合、アプリが未接続と報告していることだけが分かり、サブスクリプションが有効かどうかまでは判断できません。まず一覧の内容を確認し、使用するサーバーを選び、最後にルーティング方法を確認してください。この順序なら、一覧が空のまま、または誤ったモードのまま接続を許可し、その後の問題をすべてシステム権限のせいにする事態を避けられます。画面の概要は初回起動とHome画面の説明もご覧ください。

初回は、問題の切り分けをしやすくするため、通常はデフォルト設定のまま進めるのがおすすめです。補助機能を一度にすべて有効にする必要はありません。まずは「手持ちの情報で手動接続を一度完了する」ことを目標にします。成功してからOn Demand、DNS、ルールを一つずつ調整してください。権限、接続情報、高度な設定を分けて扱うと、どの変更が動作に影響したか把握でき、検証済みの状態にも戻しやすくなります。

システムの許可ダイアログについて

接続を開始すると、VPN構成の追加を許可するようシステムから求められることがあります。これはAppleのシステムがネットワーク拡張を管理するために必要な手続きです。許可すると、Shadowrocketが使用するVPN構成を端末で作成できるようになります。端末のパスコードなどによる認証を求められた場合は、画面の案内に従ってください。この許可は購入手続きではなく、サーバーアドレスを自動入力するものでもありません。クライアントが該当するネットワーク接続を開始するために必要なシステム上の条件です。

VPN構成とプロキシサーバーの登録情報は別のものです。前者はシステムが管理し、トンネルの起動や権限に関係します。後者はアプリに保存され、サーバー、ポート、認証方式を示します。そのため、システムにVPN構成があってもSERVERの一覧が正しいとは限らず、情報の追加が完了してもシステムの許可が済んでいるとは限りません。すべての情報を削除してやり直すのではなく、それぞれを個別に確認してください。

誤って拒否した場合は、まずHomeに戻り、接続を開始して許可の案内が再び表示されるか確認します。表示されない場合は、システム設定でVPNまたはVPNとデバイス管理に関する項目を探し、既存の構成と状態を確認してください。設定項目の名称や場所は、システムやデバイスによって異なります。組織の管理下にある端末では、一部の設定を変更できないことがあります。その場合は管理上の制限を確認し、システムのポリシーを繰り返し変更しようとしないでください。

接続できないときは権限の競合を確認

端末に別のVPN構成やネットワーク拡張がある場合は、現在どれが有効になっているか確認してください。テスト中はネットワークを同時に制御する可能性のある構成を一時停止し、Shadowrocketだけで検証すると、自動接続の条件が競合するのを避けられます。他の構成の元の内容は保持し、一度の確認のためにすべて削除する必要はありません。仕事用または学校用の端末では、構成の用途と管理上の要件を先に確認してください。

システム構成の破損が明らかに疑われ、再認証でも復旧しない場合に限り、該当するVPN構成の再作成を検討してください。操作前にアプリ内のサーバー情報と設定を保存し、接続を停止して、対象の構成名を確認してから、システムで許可される削除と再認証を行います。システムのVPN構成を削除してもサブスクリプションは復元されません。また、あらゆる問題に対する最初の手段にすべきではありません。詳しくはVPN構成の許可に関する説明をご覧ください。

許可後も接続できない場合は、どの段階で失敗するかを確認してください。スイッチがすぐに元に戻る場合は、権限や拡張機能の起動が関係している可能性があります。接続状態が続くのに宛先へのリクエストが失敗する場合は、サーバーとルーティングを確認します。現象によって確認方法は異なり、「許可済み」だけで正常と判断することはできません。画面に表示されたシステムの文言、使用中のネットワーク、失敗した操作を記録すると、スイッチを何度も切り替えるより原因を特定しやすくなります。

04 / GLOBAL ROUTING

Global Routingの3つのモードとルールの順序

Config、Proxy、Directの役割

Global Routingでは、現在の接続に使うルーティング方法を選択します。Configは現在のConfigファイルのルールに従ってリクエストの経路を決めます。Proxyは選択したプロキシ経路を全体的に使用します。Directは直接接続します。3つのモードは動作の選択肢であり、速度の段階でもサーバーの種類でもありません。モードを切り替えても認証情報は変わらないため、サーバーと設定が有効かどうかも確認してください。

トラブルの切り分けでは、一時的にProxyを使ってConfigと比較できます。同じ宛先にProxyで接続でき、Configで失敗する場合は、まずルールの判定とポリシーの振り分けを確認してください。両方で失敗する場合は、サーバーと基本ネットワークを確認します。Directは直接アクセスの状況を把握するのに役立ちますが、比較結果が有効なのは、その時点のネットワークと宛先に限られます。一度に変更する条件は1つにし、テスト後は元のモードに戻して、一時設定をそのままにしないようにしましょう。

Global Routingは、アプリごとの通信を自由に回避させる独立したスイッチではありません。実際のリクエストは、システムのネットワーク、DNS、アプリのキャッシュ、Configの例外設定などの影響も受けます。通信経路を判断するときは、現在のモード名だけでなくリクエストの記録も確認してください。ブラウザが既存の接続を再利用したり、アプリが長時間接続を維持したりする場合は、モードを切り替えた後にリクエストを再実行します。必要に応じて既存のセッションを終了し、新しい接続先を確認してください。

ルールは上から順に評価され、最初に一致したルールが適用

Configモードでは、Rule内の順序が結果に直接影響します。一般に、対象範囲が狭く条件が明確なルールを先に置き、最後にフォールバックを配置します。DOMAINはドメイン全体との完全一致、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはドメインに含まれるキーワードで照合します。キーワードルールは広い範囲に適用されることがあるため、書きやすいからといって、すべての完全一致ルールより前に置かないでください。

IP-CIDRとIP-CIDR6はアドレス範囲を対象とし、GEOIPは対応するアドレスデータに基づいて判定します。これらはドメイン分類と同じ意味のルールではありません。DNSの結果、アドレスデータ、実際のリクエスト形式によって照合結果は変わります。「ドメインルールが一致しない」場合は、リクエスト記録に表示されているのがドメイン名かアドレスか、前に別のルールがあるかを確認してください。Webページのタイトルだけを見て判断しないようにしましょう。

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

このルールは説明用の例であり、完全な接続設定ではありません。1行目は該当するドメインサフィックスへのリクエストをPROXYに送ります。2行目はGEOIPの条件に応じてDIRECTを選択します。FINALは、それ以前のルールに一致しないリクエストに対する末尾のポリシーを指定します。自分のConfigに追加する前にバックアップを取り、参照しているポリシーが現在のConfigで使えることを確認してください。例のドメインは構文の説明用であり、特定の種類のサイトに同じポリシーを適用すべきという意味ではありません。

ポリシー名、フォールバック、Configの反映

ルールのキーワードは「どう照合するか」を、末尾のポリシーは「一致後にどう処理するか」を示します。DIRECT、PROXY、REJECTはそれぞれ役割が異なるため、トラブルの切り分けのためにすべてのルールを同じキーワードに変更しないでください。独自のグループを使うConfigでは、ルールが参照する名前と実際の定義を一致させる必要があります。名前の誤記、グループの未定義、グループ内に利用可能な項目がないことなどが、ルールの見た目が正しくても期待どおりに動かない原因になります。

FINALはフォールバックとして使い、後続で確認が必要なルールより後ろに置きます。前の方に置くと、それ以降のルールが本来一致するはずのリクエストを処理できません。ルールを追加したら、新しい行の構文だけでなく、前後の対象範囲も確認してください。より広いサフィックスルールやキーワードルールが、すでに対象をカバーしている場合があります。末尾に同じようなルールを追加し続けるのではなく、実際に適用されたルールから順に原因をたどりましょう。

編集後は保存し、現在実際に有効になっているConfigファイルを確認してください。ファイルを開いて表示しただけでは、そのファイルが接続に使われているとは限りません。ルールの詳しい説明は.confの各セクションの構造をご覧ください。設定同士の影響を確認する場合は設定ガイドも参照してください。元に戻せるConfigを保存し、範囲を限定して変更すると、ファイル全体の置き換えより検証しやすくなります。

06 / DATA & OBSERVATION

Dataの通信量とリクエスト記録の見方

まず集計の範囲を確認し、数字を請求額と混同しない

Dataでは、アプリに表示される通信量や接続情報を確認できます。具体的な集計項目は現在の画面で確認してください。数値を見る前に、対象期間、再接続後に値が変化するか、アップロードとダウンロードが区別されているかを確認します。画面によって集計対象が異なるため、2つの数値が異なるからといって異常とは限りません。1回のセッションの通信量、累計通信量、システムがアプリごとに集計する通信量は、それぞれ異なる基準です。

通信がトンネルを通る際には、プロトコルのカプセル化、ハンドシェイク、再送、バックグラウンドリクエストも関係するため、転送したファイルの容量と統計値が完全に一致するとは限りません。画像のキャッシュ、動画の先読み、システムのバックグラウンド動作も観測結果に影響します。特定の操作による変化を確認する場合は、まず開始時の値を記録し、明確な操作を1つ実行してから終了時の値を確認してください。1日の累計値を、直前に開いたページだけの影響とみなさないようにしましょう。

クライアントに表示される通信量は、サービス提供元の使用量記録や課金基準の代わりにはなりません。集計期間、通信方向、計算方法が異なる場合があります。サブスクリプションの画面に残量が表示される場合も、情報の提供元と更新時刻を確認してください。数値に差がある場合は、対象期間と操作を整理してから、ご自身のサービス提供元に集計方法を確認しましょう。クライアント側のカウンターをリセットしても、サービス提供元の記録は変わりません。

リクエスト記録で実際に適用されたルールを確認

アクセス結果が想定と異なる場合、記録で役立つのは合計通信量だけでなく、宛先、時刻、使用されたポリシー、エラーが起きた段階です。対象へのリクエストをもう一度実行してから、時刻が近い項目を探してください。キャッシュからのアクセスや古い接続を、現在の結果と取り違えずに済みます。同じページから複数のリクエストが発生する場合は、失敗した項目を個別に確認してください。メインのドメインに接続できても、すべてのリソースが同じ経路を使うとは限りません。

DIRECTやPROXYなどのポリシーが表示されたら、Configに戻り、どのルールがそのポリシーを適用したかを確認してください。対象が先にある範囲の広いルールに一致している場合、ファイルの後ろに完全一致ルールを追加しても、通常は結果が変わりません。ルールの順序を調整して保存し、新しいリクエストを開始してから、変更が反映されたか確認してください。長時間接続では既存のセッションが元の経路を維持する場合があるため、新しい接続と分けて判断しましょう。

DNS関連のエラーでは、「名前解決の失敗」と「解決後の接続失敗」を区別してください。前者は名前解決の設定、現在のネットワーク、リクエストのドメインを確認します。後者は宛先アドレス、ポート、経路も確認する必要があります。エラーメッセージ1つだけから原因全体を決めつけないでください。リクエストの種類によって記録に表示される詳細は異なります。項目が表示されないからといって、その処理が行われていないとは限らないため、他の情報も合わせて判断しましょう。

通信量、バッテリー、バックグラウンド動作を分けて確認

通信量が少なくバッテリー消費が多いことは、矛盾ではありません。頻繁な再接続、継続的な端末の起動、不安定なネットワークは、有効な通信量が少なくても電力を消費する場合があります。逆に、短時間で大きなファイルをダウンロードすれば、通信量が大きく増えることがあります。利用時間、ネットワークの種類、操作内容を合わせて記録してください。バッテリー残量の変化と通信量を単純に換算したり、スクリーンショット1枚だけでクライアントの異常を判断したりしないようにしましょう。

バックグラウンド動作が続いていると思われる場合は、On Demandが有効か、アプリの自動更新があるか、端末が異なるネットワーク間を頻繁に切り替えていないかを確認します。ネットワークや使い方をそろえ、On Demandの設定だけを変えるなど、条件を近づけて比較してください。短時間のテストはシステムのタスクに影響されやすいため、数分間の変化だけで結論を出さず、再現性のある傾向を確認しましょう。

システムのバッテリー画面とData画面では集計期間が異なる場合があります。まず確認する時間帯をそろえてください。バックグラウンド動作についてはOn Demandとバッテリーの確認方法をご覧ください。データを確認する目的は、不要な動作や接続の再試行を見つけることです。特定の数値を目指すことではありません。端末のモデル、ネットワーク環境、利用内容によって異なるため、全員に当てはまる基準値はありません。

自分用の確認表には、日付、ネットワーク、モード、Config名、再現操作、結果を残せば十分です。すべてのリクエストを長期保存する必要はありません。短い記録なら比較しやすく、機密情報の蓄積も抑えられます。さらに詳しいログが必要な場合だけ追加し、問題の対応が終わったら保存範囲を見直してください。診断用の記録と日常利用の記録を分けて管理しましょう。

08 / MAINTENANCE

サブスクリプションの更新、バックアップ、日常管理

更新の前後で実際の変更を確認

日常管理では、設定全体を何度も作り直すのではなく、情報を有効な状態に保つことを優先します。サブスクリプションの更新前に、どの一覧を更新するのか確認し、更新後は記録数、名前、現在選択中の項目に変化がないか確認してください。選択中の記録が置き換わったり削除されたりした場合は、もう一度選択して接続を確認します。更新が完了しても、一覧を取得できただけであり、サーバーの接続テストにはなりません。サーバー一覧を更新しても、ルール設定が自動的に最新になるわけではありません。

サービス提供元がアドレスや認証方式を変更した場合は、新しい情報に基づいて確認してください。記録のメモだけを変えても対応できません。古いアドレスに一時的に接続できても、今後も使い続けられるとは限りません。新しい情報を追加した後は、現在のネットワークで接続を確認します。手動で追加した記録は、サブスクリプションの更新で変更されるとは限りません。近い名前でも出所が異なる項目を複数残して、トラブル時に誤選択しないよう、それぞれ別に管理してください。

アプリはApp Storeからアップデートしてください。アップデート情報と互換性はストアの製品ページで確認します。更新前に使用中のConfigをバックアップし、更新後に権限、現在のサーバー、重要なルールを確認すると安心です。動作が変わった場合は、記憶に頼って「この項目は変わっていないはず」と考えず、実際の設定とアプリの表示を確認してください。アプリ、サブスクリプション、Configの各更新を分けて記録すると、変化の原因を特定しやすくなります。

バックアップは復元可能性と機密性の両方を考慮

バックアップの前に、何を復元するのかを明確にしてください。ルールファイルだけではサーバー認証情報が含まれない場合があり、サーバー一覧だけではカスタムグループやアプリ設定が含まれない場合があります。アプリのエクスポートやバックアップ機能を使うときは、実際の選択肢を読み、何が保存されるか確認してください。用途が分かる名前を付け、対応するConfigと保存日時を記録します。ただしファイル名にパスワードやサブスクリプションURL全体を含めないでください。

バックアップファイルには接続情報が含まれることがあるため、自分で管理できる保護された場所に保存してください。システムのファイル機能や個人用ストレージで転送する場合は、送信先のデバイスとアカウントが正しいことを確認し、公開共有の場所を誤って選ばないようにしましょう。ルールの例を他の人に渡す場合は、完全なバックアップを送るのではなく、機密情報を除いた別ファイルを作成してください。ルールだけに見えるファイルでも、他のセクションに認証情報やサブスクリプション情報が残っている可能性があります。

「エクスポート成功」と表示されただけで、復元できると判断しないでください。少なくとも、ファイルの保存場所と内容が正しいこと、アプリに再度読み込む方法を確認します。実際に移行する際は、旧デバイスの情報を残したまま、新しいデバイスに読み込んでサーバー、Config、Global Routingを確認し、実際のリクエストで接続を検証してください。新しいデバイスで動作確認が終わる前に、唯一の使用可能なConfigを旧デバイスから削除しないでください。

機種変更、再インストール、長期間使わなかった後の確認

機種変更や再インストール後は、購入アカウントのApp Storeにある購入済み項目からShadowrocketを入手してください。購入対象となる条件はストアの表示で確認します。アプリの再ダウンロードと接続情報の復元は別の作業です。App Storeの購入履歴があっても、Configが復元済みとは限りません。バックアップを読み込んだ後、システムのVPN許可を再設定する必要がある場合があります。その後、現在のConfigとOn Demandの条件を確認し、新しいデバイスに合わない設定をそのまま引き継がないようにしましょう。

長期間使用していなかったアプリを再び使う場合は、まず基本ネットワークを確認し、サブスクリプションとサーバー情報が有効かを確かめてください。端末の時刻のずれ、サービス情報の変更、古いConfigの残存などが接続に影響することがあります。最初からすべてのルールを変更する必要はありません。手持ちの有効な記録で手動接続を一度確認し、成功してからOn Demandなどの補助設定を戻しましょう。このように段階的に復元すれば、情報の期限切れと端末設定の問題を区別できます。

古い記録を削除する前に、グループやルールから参照されていないか確認し、使用可能な代替項目があることを確かめてください。重複した記録は整理できますが、名前が似ているという理由だけで削除しないでください。プロトコルやパラメータが異なる場合があります。削除後は普段使うアクセス先を再確認し、存在しない項目を参照するConfigが残っていないか確認します。整理の目的は、一覧をできるだけ短くすることではなく、あいまいな項目や古い情報を減らすことです。

問題が続く場合は、アプリが起動するか、VPNを確立できるか、サブスクリプションを更新できるか、どのモードで失敗するか、影響を受ける宛先はどれかを短く記録してください。記録した結果を接続と確認の章と照らし合わせると、何度も再インストールするより原因を絞りやすくなります。最初から手順をやり直す場合はクイックスタートガイドをご覧ください。購入や再ダウンロードだけの問題は購入済みアプリの復元方法を確認してください。

ガイドの目次に戻る ↑