Shadowrocketの使い方完全ガイド：購入・サブスクリプション・ルール設定・メンテナンス

01 / APP STORE

正規購入と購入履歴

まずアプリが正規の製品か確認してから購入します。ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。当サイトのアプリの入手方法では、App Storeへのリンク、正規版の確認方法、購入済みアプリの復元についてまとめています。この章では、設定を追加する前に確認すべき理由を説明します。アプリの購入とサーバーの準備は別のものです。App Storeでの購入が完了しても、接続可能なサーバーが用意されたことにはなりません。

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

App Storeで検索するときは、「Shadowrocket」という名称だけで判断しないでください。製品ページを開き、アプリ名がShadowrocket、デベロッパがShadow Launch Technology Limitedであること、製品リンクのアプリIDが932747118であることを確認します。アイコンは当サイトのヘッダーに表示されている公式アイコンと照合してください。検索結果に似た名前が並ぶ場合は、名前、アイコン、デベロッパをすべて確認し、検索結果の一覧だけで判断せず、製品ページの詳細を読んでから購入します。

アプリIDは同一製品を見分ける重要な手掛かりです。製品ページのURL末尾にあるid932747118が、本マニュアルで説明するアプリに対応します。App Storeの説明、互換性、購入表示、アップデート履歴は、現在の製品ページを確認してください。アプリの表示やシステム設定は実際のデバイスの状態によって異なるため、固定のバージョン番号で代用することはできません。デベロッパ名またはアプリIDが一致しない場合は、アプリの入手方法に戻り、リンクを再確認してください。

買い切り購入の対象範囲

Shadowrocketは買い切り方式です。価格、通貨、購入対象となる条件はApp Storeの製品ページをご確認ください。特に、クライアントの買い切り購入とサーバーの利用プランは別です。アプリはサーバー情報を読み込み、接続を確立してルールに基づく振り分けを行います。サーバーアドレス、認証情報、サブスクリプションリンクは利用中のサービス提供元から入手してください。アプリの購入履歴からサブスクリプションの有効性は判断できません。また、サブスクリプションが無効になっても、クライアントを再購入する必要があるとは限りません。

購入前に、App Storeで使用しているアカウントを確認してください。再インストールや機種変更の際は、アプリを探すときに元の購入アカウントの履歴を確認します。システムのほかの機能で使うアカウントと、App Storeで購入に使うアカウントは異なる場合があります。デバイス設定の画面上部に表示される名前だけで、購入アカウントを判断しないでください。App Storeのボタン表示が想定と異なる場合は、購入履歴とアカウントを先に確認し、復元を試すために何度も購入操作を行わないでください。

デバイスの互換性と復元時の注意

本マニュアルでは主にiPhoneとiPadでの操作を説明します。Mac、Apple TV、Apple Visionの互換性も同じApp Store製品ページで確認できます。システム要件と購入対象となる条件は、App Storeの製品ページに記載された内容をご確認ください。あるデバイスで入手できるからといって、別のデバイスでも必ず要件を満たすとは限りません。機種変更の際は、移行先のデバイスの互換性、App Storeのアカウント、元の購入履歴が確認できることをそれぞれ確かめてください。

アプリの復元と設定の復元は別々に考える必要があります。アプリを再入手しても、サーバー、サブスクリプション、ルールファイルが自動的に戻るとは限りません。アンインストール前に必要な設定を記録し、構成ファイルを適切に保管してください。再度アプリを開いたら、HomeとConfigで実際の内容を確認します。ファミリー共有が利用できるか、現在のストアで製品を入手できるか、ストアが求める確認手順は、製品ページとシステムの案内に従ってください。一度復元できたことを、すべてのアカウントやデバイスで共通する条件とみなさないでください。

この章を読み終えたら、次の3点を確認できる状態を目指します。アプリの情報が一致しているか、購入履歴がどのストアアカウントに紐づいているか、自分のサーバー情報をどこに保存したか。確認できない項目があれば、サブスクリプションを追加する前に解決してください。App Storeの表示や再インストールについては購入済みアプリの復元方法を、検索結果の見分け方については正規版を見分ける3つのポイントをご覧ください。

02 / FIRST LAUNCH

初回起動とシステム権限

初めて開いたときは、すべての設定をすぐに変更せず、まず各画面の役割を把握します。Homeではサーバーの確認と接続、Configではルール設定の管理、Dataでは通信状況の確認、Settingsではクライアントの各種設定を行います。デバイスや表示言語、アプリの状態によって項目の配置は変わることがあります。本マニュアルでは機能を探しやすいよう英語の名称を使い、ボタンの位置だけを目印にしません。操作を始める前に、現在どの画面を開いているか確認してください。

VPN構成の追加許可について

