Shadowrocketの使い方完全ガイド 初期設定と日常メンテナンス

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

ShadowrocketはApp Store正規版の確認ページから、指定の製品ページを開いて入手してください。検索結果の名称だけでアプリを判断せず、製品名がShadowrocketであることを確認してから、デベロッパ名のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を照合します。アプリIDは製品リンク末尾のid932747118で確認できます。名称が似ていても同じ製品とは限りません。色や検索順位だけで判断せず、これらの項目をまとめて確認してください。

App Storeを開いたら、価格、互換性、購入に関する説明を確認し、システムの購入手続きを進めてください。Shadowrocketは主にiPhoneとiPadで利用します。Mac、Apple TV、Apple Visionへの対応状況も、同じ製品ページの互換性欄で確認できます。システム要件と購入対象の範囲はApp Storeの表示に従ってください。製品ページを開けることだけで、そのデバイスが現在のシステム要件を満たすとは限りません。実際に入手できるかどうかは、使用中のデバイスに対するApp Storeの表示で確認してください。

買い切り購入に含まれるもの

買い切りとはアプリ本体の購入方式であり、接続サービスが継続して提供されるという意味ではありません。米国ストアでの価格は約2.99米ドルですが、実際の価格はApp Storeの表示に従い、各ストアでは現地通貨で表示されます。支払い前に、購入に使用するApple Accountと表示金額を確認してください。購入後も、接続にはユーザー自身が用意したサブスクリプションまたはサーバーの設定値が必要です。アプリの購入履歴はこれらの情報の代わりにはならず、特定のサーバーが現在利用できることを示すものでもありません。2種類の費用と記録を分けて保管すると、機種変更やトラブル対処の際に整理しやすくなります。

サーバー情報には通常、アドレス、ポート、プロトコル、認証情報が含まれます。サブスクリプションは、サーバー一覧を取得するためのアドレスです。設定ファイルにはルール、一部の接続設定、ポリシーの参照情報が含まれます。これらはApp Storeの購入履歴とは役割が異なります。購入履歴はアプリの再入手、サブスクリプションはサーバー一覧の更新、設定ファイルは接続の処理方法に使います。アプリを復元しても、元のサブスクリプション、手入力した内容、ローカルでの変更が新しいデバイスにすべて自動で戻るとは限りません。移行前にデータの保存先とバックアップを確認してください。

初回入手と購入済みアプリの復元手順

初回購入後は、App Storeでダウンロードが完了するまで待ち、デバイスのホーム画面からアプリを開きます。App Storeに購入済みまたは再ダウンロードの表示がある場合は、すぐに再購入せず、まず該当するアカウントを確認してください。機種変更や再入手の際は、購入時のアカウントでApp Storeのアカウントページを開き、購入済みアプリを探します。項目名や表示場所はシステムの画面によって異なる場合があります。見つからないときは、購入履歴、非表示の項目、現在のストアアカウントを確認してから、ストアの地域や購入対象範囲を確認してください。ファミリー共有の対象になるかどうかも、App Storeの説明と実際のアカウント状態に従います。

クラウド同期に使うアカウントと、App Storeでの購入に使うアカウントは異なる場合があります。確認するときは、システム設定の最上部に表示される名前だけでなく、App Storeのアカウントを確認してください。アカウント情報は個人情報です。公開レビューやトラブル対処用のスクリーンショットに載せないでください。購入状況を記録するときは、自分で判別できる範囲の説明にとどめ、アカウントのパスワードは記録しないでください。復元時に支払いやアカウントの制限が発生した場合は、App Storeが案内するアカウント手続きで解決してください。Shadowrocketのルール、プロトコル、DNSを変更しても、ストアでの購入状態は変わりません。

入手後の確認

アプリを開いたら、まずHome、Config、Data、Settingsなどの主要画面を表示できることを確認し、高度なオプションはすぐに変更しないでください。サーバー一覧がまだなくても、購入に失敗したとは限りません。通常は、ユーザー自身の情報をまだインポートしていない状態です。続いて本マニュアルの順に初回の権限設定を行い、サービス情報を入力してください。アプリのアップデートはApp Storeで管理します。更新履歴と適用条件もストアページで確認してください。機種変更時の復元手順は、購入済みアプリからShadowrocketを再入手する方法をご覧ください。

システムの確認ダイアログが表示される理由

