Shadowrocket Settingsの設定項目ガイド：DNS・On Demand・診断

ENTRY 01 / SCOPE & BASELINE

設定の範囲と変更前の基準

Settings、Config、サーバー設定の違い

Settingsはアプリ全体の設定画面で、主にテスト、ログ、自動接続、画面表示の補助機能などを扱います。Configは設定ファイルの画面で、ルールやファイル内の関連項目を管理します。Homeのサーバー編集画面では、接続先のアドレス、ポート、プロトコルを設定します。いずれもリクエストに影響しますが、設定の範囲は異なります。初期状態はアプリの現在の表示を確認してください。まず問題がどの範囲にあるかを切り分け、名前が似た項目をまとめて変更せず、該当する画面で設定を見直しましょう。

アプリ全体の動作と個別サーバーの動作も分けて考える必要があります。あるサーバーのTLS設定を変更しても、通常は別のサーバーの問題は解決しません。現在のConfigのルールを変更すると、そのファイルを使用するリクエストの振り分けに影響します。サブスクリプションの更新で、登録済みサーバーの一部項目が置き換わる場合があります。リモートConfigの更新でファイルの内容が再度読み込まれることもあります。作業前に対象名、取得元、選択中の設定を記録し、「変更した項目」と「現在使っている項目」を取り違えないようにしましょう。

Global Routingの現在値を記録する

Global Routingは、リクエスト全体の処理方法を決めます。Configは選択中のConfigに従ってリクエストを処理し、Proxyはプロキシ経由、Directは直接接続します。例外的な動作は、アプリの説明や実際のログも確認してください。普段は動作確認済みのConfigを使い、比較のために一時的にProxyやDirectへ切り替えた場合は、テスト後に元の設定へ戻しましょう。調査用の一時設定をそのまま使い続けないよう注意してください。

画面上の項目	用途	確認するポイント
Config	現在のConfigに基づいて振り分け	選択中のファイル、ルールの順序、最終ポリシー
Proxy	Proxy経由で比較	選択中のサーバーでリクエストを完了できるか
Direct	Direct接続で比較	現在のネットワークから接続先へ直接アクセスできるか

再現可能な基準を作る

基準とは、変更前の状態を比較するための条件であり、速度の数値だけを指すものではありません。少なくとも、Wi-Fiかモバイル通信か、Homeで選択中のサーバー、Global Routing、現在のConfig、DNSの元の値、On Demandの状態を記録します。次に、アクセスが許可されていて、同じ条件でリクエストしやすい接続先を選び、名前解決、接続、コンテンツ読み込みのどの段階で失敗するかを記録してください。同じ接続先とネットワークで変更前後を比較すると、ネットワークやサーバー、ルールを一度に変えて原因が分からなくなる事態を防げます。

1回の確認で変更する項目は1つに絞ります。編集するConfigを複製するか、個人で管理できる場所に元の値を記録してから、1項目だけ変更し、接続し直して同じ接続先にリクエストします。設定によっては既存の接続にすぐ反映されないことがあります。以前開いたページがキャッシュを表示する場合もあるため、確認時は新しいリクエストを送ってください。改善しない場合は、次の項目を調べる前に元の値へ戻します。検証せず変更を重ねると、切り分けやすい問題が複雑になり、原因を追いにくくなります。

システム権限とApp Storeで確認する情報

初めて接続するとき、システムからVPN構成の追加を許可するよう求められる場合があります。これはネットワーク設定を管理するためのシステム上の許可であり、サーバーアカウントの認証ではありません。許可していない場合は、プロトコルを調べる前にシステムの案内に従って許可してください。システム要件はApp Storeのページに記載された内容を確認してください。このページでは主にiPhoneとiPadでの操作を扱います。他のAppleデバイスの互換性や購入の適用範囲もApp Storeの説明で確認し、ある端末の画面構成を別の端末にそのまま当てはめないでください。

アプリを確認するときは、公式アイコン、開発者名のShadow Launch Technology Limited、アプリIDの932747118を照合してください。アプリを購入すると利用資格が得られますが、接続に必要なサブスクリプションやサーバー情報は利用者自身で用意する必要があります。インストールや初回接続がまだの場合は、チュートリアルに戻り順番に進めてください。このページの設定変更は、基本設定を確認でき、情報の取得元が分かっていることを前提としています。アカウントや接続パラメータの確認に代わるものではありません。

ENTRY 02 / NAME RESOLUTION

DNS設定と名前解決の経路

DNSの役割

DNSはドメイン名をIPアドレスに変換します。アプリがドメイン名へリクエストを送る際、先にアドレスを取得し、その後に接続する場合があります。プロキシ経由では、名前解決の一部をリモート側で行うこともあります。そのため、ドメインにアクセスできないからといってDNSの障害とは限らず、DNSでアドレスを取得できても、その後の接続が成功するとは限りません。初期のDNS設定は、アプリと現在のConfigの表示を確認してください。正常に動作する名前解決の経路をまず維持し、問題が再現する接続先を調べましょう。DNSサーバーの変更を、あらゆる障害に対する最初の対処にしないでください。

