SETTINGS REFERENCE · 公式ハンドブック

Shadowrocketの設定ガイドSettingsの項目と使い方

設定を変更する前に、どこに適用されるかを確認しましょう。各項目の意味、現在の設定値の確認方法、見直しの目安、元に戻す方法を章ごとに説明します。

このページは設定を確認するためのガイドで、初回接続の手順を説明するものではありません。まだデータの読み込みや接続が済んでいない場合は、先に使い方ガイドをお読みください。完了後、このページに戻って設定を確認してください。以下の手順では、利用者自身が用意したサブスクリプションまたはサーバー情報があることを前提としています。

現在のアプリに表示される値を確認 一度に変更するのは1種類の設定だけ App Store正規版の確認

01 / SCOPE

設定の適用範囲、現在の状態、変更の順序

Shadowrocketの動作は、複数の要素によって決まります。システムのネットワークはサーバーに接続できるかどうか、サーバー項目は接続パラメーター、Configはルールなどの設定、Global Routingは現在の振り分け方法、Settingsはアプリ全体のオプションを左右します。リクエストに失敗したとき、スイッチの位置だけで原因を判断することはできません。まず、どの段階で失敗したのかを確認し、該当する設定を調べましょう。

アプリの設定、Config、サーバーパラメーターを区別する

Settingsの項目が、現在のConfigの内容すべてを表すわけではありません。動作によっては、使用中のConfig、プロトコルの仕様、システム権限にも左右されます。似た名前の項目が複数の場所にあっても、常に一方が他方を上書きするとは限りません。まず現在のConfig名、サーバー名、Global Routingで選択中の項目を記録し、設定の詳細を開いて説明を確認してください。比較する場合は、現在のアプリに実際に表示される項目を基準にします。

サーバー情報には通常、アドレス、ポート、認証情報、プロトコル固有の項目が含まれます。これらは接続先に関する情報であり、振り分け結果を変える目的でむやみに変更しないでください。Configのルールは、リクエストをどのポリシーで処理するかを決めます。サーバーのポートをローカルProxyポートに変更したり、サブスクリプションのURLをConfigのURLとして使ったりすると、データの種類を取り違えることになります。画面上で保存できても、接続が確立するとは限りません。

設定画面の項目名や並び順は、現在のアプリの表示によって変わる場合があります。このガイドではDNS、On Demand、Ping、Logなどの英語表記を使い、確認できていない初期状態を一律のデフォルト値として記載しません。使用済みのデバイスには以前の変更や同期状態が残っていることもあるため、「現在表示される値」と「初回インストール時のデフォルト値」は同じとは限りません。トラブル対処では、記憶に頼ってデフォルトに戻すより、実際の値を記録するほうが確実です。

デフォルト値が分からないときの設定の選び方

基本的には、動作を確認できている設定を維持し、原因が明確な問題に必要な項目だけを変更します。サーバーのプロトコルパラメーターは、利用者自身が持つ情報と一つずつ照合してください。On Demand、同期、ローカル待ち受けなどの任意機能は、用途と適用範囲を確認してから有効にします。推奨設定は、すべての利用者がそのまま入力すべき数値の一覧ではありません。理由を説明でき、同じ手順で再確認できる設定を選びましょう。

設定の参照元現在の状態の確認推奨する対応
Settings現在のアプリに表示される値を確認記録してから、1項目ずつ変更
Config現在選択中のファイルを確認元に戻せるコピーを保存
Add Serverサーバー項目とプロトコルによって異なる手元のサーバー情報と照合
システム権限システム設定で確認システムの案内に従って許可状態を確認

変更前に、ネットワークの種類、接続できるかどうか、失敗した接続先、現在の設定を簡単に記録してください。パスワードやサブスクリプションURL全体をそのまま残さないようにします。特定のWi-Fiだけで問題が起きる場合は、利用可能な別のネットワークでも再テストしてください。特定の接続先だけ失敗する場合は、まず該当するルールを確認します。全体的な問題と一部の問題を切り分ければ、特定の問題にすべてのリクエストへ影響する設定を適用せずに済みます。

元に戻せる手順で変更する

一度に変更するのは1種類の条件だけにし、同じ接続先で再テストしてください。たとえばDNSをテストするときは、サーバー、ルーティング方法、ルールを変えずにおきます。サーバーパラメーターを試すときは、Configも同時に更新しないでください。変更後に保存されたことを確認し、必要に応じて接続を切ってから再接続し、新しい状態でテストします。結果が悪化した場合は、未検証の変更を重ねるのではなく、直前に記録した値に戻してください。

バックアップには、復元したいデータが含まれていることを確認してください。Configだけを保存しても、サーバーの認証情報まで保存したことにはなりません。サーバー項目を残しても、すべてのルールが保存されるとは限りません。書き出しやコピーが可能なデータは、現在のアプリで操作方法と出力範囲を確認してから、自分で管理できる場所に保存します。バックアップには機密情報が含まれる場合があるため、相談のためにそのまま公開しないでください。同期機能も、個別に確認したバックアップの代わりにはなりません。

元に戻すときも、直近の変更から順に確認します。まず最新の変更を取り消し、次にConfigが選択されているかを確認し、その後にサーバーとローカルネットワークを調べます。すべてのデータを削除するのは最初の手段ではありません。データを整理し直す必要がある場合は、バックアップを読み取れることと必要な情報がそろっていることを確認し、購入に使ったアカウントでのApp Storeの状態も記録してください。この設定ガイドの目的は、変更のたびに根拠を持つことです。見た目を整えるためにすべての項目を同じ状態にすることではありません。

