Shadowrocket
使い方完全ガイド

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

まずアプリが正しいかを確認し、その後に購入します。ShadowrocketはAppleプラットフォーム向けの有料アプリで、入手先はApp Storeのみです。App Storeを開く前に、正規品の確認方法を読み、デベロッパ名、公式アイコン、アプリIDを照合してください。検索結果に表示された名前や似た画像だけでは判別できません。製品詳細ページを開き、複数の項目を照らし合わせて確認したうえで、購入手続きを進めてください。

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

デベロッパ名はShadow Launch Technology Limited、アプリIDは932747118です。製品ページのURLにあるid932747118からもアプリIDを確認できます。アイコンは、本サイトに掲載している公式アイコンと同じ、白地に青紫の縁取りがあるデザインです。この3項目を組み合わせてアプリを識別してください。検索順位や名前に付いた説明、画像内の宣伝文句を確認の代わりにしないでください。対象を確認したら、価格、互換性、購入ボタンを確認します。

価格、互換性、アップデート履歴、購入に関する説明は、App Storeの製品ページを確認してください。デバイス要件は変更される場合があるため、本文では最低システムバージョンを固定していません。本ガイドでは主にiPhoneとiPadを扱います。Mac、Apple TV、Apple Visionで利用できるかどうかも、同じ製品ページの互換性欄で確認してください。システム要件とユニバーサル購入の適用条件は、App Storeの表示に従ってください。

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

買い切りとはアプリの購入方法を指し、サーバー、Subscribeのリンク、通信サービスが付属するという意味ではありません。購入後も、自分のサーバー情報を用意するか、利用中のサービス提供元からSubscribeを取得する必要があります。アプリを起動できるか、購入が完了したか、サーバーに接続できるかは、それぞれ別の確認事項です。たとえばアプリをインストールできても一覧が空の場合は、追加の手順が必要です。それだけで購入が無効とは判断できません。

価格は購入確認画面に表示される現地通貨の金額をご確認ください。米国ストアの参考価格は2.99米ドルですが、最終的にはApp Storeの表示が優先されます。アカウントの国または地域、支払い条件、ストア上の表示は、Appleの購入手続きで確認します。購入を完了できない場合は、まずシステムに表示された具体的な案内を確認してください。Shadowrocketのネットワーク設定を繰り返し変更しても、ストアアカウントや決済の問題は解決できません。

購入済みアプリの再入手・再インストール・デバイス移行

過去に購入したことがある場合は、App Storeで以前購入したときのアカウントを使用しているか確認し、購入済みアプリの一覧からShadowrocketを探してください。製品ページに価格が表示されていても、すぐに再購入せず、まずアカウント、購入履歴、ストアの案内を確認します。購入済みアプリの表示名や場所はシステムのバージョンによって異なる場合があるため、デバイスの現在の表示に従ってください。他のデバイスで入手できるかどうかは、そのデバイスの互換性とストアに記載された条件も確認します。

アプリの再入手とアプリ内データの復元は別の手順です。ストアで確認できるのはアプリの購入資格であり、以前のSubscribe、設定ファイル、カスタムルール、通信記録が残っているかどうかは、デバイスの移行やバックアップからの復元状況によります。アプリを削除する前に必要なデータを保存してください。「購入済み一覧から再入手できる」ことを「すべての設定が自動で戻る」と解釈しないでください。ファミリー共有が利用できるかは、製品ページとAppleアカウントの実際の表示で確認してください。設定の追加手順から利用可否を推測することはできません。

アプリのアップデートもApp Storeから行います。アップデート前に、現在動作しているサーバーと設定を記録し、アップデート後は本マニュアルの第5章に沿って接続を再確認してください。購入済みアプリの再入手に関する質問は、購入済みアプリの復元と価格と買い切りについてをご覧ください。本章ではアプリの識別と購入の範囲を扱います。接続の設定は後の章で説明します。問題をそれぞれの段階に分けることで、誤った箇所で試行を繰り返すのを防げます。

2. 初回起動とシステムのアクセス許可

初回起動時は、すべての設定を変更する前に各操作エリアを確認します。Homeではサーバーの一覧、接続先の選択、接続スイッチの操作を行います。Configは設定ファイルの管理、Dataは通信量と接続関連の記録、Settingsはアプリの設定に使用します。画面のレイアウトはデバイスによって異なる場合があります。英語表記の意味を確認する際は、画面上の英語用語一覧も参照してください。アイコンの形だけで操作場所を判断しないでください。

