Shadowrocket Settings設定ガイド

1. Settings、Config、動作状態の影響範囲

設定を変更する前に、問題がどの層にあるかを確認します。Settingsのアプリ設定、Configで選択中の設定ファイル、Homeで選択したサーバーや接続スイッチは、それぞれ別の状態です。サーバーは接続先とプロトコル設定を決め、設定ファイルはルールと関連する処理を決めます。Global Routingは現在の通信の振り分け方を決めます。ある設定を変えても、別の層まで自動的に切り替わるわけではありません。トラブル対処の際は、それぞれの状態を記録してください。

Global Routingの3つのモード

普段、ルールに基づいて通信を処理する場合はConfigを使い、Config画面で選択中のファイルを確認します。Proxyは一時的にプロキシ経由の動作を確認するとき、Directは直接接続時との比較に適しています。どちらも誤った設定を修復するものではありません。Proxyに切り替えたらWebページを開けたとしても、DNSやルールがすべて正しいとは限りません。そのときの条件で、選択したプロキシ経路からアクセスできたことだけが確認できます。

初期値、現在値、推奨値

初期値は、関連する設定を変更する前のアプリの状態です。現在値は、ユーザーによる編集、設定のインポート、復元操作などで変わっている場合があります。スイッチがオンなら、現在オンであることは確認できますが、最初からオンだったとは限りません。用途がわからない項目は変更せず、問題と検証方法を説明できる場合にだけ変更することをおすすめします。サーバーのプロトコルに関する項目は、利用中のサービス情報に従ってください。汎用の設定値で置き換えないでください。

基本状態の確認にデータの消去は必要ありません。まずGlobal Routing、現在のConfigファイル名、選択中のサーバー、関連するスイッチを記録します。設定ファイルを編集する場合は、先にローカルにコピーを保存してください。次に、安定して繰り返しアクセスできる宛先を選び、現在のネットワークでの状態を記録します。DNSだけを変更する、サーバーだけを切り替える、On Demandだけを無効にするなど、一度に変更する条件は1つに絞ります。複数を同時に変えると、原因を特定できなくなります。

設定ファイルを使ったトラブル対処

設定ファイルには、全般設定、ルール、ローカルマッピングなどを記述できます。以下の例は構造を説明するもので、既存のファイルを上書きする指示ではありません。例示のドメインは学習用です。PROXYには、現在の環境で利用できるプロキシの選択先を指定してください。元のファイルで具体的なポリシー名を使っている場合は、有効な参照を維持します。インポート後はファイルが選択されていることを確認し、リクエスト記録で実際に適用されたルールを確認してください。テキストが保存されたことだけでは不十分です。

[General]
dns-server = system

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

[Host]
localhost = 127.0.0.1

変更後は、対象のリクエストが成功するか、想定したポリシーが適用されているか、ほかのよく使う宛先も正常かの3点を確認します。失敗した場合は、直前に変更した項目を元に戻して結果を比較してください。戻しても問題が続く場合は、検証中にネットワークの切り替え、サブスクリプションの更新、サーバーの変更がなかったか確認します。設定ファイルの詳しい構成は設定ファイルの構造を詳しく見るをご覧ください。初回インポートの手順はガイドページをご確認ください。

2. DNS：名前解決元、設定の上書き、キャッシュの確認

DNSはドメイン名を接続先のアドレスに変換しますが、名前解決に成功しても接続できるとは限りません。Webページが開かない場合、名前解決、プロキシサーバーへの接続、接続先への通信、その後の暗号化通信など、さまざまな段階に原因がある可能性があります。DNSを変更する前に、どの段階で問題が起きているかを確認します。記録に名前解決の失敗があるか、接続先アドレスが得られているか、サーバーが利用可能かを確認してください。ブラウザーの接続エラーだけで、DNSに問題があるとは判断できません。

dns-serverとsystemの意味

