Shadowrocketのトラブルシューティング
接続・ルール・DNS

1. 接続を開始できない：まずシステムの接続許可を確認

接続を開始できない、接続後すぐに切れる、接続状態は維持されるがリクエストに失敗する、の3つを区別します。それぞれ問題の段階が異なります。最初の2つではシステムの許可、ネットワーク拡張機能、設定の有効性を優先して確認します。3つ目は接続自体が確立している可能性があるため、ノード、ルーティング、DNSを確認します。画面上部のステータスアイコンだけで目的のサイトにアクセスできると判断しないでください。また、接続が一度切れただけでサーバーの障害と決めつけないようにします。

状況を記録し、基本のネットワークを確認

現在のネットワークの種類、選択中のサーバー、Global Routingの設定、On Demandの有効・無効を記録します。現在のConfigを保存し、最後に接続できた後で変更した項目も書き留めてください。その後、Shadowrocketを終了し、普段直接アクセスできるサイトをブラウザーで開きます。終了後もアクセスできない場合は、Wi-Fiのログイン画面、モバイルデータ通信の許可、ルーター、システムのネットワーク制限を先に確認します。アプリの接続を調べるには、端末自体がインターネットに接続できる必要があります。

公衆Wi-Fiでは、先にWeb認証が必要な場合があります。Wi-Fiに接続しただけでは認証が完了していないことがあり、以前のログイン状態がシステムにキャッシュされている可能性もあります。アプリを終了したまま、システムが表示する認証ページを開き、ネットワークを利用できることを確認してから再接続してください。組織や学校が管理するプロファイルが端末にインストールされている場合は、関連するネットワークポリシーも確認します。用途が分からない管理項目を削除したり、管理者が設定した権限を回避したりしないでください。

VPN設定と同時接続を確認

1. Homeに戻り、インポートしただけで未選択のリストではなく、ご自身の有効なサーバーが選択されていることを確認します。
2. 接続を開始し、VPN構成の追加を許可するシステムの確認画面が表示されるかを確認します。表示された場合は、システムの案内に従って許可してください。
3. システム設定のVPN管理画面で接続履歴を確認し、別の接続が繰り返し切り替わっていないか確認します。
4. On Demandを一時的に無効にして手動接続を試し、手動接続と自動接続の条件を分けて確認します。

以前に許可を拒否した場合、再試行の前にシステム設定で状態を確認する必要があります。設定を保存し、どの接続記録がShadowrocketのものか明確に分かっている場合に限り、古い接続記録を削除してアプリに再作成させる方法を検討してください。システムの接続記録を削除する操作はサブスクリプションの削除とは異なりますが、複数の場所を同時に変更して原因が分からなくならないよう、先にバックアップしてください。最初から端末全体のネットワーク設定をリセットする必要はありません。

接続がすぐに切れる場合の確認順

まず、権限や設定に関する明確なエラーがないか確認します。次に、接続をタップした後、ネットワークの切り替え後、画面ロック解除後のどのタイミングで切れるかを観察してください。起動時に必ず失敗する場合は、現在の設定を正常に読み込めるか、必須のサーバー項目が空欄になっていないか確認します。ネットワーク切り替え時だけ発生する場合は、自動接続条件を一時的に無効にし、ネットワークを一つに固定して再試行します。一度に複数のノードを切り替えると、実際の発生条件が分かりにくくなります。

サーバー設定の誤りによって接続後のリクエストが失敗することはありますが、接続開始の問題をすべてプロトコルの問題と考えるべきではありません。画面に表示されたエラー全文を記録し、まず権限と設定の読み込みを確認してください。診断記録が利用できる場合は、エラーの種類と発生手順だけを共有します。サブスクリプションURL、認証情報、サーバー識別情報は機密情報です。サポート担当者に送る前に必ず隠してください。スクリーンショットにQRコード、完全なURL、個人アカウント情報が含まれていないかも確認します。

アプリを再起動しても同じ症状が再現する場合は、作業を保存してから端末を再起動し、同じネットワークと設定で一度確認します。再起動は一時的なシステム状態を切り分けるための手段であり、原因の特定そのものではありません。再現記録には「どの手順で失敗したか」「どのようなメッセージが表示されたか」「アプリを終了すると復旧するか」の3点を含めてください。「接続できない」という曖昧な説明より、こうした事実の方が原因を絞り込むのに役立ちます。

2. 接続中なのにインターネットにアクセスできない：ノードとルールを切り分ける

接続状態が維持されている場合は、すべてのリクエストが失敗するのか、一部のドメインだけ失敗するのか、特定のアプリだけ失敗するのかを切り分けます。直接アクセスできるサイト、ご自身のサーバー経由でアクセスする必要がある対象、実際に問題が起きているアプリをそれぞれ選んで確認してください。テスト対象はご自身で決め、途中で変更しないようにします。サイトを頻繁に変えると、対象サービスの状態、キャッシュ、ルーティングの違いが混在し、結果を判断しにくくなります。

