Shadowrocket 使い方完全ガイド

入手方法と正規アプリの確認：アプリを確かめてから接続情報を準備

ShadowrocketはAppleプラットフォーム向けの有料クライアントで、主な利用端末はiPhoneとiPadです。入手先はApp Storeのみです。Mac、Apple TV、Apple Visionとの互換性も同じ製品ページで確認できます。システム要件や共通の購入条件は、App Storeのページに記載された内容をご確認ください。このマニュアルではiPhoneとiPadでの操作を中心に説明します。他のデバイスの画面レイアウトを、そのままモバイル端末に当てはめないでください。購入前に、対象端末から該当するストアページを開けることを確認し、互換性と購入情報を確認しましょう。アカウントの問題と接続設定の問題を混同せずに済みます。

デベロッパ、アイコン、アプリ ID を確認

ダウンロードガイドの正規アプリ確認方法に沿って確認します。アプリ名はShadowrocket、デベロッパはShadow Launch Technology Limited、アプリ IDは932747118です。アイコンが当サイトのページ上部に表示されている公式アイコンと一致することも確認してください。アプリ名は最初の確認材料にすぎません。検索結果に似た名前があっても、デベロッパとアプリ IDの確認に代わるものではありません。製品リンク末尾のid932747118からアプリ IDを確認できます。ストアの検索結果がはっきりしない場合は、ダウンロードガイドに戻って製品ページから確認してください。名前が似ているだけで購入を進めないようにしましょう。

詳細ページでは、製品情報とアカウントの現在の状態を区別して確認します。価格ボタン、再ダウンロードのアイコン、互換性に関する表示は、それぞれ異なる情報を示しています。価格は購入について、再ダウンロードは購入履歴について、互換性は現在のデバイスが条件を満たすかについての表示です。いずれかの表示に問題があっても、他の項目にも問題があるとは限りません。たとえば購入履歴があるのに一時的にインストールできない場合は、同じ名前の別製品を探し直すのではなく、デバイスとアカウントに関する案内を確認してください。購入前にデベロッパとアプリ IDを控えておけば、別のデバイスでも同じ情報で照合できます。

購入するのはクライアントアプリであり、接続サービスではありません

Shadowrocketは買い切り方式です。米国ストアでの価格は約2.99米ドルですが、各ストアでは現地通貨で表示されます。実際の価格と購入条件はApp Storeのページに記載された内容をご確認ください。購入によって得られるのはアプリの利用権であり、サーバーアドレス、認証情報、サブスクリプションリンクが自動的に提供されるわけではありません。アプリの買い切り購入と接続サービスの契約は別です。サブスクリプションはご利用のサービス提供元から入手し、Shadowrocketへのインポート方法に対応していることを確認してください。接続情報をまだ用意していなくても、アプリをインストールして画面を確認できます。サーバーリストが空でも、購入に失敗したとは限りません。

デバイスとアカウントの条件を分けて確認

iPhoneでは、まずシステム要件を確認してからストアで購入し、インストールします。同じ購入アカウントを使う場合でも、iPadに再ダウンロードできるか、購入の適用範囲はどうなるかをApp Storeのページで確認してください。2台の画面レイアウトが異なるからといって、照合せずに別のパラメータを新たに設定しないでください。ストアでの表示、支払い方法、購入履歴は、現在のストアアカウントの状態によって異なります。製品ページを一時的に利用できない場合は、表示された案内を確認し、現在のストアとアカウントで購入できるかを確かめてから次の手順に進みましょう。設定を何度も切り替えることが、常に有効な解決策とは限りません。

機種変更や再インストールの際は、まずApp Storeのアカウントと購入済み項目からShadowrocketを探し、購入に使用したアカウントを確認します。アプリを再ダウンロードした後、以前のサーバー、サブスクリプション、構成がデバイスに復元されているかは、別途確認が必要です。アプリが再び表示されたからといって、接続情報もすべて復元されたと考えないでください。起動後にサーバーリスト、現在の構成、ルーティングの状態をそれぞれ確認し、内容がそろってから初回接続テストを行います。購入の復元手順は購入済みアプリの復元方法をご覧ください。

次の章に進む前に、自分用の情報リストを用意しておくと便利です。サブスクリプションの入手元、サーバーのプロトコル、認証方式、構成の入手元、設定が必要なデバイスを記録します。パスワードをすべて保存する必要はなく、情報の保管場所だけ記載してもかまいません。不明なパラメータは空欄のままにして提供元に確認するほうが、よくある値を推測して入力するより確実です。インポート、更新、トラブルシューティングを行うときは、このリストで情報の出所を確認しましょう。アプリをインストールできたのは入手段階が完了したということであり、接続情報の有効性を示すものではありません。

初回起動と権限：VPN構成とHome画面の入口を理解する

