公式マニュアル / Settings 設定項目ガイド

Shadowrocket
Settingsの設定項目と設定の目安

DNS、On Demand、Proxy、Ping、Log、Widget、iCloud同期を用途別に解説します。設定の対象範囲を確認してから、変更が必要か判断しましょう。

ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。開発者はShadow Launch Technology Limited、アプリIDは932747118です。対応デバイスとシステム要件はApp Storeの掲載内容をご確認ください。購入前にApp Storeで正規アプリを確認する方法をご覧ください。

このページは設定項目を確認するためのマニュアルで、初回接続の手順に代わるものではありません。インポートと許可設定がまだの場合は、まず入門ガイドに沿って一連の手順を完了してください。接続できていて、特定の項目を確認したい場合は、このページに戻ってください。以下は、ご自身のサブスクリプションまたはサーバー情報をお持ちであることを前提としています。クライアントの買い切り購入と接続サービスの契約は別です。

現在の状態を先に記録変更は一度に1項目初期値はデバイスの表示を確認

01 / 設定の適用範囲と現在の状態

Settingsの基本と変更の進め方

アプリ設定・構成ファイル・サーバー設定の違い

Settings（設定）には主にクライアントの動作に関する項目がありますが、接続はここだけで決まるわけではありません。Home（ホーム）で選択したサーバー、Global Routing（グローバルルーティング）のモード、Config（構成）で有効になっているファイル、システムから付与されたVPNの許可が組み合わさり、リクエストの処理方法が決まります。トラブルの原因を調べる前に、どの層の問題かを切り分けましょう。そうしないと、認証エラーの原因をDNSに求めたり、ルールの適用ミスをサーバーの切り替えで覆い隠したりすることがあります。

サーバーアドレス、ポート、認証情報、プロトコルの通信パラメータは接続情報にあたるため、お手元の情報と一つずつ照合してください。ルールの順序や適用先のポリシー、一部の名前解決動作は構成ファイルに由来する場合があります。Widget（ウィジェット）とログは操作や状況の確認に使うもので、サーバー情報の問題を修正するものではありません。各項目を分けて記録しておくと、変更が原因に影響したか確認でき、試行後に関係する箇所だけ元に戻せます。

特定のデバイスに表示されるスイッチの状態を、すべての環境に共通する初期値として扱うことはできません。初回インストール、データの復元、構成のインポート、デバイス間の同期によって、開始時の状態は異なる場合があります。初期値は、設定を変更していない実際の環境で確認してください。すでにデータがあるデバイスでは「現在値」として扱います。画面に項目が見当たらない場合、記事と比較するためだけに存在しないメニューや設定を作らないでください。

Global Routingの3つのモード

モード	主な用途	確認する項目
Config（構成）	現在の構成に含まれるルールに基づいて通信を振り分けます。	有効な構成、ルールの順序、ポリシーの適用先。
Proxy（プロキシ）	対象となる通信を選択中のプロキシ経由で処理します。	サーバーへの接続と、リクエスト先へのアクセス状況。
Direct（直接接続）	対象となる通信を直接接続として処理します。	現在のネットワーク自体のアクセス状況と名前解決。

3つのモードは速度の段階を示すものではなく、接続先サービスの能力を変えるものでもありません。日常的にルールで通信を振り分ける場合は、Configの仕組みを理解し、適切に管理することが前提です。ProxyとDirectは一時的な比較に使えますが、テスト後は元のモードに戻してください。Directはルーティング方法を示すもので、システムVPNがオフになったことを意味しません。接続が切れているか判断する際は、アプリの接続状態とシステムのVPN状態をあわせて確認してください。

元に戻せる変更記録を作る

現在のネットワーク種別、接続状態、サーバーのメモ、Global Routingのモード、有効な構成名を記録します。サブスクリプションの完全なURLは記録しないでください。
変更する項目、現在値、変更する理由、確認したい結果を書き留めてから、その項目だけを変更します。
以前のリクエストを終了します。接続の再確立が必要な設定は、一度切断してから再接続し、同じ対象で確認してください。
改善が見られなければ元の値に戻してから次の項目を確認します。検証していない変更をいくつも重ねたままにしないでください。

設定値は、すべてのスイッチをオンにするのではなく、具体的なニーズに合わせて決めます。特定の名前解決要件がなければ、動作確認済みのDNS設定を維持してください。自動接続の条件が分からない場合は、まず手動で接続します。トラブル対処後は、詳細ログを日常利用に必要なレベルに戻してください。これらは設定を調整する際の考え方であり、デバイスに表示される初期状態に代わるものではありません。安定して利用できている場合に、設定をやり直す必要はありません。

システムの初回許可がまだの場合は、高度な項目を調整するのではなく、まず入門手順に戻ってください。特定の対象だけに問題がある場合は、現在の接続を維持しながらリクエストの記録を確認します。すべての対象で同時に失敗する場合は、基本ネットワークとサーバー接続を先に確認してください。現象別の確認方法はよくある質問を参照し、該当する章を読み進めてください。

