Shadowrocketの使い方完全ガイド

02 / FIRST LAUNCH

初回起動：VPN構成と接続権限について

まず画面を確認し、システムの許可を行う

有効なサーバー情報を用意してから、接続開始時にシステムの許可を行います。Homeではサーバーと接続操作を確認し、Configではルールを管理し、Dataでは通信量に関する情報を確認できます。Settingsには主な設定項目がまとまっています。デバイスによって画面の配置は異なる場合があります。固定のボタン位置ではなく、項目名を目印にしてください。初回起動時に一覧が空でも、利用可能な接続情報がまだ追加されていないことを示すだけです。

初めて接続を有効にするとき、VPN構成の追加を許可するようシステムから求められ、端末のパスコードなどで認証する場合があります。これはアプリがネットワーク拡張機能を利用するためのシステム上の許可であり、サブスクリプションへのログイン画面やサービスのパスワード入力欄ではありません。現在の操作に伴って表示された画面であることと、アプリ名が正しいことを確認してから許可してください。キャンセルした場合は、アプリに戻ってサーバー情報を確認できます。

VPN構成の追加を許可しても、端末側の接続権限が設定されるだけで、接続先サーバーの利用可否は確認されません。許可後も、アドレス、ポート、認証情報、ネットワーク条件が合わないと接続できない場合があります。システムの許可が完了しただけで接続できたと判断しないでください。続けてサーバー接続、ドメイン名の名前解決、接続先へのアクセスをそれぞれ確認します。3つの結果は互いに代用できません。

権限不足の原因を確認する

以前に許可を拒否した場合は、次回の接続時にシステムの確認画面が再び表示されるかを見てください。画面が表示されず接続がすぐに失敗する場合は、システム設定でVPN構成を開き、Shadowrocketの項目があるか、端末に組織による管理制限がないかを確認します。設定画面の項目名や場所はシステムによって異なるため、端末に表示される内容を確認してください。決まった場所を探すために、無関係な権限を何度も変更しないでください。

端末にほかのVPN構成がある場合は、現在接続中の構成を確認してください。Shadowrocketをテストする前に、使用中の別のVPN接続を終了し、システムの接続先切り替えをサーバー障害と誤認しないようにします。構成を保存することと接続を維持することは別です。通常、テストのためにすべての構成を削除する必要はありません。まず切断し、状態を確認してから、接続を一度試してください。失敗した段階を特定しやすくなります。

カメラ権限が必要なのはQRコードの読み取り時だけです。Scan QR Codeで既存のサーバー情報を追加する場合は、システムの案内に従ってカメラへのアクセスを許可してください。QRコードを使わない場合は、アプリで利用できる別の追加方法を選べます。カメラ権限を拒否してもVPN権限を拒否したことにはならず、サーバーに接続できない原因とも限りません。それぞれの権限について、利用する機能に必要か確認してから許可してください。

初回接続の前に元に戻せる状態を保つ

本格的な設定の前に、端末からテスト対象の一般的なWebページにアクセスできることを確認してください。Wi-Fiとモバイル通信のどちらを使っているか、Web認証が必要なネットワークかどうかも記録します。Web認証が必要な場合は、先に認証を完了してからShadowrocketに接続します。基本ネットワークがまだ開放されていないと、アプリに権限があっても接続に失敗することがあります。プロトコルのパラメータを何度も変更すると、原因を見誤るおそれがあります。

初めて使うときは、まず手動接続を試し、複雑なOn Demand条件は設定しないでください。「サーバーを選ぶ、ルーティングモードを選ぶ、接続を有効にする、接続先にアクセスする、接続を切る」という一連の操作を行い、各段階の状態を確認します。自動接続は基本設定が正しいことを前提とします。先に有効にすると、手動で切断しても再接続されるなど、権限、条件の発動、サーバー接続の不安定さを切り分けにくくなる場合があります。

設定やトラブルの記録用にスクリーンショットを撮る場合は、パスワード、サブスクリプションURL、認証情報、復元につながるQRコードを先に隠してください。システムの確認画面やアプリの設定画面は操作段階の記録に使えますが、共有前に内容を一つずつ確認してください。権限の確認に必要なのは、許可画面が表示されたか、許可したか、どの段階で失敗したかです。サービスの認証情報を公開する必要はありません。準備ができたら、サーバーの追加に進みます。

04 / GLOBAL ROUTING

ルーティング：Config、Proxy、Directの役割を区別

まず3つのモードでリクエストの処理方向を決める

