Shadowrocket
使い方完全ガイド

02 / 初回起動

初回起動とシステム権限

操作対象を確認してから接続する

Shadowrocketを初めて起動したら、まずHomeにサーバー項目があるか確認し、現在のGlobal RoutingとConfigも確認します。サーバー項目は接続先を、Global Routingは通信の処理方法を決め、Configは設定モードで適用する具体的なルールを提供します。メインスイッチは接続の開始と停止を行うだけで、これらの前提条件を補うものではありません。リストが空、項目が未選択、またはインポートに失敗した場合は、追加手順に戻ってください。この状態でメインスイッチを何度も切り替えても、不足している接続情報は自動で追加されません。

始める前に、システムネットワークを制御しているほかの接続を一時停止すると、設定同士の影響を抑えられます。既存の設定を削除するのではなく、どの設定が動作中か、いつ接続を開始したか、停止後にネットワークが復旧するかを把握できる状態でテストすることが目的です。学校や組織が管理するデバイスでは、ネットワーク設定の追加や変更が制限される場合があります。デバイスの管理要件に従ってください。用途が分からないまま組織から配布された設定を削除したり、管理上の制限をサーバーパラメータの誤りと判断したりしないでください。

VPN構成追加時のシステム確認について

初めて接続を開始するとき、ShadowrocketによるVPN構成の追加を許可し、デバイスのパスコードやシステム認証で確認するよう求められる場合があります。この構成は、Appleが提供するネットワーク機能を使ってアプリが通信を処理するためのものです。サービスへの接続権を購入したことや、サーバーの検証が完了したことを示すものではありません。自分で開始した操作に対する確認画面であることと、アプリの名称が正しいことを確かめてから、システムの手順に従って許可してください。許可後も、サーバーに接続できるかどうかのテストが必要です。

以前にキャンセルした場合は、アプリに戻って現在の項目が正しく入力されていることを確認し、再度接続を開始して必要な許可手続きを表示します。必要に応じてシステムのSettingsでVPN関連の項目を確認してください。名称や場所はシステムによって異なる場合があるため、実際の画面を基準にします。該当する構成があるか、有効化できるか、ほかの接続が同時に動作していないかを確認してください。確認画面を再表示するために、すべてのネットワーク設定を一度に削除しないでください。変更範囲が広がり、元の失敗箇所も特定しにくくなります。

システムにVPNの状態が表示されても、ネットワーク構成が動作中であることを示すだけです。サーバー認証が成功したことや、特定のWebサイトに想定どおり接続できることを示すものではありません。構成が起動していても選択したサーバーに接続できない場合があります。サーバーが正常でも、現在のルールによって対象がDIRECTに振り分けられることもあります。システムの状態、クライアントのテスト結果、実際のアクセス結果を分けて記録してください。そうすることで、「スイッチはオンなのにアクセスできない」場合に、権限、通信、ルーティングのどの段階で問題が起きたかを判断できます。

用途に応じて必要なアクセス権を許可する

Scan QR Codeを使う場合、利用者自身の設定QRコードを読み取るためにカメラへのアクセスが必要です。カメラを使わない場合は、手元の情報に合った別のインポート方法を選べます。アクセスを拒否した後は、システムのSettingsでカメラ権限を確認してください。リンクをコピーしてインポートする際に、ペーストの許可を求められることもあります。クリップボードの内容が取り込む予定の情報であることを確認してください。カメラの許可と接続に必要な主な許可は別です。カメラ権限はQRコードの読み取りに関わるもので、サーバーへの接続可否を直接示すものではありません。

QRコード、クリップボード、設定テキストには認証情報が含まれる場合があります。読み取る前に出所と用途を確認し、インポート後は項目の種類、アドレス、ポートを確認してください。読み取りに成功しただけでパラメータが正しいと判断してはいけません。別の自分のデバイスからQRコードを読み取る場合も、それが単一サーバー、サブスクリプションURL、設定全体のどれを表すのか確認します。対象によって、その後の管理方法は異なります。インポート先を間違えた場合に内容を認識できなかったり、想定と違う場所に項目が表示されたりしても、すべての情報が無効とは限りません。

