SHADOWROCKET / OFFICIAL MANUAL

Shadowrocketの使い方完全ガイド

正規購入、サブスクリプションの追加、ルール設定、日常のメンテナンス

このページでは、Shadowrocketの公式マニュアルとして、実際の利用段階に沿って操作方法、設定項目、トラブルの確認ポイントを解説します。初めて使う場合は、まずクイックスタートガイドを進めてから、該当する章で原因や注意点を確認してください。接続設定が済んでいる場合は、目次からData、Settings、メンテナンスの章に進めます。

主にiPhoneとiPadでの操作を解説
ご自身が用意したサブスクリプションまたはサーバー情報を使用
システム要件はApp Storeの掲載内容をご確認ください

01 / APP STORE

App Storeでの購入と正規品の確認

アプリを確認してから購入する

ShadowrocketはAppleプラットフォーム向けの有料アプリで、入手先はApp Storeのみです。購入前にApp Storeでの正規品確認ページを開き、アプリ名、デベロッパ、アプリIDを確認してからApp Storeで購入してください。検索結果の名前だけでアプリを判断しないでください。名前やアイコンが似ていても、製品ページの情報に代わるものではありません。購入条件は、App Storeに掲載されている説明、互換性、価格、購入確認画面で確認してください。

正規品の確認では、デベロッパがShadow Launch Technology Limitedであること、アプリIDが932747118であること、アイコンがこのサイトに掲載している公式アイコンと一致することの3点を確認します。製品ページのURL末尾にある id932747118 でアプリIDを確認できます。デベロッパ名はApp Storeの製品ページで確認し、検索結果の概要や別のページの説明で代用しないでください。確認後、現在サインインしている購入用アカウントと、支払い確認画面に表示される金額を確認しましょう。アプリの特定とアカウントの確認は、別々に行います。

買い切りで利用できる範囲を確認する

アプリの買い切り ≠ 接続サービスの利用契約。Shadowrocketを購入すると、アプリを利用する権利が得られます。接続には、ご自身が用意したサブスクリプションまたはサーバー情報が別途必要です。このマニュアルでは、情報の追加、設定、トラブルの確認方法を解説しますが、接続先やサブスクリプションの提供、販売、推奨は行いません。アプリは設定値を読み込み、接続を確立してルールに従って通信を振り分けます。リモートサーバーの稼働状況、利用権限、接続容量は別の条件です。アプリを購入しただけで、これらが利用可能になるわけではありません。

米国のApp Storeでは約2.99米ドルの買い切りです。実際の金額、通貨、購入条件はApp Storeの掲載内容をご確認ください。ストアの国や地域によって、表示価格や提供状況が異なる場合があります。支払い前に、ご利用のアカウントに表示される購入確認画面を確認してください。サブスクリプションの有効期限とアプリの購入は別のものです。前者はリモートアクセスの利用権限、後者はアプリの購入履歴に関係します。それぞれの記録を保管し、問題が起きた場合も個別に確認してください。

デバイスの互換性とApp Storeの国・地域を確認する

このマニュアルでは主にiPhoneとiPadでの操作を解説します。Mac、Apple TV、Apple Visionとの互換性も、同じApp Store製品ページの互換性欄で確認できます。システム要件と購入対象となる範囲は、App Storeの掲載内容をご確認ください。同じApple Accountを使っていても、すべてのデバイスとOSの組み合わせで利用できるとは限りません。デバイスを変更する場合は、移行先のデバイスで製品ページの互換性を確認し、購入履歴が現在の購入用アカウントにあることを確かめてください。

アプリが見つからない場合は、「検索結果が表示されない」のか、「製品ページに現在のストアでは利用できないと表示される」のかを確認します。アカウントのストア設定を確認し、正しい製品ページを開き直して、表示されたメッセージを記録してください。ネットワーク設定を何度も変更しても、ストアの国や地域に関する問題は解決しないことがあります。アカウントのストアの国・地域とデバイスの言語は別の設定です。表示言語を変更しても、購入に使うストアは変わりません。詳しくはApp Storeの国・地域とストアでの表示についてをご覧ください。

インストール後に確認すること

インストール後は、まずアプリが正常に起動することを確認してから、権限と接続を設定します。購入が完了しても、サブスクリプションが追加されたり、システム接続が確立されたりするわけではありません。これらは次の段階で個別に行います。アプリのアップデートはApp Storeで管理され、更新履歴もApp Storeで確認できます。初回から多くの設定を変更する必要はありません。まず初期状態を保ち、App Storeからの入手、アプリの起動、サーバー情報の追加、実際の接続を分けて確認してください。問題が起きたとき、どの段階に原因があるのか特定しやすくなります。