Global Routingで比較する

Global RoutingのConfig、Proxy、Directは、それぞれ異なる経路を確認するための設定です。Configは現在の設定にあるルールに従って経路を決めます。Proxyはプロキシ経由の経路をまとめて確認し、Directは直接接続の経路を確認します。モードの切り替えは診断手段であり、特定の設定を長期間使うことを勧めるものではありません。テスト中はサーバーを固定し、古いWebページを閉じて新しいリクエストを発行してください。以前の経路で確立した接続が再利用されるのを防げます。

ProxyでアクセスできてConfigで失敗する場合は、適用されたルール、選択中のポリシー、DNSの結果を優先して確認します。すぐにサーバー設定を作り直す必要はありません。両方のモードで失敗する場合は、サーバー認証、プロトコル設定、ネットワーク条件を確認します。DirectでアクセスできるサイトにProxy経由で接続できない場合、そのサイトが現在の直接接続条件では到達可能だと分かりますが、すべてのプロキシリクエストに問題があるとは限りません。判断は、その時点のネットワーク、接続先、モードの範囲に限定してください。

ルールの順序とポリシーの接続先を確認

Configを開き、先ほど編集したファイルが現在有効になっているか確認します。ファイルがリストに保存されていても、選択中とは限りません。リモート更新後のファイルが手動編集したファイルと異なる場合もあります。次にルールの順序に沿って対象ドメインを確認します。完全一致、サフィックス、キーワード、最終ルールによって、それぞれ異なるポリシーに振り分けられる可能性があります。通常は先に一致したルールが適用されるため、後ろに正しいルールがあっても、先に誤ったルールへ一致した結果は修正できません。

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

上記はルール構文の説明であり、汎用的な設定例ではありません。1行目は指定ドメインとそのサブドメインをPROXYに送り、2行目は完全一致するドメインを拒否します。プライベートネットワークの例はDIRECTに送り、FINALはそれ以前のルールに一致しなかったリクエストを処理します。コピーする前に対象範囲を理解し、ご自身のネットワーク環境に照らして確認してください。特に、例に含まれる拒否ルール、地域ルール、最終ポリシーを、使用中のConfig全体にそのまま置き換えないでください。

ルールの接続先がカスタムポリシーグループの場合は、グループ内に利用可能なサーバーがあり、実際の選択内容が想定どおりかも確認します。グループ名が正しくても、中で選択されているサーバーが適切とは限りません。自動選択と手動選択で結果が異なることもあります。確認中は、ご自身のリストにある利用可能なノードを一つ選んで固定すると、ポリシーの変化による影響を抑えられます。確認後は元の選択方法に戻し、今回の成功条件を記録してください。

特定のアプリだけ失敗する場合

アプリは長時間接続を再利用したり、キャッシュ済みのアドレスを使ったり、複数のドメインへ同時にリクエストしたりすることがあります。まずアプリを完全に終了してから再起動し、メイン画面、ログイン、メディアの読み込みをそれぞれ確認します。Webサイトを一つ開けても、そのアプリが必要とするすべてのドメインにアクセスできるとは限りません。診断記録にリクエスト経路が表示される場合は、失敗したドメインを一つずつ確認してください。一つのリソースを直すために、ルール全体を広範なキーワードマッチに変更しないようにします。

ローカルネットワークのサービスでは、ローカルネットワークへのアクセス許可、端末が同じネットワークに接続しているか、リクエストがドメイン名とプライベートアドレスのどちらを使っているかも確認します。インターネットに接続できても、プリンターや家庭内ストレージにアクセスできない場合は、外部サーバーへの接続障害とは別の問題です。実際のリクエストで効果を確認できた変更だけを残してください。どのルールが適用されたか分からない場合はバックアップに戻し、最小限の変更からやり直します。一時的なルールが互いに上書きし合う状態を避けてください。

3. タイムアウト・速度低下：接続とデータ転送を分けて確認

タイムアウトは、テストやリクエストが制限時間内に完了しなかったことを示します。それだけでサーバーが停止したとは判断できません。速度低下は、名前解決、ハンドシェイク、最初のデータ受信、継続的な転送のどの段階でも発生します。まず具体的な症状を記録してください。Connectivity Testに結果が表示されないのか、Webページの表示が遅いのか、ページは開くもののダウンロードが遅いのかで、確認項目は異なります。遅延の数値だけでダウンロード速度は判断できません。

サーバー情報とテストの意味を確認

