Shadowrocket Settings 設定ガイド

01 · Settingsの現在値とGlobal Routing

Shadowrocket下部のSettingsを開き、まずリストのグループと項目名を確認してから、該当する詳細画面に進みます。項目の場所や表示内容は、現在のアプリに表示される内容を基準にしてください。項目が見当たらない場合、名前の似た別項目を代わりに使わないでください。Homeでは現在のサーバーと接続操作を、Configでは設定ファイルとルールを、Settingsではアプリの動作やツールに関する設定を確認できます。これらは接続に影響しますが、制御する層はそれぞれ異なるため、問題を調べる際は分けて記録しましょう。

変更前の状態を記録する

まず、現在のネットワークがWi-Fiかモバイル通信か、Homeで選択されているサーバー、Global Routingのモード、Configで使用中のファイル名を記録しましょう。次に、変更する項目、変更前の値、期待する結果を書き留めます。たとえば「特定のWi-Fiに戻ったときに自動接続しない」のように、具体的な結果を設定します。「通信を速くする」のような曖昧な目標は避けてください。元の値が自動、空欄、継承の場合も、そのまま記録します。空欄は必ずしも無効を意味せず、Configファイルやシステムに処理を委ねている場合があります。

「デフォルト値」には、初回利用時にアプリが設定する初期値、読み込んだConfigファイルに明示された値、以前に保存され同期された可能性がある値の3種類があります。画面に表示された現在値だけでは、どれに該当するか判断できません。本ガイドでは、機器間で共通と確認できない項目について「現在正常に使えている値を維持する」ことを推奨します。すべての環境に共通するポート、テスト先、スイッチの状態があるとは限りません。既存の設定を不用意に上書きせず、変更と結果の関係を把握しやすくなります。

Global Routingの3つのモード

HomeでGlobal Routingを確認します。Config、Proxy、Directは、それぞれ設定に従う、Proxyを経由する、直接接続するモードです。Configでは現在のConfigファイルのルールに従って経路を選びます。Proxyは、経路の選択が問題に関係しているかを一時的に切り分ける際に使えます。Directは、選択したProxyサーバーを経由しない場合の接続状況を確認するためのモードです。これらはルーティング動作の選択肢であり、接続品質の評価でも、正しいサーバー設定の代わりでもありません。比較テスト後は必要なモードに戻し、一時的な診断状態をそのまま使い続けないようにしましょう。

一度に一つだけ変更して結果を確認

一度に変更するのは一つの条件だけにして、同じリクエストを再実行してください。DNS、サーバー、Global Routingを同時に変更すると、ページが表示できるようになっても、どの変更が有効だったのか判断できません。すでに読み込まれた内容だけを見るのではなく、新しいページを開くか、接続を再確立してテストします。ブラウザーのキャッシュ、既存の接続、アプリのバックグラウンド状態が変化を隠すことがあります。新しいセッションから変更が反映される場合は、いったん接続を停止してから再接続し、Homeに表示される選択項目も確認してください。

初回接続時に必要となるシステムのVPN構成の許可と、Configファイル内のProxyルールは別のものです。システムの許可によりアプリがネットワーク接続を確立できるようになりますが、サーバー情報が正しいことや、サブスクリプションが読み込まれていることを示すものではありません。スイッチをオンにできてもページを開けない場合は、初回接続の確認ガイドに沿って選択内容とテスト手順を確認してください。目的がはっきりしない高度な設定は、現在の状態を維持することをおすすめします。変更前の値、変更理由、元に戻す手順を説明できて初めて、管理可能な設定変更といえます。

02 · DNS：名前解決の仕組み、設定範囲、トラブルの見分け方

まずSettingsでDNS関連の項目を確認し、次にConfigで現在の設定ファイルを開いてDNS設定があるか確認します。実際に表示される項目を基準にしてください。別の画面にある設定が、名前解決の動作とConfigの内容をそれぞれ制御している場合があります。DNSはドメイン名をIPアドレスに変換するもので、その後に接続先の決定、経路の選択、リクエストの完了が続きます。そのため「ドメイン名を解決できる」ことと「Webページを開ける」ことは別の結果です。一方だけを根拠に、もう一方も正常だと判断しないでください。

