Shadowrocketの設定方法

01 / 設定元

ConfigとGlobal Routing

まず、現在どのConfigを使用しているか確認してから、Settingsの各項目が有効かどうかを判断します。Shadowrocketの接続結果は、一つのスイッチだけで決まるものではありません。Homeで選択したサーバーが接続パラメータを提供し、Configがルールなどの設定を保持し、Global Routingがルーティング方法を決定します。さらに、システムのネットワーク環境も接続に影響します。ユーザーがすでに利用しているサブスクリプションは通常、サーバー項目の管理に使われます。ルールを適用するConfigとは別のものです。サブスクリプションの更新に成功しても、ルールやDNSが更新されたとは限りません。

Config、Proxy、Directを区別する

Global RoutingのConfig、Proxy、Directは、それぞれConfigに従う、Proxy経由、Direct接続という3つのルーティング方法です。Configでは現在の設定にあるルールに基づいてリクエストを処理します。Proxyでは通信をProxy経由で処理し、Directでは直接接続します。これはルーティングの指定であり、すべてのリクエストが必ず成功することや、システム上のすべての通信をアプリが処理することを保証するものではありません。トラブルシューティングでは現在の設定を記録してください。Proxyの状態でルールを変更したあと、ルールが保存されていないと誤解するのを防げます。

ルールは数より順序が重要

ルールは通常、上から順に評価され、最初に一致した項目のポリシーが適用されます。DOMAIN-SUFFIXはドメイン自体とサブドメインに一致し、GEOIPは接続先アドレスを地理データベースに照らして判定します。FINALはそれまでに一致しなかったリクエストを処理します。範囲の広いルールを先に置くと、後続のより具体的な例外ルールが適用されない場合があります。編集時は対象ドメインに関係する項目を見つけ、その上にあるルールも確認してください。ファイルの末尾に正しそうな一行があるかどうかだけで判断しないでください。

[General]
dns-server = system

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

上記は構成の説明用であり、すべてのネットワークに適した完全な設定ではありません。example.comは例示用のドメインです。PROXYとDIRECTはポリシーを表すキーワードであり、サーバーアドレスとして入力するものではありません。ドメインルールで例示ドメインを確認し、次にGEOIPで該当するアドレスを処理し、最後にFINALで残りを処理します。実際に使う前に、手持ちのサーバーが利用可能であることを確認し、アクセス要件に合わせて各ルールを見直してください。マッチ範囲について詳しくはDOMAIN-SUFFIX、GEOIP、FINALのルール設定をご覧ください。

初期状態と推奨の基本設定

初期値は、インストール後の現在の表示と選択中のConfigで確認してください。Configの読み込み、データの復元、Configの切り替えによって、表示される状態が変わることがあります。ルールの内容を把握したうえで、通常はConfigを使うことをおすすめします。ProxyとDirectは比較やトラブルシューティングに使えますが、テスト後に元の設定へ戻すのを忘れないでください。基本状態を記録するときは、Config名、選択中のサーバー、Global Routing、テスト対象のリクエストを記録しておくと、後から変化の原因を判断しやすくなります。

ファイルの保存と設定の適用は、別々に確認が必要です。変更後、編集内容が保存されていることを確認し、そのファイルが現在有効なConfigであることを確かめてから、アプリの画面に従って接続状態を確認してください。既存の接続は以前の経路を使い続けることがあるため、開いたままのページを見るだけでなく、新しいリクエストを送信してテストします。それでも結果が異なる場合は、Logでリクエスト記録を確認してください。同じ内容をすぐに再インポートするのは避けましょう。

「サーバーのテストには成功するが、特定のドメインにアクセスできない」場合は、サーバーへの接続可否とルールの一致を分けて確認します。実際のリクエストの完全なドメイン名を調べ、サブドメイン、リダイレクト先のドメイン、異なるアドレスファミリーが関係していないか確認してから、適用されたポリシーを確認してください。すべてのリクエストが失敗する場合は、まず接続状態とサーバーパラメータを確認します。一部のリクエストだけ失敗する場合は、ルールとDNSに絞って調べます。初回接続の手順をやり直す場合はクイックスタートガイドに戻り、原因を隠すためにすべての設定を一度にリセットしないでください。

02 / 名前解決

DNS設定と名前解決の経路

DNSはドメイン名を接続先アドレスに変換する仕組みです。Proxyサーバーとは異なり、すべてのリクエストの経路を決めるものでもありません。DNSを調べる前に、問題の症状を確認してください。ドメイン名を解決できない、アドレスは返るが接続に失敗する、Webページの本文は表示されるが追加リソースを読み込めない、といった症状はそれぞれ異なる段階で発生しています。名前解決を直接疑うべきなのは、最初のケースです。それ以外はルーティング、サーバー、接続先サービス、接続ログも確認する必要があります。ページが開かない原因をすべてDNSに結び付けないでください。

