Shadowrocket 使い方完全ガイド

正規アプリの入手と購入履歴

購入前にアプリの正規性をご確認ください。ShadowrocketはAppleプラットフォーム向けの有料アプリで、主な利用デバイスはiPhoneとiPadです。入手先はApp Storeのみです。Mac、Apple TV、Apple Visionとの互換性も同じ製品ページで確認できます。システム要件やユニバーサル購入の対象かどうかは、App Storeの製品ページの記載をご確認ください。本マニュアルではiPhoneとiPadを中心に説明します。ほかのデバイスでも画面構成が同じとは限りません。

アプリ名・デベロッパ・アプリIDを確認する

正規アプリの確認ページからApp Storeの製品情報を開き、アプリ名Shadowrocket、デベロッパShadow Launch Technology Limited、製品リンク内のアプリID 932747118を順に確認してください。次に、App Storeのアイコンと当サイトのヘッダーに表示されている公式アイコンを見比べます。名前が似ていても同じアプリとは限りません。検索結果の掲載順位、補足説明、ページの配色ではなく、製品ページに記載された情報で正規性を確認してください。

App Storeの製品ページでは、価格、互換性、アップデート履歴を確認できます。購入前に互換性情報を開き、現在のデバイスにインストールできるか確認してください。価格は利用中のストアとアカウントの決済画面に表示される金額をご確認ください。記事内の価格例を最終的な請求額と見なしたり、製品シリーズだけで対応状況を判断したりしないでください。同じ機種でも、システムの状態によってストアで利用できる操作が異なる場合があります。

アプリの購入と接続サービスを区別する

Shadowrocketは買い切りで、米国のApp Storeでは約2.99米ドルです。各ストアでは現地通貨で表示され、実際の価格はApp Storeの製品ページに記載された金額が適用されます。購入できるのはアプリの利用権です。サーバーアドレス、認証情報、サービスの利用期間、データ容量は、利用者がすでに契約しているサービスの設定によるもので、アプリの購入によって自動的に提供されるものではありません。インストール後にリストが空の場合は、アプリを再購入するのではなく、既存の設定を追加してください。

購入前に、利用中のApp Storeアカウントを確認し、システムに記録された購入履歴を保管してください。デバイスの設定によっては、システムアカウントとストアの購入アカウントを別々に管理できます。デバイス上部に表示された名前だけで購入者を判断しないでください。機種変更、再インストール、支払いの確認では、アプリ内のサーバー名、設定メモ、接続状態ではなく、購入履歴を確認することが重要です。

インストール・復元・アップデートの範囲

App Storeで購入してインストールしたら、まずアプリを一度開き、メイン画面が表示されることを確認してから、サブスクリプションや権限の設定に進みます。ストアに再購入を求められた場合は、支払いを確定する前に、アカウントと購入履歴が一致しているか確認してください。同じ購入アカウントでの再ダウンロードや、ほかのデバイスで利用できる権利は、ストアの表示とアカウントの購入履歴をもとに判断します。ファミリー共有の対象かどうかも、ストアの記載とアカウント設定をご確認ください。

機種変更時の復元は、アプリの購入権とアプリ内データの2つに分けて考えます。購入済みアイテムからアプリを再入手しても、サーバー、サブスクリプションのリンク、ローカル設定が同時に戻るとは限りません。機種変更の前に、利用可能な設定のバックアップがあるか確認し、利用中のサービス情報を保存してください。サーバーのメモ名だけでは、プロトコル、ポート、認証パラメーターが分からず、接続を再構築できない場合があります。

アプリのアップデートはApp Storeで管理します。アップデート前に、使用中の設定と必要な接続パラメーターを保存してください。アップデート後は、デフォルトサーバー、Global Routing、現在有効な設定が想定どおりか確認します。ストアでインストールできない場合は、アカウント、支払い、デバイスの空き容量、システムとの互換性など、ストア側の問題を先に確認してください。この段階ではリモート接続を扱っていないため、DNSやルールを変更しても購入・インストールの問題は解決しません。

この章の完了条件は、App Storeで同じ製品を確認し、購入アカウントを特定し、アプリを正常に開けること、そして既存の接続情報の保存場所を把握することです。「ホーム画面にアイコンが表示された」だけで準備完了とはしないでください。入手とデータ復元の範囲を分けておけば、接続できないときにアプリの状態、設定値、リモートサービスのどこに原因があるか判断しやすくなります。

初回起動とVPN構成の許可

初回起動後は、接続する前にHome画面の構成を確認しましょう。Homeには接続スイッチ、Global Routing、Connectivity Test、SERVERリストが表示されます。デバイスやアプリの状態によって画面の配置は異なる場合があるため、固定の位置ではなく英語の機能名で判断してください。画面の詳しい説明は初回起動とHome画面の説明をご覧ください。この章では、権限と接続状態の関係を解説します。

Home画面で確認する4つのポイント

