Shadowrocketの使い方完全ガイド

まず入手先を確認する

ShadowrocketはAppleプラットフォーム向けの有料クライアントです。本ガイドでは主にiPhoneとiPadでの操作を説明します。入手先はApp Storeの製品ページです。Mac、Apple TV、Apple Visionとの互換性も同じページで確認してください。デバイス名だけで、対応するシステム要件や購入可能な範囲を判断しないでください。システム要件、対応デバイス、現在の価格はApp Storeの製品ページに記載された内容をご確認ください。購入前に、利用中のApp Storeのストアフロントと、製品ページで購入可能と表示されているかを確認します。検索結果は製品ページを探すための入口にすぎません。最終的な情報は製品詳細ページで確認してください。

製品を確認する際は、アプリ名がShadowrocket、開発者がShadow Launch Technology Limited、製品リンクのアプリIDが932747118であることを確認してください。表示されているアイコンはストアの製品アイコンと一致する必要がありますが、アイコンだけで判断してはいけません。名前や画像が似た検索結果でも、別の製品を指している場合があります。製品詳細ページを開いたら、開発者名を最後まで確認し、URLにid932747118が含まれているかを確認してください。3つの情報を照合するほうが、通称だけを覚えておくより確実です。確認箇所とデバイスの説明は正規版の確認ガイドをご覧ください。

アプリの購入費用と接続情報を区別する

購入するのはShadowrocketクライアント本体です。米国向けのページでは、以前は買い切り価格として約2.99米ドルと表示されていました。実際の価格、通貨、購入条件は、現在のApp Store製品ページをご確認ください。クライアントの買い切り購入 ≠ 接続サービスのプラン：購入によってアプリを入手できますが、接続に必要なサーバー情報が自動で作成されるわけではありません。以降の設定追加手順は、自分がすでにサブスクリプションまたはサーバー情報を持っていることを前提としています。情報をまだ取得していない場合でも、ルーティングや画面の説明は確認できますが、アプリ内にSERVER項目が表示されないことを購入失敗と判断しないでください。

iPhoneまたはiPadで購入したら、App Storeの製品詳細ページに戻り、インストールを実行して完了するまで待ちます。ボタンが再入手を示している場合は、購入時に使用したアカウントでサインインしているかを確認し、App Storeの購入済み項目も確認してください。ホーム画面にアイコンがあるかどうかだけで、購入履歴を判断してはいけません。機種変更や再インストールの際は、購入履歴とアプリ内に自分で追加した設定は別々に扱われます。アプリを再入手しても、サブスクリプション、サーバーのメモ、カスタムルールが必ず復元されるわけではありません。移行前に、利用する権限のある元の情報を保存し、新しいデバイスの状態に合わせて追加し直してください。

「製品が正しいか」「アプリを入手できているか」「接続情報を用意できているか」を分けて確認すると、後の判断ミスを減らせます。たとえばHomeを開いてリストが空の場合は、再購入するのではなく、設定を追加済みか確認します。接続後に目的のウェブサイトへアクセスできない場合は、アイコンやストアアカウントではなく、サーバー、ルーティング、ネットワークを確認してください。準備ができたら、初回起動とVPN構成の権限設定に進みます。

まずHomeの各項目を確認する

Shadowrocketを初めて開いたら、すぐにすべての項目を変更せず、まずHomeで現在の状態を確認してください。Homeは接続操作の起点です。上部の接続スイッチとステータス表示で接続状態を確認し、Global Routingでトラフィックのルーティング方法を選び、SERVER欄で追加済みのサーバーを確認・選択し、Connectivity Testで接続を補助的に確認できます。初回起動時にNot Connectedと表示されていても、現在接続されていないことを示すだけです。選択できるSERVERがない場合は、先に設定を追加してください。画面サイズやアプリ内のレイアウトによって項目の位置は異なることがあります。探す際は英語の項目名を目印にしてください。

「状態を確認する—情報を確認する—ルーティングを選ぶ—接続を開始する」の順に操作することをおすすめします。この順なら、システムの権限ダイアログが表示されたとき、どのスイッチ操作がきっかけかを把握でき、権限の許可、サーバーの追加、ルールの選択を混同しにくくなります。利用可能なサーバーを選ばずに先にスイッチをオンにした場合、接続に失敗しても、権限を繰り返し許可するだけでは解決しません。操作前に表示されていたステータスも記録しておくと、次回の確認時に状態が変わったか判断しやすくなります。