02 / ドメイン名の解決

DNS設定と名前解決の経路

名前解決の成功とリクエストの成功は別

DNS（ドメインネームシステム）はドメイン名を接続先のアドレスに変換しますが、アドレスを取得できても対象サービスが利用可能とは限りません。リクエストは、ローカルでの名前解決、ルール判定、プロキシ接続、接続先からの応答などを経る場合があります。構成によって、名前解決とルール判定の順序や実行場所も異なります。ページが開かない場合は、どの段階で失敗したか確認してください。DNSを変更して一時的に回復したからといって、すべての問題を名前解決のせいにすることはできません。

サーバーのドメイン名と接続先のドメイン名を区別してください。前者はプロキシサーバーへの接続に使われ、名前解決に失敗するとプロキシに到達する前に接続が止まる場合があります。後者はブラウザーなどのアプリがアクセスするアドレスです。両者で異なる経路が使われることがあります。エラーを記録する際は、単に「DNSが使えない」とせず、「サーバーアドレスの名前解決に失敗」か「接続後に接続先ドメインで失敗」かを明記してください。以降の確認手順に直接関わります。

DNS設定を確認するときは、まず有効なConfigにも名前解決に関する設定が含まれているか確認し、そのうえでSettingsに表示される項目を見ます。複数の場所に異なるDNSアドレスを追加したあと、最後に変更した項目だけを見て実際の動作を判断しないでください。設定の優先関係が分からない場合は、現在の構成を保存し、元に戻せる複製で重複設定を減らしてから、Log（ログ）で新しいリクエストを確認します。

初期値と推奨値の考え方

このマニュアルでは、共通のパブリックDNSアドレスを指定したり、特定のアドレスをすべてのネットワークに推奨したりしません。明確な必要がなければ、動作確認済みの現在の名前解決方法を維持してください。ローカルネットワーク内の名前が必要な場合は、現在のネットワークがそれらを解決できるか確認します。すべての名前解決を外部のリゾルバーに任せると、内部ドメインが解決できなくなることがあります。パブリックドメインを解決できることだけでは、利用環境全体に適しているとは判断できません。

画面に暗号化DNSの方式がある場合は、アドレスの形式、証明書の検証、接続条件を確認してください。暗号化は名前解決の通信を保護する方法であり、解決結果が現在のネットワークに適していることを保証するものではありません。リゾルバー自体に接続できる必要もあります。接続前のプロキシが必要なリゾルバーに頼り、そのプロキシサーバーのドメイン名も同じリゾルバーに依存する場合、起動時に依存関係が循環することがあります。まず、接続前に独立して名前解決できる経路を確保してください。

症状	優先して確認する項目	すぐに断定できないこと
接続開始前に失敗する	サーバードメインの名前解決と基本ネットワーク。	接続先のWebサイトに障害があるとは限りません。
内部名だけ解決できない	ネットワークが提供する名前解決と内部ドメインの処理。	パブリックドメインの結果だけで判断できません。
ネットワーク切り替え後に異常が起きる	新しいネットワークへの接続性、キャッシュ、接続の再確立。	切り替え前に成功した記録だけでは判断できません。
一部のアドレスだけ失敗する	アドレスファミリー、ルール経路、接続先への到達性。	すべての名前解決が失敗しているとは限りません。

IPv6、キャッシュ、再検証

1つのドメインから複数のアドレスファミリーのレコードが返ることや、ネットワークの場所に応じて異なるアドレスが返ることがあります。IPv6関連の設定は、現在のネットワークとサーバーまでの経路が対応しているかを基準にしてください。一度のアクセス失敗だけで長期的に無効化するのは避けましょう。同じドメインの結果がネットワークごとに異なる場合は、実際に使われたアドレスファミリー、ルールのポリシー、接続エラーを比較します。名前解決の記録があるのは候補アドレスを取得できたことを示すだけで、その経路で通信が完了する保証にはなりません。

名前解決の設定を変更しても、以前の接続やキャッシュが結果に影響する場合があります。対象アプリで古いリクエストを終了し、必要であればShadowrocketの接続を再確立してから新たにアクセスしてください。現在の画面に関連キャッシュを消去する操作がある場合は、元の状態を記録してから実行できます。同じページを何度も再読み込みしても、既存の接続が再利用されたり、ネットワークリクエストを発生させずにキャッシュが読み込まれたりするため、独立したテストにはなりません。

再現可能な確認手順は、基本ネットワークからアクセスできることを確認し、サーバードメインが解決できることを確かめてから接続を確立し、決めた対象にアクセスして該当する記録を見ることです。その後、DNS関連の項目を一つだけ変更し、必要な接続を再確立して同じ手順を繰り返します。変更前後は同じネットワークとルーティングモードで記録してください。途中でネットワークを切り替えた場合は別のテストとして扱い、単純に比較しないでください。