設定の取得元を確認する

Configファイルでは、GeneralセクションにDNSサーバーを指定できます。以下の例は、システムのDNSを使う記述方法を示すもので、すべてのConfigにおけるデフォルト値でも、既存ファイルを置き換える指示でもありません。まず現在のファイルに該当する項目があるか確認してください。同じパラメーターを重複して追加すると、管理や原因の特定が難しくなります。リモートの内容で更新されるファイルは、手動での変更が次回更新時に置き換わる場合もあります。別のコピーを保存してから、日常的に使うファイルをどれにするか決めましょう。

[General]
# 解説用の例：システムのDNSを使用。デフォルト値を示すものではありません
dns-server = system

[Rule]
# ドメインの例はPROXY経由
DOMAIN-SUFFIX,example.com,PROXY
# プライベートアドレス範囲はDIRECT
IP-CIDR,192.168.0.0/16,DIRECT
# その他のリクエストはPROXY経由
FINAL,PROXY

画面上で編集できる設定項目だからといって、Configの内容すべてに必ず優先されるとは限りません。画面に説明や継承状態、適用範囲が示されている場合は、その内容に従って判断してください。明確な説明がない場合は、現在のConfigのコピーで一つずつ変更を試し、リクエスト記録を確認します。推奨値は特定のDNSアドレスではなく、現在のネットワークと設定に合い、繰り返しテストで利用できると確認できたDNSです。名前解決が正常なら、抽象的な指標を追ってすべての設定を変える必要はありません。

名前解決の問題と接続の問題を切り分ける

診断では、普段アクセスできるドメインを一つ選び、名前解決の結果が返るか記録してから、接続がタイムアウトするか確認します。どのドメインも解決できない場合は、まず現在のネットワーク、DNSの接続可否、Configの記述ミスを確認してください。特定のドメインだけに問題があるなら、ドメインのレコードやキャッシュ、そのドメインに適用されるルールを確認します。名前解決は正常でも接続できない場合は、選択中のサーバー、接続先のサービス、ルーティングを確認してください。名前解決以外の問題に対処するために、DNSを何度も変更しないようにしましょう。

ドメイン名を条件とするルールもあれば、接続先のIPアドレスで判定するルールもあります。名前解決後に複数のIPアドレスが返ることや、アクセス時に複数のドメインへ接続することもあります。そのため、1つのページを読み込んだ際に複数のポリシーが適用されても、設定が無効とは限りません。同じ新規リクエストのドメイン、接続先アドレス、マッチしたルールを照合してください。ページ名だけを見て判断しないようにしましょう。IPv6についても、現在のネットワークと接続先が対応しているか確認したうえで、該当する名前解決とアドレスルールを確認します。特定のアドレス種別を無効にすることを、すべての問題に対する最初の手段にしないでください。

キャッシュ、ネットワーク切り替え、推奨手順

DNSの参照先を変更しても、古いキャッシュや既存の接続が引き続き使われる場合があります。古いリクエストを終了し、必要に応じて再接続してから、新しいページにアクセスしてください。画面にキャッシュの削除機能がある場合は、その説明に従って操作します。1つのドメインの問題を解決するために、Config全体を削除しないでください。Wi-Fiとモバイル通信を切り替えると、システムが取得するDNSや接続可否が変わることもあります。一方のネットワークでの結果を、もう一方の結果として扱わず、テスト記録にはネットワーク環境も含めてください。

追加の接続手順を必要とするDNS方式を使う場合は、DNSサービス自体への接続経路も考慮してください。IPアドレスを取得するために、まず別のドメインへアクセスしなければならない場合、最初の名前解決が複雑になることがあります。タイムアウトが発生したら、接続先のWebサイトだけでなく、この依存関係も確認しましょう。まず動作確認済みのシンプルな設定から始め、必要に応じて項目を追加することをおすすめします。元に戻す際は、以前のDNS設定を復元して再接続し、重複した設定が残っていないことも確認してください。変更前の状態に戻ったか正しく判断できます。

03 · On Demand：条件による接続と手動接続