まず現在のConfigのDNS設定を確認

DNSの動作は、Settings内の項目だけでなく、現在のConfigにも左右されます。確認する際は現在のConfigを開き、DNSサーバー、ドメインのマッピング、関連オプションが明示的に設定されているかを調べてから、アプリ画面の状態を確認してください。明示的な設定がない場合でも、すべてのネットワーク環境で同じ結果になるとは限りません。システムが利用する名前解決の条件は、Wi-Fi、モバイル通信、ネットワークへの接続状態によって変わります。あらゆるデバイスに共通する固定のDNSアドレスは指定していません。

Config内のdns-server = systemは、システムが提供するDNSを使う設定です。設定元を理解するための基本例であり、あらゆる状況におけるアプリの初期設定を示すものではありません。既存のConfigで名前解決方法が明示されている場合は、変更する前に元の設計を理解してください。この一行をファイル末尾に貼り付けるだけでは不十分です。該当する設定セクションに記述し、重複設定によって内容がわかりにくくならないようにしてください。変更前にファイル全体のコピーを保存しておけば、項目ごとに元に戻せます。

名前解決の通信とリクエストの経路を分けて考える

通常のDNSと暗号化DNSの違いは、名前解決リクエストの通信方法です。暗号化DNSを使っても、解決結果の正しさやアクセスの成功が保証されるわけではありません。暗号化された名前解決を使う場合は、まず名前解決サービスへの接続を確立する必要があります。接続先がドメイン名の場合、そのサービス自身のアドレスを調べる処理が先に必要となることもあります。設定が複雑すぎると、業務ドメインの解決を待つ一方で、DNSサービスへの接続も未確立の経路に依存するという診断の行き詰まりが生じます。そのような場合は、動作を確認済みのシンプルな基本設定に戻してください。

IPv4、IPv6、キャッシュの確認範囲

同じドメインからIPv4とIPv6の両方のアドレスが返されることがあります。いずれかのアドレスを解決できても、現在のネットワークや選択中のサーバーからそのアドレスへの経路が利用できるとは限りません。特定のアドレスファミリーでリクエストが失敗し続ける場合は、Logで実際に接続したアドレスを確認してから、ネットワーク環境を調べてください。どちらかのアドレスファミリーを無効にすることを、一般的な対処法として推奨することはできません。一時的にテストが成功しても元の経路の問題が隠れる可能性があり、正常な他のリクエストに影響する場合もあります。

キャッシュが原因で、変更後も結果が変わらないように見えることがあります。ただし、キャッシュはShadowrocketだけにあるわけではありません。システム、ブラウザ、アプリ、上流の名前解決サービスが結果を保持している場合があります。また、既存の接続では再度名前解決が行われないことがあります。検証時は現在のテスト接続を閉じ、新しいリクエストを送信してください。アプリに関連するキャッシュ削除機能がある場合は、削除対象を確認してから使用します。複数の場所で何度もデータを消去すると手間が増えるうえ、比較に必要な情報も失われます。

推奨設定と確認手順

特別な名前解決の要件がない場合は、現在正常に使えているConfigのDNS設定をそのまま使うことをおすすめします。変更が必要な場合は、用途と到達性を確認できているDNSサービスを使い、一度に変更するのは一項目にしてください。元の設定、対象ドメイン、返されたアドレス、適用されたポリシー、接続結果を順に記録し、同じネットワークで再テストします。実際に名前解決が行われたことを確認せず、Webページの表示速度だけを比べても、変化がDNS、キャッシュ、接続先サービスのどれによるものか判断できません。

アプリ内部で完結する名前解決、保持されている過去の接続、ネットワークリクエストの方式の違いにより、診断結果と特定のアプリでの挙動が一致しないことがあります。より確実に比較するには、同じネットワーク、同じGlobal Routing、同じサーバーで、同じ接続先へのリクエストを続けて試してください。DNSが妥当なアドレスを返しているのにアクセスできない場合は、DNSアドレスを何度も変更せず、LogとProxyポートの章で原因を調べてください。よくある接続トラブルはよくある質問で症状から確認できます。

03 / 接続の自動開始

On Demandによる条件付き接続

On Demandは、条件に応じてVPN接続を開始するための機能であり、ルールによる振り分けとは別の仕組みです。「いつ接続を試みるか」を決めるのがOn Demandで、「接続後にリクエストをどう処理するか」を決めるのがGlobal RoutingとConfigです。On Demandを有効にしても、誤ったサーバーパラメータが修正されたり、適切なルールが自動的に選ばれたりするわけではありません。設定する前に、手動接続で手持ちのサーバーが利用できることを確認してください。その後、動作を確認済みの接続を条件に応じて開始する設定を検討します。