Shadowrocketは、接続を処理するためにシステムが提供するネットワーク拡張機能を使用します。接続機能を初めて有効にすると、システムからVPN構成の追加を求められ、デバイスのパスコードや利用可能な認証方法での確認が必要になる場合があります。この操作によってアプリがシステム内にネットワーク構成を作成できるようになります。新しいサービスの購入や、サブスクリプション先への支払いではありません。ダイアログに表示されたアプリ名と操作内容を読み、自分が直前に開始した操作であることを確認してから判断してください。システムのダイアログをすべて同じものとみなし、続けて承認しないでください。

許可は接続準備の一部にすぎません。システムが構成の追加を許可していても、サーバーアドレスの誤り、認証情報の不一致、サービス停止などがあればアクセスできません。反対に、サーバー一覧を正しくインポートしていても、システムが求める構成の許可を省略することはできません。初回利用時は「情報のインポート済み」「構成の作成を許可」「接続開始」「目的のサイトにアクセス成功」を4つの確認項目に分けると、スイッチを1つ見ただけで全工程が完了したと判断せずに済みます。

許可しなかった場合の再開方法

ダイアログをキャンセルした場合は、まずアプリに戻って現在の接続状態を確認します。そのうえで自分で接続を開始し、システムの確認が再び表示されるかを見てください。スイッチを連続して素早く操作すると、許可、起動、停止の処理が重なることがあるため避けてください。再度ダイアログが表示されない場合は、デバイスの設定でVPN関連の構成を探し、Shadowrocketの項目があるか確認します。システムメニューの名称はバージョンによって変わる場合があります。メニューの階層を暗記するのではなく、アプリ名と状態を確認してください。

ネットワーク構成が複数ある場合は、それぞれの用途を先に確認してください。他のVPN接続や管理対象のネットワーク設定が現在の接続に影響する場合があります。自分で管理できる他の接続をいったん停止し、Shadowrocket単独で確認してください。会社や学校の管理対象デバイスには追加の制限がある場合があり、管理者に確認する必要があります。管理設定をむやみに削除して対処しないでください。このアプリのシステム構成の削除も最初に試す方法ではありません。影響を把握し、必要な情報を保存してから検討し、再作成後は改めて許可を完了してください。

初回接続前に環境を整える

接続をテストする際は、認証済みのWi-Fiなど、状態を把握できるネットワークを1つ選んでください。公共Wi-Fiの中には、システムやブラウザで先に接続認証が必要なものがあります。通常のネット接続ができない状態では、クライアントの設定が正しくてもサーバーへ接続できません。まずクライアントの接続を一時停止し、デバイスが通常どおりインターネットに接続できることを確認してから、アプリに戻ってください。初回確認中にWi-Fi、モバイル通信、複数のサーバーを同時に切り替えないでください。失敗した場合に、どの変更が影響したのか分かりにくくなります。

デバイスの日付と時刻も確認してください。TLS接続では証明書の有効期間を検証するため、デバイスの時刻が大きくずれていると、正しい証明書が無効と判定される場合があります。検証要件を緩めて症状を隠すのではなく、まずシステム時刻を修正してください。証明書、デバイス管理、追加のプロファイルに関するシステムの確認が表示されても、クライアントの設定中だからといってすべて承認する必要はありません。通常のサーバー情報やルールのインポートは、出所不明のシステム変更を承認する理由にはなりません。

権限に関する不具合の記録方法

権限の問題は接続開始の前後に起こりやすく、許可が完了しない、構成を作成できない、スイッチが意図した状態を保てないといった形で現れます。記録には、行った操作、システムのダイアログが表示されたか、確認後にアプリに何が表示されたかを書いてください。「使えない」だけでは不十分です。スイッチで接続を開始できるのに特定のサイトだけ開けない場合は、接続とルールの章で確認してください。権限を何度も作り直す必要はありません。発生順に近い記録を残すほど、システム側とサービス側の問題を区別しやすくなります。

この段階ではOn Demandの設定も保留してください。まず手動操作で、接続と切断を再現できる状態にします。その後で自動接続の条件を追加すれば、再接続が手動操作によるものか、自動条件によるものかを判断できます。切断後に毎回自動接続する場合は、スイッチの故障と決めつけず、関連する自動動作が有効になっているか確認してください。権限を確認したら、次の章でサーバーまたはサブスクリプションを追加します。サービス情報をまだ用意していない場合は、画面の説明を読むだけでもかまいません。先に進むために設定値を適当に入力する必要はありません。

受け取った情報の種類を見分ける