ご自身が利用しているサーバーの情報画面で、アドレス、ポート、プロトコル、認証情報を一つずつ確認します。ノード名だけで地域やプロトコルを判断しないでください。ノード名は単なるメモです。情報をコピーした際に空白が混入していないか、文字が欠けていないか、ポートが正しいか確認します。サブスクリプションから追加した情報の場合は、元の記録を残してください。手動で変更したノードと、次回のサブスクリプション更新後の内容を混同しないようにします。必要なら、すべてのリストを上書きするのではなく、同じ情報源から比較用の項目を一つ再インポートします。

Connectivity Testの結果は、選択したテスト方法と合わせて解釈してください。テストによっては接続や特定の接続先だけを確認するため、実際の利用時のリクエストを代替するものではありません。テストがタイムアウトしてもWebサイトにアクセスできる場合は、テスト対象と方法を確認し、利用可能なノードを削除する必要はありません。テストは成功してもWebサイトにアクセスできない場合は、接続先への経路、ルール、DNSを確認します。テストと実際のリクエストの接続先が異なれば、結果が異なっても矛盾ではありません。

プロトコル設定は関連項目をまとめて確認

Shadowsocksの暗号化方式とパスワードはサーバー側の設定と一致させる必要があります。VMessとVLESSでは認証情報とトランスポート設定を対応させ、TrojanではパスワードとTLSの条件を正しく設定してください。追加のトランスポート経路、Host、Server Nameを使う構成では、各項目の役割が異なります。名前が似ているからといって相互に置き換えないでください。サーバーアドレスは接続先を特定するために使いますが、証明書の検証に使う名前は異なる場合があります。ご自身が利用しているサービスで指定されたパラメーターを使用してください。

証明書またはハンドシェイクのエラーが発生した場合は、端末の時刻、証明書に対応する名前、パラメーターを手動変更したかを確認します。エラーを隠すために証明書検証を無効にしないでください。セキュリティ条件が変わるうえ、その後の確認結果も比較できなくなります。Hysteria2など特定のトランスポート条件に依存するプロトコルでは、現在のネットワーク環境も考慮してください。同じプロトコル名でも、すべてのサーバーでポート、認証形式、トランスポート設定が共通とは限りません。

ネットワークとノードを組み合わせて比較

1. 接続先とサーバーを固定し、Wi-Fiとモバイルネットワークでそれぞれ新しいリクエストを実行して、違いを記録します。
2. ネットワークを変えずに、ご自身のリストにある別のノードへ切り替え、同じ接続先にリクエストします。
3. 初回表示、ページ内リソースの読み込み、継続的なデータ転送を個別に確認し、すべてを一つの「速度」として扱わないでください。
4. 時間帯を近づけて再テストし、バックグラウンドの大容量同期を停止して端末側の帯域使用を除外します。

特定のネットワークだけで失敗する場合は、そのネットワークからサーバーまでの経路、Wi-Fiの電波状態、アクセス制限を優先して調べます。特定のノードだけで失敗する場合は、そのノードとサーバー側の状態を確認します。複数のノードが同時に失敗する場合でも、共通の接続先や同じ設定を利用している可能性があります。それだけでアプリ全体の異常とは判断できません。比較テストの目的は範囲を絞ることであり、特定の側に必ず障害があると証明することではありません。

速度低下時は根拠のない設定変更を避ける

まずアプリを終了した状態で同じ端末の基本的なデータ転送を確認し、プロキシ経由でさらに遅くなるかを調べます。無線干渉、モバイルネットワークの電波状況、サーバーの負荷、接続先サイトの速度制限、バックグラウンド同期など、さまざまな要因で速度は変化します。テスト中は大容量の通信を同時に行わず、何度も更新して大量のリクエストを発生させないでください。測定条件が変わるだけでなく、サーバー側で一時的な制限がかかる可能性もあります。

小さなWebページは問題なく大容量ファイルで停止する場合は、複数の接続先でも再現するかを記録し、現在のネットワークとプロトコルの転送条件を確認します。MTUなどの設定はパケット転送に影響しますが、すべてのネットワークに適した共通値はありません。根拠がないまま数値を次々に変更しないでください。さらにサポートを求める場合は、ネットワークの種類、プロトコルの種類、失敗した段階、実施済みの比較結果を伝えます。パスワードや完全なサブスクリプションURLは共有しないでください。

ノードの詳しい確認方法は、遅延テスト・地域・プロトコルの種類をご覧ください。「このネットワークとこのノードの組み合わせでは、同じ接続先の表示が遅い」のように記録し、遅延値だけを残さないようにします。条件を揃えて再現できると、一時的な混雑と継続的な設定問題を区別しやすくなり、無関係な変更を一時的な復旧原因と誤認するのも防げます。

4. サブスクリプション更新に失敗する：返された内容を確認してからノードを調べる