初回設定の適切な完了条件は「すべての権限をオンにする」ことではなく、現在の操作に必要な権限だけを許可し、それぞれの用途を説明できることです。システムのネットワーク権限を許可したら、テスト用のサーバー項目を1つに絞り、手動で接続と切断をそれぞれ一度行います。状態の変化を把握しやすくするため、最初は自動接続条件を有効にしないでください。手動操作を再現できることを確認してから、Settingsの章でOn Demandを設定します。自動接続によって手動接続時の問題が見えにくくなるのを防げます。

03 / 接続情報を入力する

サーバーと既存サブスクリプションの追加

Add Server：接続パラメータを確認

追加前に、手元の情報が何を表すか確認します。単一の共有リンクは1つのサーバー、サブスクリプションURLは更新可能なサーバー項目の一覧、設定ファイルはルールやほかの設定を含む場合があります。どれもテキストに見えるからといって、互いに置き換えられるわけではありません。情報は利用者自身のサービス提供元、または既存の設定から取得してください。ドメインとパスワードしか分からず、プロトコル、ポート、転送方式が不明な場合は、まず必要なパラメータを確認します。種類を手当たり次第に変えて保存できる項目を作っても、接続できる証明にはなりません。

HomeでAdd Serverを選び、元の情報に一致する種類を選択してから、アドレス、ポート、認証項目を入力します。アドレス欄には通常、ホスト名またはIPアドレスを入力します。Webページのパスを含むURLではありません。ポートはサーバー側の待ち受けポートと一致させてください。表示名は項目を識別するためのもので、認証には使われません。入力後に各項目を確認し、コピーした文字列の前後にある空白、全角記号、途中で切れた文字列に注意してください。保存できても、入力がローカルの確認を通過しただけです。利用可能かどうかは接続テストで確認します。

Shadowsocks、VMess、VLESS、Trojanなどでは、設定項目がそれぞれ異なります。あるプロトコルの入力方法を別のプロトコルにそのまま当てはめないでください。元の情報にTLS、Server Name、Host、Pathが含まれる場合は、対応する項目にそのまま設定します。Server Nameと接続先アドレスは異なる場合があり、Pathは大文字・小文字を区別することがあります。証明書の確認を無効にすることを汎用的な解決方法と考えないでください。証明書名が一致しない場合は、時刻、名称、元のパラメータを確認し、本来解決すべき設定上の問題を回避しないようにします。

Subscribe：インポートと更新は別の操作

既存のサブスクリプションは、その種類に応じた方法でインポートします。URLは通常、サーバー一覧を取得するためのもので、単一サーバーのホスト名として直接使うものではありません。インポート前にURLを最後までコピーし、特に疑問符以降のパラメータが残っているか確認してください。そこには利用者を識別できる機密情報が含まれる場合があります。インポート後は、想定した項目が作成されたか、グループが分かりやすいか、項目数が妥当かを確認し、サーバーを1つ選んでテストします。サブスクリプションの取得に成功しても、一覧内のすべてのサーバーが現在のネットワークで接続できるとは限りません。

更新するとサブスクリプション側から内容を再取得するため、Subscribeで管理している項目を長期的な手動編集用コピーとして扱わないでください。特定の項目を一時的に変更する場合は、元の情報を保管し、必要なら独立したテスト項目として別に保存してから、次回更新で変更が上書きされるか確認します。項目が重複している場合は、同じサブスクリプションを複数回インポートしたのか、手動コピーとサブスクリプションの項目が両方あるのかを確認してください。出所を確認せずにまとめて削除すると、唯一の有効な設定まで消すおそれがあります。

更新に失敗した場合はリクエスト経路を確認

サブスクリプションの更新に失敗した場合は、まずデバイスの基本的なネットワーク接続を確認し、URLが完全か、現在のアクセス経路は何か、サーバーからどのような応答が返ったかを調べます。現在のサーバーが利用できない場合、そのサーバー経由でサブスクリプションを取得することもできない場合があります。影響を理解したうえで、サブスクリプションURLにアクセスできる経路に切り替えて再試行してください。認証や権限のエラーが表示された場合は、元のURLが変更されていないか確認します。内容を取得できても解析できない場合は、返された内容が対応するサブスクリプション形式か、ログインページ、エラーページ、通常の説明ページではないか確認してください。