VPN構成の許可が求められるタイミング

アプリが接続を開始するとき、システムからVPN構成の追加を許可するよう求められることがあります。このダイアログはネットワーク拡張機能の構成に関するシステムの許可であり、新しいサーバーや別のサービスを追加するものではありません。現在使用中のShadowrocketから表示されたことを確認し、システムの指示に従って認証を完了してください。許可後も、接続可能なサーバー情報と適切な動作モードが必要です。許可だけでは、これらの準備の代わりになりません。

許可ダイアログを閉じた場合は、アプリに戻って接続スイッチの状態を確認し、通常の接続手順をもう一度行ってください。どの操作で通知が出たか分からなくならないよう、スイッチを素早く連続してタップしないでください。システムに構成の管理制限や追加不可と表示された場合は、まずデバイスの関連設定と管理状態を確認します。管理対象のデバイスでは、アプリ内の操作だけで制限を解除できないことがあります。トラブルの記録には、許可に関する問題とまとめず、表示されたメッセージをそのまま残してください。

操作に必要なアクセス許可だけを与える

Scan QR Codeを使うとき、カメラへのアクセス許可を求められる場合があります。自分の接続情報をカメラで読み取る場合にのみ許可してください。カメラへのアクセスを拒否しても、サーバーを手動で追加したり、既存のSubscribeを追加したりできます。後からQRコードを読み取る場合は、システムのアプリ別アクセス許可設定で確認できます。画面内に複数のQRコードがある場合は、読み取り結果が意図した接続情報であることを確認してください。

クリップボードからリンクを貼り付けるとき、ファイルから設定を選ぶとき、または別の方法で追加するときにも、対応するシステムの確認が表示されることがあります。実行中の操作に合わせて許可内容を確認してください。貼り付け中なら貼り付け要求、ファイル選択中ならファイルの保存場所を確認します。「事前に準備しておく」ためだけに、現在の作業と無関係なアクセス許可を有効にする必要はありません。追加できなかった場合は、システムの選択画面をキャンセルしていないか確認してから、データの形式を確認してください。

システムの接続状態とアプリの状態を分けて確認する

システムにVPN接続中と表示されても、ネットワーク構成が接続状態にあることを示すだけで、リモートサーバー、DNS、接続先のWebサイトが正常であるとは限りません。反対に、Homeで有効なサーバーが選択されていなければ、VPN構成の追加が許可されていても、意図したプロキシ接続はできません。初回は「情報を追加済み」「接続先を選択済み」「モードを確認済み」「スイッチをオン」の順に確認し、単一のステータス表示だけで結論を出さないでください。

デバイスでネットワーク拡張機能を使うアプリやシステム構成がほかにも動作している場合は、実際に接続を処理している対象を確認してください。一度のテストで複数のネットワークツールとシステム設定を同時に切り替えると、構成変更による切断をShadowrocketの設定ミスと誤認しやすくなります。用途の分からないシステム構成は、すぐに削除しないでください。名前、提供元、デバイスの管理条件を確認してから、無効化するか管理者に相談するかを判断します。

初回利用時の確認基準を記録する

初回起動時は、Homeが正常に表示されるか、VPN構成の追加に成功したか、現在Wi-Fiとモバイル通信のどちらを使っているかの3点を記録しておくと便利です。パスワードやSubscribeの完全なURLを記録する必要はありません。この基本情報があれば、問題がアプリの起動前、システムの許可、リモート接続のどの段階で発生したかを判断しやすくなります。アプリを正常に開けるのに通信できない場合は、何度も再インストールするより、接続情報を確認するほうが有効です。

アクセス許可の設定後もサーバー一覧が空の場合は、次の章に進み、手元にある情報を追加してください。一覧が復元された場合も、古いデバイスの状態をそのまま当てにせず、選択中のサーバーとGlobal Routingを確認します。デバイスの移行で一部データが残っていても、ネットワーク環境とシステムの許可は新しいデバイスで確認が必要です。初回起動の目的は、操作の出発点を明確にすることであり、すべての詳細設定を一度に完了することではありません。

3. 既存サーバーとSubscribeの追加

追加する前に、3種類の情報を区別してください。個別のサーバーパラメータは接続先を1件登録するための情報、SubscribeのURLはサーバー一覧を取得・更新するための情報、設定ファイルはDNSやルールなどの動作設定を記述するファイルです。これらが同じ案内に記載されていることもありますが、用途は異なります。サーバーの入力欄にSubscribeのURLを入力したり、設定ファイルをサーバーのパスワードとして扱ったりしても、正しく設定できません。まず情報の種類を確認し、適切な追加方法を選んでください。