システムの許可ダイアログを確認する

iPhoneまたはiPadで初めて接続を開始しようとすると、ShadowrocketによるVPN構成の追加を許可するようシステムから求められることがあります。これはネットワーク構成の変更を確認する手順であり、サーバーへの接続が完了したことを意味するものではありません。ダイアログに表示されたアプリ名とシステムの説明を読み、現在の操作に対応していることを確認してから、案内に従って許可してください。デバイスによってはパスコードや生体認証での確認も必要です。許可後にアプリへ戻ったら、接続スイッチ、選択中のSERVER、Global Routing、確認結果をそれぞれチェックします。ステータスバーにVPNアイコンが表示されても、ネットワーク構成が有効になっていることを示すだけで、すべての接続先へ想定どおりにアクセスできるとは限りません。

ダイアログをキャンセルした場合は、Homeに戻ってスイッチの状態を確認し、アプリ内の接続操作から再度表示してください。スイッチを何度も素早く切り替えるのは避けましょう。以前に構成を許可したのに、次の接続時にも権限に関する案内が表示される場合は、デバイスでVPN設定の変更が許可されているか、ほかのデバイス管理上の制限がないかを確認してください。実際に操作できる項目はデバイスの設定によって異なります。通常のサーバーパラメータの誤りに対処するために、システム構成を何度も削除しないでください。エラーが「許可前」「許可後だが未接続」「接続済みだがアクセスに問題あり」のどの段階で発生したかを切り分けてください。それぞれ確認すべき内容が異なります。

iPadでも同じ手順で確認する

iPadではワイド画面のレイアウトにより、Homeのリストやコントロールの表示がiPhoneと異なることがありますが、権限の意味は変わりません。システムが確認するのはデバイス上のVPN構成であり、SERVER情報は引き続きユーザー自身が追加する必要があります。どちらのデバイスも初めて使う際は、それぞれのシステム権限とアプリ内の選択項目を確認してください。一方のデバイスで許可しても、もう一方で自動的に許可されるわけではありません。同じApple IDでの購入履歴はApp Storeの購入済み状況で、接続情報は各デバイスの実際のリストで確認してください。

権限を確認したら接続をオフにしたまま、まず既存の情報を追加して各項目を確認してください。スイッチ、リスト、テストの入口が見つからない場合は、初回起動とHomeの各項目の説明をご覧ください。この段階で記録しておきたいのは「ウェブサイトを開けるか」ではなく、アプリが正常に起動するか、Homeが表示されるか、システム権限を確認済みか、SERVERが空のままかどうかです。これらを把握しておくと、次の設定追加時の問題を切り分けやすくなります。

まず情報の種類を見分ける

Shadowrocketのサーバー項目は、手動入力、単体の共有リンク、サブスクリプションから追加できます。開始前に、自分がすでに持っている情報の種類を確認してください。サーバーアドレス、ポート、プロトコル、認証情報が揃っている場合は、項目ごとに入力します。プロトコルのプレフィックスで始まる共有リンクは、通常は単一の項目を表します。サービス提供元から定期的に複数の項目を取得するためのURLは、Subscribeとして扱います。サブスクリプションURLと個別サーバーのアドレスは互いに代用できません。前者をサーバーアドレス欄に入力したり、単体の共有リンクを更新用URLとして使ったりすると、原因の分かりにくいエラーにつながります。

手動で追加する場合は、Homeで追加メニューを開き、Add Serverに進みます。既存の情報に合うプロトコルを選択してから、各項目を入力してください。アドレスにはホスト名またはIPアドレスを入力し、ポートは資料の記載と一致させます。認証情報はプロトコルの要件に従って入力してください。メモは項目の識別に使えますが、接続パラメータではありません。入力時はコピーした文字列の前後の空白、ポート番号、大小文字を区別する項目、見間違えやすい文字に注意してください。保存後はSERVERに戻り、新しい項目が表示されたことと、選択されている項目を確認してから接続を開始します。対応する項目はAdd Serverに現在表示されている内容をご確認ください。

