Shadowrocket トラブルシューティング大全

切り分けの基準を作る：スイッチがオンにならない、またはすぐ戻る

まず「スイッチの失敗」と「サーバー接続の失敗」を分ける

ShadowrocketのHomeスイッチは、システムにVPN構成の作成を要求します。スイッチをオンのまま維持できない場合、通常は通信がサーバーに到達する前の段階で問題が起きています。一方、サーバーのタイムアウトはシステムの通信経路は確立したものの、その後のサーバー接続が完了していないことを示します。両者では対処手順が異なります。確認時はウェブページが開くかどうかだけでなく、Homeスイッチの状態、システムのステータスバーに表示されるVPNマーク、選択中のサーバー、Global Routingの設定も同時に記録してください。スイッチをタップするとすぐ戻る場合は、まずシステムの権限と設定の競合を確認します。スイッチがオンのままでもウェブページを開けない場合は、次の章でサーバー、DNS、ルールを確認します。

初回起動時やシステムが権限を再確認する際、デバイスにVPN構成の追加を許可する画面が表示されることがあります。デバイスの認証を完了して初めて、Shadowrocketは対応する構成をシステムに作成できます。以前に許可を拒否した場合は、システムのSettingsでVPN構成が存在するか確認してから、Shadowrocketに戻って再試行してください。ここでアプリを何度も削除する必要はありません。まず権限の手順を確認することで、システム権限の問題をサーバーの問題と誤認せずに済みます。組織による管理、コンテンツ制限、ペアレンタルコントロールが有効なデバイスでは、VPN構成の変更が制限される場合もあります。その場合はシステムに表示される具体的な案内を確認し、デバイスの管理者にポリシーを確認してください。

同時刻に発生する接続競合を解消する

Appleプラットフォームでは、システム条件を満たすネットワーク拡張のうち、対応する通信を引き継げるものは同時に1つだけです。システムのSettingsに、接続中または自動的に何度も起動する別のVPN構成があると、Shadowrocketのスイッチが「接続中」のままになった後、元に戻ることがあります。切り分け時はまず他のVPN構成をオフにし、ShadowrocketのOn Demandも一時的にオフにして、Homeスイッチを手動で一度操作してください。On Demandの条件が現在のWi-Fi、モバイルネットワーク、ドメイン条件と一致していない場合、ユーザーが接続を切った直後にシステムが再接続したり、手動でオンにした後に条件が再評価されたりすることがあります。

On Demandをオフにするのは基準状態を作るためであり、この機能自体に異常があることを意味しません。手動接続が復旧したら、トリガー条件を1つずつ確認します。現在のネットワーク名が正しい分岐に含まれているか、モバイルネットワークの条件が想定どおりか、条件が「すべて満たす」なのか「いずれかを満たす」なのか、ルールが削除済みの構成を参照していないかを確認してください。1項目を変更するたびにネットワークを切り替えるか、システムが再評価するまで待ちます。複数の条件を同時に変更すると、どの項目で接続が復旧したのか分からなくなります。

最小限の変数で接続を復旧する

基準テストでは、情報が完全に確認できているサーバーを1つだけ残し、On Demandをオフにします。プロトコルのパラメータは一時的に変更せず、まず安定したWi-Fiで接続してください。失敗した場合は、モバイルネットワークに切り替えて比較します。同じ設定で2種類のローカルネットワークの結果が異なるなら、ルーター、ネットワーク接続、DNS環境に問題がある可能性が高くなります。両方のネットワークで失敗した場合に、サーバーアドレス、ポート、認証情報、プロトコルパラメータを確認します。1回のテストでサーバー、DNS、Global Routing、ルールファイルを同時に変更しないでください。複数の変数を変えると本当の原因が隠れてしまいます。

App Storeの購入履歴、アプリID、開発者情報を再確認する必要がある場合は、正規版を確認する3つのポイントをご覧ください。Shadowrocketは買い切り型のクライアントですが、クライアントの買い切りは回線プランを意味しません。接続に必要なサブスクリプションやサーバー情報は、ユーザーがすでに利用しているサービスの提供元から取得してください。アプリの購入状態によって、特定のサーバーが利用可能になるわけではありません。

スイッチはオンだが、ウェブページやアプリがインターネットに接続できない

3種類のGlobal Routingで範囲を切り分ける