Add Serverから手動で入力する

Add Serverで追加するときは、まず手元の情報と一致するTypeを選択し、アドレス、ポート、認証情報を入力します。アドレス欄には指定されたサーバーのホスト名またはアドレスだけを入力し、プロトコルの接頭辞を含むURL全体を通常のアドレス欄に貼り付けないでください。入力後は項目ごとに照合し、コピー時に混入した前後の空白、全角記号、英字の大文字・小文字を特に確認します。保存に成功した時点では登録が完了しただけで、接続の確認は別途必要です。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard、HTTP、SOCKS5では、入力項目がすべて同じではありません。あるプロトコルでパスワードが必要だからといって、別のプロトコルにも同じ情報を入力するとは限りません。UUID、鍵、TLS名、トランスポートのパスが必要な場合は、対応する項目に入力してください。手元の情報に説明がない詳細項目は、別のプロトコルの設定例を流用せず、利用中のサービス提供元に確認してください。

SubscribeのURLとグループの更新

利用中のSubscribeは、自分のサービス提供元から取得し、アプリに対応する追加画面で登録してください。Add ServerのSubscribeタイプを使う場合は、画面の指示に従ってURLと識別しやすい名前を入力します。保存後に更新を実行し、想定したサーバーが表示されることを確認してください。Subscribeの取得成功とサーバーへの接続成功は、別々の確認です。前者では一覧を取得できるか、後者では一覧にある個別の接続情報が使えるかを確認します。

Subscribeの更新に失敗した場合は、まずURLが完全か、改行が含まれていないか、現在のネットワークからURLにアクセスできるかを確認します。応答がログインページ、案内ページ、または非対応のデータであれば、アプリがサーバー一覧を作成できないことがあります。利用中のサービスの期限切れ、リンクの変更、認証情報の無効化も更新に影響します。アプリに表示されたエラーとサービス提供元が示すSubscribeの状態を照合し、一覧の件数が変わっただけで削除や再登録を繰り返さないでください。

QRコード・リンク・設定ファイルの追加範囲

Scan QR Codeは、手元にある自分のQRコード情報を追加するときに使います。読み取り後も、Type、名前、主要なパラメータが想定どおりか確認してください。QRコードは情報を伝える形式にすぎず、内容の正確性や有効性を保証するものではありません。リンクから追加する場合も同様です。アクセス情報を含むQRコード、Subscribeの完全なURL、共有リンクは機密情報として扱い、公開画像、コメント、トラブル記録に載せないでください。

Config内の設定ファイルと、Subscribeの更新で取得するサーバー一覧は、別々に管理してください。ルールを含むファイルを追加した後は、それが現在使用中の設定として選択されているか確認します。Subscribeを更新した後も、既定のサーバーが一覧に残っているかを確認してください。情報によってはサーバーと設定の両方を含むことがありますが、拡張子やファイル名だけで用途を決めず、アプリが実際に認識した内容を確認してください。

追加後はHomeに戻り、サーバーを1件選択して、左側の選択マークを確認してください。編集画面を開いただけでは選択したことになりません。似た名前の項目を誤って選びやすいため、自分で追加した記録には用途が分かるメモを付けてもかまいませんが、メモにパスワードを書かないでください。重複項目を整理する場合は、まず所属するグループを確認します。Subscribeから作成された項目は次回更新で再表示されることがあるため、日常の整理では各項目の削除だけでなくSubscribeの提供元も確認してください。

この章を終える目安は、「情報が正しく認識され、現在選択しているサーバーを特定できること」です。登録数の多さではありません。次にGlobal Routingを選び、接続を確認します。Subscribeの更新に問題がある場合は、元のエラーと発生した手順を残してから第8章のメンテナンス方法を確認してください。一覧の取得失敗と個別サーバーへの接続失敗を混同しないようにしましょう。

4. Global Routingとルールの順序

Global Routingは、現在の通信をどのように処理するかを決めます。設定ファイルに従う、プロキシを使う、直接接続するという動作は、画面上ではそれぞれConfig、Proxy、Directと表示されます。ルールによる振り分けを普段使う場合は、通常Configを選びます。ProxyとDirectは、特定の用途や比較テストに使えます。この選択はサーバーや設定ファイルの切り替えとは別です。モード、使用中の設定、選択中の接続先をそれぞれ確認してください。

3つのモードで制御される内容