02 / PERMISSIONS

初回起動とシステム接続の権限

アプリのスイッチとシステムの許可を区別する

初回起動後は、Homeにサーバー情報が表示されているか確認します。リストが空でも、まだ情報を追加していないだけで、アプリの異常とは限りません。Shadowrocketがシステムレベルの接続を確立するには、システムのVPN構成機能を使用します。初めて接続を試みる際に、VPN構成の追加を確認する画面が表示されることがあります。この確認は、デバイス上にネットワーク接続を作成するための許可です。リモートサーバーへのログイン画面ではなく、利用可能なサーバーやサブスクリプションが提供されるわけでもありません。

システムの確認画面が表示されたら、対象が現在使用しているShadowrocketであることを確認し、デバイスの指示に従って許可または認証を完了してください。システムのパスコード、生体認証、サーバーのパスワードは、それぞれ用途が異なります。互いの入力欄に入力しないでください。以前に許可を拒否した場合は、アプリに戻って接続操作をやり直し、システムの確認が再度表示されるか確認します。既存の構成を確認するには、システム設定でVPN関連の項目を探してください。具体的な場所はシステム画面によって異なるため、デバイス上の表示に従ってください。

権限の問題は発生した場所から確認する

アプリのスイッチがすぐにオフに戻る場合は、システムの確認が未完了でないか、デバイス管理の制限がないか、別のVPN接続が確立中でないかを確認します。この現象だけでサブスクリプションの無効を判断しないでください。リモートサーバーへの接続がまだ始まっていない場合もあります。管理対象デバイスのネットワーク権限は、管理ポリシーで制限されていることがあります。制限がある場合は、まずデバイスのポリシーを確認してください。スイッチを連続してタップして無理に再試行するのではなく、接続要求をいったん終了し、システムの状態が安定してから表示内容を記録します。

システム構成がすでに存在するのにアプリが権限の問題を表示する場合は、まず接続を切断し、システム上の該当構成がShadowrocketに属しているか、別の構成を誤って選択していないか確認します。システム構成を変更または削除する前に、サーバー情報と設定資料を保存し、削除すると再度許可が必要になることを把握してください。アプリ全体の削除は、権限の問題を調べる最初の手段ではありません。アプリ内データとシステム構成は別々に管理されているため、安易に再インストールすると、単純な権限の問題がデータ復元の問題に変わるおそれがあります。

必要な機能に限って追加の権限を許可する

Scan QR Codeを使う際、カメラへのアクセスを求められることがあります。QRコードを読み取って情報を追加する場合にのみ、この権限が必要です。以前にカメラへのアクセスを拒否した場合は、何度もスキャンするのではなく、システムのアプリ権限設定を確認してください。写真ライブラリ内の画像を読み取る場合と、カメラを直接使う場合では、表示される許可の確認が異なることがあります。実際の操作に必要な権限を許可してください。QRコードには接続情報が含まれていることがあるため、入手元を確認してから追加し、トラブル確認のために元のQRコードを公開しないでください。

サブスクリプションのURLを貼り付ける際、クリップボードに関するメッセージが表示されることがあります。クリップボードの内容が追加する予定のものか確認し、チャットの文章、改行、余分な記号が混ざっていないか確かめてください。ローカルまたはクラウド上のファイルを読み込む場合は、システムのファイル選択画面で対象を選び、追加結果を確認します。権限を許可しても、ファイルの内容が正しいかどうかは検証されません。許可後も、サーバーの数や名前、重要な設定値が想定どおりか確認してください。

初回利用時に確認の基準を作る

初回の設定は、安定したローカルネットワークで行うのがおすすめです。複雑なOn Demand条件を同時に有効にしたり、DNSをまとめて変更したりするのは避けてください。まず識別できるサーバー情報を1件追加し、Global Routingを選択してから接続を試します。こうすると、「情報を追加できない」「システム接続を確立できない」「接続後にリクエストが失敗する」を分けて確認できます。デバイスにネットワークフィルタや別のVPN構成がある場合は、その状態も記録し、テスト中は今回確認する接続条件だけを有効にしてください。

権限の確認後は、特定のアイコンがシステムに表示されるかではなく、アプリの接続状態、システムのVPN状態、実際のリクエスト結果が一致しているかを確認します。状態の表示方法はデバイスによって異なります。ステータスバーに常時アイコンが表示されないことだけを、失敗の根拠にしないでください。この時点のネットワークの種類、選択中のサーバー、権限の状態を記録しておけば、次の章で情報を追加した後、変化が追加データによるものかシステム設定によるものか比較できます。

