Shadowrocket 完全ガイド

段階 01 / 入手

App Storeでの入手と正規品の確認

ShadowrocketはAppleプラットフォーム向けの有料・クローズドソースの商用アプリで、入手先はApp Storeのみです。開始前に、端末で使用しているストアアカウント、購入記録、利用可能な支払い方法を確認してください。アプリの購入とサーバー情報の準備は別の手順です。インストールが完了しても、アプリを使う準備が整っただけで、接続可能なサービスが用意されたことにはなりません。本サイトでは、お手元の情報を追加して使用する方法を説明します。接続サービスは提供していません。

App Storeの製品ページで確認する3項目

正規の入手方法を開き、App Storeの製品ページに移動したら、まずアプリ名Shadowrocketを確認します。続いて開発元Shadow Launch Technology Limited、公式アイコン、アプリID 932747118を照合してください。アプリ名はあくまで最初の確認材料です。類似した名前の検索結果を見分けるには、開発元とアプリIDの確認が有効です。アプリIDは製品リンク末尾のid932747118に対応し、現在のアプリバージョンを示す番号ではありません。

アイコンは本サイトのヘッダーに表示されている公式アイコンと一致するはずです。検索結果、ストアの詳細ページ、購入確認ページの間で画面が切り替わる場合があるため、購入を確定する前に製品名をもう一度確認してください。表示された開発元が異なる場合は操作を中止し、正規の入手方法から開き直してください。アイコンの色が似ているだけで開発元の確認を省略したり、検索順位を正規品の判断基準にしたりしないでください。

買い切り購入と対応デバイスの範囲

Shadowrocketはアプリの買い切り方式です。価格、通貨、税額はApp Storeの製品ページに表示される内容をご確認ください。アプリの買い切り購入と接続サービスの契約は別です。アプリの料金に、お手元のサービスの利用料金は含まれず、サービスの有効期限、通信量、アカウント認証にも影響しません。接続に失敗した場合は、アプリとサービスの状態を分けて確認してください。「アプリを購入済み」という理由だけで、サーバーが利用可能だと判断することはできません。

本ハンドブックでは主にiPhone・iPadでの操作を解説します。Mac、Apple TV、Apple Visionの対応状況も同じApp Storeの製品ページで確認できます。システム要件、対応デバイス、その他のデバイスでの購入適用範囲は、App Storeの製品ページに記載された内容をご確認ください。デバイスによって画面レイアウトや入力方法が異なる場合があるため、あるデバイスのボタン位置を別のデバイスでの操作手順として扱わないでください。

インストール後は購入記録と設定データを分けて管理

インストールが完了したら、ホーム画面からShadowrocketを開き、正常に起動することを確認してから情報を追加します。App Storeの購入記録はアプリの再入手に使います。サーバー情報と設定データは別途保存してください。購入記録を復元してもローカル設定がすべて戻るわけではありません。再インストール後に、サブスクリプションのグループ、手動で追加したサーバー、カスタムルールがすべて復元されるとも限りません。

機種変更や再インストールの際は、まずApp Storeで元の購入アカウントの購入済み項目を確認し、購入済みアイテムの復元方法に沿ってください。ストアに再び価格が表示される場合は、操作を繰り返す前にアカウントと購入記録を確認します。購入済み項目の表示は、現在のストア地域やアカウントの状態にも左右されます。まずストア内で確認し、クライアントの接続パラメータを変更して解決しようとしないでください。

段階 02 / 権限

初回起動とシステムVPN構成

Shadowrocketを初めて開いたら、Home、Config、Data、Settingsの役割を確認しましょう。Homeでは主にサーバーと接続状態を確認します。Configは振り分け設定、Dataは通信量に関する情報、Settingsはよく使う動作設定を管理します。画面の具体的な構成は、現在のアプリ表示に従ってください。各項目の役割を把握してから操作すると、複数のスイッチを同時に変更するより、問題の原因を特定しやすくなります。

システムがVPN構成の追加を求める理由