SettingsのDNS関連項目とConfig内のDNS設定は、あわせて確認してください。実際に適用される設定は、選択中のファイルや機能のオン・オフに左右される場合があり、片方の画面だけでは判断できません。まず使用中のConfigを確認し、既存のDNS設定を記録してから、アプリ内のDNS項目の説明を確認します。両方に設定がある場合は、現在の画面に表示された適用範囲をもとに1項目ずつ検証してください。設定がある場所だけで優先順位を決めつけたり、確認していないアドレスを一度に複数登録したりしないでください。

通常のDNSと暗号化DNS

通常のDNSと暗号化DNSの主な違いは、問い合わせの転送方法です。DoHは通常、HTTPS URLで名前解決の接続先を指定し、DoTは通常、TLS接続でDNSサービスに接続します。どちらも、クライアントから接続先へ到達できる必要があります。暗号化通信にしても、出口のポリシーが決まるわけではなく、証明書の検証も省略できません。内容を理解していて、現在のネットワークから接続できるDNSサービスのみを使い、入力欄が受け付ける形式で入力してください。通常のアドレス欄と完全なURLを入力する欄は使い分けが必要です。文字列が似ているからといって、相互にコピーしないでください。

暗号化DNSの接続先にドメイン名が使われている場合、その接続先のアドレスをどう取得するかも問題になります。基本の名前解決が使えない状態で、ドメイン名形式の接続先を入力しても、最初の接続を確立できない場合があります。接続先への到達性、システム時刻、ネットワークへのログインの要否、アプリ内の名前解決経路を確認してください。まず動作していたDNS設定に戻して比較し、接続先の調査を続けるか判断しましょう。エラーを回避するために、複数の検証項目を一度に無効にしないでください。

ドメインルールとIPアドレスルール

ドメインルールはリクエストに含まれるドメイン名をもとに照合し、IPアドレスルールは接続先のアドレスをもとに処理します。アドレス情報を使って判定する場合、名前解決の結果がその後のルール選択に影響することがあります。以下はConfigでよく使われる記述例で、DNSサーバーのアドレスではありません。DNSの入力欄に貼り付けないでください。example.comは説明用の例であり、GEOIPの判定結果はアプリが使用するデータによって変わります。ログを読むときは、「名前解決で何が返ったか」と「ルールが何を選択したか」を別々に考えてください。

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

no-resolveをIPアドレスルールに指定すると、そのルールに一致させるためだけの名前解決を新たに行わないようにできます。リクエスト全体でDNSを一切使わないという意味ではありません。マッチ条件を理解したうえで追加してください。Direct接続を想定したドメインがProxy経由になった場合は、DNSエラーと決めつけず、より前にあるルールや最終ポリシーを確認します。返されたアドレスが想定と異なる場合は、キャッシュ、ネットワークの切り替え、実際に使用されたDNSサービスも調べてください。

確認と設定を戻す手順

DNSを確認するときは、同じネットワークから同じドメインへ複数回リクエストし、失敗が再現するかを見ます。その後、Logに名前解決や接続に関する情報があれば確認してください。アドレスを取得できているのに接続がタイムアウトする場合は、ルーティングやサーバーを調べます。名前解決がタイムアウトする場合は、DNSサービスへの到達性と入力形式を優先して確認してください。特定のアプリだけで失敗する場合は、そのアプリ独自のキャッシュや名前解決方法も考慮します。1つのアプリの結果を、システム全体のリクエストに当てはめないでください。

DNSを変更した後は、アプリの手順に従って接続し直してください。キャッシュの削除が必要な場合は、現在の画面に明示されている機能だけを使います。その後、同じ接続先に再度リクエストを送り、ログを比較します。元の値に戻すと問題が解消した場合は、その変更が現象に関係していたと考えられます。引き続き失敗する場合は、現在のネットワーク、Config、プロトコル設定を確認してください。動作を確認できた設定を基準として残し、ネットワークが変わるたびにDNS設定を追加して必要な値が分からなくなる状況を避けましょう。

ENTRY 03 / AUTOMATION

On Demandによるオンデマンド接続

接続のトリガーと処理方法

On Demandは、条件に応じてシステムにVPN接続の開始や処理を要求する機能であり、ルールによる振り分けの別形式ではありません。On Demandは「いつ接続するか」を決め、Configは接続後に「リクエストをどう処理するか」を決めます。初期状態や登録済みの条件は、アプリの現在の表示を確認してください。まず手動接続が安定して動作することを確かめ、必要最小限のオンデマンド条件を設定しましょう。手動接続に失敗している状態では、自動接続を設定しても繰り返し失敗するだけで、サーバーに不足している設定は補われません。