トラブル対処が終わったら、一時的に追加したものの効果を確認できなかったDNS項目を削除するか、元の値に戻し、最終設定を選んだ理由を残します。長期的に使う設定には、内部ドメインの名前解決を維持する、既知のネットワーク要件を満たす、再現した依存問題を解消するといった適用理由が必要です。単に「以前はこのアドレスで動いた」という記憶だけで選ばないでください。

03 / 自動接続とシステムの許可

On Demandの接続開始と停止

オンデマンド接続は、常に通信リクエストを発生させる機能ではありません

On Demand（オンデマンド接続）は、設定済みの条件に基づいてシステムが接続開始を管理する機能です。接続を試みるタイミングを扱うもので、接続先へのアクセスに使うルールを選ぶ機能ではありません。有効にしても、正しいサーバー情報、利用可能なネットワーク、必要なシステム許可が必要です。認証情報が無効なら、自動接続を繰り返しても同じエラーが起きるだけで、サーバー設定を自動修正したりサブスクリプション情報を補ったりすることはありません。

この項目を確認するときは、アプリ内の設定、システムに保存されたVPN構成、現在の接続状態を分けて考えてください。アプリをバックグラウンドに移しただけで、システムの接続が終了するとは限りません。手動で一度切断しても、その後に条件が一致すれば再接続される場合があります。動作を判断するには、自動接続を無効にする前に切断したのか、無効にした後も再接続されるのかを明確にしてください。2つの現象で確認する順序は異なります。

初回接続時にVPN構成の追加を求めるシステムの通知が表示される場合があります。これは、Appleのシステムがアプリに関連するネットワーク接続を許可する手順です。操作中のアプリがShadowrocketであることを確認し、システムの案内に従って認証してください。拒否した場合は、後から設定を正しく入力しても接続を確立できないことがあります。システムの「設定 › 一般 › VPNとデバイス管理」で該当項目を確認できます。具体的な表示や経路はデバイスによって異なります。

まず手動で確認してから条件を有効にする

自動接続に頼らず、現在のサーバーとConfigを使って手動接続し、決めた対象にアクセスできることを確認します。
SettingsでOn Demandを探し、現在のオン・オフ状態と設定済みの条件を記録します。条件の名称や選択肢は、現在の画面表示に従ってください。
必要な条件だけを一つ有効にし、切断してから該当するネットワーク環境に入り、システムが意図どおり接続を開始するか確認します。
次に、接続が開始されないはずの環境に入り、期待どおりの状態が維持されるか確認します。最後に手動で停止する手順も一通り確認してください。

まずは必要最小限の条件から設定し、すべてのネットワークを一度に対象にしないことをおすすめします。特定のネットワーク条件で接続したい場合は、現在の画面に該当する条件があるか、条件と例外がどう適用されるかを先に確認してください。似た名前でも同じネットワークとは限らず、空白、大文字・小文字、名称変更も識別に影響する場合があります。記録には自分で判別できるメモを使い、自宅ネットワークの詳細な識別情報は公開しないでください。

「自動接続が有効」を「常に接続状態が維持される」と解釈しないでください。ネットワークの切り替え、システムのスケジュール、サーバーへの到達性、デバイスのスリープ、許可設定の変更などが実際の状態に影響します。動作を確認するには、接続表示だけでなく実際のリクエストも確認してください。デバイスが長時間通信していない場合、新しいログがないからといって自動接続が機能していないとは限りません。

接続の繰り返しとネットワーク切り替えへの対処

切断後に接続が何度も復帰する場合は、まずOn Demandをオフにしてから手動で切断し、システムの状態を確認します。それでも問題がある場合は、自分で設定したほかの自動化動作や重複するVPN項目がないか調べ、用途を一つずつ確認してから対処してください。最初からすべてのネットワーク設定を削除すると、必要な情報も失われ、再現できたはずの接続条件も追跡しにくくなります。

接続前にWebページでログインが必要なWi-Fiでは、まずそのネットワークへの接続手続きを完了してください。自動接続のためにログインページを開けない場合は、一時的にOn Demandをオフにして切断し、ネットワークの案内に従って認証します。接続が完了したら元の設定に戻し、もう一度確認してください。これは基本ネットワークがまだ利用条件を満たしていない場合の対処です。証明書の検証を恒久的に緩めたり、プロキシ設定を長期的に変更したりして解決しないでください。

Wi-Fiからモバイル通信に切り替えた後は、以前の接続を再確立する必要がある場合があります。切り替え前の成功記録をそのまま使わず、新しい接続の記録を確認してください。特定のネットワークだけで失敗する場合は、それぞれのネットワークで手動テストを行い、結果を記録してから、そのネットワークの接続条件を変更するか判断します。自動接続は、各ネットワークで個別に接続できることを確認したうえで設定してください。基本的な問題が残っていると、自動化によって同じ障害が繰り返し現れます。