インポートする前に、サービス提供元から渡されたものがサブスクリプションURL、単一サーバーの共有情報、完全な設定ファイルのどれかを確認してください。サブスクリプションURLは通常、複数のサーバー情報を取得するために使います。単一の共有情報には1つの接続先が記載され、設定ファイルにはルールやその他の設定が含まれる場合があります。すべてテキストやURLだからといって、同じ入力欄に入れないでください。情報の入手元にある用途の説明を読み、Homeの追加メニューかConfigの設定管理メニューを選ぶと、「インポートは成功したのに期待した内容がない」という状況を減らせます。

サーバー情報やサブスクリプションURLには認証情報が含まれる場合があるため、パスワードと同様に管理してください。コピーする際は内容を完全に保ち、説明文、空白、改行、日本語の句読点を混ぜないようにします。Scan QR Codeで読み込む場合も、信頼できる自分の情報元から取得したQRコードか確認してください。スキャンできたことだけでは、設定の安全性は保証されません。QRコードを公開の場にアップロードして質問したり、内容確認のために完全なサブスクリプションURLを不明なサイトへ貼り付けたりしないでください。トラブル対処では、情報の種類、エラー表示、操作手順を説明すれば十分です。

サーバーを手動で追加する際の確認方法

Add Serverで、サービス情報と一致するタイプを選び、アドレス、ポート、認証欄を入力します。プロトコルの選択によって、後続の設定項目の意味が変わります。タイプが異なれば、パスワード、識別子、暗号化方式、通信オプションを互いに置き換えることはできません。アドレス欄には通常サーバーのアドレスだけを入力し、独自にWebページのパスを付け加えないでください。ポートには提供された値を使用します。保存前に元の説明と項目ごとに照合し、特に大文字・小文字、末尾の文字、数字を確認してください。「だいたい同じ」に見えるだけで一致と判断しないでください。

TLS、サーバー名、パス、その他の通信パラメータが指定されている場合は、該当する項目にすべて入力してください。サーバー名は接続先アドレスと同じとは限らず、パスも自由に追加できる説明文ではありません。項目の意味が分からない場合は、すべてのスイッチを順に試すのではなく、サービス情報の提供元に確認してください。パラメータが揃っていて件数が少ない場合は手動追加が適しています。標準形式の共有情報がある場合は、インポートすると入力ミスを減らせますが、取り込み後もタイプと重要な項目が想定どおりか確認してください。

サブスクリプションの追加と初回更新

サブスクリプションを追加するには、該当するSubscribeタイプの入力欄に完全なURLを入力し、保存後に更新を実行してサーバー一覧が表示されるか確認します。名前は入手元の識別に使えますが、接続パラメータではありません。一覧が空の場合は、URLの保存失敗、リクエスト失敗、取得した内容の解析失敗を区別してください。それぞれ対処方法が異なります。ブラウザでページを表示できても、クライアントが利用できるサブスクリプション情報が返されているとは限りません。アカウントのログイン画面やエラー説明が表示されることもあります。

サブスクリプションのインポート後は、一覧からサーバーを1つ選び、次の章で接続を確認します。更新時に変更が上書きされる場合があるため、サブスクリプションから生成された項目をすぐに個別編集しないでください。独自に調整する必要がある場合は、項目の入手元と更新時の動作を確認し、元のサブスクリプションを保持したうえで、自分用のコピーに分かりやすい名前を付けます。サブスクリプションの更新は主にサーバー情報の再取得であり、現在のConfigにあるルールファイルの切り替えとは別の操作です。サーバー一覧とルールによる振り分けは、それぞれ個別に管理します。

インポートに失敗しても現状を保つ

更新に失敗しても、既存のサブスクリプションをすぐに削除する必要はありません。まず現在の一覧を保持し、URLが完全か、サービスアカウントが有効か、現在のネットワークから内容を取得できるかを確認します。以前は正常だったのに突然失敗した場合は、最後に更新に成功した日時と最近の変更を記録し、サービス提供元の状況説明を確認してください。リクエストを連続で繰り返しても形式の問題は解決しません。アクセス制限が生じることもあります。サブスクリプションの解析失敗・一覧が空の場合の確認リストに沿って原因を絞り込み、特定してからURLを置き換えるか判断してください。

モードを確認してからルールを読み解く