接続スイッチは現在の接続を開始・停止します。Not Connectedは接続が確立していない状態を示し、アプリの購入に失敗したという意味ではありません。Global Routingでは、設定したルールに従うか、プロキシを使うか、直接接続するかを選びます。SERVERリストには選択可能なサーバーが保存されます。項目を開いて編集する操作と、デフォルトサーバーに選択する操作は別なので、それぞれ確認してください。

Connectivity Testでは、リスト内のサーバーへの接続状況を確認できます。テスト結果は問題の範囲を絞る手掛かりになりますが、実際のアクセスを完全に検証するものではありません。初回起動時にリストが空なら、有効なサーバーのテスト結果は得られません。項目が表示されていても、すべて利用可能とは限りません。まず第3章でパラメーターを確認し、結果を参考情報として使いましょう。必要な情報がそろう前にスイッチを何度も切り替えるのは避けてください。

アプリに表示される状態と、システムに保存されている構成も区別しましょう。システムに以前追加したVPN構成が残っていても、アプリは接続していないことがあります。アプリを正常に開けても、システムが接続を許可しているとは限りません。状態を確認するときは、アプリで選択中の項目とスイッチを見てから、システムのVPN状態を確認します。ステータスバーのアイコンだけで、すべての通信経路を判断しないでください。

VPN構成を追加するシステムの確認画面

アプリが必要なネットワーク接続を確立しようとすると、システムからVPN構成の追加確認が表示されます。これはAppleのシステムが接続権限を管理するための手続きで、購入確認やサブスクリプションへのログインではありません。自分でShadowrocketを操作している最中に表示されたことを確認してから、システムの案内に従って許可し、必要な認証を完了してください。確認する前に作業内容を保存しておくと、アプリを切り替えたあとに画面がどの手順で表示されたか分からなくなるのを防げます。

以前に許可を取り消した場合は、アプリに戻り、接続を再度開始できるか確認してから、現在のシステムの案内に従って操作してください。システム設定の項目名や場所は画面の変更に伴って変わることがあるため、設定内で「VPN」を検索し、Shadowrocketの構成があるか、現在どの状態かを確認します。用途が分からない構成を続けて追加したり、再試行のために使用中のほかのネットワーク構成を削除したりしないでください。まずどの構成かを確認してから対処します。

組織が管理するデバイスでは、ネットワーク設定が管理ポリシーによって制限されている場合があります。確認画面が分からない、構成を追加できない、スイッチがすぐ元に戻る場合は、デバイスに該当する制限がないか確認し、管理者に許可されている設定を問い合わせてください。サブスクリプションを再インポートしてもシステムのポリシーは変わりません。問題を調べる際は、「反応がない」という曖昧な説明より、システムに表示された文言を正確に記録すると原因を特定しやすくなります。

初回操作の基準状態を整える

初回設定では手動接続のままにし、On Demandはまだ有効にしないでください。「サーバーを準備する、デフォルトを選ぶ、ルーティング方式を確認する、接続を開始する、アクセスを検証する」という操作の流れを1つずつ進めます。こうしておけば、状態の変化を直前の操作に結びつけられます。自動接続、設定変更、サブスクリプション更新を同時に行うと、接続や切断の原因が分かりにくくなり、変更が反映されたかどうかも判断できません。

初回の権限設定後は、アプリのスイッチがオンのまま維持されるか、システムに接続状態が表示されるかを記録してください。スイッチを維持できない場合は、権限、設定の有効性、エラーメッセージを優先して確認します。スイッチを維持できてもアクセスできない場合は、接続確認の手順に進みます。この2つは異なるトラブルシューティングの分岐です。「権限を許可した」「スイッチをオンにした」「目的のサイトにアクセスできた」を一つの成功条件にまとめないでください。

この章を終えると、Home画面で接続、ルーティング、テスト、サーバー選択を行う場所と、システム権限の確認状況を説明できるようになります。すべてのサイトにアクセスできる必要はありませんが、サーバー情報、権限、接続確認のうち何が不足しているかを把握してください。最短手順で操作を進める場合は使い方ガイドに戻り、設定値の入手先やインポートの範囲を確認する場合は次の章に進んでください。

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

インポート前に、手元にある情報が単一サーバーの情報、サーバー共有用データ、サブスクリプションリンク、設定ファイルのどれか確認します。それぞれ用途が異なります。サーバー項目には1回の接続に必要なパラメーターを保存し、サブスクリプションは複数のサーバーを更新します。設定ファイルは主にルーティングや関連設定をまとめます。設定ファイルのURLをサブスクリプション欄に入力したり、通常のWebページのURLをサーバーアドレス欄に入力したりすると、解析に失敗したり、想定と異なる内容が表示されたりする場合があります。

手動追加とプロトコルパラメーターの確認