初めて接続を開始するとき、システムからVPN構成の追加を求められることがあります。これはクライアントがシステムのネットワーク接続機能を使うための許可であり、サブスクリプションの追加が成功したことを示すものではありません。自分で接続スイッチを操作した後にシステムのダイアログを読み、要求元がShadowrocketであることを確認してから、案内に沿って認証してください。許可を取り消すと、アプリに戻ったとき接続状態を維持できない場合があります。その場合は、サーバーのパスワードを変更したり同じサブスクリプションを再登録したりする前に、許可が完了しているか確認してください。

システムに保存されるVPN構成と、Homeのサーバー一覧は別の階層にあります。前者はシステムが接続機能を呼び出すためのもので、後者には接続先とプロトコルのパラメータが保存されます。システムのVPN構成を削除してもサーバーは削除されません。また、サーバーを削除してもシステムに保存された構成が消えるとは限りません。問題を調べる前に、どちらを操作するのか明確にしましょう。「再認証」のつもりで誤って「サーバーをすべて削除」すると、問題の範囲が広がります。

カメラ、クリップボード、ローカルデータの利用条件

Scan QR CodeでQRコードを読み取るとき、システムからカメラの使用許可を求められることがあります。この許可が必要なのは、カメラでスキャンする場合のみです。許可しなかった場合は、システム設定でShadowrocketのカメラ権限を確認するか、必要なテキスト情報が手元にあれば手動で追加できます。まだ接続を試していない段階なので、カメラ権限の問題をサーバー障害と混同しないでください。QRコードには認証情報が含まれている場合があります。読み取る前に提供元を確認し、読み取り後も追加された種類とアドレスを確認してください。

クリップボードから設定を読み込むときは、コピーした内容が完全なリンクまたは設定テキストであり、ウェブページのタイトル、説明文、途中で切れたアドレスではないことを確認してください。貼り付けの確認が表示されるかどうかは、操作やシステムの動作によって異なります。表示された場合は案内に従ってください。想定した項目が追加されない場合は、元の情報の形式を確認します。追加ボタンを何度も押した後、成功したと決めつけないでください。HomeまたはConfigに新しい内容が実際に表示されることを確認します。

初回利用では確認可能な基準を作る

初回の設定では、明確なテスト対象を一つ決めておくと便利です。有効性を確認できるサーバー情報を一つ追加し、現在のGlobal Routingの選択を記録してからスイッチを入れます。この段階ではDNS、On Demand、複雑なルールを同時に変更しないでください。接続に失敗しても、認証、サーバーパラメータ、基本ネットワークのいずれに問題があるか切り分けやすくなります。検証していない設定を複数組み合わせて影響し合うのを避けるため、変更は一度に一項目ずつ行います。

デバイスにほかのVPN構成がある場合は、接続前にシステムでどの構成が有効か確認し、複数の接続設定が影響し合わないようにします。システム設定の接続状態とアプリのスイッチを合わせて確認してください。ステータスバーにアイコンが表示されているだけでは、目的のWebサイトに想定どおりのルールで接続できているとは限りません。また、システムとアプリの間でスイッチをすばやく何度も切り替えると、接続・切断処理と画面更新が重なり、どの操作が結果に影響したか判断しにくくなります。

初回認証が完了したらHomeに戻り、サーバーが残っていることと選択項目が正しいことを確認してから次の章に進みます。スイッチがすぐに戻る場合は、権限の確認画面が表示されたか、システム構成がすでに存在するか、具体的なエラーが出たかを記録してください。「まったく使えない」とまとめるより、実際に起きたことを残すほうが役立ちます。初回の操作をすぐに進めたい場合は使い方ガイドを、権限やシステム状態に関するよくある質問はFAQをご覧ください。この章の目標は、許可の目的を理解することであり、スイッチがオンになることだけではありません。

03 / SERVER & SUBSCRIBE

サーバーの追加とサブスクリプションの登録

追加する前に、手元の情報の種類を確認します。単一サーバーの完全なパラメータ、サーバー1件分の共有リンク、サブスクリプションリンク、ルール設定ファイルのいずれでしょうか。同じテキスト形式に見えても、それぞれ別の項目に入力する必要があります。サーバー情報は接続先を示し、サブスクリプションはサーバー項目を一括取得・更新するためのもの、ルール設定ファイルはリクエストの振り分け方法を定義するものです。本マニュアルでは、自分で用意したサブスクリプションまたはサーバー情報があることを前提としています。情報は利用中のサービス提供元から入手してください。

手動追加では各項目を正しく入力