02 / ROUTING

Global Routing：Config、Proxy、Direct

Global Routingは、現在のリクエストを全体としてどの方法で処理するかを決めます。設定、プロキシ、直接接続は、それぞれ画面上のConfig、Proxy、Directに対応します。普段のルールベースの振り分けには、内容を確認したConfigを使うのが基本です。ProxyとDirectは短時間の比較テストに利用できますが、サーバーパラメーターの問題を解決するものではなく、すべてのアプリの通信条件が同じであることを証明するものでもありません。

モードを確認してから、ルールの結果を調べる

Configは、現在のConfig内のルールに従ってリクエストを処理するモードです。Configが有効で選択されており、ルールが参照するポリシーも正しく解決できる必要があります。ファイルをリストに読み込んだだけでは、実際に使用中とは限りません。「ルールを設定したのに反映されない」ときは、まずGlobal RoutingがConfigになっているか、次に選択中のファイル名を確認し、その後で個々のルールの記述や順序を調べてください。

Proxyは全体をプロキシ経由で、Directは全体を直接接続で処理するためのモードです。ここでいう「全体」はルーティング方法を示すものであり、システム内のすべての通信に対する絶対的な保証ではありません。システム自身の接続、ネットワーク固有の制限、プロトコルの処理も確認結果に影響します。テストが終わったら、元のConfigに戻してください。戻さないと、後でルールログを確認した際に、モードの違いをルールの不具合と誤認することがあります。

画面上の表記意味推奨する用途
Config設定確認済みのルールで日常の通信を振り分ける
Proxyプロキシ短時間の比較でプロキシ経由の接続を確認
Direct直接接続短時間の比較でローカルからの直接接続を確認

3つのモードのうち現在選択されているものは、アプリの表示で確認してください。このガイドでは、インストール直後にどれが選ばれているかを推測しません。切り替えた後に接続先へアクセスできるようになっても、処理方法の変更が結果に影響したことが分かるだけです。DNS、ルールの一致、サーバーへの接続もあわせて確認してください。すべてのリクエストを別のモードに長期間変更すると、正常だったローカルリソースへのアクセス、名前解決の経路、接続元も同時に変わる可能性があります。

ルールが評価される順序を理解する

一般的なルールは上から順に評価され、先に一致したルールが後続ルールの適用に影響します。DOMAINはドメインの完全一致、DOMAIN-SUFFIXはドメインのサフィックス一致、DOMAIN-KEYWORDはドメインに含まれるキーワードの一致に使います。IP-CIDRとIP-CIDR6はアドレス範囲を対象とします。ルールの種類はできるだけ適切なものを選び、特定の接続先を一致させるために範囲の広すぎるキーワードを使わないでください。関係のないリクエストまで同じポリシーの対象になる可能性があります。

GEOIPはアドレスの地域情報を使って判定しますが、ユーザーの現在地を特定する機能ではなく、特定のWebサイトのすべてのリソースに適用される保証もありません。1つのページから複数のドメインや異なる地域のアドレスへリクエストが送られる場合があります。そのため、メインページがDirectで処理されても、すべての関連リソースがDirectになるとは限りません。FINALは、前のルールに一致しなかった場合のフォールバックです。最終的な動作を確認するときは、目立つ先頭のルールだけでなく、フォールバックのポリシーも記録してください。

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

上の例はルールの順序とポリシーの書き方を示すもので、あらゆる場面に使える完成済みのConfigではありません。example.comは説明用のドメインで、PROXYとDIRECTはルールキーワードのため原文のまま記載しています。手元のConfigのコピーを使って該当箇所を確認し、同名のセクションを重複して追加したり、例をサーバー情報として読み込んだりしないでください。保存後に選択中のファイルを確認し、Logで対象リクエストが想定どおりのルールに一致するかを調べます。

実際のリクエストからルールの問題を調べる

トラブル対処では、問題を再現できる接続先を1つ選び、操作と時刻を記録してから、該当するリクエストのドメイン、アドレス、ポリシーを確認します。想定外の上位ルールに一致している場合は、そのルールの範囲や順序を調整してください。常にFINALに到達する場合は、入力したドメインと対象が一致しているかを確認します。リダイレクト、画像、APIで異なるドメインが使われていることは、「ページのURLは正しいのにルールに一致しない」よくある原因です。

REJECTは一致したリクエストを拒否する指定であり、ページ上のコンテンツをすべて判別できるという意味ではありません。範囲が広すぎるドメインサフィックスにREJECTを指定すると、ログイン、画像、APIまで遮断する可能性があります。変更前に元のルールを記録し、変更後はページが開けるかだけでなく、主な操作を個別にテストしてください。一致範囲、意図しない遮断、元に戻す方法については、REJECTルールの書き方と適用範囲をご覧ください。

元に戻せるよう、元のファイルを残したままコピーで1つのルールを検証し、Logを確認してから必要に応じて統合してください。ルールを増やせば自動的に振り分けが正確になるわけではありません。用途を説明できない重複ルールは、かえって管理の負担になります。テスト後はGlobal Routing、現在のConfig、選択中のサーバーが想定した組み合わせのままかを確認し、次回のトラブル対処に使えるよう記録してください。

03 / NAME RESOLUTION

DNS：名前解決の経路、キャッシュ、アドレスの違い