Shadowrocketを初めて開いたら、接続スイッチを操作する前にHome画面を確認します。Homeは接続操作の主な入口です。接続状態、Global Routing、Connectivity Test、SERVERリストは、それぞれ状態表示、ルーティングの選択、接続テスト、サーバーの選択を担当します。これらは別々の項目です。リストにサーバーがあるだけでは選択済みとは限らず、選択済みでも接続が確立したとは限りません。システムにVPN状態が表示されても、すべての接続先にアクセスできるとは限りません。それぞれの状態を分けて理解しておくと、画面上部のスイッチだけで成否を判断することを避けられます。

VPN構成の追加を許可する意味

初回の接続など、システム構成の作成が必要な操作を行うと、VPN構成の追加を許可するか尋ねられる場合があります。Shadowrocketの操作をきっかけに表示された確認であることを確かめてから、システムの案内に従って許可してください。デバイスのパスコードなどによる認証が必要な場合もあります。この手順により、アプリがシステムのネットワーク拡張機能を使って通信を処理できるようになります。特定のサーバーが自動的に信頼されたり、認証情報が自動入力されたりするわけではありません。実際に通信するには、引き続き正しいサーバー、ルーティング、構成が必要です。

確認画面で以前に許可しなかった場合は、アプリに戻って接続操作をやり直し、システムに再表示される案内に従ってください。期待した確認画面が表示されない場合は、スイッチを続けて何度もタップするのではなく、システム設定でVPN構成の状態を確認し、すでに構成が存在するかを確かめます。管理対象デバイスでは、組織のポリシーによって構成の作成やネットワーク拡張機能の利用が制限される場合があります。その場合はデバイスの管理者に確認してください。他の用途のシステム構成を安易に削除しないでください。特に仕事用や学習用のデバイスでは、削除前に用途と復元方法を把握しておく必要があります。

Home画面の流れに沿って4つの状態を確認

1. まずSERVERを確認し、使用するサーバーが追加済みで、選択状態になっているか確認します。
2. 次にGlobal Routingを確認し、現在の設定がConfig、Proxy、Directのどれかを確認します。
3. 画面上部の接続スイッチをオンにし、タップしてすぐ画面を離れず、状態が切り替わることを確認します。
4. Connectivity Testを実行し、さらに実際のリクエストを1つ選んで確認します。

接続が確立していない場合、Not Connectedと表示されることがあります。この状態が示すのは現在の接続状況であり、失敗の原因までは特定できません。サーバーリストが空、認証エラー、システム構成が未許可、ネットワークが利用できないなど、原因に応じてそれぞれ確認が必要です。反対に、画面上部の状態が切り替わっても、接続機能が動作状態になったことを示すだけです。サーバーが転送できるか、ドメインを解決できるか、ルールが想定したポリシーを選択しているかは、別途確認してください。画面の詳しい説明は初回起動とHome画面の各エリアの説明をご覧ください。

その他の権限は、必要な操作に応じて許可

Scan QR Codeでインポートする場合はカメラ権限が必要です。許可しなかった場合は、システム設定で該当する権限を確認してからスキャンに戻ります。手入力やリンクからインポートするだけなら、あらかじめカメラ権限を有効にする必要はありません。ファイル選択画面から構成をインポートするときは、選択したファイルの入手元と内容を確認してください。クリップボードから情報を読み取る場合は、接続情報を直前にコピーしたことを確認します。権限の確認画面で分かるのは、アプリがどの種類のシステムリソースにアクセスしようとしているかです。情報の入手元を判断する代わりにはなりません。

初回は一度に1つの操作だけ行うのがおすすめです。まず確認済みの情報を1件インポートし、リストの内容を確かめてから接続します。権限の確認が終わらないうちにネットワークを切り替えたり、サブスクリプションを更新したり、ルーティングを変更したりしないでください。異常が起きたとき、どの操作が原因か分かりにくくなります。システムから再認証を求められた場合は、そのときの操作と表示された文言を記録し、既存のVPN構成が現在のアプリに対応しているか確認します。接続に一度失敗しただけでアプリを削除すると、バックアップしていないローカル情報を失い、再認証や再インポートの手間が増える場合があります。

この段階では、デバイス自体がインターネットに接続していることも確認します。通常アクセスできるページを開き、現在のネットワークでログインや確認手続きが必要かどうかを確かめてください。インターネットに接続されていないデバイスに、アプリが基礎となる接続を作ることはできません。公共ネットワークのログインページが表示される場合は、必要な手続きを済ませてからShadowrocketをテストします。ネットワークを引き継ぐ他の機能がデバイス上で動作している場合は、それぞれの役割を確認し、条件を整えて1つずつ比較してください。こうした確認を済ませると、次章でのインポート結果を安定した環境でテストできます。

サーバーとサブスクリプション：個別の接続情報、Subscribe、Configを区別

インポート前に、手元の情報が何にあたるかを確認します。個別のサーバー情報は1つの接続先を示し、通常はプロトコル、アドレス、ポート、認証情報を含みます。サブスクリプションリンクはサーバーの一覧を取得・更新するためのものです。Configファイルは主にルールや関連設定を含み、ポリシー名を参照する場合もあります。リンクの見た目だけで、これらの情報を相互に置き換えることはできません。サブスクリプションはご利用のサービス提供元から入手し、形式が分からない場合は、どの入口に追加する情報なのかを先に確認してください。サービス案内ページのURLを、そのままサブスクリプションリンクとして使わないでください。