現在の設定で初期状態を確認

他のデバイスの画面を見て、On Demandの初期状態を判断しないでください。初回インストール、システムデータの復元、VPN構成の追加、アプリ内の条件変更によって、現在の状態は変わることがあります。Shadowrocketでスイッチと条件を確認し、システムのVPN関連設定でも対応する構成を確認してください。VPN構成が複数残っている場合は、操作対象がShadowrocketで使用している構成であることを確かめましょう。過去の別の構成を誤って変更するのを防げます。

接続機能を初めて有効にするとき、システムからVPN構成の追加を許可するよう求められる場合があります。これはシステムに接続構成を登録するための許可であり、購入確認でもサーバーの接続確認でもありません。システムのダイアログを読み、内容を確認してから操作してください。許可を取り消した場合は、アプリに戻って画面の案内に沿って再度操作します。影響範囲を把握せずに他のシステム構成を削除しないでください。管理対象デバイスでは管理者による対応が必要な場合もあります。

推測で条件を増やさず、ネットワーク環境に合わせて設定する

現在の画面にWi-Fi、モバイル通信、特定のネットワークなどの条件が表示される場合は、それぞれの発動条件を確認してください。特定のWi-Fi名を識別できても、そのネットワークのすべての特性がわかるわけではなく、接続後すぐにインターネットへアクセスできるとも限りません。公衆Wi-Fiでは、接続確認の操作が必要な場合があります。また、同じネットワーク名が複数の場所で使われていることもあります。まずはシンプルで説明しやすい条件を設定し、必要に応じて例外を追加してください。互いに競合する条件を一度に多く設定するのは避けましょう。

テストでは少なくとも3段階を確認します。ネットワーク接続後に条件を満たすか、システムが接続を試みるか、接続後に目的のリクエストが完了するかです。スイッチがオンになっただけでは、最後の段階まで成功したことは確認できません。ネットワークを切り替えた前後の種類と時刻を記録し、アプリの状態とLogを確認してください。条件に応じて接続できてもリクエストに失敗する場合は、接続パラメータとルーティングを調べます。接続条件をさらに変更するのは避けてください。二つの異なる段階の問題が混同されるのを防げます。

手動切断後の再接続

条件付き接続を有効にしている場合、手動で切断しても、その後ずっと切断状態が保たれるとは限りません。ネットワーク条件を再び満たすと、システムが接続を再試行することがあります。一時的に自動動作を止めるには、まずOn Demandを一時停止してから現在の接続を操作し、システムの表示状態を確認してください。「切断してもすぐ再接続する」場合は、スイッチの不具合と判断する前に条件が引き続き有効かどうかを確認します。テスト後は必要な条件に戻してください。

スリープ、ネットワーク切り替え、接続の復旧

デバイスのスリープ、Wi-Fiとモバイル通信の切り替え、一時的なネットワーク切断によって、現在の接続が中断または再確立されることがあります。On Demandでこうした環境の変化をなくすことはできず、常時接続を保証する機能でもありません。ネットワーク切り替え後に一時的な接続障害が起きた場合は、ネットワークへの接続が完了するまで待ち、再接続の記録を確認してください。ネットワーク自体が復旧していない状態でアプリのスイッチを何度も切り替えても、失敗記録が増えるだけです。

推奨設定は使い方によって異なります。自動接続が必要な場合は、手動接続が安定していることを確認してから、必要最小限の条件を有効にします。原因を切り分けやすい環境が必要な場合は、一度のテストにつき一度だけ接続動作が行われるよう、条件付き接続を一時的に無効にしてください。「すべて有効にする」を一律の推奨設定としないでください。バッテリー消費、バックグラウンド動作、接続の安定性のバランスに、すべてのデバイスに共通する固定値はありません。実際の使用記録をもとに判断してください。

自動接続時だけ問題が発生する場合は、手動接続で成功したときと自動接続で失敗したときの記録を残し、ネットワーク条件、選択中のサーバー、現在のConfigを比較します。条件が同じなのに結果が異なる場合は、システム構成とアプリの状態を一項目ずつ確認してください。初回の許可と接続確認を最初からやり直す必要がある場合は、スタートガイドの手順に沿って進めます。On Demandのテストと同時にDNS、ルール、プロトコルの種類を変更しないでください。

04 / 接続テスト

PingとConnectivity Test

PingとConnectivity Testの結果は、特定の条件で実施したテストを示すものであり、サーバーの品質を総合的に評価するものではありません。一定の時間内に特定のテストが完了したかどうかは確認できますが、実際の通信を代替することはできません。数値が小さくても、すべてのページが速くなるとは限りません。タイムアウトしても、それだけでサーバー設定の誤りとは判断できません。数値を解釈する前に、テスト方法、対象、現在のネットワークを確認してください。