許可を誤って削除または拒否した場合は、まずアプリがApp Storeから正常にインストールされていることを確認し、接続操作を行ってシステムが許可を再度求めるか確認してください。システム項目の確認と復元については、VPN構成の追加を求める通知についてをご覧ください。システム構成の削除とサブスクリプションの削除は、異なる種類のデータを管理する操作です。混同しないでください。

04 / 接続パラメータとローカル待ち受け

Proxy、プロトコル、ポートの適用範囲

リモートサーバーのポートとローカルポート

Proxy（プロキシ）に関して混同しやすいのが、2種類のポートです。サーバー情報にあるポートはリモートサービスへの接続先を示し、ローカル待ち受けポートは対応する方法で接続されるリクエストを受け付けます。数値が偶然同じでも、両者を一致させる必要はありません。ローカルポートを変更してもリモート側の認証エラーは解消せず、リモートポートを変更しても他のデバイスが自動的にローカルプロキシへ接続できるようにはなりません。

編集しているのがAdd Server（サーバーを追加）の接続情報なのか、Settingsにある現在のデバイスの待ち受け関連項目なのか、まず確認してください。リモートポートは、お手元のサーバー情報に合わせる必要があります。「よく使われるポート」をもとに推測しないでください。情報がSubscribe（サブスクリプション）から取得されている場合は、次回の更新で手動変更した項目が上書きされるかも確認します。必要に応じて別途メモを残し、更新後に設定が勝手に無効になったと誤解しないようにしてください。

ローカルポートは、対応する待ち受け機能が有効で、接続方法も一致している場合にのみ意味があります。ポート番号が同じでもHTTPとSOCKS5が自動的に相互接続できるわけではありません。接続側は待ち受け側が実際に対応するプロトコルを使用する必要があります。デバイス内で通常どおり利用するだけなら、ローカル待ち受けを有効にする必要はありません。明確な接続要件がない場合は、動作確認済みの状態を維持し、Webページの問題を調べるためだけに待ち受け範囲を広げないでください。

ポートの値とアクセス範囲

現在の画面にローカルポートの編集項目がある場合は、元の値と待ち受け範囲を記録してから、ほかのサービスで使われていないことを確認してください。有効範囲の番号を使うことは基本条件にすぎず、正常にバインドできるかはシステムの許可や実行環境にも左右されます。そのため、このマニュアルではすべてのデバイスに共通する初期ポートを指定しません。覚えやすさだけを理由に、異なるサービスで同じ待ち受けアドレスとポートの組み合わせを使うこともおすすめしません。

項目の属する層	意味	設定の根拠
リモートサーバーのポート	リモートサービスに接続するためのポート。	手元にあるサーバー情報。
ローカル待ち受けポート	対応するプロキシプロトコルのリクエストを受け付ける入口。	実際の接続要件と使用可能なポート。
待ち受けアドレスまたは範囲	接続を受け付けるネットワークインターフェース。	必要最小限のアクセス範囲。
認証情報と通信項目	接続時の認証情報と通信方式。	サーバー側で設定された対応パラメータ。

画面がローカルネットワークからの接続に対応している場合は、まず現在のネットワークが信頼できることと、接続側がその機能を必要としていることを確認してください。他のデバイスから接続可能な待ち受けを「このデバイス内だけで使う」と解釈しないでください。別のデバイスから到達できるかは、ネットワークの分離設定やシステムの制限にも左右されます。アクセス認証を設定できる場合は、用途に応じて設定し、認証情報を安全に管理してください。使用後は必要最小限の範囲に戻し、一時的なテスト設定を長期間開放したままにしないでください。

クライアントの待ち受けポートをルーター側のネットワーク設定と混同したり、バインド失敗をサーバーのオフラインと同一視したりしないでください。バインドエラーが起きた場合は、まず元のポートに戻す、重複した待ち受けを停止する、関連する接続を再起動するなどして、エラーが解消するか確認します。ローカルの接続口を確立できてから、リクエストが正しいサーバーとルール経路を通るか調べてください。そうしないと、複数の問題が一度のテストに重なります。

プロトコルのパラメータは情報に沿って対応づける

Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2は、それぞれ異なるプロトコルまたは接続方式の名称で、自由に置き換えられるラベルではありません。サーバーアドレスとポートが同じでも、ほかの認証情報や通信項目を共用できるとは限りません。まずプロトコルの種類を確認し、画面に表示された必須項目を照合してください。入力を省くために、根拠のない値を証明書、サーバー名、通信関連の項目へ入力しないでください。

接続情報でTLSが必要な場合は、証明書の検証とサーバーの識別情報を一致させてください。アドレスは接続先を示し、サーバー名は認証に使われる場合があるため、両者が同じ用途とは限りません。証明書エラーが出たときは、デバイスの時刻、手元の情報に記載されたサーバー名、証明書の状態を確認してください。検証を無効にする設定を長期的な推奨値として扱わないでください。暗号化された接続を確立できることと、接続先が意図したサーバーであると確認できることは、別々に満たす必要があります。