インポート後は、項目の出所、現在の選択、更新結果をそれぞれ把握しておきます。単一リンクとサブスクリプションの違いは、共有リンクとサブスクリプションURLの解説をご覧ください。以降の確認では、対象を明確にした項目を1つだけ使います。サブスクリプション全体の更新、ルールの変更、DNSの変更を同時に行わないでください。入力条件を一定に保つことで、その後のGlobal Routingの変更が何に影響したのか判断しやすくなります。

04 / 通信経路を決める

Global Routingの3つのモードとルール照合

Config、Proxy、Directの役割

接続を確認する前に、Global Routingの状態を確認してください。Configは現在有効な設定のルールに従ってリクエストを処理します。Proxyは対象となる通信をプロキシ経路に送ります。Directは直接接続する経路を使います。3つのモードが決めるのは通信経路であり、サーバー自体の認証情報は変更されません。同じ接続先でもモードによって結果が異なる場合は、すぐにサーバーを作り直すのではなく、まず経路を確認します。モード名とルール内の大文字のポリシーキーワードも区別してください。前者は画面上の選択肢、後者は設定テキストです。

トラブル対処では一時的にProxyを使い、選択中のサーバーを確認できます。テスト後は想定しているモードに戻してください。Proxyで使えてConfigで使えない場合は、確認すべきルールの違いがあることを示していますが、サブスクリプションの破損を直接意味するわけではありません。Directは現在のネットワークから直接アクセスできるか比較するために使えますが、すべての接続先にDirectでアクセスできるとは限りません。テスト結果には対象とモードを明記してください。「使える」「使えない」だけでは対象範囲が分からず、次の設定変更にも役立ちません。

ルールは上から順に照合し、具体的な条件を先に置く

Configのルールは通常、上から順番に照合され、一致したルールのポリシーが適用されます。DOMAINは完全なドメイン名、DOMAIN-SUFFIXは指定したドメインとサブドメイン、DOMAIN-KEYWORDはドメイン内のキーワードに一致します。IP-CIDRとIP-CIDR6はアドレス範囲を対象とし、GEOIPはアドレスの地域情報に基づいて判定します。FINALはそれ以前のルールに一致しなかったリクエストを処理します。条件の範囲が広いほど、後続のリクエストを先に受け止めやすくなります。具体的な条件を先に置き、範囲の広い条件や最終ルールは後に配置してください。

以下は説明用の.confルール例であり、既存の設定に置き換えられる完全なConfigではありません。ドメインには例示用の値を使っています。PROXYを使うには、利用可能なプロキシ経路が必要です。例を適用する前に現在のConfigを複製し、コピー側の該当箇所だけを変更して、そのConfigが有効になっていることを確認してください。テキストをファイルに保存しただけでは、現在の接続に読み込まれたことにはなりません。Configを切り替えた後、新しいリクエストを発生させてルールの結果を確認します。

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

この例では、example.comとそのサブドメインを最初にPROXYへ送ります。exampleを含む別のドメインへのリクエストは、2つ目のルールに一致する可能性があります。2つのルールは同じ意味ではなく、後者のほうが広い範囲に一致します。プライベートネットワーク範囲とGEOIPの条件を順に照合し、残った通信はFINAL,DIRECTで処理します。FINALを先頭に置くと、後続の具体的な条件は想定どおり機能しません。フォールバックをFINAL,PROXYに変更すると、一覧にない通信の経路も変わります。単なる書式上の置き換えではありません。

変更を最小限にしてルーティングの意図を確認

指定したWebサイトだけをプロキシ経由にする場合は、対象のDOMAIN-SUFFIXルールを残し、最後をFINAL,DIRECTにできます。ただし、1つのWebページが複数のドメインにリクエストすることがあります。メインのドメインが一致しても、画像、ログイン、APIのリクエストが同じ経路を使うとは限りません。一部のコンテンツだけ表示されない場合は、実際に失敗したリクエストを確認してから、明示的なドメイン条件を追加するか判断します。範囲を無制限に広げるキーワードルールで問題を覆い隠さないでください。Directにしたいほかのリクエストまで変わるおそれがあります。