Homeから追加メニューを開き、Add Serverに進んでTypeを選択し、選んだプロトコルに必要な項目を入力します。種類を間違えると、アドレスやパスワードが正しく見えても想定どおりに接続できません。アドレス欄にはサーバーアドレスのみを入力し、ポートには提供された値を入力します。パスワード、ユーザーID、暗号化方式、通信方式、TLSパラメータは、元の情報に合わせて入力してください。備考は項目を見分けるために使うもので、サーバーアドレスの代わりにはなりません。

Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では必要な項目が異なり、すべてのプロトコルに共通するパラメータの組み合わせはありません。見慣れない項目がある場合は、別のサーバー情報をそのまま流用せず、情報の提供元に確認してください。特に、接続先アドレス、TLSで使用するサーバー名、通信層のHostは区別が必要です。値が異なることもあり、それぞれ役割が異なるため、「同じにする」という理由だけで一つの値に統一しないでください。

パラメータの種類	確認項目	よくある間違い
Type	元のプロトコルと一致しているか	名称や見た目から種類を推測する
アドレスとポート	提供された値を一文字ずつ確認	WebページのURL全体をアドレス欄に入力する
認証情報	パスワードまたはユーザーIDがすべて含まれているか	コピー時に空白が入る、または末尾が欠ける
TLSと通信方式	元のパラメータに従って個別に入力	Hostとサーバー名を同じ項目として扱う

サブスクリプションの追加と更新後の確認

サブスクリプションを追加するときは、追加画面で該当するSubscribeタイプを選び、完全なサブスクリプションリンクを対応するアドレス欄に入力し、見分けやすい名前を付けます。保存後、読み込みが終わるまで待ち、Homeに戻ってサブスクリプションのグループと、その中のサーバーが表示されることを確認してください。グループ名だけが表示され、利用可能な項目がない場合は追加完了とはいえません。リンクが完全か、取得が成功したか、サブスクリプションの内容が有効かを確認してから、接続手順に進みます。

サブスクリプションリンクにはアクセス認証情報が含まれている場合があります。前後の空白や改行、チャットアプリによるリンクの切り詰めは読み込みに影響します。ブラウザーでページが開けても、そのページがクライアントで読み込めるサブスクリプション内容とは限りません。ログイン画面、通常の説明ページ、エラーメッセージが表示された場合は、元のリンクの用途を確認してください。返されたテキストを無理にサーバーパラメータとして入力したり、リンク全体を公開の場に貼って他人に判断を求めたりしないでください。

サブスクリプションを更新すると、提供元から最新の内容が再取得されます。項目名、件数、順序が変わることがあります。更新後は現在選択中のサーバーが残っているかを確認してください。更新処理が終わっただけで、接続先が変わっていないと決めつけないでください。手動入力したパラメータも記録し、一時的な変更をサブスクリプションの恒久的な内容と混同しないようにします。長期保存が必要な備考や設定変更は、更新時に上書きされるか確認してから、適切な管理方法を決めてください。

QRコード、共有リンク、設定ファイルの違い

Scan QR Codeは読み込みの入口にすぎません。追加後もプロトコル、アドレス、認証項目を確認してください。QRコードにはサーバー情報が含まれる場合も、サブスクリプションへのリンクが含まれる場合もあります。スキャン成功の表示だけで内容を判断しないでください。共有リンクも完全にコピーする必要があります。複数の項目が追加された場合は、それぞれの出所と用途を確認してください。追加件数は成功の基準ではありません。パラメータが明確で選択可能なサーバーが一つあれば、最小限の確認結果として十分です。

ConfigのルールファイルとHomeのサーバーは、それぞれ別に確認してください。ルールを追加してもサーバーが自動的に用意されるわけではありません。サブスクリプションを追加しても、Configに適切な振り分け設定が含まれるとは限りません。初回のテストでは、まずサーバーパラメータを確認し、次にルーティングの状態を確認してからルールを検証します。プロトコルの項目についてはプロトコルとTypeの解説をご覧ください。接続パラメータは必ず手元の元情報に従い、記事の例を実際の認証情報の代わりに使わないでください。

04 / GLOBAL ROUTING

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

接続前にGlobal Routingを確認してください。Config、Proxy、Directの3つのモードは、それぞれConfig、Proxy、Directに対応し、リクエストをどのように処理するかを決めます。サーバーのプロトコルや通信速度の段階を示すものではありません。モードを切り替えても、パスワードの誤り、無効なサブスクリプション、接続できないサーバーは修復されません。変わるのはルーティングの判断方法です。問題を調べるときは現在のモードを記録してください。記録しないと、同じリクエストでも異なる経路を通り、サーバーの状態が不安定になったと誤解することがあります。

Config、Proxy、Directを選ぶ

Configは、現在有効な設定とルールに従ってリクエストを処理します。振り分け先が明確な場合の日常利用に適しています。一部のリクエストをProxy経由、一部を直接接続にしたり、指定したリクエストを拒否したりできます。Proxyは代理接続を主な処理方向とし、ルールの影響を抑えてサーバーがリクエストを処理できるか確認する場合に適しています。Directは直接接続するためのモードで、Directでアクセスできたことを代理サーバーが動作している証拠として扱わないでください。いずれのモードも、対象のリクエストとシステムの実際の状態を合わせて確認します。