Add Serverから手動で追加

Add Serverを開いたら、手元の情報と同じプロトコルを選び、そのプロトコルで必要な項目を入力します。アドレスには実際のサーバーのドメイン名またはアドレスを入力し、ポートには提供された値を指定します。認証にはPassword、UUID、鍵などが使われますが、相互に置き換えることはできません。入力時にスペース、全角記号、改行が追加されていないか確認し、コピーした文字列の前後に余分な空白がないかもチェックします。表示名はサーバーを見分けるためのもので、接続パラメータではありません。名前を変えても、アドレス、認証情報、トランスポート設定の誤りは解決しません。

同じプロトコルでも異なるトランスポート方式が使われることがあります。「プロトコル名が同じ」というだけでは条件を満たしません。TLSが必要な接続では、実際の接続先アドレスと証明書の検証名が異なる場合があり、HostとSNIにもそれぞれ異なる役割があります。すべてのドメイン項目に同じ値を入力して試すのは避けてください。情報に記載のない項目は、初期値のままにするか提供元に確認します。プロトコルの概要は対応プロトコルとパラメータの概要をご覧ください。実際の入力には、ご自身のサーバー情報を使用してください。

Subscribeから追加・更新

サブスクリプションを追加するには、該当するSubscribeの入口に完全なリンクを入力して保存し、更新を実行します。リンクのパスやクエリ部分が認証に使われることがあり、一部を省くとエラーページや空の結果になる場合があります。URLを短くするためにパラメータを削除したり、認証情報を公開の質問欄に貼り付けたりしないでください。更新後はSERVERに戻り、想定した項目が追加されたことを確認してから、その中の1つを選んで接続します。サブスクリプション名は整理のために変更できますが、後で更新対象を確認できるよう、入手元を判別できる情報は残しておきましょう。

サブスクリプションの更新成功は、今回の内容を取得して解析できたことを示すだけで、個々のサーバーがその時点で利用できるとは限りません。更新に失敗しても、すべてのサーバーが使えなくなったとは限りません。現在の基本ネットワーク、リンクの完全性、認証の有効性、取得内容の形式を分けて確認します。以前から使えるリストがある場合は削除せず、エラー表示を記録してから対処してください。サブスクリプションの更新で項目が追加、削除、改名されることもあるため、更新後に現在選択中のサーバーが残っているか確認しましょう。

QRコード、リンク、構成ファイルの違い

Scan QR Codeは、認識可能な接続情報をインポートするのに便利ですが、QRコードは情報を伝える手段にすぎず、有効性を保証するものではありません。スキャン後にプロトコルとアドレスを確認してから保存します。結果が通常のWebページだった場合は、正しいQRコードか情報の入手元に確認してください。クリップボードやファイルからインポートする場合も同様です。成功の表示だけを見るのではなく、インポート後に実際に作成された項目を確認しましょう。Import from Cloud JSONなどの専用入口は、手元の情報で使用が明確に指定されている場合に限って使い、合わないファイルを複数の入口で繰り返し試さないでください。

Configとサブスクリプションは分けて管理します。サーバーリストを更新しても、必要なルールが自動的に作成されるわけではありません。構成を切り替えても、サブスクリプション更新の代わりにはなりません。ルールが独自のポリシー名を参照している場合、現在の環境でその名前を認識できるか確認してください。元の情報を保管してからローカルで調整し、変更した対象が個別のサーバー、サブスクリプショングループ、構成ファイルのどれかを記録します。対象を意識しておけば、リストの内容が変わったときも、再インポート、サブスクリプションの更新、現在の構成の修正のどれが必要か判断できます。

Global Routing：Config、Proxy、Directとルールの順序

Global Routingでは、全体のルーティング方式を選択します。設定に従う方式がConfig、プロキシ経由がProxy、直接接続がDirectで、画面上では英語表記のまま表示されます。これらはサーバーのプロトコルや通信速度の段階を示すものではありません。Configでは現在の構成のルールに従って処理方法を選びます。Proxyでは現在の接続で処理できるリクエストを、選択中のプロキシポリシーに渡します。Directは直接接続に使います。トラブルシューティングを始める前に、まず現在の方式を確認してください。同じサーバーでも、方式によって実際のリクエスト経路が異なる場合があります。

方式を確認して問題の範囲を切り分ける

Proxyでは同じリクエストが成功し、Configでは失敗する場合は、すぐに認証情報を変更するのではなく、ルールの適用先やポリシーの参照を優先して確認してください。両方で失敗する場合は、基本ネットワーク、サーバー、名前解決を確認します。Directの結果は直接接続経路との比較にすぎず、プロキシ経由の経路が正常であることを証明するものではありません。テスト後は、日常利用に必要な方式に戻してください。一度の診断に使った設定をそのままにすると、その後の統計やアクセス状況が想定と異なる場合があります。