ルールを確認するときは新しいリクエストを使い、必要に応じて接続を確立し直してください。既存の接続が以前の経路を使い続けると、誤判定につながります。IP関連の条件は名前解決結果の影響を受ける場合があります。また、GEOIPだけで特定サイトの事業上の地域を正確に表せるとは限りません。より詳しい照合方法はルールキーワードの解説を、特定サイトの設定例は対象サイトをプロキシ経由にする設定例をご覧ください。変更後は「対象、適用されたルール、最終ポリシー」を記録すると、接続アイコンを見るだけの場合より的確に判断できます。

05 / 接続を確立する

接続確認とトラブルの切り分け手順

再現可能なテスト条件を整える

接続前に、デバイスから正常なWebページへアクセスできること、対象のサーバー項目が明確であること、Global Routingがテストするモードになっていることを確認します。初回のテストは同じWi-Fiまたはモバイル通信に固定し、テスト中にネットワークの切り替え、サブスクリプションの更新、ルールの変更を同時に行わないでください。テスト対象の記録も重要です。Webページのトップ、ログインAPI、アプリ内リクエストでは異なるドメインを使う場合があり、1つへのアクセス成功をすべての通信に当てはめることはできません。

サーバーを選択したら、Connectivity Testを実行してからメイン接続をオンにし、実際のリクエストを行います。テスト結果が示すのは、そのテスト方法での到達性と所要時間に限られます。すべてのプロトコル、接続先、長時間接続の結果を示すものではありません。ネットワークによっては、テスト用リクエストと実際の通信で異なる処理が行われるため、テスト失敗が実際のサービス利用不可を意味するとは限りません。反対に、テストに応答があっても、認証、TLS、接続先サイトへのアクセスがすべて成功する証明にはなりません。両方の結果をあわせて判断してください。

「接続が開始した」と「アクセスできる」を別々に確認

メインスイッチをオンにしたら、まずシステム上の接続状態が維持されるか確認し、ブラウザから新しいアクセスを一度行います。スイッチがすぐにオフに戻る場合は、システム権限、Configの読み込み、エラーメッセージを優先して確認してください。状態が維持されても接続先にアクセスできない場合は、サーバー、ルーティング、DNS、リクエストの詳細を調べます。システムのVPNアイコンだけを最終的な確認条件にしないでください。これはローカルのネットワーク構成の状態を示すもので、実際のリクエストには名前解決、接続、認証、接続先からの応答など複数の段階があります。

ページを開けた場合も、想定した経路でアクセスできているか確認してください。Configモードでは、各リクエストに適用されたルールとポリシーを確認します。Proxyモードでは、検証対象のサーバーが実際に選択されていることを確認してください。ページがキャッシュから表示されている場合、再読み込みだけでは新しい経路の動作を確認できないことがあります。明確な新規リクエストを行うか、対象ページを開き直してください。テスト後は通常のモードに戻し、もう一度確認します。トラブル対処のために変更した一時的な全体設定を残さないようにします。

問題の段階に応じて次の確認を行う

第1段階は現在のネットワークです。接続を切っても通常の接続先にアクセスできない場合は、まずWi-Fi、モバイル通信、ポータル認証、デバイスのネットワーク制限を確認します。第2段階はサーバーです。アドレス、ポート、認証情報、サービスの状態を確認してください。同じ条件で自分が利用している別の項目に切り替えると、特定のサーバーだけで起きている問題か判断しやすくなります。第3段階はルーティングです。ProxyではアクセスできてもConfigで失敗する場合は、有効なConfig、対象ルール、フォールバックポリシーを確認します。次の段階へ進む前に、それぞれの段階で結論を出してください。

第4段階はDNSと接続先へのリクエストです。ホスト名の名前解決に失敗している場合、想定するサーバーとの通信段階にまだ進んでいません。名前解決ができてもタイムアウトする場合は、接続の確立、認証、応答待ちのどこで止まっているかを切り分けます。証明書エラーが出たら、デバイスの時刻、Server Name、証明書の対応関係を確認してください。検証をすぐに無効にするのは避けます。特定のWebサイトだけで失敗する場合は、接続先の状態、ログイン状態、関連ドメインも確認してください。すぐにConfig全体を利用不可と判断しないでください。

一度に1項目だけ変更し、元に戻せる状態にする

