Shadowrocket 設定ガイド

Settings / 設定範囲

設定範囲・初期値・変更履歴

アプリの設定とリクエスト処理を分けて考える

Settingsだけですべてのネットワーク動作が決まるわけではありません。Homeで選択したサーバーは転送先を決め、Global RoutingはConfigのルールを使うか、ProxyまたはDirectを一律に選ぶかを決めます。Configにはルールと関連パラメータが保存され、Settingsにはアプリの接続、テスト、表示、メンテナンスに関する項目があります。トラブルの切り分けでは、まず問題がどの層にあるかを確認してください。Webサイトへの接続先が想定と異なる場合、テスト用パラメータを変更しても解決しないことがあります。Widgetの表示が更新されていない場合も、表示だけでルールの不具合とは判断できません。

設定を変更するときは、画面上の場所、現在の値、変更したい動作、効果の確認方法を記録しましょう。たとえばDNSを変更するなら、テストの数値を小さくするのではなく、特定のドメインを安定して名前解決できることを目標にします。On Demandを調整する場合は、指定したネットワーク条件で想定どおりに接続することを確認します。バックグラウンドでアプリが常に表示される状態を目指すものではありません。目標を再現可能な操作として記録すれば、設定が実際に機能したかを判断しやすくなり、無関係な変更も見つけやすくなります。

初期状態の考え方

「初期値」には少なくとも3つの意味があります。初回起動時に表示されるアプリの値、Configを読み込んだ後にファイルに記載されている値、システムが現在のネットワークから取得している値です。これらは一致するとは限りません。データの復元、iCloud同期、Configの切り替え後に表示される内容も、工場出荷時の状態とは呼べません。本マニュアルでは、端末で直接確認できない初期値を推測しません。推奨するのは、検証済みの設定を維持して余計な変数を減らすことであり、すべての端末に同じ値を入力することではありません。

元に戻せる変更手順を作る

変更を始める前に、現在正常に動作するConfigのコピーを保存し、選択中のサーバー、Global Routing、ネットワークの種類、接続スイッチの状態を記録します。記録には項目名と変更内容だけを書き、サブスクリプションの完全なURLやパスワードを公開ページに貼り付けないでください。その後、一度に1項目だけ変更して保存し、画面の指示に従って接続を確立し直し、同じアクセス操作で確認します。サーバーの変更、DNSの変更、ルールの切り替えを同時に行うと、復旧してもどの操作が原因を解消したのか分かりません。

「保存済み」と「新しい接続に適用済み」は異なる状態です。一部のパラメータは、トンネルの再確立や新しいリクエストの開始後に反映されます。既存の接続は以前の経路を使い続ける場合があります。検証するときは、まず以前のテストリクエストを停止し、必要に応じてクライアントの接続をいったん切ってから再接続し、新たにアクセスしてください。ダウンロードや通話などの通信中に設定を何度も切り替えるのは避けましょう。切断そのものがトラブルのように見え、Logと変更内容を対応づけにくくなります。

推奨する基本方針は、すべてをリセットすることではなく、動作を説明できる現在の設定を保つことです。明確な必要がなければ、テスト方法、ポート、同期範囲、自動接続条件は変更せず、問題が起きたときに本ページの該当箇所を確認してください。アプリの入手元を確認する場合は、正規アプリの確認方法を参照し、開発者名Shadow Launch Technology LimitedとアプリID 932747118を確認してください。購入やインストールの問題はApp Storeの手続きで対応し、ネットワーク設定の変更で代用しないでください。

DNS / ドメイン名の解決

DNS設定と名前解決の経路

DNSが担うのは名前からアドレスへの変換

DNSはドメイン名をネットワークアドレスに変換するもので、プロキシ接続そのものとは異なります。アクセス時には、まずアドレスを取得し、その後ルールで接続先を決める場合があります。また、宛先名の処理をプロキシ側で行うこともあります。具体的な経路はConfigやプロトコルによって異なります。そのため、サーバーテストが成功してもWebページが開かないからといって、DNSが原因とは限りません。ドメイン名を解決できても、接続先サービスへのアクセスが成功するとは限りません。名前解決、サーバー接続、ルール選択、接続先からの応答を分けて検証し、1つの結果で全体を判断しないようにしましょう。