日常的なルールによる振り分けにはConfigを使い、選択中のサーバーを確認するにはProxyを使い、端末から直接アクセスした場合と比較するにはDirectを使います。Global Routingはアプリ全体のルーティング方法を選ぶ項目で、サービスのプロトコルやシステムの許可スイッチではありません。リクエストがサーバー経由または直接接続になる理由を調べる前に、現在の設定を確認してください。サーバー名だけを見ても、実際の経路は判断できません。

Configでは通常、ルールが順に確認され、最初に一致したルールの処理ポリシーが適用されます。より具体的な例外は、それを上書きする可能性がある広範なルールより前に置きます。FINALは、それ以前のルールに一致しなかった場合の最終処理です。以下の例はマッチングの仕組みを説明するもので、既存の設定すべてにそのまま適用できる完全なConfigではありません。変更前に現在有効なファイルをコピーし、既存のサーバーとポリシーの定義を残してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

ルールの種類、ポリシー、順序を分けて理解する

DOMAINは完全なドメイン名に一致し、DOMAIN-SUFFIXはドメインのサフィックスに一致し、DOMAIN-KEYWORDはドメイン名に含まれるキーワードに一致します。サフィックスルールは、ドメインとそのサブドメインに共通のポリシーを適用するのに適しています。キーワードルールは範囲が広く、同じ文字列を含む別のドメインにも一致することがあります。ルールを追加する前に、対象範囲を明確にしてください。対象ドメインの確認を省き、広すぎるルールで代用しないでください。

IP-CIDRとIP-CIDR6はそれぞれ対応するアドレス範囲に使い、GEOIPはアドレスデータベース上の所属情報に基づいて判定します。ドメインへのリクエストには名前解決が関わる場合があり、IPルールの適用も名前解決の動作に影響される場合があります。例にあるno-resolveは、そのルールが追加の名前解決を引き起こさないようにする指定であり、接続速度を上げる汎用スイッチではありません。ルールに一致するかどうかは実際のリクエスト情報によって決まるため、Webページに表示された名前だけから推測できません。

PROXY、DIRECT、REJECTはそれぞれ異なる処理ポリシーを表し、Global Routingで選ぶ画面上のモードとは別のものです。ConfigのルールがDIRECTに一致しても、アプリ全体がDirectに切り替わるわけではありません。PROXYに一致した場合も、現在のConfigでのポリシー参照先とサーバーの選択を確認してください。ファイルで独自のポリシーグループ名を使う場合、ルールの末尾には実在し、表記が一致する名前を指定する必要があります。

変更を最小限にしてルールの有効性を確認

Configを編集するときは、同名のコピーではなく、現在選択されているファイルを変更しているか確認してください。保存後、アプリの案内に従って再接続またはConfigの再読み込みを行い、新しいリクエストを送信します。既存の長時間接続、Webページのキャッシュ、アプリのキャッシュにより、以前の動作が続く場合があります。すでに開いているページだけを確認せず、明確に新しいリクエストを行い、リクエスト記録で一致したポリシーを確認してください。

Proxyでは接続できるのにConfigで接続できない場合は、ルールへの一致、ポリシーグループの参照、DNSの結果を優先して比較し、すぐにサーバーを作り直さないでください。Directでは正常でProxyでは異常がある場合は、サーバーとプロトコルを確認します。3つのモードは原因を絞り込むための比較手段であり、互いに代用できる修復スイッチではありません。テスト後は本来使うモードに戻し、一時的なテスト設定をそのまま使い続けないようにしてください。

ConfigにはDNS、ポリシーグループ、リモートルールへの参照が含まれる場合もあります。FINALの1行だけを見て全体の動作を判断しないでください。まず、検証しやすい少数の明確なルールで基準を作り、例外を少しずつ追加します。ルールを追加するたび、対象、想定するポリシー、実際に一致した内容を記録してください。引き続き確認する場合は、この3点を添えてよくある質問とトラブル対処を参照すると、「振り分けがおかしい」とだけ伝えるより原因を絞りやすくなります。

06 / DATA

Data：通信量の統計、リクエスト記録、サービスの使用量を区別

数値はまず集計範囲を確認し、その後に大きさを見る

Dataの通信量情報は、クライアント側の処理状況を確認するためのもので、利用中のサービスの最終的な課金量と同じとは限りません。数値を見る前に、項目名、集計期間、現在の接続状態を確認し、アップロード、ダウンロード、現在の接続、累計記録のどれを表しているかを把握してください。集計範囲が異なる数値をそのまま差し引いて比べたり、2か所の数値が違うだけでクライアント側またはサーバー側の集計ミスと判断したりしないでください。