設定ファイルのdns-server = systemは、システムが提供するDNSの名前解決元を使う設定です。現在のネットワークと比較しやすい基本設定の例であり、すべての端末に共通する初期値を示すものではありません。システムの名前解決条件は接続先のネットワークによって変わるため、同じ設定でもWi-Fiとモバイル通信で結果が異なる場合があります。既存の設定で別の名前解決元が指定されている場合は、その理由を確認してから戻すかどうか判断してください。

名前解決サービスを指定する場合は、内容を確認でき、現在のネットワーク要件に合うアドレスと形式を使ってください。通常のDNSと暗号化DNSでは接続条件が異なり、後者ではサービスのドメイン名や証明書、DNSサービスまでの通信経路も関係します。アドレスを入力しただけで利用可能になるわけではありません。保存後、アプリがその形式を受け付けるか確認し、新しいリクエストで動作を検証してください。DNSアドレスをプロキシサーバーのアドレス欄に入力しないでください。

名前解決元を変更する前に、設定とHostを確認する

特定のドメインだけに問題がある場合は、まず現在の設定の[Host]に対応するマッピングがあるか確認します。明示的なマッピングがあると、リクエストは固定アドレスを使い続ける場合があり、名前解決元を変えても結果が変わらないことがあります。次に、ルールによってそのドメインが想定外のポリシーに振り分けられていないか確認します。ルールの適用とDNS問い合わせは別の処理です。プロキシ経由のアクセスに失敗しても、ドメインが誤ったアドレスに解決されたとは限りません。

キャッシュが残っていると、変更後の最初の検証で結果がわかりにくい場合があります。システムやアプリ、接続先のWebサイトが既存の状態を保持している可能性があります。名前解決元を切り替えても、確立済みの接続では再度名前解決されないことがあります。検証中のページを閉じてリクエストを再実行し、必要ならアプリが提供するキャッシュ削除機能を使ってから再接続してください。ログイン状態など、トラブル対処に関係のないデータを失わないよう、すべてのWebサイトデータを一律に消去することは避けてください。

IPv6、接続ネットワーク、名前解決の問題を切り分ける

接続先によってはIPv4とIPv6の両方のアドレスを提供し、現在のネットワークで両方のアドレスに同じように接続できるとは限りません。記録上は名前解決に成功しているのに、特定のアドレスファミリーへの接続が繰り返し失敗する場合に限り、関連する設定を1つずつ比較してください。関連機能を無効にすると一時的に状況が変わることはありますが、根本原因の解決を意味するわけではありません。変更前の状態を記録し、ほかのアクセスに影響がないか確認してください。

推奨する確認順序は、現在のConfigを確認し、dns-serverとHostの項目を確認して記録を調べたうえで、名前解決の条件を1つ変えて比較することです。検証中はサーバーとGlobal Routingを変更しないでください。特定のネットワークだけで失敗する場合は、そのネットワークのシステムによる名前解決と認証状態を記録します。ネットワークを切り替えても失敗する場合は、設定ファイルを確認してください。改善しなかった変更は検証後に元に戻し、一時的な試行を設定に残さないようにします。

3. On Demand：自動接続の開始条件と停止条件

On Demandは、設定した条件に応じて接続を開始する機能です。正しいルールを選んだり、サーバー情報を補ったりする機能ではありません。有効にする前に、手動接続が機能することを確認してください。利用可能なサーバーがあり、現在のConfigが使え、システムのVPN構成に必要な許可が済んでいることが前提です。手動接続に失敗する場合は、先にサーバー、DNS、ルールの問題を解決します。そうしないと、自動接続でも同じ問題が繰り返されます。

有効にするのに適した状況

指定したネットワーク環境で自動接続したいなど、利用状況に明確な条件がある場合にOn Demandを設定します。初めて設定する場合は、手動接続を検証できるまで無効にしておき、その後、単独で有効にすることをおすすめします。ここでの無効状態はトラブル対処のための基本設定であり、アプリ全体の初期状態を示すものではありません。すでに有効な端末では、現在のルールと条件を記録してください。特定のネットワーク向けに設定した例外が含まれる可能性があるため、すぐに削除しないでください。