SettingsでOn Demandを開き、まず全体のスイッチを確認してから、現在のConfigに設定されているネットワーク条件と動作を確認します。On Demandは条件に応じて接続動作を管理する機能です。サーバーの通信速度を上げるものでも、不足しているサーバー情報を補うものでもありません。設定を始める前に、同じサーバーへ手動接続して正常に使えることを確認してください。そうしないと、条件による自動接続とサーバーの問題が重なり、自動接続に失敗する原因を特定しにくくなります。

条件を決めてから動作を選ぶ

よく使われる条件は、Wi-Fi、特定のSSID、モバイル通信などのネットワーク環境に関するものです。実際の画面に表示される項目を使い、対象と動作を一つずつ確認してください。「特定のネットワークを含む」を「それ以外のすべてを除外する」と解釈しないようにしましょう。SSIDはWi-Fiネットワーク名であり、サーバー名ではありません。設定時は大文字・小文字、スペース、デバイスに表示される名前全体を確認します。同じ名前でも実際の環境が異なる場合、名前だけですべてを区別できないため、手動で接続状態を確認する習慣を保ちましょう。

まずは検証しやすい条件を一つだけ設定することをおすすめします。たとえば、モバイル通信から普段使うWi-Fiに切り替えたとき、期待する動作が行われるか確認してから、次の条件を追加します。最初から互いに重なる複数の条件を設定すると、意図しない接続が起きた際に、どの条件が適用されたか判断しにくくなります。リスト内のすべての項目が想定どおりの順に加算されるとは限りません。画面の説明を読み、優先関係を把握してから、実際にネットワークを切り替えて確認してください。説明されていない動作を推測で補わないようにしましょう。

停止したのに接続が再び始まる理由

手動で停止した後に接続が再び始まる場合は、システムのVPN構成を何度も削除するのではなく、まずOn Demandに該当する条件が残っているか確認してください。有効なオンデマンド条件に応じて、システムが新たなネットワークリクエストに反応することがあります。一度接続を停止する操作と、自動接続を無効にする操作は別です。一時的に手動接続だけで切り分ける場合は、先にOn Demandを無効にしてから接続を停止し、新しいリクエストで再接続が始まらないことを確認します。切り分け後は、記録した条件に戻してください。

ネットワークの切り替えも瞬時に完了するわけではありません。デバイスは、元の接続を失い、新しいIPアドレスやDNS情報を取得してから、新たな接続を確立することがあります。その間、一時的に利用できなくても、条件設定が間違っているとは限りません。Wi-Fiまたはモバイル通信が安定してから新しいリクエストを行い、Homeで選択中のサーバーが期待どおりか確認してください。On Demandは接続の開始条件を管理するもので、ネットワークを切り替えるたびに別のサーバーを選ぶ機能ではありません。

画面ロック、バックグラウンド、復元時の確認

ロック画面やバックグラウンドでの動作は、システムの管理やネットワーク状態に左右されます。アプリが常に前面に表示されているかどうかだけで、接続の有無を判断しないでください。長時間のロック後にだけ問題が起きる場合は、ロック解除時のネットワーク、接続状態、最初に行った新規リクエストを記録し、通常のネットワーク切り替えテストと比較します。バックグラウンド動作を確認するために、スイッチをすばやく何度も切り替えないでください。状態の変化が増え、接続が開始された経路が分かりにくくなります。ネットワークが安定し、リクエストが完了するまで待ってから確認しましょう。

このページでは、現在表示されているOn Demandのスイッチ状態を、初回インストール時の共通の初期値とはみなしません。デバイスに既存の設定が残っている場合があるためです。自動接続が不要なら手動操作を維持することをおすすめします。必要な場合は、明確な利用状況をカバーする最小限の条件を設定し、無効にする手順も記録してください。期待しない動作が起きたら、まず全体のスイッチを無効にして手動接続が正常か確認してから、条件を一つずつ戻します。多くの例外を一度に設定して競合を探すより、元に戻す手順を残すほうが確実です。

04 · PingとConnectivity Test：テスト対象と結果の見方

まずSettingsでPing関連の設定を開き、現在利用できるテスト方法と対象を確認します。次にHomeに戻り、サーバーリストのテスト結果を確認してください。具体的な選択肢はアプリに表示される内容を基準にし、一つの数値だけでテスト方法を決めつけないでください。日常会話ではPingを遅延テスト全般の意味で使うことがありますが、測定する段階は方法によって異なります。アドレスへの到達性を確認するもの、ポートへの接続を測るもの、指定した接続先へのリクエストまで含むものがあり、結果を混ぜて比較してはいけません。