まずConfigで現在使用中のファイルを確認し、DNSが明示的に設定されているかを調べます。そのうえで、Settingsに表示される端末上の関連項目と照らし合わせてください。入力欄が空だからといって、DNS処理がないとは限りません。他の設定を参照する意味で空欄になっている可能性があります。ファイルにdns-serverと記載されている場合は、その項目と関連する説明を確認し、別の画面に表示された値だけを変更しないでください。設定の優先関係が分からない場合は、ファイルをコピーして、実際に適用される値をコピー上で検証しましょう。

初期値の参照元と推奨設定

特別な名前解決の要件がなければ、現在正常に動作しているDNS設定を維持してください。システムのDNSを使う設定は比較の基準になりますが、すべてのネットワークに適しているとは限らず、すべてのリクエストがプロキシを経由しないという意味でもありません。以下の例はsystemの記述位置を示すものです。サーバー情報は含まず、個別のConfigを置き換える完全なファイルでもありません。変更前の値を保存し、名前解決の経路に影響する他の設定が現在のファイルにないか確認してください。

[General]
dns-server = system

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

「予備」を増やすためだけに、用途が分からないDNSアドレスを複数登録しないでください。参照先が複数あると、異なる結果が返るほか、タイムアウトやキャッシュの差が生じることがあります。別の名前解決方法を選ぶ前に、現在のアプリ画面またはConfigの構文がその形式に対応していること、利用中のネットワークから到達できることを確認してください。暗号化DNSでは、通信の暗号化、DNSサービスへの到達、接続先への到達をそれぞれ区別します。1つの条件を満たしても、リクエスト全体の成功を意味しません。

症状から名前解決の失敗を切り分ける

特定のドメインだけで失敗する場合は、スペル、接続先が現在も有効か、同じネットワークで同じドメインへのアクセスを繰り返したときの結果を確認します。互いに関係のない複数のドメインで失敗する場合は、Logに名前解決に関するエラーがないか調べてください。IPアドレスでの直接アクセスは、限られた参考情報にしかなりません。多くのサービスはドメイン名、証明書、リクエストヘッダーに依存するため、IPアドレスでアクセスできないからといってネットワーク全体に問題があるとは限りません。比較テストには通常のドメイン名を使い、証明書エラーをDNS障害と混同しないようにしてください。

Wi-Fiを切り替えたときだけ問題が起きる場合は、切り替え前後にネットワークへのログインが必要か、システムが利用可能な接続を確立したか、クライアントがトンネルを再確立したかを記録します。一部のネットワークではログインが終わるまで、名前解決や外部へのアクセスが正常にできません。その状態でDNSを書き換えると、本来の接続開始時の問題を見えにくくすることがあります。まずシステムのネットワークが基本的に利用できる状態に戻してから、Shadowrocketを検証してください。元のネットワークは正常で、別のネットワークでは失敗が続く場合、その違いを記録するほうがConfigを何度も差し替えるより診断に役立ちます。

キャッシュの影響で、変更後すぐに症状が変わらないことがあります。アプリ、システム、ブラウザ、接続先サービスには、それぞれ一部の結果が保存される場合があります。ページを1回更新しただけで結論を出さないでください。クライアントを再接続したら、以前のテストページを閉じて新しいリクエストを作成し、同じドメインへのアクセスを複数回試して、時刻と結果を記録します。キャッシュの消去は端末で提供される操作に従ってください。1つのドメインを検証するために、Configをすべて削除したり、アプリを再インストールしたり、無関係なデータを消去したりする必要はありません。

トラブル対処後は、使用したDNSの参照元、対象となるネットワーク、検証に使ったドメインをConfigのメモに記録してください。一時的なテスト値の効果を確認する前に、すべての端末へ同期しないでください。DOMAIN、IP-CIDR、名前解決の違いを確認するには、用語集をご覧ください。スイッチがオンなのにアクセスできない場合は、サーバー・モード・DNS・ルールのトラブル対処チェックリストで経路全体を確認してください。

Global Routing / Config

Global Routing、ルール、Configの優先関係

モードによってルールの使い方が決まる

Global Routingは、通信の接続先を判断する際に最初に確認する項目です。Configモードでは現在のConfigに従ってリクエストを処理します。Proxyモードではクライアントの処理対象となる通信をプロキシモードで処理し、Directモードでは直接接続モードで処理します。ここで説明しているのはクライアントの処理方法であり、端末上のすべてのシステム通信を一律に説明するものではありません。特定のルールを検証する前にConfigが選択されていることを確認してください。ファイルの記述が正しくても、Configが選ばれていなければ現在の動作を決める要因にはなりません。