SettingsでOn Demandを開き、現在の画面に表示される条件を1つずつ確認します。複数の条件には一致判定や優先順が関係する場合があるため、各ルールの動作と適用範囲を確認してください。ネットワーク名を条件に使う場合、その名前は照合用の情報であり、ネットワークの安全性を証明するものではありません。複数のアクセスポイントが同じ名前を使う場合もあり、名前が変わると従来の条件に一致しなくなることもあります。

システムのVPN許可とアプリのスイッチの違い

初回接続時、システムからVPN構成の追加を求められることがあります。この許可によってシステムが該当する接続を確立できますが、サーバーがインポート済みであることや、すべてのアプリ設定が完了していることを意味するものではありません。許可の手続きが中断された場合は、アプリに戻って接続状態を確認し、システムの案内に従ってください。うまくいくことを期待して構成を何度も作り直すのではなく、既存の構成とアプリの対応を確認し、管理ポリシーやほかの接続構成の影響を調べます。

On Demandを有効にした後の手動切断と、自動接続の停止は別の操作です。接続を切った直後でも、新たなネットワーク活動が条件に一致すると、システムが再接続することがあります。その結果、スイッチが勝手にオンになったように見える場合があります。まずOn Demandを一時的に無効にしてから切断し、同じ条件で比較してください。再接続しなくなる場合は、アプリの異常と決めつけず、開始条件を確認します。

開始条件を一通り検証する方法

テストでは、開始条件、接続の維持、条件から外れた後の3段階を確認します。まず接続中のネットワークと接続状態を記録し、On Demandを有効にして、条件に従ってネットワークを切り替え、通常のアクセスを1回行います。システムの接続状態とアプリの記録を確認し、想定した条件で接続が開始したことを確かめてください。次にその条件から外れ、実際の動作が設定どおりかを確認します。最初に接続できたことだけで検証を終えないでください。

ログイン認証が必要な公共Wi-Fiは、個別にテストしてください。認証が完了する前は、名前解決やサーバーへの接続が制限される場合があります。自動接続はネットワークの認証を代行しません。認証ページを表示できない場合は、操作内容を把握したうえで自動接続を一時的に無効にし、ネットワーク認証後に元の設定に戻します。認証中の失敗と、通常接続後の結果を混同しないでください。

組織の管理下にある端末では、VPNの動作がシステムポリシーによって制限される場合があります。個人端末向けの本ページの手順で、こうした制限を回避することはできません。元の状態に戻すときは、まずOn Demandを無効にし、元の条件と接続先を復元してから、手動接続を再検証します。「切断後に再接続する」「特定のネットワークだけで接続する」といった疑問は、よくある質問もご覧ください。その際はスイッチの表示だけでなく、発生時のネットワーク条件も記録してください。

4. PingとConnectivity Test：テスト結果からわかること

PingとConnectivity Testは接続条件を確認するための機能であり、実際の利用品質をすべて示すものではありません。テストに成功すれば、その時点で使用した方法による通信が成立したことは確認できます。しかし、Webページ、動画などのリクエストは、名前解決、ルール、接続先サービス、プロトコル条件が異なるため、失敗する場合があります。比較する前に、テスト方法、対象、タイムアウト条件を確認し、意味の異なる数値をそのまま比べないようにしてください。

テスト方法によって数値の意味は異なる

SettingsでPing関連の設定を開き、現在選択されているテスト方法を確認します。TCP系のテストがある場合は、主に接続先ポートへの到達状況を確認します。プロキシ経由のHTTP系テストがある場合は、プロキシのネゴシエーション、テスト先、応答の処理も関係します。測定する段階が異なるため、単位が同じでも、数値が小さいほどあらゆるアクセスに適しているとは限りません。