サーバー情報を準備した後、初めて接続を有効にすると、VPN構成の追加を許可するかシステムから確認されることがあります。これはAppleのシステムがネットワーク拡張機能による接続を管理するための許可手順で、クライアントがシステムのネットワーク機能を通じて通信を処理できるようにします。Configのルールファイルとは別のものです。システムのVPN構成は「アプリが対象の通信を処理できるか」を扱い、Configは「処理するリクエストをどう扱うか」を決めます。

確認画面がShadowrocketで接続を開始した直後に表示されたことを確認し、システムの案内に従って許可してください。端末の認証を求められる場合があります。許可後はアプリに戻り、スイッチと接続状態を確認します。構成の追加を許可しただけでサーバー認証が成功したと判断しないでください。このシステム許可では、アドレス、パスワード、UUID、接続先サービスの状態は検証されません。サーバーに到達できなくても、システム構成は作成されている場合があります。

許可を拒否した場合、削除した場合、または確認が繰り返し表示される場合

許可を拒否した場合は、まずアプリに戻り、サーバー情報が保存されていることを確認してから、接続を再度有効にしてシステムの許可手順が表示されるか確認します。想定した確認画面が表示されない場合は、端末のシステム設定にあるVPN管理画面で該当する構成を確認してください。システムの画面構成は変わることがあるため、固定の階層をそのまま探すのではなく、VPN項目の名前で確認します。用途が確認できていない他の構成は削除しないでください。

システム設定からShadowrocketのVPN構成を削除した場合、その後の接続で再度許可が必要になることがあります。対応する前に接続を切り、アプリから新しい接続要求を開始してください。許可を繰り返しても失敗する場合は、システムに表示されたメッセージ、デバイス管理の制限の有無、他のVPN接続が実行中かどうかを記録します。まず権限の問題を解決し、プロトコル、DNS、ルールを同時に変更しないでください。

カメラ、写真、ネットワークの各権限の用途

Scan QR Codeを使うには、カメラで読み取る場合にカメラへのアクセスが必要です。画像からQRコードを読み取る場合は、システムの写真選択機能を使うことがあります。これらの権限は情報の追加方法に関するもので、Add Serverに手入力する場合に事前の読み取りは必要ありません。QRコードには認証情報がすべて含まれている場合があります。読み取る前に、ご自身のサービスの情報であることを確認し、読み取った後もプロトコル、アドレス、ポートを照合してください。

ローカルネットワークへのアクセスに関する確認が表示された場合は、ローカルネットワーク上の機器へのアクセスなど、その時点で使っている機能に照らして目的を判断してください。この権限はVPN構成の許可に代わるものではありません。通知などの補助的な権限も接続許可とは異なります。複数の確認画面が表示された場合は、一つずつ内容を読み、「以前に許可を押した」ことだけで必要な権限がすべて有効だと判断しないでください。どの項目を拒否したか記録しておくと、後で適切に再設定できます。

初回接続を再現できる条件に整える

初回設定では、安定したネットワーク環境を使い、Wi-FiとCellularを頻繁に切り替えないようにします。まずクライアントの接続を切った状態で通常のネットワークが使えることを確認し、正しいパラメータを1組保存してシステムの許可を済ませ、アプリとシステムの状態が一致するか確認してください。組織の管理下にあるデバイスでは、ポリシーによりネットワーク拡張機能の操作が制限されることがあります。デバイス管理のルールに従い、その制限をサーバーの障害と混同しないでください。

この段階で確認できるのは、アプリの起動とシステムの許可手順が正常に進んだことまでです。接続後は、対象のリクエストが成功したか、Global Routingが想定どおりかを確認します。詳しくは第5章を参照してください。権限の確認画面とシステム構成の関係は、初回接続時に表示されるVPN構成の確認画面で解説しています。問題を調べる際は、「接続できない」とだけ記すより、画面に表示された文面をそのまま残すと役立ちます。

段階 03 / 追加

サーバーの追加とSubscribeの管理