画面の選択肢	主な判断基準	確認するポイント
Config	現在の設定に含まれるルールとポリシー	このリクエストはどのルールに一致したか？
Proxy	代理接続の処理方向と実際の接続先	振り分けの違いを除いて、リクエストを完了できるか？
Direct	ローカルネットワークで直接接続できる条件	基本ネットワークからこの接続先に直接アクセスできるか？

ProxyからConfigに切り替えた後で結果が変わった場合は、サーバーが突然使えなくなったと考える前に、ルールとポリシーの接続先を確認してください。逆に、Configで特定のWebサイトが使えても、DIRECTに一致している可能性があるため、代理接続が機能している証拠にはなりません。適切にテストするには、まずリクエストが通るべき経路を決め、実際に適用されたポリシーを確認します。テスト後は日常利用のモードに戻し、問題の切り分けのために変更した設定がそのまま残らないようにしてください。

ルールは上から順に確認

ルールは通常、上から順に確認され、最初に一致した項目で後続の処理が決まります。そのため、具体的なルールを広範囲に一致するルールより上に置きます。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはドメインの末尾、DOMAIN-KEYWORDはドメイン内のキーワードに一致します。IP-CIDRとIP-CIDR6はIPアドレスの範囲、GEOIPはアドレスの所在地に基づいて判定します。FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールキーワードは一致条件を、末尾のポリシーは処理方法を示すため、分けて確認してください。

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

上記は学習用の.confルール例であり、完全な設定ではありません。また、すべてのネットワークに適しているとは限りません。1行目は指定した完全なドメイン名にのみ一致し、2行目は対応するドメインのサフィックスに一致します。3行目はプライベートアドレス範囲とno-resolveの記述例です。最後のFINALが、それまでのルールに一致しなかったリクエストを処理します。example.comとexample.orgは例示用のドメインです。貼り付ける前に各ルールの意味を確認してください。既存ファイルを変更する場合は、同じ内容や、より広い範囲に一致するルールがすでにないか確認します。

ポリシーの接続先とルールの確認

PROXY、DIRECT、REJECTは、それぞれ代理接続、直接接続、拒否という処理方向を示します。ルールに独自のポリシー名を使う場合は、現在の設定内に対応する定義が必要です。サーバーの備考をポリシー名として入力すれば、クライアントが適切な接続先を自動で見つけると考えないでください。ルールを確認するときは、一致条件だけでなく、適用されたポリシーが最終的にどこを接続先にしているかも確認します。ルールへの一致と接続の成功は、別々に検証する必要があります。

Configを変更したら、現在有効なファイルを編集したか、内容を保存したかを確認します。画面の案内に応じて再読み込みまたは再接続し、変更後の状態でテストしてください。既存の接続が以前の経路を使い続けたり、アプリのキャッシュが変更結果を覆い隠したりする場合があります。新しいリクエストを発行して確認しましょう。キーワードの詳しい解説はルール構文の入門を、見慣れない名称は用語集をご覧ください。調整のたびに元のファイルを残し、結果を確認してからルールを追加してください。

05 / CONNECTIVITY

接続と段階的な確認

接続は「基本ネットワーク、サーバーの選択、システム権限、テストリクエスト、ルールの一致」の順に確認します。スイッチがオンのままでも、クライアントとシステムが所定の接続状態にあることを示すだけで、すべての接続先にアクセスできるとは限りません。Homeにサーバーが表示されても、項目が保存されていることがわかるだけです。状態を一つずつ確認すれば、Webサイトが開かないときに設定をすべて削除したり、アプリを買い直したりする誤った対応を避けられます。

選択中のサーバーから確認

Homeでテストに使うサーバーを見つけて選択し、選択済みの表示を確認します。サブスクリプションのグループに項目が多い場合は、グループ名を接続先と取り違えないよう、今回使うサーバーを明確にしてください。サブスクリプションを更新した直後は、選択中の項目がまだ有効か確認します。次にGlobal Routingを確認し、Config、Proxy、Directのどれが選ばれているか記録します。Configで独自のポリシーを使っている場合は、実際の接続先が想定どおりかも確認してください。

画面上部の接続スイッチをオンにし、システムから求められた権限を許可します。状態が安定してからテストしてください。スイッチがすぐにオフに戻る場合は、まず権限、システムのVPN状態、アプリに表示されるエラーを確認します。スイッチがオンのままリクエストに失敗する場合は、サーバーとネットワークを確認してください。この2つの現象を同じ問題として扱わないでください。テスト中にスイッチをすばやく何度も切り替えると、処理中の接続と新たな接続試行が重なり、表示される案内とリクエストを対応付けにくくなります。

Connectivity Testで確認できること