Global RoutingのConfig、Proxy、Directは、「接続は成功したがネットワークを利用できない」問題を切り分ける主な基準です。Configでは、Config内のルールの順番に従って各リクエストの経路を決めます。Proxyでは通信を現在のサーバーに一律経由させ、Directでは直接アクセスします。テスト時は元の設定を記録してから、短時間だけDirectに切り替えてください。Directでもアクセスできない場合、問題はプロキシサーバーではなく、システムの通信経路、ローカルネットワーク、DNSにある可能性があります。Directは正常でProxyが失敗する場合は、サーバーの到達性とパラメータを確認します。Proxyは正常でConfigが失敗する場合は、ルールの順番、ポリシー名、FINALの結果を重点的に確認します。

設定状態の切り替えは診断のためにのみ行い、Proxyをルールの問題を隠す方法として長期的に使わないでください。Configに異常がある場合は、ルール自体を修正します。ルールは上から順に評価され、最初に一致した時点で判定が終了します。そのため、範囲の狭いDOMAIN、DOMAIN-SUFFIX、IP-CIDRは通常、より広いルールより前に置き、FINALは末尾に配置します。早い位置にあるREJECT、DIRECT、広範囲のDOMAIN-SUFFIXによって、後続の想定ルールが永遠に適用されなくなることがあります。

読みやすい最小限のルールセットを作る

以下の断片はルールの順序を示す例であり、実際のサービス情報ではありません。ポリシー名は、Configに存在するポリシー、またはアプリが対応する結果名と一致させてください。テスト時は、自分の既存設定にある正しいポリシー名でPROXYを置き換え、FINALが最後にあることを確認します。ローカルネットワークのアドレスにはDIRECTを使用すると、ルーターやローカルデバイスへのアクセスが遠回りになるのを避けられます。明示的なドメインルールはGEOIPとFINALより前に置き、Dataやリクエスト記録で適用結果を確認しやすくします。

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

Configファイルの読み込み後に、ポリシーが見つからない、ルールが無効、または通信全体が失敗する場合は、カンマ区切りのフィールドが完全か、ポリシー名の大文字・小文字が一致しているか、不可視文字が混入していないか、参照先のポリシーグループが実際に存在するかを確認してください。ファイルを読み込めたことだけで設定が有効だと判断しないでください。読み込み成功はテキストが受け入れられたことを示すだけで、すべてのサーバー、ポリシーグループ、ルールが実行できることを保証しません。まず少数のルールだけを残して確認し、その後に複雑なルールを段階的に戻します。

システム時刻、ネットワークのログインページ、IPv6の違いを確認する

デバイスの日付と時刻が大きくずれていると、TLS証明書の検証に失敗し、多くのHTTPSページが開けない一方で一部のローカルページは開けることがあります。システムのSettingsで日付と時刻の自動設定を有効にし、再接続してください。ホテル、学校、公共Wi-Fiでは、先にネットワークのログインページで認証が必要なことがあります。Shadowrocketに接続する前に一時的にスイッチをオフにし、ブラウザで通常のページを開いてログイン画面を表示し、認証後にオンにしてください。Wi-Fiでは正常でモバイルネットワークでは失敗する、またはその逆の場合は、両方のネットワークでDNSとIPv6の到達性を個別に確認し、1つの接続環境の制限をすべてのサーバーの問題とみなさないでください。

一部のアプリは古い接続をキャッシュすることがあります。Config、DNS、サーバーを変更した後は、Shadowrocketで接続を切ってから再接続し、問題のあるアプリを完全に終了して再起動してください。それでも失敗する場合は、機内モードを一度切り替えてシステムにネットワークインターフェースを再構築させます。デバイスの再起動は、権限、設定状態、ルール、DNS、ネットワークの比較を終えた後に行います。一時的な状態は解消できますが、誤ったサーバーパラメータやルール順序は修正できません。

問題が「スイッチがオン」の状態でのみ発生する場合は、サーバー状態、Global Routing、DNS、ルールを順番に確認する方法もご覧ください。短時間で確認できる現場向けチェックリストを掲載しています。

サーバーのタイムアウト、ハンドシェイク失敗、Connectivity Testの異常

「タイムアウト」をアドレス、ポート、プロトコルの3段階に分ける

タイムアウトには単一の原因があるとは限りません。まずサーバーアドレスをIPに解決し、次にポートへの通信接続を確立し、最後にShadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2などのプロトコルで認証とハンドシェイクを完了します。前の段階で失敗すると、後の段階には進みません。Connectivity Testの結果は、同じ時刻、同じローカルネットワークで複数の既存サーバーを比較するために役立ちます。ただし、1回の失敗だけでサーバーが永久に利用できないとは判断できません。ローカルネットワークの変動、DNSの一時的な失敗、サーバーのメンテナンス、パラメータの不一致でも似た症状が起こります。