UDP関連の機能は、プロトコル、リモートサービス、現在のネットワークにも左右されます。スイッチ一つだけを見て、すべてのリクエストが通信できると判断しないでください。Webページにアクセスできても、ほかの種類のリクエストが正常とは限りません。逆に、特定の通信だけが失敗しても、プロキシ全体が使えないとは限りません。問題が起きた通信に合った方法で確認し、Logでローカル接続、リモート接続、接続先からの応答のどこで失敗したかを切り分けてください。

05 / 測定対象と比較方法

PingとConnectivity Test

まず、テスト対象の範囲を確認する

Ping（遅延テスト）は、特定の条件下での応答状況を示すもので、通信品質全体の結論ではありません。画面にPingと表示されていても、内部で特定の探測方法が必ず使われているとは限りません。現在のバージョンにテスト方式の選択項目がある場合は、その説明を読み、対象がサーバーアドレス、接続確立の過程、特定のリクエストのどれなのかを確認してから結果を判断してください。

Connectivity Test（接続テスト）も、実際のサービスへのアクセスとは分けて考える必要があります。テストに成功しても、確認できたのはテスト対象が応答したことだけかもしれません。実際のアプリ利用にはDNS、ルール、認証、接続先の制限、接続の再利用などが影響する場合があります。テストの失敗も、現在のネットワークに探測方法が適していないことが原因で、実際の通信は動作する場合があります。そのため、テスト結果は判断材料の一つとして扱い、利用可否を決める唯一の基準にはしないでください。

遅延の数値を比べるには、測定条件をそろえる必要があります。同じサーバーでも、ネットワーク、測定時刻、テスト対象が異なる結果をそのまま順位づけすることはできません。数値が低くても、継続通信の速度、パケットロス、長時間接続の安定性が優れているとは限りません。日常利用の接続先は実際の利用状況に合わせて選び、一度の測定で最小値が出たかではなく、再現可能な成功と失敗を重視してください。

テスト対象、タイムアウト、同時実行数の設定の目安

Settingsにテスト対象やタイムアウトなどの項目がある場合、初期値は現在の画面表示で確認してください。トラブル対処の必要がなければ、動作確認済みの設定を維持します。テスト対象を変更する場合は、自分がアクセスでき、挙動が安定していて、応答の意味を確認できるものを選んでください。特定のネットワークでしか到達できない、頻繁にリダイレクトされる、ログインが必要なアドレスを見栄えのよい結果のために選び、あらゆるアクセスの代表として扱わないでください。

タイムアウトが短すぎると、正常でも応答に時間がかかる接続を失敗と判定することがあります。長すぎると、問題の発見が遅れます。値はテストの目的に合わせて決め、常に小さくすればよいわけではありません。現在の画面に該当項目がない場合は、ほかの資料に同じ名称の項目を探す必要はありません。変更後は、動作が分かっている接続でテスト自体が正常に行われるか確かめてから、問題のある接続を試してください。不適切な測定条件をすべての結果に持ち込まないようにしましょう。

一度に大量のテストを実行すると、瞬間的な接続数やネットワーク負荷が増え、結果に影響する場合があります。複数のサブスクリプションを管理している場合は、まずグループで対象を絞り、比較したい項目だけをテストしてください。サブスクリプションの更新、ネットワーク切り替え、接続の再確立とテストを同時に行わないでください。条件が一度にいくつも変わると、差がテスト対象によるものか、その時点のデバイス状態によるものか判断しにくくなります。

再現可能なテスト記録の作り方

ネットワークとGlobal Routingのモードを固定し、サーバーのメモとテスト方式を記録します。認証情報は記録しないでください。
まず、利用できることが分かっている対象にアクセスし、デバイスの基本ネットワークとテスト対象の両方が使用可能であることを確認します。
同じ項目を一定の間隔をあけて複数回テストし、最小値だけでなく、安定して成功するかを確認します。
次に、実際のアプリで新しいリクエストを発生させ、Logで適用されたポリシーと接続結果を確認してから、一時的なテスト設定を元に戻します。

すべてのテストがタイムアウトする場合は、テスト対象と基本ネットワークを先に確認し、サブスクリプション全体をすぐに削除しないでください。一つの項目だけが失敗する場合は、その項目のサーバー情報と直近の更新が完全に行われたかを確認します。テストは成功しても実際の利用で失敗する場合は、アプリのリクエストが本当に同じサーバーを使っているか、Configによって対象が別のポリシーに振り分けられていないか調べてください。層ごとに確認すれば、不要な全体変更を減らせます。

Wi-Fiかモバイル通信のどちらか一方だけでテストに失敗する場合は、それぞれのネットワークで別々に記録してください。ネットワーク切り替え前の数値を新しいネットワークの結果として扱ったり、以前の順位だけで現在最適な項目を判断したりしないでください。必要であれば基本ネットワークが安定するまで待ち、接続を再確立してから再テストします。変化の多い環境では、固定順位にこだわるより、失敗の傾向を確認してください。

