Settings設定ガイド

01 / Scope

設定の範囲と現在値の確認

Settings、Config、システムの許可を区別する

接続動作を決めるのはSettingsだけではありません。確認項目は大きく3つに分けられます。アプリ側ではテスト方法、ログ、一部の共通設定を管理します。Configにはルールや設定ファイルの関連パラメータが含まれます。システム側ではVPN構成の許可、ネットワークへのアクセス条件、iCloudの利用可否が決まります。サーバー項目には、アドレス、ポート、プロトコルも設定されています。問題が起きたら、まずどの層に該当するかを見極めてから、対応する設定画面を確認してください。Settingsを変更してもサーバーアドレスの入力ミスは直りません。Configを切り替えても、システムの確認画面での許可に代わるものではありません。

設定を変えていないように見えても、実際のリクエスト経路が異なる場合があります。たとえば、Homeで選択中のサーバー、Global RoutingのConfigからProxyへの切り替え、Wi-Fiからモバイル通信への切り替えによって、テスト条件が変わります。各章を確認する前に、現在のネットワーク、選択中のサーバー、Global Routingのモード、現在のConfig名を記録してください。この4項目が結果を比較するための基本情報です。記録がないまま「昨日は使えたのに今日は使えない」と考えても、設定、ネットワーク、接続先のどれが変わったのか判断しにくくなります。

初期値・現在値・推奨値はそれぞれ異なる

初期値は、特定のインストール環境でまだ変更されていない設定値です。現在値は画面に表示されている値や設定ファイルに保存された値、有効値は実際のリクエストで使われる動作を指します。バックアップや同期から復元すると、現在値が以前の端末の設定になり、初期値と一致しない場合があります。変更可能な項目は、まず「現在使えている値を維持する」ことを推奨します。マニュアルと比較するためだけに、アプリ全体をリセットする必要はありません。値が自動、空欄、継承と表示されていても、すぐに無効だと判断せず、Configやシステムに設定を委ねる状態か確認してください。

元に戻せる形で変更を記録する

変更前に現在の設定を複製し、非公開のメモに項目名、変更前後の値、変更理由、検証結果を記録してください。設定の複製にはサーバーの認証情報が含まれる場合があります。公開メモには保存しないでください。一度に変更するのは1項目だけにします。たとえば、DNSとテスト方法を同時に変更せず、先にテスト方法だけを変えます。変更を保存したら、必要に応じて接続が中断してもよい時間帯に切断してから再接続し、同じ接続先へのリクエストを再実行してください。改善しなければ、変更を重ねず元の値に戻します。こうすることで、原因と結果の関係を追跡できます。

検証では「設定が保存されたこと」と「設定が実際に使われたこと」を分けて考えてください。前の画面に戻れたのは編集が完了したというだけで、既存の接続が再構築されたことを示すものではありません。ブラウザーでページが表示されても、キャッシュによる可能性があります。重要な変更を確認する際は、新しいリクエストを実行し、Logで該当する時刻の記録を照合してください。システムの許可に関わる場合は、アプリのスイッチの色だけでなく、システムのVPN状態も確認します。初期値を確認するためにアプリを削除する必要はありません。削除するとローカルの設定や記録にも影響する場合があり、以前の利用可能な状態に戻る保証もありません。

特定の接続先だけで問題が起きる場合は、まずその接続先のルールを確認してください。すべての接続先で失敗する場合は、サーバー、ネットワーク、名前解決を確認します。購入ページやアプリの正規性が不明な場合は、まず正規品を確認する3つのポイントをご覧ください。設定を参照しても購入条件は変わらず、手元にあるサーバー情報の正確性を補うこともできません。症状別の簡潔な回答はQ&Aにまとめています。まず問題の種類を絞り込んでから、このページで項目ごとに確認してください。

02 / DNS

DNSの名前解決とルールの関係

接続先ドメインとサーバードメインを分けて考える

DNSはドメイン名を接続に必要なアドレスへ変換します。Proxy接続では、少なくとも2種類の名前解決が必要になる場合があります。まずサーバードメインに対応するアドレスを調べ、その後、接続先ドメインも該当する経路で解決します。前者に失敗するとProxy接続を確立できない場合があります。後者に失敗すると、サーバーテストには応答があるのに特定のWebサイトを開けないことがあります。そのため「DNSを変更する」ことは、あらゆる接続エラーに有効な対処ではありません。どのドメインで失敗したのか、接続の確立前と確立後のどちらで名前解決が行われたのかを確認してください。