ドメイン名やアドレスに応じて日常的に通信を振り分ける場合は、内容を確認済みのConfigを使うのがおすすめです。ProxyとDirectはトラブルの切り分けに役立ちますが、一時的な比較結果をそのまま恒久的な設定にしないでください。モードを切り替える際は元の値を記録し、テスト後に戻します。Directでアクセスできても、その時点での直接接続が可能だったことしか分かりません。Proxyでアクセスできても、Config内のすべてのポリシーが正しいとは限りません。モード、ルール、サーバーをそれぞれ検証し、互いの代わりに判断材料として使わないようにしましょう。

ルールの順序と最終マッチ

ルールは通常、上から順に確認されます。具体的なルールを広範囲に適用されるルールより前に置き、最終ルールでそれまでに一致しなかったリクエストを処理します。DOMAINは完全なドメイン名、DOMAIN-SUFFIXは該当するドメインのサフィックス、IP-CIDRとIP-CIDR6はアドレス範囲を対象にします。GEOIPはIPアドレスの地理情報で判定しますが、データベースやアドレスの割り当て状況にも左右されます。GEOIPでWebサイトのコンテンツの提供元を判断しないでください。また、1つのドメインに固定アドレスが長期間割り当てられるとも限りません。

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

例にあるドメイン名とドキュメント用アドレス範囲は構文の説明に使うもので、実際のサーバーではなく、汎用的な振り分け方法を推奨するものでもありません。PROXYは利用可能なプロキシ接続を前提とし、DIRECTは直接接続、FINALは残りのリクエストの処理方法を示します。最終ルールをDIRECTに変更すれば、一致しなかったリクエストの経路が変わります。Configを読む際は、対象ドメインを含む行だけでなく、その前にあるルールと最終ルールも確認し、実際にどの分岐が適用されるかを判断してください。

ファイル名より、選択されているファイルが重要

Configを読み込んでも、そのファイルが有効になったとは限りません。ファイルを編集しても、現在の接続がそのコピーを参照しているとは限りません。検証のたびにConfigに戻り、選択中のファイルと保存結果を確認してください。似た名前のファイルがある場合は、普段使う設定や一時テストなど、用途を個人用のメモに記録し、リストの位置だけに頼らないようにします。複数のセクションを含むファイルを編集するときは、対象のセクションだけを変更し、サーバー情報など必要な項目を残してください。断片をコピーした際に前後の設定を誤って削除しないよう注意しましょう。

自分で管理しているサブスクリプションとConfigファイルも、同じものとして扱わないでください。サブスクリプションの更新でサーバー一覧が変わることはありますが、ルールが変わるかどうかは読み込まれた内容と実際の操作によります。更新後にサーバーが見つからない場合、選択中の項目を確認し直す必要があるかもしれませんが、DNSを必ず再入力するという意味ではありません。更新前後の利用可能なサーバー、選択項目、現在のConfigを比較すると、データをすべて作り直すより原因を特定しやすくなります。認証情報を含むURLはご自身の端末内で管理し、公開のトラブル相談に載せないでください。

「同じドメインなのに経路が変わる」場合は、関連するドメインが複数ないか、アドレスの種類が異ならないか、古い接続が再利用されていないか、リソース取得時に転送されていないかを確認します。ページ本体と、ページ内の画像・動画・APIが異なるドメインを使うことがあります。Logで実際に失敗したリクエストを見つけ、その範囲に合わせて調整してください。ページのメインドメインにルールを1つ追加するだけでは、すべてのリソースをカバーできない場合があります。DOMAIN-SUFFIXを変更するときは適用範囲に注意し、1つの接続先を直すために無関係なリクエストまで変更しないようにしましょう。

On Demand / 接続の自動トリガー

On Demandと接続状態

自動接続は、接続が常に利用可能であることを保証しない

On Demandは、保存された条件に応じてVPN接続を開始する機能です。動作はシステムのネットワーク状態や端末で許可されている操作にも左右されます。サーバーの正常性を確認する機能ではなく、誤ったパスワード、接続できないアドレス、DNSの失敗を修正するものでもありません。手動接続が安定するまでは、自動トリガーの条件を追加しないことをおすすめします。サーバーとルールを検証してから有効にしてください。そうしないと、自動接続の試行が手動でのトラブル対処と重なり、接続がいつ開始したか、なぜ失敗したかを切り分けにくくなります。