Add Serverまたは既存の項目で、SERVER、ポート、パスワードまたは識別子、プロトコル種別、通信に関するフィールドを確認してください。情報をコピーする際によくある誤りは、アドレスの前後の空白、ポートの欠落、大文字・小文字の変更、メモをサーバーアドレスとして入力すること、QRコードやクリップボードの内容が古いことです。パラメータは、ユーザーが利用しているサービスの提供元から示された情報と1項目ずつ一致させてください。暗号方式、通信方式、TLS関連の値を経験だけで置き換えないでください。プロトコル名が同じでも、パラメータを交換できるとは限りません。

ネットワークを比較して、ローカルの遮断か遠隔側の異常かを判断する

Wi-Fiでタイムアウトする場合は、Shadowrocketを切断して通常のウェブページが開けることを確認し、同じサーバーをモバイルネットワークでテストします。その後、利用可能であることを確認済みの別のWi-Fiでも再確認します。同じサーバーが特定の接続環境でのみ失敗するなら、ルーターのDNS、IPv6、ゲストネットワークの分離、組織ネットワークのポリシー、ログインが必要なネットワークポータルを優先して確認します。異なる接続環境ですべてタイムアウトし、同じサブスクリプションの他のサーバーが正常なら、そのサーバーのアドレス、ポート、遠隔側の状態に問題がある可能性が高くなります。すべてのサーバーがすべてのネットワークで同時に失敗する場合は、サブスクリプションの内容、システム時刻、DNS、設定全体が置き換わっていないかを確認します。

テストの順番を固定します。まず現在のサーバー、次に同じ設定内の別サーバー、その後にローカルネットワークを変更し、最後にプロトコルパラメータを変更します。これにより2つの軸で比較できます。サーバーを変えた場合だけ復旧するなら、システム経路とアプリの権限はおおむね正常です。ローカルネットワークを変えた場合だけ復旧するなら、サーバー自体は別のネットワークから到達できています。すべての組み合わせで失敗する場合は、誤ったDNS、期限切れの設定、システムのVPN状態、サービス提供元による全体的な変更など、共通要因を確認します。

遅延テストと実際の利用可能性の違いを理解する

遅延値は、特定のテストリクエストがその時点のネットワーク条件で往復した結果にすぎず、ウェブページの読み込み、動画転送、大容量ファイルのスループットと同じではありません。あるサーバーがテスト結果を返せても、現在のルールで目的のすべてのドメインにアクセスできるとは限りません。逆に、テストリクエストが遠隔側で制限されても、実際の通信には応答がある場合があります。そのためConnectivity Testは、実際のリクエスト記録と組み合わせて確認します。リクエストが送信されたか、どのポリシーに適用されたか、タイムアウト、接続拒否、名前解決失敗のどれが返ったかを確認してください。エラー表示は層によって意味が異なるため、すべてを「サーバーを変更する」だけで対処しないでください。

WireGuardやHysteria2などのプロトコルでは、より具体的な鍵、アドレス、MTU、通信パラメータが必要になることがあります。接続はできるものの一部のページが止まる場合、すべてのパラメータを先に適当に上げ下げしないでください。まずサービス提供元が示した完全なフィールドを確認し、初期値または明示された値でテストします。MTUが適切でないと、小さなリクエストは正常でも大きなレスポンスが止まることがありますが、同じ症状はDNS、経路品質、サーバー側の制限でも発生します。ローカルネットワークを切り替え、他のサーバーと比較して確認してください。

サーバー情報がサービス提供元によって変更されたことを確認した場合は、最新情報で既存の項目またはサブスクリプションを更新してください。本ガイドはクライアント内での読み込み、テスト、切り分け方法のみを説明するもので、サーバーやサブスクリプションの内容は提供しません。

Subscribeの読み込みまたは更新に失敗する

アドレスに到達できない、内容が無効、更新が反映されない状態を分ける

サブスクリプションの失敗は少なくとも3種類に分けられます。1つ目はSubscribeのアドレスにアクセスできないケースで、タイムアウト、DNS失敗、HTTPステータスの異常などが現れます。2つ目はアドレスから内容を取得できるものの、Shadowrocketが認識できるデータ形式ではないケースです。3つ目は画面上では更新完了と表示されるのに、サーバー一覧に期待した変化がないケースです。切り分けでは、どの段階で失敗したかを確認し、何度も削除して追加し直すことは避けます。ユーザーが利用しているサービス提供元から示された完全なサブスクリプションアドレスを使用し、リンク内のクエリパラメータも通常はアドレスの一部であるため、コピー時に省略しないでください。