ルールは上から順に照合し、具体的な条件を先に配置

ルールでは条件、ポリシー、順序が重要です。通常は上から順に照合し、最初に一致したルールで処理方法が決まります。そのため、具体的な例外は範囲の広い条件より前に置き、FINALは最後にフォールバックとして配置します。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはドメインの末尾、DOMAIN-KEYWORDはドメインに含まれるキーワードに一致します。IP-CIDRとIP-CIDR6はそれぞれアドレス範囲に使い、GEOIPはIPアドレスの地域情報を利用します。キーワードを知っているからといって安易にコピーせず、対象のリクエストからルールの照合に必要な情報を取得できるか確認してください。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、まず特定の完全なドメインをDirectで接続し、同じサフィックスに一致する他のリクエストはPROXYを使用します。プライベートアドレス範囲はDIRECTとし、続いてGEOIPでIPアドレスの地域情報に応じて処理し、最後にFINALでフォールバックします。ここで示すのは構文と順序であり、すべてのネットワークに適した設定ではありません。特にGEOIPルールはドメインルールの代わりにはならず、リクエストごとに利用可能なIPアドレス情報が存在するとも限りません。実際の構成に使う前に、既存のルール、ポリシーの定義、ローカルネットワークの要件を確認し、例を使って元のファイル全体を置き換えないようにしてください。

ポリシー名と画面上のルーティング方式を混同しない

ルールに記載するPROXY、DIRECT、REJECTは処理ポリシーを示すキーワードであり、Global RoutingのProxy、Directとは概念上の階層が異なります。構成が定義済みのポリシーグループや特定の名前を参照する場合もあり、名前のスペルと参照先を一致させる必要があります。ルールの構文が正しくても、参照先のポリシーが存在するとは限りません。ポリシーが存在しても、内部で選択されているサーバーが利用できるとは限りません。構成を確認するときは、「どのルールに一致したか」「そのルールは何を参照しているか」「そのポリシーは最終的に何を選択するか」の順に確認し、条件だけを見て判断しないでください。

複雑なページでは複数のリクエストが発生します。1つのページでも、ページ本体、リソース、APIの各ドメインにアクセスし、それぞれ異なるルールに一致する場合があります。ページが開いても一部のコンテンツが表示されない場合は、失敗したリクエストの実際の接続先を確認してからルールを追加するか判断してください。DOMAIN-KEYWORDの範囲が広すぎると、関係のないドメインにも影響する場合があります。対象範囲を正確に指定できる条件を優先してください。ルールは一度に少数ずつ追加し、ローカルの例外には用途を一言記録しておくと、サブスクリプションや構成を更新した後も必要性を判断しやすくなります。

構成をインポートした後は、現在使用するファイルが正しく選択されていることを確認します。ファイルを編集しただけでは、その内容が適用されたことにはなりません。保存後に構成が利用できるか確認し、必要に応じて接続を再確立して古い接続の影響を除いたうえで、同じ接続先を再テストします。長時間維持される接続では、ページを開き直すだけでは新しいポリシーを確認できない場合があります。テストするアプリの動作に応じて、リクエストを改めて実行してください。構成の選択、ルールの順序、リクエストのライフサイクルを合わせて考えると、「ルールを変更したのに結果が変わらない」理由を正しく判断できます。

接続と確認：サーバーの選択から失敗箇所の切り分けまで

接続前にHomeに戻り、SERVERで想定したサーバーが実際に選択されているか確認します。サーバーの編集画面を開いただけでは選択したことになりません。今回のテストに合ったGlobal Routingであることを確認してから、画面上部のスイッチをオンにします。システムとアプリの状態が変わるのを確認し、接続処理が完了してからテストしてください。初回の確認では、情報が明確なサーバーを1つ選び、固定の接続先を使うのがおすすめです。サブスクリプション更新、ルール変更、複数のテストを同時に行わないでください。一度の偶然の成功より、条件をそろえて繰り返せるテストのほうが参考になります。

接続の成功を3つの段階に分けて考える

第1段階はシステムの接続状態で、ネットワーク拡張機能が動作状態になっているかを示します。第2段階はサーバーへの通信経路で、現在の接続先が必要な通信を確立できるかを示します。第3段階は実際のサービスへのリクエストで、接続先のドメイン、名前解決、ルール、サービス自体の状態が関係します。この3段階で結果が異なることもあります。たとえばシステムの状態が正常でも、ページが開かない場合があります。サーバーのポートが応答しても、認証やその後の転送が成功するとは限りません。トラブルシューティングでは、どの段階で失敗したかを記録し、すべてを「接続できない」でまとめないようにしましょう。

Connectivity Testは簡易確認の入口として使えますが、結果はテスト方法、接続先、現在のネットワーク条件に左右されます。あるテストの数値が示すのは、その時点での特定の経路だけであり、日常利用の品質を順位付けするものではありません。テストを実行したら、実際の接続先も開き、ページやリクエストが最後まで完了するか確認します。テスト結果と実際の動作が一致しない場合は、どちらか一方を絶対的な結論とせず、接続先、プロトコル、ポリシーを比較してください。操作の流れはサーバーの選択とConnectivity Testによる確認をご覧ください。