Connectivity Testでは、指定されたテスト条件下で接続できるかを確認します。現在のルーティングモード、テスト対象、選択中のサーバーを合わせて結果を見てください。一度テストに成功しても、すべてのWebサイトやアプリが正常だとは限りません。テスト方法によって通る経路やプロトコルが異なることがあり、単一の数値で実際の通信を判断することもできません。初回はサーバー、ネットワーク、テスト対象を固定し、変数を一つずつ変えて比較します。

まずConnectivity Testを実行し、次に利用可能なはずだと分かっている接続先を一つ開いて、タイトルが表示されるだけでなくページ全体が読み込まれるか確認します。テストに成功しても接続先にアクセスできない場合は、接続先自体、DNS、ルール、証明書、アプリのキャッシュなどが関係している可能性があります。テストと複数の接続先がすべて失敗する場合は、基本ネットワークとサーバーパラメータに戻って確認してください。また、TCP系のリクエストとその他の通信要件を区別します。一般的なWebページが開いても、すべての通信方式が検証されたわけではありません。

現象から問題の範囲を絞り込む

接続を切った状態で、まずデバイス自体が通常の接続先にアクセスできるか確認します。Wi-Fiのログインが完了していない、モバイル通信が使えない、ネットワークが一時的に切断されているといった可能性を除外してください。基本ネットワークが復旧したら、同じサーバーに接続して比較します。特定のネットワークだけで失敗する場合は、そのネットワーク環境と通信条件を重点的に確認します。異なるネットワークでも失敗する場合は、サーバーアドレス、ポート、認証情報、TLSパラメータを見直してください。ネットワークの切り替えは変数の変更にあたるため、テスト記録に残し、ルール変更と同時に行わないでください。

Proxyではテストに成功し、Configでは失敗する場合は、現在の設定ファイル、一致したルール、ポリシーの接続先を優先して確認します。特定のドメインだけで問題が起きる場合は、より上位のルールに一致していないか、名前解決が想定どおりかを確認してください。複数のサーバーで同時に問題が起きても、すべてのサーバーが使えなくなったとすぐに判断しないでください。基本ネットワーク、システム時刻、共通のサブスクリプション、最近変更した共通設定も確認します。複数の項目が同じ要因に依存していることがあり、件数が多くても互いに独立しているとは限りません。

確認後の後処理

接続できたら、日常利用で使うGlobal Routingに戻し、同じ接続先で再テストします。一時的なモードでしか成功しない状態ではないことを確認してください。Dataを開き、新しいリクエストとポリシーが一致しているかを確認し、不要なDNS設定やデバッグ項目が残っていないことも確かめます。問題が続く場合は再現手順をまとめ、FAQの接続トラブルシューティングをご覧ください。操作例を順番に確認したい場合は初回接続の確認方法も参考になりますが、実際のパラメータ確認を省略しないでください。

この章の目標は、一度偶然つながることではありません。現在どの接続先を使い、どのモードでリクエストを処理し、どう再確認するかを説明できる状態を目指します。この基礎が安定してからDataの分析やSettingsの調整に進めば、比較の基準ができます。基礎が不安定なまま設定を追加し続けると、不確定な要素が増えるだけです。

06 / DATA

Dataで通信状況とリクエストを確認

Dataではクライアントが記録した通信状況を確認できます。「テスト中にリクエストが発生したか」「どの接続先と継続的に通信しているか」「処理方向が想定どおりか」といった確認に役立ちます。一方、サービス提供元の請求明細でも、デバイス上のすべての通信履歴でもありません。データを見る前に、集計範囲、現在の接続状態、テストした時間帯を確認してください。合計値が増えても、開いたページだけがその通信量を使ったとは限りません。バックグラウンド同期や既存の接続も同時に発生することがあります。

まず観察する時間帯を決める

テスト前に現在の集計値または一覧の状態を記録し、不要な前面タスクを終了してから、「指定したページを開く」「内容を一度更新する」など明確な操作を一つだけ行います。累計値から推測するのではなく、Dataに戻って新しい変化を確認してください。統計を消去する場合は、対象と表示された確認内容を確認し、必要な記録を残してから実行します。ローカルの統計を消去しても、リモート側の使用量やサブスクリプションの有効期間、サービス提供元の記録は変わりません。

アップロードとダウンロードを確認するときは、接続の確立、リクエストヘッダー、アプリが送信する内容など、リクエスト自体にもアップロード通信が発生することを理解してください。Webページを読むだけでも、アップロードがゼロになるとは限りません。プロトコルのオーバーヘッド、キャッシュ、再試行、圧縮などにより、ダウンロード量とファイルの表示サイズが異なる場合があります。1回のテストで生じたわずかな差だけで異常と判断しないでください。同じ条件で同じ操作を繰り返したとき、明らかに異なる動作が何度も起きるかを比較するほうが有用です。