アップロードとダウンロードは、端末から見たデータの方向を表します。ページを開くときにもアップロードのリクエストが発生する場合があり、コンテンツのダウンロード中にもプロトコルの通信が行われます。そのため、アップロードをファイルの送信だけと考えることはできません。通信量の数値はデータの転送量を示すもので、すべての内容が正常に表示されたことを意味しません。再接続、バックグラウンド更新、失敗したリクエストでも通信量が発生する場合があります。実際の操作と照らし合わせて判断してください。

端末側の統計とサーバー側の記録には、集計時間、プロトコルのオーバーヘッド、リトライの扱い、サーバー独自の計算方法などによって差が生じる場合があります。また、ルールによって直接接続されたリクエストは、サーバー側では一部しか確認できない場合があります。使用量を照合する場合は、まず確認する時間と接続範囲をそろえ、利用中のサービスの説明を確認してください。Dataを請求額の確定記録として扱わないでください。

リクエスト情報からルールと名前解決の問題を確認

リクエスト記録では、まず自分で直前に行った操作を探し、時刻、接続先、適用されたポリシーを確認します。端末はバックグラウンドでほかの通信を行うため、一覧の先頭が調査中のWebページとは限りません。無関係な操作をいったん止め、明確なテストを1回実行すると、対象を絞りやすくなります。再確認するときは接続先を変えず、異なるリクエストの結果を同じリクエストの変化と誤認しないようにしてください。

記録にルールの一致情報がある場合は、ルールの種類と最終ポリシーを合わせて確認します。ドメインルールへの一致は、そのルールがマッチングされたことを示すだけです。ルールが参照するポリシーが想定どおりかも確認してください。DIRECTの記録はサーバーの障害を意味せず、REJECTの記録も必ずしも接続エラーではありません。Configで指定された処理である可能性があります。まず想定と比較し、異常かどうかを判断します。

ドメイン名の記録とアドレスの記録は分けて考える必要があります。同じWebページでも複数のドメインにアクセスすることがあり、同じドメインでも異なるアドレスに名前解決される場合があります。ネットワークを切り替えた後に結果が変わることもあります。1つのアドレスの所属情報だけでは、Webページ全体にどのルールを適用すべきか判断できません。DNSを調べるときは、名前解決の結果、一致したポリシー、接続先へのアクセスをまとめて確認し、1つのアドレスだけを根拠に広範なGEOIPやIP-CIDRルールを変更しないでください。

通信量の急増、記録の削除、プライバシーへの配慮

端末で操作していないのに通信量が増える場合は、バックグラウンド同期、メディア再生、システムアップデート、ほかの実行中の通信を先に確認し、現在のテストと関係があるかを判断します。一定時間バックグラウンドの動作を減らし、接続を有効にする前後や異なるルーティングモードで比較できます。数値が増えただけでサブスクリプションに問題があると決めつけないでください。クライアントが処理するバックグラウンドのリクエストも統計に反映される場合があります。

アプリに統計や記録を消去する機能がある場合、実行前にトラブル対処に必要な集計範囲と重要な状態を保存してください。端末上の表示を消去しても、サーバー側の使用量が消えるわけでも、サーバーの接続状態が変わるわけでもありません。数値の消去をサービスの利用量回復に使わないでください。リセット後の短時間テストは条件をそろえて変化を見るのに役立ちますが、新しい測定開始点を記録し、以前の累計値と直接比較しないようにしてください。

リクエスト記録には、アクセス先のドメイン、サーバーアドレス、時刻、その他の機密情報が含まれる場合があります。エクスポートやスクリーンショットの共有前に、項目ごとに確認してください。問題を共有するときは、ルールの種類、ポリシー名、エラーが発生した段階を残し、個人の認証情報や問題に関係のないアクセス内容を隠せます。サブスクリプションURLは一部だけ表示されていても認証情報を含む可能性があります。先頭を切り取れば安全だと思わず、共有前に表示範囲全体を確認してください。

Dataは単独で結論を出すものではなく、判断の根拠を得るために使います。1回のアクセスについて、ネットワーク環境、ルーティングモード、一致したポリシー、結果を合わせて記録すると、大量のスクリーンショットを集めるより効果的です。記録と観察結果が一致しない場合は、同じリクエストの記録かを確認してから、キャッシュや長時間接続を調べてください。根拠を整理したうえでSettingsを調整し、統計の変化だけを理由に広範な設定を変更しないようにします。

08 / MAINTENANCE

メンテナンス：有効な設定を保ち、更新と復元を分けて管理

アプリ、サブスクリプション、ルールを個別にメンテナンス

App Storeのアプリ更新、Subscribeの一覧更新、Configのルール管理は別々に行います。アプリの更新はクライアント自体を変更し、サブスクリプションの更新はサーバー情報を変更し、ルールの更新はリクエストの振り分け条件を変更します。それぞれ異なるタイミングで行われるため、変化があったら最近どの部分を変更したかをまず確認してください。サブスクリプションの更新に成功してもアプリが更新されたとは限らず、アプリの更新で無効な情報を確認することもできません。