まずテスト対象の接続区間を確認

テスト方法によって、確認できる接続段階は異なります。基本的な到達性の確認、特定のポートへの接続試行、Proxy経由での接続先へのアクセスでは、必要な条件がそれぞれ異なります。選択できる方法は現在のアプリ画面で確認してください。「Ping」という名称だけを見て、特定のプロトコルを必ず使うと判断してはいけません。どの段階を経由するテストなのかを理解してはじめて、成功や失敗から何がわかり、何がわからないのかを判断できます。

たとえば、サーバーのポートへの接続に成功しても、その後の認証、TLSハンドシェイク、接続先へのアクセスまで成功したとは限りません。Proxy経由でテスト対象にアクセスできても、その時点でその接続先に到達できたことしかわかりません。サーバーによって、あるテスト方法は許可し、別の方法は制限している場合があります。また、テスト対象自体が一時的に異常な場合もあります。「テストには成功したがWebページが開かない」ときは、テストを繰り返すだけでなく、Logで実際のリクエストを確認してください。

テスト対象、タイムアウト、同時実行数

初期のテスト対象、タイムアウト、同時実行数は、現在のデバイスで直接確認してください。設定を復元した場合、インストール直後と同じ状態とは限りません。具体的な問題がなければ、アプリの現在のテスト設定を維持することをおすすめします。テスト対象を変更する場合は、用途を説明でき、現在のネットワーク環境で検証できるものを選んでください。ログイン情報や個人用トークンを含むURLをテスト先に使わず、一つのサービスへのアクセス結果をすべての通信の結果とみなさないでください。

タイムアウトは、テストでどれだけ待つかを示す値であり、接続に割り当てる帯域を増やすものではありません。短すぎると一時的な変動を失敗と判断する可能性があり、長すぎると複数の項目を確認するのに時間がかかります。同時実行数が多すぎると、限られたネットワークリソースをテスト同士で奪い合うことがあります。まず少数のサーバーと同じテスト対象で基本結果を記録し、必要に応じて調整してください。より小さな数値を求めて、すべての設定を何度も切り替えるのは避けましょう。

レイテンシ、スループット、安定性を分けて比較

レイテンシは一回の通信で応答を待つ時間、スループットは継続的なデータ転送能力、安定性は一定期間の失敗や変動を示します。互いに関係しますが、同じ指標ではありません。Webページの表示にはDNS、接続確立、暗号化のネゴシエーション、サーバー処理、リソースの読み込みなど、さまざまな段階があります。一回のテストで確認できるのはその一部です。サーバーを選ぶ際は、一覧の数値だけで並べ替えず、実際に必要な通信を考慮してください。

比較するときは条件をそろえることが重要です。同じデバイス、ネットワーク、接続先、テスト方法を使い、複数回の結果と失敗状況を記録します。Wi-Fiとモバイル通信を切り替えた後は、別の条件で得た結果として扱い、前の結果と混ぜて比較しないでください。テスト中にバックグラウンドで同期や大容量の転送を行っている場合も記録します。そうしないと、サーバー側の変動か、デバイス内の通信競合かを判断できません。

失敗時に分けて確認する

すべてのサーバーで同時に失敗する場合は、デバイスが実際にインターネットへ接続しているか、ネットワーク接続時の確認操作が残っていないか、テスト対象が利用可能かを確認します。一つの項目だけ失敗する場合は、その項目のアドレス、ポート、プロトコルパラメータを調べてください。サブスクリプションを更新した直後であれば、手動で残した古いコピーではなく、更新後の項目をテストしていることを確認します。プロトコルごとに必要なパラメータは異なるため、テストに通す目的で種類を別のものに変更しないでください。

変更の前後で同じ条件のテストを行い、実際のリクエストでも結果を確認してください。数値が改善しても問題の症状が変わらない場合、その変更を解決策とみなすべきではありません。Trojanの認証情報やTLSの項目を確認するには、Password、SNI、Allow Insecureの設定解説をご覧ください。プロトコルの項目は手持ちのサーバー情報に基づいて設定します。テストに失敗しても、証明書の検証要件を緩和する理由にはなりません。

最後に、再現可能な記録を残してください。テストの日時、ネットワークの種類、項目名、方法、対象、結果を記録します。パスワードやサブスクリプションのURLを記載する必要はありません。自分で識別できる名前を使ってください。「速いときも遅いときもある」という感想より、こうした情報のほうが原因の特定に役立ちます。設定変更後に再現性のある改善があったかどうかも判断しやすくなります。

05 / リクエストの記録

Logを使った接続トラブルの確認