設定する前に、実現したい動作を明確にします。特定のWi-Fiで接続するのか、モバイル通信で接続するのか、特定のドメインを条件にするのかを決めてください。条件によって、接続、無視、その他のシステム動作が設定される場合があります。選択できる動作は画面の表示を確認してください。「新しい接続を開始しない」ことを「既存の接続をすぐ切断する」と解釈しないでください。手動でオフにした後、一時的に切断したからといって、条件が無効になったとも限りません。次のネットワーク変更時に再び動作する場合があります。

Wi-FiとSSIDの条件

SSIDはWi-Fiネットワークの名前であり、ルーターの管理アドレスではありません。入力欄の指定に従い、実際の名前に含まれる大文字・小文字、空白、記号を保持し、余計な改行をコピーしないようにします。まず、その場で確認できるネットワーク条件を1つ登録し、接続時のシステムVPN状態と、ネットワークから離れた後の変化を確認してください。家庭内の複数のアクセスポイントが同じSSIDを使うこともあります。SSIDが同じでもネットワーク環境が同一とは限らず、サービスへのアクセスを許可する信頼情報にもなりません。

特定のWi-Fiを除外する条件を設定した場合は、より広い範囲に適用される別のWi-Fi条件がないかも確認してください。条件の並び順、対象範囲、動作によって結果が変わる可能性があるため、現在の編集画面に表示される順序と説明に従って判断します。除外したネットワークでも接続する場合は、既存の接続が残っていないか、別の条件が一致していないか、設定が保存されているかの順に確認してください。条件を1つ削除しただけで、自動接続がすべて停止したと決めつけないでください。

モバイル通信への切り替えとドメイン条件

モバイル通信の条件は、端末がモバイルネットワークを使用しているときのオンデマンド動作を設定するもので、SSIDの条件とは異なります。テスト時はWi-Fiから実際に切り替わっていることと、アプリがシステム上でモバイルデータ通信を許可されていることを確認してください。「新規接続」と「接続中にネットワークが切り替わる場合」を分けてテストしましょう。後者ではセッションの再確立が必要になることがあります。ネットワーク切り替え時の一時的な切断だけでルールの誤りと判断せず、発生時刻と接続ログをあわせて確認してください。

ドメイン条件は、指定したドメインに関する接続判断をトリガーにします。同じドメインへのすべてのリクエストが、特定のプロキシポリシーを通るという意味ではありません。システムキャッシュ、既存の接続、アプリのリクエスト方法によって、確認できる結果が変わる場合があります。入力欄で指定されたドメイン形式に従い、WebページのURLやパス全体をドメイン条件として入力しないでください。アクセスが許可され、繰り返しリクエストできるドメインでテストします。接続後は、Configで想定したポリシーが選ばれているかも別途確認してください。

条件の範囲	確認方法	よくある誤解
Wi-Fi / SSID	指定したネットワークに接続し、そこから離れる	同じ名前のネットワークを同一環境とみなす
モバイルネットワーク	ネットワーク切り替え後に新しいリクエストを送る	端末がまだWi-Fiを使用している
ドメイン条件	対象ドメインに新しいリクエストを送る	キャッシュが残り、新しい判定が行われていない

自動再接続を止めて原因を調べる

手動で切断した後に再接続する場合は、まずOn Demandとその条件を確認し、次にシステム上のVPN構成の状態を確認してください。切り分ける際は、アプリ内のオンデマンド機能を一時的にオフにして保存し、手動で切断した後に再接続するか観察します。システム構成の削除、サブスクリプションの再インポート、ルールの変更を同時に何度も行わないでください。変更前後の比較ができなくなり、「システムによる再接続」と「設定の再インストール」が混同されます。

自動接続を再開する前に、テスト中に追加した重複条件を整理し、各条件の用途を1つずつ確認してください。Wi-Fi、モバイル通信、画面ロック後に再び使用する場合の動作も検証します。バックグラウンド動作については、システムで実際に許可される範囲を前提にしてください。1回のテスト結果を継続動作の保証とみなさないでください。詳しいケース別の説明はWi-Fi・モバイル通信・ドメインによるOn Demandの設定をご覧ください。普段は手動接続で十分な場合、確認済みの手順をそのまま利用できます。

ENTRY 04 / CONNECTIVITY TEST

PingとConnectivity Test

テスト結果から分かること

PingとConnectivity Testは、特定の方法で調べた接続可否や応答時間を確認するための機能です。実際の通信全体が成功することを保証するものではありません。テストはサーバーの接続先を対象とする場合も、指定した経路を通じてテスト先へアクセスする場合もあります。意味は、現在選択しているテスト方法によって異なります。初期のテスト方式、接続先、タイムアウト値はアプリの現在の表示を確認してください。まずテスト項目の説明を読み、どの区間を調べているか確認してから数値を比較します。異なるテスト方法の結果を同じ基準で順位付けしないでください。