DNSはドメイン名をアドレスに変換します。接続の失敗は、名前解決の前、処理中、アドレス取得後のいずれでも起こり得ます。DNSの変更で影響するのは、その一部だけです。まず、現在正常に動作している設定を使い、Config内の名前解決に関する設定を確認してください。デフォルト値や選択可能な方式は現在のアプリ表示で確認します。特定のパブリックDNSを、どのネットワークでも使える一律の正解として扱わないでください。

名前解決の失敗と接続の失敗を切り分ける

リクエストから有効なアドレスを取得できない場合は、DNSサーバーに到達できるか、ドメインが有効か、ネットワークへの接続認証が必要かを確認します。アドレスを取得できても接続がタイムアウトする場合は、ルールの方向、サーバーの状態、接続先サービスに問題がある可能性があります。ブラウザーの「ページを開けません」という表示だけでは区別できません。Logの同じ時間帯にある名前解決と接続の情報を確認し、どの段階で失敗したかを特定してください。

ドメインの名前解決経路と、その後の接続経路は関連していますが、別の問題です。リクエストが最終的にPROXYで処理されても、名前解決のすべてが同じ通信経路を使うとは限りません。DIRECTの場合も、ポリシー名だけでDNSサーバーの場所を判断することはできません。実際の動作は現在のConfigとアプリの設定にも左右されます。「どこで名前解決したか」と「どこに接続したか」を分けて記録し、1つの曖昧なスイッチの問題として扱わないでください。

DNSの設定は、アプリのオプションとConfigの両方に関係する場合があります。まず現在のConfigを開いて、名前解決に関する項目を確認し、次にSettingsで利用できるDNSオプションと説明を確認してください。複数の場所に異なる値を同時に設定し、結果から優先順位を推測しないでください。設定間に矛盾がある場合は、Configのコピーで項目を1つずつ整理し、再接続してテストします。どの変更が結果に影響したか分かるまで続けてください。

名前解決方式の選択とキャッシュの確認

通常のDNSと暗号化DNSでは、通信条件が異なります。暗号化通信は経路上のDNSリクエストの保護方法を変えますが、名前解決が速く、正確になり、現在のネットワークで必ず使えることを保証するものではありません。現在のアプリでDNSサーバーを指定できる場合は、形式、プロトコルへの対応、実際の到達性を確認してください。まず正常に動作している方式を維持し、明確な必要性があり、結果を検証できる場合にのみ変更します。

キャッシュが残っていると、設定を変更しても結果が変わらないように見えることがあります。キャッシュはアプリ、システム、ブラウザー、接続先の処理などに存在する可能性があるため、ページを1回再読み込みしただけでは、すべての名前解決がやり直されるとは限りません。テスト時は古いページを閉じるか、既存の接続を終了し、現在のアプリにキャッシュの操作方法があれば実行してから、必要に応じて再接続します。キャッシュの削除だけを目的にConfig全体を消さないでください。未検証の変更によって一度だけ復旧したと決めつけるのも避けましょう。

IPv4とIPv6も確認結果に影響します。1つのドメインが両方のアドレスレコードを持つ場合があり、ローカルネットワークで両方の接続がサポートされるとは限りません。一部の接続先だけに問題がある場合は、実際に使われたアドレスの種類と失敗した段階を確認してください。まずネットワークとサーバーが該当する経路をサポートしているか確認し、その後で関連する設定を検討します。片方のアドレスファミリーを無効にすれば一時的に回避できる場合もありますが、根本原因が解決したことにはなりません。

ローカルネットワークの名前解決と接続認証

家庭内のデバイス、職場のリソース、特定のネットワーク内だけで使える名前にアクセスする場合、ローカルの名前解決環境が必要なことがあります。すべてのドメインを同じ外部DNS経路に任せると、こうした名前を解決できなくなる場合があります。まず正しいローカルネットワークに接続しているか確認し、DirectとConfigの結果を比較してください。対象のリソースに特定のドメイン、アドレス範囲、アクセス権限が必要かも確認します。

Web認証が必要なWi-Fiでは、プロキシ接続をテストする前にネットワークへの接続手続きを完了してください。システムが通常のネットワークアクセスを確立していない状態でDNSを変更したり、サーバーを何度も切り替えたりすると、確認すべき条件が増えるだけです。システムに認証画面が表示されているか確認し、利用可能な一般的なアクセス方法でネットワークをテストします。認証後に元のConfigへ戻して再接続し、認証前の失敗ログと認証後のテスト結果を混同しないようにしてください。

DNSが正常か確かめるために、ドメイン名の代わりに接続先のアドレスを直接入力しないでください。暗号化接続を使うWebサイトでは、証明書の検証や接続先の選択にドメイン名が必要なことが多く、アドレスへ直接接続すると別のエラーが発生する可能性があります。名前解決で結果が得られるかを確認したうえで、元のドメイン名を使って接続を調べるほうが確実です。テスト中にリダイレクトがある場合は、その後のドメインで異なるDNSやルールが使われていないかも記録してください。

DNSのトラブル対処では、説明できる安定した状態に戻すことが大切です。有効な設定を残し、根拠のない変更を取り消して、最初に失敗した接続先と、もともと正常だったローカルリソースを再テストします。特定の接続先だけに問題が残る場合は、ルールや接続先サービスを確認してください。すべてのドメインで失敗する一方、既存の接続が一時的に使える場合は、まず名前解決の経路を調べます。同じ項目で試行錯誤を繰り返さずに済みます。

04 / CONNECTION LIFECYCLE

On Demand：接続条件と接続のライフサイクル