Add Serverから手動で追加する場合は、まずプロトコルを選び、アドレスとポートを入力してから、認証情報と転送パラメーターを確認します。各項目には、利用中のサービスから提供された情報を入力してください。名前から値を推測しないでください。同じドメインでもポートが異なる場合があり、同じポートでも異なるプロトコルが使われることがあります。すべての項目が埋まっていても、組み合わせが正しいとは限りません。保存後は編集画面を開き、特にコピー時に混入した空白、改行、全角記号がないか、一つずつ確認します。

表は確認の観点を示すもので、すべてのプロトコルで同じ項目を入力するという意味ではありません。サービス情報に転送パス、ホスト名、TLSサーバー名が含まれている場合は、それぞれの用途に合わせて入力し、すべてをアドレス欄にコピーしないでください。サーバーアドレスは接続先を指定し、TLS関連の名前は該当する認証に使います。両者が同じ場合も異なる場合もあり、サービス設定で明示された値を相互に置き換えることはできません。

既存のサブスクリプションを追加して結果を確認する

サブスクリプションをお持ちの場合は、アプリの追加メニューからSubscribeを選び、完全なサブスクリプションURLを入力して保存し、更新操作を行います。サブスクリプションリンクにはアクセス用の認証情報が含まれる場合があるため、コピー時は内容を保ちつつ、公開チャット、スクリーンショット、問い合わせ文面に貼り付けないでください。追加後はSERVERリストに戻り、想定したグループと項目が表示されているか確認します。サブスクリプション名が表示されただけでは、サーバー情報の取得に成功したとは限りません。

リストが空の場合は、更新がまだ完了していないのか、リクエストが失敗したのか、受信した内容を認識できないのかを確認します。URLの先頭、末尾、クエリパラメーターが欠けていないか確認し、アカウント管理ページではなくサブスクリプション用URLであることを確かめてください。そのうえで、元のサービス提供元にサブスクリプションの状態と対応する形式を確認します。同じURLを何度も追加すると、同じ名前のグループが複数でき、更新や削除の判断が難しくなるため避けてください。

サブスクリプションを更新すると、サーバー項目が追加、削除、変更される場合があります。単なる表示の再読み込みではありません。更新前に、現在のデフォルトサーバーが属するグループを控え、更新後に選択状態が有効か確認してください。サーバー名が変わった場合は、以前のメモ名だけで削除されたと判断せず、グループとサービス提供元の案内を照らし合わせます。リストが空になる場合や解析エラーについては、サブスクリプションの解析失敗を確認する方法をご覧ください。

共有データ・QRコード・設定ファイルのインポート

Scan QR Codeでインポートする前に、QRコードが自分の利用中サービスに関する信頼できる資料のものか確認し、読み取り後に表示されるプロトコル、アドレス、メモを確認します。QRコードの読み取りで手入力を省けますが、接続先の品質やパラメーターの有効性を検証できるわけではありません。同じデバイスにQRコードが表示されている場合は、アプリが用意している適切なインポート方法を使ってください。認証情報を含む画像を公開の読み取りサービスに送らないでください。

共有データのインポート後は、保存されたのが単一サーバーかサブスクリプションかを確認します。単一項目から今後の自動更新を想定することはできません。サブスクリプション内の項目は、更新時に変更される場合があります。インポート後の編集項目が元資料と異なる場合は、まず元資料を保管し、対応プロトコルとパラメーターの割り当てを一つずつ確認してください。比較基準を失わないよう、使えるサーバーをすぐに上書きしないでください。

設定ファイルをインポートした後は、Configで現在有効なファイルを確認してください。ファイルが保存されている状態と有効になっている状態は異なります。ルールを含む設定をインポートする前に、ポリシー参照、最終ルール、DNS設定を読み、追加のルールリソースに依存していないか確認します。設定が存在しないポリシーを参照している場合、ファイルを開けるだけでルーティングの設定が完成しているとは限りません。次の章では、ルールとGlobal Routingの連携を説明します。

この章の完了条件は、判別できるサーバー項目がリストにあり、その入手元が分かっていて、主要なパラメーターを元資料と照合でき、サブスクリプションの更新結果を確認できることです。最後にデフォルトサーバーを個別に選択してください。編集を終えただけで選択済みだと判断しないでください。利用可能なパラメーターを退避用に保存してからルーティング設定に進むと、インポートの問題と振り分けの問題を分けて対処できます。

3つのルーティング方式とルールの順序

Global RoutingにはConfig、Proxy、Directの3つの方式があります。接続のルーティング判断を切り替えるもので、サーバーのパスワードを補ったり、リモートサービスの障害を修復したりする機能ではありません。問題を調べる前に、現在の方式を確認してください。特に「サーバーのテスト結果はあるのに、特定のアプリで想定どおりアクセスできない」場合は、デフォルトサーバーではなく、ルールによって別のポリシーが選ばれている可能性があります。

通信経路の判断元を確認する