接続先への到達を確認できても、その時点でテストしたアドレスとポートが応答したことしか分かりません。プロトコル認証、TLSのネゴシエーション、リモート側の名前解決、接続先サービスは失敗する可能性があります。一方、テスト方法によっては応答がなくても、通常のリクエストが成功する場合があります。サーバーが特定のテストを制限している可能性があるためです。テストは原因を絞り込む手掛かりとして使い、アクセスが許可された接続先に新しいリクエストを送って確認してください。一度の成功表示やタイムアウトだけで結論を出さないでください。

テスト先とタイムアウト

テスト先には、自分がアクセスを許可され、安定して応答し、用途が明確なアドレスを選んでください。完全なURLの入力が必要な場合は指定の形式で入力し、ホスト名やポートだけを求める欄にはWebページのURL全体を貼り付けないでください。リダイレクト、ログイン要求、リクエスト頻度の制限があると、結果が通常利用時の状態と異なる場合があります。まずテスト先そのものが利用可能かを確認してからサーバーを比較しましょう。すべての対象でタイムアウトする場合に、プロトコルのパスワードを次々と変更するのは避けてください。

タイムアウト値は結果を待つ時間の上限を設定するもので、ネットワーク性能を直接高めるものではありません。短すぎると、遅くても利用可能な接続を失敗と判定する場合があり、長すぎると複数のテストに時間がかかります。まず元の値を維持し、ネットワークが遅くてもリクエスト自体は完了すると確認できた場合に限り、慎重に調整してください。変更後は新しい値を記録し、同じ対象を複数回テストして比較します。テストを成功表示にするためだけに待ち時間を延ばし続けると、異常を見つける意味がなくなります。

比較条件をそろえる

サーバーを比較するには、少なくとも同じネットワーク、テスト方法、接続先を使い、時間もできるだけ近づけます。Wi-Fiとモバイル通信の結果や、画面を開いているときとネットワーク切り替え中の結果を同列に比較しないでください。まず実際に使う予定のサーバーをテストし、ほかに登録済みのサーバーと比較します。複数のテストを同時に行うと、混雑状況や端末の状態が結果に影響する場合があります。一度順位が変わっただけで自動切り替えを繰り返すと、接続の再確立が増えるため注意してください。

応答時間が短いことは、通信速度が速いことやアプリの使用感がよいことを意味しません。小さなリクエストのテストで分かるのは、接続確立や応答受信など、特定の段階に限られる場合があります。大容量の転送、動画のバッファリング、長時間のセッションには別の要因が影響します。普段使えるか判断するときは、実際のリクエストが完了するか、失敗が繰り返されるか、ネットワーク切り替え後に復旧するかも確認してください。数値を固定しようと高頻度でテストするのではなく、適度な回数を試して一時的な変動を見分けましょう。

失敗した段階から原因を絞る

登録済みのサーバーがすべて同じ時間帯に失敗する場合は、まずローカルネットワーク、テスト先、システム時刻、ネットワークへのログインの要否を確認してください。特定のサーバーだけ失敗する場合は、有効期限、アドレスの名前解決、ポート、プロトコル設定を調べます。テストは成功するのにブラウザーで失敗する場合は、同じテストを繰り返して復旧を待つのではなく、現在のGlobal Routing、Config、DNS、接続先を確認してください。

プロトコル設定は、自分が利用するサーバーの情報と照合してください。Shadowsocksでは暗号化方式とパスワード、VMessやVLESSでは識別情報、Trojanでは認証情報とTLS設定、WireGuardでは鍵とアドレス範囲を確認します。画面に同じ「ポート」という項目があっても、プロトコル間で設定を流用できるとは限りません。テスト結果だけで特定の項目が正しいと判断できない場合、遅延の数値から設定値を推測しないでください。元の情報と各項目を照合し、戻せるように変更前の値を残しましょう。

設定を調整した後は、不要な一括テストを止め、再接続して実際の接続先にアクセスします。テストの通信が確認に影響しないようにしてください。解決しない場合は、テスト方法、失敗した時間帯、ネットワークの種類、機密情報を除いたエラーの種類を記録します。接続タイムアウトの確認手順も参考にしてください。問い合わせる場合、サブスクリプションのURL、認証情報、設定ファイル全体を添付する必要はありません。失敗した段階を説明できる範囲で十分です。

ENTRY 05 / OBSERVABILITY

LogとDataで診断する

Logと通信量統計の違い

Logでは、アプリに記録された接続イベント、エラー、リクエスト処理の手掛かりを確認できます。Dataでは、アプリが提供する通信量の統計を確認できます。どちらもネットワーク全体を監査するものではなく、接続先からの応答の代わりにはなりません。初期の記録状態、保存範囲、集計期間はアプリの現在の表示を確認してください。問題を再現する前に関連項目の説明を読み、必要な範囲だけ診断機能を有効にします。観察を始めた時刻も記録し、関係のない過去のログを探し続けないようにしましょう。