VPN構成を初めて追加するときは、システムに許可を求める画面が表示されます。Shadowrocketの接続操作を実行していることを確認したうえで、システムの案内に従って許可してください。画面の内容や認証方法は、端末に表示されたものを確認してください。既存のVPN構成も、端末の管理ポリシーや他の接続状態の影響を受ける場合があります。許可できない、または接続状態がすぐに戻る場合は、まずシステムの案内を確認し、アプリのデータを何度も削除しないでください。システムでトンネルの確立が許可されていない場合、ルールの記述を変更しても解決しません。

条件、初期状態、推奨する選び方

端末のOn Demand画面を開き、現在有効かどうかと、すでに設定されているネットワーク条件を記録します。画面に表示される条件や選択肢は端末によって異なるため、すべての端末で同じ項目があるとは限りません。データ復元後の状態を初期設定でオフだったとみなすこともできません。まずは明確に検証できる条件を1つ設定し、相互に重なる複数の条件を一度に追加しないようにしてください。Wi-Fiごとに動作を分ける場合はネットワーク名を正確に確認し、同じ名前でも実際には異なるネットワークである可能性を考慮します。

自動接続を検証する際は、継続中の通信を停止し、開始時のネットワークとスイッチの状態を記録してから、ネットワークを一度切り替えます。システムの接続処理が終わるのを待って、実際のリクエストを行ってください。1回のテストで変更する条件は1つだけにし、Wi-Fi、モバイル通信、端末のロック前後の状態をそれぞれ記録します。ネットワーク切り替え直後の短い中断を長期的な障害と誤認したり、ステータスアイコンだけで判断したりしないでください。ネットワークの切り替え、トンネルの再確立、アプリからの新しい接続開始には時間差が生じる場合があります。

接続を切った後に再接続する場合

手動で接続を切った後すぐに再接続される場合は、On Demandが有効なままか、現在の環境がトリガー条件を満たしているかを確認してください。一時的に接続を停止するには、自動トリガーの設定を先に確認し、次に接続を切ってから状態を再確認します。条件を調べずにHomeのスイッチを何度もタップすると、切断と再接続が繰り返されることがあります。自動トリガーを無効にしても問題が起きる場合は、システムのVPN状態と操作時刻を記録し、接続に影響する他のシステム設定を確認してください。

Wi-Fiのログイン画面もよくある境界ケースです。一部のネットワークは、システムに表示される案内からログインを済ませて初めて正常に利用できます。ネットワークの準備が整う前に自動接続が始まると、待機が続いたりアクセスに失敗したりすることがあります。まずネットワークへの正しい接続方法を確認し、システムでログインを完了して基本的な接続を検証してから、On Demandの動作を確認してください。ネットワークに接続できていない段階でサーバーを何度も入れ替え、接続開始の問題をクライアント設定の問題と取り違えないようにしましょう。

端末をロックしたとき、アプリが前面に表示されていないからといってVPNが必ず停止するわけではありません。同様に、Widgetに接続中と表示されていても、現在のリクエストが成功したとは限りません。関連するネットワークコンポーネントの動作はシステムが管理するため、前面の画面だけからバックグラウンドの状態を判断できません。端末を再び操作できる状態にして新しいリクエストを行い、実際の状態とLogを照合してください。アプリを何度も開閉したり、スイッチを続けて切り替えたりすると、確認したい条件そのものが変わり、自動接続の安定性を判断しにくくなります。

最終的に残す条件は、「どのネットワーク状態で、いつ接続するか」を簡潔に説明できるものにしてください。例外条件が複数ある場合は、1つずつ検証して記録します。条件の数を増やす必要はありません。端末の買い替えやデータ復元後は、以前の条件が残っていても新しい端末のネットワーク環境が同じとは限らないため、改めて一通りテストしてください。初回の許可と接続手順はチュートリアルで確認できます。本ページでは、その手順を済ませた後の設定範囲を説明します。

Ping / Connectivity Test

Ping、テスト方法、結果の見方

テストが確認できる範囲を超えて結論を出さない