初期のテスト方法、テスト先、タイムアウト値は、現在のアプリに表示される内容を確認してください。本ページでは固定値を指定しません。まず現在の設定で再現できる基準を作り、テスト先に到達できない場合や、目的に合わない方法を使っている場合に限って変更します。カスタムのテスト先を使う前に、安定して利用でき、自分にアクセス権があることを確認してください。ログインや頻繁なリダイレクトが必要なページ、自動リクエストを制限するページは、汎用の接続確認先として使わないでください。

タイムアウトはすべてのリクエストの失敗を意味しない

タイムアウトは、指定時間内にテストが完了しなかったことを示します。それだけでサーバーが完全に利用不能とは判断できません。ポートに到達できない、プロトコル設定が合わない、テスト先に制限がある、テスト中にネットワークが切り替わったなどの原因が考えられます。反対に、すぐ応答が返っても、大容量のデータ転送が安定しているとは限りません。タイムアウトが発生した場合は同じ条件で再テストし、通常のリクエストも使って確認して、それぞれの結果を別に記録してください。

利用中のサーバーを比較する方法

比較の際は、接続ネットワーク、テスト方法、テスト先、ほかの設定をそろえてください。ネットワークの切り替えが安定するのを待ってから、現在利用できるサーバーを少数回ずつ繰り返しテストし、結果が継続して近いか確認します。偶然出た最小値だけで選ばないでください。テスト自体も通信を発生させます。順番を決めるために何度も連続してテストする必要はありません。また、ある時点の順位を長期的な信頼性の評価とみなさないでください。

プロトコル項目が誤っていても、「アドレスには到達できるが使えない」ことがあります。たとえばポートへの接続に成功しても、認証情報、暗号化方式、サーバー名などが正しいとは限りません。Add Serverに戻り、利用中のサービス情報と照合してください。特に、コピー時の空白、ポート、各項目の入力位置に注意します。テストを成功させるために、証明書の検証やプロトコルのセキュリティ設定を安易に無効化・変更しないでください。

テスト結果を実際のアクセスで確認する

Connectivity Testの後、検証に使うサーバーを明示的に選択し、Global Routingと現在のConfigを確認してください。テスト一覧の項目が成功しても、現在の接続先がそのサーバーに切り替わったとは限りません。一覧の順序が変わっても、切り替えが成功した証拠にはなりません。繰り返し確認できる宛先にリクエストを送り、記録で実際の経路を確認して、テスト結果と実際のアクセスを対応づけてください。

スイッチがオンなのにアクセスできない場合は、すべての項目を何度もテストするより、ネットワーク、サーバー、モード、DNS、ルールの順に確認すると原因を特定しやすくなります。詳しい手順は接続スイッチがオンなのにアクセスできないときの確認リストをご覧ください。状況を共有する際は、テスト方法と失敗した段階を記載してください。タイムアウト画面だけでは、テスト先の問題をサーバーの問題と誤認するおそれがあります。

5. LogとData：リクエスト記録、通信量、プライバシー

Logは発生したことを確認するため、Dataはアプリの集計対象のデータ変化を把握するために使います。それぞれ役割が異なります。接続スイッチがオンでも、接続を試みたことがわかるだけで、すべてのリクエストが想定どおり処理されたとは限りません。問題が起きたときは、再現できるリクエストを1つ行い、発生時刻、接続先ドメイン、適用されたポリシー、エラー情報を結び付けて確認します。関係がありそうな行を探すために、大量の過去ログをまとめて確認するのは避けてください。

ログの詳細度を選ぶ

SettingsでLog関連の項目と現在の記録レベルを確認します。詳細度を選べる場合、普段は問題を把握できる程度のレベルにします。具体的な問題を調べるときだけ、一時的に詳細度を上げてください。現在選択されている項目が、その端末での実際の状態です。本ページでは特定のレベルを初期値とは定めません。詳細なログは保存容量や処理負荷を増やす可能性があります。調査後は元の設定に戻し、必要に応じて記録を削除してください。