03 / SERVER & SUBSCRIBE

手元の情報の種類を確認する

情報を追加する前に、手元にあるものが個別のサーバー設定、共有URL、QRコード、複数のサーバー情報を取得できるサブスクリプションURLのどれかを確認します。見た目が似ていても、これらは互いに置き換えられません。サーバーアドレスは接続先を示し、サブスクリプションURLは複数のサーバー情報を取得するために使います。Configファイルにはルールやその他の設定が含まれる場合もあります。サブスクリプションURLをサーバーアドレス欄に入力しても、正しく動作しません。情報の用途が分からない場合は、各入力欄に試しに入力するのではなく、元の説明を確認してください。

Add Serverから手動で追加する場合は、手元の情報に合ったプロトコルを選び、対応する項目を入力します。アドレス欄には通常、ホスト名またはIPアドレスだけを入力し、ポート番号は別の欄に入力します。ウェブページのパスをアドレスに含めないでください。パスワード、UUID、暗号化方式などは、元の情報と一つずつ照合し、大文字と小文字、前後の空白、入力時の記号に注意します。用途を区別できる名前を付けてください。同じ名前の項目が複数あると選択を誤ることがあります。名前は識別用であり、誤った接続設定を修正するものではありません。

プロトコルごとに必要な設定値を確認する

プロトコルによって各項目の意味が異なります。同じポート番号や同じパスワードを、異なるプロトコルでそのまま使えるとは限りません。Shadowsocksでは暗号化方式とパスワードを一致させます。VMess、VLESSでは識別情報と通信方式をあわせて確認します。TrojanではパスワードとTLSの設定が関係します。HTTP、SOCKS5の認証情報は、手元の情報に従って入力し、別のプロトコルの項目の意味を当てはめないでください。WireGuardやHysteria2なども、完全な元の設定情報を基準にし、名前から初期値を推測しないでください。

確認項目	確認する内容	よくある入力ミス
アドレスとポート	ホスト名またはIPアドレス、ポートは別の欄に入力	ウェブページのパスを含める、全角記号を使う
認証情報	パスワード、UUID、プロトコルに応じた項目	文字の抜け、大文字・小文字の違い、末尾の空白
TLSと通信方式	有効・無効、名前、パスなど、元の情報にある設定	基本項目だけを追加し、通信条件を入れ忘れる
プロトコルのオプション	暗号化方式と、明示されているその他の設定	別のプロトコルの使い方に合わせて入力する

Subscribeの追加と結果の確認

既存のサブスクリプションを追加するには、追加画面でSubscribeを選択し、完全なサブスクリプションURLを入力して保存した後、更新を実行します。想定したサーバー情報が作成されたか確認してください。URLのクエリパラメーターはアクセス認証の一部であることが多く、削除、並べ替え、置き換えをしないでください。コピー時は末尾の文字が欠けていないか、チャットアプリによってURLが途中で切れていないか、前後に説明文が入っていないか確認します。追加できたら、まず項目を1つ選んでテストしてください。リストに表示されたことだけで、すべての項目が検証済みになるわけではありません。

サブスクリプションの更新に失敗したら、URLにアクセスできない、取得した内容を認識できない、リモート側の認証が無効になっている、のどれかを切り分けます。エラーメッセージを保存し、URL全体を確認して、現在のネットワークから内容を取得できるか比較してください。サブスクリプションの更新が一時的に失敗しても、既存のサーバーに接続できる場合があります。更新リクエストと、追加済みのサーバーへの接続は別の処理です。すぐにグループ全体を削除せず、使える項目を残して更新条件を確認してください。接続手段とトラブル確認の手がかりを同時に失わずに済みます。

QRコードの読み取り、更新、情報の保護

Scan QR Codeで追加した後も、プロトコル、アドレス、ポート、認証情報を確認してください。QRコードを読み取れたことは、テキストを取得できたことを示すだけで、内容が完全で有効であることを保証しません。サブスクリプションを更新すると、項目の名前、数、順番が変わることがあります。よく使うサーバーをリストの位置だけで覚えないでください。項目を手動で変更する場合は、次回の更新で上書きされるか確認します。必要に応じて独立したコピーを保存し、分かりやすい名前を付けてください。一時的な変更を、サブスクリプション元の設定が恒久的に変わったものと誤解しないようにします。