基本ネットワーク、接続先、名前解決、ルールの順に確認

1. デバイスの基本ネットワークが利用でき、現在のネットワークで必要なログインや確認手続きが完了していることを確認します。
2. 選択中のサーバーのアドレス、ポート、認証情報、必要なトランスポートパラメータを確認します。
3. ドメイン名を解決できることを確認し、アドレスに接続できない問題と名前解決の失敗を区別します。
4. ルーティング方式、現在の構成、失敗したリクエストに適用されたポリシーを確認します。
5. 最後に、接続先のサービスからの応答とアカウント条件を確認します。

タイムアウトが発生した場合は、まず利用可能と確認済みの別のサーバーと、条件を管理できる別のネットワークで比較します。接続先と構成を変えずに比較すれば、どこに差があるか判断できます。ネットワークを変えると同じ接続先が復旧する場合は、元のネットワークの制限、接続状態、経路の条件を調べます。どのネットワークでも特定の接続先だけが失敗する場合は、その接続情報とサービスの状態を優先して確認してください。根拠がないままポート、パスワード、TLS、DNSを同時に変更しないでください。復旧しても原因が分からなくなります。

認証またはTLSに関する表示が出た場合は、元の情報に戻って一字ずつ確認します。認証エラーは通常、ルールを追加しても解決しません。証明書名が一致しない場合も、検証を安易に緩めて隠さないでください。デバイスの日付と時刻が正確か、SNI、接続先ドメイン、証明書の要件がどう関係するかを確認し、想定されるパラメータを情報提供元に問い合わせます。エラー表示がデータ形式を示している場合は、同じ項目を繰り返しテストするのではなく、まずインポートした情報を修正します。エラー表示の原文を保存しておくと、認証、ハンドシェイク、接続先からの応答のどの段階かを区別できます。

一部のリクエストだけ失敗する場合は、リクエスト自体を確認

特定のページやアプリの機能だけが失敗する場合は、同じ条件で他の接続先が正常か確認します。そのうえで、失敗した接続先が追加のドメイン、異なるトランスポート、持続接続を使用していないか調べてください。ブラウザーやアプリ内のキャッシュ、古い接続が以前の結果を保持している場合があります。ルール変更後はリクエストを改めて実行して比較します。接続先サービスのログイン状態、地域設定、アカウント条件も応答に影響する場合があります。こうした結果をすべてクライアントアプリの不具合と決めつけないでください。失敗の範囲を絞り込むほど、ログの情報を解釈しやすくなります。

記録が必要な場合は、問題を再現できる短い時間だけを対象にします。テスト時刻、接続先、現在のサーバー、ルーティング方式を記録してからリクエストを1回実行し、関連する記録を確認します。共有する前に、サブスクリプションリンク、認証情報、完全な鍵、問題に関係しないアクセス内容を削除してください。エラーの種類、プロトコル名、実施した比較テストは共有できますが、接続情報全体を公開しないでください。状態の説明や対処方法はFAQをご覧ください。

確認に成功したら、同じリクエストを少なくとももう一度実行し、更新操作によって構成やサーバーの選択が変わっていないことを確認します。長期利用する場合は、ネットワークを切り替えた後の動作も確認してください。ただし、ネットワーク切り替えのテストと初回接続のテストを同じ回に行わないようにします。使用ネットワーク、サーバー、ルーティング方式、アクセスできる接続先を簡潔な基準として記録しておきましょう。次回問題が起きたとき、この基準を再現するほうが、すべてのパラメータを最初から入力し直すより速く、正常に動作していた設定も壊しにくくなります。

Dataの通信量：統計の範囲を理解してリクエストの行き先を確認

Dataはアプリに記録された通信量を確認するためのものであり、単独でネットワーク品質を判断するものではありません。数値を見る前に、どの統計範囲、どの対象、どの期間が表示されているか確認してください。サーバー別の表示では各接続先が扱った通信量を、アプリ別の表示では各アプリに関連付けられた通信を確認できます。表示によって集計方法や対象範囲は異なるため、2か所の数値が一致しなくても、統計が誤っているとは限りません。まず現在の表示項目を読み、直前に行った操作と数値を照らし合わせてください。

アップロードとダウンロードで分かること

アップロードはデバイスから送信されるデータ、ダウンロードはデバイスが受信するデータです。ページを開く操作ではダウンロード量が多くなりがちですが、リクエストヘッダー、認証、応答、制御通信によってアップロードも発生します。ファイルを送信するとアップロード量が大きく増えることがあります。通信量は利用する機能によって異なるため、片方の増加が遅いだけで故障と判断しないでください。接続の維持、再試行、バックグラウンド動作によって、画面上でページを開いていなくても通信量が変化することがあります。観察する時間を短くすると、対象操作による増加を見分けやすくなります。