PingとConnectivity Testは接続状況を判断する手掛かりになりますが、テスト方法によって確認できる経路は異なります。サーバーアドレスへの到達性を調べるもの、通信接続を確立するもの、プロキシ経由でテスト先にアクセスするものがあります。まず端末で選択されているテスト方法と対象を確認してから結果を解釈してください。リストに応答時間が表示されても、対象のWebサイト、ルールを含む経路全体、すべてのプロトコル機能が検証されたとは限りません。結果が表示されない場合も、テスト方法に対して接続先ネットワークが応答していない可能性があります。

基本的なネットワーク確認、ポートへの接続、プロキシ経由のリクエストは、それぞれ異なる処理です。サーバーが特定の確認方法に応答しなくても、プロキシ接続は正常に受け付ける場合があります。反対に、ポート接続がすぐに確立しても、認証や後続の転送で失敗することがあります。そのため「数値が小さいのにWebページが開かない」という結果に矛盾はありません。テスト結果を解釈するときは、実際のプロキシプロトコルを使ったか、認証が完了したか、テスト対象が問題の起きているサービスと同じかを明確にし、部分的な成功を全体の成功とみなさないようにしましょう。

初期のテスト方法と推奨パラメータ

Ping画面の初期のテスト方法、タイムアウト、テスト対象は、端末に現在表示されている内容で確認してください。設定を復元したり使い方を変えたりした後も、すべての端末で同じとは限りません。既知のテスト方法を維持し、同じ対象を使って変更前後を比較するのがおすすめです。タイムアウトが短すぎると通常の変動を失敗と判定することがあり、長すぎると待ち時間が延びますが、失敗した接続が利用可能になるわけではありません。待ち時間の設定に問題がある根拠がない場合は、数値を変更する必要はありません。すべてのテスト項目をまとめて変更するのも避けてください。

テスト対象には、安定していて明確で、現在の問題を検証するのに適したものを選びます。アプリでテスト対象をカスタマイズできる場合は、入力形式が画面の要件に合っているか確認してください。認証情報を入力したり、ログイン後にしか開けないページを使ったりしないでください。対象側のリダイレクト、アクセス制限、メンテナンス、証明書の問題も結果に影響します。テスト対象を変更する場合は、比較できるよう以前の対象も記録し、テスト条件が変わったことを明確にしてください。新旧の数値をそのままサーバー性能の順位として比較することはできません。

再現可能なテストセットを作る

シンプルな検証手順を用意します。一定のネットワーク環境で現在のサーバーをテストし、同じGlobal RoutingとConfigを使って対象にアクセスした後、失敗したリクエストのLogを確認します。数回繰り返し、失敗が続くのか、断続的なのか、特定の操作後だけ発生するのかを記録してください。特にネットワークが不安定な環境やサーバーの同時接続数に制限がある環境では、大量のテストを同時に実行しないでください。テスト自体も接続リソースを消費するため、同時に多くのテストを行うと、日常的な単独アクセスとは異なる症状を引き起こすことがあります。

サーバーテストは正常なのにWebページが開かない場合は、対象ドメインの名前解決、ルールの適用、認証、接続先からの応答を順に確認します。テストは失敗するのにWebページが開く場合は、利用可能なサーバーをすぐ削除せず、テスト方法が適切かを確認してください。特定のサーバーだけ失敗が続く場合は、利用中のサービスから提供されたアドレス、ポート、プロトコルパラメータ、有効状態を照合します。これらの情報は元の提供元に確認してください。タイムアウトを何度も延長して正しい値を推測しないでください。

TLSを使う接続では、サーバーアドレスと証明書の検証に使う名前も区別する必要があります。正しい設定でも両者が異なる場合があるため、具体的な要件はご自身のサーバー情報を確認してください。証明書の検証に失敗したからといって、検証要件を下げることを通常の対処にしないでください。端末の日時、名前の入力、証明書チェーン、サービスの状態を確認します。ポートへの接続が成立したことから分かるのは、通信の最初の段階で応答があったことまでです。暗号化のネゴシエーションや後続のリクエストが完了したとは限りません。

テストが終わったら、一時的に変更した対象や方法を元に戻し、維持するパラメータを変更履歴に記録してください。特定のネットワークでのみ問題が起きる場合は、同じ条件で少なくとも2回分の結果を記録してから、Logで段階を特定します。プロトコル項目の名称は機能と設定の解説および用語集で確認できます。これらのページでは用語を解説します。本節では、テスト結果からどこまで判断できるかを説明します。

Log / Data

Log、リクエスト記録、トラブル対処の手掛かり

1つのリクエストに絞ってLogを読む