統計値は、まず集計範囲を確認してください。画面によって、現在のセッション、特定のサーバー、累計データなど、対象が異なります。異なる範囲の数値を足して通信事業者の請求量と解釈しないでください。再起動、リセット、対象の切り替え、同期によって、表示の基準が変わることもあります。同じ統計画面で、条件をそろえたリクエストの前後を比較し、集計方法を確認しましょう。端末全体の通信量を確認する場合は、システムが提供する統計を別途参照してください。アプリ内の特定の数値から、すべての通信量を推定しないでください。

1回の再現で時間の流れを記録する

再現テストは、できるだけ簡潔に行います。現在のネットワーク、サーバー、Global Routing、Configを確認し、診断画面を開いて時刻を記録してから、失敗する操作を1つだけ実行してください。Logに戻り、その時刻付近のイベントを優先して確認します。名前解決、接続、ネゴシエーション、応答の順に読み取ってください。複数のアプリを同時に開いたり、サブスクリプションを更新したり、一括テストを行ったりすると、無関係なリクエストが記録に混ざり、どのエラーが現象に対応するか分かりにくくなります。

エラーを読むときは、前後の状況も確認してください。接続タイムアウトは、待ち時間内に特定の段階が完了しなかったことを示しますが、接続先が恒久的に利用できないとは限りません。接続拒否の場合は、接続先のポートやサービスの状態を確認します。証明書エラーでは、検証を無効にするのではなく、時刻、ドメイン名、TLS設定を確認してください。プロトコルやリクエストによって表示内容は異なります。このページのエラー分類と画面上の文言が完全に一致するとは限らないため、現在のログに記録された原文をもとに調べましょう。

ログでルールの選択を確認する

現在の画面で確認できる場合は、リクエストのドメイン、接続先アドレス、適用ルール、使用されたポリシーを確認します。想定と異なる経路になった場合は、まずそのリクエストが現在のConfigを実際に使用しているか確認し、次に、より前にあるルールが一致していないか調べてください。ログにアドレスしか表示されない場合は、ドメインルールが必ず判定に使われたと推測できません。アプリがすでに名前解決を行っている、または異なる接続方式を使っている可能性があります。画面で確認できる情報の範囲内で判断してください。

確認された状態	優先して確認する項目	この情報だけでは判断できないこと
名前解決で失敗	DNSの入力形式と名前解決の経路	すべてのサーバーが利用できない
サーバーへの接続がタイムアウト	ローカルネットワーク、アドレス、ポート	必ず認証情報の誤り
想定外のポリシーが適用された	Global Routingとルールの順序	必ずDNS設定の誤り
Dataの数値が増え続ける	集計範囲と現在のリクエスト	接続先のコンテンツが正常に読み込まれた

ログに含まれる機密情報

Log、サブスクリプションのURL、Configには、アクセス先ドメイン、サーバーアドレス、ユーザー識別情報、認証情報が含まれる場合があります。エクスポートやスクリーンショットを作成する前に、個人で管理できる場所で内容を確認し、機密情報を伏せてください。特にURLのクエリパラメータや認証情報を含む行に注意します。エラーの前後に必要な範囲だけを残し、アカウントを特定できる情報は削除してください。マスキング後もイベントの順序とエラーの種類は残しましょう。これらを削ると、情報を隠せても原因を調べられなくなる場合があります。

診断が終わったら、現在のアプリで提供されている機能を使って、一時的に有効にした詳細ログをオフにします。必要であれば、不要になったローカルログも削除してください。大量の履歴を長期間残すと、検索の負担が増えるだけでなく、アクセス履歴が余分に残る可能性があります。Logをオフにしても過去の記録が削除されるとは限りません。また、Dataを消去してもサブスクリプションやサーバー情報が消えるわけではありません。操作ごとに対象が異なるため、確認画面を読んでから実行し、Configを誤って削除しないようにしてください。

最終的な判断は、「どのネットワークで、どの対象を使い、どんなリクエストを行い、どの記録が残り、何を変更した後に変化したか」という証拠の流れで説明できるようにします。対応関係が分からない場合は、記録の範囲を広げ続けるのではなく、再現条件を絞ってもう一度確認してください。システム設定、現在のConfig、リクエストが関係する問題では、この章とDNS、Configの各章をあわせて読むと役立ちます。エラーの種類が分かっている場合は、ページ末尾のQ&Aからも確認できます。

ENTRY 06 / WIDGET & ICLOUD

Widget、iCloud同期、設定の保存

Widgetで確認できる範囲

Widgetは、システムが提供するアプリ情報の表示や、簡単な操作を行うための入口です。表示内容や操作できる範囲は、端末のシステムとアプリの実装によって異なります。初期状態で追加されているか、どの項目が表示されるかは、システムとアプリの現在の画面を確認してください。まずアプリ内で正常に接続できることを確認してから、必要なWidgetを追加します。ホーム画面にWidgetが表示されてもVPN接続中とは限りません。表示の更新が遅れていても、サーバーとの接続が切れたとは限りません。