Global RoutingのConfig、Proxy、Directが、主なルーティング方式を決めます。Configは現在の設定ファイルのルールに従って接続を振り分けます。Proxyはクライアントが処理する接続を、選択したサーバーにまとめて渡します。Directは直接接続として処理します。ここでいう「まとめて」はルーティングモードの意味であり、デバイス上のすべてのシステム動作を例外なく説明するものではありません。システムに保持された動作、既存の接続、他のネットワーク設定も確認結果に影響する場合があります。トラブル対処では、すでに開いているページだけを見るのではなく、新しいリクエストで検証してください。

Configは設定モードを示す画面用語です。画面下部の設定管理メニューにも、Global Routingの選択肢にも表示されますが、役割は異なります。前者はファイル管理、後者はルールによる処理方法の選択に使います。ファイルをインポートしただけでは、現在のモードがConfigとは限りません。モードがConfigでも、ダウンロードしたばかりのファイルが有効とは限りません。ルールを変更する前に、この2か所の状態をそれぞれ確認してください。「ルールが機能しない」場合、実際にはProxyが選択されたままか、編集したものとは別のファイルが有効になっていることがあります。

ルールの構成要素

一般的なルールは、タイプ、マッチ条件、ポリシーからなり、各項目を英語のカンマで区切ります。DOMAINは完全なドメイン名に一致します。DOMAIN-SUFFIXはドメインのサフィックスと該当するサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで判定します。IP-CIDRとIP-CIDR6はそれぞれ該当するアドレス範囲を表し、GEOIPは地理情報データベースを使って判定します。ポリシーのPROXY、DIRECT、REJECTはそれぞれプロキシ経由、直接接続、拒否を表します。ポリシー名は実際の設定の意味と一致させ、ルール内のキーワードを日本語の説明文に置き換えないでください。

[General]
bypass-system = true

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

上記はルールを読むための最小限の例であり、あらゆるネットワーク環境で使える完全な設定ではありません。例のドメイン名は構文を説明するためのもので、サーバーの接続確認には使えません。ローカルネットワークのアドレスを直接接続するルールは、アドレス範囲による判定を示しています。GEOIPの判定はデータベースに依存するため、個別の接続先の状態を確認する代わりにはなりません。実際に適用する前に、必要なサービス、ローカルネットワーク上のリソース、最終的なフォールバックポリシーを確認してください。元の設定を複製してからコピー上で少しずつ変更し、唯一の利用可能なファイルを直接上書きしないでください。

上から順に確認し、最初に一致したルールで判定終了

ルールは上から順に確認され、一致するとそのポリシーが適用されます。より下にある「さらに詳細な」ルールは続けて確認されません。そのため、特定ドメインへの例外は、適用範囲の広いルールに上書きされる前に配置してください。FINALはそれまでに一致しなかった場合のフォールバックで、通常は一番最後に置きます。FINALを上の方に置くと、それより下の項目は想定どおり判定されません。DOMAIN-KEYWORDは直感より広い範囲に一致する場合があります。他のドメインにも誤って一致しないか確認し、明確なサフィックスで指定できるときは条件をむやみに広げないでください。

ドメインルールとアドレスルールでは、参照する情報が異なります。接続先は最初にドメイン名として扱われ、その後アドレスに変換されます。ルールの判定にDNSが関係する場合もあります。最終的に特定のアドレスへ接続されたからといって、必ず最初にアドレスルールに一致したとは限りません。実際のリクエスト記録、ルールの順序、名前解決の結果を組み合わせて確認し、アドレスの割り当て情報だけを一度調べて結論を出さないでください。IPv6環境では対応するアドレスルールも考慮し、IPv4の範囲を追加しただけで同種の接続をすべて処理できると判断しないでください。

接続の確認に必要なこと

情報のインポート後、Homeで自分が用意したサーバーを選択し、Global Routingのモードを確認してから接続を開始し、必要な許可を完了します。状態が安定したら、新しいリクエストで実際のアクセスを試します。少なくとも、スイッチが想定した状態であること、サーバーの選択が正しいこと、接続先から応答が返ること、リクエストに適用されたポリシーが想定どおりであることを確認してください。システムのVPN表示が示すのは、対応するネットワーク構成が動作していることまでです。サーバー認証の成功や、すべてのWebサイト・アプリへのアクセスを保証するものではありません。

最初のテストでは、正常な結果を判断できる、使い慣れた接続先を1つ選び、大量のページを同時に開かないでください。まず通常のリクエストを確認し、次にプロキシ経由が必要なリクエストをテストします。ローカルネットワーク上のリソースを使う場合は、それも個別に確認してください。接続先によって適用されるポリシーが異なることがあるため、1つの成功だけで全ルールが正しいとは限りません。再テストで比較できるよう、テスト時のネットワーク環境、サーバー、モードを記録し、同じ条件で繰り返してください。検証の途中でサブスクリプションを自動更新したり、設定を入れ替えたりしないでください。テスト条件が意図せず変わるのを防げます。