Logは現象がどの処理段階で起きているかを特定するためのもので、すべての記録を1行ずつ解釈する必要はありません。トラブル対処を始める前に、時刻、ネットワーク、サーバー、Global Routing、Configを記録し、失敗する操作を1つ実行します。その後、該当する時刻の記録だけを確認し、ドメイン名、接続先、ルール、エラー情報の関係を調べてください。Webページを1回開くだけでも多くのリソースリクエストが発生するため、最初に表示されたエラーがページ全体の利用を妨げているとは限りません。

まずリクエストがクライアントに届いているかを確認し、次に名前解決の結果、適用されたポリシー、接続の確立、接続先からの応答を調べます。記録に対象が見つからない場合も、すぐにルールが正常だと判断しないでください。リクエストを再送していない、アプリのキャッシュが使われている、異なるシステム経路を通っている、現在の記録方法がその情報を含んでいない、といった可能性があります。明確な新しいリクエストをもう一度行い、Logの範囲を確認してください。決まったエラー用語だけを検索するより、処理段階を絞って調べるほうが確実です。

記録範囲と初期状態

Logに表示される内容や詳細度は、端末で利用できる設定と現在の状態によって異なります。一部の詳細は該当する記録を有効にしてから表示されますが、有効にする前のリクエストが後から補完されるわけではありません。日常的には基本的な確認に必要な記録方法を維持し、問題を再現する短い時間だけ詳細度を上げることをおすすめします。記録を増やすと、保存容量や処理負荷が増えるほか、アクセス内容がより多く記録される場合があります。診断後は元の設定に戻し、不要になった記録は必要に応じて削除してください。

Logのエラーは多くの場合、処理段階で発生した結果であり、最終的な原因とは限りません。たとえばタイムアウトは、アドレスに到達できない、サーバーが応答しない、接続先からの応答待ち、ネットワーク切り替えなど、さまざまな原因で発生します。1つの用語だけで原因を特定せず、発生前後の記録を関連づけ、実際の操作時刻と照合してください。1つの設定を変更してエラーが起きる段階が変わった場合も記録します。名前解決の失敗から接続の失敗に変化したなら、リクエストが次の段階まで進んだことを示しますが、全体が復旧したとは限りません。

Dataと接続状態の違い

Dataに表示される通信量や関連統計は、一定時間内にデータ通信があったかを確認する参考になりますが、接続先サービスから正常な応答があったことを示すものではありません。累積値には他のバックグラウンドリクエストが含まれる場合があり、以前の接続のデータが残ることもあります。まず現在の画面で統計が対象とする時間範囲を確認してから、短時間で比較してください。範囲が分からない場合は、累積値の変化から特定のルールが適用されたと推測しないでください。対象を正確に特定するには、該当リクエストの記録と再現可能なアクセスを主な判断材料にします。

問題が断続的に起きる場合は、まずConfigを変更せず、再現条件を明確にします。ネットワークの切り替え、端末のロック、サブスクリプションの更新、継続中の通信と関係があるかを記録し、同じ条件で回数を絞ってテストしてください。失敗するたびに別の設定を変更すると、結果を比較できなくなります。安定した基準のConfigと、1項目だけ変更したコピーを残しておけば、元の状態を忘れずに済み、復旧が一時的な選択に依存していたかも確認できます。

記録を整理するときは、サブスクリプションのURL、サーバーの認証情報、個人ドメイン、端末情報を保護してください。必要な時間帯だけを切り取り、エラーの種類、ルールキーワード、発生段階を残し、認証データや個人を特定できる情報を取り除きます。ConfigとLogを一緒に公開しないでください。パスワード欄を隠せば機密情報がすべて消えるわけではありません。サブスクリプションURLのクエリパラメータ、接続先アドレス、一部の名前から個人の利用情報が分かることもあるため、項目ごとに確認してください。

解決を確認したら、元と同じ条件で再度テストし、一時的に有効にした詳細ログを元に戻してください。過去のLogをすべて削除することを通常の修復手順にしないでください。記録の削除で変わるのは表示内容や容量であり、サーバーのパラメータやルールが自動的に修正されるわけではありません。手順の全体像は接続後にアクセスできない場合のトラブル対処ガイドも参考にしてください。まず症状から発生段階を特定し、その後で変更する項目を決めます。

Widget / iCloud

Widget、iCloud同期、端末の復元

Widgetは操作や状態確認の入口であり、すべてを診断する画面ではない