トラブル対処で原因を見失いやすいのは、複数のパラメータを一度に変更して「使える」ようになったものの、どの変更が有効だったか分からなくなるケースです。変更前の値、変更内容、結果を時系列で記録し、毎回、説明できる条件を1つだけ変更してください。効果がなければ元の値に戻してから次の確認に進みます。改善した場合は同じテストを繰り返してください。これにより一時的なネットワークの変動にも気づきやすくなり、関係のない設定を原因と誤認しにくくなります。

さらに確認する場合は、接続中なのにアクセスできない場合の確認リストに沿って進めてください。問題を報告する際は、デバイスのネットワークの種類、Global Routing、エラーの分類、再現手順を記録すれば十分です。認証情報全体を添付する必要はありません。再現可能な説明には「どのネットワークで、どのモードを使い、どの接続先で、どのような結果になったか」を記載してください。スイッチのスクリーンショットだけでは十分ではありません。この記録は次の章でDataを確認する際にも役立ちます。

06 / 診断情報を確認する

Dataで通信量とリクエスト結果を確認

統計の対象範囲と確認する時間を把握する

Dataでは、アプリが提供する通信量や接続情報を確認できます。表示される項目は現在の画面によって異なります。数値を読む前に、それが現在のセッション、特定の期間、累積記録のどれを対象にしているか確認してください。対象範囲が異なる画面の数値をそのまま差し引くことはできません。アプリのローカル記録とサービス提供元の課金基準も異なる場合があります。数値が同じだけ利用枠から差し引かれたと判断せず、利用枠は利用者自身のサービスの記録で確認してください。

変化を判断できるよう、まず確認開始時点を記録し、テスト対象を1つだけ開いて、記録や通信量の増加を確認します。接続中は、デバイスのバックグラウンド同期、通知、画像の先読み、ほかのアプリのリクエストでも通信が発生する場合があります。アップロードまたはダウンロードの数値が増えても、データが処理されたことしか示しません。対象のWebページが正常に開けた証明にはなりません。ページが失敗していても、名前解決、ハンドシェイク、再試行、エラー応答にも通信が必要なため、少量の通信量が発生する場合があります。

ドメイン、ポリシー、エラーをあわせて確認

現在の画面にリクエストの詳細が表示される場合は、合計数だけでなく対象ドメイン、使用ポリシー、結果を確認してください。ConfigモードでリクエストがDIRECTになった場合、Directのルールに一致した可能性もあれば、最後のFINALで処理された可能性もあります。適用されたルールを確認して判断してください。現在の記録に適用ルールが表示されない場合は、設定の順序と条件を絞ったテストで原因を探します。IPアドレスだけを見て、特定のドメインルールに一致したと推測しないでください。

名前解決エラーが出た場合は、まずDNSの経路と対象の名前を確認します。接続タイムアウトが出た場合は、サーバーへの到達、接続先への到達、応答待ちを切り分けます。認証に失敗した場合は、サーバー項目の認証情報を確認してください。同じような症状でも原因が異なる場合があります。ページが読み込み中のままになるのは、APIドメインが誤った経路に振り分けられた場合もあれば、サーバーの応答が遅れている場合もあります。エラー情報は問題の段階を絞り込むために使います。特定の語句を見ただけで決まった設定変更を行わないでください。

条件をそろえて変化を確認

特定のページが通信を続けていると思われる場合は、そのページと関連アプリを閉じ、同じリクエストが続くか確認します。その後、ページだけを開いて新しい記録と比較してください。テスト中はサーバー、Global Routing、ネットワークの種類を変えず、ほかの要因を減らします。ページを閉じても通信量が増え続ける場合は、バックグラウンド処理や長時間接続がすぐに終了していない可能性があります。すぐにアプリの異常と決めつけず、少し待ってから再確認してください。すべての記録を消して推測し直すより、観察を繰り返すほうが有効な手がかりを残せます。

ルールが適用されていないと思われる場合は、変更後に新しく作成されたリクエストを確認しているか確かめてください。既存の接続は以前の経路を使い続ける場合があり、Dataには異なる時間帯の結果が混在することがあります。対象ページの接続を終了して同じ方法でアクセスし直し、必要なら影響を理解したうえでクライアントの接続を確立し直してください。比較する際は古い記録と新しい記録を区別します。以前のポリシーがリストに残っているだけで、保存したルールがまったく機能していないと判断しないでください。