情報を追加する前に、手元にあるものが単一サーバーのパラメータ、サーバー情報を含むQRコード、サブスクリプションリンクのどれかを確認してください。入力の種類によって操作が異なります。通常のウェブページのURLをサブスクリプションとして扱ったり、サブスクリプションリンクを単一サーバーのアドレス欄に入力したりしないでください。入力する情報はすべて、ご自身がすでに利用しているサービスのものに限ります。本章では正確な入力と確認方法を説明し、サービスの選び方は案内しません。

Add Serverの各項目に対応する情報を入力

Add Serverを開いたら、手元の情報と一致するプロトコルを選び、アドレスとポートを入力します。アドレスは通常、ドメイン名またはIPアドレスです。パスを独自に追加しないでください。ポートは接続先が待ち受けているポートと一致させます。続いて、そのプロトコルで必要な認証項目を入力してください。項目が空欄だからといって任意の値を補ったり、説明文のラベルまで一緒にコピーしたりしないでください。入力後に保存し、もう一度開いて内容を確認します。

認証に成功しても、トランスポートの設定が正しいとは限りません。TLSのサーバー名やWebSocketのパスとHostなどは、それぞれ異なる役割を持つ項目です。手元のパラメータに従って個別に入力し、似たサーバーアドレスで代用しないでください。証明書の検証に失敗した場合は、名前、端末の時刻、接続先の証明書を確認します。検証を無効にする方法を日常的な解決策にしないでください。VMessとVLESSの項目の違いは、プロトコルパラメータの違いで解説しています。

Subscribe：追加と更新は別の操作

サブスクリプションを追加すると、リンクから取得した内容を読み込み、サーバーグループが作成されます。更新は、アドレスやポートなどの変更を反映するために内容を再取得する操作です。追加時はアプリが用意するサブスクリプションの方法に従ってリンクを入力し、保存後に処理が完了するのを待ってから、グループ内にサーバーが表示されることを確認してください。グループ名だけがあり、使用できる項目がない場合は、取得した内容を確認します。名前が表示されただけで追加が成功したとは限りません。

サブスクリプションリンクには個人用の認証情報が含まれることが多いため、公開の会話、スクリーンショット、問い合わせ内容に掲載しないでください。コピーする際は末尾が欠けていないか、空白が混入していないか、リッチテキストから表示文字列だけをコピーしていないか確認します。更新に失敗した場合は、まず具体的なエラーを記録します。そのうえで通常のネットワークからリンクにアクセスできるか、サービスが有効か、応答がログイン画面やエラーページになっていないかを確認してください。原因を調べずに更新を何度も押さないでください。

QRコードから追加した後も内容を確認

Scan QR Codeで読み取った後、新しい項目のプロトコル、メモ、アドレスが想定どおりか確認してください。QRコードは単一サーバーを表す場合も、サブスクリプションの入口を示す場合もあります。追加結果はアプリが作成した項目に基づいて判断します。読み取りに成功しても期待した内容が表示されない場合は、まず入力の種類を確認し、リンクをすぐに手作業で組み立てないでください。出所が不明、または内容を照合できない場合は使用を中止し、ご自身の正しい情報を入手し直してください。

手動変更とサブスクリプションによる上書き

サブスクリプション内の項目は、取得した内容に基づいて管理されます。パラメータを手動で変更しても、次回の更新でその項目が上書きされる場合があります。一時的な検証が必要な場合は、元の値を記録し、できるだけ独立したテスト項目を使ってください。グループ全体を変更して後から追跡しにくくなるのを避けられます。サーバーの表示名はメモにすぎません。同じ名前でも同じアドレスとは限らないため、重複を整理するときはプロトコル、アドレス、ポートを確認してください。

追加後はサーバーを1つ選んで、まず1回だけ接続を確認します。すべての項目をすぐにテストする必要はありません。以前の項目は使えるのに新しい項目が使えない場合は、新旧のパラメータとサービスの状態を優先して比較します。すべての項目で失敗する場合は、システム権限、ローカルネットワーク、追加方法を確認してください。古いグループを削除する前に、新しいグループで実際のアクセスが成功したことを確認し、必要なときに戻せるデータを残します。

段階 04 / 振り分け

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