数値からわかること

テスト結果が示すのは、実行時点、現在のネットワーク、現在の方法における一部の状況です。テスト対象、DNS、プロトコルのハンドシェイク、サーバーからの応答が結果に影響するため、数値が小さくてもWebページの読み込みが速いとは限りません。数値が大きくても、接続できないとは限りません。応答がない探査方法でもページを正常に開ける場合は、その方法がどこまで測定するものか確認してください。逆に、ポートへの接続が確立できても、認証や上位プロトコル、最終的なリクエストが成功するとは限りません。

テストの設定を変更する前に、元の方法と対象を記録してください。異なる条件の結果を同じデータとして比較しないためです。テスト対象を自分で入力する場合は、継続的にアクセスでき、テスト方法の条件に合ったアドレスを使います。サブスクリプションURLをテスト対象にしたり、アクセス情報を含むリンクを入力したりしないでください。テスト先は接続確認のために使うもので、サーバー情報を読み込むものではありません。タイムアウト設定は、まず現在値を維持することをおすすめします。短すぎると通常の遅延を失敗と判定し、長すぎると応答がないときの待ち時間が増えます。

リストのテストと実際のリクエストを照合する

Homeで現在のサーバーに選択マークが付いていることを確認して接続し、Connectivity Testを実行します。テスト後は、実際に利用するページへ新しいリクエストを送ってください。これにより、「リストの探査に応答があった」「アプリのテストが完了した」「目的のサービスを利用できた」という3つの段階を区別できます。リストの数値だけを見てサーバーを選択していない場合、その後のリクエストで別の項目が使われることがあります。システムのVPNアイコンだけでは、上位レベルのアクセスが完了したかどうかは分かりません。

2つのサーバーを比較する場合は、ネットワーク、テスト方法、テスト対象を同じにし、できるだけ近い時間に実行してください。モバイル通信に切り替えながらテスト先も変更し、その結果をサーバー自体の差として扱わないようにしましょう。大きく変動する結果は、少数回繰り返して安定して完了するか確認し、最も良い結果だけを記録しないでください。選択方法の詳細は遅延、地域、プロトコルの選び方をご覧ください。数値と実際の使用感は別であることも説明しています。

テストの基準を設定する

このガイドでは、すべてのデバイスで共通して使えるテスト対象やタイムアウト値を指定せず、保存されている値をアプリのデフォルトともみなしません。実際の目的を説明できる方法を選びましょう。最終的なWebページのリクエストを確認するなら、接続の初期段階だけで終わらせず、実際のアクセスも検証する必要があります。同じテスト基準を継続して使うと、ネットワークの変化を把握しやすくなります。対象を頻繁に変更すると、過去の結果と比較できなくなります。

Connectivity Testと実際のページ表示が異なる場合は、同じ経路を通っているか、別のドメインにアクセスしているか、テスト対象自体が応答しているかを確認してください。あるテスト先のメンテナンスや一時的な障害が、すべてのアクセスの不具合を示すとは限りません。設定を元に戻す際は、テスト方法と対象を復元し、サーバーを再選択して同じリクエストを実行します。時刻、ネットワーク、方法、対象、結果をまとめて記録すると、遅延の数値だけを保存するより原因を判断しやすくなります。

05 · LogとData：リクエスト記録から設定の問題を調べる

SettingsでLog関連の設定を確認し、現在の画面に表示される入口からログやリクエスト記録を開きます。Dataに表示される情報も、実際の画面を基準にしてください。Logはリクエストがどのように処理されたかを確認するのに適し、Dataは接続や通信量を把握する手がかりになります。請求額やサービス提供元の統計と混同しないでください。調査を始める前に、問題が起きた時刻と対象のリクエストを特定し、該当する記録を開きます。大量の履歴から推測で原因を探さないようにしましょう。

原因を特定しやすい新しいリクエストを行う