On Demandは、設定した条件に応じて接続を開始する機能で、サーバーの品質やルールの優先順位を変えるものではありません。まず手動接続が安定して動作することを確認し、実際の使い方に応じて条件を設定してください。デフォルト状態、条件の種類、動作は現在のアプリ表示で確認します。有効にする前に、どのときに接続したいのか、どのときに切断状態を保ちたいのか、ネットワーク切り替え後にどう復帰させるのかを明確にしておきましょう。

まず手動接続の基準を確認する

自動接続に頼る前に、Homeで選択中のサーバー、Global Routing、現在のConfigを確認し、手動で接続してください。システムからVPN構成の追加を求められた場合は、追加元を確認し、システムの手順に従って許可します。許可したことは、システムが該当する接続を認めたことを示すだけです。サーバー情報が正しいことや、接続先のWebサイトにアクセスできることを保証するものではありません。実際のアクセスとLogで確認してください。

手動接続が安定していないと、On Demandは不安定な処理を自動で繰り返すだけです。条件を設定する前に、認証、名前解決、ルーティングの問題を解決してください。そうしないと、接続と切断が繰り返される現象をOn Demand自体の不具合と誤解しやすくなります。ネットワーク、サーバー情報、手動接続、ルールの結果の順に確認し、最後に自動接続の条件が想定どおりに働くかをテストします。

システムのステータスバーに表示されるアイコンだけで、接続の品質を判断しないでください。アイコンやアプリのスイッチから接続状態は分かりますが、すべてのリクエストが成功したことまでは分かりません。接続が確立しているか、明確な接続先にアクセスできるか、Logに新しいリクエストが記録されているか、適切なポリシーが使われているかを個別に確認します。結果を分けて記録すれば、「接続が開始されない」場合と「接続済みだがアクセスできない」場合を区別できます。

条件の設定と手動切断の関係

現在の画面でネットワークの種類や条件に応じた動作を設定できる場合は、各条件の意味を確認し、実際に使うネットワークだけを指定してください。Wi-Fiの名前が似ていても、同じ信頼できる環境とは限りません。名前だけで安全性を判断しないでください。まず少数の明確で再テストしやすい条件から始め、条件を重ねて追加しないようにします。条件同士の一致方法は、現在のアプリ表示と実際のテストで確認してください。

手動で切断しても再接続される場合は、有効なトリガー条件が残っていないかOn Demandを確認します。接続スイッチを1回オフにしても、自動化ルールが解除されるとは限りません。切断状態を維持したい場合は、関連する条件を先に処理してから、接続状態を確認してください。テスト後に普段の設定へ戻す際も、条件とスイッチの両方を見直し、どちらか片方だけ戻し忘れないようにします。

ネットワークが切り替わると、既存の接続が切れて再確立される場合があります。通信中のタスクが新しいネットワークで継続できるとは限らないため、一時的な失敗だけでルールの不具合と判断しないでください。ネットワークが正常に使えるようになってから新しいリクエストを送り、Logの時系列を確認します。切り替えのたびに失敗が続く場合は、手動で接続し直し、自動復帰との差を比較して調査範囲を絞ってください。

画面ロック、バックグラウンド、システムの制限

アプリが前面に表示されていなくても接続が停止したとは限らず、画面を開いたままでもシステムのネットワーク状態が変わらないとは限りません。画面ロック、ネットワークの変化、システムのリソース管理が結果に影響することがあります。画面をロックした後に同じ接続先を開くなど、再現可能な状況でテストし、再接続が必要かを記録してください。バックグラウンドで一度動作した結果から、すべてのデバイスで常に同じ動作をすると推測しないでください。

消費電力は、使用時間、通信量、電波状況、再接続の頻度をあわせて確認します。継続的な通信、弱い電波、頻繁な再接続はいずれも消費電力に影響するため、On Demandのオン・オフだけで結論を出すことはできません。比較時はネットワーク、サーバー、使用するタスクをできるだけ同じ条件にし、ある程度の時間にわたって観察します。短時間に設定をいくつも切り替えても、電池残量の変化から原因を特定するのは困難です。

接続がほかのシステムネットワーク設定に影響される場合は、システム設定で現在有効な接続と管理上の制限を確認してください。管理対象のデバイスには、組織が設定した制約がある場合があり、構成をむやみに削除して対処することはできません。自分で管理できる範囲で比較テストを行い、元の設定を記録しておきます。用途が分からないシステム設定は、変更によって必要なネットワークアクセスに影響がないか確認してから調整してください。

On Demandの設定後は、少なくとも3つの状態を確認します。通常の起動時に接続できること、ネットワーク変更後の動作が想定どおりであること、切断が必要なときにその状態を維持できることです。いずれかが想定と異なる場合は、補助ルールを増やすのではなく、まず条件を簡素化します。決まった時間だけ使う場合は、手動接続を選ぶのも分かりやすい方法です。自動化は繰り返し操作を減らすためのもので、説明しにくい状態を増やすためのものではありません。

05 / DIAGNOSTICS

Ping、Connectivity Test、Log

PingとConnectivity Testは、特定のテスト条件における到達性を確認するための機能です。Logには実際の動作が記録されます。テスト結果は継続的な接続の保証ではなく、実際の通信速度を直接測定するものでもありません。接続先と方法を明確にしてからテストし、実際のアクセスやLogとあわせて原因を調べましょう。テスト方法、接続先、初期設定は現在のアプリ表示で確認してください。

数値だけでなく、何をテストしたかを確認する