サブスクリプションURL、共有URL、QRコードにはアクセス権限に関する情報が含まれることがあるため、認証情報として扱ってください。トラブルを相談する際は、プロトコル、エラーの種類、発生した段階を説明し、パスワード、UUID、サブスクリプションのクエリパラメーター全体は公開しないでください。追加後の最低限の確認項目は、リストの情報元が分かること、重要な設定値が元の情報と一致すること、対象を1つ以上選択していることです。続いてGlobal Routingを設定します。一連の操作を通して確認したい場合は、クイックスタートのSubscribe追加手順をご覧ください。

04 / GLOBAL ROUTING

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

モードを決めてから、ルールの適用結果を確認する

Global Routingは、リクエストをどのように処理するかを決めます。モードはConfig、Proxy、Directの3つで、それぞれ設定に従った処理、プロキシ経由、直接接続を意味します。Configでは現在の設定ファイルのルールに従って処理方法が選ばれます。Proxyでは対象となるリクエストを現在選択中のサーバーに送ります。Directでは直接接続します。3つはリクエストの処理方法であり、サーバーの種類やリモートアカウントを変更するものではありません。トラブル確認では、まず現在のモードを記録してください。モードが異なると、同じルールでも適用されていないように見えることがあります。

モード	主な判定基準	確認できること
Config	現在有効なConfigのルールとポリシー	対象に想定したルールが適用されているか
Proxy	現在選択中のサーバー	サーバーがテストリクエストを処理できるか
Direct	ローカルネットワークから直接接続できる条件	直接アクセスが正常に行えるか

日常的にConfigを使う場合、Configリストにファイルがあるかだけでなく、どのファイルが現在有効か確認してください。ファイルの保存、編集、有効化はそれぞれ別の操作です。ルールを変更したら、アプリの手順に従って保存・適用し、新しいリクエストを送信して確認します。すでに確立された接続には、以前の状態が残ることがあります。Proxyは一部のルールに関する問題を切り分けるのに役立ちますが、テスト後は必要なモードに戻し、一時的な状態を長期間そのままにしないでください。

ルールは上から順に判定し、最後のルールが該当なしの場合に適用される

通常のルールは設定ファイルの順に判定されます。具体的な対象のルールを、より広範なルールより前に配置してください。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはドメインの末尾とそのサブドメイン、DOMAIN-KEYWORDはドメインに含まれるキーワードを照合します。IP-CIDRとIP-CIDR6はアドレス範囲を対象とし、GEOIPはIPの地理情報によって判定します。ルールの種類は照合する対象を決め、ポリシーは一致した後の処理方法を決めます。ポリシー名と照合条件を混同しないでください。

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

上の例はルールの順序を説明するためのもので、すべてのネットワークに適した完全な設定ではありません。api.example.comへのアクセスは最初のルールに一致するため、後続のドメインサフィックスルールでは判定されません。example.comに属するその他の対象は、2つ目のルールで処理される場合があります。最後のFINALは、それ以前のルールに一致しない場合に適用するポリシーを示し、末尾に置きます。例のドメインは説明用です。実際に設定する前に対象を確認し、そのまま実用ルールとして使わないでください。

ポリシー、名前解決、ルールの適用範囲を理解する

PROXY、DIRECT、REJECTは一般的な処理ポリシーです。Configで定義済みのポリシーグループをルールから参照する場合もあります。参照名は実際の定義と一致させてください。存在しない名前を書いても、ポリシーグループが自動作成されるわけではありません。対象を拒否する場合は、まず照合範囲を限定し、その対象がログイン、認証、その他のリソースにも使われていないか確認します。範囲の広いルールで通常の機能に影響が出ないよう注意してください。トラブル確認では、キーワードや広いアドレス範囲に拡大する前に、具体的なドメインで試します。

ドメインルールとアドレスルールでは、判定に必要な情報が異なります。リクエストにドメイン名が含まれていればドメインで判定できますが、アドレス情報だけの場合はアドレスに関する判定が使われることがあります。ルールによっては追加の名前解決が関係します。DNSの応答、キャッシュ、リクエストの種類によって観察結果が変わるため、対象名だけから必ずどのルールに一致するか判断することはできません。USER-AGENTなどの条件にも適用範囲があります。暗号化されたリクエストすべてで、同じアプリケーション層の情報を取得できるとは限りません。

Configが複雑になるほど、復元できる基本ファイルを残しておくことが重要です。ルールは一度に1グループずつ追加し、想定する対象と実際に選ばれたポリシーを記録してから次に進みます。異常が起きたら、ファイルが有効か、ルールの順序が正しいか、ポリシー名が有効かを先に確認し、変更範囲を広げるのは最後にします。大量のルールを追加するより、1つのリクエストが特定のルールに一致した理由を説明できるほうが、管理に役立ちます。