再現テストの前に時刻を記録し、今回の調査に関係のない古い記録があれば必要に応じて整理します。その後、接続先を1つだけ開いてください。名前解決が行われたか、アドレスが取得されたか、ポリシーが選択されたか、接続が始まったか、どの段階で失敗したかを順に確認します。並行して発生した別々のリクエストが記録上で隣接する場合があります。隣り合っているだけで同じ接続の記録とは判断せず、接続先、時刻、アプリが表示する関連情報を照合してください。

ルールの適用状況で設定を確認する

特定のドメインをPROXYに通したいのに記録にDIRECTと表示される場合は、Global RoutingがConfigになっているか、ルールの順序と現在のファイルが正しいかを確認します。以下の例は「指定したドメインを優先的にプロキシ経由にし、それ以外は直接接続する」設定です。ルールは記述順に判定され、FINALは末尾に置きます。この例は適用ルールの仕組みを説明するもので、既存の設定を上書きする指示ではありません。編集後にリクエストを再実行してください。既存の接続ではルールがすぐに再判定されない場合があります。

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

前に記述された範囲の広いルールが対象に一致すると、後のルールがより具体的でも自動的に優先されるわけではありません。新しく追加した2行だけでなく、ルール一覧全体を確認してください。DOMAIN、DOMAIN-SUFFIX、IP-CIDRはそれぞれ異なる対象に一致します。また、DNSで得られるアドレスは元のドメイン名と同じものではありません。ルールの基本はルールキーワードとマッチ順序をご覧ください。

Dataの数値をそのまま請求額として扱えない理由

Dataを確認するときは、画面に表示されている数値が現在のセッション、特定の項目、累計のどれにあたるかを確認し、リセット履歴も調べてください。アプリの統計とサービス提供元の請求では、集計期間や計算方法が異なる場合があります。プロトコルのオーバーヘッド、集計範囲、対象期間にも違いがあり得ます。数値が完全に一致しなくても、ただちに異常とは限りません。まず比較する期間をそろえ、利用中のサービスの通信量に関する説明を確認してください。

接続後に少量のデータが変化しても、接続の維持、名前解決、ほかのアプリのリクエストなど、通常の通信が原因である可能性があります。カウンターが増えただけで、特定の宛先との通信が続いているとは判断できません。発生元を調べる場合は、リクエスト記録と照合してください。統計をリセットする前に、元の数値と時刻を記録します。リセットは新たな観察の開始点を作るためのもので、発生済みのサービス利用量を変えたり、接続の問題を解決したりするものではありません。

エクスポートや共有の前に確認すること

ログにはアクセス先ドメイン、サーバーアドレス、リクエストパス、認証に関する情報が含まれる場合があります。サブスクリプション情報にも個人を識別できる情報が含まれることがあります。共有する前に必要な部分だけを抜き出し、パスワード、サブスクリプションURL全体、トークン、個人を特定できる情報を削除してください。目立つ一行だけを隠し、別の場所に同じ情報を残さないよう注意します。失敗した段階と必要最小限の前後関係で説明できる場合、ログ全体を公開する必要はありません。

有効な記録であれば、いつ、どのネットワークで、どのモードを使い、どのような結果になったかがわかります。原因を特定したら一時的に詳細度を上げた記録を終了し、必要に応じてエクスポートした複製を削除して、統計の対象範囲を元に戻してください。次に問題が起きた場合も、同じ方法で必要最小限の再現資料を集めると、機密情報を含む大量の過去記録を長期間保存するより判断しやすくなります。

6. Widget：ショートカット、状態の更新、システムの制約

Widgetは、システムで許可された範囲でショートカットや状態を表示する機能です。アプリ内の設定すべてを代替するものではありません。状態がいつ更新されるか、どの操作を利用できるかは、アプリが提供するWidgetとシステムの仕組みによります。設定する前にShadowrocketで手動接続を確認し、システムで利用できるWidgetを追加してください。Widgetが表示されたことだけで、サーバーのインポート、設定ファイルの選択、システムの許可が完了したとは判断できません。

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