合計量と速度も分けて考える必要があります。累計量は選択した統計期間のデータ量を示し、瞬間または短期間の速度は一定時間内の通信の変化を示します。現在の接続を停止しても、過去に累積した合計量は自動で消えません。そのため、合計量が残っていることは、接続が現在も動作している証拠にはなりません。反対に、短時間速度が表示されないのは、リクエストがすでに完了したためかもしれません。一連の操作を観察するときは、特定の瞬間の数値だけでなく、操作の開始前と完了後の変化を記録します。

合計量から推測せず、増加分で確認

1. 現在のサーバー、Global Routing、構成を確認し、関係のない大容量通信は一時停止します。
2. 対象の統計項目の現在値を記録し、今回の観察範囲に含まれる項目かを確認します。
3. 再現可能な操作を1回だけ実行し、完了するか明確なエラーが出るまで待ちます。
4. Dataに戻って数値の変化を確認し、リクエストの記録と照らし合わせてポリシーを確認します。

特定のサーバーの統計が増えた場合、その項目に通信が計上されたことは分かりますが、すべてが直前に開いたページによるものとは限りません。バックグラウンド同期、通知、他のアプリの動作が同時に発生することがあります。増加が見られない場合も、リクエストがDIRECTに一致したか、古い接続を使用していないか、キャッシュから直接読み込んでいないか、表示対象が正しいかを確認してください。Dataは状況を観察する手がかりとして活用できます。どのルールに一致したかを確認するには、現在の構成や関連するリクエストの記録も参照してください。統計から直接分からないことまで判断させないようにしましょう。

サーバー別とアプリ別の表示を照合

サーバー別表示は、接続先を切り替えた後に新たな通信が発生したか、以前使っていた項目が引き続き通信していないか確認するのに適しています。アプリ別表示は、特定のアプリ操作に伴って通信量が増えたかを見るのに役立ちますが、表示方法はシステムやアプリから取得できる情報に左右されます。正確に関連付けられない通信を、無理に特定のアプリに割り当てないでください。2つの表示は問題の範囲を絞る助けになりますが、数値が厳密に一致する2つの明細として扱わないようにします。集計方法が異なるため、直接足したり引いたりしても意味がない場合があります。

Configでは、一部のリクエストがルールに従って直接接続され、別のリクエストはPROXYを使用するため、サーバーの通信量とデバイス全体の通信量は通常同じではありません。サービス提供元が表示する通信量にも、独自の計測方法、集計期間、通信処理のルールが適用されることがあります。アプリ、システム、サーバー側が同時に通信量を記録していても、開始・終了時刻、プロトコルのオーバーヘッド、集計対象の範囲によって数値が異なる場合があります。比較する前に期間と対象をそろえてください。一度の差だけを見て、接続情報に異常があると判断しないようにしましょう。

統計のリセットと継続的な観察

現在の画面に統計を消去する操作がある場合は、実行前に対象と範囲を確認します。ローカル統計を消去しても、サービス提供元の通信量がリセットされたり、サーバーが削除されたりするわけではありません。サブスクリプションの更新にもなりません。過去の結果との比較が必要な場合は、先に記録してから新しいテスト期間を始めます。長期的に観察する場合は、同じ種類の操作、似たネットワーク、同じルーティング方式など、条件を固定してください。条件が大きく異なる場合は、ひとまとめにして傾向を判断せず、分けて記録します。

統計と実際の使用感が一致しない場合は、前章の段階別の確認に戻ります。通信量が増えてもページが失敗する場合、認証後の接続先リクエスト、リソースのドメイン、応答内容に問題があるかもしれません。ページが正常に表示されても対象サーバーの統計が変わらない場合は、直接接続やキャッシュが使われている可能性があります。統計をすぐに消去したりサーバーを何度も切り替えたりするより、こうした可能性を残して確認するほうが有効です。表示の詳しい説明はData画面のサーバー別・アプリ別の数値の見方をご覧ください。実際の画面に表示されている項目名を基準に確認してください。

Settingsの主な項目：On Demand、DNS、診断機能の注意点

Settingsの項目は、すべてのスイッチを一度にオンにするのではなく、明確な目的に沿って調整します。システムによる接続開始に影響する設定、名前解決や記録に影響する設定、現在のConfigによって決まる動作があります。変更前に、現在のサーバーだけに影響するのか、構成だけに影響するのか、アプリ全体の動作に影響するのかを確認してください。画面の構成はアプリの更新で変わる場合があります。項目を探すときは、英語の項目名と実際の説明を基準にしてください。現在の画面にない設定を、別のデバイスのスクリーンショットを頼りに同じ場所で探さないようにしましょう。

On Demand：接続を開始する条件とルールによる振り分けの違い

On Demandは、設定した条件に基づいて接続を開始する機能です。接続をいつ要求するかを決めるものであり、特定のドメインにどのポリシーを適用するかを決めるものではありません。リクエストの振り分けは引き続きGlobal Routingと現在の構成で決まります。両者は併用できますが、互いの代わりにはなりません。有効にする前に、手動接続が安定していることを確認してください。解決していない問題を自動接続によって再現すると、原因を確認しにくくなります。自動動作が必要な場合は、どのネットワーク条件で接続し、どの条件では切断を維持するか明確にしてから、1つずつ設定してテストします。