05 / CONNECT & VERIFY

接続の確立と段階別の確認

再現可能なテストを行う

接続前に、選択するサーバー、Global Routingのモード、現在のローカルネットワークの3つを固定します。サーバー情報が有効なものか確認し、モードを決めてから接続スイッチをオンにし、未完了のシステム権限の確認に対応します。テスト中にサーバーの切り替え、サブスクリプションの更新、DNSの変更を同時に行わないでください。接続が回復しても、どの操作が影響したのか判断できなくなります。少数の再現可能なリクエストで基準を作ると、その後の比較に役立ちます。

接続を検証するには、少なくとも3段階を確認します。システム接続が確立されたか、対象へのリクエストが完了するか、実際の処理ポリシーが想定どおりかです。システムで接続済みと表示されても、ローカルの通信経路が動作していることを示すだけで、リモートサーバーの認証や対象へのアクセスが正常とは限りません。ウェブページが表示されても、選択中のサーバーを経由したとは限りません。ConfigではDIRECTに一致する場合があります。「アクセスできたか」と「どのポリシーで処理されたか」の両方を記録し、成功・失敗だけで結論づけないでください。

Connectivity Testの結果を活用する

Connectivity Testはサーバー項目の基本的な接続状態を比較するのに役立ちます。まず、選択したテスト方法を確認してください。方法によっては、接続の確立、特定の対象からの応答、一部のプロトコル処理だけを確認します。結果を日常利用時のダウンロード速度と同一視しないでください。テストがタイムアウトしても、テスト対象、一時的なネットワーク変化、サーバー側のテスト方法への対応が影響している可能性があります。同じネットワークと条件で少数回テストし、実際のリクエスト結果とあわせて判断してください。

遅延が小さくても転送速度が高いとは限らず、接続を確立できても、すべてのリクエストが正常とは限りません。基本テストが正常で特定のページだけ失敗する場合は、サーバー全体をすぐに否定せず、対象ドメイン、ルール、DNS、関連リソースを確認してください。反対に、複数の独立した対象で失敗し、Proxyでもリクエストを完了できない場合は、アドレス、ポート、認証情報、リモート側の状態を優先して確認します。テストツールは手がかりを示すものであり、失敗した段階の切り分けに代わるものではありません。

失敗の状況に応じて次の確認を選ぶ

状況	まず確認すること	次に行う確認
スイッチがすぐにオフに戻る	システム権限と構成の状態	システムのメッセージを記録し、許可が完了しているか確認
接続済みだが複数の対象にアクセスできない	サーバーの設定値と現在のモード	ネットワークを固定し、Proxyで比較
一部の対象だけ失敗する	ルールの適用結果とDNSの応答	新しいリクエストを作成し、対象を個別に確認
ネットワークを切り替えた後に失敗する	新しいネットワークの条件とOn Demand	サーバーを変えずに2種類のネットワークで比較

インターネットに接続できない場合は、まず切断した状態でローカルネットワークから通常のリクエストを完了できるか確認し、同じサーバーに再接続して比較します。ローカルネットワークでウェブ認証が必要な場合は、先に認証を完了してください。ProxyとConfigを比較する際は、モードだけを変更します。Proxyで正常、Configで異常なら、ルール、ポリシーの参照、有効なConfigを優先して確認します。どちらも異常なら、サーバーと接続条件を確認してください。この比較ですべての原因が分かるわけではありませんが、確認範囲を大きく絞れます。

「速度が遅い」と「接続できない」を分けて考える

速度の問題は、接続が利用可能な状態で調べます。測定する内容と時間帯を固定し、リモートサーバー、ローカルネットワーク、通信条件、接続先サービスの制限を切り分けてください。大容量ファイルの転送と短いウェブリクエストでは、注目すべき指標が異なります。短いリクエストの応答時間から、継続的な転送性能を推測しないでください。比較中は、ほかのデバイスやアプリによる通信をできるだけ避けます。測定中にプロトコルの設定を何度も変更すると、比較できなくなります。

確認が終わったら、使用したサーバー、モード、Config名、ネットワークの種類を記録し、日常の設定に戻してから、もう一度リクエストを送信します。詳しく調べる場合は、接続済みなのにインターネットを利用できないときの確認項目をご覧ください。速度が継続的に不足する場合は、サーバー、接続経路、プロトコル、ローカルネットワークを段階別に確認する方法を参考にしてください。記録には現象と条件を残し、アクセス認証情報全体は含めないでください。