記録を開始したら、調べたいページや機能だけを操作し、おおよその時刻を記録します。複数のアプリを同時に開くとバックグラウンドのリクエストが増え、別のドメインのエラーを現在のページの問題と誤認しやすくなります。ページの読み込みでは複数のドメインにアクセスすることがあり、メインページが成功しても関連リソースのリクエストに失敗すると、表示が不完全になる場合があります。一つの操作に関連するリクエストをまとめて確認し、失敗した記録を一つ見つけただけで設定全体を変更しないでください。

記録を読むときは、ドメイン、接続先アドレス、マッチしたルールとポリシー、接続段階でエラーが発生したかを順に確認します。現在の記録に実際に表示される項目だけを根拠にしてください。項目が表示されないからといって、その処理が実行されなかったと推測しないでください。リクエストがREJECTにマッチした場合は、意図したルールか確認します。DIRECTにマッチし、Proxy経由を想定していた場合は、サーバーのパスワードやテストのタイムアウトを変更するのではなく、ルールの順序と選択中のConfigを確認してください。

ログレベルと記録の範囲

ログレベルは記録の詳細さを決めます。レベルごとの具体的な内容は、アプリの説明を確認してください。日常的には基本的な確認に必要な現在のレベルを維持し、再現できる問題が発生した場合に限り、一時的に詳細度を上げることをおすすめします。調査後は元に戻してください。記録を増やしても接続が改善するわけではなく、確認の手間が増える場合もあります。詳細ログは性能を上げる設定ではありません。証拠を集めるための機能であり、誤ったルールやサーバーパラメーターの修正に代わるものではありません。

[General]
# 解説用の例：ログレベル。アプリのデフォルト値を示すものではありません
loglevel = notify

[Rule]
# 具体的なドメインのルールは、より広い範囲のルールより前に置く
DOMAIN-SUFFIX,ad.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
# その他のリクエストにはPROXYを使用
FINAL,PROXY

上の例では、より具体的なドメインルールを先に置き、広い範囲のルールに先回りしてマッチしないようにしています。ルールは上から順に評価され、マッチすると対応するポリシーが適用されます。そのため、「ファイルにルールが書かれているか」だけでなく、「実際にどの行がマッチしたか」が確認の要点です。REJECTの適用範囲や誤ブロックへの対処は、REJECTルールの解説をご覧ください。例にあるドメインは記述方法の説明用で、利用可能なサービスを示すものではありません。

Dataの数値と機密情報の取り扱い

Dataを確認するときは、まず集計範囲と計測の開始条件を確認してください。接続の再確立、アプリの再起動、統計情報の消去によって表示範囲が変わることがあります。異なる範囲の数値を単純に引き算し、特定のアプリの通信量として説明することはできません。少量の通信があることはデータ交換が発生したことを示しますが、目的のページが完全に利用できる証拠にはなりません。数値が変化しない場合も、リクエストがキャッシュされている可能性があります。Dataは補助的な手がかりとして、ログや実際のリクエストと合わせて判断してください。

ログにはドメイン、アドレス、リクエストパス、サブスクリプション情報など、アクセスに関する情報が含まれる場合があります。調査資料を保存する場合は、まずローカルの原本を保管し、確認したうえで説明用のコピーを作成して、アクセス情報や不要な内容を削除してください。サブスクリプションURLをそのまま公開しないでください。ログを消去する前に、必要な時刻とマッチ結果を記録したことを確認します。問題が再現しない場合も、ログレベルをいつまでも上げたままにせず、通常の設定に戻してください。次回発生したときに、同じ手順で必要最小限の記録を集めましょう。

06 · Widget：クイック操作、表示状態、システムの更新

まずSettingsでWidget関連の設定を確認し、次にシステムのウィジェット管理画面で、現在のデバイスに追加できるShadowrocketのウィジェットを確認します。選べるサイズ、表示内容、操作方法はアプリとシステムが実際に提供するものを基準にしてください。別のデバイスのレイアウトが、このデバイスにも必ずあるとは限りません。Widgetは状態表示やクイック操作の入口であり、独立したサーバー設定ではありません。Homeでの選択項目や接続確認の代わりにもなりません。

追加する前にアプリ内の状態を確認