Global Routingでは、クライアントが処理するリクエストの扱い方を選びます。Configは現在の設定にあるルールに従って処理し、Proxyは対象のリクエストを選択したプロキシに渡し、Directは直接接続で処理します。ここで説明するのはクライアントが処理する範囲のリクエストです。どのモードでも、端末上のすべての通信が必ず同じ経路を通るわけではありません。システムの仕組み、アプリの動作、接続の種類によって観察結果は変わります。

モードを選んでからアクセス結果を確認

日常的にルールで振り分ける場合はConfigを使い、現在有効な設定を確認してください。問題を調べる際はProxyとConfigを一時的に比較できます。同じ対象にProxyではアクセスでき、Configでは失敗する場合、ルール、ポリシーの参照、DNS処理を優先して確認します。ただし、この比較だけで原因を断定することはできません。キャッシュ、接続の再利用、ネットワークの変化が影響する場合もあるため、近い条件で再確認してください。

ルールは通常、記載順に照合される

ルールファイルでは、具体的な条件を広範な条件より先に記述し、前のルールに一致しなかったリクエストを最後のFINALで処理します。DOMAINは特定のドメイン名、DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはアドレス範囲、GEOIPはアドレスの所在地データベースに基づいて照合します。ルールキーワードとポリシー名は別のものです。前者は何に一致するかを決め、後者は一致後にどの方法で処理するかを決めます。

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

以下はルールの順序を説明するためのShadowrocket .confの例で、すべてのネットワークに使える完全な設定ではありません。1行目は例示したドメインのサフィックスをPROXYに渡し、2行目は指定したプライベートアドレス範囲をDIRECTで処理します。3行目はGEOIPに基づいて処理し、最後の行はそれまでのルールに一致しなかったリクエストを受け持ちます。実際に使う際は、ご自身のLANアドレス、目的、設定内で利用できるポリシーを確認してください。この例をコピーするだけで振り分けが完成するわけではありません。

ドメインルールとIPルールで結果が異なる理由

ドメインの照合には、リクエスト内で認識できるドメイン情報が必要です。一方、IPルールは接続先のアドレスを対象とします。アプリがIPアドレスに直接接続する場合や、すでにキャッシュされた名前解決結果を使う場合、ドメインルールだけでは関連するリクエストをすべて処理できないことがあります。1つのページから複数のドメインにリクエストが送られることもあります。ページ本体は表示されるのに画像が読み込めない場合は、関連するリソースのリクエストも確認してください。メインのドメインにルールを1つ追加するだけで解決するとは限りません。

GEOIPの判定はデータベースと名前解決の結果に依存し、ウェブサイトの表示言語、ブランドの所在地、ユーザーに表示される内容とは別のものです。接続先が複数のアドレスを使用したり、アドレスが変わったりすると、判定結果も変わる場合があります。判断が難しい場合は、まず実際の接続先を確認し、明示的なドメイン、アドレス範囲、その他のルールのどれを使うべきか検討してください。単一のアクセス問題に対処するためだけに、アドレス範囲全体の処理を安易に広げないでください。

Configの変更後は必ず再確認

まず元の設定ファイルを複製し、目的を明確にしたルールを1つだけ変更します。保存後、変更した設定が現在使用されていることを確認してください。設定一覧にファイルがあるだけでは、有効になっているとは限りません。似た名前のファイルがある場合は、特に注意して照合してください。参照先のポリシー名が存在しない、ルールの形式が正しくない、リモートリソースの更新に失敗している場合は、ネットワークアクセスをテストする前に設定の問題を解決します。

段階 05 / 接続確認

接続スイッチ、Connectivity Test、実際のアクセス

接続を確認するには、システムが起動を許可しているか、サーバーとの通信経路を確立できるか、対象へのリクエストが想定どおりに完了するか、3つの段階を確認します。スイッチがオンのままでも、それは一部の状態を示すにすぎず、ウェブページにアクセスできる証明にはなりません。同様に、1回のテストがタイムアウトしても、すべてのネットワーク経路が使えないとは限りません。段階ごとに結果を記録すれば、「ときどき使える」という曖昧な説明に隠れた違いを見つけやすくなります。