サブスクリプションの更新はリストを取得して解析する操作であり、ノードへの接続はリスト内の項目を使う操作です。更新に失敗しても、保存済みのノードがすべてすぐに使えなくなるわけではありません。既存のノードに接続できても、サブスクリプションURLが引き続き有効とは限りません。まず現在のリストを残し、更新時のメッセージ、失敗した時刻、そのときのネットワーク経路を記録してください。一度の更新失敗でConfigを消去しないでください。削除済みのサブスクリプションを復元するには、情報源を改めて確認する必要がある場合もあります。

URLの完全性と返される内容を確認

ご自身が利用しているサービスの案内ページからサブスクリプションURLを再コピーし、先頭、パス、クエリパラメーターがすべて含まれているか確認します。チャットアプリ、改行、手動編集によってURLの一部が欠けていることがあります。画面によってはURLが省略表示されるため、表示上の省略形を完全なURLと考えないでください。サブスクリプションURLには認証情報が含まれることが多いため、パスワードと同様に扱い、公開投稿、オンライン解析ページ、他人が提供する検査ツールに貼り付けないでください。

単一の共有リンクとサブスクリプションURLは別のものです。ss://、vmess://、vless://、trojan://は通常、一つのサーバー情報を表します。サブスクリプションは更新可能な項目の集合を提供します。単一ノードの内容を誤ったインポート画面に入力すると、形式を認識できなかったり、項目が一つだけ追加されたりすることがあります。違いについては共有リンクとサブスクリプションリンクの形式を確認し、適切な画面から操作してください。

失敗した段階に応じて対処

HTTPステータス情報が表示される場合は、ステータスコードと簡潔なエラーの種類を記録します。認証エラー、リクエスト過多、サーバー側の障害では、それぞれ対処が異なります。クライアントのDNS設定を変更するだけで、すべての応答エラーを解決できるわけではありません。ブラウザーでURLを開けても、有効なリストが返されているとは限りません。アカウントのログインページ、案内ページ、アクセスに関するメッセージが表示される場合があります。こうしたページを保存してノード設定としてインポートしないでください。

更新経路への依存を確認

現在のネットワークからサブスクリプションのドメインに直接アクセスできず、アプリで選択中のノードもすでに使えない場合、更新と接続が互いに依存することがあります。まず、既存リストにご自身が利用できるノードが残っているか確認し、更新リクエストが実際にどの経路を使うかを調べます。Global Routingを切り替えれば、すべての更新リクエストが自動的に同じ経路を使うとは限りません。現在の設定、利用可能な診断情報、実際の結果に基づいて確認してください。

リスト内に利用できるノードがない場合は、URLを漏らさないように注意しながら、サブスクリプションの提供元にアクセスできるネットワークへ切り替えるか、ご自身のサービス提供元にサブスクリプションの状態を確認します。出所の分からない一時的なノードを探して更新しないでください。手動での再試行には間隔を空けます。何度繰り返しても認証や形式の問題は解決せず、リクエスト頻度の制限にかかって、元の問題に新たな制限が重なる可能性があります。

更新後のリストも確認

更新に成功したら、まずノード数の変化、現在の選択、プロトコル項目を確認します。次に、既存項目の一つへ接続して目的のリクエストを検証してください。サービス提供元が名前、接続先、認証情報を変更することがあり、以前の手動選択が同じ項目を指すとは限りません。ノードに加えたローカル変更がサブスクリプションの更新で置き換わる場合もあります。手動メモ、サブスクリプションの内容、Config全体は別々に管理し、同じバックアップと見なさないでください。

サブスクリプションURLが公開環境に漏れた場合は、元のサービス提供元に認証情報の変更方法を確認し、アプリに保存したURLを更新します。チャットメッセージを削除しただけでは、古いURLが無効になったことにはなりません。トラブルシューティングの記録には、必要な範囲のドメイン名、エラーの種類、操作手順だけを残してください。クエリパラメーター全体をスクリーンショットや共有ドキュメントに記載しないでください。復旧を確認してから自動更新を設定し、原因が分からない間にバックグラウンドでリクエストが繰り返されるのを防ぎます。

5. DNSの問題：名前解決の結果と実際の経路を確認

DNSはドメイン名を接続に必要なアドレスへ変換します。ドメインにアクセスできない、初回表示が遅い、一部のリソースだけ失敗するといった症状には、名前解決が関係する場合があります。ただし、TLS、接続先のサービス、ルールが原因の可能性もあります。まず、エラーが名前解決の前後どちらで発生したかを確認してください。アドレス取得後もタイムアウトする場合、すべての原因をDNSに求めるべきではありません。名前解決に成功しても候補となるアドレスが得られただけで、そのアドレスに現在のネットワークやルーティング条件から到達できるとは限りません。

ドメイン、アドレス、ルールを分けて記録