まずHomeで利用するサーバーを選択し、Global Routingを確認して、実際のリクエストで接続を検証してからWidgetを追加することをおすすめします。こうすれば、表示やクイック操作に問題が起きたときに、サーバー設定と切り分けられます。表示対象を選べるWidgetの場合は、現在選択中の項目、指定した項目、別のグループのどれを指しているか確認してください。選択機能がない場合、遅延の結果に応じて自動でサーバーを選ぶと推測しないでください。

追加後は、Widgetの表示とアプリ内の状態が一致しているか確認してから、明示的に対応している操作をテストします。操作の入口によっては、まずアプリが開き、その後アプリ内で処理が行われます。直接操作を完了できるかどうかは、現在のシステムやWidgetの機能によります。タップ時の反応だけでなく、最終的な状態を確認してください。目的のサーバーに切り替わったことを確認する場合は、Homeに戻って選択マークを確認し、新しいリクエストを行います。アプリが開いたことを、接続先の切り替え完了と取り違えないようにしましょう。

表示がすぐ更新されないことがある理由

システムがWidgetの更新とバックグラウンド実行を管理するため、Widgetを秒単位で更新されるリアルタイム監視画面とみなすことはできません。ネットワークの切り替え直後、接続の停止直後、サーバーの変更直後は、以前の状態が表示されることがあります。まずShadowrocketを開いて状態を確認し、その後Widgetが更新されるのを待ちましょう。古い表示を見て何度もタップするのは避けてください。接続と停止を繰り返すと実際の状態が変わり続け、アプリとWidgetの表示が食い違いやすくなります。

アプリ内と実際のリクエストは正常なのに、Widgetだけが長時間更新されない場合は、表示の問題として調べます。WidgetがShadowrocketのものか確認し、設定を確認したうえで、アプリを開き直すかWidgetを追加し直してください。最初にサーバーやConfigファイルを削除しないでください。アプリ内でも接続できない場合は、Home、On Demand、ネットワークの確認手順に戻ります。Widgetを追加し直しても、サーバー認証やDNSの問題は解決しません。

On Demandと併用する場合の動作

Widgetでの手動操作とOn Demandの条件による接続が、前後して実行される場合があります。たとえば、クイック操作で接続を停止した後に、該当する条件に基づいてシステムが再接続することがあります。その場合は、Widgetの故障と判断せず、On Demandを確認してください。クイック操作をテストする際は、まずオンデマンド接続を一時的に無効にして手動操作を確認し、その後条件を戻して組み合わせて検証することをおすすめします。「操作の入口が実行されたか」と「実行後に別の条件で状態が変わったか」を分けると、原因を把握できます。

ロック画面に表示される情報は、プライバシーにも配慮してください。Widgetにサーバー名や接続状態が表示される場合、画面上で公開したくない情報が名前に含まれていないか確認します。サーバーのメモは識別に役立ちますが、パスワード、サブスクリプションURL全体、その他のアクセス情報は書き込まないでください。名前はローカルで管理するための情報であり、変更してもサーバーのアドレスやプロトコル設定は変わりません。変更後はHomeで選択中の項目を確認し、同名の項目と混同しないようにしましょう。

このページでは固定のWidgetサイズやレイアウトを指定せず、Widgetが表示されないことをインストール失敗ともみなしません。必要な表示やクイック操作だけを追加し、アプリ内でも確認できる経路を残すことをおすすめします。システム要件と対応状況はApp Storeの表示および実際のデバイス画面をご確認ください。Widgetの設定を元に戻す場合は、まずWidgetを削除し、アプリの設定は維持したまま日常の接続が正常か確認してから、必要なものを一つずつ追加します。このように切り分けると、アプリ全体のリセットより既存の正常な環境を保ちやすくなります。

07 · iCloudとConfig：同期範囲、バックアップ、ファイル更新

まずSettingsでiCloud関連の項目を確認し、現在の画面に表示される同期範囲の説明を読んでから、Configでこのデバイスのファイルを確認します。同期の可否は、システムのiCloudの状態、アプリのアクセス許可、ネットワーク環境にも左右されます。スイッチをオンにしただけで、すべてのデータがすぐ別のデバイスに転送されるわけではありません。Home、Config、統計記録、システムの許可がすべて同じ範囲で同期されるとも限りません。画面に明示された内容を基準にしてください。