リクエスト、ルール、ポリシーを関連付けて確認

現在の画面でリクエストや接続の詳細を確認できる場合は、通信量だけでなく、接続先、処理ポリシー、時刻を確認します。Configモードでは、1つのページがメインドメイン、画像用ドメイン、API用ドメイン、その他のリソースを同時に要求し、それぞれ別のルールに一致することがあります。ページ本体が開いて画像だけ失敗する場合は、各リソースが異なる経路を通っている可能性があり、サーバー全体の問題とは限りません。まず失敗したリソースの接続先を特定し、Configで該当するルールを確認してください。

DIRECTが表示された場合は、それが想定どおりの結果か確認します。PROXYが表示された場合は、実際の接続先も確認してください。Webサイトの表示言語、外観、読み込み速度から適用されたポリシーを推測することはできません。ドメイン名が常に完全に表示されるとは限らず、アドレス情報だけが表示される接続もあります。また、既存の接続は以前の判断を引き継ぐ場合があります。ルールを変更した後は、新しいリクエストを発行して記録を確認してください。古い接続がすぐに変化するかを見続けるより確実です。

観察された状態	追加で確認できること	直接は判断できないこと
テスト後、新しい記録がほとんどない	新しいリクエストを実際に発行したか、キャッシュを使用したか	サーバーが必ず使えなくなった
特定の接続先への再試行が続いている	接続先への到達性、ルール、DNS、認証	すべてのアプリが接続できない
集計値が増え続けている	バックグラウンド同期や通信中のタスク	現在表示しているページだけが通信している
ローカル集計とリモート側の使用量が異なる	集計範囲、期間、計算方法	どちらかの記録が必ず間違っている

通信量、速度、安定性を区別する

累計通信量は処理済みのデータを示し、短時間の変化はその期間の通信状況を示します。どちらも長期的な安定性を表すものではありません。ページを開いたまま新しい通信がないのは、読み込みが終わっただけかもしれません。短時間に通信量が増えた場合も、テスト対象ではなくバックグラウンド処理が原因の可能性があります。同じ操作を繰り返し、エラーが再現するかを接続状態と合わせて確認してください。瞬間的に大きな数値が出ることだけを目標にしないでください。

ネットワークごとの結果も分けて記録します。Wi-Fiとモバイル通信では条件が異なり、接続の確立や通信状況にも影響します。異なるネットワークでのテストを、一つの累計統計にまとめて直接比較しないでください。設定が原因で再接続を繰り返していると思われる場合は、まず観察結果を残し、その設定だけを元に戻して再テストします。統計の消去、サブスクリプションの更新、ルール変更を同時に行うと、結果が改善しても、どの操作が有効だったか分からなくなります。

診断データとプライバシー

通信やリクエストの記録には、ドメイン、パス、デバイスの利用傾向、認証情報に関係する内容が含まれる場合があります。共有する前に、問題の切り分けに必要な部分だけを残し、アカウント、サブスクリプションの認証情報、サーバーの完全な認証パラメータ、個人的なリクエスト情報を削除してください。ランダムな文字列に見える項目が実際に使える認証情報である可能性もあります。用途が分からないという理由で、そのまま公開しないでください。テスト後は必要に応じて追加の記録を終了し、現在の問題に関係のないデータを長期間保存しないようにします。

この章では、テスト操作を明確にし、新しいリクエストを見つけ、適用されたポリシーを確認してから、サーバー、ルール、接続先のどれを調べるか判断するための証拠を集めます。Dataは確認の手掛かりを示すもので、判断そのものに代わるものではありません。異常の内容を前章の最小限のテスト記録と合わせると、累計値だけが写ったスクリーンショットより問題を特定しやすくなります。

07 / SETTINGS

Settingsの主な項目と変更時の注意

基本の接続を確認してから、Settingsを一項目ずつ調整してください。初回起動時にすべてのスイッチをオンにする必要はありません。設定によって、接続を開始する条件、ドメインの名前解決、テストや記録など、影響する階層が異なります。変更前に解決したい現象を明確にし、項目の説明と現在値を確認してください。本章で触れている項目が画面にない場合は、デバイスに実際に表示されている内容に従います。似た名称から同じ機能だと推測したり、別の設定一式をそのまま適用したりしないでください。

On Demand：接続条件の設定であり、サーバーの修復ではない

On Demandは、条件に応じて接続を開始する機能です。実際の動作は、システムのVPN構成、ネットワークの変化、デバイスの管理状態にも左右されます。有効にする前に、手動接続が安定して使えることを確認してください。基本パラメータの誤りと自動接続の動作が重なると、接続の繰り返し、スイッチ状態の変化、ネットワーク切り替え後の結果の違いが起き、原因を見分けにくくなります。On Demandは接続を試みるタイミングを決めるもので、使えないサーバーを修復する機能ではありません。