まずSubscribe項目で、アドレスの先頭や末尾に空白がないか、プロトコルヘッダーが完全か、チャットアプリによる改行が入っていないか、サービス提供元によってリンクが変更されていないかを確認します。例示アドレスは構造を理解するためのもので、実際のサーバーを生成するものではありません。

https://example.com/sub?token=xxxx

同じアドレスが以前は更新できたのに突然失敗した場合は、まずローカルネットワークを変えてテストし、システムの日付とDNSを確認します。公共Wi-Fiのログインページ、ルーターのフィルタリング、一時的な名前解決の異常がサブスクリプションリクエストに影響することがあります。異なるネットワークでも明確なエラーが返る場合は、元のサービス提供元にアドレスの状態を確認してください。不明なページでサブスクリプション内容を変換したり、アクセス情報を含むリンクを知らないツールに送信したりしないでください。

更新ポリシーとローカル項目の関係を確認する

サブスクリプションの更新では、そのサブスクリプションが管理するサーバーが追加、変更、削除されることがあります。ユーザーが手動で作成したAdd Server項目とSubscribe管理項目は、切り分け時に分けて確認してください。更新前にサブスクリプショングループ内のサーバー数を記録しても、長期的な確認方法としては信頼できません。サービス提供元が内容を変更する可能性があるためです。代わりに、明確なサーバー名や更新時刻の表示を記録し、更新後にSubscribe項目の状態と選択中のサーバーが存在するかを確認します。

更新後もHomeが、削除済みまたはパラメータが変わった古い項目を選択している場合は、サブスクリプション内の有効なサーバーを選び直してConnectivity Testを実行します。Configのポリシーグループがサーバー名を参照している場合、名前の変更によってポリシーに空きが生じることもあります。その場合はサーバー一覧だけでなく、Configのポリシーグループのメンバーとルールの結果も確認してください。サブスクリプションの更新成功はデータが書き込まれたことを示すだけで、元のConfigから新しいデータを正しく参照できることを保証しません。

形式エラーと一部データの問題に対処する

返された内容の一部のフィールドだけに異常がある場合、アプリが一部の内容を無視したり、読み込み結果全体が想定外になったりすることがあります。不足しているフィールドを推測して手入力しないでください。元のSubscribe項目と現在利用できる設定を保持したまま、サービス提供元にShadowrocketに適した形式か確認します。サービス提供元がQRコードも提示している場合はScan QR Codeで読み込めますが、QRコードは別の伝達方法にすぎません。読み込み後もサーバーアドレス、プロトコル、メモを確認し、「スキャンできた」ことだけで「パラメータが正しい」と判断しないでください。

Import from Cloud JSONは、ユーザー自身が保存した対応データを読み込むために使用できます。ただし、クラウド上のファイルが現在の設定より古い場合があります。読み込む前に、バックアップの復元とサブスクリプションの更新を区別してください。バックアップは特定時点のローカル構成をデバイスに戻すもので、サブスクリプション更新は元のアドレスから現在の内容を取得します。古いバックアップで既存データを上書きした後は、Subscribeアドレス、サーバー選択、Config、On Demand条件を再確認してください。サーバー一覧が表示されたかだけで判断しないでください。

サブスクリプションはShadowrocketの購入内容ではありません。クライアントの買い切りは回線プランを意味しません。App Storeでの購入はクライアントを取得するためのもので、Subscribe内のデータはユーザーが利用しているサービスの提供元が管理します。新しいデバイスへ移行する場合は、設定のバックアップとデバイス変更後の復元手順も参照し、先にアプリの購入を復元してからローカル設定とサブスクリプションの状態を確認してください。

速度低下、読み込み停止、アプリごとの挙動の違い

ローカルネットワーク、サーバー、経路、プロトコルを段階的に測定する

速度が遅い場合は、まず具体的な症状を定義します。ページを開くまで長時間待つのか、継続的な転送速度が低いのか、画像や動画だけが止まるのか、特定のアプリだけに起きるのかを確認してください。症状によってDNS、接続確立、スループット、パケットロス、ルールの適用など、関係する層が異なります。切り分け前に大量の同期やダウンロードを停止し、テスト対象と時間帯を固定します。まずShadowrocketをオフにしてローカルネットワークを測定し、その後にオンにして現在のサーバーをテストします。異なる時間やウェブサイトを感覚だけで比較しても、信頼できる結論は得られません。