3つのモードの説明は、アプリのシステムバイパス設定、通信を処理する範囲、個々の設定と併せて確認してください。デバイス上のすべてのシステム通信が同じ経路を通るとは限りません。トラブル時にProxyへ切り替えると、特定の振り分けルールが原因かどうかを比較できますが、すべての接続障害を解決するスイッチではありません。Directに切り替えても、DNS、リモートのWebサイト、現在接続中のネットワークが正常だとは限りません。

.confファイルを順に読む

以下は構文を説明するための設定例であり、すべてのネットワーク環境に適した完成済み設定ではありません。[General]には一般設定、[Rule]にはルールを記述します。ルールは通常上から順に評価され、最初に一致した項目の処理が適用されます。PROXY、DIRECT、REJECTは処理方法を示す値であり、サーバーのプロトコル名ではありません。変更前に元のファイルを保存し、一度に変更するのは1項目だけにしてください。

[General]
bypass-system = true
dns-server = system
skip-proxy = 192.168.0.0/16, localhost

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、example.comと、サフィックス条件に一致するサブドメインが先にDOMAIN-SUFFIXで処理されるため、後続のDOMAIN-KEYWORDには一致しません。対応するキーワードを含むその他のドメインが、次の行に一致する可能性があります。IP-CIDRはアドレス範囲に使い、GEOIPはアドレスの所在地データを基に判定します。FINALは、それ以前のルールに一致しなかった場合の最終処理です。範囲の広いルールを先に置くと、後で個別に処理したい対象に対するルールが適用されなくなることがあります。

ドメインルールとアドレスルールは使い分ける

DOMAINは完全なドメイン名、DOMAIN-SUFFIXはサフィックスの範囲、DOMAIN-KEYWORDはキーワードを含む範囲に一致します。キーワードの範囲は想定より広くなることがあるため、追加時は似た名前で用途の異なる接続先にも影響しないか確認してください。IP-CIDRとIP-CIDR6は、それぞれ対応するIPアドレスの範囲を表し、特定のWebサイトを直接指定するものではありません。同じサービスが複数のドメインやアドレスを使うこともあるため、1つのルールに一致しても、そのページのすべての通信が同じ経路を通るとは限りません。

GEOIPの判定はアドレスの所在地データと実際の名前解決結果に依存します。Webページの表示言語や企業の所在地だけで、ルールに一致するかどうかを判断できません。DNSの結果によって、アドレスルールで認識される接続先が変わることがありますが、DNS設定自体は振り分けルールではありません。USER-AGENTなどの条件を使う場合は、現在のアプリが対応している範囲と取得可能な情報を確認してください。暗号化されたすべてのリクエストを安定して判別できるものとして扱わないでください。

ルール変更後の確認方法

まずGlobal RoutingがConfigになっていることを確認し、次に変更したファイルが現在の設定として選択されていることを確認します。対象を1つ決めてリクエストを送り、参照できる記録でドメイン、適用ルール、処理方針を確認してください。以前の経路が記録されている場合は、設定の再読み込みや接続の再確立が必要か確認します。対象アプリが既存の接続を再利用している可能性にも注意してください。ページが表示されたかどうかだけで新しいルールの適用を判断できません。キャッシュによって正常に見える場合もあります。

ローカルネットワークへの接続に問題がある場合は、実際のアドレス範囲、関連するバイパス設定、ルールの順序を確認してください。公開Webサイトに接続できるかだけでは判断できません。DNSの仕組みはDNS設定ガイドで、用語の概要は用語早見表で確認できます。本章の要点は「モード、設定、ルール、処理方針」の順に確認することです。キーワードだけ覚えても、経路全体の判断の代わりにはなりません。

5. 接続・Connectivity Test・トラブル対処

接続確認は3段階で行います。アプリが接続を確立したか、選択中のサーバーが利用できるか、実際の接続先へのリクエストが想定どおり完了したかです。Home上部のスイッチ、Connectivity Test、実際のアクセスはそれぞれ異なる情報を示し、互いに代用できません。開始前にネットワークが使えること、既存の接続情報が有効であること、サーバーを1件選択していることを確認してください。テスト中にSubscribeの更新、DNSの変更、設定の切り替えを同時に行わないでください。

決まった手順で接続する

Homeで接続先のサーバーを選び、左側の選択マークがその項目に付いていることを確認してから、Global Routingを確認します。接続スイッチをオンにし、システムからVPN構成の許可を求められた場合は、第2章の手順に従ってください。接続状態が安定してからテストを始めます。同じ名前の項目が複数ある場合は、グループとTypeで見分けてください。編集した項目とは別の古い項目に接続してしまう可能性があります。