追加するときは、システムのWidget編集画面からShadowrocketを選び、現在利用できるスタイルを選択します。Settingsに関連する表示項目がある場合は、用途に応じて調整してください。Widgetの更新タイミングはシステムによって管理されるため、アプリ内の状態とホーム画面の表示が同時に変わるとは限りません。重要な操作の後はHomeを開いて、接続状態と選択中のサーバーを確認しましょう。特にネットワークの切り替え、設定の変更、テストの終了後は、更新されていない可能性のあるWidgetだけを判断材料にしないでください。

ショートカット操作と自動接続の関係

Widgetは操作を開始するための入口であり、サーバー認証やConfigに必要な基本条件を変更するものではありません。初回のシステム許可が済んでいない、選択中のサーバー設定が不足している、On Demandに有効な条件が残っている場合、操作結果が想定と異なることがあります。まずアプリ内でこれらの問題を確認してから、Widgetを試してください。タップ後に状態が何度も変わる場合はOn Demandも確認します。接続の仕組みを直そうとしてWidgetを何度も追加し直さないでください。

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

iCloud同期は、現在の機能で対応しているデータを同期するためのものです。利用者自身のサービス提供元へ最新のサブスクリプションを要求する機能ではなく、システムの許可や一時的な状態まですべての端末にコピーできるとは限りません。初期状態のスイッチや同期対象は、アプリの説明で確認してください。まず両方の端末で使用しているアカウント、iCloudの利用許可、ネットワーク状態を確認し、同期に対応する項目を調べます。別の端末にアプリをインストールしただけで、接続に必要な情報がすべて自動で使えるようになると考えないでください。

サブスクリプションの更新、リモートConfigの更新、iCloud同期は別々の操作です。サブスクリプションの更新で登録済みサーバーの一覧が変わる場合があります。Configの更新ではルールが置き換わることがあります。同期では保存済みデータが別の端末に反映される場合があります。「変更したのに元に戻った」ときは、すべてを同期の問題とみなさず、どの操作が行われたかを確認してください。項目の取得元を記録し、同じ項目を複数端末で同時編集しないようにします。特に、リモートの内容を更新しながらローカルのコピーを上書きしないでください。

同期の競合と削除の反映

同期の競合は、複数の端末で同じデータに異なる変更が加わった状態です。実際にどちらが残るかはアプリの動作を確認してください。最後に表示された内容が、必ず正しい唯一のバージョンとは限りません。操作する前に、個人で管理できる場所へ両端末の必要なConfigを保存し、どちらを残すか決めてから項目ごとに統合するか、再インポートしてください。同期方向が分からないまま機能のオン・オフを繰り返したり、更新を促すために項目を連続して削除したりしないでください。削除も別の端末へ同期される場合があります。

コピーを保存する際は、サーバー情報、サブスクリプションの取得元、Configファイルを区別し、内容を判別できない1つのデータにまとめないでください。ファイル名には用途や個人による変更内容を記録できますが、パスワードやサブスクリプションのURL全体は含めないでください。認証情報を含むデータは、自分で管理できる保存先に保管します。インポート後は、項目数や必要な設定がそろっているか確認してください。バックアップが成功したと判断する基準は、ファイルが作成されたことではなく、復元して確認までできることです。

端末を買い替えた後の確認手順

端末を買い替えたら、まずApp StoreからShadowrocketを入手します。購入済みアプリの復元と購入の適用範囲については機種変更・再インストールの案内をご覧ください。次に、同期またはインポートしたデータを確認し、端末で必要なシステム許可を行います。VPNの許可、Widgetの配置、現在のネットワーク環境は、別の端末からそのまま複製できるものではありません。まず設定がそろっていることを確認したサーバーで手動接続し、成功してからOn Demandや補助表示の設定を戻してください。

最後に、両方の端末で想定したConfigが選択されていることを確認し、サブスクリプションの更新後もローカルの変更が残っているか確認します。重要なルールを変更した場合は、理由を記録しておくと更新後に見直せます。片方の端末だけで問題が発生した場合は、もう一方の正常なConfigをすぐに削除せず、問題がある端末の権限、ネットワーク、選択中の項目を比較してください。「アプリの入手、データの復元、手動での確認、自動化設定の復元」の順に進めると、動作する基準を維持しやすくなります。

ENTRY 07 / PROXY & PROTOCOL

Proxyポートとサーバーのプロトコル設定

ローカルポートとリモートポート

Proxy関連のポートは、まず通信の方向を区別します。ローカルの待ち受けポートは、その入口を使うように設定されたリクエストの接続先です。サーバーポートは、利用者自身が使うリモートサーバーの接続先を指します。2つは別の値であり、相互に置き換えることはできません。初期ポート、待ち受け範囲、機能の状態はアプリの現在の表示を確認してください。用途が明確でない場合は元の値を維持します。ローカルProxyの入口が必要で、リクエストがそこに到達する仕組みを理解している場合に限り、関連項目を変更してください。