SettingsのDNS関連項目は、現在のConfigの内容と合わせて確認してください。使用中のConfigにDNS指定や関連する動作パラメータがある場合、1つの画面だけを見て最終的な名前解決方法を判断することはできません。初期状態は現在の画面と有効な設定に従います。すべてのネットワークに使える共通のパブリックアドレスを指定することはありません。まず現在利用できている設定を維持し、Configで明示された内容に従ってください。Logに名前解決エラー、不正なアドレス、想定外の解決経路が記録されている場合に限り、該当項目を確認します。

入力形式を確認し、アドレスとプロトコルを混同しない

DNS欄では、アドレス、サーバーのリスト、アプリが対応する特定の形式などを指定する場合があります。入力形式は欄の説明と実際の選択肢を確認してください。通常のアドレスとプロトコル付きの名前解決アドレスは、自由に置き換えられる文字列ではありません。入力前に、プロトコルのプレフィックスが必要か、余分な空白がないか、区切り方が正しいか、現在のネットワークからDNSサービスに到達できるかを確認します。WebページのURLをDNSアドレスとして入力しないでください。暗号化通信と表示されているだけで、現在のネットワークから利用できると決めつけることもできません。名前解決サービス自体にもネットワーク接続が必要です。

サーバーアドレスにドメイン名を使っている場合は、名前解決の依存関係にも注意してください。Proxy接続が確立する前に利用できない解析先を経由しなければならず、そのProxy接続の確立自体もサーバードメインの解析に依存する場合、起動時に循環依存が発生する可能性があります。このような問題では、まず元のDNS設定に戻し、接続確立前にサーバードメインを正しく解決できることを確認してください。その後、接続先ドメインの解決経路を個別に検証します。一度確認したアドレスをサーバー項目に恒久的に設定するのは避けてください。接続先のアドレスは変わることがあり、プロトコルによっては正しいホスト名の検証も必要です。

DNSとルール判定の順序が与える影響

ドメイン系ルールとアドレス系ルールでは、判定対象が異なります。DOMAIN-SUFFIXはドメインのサフィックスに直接一致します。一方、GEOIPやIP-CIDRなどのルールはアドレスに関係します。アドレス系ルールの一致を判断する処理では、名前解決が必要になる場合があります。特定のドメインに指定したポリシーを適用したい場合は、DNSの設定をいくつも追加するより、具体的なドメインルールを広範なアドレス判定より前に配置するのが一般的です。ルールは上から順に処理されます。先に一致した場合、後続の例は同じリクエストの選択に使われません。

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

以下はルール間の関係を示す例で、接続設定の全体ではありません。example.comとexample.orgは説明用のドメインで、PROXYとDIRECTはポリシーのキーワードです。使用する前に、現在のConfigが該当するポリシーに対応していることを確認し、Global RoutingをConfigモードにして検証してください。DNSサーバーは指定していないため、この数行だけでは名前解決のリクエストがどの経路を通るかは判断できません。ルールの一致対象について詳しくはルール構文とマッチ順序の解説をご覧ください。

名前解決の検証と元に戻す方法

同じネットワーク、同じサーバーを使い、問題を安定して再現できる接続先にリクエストを送信します。実行時刻を記録してからLogを確認し、名前解決のタイムアウト、名前解決の失敗、その後の接続失敗がないか調べてください。名前解決に成功して接続がタイムアウトする場合は、アドレスへの到達性を確認します。名前解決自体に失敗する場合は、解析先とネットワーク条件を確認してください。DNSを変更しても古いキャッシュがすぐに消えるとは限りません。再テストでは新しい接続を使い、キャッシュ済みページを成功の証拠にしないでください。明確な改善がなければ元の値に戻し、複数の解析先を続けて入れ替えないようにします。

03 / On Demand

On Demandの自動接続条件

自動接続の実行は、接続の成功を保証しない

On Demandは、設定した条件に基づいてシステムにVPN接続を要求する機能です。「いつ接続を試みるか」を設定するものであり、サーバーの有効性や、すべてのアプリ通信が常に接続できることを保証するものではありません。有効にする前に、まず手動で接続を完了してください。Homeの既定サーバー、Global Routing、Configが意図した状態であることを確認し、Connectivity Testと実際の接続先へのアクセスも検証します。手動接続に失敗していると、自動接続は同じ失敗を繰り返し、問題が頻発しているように見えるだけで、アドレスや認証の誤りは解決しません。

スイッチの初期状態、利用できる条件、既存のルールは現在の画面で確認してください。特に以前の端末から復元した場合は、過去の条件が引き継がれていないか確認します。まず手動接続のままにして、接続が安定してから用途に応じて自動接続を有効にすることを推奨します。自動接続を使う場合は、各条件を読み、ネットワーク環境、リクエストによる起動、その他の設定範囲のどれを対象にするか確認してください。条件名だけであらゆるネットワークに適用されると判断したり、リストの後ろにある項目が前の動作を必ず上書きすると考えたりしないでください。