プロトコルごとに必要なパラメータを確認する

この表は確認箇所を見つけるためのもので、汎用入力テンプレートではありません。同じプロトコルでも、トランスポート、セキュリティ、ドメインの設定が異なる場合があります。記憶を頼りに、サービス提供元が指定した値を変更しないでください。WireGuardのPrivateKeyはローカルの識別情報です。PublicKeyとEndpointはそれぞれ役割が異なります。詳しくはWireGuardのパラメータ解説をご覧ください。認証情報を公開ページ、スクリーンショット、問い合わせメッセージなどにそのまま掲載しないでください。項目を確認する際は、手元の元資料と一つずつ照合してください。

既存のサブスクリプションを追加・更新する

Subscribe URLをすでに持っている場合は、アプリ内のサブスクリプション追加機能を使い、URL全体を貼り付けて保存してから、アプリの更新操作を実行してください。https://example.com/sub?token=xxxxのようなサンプルURLはURLの形式を示すだけで、接続には使えません。更新が完了したらSERVERに戻り、項目が追加されたか、選択中の項目が引き続き必要なものかを確認します。インポート成功とサーバーが利用可能であることは別です。前者はアプリが情報を取得して解析できたことを示し、後者は接続と接続先へのアクセス確認が必要です。ss://、vmess://、vless://、trojan://の単体リンクとサブスクリプションURLの違いは、共有リンクとサブスクリプションリンクの解説をご覧ください。

更新に失敗した場合は、デバイスからサブスクリプションURLへアクセスできるか、URLが途中で切れていないか、元の情報がまだ有効かを確認してください。更新完了と表示されてもリストが空の場合は、サブスクリプションの実際の内容とアプリが認識する形式を確認します。確認のために、非公開のURLを公開のチェックサイトへ貼り付けないでください。Scan QR Codeは、自分が持つ有効な情報の追加に使えますが、読み取り後も項目と情報の入手元を確認してください。情報がSERVERに追加されたら、次にGlobal Routingを選びます。リストに項目が表示されたことだけで、ルール振り分けが正しいと判断してはいけません。

まず動作モードを選び、ルールの一致を確認する

Global Routingでは、トラフィックのルーティング方法を選択します。画面に表示されるConfig、Proxy、Directは、それぞれ設定に基づく判定、選択中のプロキシ経路の使用、直接接続として理解できます。日本語の説明は動作を把握するためのもので、設定を探すときは英語の項目名を確認してください。モードを切り替えても通常はサーバー情報を再入力する必要はありませんが、接続結果の解釈は変わります。同じ接続先でも、ConfigではDIRECTに一致し、Proxyでは選択中のサーバーを経由する場合があります。トラブル対処の際は、まず現在のモードを記録してください。そうしないと「スイッチはオンなのにサーバーを経由していない」という状況が、正常なルーティングの結果なのか判断できません。

Configで特に重要なのは、ルールの順序と最後に適用されるポリシーです。通常、ルールは具体的な条件から一般的な条件へと並びます。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはキーワードで照合します。GEOIP、IP-CIDR、IP-CIDR6はアドレス範囲による判定に関係します。ルール右側のPROXY、DIRECT、REJECTは処理ポリシーであり、プロトコル名ではありません。PROXYは利用可能な選択中サーバーに依存し、DIRECTはデバイスの現在のネットワークから直接アクセスし、REJECTは一致したリクエストを拒否します。USER-AGENTもルールキーワードとして表示されます。個々のリクエストに適用されるかどうかは、アプリ内での照合結果をご確認ください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

上記のexample.comはサンプルのドメイン名です。この例はルールの関係を示すもので、設定全体としてそのまま使えるものではありません。1行目はこのドメインとサブドメインをPROXYに振り分けます。2行目はキーワード一致後にREJECTする例です。3行目はGEOIPとDIRECTの組み合わせを示します。前のルールに一致しないリクエストの処理先はFINALで決まります。末尾にFINAL,DIRECTを記述すると、一致しなかったリクエストは直接接続されます。変更前に現在のConfigを保存し、対象と期待する動作を記録してください。複数のルールを同時に変更すると、どの変更が結果に影響したか分からなくなるおそれがあります。