ローカルポートを変更するときは、入力できる範囲と関連機能が有効かを確認し、他の待ち受けサービスと競合しないようにしてください。ポートを変えても、古いポートを明示的に指定しているリクエストに新しい値は自動で反映されません。接続側の設定もあわせて変更する必要があります。「他の端末からのアクセスを許可する」などの項目がある場合は、待ち受け範囲とネットワーク上のアクセス条件も確認してください。必要な範囲だけを許可し、アクセス許可を速度向上のためのスイッチとみなさないでください。アプリをバックグラウンドに移動しても入口が必ず動作し続けるとは限りません。

プロトコルの設定項目を使い回さない

リモートサーバーの編集は、利用者がすでに持っている完全な設定情報をもとに行います。Shadowsocksでは暗号化方式とパスワード、VMessやVLESSでは対応する識別情報や通信設定、Trojanでは通常、認証情報とTLS設定を確認します。Hysteria2やWireGuardには、それぞれ固有の認証情報、鍵、アドレスなどがあります。まずプロトコルの種類を確認し、現在の画面で必須項目を調べてください。別のプロトコルのパスワードを識別情報の欄に入れて試すことは避けましょう。

Subscribeからインポートした設定にも、項目の不足、形式の不一致、情報の変更がある場合があります。インポートが成功したということは、アプリが何らかの内容を認識して保存したという意味であり、リモートサーバーの認証が成功した証拠ではありません。サブスクリプション内の項目を手動で変更した場合、次回の更新で上書きされる可能性にも注意してください。利用が許可された設定であることを確認したうえで、比較が必要な元の情報を保存し、各項目を照合します。サーバーの反応を試すためにプロトコルを無作為に切り替えないでください。

項目の種類	確認する内容	混同しない項目
アドレスとポート	リモートホストとサーバーの接続先	ローカルProxyの待ち受けポート
認証情報	選択したプロトコルで必要な識別情報やパスワード	App Storeでの購入に使用するアカウント
TLS / SNI	証明書のドメインとサーバー側の要件	アクセスできるWebページの任意のドメイン
通信設定	設定済みのパス、Hostなど	接続先Webページの任意のURL

TLS、SNI、システム時刻

TLSは、証明書の検証を伴う暗号化接続を確立するために使用します。SNIは通常、ハンドシェイクで接続先のサーバー名を通知します。サーバーアドレス、証明書のドメイン、アプリ内の関連項目が、必ず同じ値とは限りません。入力内容は利用者自身が持つサーバー情報に従ってください。証明書の検証を維持し、ドメイン名の綴り、端末の時刻、必要な中間設定を確認します。証明書エラーを隠すために無関係なドメインを入力したり、検証を無効にしたりしないでください。接続の前提条件が変わってしまいます。

通信設定の項目も正確に入力する必要があります。パスでは大文字と小文字が区別される場合があり、Hostは接続先アドレスとは異なる役割を持つことがあります。余分な空白もリクエストの不一致につながります。編集前に元の値を比較用に保存し、変更後は接続し直してください。エラーが接続開始、プロトコルのネゴシエーション、応答のどの段階まで進んだかを確認します。エラーが変わらず、ほかに確かな根拠もない場合は元の値に戻してください。複数項目を次々と変更すると、動作していた元の情報が失われます。

リモート設定とローカル機能の違い

一部の機能はリモートサーバー側の対応が必要であり、ローカルのスイッチだけでは有効にできません。ポートに到達できても、選択したプロトコルがサーバーで有効とは限りません。テストに成功しても、すべての通信方式が使えるとは限りません。WireGuardでは、アドレス範囲とルーティングの意図を既存の設定に合わせる必要があります。他のプロトコルでも、認証情報と通信設定を対応させてください。サーバーから提供された情報は、個別に組み合わせられる値ではなく、互いに関連する設定のまとまりとして扱いましょう。

設定の照合後はルールを変更せず、まずサーバー単体で接続を確認します。その後Configに戻り、対象リクエストに適用されるポリシーを確認してください。特定の接続先で失敗する場合は、選択中のサーバーを経由していないのか、経由後に応答を完了できないのかを切り分けます。ローカルProxyの入口、リモートサーバーへの接続、接続先へのリクエストは連続する別々の段階であり、それぞれに根拠が必要です。ローカルの待ち受け機能を使う必要がなければ、リモートの認証問題を調べるためにローカルポートを変更する必要はありません。

ENTRY 08 / CONFIG & VERIFICATION

Configのルール、変更の確認、元に戻す方法

ルールの順序と最終ポリシー