ネットワーク切り替え時のテストを計画する

自動接続は、Wi-Fiとモバイル通信の切り替え、アクセスポイントからの離脱、端末のスリープ解除後などで挙動が変わる場合があります。テスト前に、指定したネットワークでは現在の状態を維持し、他の許可済みネットワークでは接続を試みる、といった期待する結果を明確にしてください。一度に切り替える条件は1つだけにし、システムのネットワーク変更が完了してから、システムのVPN状態とアプリの記録を確認します。切り替え直後に短時間接続が途切れても、それだけでルールの誤りとは限りません。発生時刻とその後の状態を合わせて判断してください。ネットワークを何度も切り替えると複数の状態変化が重なり、原因を特定しにくくなります。

切断後に再接続が試みられる理由

手動で切断した後、システムが再び接続を試みる場合は、まずOn Demandが有効かどうか、現在の条件が引き続き成立しているかを確認してください。手動切断と自動ルールは別々の制御方法です。手動で切断しても、自動ルールが必ず解除されるわけではありません。一時的に自動動作を止めるには、まずアプリで該当する自動接続設定を無効にしてから切断し、システムの状態を確認します。それでも繰り返し動作する場合は、システムで実際に使われているVPN構成を確認してください。別の保存済み構成の動作を、現在編集中の画面が原因だと誤認しないようにします。

端末には複数のVPN構成が保存されている場合があります。アプリ画面で選択されている構成と、システムで実際に使われている構成が一致しているか確認してください。すべての構成をすぐに削除するのではなく、名前、登録元、現在の状態を確認します。システムの許可画面でアプリに構成作成を許可しても、自動接続条件の設定がすべて完了したことにはなりません。組織管理下の端末では、ネットワークやVPNの動作がシステム管理ポリシーの影響を受ける場合があります。アプリ内のスイッチではシステム側の要件を代替できません。端末の管理ルールに従って対応してください。

ネットワークログインと復旧時の対応

ネットワークのログインページを先に開く必要があるWi-Fiでは、まだ通常のアクセスができない場合があります。ネットワークの認証を正規の手順で完了するまでは、自動接続が正常に起動してもサーバーに到達できないことがあります。その場合は自動接続の試行を一時停止し、システムで認められた手順でネットワークにログインしてから、元の条件に戻して再テストしてください。まだネットワークに接続できていない段階で、サーバーのプロトコルパラメータを何度も変更しないでください。問題はProxy接続の前に発生しており、プロトコルを変更すると新たな要因が増えるだけです。

自動ルールを設定した後は、条件に入るとき、条件から外れるとき、手動で一時停止するときの3つを検証し、元の設定も保存してください。システム状態、起動記録、実際のアクセス結果が互いに説明できることを確認します。ルールが複雑になった場合は、まず条件を最小限に戻し、一つずつ追加してください。追加するたびにネットワーク切り替えのテストを行います。自動接続とは別の初回接続手順は既定サーバーの選択とConnectivity Testをご覧ください。On Demandの確認のために、インポート手順全体をやり直す必要はありません。

04 / Ping

PingとConnectivity Test

テスト結果が示すのは、該当するテスト経路の状態

Ping関連の設定は、リストテストで使う方法、接続先、待機条件などに影響します。実際の項目は現在の画面に表示されている選択肢で確認してください。リストに表示される応答時間はネットワーク品質全体の評価ではなく、Webページの表示にかかる時間とも異なります。1回のリクエストには、名前解決、接続確立、プロトコルのネゴシエーション、接続先での処理、データ転送など複数の段階が含まれる場合があります。テスト方法によって確認する段階が異なるため、異なる方法で得た数値をそのまま比較できません。最小の数値だけを見て、あらゆる用途に最適なサーバーだと判断することもできません。

テスト方法とタイムアウトの初期値は、現在の設定で確認してください。同期からの復元や過去の手動変更によって、値が変わっている場合があります。まず既存のテストパラメータを維持し、安定して利用できるサーバーを1つ選んで基準を取ってから、項目を一つずつ変更して差を確認します。現在の画面でTCPなどの接続テストが選べる場合、主に設定された待機時間内に該当する接続を確立できるかを確認します。接続先へのリクエストを必要とするテストでは、接続先自体の利用可否も結果に影響します。テストが失敗しても、サーバー項目が無効とは限りません。接続先側の問題である可能性もあります。

接続先、ネットワーク、時間帯をそろえて比較する