Widgetでは、システムが提供する場所から状態を確認したり、ショートカット操作を実行したりできます。具体的に利用できる内容は、端末で提供されるWidgetによって異なります。更新はシステムが管理するため、表示時刻と直前のネットワーク変更が完全に一致するとは限りません。WidgetとHomeの表示が異なる場合は、アプリを開いて現在のサーバー、接続状態、実際のリクエストを確認してから、表示が更新されるかを見てください。表示の遅れを直すためにConfigを書き換えたり、Widgetの文字だけを見て接続が続いている、または停止したと判断したりしないでください。

Widgetを追加するには、システムの編集画面からShadowrocketを選択し、現在のWidgetで設定できる項目を確認します。関連項目を選べる場合は、まだ存在していて用途に合う項目を参照しているか確認してください。データの復元、名前の変更、古い項目の削除後には、以前の選択内容を見直す必要がある場合があります。まず用途が分かるシンプルな表示を使い、意味が似たショートカットを複数並べて、状態を確認せずに接続操作を連続して実行しないようにしましょう。

同期するデータと購入資格は別々に確認する

iCloud同期は、アプリが同期に対応するデータを扱う機能です。App Storeの購入履歴とは別であり、現在のVPNセッションが端末間でそのまま移行されるわけでもありません。アプリの購入、設定の同期、接続を確立するための許可は、それぞれ独立した手続きです。新しい端末で購入履歴からアプリを入手できても、すべてのConfigが同期されたとは限りません。Configが表示されている場合も、端末上のネットワーク許可、サーバーの選択、ルールを確認してから接続を検証してください。

同期の初期状態と対象範囲は、端末のSettingsに表示される内容で確認してください。有効にする前に、システムのiCloudへのサインイン状態と関連するアクセス許可を確認し、端末で利用できるConfigのコピーを保存します。2台の端末で同じ内容を大幅に変更してから同期を待つのは避けてください。同期は履歴を無制限に保存するバックアップ機能ではなく、すべての古い値を復元できるとは限りません。重要なConfigの変更は、安全に管理できる場所にも復元可能なコピーを保存し、認証情報を保護してください。

同期の遅延と競合への対処

別の端末に変更が反映されない場合は、まず両方の端末でネットワークが使えること、iCloud関連のアクセス許可、アプリ内の同期状態を確認してください。その後、適切な時間待ってから内容を確認します。同期を促すために、読み込み、上書き、削除を続けて実行しないでください。2台の内容がすでに異なる場合は、それぞれのコピーを保存し、どちらを基準にするか決めます。自動で統合、上書き、競合内容の保持が行われるかどうかは、実際の画面で確認してください。本マニュアルでは、競合時の動作が常に一定とは想定していません。

端末ごとに適したネットワーク設定が異なる場合があります。iPhoneで使うモバイル通信と、iPadでよく使うWi-Fi環境では、On Demandの条件、テスト対象への到達性、ローカルポートの用途が異なることがあります。同期後は環境に関係する項目を改めて確認し、Configのファイル名が同じだからと検証を省略しないでください。同じConfigで最小限の接続を確立してから、自動トリガーとWidgetのショートカットを1つずつ戻すと、同期の成功をすべての設定がそのまま使える証拠と誤認しにくくなります。

端末の買い替えや再インストール時は、元の購入アカウントのApp Store購入履歴からアプリを入手してください。再入手の方法とユニバーサル購入の適用状況は、App Storeの掲載内容をご確認ください。次に、同期に対応するデータが復元されたか、サーバーとサブスクリプションの内容が現在も有効かを確認し、最後にシステムの案内に従って端末上の接続を許可します。詳しい手順は購入済みアプリの復元方法と機種変更後にShadowrocketを復元する方法をご覧ください。購入と同期の問題を一度に扱う必要はありません。

iPadでは、横向き表示や画面分割によって項目の位置が変わる場合があります。決まった画面上の位置ではなく、Home、Config、Settingsなどの画面上の項目名を目印にしてください。詳しくはiPadでの購入と画面表示の解説をご覧ください。復元後はWidgetの参照先とOn Demandの条件を改めて確認し、ショートカットから実際に利用するデータと一致していることを確かめます。

Proxy / ポートと切り戻し

Proxyポート、設定の範囲、切り戻しの確認

ローカルの待ち受けポートとリモートサーバーのポート