有効にする前に、どのネットワーク条件で接続するか、どの状況で停止するか、手動で切断した後にどう動作してほしいかを明確にします。変更後は、アプリを前面にした状態、ネットワークの切り替え、デバイスのスリープ解除など、実際の利用場面でそれぞれテストしてください。設定画面でスイッチがオンになっているだけで、すべての条件で有効だと判断しないでください。自動再接続の問題を調べる場合は、一時的に手動接続に戻すと、接続条件とサーバー自体を切り分けやすくなります。

DNS：名前解決の失敗と接続の失敗を区別

DNSはドメイン名をIPアドレスに変換するもので、名前解決の成功は接続の前提の一つにすぎません。ドメイン名を解決できない場合と、アドレスを取得できても接続を確立できない場合は、別々に対処する必要があります。まず、問題がドメイン名を使うリクエストに限られるか確認し、現在のConfigとSettingsにDNS関連の設定が含まれているかを調べてください。設定ファイルと画面上の設定が両方とも影響する場合があります。現在の項目の説明と実際のリクエスト結果を確認し、一方だけを見てもう一方には設定がないと決めつけないでください。

DNSの項目は数が多いほどよいわけでも、適当に置き換えればすべての接続が改善するわけでもありません。DNSサービス自体に接続できる必要があり、返されたアドレスもその後のルーティングに適していなければなりません。変更後に一部の接続先だけで問題が起きた場合は、ドメイン名と変更前後の設定を記録し、元の値に戻して比較してください。IPアドレスへの直接接続に成功しても、名前解決が必ず正常とは限りません。テスト用ページに内容が表示されても、アプリの実際のリクエストでは別のドメインやキャッシュが使われている可能性があります。

テスト、記録、証明書に関する項目

接続テストの対象と方法は、Connectivity Testの結果の解釈に影響します。テスト項目を変更する場合は元の値を記録し、用途が明確な対象を使って確認してください。テスト対象自体に接続できない場合、サーバーではなく対象の問題が結果に表れる可能性があります。ログや診断記録は具体的な問題があるときに一時的に使用します。記録期間や範囲を広げても、分析しやすくなるとは限りません。テスト後は不要な詳細記録が残っていないか確認し、必要に応じて保存済みの内容を整理してください。

証明書とHTTPS関連の設定は特に慎重に扱ってください。通常のサーバー接続や基本的なルール設定を、復号検査を有効にする理由にしないでください。証明書エラーが出た場合は、まずデバイスの時刻、接続先のドメイン名、サーバーのTLSパラメータを確認します。検証を無効にすることを通常の修復方法にしないでください。証明書機能の影響が分からない場合は、現在の状態を維持して項目の説明を読んでください。エラー表示を消すためだけに、デバイス全体の信頼判断を変更しないでください。

設定の適用範囲と元に戻す方法

変更のたびに、その値が特定のサーバー、Configファイル、アプリ全体のどこに適用されるか確認してください。サーバー1件の通信パラメータを変更しても、サブスクリプション内のほかの項目に同じ変更が反映されるとは限りません。Configを切り替えても、アプリのすべての設定が元に戻るとは限りません。適用範囲を簡単に記録しておくと、サーバーを切り替えた後も問題が続く理由や、別の設定ファイルで結果が変わった理由を把握できます。複数の接続先に共通する問題を調べるときは、共通して適用される設定の階層を確認してください。

元に戻すときは、変更した順序を逆にたどり、一項目ずつ復元して再テストします。すべての内容を一度にリセットしないでください。リセットが必要な場合は、先にサーバーと設定をバックアップし、機密情報の保存先を確認して、再入力が必要な値を記録します。Settingsの目的は動作を予測できるようにすることであり、項目を増やすことではありません。用途を説明できる変更だけを残してください。意味の分からない画面上の用語は用語集で確認し、変更が必要か判断しましょう。

08 / MAINTENANCE

サブスクリプションの更新、バックアップ、日常のメンテナンス

日常のメンテナンスでは、確認済みの状態を保ち、変更の経緯を追えるようにすることが大切です。アプリの更新、サブスクリプションの更新、ルールの変更、機種変更は別々の操作です。記録を残さず一度に試さないでください。問題が起きたら、最近何を変更したか確認し、必要最小限の範囲で対処します。基本の接続を繰り返し確認できるなら、局所的な問題のためにすべてのサーバーと設定を削除する必要はありません。メンテナンスの目的は不確定要素を減らすことであり、何度も最初からやり直すことではありません。

アプリとサブスクリプションの更新を分けて行う

アプリはApp Storeから更新します。現在の互換性や関連情報はApp Storeの製品ページをご確認ください。アプリを更新しても、サブスクリプションが有効なままだとは限りません。また、リモートサーバーの状態が変わらないことも保証されません。サブスクリプションの更新では、サービス提供元が用意した内容を読み込みます。目的も情報源も異なるため、まず現在の接続結果を記録し、どちらか一方を更新して再確認します。正常に動作することを確認してから次の更新を行うと、異常と変更内容を対応付けやすくなります。