サイト名だけでなく、失敗した完全なホスト名を記録します。同じサービスでも、ログイン、画像、APIが異なるドメインを使う場合があります。メインページが開いて画像だけ失敗する場合、別のリクエストが原因かもしれません。診断記録に名前解決の結果が表示される場合は、アドレスの種類と発生時刻も記録してください。完全なURLに含まれる認証パラメーターを公開したり、確認のために信頼できないDNSサービスへプライベートな内部ドメインを送ったりしないでください。

現在有効なConfigを開き、カスタムDNS、ドメインマッピング、名前解決関連の項目が設定されているか確認します。まず有効なファイルを確認し、その後でルールを確認してください。無効なコピーを編集してもリクエスト結果は変わりません。リモート設定を使っている場合は、更新によってローカル設定が置き換わっていないかも確認します。比較時は元のファイルを残し、名前解決関連の項目を一つだけ変更してください。そうしないとアクセスが復旧しても、どの変更が有効だったか分かりません。

ルールが名前解決を必要とする場合を理解

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはドメイン情報に基づいて一致します。IP-CIDR、IP-CIDR6、GEOIPはアドレス範囲やアドレスの所属地域に関係します。ドメインリクエストがアドレス関連のルールに照合されると、設定によっては判定前に名前解決が必要になる場合があります。この仕組みを理解すると、「ルールは正しいように見えるのに初回リクエストが遅い」現象を説明できます。待ち時間が発生するのは、プロキシ接続ではなくアドレス判定の段階かもしれません。

[Rule]
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
FINAL,PROXY

例のno-resolveは、そのアドレスルールのためだけにドメインの名前解決を行わないことを示します。すべてのDNSを無効にする設定でも、すべてのドメインを特定の経路に強制する設定でもありません。DNSサーバーに到達できない問題は解決せず、ローカルネットワークの名前解決を保証するものでもありません。ルール例は構文上の関係を示すものです。実際に設定する際は既存ルールの順序、内部ネットワークの範囲、接続先を考慮してください。例全体を万能な修正方法として使わないでください。

IPv4、IPv6、ネットワークの切り替え

同じドメインから複数のアドレスが返され、現在のネットワークではIPv4とIPv6の到達性が異なる場合があります。特定のWi-Fiだけで失敗する場合は、そのネットワークのアドレス環境を記録し、別のネットワークと比較してください。IPv6を一度無効にして復旧したからといって、すべての環境でIPv6を無効にすべきとは限りません。アドレスの選択や経路をさらに調べる手がかりに過ぎません。システムのネットワーク条件を変更する前に、元の設定値と戻し方を記録してください。

Wi-Fiとモバイルネットワークでは名前解決の条件が異なる場合があります。ネットワークを切り替えた後も、キャッシュや既存の接続が残ることがあります。比較のたびにリクエストを新しく実行し、必要に応じて対象アプリを終了してから再起動してください。何度も更新をタップしても、新しい名前解決が行われるとは限りません。アドレス欄にIPアドレスを直接入力してすべての確認の代わりにしないでください。HTTPS証明書、仮想ホスト、サービスのルーティングは通常ドメイン名に依存するため、アクセスの成否が誤解を招くことがあります。

内部ドメインとキャッシュの範囲

家庭用ルーター、組織のネットワーク、ローカルネットワーク上のサービスでは、そのネットワーク内でのみ有効な名前解決を使う場合があります。別のDNSを使うと、外部サイトにアクセスできても、こうした内部名を解決できずローカルサービスに問題が発生することがあります。まず端末が同じローカルネットワークに接続しているか、対象ドメインにローカルでの名前解決が必要かを確認します。内部ドメインの問題をPROXYルールの拡大だけで解決しないでください。プロキシ経由ではプライベートアドレスにアクセスできない場合があります。

ブラウザー、アプリ、システム、クライアントには、それぞれキャッシュが残る場合があります。設定変更後は、「既存の接続が引き続き使えている」のか「新しいリクエストが復旧した」のかを区別してください。確認後、以前失敗した接続先に再度アクセスし、実際に適用された経路を確認します。特定の名前解決条件でのみ安定して復旧する場合は、すべての端末に同じアドレスを適用するのではなく、条件と適用できるネットワークを記録してください。DNS設定の妥当性は、現在のネットワークで実際にリクエストして確認します。

6. バッテリー消費・通信量の異常：継続的な通信の発生源を確認

バッテリー消費の増加を調べるには、比較できる条件を揃える必要があります。端末の温度、画面の明るさ、電波の強さ、バックグラウンド同期、実際の通信量は、いずれもバッテリーの消費に影響します。一度の電池残量の減少だけでShadowrocketの異常と判断しないでください。まずシステムのバッテリー使用状況で同じ時間帯の動作を確認し、ファイルのダウンロード、メディアの再生、ネットワークの頻繁な切り替えがあったか記録します。日付ごとに使用時間や通信量が異なる場合、結果をそのまま比較することはできません。

通信量の表示と通信の発生源を区別