比較の前に、テスト先、現在のネットワーク、テスト方法、サーバー項目を固定し、できるだけ近い時間内に実行してください。Wi-Fiからモバイル通信に切り替えた後では、比較条件が変わっています。日中の結果と負荷の高い時間帯の結果を単純に比較しても、設定が改善したかは判断しにくくなります。少数回のテストを繰り返して、結果が安定しているか確認できますが、高頻度の連続リクエストは必要ありません。テストでも通信と接続が発生します。過度に実行すると使用中の接続に影響したり、短時間の変動を大きな問題と誤認したりする可能性があります。

タイムアウトは、設定された待機時間内にテストが完了しなかったことを示します。アドレスに恒久的に到達できないという意味ではありません。待機時間が短すぎると、遅くても利用できる経路を除外する場合があります。長すぎると、失敗した項目の結果が返るまで時間がかかります。このガイドでは共通の秒数を指定せず、まず画面に表示されている値を使い、実際のテスト目的に応じて調整することを推奨します。複数項目がタイムアウトする場合は、サーバー情報を書き換える前に、端末のネットワークとテスト先を確認してください。1項目だけ異常な場合は、そのアドレス、ポート、認証情報、サーバーの状態を確認します。

リストテストと実際の接続を分けて検証する

リストに応答が表示されても、その項目が既定サーバーとして選択されたとは限りません。まずHomeで使うサーバーを選び、選択状態を確認してから、Global Routingのモードを確認してください。その後接続し、Connectivity Testを実行して、問題を安定して再現できる接続先にアクセスします。これにより「項目のテストができる」「現在の選択が正しい」「接続経路が利用できる」の3点をそれぞれ確認できます。最初の確認しか行わないと、選択されていないサーバーのテスト結果を、現在の接続状態と誤認しやすくなります。

応答は正常だが、実際のアクセスに失敗する

結果に差がある場合は、まずテストでどの段階まで確認したかを調べてください。サーバーポートまでしか確認していない場合、認証情報が誤っている可能性があります。テスト先にアクセスできるのに実際の接続先で失敗する場合は、別のルールが適用されている可能性があります。次にDNS、接続先ドメインのポリシー、Logに記録されたエラーの段階を確認します。応答時間だけを見てサーバーを何度も切り替えないでください。接続先の出口と接続状態が同時に変わり、元の問題を再現できなくなることがあります。テスト数値を増やすより、問題を再現できる条件を記録する方が役立ちます。

VMess、VLESS、Trojan、Hysteria2などのプロトコルでは、ポートに接続できても、すべてのプロトコルパラメータが一致するとは限りません。項目によってはトランスポート層、ホスト名の検証、その他のサーバー側の指定も関係します。手元にあるサーバー情報と項目ごとに照合してください。各プロトコルの項目については対応プロトコルとAdd Serverの項目概要をご覧ください。このページではテスト設定のみを説明します。テスト数値に基づくサービスの評価や、サーバーの推奨は行いません。

05 / Log

Logの記録とトラブル対処

時刻を記録してからリクエストを1回再現する

Logでは接続中のイベントやエラーを照合できますが、記録された情報がすべて障害を意味するわけではありません。調査を始める前に、端末の時刻、現在のネットワーク、既定サーバー、Global Routing、現在のConfigを記録してください。その後、接続して特定の接続先を開くなど、操作を1つだけ実行します。近い時刻の記録を探し、名前解決、接続確立、プロトコル処理、接続先へのアクセスの順に確認してください。ログ全体を区別せずに見ると、以前の試行でのエラーと今回の成功を混同しやすくなります。

記録のスイッチ、詳細度、保存方法は現在の画面で確認してください。すべての環境で同じ内容が初期状態から保存されるとは限りません。通常は基本的な診断に必要な現在の設定を維持し、トラブル対処時に限って利用可能な詳細記録を一時的に増やし、完了後に元に戻すことを推奨します。詳細な記録にはより多くのアクセス情報が含まれる可能性があり、保存容量と確認の負担も増えます。画面に存在しないログレベルや書き出し項目を探す必要はありません。実際に利用できる機能を確認してください。

失敗した段階から問題の範囲を絞る

ログの最初に名前解決エラーがある場合は、DNSと該当ドメインを確認します。名前解決の結果があるのに接続待ちが終了する場合は、アドレス、ポート、ネットワークの到達性を確認してください。接続の確立後に認証またはプロトコル関連のエラーが発生する場合は、サーバー項目を照合します。接続先がエラーレスポンスを返している場合は、接続先サービス自体も確認してください。これはすべてのログを機械的に分類する方法ではなく、無関係な変更を減らすための手順です。名前解決の証拠がないのにプロトコルパラメータを一度に変更したり、認証エラーがあるのにDNSを繰り返し入れ替えたりすると、実際の問題から遠ざかる可能性があります。