結果が空欄、未テスト、失敗の表示になっている場合は、画面の意味どおりに記録し、独自に遅延の数値へ置き換えないでください。「測定できなかった」と「測定結果が遅かった」を区別すると、順位の読み違いを防げます。結果に一貫性がない状態が続く場合は、一括テストをいったん止め、固定した対象と接続一つでテストし、次の章のログ確認方法を使って最小限の再現条件を整えます。

06 / 状況の確認と情報の保護

Logの読み方とトラブルの特定

新しいリクエストで時系列を作る

Log（ログ）は操作と結果を対応づけて確認するためのもので、記録を増やせばよいというものではありません。トラブルを調べる前に、現在のネットワーク、Global Routingのモード、有効なConfig、選択中のサーバーを記録し、対象への新しいリクエストを発生させます。その後、時系列に沿って関連する記録を探し、名前解決、ルールの適用、接続確立、接続先の応答を区別してください。バックグラウンドのアプリが発生させたリクエストを、テスト中のアクセスと取り違えないようにしましょう。

現在の画面にログのオン・オフや詳細度の選択肢がある場合、日常利用では確認に必要なレベルに設定します。問題を再現するときだけ、一時的に必要な詳細度へ上げてください。初期状態はデバイスの表示で確認し、すべての環境で同じ内容が常に記録されると想定しないでください。詳細なログは保存容量や処理負荷を増やし、アクセスに関する情報を多く含む場合もあるため、トラブル対処後は日常利用に必要な状態へ戻してください。

新しいログがないからといって、クライアントが動作していないとは限りません。対象アプリが既存の接続を再利用したり、ローカルキャッシュを読み込んだり、通信が現在のログ記録範囲に含まれていなかったりする場合があります。まずテストによって本当に新しいリクエストが発生したかを確認し、その後に接続状態とログ設定を見てください。複数のスイッチを繰り返し切り替えると、観察条件が変わるだけです。固定した対象への明確な操作を一度行い、短時間記録するほうが、原因と結果を結びつけやすくなります。

失敗した段階に分けてログを読む

確認する段階	主な確認事項	次に行うこと
名前解決	ドメイン名から使用可能なアドレスを取得できたか。	サーバーのドメイン名と接続先のドメイン名を区別する。
ルール	リクエストにどのルールとポリシーが適用されたか。	有効な構成と、それより前にあるルールを確認する。
接続	リモートサーバーへの接続を確立できたか。	サーバー情報、認証、ネットワークを確認する。
接続先の応答	接続後に、接続先から期待した内容が返されたか。	実際のアプリ動作と応答の意味を確認する。

リクエストがDIRECTを通り、本来はPROXYを使うはずだった場合は、サーバーをすぐに変更せず、ルールと有効な構成を先に確認してください。期待したポリシーが適用されているのにリモート接続が失敗する場合は、サーバー情報を確認します。接続が確立していても接続先がエラーを返す場合は、応答の内容を調べてください。ログにある「成功」は、通常、一つの段階を示すだけで、処理全体の完了を意味しません。

ルールの適用状況を確認するには、最初に実際に有効になった条件に注目してください。後ろに正しそうなルールがあっても、リクエストがそこまで到達するとは限りません。接続先が異なるサブドメインからリソースを取得している場合や、新しい接続経路を使っている場合にも注意が必要です。ページ本体は開けても一部のリソースだけ失敗するなら、それぞれのリソースの記録を個別に探してください。ページ内のすべてのリクエストを同じドメインのものとして扱わないでください。

接続エラーは具体的に記録してください。タイムアウト、認証情報の不一致、証明書の検証エラーは、それぞれ確認すべき点が異なります。すべてを「速度が遅い」とまとめないでください。デバイスの時刻、サーバーアドレス、ポート、プロトコルの設定を確認してから、必要に応じて利用中のサービス提供元に情報の状態を問い合わせます。問い合わせ時はエラーの種類と発生条件を伝えればよく、認証情報やサブスクリプションの完全なURLを共有する必要はありません。

必要最小限の情報だけを残し、公開範囲を広げない

ログにはアクセス先のドメイン、接続先アドレス、サーバーのメモ、周辺の通信情報などが含まれる場合があります。共有する前に内容を確認し、トラブルに関係する短い部分だけを残してください。サブスクリプションURLの機密部分、認証情報、個人のネットワーク識別情報は取り除きます。スクリーンショットではステータスバー、一覧のメモ、前後の記録も確認してください。項目一つを隠しただけで画像全体を公開できるとは限らないため、表示されている内容をすべて見直してください。

簡潔な説明には、どのネットワークで、どのルーティングモードを使い、どの対象にどのような操作を行ったか、期待した結果と実際の結果は何か、元の設定に戻すと変化したかを記載します。整理したエラー部分を添えると、長時間分のログ全体をエクスポートするより再現しやすくなります。どの項目が機密情報か判断できない場合は、生データをそのまま送らず、エラーの種類を文章で説明してください。