App Storeで更新する前に、現在有効な設定を保存し、サブスクリプション情報を再取得できることを確認します。更新後は、元のサーバー、ルーティングモード、テスト対象を使って結果を確認してください。新しいルールをすぐに同時追加しないでください。結果に変化があった場合は、具体的な機能と失敗した段階を記録し、Configとの互換性、ネットワーク環境、サーバーの状態のどれに関係するかを確認します。アプリの更新履歴はApp Storeで確認できるため、自分でバージョン一覧を管理する必要はありません。

サブスクリプションの更新後は、一覧の項目の追加・削除、名前の変更、現在の選択が引き続き有効かに注意してください。更新完了後は、少なくとも現在使っているサーバーを1つ確認します。「成功」という表示だけで判断しないでください。一覧が突然空になった場合は、手元の情報を残してリンクの状態を確認し、削除と再追加を繰り返さないでください。利用中のサービスの利用期限と権限は、利用者自身が契約したサービスによって決まり、クライアントの更新では延長も変更もされません。

バックアップはファイルを1つ保存するだけではない

バックアップでは、ルールファイル、手動で追加したサーバーのパラメータ、サブスクリプションURLを区別してください。Configファイルにすべてのサーバー情報が含まれているとは限らず、一覧のスクリーンショットでは認証情報を復元できません。アプリのエクスポートやバックアップ機能を使う前に、実際にどの情報が含まれるかを確認し、必要なデータを自分で管理できる場所に保存してください。バックアップファイルに認証情報が含まれる場合があるため、公開URL、共有フォルダ、内容を確認していないチャットには保存しないでください。

バックアップを検証するには、ファイルが存在するかではなく、復元できるかを確認します。現在有効な設定を壊さないように、エクスポート内容と復元手順を確認し、ファイルが読み取れること、ルールがそろっていること、ポリシー参照先が存在することを確かめてください。バックアップの確認のために、すべての設定を消去する必要はありません。元の設定を残してコピーを確認すれば、バックアップ作業がすべての接続を再調査する作業に変わるのを防げます。

機種変更後は、まずApp StoreからShadowrocketを復元し、続いてサーバー情報とConfigを復元します。購入権の復元と端末上のデータの復元は別々に確認してください。同じアカウントでアプリを入手できても、すべての設定が自動で表示されるとは限りません。ファミリー共有、複数デバイスでの利用、互換性の条件はApp Storeページの記載に従ってください。復元後はまず手動接続を確認し、利用できることを確かめてからOn Demandなどの自動動作を再び有効にします。

不要な項目を整理し、再利用できる記録を作る

サーバー一覧を整理するときは、一時的なテスト失敗と、今後使わないことが確認済みの項目を区別します。ネットワークの一時的な不安定さによるタイムアウトが1回あっただけでは、削除すべきとは判断できません。サブスクリプションを更新し、パラメータを確認してから、同じ条件で再テストしてください。手動追加した項目には情報の提供元を記録し、サブスクリプションから追加された項目は次回更新時に再構成される可能性に注意します。名前や1回のテスト結果だけでまとめて削除するより、追加元に沿って整理するほうが安全です。

Configにも、明確な有効状態を1つ残してください。変更前にコピーを作成し、ドメインの例外を1つ追加する、最終ポリシーを変更するなど、変更の目的を記録します。結果を確認してから元のファイルを置き換えるか判断してください。同じ名前のコピーを複数作り、それらをすべて「現在のConfig」として使わないでください。次回の接続時に選択を誤る可能性があります。例にある予約済みアドレスやドメインは説明用であり、実際のサーバー接続情報として使うことはできません。

トラブルの記録は簡潔で構いませんが、ネットワークの種類、選択したサーバーの情報元、Global Routing、問題が起きた時間帯、エラーの段階、直近の変更を含めてください。パスワードやサブスクリプションの認証情報全体を記録する必要はありません。同様の問題が再発したら、前回の有効な状態と比較し、最近の変更を確認してから、権限、サーバー、名前解決、ルール、接続先へのアクセスの順に検証します。毎回すべてを最初から設定し直す必要はありません。

長期利用時の確認順序は、基本ネットワークが正常、情報が有効、正しいConfigが選択済み、想定どおりのルーティングが適用される、接続先にアクセスできる、の順です。この流れを確認してから、自動接続や複雑なルールを追加してください。最短の手順をもう一度確認するにはクイックスタートをご覧ください。購入と復元についてはダウンロードガイドを、具体的な症状についてはよくある質問とトラブル対処を参照してください。