テストによっては、サーバーのポートに到達できるかを確認し、別のテストではプロキシ経由で接続先へアクセスする一連の処理を確認します。両者の結果をそのまま比較することはできません。前者が成功しても、その後の認証や接続先への接続で失敗する場合があります。後者が失敗しても、テスト対象が一時的に利用できないだけかもしれません。操作前にテスト方法と説明を確認し、遅延として表示される数値をすべて同じネットワーク層の往復時間とみなさないでください。

テスト時間が短くても、ダウンロードが速いとは限りません。実際の速度は、ローカルの電波、利用可能な帯域幅、サーバーの負荷、通信プロトコル、接続先の制限にも左右されます。同じネットワーク、同じテスト方法、近い時間帯で回数を絞って比較し、結果が安定しているかを確認してください。一度だけ最速だった結果を長期的な選択の根拠にしたり、一度タイムアウトしただけで項目を削除したりせず、同じ現象が再現するかを先に確かめましょう。

テスト前に、正しいサーバー項目が選択されていることを確認してください。特に、似たメモや重複する項目がある場合は注意が必要です。サブスクリプションの更新で項目一覧が変わる場合があるため、古いメモだけで現在のパラメーターを判断しないでください。リスト上のテストは成功するのに、接続を開始すると失敗する場合は、両方の操作の時刻と対象を記録します。同じ項目、ルーティング方法、ネットワークを使っているかを確認し、すぐにテスト機能の精度の問題と決めつけないでください。

Logで1つの失敗リクエストを追跡する

Logを読むときは、画面全体ではなく、再現できる操作1回を単位にします。時刻を記録し、接続先を1つ指定してアクセスした後、近い時刻のドメイン、アドレス、ルール、エラーを確認します。Logに表示される項目は現在のアプリで確認してください。ログが長い場合は、テストする操作を絞ります。同時に複数のページを開くと、バックグラウンドリクエストや関連リソースが増え、重要な記録を特定しにくくなります。

まず、失敗した段階を確認します。ドメインを名前解決できたか、適用するポリシーが見つかったか、サーバーへの接続が確立したか、認証が通ったか、接続先が応答したかを調べます。エラーの文言は原文のまま記録し、すべてのタイムアウトを同じ原因とみなさないでください。タイムアウトは異なる段階で発生することがあり、接続拒否と認証エラーにも別の対処が必要です。最後の1行だけでなく、前後のイベントと接続先をあわせて判断します。

確認できた現象そのままでは判断できないこと次に確認する項目
テスト時間が短い実際の通信も必ず速い条件をそろえて実際のタスクを確認
名前解決の結果がないサーバーが必ず利用できないDNSとローカルネットワークを確認
ルールに正しく一致した後続の接続も必ず成功する接続と認証の段階を引き続き確認
1つの接続先だけ失敗する設定全体が無効になったドメイン、ルール、応答を確認

Logにアドレスやドメインが記録されても、対応するデータの転送が成功したとは限りません。名前解決、接続の試行、ルールの一致が記録されただけの場合があります。想定した記録が見当たらなくても、アプリがリクエストを処理していないとは限りません。フィルター、記録対象、リクエストが実際に送信されたかを確認してください。まずLog画面のフィルター状態を確認し、新しい明確な操作を行って記録が更新されるかテストしましょう。

診断に必要な情報だけを残す

相談する前に、パスワード、認証トークン、サブスクリプションURL全体、個人の利用状況が分かる記録を削除してください。サーバーアドレス、メモ、アクセス先のドメインも機密情報になる可能性があるため、問題の説明に必要な最小限だけを残します。「同じネットワークで手動接続に失敗し、認証段階でエラーが出る」のように説明し、関連する数行だけを必要に応じて加工して添付できます。Config全体やLog全体を公開する必要はありません。サブスクリプションの内容をそのまま送らないでください。

詳細な記録はストレージの使用量や診断時のノイズを増やすことがあります。必要なときだけ現在の画面で利用できる方法で有効にし、トラブル対処が終わったら元の状態に戻してください。Logのレベルや初期状態はアプリの表示で確認し、「情報が多いほどよい」と考えて詳細を常に記録しないでください。記録を消す前に、問題の解決に必要な部分を保存します。削除後に再テストすれば、古いエラーを新しい失敗と取り違えずに済みます。

速度が遅い場合は、ローカルネットワーク、プロトコルの設定、回線の状態、サーバーの負荷を順に確認します。各段階では1つの条件だけを変え、実際のタスクの結果を記録してください。詳しい比較手順は接続後に速度が遅い場合の段階的な確認方法をご覧ください。テスト結果が示すのはその時点の条件だけです。将来の安定性を推測したり、特定の接続サービスの評価や推奨に使ったりしないでください。

診断後は、解決につながった条件を明確に記録してください。変更した項目と元の値、テストに使った接続先、別のネットワークでも再確認したかを残します。効果がなかった変更は取り消し、一時的に切り替えたGlobal Routingも元に戻してください。次に似た現象が起きたときは、記録済みの状態から確認を始められます。Logの目的は変更の数を増やすことではなく、原因の候補を絞ることです。

06 / CONFIGURATION DATA

Subscribe、Add Server、Configの役割の違い

Subscribeは利用者自身が持つサブスクリプション情報を管理し、Add Serverはサーバー項目を追加し、Configは設定ファイルを管理します。互いに関連はありますが、置き換えることはできません。まず手元の情報がどの種類に当たるかを確認し、対応する画面から追加してください。リンクのように見えるという理由だけで、同じ方法で読み込まないでください。初期項目や読み込み方法は現在のアプリ表示で、サーバーパラメーターは手元の情報で確認します。

サブスクリプションの更新と実行中のConfigを別々に確認する