接続の中断は、ネットワークの切り替えや手動切断が原因の場合もあります。ログの時刻を操作した時刻と照らし合わせ、Wi-Fiからモバイル通信への切り替え、On Demandの有効化、サーバーの切り替えの後に発生したか確認してください。同じ操作で毎回似たエラーが出る場合は、再現性の高い根拠になります。一度だけ発生し、その後復旧した記録は、まず経過観察のために残しておけばよく、すぐに設定をリセットする必要はありません。安定して再現できない問題では、無関係な変更を重ねて現象を見えなくするのではなく、発生条件を記録してください。

ルールの一致を確認し、接続先とポリシーを混同しない

Configモードを使っている場合、Logにポリシーや一致情報が表示されるなら、実際の接続先に想定したポリシーが適用されているか確認してください。ドメインルールは、先に一致する可能性がある広範なルールより前に記述し、FINALはフォールバックの位置に配置します。アプリに表示される接続先ドメイン、実際の接続アドレス、ポリシー名はそれぞれ別の項目です。見覚えのあるドメイン名が1つ表示されただけで、Proxy経由だと判断することはできません。ProxyまたはDirectモードを使っている場合は、ルールが「反映されていない」と判断する前に、そのモードの動作を確認してください。

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

この例では、example.com自体は先にDOMAINに一致し、DIRECTを使用します。そのサブドメインは後続のDOMAIN-SUFFIXに一致する場合があります。これは具体的な条件が優先される例であり、関連するルールが2つあるからといって必ず競合するわけではありません。変更するときは、変えたいルールだけを調整し、同じ接続先で再検証してください。2行の順序を入れ替えると、ルートドメインが先にサフィックスルールに一致する可能性があります。ルールが「存在する」かどうかだけでなく、順序と実際のリクエスト名も確認してください。

保存や共有の前に機密情報を取り除く

ログにはサーバーアドレス、接続先ドメイン、ローカルネットワーク情報、サブスクリプションURL、認証情報などが含まれる場合があります。公開の場で相談する前に、サブスクリプションURL全体とクエリパラメータ、認証情報、個人を特定できるデータ、不要なアクセス記録を削除してください。サーバーの表示名を隠すだけでは不十分なことがあります。後続の行に実際のアドレスが記録されている可能性があるためです。ログ全体を送信せず、発生時刻の範囲、エラー段階、関連項目を伏せた情報、実行した操作など、再現に必要な最小限の部分を残してください。

有用な証拠を残すため、ログを整理する前に削除しないでください。必要な部分を非公開の場所に保存してから、アプリで現在利用できる方法で記録を消去します。ログの消去と設定の消去は別の操作であり、設定を復元してもログが戻るとは限りません。それぞれ別に管理してください。ログが空の場合は、記録が有効か、正しい範囲を見ているか、リクエストが実際に現在の接続を通ったかを確認します。記録がないことだけでは、リクエストの成功も失敗も判断できません。よくあるエラーをすばやく切り分けるには、Q&Aのトラブル対処カテゴリをご覧ください。

06 / Widget

Widgetとシステム状態の確認

便利な入口は、設定画面全体の確認に代わるものではない

Widgetは、システムが提供する簡易表示または操作用の入口です。利用できる種類や機能は、端末のシステムとアプリが現在提供している内容によって異なります。限られた状態を確認したり、対応する操作を実行したりする用途には便利ですが、Home、Config、Settingsのすべての項目を確認する代わりにはなりません。設定を読み込んだ直後、既定サーバーを切り替えた後、On Demandを変更した後は、まずアプリに戻って実際の選択を確認してください。Widgetに表示された文字だけでは、Config、ポリシー、サーバーが正しく切り替わったかは判断できません。

Widgetが表示されるか、どこに配置されるか、どのサイズを使うかはシステム側で管理されます。アプリ内の関連設定は、表示または読み込み可能な内容に影響する場合があります。両者を分けて確認してください。初期表示の状態は、現在追加されているWidgetとその設定によって異なり、すべての端末に共通する推奨レイアウトはありません。まずは表示項目が少なく、見分けやすい既存のWidgetを使うことを推奨します。必要な場合に限って他の入口を追加し、似た名前による古い選択の誤操作や状態の読み違いを避けてください。

表示の遅延と接続状態のずれ

システムWidgetの更新タイミングはシステムが管理しており、アプリ画面と秒単位で一致するとは限りません。アプリではすでに切断されていてもWidgetに以前の状態が残ったり、接続直後に表示が更新されなかったりする場合があります。表示に差があるときは、Widgetを何度も押して更新を試すのではなく、Shadowrocketを開いて現在の接続状態を確認し、システムのVPN状態と実際のリクエストを照合してください。接続と切断を繰り返すと新たな状態変化が発生し、単なる表示遅延が実際の接続中断に変わる可能性があります。