プロキシ接続は他のアプリのデータを中継するため、システムの使用量表示では関連プロセスにネットワーク活動がまとめて表示される場合があります。それだけでクライアント自身が同じ量のリクエストを発生させているとは限りません。写真のバックアップ、ファイル同期、アプリのアップデート、メディアの自動再生が実行中かを確認し、これらを一時停止した後に通信量が減るか観察します。統計のランキング一つだけでは、実際にリクエストを発生させたアプリは特定できません。

画面にDataや接続記録が表示される場合は、通信が継続しているかを確認できます。ただし、集計方法、リセット時刻、システム側の統計と異なる場合があることに注意してください。累積通信量、リアルタイム速度、アプリのバックグラウンド動作は別の指標です。調査前に開始時の状態を記録し、観察時間を固定してから変化を比較します。累積値を瞬間的な通信量と見なしたり、異なる時間幅の数値を比較して異常を証明したりしないでください。

接続の繰り返しと再試行を確認

電波が弱い、頻繁にローミングする、ノードが不安定といった場合、アプリが接続を何度も試みることがあります。画面上ではページを開けていなくても、バックグラウンドでハンドシェイク、名前解決、再試行が続く場合があります。電波の安定したネットワークに固定し、ご自身のリストにある利用可能なノードを選び、アイドル状態でも繰り返し通信が発生するか確認してください。ネットワークの切り替え時だけ問題が起きる場合は、プロトコル設定全体を変更する前に、切り替えの順序と自動接続条件を記録します。

On Demandは条件に応じて接続を開始する機能です。すべての状況で同じ接続方法を維持する必要はありません。一時的に無効にして手動接続することで、接続の開始、切断、再接続が繰り返されていないかを確認できます。テスト前に元の条件を記録し、終了後は元に戻してください。原因を調べるために長時間接続を何度も切り替えないでください。切り替え自体が余分な通信を発生させ、バックグラウンドアプリから新しいリクエストが送られる可能性があります。

再現可能なアイドル状態の比較を行う

1. 大容量ファイルの処理を終了し、画面の明るさとネットワークを揃えて、通常利用時の状態を記録します。
2. 設定を保存し、利用可能と確認済みのノードを一つ使って、不要な手動テストを一時停止します。
3. 画面をロックした後、システムのバックグラウンド動作を確認し、ネットワークの切り替えや通知が集中した時間帯があったか記録します。
4. 次にクライアントを終了した状態でも同じように観察し、同じ現象が続くか比較します。結果を他のネットワークに当てはめないでください。

比較中はサブスクリプションの更新、ルールの切り替え、Connectivity Testの連続実行を同時に行わないでください。テストのリクエスト自体が通信を発生させ、頻繁な検査はアイドル状態での比較を成立しにくくします。自動更新を使う場合は、更新間隔が実際の必要に合っているか確認してください。リストが有効かを確認するために、手動更新を続ける必要はありません。更新に失敗した場合は先に原因を確認します。繰り返し再試行しても問題が解決せず、バックグラウンドの通信だけ増えることがあります。

温度、充電、接続条件

充電中、システムのバックアップ復元、インデックス作成、高負荷アプリの使用は、いずれも端末の発熱につながることがあります。著しく熱くなった場合は、まず高負荷の処理を止め、端末が通常の動作状態に戻ってから調査してください。充電しながら連続でダウンロードして、クライアントのバッテリー消費を比較しないでください。電波が弱いと接続の維持にも多くの電力を使うことがあります。安定したネットワークへの切り替えで改善した場合、それを特定のルールの効果として記録しないようにします。

クライアントを終了しても発熱や急激な電池消費が続く場合は、システムや他のアプリを引き続き確認します。特定の設定、ノード、自動接続条件でのみ再現する場合は、その条件を最小限にして保存してください。統計の数値を下げるために、証明書検証を無効にしたり、必要なルールを削除したりしないでください。適切な対処では、通常のリクエストが完了すること、アイドル時の活動が落ち着くこと、元の設定に戻した場合も問題を説明できることを確認します。

7. アップデート後の異常：変化を確認し、原因と決めつけない

「アップデート後に起きた」というのは発生時期の前後関係を示すだけで、アップデートが原因とは限りません。アプリの更新、システムアップデート、サブスクリプション更新、リモートConfigの変更、サーバー側の変更が同じ時期に起きている場合があります。まずそれぞれの変更を列挙し、確認できた事実と推測を分けて、障害に最も近い操作から調べます。記憶だけでバージョン番号や更新日時を記録せず、ネットワークが一時的に復旧しただけで原因を特定したと思わないでください。

更新前と現在の状態を保存