サブスクリプションは通常、サーバー項目の取得や更新に使われますが、完全な振り分けルールも含まれているとは限りません。読み込み後は、実際に作成された内容を確認してください。項目数に変化があったか、メモが想定どおりか、読み込みエラーが出ていないかを調べます。その後、Configで使用中のファイルとGlobal Routingを別途確認します。サーバー項目がリストにあることは、接続情報があることを示すだけで、ルールまで選択済みとは限りません。

サブスクリプションURLには利用者を識別する情報が含まれることが多いため、パスワードと同様に扱ってください。コピー時に空白、改行、説明文が混入しないようにし、読み込んだ後もURL全体をメモ欄に貼り付けないでください。更新できない場合は、URLが有効かを確認し、現在のネットワークでアクセスできるかを調べます。テスト目的で不明なWebページに送信しないでください。更新の仕組みや内容が分からない場合は、利用者自身が持つサービス情報の説明を確認します。

更新前に、現在使っているサーバー項目を記録し、更新後に想定したサーバーが選ばれているか確認してください。項目の追加、削除、名称変更によって、以前の選択が影響を受ける場合があります。サーバーを判別できるメモは残しつつ、パスワードを名称に含めないでください。項目が重複している場合は、削除する前に参照元と実際のパラメーターを照合します。名前が同じでも、同じ接続先とは限りません。

Add Serverのパラメーターを推測で入力しない

サーバーを手動で追加する場合、アドレス、ポート、認証情報は手元の情報と一致させる必要があります。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2などでは必要な項目が異なり、あるプロトコルの入力方法を別のものに流用できません。現在選択中のプロトコルに必要な項目を1つずつ確認し、画面上の英語表記を保ったまま、手元の情報と照合してください。パラメーターが不足している場合は、適当に試すのではなく、先に情報をそろえます。

転送方式、暗号化接続に関する項目、証明書名はハンドシェイクに影響する場合があります。サーバーのアドレスに到達できても、これらの項目が正しいとは限りません。エラーを回避するために証明書の検証をむやみに無効にしたり、アクセス失敗をすべてパスワードの問題と決めつけたりしないでください。まず元のエラーを記録し、ドメイン、時刻、認証情報、プロトコルの要件を照合します。セキュリティ検証に失敗した場合は原因を特定し、接続済みの表示だけを目標にしないでください。

QRコードから読み込む場合も、読み込み後の内容を確認してください。Scan QR Codeを使うと手入力を減らせますが、パラメーターの確認は必要です。信頼できる提供元からの情報でも、現在有効とは限りません。読み込み後にプロトコル、アドレス、ポート、メモを確認し、別の項目を選んでいないことを確かめてから接続します。現在の画面で対応していない種類のデータであれば、何度もスキャンせず、サーバー情報、サブスクリプションURL、その他のConfigのどれに当たるかを確認してください。

Configの編集、選択、復元

Configを編集する前にコピーを保存し、そのコピーで一部だけ変更してください。Configには共通設定、ルール、その他のセクションが含まれる場合があります。数行のルールを追加するために、元の内容を削除しないでください。保存後にアプリで形式エラーが表示されないか確認し、実行時にそのファイルが選択されていることも確かめます。リスト内の位置、最終編集日時、表示名だけでは使用中かどうか判断できません。実際の選択状態を確認してください。

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

例はルールの構文を示すものです。プライベートアドレス範囲も、アドレスによる一致方法を説明するための例にすぎません。実際のローカルネットワークでは別の範囲が使われることがあるため、そのままコピーしてすべてのローカルリソースをカバーできるとは限りません。DOMAINとDOMAIN-SUFFIXでは一致する範囲が異なり、FINALはフォールバックとして扱います。まず明確な接続先を1つ選んで検証し、問題がなければルールの範囲を広げます。変更後は対象の接続先と周辺の機能も確認し、意図しない遮断を防いでください。

リモートConfigを更新するとルールが変わる場合があるため、ローカル編集との役割分担を明確にしてください。更新前に残す必要がある内容を確認し、更新後に重要なルールが引き続き存在するかを調べます。継続的に更新されるソースと、記録していないローカル変更を混在させると、変更元を特定しにくくなります。重要な変更は用途と検証方法を記録し、直前の正常な状態に戻せるコピーを残してください。

複数のサブスクリプションを使う場合は、参照元や用途が分かるメモを付け、内容を整理してから削除してください。サブスクリプションを削除したときに、それによって作成されたサーバー項目がどうなるかは、現在のアプリに表示される操作案内で確認します。確認前に複数の項目を続けて削除しないでください。整理の手順は複数のサブスクリプションの分類、並べ替え、重複項目の整理をご覧ください。このハンドブックでは手元の情報の管理方法のみを説明し、サーバーやサブスクリプションの提供、販売、推奨は行いません。

この章の最後に、3種類のデータがそれぞれ正しい場所にあることを確認します。Subscribeで既存のサーバー項目を更新できること、Add Serverのパラメーターが手元の情報と一致すること、Configが選択され、想定したルールの結果が得られることです。いずれかの段階に問題がある場合は、すべてを何度も読み込み直すのではなく、その段階で対処してください。最初から手順を確認する場合は、クイックスタートガイドに戻り、読み込み、選択、接続、確認の順に進めます。

07 / CONTINUITY

Widget、iCloud同期、デバイス間の状態