On Demandをテストするときは、ネットワークが切り替わる一連の動作を確認します。切り替え前の接続状態を記録し、想定した条件を発生させてから、システムが接続を開始するか、実際のリクエストが成功するかを確認します。スイッチがオンになっているだけで、条件が正しく設定されたと判断しないでください。手動で切断した後に再接続されても、設定済みの条件が原因の場合があります。アプリが切断できないとは限りません。一時的に自動接続を止める場合は、On Demandの状態と条件を先に確認してから手動で切断し、後で必要に応じて元に戻します。

On Demand
Global Routing
Config
Connectivity Test

ここに示すのは確認する項目名であり、インポート用の構成ではありません。自動接続を調べる場合はOn Demandを確認します。リクエストの行き先を調べる場合はGlobal RoutingとConfigを確認し、実際の接続を調べる場合はConnectivity Testを実行してサービスへのリクエストを行います。項目ごとに変更を記録すると、ルール変更で自動再接続を解決しようとしたり、自動接続を無効にしてドメインのポリシーエラーを解決しようとしたりすることを避けられます。変更するたびに、何を確認するための操作なのか明確にしましょう。

DNS：名前解決の問題を見極めてから構成を変更

DNSは、ドメイン名を接続に必要なアドレス情報へ変換します。結果はアドレスを使うルールや接続処理に影響する場合があります。ほかのリクエストは正常なのにドメインへのアクセスが失敗するとき、名前解決は確認すべき要因の1つですが、原因はそれだけとは限りません。まず現在の構成で同じドメインを解決できるか確認し、接続エラーと合わせて次の手順を判断します。構成によってはすでに名前解決に関する設定が含まれている場合があります。複数の場所を同時に変更すると、設定の優先関係が分かりにくくなります。現在有効な構成を確認し、既存の設定を記録してから、1項目ずつ比較してください。

任意の名前解決サービスのアドレスを、どんな場合にも使える修正値として扱わないでください。名前解決の経路、サーバーへの到達性、暗号化方式、ルールを合わせて考える必要があります。あるネットワークで使える値が、すべてのネットワークに適するとは限りません。変更後はリクエストを改めて実行し、必要に応じて古い名前解決結果や接続の影響を除いてから、同じ接続先で比較します。改善しない場合は元の設定に戻し、試した値を重ねて追加せずに確認を続けてください。プライベートネットワーク内の名前解決では、ローカル環境に依存する場合もあるため、その要件を保ったまま調整しましょう。

記録、証明書、必要に応じて有効にする機能

診断記録は問題の調査に必要な場合に有効にし、十分な情報を取得したら、そのまま有効にしておく必要があるか確認します。詳細な記録には、アクセス先のドメイン、時刻、接続情報が含まれる場合があります。エクスポートや送信の前に、機密情報を削除してください。暗号化通信の処理方法を変える証明書関連機能については、信頼の範囲、対象、元に戻す方法を理解してから使用します。通常のサーバー接続やルールによる振り分けを始めるだけなら、「設定をそろえる」ために追加の証明書を先にインストールする必要はありません。明確なデバッグ上の必要がある場合に限って操作し、関連するアプリやサービスでその方法が許可されていることを確認してください。

UDPやIPv6などの動作を確認するときは、クライアント側だけを変更するのではなく、サーバーのプロトコルと現在のネットワークが対応しているかも確認します。特定の通信方式を必要とするサービスは、他の条件を変えずに対応状況をテストできます。サーバー側が対応していない機能を、任意のスイッチで補うことはできません。IPv6アドレスのルールには対応する種類を使い、実際の名前解決結果と合わせて確認してください。特定のネットワークでのみ問題が起きる場合は、まずネットワークの機能と経路の違いを比較してから、構成を変更するか判断します。

設定後はHomeに戻り、現在のサーバーが正しいか、Global Routingが想定どおりに戻っているか、目的の構成が選択されたままかを確認します。その後、通常のリクエストと特別な設定が必要なリクエストをそれぞれ1回テストします。機能の問題は解決しても、日常接続が一時的な設定で変わってしまう、といった状況を確認できます。安定した利用に必要なのは設定の数ではありません。有効にする項目それぞれに明確な用途、確認できる結果、既知の復元方法があることです。実際に必要のない項目は初期状態のままにできます。

日常のメンテナンス：更新、バックアップ、機種変更、再現可能なトラブルシューティング

安定して利用できるようになったら、「接続方法」だけでなく、「変更をどう追跡するか」も重要になります。アプリの更新、サブスクリプションの更新、構成の更新、サーバーの選択はそれぞれ別の操作です。アプリはApp Storeで更新します。サブスクリプションの更新ではサーバー情報を取得します。構成の更新ではルールや関連設定が変わります。サーバーの選択は現在使用する対象を変更します。いずれか1つの更新に成功しても、他の内容まで同期されたと考えないでください。問題が起きたら、最近どの層を変更したか確認すると、調査範囲を絞り込みやすくなります。