トラブル対処が終わったら、最終的に有効だった設定の差分と復元手順を保存し、必要に応じて不要になったローカル記録を整理してください。ログを消しても原因となった設定は直りません。また、ログの削除はサブスクリプションの削除とは別の操作です。それぞれ分けて対処してください。同じ問題が再発した場合は、すべての設定を最初から試すのではなく、前回のネットワーク条件と失敗した段階を照合できます。

07 / クイック操作とデバイス間のデータ

Widgetは操作の入口であり、独立した接続設定ではありません

Widget（ウィジェット）は、システムが許可する範囲で、状態の確認や操作を手早く行うためのものです。具体的な内容はデバイスで追加できるウィジェットによって異なります。通常はアプリで設定済みの内容を利用するため、初回インポート、VPNの許可、手動接続の確認には代わりません。ウィジェットを追加する前に、Shadowrocket内で現在のサーバーと構成が使えることを確認し、ウィジェットの表示とアプリ内の状態が一致しているかを確認してください。

ウィジェットの表示更新はシステムの更新タイミングに左右されることがあります。画面がまだ更新されていない状態を、接続状況の即時確認に使わないでください。操作が反映されたか確認するには、アプリを開いて現在の接続状態を見て、新しいリクエストを発生させます。ウィジェットの操作後に想定した変化がない場合は、DNSやサーバー設定をすぐに変更せず、アプリ側の許可、接続情報の有効性、システムが該当動作を許可しているかを確認してください。

ウィジェットは、状態を理解している日常的な操作に使い、動作が分からないまま連続でタップしないでください。操作を短時間に繰り返すと、接続の確立中や切断中などの過渡状態になり、表示と実際の状態が一時的にずれることがあります。一度の操作が完了してから次を行ってください。自動再接続を止める場合は、On Demandの章にある手順に従い、ウィジェットの切断操作一度だけに頼らないでください。

iCloud同期はデバイス全体の複製ではありません

SettingsにiCloud Sync（iCloud同期）や関連項目がある場合は、システムの要件に従ってデバイスでiCloudにサインインし、アプリの利用が許可されているか確認してください。同期対象となるデータ、手動操作が必要か、独立したインポート・エクスポート機能があるかは、現在の画面の説明に従います。すべてのサーバー、構成、スイッチ、ログ、システムの許可が自動的に同期されると想定しないでください。一度同期に成功しても、長期バックアップが保証されたわけではありません。

App Storeでの購入に使うアカウントと、デバイスで使うiCloudアカウントは用途が異なります。購入を復元する操作はアプリを入手する権利に関するもので、iCloud同期は対応するデータを引き継ぐためのものです。相互に代用できません。デバイスを買い替えた後にアプリを再ダウンロードできても、以前の接続情報がすべて保存されているとは限りません。逆に同期データが表示されても、新しいデバイスで必要なVPNの許可が完了したことにはなりません。

有効にする前に、復元可能な情報を保存し、本体だけに存在するデータを確認してください。現在の画面にエクスポート機能がある場合は、対象範囲とファイルの内容を確認し、認証情報が含まれる可能性があれば安全に保管します。バックアップは、自分で管理できて復元可能な場所に保存してください。情報一式を公開ドキュメントに置かないでください。同期の初期状態も別のデバイスから推測せず、現在のデバイスで確認します。

2台のデバイスに差がある場合の確認順

両方のデバイスで、有効なConfig、サーバーのメモ、直近に手動で変更した項目を記録します。同じデータを同時に編集しないでください。
システムのiCloud利用条件と、アプリが実際に同期するデータの範囲を確認し、両方のデバイスで同じ種類の情報を比較しているか確かめます。
どちらの内容を残すか決め、復元可能な状態を確保してから、画面に表示された同期またはインポート操作を実行します。
デバイスごとに一覧、構成の選択状態、実際の接続を確認してください。ファイル名が同じだからといって、中身も同じとは限りません。

両方のデバイスで同じ内容を変更した場合、最後にアプリを開いたデバイスがもう一方を必ず上書きするとは限りません。正しい統合を期待して続けて操作しないでください。まず両方の差分を保存し、アプリに表示される競合処理の方法に従って残す内容を選びます。統合方法が画面に説明されていない場合は、一方のデバイスで変更を完了し、もう一方で結果を確認するほうが、同時編集より追跡しやすくなります。

iPhoneとiPadで同じ構成のレイアウトが異なっても、データが違うとは限りません。リストの幅やボタンの位置だけで判断せず、具体的な項目と有効状態を比較してください。iPadでの購入復元と画面レイアウトについては、iPadの購入と画面表示についてをご覧ください。共有購入、デバイスの互換性、システム要件はApp Storeの掲載内容で確認してください。同期結果から対応範囲を推測しないでください。