操作する前に現在のConfigをエクスポートし、ご自身のサブスクリプションの情報源を保存します。現在選択中のノードとGlobal Routingの設定も記録してください。バックアップファイルにはサーバーの認証情報が含まれる場合があるため、管理された安全な場所に保管します。更新前のバックアップがある場合は、ルールの順序、ポリシーの接続先、DNS、プロトコルの設定を比較します。最初から現在のファイルを上書きしないでください。現在の状態も原因の特定に役立つ証拠であり、上書きすると再現できなくなることがあります。

まず基本の経路を確認します。クライアントを終了して直接インターネットに接続できるか、手動接続を維持できるか、Proxyで固定した接続先にアクセスできるか、Configでは結果が異なるかを確認してください。同じ最小限のテストを使い、アップデート後の問題を権限、サーバー、ルール、名前解決のいずれかに分類し直します。更新前の詳細な記録がなくても、「新しいバージョンがおかしい」と推測し続けるのではなく、実際の失敗箇所を調べられます。

設定の更新とアプリの更新を区別

サブスクリプションの更新ではサーバーパラメーターが置き換わる場合があり、リモートConfigの更新ではルールやポリシーが変わる場合があります。この2種類の変更にアプリの更新が伴うとは限りません。手動設定がリモート内容で上書きされていないか、現在有効なファイルが変わっていないか、以前選択していたポリシーグループに同じ項目が残っているかを確認します。ノードを一つ復元しただけで動作する場合は、ノード情報をさらに比較してください。出所の分からない内容でConfig全体を置き換えないでください。

システムアップデート後は、VPNの許可、ネットワーク接続の記録、自動接続の条件も確認します。システムから明確な許可を求められた場合は、案内に従って許可してください。古い接続状態に不整合があるだけなら、いったん切断して手動で再接続します。システムの接続記録を作り直す場合はバックアップ後に行い、Shadowrocketのものだと確認できた項目だけを対象にしてください。ネットワーク設定をすべて削除すると影響範囲が広がるため、最初に行う確認方法としては適切ではありません。

再インストール前に復元できることを確認

再インストールはバックアップの代わりにはなりません。アプリを削除する前に、Config、サブスクリプション、必要なサーバー情報を復元できるか、どの情報が端末内にしか保存されていないかを確認してください。エクスポートしたファイルを開けるか確認し、手動ルールやノードのメモを記録します。購入記録が業務設定まで自動的に復元すると思い込まないでください。一つの接続先だけが失敗している場合は、まずその接続先とルールを確認します。通常、アプリ全体を削除する必要はありません。

インストールファイルが必要な場合は、ダウンロードページのプラットフォーム別セクションをご利用ください。iPhone / iPad版はApp Storeから入手できます。システム要件はApp Storeのページに記載された内容をご確認ください。Mac、Windows、Android、Linux版は当サイトのダウンロードページから入手できます。iPhone / iPad版は2.99米ドルの買い切りで、その他の上記プラットフォーム版は無料です。クライアントの入手と、ご自身が利用している接続サービスの状態は分けて確認してください。

再インストール時のシステムによる許可

デスクトップ版とAndroid版のインストールファイルにはコード署名がないため、初回起動時にシステムがブロックすることがあります。ファイルが当サイトから入手したものだと確認したうえで、WindowsではSmartScreenの「詳細情報」から「実行」を選択できます。macOSでは「プライバシーとセキュリティ」でブロックされた項目を確認して「このまま開く」を選択します。Androidではシステムの案内に従い、現在の提供元からの不明なアプリのインストールを許可し、完了後にその許可を取り消すことができます。システムによって表示される文言は異なる場合があるため、実際のファイルを確認して操作してください。

macOSでアプリが破損していると表示された場合は、インストールが完了しているか、正しい提供元から入手したかを確認してから、インストールの許可手順に沿って隔離属性を確認します。Linuxではディストリビューションとパッケージ形式に応じてインストール結果を確認してください。AppImageには実行権限が必要です。ファイルを起動するためにシステムの保護機能を全体的に無効にしたり、起動をブロックされた問題と接続後のリクエスト失敗を同じ問題として扱ったりしないでください。発生する段階が異なるため、それぞれ別に確認します。

後から確認できる形で結論を記録

復旧後、最初に失敗した操作をもう一度行い、目的のリクエスト、ルールの適用、ネットワークの切り替えが想定どおりか確認します。有効だった具体的な変更を記録してください。たとえば、利用可能なノードを選び直した、上書きされたルールを戻した、必要な許可を設定した、といった内容です。「再インストールで直った」だけでは不十分です。まだ失敗する場合は、再現可能な手順を数段階にまとめ、機密情報を隠したエラー情報を添えます。バージョン情報はアプリの実際の画面で確認し、記憶だけで記録しないでください。

8. iPadでの確認事項：購入、移行、横向き表示