まずHomeを開き、選択中のサーバーと接続状態を確認し、Configで有効なファイルを確認します。ルールで通信を振り分ける場合は、Global RoutingがConfigになっていることも確認してください。次にSettingsで、現在利用できるWidget関連の項目を確認します。端末で実際に確認できる項目だけを変更してください。本ページではWidgetの数やサイズ、ボタンの配置を固定せず、特定の表示をすべての端末に共通する初期状態ともみなしません。

システムのWidget追加画面でShadowrocketを検索し、現在利用できるスタイルを選びます。追加画面に表示されない場合は、アプリを初回起動済みか確認し、システムの現在の手順に沿って追加画面を確認してください。システム要件はApp Storeの記載に従ってください。現在の画面にないスタイルを探すために、アプリのデータをすべてリセットしないでください。まずアプリに戻り、基本機能が正常か確認します。

表示状態と実際の接続を照合する

Widgetには前回更新時の状態が表示される場合があり、アプリ内のリアルタイム表示と完全に同期するとは限りません。状態がすぐに変わらない場合はアプリを開き、実際のリクエストで確認してください。システムの接続表示も確認材料の1つにすぎません。特定の宛先にどのルールが適用されたかや、サーバーからすべての宛先にアクセスできるかはわかりません。Widget、アプリ、リクエスト記録はそれぞれ分けて確認してください。

ショートカットとOn Demandの連動

ショートカットで切断した後に再接続する場合は、まずOn Demandを確認してください。Widgetの操作と自動接続ルールが続けて実行されることがあり、最後の状態を直前のタップだけで説明できない場合があります。自動接続を一時停止する場合は、先にアプリで自動接続の条件を処理してから切断してください。続けて何度もタップすると操作が重なり、結果がわかりにくくなります。各操作の後は状態が落ち着くまで待ってから次に進んでください。

画面がロック中の場合、システムがバックグラウンド動作を制限している場合、または追加の確認が必要な場合は、ショートカットの操作がアプリ内の操作と異なる手順で完了することがあります。システムの実際の案内に従ってください。バックグラウンド許可、低電力モード、更新設定をすべて変更する必要があるとは限りません。特定のシステム制限が現在の機能に影響していると再現できた場合に限って、1項目ずつ比較し、検証後に不要な変更を元に戻してください。

表示内容と端末のプライバシー

Widgetを他人から見えやすい場所に置くと、表示名からサーバーの用途や個人の利用傾向がわかることがあります。識別しやすく、個人情報を含みすぎない名前を付けると、選択ミスや情報の露出を減らせます。パスワード、サブスクリプショントークン、サービスアドレス全体を名前に含めないでください。名前は識別用です。サーバーの認証情報は変わらず、名前からプロトコル設定の正しさを判断することもできません。

まずアプリ内の操作を安定させ、必要なショートカットだけを残すことをおすすめします。システムのWidgetを削除しても、通常はアプリ内のサーバーや設定が削除されるわけではありませんが、実際に削除する前に対象を確認してください。Widgetだけで問題が起きる場合は、まずアプリ内で同じ操作を試します。アプリ内でも失敗する場合は接続のトラブル対処に進み、Widgetの配置を変更し続けないでください。これにより、システムの表示上の問題とネットワーク処理の問題を切り分けられます。

7. iCloud同期：データの範囲、競合、復元の順序

iCloud関連の機能は、現在サポートされている範囲でアプリのデータを保存・同期するためのものです。すべての動作状態が自動で複製されるわけではありません。サーバー項目、設定ファイル、アプリの設定、システムのVPN許可はそれぞれ別のデータです。同期に対応する内容は、現在のアプリに表示される機能と説明を確認してください。初めて使う前に、利用可能なローカルコピーを保存し、同期の方向がわからないまま唯一の設定を上書きしないようにします。

同期、インポート、購入済みアプリの復元を区別する