06 / DATA

Dataで通信量とリクエスト記録を確認する

集計範囲と期間を確認する

Dataでは、アプリが把握できる通信量や接続情報を確認できます。数値を見る前に、現在の画面が今回の接続、特定の期間、累計のどれを表示しているか、リセット操作が行われていないか確認してください。集計方法が異なる数値は、そのまま差し引いて比較できません。再接続後の変化も、過去の記録がすべて消去されたことを意味するとは限りません。画面に表示される項目はアプリの実際の表示を基準にしてください。別のデバイスのスクリーンショットから、自分のデバイスにも同じ統計表示や記録の保存方法があると推測しないでください。

上りと下りは通信の方向を示すもので、ファイルのアップロードとダウンロードの操作を表すわけではありません。ウェブページを開く際にもリクエストが送信され、ファイルを送信する際にも確認や応答を受信します。プロトコルのオーバーヘッド、再送、接続維持、名前解決によって通信が発生するため、画面上の通信量とファイルサイズは一致しないことがあります。操作による変化をおおよそ確認するには、ほかの通信が少ないときに前後の数値を記録してください。ただし、結果は概算であり、リモート側の正確な課金記録ではありません。

アプリの統計はリモートアカウントの記録とは異なる

Shadowrocketの統計は、クライアントから確認できる通信状況を示します。リモートのサブスクリプションで使われる通信量や残量は、異なる方法で集計される場合があります。デバイスから別の直接接続がある場合、複数のデバイスで同じリモートアカウントを利用している場合、または集計期間が違う場合は、両者の数値を単純に比較できません。サブスクリプションに表示される残量はリモート側の情報を基にしていることがあり、更新頻度もアプリのリアルタイム集計とは異なります。差がある場合は、異常と判断する前に期間と対象デバイスを比較してください。

特定のアプリが想定したポリシーで通信しているか調べるには、総通信量の増加だけでなく、リクエストの対象とルールの適用情報を確認します。総量の変化から分かるのは通信が発生したことだけで、特定の操作が原因とは限りません。システムのバックグラウンド同期、ページの先読み、ほかのアプリの更新が同時に行われることもあります。影響を減らすには、不要な操作をいったん止め、短く明確な操作を行って時刻を記録し、その前後のリクエストとポリシーを確認してください。

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

現在の画面で接続やリクエストの詳細を確認できる場合は、対象のドメイン名またはアドレス、適用されたポリシー、関連するサーバー、エラーが発生した段階に注目します。ドメイン名とアドレスは異なる種類の情報です。前者はドメインルール、後者はアドレス範囲や名前解決の結果を確認するのに役立ちます。1つのページが複数の対象にアクセスすることがあるため、本文が表示されても、画像、ログイン認証、その他のリソースが同じ経路を使ったとは限りません。一部だけ表示されない場合は、ページのメインドメインだけでなく、失敗したリソースを特定してください。

ルールを変更したら、新しいリクエストを作成して結果を確認してください。ブラウザーの既存接続、アプリのキャッシュ、DNSキャッシュによって古い状態が残り、新しいルールが適用されていないように見えることがあります。現在のテストを終了し、必要に応じて該当するリクエストを再実行して、新しい記録を確認します。記録を消去する前に、重要なエラーの段階と時刻を保存してください。先に消去してから再試行し、一時的に問題が解消すると、原因を説明する唯一の手がかりを失うことがあります。

通信量の増加とバックグラウンド動作を調べる

バックグラウンドの通信量が増え続けている場合は、接続時間、デバイスの同期タスク、On Demandの条件を確認してください。接続が維持されていると定期的な通信が発生することがありますが、総量の増加だけで設定の問題と判断することはできません。再現しやすい短い期間を決め、画面の使用状況、バックグラウンド同期、ネットワーク切り替えと通信量の変化を比較します。通信量だけでバッテリー消費を説明することもできません。接続の再開、無線ネットワークの状態、デバイス上のタスクも関係するため、分けて記録してください。

問題をほかの人に説明する場合は、整理した時刻、対象の種類、ポリシー、エラーメッセージを優先して共有してください。リクエスト記録には、閲覧状況、完全なURL、クエリパラメーター、認証情報が含まれることがあります。共有前に不要な内容を削除してください。すべての記録やサブスクリプション情報を一括で送らないでください。診断後は詳細記録の設定を日常利用に必要な範囲に戻します。後から確認しやすくなり、不要な情報の蓄積も抑えられます。

07 / SETTINGS

Settings、DNS、On Demandの設定

設定が作用する範囲を確認する