Configは接続先ごとに処理を分けるのに適していますが、現在の設定内容が明確であることが前提です。Proxyはプロキシ経路の基本的な利用可否を確認するのに使えますが、すべての特殊な通信やシステム動作が同じ結果になるとは限りません。Directもアプリの停止を意味しません。現在の接続を終了するには接続スイッチを使います。ルーティングの影響を比較する場合にGlobal Routingを切り替えてください。

ルールを上から順に確認する

ルールは通常、上から順に評価され、最初に一致した適用ルールでポリシーが決まります。具体的な条件を前に、範囲の広い条件を後ろに置き、最後にFINALで一致しなかった通信を処理します。広範囲のルールを早い位置に置くと、後続の詳細なルールが評価されない場合があります。問題を調べるときは、ドメインがルールに含まれているかだけでなく、その前にあるルールと、各ルールが参照するポリシーも確認してください。

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

これは構文の例であり、あらゆる環境に適用できる完成済みの設定ではありません。DOMAINは指定したドメイン、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはドメイン内のキーワード、IP-CIDRはIPアドレスの範囲に一致します。GEOIPは対応するIPデータに依存するため、判定結果だけで接続先のサービス所属を確定できるわけではありません。FINALは最後のフォールバックであり、想定するデフォルトの通信経路と一致させる必要があります。

この例では、完全一致のドメインルールがキーワードルールより前にあります。そのため、キーワードにexampleが含まれるからといって、関連するすべてのリクエストがDirectになるとは限りません。ドメインルールとIPアドレスルールでは判定対象が異なり、実際の接続から取得できる情報も一致結果に影響します。ブラウザーのアドレスバーに表示されたページ名だけで、そのページのすべてのリクエストが単一のドメインに関係すると判断しないでください。

ルール・ポリシー・現在の設定を区別する

PROXY、DIRECT、REJECTはルールで使われる代表的なポリシーキーワードで、それぞれ役割が異なります。ルールが独自のポリシー名を参照している場合は、定義が存在することと、そのポリシーで最終的にどのサーバーを使うかを確認してください。ファイルの構文が正しく見えても、ポリシー名の綴りが異なれば想定どおりに動作しない場合があります。変更時は大文字・小文字、区切り記号、項目の順序を保ち、半角カンマを全角カンマに置き換えないでください。

Configには複数のファイルを保存できる場合があります。ファイルを編集したら、まず保存し、現在使用中のファイルが編集したものか確認してから、アプリの案内に従って新しい設定を接続に適用します。ファイル名を変更してもルールの内容は変わりません。また、リモート設定の更新でローカルの変更が上書きされる場合があります。長期間使う独自ルールは、どこで管理するかを明確にし、更新前にコピーを保存してください。入手元が分からないファイルに変更をすべて詰め込むのは避けましょう。

特定の接続先だけに問題がある場合は、ProxyとConfigの結果を一時的に比較してください。プロキシ経路では正常でConfigでは異常なら、ルールとポリシーを確認します。どちらも異常なら、サーバーとリモート側の条件に戻って調べます。比較後は必要な方式に戻し、一時的な確認状態を恒常設定として残さないでください。テストごとに変更する条件は一つにし、変化を記録すると原因を追いやすくなります。

ルールの一致は、一度設定すれば常に同じ結果になるとは限りません。接続先のサービスが複数のドメインやアドレス、接続方式を使う場合があり、設定の更新でルールの順序が変わることもあります。実際の利用状況で検証し、例のルールが存在するだけで確認を終えないでください。DNSやアドレス判定が関係する場合は第7章もご覧ください。よくある現象の説明はよくある質問をご確認ください。

接続確認と段階的なトラブルシューティング

接続の成否は段階ごとに判断します。基本ネットワークが使えること、サーバーパラメーターが有効であること、システムが接続を許可していること、現在のルーティングが想定どおりであること、目的の接続先へのリクエストが完了することをそれぞれ確認してください。どの段階に問題があっても「接続できない」と表示される可能性がありますが、対処方法は異なります。スイッチが維持できない、テストがタイムアウトする、特定の接続先だけ失敗する、ネットワーク切り替え後に異常が出るなど、現象を具体的に記録してから該当する確認手順を選びます。

再現可能な接続手順を確立する

まず、現在のWi-Fiまたはモバイル通信で通常のインターネット接続ができることを確認します。ネットワークの利用開始に認証が必要な場合は、先にその手続きを済ませてください。その後Homeに戻り、SERVERリストから確認するサーバーを選び、デフォルトの選択マークが目的の項目にあることを確認します。項目をタップして詳細を開く操作を、デフォルト選択の完了と取り違えないでください。グループが異なれば、同じ名前のサーバーがある場合もあります。

次にGlobal Routingを確認します。初回の検証では、明確なプロキシ経路を選んでから接続を開始し、表示に従ってシステム権限を設定します。状態が安定したらConnectivity Testを実行し、ブラウザーまたは実際に使うアプリから新しいリクエストを送信します。デフォルト選択から初回テストまでの手順は、初回接続とテストの説明をご覧ください。