Connectivity Testを実行し、成功、失敗、タイムアウトなど実際の結果を記録してから、実際のWebサイトにもアクセスします。テスト結果は通常、テスト対象と方法に対応する条件だけを示し、すべての接続先が正常であることを保証しません。テストに失敗しても実際のアクセスができる場合は、テスト対象に個別の接続制限がないか確認してください。逆にテストが成功しても特定のページを開けない場合は、そのページのドメイン、DNS、ルールを調べます。

レイテンシと実際の通信の違い

レイテンシテストは同じ条件で応答時間を比較するためのもので、帯域幅、継続的な安定性、特定コンテンツの表示状況を直接示すものではありません。測定時刻、接続ネットワーク、接続先、測定方法が異なると、数値を単純に比較できません。レイテンシが一度低かっただけでは、認証、トランスポート設定、長時間接続が正常とは限りません。利用中のSubscribeにあるサーバーを比較する際は、レイテンシ・地域・プロトコルの解説を参考にしてください。

接続状況に応じて原因を絞り込む

すべての接続先に失敗する場合は、まず基本ネットワークを確認し、次に選択したサーバーのアドレス、ポート、認証情報、TLSパラメータを確認します。通常のサービスにも接続できない場合は、先にネットワークの問題を解決してください。サーバーが1件だけ失敗する場合は、手元にある別の登録情報を選んで比較できます。別のサーバーに接続できれば調査範囲を絞れますが、1回の結果だけで元のサーバーが恒久的に使えないとは判断できません。

一部の接続先だけ失敗する場合は、対象と発生時刻を記録し、関連するリクエストにどのルールが適用されたかを確認します。Webページはメイン文書、画像、API、認証など複数のドメインを使うことがあります。そのうち1つの経路が正しくなければ、部分的な問題が起きる可能性があります。Proxyへの切り替えは短時間の比較に限り、テスト後は元のモードに戻してください。切り替え後に改善した場合は、振り分けルールと名前解決を確認し、設定全体をすぐに削除しないでください。

ネットワークの切り替え後に接続を再確立する

Wi-Fiからモバイル通信に切り替えた後は、以前の接続を確立し直す必要がある場合があります。デバイスのネットワーク状態が安定するまで待ち、接続スイッチを一度オフにしてから再びオンにし、同じテストを繰り返してください。接続先とサーバーを変えなければ、違いがネットワークに由来するか判断しやすくなります。サーバー、設定、ネットワークを同時に変更すると、接続が回復しても、どの変更が効果をもたらしたか分かりません。

TLSや認証に関するエラーは、手元の情報とデバイスの日付・時刻を1項目ずつ照合してください。証明書の検証を無効にすることを標準的な解決策にしないでください。接続時の検証条件が変わり、ドメイン名や時刻の誤りを隠してしまうおそれがあります。判断できない項目は、利用中のサービス提供元に確認してください。問い合わせるときは、エラーの種類、プロトコル、操作手順、ネットワークの種類を伝えれば十分です。パスワード、鍵、SubscribeのURL全体を公開の記録に含めないでください。

確認を終える際は、現在のネットワーク、選択中のサーバー、Global Routing、使用中の設定、実際のテスト結果を説明できる状態にしてください。この情報があれば、「接続中と表示されるが使えない」という説明よりも原因を判断しやすくなります。次にDataを確認する目的は、直前のリクエストを調べることであり、累計通信量で接続テストの結果を代用することではありません。

6. Dataの通信量とリクエスト記録

Dataでは、アプリが記録した通信量や接続情報を確認できます。「テスト中にリクエストが発生したか」「どの接続先に問題があったか」「ルールに沿った経路になっているか」といった確認に役立ちます。一方、サービス提供元のアカウント明細ではなく、デバイスのすべてのネットワーク通信を記録するものでもありません。数値を解釈する前に、集計対象と期間を確認してください。対象期間の異なる統計を単純に差し引いて、アプリやサービスの問題を推測しないでください。

数値を見る前に集計範囲を確認する

通信量を確認するときは、現在の接続分、特定期間の集計、累計記録のどれが表示されているかを確認し、アップロードとダウンロードも区別してください。再接続、統計のリセット、アプリデータの復元、使用中の設定によって、記録される範囲が変わることがあります。詳細は画面の説明をご確認ください。数値を記録する場合は、測定の開始時刻と終了時刻も一緒に残してください。そうしないと、テストの通信による変化か、その間のバックグラウンド通信によるものか判断しにくくなります。