3つのモードで問題の範囲を絞り込む

Configで特定の接続先にアクセスできない場合は、テスト範囲を決めてからProxyとDirectの結果を比較します。Proxyではアクセスでき、Configではできない場合は、まずルールの一致とFINALを確認してください。Proxyでも失敗する場合は、選択中のサーバーパラメータ、認証、ネットワーク接続、接続先自体を確認します。Directではアクセスでき、Configで問題が起きる場合も、Directを恒久的に使うべきとは限りません。引き続き、そのリクエストに一致するルールを調べてください。3つのモードの比較は診断方法の一つであり、すべてのネットワーク環境に共通する推奨設定ではありません。テスト後は必要なモードに戻し、よく使う接続先で再確認してください。

Configには、ルール以外の設定（DNS関連の項目など）が含まれることもあります。リクエストの最終的な結果は、ドメインの名前解決、IPルール、ルーティングモード、接続先のサービスなどの影響を受けます。テストサイトの単一の結果だけで、Config全体が正しいと判断しないでください。用語の確認には用語集を、DNSの具体的な設定にはDNS設定の解説をご覧ください。

接続を観察可能な段階に分ける

接続を開始する前に、SERVERで自分がすでに持っているサーバーを選び、Global Routingが先ほど決めたモードになっていることを確認してから、Homeのスイッチを操作します。その後、システム権限が許可されているか、アプリの状態がNot Connectedから変化したか、デバイスに対応するネットワーク状態が表示されているか、Connectivity Testで結果が出るか、実際の接続先へ想定どおりアクセスできるかを順に確認してください。これらは互いに代用できる確認項目ではありません。スイッチがオンでもサーバー認証が成功しているとは限らず、あるアドレスのテストに成功しても、すべてのドメインが同じルールに一致するとは限りません。

Connectivity Testは手早い比較に便利ですが、テスト対象、現在のネットワーク、ルーティング設定によって結果が変わります。一度失敗したら、まずデバイス自体がインターネットに接続できることを確認し、テストしたいサーバーが選択されているかを確認してください。Subscribeを更新した直後は、特に選択中の項目を再確認しましょう。次に、現在のモードがConfig、Proxy、Directのどれかを確認してから、同じ接続先で再テストします。毎回ネットワークや接続先を変えるのは避けてください。「モード、選択中の項目、テスト対象、発生した現象」の4点を記録すると、「接続できない」とだけ記録するより原因を特定しやすくなります。

現象に応じて切り分ける

接続を開始できない場合は、ルールを変更する前に、システムのVPN構成権限とHomeの状態を確認してください。接続済みなのに接続先へアクセスできない場合は、まずConfig内のREJECTまたはDIRECTルールが適用されていないかを確認し、次にPROXYが使用するサーバーを調べます。一部のドメインだけで問題が起きる場合は、該当するDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDとDNSを重点的に確認してください。すべての接続先で問題が起きる場合は、デバイスの基本的なネットワーク接続、サーバーの項目、認証、選択中の項目を優先して確認します。接続先のウェブサイト自体が一時的に利用できない場合も似た現象になるため、使い慣れた複数の接続先で比較してください。

既存サーバーのパラメータを確認する必要がある場合は、最初に入手した資料と照合してください。プロトコル、ポート、安全設定を手当たり次第に変更してはいけません。アドレスの名前解決が正常でも接続できない場合、認証やトランスポートパラメータに問題がある可能性があります。サブスクリプションを更新できてもサーバーを利用できない場合は、情報の取得に成功しただけで、サーバーの確認は別途必要です。反対に、単一のサーバーは使えるのにサブスクリプションの更新に失敗する場合は、サブスクリプションURLの完全性とアクセス可能性を確認します。「設定の取得」「接続の確立」「接続先へのアクセス」を別の段階として考えると、同じ確認を繰り返さずに済みます。

接続が安定したら長期的な動作も確認する