同期前に見分けられるコピーを保存する

同期を有効にしたり設定を変えたりする前に、現在のファイル名を整理し、使用中のファイルを記録して、アプリが提供する保存または書き出し方法で復元可能なコピーを残すことをおすすめします。「日常用ルール」「確認用コピー」のように用途を名前に含めても構いませんが、未検証の効果を示すような名前は避けてください。ファイルをコピーしただけでは、内容がすべて保存されたとは限りません。コピーを開き直し、必要なGeneralやRuleなどのセクションがあることを確認してください。

同期とバックアップでは目的が異なります。同期は、対象のデバイス間で変更を共有するための機能で、誤った変更も反映される場合があります。バックアップは変更前の状態に戻すためのものです。同じファイルを2台のデバイスで編集する前に、どちらを基準にするか決めてください。競合の通知や同名のコピーが表示された場合は、まず両方を別々に保存し、ルールの内容を比較します。ファイル名だけで上書きするものを決めないでください。名前が同じでも内容が同じとは限らず、最後に開いたファイルが残したいバージョンとも限りません。

Configの更新とローカル編集の注意点

Configで現在有効なファイルを確認し、リモートコンテンツから取得したものか、更新の入口があるかを調べます。リモートConfigの更新と、HomeのSubscribeから行う更新は別の対象です。前者はルールやConfigの内容、後者は読み込んだサーバー情報に関するものです。どちらも接続に影響する可能性がありますが、分けて確認してください。サブスクリプションURLはご利用のサービス提供元から入手します。読み込み後も一般公開してよいURLとして扱わず、同期しやすくするために公開メモへ記載することも避けてください。

リモートConfigを直接編集する前に、次回の更新で変更内容が上書きされる可能性を考慮してください。長期的に維持したい個別ルールは、管理可能な別のコピーにまとめ、更新元と内容を統合する方法を記録することをおすすめします。アプリに別の管理方法が用意されている場合は、その説明に従ってください。ローカルの内容がすべて自動的に保存されると、経験だけで判断しないでください。更新後は重要なルールと最終ポリシーを確認し、更新処理の完了表示だけで判断せず、実際のリクエストを行います。

機種変更時や同期の問題を確認する順序

別のデバイスに期待した内容が表示されない場合は、まずシステムアカウントとiCloudが利用可能か確認します。次にShadowrocketに関連する許可とアプリ内のスイッチを確認し、ネットワークが安定してから再度表示を確認してください。同期を何度も切り替え、すぐローカルファイルを削除するのは避けましょう。唯一の完全なコピーを失うおそれがあります。2台のデバイスで一部の内容だけが異なる場合は、同期の失敗を判断する前に、その内容が同期対象に含まれるか確認します。対象外の内容は、アプリが提供する方法で個別に移行してください。

アプリの再入手とアプリ内データの復元は分けて考えてください。購入済みアプリはApp Storeから再入手できます。手順は購入済みアプリの復元ガイドをご覧ください。サーバー、ルール、システムの接続許可は、それぞれ確認が必要です。サブスクリプショングループが複数ある場合は、複数サブスクリプションの管理ガイドを参考に重複項目を整理してください。新しいデバイスで動作確認が完了するまでは、旧デバイスで使える設定を残し、両方で同時に編集するのは控えましょう。基準となる内容が一致してから、通常の同期に戻してください。

08 · Proxyポート：リスニング範囲と設定の復元確認

SettingsでProxy関連の項目を確認し、ローカルProxyの待ち受け、接続共有、その他実際に提供される設定を区別します。項目名と対応範囲は現在の画面を基準にしてください。ここで扱うローカルポートは、Add ServerにあるリモートサーバーのPortとは別のパラメーターです。前者は、端末上のProxy接続をどのポートで受け付けるかを示し、後者はクライアントがリモートサービスへ接続するポートを示します。両方を同じ数字にしても接続が改善するわけではなく、既存の設定を壊すおそれがあります。

ローカルの待ち受けが本当に必要か確認する