更新前に基準を記録し、更新後に対象を確認

サブスクリプションを更新する前に、現在のリンクの入手元と、利用可能な項目を確認します。必要なら使用中のサーバー名を控えておきます。更新後はリストに追加、削除、改名があったか、現在選択中の項目が想定した対象を指しているか確認してください。リストの変更で独自ポリシーへの参照が無効になった場合は、アプリのデータ全体を再インポートするのではなく、ルールやポリシーの関係を修正すればよいこともあります。サブスクリプションの認証、有効期限、取得内容に問題がある場合は、ご利用のサービス提供元に確認してください。このマニュアルでは、手元にある情報のインポートとメンテナンス方法を説明します。

構成を更新する前に、元に戻せるコピーを保管し、リモートの内容とローカルの変更を区別します。更新で上書きされる構成に独自ルールを追加した場合は、用途と場所を記録し、更新後も残っているか1つずつ確認してください。古い構成の内容をすべて確認せず新しいファイルに貼り付けると、現在は適さない設定まで戻してしまうことがあります。更新後はまず基本動作を確認し、必要に応じて少数のローカル例外を追加するほうが安全です。追加するたびに、固定した接続先で再テストしてください。

バックアップではファイルだけでなく、関連項目も記録

役立つバックアップ記録には、サーバーやサブスクリプションの入手元、現在の構成名、Global Routingの方式、必要なローカルルール、重要な設定を含めます。構成ファイルだけでは認証情報をすべて保存できない場合があります。サブスクリプションリンクだけでは、ローカルでの編集内容やシステムの権限状態を含まない場合があります。アプリに用意されているエクスポートやバックアップ機能を使う場合は、どの項目が実際に含まれるか確認してから、別途記録が必要か判断してください。バックアップファイルには機密情報が含まれる場合があるため、アクセス制限のある、自分で管理できる場所に保管します。

バックアップ後は、機種変更してからファイルがないと分かることのないよう、読み取れることを確認します。ファイルの存在、形式、必要な項目が含まれているかを確認してください。動作中の環境を上書きして検証する必要はありません。鍵、パスワード、完全なサブスクリプションリンクを公開メモやスクリーンショットに記録しないようにします。トラブルシューティングの記録では、完全な認証情報の代わりに情報の名前や保管場所を記載してください。機密リンクを公開してしまった場合は、情報提供元に変更または無効化の方法を確認し、ローカルの参照先も更新します。

機種変更時は入手、インポート、権限、確認を順にやり直す

新しいデバイスでは、まずApp StoreからShadowrocketを復元し、バックアップまたはデバイスの復元でどの情報が戻ったか確認します。サーバーリスト、構成ファイル、システムのVPN権限は、それぞれ個別に確認してください。以前のデバイスのシステム状態がそのまま移行されるとは限りません。情報をインポートしたら、手動接続と固定した接続先での確認を済ませてから、On Demandなどの自動動作を再設定します。iPhoneとiPadの違いを確認するときは、古いデバイスの画面上の位置を頼りに機械的に操作せず、現在の画面と選択中の項目を確認します。システム要件と購入範囲は、引き続きApp Storeのページに記載された内容をご確認ください。

新しいデバイスで動作確認が終わるまで古いデバイスを手元に残すと、パラメータの比較に役立ちます。ただし、両方の情報を誤って変更しないように注意してください。新しいデバイスで使えることを確認した後、古いデバイスの認証情報、サブスクリプション、バックアップファイルを必要に応じて整理します。一般的な不具合の最初の対処として、アプリを再インストールするのは避けてください。ローカル構成が消えたり、追加の権限設定が必要になったりする場合があります。環境を再構築する必要が明確で、情報を復元できると確認できた場合に限り、この操作を検討してください。購入の復元については購入済みアプリの復元の章をご確認ください。

最小限のトラブルシューティング記録を作成

長期的なメンテナンスでは、発生時刻、ネットワークの種類、対象リクエスト、サーバー、ルーティング方式、構成名、エラー表示の原文、最後に有効だった変更を簡潔に記録しておくと便利です。アクセス内容や認証情報を含める必要はありません。再現条件が分かれば十分です。問題が起きたら既知の基準を試してから最近の変更と比較し、一度に1項目だけ変更して、成功の基準を明確にします。テスト後は効果のなかった変更を元に戻してください。こうした記録は「いろいろ試した」という記憶より再利用しやすく、次に同じ問題が起きたときの作業を減らせます。

接続手順をすばやくやり直すにはクイックスタートガイドをご覧ください。個別の疑問を調べる場合はFAQへ、購入やアプリの情報を確認する場合はApp Storeダウンロードガイドに戻ってください。このページの章立てはメンテナンス用のチェックリストとしても使えます。まずアプリと情報の入手元を確認し、次に権限とインポート、続いてルーティングと接続確認、最後に統計と設定を確認します。各段階を明確に分けておけば、日常の設定変更も、リセットや推測に頼らず事実に基づいて進められます。