初めて接続先へアクセスできた後も、普段使う状況を何度か試してください。既知のネットワーク間の切り替え、画面ロック後の再解除、サブスクリプション更新後の項目の選び直しなどです。ネットワークを切り替えると、DNS、利用可能な経路、接続の維持状態が変わることがあります。一度成功しても、以後どの環境でも確認不要とは限りません。普段On Demandを使う場合は、まず起動条件を理解してからテストに加えてください。そうしないと自動接続が手動スイッチの結果に影響します。On Demandとバックグラウンド利用のバランスは、オンデマンド接続とバッテリー消費のトラブル対処をご覧ください。

確認の完了は、特定のステータスが点灯することではありません。PROXYを使う想定の接続先に期待どおりアクセスでき、DIRECTを使う想定の接続先も正常に利用でき、日常使用のConfigに戻しても結果が変わらないことが基準です。この前提がそろって初めて、Dataの数値を適切に解釈できます。問題が上記のどの分岐にも当てはまらない場合は、チュートリアルの手順に戻り、入力、選択、スイッチ操作の順を一つずつ確認してください。状態が分からないまま設定変更を重ねないようにしましょう。

まず集計範囲を把握する

Dataでは、アプリ内に表示される通信量を確認できます。ページを開く前に、現在の接続状態、選択中のサーバー、Global Routingを記録してから、数値を確認してください。数値の変化は、この条件を踏まえて解釈します。DIRECTで処理されるリクエストやREJECTされるリクエストがあるほか、デバイス上のほかのアクティビティ、バックグラウンド更新、以前の接続によって、表示期間の数値が直前に開いたページだけを示すとは限りません。Dataの合計値を「特定のウェブサイトの通信量」とみなしたり、アプリ内の集計値と通信事業者の請求における計測方法が完全に同じだと考えたりしないでください。

前後のデータを比較するときは、観察の開始時点と終了時点を決めてください。現在の値を確認してから、使い慣れた接続先にアクセスし、Dataに戻って変化を見ます。その間にネットワーク、サーバー、ルーティングモードを切り替えた場合は、その変更も記録してください。画面によって接続、項目、期間など、情報の表示単位が異なることがあります。比較する前に画面のラベルを確認してください。実際に利用できるフィルターやリセットの項目は、現在のアプリ内表示をご確認ください。他の人のスクリーンショットをもとに、自分の画面にも同じボタンがあると判断しないでください。

通信量は判断の参考にとどめ、接続テストの代わりにしない

通信量が増えた場合、観察範囲内で通信が発生したことは分かりますが、接続先のコンテンツが正常に読み込まれたことや、すべてのリクエストがPROXYを経由したことまでは証明できません。Dataの数値がすぐに変わらない場合は、接続が維持されているか、リクエストを実際に送信したか、現在の表示範囲にテスト時刻が含まれるかを確認してから、HomeとConnectivity Testに戻って確認してください。特にConfigでは、同じアプリからのリクエストでも異なるルールに一致する場合があります。累計値だけで各リクエストの経路を把握するのは困難です。特定の接続先を確認する際は、ルール、接続状態、接続先での実際の動作をあわせて確認してください。

「通信量が多く見える」場合は、機能を一度にすべて無効にするのではなく、再現可能な範囲で観察してください。開始時の数値を記録し、自分で実行中の大容量通信を一時停止してから、普段のネットワーク利用をしばらく続けます。バックグラウンドで増加が続く場合は、システムのバッテリーとネットワーク使用状況を比較し、On Demandなど接続タイミングに影響する設定も確認してください。アプリとシステムの集計は対象範囲や計算方法が異なることがあり、数値に差があってもすぐにアプリの異常とは限りません。単位、対象期間、バックグラウンドの通信が含まれるかを確認してから、設定変更を検討してください。

後から確認できる記録を残す

接続情報についてサービス提供元に問い合わせる際は、ネットワークの種類、選択中のプロトコル、接続した時間帯、再現できる現象を伝えれば十分です。サブスクリプションURL全体、パスワード、キーは添付しないでください。Dataのスクリーンショットにも、アカウント、サーバーのメモ、その他の個人情報が写っていないか確認しましょう。ルールが想定と異なる通信経路の原因と考えられる場合は、統計をリセットするのではなく、Configで処理ポリシーを一つずつ確認してください。リセットで変わるのは観察の開始点であり、ルーティングの動作は修正されません。