通信量が急増した場合は、まず写真の同期、動画再生、アプリの更新など、実際に通信する処理を確認し、その後、大量の再試行が発生していないか調べます。同じ接続先でエラーが繰り返される場合は、大量のコンテンツを正常にダウンロードしたのではなく、アプリがリクエストを繰り返している可能性があります。発生時刻とエラーの種類を確認し、接続の章に戻って原因を調べてください。異常をすべてサーバーの速度の問題とみなしたり、短時間の観察だけでConfig全体を変更したりしないでください。どの種類のリクエストが、どの条件で変化したのかを先に確認します。

必要な記録を残し、機密情報の共有を避ける

診断情報を保存する場合は、発生時刻、モード、接続先の種類、エラーの概要を記録してください。完全な通信内容を保存するより、日常の管理に適しています。ドメイン、リクエストパス、アクセス時刻にも個人情報が含まれる場合があります。スクリーンショットを共有する前に、サブスクリプションURL、認証パラメータ、プライベートなアクセス内容が写っていないか確認してください。技術ログであっても機密情報が含まれないとは限らないため、問題の説明に必要な部分だけを残してください。

履歴を消去する前に、調査中の問題を示す最低限の記録を保存し、画面上の消去操作が対象とする範囲を確認してください。診断記録を消去してもサーバーは削除されません。項目を削除してもシステム権限はリセットされません。操作前に対象を確認してください。Dataの主な用途は、想定した動作と実際の結果を照らし合わせて確認することです。サービスの状態確認に代わるものではなく、合計数だけで全リクエストが同じ経路を通ったと証明することもできません。

07 / よく使う設定を調整する

Settings、DNS、On Demand

まず設定の適用範囲を確認

Settingsを変更する前に、問題がアプリ全体の動作、現在のConfig、個別サーバーのパラメータ、システムのネットワーク権限のどれに該当するか判断してください。名前が似た設定でも、異なる階層にあれば同じ機能を制御するとは限りません。たとえばサーバー項目のTLSはそのサーバーへの接続に、ConfigのDNS条件は名前解決の経路に、On Demandは自動接続の開始条件に関わります。実際の動作は現在の画面と有効なConfigの両方で決まります。変更前に設定の場所と値を記録し、誤った階層で調整を繰り返さないようにしてください。

安定して動作している設定を変更する場合は、手動接続の手間を減らす、特定ドメインの名前解決エラーを直す、特定のネットワークでの動作を確認するといった、明確な目的に沿って行います。サービス側の条件、ネットワーク環境、ルールの対象は異なるため、インターネット上の設定例をそのまま最適な値とみなさないでください。説明と画面上の選択肢が一致しない場合は、アプリで現在確認できる内容を基準にします。用途が分からない項目は変更せず、影響を小さくしたテストで動作を確認してから判断してください。

DNS：名前解決の結果は後続の接続にも影響する

DNSはドメイン名をアドレスに変換しますが、アドレスを取得できるかどうかだけでは判断できません。名前解決にどの経路を使うか、返された結果が現在のネットワークに適しているか、その後のリクエストがどのように接続されるかもアクセス結果に影響します。システムDNS、カスタムDNS、DNS over HTTPSの違いは、主に名前解決のリクエストがどのように送信され、誰が応答するかです。名前だけで、どれが必ず速いかを判断しないでください。カスタムの名前解決方法を追加する前に、もともとの問題が名前解決の失敗なのか、名前解決後の接続失敗なのか確認します。

DNS over HTTPSを使うには、対応する名前解決エンドポイントにアクセスできる必要があります。そのエンドポイントへのアクセスに、まだ正常に動作していないプロキシ経路が必要な場合、起動時に依存関係の問題が起きることがあります。同様に、サーバーアドレスがドメイン名の場合も、接続を確立する前に有効な名前解決結果が必要です。変更後はサーバーへの接続と対象ドメインへのアクセスをそれぞれ確認してください。キャッシュ済みのページを1つ表示できただけで、すべて復旧したと判断しないでください。変更に効果がなければ元に戻し、別の段階を確認します。