第1層はローカルWi-Fiまたはモバイルネットワークです。Shadowrocketをオフにしてもローカルネットワークに明らかなパケットロス、頻繁なネットワーク切り替え、弱い信号があるなら、後続の接続で変動が増幅されます。ルーターに近づく、品質の低いWi-Fiを切ってモバイルネットワークに切り替える、別の安定したネットワークで再テストすることで、基礎となる接続が主な原因か判断できます。第2層は現在のサーバーと経路です。既存設定内の複数サーバーをConnectivity Testで比較し、同じ対象ページも実際に開いてください。1回の遅延結果だけで選ばないでください。低遅延でも継続的なスループットが安定しているとは限りません。

第3層はプロトコルとパラメータです。プロトコルによってネットワーク条件ごとの挙動は異なりますが、パラメータは既存のサーバー情報に基づく必要があります。速度を求めて認証、通信、TLS設定を適当に変更しないでください。サービス提供元が複数の利用可能な項目を示している場合は、同じネットワーク、同じ時刻、同じ対象で比較します。第4層はルールです。同じアプリのドメインが異なるポリシーに割り当てられることがあります。ページ本体はPROXY、画像ドメインはDIRECTまたはREJECTになると、文字だけ先に表示されて画像が長時間空白になることがあります。

リクエスト記録からルールの分岐を見つける

Dataまたは対応するリクエスト記録で、問題が発生した時のドメイン、適用ルール、最終ポリシーを確認します。メインドメイン、静的リソースのドメイン、ログインドメイン、コンテンツ配信ドメインが同じ方向に処理されているかを重点的に見ます。一部のドメインが広すぎるDOMAIN-KEYWORDに一致している場合は、より正確なDOMAINまたはDOMAIN-SUFFIXに変更します。GEOIPが先に適用されて想定と異なる結果になる場合は、明示的なドメインルールをその前に移動します。ルールを変更した後は切断して再接続し、対象アプリも再起動してください。古い接続が以前の経路を再利用するのを避けるためです。

速度の問題を、すべての通信を長時間Proxyに切り替えて隠さないでください。Proxyは「ルールが問題に関係しているか」を確認するために使用し、Proxyが正常でConfigが遅いと分かったら、Configに戻ってルールを修正します。両方が遅くDirectが正常なら、サーバーと経路を確認します。3種類の設定状態すべてが遅い場合は、まずローカルネットワーク、DNS、デバイスの状態を確認してください。この3種類の比較は第2章と同じですが、本章では完全にアクセスできない場合ではなく、接続できている状態での性能差を扱います。

大きなレスポンスの停止とMTUの手がかりを確認する

小さなウェブページは正常でも、大きな画像や継続的な転送が止まりやすい場合は、MTUまたは経路上の分割の問題を候補にできます。ただし、すぐに原因と断定しないでください。まず異なるローカルネットワークとサーバーを比較します。特定のネットワークの組み合わせでのみ起こるなら経路の特徴が疑われ、すべての組み合わせで起こるなら、プロトコルパラメータ、デバイスの省電力状態、対象サービスも確認します。MTU設定が明示された構成では、ユーザーが利用しているサービス情報またはプロトコル要件を基準にし、一度に1つの値だけ変更して同じテスト結果を記録してください。むやみに繰り返し変更すると、さらに不安定になります。

テストは少なくとも2つの時間帯で行い、一時的な混雑を安定した結論と誤認しないようにします。ローカルネットワークの種類、サーバー名、Global Routing、対象アプリ、症状が発生する段階を記録して比較してください。同じサーバーの結果が時間帯によって大きく異なる場合、遠隔側の負荷や経路の変化が関係している可能性があります。すべてのサーバーが1つのWi-Fiだけで遅い場合は、ルーターと接続ネットワークを優先して確認します。より詳しい4層の確認は、サーバー、経路、プロトコル、ローカルネットワークを段階的に確認する方法をご覧ください。

DNSの名前解決失敗、異常な結果、一部ドメインにアクセスできない問題

すべてをネットワーク切断とみなさず、DNS障害を見分ける

DNSはドメイン名を接続可能なアドレスに変換します。典型的なDNS障害には、ドメイン名では開けないが既知のIPへ直接アクセスすると応答がある、一部のドメインでサーバーが見つからない状態が続く、Wi-Fiを切り替えると同じドメインが復旧する、初回リクエストが非常に遅いがキャッシュ期間中は正常になる、といった症状があります。TLS、ルールのREJECT、サーバーのタイムアウトでも似た症状が出るため、リクエスト記録のエラー種別と合わせて判断します。記録に名前解決失敗と表示される場合はまずDNSを処理し、対象IPを取得済みなのに接続がタイムアウトする場合はサーバーまたは経路の層を確認します。