Settingsの項目がすべて同じ範囲に作用するわけではありません。アプリの動作に関するもの、現在の接続に関するもの、Configファイルや個別のサーバー情報で決まるものがあります。変更前に対象を確認し、元の値を記録してください。Configに関連する設定がある場合、画面上の別の設定が必ず上書きすると決めつけないでください。現在の項目の説明を確認し、実際のリクエストで検証します。多くの便利そうな項目を一度に有効にするより、正常に動作する基準を保つことが大切です。

設定は3つのグループに分けて確認するのがおすすめです。まず接続に必要な項目、次にオンデマンド接続と名前解決、最後に特定のネットワークで使う高度な設定を扱います。関連する設定を1グループずつ変更し、保存後に同じ対象をテストしてください。結果が悪化した場合は、別の変更を加えて補うのではなく、そのグループを元の値に戻します。役割を理解していないスイッチは推測で変更せず、現在使えている設定を保つほうが管理しやすくなります。

DNSは名前解決に関係し、接続認証の代わりにはならない

DNSは、ドメイン名をリクエストに必要なアドレスへ変換します。名前解決に失敗する、想定外のアドレスが返される、名前解決自体にアクセスできないといった問題で、ウェブページが開けないことがあります。ただし、サーバーのパスワードが誤っている場合とは発生段階が異なります。原因を調べる際は、名前解決の前後どちらで失敗しているかを確認してから、変更する設定を決めてください。特定のIPアドレスに接続できても、そのサービスのすべてのドメインリクエストが正常とは限りません。多くのサービスはドメイン名、証明書、複数のリソース用ドメインを必要とするため、アドレスへの直接アクセスだけで一連の動作を検証することはできません。

DNSを選択または変更する際は、現在の接続条件で名前解決サービスに到達できるか、設定がどのように名前解決リクエストを処理するかをあわせて確認します。アドレスだけを変更して経路を確認しないことや、情報元が不明なアドレスを次々に追加することは避けてください。ドメイン名、応答、時刻を記録し、ほかの条件は変えずにテストします。暗号化された名前解決を有効にしても、すべてのリクエストが同じ出口を使うとは限りません。名前解決の経路と実際の通信に適用されるポリシーを個別に検証してください。1つの設定だけで接続経路全体を判断することはできません。

On Demandは条件に応じて接続する

On Demandは、設定した条件に基づいて接続を開始または維持する機能であり、リモートサーバーの問題を自動修復するものではありません。設定前に、どのネットワークで接続するか、離れた後も接続を維持するか、どの状況でローカルネットワークを直接使うかを明確にしてください。利用できる条件はアプリの現在の画面を基準にします。条件の順序と適用範囲を一つずつ確認してください。ネットワーク名が似ていても同じ条件とは限りません。保存後は実際にネットワークを切り替えて動作を検証します。

スイッチをオフにした後、再び自動接続される場合は、手動スイッチの故障と判断する前にOn Demandが有効か確認します。オンデマンドルールは、新しいネットワークリクエストやネットワークの変更をきっかけに接続を開始することがあります。トラブル確認中は、該当する条件を一時的に無効にし、手動接続を確認してから一つずつ戻してください。ウェブ認証が必要なネットワークでは、まずローカルの認証を完了します。その後、最初の接続を妨げないよう、On Demandの条件が適切か確認してください。

接続方式の選択と高度な設定

オンデマンド接続と常時接続では、使い勝手、バックグラウンドの動作、ネットワーク切り替え後の復帰にそれぞれ違いがあります。すべてのデバイスに合う設定が一つに決まっているわけではありません。条件の対象となるネットワークに頻繁に出入りすると、接続確立の処理が増えることがあります。バッテリー消費を比較する際は、同程度の使用時間とネットワーク環境をそろえ、1回のシステム表示だけで判断しないでください。詳しい比較方法は、On Demandの設定とバックグラウンドでのバッテリー消費をご覧いただき、実際の使い方に合わせて選択してください。

IPv6、UDP、接続タイムアウトなどの設定を変更する前に、症状がその項目と関係していることを確認してください。特定のリクエストが失敗しただけでは、機能を全体的に無効にする根拠にはなりません。変更範囲が広いほど、正常だったリクエストに影響する可能性があります。まず影響の小さい範囲でテストし、変更前後の結果を保存してください。設定後は再接続とネットワーク切り替えをそれぞれ一度確認し、終了していない接続で一時的に正常に見えただけではないことを確かめます。

08 / MAINTENANCE

日常のメンテナンス、機種変更、トラブル記録

アプリ、サブスクリプション、Configを分けて管理する