「ポート」を変更する前に、どちら側のポートかを確認してください。Add Serverに入力するサーバーポートは、利用中のサービスから提供された情報に基づき、リモートへの接続に使います。SettingsにローカルProxyの待ち受け項目がある場合は、端末内または許可された接続元からのプロキシリクエストに使われます。役割は異なるため、リモート接続の失敗を解決する目的でローカルポートを変更したり、サーバー情報にローカルポートを入力したりしないでください。変更前にアドレス、ポート、プロトコルを照合し、どの層の設定を変更するのか確認します。

ローカルのHTTPまたはSOCKS5接続方式と、リモートサーバーのプロトコルも別の概念です。接続元はローカルで実際に提供されている方式を使い、リモート側は保存済みのサーバーパラメータに従って動作します。ポートが待ち受け状態になっただけでは、DNS、ルール、リモートへの転送が検証されたとは限りません。ローカルProxyに明示的に接続するアプリや端末がなければ、現在の状態を維持し、通常のVPN接続のためだけに待ち受け機能を追加設定しないことをおすすめします。

初期ポートとアクセス範囲

ポート番号、待ち受け範囲、認証オプションは端末のSettingsで確認してください。本マニュアルでは、すべてのインストール状態に当てはまる固定値を指定しません。変更前に元の値を記録し、利用するアプリや端末にそのポートがすでに設定されているか確認します。ポートを変更した場合は、接続する側の設定も更新してください。片方だけ変更すると、接続拒否や待ち状態になることがあります。ポートの競合が発生したら、まず原因を確認し、最後に残した値を記録せずに複数の番号を次々に試さないでください。

端末内だけでの利用と、許可したローカルネットワークからの接続ではリスクが異なります。待ち受け範囲を広げる前に、現在のネットワークが信頼できるか、認証が提供され正しく使われているか、どの接続元からポートに到達できるかを確認してください。一度のテストを便利にするために、必要以上のアクセス範囲を長期間残さないようにしましょう。ローカルネットワークから接続できるかどうかは、ネットワークの分離設定やシステム状態にも左右されます。アプリで関連するオプションを有効にしても、すべての端末からアクセスできるとは限らず、アクセス範囲をさらに広げる必要があるわけでもありません。

Settingsでプロトコルパラメータの不足は補えない

Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2などのプロトコルには、それぞれ対応する項目があります。利用中のサービスから提供された情報を確認してください。アドレス、ポート、認証情報、転送方式、暗号化関連のパラメータが一致しない場合、Ping、Widget、Logの詳細度を調整しても不足項目は補えません。読み込み後もプロトコルの種類と必要なパラメータを確認し、特に手入力した内容は入念に照合してください。別の接続で使えた項目の構成を、現在のプロトコルにもそのまま当てはめないでください。

サーバー情報にドメイン名が含まれる場合、アドレスが変わってもドメイン名は有効なサービスを指し続けることがあります。名前の検証や後の更新に影響する可能性があるため、一度名前解決されたIPアドレスに安易に置き換えないでください。TLSの名前や転送経路などの項目は、提供された情報に明確な要件があればそのまま維持し、ポートテストに応答があったからといって削除しないでください。確認済みの入力ミスを一度に1つだけ修正し、実際に接続をテストします。変更前後のエラー段階も比較できるよう記録してください。

最後に検証できた状態へ戻す

トラブル対処後も復旧しない場合は、変更履歴を逆順にたどって元に戻します。まず一時的に変更したポートやテスト項目を戻し、次にDNSを戻して、以前のConfigとサーバーを再選択し、最後にOn Demandを確認してください。利用可能な基準設定とトラブルの手掛かりが同時に失われるため、すべてのデータを一度に消去しないでください。復元後は接続を確立し直し、同じ対象にアクセスします。元のConfigでも問題が起きる場合は、端末のネットワークと既存サービスの状態を確認し、変更がすべてクライアント設定の影響だと決めつけないでください。

購入方法とシステム要件を改めて確認する場合は、App Storeでの入手方法をご覧ください。Shadowrocketは有料の商用クライアントです。クライアントの買い切り購入と接続サービスの契約は別です。利用中のサービスが有効かどうかと、クライアントの購入状況は個別に確認してください。Settingsの適切な状態とは、すべての項目を変更することではありません。維持する値に明確な用途があり、自動動作を説明でき、問題が起きたときに最後に検証できた状態へ戻せることが大切です。