省電力設定、端末のロック、バックグラウンド処理、ネットワークの変化は、情報の更新タイミングに影響する場合があります。一定の更新間隔は保証されていません。Widgetの表示をすぐに更新するためだけに、システムの電源設定を長期的に変更することは推奨しません。Widgetの表示が継続して異常な場合は、まずアプリが正常に起動し、現在の状態を読み取れることを確認します。次に、Widgetで選択している項目を確認してください。システムに削除と再追加の機能がある場合は、元の配置を記録してから試せます。この操作はWidgetの表示に対するものであり、アプリの削除や接続設定のリセットは必要ありません。

選択中のサーバーと接続中のサーバーを区別する

Homeでの選択、確立済みの接続、Widgetに表示されている項目は、切り替え中に異なる状態になることがあります。項目を選択しただけで、既存の接続が新しい項目で再構築されたとは限りません。Widgetに名前が表示されていても、その項目が現在利用できるとは限りません。切り替えた後は、アプリの現在の動作を確認し、必要に応じて再接続してからConnectivity Testを実行してください。テストに失敗した場合は、Ping、DNS、Logの各章に戻って調べます。Widgetの表示設定だけに問題をすべて帰属させないでください。

名前が似たサーバー項目が複数ある場合は、自分の管理範囲で見分けやすい名前を使うことを推奨します。ただし、パスワード、サブスクリプションURL全体、その他の機密情報を名前に含めないでください。Widgetには他人から見える場所に項目名が表示される場合があります。特にロック画面に表示する場合は、プライバシーにも配慮してください。名前は項目を見分けるためのものであり、変更してもプロトコルの設定は修正されず、サーバーの機能も変わりません。テストと設定の確認は、実際の項目を対象に行ってください。

On Demandと併用する場合の注意点

Widgetから切断しても、On Demandの条件が引き続き成立していれば、システムが再接続を試みる場合があります。その場合は、Widgetのボタンが反応しなかったと考えるのではなく、自動接続の起動条件を確認してください。一時的に接続を止めるには、アプリで自動接続の条件を確認してから切断します。再び有効にする前に、元のサーバーとConfigが正しいことを確認してください。Widgetは操作の入口、自動ルールは別の制御機能です。最後のタップだけを見るのではなく、同じ検証手順の中で両方を確認してください。

Widgetをタップしても期待した操作が直接完了せず、アプリが開く場合は、現在のシステムで許可されている操作方法に従ってください。端末のロック解除、アプリの起動、システムでの確認が必要な操作もあります。すべての操作がバックグラウンドで実行されるとは限りません。初回のVPN許可は、システムの確認画面で明示的に承認してください。Widgetは動作を確認した日常操作に適しています。初回設定やトラブル対処は、必要な項目とエラー情報を確認できるアプリの全画面で行ってください。

iPhoneとiPadではWidgetの配置場所や利用できる位置が異なる場合があります。システム要件と対応状況はApp Storeの表示をご確認ください。最初から接続手順をやり直す場合は使い方ガイドに戻ってください。表示の遅延だけが問題であれば、既存のサブスクリプションを再読み込みしたり、表示更新のためにDNSやProxyポートを何度も変更したりする必要はありません。

07 / iCloud

iCloud同期と設定の復元

アプリの購入、設定の同期、システムの許可は別々に確認する

iCloud同期は、アプリが対応する範囲でデータを保存または共有する機能です。App Storeの購入履歴と同じものではありません。購入履歴では「アプリを再入手できるか」を確認します。同期では「どのアプリデータを端末間で復元できるか」を確認します。システムのVPN許可では「この端末で該当する構成を作成できるか」を確認します。同じアカウントの仕組みを使っていても、それぞれ入口と状態が異なります。機種変更後にアプリがインストールされていても、サーバー、ルール、接続の許可がすべて復元済みとは限りません。

同期のスイッチ、対象データ、現在の状態は、アプリとシステムの画面で確認してください。Config、サーバー項目、すべてのSettings、ログ、システムの許可が一式で完全に複製されるとは限りません。まず移行元の端末で同期対象を確認してから、移行先で実際に表示されている項目を一つずつ確認してください。データを個別に選択できる場合は、必要な項目だけを有効にします。「すべて同じにする」ために、すべての項目を確認せず有効にしないでください。システム側のVPN許可は、移行先の端末で改めて確認します。

有効にする前にアカウント、容量、独立したバックアップを確認する