ShadowrocketのDNSの実際の動作は、Config、システムネットワーク、IPv4、IPv6、ルール設定の影響を受けます。切り分け時は現在のDNS設定を記録し、すべてのフィールドを直接消去しないでください。現在の構成に適していることを確認済みのDNS方式を一時的に使用してテストし、Wi-Fiとモバイルネットワークで個別に観察します。特定のWi-Fiだけで失敗する場合は、ルーターが配布するDNS、ネットワークのログインページ、ローカルネットワーク上の書き換えが関係している可能性があります。すべてのネットワークで失敗する場合は、Configが到達不能なアドレス、形式の誤った設定、現在のルールと一致しない解決経路を参照していないか確認してください。

no-resolveとIPルールの関係を理解する

IP-CIDR、IP-CIDR6、GEOIPは対象IPに基づいて判断します。一部のルールにno-resolveが付いている場合、そのルールを実行するために追加のドメイン解決を発生させないことを意味します。不要な問い合わせを減らせますが、既存のIP情報がある場合にしかルールを適用できません。すべてのIPルールが自動的にドメインを解決すると誤解すると、なぜルールが適用されないのかを誤って判断します。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはドメイン名に直接一致するため、正確な振り分けが必要なIP系ルールより通常は前に置きます。

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

上記のローカルネットワーク用ルールは、マッチ方法を示すためのものです。デバイスからローカルネットワーク内のルーター、ストレージ、プリンターへアクセスする場合、DIRECTを使うと通信が遠隔側へ送られるのを避けられます。ただし、実際のアクセスはWi-Fiの分離設定やローカルネットワークの権限にも左右されます。ローカルIPにアクセスできない場合でも、必ずしもDNSの問題とは限りません。IPを直接使用している場合、ドメイン解決は行われないためです。まず対象がドメインかIPかを区別し、次にどの層で失敗しているかを確認してください。

キャッシュ、IPv6、暗号化DNSの相互影響を確認する

DNSを変更した後も、古い結果がアプリ、システム、接続のキャッシュに残ることがあります。Shadowrocketを切断して再接続し、対象アプリを完全に終了してから起動してください。必要に応じて機内モードも一度切り替えます。複数のDNSを連続して変更し、すぐに結論を出さないでください。キャッシュによって前後の結果が混ざるためです。あるドメインがIPv4とIPv6の両方を提供し、現在のネットワークのIPv6経路が不安定な場合、解決は成功しても接続が遅くなったりタイムアウトしたりすることがあります。異なる接続ネットワークを比較し、失敗したリクエストがどのアドレス種別を使用したかを確認してください。DNSが結果を返していないと単純に判断しないでください。

暗号化DNSを設定する場合は、そのサーバーのドメインを最初にどのように解決するか、DNSエンドポイントへの経路が現在のルールの影響を受けないかも考慮します。DNSエンドポイント自体が、まだ確立していない経路でしかアクセスできない場合、起動時の依存関係が生じることがあります。切り分けでは、まず構成で明示的に対応している基本方式に一時的に戻し、通常の名前解決が正常であることを確認してから、暗号化DNS設定を段階的に戻します。変更するたびに、以前から安定して失敗していたドメインと正常なドメインを1つずつテストし、全体的な解決障害か特定ドメインの異常かを判断してください。

異常なバッテリー消費、バックグラウンド動作、更新後の異常

バッテリー消費が継続的な通信か再接続の繰り返しかを判断する

Shadowrocketが接続中の場合、システムのネットワーク拡張を通過する通信を処理する必要があります。バッテリー消費は、デバイスの電波状況、通信量、プロトコル、ルールの複雑さ、ログ記録、接続の安定性によって変わります。まずシステムのSettingsにあるバッテリー使用状況を開き、確認期間内のShadowrocketのフォアグラウンドとバックグラウンドの動作を比較します。同時に、写真の同期、クラウドバックアップ、メディア再生、他のアプリによる継続的な通信も確認してください。他のアプリが通信を発生させている場合、Shadowrocketはその接続を処理することでバックグラウンド動作として表示されることがあります。割合だけを見てクライアント自体の異常と判断しないでください。