比較の基準をそろえる

まず接続を切り、現在のWi-FiまたはCellularで通常のネットワークアクセスができることを確認します。通常のネットワークでログインが必要、または接続が切れている場合は、先に基礎ネットワークの問題を解決してください。その後、確認済みのサーバーを1つとGlobal Routingのモードを1つに固定して接続し、状態が安定するまで待ちます。検証中は同じ対象を使い、ネットワーク、サーバー、ルールを同時に変更しないでください。

実際のアクセスでは、対象のページが最後まで読み込まれるか、各リソースが継続して取得されるか、新しいリクエストが繰り返し成功するかを確認します。すでに開いているページはキャッシュから表示されている場合があるため、更新アイコンが止まっただけでは判断できません。必要に応じて対象アプリの既存の接続を閉じ、新しいリクエストを送るか、別の明確な新規リクエストで確認してください。検証のために端末のデータをすべて消去する必要はありません。

Connectivity Testで確認できること

Connectivity Testはテスト対象への接続状況を確認するための補助機能です。結果はテスト方法、対象、実行時のネットワーク状況に左右されます。数値が低くてもダウンロード速度が必ず高いとは限らず、すべてのウェブサイトにアクセスできるとも限りません。サーバーのテストに成功しても、実際のアクセスに必要なDNS、TLS、アプリのプロトコル、リソースのドメインで問題が起こることがあります。テスト結果は実際のアクセスとあわせて確認してください。

サーバーを比較する場合は、テスト方法とネットワーク環境をできるだけ統一し、条件の異なる数値をそのまま順位付けしないでください。1回のタイムアウトは再試行して確認できますが、すべての項目を続けて何度もテストする必要はありません。過度なテストは余計なリクエストを増やし、状況の把握を妨げることもあります。一時的な数値を覚えるより、代表的な成功例と失敗例を記録してください。

失敗した段階から原因を絞り込む

スイッチがすぐにオフに戻る場合は、システムのVPN構成、権限、アプリの表示を確認します。スイッチがオンのままなのに実際のリクエストがすべて失敗する場合は、サーバーのアドレス、ポート、認証、トランスポート、基礎ネットワークを確認してください。特定の対象だけ失敗する場合は、その対象の名前解決、ルールの照合、接続先の状態を確認します。認証エラー、証明書エラー、タイムアウトはそれぞれ意味が異なります。「接続できない」にまとめず、エラーの文面をそのまま残してください。

テストに成功してもウェブページが開かない場合は、まずDNSで有効な結果が返るか確認し、同じリクエストをConfigとProxyで比較してください。名前解決に成功していても、その後の経路から到達できないアドレスが返ることがあります。続いて発生した接続エラーもあわせて確認してください。詳しい手順はDNS名前解決の失敗を調べる手順を参照してください。すべてのDNS設定を一度に置き換えて試さないでください。

速度の問題と接続の問題を分けて確認

接続はできるのに速度が安定しない場合は、接続確立の遅さ、個別リクエストの遅さ、継続的なデータ転送の遅さを分けて考えます。前の2つには名前解決やハンドシェイクが関係する場合があります。継続的な転送には、接続先の負荷、端末側の電波状況、ネットワークの混雑、接続先の制限も影響します。遅延は判断材料の1つであり、通信速度を直接換算する値ではありません。ネットワークを変えて結果が変わっても、ローカルの経路を確認する手掛かりになるにとどまります。

速度が遅い場合の段階的な確認方法に沿って条件をそろえて比較してください。一時的なテストが終わったら、普段使うモードに戻します。特に、問題を調べるために使ったProxyやDirectを、目的に合わないまま常用しないでください。それでも原因を特定できない場合は、ネットワークの種類、プロトコル、モード、エラーの原文、再現手順をまとめてから、よくある質問の該当項目を確認してください。

段階 06 / 状況の確認

Dataの通信量と統計の範囲