テスト中はネットワーク、サーバー、接続先をできるだけ固定し、1回の操作で複数を変更しないでください。ページがキャッシュされていたり、アプリが以前の接続を保持していたりする場合があります。結果を見る際は、新しいリクエストが実際に発生したか確認しましょう。一度読み込んだページを表示しただけでは、キャッシュを通信成功と誤認するおそれがあります。明確な操作を改めて実行し、接続記録に目的の接続先に対応する新しい通信があるか確認してください。

テスト結果と実際のアクセス結果を区別する

Connectivity Testの結果は、現在のテスト条件における接続状況を示すもので、リモートのすべてのサービスを完全に検証するものではありません。テスト結果があるのに目的の接続先へアクセスできない場合は、接続先、DNS、ルール、アプリが使用する接続方式などが関係している可能性があります。テストがタイムアウトしても、保存済みのすべての項目に誤りがあるとは限りません。まずほかの既存サーバーを試し、同じサーバーを別の基本ネットワークで使った場合と比較すると、問題の範囲を絞り込めます。

接続スイッチがすぐオフになる場合は、アプリのメッセージとシステムのVPN状態を確認し、権限と設定の有効性を調べてください。スイッチがオンのままでもすべてのリクエストに失敗する場合は、デフォルトサーバー、プロトコル、ポート、認証情報を確認してから、リモートサービスの状態を調べます。Configだけで失敗する場合は、有効なファイルとルールのポリシーを確認します。特定のアプリだけで異常が起きる場合は、すべての設定をリセットする前に、そのアプリに関係するドメインとリクエストを調べてください。

一時的な中断と、安定して再現する異常も区別してください。画面ロックからの復帰、ネットワークの切り替え、リモート接続の再確立中に、一時的な状態が発生することがあります。現在の処理が終わるまで待ってから、新たにテストしてください。同じ手順で再現する場合は発生条件を記録します。まれにしか起きない現象で、複数の低レベルパラメーターをすぐ変更しないでください。変更を重ねると一時的に問題が見えなくなる一方、再現条件が失われ、後のメンテナンスが難しくなる場合があります。

変更を最小限にして問題の段階を特定する

複数の既存サーバーで異常がある場合は、共通条件を先に確認します。同じ基本ネットワーク、同じ設定ファイル、同じDNS設定、同じシステム制限などです。1つのサーバーだけに異常がある場合は、その項目のパラメーターとリモート側の状態を重点的に確認してください。こうした条件ごとの比較は、手当たり次第に設定を変えるより効果的です。比較用として、利用可能と確認済みの項目を1つ残し、元の値を記録する前に認証パラメーターを上書きしないでください。

TLSまたは認証関連のエラーが発生した場合は、デバイスの時刻、サーバー名の要件、元のパラメーターを確認します。確認の代わりに、検証を安易に無効化しないでください。ドメイン解決エラーでは、サーバーのドメインを解決できないのか、アクセス先のドメイン処理に問題があるのかを判断します。タイムアウトの場合はネットワーク、ポート、リモート側の状態を合わせて調べます。同じエラー表示でも、原因が同じとは限りません。

さらにサポートを求める場合は、個人情報を隠した現象、プロトコルの種類、ネットワークの種類、Global Routingの方式、実施した比較テストを伝えてください。サブスクリプション全体、パスワード、UUID、鍵、クエリパラメーターを含むURLを公開しないでください。エラー表示は原因に関係する部分を残し、サーバーを特定できる情報は伏せます。サービス提供元に連絡する場合は、問題が起きる項目とネットワークを具体的に伝えると、設定全体を送るより状況が分かりやすくなります。

この章を終えると、基本接続が利用可能か、または権限、パラメーター、ルーティング、名前解決、接続先サービスのいずれかに問題を絞り込めます。接続を確認できたら、必要なConfig方式に戻し、よく使う接続先が想定どおりか確認してください。その後Dataで実際の通信量を観察します。1回のテスト結果を、接続品質の長期的な証明と見なさないでください。

通信量の統計と接続の確認

Dataではアプリが表示する通信量や関連する接続状況を確認できます。「通信が発生しているか」「どの操作で変化したか」「集計範囲は何か」といった確認に役立ちます。ただし、サービス提供元のアカウント上の利用記録とは別の計測システムです。数値を読む前に、画面に表示された期間、集計対象、単位を確認してください。集計範囲の異なる数値をそのまま差し引かず、増加が異常かどうか判断しましょう。

統計の対象範囲を確認してから比較する