App Storeでの購入済みアプリの復元は、アプリを入手する権利を復元するものであり、サーバーや設定を復元するものではありません。元のApple Accountでアプリを再入手した後、ローカルデータが残っているか確認してから復元方法を決めてください。購入手順は機種変更と購入済みアプリの復元方法をご覧ください。購入に関する対応状況はApp Storeの記載に従ってください。ある端末にインストール済みだからといって、ほかの端末にも同じデータがあるとは限りません。

同期は複数の場所にあるデータを更新する仕組みであり、インポートは選択した内容を現在のアプリに取り込む操作です。両者は同じではありません。Import from Cloud JSONが表示された場合は、その項目が求める形式を選択してください。一般的な設定テキストやサブスクリプションURLを同じ種類のファイルとして扱わないでください。インポートの前に、データの提供元、種類、保存先を確認します。操作後は重複した項目がないか、実際に選択中の項目が正しいか確認してください。

初期状態と有効にする条件

iCloudスイッチの状態は、端末のシステム設定、アプリの設定、復元履歴によって異なる場合があります。本ページでは統一された初期状態を示しません。まず1台の端末でデータが使えることを確認してから、必要に応じて同期を有効にしてください。端末が1台だけで同期の必要がなければ、現在の方法を維持すれば十分です。有効にする前に、システムでShadowrocketのiCloud機能が許可されていることと、アカウントやストレージの状態を確認してください。

同期後すぐにローカルコピーを削除して、クラウドに保存されたか確認する方法は避けてください。より安全な方法は、利用条件を満たした別の端末でデータを確認し、ファイルの内容、項目数、必要なフィールドを照合することです。同期完了の表示だけでは、実際の接続を確認できません。その端末でシステムの許可、サーバーの選択、ネットワーク環境も個別に確認してください。

複数の端末で編集内容が競合した場合

重要な設定を2台の端末で同時に編集し、システムが正しく自動統合することを期待しないでください。通信の遅延やオフラインでの編集によって、異なる複製が別々のタイミングで同期される場合があります。変更時刻が新しいことだけで、内容が適切とは限りません。編集を行う端末を1台決め、コピーを保存して変更を検証してから、もう一方の端末を確認してください。差異があっても、内容を比較する前に一方で全データを上書きしないでください。

サブスクリプションの更新とクラウド同期は別

サブスクリプションの更新では、利用者が用意したサブスクリプション元から内容を読み込みます。iCloud同期は、アプリが対応するデータを扱います。ローカルの設定ファイルが同期済みでも、サブスクリプションが更新済みとは限りません。サブスクリプションの更新に成功しても、別の端末に最新の複製が届いたとは限りません。トラブル対処では、この2種類の操作を分けて記録し、「更新後に項目が変わった」ことをクラウド上書きの結果と誤認しないようにしてください。残しておきたいローカルのメモや編集内容が更新操作に影響されるかも、あらかじめ確認します。

エクスポートしたデータにはサーバーの認証情報が含まれる場合があるため、保存・共有時は機密情報として扱ってください。削除する前に、操作対象がローカルコピーか同期データかを確認します。削除が現在の端末だけに反映されると思い込まないでください。復元は、アプリの入手、データの復元、項目の確認、設定ファイルの選択、システムの許可、自動接続の検証、最後にOn Demandの再開という順序で行います。この順序なら、データの復元が終わる前に自動接続が問題を覆い隠すのを防ぎ、原因を特定しやすくなります。

8. Proxyポート：ローカル待ち受け、アクセス範囲、復元確認

Proxyポートの設定では、まず2種類のアドレスを区別してください。サーバー項目にある接続先のリモートポートと、端末上でプロキシの入口を提供するためのローカル待ち受けポートです。前者は利用者が用意したサービス情報、後者は現在の端末での接続設定に属します。ローカル待ち受けポートを変更しても、リモートサーバーのポートの誤入力や認証情報は修正されません。トラブル対処を始める前に、どちらの項目を編集しているか確認し、同じ番号をすべての欄に入力しないようにしてください。

ローカルポートを変更する必要がある場合