Dataでは、クライアントが統計できる通信の状況を確認できます。接続中にリクエストやデータ転送が発生しているかを判断する際の参考になりますが、サービスの請求額ではなく、すべてのリクエスト経路を判断する唯一の手段でもありません。数値を読む前に、統計の対象範囲、画面上の分類、単位、集計の開始・終了時刻を確認してください。範囲の異なる数値は、似た値に見えても単純に差し引いて結論を出せません。

アップロード、ダウンロード、速度の見方

アップロードとダウンロードは、端末に対するデータの方向を示します。アップロードには通常、リクエスト、送信データ、接続中のやり取りが含まれます。ダウンロードには応答データや受信内容が含まれます。ページを開くだけでもアップロードは発生するため、アップロードがゼロでないからといって、大きなファイルを端末から送信しているとは限りません。接続の確立、再試行、バックグラウンドの動作でも数値が増えることがあります。実行中の操作とあわせて確認してください。

速度は一定の時間内にデータがどの程度変化したかを示し、累計通信量は集計期間内の総量を示します。一時的に速度が落ちても、新しいデータが発生していないだけの場合があり、接続が切れたとは限りません。累計値が増えていても、対象ページの読み込みが完了した証拠にはなりません。画面の単位がバイト系かビット系かを確認してください。単位が異なると、数値に大きな差があるように見えることがあります。

サーバー別・アプリ別に表示する際の注意点

サーバー別に確認する際は、現在選択されているサーバー名だけでなく、同じ集計期間にそのサーバーが処理したデータの変化に注目してください。サーバーを切り替えた後、以前の接続の継続時間や数値の扱いは実際の画面表示に基づいて判断します。選択項目が変われば過去の統計もすべて即座に切り替わるとは限りません。画面に複数の表示方法がある場合は、現在の表示名と分類の基準を確認してください。

現在の画面でアプリ別またはプロセス別の情報が提供されている場合も、それはクライアントが識別できる範囲の結果です。端末上のすべてのアプリ通信を完全に記録したものではありません。システムが取得できる情報、共有接続、バックグラウンドのリクエストが分類に影響します。識別できない通信を無理に特定のアプリへ割り当てないでください。具体的な表示範囲は現在のアプリ画面に従ってください。項目が表示されていないからといって、通信がまったくないとは判断できません。

サービス側の記録と一致しない理由

クライアントの統計と、利用中のサービスの管理画面では、集計期間、請求サイクル、単位換算、プロトコルのオーバーヘッドの扱いが異なる場合があります。サービス側では同じアカウントを使う別の端末や接続も集計される一方、クライアントにはこの端末で統計できる通信だけが表示されることがあります。まず期間と端末をそろえ、アップロード・ダウンロード、再送、追加の接続オーバーヘッドが含まれるか確認してください。単純な合計値の比較より有効な判断につながります。

観察を始めた時点ですでにバックグラウンドのリクエストがある場合、初期値はゼロではありません。テスト中にサブスクリプションの自動更新、接続確認、他のアプリの同期が動いて、追加の通信が発生することもあります。小規模な比較をする場合は開始時と終了時の値を記録し、テスト時間と対象を統一してください。「ゼロに戻す」ために統計履歴を削除したり、すべての設定をリセットしたりしないでください。

Dataを範囲を定めた診断に活用する

接続を有効にして新しいリクエストを送ったのに想定した通信量の変化が見られない場合は、リクエストが現在の統計範囲に含まれるか、キャッシュが使われていないかを確認してください。アップロードが増える一方で、ダウンロードに長く目立った変化がない場合は、接続先の応答を追加で調べる手掛かりになります。ただし、この現象だけで特定の認証エラーだと判断することはできません。接続時の表示、名前解決の結果、ルールの処理状況も確認してください。

テストの開始時刻、対象、モード、サーバーを記録し、対応する数値の変化を確認します。その後、条件を1つだけ変更して再テストしてください。統計と実際の操作を関連付けて把握できます。数値の見方はDataの通信量統計の見方で解説しています。問題を報告する場合は必要な統計の概要だけを残し、サーバーアドレス、個人識別情報、認証情報を隠してください。画面全体の記録を公開する必要はありません。

段階 07 / 設定

Settings、DNS、On Demand