アップロードとダウンロードはデータ転送の方向を示します。瞬間的な速度と累計データ量も異なります。速度は一定時間内の転送速度を表し、累計量は該当範囲で転送されたデータの総量を示します。画面上の瞬間的な変化から月間使用量を直接推定することはできません。また、ある時間帯に目立った速度が表示されなくても、それ以前にバックグラウンド通信がなかったとは限りません。観察した時間と操作内容を合わせて結果を読み取ってください。

アプリの統計、システムのモバイルデータ統計、サービス提供元の記録は、計測範囲、セッション、更新タイミング、プロトコルのオーバーヘッドが異なるため、数値に差が出る場合があります。サービスの利用容量を確認する際は、利用中のサービスのアカウント記録と計測方法を基準にしてください。数値が一致しない場合は、同じ期間、同じデバイス、同じ接続範囲を比べているか確認します。差があるというだけで、どちらかの記録に誤りがあると判断しないでください。

統計をリセットまたは消去する場合は、必要な観察結果を先に保存し、どのローカル記録に影響する操作か確認してください。アプリの数値をリセットしても、リモートアカウントの利用容量は戻らず、すでに発生した通信量も変わりません。数値をゼロにするために何度も消去すると、期間をまたいだ比較の基準が失われます。長期間記録する場合は、日時、ネットワーク、利用状況も合わせて記録してください。

1つの操作で通信量の変化を確認する

特定の操作で想定した通信が発生するか確認する場合は、まず現在の数値を記録し、ほかのアプリの動作を一時的に減らしてから、ページの再読み込みなど範囲が明確な操作を1つ行います。操作後にDataを開き、該当する記録の変化を比較してください。メディアの再生、写真の同期、アプリのアップデートを同時に行うと、増加分を特定のページに結びつけられず、単独の数値では問題を調べにくくなります。

バックグラウンド同期、通知、アプリ独自の更新でも通信が発生するため、ユーザーが操作していないからといって、デバイスがネットワークを利用していないとは限りません。通信量が増え続ける場合は、接続記録を調べる前に、システムやアプリで実行中の処理を確認してください。メディアのキャッシュや先読みで、画面上に見えている内容より多くのデータが転送される場合もあります。こうした現象は利用状況と合わせて判断します。

ルールに従って正しく振り分けられているかを確認する場合、通信量の増加から分かるのは転送があったことだけで、想定したルールに一致した証明にはなりません。具体的な接続先、接続記録、ルーティングポリシーを照合してください。特にConfigでは、1つのページの読み込みで複数のドメインにリクエストが送られ、それぞれ異なるポリシーに一致する場合があります。通信量の合計は第4章のルール確認の代わりにはならず、アプリ全体が常に同じ経路を使うと断定する根拠にもなりません。

接続情報を確認し、記録を保護する

アプリ内の接続情報に接続先、ポリシー、エラーなどが表示される場合は、具体的なリクエスト単位で確認します。まず操作した時刻を特定し、該当する接続先を探して、使用されたポリシーと結果を確認してください。リストの先頭の行が直前に開いたページに対応すると決めつけないでください。バックグラウンドのリクエストが同時に記録される場合があります。接続先が共有ドメインやアドレスを使う場合も、名前の一部だけでどのアプリの通信か判断できません。

接続記録にはアクセスしたドメイン、アドレス、時刻、その他のネットワーク情報が含まれる場合があります。書き出しやスクリーンショットを撮る前に内容を確認してください。問題を共有する際は、関連する少数の項目だけを残し、個人のサービス情報や認証情報を隠します。ログ全体から無関係な通信まで分かる場合は、エラー発生時刻と必要な項目だけを抜き出してください。トラブルシューティングに必要なのは、可能な限り多くの生データではなく、明確な状況です。

失敗した接続が大量に続く場合は、同じ接続先、ポリシー、時刻に集中しているか確認します。同じ接続先への再試行で記録が急増することがありますが、同じ規模の有効なデータ転送が発生したとは限りません。記録件数だけで接続の負荷を判断せず、接続先とルーティングの問題に戻って確認してください。件数とデータ量を比較できるのは、統計の対象範囲を確認した後です。

観察が終わったら、一時的なテストと日常利用の記録を分けてください。長期的なメンテナンスでは、主な異常、変更前後の結果、必要な基準値を残せば十分です。Dataに正常な通信が表示されても接続先に問題がある場合は、応答が成功したか、内容が完全か、アプリが正常かを引き続き確認してください。通信があったことから分かるのは経路上で通信が発生したことだけで、サービスのリクエストが完了したとは限りません。

基本設定と自動接続

Settingsを変更する前に、まず手動接続が利用できることを確認します。解決したい問題を明確にし、対応する設定だけを変更して元の値を記録してください。アプリ設定、現在の設定ファイル、システムのネットワーク設定が同じ接続に影響する場合があるため、調査時はどの層を変更したか明記します。「DNSを変えた」「自動接続を有効にした」だけではなく、変更した場所、元の状態、確認結果も記録してください。

DNS：名前解決の場所を確認する