Widgetは状態の確認や操作をすばやく行うためのシステム上の入口です。iCloud関連機能は、現在のアプリが対応する範囲でデータを引き継ぎます。どちらもメイン画面での状態確認に代わるものではなく、接続が成功した証明にもなりません。まずメインアプリで動作を確認してから、ショートカットや同期を設定してください。利用できる機能、同期範囲、デフォルト状態は現在のアプリとシステム表示で確認し、すべてのデータが同期されると決めつけないでください。

Widgetの表示と実際の接続状態を別々に確認する

Widgetを追加するときは、システムのウィジェット管理手順を使い、現在のデバイスで選べるShadowrocketのWidgetとサイズを確認してください。種類や操作方法はシステム画面で確認し、別のデバイスの配置から推測しないでください。追加後はメインアプリで接続状態と選択中の項目を確認し、Widgetの表示と照合します。すぐに表示が更新されない場合は、アプリに戻って実際の状態を確認してください。接続を何度も切り替えるために、Widgetを続けてタップしないでください。

Widgetの更新タイミングはシステムによって制御される場合があるため、表示が常にメインアプリと完全に同期するとは限りません。メインアプリでは接続できるのにWidgetの表示だけがおかしい場合は、表示や更新の問題として切り分けてください。接続または切断の操作を1回行って比較し、表示が更新されるまで待ちます。サーバーの切り替えやConfigの削除を繰り返しても、Widget自体の更新問題が解決するとは限りません。

ロック画面やホーム画面に表示されるメモから、利用状況が分かることがあります。サーバーやConfigの名前は、識別のしやすさとプライバシーの両方を考え、完全なアドレス、認証情報、サブスクリプションURLを表示されやすい場所に書かないでください。共有デバイスでは、ほかの利用者に表示されたり操作されたりする可能性も考慮します。機密情報を含まない短い名前を使い、アプリ内のリストだけでなく、Widgetに実際にどう表示されるかも確認してください。

iCloud同期を使う前にデータの範囲を確認する

同期を有効にする前に、システムアカウント、iCloudの利用状況、アプリ内の関連オプションを確認してください。同期するデータの範囲は項目ごとに確認します。「iCloudが有効」だからといって、サーバー、Config、Log、接続状態、すべての設定が完全に保存されているとは限りません。まず機密情報を含まない変更を1つ使って同期を確認し、それからデバイス間の管理を同期に頼るか判断します。デフォルト状態は現在のアプリ表示で確認してください。

同期はデータの状態を引き継ぐ機能であり、過去の状態を保存するバックアップではありません。誤った削除や変更がほかのデバイスにも反映される可能性があるため、重要な内容は別のコピーも保管してください。コピーには用途と保存範囲を記し、自分で管理できる場所に保存します。別のデバイスでファイル名が見えるだけで、内容すべての同期が完了したと判断しないでください。重要な項目を開いて確認し、実際の接続に使えるかを確かめます。

複数のデバイスで同時に編集すると、どちらの内容が新しいのか分かりにくくなります。まず1台で整理し、ほかのデバイスに想定した結果が反映されてから次の操作に進んでください。同名のコピーや内容の違いが見つかった場合は、すぐに削除せず、両方を保存して重要な項目を比較します。ルールの順序、サーバーパラメーター、メモとの対応を確認してください。ファイル名が同じでも、内容が一致するとは限りません。

ファイルの読み込みと継続的な同期を区別する

Import from Cloud JSONは、現在のアプリに表示される入口と案内に従って利用してください。ファイルから一度データを読み込んでも、継続的な同期が設定されたことにはなりません。ファイルを正常に読み取れても、すべての項目が現在のデバイスに適用できるとは限りません。操作前にファイルの種類と参照元を確認し、操作後に追加・変更された内容を調べます。拡張子だけを見てサーバー項目が入っていると決めつけたり、参照元が分からないデータで使用中のConfigを上書きしたりしないでください。

システムのネットワーク許可は、使用する各デバイスで確認する必要があります。別のデバイスで接続を許可済みでも、現在のデバイスで許可が完了しているとは限りません。新しいデバイスで初めて接続するときは、システムの案内に従って許可し、ローカルネットワーク、サーバー、ルールをあらためて確認してください。アプリの購入資格とデバイスの互換性はApp Storeの製品ページで確認できます。同期したデータが見えることと、そのデバイスが動作要件を満たすことも別々に確認が必要です。

同期に時間がかかる場合は、まず両方のデバイスでシステムアカウントとネットワークの状態を確認し、次にアプリ内の関連オプションを調べてから、再読み込みが必要か判断してください。コピーを保存せずに同期をオフにしてクラウド上のデータを消去したり、同期のオン・オフを何度も切り替えたりしないでください。変更は一度に1つの段階だけにし、もう一方のデバイスで実際にどのような変化があったかを記録します。転送の遅れ、同期範囲の違い、データの競合を切り分けやすくなります。

設定後も、Widgetと同期は補助的な入口として使い、唯一の操作画面にはしないでください。普段と異なる動作が起きたときは、メインアプリで接続、Global Routing、現在のConfig、サーバーの選択状態を確認します。バックアップを読み取れるか、メモに機密情報が表示されていないか、不要になったコピーを整理する必要があるかも定期的に確認してください。操作の手軽さを保ちながら、状態を明確に確認できるようになります。

08 / LOCAL LISTENING & REVIEW

Proxyポート、ローカル待ち受け、設定の見直し

Proxy関連のポートは、特定のプロキシサービスが待ち受ける場所を示すもので、リモートサーバーのポートとは異なります。HTTP、SOCKS5などのローカル待ち受けを利用できるか、初期値や有効になる条件は現在のアプリ表示で確認してください。明確な必要がなければ現在の設定を維持し、固定のポート番号を推測したり、速度改善を目的に待ち受け設定をむやみに変更したりしないでください。

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