Logは、接続時に起きたことを確認可能な段階に分けるためのものです。エラー表示を一つ見ただけで、すべての設定をすぐ変更するためのものではありません。失敗は、名前解決、ルールの選択、サーバー接続、認証、TLSハンドシェイク、接続先からの応答など、さまざまな段階で発生します。実際の操作に対応する記録を見つけ、どの段階で失敗したか確認してから、DNS、Config、サーバーパラメータのどれを変更するか判断してください。画面によって記録の詳しさは異なるため、現在のアプリに表示される情報を基準にします。

初期の記録状態と記録範囲

Logのスイッチ、記録レベル、保存方法は、使用中のデバイスで確認してください。特定のインストール時に表示された状態を固定の初期値として扱わないでください。通常は基本的な確認に必要な範囲で記録し、問題の再現時に限って詳細度を上げ、終了後に元へ戻すことをおすすめします。詳細な記録では、確認する情報が増え、リクエストに関する情報も多く含まれる場合があります。記録を有効にしても、過去のすべてのリクエストが取得されるわけではありません。対象の操作を始める前にテスト手順を決めてください。

有効な再現テストは、できるだけ短く行います。現在の時刻、ネットワークの種類、Global Routing、Config、選択中のサーバーを記録し、対象に一度だけアクセスしたら、すぐに該当する記録を確認してください。多くのアプリを同時に開いたり、ページを何度も再読み込みしたりすると、バックグラウンド通信に対象のリクエストが埋もれてしまいます。アプリにフィルターや検索機能がある場合は、ドメイン、時刻、接続情報で絞り込めます。ただし、曖昧な名前だけで、同じ接続の記録だと判断しないでください。

単語から推測せず、接続段階に沿って読む

まずリクエストのドメイン名またはアドレスを確認し、適用されたポリシーとサーバーを特定します。DIRECTが適用されていて、本来はPROXYを使うはずだった場合は、Configに戻ってルールの順序を確認してください。この場合、サーバーのパスワードを変更しても解決しません。ポリシーが想定どおりなら、名前解決が完了したか、接続を試みたか、その後に認証やハンドシェイクのエラーがあったかを確認します。特定の段階の情報がLogにない場合でも、その段階が発生しなかったとは限りません。現在の記録レベルでは表示されていない可能性があります。

接続のタイムアウトは、設定された時間を超えても応答がなかったことを示します。経路が利用できない、ポートに到達できない、リモート側が応答しないなどの原因が考えられますが、それだけではどちら側に原因があるか判断できません。認証エラーの場合は、まず手持ちのサーバー情報にある認証情報と照合し、コピー時の空白や入力欄の対応を確認してください。TLS関連のエラーでは、サーバー名、証明書、デバイスの時刻などを確認します。Allow Insecureを有効にすることを一般的な解決策にしないでください。証明書検証の範囲が変わります。

DataとLogは用途が異なる

Dataの統計とLogのリクエスト詳細は、それぞれ異なる目的で使われます。統計から一定期間の通信量の変化は確認できますが、特定のページが開かない原因まではわかりません。リクエスト記録は接続段階の特定に役立ちますが、通信量の完全な請求明細とは限りません。アプリ内の統計を、利用中のサービスの課金根拠として扱わないでください。集計基準、時間範囲、計算方法が異なる場合があります。トラブルシューティングでは、問題に対応する証拠を優先して確認してください。

アプリの画面でアクセスに失敗しても対応する記録が見つからない場合は、想定した接続方法を使っているか、古い接続を再利用していないか、リクエスト前にLogを有効にしていたかを確認してください。続いて、実際のリクエスト先のドメイン名を確認します。ページのリダイレクトやリソースの読み込みで、別の名前が使われていることがあります。ページタイトルで検索して見つからないからといって、リクエストがアプリを経由していないと判断しないでください。Logは通常、Webページに表示されたタイトルではなく、ネットワーク接続情報を基準に記録します。

エクスポート、情報のマスキング、復元

Logにはアクセス先のドメイン、IPアドレス、ネットワーク名、接続識別情報などが含まれる場合があります。エクスポート前に内容を確認してください。サブスクリプションのURL、認証情報、再利用可能な接続情報を公開してはいけません。一部だけを共有する場合も、前後に機密情報が含まれていないか確認してください。問題が起きた段階と項目の構成がわかれば、状況を説明できる場合が多く、設定全体を添付する必要はありません。ここに示すexample.comは例示用であり、実際の記録に含まれる情報を手作業でマスキングする代わりにはなりません。

修正後は、以前失敗した操作をもう一度実行し、新しい記録の経路が想定どおりか確認してください。エラーが消えていても、別のポリシーやサーバーに切り替わっている場合は、条件が変わった結果であり、元の問題が解決したとは限りません。原因を特定できない場合は、よくある質問のトラブル分類で確認箇所を絞り込んでください。ドメイン拒否ポリシーについては、REJECTの役割と適用範囲をご覧ください。意図的な拒否をネットワーク障害と取り違えないための説明です。