Settingsの項目はクライアントの動作に影響し、Configの項目は現在の設定におけるリクエストの処理に影響する場合があります。各機能の場所は、現在のアプリ画面に従ってください。変更する前に、解決したい症状と、その項目が全体の動作に作用するのか、特定の設定だけに作用するのかを確認します。適用範囲がわからない場合は既定値を維持し、内容を確認してください。関連して見えるスイッチをすべて同時に有効にしないでください。

On Demand：自動接続の条件と手動接続

On Demandはシステムの条件に応じて接続の開始や維持を要求する機能です。一般的な条件にはWi-FiやCellularが含まれます。サーバーが利用可能であることを保証する機能ではなく、接続に失敗した場合に別のサーバーへ自動で切り替えるという意味でもありません。有効にする前に、まず手動接続が安定して動作することを確認し、どのネットワーク条件で接続する必要があるかを決めてください。基礎的な接続障害と自動接続の動作を混同しないようにします。

まず同じネットワーク環境でルールの動作を確認し、その後別のネットワークに切り替えて観察します。手動でオフにした後に再度接続が開始されるかどうかは、現在の条件とシステムの状態によって異なります。接続が繰り返し有効になる場合は、主スイッチを何度も操作するのではなく、On Demandの条件が引き続き満たされているか確認してください。一時的に無効にする場合も、自動接続の設定を理解し、システムの状態が意図したとおりになっていることを確認します。

Wi-Fi名の条件は正確に照合してください。名前が似ていても同じネットワークとは限りません。ウェブページへのログインが必要なWi-Fiでは、まず通常のネットワーク認証を済ませてから自動接続を確認します。スリープ、ネットワークの再接続、切り替えの状態によってシステムが条件を再評価することがあります。一時的な変化は時間の経過とともに観察し、1回切り替えただけであらゆる状況を検証済みと判断しないでください。

DNSは役割を確認してからアドレスを設定

DNSはドメイン名をアドレスに変換しますが、名前解決の経路と、その後の接続経路は別の問題です。DNSを変更する前に、失敗が名前解決段階か接続段階かを判断してください。ドメイン名の結果が得られない、またはエラーが返る場合と、アドレスは得られるが接続がタイムアウトする場合では、確認すべき内容が異なります。ページが開かないという理由だけでDNSを変更すると、単純な問題に新たな要因を加えてしまうことがあります。

カスタムの名前解決方式を使う場合は、現在のネットワークからその方式に到達できることと、リクエストの処理方法を確認してください。LAN内の名前、内部ドメイン、公開ドメインでは必要な設定が異なる場合があり、1つの設定があらゆる環境に適しているとは限りません。変更後は新しいリクエストを送って確認します。キャッシュや既存の接続によって古い結果がしばらく残ることもあります。1回結果が変わらなかったからといって、さらに設定を重ねないでください。

ログ、テスト、プライバシー情報

ログは問題を再現する際に必要な範囲で確認し、エラーの原文、時刻、対象、再現条件を記録します。詳細なログを長期間保存すると、端末のストレージを使用し、アクセスに関する情報が蓄積される場合があります。共有する前に、完全なサブスクリプションリンク、認証項目、個人識別情報を削除してください。ドメインの一覧から利用状況が推測されることもあるため、必要最小限の範囲で提供します。

接続テストの設定は、テスト対象や方法に影響します。変更後は、条件が異なる以前の数値とそのまま比較しないでください。対象自体が不安定な場合、結果も変わる可能性があります。原因を調べる間はテスト条件を固定し、実際のアクセスも追加で確認してください。小さな数値を得るために設定を何度も変更しないでください。

変更後に元へ戻せる手順を確保

Settingsを変更する前に、元の値、変更理由、想定する結果を記録します。Configを変更する場合は、設定ファイルの複製を別に保存してください。アプリから再接続を求められた場合は、重要な通信を停止してから操作します。変更しても問題が改善しなければ、元の値に戻してから次の項目を確認してください。説明できない試行設定を複数残さないようにします。

段階 08 / メンテナンス

更新、バックアップ、トラブル記録