HomeのスイッチからShadowrocketを使い、他の明確なローカルProxy利用の要件がない場合は、Proxyの項目があるというだけで追加の待ち受けを有効にしないでください。接続元が対応するProxyプロトコルと、接続するアドレスおよびポートを把握している場合に限って変更することをおすすめします。HTTPとSOCKS5では接続方法が異なります。接続元のプロトコルを間違えると、ポートに到達できてもリクエストを完了できない場合があります。ポート番号だけを確認して終わりにしないでください。

通常、ループバックアドレスは端末内部からのみアクセスできることを示します。現在の画面にLANへ公開する設定がある場合は、対象範囲とリスクが異なります。有効にする前に、ネットワークが信頼できるか、どのデバイスが接続できるか、認証やアクセス制限が設定できるかを確認してください。同じWi-Fiに接続できるすべてのデバイスを信頼できるものとみなさず、確認のためだけに公共のネットワークで待ち受け範囲を広げないでください。明確な必要性がある場合も、要件を満たす最小限の範囲にし、使い終わったら元に戻します。

ポート、アドレス、競合の確認

ポートは有効な数値で、接続元に入力した値と一致している必要があります。待ち受けを開始できない場合は、まずスイッチの状態、入力形式、ポートの競合を確認し、アプリに表示されるメッセージを確認します。ポートを無作為に何度も変更して、たまたま一度成功した結果だけを残さないでください。値を変えるたびに接続元の設定も変更し、変更前後の値を記録します。このページでは共通のデフォルトポートを確認できないため、推測した数値は示しません。現在の画面と関連する説明を確認し、検証できている元の値を維持してください。

アドレスも利用範囲に合わせる必要があります。端末内部から接続する場合と、別のデバイスから接続する場合で、同じアドレスを区別せず使えるとは限りません。Wi-Fiでデバイスに割り当てられるアドレスは、ネットワークの変更によって変わることがあるため、前日に保存した接続先が今日も正しいとは限りません。ネットワーク切り替え後にだけ問題が起きる場合は、リモートサーバーの設定をすぐ変更するのではなく、現在のアドレスとネットワークの隔離条件を確認してください。追加の待ち受けを無効にした状態で、既存の手動接続が正常か確認するのも有効な切り分け方法です。

ルールと接続確認の全体像に戻る

接続がアプリに入った後も、現在のGlobal RoutingとConfigに従ってポリシーが適用されます。以下の例では、ルールの順序を示しています。最初に特定のドメインとプライベートアドレスを処理し、次に地域ルールを適用し、最後にFINALを使います。GEOIPの判定はアドレスと対応するデータに基づきます。Webページの言語やサーバー名を表すものではありません。この例はルールの記述方法を説明するもので、確認せずにConfig全体を置き換えないでください。既存の設定に必要な例外ルールがあるか、特に確認しましょう。

[Rule]
# 指定したドメインにはPROXYを使用
DOMAIN-SUFFIX,example.com,PROXY
# プライベートアドレス範囲にはDIRECTを使用
IP-CIDR,192.168.0.0/16,DIRECT
# 該当するアドレスデータにマッチした場合はDIRECTを使用
GEOIP,CN,DIRECT
# 先行ルールにマッチしない場合はPROXYを使用
FINAL,PROXY

調整後は、現在のネットワーク、Homeの選択項目、Global Routing、Config、On Demand、変更したProxy項目の順に確認してから、新しいリクエストを行い、記録を確認します。この順序で、「接続の入口が利用できない」「ルールの選択が想定と異なる」「リモート接続に失敗している」を切り分けられます。ローカル接続のリクエストに失敗したからといって、DNS、同期、すべてのサーバーを同時にリセットしないでください。変更した範囲に影響を限定することで、正常に使えている基準状態を保てます。

結果を説明できない場合は、記録した元の値に戻し、今回追加した待ち受けや条件を無効にして、変更前の経路を再検証してください。復元後に正常になっても、今回の変更が関係していることが分かるだけで、特定のパラメーターに誤りがあったとは限りません。改めて一つずつ変更してテストします。日常的な推奨設定は、固定された数値の一覧ではなく、必要な機能が有効で、適用範囲が明確であり、元の値に戻せて、実際のリクエストで検証できる状態です。初回接続の手順はクイックスタートガイドをご覧ください。購入や互換性の問題は正規版の入手方法をご確認ください。ネットワーク設定で、本来別の問題を解決しようとしないようにしましょう。