Connectivity Testの見方

Connectivity Testはサーバーやテスト先への到達性を確認する補助になりますが、結果はテスト方法、テスト先、その時点のネットワーク状態に左右されます。テストの成功はすべての実際の通信が正常であることを意味せず、失敗もすべての接続が利用できないことを意味しません。実際のアクセス結果とあわせて判断するための情報の1つとして扱ってください。テスト方法を設定できる場合は、まず現在の方法を確認してから結果を比較します。異なる方法で測定した所要時間をそのまま順位付けしたり、1つの数値だけで長期的な安定性を判断したりしないでください。

テストに成功してもWebページが表示されない場合は、特定のドメイン、種類のリクエスト、アプリだけで起きているか確認してください。接続先のサービス、DNS、TLS、ルールの適用結果、接続先側のアクセス制限などが関係する可能性があります。すべての接続先で失敗する場合は、サーバーアドレス、ポート、認証情報、基本ネットワークに戻って確認してください。特定のアプリだけで起きる場合は、古い接続を完全に終了してから再試行します。既存のセッションやキャッシュを新しいモードの結果と誤認しないためです。1つのアプリの接続を整理するために、デバイス設定全体をすぐにリセットしないでください。

段階的に原因を絞り込む

第1段階は基本ネットワークです。クライアントの接続を停止した状態でデバイスが通常どおりインターネットに接続できるか、公共Wi-Fiの認証が済んでいるかを確認します。第2段階はサーバー接続です。条件を管理できる状態でProxyを使い、選択したサーバーが実際のリクエストを処理できるか確認します。第3段階は設定による振り分けです。Proxyが正常でConfigに問題がある場合は、有効な設定ファイル、ルールの順序、関連する名前解決設定を確認してください。第4段階は接続先自体です。他の同種のリクエストが正常なのに特定の接続先だけ失敗する場合は、そのサービスの状態と具体的なエラーを確認し、すべてをクライアントの問題と決めつけないでください。

モードの一時切り替えは原因を絞り込むための方法であり、最終的な解決策ではありません。テスト後は通常使うモードに戻し、もう一度確認してください。ProxyとConfigで結果が異なる場合、ルールの経路が異なる可能性がありますが、DNSや既存接続が関係することもあります。この比較だけで特定のルールの誤りだと断定しないでください。Directでの比較も、直接接続が許可されるテスト先で行います。一度に変更する要素を1つにし、変更前後の結果を記録すれば、原因を順に除外できます。サーバー、モード、ネットワークを同時に変えて接続できても、何が解決したのかは分かりません。

タイムアウト、名前解決、証明書の問題を区別する

タイムアウトは、必要な応答が所定の時間内に返らなかったことを示しますが、どの段階で応答が失われたかまでは分かりません。基本ネットワーク、ポート、接続先の範囲をあわせて確認してください。名前解決の失敗では、まずドメイン名を解決する経路を確認します。すぐに認証パスワードを変更しないでください。証明書エラーでは、デバイスの時刻、サーバー名、サーバー側の証明書を確認します。検証を無効にすると接続の信頼条件が変わるため、通常のトラブル対処として行わないでください。複数の高度な設定を手当たり次第に変更するより、まず情報を照合し、利用中のサービス提供元にサーバー側の要件を確認するほうが確実です。

ネットワーク切り替え後だけ発生する場合は、切り替え前後の状態と再接続で復旧するかを記録してください。スリープ後だけ発生する場合は、復帰直後の最初のリクエストと、その後のリクエストを比較します。再現条件が分かってから関連する設定を調整してください。最初からシステム動作、サブスクリプションの形式、ルールをすべて作り直す必要はありません。初回接続の手順が分からなくなった場合は、クイックスタートガイドに戻って最小限の手順をもう一度試してください。高度な分析は、繰り返しテストできる基本設定を用意してから行います。

集計される通信量の範囲

Dataでは、クライアントが取得できる通信量や接続関連の情報を確認できます。表示項目はアプリの現在の画面に従います。見る前に集計の範囲を確認してください。現在のセッション、一定期間の累計、特定サーバーのカウンターなど、範囲が異なれば直接比較できません。クライアントで観察するデータは、システムのモバイル通信量、サービス提供元のアカウント使用量、接続先のファイルサイズとも集計基準が異なります。数値が一致しない場合は、いずれかが誤りだとすぐに判断せず、集計範囲と単位を確認してください。