Dataは「既知の条件下で、この期間に通信量が変化したか、操作とおおむね一致しているか」を確認するのに適しています。一方で、「サーバーの認証に失敗する理由」「特定のドメインに一致したルール」「ストアでの購入成功」を単独で調べる用途には向きません。前者は接続とGlobal Routingの章、購入に関する問題は購入済みアプリの復元ガイドをご覧ください。ツールの用途を明確にすると、数値をトラブル対処の手掛かりとして活用でき、誤解の原因も減らせます。

まず動作確認済みの状態を維持する

Settingsには使用方法や接続動作に影響する項目が集まっていますが、初回の接続に成功した後、すべてを変更する必要はありません。まず、動作確認済みの状態として、選択中のSERVER、Global Routing、現在のConfig、On Demandの使用有無を記録してください。その後、明確な問題に関係する設定だけを調整し、一度に一項目だけ変更して同じ接続先を再確認します。そうすれば動作が悪化した際、複数のスイッチを変更した後で原因を推測するのではなく、どの項目を元に戻せばよいか分かります。デバイスやアプリ内の画面によって表示項目は異なることがあります。項目名と利用できる範囲は実際の画面をご確認ください。

On Demandは、設定した条件に基づいて接続を開始するタイミングを決める機能です。サーバーの速度を上げるボタンではありません。特定のネットワーク環境で自動接続する必要がある場合は、起動条件と例外を明確にしてから該当する設定を有効にしてください。ネットワークへの接続時、切断時、デバイスのロック解除後の状態を確認します。手動接続の問題を調べるだけなら、テスト条件をシンプルにするため、まず自動動作を一時的に無効にしてください。バックグラウンド動作やバッテリー消費に疑問がある場合は、まずシステムに表示されるバッテリー使用状況を確認し、接続頻度とあわせて判断します。アプリが接続を維持しているという事実だけで原因を決めつけないでください。

DNSとルーティングルールを区別する

DNSはドメイン名を後続の接続に必要な情報へ変換します。Global RoutingとConfigのルールは、リクエストの処理方法を決めます。両者には関係がありますが、同じ設定ではありません。システムDNS、カスタムDNS、DNS over HTTPSにはそれぞれ適した場面があります。名前解決の方式を変更したら、以前問題が起きたドメインを再テストし、影響を受けていない接続先も比較用に一つ残してください。サーバー認証情報の誤りが原因の場合、DNSを変更しても通常は直接解決しません。一部のドメインだけで発生する問題は、名前解決の結果とルールの一致をあわせて確認してください。

Configにdns-serverなどの項目がある場合は、どの設定ファイルを編集しているか、変更後に実際に有効になっているかをまず確認してください。解説用の例にあるDNSアドレスを、すべてのネットワークに適した既定値とみなさないでください。以前の値を記録し、一項目だけ変更して保存した後、再テストし、関連する接続を更新する必要があるか確認します。これが一連の設定テストです。3つの名前解決方式と確認手順はDNS設定の解説をご覧ください。既存の情報から追加したConfigを編集する場合は、次回の更新でローカルの変更が上書きされる可能性も考慮してください。

設定ファイルとデバイスの違いに対処する

同じ接続情報をiPhoneとiPadで使っても、各デバイスのSettingsが完全に一致するとは限りません。システムネットワーク、権限の状態、選択中のConfig、ローカル設定をそれぞれ確認してください。Import from Cloud JSONなどのインポート項目は、対応する形式の情報を実際に持っている場合にのみ使用します。通常のサブスクリプションURLで代用しないでください。インポート後は内容を確認してから有効にしてください。入手元が不明な設定で、現在使えている設定を直接上書きするのは避けましょう。

設定をメンテナンスする際は、次の3点を明確にしてください。どの現象を変えたいのか、どの項目が直接関係する可能性があるのか、変更が有効だったかをどう確認するか。答えが分からない場合は、動作確認済みの状態を維持してください。Settingsは必要に応じて動作を調整するためのものであり、すべての項目を一律の状態にするためのものではありません。画面に表示される英語の項目名やルールキーワードを確認する際は、用語集もご利用ください。設定後は接続の章で紹介した方法で、実際の接続先を確認してください。