デバイスが発熱し、サーバーのタイムアウトが繰り返される、Homeの状態が頻繁に切り替わる、On Demandが何度も起動する場合は、再接続の繰り返しを重点的に確認します。まずOn Demandをオフにし、利用可能であることを確認済みのサーバーを1つ選び、安定したWi-Fiで手動接続して観察してください。復旧したら、Wi-Fiとモバイルネットワークの切り替え時にOn Demandの条件が競合していないか確認します。信号が弱いと、モバイルネットワークは接続維持のために消費電力が増えます。同じ設定が安定したWi-Fiでは正常で、弱い信号環境で明らかに発熱するなら、接続ネットワークも重要な変数です。

ログ、ルール、バックグラウンドタスクの影響を小さくする

切り分け中は、不要な長時間の詳細ログを減らし、Dataで特定のアプリが大量のリクエストを継続的に発生させていないか確認します。異常な再試行を起こすドメインは短い間隔で繰り返し現れ、通信量を増やすだけでなくネットワークを継続的に起動させます。まず、どのアプリからのリクエストか、どのルールに適用されたか、どのエラーが返ったかを確認してから、ルールまたは対象アプリのバックグラウンド動作を処理してください。似たドメインをすべて広範囲なREJECTで遮断しないでください。広すぎるDOMAIN-KEYWORDは正常な機能まで妨げ、新たな再試行を生むことがあります。

複雑なルールファイルだけがバッテリー消費の原因とは限りませんが、重複、相互上書き、順序の不合理なルールが多いと診断が難しくなります。現在のConfigを複製し、必要なローカルネットワーク用ルール、明示的なドメインルール、GEOIP、FINALだけを残した簡略版を作成して、同じ時間帯の接続安定性を観察します。簡略化後に問題が消えた場合は、元のルールを段階的に戻し、再試行や誤った振り分けを引き起こす部分を特定します。すべての設定を一度に削除するより安全で、復元経路も残せます。

更新後はすべての設定をすぐ作り直さず、まず状態の引き継ぎを確認する

App Storeで更新した後にスイッチの失敗、サーバーを選択できない、ルールの動作変化、画面状態の異常が発生した場合は、まずShadowrocketの接続を再起動します。Homeをオフにし、システムのVPNマークが消えるまで待ってから再度オンにしてください。その後、現在のサーバー、Global Routing、Config、DNS、On Demandが更新前と同じ項目か確認します。システム更新によってネットワーク拡張の権限が再評価されることもあるため、システムのSettingsでVPN構成が存在し、利用可能か確認してください。システム要件と対応範囲はApp Storeページの記載を基準とします。

設定内容は残っているのに、特定のサブスクリプションまたはサーバーだけが失敗する場合は、サブスクリプションとタイムアウトの章に従って確認し、すべてをアプリ更新のせいにしないでください。すべての設定で同じ問題が起きる場合は、まず重要な設定をエクスポートまたは記録してから、デバイスとネットワークを再起動します。ローカルデータを復元できるバックアップがあり、購入履歴をApp Storeから復元でき、サブスクリプションアドレスもユーザーが保存していることを確認してから、広範囲の再構築を検討してください。急いでデータを消去すると、一時的なシステム状態の問題が設定復元の問題に変わってしまいます。

Shadowrocketを入手できる唯一の入口はApp Store製品ページです。ページで開発者名Shadow Launch Technology LimitedとアプリID 932747118を確認できます。アプリの更新もApp Storeが管理するため、ネット上のバージョン情報でストアページの記載を代用しないでください。

iPad固有の確認：分割表示、キーボード、ローカルネットワーク、デバイス変更後の復元

まずiPadでの購入と設定の入手元を確認する

iPadのShadowrocketはiPhoneと同じApp Store製品ページを使用します。同じApple IDで購入済みの場合は、App Storeの購入済み項目から探して復元できます。具体的な対応範囲とシステム要件はApp Storeページの記載を基準としてください。初回起動時には、VPN構成の追加をシステムで許可する必要があります。iPhoneでは正常なのにiPadでスイッチをオンにできない場合は、iPadのVPN権限、デバイス管理ポリシー、On Demand条件、現在のネットワークを個別に確認し、2台のシステムネットワーク状態が完全に同じだと決めつけないでください。

iCloud、Configのエクスポート、Import from Cloud JSONで設定を復元した後は、「ファイルが表示された」ことと「設定で接続できる」ことを分けて確認します。まずサーバー項目とSubscribeアドレスを確認し、現在のサーバーを選択して、Global RoutingとDNSを確認し、最後にHomeをオンにします。バックアップが古い場合、サブスクリプション管理の項目は再更新が必要になることがあります。ポリシーグループが参照するサーバー名が変わっている場合は、Configも確認してください。詳しい手順は設定のバックアップとデバイス変更後の移行方法をご覧ください。旧デバイスからiPadへ移行する場合も同じ順番で確認できます。