通常のシステムVPN接続では、「最適化」のためだけにローカルProxyポートを変更しないでください。アプリが提供するローカルプロキシを入口として使う必要がある場合、または待ち受けポートの競合が確認された場合に限り、関連する設定を確認します。実際の設定は、現在のアプリに表示されるプロトコル、待ち受けアドレス、ポートを基準にしてください。本ページでは固定の初期ポートを指定しません。画面にない機能を、別の資料をもとに設定項目として作り足さないでください。

ポートには有効な数値を指定し、接続側の設定と一致させてください。HTTPとSOCKS5は異なる接続方式です。どちらもプロキシだからといって設定を入れ替えることはできません。接続が拒否された場合は、待ち受けが開始しているか、アドレスとポートが正しいか、選択したプロトコルが一致しているかを確認し、その後でリモート接続の経路を調べます。リクエストがまだローカルプロキシの入口に到達していない可能性があるため、最初にDNSを変更するのは避けてください。

ローカルアドレスとLANアドレスの違い

127.0.0.1は接続を開始した端末自身を指します。別の端末でこのアドレスを指定しても、Shadowrocketが動作している端末には接続できません。端末間で接続するには、アプリで該当するアクセス機能が提供され、有効になっていることを確認し、正しいLANアドレスを使って、両方の端末が相互に通信できるか調べてください。アクセスポイント間の通信制限、異なるサブネット、端末のスリープなどにより、ポートに接続できない場合があります。

アクセス範囲を広げると、その入口を利用できる相手も増えます。1回のテストのために広い範囲を長期間許可しないでください。アプリにアクセス制限や認証の項目がある場合は、実際の用途に合わせて設定します。入口を共有する必要がなければ、ローカル端末のみに制限し、拡張アクセス機能を無効にしておくことをおすすめします。これは安全な確認のための基本設定であり、アプリの初期状態を示すものではありません。管理できないネットワークにローカルプロキシの入口を公開しないでください。

転送の繰り返しや誤ったループを防ぐ

ローカルプロキシの入口を、現在の経路のリモートサーバーとして再利用しないでください。転送が繰り返されたり、接続ループが発生したりする場合があります。変更後に接続記録が大量に繰り返される、タイムアウトが続く、異常な通信量が発生するといった場合は、テストをただちに停止し、元のサーバー選択と待ち受け設定に戻してから参照関係を確認してください。診断では、ポートを次々と変えるより、「リクエストがどこから入り、どのポリシーを経由し、最終的にどこへ接続するか」を整理することが有効です。

ルールファイルは別途検証する必要があります。特定のドメインだけをプロキシ経由にしたい場合は、ポート設定に頼らず、ConfigモードやDOMAIN-SUFFIXなどのルールを確認してください。具体例は特定のWebサイトだけをプロキシ経由にするルール設定をご覧ください。ローカル入口に接続できるかどうかと、接続先にPROXYが適用されるかどうかは別の段階です。テスト結果も分けて記録してください。

設定変更後の確認と元に戻す手順

Settingsの変更後は、まず直接影響を受ける機能を確認し、次に普段のアクセスに影響がないか検証します。変更前後の値、ネットワーク条件、結果を記録してください。明確な改善がなかった変更は元に戻します。同期と自動接続の両方が関係する場合は、まずローカル設定を安定させ、次に同期内容を確認し、最後にOn Demandを有効にしてください。設定が変化している途中の自動接続を、最終確認の結果と取り違えずに済みます。

引き続き原因を調べる場合は、本ページの影響範囲、DNS、テスト、ログの順に確認し、クイックスタートガイドで最小限の接続手順をやり直してください。購入、復元、端末要件に関する問題は、ダウンロード案内をご覧ください。アカウントの問題をネットワーク設定の変更で解決しようとしないでください。ガイドの推奨設定は、現在のアプリ画面と照らし合わせて利用してください。変更の目的を説明でき、結果を再現して確認でき、元に戻す方法が残されていれば、設定変更は完了です。