Add Serverのポートは通常、利用者自身が用意したリモートサーバーへの接続に使い、サーバー情報と一致させる必要があります。ローカルProxyポートは、対象となるリクエストを本機のプロキシ入口に接続するためのものです。設定場所も役割も異なり、ローカルポートを変更してもリモートサービスの待ち受けポートは変わりませんし、リモートの認証エラーも自動的には解消されません。トラブル対処の前に、どちらのポートを編集しているか確認し、対応するアドレスも記録してください。

プロキシの入口はアドレス、ポート、プロトコルの組み合わせで構成されます。ポート番号だけでは接続できません。SOCKS5専用の入口にHTTPで接続したり、リモートアドレスとローカル待ち受けポートを組み合わせたりすると、接続に失敗する可能性があります。現在のアプリで利用できる機能と実際の用途に基づいて設定してください。Webページでよく見かける番号をデフォルト値とみなしたり、ポート番号の大きさを性能の目安にしたりしないでください。

待ち受けアドレスによって、どこから入口にアクセスできるかが決まります。本機だけからアクセスできるアドレスと、ローカルネットワークからアクセスできるアドレスでは、適用範囲が異なります。画面に関連する設定がある場合は、説明を読んでから選択してください。公開範囲を広げると、同じネットワーク上のほかのデバイスから接続を試みられる可能性があります。アクセス範囲と認証機能を確認し、複数デバイスから利用する明確な必要がなければ、必要最小限の範囲を維持してください。一時的に公開した場合は、テスト後に元へ戻します。

有効になる条件、競合、到達性を確認する

ローカル待ち受けの利用可否は、アプリの接続状態、有効な機能、システムのネットワーク条件に左右される場合があります。まずアプリが想定した状態で動作しているか確認し、次にプロキシを利用する側のデバイスでアドレスとプロトコルを確認してください。設定画面にポートを保存できたからといって、常に待ち受けているとは限りません。本機から利用できても、ほかのデバイスから必ず接続できるわけではありません。それぞれ異なる経路を使ったテストです。

ポートの競合やバインド失敗が表示された場合は、まず元のエラーを保存し、同じ待ち受け位置を別のサービスが使用していないか確認します。有効な数値範囲に含まれていても、すべてのポートが現在の用途に適しているとは限りません。システムの制限や既存サービスもバインドに影響します。用途に合った使用可能な値を選び、変更後に保存され、有効になったかを確認してください。原因を隠すために数字を次々とランダムに入力しないでください。

ローカルネットワークからのアクセスには、デバイスが互いに通信できるネットワーク上にあるか、Wi-Fiでデバイス間通信が制限されていないか、アドレスが変わっていないかも関係します。ゲストネットワークではインターネットを利用できても、デバイス同士が直接通信できない場合があります。まず基本的な通信が可能か確認し、その後Proxyの入口を調べてください。すべての失敗をShadowrocketの問題と決めつけないでください。共有ネットワークでは慎重に扱い、一時的なテスト後はアクセス範囲を元に戻します。

確認項目デフォルト値の確認方法設定を選ぶときの目安
リモートサーバーのポート手元のサーバー情報を確認リモートの実際のサービスと一致させる
ローカルProxyポート現在のアプリに表示される値を確認用途に合い、待ち受けの競合がないこと
待ち受けアドレス現在のアプリに表示される値を確認必要最小限のアクセス範囲
入口のプロトコル現在利用できる機能を確認利用側の設定と一致させる

変更後の確認と元に戻す方法

ポートを変更したら、段階ごとに確認します。入口に到達できるか、プロトコルが一致しているか、リクエストがアプリに届くか、ルーティングが想定どおりか、接続先から応答があるかを調べてください。前の段階が成功しても、次の段階が成功するとは限りません。アプリにリクエストが届いているのに接続先がタイムアウトする場合は、サーバー接続とルールを確認します。入口にまったく到達できない場合は、リモートサーバーをすぐに変更せず、待ち受け状態とネットワークの範囲を先に確認してください。

Settingsの変更には、共通の確認手順を使えます。元の値を記録する、変更の目的を明確にする、1つの項目だけを変える、固定の接続先でテストする、Logを確認する、正常だった機能も再テストする、有効な変更だけを残してほかを元に戻す、という順です。明確な改善がない変更は、元の値に戻すことを優先してください。設定を少数に保ち、理由を説明できる状態にすると、役立つかもしれないスイッチを増やし続けるより管理しやすくなります。

アプリを更新した後、すべての設定を機械的にやり直す必要はありません。ただし、よく使うオプションや重要な操作が引き続き想定どおりか確認してください。更新はApp Storeを通じて行い、具体的な変更点はストアページとアプリ内表示で確認します。古いスクリーンショットから新しい画面を推測しないでください。まず普段の接続、Configの選択、必要なOn Demandの動作をテストします。違いが見つかった場合は、データを消去して最初からやり直すのではなく、元のデータを保ちながら項目ごとに確認してください。

最後に、同じ状態を再現できるようメンテナンス記録を整理します。使用したネットワーク、Config、サーバー項目、Global Routing、変更したSettingsを記録してください。実際の認証情報は不要ですが、再度同じ環境を作れる内容にします。未解決の問題があれば該当する章に戻って確認してください。初回の操作は使い方ガイド、購入とデバイス要件はダウンロードページで確認します。各ページの役割に沿って参照できます。