アプリとサービス提供元では、計測する場所が異なる場合があります。プロトコルのオーバーヘッド、集計方法、接続の再試行、測定時間、単位によって数値に差が生じることがあります。Dataに通信量が記録されていても、サービス提供元のアカウントで同じ数値が課金されるとは限りません。提供元が示す残量を、端末内の累計数値だけから逆算することもできません。利用中のサービスの通信量や有効期間は、サービス提供元のアカウント情報で確認してください。

単独のリクエストで記録を確認する

トラブルの調査中は、同時に行う操作をできるだけ減らしてください。まず現在の状態を記録し、対象を明確にしたアクセスを1回行ってから、Dataで該当時間の変化を確認します。複数のアプリを同時に更新すると、記録にテストと無関係なリクエストが含まれることがあります。システムのバックグラウンド通信も記録されるため、見慣れないドメインがあっても、直前に開いたページのものだとすぐに決めつけないでください。時刻、アクセス先、テストを繰り返した結果を併せて判断します。

現在の画面に接続先のドメイン、アドレス、処理方針、適用ルール、エラー情報が表示される場合は、項目ごとに確認してください。ドメインはアクセス先、処理方針は通信の扱い、エラーは失敗した段階を示します。3つを関連づけて読み取ってください。リクエストにDIRECTが適用されても、それだけでルールが誤っているとは限りません。想定していた処理と異なる場合に、現在の設定で一致したルールを調べます。

記録からルールとDNSを確認する

接続先に想定外の処理方針が適用されている場合は、まずGlobal RoutingがConfigか確認し、次に設定ファイルとルールの優先順を確認します。接続先がアドレスとして記録されている場合は、DNSとアプリ側のアクセス方法も考慮してください。記録に一度現れたアドレスを、そのまま広い範囲のルールに登録しないでください。同じアドレスを複数のサービスが使うことがあり、範囲をむやみに広げると正常な通信にも影響します。

ドメインの名前解決に失敗した場合は、DNSの条件を確認します。アドレスを解決できてもリモート接続がタイムアウトする場合は、サーバー、経路、接続先への到達性を引き続き調べます。2種類の問題は相互に影響することがありますが、対処の順序は異なります。記録されたエラーは原因を探る手がかりです。実際に起きた操作と照らし合わせず、エラーだけで結論を出さないでください。DNSの設定を確認する際は第7章を参照し、Dataの記録を何度も消去しないでください。

リセット、記録の保存、機密情報

統計をリセットすると次の比較を始めやすくなりますが、サーバーの修復、ルールの変更、サービス提供元の計測値のリセットにはなりません。リセットする前に、比較に必要な数値と時刻を保存してください。トラブルを調べる唯一の手がかりを失うおそれがあります。短時間のテストを確認したいだけなら、テスト前後の差分を記録すればよく、毎回すべての履歴を消去する必要はありません。

記録を公開する前に、完全な接続先URL、クエリパラメータ、Subscribeの認証情報、認証フィールド、個人のアクセス情報が含まれていないか確認します。パスワードが画面に写っていなくても、トークンを含むリンクが露出することがあります。問い合わせるときは、必要なフィールドを残してエラーの種類を抜き出し、関係のない個人情報を隠してください。伏せ字にした後も項目同士の関係は分かるようにしてください。DNS、認証、リモート接続のどの問題か判断できなくなるためです。

長期的な変化を確認する場合は、測定する時間帯とテスト方法を固定すると比較しやすくなります。一時的な通信量の増加は通常のバックグラウンド処理によることもあるため、1回の変化だけでSubscribeをすべて追加し直さないでください。問題が繰り返し起きる場合は、ネットワークの切り替え、設定の更新、エラー発生の時刻を簡潔に記録します。操作と結果を結び付けた記録があれば、次章で設定を調整する際にも役立ちます。

7. Settings、DNS、On Demand

Settingsの変更は、明確な目的に沿って行い、すべての項目を一度に変更しないでください。初めて使うときは動作中の設定を基準として残し、その後にDNS、On Demand、診断関連の項目を必要に応じて調整します。アプリの画面にある設定と設定ファイルに記述する項目があるため、現在選択している設定と併せて確認してください。現在の画面にない項目を、別のスクリーンショットの位置から探したり、似た名前で設定したりしないでください。

システムDNSとカスタムDNS