06 / ローカルとリモートの接続

Proxyポートとプロトコルパラメータ

まず、ポートがどこに属するかを区別してください。Add Serverのリモートポートは、手持ちのサーバーへの接続情報です。ローカルProxy設定の待ち受けポートは、デバイス上のProxy接続口です。通信先のサービスにも、そのサービス自身のポートがあります。数値がたまたま同じでも、同じ設定項目ではありません。ローカルの待ち受けポートを変更しても、リモートサーバーのポートの入力ミスは直りません。リモートポートを変更しても、無効なローカル接続口が使えるようにはなりません。

リモートパラメータは手持ちのサーバー情報に合わせる

サーバーの種類、アドレス、ポート、認証項目は、組み合わせて確認する必要があります。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard、HTTP、SOCKS5ではパラメータの構成が異なり、すべてのプロトコルに共通する入力方法はありません。手持ちのサーバー情報に従って種類を選び、項目を一つずつ入力してください。不明な項目を別のプロトコルの経験から推測したり、見慣れた種類に変えたりしないでください。

ポート番号は接続先を示す情報の一部にすぎず、プロトコルの種類やTLSの状態を単独で判断することはできません。よく使われる同じポート番号であっても、認証方法や通信方式がまったく異なる場合があります。TLSを含む設定では、サーバーアドレスと、名前の検証に使う項目をそれぞれ確認してください。常に同じ値であるとは限りません。各項目についてはTrojanの設定項目を確認し、パスワードをいろいろ試して判断しないでください。

ローカル待ち受けの初期値と調整

ローカルProxy機能の接続口、待ち受けアドレス、ポートは、現在のアプリ画面に表示される選択肢を確認してください。ここでは固定の初期ポートを指定せず、他のデバイスでの値をそのまま設定するよう求めることもありません。ローカルProxyを利用する具体的な目的がない場合は、元の設定を維持し、通常のWebアクセスを調べるために待ち受けを追加で有効にしないことをおすすめします。変更が必要な場合は、元の値を記録し、その接続口を使うアプリのアドレスとポートも合わせて更新してください。

ポート番号は待ち受けアドレスやプロトコルの種類と合わせて考える必要があります。ループバックアドレスは通常、デバイス内からのみアクセスできることを示します。LAN内のアドレスでは、他のデバイスからのアクセスが関わります。待ち受け範囲を広げると、アクセス可能な範囲が変わります。画面にLANアクセスの項目がある場合は、用途を理解したうえで有効にし、ネットワーク環境も確認してください。テストを通すためだけに範囲を広げないでください。また、システムのVPN構成とLAN内のProxy共有は同じ仕組みではありません。

ポートの競合と接続方式の不一致

利用側のアプリにローカルProxyへ接続できないと表示された場合は、まずShadowrocket側で該当する接続口が利用可能か確認し、待ち受けアドレス、ポート、プロトコルを照合してください。HTTP ProxyとSOCKS5では接続方法が異なるため、利用側のアプリでも対応する方式を選ぶ必要があります。ポートに適当なリクエストを送っても、すべてのプロトコルを確認したことにはなりません。ポートの競合が疑われる場合は、画面のエラー表示をもとに確認し、リモートサーバーを次々に変更するのは避けてください。

待ち受けポートを変更しても、利用側のアプリに設定された値は自動更新されません。ブラウザ、テストツール、Proxy設定に対応した他のアプリが、以前の接続先アドレスを引き続き使っている場合があります。古いテストを停止してから利用側の設定を更新し、新たに接続してください。システムの接続とアプリ内の個別Proxy設定を両方使っている場合は、テストがどちらの経路を通るかを明確にしてください。設定が重複すると結果を判断しにくくなります。

接続パラメータとセキュリティ検証は分けて確認

VMessとVLESSでは、名前だけを比べるのではなく、手持ちのサーバー情報をもとにUUID、通信方式、関連項目を確認してください。両者では使用するパラメータが異なります。WireGuardは専用の鍵、ピア、アドレス情報に基づいて設定します。パスワードとポートだけを入力する項目として扱わないでください。関連する概念はVMessとVLESSの違いとプロトコル用語集をご覧ください。これらは設定項目の説明であり、接続先の提供は行っていません。

推奨する確認順は、まずデバイスがインターネットに接続しているかを確認し、次にリモートの接続情報、プロトコルの認証とハンドシェイクを調べ、最後にテストで実際に使うローカル待ち受けを確認することです。変更後は同じ接続先に対して再テストし、Logで実際の経路を確認してください。手持ちのサブスクリプションを更新してポートや認証情報が変わった場合は、選択中の項目が更新済みか確認します。古い手動コピーとサブスクリプションの新しい項目を混ぜて使わないでください。根拠がなければ、複数のポートを一度に変更するより初期状態を維持したほうが、原因を特定しやすくなります。