安定して使えるようになった後は、頻繁に設定を変えるより、復元できる状態を保ち、変化があったときに原因を追えるようにすることが大切です。クライアント、サブスクリプション、Config、システムの更新はそれぞれ別の操作で、影響する範囲も異なる場合があります。重要な変更は一度に1種類ずつ行い、動作を確認してから次に進むと、問題発生時の原因特定が容易になります。

クライアントの更新はApp Storeから

App StoreでShadowrocketの更新履歴と現在の端末への対応状況を確認し、ストアの案内に従って更新してください。更新前に、必要なパラメータとローカルの設定をバックアップします。更新後は以前と同じサーバーとモードで動作を確認し、すべての設定を一度に入れ替えないでください。動作が変わった場合は、変更前後の操作とアプリに表示された内容を記録します。特定のバージョンが必ず原因だと推測する必要はありません。

システムの更新によって、権限の確認画面、ネットワーク切り替え時の動作、設定画面の場所が変わる場合もあります。更新後、初回接続時に再確認を求められた場合は、画面を読み、該当するシステム構成を確認してください。すべてのデータをすぐに削除しないでください。システム要件はApp Storeの製品ページに記載された内容をご確認ください。アプリが正常に起動しても接続に問題がある場合は、権限、サーバー、ルール、DNSの順に確認します。

役立つバックアップの対象

少なくとも、手動で追加したサーバーに必要なパラメータ、サブスクリプションの取得元、現在のConfigファイル、重要なSettingsの元の値を分けて保存してください。サブスクリプションリンクは、長期間使えるサーバー情報のスナップショットとは限りません。サービスの内容が変わると、再取得した結果も異なることがあります。バックアップには保存日時と用途を記載し、認証情報を公開ファイル名、スクリーンショットの見出し、共有ドキュメントに含めないでください。

アプリに現在用意されている書き出し機能や保存機能を使う場合は、何が書き出されるのか確認し、必要な内容が含まれているか調べてください。書き出し完了の表示だけでは、復元できることの確認にはなりません。重要な設定は元のデータを残したまま、読み込めることを確認してください。バックアップはご自身で管理できるアクセス制限付きの場所に保管します。ルールの例を共有する場合は、個人のサーバー情報とサブスクリプション情報を事前に削除してください。

サブスクリプションとConfigは分けて管理

サブスクリプションを更新した後は、項目数と重要なパラメータが想定どおりかを確認してから接続を検証してください。項目が減った場合は、取得した内容とサービスの状態を確認し、すぐに古い情報をすべて削除しないでください。Configを更新した場合は、ルールの順序、ポリシーの参照、リモートリソースの状態を確認します。2種類の更新を同時に行うと、失敗の原因を区別しにくくなります。すでに接続できない状況では、特に避けてください。

重複項目を整理するときは、メモの名前だけでなく、実際のプロトコル、アドレス、ポートで見分けてください。検証済みで元に戻せる設定を1つ残し、新しい状態が安定してから古いファイルを整理します。出所や用途が不明な設定を安易に追加しないでください。ファイルの数が多いほど機能が充実するわけではありません。現在有効な項目が明確で、参照関係が正しく保たれていることがメンテナンスの目標です。

再現可能なトラブル記録を整理

有効な記録には、発生時のネットワークの種類、直前にネットワークを切り替えたか、使用したプロトコル、Global Routingのモード、具体的なエラーの原文、失敗する対象の範囲、最後に正常だった状態を含めます。試した設定変更を1つずつ、その結果とあわせて記録してください。「すべてのリクエストが失敗」「特定の対象だけ失敗」「テストは失敗したが実際のアクセスは正常」といった異なる状況を区別できます。

記録にパスワード、UUID、完全なサブスクリプションリンク、個人を特定できる情報を含める必要はありません。必要に応じて実際のアドレスを説明用の表記に置き換え、プロトコル、エラーの種類、発生順序を残してください。FAQを確認する場合や、入門ガイドで基本手順を見直す場合は、記録に沿って項目ごとに確認します。結果を変えようとして、追加手順を最初から何度も繰り返さないでください。