1回のページ表示には、本文、画像、スクリプト、フォント、バックグラウンドのリクエストが含まれるため、アドレスバーにURLが1つだけ見えていても通信数は推定できません。アップロードとダウンロードは同時に発生します。主にコンテンツを読む場合でも、デバイスはリクエストやプロトコルデータを送信します。ページの再読み込み、プリロード、アプリのバックグラウンド同期でも数値が増える場合があります。特定の操作による変化を確認するには、操作前の数値を記録し、明確な操作を1つ行ってから増加分を見てください。増え続ける合計値だけを見て原因を推測しないでください。

クライアントの集計とサービス提供元の請求は別

サービス提供元は独自の料金体系、集計期間、通信量の基準で使用量を記録する場合があります。クライアントの記録は、観察可能な接続範囲によって変わります。通信上のオーバーヘッド、再試行、集計範囲の違いも差の原因になります。そのためDataは、手元での状況確認やトラブル対処の補助に使うもので、サービスアカウントの請求基準の代わりにはなりません。アプリの買い切り購入に接続サービスは含まれず、アプリ内の通信記録によってサービスの利用可能量が増えることもありません。容量、有効期限、アカウントの制限は、自分が利用しているサービス情報で確認してください。

1回のテストでルールを確認する

特定のルールを確認する前に、現在のモード、設定ファイル、テスト時刻を記録してから、接続先を1つだけ開いてください。現在の画面にリクエストや接続の詳細が表示される場合は、同じ時刻の記録を探し、ドメイン、アドレス、適用ポリシーを確認します。1つのページから複数の異なるドメインへリクエストが送られる場合があるため、最初の記録だけで確認を終えないでください。ページの本文は表示できても一部の素材が読み込めない場合、それぞれのドメインに別のポリシーが適用されている可能性があります。ページ全体に適用範囲の広すぎる例外を追加せず、失敗した素材と該当ルールを照合してください。

記録に想定した情報がない場合も慎重に判断してください。アプリが既存接続を再利用した、接続先にキャッシュがある、表示中の範囲に該当の記録が含まれない、といった可能性があります。識別できる新しいリクエストを発生させ、絞り込み条件と記録範囲を確認してください。ページを何度も再読み込みして重複する項目を増やさないでください。分析のノイズが大きくなります。ルール変更前後を比較する場合は、それぞれの時刻を記録し、同じ操作を行って新しい設定が適用されていることを確認してください。同じ要素を比較するために必要です。

バックグラウンド動作とプライバシー

積極的に閲覧していないときに通信量が増えることは珍しくありません。システム同期、メッセージの受信、メディアのプリロード、アプリのバックグラウンド処理などで通信が続く場合があります。自分で制御できるダウンロードや同期を一時停止し、変化が小さくなるか確認してください。数値が増えたというだけで異常と判断しないでください。特定のアプリで失敗と再試行が繰り返されると、通信量が増え続けることがあります。カウンターをリセットするだけでなく、エラー記録から原因を確認してください。リセットで変わるのは観察の開始点だけで、接続の問題やサービス提供元の記録は解決・リセットされません。

リクエスト記録には、アクセスしたドメイン、時刻、ネットワークアドレス、認証情報を含む内容が表示される場合があります。エクスポートやスクリーンショットの前に、サブスクリプションのパラメータ、完全なアクセスパス、個人データが含まれていないか確認し、問題に必要な最小限の範囲だけを残してください。トラブル対処が終わったら、不要になった記録をプライバシー上の必要に応じて削除します。詳しい情報を得るためにHTTPS復号を安易に有効にしないでください。通常のルール確認では、接続先、時刻、ポリシーなどのメタデータを優先して使います。画面下部の各メニューの役割は、Home、Config、Data、Settingsの画面用語で確認できます。

安定した基本状態から設定を始める

Settingsはアプリの動作を調整するためのもので、すべての項目を有効にすれば接続が改善するわけではありません。初回利用では、動作確認済みの基本状態を保ちます。具体的には、サーバーを明確に選び、モードを固定し、追跡可能な設定ファイルと再現可能なテスト先を用意してください。その後は一度に1種類の設定だけを変更し、元の値と変更目的を記録します。アプリの画面は実際のバージョンによって変わる場合があるため、設定項目は現在の表示に従ってください。ガイドにある項目が見つからなくても、名称の似た別の項目で代用したり、不明な設定を使って無理に追加したりしないでください。