07 / 状態確認の入口

Widgetとシステムの状態

Widgetは、アプリの状態を表示したり、用意された操作を実行したりするためのショートカットです。独立した接続機能ではありません。表示や実行できる内容は、使用中のシステム、アプリが提供するWidget、選択したスタイルによって異なります。他のデバイスのレイアウトを見て、同じボタンが使えると判断しないでください。Widgetに表示された状態だけで、実際のリクエストが成功したとみなすこともできません。接続状態を正確に確認するにはHomeに戻り、実際にリクエストを送信してください。

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

まずShadowrocket内でサーバーを選択し、Global Routingを確認して、手動接続をテストしてからWidgetを追加することをおすすめします。Widgetは初回のインポートを代わりに行ったり、不足している認証情報を補ったりするものではありません。初回操作でシステムからアプリを開いて許可するよう求められた場合は、案内に従ってアプリに戻ってください。Widgetを何度もタップしても、アプリを前面に表示して完了する必要がある手順を省略できません。状態の変化が繰り返され、確認しにくくなることもあります。

追加位置やWidgetのサイズは、システムの編集画面で設定します。Shadowrocketを選択し、現在利用できるスタイルの説明を確認して、必要な情報を表示するものを選んでください。デバイスやシステムの機能によって異なるため、固定の初期サイズやレイアウトは指定できません。追加後は、まず表示内容がHomeの状態と一致するかを確認し、その後でWidgetに用意された操作をテストします。最初の表示同期が完了する前に、Widgetが動作していないと判断しないでください。

表示の遅れは接続失敗を意味しない

Widgetの表示はシステムの更新方式に左右され、接続状態が変わるたびにすぐ更新されるとは限りません。バックグラウンドの状態、省電力条件、システムのスケジュールによって、表示されるタイミングは変わります。Widgetとアプリ内の状態が一時的に異なる場合は、まずアプリを開いて確認し、実際のリクエストで動作を確かめてください。Widgetの削除と再追加は表示上の対処方法の一つですが、あらゆる接続問題に対する最初の手順ではありません。実際の接続ログの確認にも代わりません。

On Demandとの関係

On Demandが有効なときにWidgetから切断しても、ネットワーク条件を再び満たすと新たな接続が試みられる場合があります。Widgetに別の隠れた設定があるのではなく、条件付き接続が引き続き有効なためです。Widgetの一度の操作を確認する場合は、まずOn Demandを一時停止し、タップの前後でHomeとシステムの状態を確認します。テスト後は元の条件に戻してください。自動接続の条件とWidgetのレイアウトを同時に変更すると、どの操作が結果に影響したか判断しにくくなります。

現在のサーバーやConfigを切り替えた後、Widgetの表示に反映されるまで時間がかかる場合があります。まずアプリ内の選択状態を基準にし、システムが用意する通常の方法で更新されるのを待ってください。Widgetをタップしてアプリが開いた場合は、システム画面が閉じたかどうかだけで判断せず、前面に表示されたアプリで実際の操作結果を確認します。ショートカットで減るのは操作手順であり、接続確認に必要な条件ではありません。

表示内容とプライバシーの範囲

Widgetは他の人から見える画面に配置される場合があります。サーバー名や接続状態が表示される場合は、名前に個人アカウント、利用目的、再利用できる接続情報を含めないでください。デバイス画面を共有する前に、アプリのウィンドウだけでなくWidgetの表示も確認します。Widgetはサブスクリプション情報を安全に保管するための機能ではありません。識別しやすくするために、サブスクリプションのURL全体を項目名に記載しないでください。

日常的には必要最小限の情報だけを表示し、アプリ内では識別できても機密情報を含まない名前を使うことをおすすめします。ショートカット操作が必要なければ、Widgetを追加しなくても設定済みの手動接続に影響はありません。表示に問題がある場合は、アプリ内の状態、システムの状態、Widgetの表示の違いを記録し、システムにWidgetが残っているかを確認してください。問題が表示だけに限られる場合に、再追加を検討します。ネットワーク設定をリセットするのは避けてください。

よくある状況は、Widgetが更新されない場合は表示を確認し、Widgetの操作が完了しない場合は前面での許可が必要かを調べ、接続済みなのにアクセスできない場合はDNS、Config、Logに戻って確認する、という3つです。この順で対処すると、古い表示を理由に正常な接続を何度も切断するのを防げます。ネットワーク切り替え後だけ問題が起きる場合は、On Demandの章で条件の変化を確認してください。初回接続がまだ完了していない場合は、まずガイドページに戻って基本手順を終えてから、ショートカットを確認します。