分割表示、マルチウインドウ、キーボードによる画面の違いに対処する

iPadOSの分割表示とマルチウインドウでは使用できる幅が変わり、Home、Config、Settings、Dataの一覧と詳細が異なる配置になることがあります。ボタンが見つからない場合は、まず狭い分割表示を終了するかサイドバーを展開してください。iPhoneの固定位置を基準に探さないでください。接続状態はシステムのネットワーク拡張が維持するため、Shadowrocketのウインドウを閉じてもHomeの接続が切れるとは限りません。アプリまたはシステムのVPN状態に戻って確認します。複数のウインドウを同時に開いている場合は、Configを変更した後に、同じ設定と最新状態を表示しているか確認してください。

外付けキーボードでSubscribeアドレス、SERVER、パスワード、ルールを貼り付ける際は、全角記号、スマート引用符、自動スペース、改行に注意してください。ルール構文には半角の英語カンマが必要で、ポリシー名は既存の名称と一致させます。書式付きテキストから長押しコピーした内容には、不可視文字が混ざることがあります。見た目は同じなのに接続できない場合は、プレーンテキスト環境で再確認し、各フィールドを入力し直してください。Scan QR Codeで読み込んだ後も結果を確認し、スキャンが完了したことだけで判断しないでください。

ローカルネットワークのデバイスとWi-Fi環境へのアクセス

iPadはローカルネットワーク上のストレージ、プリンター、家庭内サービスへのアクセスに使われることがあります。Shadowrocketをオンにした後にローカルリソースへアクセスできなくなった場合は、まずIPアドレスでテストし、名前解決とネットワーク到達性を分けて確認します。一般的なローカルネットワークの範囲に対するDIRECTルールがFINALより前にあることを確認してください。IPではアクセスできるのにローカル名で失敗する場合は、ルーターのDNSまたはローカル名前解決を確認します。IPでもアクセスできない場合は、Wi-Fiのゲスト分離、同一サブネットかどうか、対象デバイスが現在のネットワークからのアクセスを許可しているかを確認してください。

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

学校、会議場、ホテルのWi-Fiでは、iPadで先にログインページを完了する必要がある場合があります。Homeをオフにし、ブラウザでネットワークログインを表示し、通常のページにアクセスできることを確認してから接続してください。分割表示中のブラウザにログインページが表示されない場合は、一時的に全画面で開くか、システムのWi-Fi詳細からネットワークに再接続します。ログイン状態が期限切れになると、Shadowrocketは接続中と表示されてもすべてのリクエストが失敗することがあります。その場合はすぐにサーバーパラメータを変更せず、ネットワークポータルを再確認してください。

iPhoneとiPadを独立して比較する

同じ設定でiPhoneは正常、iPadだけ異常な場合は、2台を同じWi-Fiに接続し、同じサーバー、同じConfig、同じGlobal Routingを選んで結果を比較します。iPadだけ失敗するなら、システム時刻、DNS、VPN構成、デバイス管理、プライベートネットワーク関連の設定を確認します。2台とも失敗するなら、サーバー、サブスクリプション、現在のWi-Fiに共通する問題である可能性が高くなります。比較時に片方をモバイルネットワーク、もう片方をWi-Fiにすると、接続環境の影響が混ざるため避けてください。

モバイルネットワークに対応したiPadでは、Wi-Fiとモバイルネットワークを分けてテストし、On Demand条件が両方のネットワークに異なる動作を設定していないか確認します。ネットワークを切り替えた後は、システム状態が安定するまで待ってからテストしてください。VPNマークが変化している間にHomeを連続してタップしないでください。Wi-Fiだけが失敗する場合はルーターとログインページを確認し、モバイルネットワークだけが失敗する場合は電波、データ通信の権限、対応するOn Demand条件を確認します。両方が失敗する場合は、サーバーパラメータ、DNS、システムのVPN構成に戻って確認します。

iPadのApp Storeからの入手、購入済み項目からの復元、初回権限の手順を再確認する場合は、iPadの入手方法をご覧ください。Mac、Apple TV、Apple Visionの対応情報も同じApp Storeページの記載を基準とします。本ページの操作の中心は、引き続きiPhoneとiPadでの問題切り分けです。