次回の接続に反映される設定もあれば、現在のリクエストに影響する設定、表示や更新動作だけを変える設定もあります。保存後は、接続を再確立する必要があるか判断し、新しいリクエストで結果を確認してください。画面上のスイッチが変わっただけで、ネットワークにも新しい条件が反映されたと判断しないでください。設定ファイルに関連する項目はファイル側で指定されていることもあります。入口の一方だけを変更して、もう一方の既存設定が影響していないかも確認してください。

On Demandは条件を明確にしてから設定する

On Demandは、設定した条件に応じて接続を自動的に開始する機能です。使用前に、接続したいネットワーク環境や、切断状態を維持したい条件など、目的を明確にし、アプリで実際に選べる条件を設定してください。サーバーを常時利用可能にする機能ではなく、認証の失敗を直すものでもありません。手動接続の動作を確認できていない場合は、自動動作を有効にしないでください。失敗時の再試行やネットワーク切り替えが重なると、条件設定とサーバーのどちらに問題があるか分かりにくくなります。

有効にした後は、条件に合う場合と合わない場合をそれぞれテストし、想定どおりに動作するか確認してください。手動で切断した後に再接続する場合、自動条件がまだ成立している可能性があります。切断操作が反映されなかったとは限りません。一時的に停止する場合は、自動接続の設定も確認してください。元のネットワークから離れる、戻る、デバイスをスリープから復帰させる、といった状況は個別に確認する価値があります。条件にネットワーク名を使う場合、同じ名前でも実際の環境が異なることがあります。名前だけを信頼できるネットワークの証明とみなさないでください。

サブスクリプション更新設定の範囲

現在の画面にアプリ起動時にサブスクリプションを更新する設定がある場合は、利用頻度に応じて有効にするか決めてください。この設定はサーバー一覧の更新に役立ちますが、更新にはネットワークからのアクセスと有効なサブスクリプションURLが必要です。アプリ起動後の更新に失敗しても、キャッシュ済みのすべてのサーバーが直ちに使えなくなるわけではありません。一覧の更新と既存接続を分けて確認してください。自動更新はサービス提供元の変更を常時監視する機能ではなく、毎回最適なタイミングで最新情報を取得できる保証もありません。

更新の動作を変更する前に、サブスクリプションから作成された項目がどのように扱われるか確認してください。名前、並び順、接続項目を自分で変更している場合、次回の更新後もその変更が維持されるか確認します。重要な変更は、更新で上書きされる可能性のある項目だけに残さず、別途記録してください。更新に失敗した場合は、使える状態を保存してから原因を調べます。「自動」だからといって失敗の表示を無視しないでください。具体的な操作はサブスクリプションの手動更新とアプリ起動時の自動更新も参考にしてください。画面上のメニューは実際のアプリ表示に従います。

DNSや接続オプションをまとめて試さない

DNSはドメイン名をアドレスに変換するために使われます。問い合わせ経路や結果が、その後のルール判定や接続先への接続に影響する場合があります。名前解決の設定を変更する前に、問題が実際にDNSに関係しているか確認してください。たとえば、基本ネットワークとサーバー接続が正常だと確認できているのに、同じドメインの名前解決だけが繰り返し失敗する場合です。Webで見つけたDNSアドレスをまとめて追加しないでください。入手元、到達性、設定上の意味が不明なままアドレスを増やすと、確認要素が増えるだけです。元の設定を保持し、同じ接続先で変更前後を比較してください。

TLS、通信方式、IPv6、接続再利用に関する項目も、実際のサービス要件に応じて調整してください。機能を有効にしても、ネットワークとサーバー側の両方が対応している必要があります。項目を多く有効にするほど完全になるわけではありません。接続に問題がある場合は、まずサービスの設定値を確認してから高度なオプションを検討してください。表面的な接続成功のために証明書検証を無効にしないでください。ログの詳細度も必要に応じて調整します。トラブル対処中に必要な情報を集めたら、日常利用に適した状態へ戻し、エクスポートした記録を適切に管理してください。

3種類の更新を分けて管理する