Configにはリクエスト処理に使う設定が保存され、ルールは上から順に照合されます。適用される最初の一致ルールが処理ポリシーを決め、前のルールに一致しないリクエストにはFINALが適用されます。初期のルール構成は、現在選択中のファイルを確認してください。まず既存ファイルの意図を理解し、必要なルールだけを追加します。選択されていないファイルを編集しても、現在のリクエストにはすぐ反映されません。確認前にConfigへ戻って使用中のファイルを確かめ、Global RoutingがConfigになっているか確認してください。

ルールキーワードは照合条件を決め、ポリシーは一致後の処理方法を決めます。DOMAINはドメイン名の完全一致、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDは指定した文字列を含むドメインに使います。IP-CIDRとIP-CIDR6はアドレス範囲、GEOIPは地域別のIPアドレスデータを使います。PROXY、DIRECT、REJECTはそれぞれ異なる処理方針です。キーワードとポリシーを入れ替えて使うことはできません。無関係なリクエストまで一致しないよう、対象範囲が明確な条件を優先してください。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、api.example.comは最初に完全一致ルールに適用され、残りのexample.com配下のドメインは後続のポリシーで処理されます。アドレス範囲のルールは、例に示すDirect接続の意図を表します。すべてのネットワークで同じローカルアドレスの割り当てが使われるとは限りません。この記述は構文と順序の説明用で、誰にでも適した完全なConfigではありません。必要なルールはバックアップ済みのファイルに1つずつ追加してテストし、この数行で既存の内容全体を上書きしないでください。

リモート更新とカスタム変更

リモートConfigを更新すると、新しいルールが反映される場合があります。ローカルの変更が維持されるかは、アプリの保存方法と更新方法を確認してください。元のリモートファイルとテスト用のコピーを分け、「なぜ追加したか」「どの接続先で確認したか」を変更記録に残しましょう。サブスクリプション内のサーバー一覧とConfigのルール取得元も、別々に記録してください。前者を更新しても後者が更新されるとは限りません。内容が変わった場合は、まず実際に更新された対象を確認し、サーバー名の変更をルール順の変更と取り違えないようにします。

リクエストが想定したルールに一致しない場合は、決まった順に確認してください。Global RoutingがConfigか、正しいファイルを選んでいるか、前に範囲の広いルールがないか、実際のリクエストで元のドメインが使われているか、FINALが先に適用されていないかを調べます。アプリによっては、リクエストにアドレスしか含まれない場合や、リダイレクト後に別のドメインへ接続する場合があります。最初に見たドメインだけですべての通信を判断しないでください。Logで確認できる情報をもとに照合対象を特定してから、ドメインルールとアドレスルールのどちらを追加するか決めましょう。

変更後の動作を一通り確認する

変更を完了するには、変更前の状態を記録し、1項目だけ変更して、接続し直した後に同じ接続先へリクエストし、結果を記録します。成功の基準はスイッチがオンのままであることではなく、想定した経路で目的の操作が完了し、必要な他のリクエストにも影響がないことです。まず同じネットワークで確認し、その後、普段使う別のネットワークでも確認してください。On Demandを使う場合は、自動接続後にも想定したConfigが適用されることを確認します。手動接続時の結果だけで判断しないでください。

設定を戻すときは、直前に変更した対象だけを元に戻します。すぐにアプリ全体をリセットする必要はありません。ルールの問題はファイル、DNSの問題は名前解決の設定、プロトコルの問題は該当サーバーの項目を元に戻してください。現在の状態を特定できず、重要なデータも保存済みの場合に限り、より広い範囲の再設定を検討します。復元後も同じリクエストを行い、元の状態に戻ったことを確認してください。復元しても失敗する場合は、ネットワークやリモート側の変更が考えられるため、現在の条件で基準を作り直します。

よくあるトラブルと質問

Settingsを変更しても、開いているページに反映されないのはなぜですか？

既存の接続、アプリのキャッシュ、現在の設定の取得元が影響している場合があります。まず変更が保存され、対象に適用されているか確認してから、接続し直して新しいリクエストを送ってください。他の設定を続けて変更するのは避けましょう。

接続スイッチがオンなら、設定はすべて正しいということですか？

スイッチから分かるのは、接続管理の状態の一部だけです。対象のリクエストが完了するか、正しいサーバーを使っているか、Configで想定したポリシーが適用されるかも確認してください。必要に応じてLogを参照します。

サブスクリプションを更新した後、ローカルの変更を確認する必要があるのはなぜですか？

サブスクリプションの更新で、登録済みサーバーの項目が再度読み込まれる場合があります。更新前後のサーバー設定を比較し、継続して管理する必要がある変更は説明を記録してください。手動で編集した内容が常に維持されるとは限りません。

初回インポートがまだの場合は、クイックスタートチュートリアルに戻って順番に進めてください。ルールの対象範囲やFINALの位置を確認するには、カスタムルールと最終ポリシーの説明をご覧ください。このページは、失敗した段階に応じて該当する章を確認し、元の値を残して必要最小限の変更を加え、記録をもとに検証するためのガイドです。すべての設定を一度に有効にするためのものではありません。