DNSはドメイン名を後続の接続で使うアドレスに変換し、ルールはリクエストの処理方法を決めます。関連はありますが、役割は異なります。dns-server = systemは、その項目でシステムDNS設定を使用するという意味です。これは設定の動作を理解するうえでの手がかりですが、すべてのネットワーク環境で同じ結果になることを保証するものではありません。Wi-Fiとモバイル通信を切り替えると、デバイスが使用する名前解決の条件も変わる場合があります。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

カスタムDNSまたはDNS over HTTPSを使う場合は、まずDNSサービスのアドレスと現在のネットワークからの到達性を確認し、次にアプリが対応する入力形式を確認してください。DNSサービス自体への接続も必要です。接続できない状態で設定を変更すると、より多くの接続先に問題が発生することがあります。DNSの変更はサーバー認証の変更とは異なります。また、暗号化DNSを使えばすべての接続問題が自動的に解決するわけではありません。

変更後は同じ接続先を使って確認し、キャッシュの影響も考慮します。接続先のアプリが以前取得したアドレスや既存の接続を再利用している場合、短時間では変化が見えないことがあります。それだけで設定が適用されていないとは限りません。まず設定が読み込まれていることを確認し、必要に応じて接続を再確立してください。DNS設定を次々に切り替えるのは避けます。詳しくはシステムDNS・カスタムDNS・DNS over HTTPSの解説をご覧ください。

On Demandは接続のトリガーであり、サーバーの修復機能ではありません

On Demandは、設定した条件に応じて接続を開始する機能です。手動接続が安定してから設定してください。ネットワークの種類、Wi-Fi名、ドメインなどの条件は、現在の画面のルールに従って入力し、1つずつ確認します。On Demandが変更するのは接続を開始するタイミングです。誤ったパスワード、期限切れのSubscribe、接続できないサーバーを自動修正するものではありません。手動接続も失敗する場合は、まず接続自体を解決してください。

設定する前に、「指定したネットワーク条件で接続を開始する」など、意図する動作を書き出してください。そのうえで、範囲が重複する条件がないか確認します。複数条件の優先順位を記憶だけで推測せず、アプリ内の説明と実際のテストに基づいて判断してください。条件を満たす環境と満たさない環境の両方で接続を試し、想定どおりに動作するか確認します。1種類のネットワークでしかテストしないと、条件が広すぎないかや、意図しない接続が起きた理由を確認できません。

接続を手動でオフにしてもすぐに戻る場合は、スイッチの故障と判断する前にOn Demandが有効のままか確認してください。トラブルを一時的に調べる場合は、自動接続を停止してから手動接続の基準を作ります。条件を長期的に調整するときは、Wi-Fi・モバイル通信・ドメインに応じたOn Demandの設定を参考にし、接続条件とサーバー情報を同時に変更しないでください。

診断用スイッチと詳細設定の範囲

ログや診断に関する項目は必要な場合だけ有効にし、記録にアクセス先や接続情報が含まれる可能性に注意してください。トラブルの確認後は、必要に応じて元の設定に戻します。記録を増やしても接続が安定するわけではありません。診断情報は原因を判断するために使います。システム時刻、証明書の検証、トランスポートの設定などが接続に影響する場合は、手元のサービス案内に従って確認してください。セキュリティ検証の項目を一般的な速度調整として扱わないでください。

内容を把握していない詳細設定は、まずアプリ内の説明を読み、元の値を記録してから1項目ずつ試します。変更後に問題が起きたら元の値に戻し、同じ方法で再確認してください。「役立つかもしれない」設定を重ねて追加しないでください。設定ファイルに似た項目があっても、現在の動作に影響するか確認が必要です。編集しただけで、その設定がアプリに適用されたとは限りません。設定変更と使用中のファイルを併せて記録してください。

目的が初回接続だけであれば、Settingsですべての詳細設定を完了する必要はありません。まず第5章に戻って接続できることを確認し、その後に必要な設定を1つずつ追加してください。画面上の用語やプロトコルの項目は用語早見表で、3つの動作モードはプロキシモードで確認できます。本章で大切なのは固定の設定値ではなく、変更の目的を検証できるようにすることです。

8. Subscribeの更新・バックアップ・日常のメンテナンス

日常のメンテナンスでは、既存情報の有効性を保つこと、復元できる設定を残すこと、問題の原因を特定できるようにすることの3点を意識します。Subscribeの更新、アプリのアップデート、ルールの変更は別々の操作です。トラブルの調査中にまとめて行わないでください。接続が正常なら、新しい項目を見ただけで設定を変える必要はありません。実際に変更が必要な場合は、現在の状態を記録し、目的に沿った順序で進めてください。