日常メンテナンスでは、App Store経由のアプリ更新、サブスクリプション内のサーバー一覧の更新、Config内の設定ファイルの更新を分けて管理します。アプリの更新はクライアントの機能や動作を変え、サブスクリプションの更新はサービス情報を変え、設定ファイルの更新はルールや関連設定を変えます。トラブル対処中にこれら3つを同時に実行しないでください。どの層に変更があったか把握していれば、更新前後を比較し、適切な情報元に確認できます。

更新前に、現在の接続が重要な作業に使われていないか確認し、ローカルでの変更を保存して、使用中の設定名を記録してください。更新後はサーバー一覧と有効な設定ファイルを確認し、実際のアクセスを一度テストします。その時点で他の設定をすぐに変更する必要はありません。設定元から内容を更新すると元の内容が上書きされる場合があり、サブスクリプションの更新で項目が変わることもあります。重要な例外ルールや手入力したパラメータは、別の確実なコピーに保存してください。アプリの更新履歴はApp Storeのページで確認し、ネット上で流通する番号を見て更新が必要か判断しないでください。

バックアップでは内容だけでなく入手元も記録する

バックアップはファイルを保存するだけでなく、入手元、用途、変更内容も把握しておく必要があります。元の設定、テスト用コピー、日常利用のコピーを短い名前で区別し、差分を個人用のメモに記録すると便利です。ファイルをエクスポートしたら、サブスクリプションURL、サーバーの認証情報、その他の機密情報が含まれていないか確認してから保存先を決めてください。バックアップを一般的な文書のように公開しないでください。大半がルールでも、認証情報を含むURLが1行あるだけで情報漏えいにつながるおそれがあります。

バックアップの有効性は、エクスポートに成功したかだけではなく、実際に復元できるかで決まります。移行前にファイルを読み取れること、入手元から情報を取得できること、手入力した情報が十分揃っていることを確認してください。自分で管理できる安全な場所に保存し、アプリの入手、権限設定、サービス情報と設定の復元、接続確認の順に、分かりやすい復元手順を用意します。同期機能を使う場合も、実際の同期範囲を確認してください。同じファイル名が表示されるだけで、すべての設定、記録、認証情報が一致しているとは限りません。

機種変更後の最小限の復元手順

新しいデバイスでは、まず購入時のアカウントを使ってApp Storeからアプリを再入手してください。システム要件と購入対象範囲はApp Storeの表示に従います。アプリを開いたら高度な設定をすべてコピーするのではなく、まず利用可能なサーバーまたは自分のサブスクリプションを1つ復元し、明確なモードを選択してシステムの許可を完了してください。最小限の手順で接続できた後に、日常利用のルールや自動接続条件をインポートします。これなら異常が発生したときに、復元した内容のどこに問題があるかを特定しやすくなります。一式を同時に移行した後の分からない状態を避けられます。

旧デバイスで接続できても、新しいデバイスが異なるネットワークで同じ結果になるとは限りません。ローカルネットワークのアドレス、ネットワーク認証、デバイスの時刻、自動接続条件を再確認してください。新しいデバイスで安定して動作することを確認してから、旧デバイスで不要になった機密情報を整理します。移行の確認前に唯一のコピーを削除しないでください。購入済みアプリの復元については購入済みアプリの復元をご覧ください。価格と買い切りに関するよくある質問は価格と買い切り購入についてで確認できます。アカウントの問題を解決するためにクライアントのルールを変更しないでください。

異常が起きたら直近の変更を元に戻す

メンテナンス中に問題が起きた場合は、「最後に正常だった条件は何か」を確認してから、「その後何を変更したか」を整理します。設定ファイルだけを変更した場合は、まずバックアップに切り替えます。サブスクリプションだけを更新した場合は、項目のパラメータと選択状態を確認します。On Demandを有効にした直後なら、自動動作を一時停止して手動でテストしてください。元に戻すのは比較の基準を復旧するためで、古い設定を使い続けるためではありません。差分を確認してから該当項目に対処し、問題のたびにすべての設定を削除して最初からやり直すのは避けてください。

変更の目的、変更した項目、確認結果を簡潔な個人用メモに残し、パスワードや完全なサブスクリプションURLは記録しないことをおすすめします。問題を再現できない場合は、原因の条件がまだ分からないことをそのまま記録してください。結論を出すためにルールを次々と追加しないでください。詳しい説明はブログの記事一覧から、ルール、サブスクリプション、購入に関するテーマを選んでご覧ください。初回接続の手順をもう一度確認したい場合は、使い方ガイドに戻ってください。このマニュアルの目的は、操作に根拠を持たせ、結果を説明できるようにすることです。すべての項目を設定することではありません。