iPadの接続トラブルも、権限、サーバー、ルール、DNSの順に確認します。ただし、購入の復元、横向き表示、設定の移行が原因で誤解が生じる場合があります。まずiPadにShadowrocketがインストールされていることを確認し、Homeで選択中のサーバー、現在のConfig、Global Routingを確認してください。別の端末で接続できても、このiPadの条件がすべて同じとは限りません。ネットワーク、権限、設定ファイルのコピー、接続記録が異なる場合があります。

購入の復元と設定の復元は別の操作

iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac、Windows、Android、Linux版は無料です。iPhone / iPad版を購入済みの場合、App Storeで購入時と同じアカウントを使用し、購入済み項目からアプリを探して再ダウンロードできます。実際にダウンロードできるかはストアの記録をご確認ください。アプリの購入資格があっても、サブスクリプション、ノード、Configが自動的に移行するわけではありません。インストール後にローカルデータを確認してください。

ストアで開発者名Shadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。システム要件はApp Storeのページに記載された内容をご確認ください。アプリが検索結果に表示されない場合は、まずアカウントのストア地域と購入済み項目を確認します。検索結果が見つからないことを接続障害と混同しないでください。同じアカウントでの購入と画面レイアウトについては、iPadの共有購入と横向き画面の違いをご覧ください。

横向きの分割表示では、現在選択中の項目を確認

横向き表示や分割表示では、リストの選択項目と右側の詳細が同時に表示される場合があります。ノードの詳細が表示されていても、現在の接続にそのノードが使われているとは限りません。Configの内容を開いても、そのファイルが有効になっているとは限りません。変更後は接続画面に戻り、現在の選択を確認してから実際のリクエストで検証してください。詳細画面に表示されている項目だけで、接続に使用中のサーバーやルールファイルを判断しないでください。

画面分割、ウィンドウサイズ、システムの表示設定によって、見える範囲が変わることがあります。ボタンが見つからない場合は、いったんアプリを全画面表示にして位置を確認し、その後で元の使い方に戻してください。操作が完了する前にリストの複数項目を続けてタップしないでください。特に編集、選択、接続の操作は異なる領域に分かれていることがあります。記録にはスクリーンショットの一列だけでなく、どの項目をタップしたか、どこに保存したか、最終的に接続画面にどの状態が表示されたかを記載します。

データの種類ごとに移行し、段階的に確認

移行する前に、サーバーまたはサブスクリプション、Config、手動ルール、必要なメモがそれぞれ保存されているか確認します。Config全体と単一の共有リンクでは、含まれる情報の範囲が異なります。ノードを一つインポートしても、すべてのルールが移行するわけではありません。アプリが提供するインポート・エクスポート機能を優先し、ご自身が管理する端末間でデータを移してください。転送ファイルやQRコードには認証情報が含まれることがあるため、公開の写真アルバム、共有ドキュメント、公開チャットに保存しないでください。

iPadでは、まずご自身が利用できるノードを一つインポートし、Proxyで固定した接続先を確認してから、移行するConfigを有効にします。こうすることでサーバーの利用可否とルールの問題を切り分けられます。最初から大量の設定をインポートして自動接続も有効にすると、失敗時にどの段階が原因か分かりにくくなります。テストに成功した後で残りの項目を追加し、サブスクリプションの更新で先ほどの手動変更が上書きされていないか確認してください。

同じWi-Fiでもネットワーク条件を比較

2台の端末に同じWi-Fi名が表示されていても、同じ権限や経路を使っているとは限りません。ゲストネットワークの隔離、ローカルネットワークへのアクセス許可、アドレスの種類、キャッシュが異なる場合があります。家庭内ストレージやローカルサービスにアクセスできない場合は、まず端末のネットワーク、関連する権限、接続先のアドレスを確認してからDIRECTルールを調べます。iPadにモバイルデータ通信機能がない場合、比較のために別のネットワークが使えると想定しないでください。代わりに、ご自身が利用できる別のWi-Fiで確認します。

画面ロック解除後に失敗する場合は、解除時にネットワークが切り替わったか、自動接続が再実行されたか、古いアプリ接続が再利用されているかを記録します。新しいリクエストを発行してから、システムのVPN状態を確認してください。移行後のデータをすべて削除しないでください。特定のアプリだけで問題が起きる場合は、2章に戻ってアプリが必要とするドメインを確認します。すべての新しいリクエストが失敗する場合は、1章と5章に従って権限と名前解決の条件を再確認してください。

ここまで確認しても原因が特定できない場合は、機密情報を除いた記録をまとめます。端末の種類、ネットワークの種類、失敗した手順、エラーメッセージ、クライアント終了後の状態、実施済みの単一条件による比較を記載してください。サブスクリプションURL全体、QRコード、パスワードは添付しないでください。こうした事実をもとに該当する章を再確認すると、すべての設定を再インポートするより原因を絞り込みやすくなります。初回接続の手順がまだ完了していない場合は、使い方ガイドに戻って順に確認してください。