DNSの結果はIP-CIDRやGEOIPなど、アドレスに基づくルールにも影響する場合があります。ただし、ドメインルールとアドレスルールでは使用条件が異なります。1つのWebサイトが複数のアドレスを返す場合や、リクエストごとに異なるレコードが使われる場合があるため、1回の名前解決結果がすべての通信を表すわけではありません。具体的な選び方と確認方法はDNS設定の解説をご覧ください。変更前後の対象、名前解決の結果、アクセス時の状態を記録し、キャッシュの変化を設定の改善と誤認しないようにします。

On Demand：手動接続を確認してから自動接続を設定

On Demandは設定した条件に応じて接続を開始する機能で、誤ったサーバーパラメータを修正するものではありません。有効にする前に、手動で接続、切断、再接続が正常に行えることを確認してください。その後、自動接続の条件を1つずつ設定します。現在の画面でネットワーク環境ごとに条件を設定できる場合は、その環境に接続したとき、離れたとき、切り替えたときの動作をそれぞれテストしてください。一度に追加する条件は1種類にして、想定したタイミングで接続が始まるか確認します。複数の条件を重ねると、自動再接続の理由を判断しにくくなります。

有効にした後、手動で切断してもすぐに再接続する場合は、自動接続条件がまだ満たされている可能性があります。VPN構成を繰り返し削除するのではなく、まずOn Demandを確認してください。Directで基準となる接続を確認する場合は、関連する自動接続条件を一時停止してから切断します。そうしないとテスト中に自動で再接続されることがあります。トラブル対処後は元の条件に戻し、日常の接続に影響しないことを確認してください。自動化は、動作確認済みの手順を効率化するものであり、不安定な接続を隠すためのものではありません。

高度な設定は慎重に確認する

LAN内のリソース、UDP通信、特定の転送方式で問題が起きた場合は、まずサーバーと現在のプロトコルが必要な機能に対応しているか確認してから、関連する設定を調べてください。スイッチをオンにしただけで、サーバーに元からない機能が追加されることはありません。通常のWebページの問題に対して、複数の低レベル設定を一度に変更するのも避けてください。条件が増えて原因を特定しにくくなり、問題を再現しづらくなります。既存のConfigに特別なDNSやルーティングの指定がある場合は、意図を把握して元の内容を保存してから、コピーで試してください。

接続できるようになった後に大切なのは、設定を増やし続けることではなく、設定の意図を説明でき、変更を元に戻せる状態にすることです。サーバー、Config、アプリ全体の設定を区別しておくと、ネットワーク環境が変わった際に関係する階層だけを調整できます。日常利用の前にGlobal RoutingとOn Demandの状態を確認し、テスト用の設定をデバイスに残さないようにしてください。次の章では、これらの確認を繰り返し実行できる管理手順にまとめます。

08 / 設定を復元できる状態に保つ

バックアップ、更新、日常の管理

複数の項目を個別にバックアップ

アプリ、サーバー項目、サブスクリプションURL、Config、システム権限はそれぞれ別の項目です。どれか1つを保存すれば環境全体を復元できるとは限りません。管理を始める前に必要な内容を整理してください。サブスクリプションから作成された項目、手動で追加した項目、現在有効なConfig、自分で変更したルールがあるかを確認します。画面に保存や書き出し機能がある場合は、実際に何が含まれるかを確認してください。一部しか保存できない場合は必要な情報を個別に保存し、ファイル名だけを根拠に完全な復元が可能だと考えないでください。

バックアップファイルにはサーバーの認証情報やサブスクリプションの認証情報が含まれる場合があります。自分だけ、または明確に許可した人だけがアクセスできる場所に保存してください。公開メモ、共有アルバム、一般公開されるファイル領域には保存しないでください。自分で管理しやすいよう、用途、出所、ローカルでの保存日を記録してもかまいませんが、パスワードをファイル名に含めないでください。バックアップの有用性は保存操作を行ったかどうかではなく、必要な項目を理解し、復元できるかどうかで決まります。

変更前にコピーを作成し、変更後は確認結果を記録

Configを編集する前に、現在正常に動作しているコピーを保存し、今回解決したい問題を書き留めてください。1回の変更は、たとえばドメインルールを1つ追加するなど、同じ目的の範囲にとどめます。すべてのルールの並べ替え、DNSの変更、サーバーの変更を同時に行わないでください。保存後、新しいコピーが有効になっていることを確認し、接続の章に沿って新しいリクエストを行います。想定どおりでなければ元のConfigに戻して再テストしてください。同じ条件で元のコピーが正常に動作する場合は、外部ネットワークではなく今回の変更を引き続き調べる根拠になります。