08 / データの復元

iCloud同期と設定の復元

iCloud関連の機能は、アプリが対応する範囲でデータを同期または復元するためのものです。すべてのデバイスであらゆる状態が完全に一致するとは限りません。現在の画面で同期対象、スイッチ、操作方法を確認してから有効にしてください。サーバー項目、Configファイル、システムのVPN許可、現在のネットワーク、接続状態はそれぞれ別の要素です。ある種類のデータが同期されても、他の要素は移行先のデバイスで個別に確認する必要があります。

初期状態とシステムの前提条件

初期の同期状態は、使用中のアプリとシステムで確認してください。利用前に、デバイスが想定したApple Accountにサインインしていること、システムでアプリのiCloud機能が許可されていること、現在のネットワークで同期できることを確認します。スイッチがオンでも、データのアップロードが完了したとは限りません。別のデバイスに内容がすぐ表示されないからといって、すぐに再インポートするのも避けてください。アプリ内の記録とシステム画面を合わせて確認します。

アプリの入手と設定の復元は別の手順です。機種変更後は、まずApp StoreからShadowrocketを入手し、その後にデータの復元と初回接続の許可を行います。システム要件、デバイスの互換性、購入の適用条件はApp Storeのページをご確認ください。正規の入手先を確認する方法は正規版を確認する3つのポイント、購入済みアプリの復元については機種変更後の再入手ガイドをご覧ください。同期機能を、複数デバイスで購入が適用される根拠として扱うことはできません。それぞれ別に確認してください。

基準にするデバイスを決めてから複数デバイスの変更を扱う

同期を有効にする前に、保持する完全なConfigがあるデバイスを決め、識別できるコピーを保存してください。重要な内容を2台のデバイスで同時に編集しても、意図どおりに統合されるとは限りません。両方のデバイスに異なるバージョンがある場合は、ファイルと項目を比較して、どちらを残すか決めてください。同期は内容を人が確認する作業の代わりにはなりません。用途がわからない重複項目も、確認前にまとめて削除しないでください。

日常用、テスト用、復元用のConfigをわかりやすい名前で区別することをおすすめします。ただし、名前にパスワードやサブスクリプションのトークンを含めないでください。新しいデバイスに復元した後は、項目数、重要なフィールド、Configの内容を確認してから、使用するサーバーとGlobal Routingを選びます。名前が同じでも内部の項目が異なる場合があります。リストのタイトルだけでは、完全に復元されたか、サーバーが現在も利用可能かは確認できません。

同期、バックアップ、サブスクリプション更新の違い

同期によって変更が他のデバイスに反映される場合があるため、古い状態を永続的に保持するバックアップと同じものではありません。サブスクリプションの更新は、手持ちのサブスクリプションが提供する項目情報を取得するためのもので、ローカルで行った変更の統合方法を判断するものではありません。長期間保存するConfigは、現在のアプリで利用できるエクスポートやバックアップ機能を使って別途保存し、保存先とアクセス権を明確にしてください。クラウドまたはローカルのデータを削除する前に、コピーを実際に読み取れることを確認します。

新しいデバイスでの確認と機密情報の管理

復元後は、必要最小限の確認手順を再度行ってください。デバイスがネットワークに接続していることを確認し、選択中の項目とConfigを確認します。システムの案内に従ってVPN構成を許可し、実際のリクエストを一度送信してください。On Demandは手動接続が正常になってからテストし、Widgetはアプリ内の状態を確認してから調べます。こうすることで、データ不足、許可の未完了、サーバーの利用不可を切り分けられます。一度の接続失敗だけで同期全体に問題があると判断せずに済みます。

エクスポートしたConfigには、サーバーアドレス、パスワード、鍵、サブスクリプショントークンが含まれる場合があります。接続認証情報と同様に慎重に保管してください。問題を報告するときは必要な構成だけを残し、ファイル全体を公開しないでください。ここでは、現在の画面の説明を超えて、同期対象の暗号化方式や保存期間を保証しません。データの取り扱い範囲については、プライバシーポリシーとシステムの説明もあわせて確認してください。削除する前に、操作が他のデバイスに影響しないかも確認します。

設定を元に戻す場合は、まず継続的に状態を変更する操作を一時停止し、内容を確認済みのコピーを復元してから、DNS、On Demand、テスト設定、現在のルーティング方法を一つずつ確認してください。故障の原因を見極めにくくなるため、「すべて初期設定に戻す」ことを最初の手段にしないでください。完了後は変更項目、変更前と変更後の値、確認結果を簡潔に記録します。次に問題が起きたときも、すべての設定を最初から試すより、最後に正常だった状態から調べるほうが原因を特定しやすくなります。