同期を有効にする、またはトラブル対処を始める前に、システムでiCloudにサインインしていること、アプリが必要な利用条件を満たしていること、ストレージとネットワークが利用できることを確認してください。初期状態は現在の端末で確認します。以前の端末で同期が有効だったからといって、新しい端末でも同じ状態になるとは限りません。正常に使えている設定は、独立した複製を保存し、含まれる認証情報を安全に保管してください。同期は過去のバージョンを保存する機能ではなく、誤変更を必ず復元できるものでもありません。誤った設定がほかの端末にも同期された場合に備え、確実に戻せる元データを用意してください。

移行元と移行先の端末で同じ内容を同時に編集すると、名前の重複、内容の不一致、上書きの選択が発生する場合があります。対応する前に双方の編集を一時停止し、利用可能な内容が揃っている端末を基準として、もう一方の実データと比較してください。両方の端末で同じ名前の設定を続けて削除・再作成しないでください。こうした操作自体が同期される可能性があります。アプリに競合や選択の案内が表示された場合は、残す範囲を読み、どちらのデータを保持するか決めてから操作します。

サブスクリプションの更新とiCloud同期は別の機能

Subscribeの更新は、ユーザーが用意したサブスクリプションURLからデータを再取得します。iCloud同期は端末間でデータを交換します。前者はURL、認証、形式に左右され、後者はアカウント、システムの権限、同期状態に左右されます。新しい端末に項目が表示されても、サブスクリプションURLを現在更新できるとは限りません。移行元で更新できても、移行先に最新のリストが届いているとは限りません。問題が「接続先からデータを取得できない」のか「端末間でデータを転送できない」のかを確認し、2つの手順を交互に試さないでください。

移行先にサブスクリプション項目が表示されているのに更新できない場合は、iCloudを何度も切り替えるのではなく、URLが完全か、期限が切れていないか、現在のネットワークからアクセスできるかを確認してください。移行元では更新済みなのに移行先のリストが古い場合は、同期の対象範囲と状態を確認します。更新方法と失敗時の対処についてはサブスクリプションの手動・自動更新とトラブル対処をご覧ください。アクセス情報を含むサブスクリプションURLは非公開情報として保管し、公開の同期トラブル記録に含めないでください。

復元後は項目ごとに検証し、設定全体をそのまま引き継がない

復元が完了したら、まずHomeのリスト、既定サーバーの選択、Global Routing、現在のConfig、DNS関連の設定を確認してください。その後、新しい端末の利用状況にOn Demandが合っているか確認します。2台の端末でデータが同じでも、ネットワークやシステムの許可、ルーティング条件が異なる場合があります。移行元で接続先にアクセスできることだけを、移行先の復元成功の証拠にしないでください。移行先でも手動接続、Connectivity Test、実際のアクセスを個別に確認してください。

アプリを再入手する場合は、App Storeの購入済み項目または正規の商品ページから手続きしてください。手順は機種変更と購入済みアプリの復元についてをご覧ください。購入条件、システム要件、共有範囲はApp Storeの表示をご確認ください。アプリの購入を復元しても、ユーザーが管理する接続サービスは含まれず、認証情報が今後も有効であることも保証されません。復元後にデータが不足している場合は、まず現在の状態を保ったまま同期範囲と独立したバックアップを確認してください。順序立てた確認の代わりに、再インストールを繰り返さないようにします。

アカウントからサインアウトする、同期を停止する、クラウド上のデータを削除する前に、操作がこの端末、クラウド、ほかの端末のどこに影響するか確認し、残す必要があるデータを保存してください。「同期を停止する」ことが「すべての複製を削除する」ことを意味するとは限りません。また、「端末にデータが残っている」からといって、クラウドへのバックアップが成功しているとも限りません。画面の案内と実際の確認結果に基づいて操作することで、復元時の誤削除を防ぎやすくなります。

08 / Proxy

Proxyポートと最終確認

リモートポートとローカルの待ち受けポートを区別する

Add Serverのサーバーポートは、ユーザーが持つサーバー情報に基づき、リモートサービスへの接続に使います。SettingsのProxy関連ローカルポートは、端末がローカルのProxy入口を提供するときに使う待ち受け設定です。どちらも数字ですが、別の項目です。ローカルポートを変更してもリモートサービスのポートは変わらず、誤ったサーバーアドレスも修正されません。トラブル対処の前に、サーバー編集画面を見ているのか、アプリのローカルProxy設定を見ているのか確認し、誤った画面で数字を何度も試さないようにしてください。

ローカル待ち受けポートの初期値、有効・無効、アクセス可能な範囲は、現在の画面で確認してください。ローカルProxyを使う必要がない場合は、現在の状態を維持し、通常の接続のために待ち受けを追加で有効にしないことを推奨します。必要な場合は、設定したアドレス、ポート、プロトコル、アクセス範囲を記録してから、接続する側を設定してください。ポートは接続入口の一部です。待ち受けアドレスやプロトコルと合わせて確認してください。ポート番号だけでは接続方法を完全には表せず、ほかの端末からのアクセス可否も判断できません。