サブスクリプションを更新する前に、保持したい手動変更を確認してください。更新後はグループ内の項目、現在の選択項目、ルールが参照する接続先を確認します。名称や項目が変わると、以前の名称に基づく記録が正確でなくなる場合があります。アドレスと用途をもう一度確認してください。更新に失敗しても、既存のグループをすぐに削除しないでください。古い項目でまだ接続できるか確認してから、サブスクリプションリンク、基本ネットワーク、返された内容を調べます。使える状態を維持すれば、読み込みの問題とサーバーの問題を区別しやすくなります。

バックアップでは設定内容と認証情報を分けて扱う

バックアップ前に、保存する対象を整理します。サーバー情報、サブスクリプションの入口、Configファイル、必要なSettingsの変更前の値、App Storeの購入アカウントを確認するための記録などです。アプリに備わっているエクスポート機能やシステムのファイル保存機能を使う場合は、どの範囲が書き出されるかを確認してください。ファイルにすべての設定が含まれるとは限りません。保存後は、ファイルを見つけられるか、内容が分かる名前か、長期保管に適した場所かを確認します。バックアップが存在していても読み込めなければ、復元の準備ができたとはいえません。

設定ファイルや共有内容には、パスワード、ユーザーID、サブスクリプションの認証情報が含まれる場合があり、一般的な説明文書のように公開の場所へ保管できません。問題の相談に使うコピーからは機密部分を削除してください。復元用のバックアップには必要な情報を残し、適切に保護します。この2つは用途が異なります。情報を削除した診断用コピーを、唯一の復元用ファイルにしないでください。認証情報を誤って公開した場合は、利用中のサービス提供元に対応方法を確認し、古い情報がまだ有効か調べてください。

機種変更や再インストールでは段階的に復元

新しいデバイスでは、まずApp Storeからアプリを再入手します。システム要件と購入対象となる条件はApp Storeの製品ページを確認し、アプリを開いて実際の状態を調べてください。次にサーバー1件またはサブスクリプション1つを復元し、システムの権限を許可して、手動接続を確認します。基本の接続に成功したらConfigと日常利用のSettingsを戻し、最後にOn Demandをテストしてください。すべての内容を一度に読み込んで、スイッチの状態だけで復元完了と判断しないでください。古い設定の影響がネットワーク切り替え後に初めて表れることがあります。

以前のデバイスで使えていた設定も、そのときのネットワーク、システム権限、有効なサーバー情報に依存していた可能性があります。新しいデバイスで結果が異なる場合は、ファイルが壊れたと決めつける前に、こうした前提を比較してください。旧デバイスで使えていた状態を記録し、サーバーパラメータ、Global Routing、現在のConfigを一つずつ比較します。復元が完了してから、旧デバイスに残った機密情報を処理してください。購入済みアプリの復元手順は購入済み項目の復元方法をご覧ください。App Storeでの復元と設定の移行を一つの手順として扱わないでください。

定期確認とトラブル対応の手順を決める

重要な変更を行った後は、同じ項目を確認します。現在のサーバーが明確であること、Global Routingが正しいこと、Connectivity Testと実際の接続先で確認できること、Dataに表示されるポリシーが想定どおりであること、一時的なデバッグ設定を元に戻したことです。問題が再発したら、変更を続ける前にいったん止め、最後に正常だった状態から最初に異常が起きた状態までの変更を記録してください。範囲を絞りやすくなり、数日後に一時的な設定を有効にした理由を忘れて、誤った前提から調査を始めることも防げます。

サポートを求める際は、デバイスの種類、ネットワーク環境、ルーティングモード、問題を再現できるか、すでに試した比較方法、認証情報を含まないエラー表示を伝えてください。「つながらない」「遅い」といった説明だけではなく、バックアップ全体を最初の資料として共有することも避けてください。問題が発生した段階に応じて、本マニュアルの該当章に戻ります。追加の問題ならサーバーとサブスクリプション、経路の問題ならGlobal Routing、スイッチやリクエストの問題なら接続確認、自動起動の問題ならSettingsを確認してください。

ここまでの内容を一連の手順として確認できます。正規購入でアプリの情報を確認し、初回認証でシステムの接続条件を整え、サーバー情報で接続先を設定し、Configでルーティングを決めます。テストとDataで状況を確認し、Settingsで動作を調整し、バックアップと記録で復元できる状態を保ちます。日常利用のたびにすべてをやり直す必要はありません。変更が起きたら、影響を受けた階層から確認してください。基本操作は使い方ガイド、よくある質問はFAQ、ルールの詳細はサイト内の関連解説をご覧ください。