同期後に古いサーバーや重複項目が現れた場合は、サブスクリプションの更新、手動インポート、同期データのどれに由来するかを見分けてから整理してください。削除する前に、必要なメモとローカルでの変更を保存し、使用中の情報源まで一緒に削除しないようにします。ウィジェットは操作への入口、同期は対応データの受け渡しにすぎません。最終的には、このデバイスで有効な構成と実際のアクセス結果で設定を確認してください。

08 / Configの管理と復元の確認

Config、Subscribe、設定の復元

サーバー情報の更新は、すべての設定の更新ではありません

Subscribe（サブスクリプション）は通常、お手元のサーバー情報を管理するために使います。Config（構成）はルールや関連設定を保持し、Settingsはクライアントの動作項目を管理します。サブスクリプションを更新して新しい項目が表示されても、有効なルール構成まで変更されたとは限りません。構成を編集しても、それが選択されて使用中とは限りません。変更後は毎回、一覧の内容、有効な選択、実際のリクエストが一致しているか確認してください。

複数のサブスクリプションがある場合は、まず自分で判別できるメモを付けて出所を区別してから、並び順や重複項目を整理してください。同じ名前でもパラメータが同じとは限らず、似たパラメータがあるからといって両方を残す必要があるとも限りません。表示名だけでまとめて削除せず、区別するためにサブスクリプションの完全なURLをメモに記載することも避けてください。グループ分け、重複項目、削除の順序については、複数のサブスクリプションURLの管理方法をご覧ください。

サブスクリプションの項目を手動で変更する前に、次回の更新で変更が上書きされるか確認してください。特別な調整を残す必要がある場合は、差分を記録し、現在の画面でサポートされている方法を使って、独立した識別しやすい情報として保存します。更新後に接続状況が変わった場合は、まずサーバー項目と選択中の項目を比較してください。Settings全体をすぐにリセットする必要はありません。クライアント設定が原因だと確認できた場合に、該当する章の項目を調整してください。

ルールの例と適用順序

以下はShadowrocketの.confに含まれるルールの一部で、キーワード、対象、ポリシーの関係を示しています。完全な構成ではなく、サーバー情報も含みません。自分の構成に適用する前に、該当するポリシーが意図どおりに動作するか確認してください。例ではexample.comのみを使用しており、実際の通信を同じ経路に一律で設定することを推奨するものではありません。

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

DOMAIN-SUFFIXはドメインのサフィックスに基づいて一致し、ドメインとそのサブドメインを指定する場合に使います。GEOIPはアドレスに対応する地域データに基づいて一致し、結果はアドレスとデータの内容に左右されます。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ルールは通常、上から順に確認されます。より具体的な条件に影響する広いルールより前に配置し、最後に適用するルールは末尾に置いてください。

キーワード	一致条件	注意点
DOMAIN	完全なドメイン名。	すべてのサブドメインに一致するわけではありません。
DOMAIN-SUFFIX	ドメインのサフィックス。	対象範囲が広すぎないか確認してください。
IP-CIDR / IP-CIDR6	対応するアドレスファミリーのネットワーク範囲。	ドメイン名のリクエストでは名前解決も関係する場合があります。
FINAL	それ以前のルールに一致しなかったリクエスト。	最終的に適用されるポリシーが意図どおりか確認してください。

テキスト内に正しいルールがあるだけで、適用済みと判断しないでください。現在のGlobal RoutingがConfigになっていること、有効なファイルに該当部分が含まれていることを確認し、Logで新しいリクエストの適用結果を確認します。ProxyまたはDirectモードを使用中の場合は、正しいテスト条件に戻してください。ルールの確認が終わったら、実験のためだけに追加した項目も削除します。一時的なルールで他の通信への適用が長期的に変わらないようにしてください。

すべてをリセットせず、必要最小限の復元から始める

問題が起きたら、最後に確認できた変更を思い出してください。DNS変更後に異常が起きた場合は、元の設定に戻して接続を再確立します。ルール編集後なら保存した構成の複製に戻し、サブスクリプション更新後なら更新内容と現在のサーバー情報を確認してください。この方法なら変更する層を一つに絞れ、検証しやすく、正常に動作しているほかの設定も維持できます。問題への対処とデータの損失を同時に起こすのを避けられます。

変更の出所が分からない場合は、基本ネットワークが使えること、サーバー情報がそろっていること、手動接続に成功すること、固定した対象にアクセスできることから確認します。その後、Config、On Demand、Widget、同期を一つずつ戻します。各項目を復元するたびに検証し、一度の操作ですべてを再インポートして全機能を有効にしないでください。この最小限の確認手順は依存関係を特定するためのもので、日常利用でも簡略化した設定を使い続けることを求めるものではありません。

復元が完了したら、日常利用のルーティングモード、自動接続の条件、ログの詳細度、同期状態を最後に確認し、有効な設定差分を保存してください。操作を最初からやり直す場合は入門ガイドへ、症状から原因を探す場合はよくある質問をご覧ください。このマニュアルの目的は、全員に同じ設定を勧めることではありません。各設定の用途と検証方法が明確で、元に戻す手順を実行できる状態を目指します。