更新を2種類に分けて確認する

日常のメンテナンスでは、アプリの更新と接続情報の更新を区別してください。Shadowrocket本体はApp Storeから更新します。アプリの情報、互換性、更新履歴を確認する際もストアページを利用します。一方、Subscribeの更新では、自分がすでに持っているサブスクリプションURLからアプリが設定内容を再取得します。どちらも「更新」と呼ばれますが、自動的に連動するわけではありません。新しい項目が表示されない場合は、まずサブスクリプションの更新状況とSERVERを確認してください。アプリの機能や画面の説明が本ガイドと異なる場合は、App Storeの製品ページとアプリ内の現在の表示を確認します。サーバーリストの変化からアプリのバージョンを推測したり、アプリの更新からサブスクリプションの内容も更新済みだと判断したりしないでください。

機種変更前に、App Storeの購入履歴と、現在のデバイスから購入時のアカウントにアクセスできることを確認してください。そのうえで、自分が利用する権限のあるサブスクリプションURL、手動入力に必要な項目、個人用Configの変更、必要なメモを整理します。非公開の情報は自分で管理する安全な場所に保管し、URL全体やキーを公開のディスカッションに投稿しないでください。新しいデバイスでアプリを入手したら、「権限—設定の追加—サーバーの選択—Global Routing—確認」の順に再チェックします。同じ購入アカウントを使っていても、各デバイスのアプリ内に実際にどの項目があり、どの設定が選択されているかを個別に確認してください。購入済みであることだけでは、アプリ内のデータを確認したことにはなりません。

トラブルの再確認に必要な情報を残す

後から状況を振り返れるよう、問題が始まったおおよその時間、iPhoneまたはiPad、ネットワークの種類、接続前後のHomeの状態、選択中のプロトコルとサーバーのメモ、Global Routingのモード、テスト対象と結果を記録してください。変更後に問題が起きた場合は、直前に変更した設定も残します。メモは項目の識別に使い、パスワード、キー、サブスクリプションURL全体は記録しないでください。まず一度再現した後、一つの条件だけ変えて再テストします。結果が変わった場合は、その条件に沿って確認を続けてください。複数の項目を同時に変更すると、次に同じ問題が起きたときに対処しにくくなります。

問題は次の手順に沿って整理できます。アプリは正常に開くか、SERVERに想定した項目があるか、システムのVPN構成権限を確認できているか、接続状態が変化したか、Proxyで選択中のサーバーが使えるか、Configで接続先にどのルールが適用されるか、既知のテストでDataが変化するか。本ページの各章が、それぞれの確認項目に対応しています。サブスクリプションを更新できない場合、最初からDNSやすべてのルールを変更する必要はありません。特定のドメインだけで失敗する場合も、まずアプリを再インストールする必要はありません。問題がどの段階にあるかを特定してから、その段階の設定と条件を確認してください。

頻繁なリセットではなく、定期的な確認を行う

App Storeの製品ページ、保存した元の情報がまだ使えるか、よく使う接続先が現在のConfigで想定どおりかを定期的に確認してください。ネットワーク環境が変わったら、まず簡単な接続確認を行い、そのうえでOn DemandやDNSを調整するか判断します。ルールで使用するドメインやアドレス範囲、個人の要件は変わることがあります。以前一致したルールが今後も有効とは限らないため、設定を変更するたびに元に戻せる状態を保ってください。リストの消去、統計のリセット、すべての情報の再追加は、目的とバックアップ範囲を明確にしてから行う操作です。一度のテスト失敗で最初に試す方法ではありません。

本ガイドは「完了」ボタンを押して終わるものではありません。App Storeで製品を確認し、権限と既存の情報を確かめ、Global Routingで経路を選び、接続を実際に確認し、Dataを参考に通信量を観察して、Settingsでは目的を明確にした項目だけを変更する。この確認手順を繰り返せることが大切です。簡単な手順を最初から確認する場合はクイックスタートガイドへ、購入やデバイスの条件を確認する場合はApp Store正規版の説明をご覧ください。操作箇所はApp Storeの製品ページとアプリ内の現在の表示を基準に確認してください。