日常のメンテナンスでは、アプリのアップデート、サブスクリプションの更新、Configファイルの変更を分けて扱います。アプリのアップデートはApp Storeから行います。サブスクリプションの更新では、ご自身が用意したURLからサーバー情報を取得します。Configの変更ではルールや関連する動作が変わります。3つの変更は互いに影響する場合がありますが、同じ操作ではありません。原因を特定しやすくするため、1回のテスト前にすべてを更新しないようにしてください。現在の接続状態を確認して記録し、段階ごとに操作して、その都度簡単な確認を行います。

サブスクリプションを更新した後は、項目数、よく使うサーバーが残っているか、現在選択中の項目が変わっていないかを確認します。名前が同じだからといって設定値も変わっていないとは限りません。リストの順序が変わっただけで、項目がなくなったと判断しないでください。サブスクリプションで管理されている項目を手動で変更すると、次回の更新で上書きされることがあります。一時的なテスト用の項目と、日常的に使う項目を分けてください。重複している情報や、不要であると確認済みの情報は定期的に整理します。ただし、問題の原因を特定する前にまとめて削除するのは避けてください。

復元できるConfigと情報を保管する

Configを変更する前に、動作するコピーを保存してください。名前に用途を記せば十分で、「最終」といった判別しにくい言葉を重ねる必要はありません。バックアップではルールのテキストだけでなく、サーバー情報に由来する設定値と、サブスクリプションの更新で取得する情報を区別します。パスワード、UUID、サブスクリプションURL全体を含む情報は、保護された場所に保管し、公開されるメモに含めないでください。復元する際は設定の適用範囲を確認し、あるデバイスの設定をすべて無条件に別のデバイスへ適用しないでください。

機種変更の前に、アプリ購入用アカウント、既存のサーバー情報、Configファイルをそれぞれ再取得できるか確認してください。App Storeでの購入を復元することと、アプリ内の情報を復元することは別の操作です。前者ではアプリを再入手できるかを確認し、後者では以前の接続条件を取り戻せるか確認します。購入時と同じアカウントでApp Storeの購入済み項目を開き、Shadowrocketを探してください。システム要件と購入対象の範囲は、App Storeの掲載内容をご確認ください。手順は購入済みアプリの復元方法をご覧ください。

再インストールの前に最低限のトラブル記録を残す

問題が起きたら、発生時刻、デバイスのネットワークの種類、Global Routingのモード、Config名、サーバーのプロトコル、エラーが発生した段階を記録します。サブスクリプションを更新できないのか、システム接続を確立できないのか、接続後に特定の対象へのリクエストが失敗するのかを明確にしてください。再現可能な操作を1つに絞って比較するほうが、「すべてリセットして確認する」より原因を特定しやすくなります。サーバーの識別には任意の名前を使い、実際のアドレスや認証情報を公開しないでください。

再インストールは通常、最初に行う手段ではありません。アプリを削除すると、ローカルの情報、記録、保存済みのトラブル確認の手がかりが使えなくなることがあります。一方で、リモート認証のエラー、ネットワーク条件、ルールの問題は解決しない可能性があります。まず直前に使えていたConfigに戻し、一時的に追加した条件を無効にして、接続の章に沿って順番に確認してください。再インストールが必要な場合は、必要な情報をすべて再取得できると確認してから実行します。App Storeで再入手できることと、アプリ内の設定がバックアップされていることは別です。

繰り返し使えるメンテナンス手順を作る

メンテナンスは、基準状態の確認、情報の保存、変更を1つ実施、代表的な対象をテスト、適用されたポリシーを確認、結果を記録、の順に進められます。代表的な対象は、実際に必要なアクセスの種類をカバーするものを選び、関係のないページを大量に開かないでください。正常に動作した条件も簡潔に記録しておくと、次回のトラブル時に前回成功した設定を確認できます。テストでProxyに一時変更した場合は、終了後に日常のモードへ戻し、On Demandの条件も元の予定どおりか確認してください。

トラブル情報を共有する前に、スクリーンショット、ログ、コピーしたテキストに機密情報が含まれていないか確認してください。特にサブスクリプションのクエリパラメーター、認証情報、アクセス記録に注意します。通常、相手に必要なのはエラーが起きた段階と再現条件であり、アカウント情報全体ではありません。機種変更後に購入履歴が見つからない場合は、機種変更・再インストール後に購入済みアプリを復元する方法をご覧ください。初めて設定し直す場合はクイックスタートガイドに戻り、基本手順に沿って接続を確立してから、個別の設定を一つずつ復元してください。