DNSはドメイン名を、後続の接続に必要なアドレス情報へ変換します。接続エラーは、名前解決の前、処理中、アドレス取得後のいずれでも発生するため、DNSの変更ですべてのタイムアウトを解決できるわけではありません。まず解決できないのがサーバーのドメインか、アクセス先のドメインかを確認し、現在の設定にある関連項目を調べてください。サーバーアドレスを解決できない場合は接続先が確定していません。アクセス先の名前解決に問題がある場合は、現在のルーティングと名前解決の経路も確認します。

システムDNS、カスタムDNS、DNS over HTTPSでは利用方法が異なります。現在のネットワークとDNSサービスへの到達性を考慮して選択してください。暗号化通信は名前解決リクエストの転送方式を示すもので、どのネットワークでも必ず適しているとは限りません。DNS設定を変更したら、同じ接続先とサーバーを使って結果を比較します。ネットワークも同時に切り替えると、原因を判断しにくくなります。詳しくはDNS設定の比較をご覧ください。

[General]
dns-server = system

この例は、設定ファイル内でシステムDNSを指定する場所を示したもので、完成済みの設定でも、すべての環境に共通する設定でもありません。Generalセクションに記述し、Ruleセクションには入れないでください。同じ名前の設定がすでにある場合は、元の値と関連項目を読んでから変更方法を決めます。重複した定義は内容の把握を難しくする場合があります。保存後は有効なファイルを確認し、アプリの案内に従って接続を再検証してください。

キャッシュがあると、短時間の比較に影響する場合があります。同じ接続先で以前に取得した結果が再利用されたり、アプリが既存の接続を使い続けたりすることがあります。設定変更後すぐに古いページが表示されても、反映されていないとは限りません。新しいリクエストと接続記録を合わせて確認してください。1つの接続先だけに問題がある場合は、その記録とルールを確認し、すべての名前解決方式を複雑な別設定に置き換えないでください。

On Demand：手動接続を確認してから自動化する

On Demandは、設定した条件に応じて接続の開始を管理します。サーバーの状態を修復する機能でも、初回の手動での許可を代替する機能でもありません。有効にする前に、選択中のサーバーが使えること、Configが想定どおりに動くことを確認し、アプリに表示される条件を読んでください。内容を説明できる条件だけを追加し、その条件に合う場合と合わない場合の両方で状態を確認します。自動接続が予想と異なるのに原因が分からなくなる事態を避けてください。

自動接続を確認する際は、現在のネットワーク、接続状態、きっかけとなる操作を記録します。たとえばネットワーク変更後に、設定したとおりの状態になるかを確認し、続けて実際のアクセスを検証してください。スイッチが再びオンになっただけで、リモート接続に成功したとは判断できません。手動で切断した後に接続が戻る場合は、システム構成を何度も削除するのではなく、On Demandが有効か、現在の条件が再度成立したかを確認します。

接続関連のオプションと変更時のルール

プロトコルのTLS、転送方式、その他のパラメーターは、利用中のサービスの要件に従って設定してください。汎用的な最適化スイッチのように自由に調整するものではありません。互換性の問題を解決したい場合は、まずサーバー側の対応範囲を確認します。エラーを調べる場合は、元のパラメーターを保管し、エラーの変化を記録してください。ネットワークに関係する名前だからといってオプションを有効にすると、成立していた接続条件が変わり、新旧の問題が混在する場合があります。

設定ファイルと画面上に関連項目が表示されても、すべての項目に同じ優先順位が適用されると決めつけないでください。現在のファイル、アプリの説明、実際の接続結果を確認し、どの設定が有効か特定します。リモート設定の更新後は、以前必要だった項目が残っているかも確認してください。用途が分からないオプションは、確認済みの状態を維持するほうが一括変更より管理しやすくなります。変更が必要な場合は、コピーを使って範囲を限定して検証してください。

変更のたびに「元の値・目的・結果・戻し方」の4点を記録します。目的は「速度を上げたい」ではなく、「特定のドメインが名前解決できるか」など具体的にしてください。結果は再現可能な形で記録し、一瞬ページが読み込まれた感覚だけで判断しないでください。改善しない場合は、次の設定を試す前に元の値へ戻します。理由の分からない設定が積み重なるのを防ぎ、次章のメンテナンスにも明確な基準を残せます。

バックアップ・アップデート・日常のメンテナンス

日常のメンテナンスでは、説明できて復元可能な動作状態を保つことを目指します。設定をむやみに増やす必要はありません。現在のデフォルトサーバー、サブスクリプションの入手元、有効なConfig、Global Routing方式、自動接続の条件を把握してください。異常が起きた際に最近の変更を特定しやすくなり、機種変更時の復元項目にもなります。アプリのスクリーンショット1枚だけでは、通常、状態を完全に再現できません。

サーバー・サブスクリプション・設定を分けてバックアップする