管理記録は複雑にする必要はありません。問題、変更前の値、変更箇所、テスト対象、結果を順番に記録します。ルールの場合は想定したポリシーと実際に確認した結果も記載します。サーバーパラメータの場合は、情報を公開可能な文書に保存せず、どこで再確認できるかを記録してください。次回同じ症状が出たとき、検証済みの対処を把握できます。記録を続けることで、一時的に復旧しただけの変更と、同じ条件で再現性のある解決策を区別でき、試行錯誤を減らせます。

アプリの更新とサブスクリプションの更新を分ける

Shadowrocketのアプリ更新はApp Storeで行います。バージョン情報や更新内容はストアページの表示を確認してください。Subscribeの更新では、利用者自身の既存サブスクリプションから内容を再取得します。2つは別の操作です。問題を特定しやすくするため、アプリの更新、サブスクリプションの更新、Config全体の置き換えを同じテスト中に行わないでください。更新後は、既存の接続とよく使う接続先が正常か確認してから、次の変更に進みます。画面上の項目の場所が変わった場合は、該当する項目を探してください。項目が混在するのを避けるため、すぐに再インポートしないでください。

サブスクリプションを更新した後は、以前選択していたサーバーが残っているか、名称やグループが変わっていないか、手動変更が上書きされていないか確認します。古い項目が消えていても、サブスクリプション側の内容が変更された可能性があり、ローカル保存の失敗とは限りません。更新結果と項目の出所を確認してから、サーバーを選び直すか判断してください。更新に失敗しても古いリストが残っている場合は、テストで以前のデータを使っていることを確認します。古い項目に接続できても、今回の更新が成功したことにはなりません。

デバイスの変更・再インストール後の復元手順

デバイスを変更する場合は、まずApp Storeでアプリの購入履歴と互換性を確認します。次に自分のサーバー情報とConfigを復元し、最後にシステム権限と自動接続条件を確認してください。アプリを再入手できても、ローカルの項目が自動で表示されるとは限りません。システムのネットワーク権限も、新しいデバイスに表示された案内に従って設定します。復元後は、対象を明確にした項目を1つ選んで手動接続を確認し、次にルールとDNSを確認してからOn Demandを設定します。この順序なら、Configの有効性を確認する前に自動接続が何度も開始されることを防げます。

復元後に項目が重複していても、すぐにまとめて削除しないでください。バックアップから復元した項目と、サブスクリプションを再インポートした項目を見分けてから、残す出所を選びます。サブスクリプショングループを削除する前に、そのグループが管理する項目も一緒に削除されるか確認してください。複数の項目に関わる整理を行う場合は、復元に必要な情報を先に保存し、段階的に進めます。購入の復元については購入済みアイテムの復元方法をご覧ください。購入履歴とConfigのバックアップは別の役割です。

短く決まった手順で日常確認

日常のトラブル対処では、現在のネットワークが正常か、選択中のサーバーが正しいか、Global Routingが用途に合っているか、想定したコピーのConfigが有効か、サブスクリプションの前回更新が成功したかを順番に確認してください。その後、DNS、ルール、個別リクエストを詳しく調べます。長期間使用していないテスト項目は、出所を確認してから整理できます。使用中のConfigには分かりやすい名前を付けて保管してください。確認が終わったら一時設定を元に戻し、よく使う接続先でもう一度テストします。これにより、ある状況を解決した後に別の経路変更が残ることを防げます。

初めて操作する場合はクイックスタートに戻り、基本手順に沿って進めてください。症状の原因を理解したい場合は、本ページの目次から該当する段階を確認します。メンテナンス手順の目的は、すべての変更の出所、各テストの対象範囲、各設定の復元方法を明確にすることです。一度接続に成功しても、あらゆる状況で今後も利用できるとは限りません。安定して使えているときにConfig全体を頻繁に作り直す必要もありません。必要な記録を残して段階ごとに確認すれば、設定を積み重ねるより、明確で再現性のある結果を得やすくなります。