待ち受けアドレスとアクセス範囲のセキュリティ

端末内だけからアクセスできるアドレスと、ローカルネットワークからアクセスできるアドレスでは、公開される範囲が異なります。待ち受け範囲を広げる前に、実際の必要性、接続中のネットワークが信頼できるか、アプリにアクセス制御があるかを確認してください。ほかの端末を接続するために、すべてのネットワークからアクセスできる設定へ安易に変更しないでください。端末内でのみ使う場合は、現在の機能で設定できる最小限の範囲を選びます。共有ネットワーク上のほかの端末はユーザーが管理できない場合があります。ローカルProxyの入口は、単に「接続できる」ことだけを目的にせず、実際の用途に合わせて管理してください。

接続側の設定では、アドレスにリモートサーバーのドメイン名ではなく、待ち受けを提供する端末のアドレスを指定します。ポートはローカルの待ち受け値と一致させ、プロトコルも合わせてください。端末が別のネットワークに移ると、ローカルアドレスが変わる場合があります。以前のアドレスが使えなくなっても、必ずしもShadowrocketの問題とは限りません。トラブル対処では、まず双方が想定したネットワークに接続していること、待ち受けが有効なこと、アドレスが変わっていないことを確認してから、ポートとプロトコルを照合します。これらの条件を確認する前に、DNS、ルール、サーバー認証情報を変更しないでください。

ポートの競合と接続拒否を確認する順序

接続がすぐ拒否される、待ち続ける、接続後にプロトコルエラーになる現象は、それぞれ異なります。接続が拒否された場合は、まず待ち受けが起動しているか、アドレスとポートが正しいか確認します。待ち続ける場合は、ネットワークの到達性とアクセス範囲を確認してください。接続確立後に失敗する場合は、接続側で選択したプロトコルと認証要件を確認します。ポート競合によって待ち受けが正常に起動しない場合もありますが、一度タイムアウトしただけでは競合と判断できません。アプリの案内とLogを照合し、ポート番号を無作為に何度も変更して試すのは避けてください。

ローカルポートを変更する必要がある場合は、接続が中断してもよい時間帯に操作してください。変更を保存した後、すべての接続側の設定も更新します。既存の接続が新しいポートに自動で切り替わらない場合があるため、テスト接続を新たに確立してください。数値を選ぶ前に、入力欄で指定できる範囲と、ほかのローカル機能で使用中でないか確認します。このガイドでは一律に指定するポート番号はありません。変更しても改善しない場合は、待ち受け設定と接続側の設定の両方を元に戻し、片方だけが変更された状態を残さないようにしてください。

Proxy入口だけでなくルーティングとConfigも確認する

ローカル入口でリクエストを受け付けられても、その後のポリシーが正しいとは限りません。Global Routing、選択中のサーバー、現在のConfigも確認してください。以下はポリシー選択を説明する独立したルール例で、待ち受け設定やサーバー認証情報は含みません。この例だけで完全なConfigを置き換えることはできず、既存のサブスクリプションにあるプロトコル項目を上書きするものでもありません。ローカルポートの確認とルールの確認を分けることで、リクエストがアプリに届いていないのか、届いた後に想定外の経路を通っているのかを判断できます。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

例に含まれるドメインとアドレス範囲は、構文を示すためのものです。DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはドメイン内のキーワード、IP-CIDRはアドレス範囲に一致します。FINALは末尾のポリシーとして使用します。REJECTは一致したリクエストを拒否するため、追加する前に対象範囲を検討してください。重要なサービスに広範なキーワードを安易に使わないでください。このようなルール順序で通常の振り分け結果を説明できるのは、Global RoutingがConfigモードの場合です。それ以外のモードでは、それぞれの動作に基づいて検証してください。

変更を一連の検証で完了する

最終確認は入口と出口に分けます。まず接続側から正しいローカル待ち受けに到達できることを確認し、次にアプリが意図したポリシーを選択して接続先へのアクセスを完了できることを確認してください。入口には接続できるのに出口で失敗する場合は、Ping、DNS、Logの各章に戻ります。入口に接続できない場合は、アドレス、ポート、アクセス範囲を確認します。完了したら、成功した条件、変更前後の値を記録し、トラブル対処のためだけに有効にした追加の記録を停止して、必要なOn Demandの状態に戻してください。設定ガイドの目的はスイッチを増やすことではなく、各変更に明確な用途と検証可能な結果を持たせることです。