バックアップ前に対象を区別してください。サーバーパラメーターは接続先と認証方式を定め、サブスクリプションリンクはサーバーリストの再取得に使い、設定ファイルはルーティングや関連設定を保存します。1種類の書き出しデータにほかのすべてが含まれるとは限らないため、バックアップの内容を実際に確認してください。アプリが提供する書き出し・バックアップ機能を使う場合は、操作説明を読み、機密情報が含まれるか、復元にアカウントなどの条件が必要かを確認します。

バックアップは、自分で管理できる保護された場所に保存し、公開リンクで共有しないでください。サブスクリプションURL、パスワード、UUID、鍵はすべて機密情報として扱います。どの設定や利用状況に対応するバックアップか分かるように説明を付けます。ただし、ファイル名に認証情報をそのまま記載しないでください。サービス情報が変更されている場合、古いバックアップは使えない可能性があります。復元時に誤用しないよう、必要な履歴情報を残してください。

機種変更の前に、一度復元の予行演習をしておくと安心です。元の購入履歴を見つけられること、既存のサブスクリプションやサーバー情報を確認できること、設定ファイルのポリシー参照を読み取れることを確認します。利用中のデータを削除する必要はありません。コピーを使って確認できます。重要なのは、以前書き出したことを覚えているだけでなく、復元に必要な情報が実際に残っていると確かめることです。デバイスを失くしてから、端末内にしかないリンクを探しても復元できない場合があります。

アップデート後は決まった順番で確認する

アップデートには、アプリ、サブスクリプション、設定の3種類があります。アプリの更新はApp Storeで管理され、サブスクリプションの更新でサーバーリストが変わる場合があり、設定の更新でルール、ポリシー、名前解決の設定が変わる場合があります。原因を特定しにくくなるため、一度のトラブルシューティングで3種類をまとめて更新しないでください。各更新後に基本接続とよく使う接続先を確認してから、次のメンテナンスに進みます。

サブスクリプションを更新したら、まずデフォルトサーバーが残っているか確認し、次にグループや項目の変化を調べます。設定を更新したら、有効なファイル、最終ルール、カスタムポリシーを確認し、ローカルの変更が保持されているか確認します。アプリを更新した場合は、権限、接続スイッチ、自動接続の条件を再確認してください。すべてのWebサイトを確認する必要はありませんが、日常的に必要な接続先と、LANなど直接接続が必要な利用場面を確認しましょう。

問題が見つかったら、まず直近に記録した変更を1つ戻します。サブスクリプションの内容が変わった場合は、古い項目で新しいリスト全体を上書きせず、元のサービス提供元に状態を確認してください。ルールの変更で異常が起きた場合は、保存したコピーと差分を比較します。ロールバックは既知の状態を復元し、原因を特定するためのものです。古い設定を無期限に使えるという意味ではありません。リモートで無効になったサーバーは、ローカルで以前の状態に戻しても再び利用できるようにはなりません。

設定を整理してトラブルの記録を残す

重複したサブスクリプション、用途不明の設定、使われていない項目は定期的に整理します。ただし、削除前に現在も利用されているか確認してください。同じ名前のファイルやサーバーは、名前だけで有効な項目を削除しないよう特に注意します。テスト用と日常用の設定は、用途や入手元が分かるメモで区別し、コピーごとに分かりにくい連番を付けるのは避けてください。明確な目的がある少数の復元用コピーを保管するほうが、過去のファイルをすべて残すより管理しやすくなります。

トラブルの記録には、判断に必要な情報だけを残します。発生条件、エラー内容、デフォルトサーバーの種類、ルーティング方式、直近の変更、比較テストの結果を記録し、サブスクリプションの認証情報や個人のアクセス情報は削除してください。変更で問題が解決した場合は、最終的に残した設定を記録し、不要になった一時的な試行は整理します。数週間後に「いろいろ変更した」としか分からず、原因を追えなくなるのを防ぎます。

再インストールが必要な場合は、まず接続を停止し、On Demandの状態を確認してから、データが保存されていることを確かめ、App Storeから再入手してください。インストール後は、本マニュアルの順に復元します。権限を設定し、既存情報をインポートし、デフォルトサーバーを選択し、設定を有効にして接続を確認してから、自動接続を再設定します。過去のファイルをすべて一度に読み込んで即座に接続すると、重複項目や古いルールによって同じ問題が再発する場合があります。

これで日常のメンテナンスは、「基準状態を保つ、1つずつ変更する、段階ごとに確認する、結果を記録する、必要なら元に戻す」という流れになります。接続手順をもう一度簡単に確認する場合は使い方ガイドをご覧ください。購入やインポートに関する疑問はよくある質問で確認できます。App Store上の正規性や購入済みアプリの復元は、App Storeからの正規入手と復元方法をご覧ください。本ページでは各段階の範囲を解説します。実際のパラメーターは、アプリ内の選択肢と利用者がすでにお持ちのサービス情報に従ってください。