Subscribeの更新前後に確認する

更新前にSubscribeの提供元とグループを確認し、現在選択しているサーバーと使用中の設定を記録します。更新後は、エラーが表示されたか、一覧の内容が想定どおりか、以前選択していたサーバーが残っているかを確認してください。サービス提供元が名前、件数、パラメータを変更することがあります。一覧に変化があっただけでアプリの故障とは限りません。元の項目が置き換わった場合は、利用できる接続先を選び直して、実際に接続できるか確認します。

更新に失敗しても、元のSubscribeをすぐに削除しないでください。ネットワーク、URLの完全性、サービスが有効かどうか、応答内容が認識可能なSubscribeデータであるかを確認します。既存の一覧で接続を続けられる場合もありますが、それだけではSubscribeのURLが有効とは確認できません。反対に、新しい一覧を取得できても、すべてのサーバーが使えるとは限りません。「一覧の取得」と「サーバーの接続確認」を分けて記録すれば、問題が起きた手順をサービス提供元に正確に伝えられます。

バックアップに含める情報

アプリが現在対応している書き出しまたはバックアップの範囲で、必要な設定ファイル、カスタムルール、Subscribeの提供元、手動で追加した情報を保存してください。ルールだけを書き出せばすべてのサーバーも保存されるとは限りません。システム移行でアプリのデータがすべて復元されるとも限りません。バックアップ後は、ファイルの内容と用途を識別できることを確認し、サービス提供元から取得し直す必要がある情報も記録してください。

バックアップにはパスワード、鍵、Subscribeの完全なURL、その他の認証情報が含まれる場合があります。自分でアクセスを管理できる場所に保存してください。問い合わせに使うコピーは、機密情報を個別に取り除いてから作成し、元のバックアップをそのまま公開しないでください。ファイル名に用途やバックアップ日を付けても、認証情報は含めないでください。複数のコピーを保存する場合は、動作確認済みのものを明記し、復元時にテスト用の設定を選ばないようにします。

デバイスの買い替え・再インストール・アプリの更新

デバイスを買い替える場合は、まずApp Storeから購入済みアプリを入手し、データを復元してから、新しいデバイスでVPN構成の許可と接続確認を行います。購入資格、アプリデータ、システムの許可にはそれぞれ別の復元手順があります。1つが完了したからといって、ほかも完了したとは限りません。設定の照合用に古いデバイスをしばらく残してもかまいませんが、同じサービスを両方のデバイスで同時に使えるかは、サービスの利用条件に従ってください。

アプリのアップデート後に動作が変わった場合は、まず現在のサーバー、Global Routing、設定ファイルを確認し、アプリ内の案内とApp Storeのアップデート説明も確認してください。再インストールを最初に行うと、データの復元作業が増え、原因を調べる手がかりも失うおそれがあります。再インストールが必要な場合は、購入時のアカウント、利用可能なバックアップ、必要な認証情報を準備してから実施してください。

復元可能なトラブル対処の順序を作る

まず基本ネットワークを確認し、次にシステムの許可と接続状態、選択中のサーバー、動作モード、使用中の設定、DNS、ルールの順に確認します。各手順で変更するのは1項目だけにし、テスト後に変更を残すか戻すか判断してください。断続的な問題では、すべての操作を繰り返すより、ネットワーク切り替え、デバイスのスリープ、Subscribeの更新、問題の発生時刻を記録するほうが有効です。時間の流れを記録すれば、特定の条件に問題が連動しているかを確認できます。

問い合わせる場合は、デバイスの種類、ネットワークの種類、プロトコル、動作モード、エラーの原文、再現手順を整理してください。アプリのバージョンは、自分のトラブル記録に実際の表示をそのまま記載できます。不確かな情報を推測で補わないでください。機密情報を伏せた必要な項目だけを共有し、Subscribeの完全なURL、パスワード、鍵、個人のアクセス記録は公開しないでください。発生した具体的な手順を説明すると、状況を判断しやすくなります。

以上の手順で、正規購入、アクセス許可、情報の追加、モード選択、接続確認、メンテナンス記録までの一連の流れを確認できます。操作を最初からやり直す場合はクイックスタートガイドへ、購入や復元についてはApp Storeでの正規購入に関する案内のFAQへ、用語を確認する場合は用語早見表へ進んでください。問題を該当する段階に分けて対処すると、すべての異常を「接続できない」とひとまとめにするより、継続的に管理しやすくなります。