Shadowrocket トラブルシューティング完全ガイド

接続スイッチが失敗する段階を確認する

iPhone／iPadのHomeにNot Connectedと表示されていても、接続が確立していないことを示すだけで、サブスクリプションに問題があるとは限りません。まず自動再接続の条件をオフにし、スイッチを手動で一度操作して、システムからVPN構成の追加を求められるか確認します。権限の確認画面がまだ表示されていない場合は、システムの案内に従って認証してください。スイッチが一瞬オンになって戻る場合は、継続時間と直後に表示されたエラーを記録し、何度も連続してタップしないでください。

次にクライアントを切断し、ブラウザーで普段アクセスできるページを開きます。通常のネットワーク接続も失敗する場合は、Wi-Fiのログイン、モバイルデータ通信、ネットワークへの再接続を確認してください。Web認証が必要な公衆Wi-Fiでは、切断した状態で認証を済ませてから接続をテストします。端末がWi-Fiアクセスポイントに接続できても、ローカルネットワークへの接続が確認できただけで、インターネットへのアクセスが可能とは限りません。

VPN構成とシステム管理による制限を確認する

iPhone／iPadでは、システム設定で「VPN」を検索し、該当する構成があるか、ほかのVPNが接続中でないかを確認できます。競合する接続を停止してからShadowrocketに戻り、再試行してください。会社、学校、デバイス管理によって追加された構成は、名前だけで判断して削除しないでください。管理対象の端末ではVPNの追加が制限されている場合があります。接続方法を管理者に確認してください。アプリにサーバーを再インポートしても、システムの制限は解除されません。

以前に権限を拒否した場合は、接続を再度開始してシステムの案内を確認してください。システムに古いShadowrocket VPN構成が残っている場合は、アプリ内のデータを保存したうえで、本アプリのものと明確に確認できた構成だけを削除し、アプリから再申請します。システム構成とサーバー項目は別のデータです。削除する対象を確認し、サブスクリプションやルールまで消さないよう注意してください。完了後はまず手動接続をテストし、自動接続の条件はすぐに戻さないでください。

権限不足と設定ミスを分けて確認する

Mac、Windows、Android、Linuxでは、アプリが正常に起動しているか、ネットワークトンネルの作成に必要なシステム権限が付与されているかを確認します。AndroidではVPN接続の確認画面とアプリのバッテリー制限を、デスクトップでは現在のアカウント権限とセキュリティソフトのブロック履歴を調べてください。Shadowrocketに必要な権限だけを変更し、トラブルシューティングのためにシステム保護を長時間無効にしたり、すべてのアプリの権限を緩和したりしないでください。

システムが接続を許可しているのにスイッチがすぐ戻る場合は、保存済みの最小構成に切り替え、設定がそろった既存のサーバー項目を1つだけ残します。カスタムスクリプト、Rewrite、複雑なポリシーグループを一時的に無効にしてから、再接続してください。これは設定の読み込みが原因かどうかを調べるための手順であり、サーバーが利用可能だと証明するものではありません。最小構成で接続を維持できた場合は、拡張機能を1つずつ戻し、切断の原因となる項目を特定します。

On Demandと競合する接続を確認する

On Demandはシステムの条件に応じて接続を開始するため、手動でオフにしたあと自動的にオンへ戻ったように見えることがあります。トラブルシューティングでは、まず元の条件を記録してからOn Demandを一時的にオフにし、手動接続のリクエストが1回だけになるようにします。同時にほかのVPN、ネットワークフィルター、トンネル機能を停止し、テスト後にそれぞれ元に戻してください。ネットワークを制御する機能を複数同時に動かすと、権限やルートの状態を特定しにくくなります。

画面ロック後やネットワーク切り替え時だけ切断される場合は、サーバーを削除せず、バッテリーとiPadの章を確認してください。起動のたびに構成の解析エラーが表示される場合は、設定のセクション名、句読点、参照しているポリシーを確認します。エラーの全文と最後に正常接続したときの設定を比較すれば、アプリの再インストールより手がかりを残しやすく、認証情報を何度も入力する必要もありません。

再現可能なアクセス比較を行う

どのプラットフォームでも「接続済みなのに開けない」場合は、まずテストするページとブラウザーを1つに決めます。切断時、接続後、サーバー切り替え後の結果を順に記録し、ネットワークと設定を同時に変更しないでください。切断中もページを開けない場合は、サイト自体または通常のネットワークに問題がある可能性があります。特定のアプリだけで起きる場合は、そのアプリのキャッシュ、ログイン状態、システムのネットワーク権限を別途確認してください。すべての通信が原因だと決めつけないようにします。

Homeで実際に選択されているSERVERを確認します。サブスクリプションのリストが更新されたかだけでは判断できません。複数の項目がある場合、リストを更新しても現在の選択が切り替わるとは限りません。次にGlobal Routingを確認し、Config、Proxy、Directのどれが選択されているかを調べます。接続ボタンで確認できるのはネットワーク拡張機能が起動したことです。すべてのリクエストが同じサーバーを経由することや、ルールが意図したポリシーに一致したことまでは示しません。

Global Routingでルールの影響を切り分ける

一時的にProxyに切り替え、同じ接続先を再テストします。Proxyでは成功しConfigで失敗する場合は、設定、マッチ順、ポリシー参照を重点的に確認します。どちらも失敗する場合は、サーバーのパラメーター、DNS、接続先のサービスを調べてください。Directは直接接続経路との比較に使えますが、クライアントを完全に終了した状態と同じではありません。必要に応じて、切断中の通常ネットワークとの比較も行います。

ルールの順序と末尾のポリシーを確認する

Configではルールを上から順に確認します。先に一致したルールが、その後の処理に影響します。範囲の広いDOMAIN-KEYWORDや、先に置かれたフォールバックルールによって、意図した詳細ルールが適用されないことがあります。ルールが参照するポリシーが実際に存在するか、編集した設定が有効になっているか、同名の別コピーを使っていないかも確認してください。変更後は接続を確立し直して新しいリクエストを送信します。既存の接続では以前の経路が引き続き使われる場合があります。

以下の例はルールのセクションと順序を示すもので、既存の完全な設定の代わりにはなりません。PROXYはポリシー参照なので、現在の設定で利用できるポリシーに対応させてください。ローカルネットワークの例は実際の環境に合わせて調整します。FINALは残りのリクエストを処理するフォールバックとして末尾に置き、後続のルールで詳しく判定する必要がある項目より前に置かないでください。テストではルールを一度に1つだけ変更し、元の順序も保存します。

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

ログから問題が発生している段階を特定する

アプリに接続ログがある場合は、まずリクエストが記録されているか、次に適用されたポリシー、接続先、エラーを確認します。ログがない場合、リクエストが現在の経路に入っていない、アプリが既存の接続を使っている、ログ機能が無効になっている可能性があります。ログが空というだけでアプリが動作していないとは断定できません。テストページを閉じて再度開き、新しいリクエストを送信してください。共有前にログのドメイン名や認証情報を伏せ、エラーの種類と発生時刻を残します。

ログにサーバーへの接続が確立した記録があるのに接続先からエラーが返る場合は、端末のVPN権限を変更し続けるのではなく、接続先のサービス、アカウント制限、接続先からの応答を確認します。特定のドメインだけ失敗する場合はDNSの章へ、プロキシ経由のリクエストがすべてタイムアウトする場合はサーバーのタイムアウトの章へ進んでください。通常の使用に戻す前に、一時的なProxyの状態を元の設定に戻し、Configでの動作も再確認します。

タイムアウト、接続拒否、認証エラーを区別する

どのプラットフォームでもサーバーがタイムアウトする場合は、まずエラーの全文を保存します。タイムアウトは、待機時間内に期待する応答がなかったことを示します。DNSの名前解決、接続の確立、ハンドシェイク、接続先へのアクセスなど、さまざまな段階で発生します。接続拒否は通常、接続先から応答があったものの、ポートが接続を受け付けなかったことを示します。認証エラーではユーザー情報を優先して確認してください。対処の順序はそれぞれ異なります。失敗するたびにパスワードを入力し直したり、すべての原因をネットワーク速度の不足と考えたりしないでください。

サーバーアドレスにプロトコルの接頭辞、空白、コピー時に混入した改行がないか確認します。ポートにはサブスクリプションまたはサーバー設定で指定された値を使ってください。名前が似ているからといって、別の項目のポートや認証情報を組み合わせないでください。サブスクリプションに表示される名前はメモであり、プロトコルの識別には使われません。項目の名前を変更しても、実際のプロトコル、アドレス、伝送パラメーターは自動で変わらないため、詳細画面で1つずつ確認します。

プロトコルごとに関連するパラメーターを確認する

Shadowsocksでは暗号化方式とパスワードを確認します。VMess、VLESSではユーザーIDとサーバーが要求する追加パラメーターを確認してください。TrojanではパスワードとTLS関連の設定を確認します。WireGuardのキー、アドレス、ピア情報も、ほかのプロトコルの項目と入れ替えることはできません。すでにお持ちのサーバー情報を基準にし、別のガイドにある「よく使われる値」を共通設定として既存項目に上書きしないでください。

TLS名と接続先アドレスを区別する

TLSを有効にした項目では、接続先アドレス、ハンドシェイクに使うサーバー名、トランスポート層のHostがそれぞれ異なる役割を持つ場合があります。ドメイン名をIPアドレスに置き換えると、ポートに接続できても証明書名が一致せず失敗することがあります。まずサーバーが要求する名前に戻し、端末の日付と時刻が正しいか確認してください。時刻が大きくずれていると証明書の有効期間を正しく判定できず、設定ミスに似た症状が出ることがあります。

証明書の検証を無効にしたまま使わないでください。証明書エラーが発生した場合は、まずアドレス、名前、システム時刻、サーバー証明書の状態を確認します。サブスクリプション情報しかない場合は、更新してテスト用の項目を別に取り込み、各フィールドの違いを比較してください。元の項目に推測した値を次々と入力しないでください。サーバー側のパラメーターが分からない場合は、既存サービスの管理者に確認し、値を手当たり次第に組み合わせて接続できる状態を探さないようにします。

ネットワークとサーバーを比較テストで切り分ける

同じ項目を使い、Wi-Fiとモバイルデータ通信でそれぞれテストします。次に同じネットワークのまま、すでに利用可能な別の項目に切り替えてください。1つのネットワークだけで失敗する場合は、そのネットワークの認証、ポート、UDPへの接続状況を調べます。複数のネットワークで同じ項目だけ失敗する場合は、サーバーの状態やパラメーターを重点的に確認してください。Hysteria2などUDPを使う経路をテストする際、通常のWebページにアクセスできても、同じ伝送方式が使えるとは限りません。

Connectivity Testの結果はテスト方法によって異なり、到達可能と表示されても実際の通信が成功したとは限りません。ポートへの接続、ハンドシェイクの完了、目的のページを開く操作では、それぞれ異なる段階を確認しています。実際のリクエストもテストしてください。サーバー側のログを確認できる場合は、同じテスト時刻の接続受信、認証拒否、接続先へのアクセス成功を調べます。クライアントに表示される一律のタイムアウトだけで原因を判断しないようにします。

アドレスの問題かネットワークの問題かを確認する

どのプラットフォームでも既存のサブスクリプションを更新できない場合は、URLが完全か確認します。特に「?」以降のクエリパラメーターに注意してください。チャットツールやメールでの改行、文字列の手動選択によってURLが途中で切れることがあります。サブスクリプションのメモ名からURLを作り直したり、サービスのログインページをサブスクリプションのURLとして使ったりしないでください。コピーしたURLは端末上でのみ確認します。アクセス情報が含まれることが多いため、公開スクリーンショットやエラー報告のタイトルに載せないでください。

更新時のネットワークと接続状態を記録します。現在選択中のサーバーが使えなくなっていて、サブスクリプションの更新にもそのサーバーが使われている場合、新しい項目を取得できない状態に陥ることがあります。まず通常のネットワークが使える状態で更新を試し、必要に応じてすでに利用可能な別の接続経路を使います。連続して何度もタップしないでください。接続先でリクエスト頻度が制限されることがあります。同じ条件で時間をおいて再試行すると、一時的な応答失敗かどうかを判断できます。

成功の表示だけでなく応答内容を確認する

応答を受信できても、解析可能なサーバーリストが届いたとは限りません。接続先からアカウントのログインページ、期限切れの案内、アクセス認証ページ、エラーテキストが返されることがあります。アプリに形式エラーが表示された場合は、応答ステータスとエラーの説明から内容の種類を確認してください。応答全体をそのままAdd Serverに貼り付けないでください。ブラウザーにテキストが表示されても、その内容が現在のインポート方法で対応している形式とは限りません。

未認証またはアクセス拒否が表示された場合は、まずアカウントの状態、URLがリセットされていないか、クエリパラメーターが欠けていないかを確認します。アドレスが存在しない場合は、古いURLをコピーしていないか確認してください。接続先のサーバーエラーであれば、時間をおいて再試行し、既存サービスの管理者に問い合わせます。クライアントを更新しても接続先のアカウント制限は解決しません。端末の設定を何度削除しても、サブスクリプションのリクエストに対するサーバーの認証結果は変わりません。

情報の形式に合ったインポート方法を選ぶ

SubscribeはサブスクリプションURL用、Add Serverはサーバー情報を1項目ずつ入力するための機能です。Scan QR Codeとクリップボードからの読み取りは、実際のデータ形式によって使い分けます。QRコードには単一の項目が含まれる場合も、WebページのURLだけが含まれる場合もあります。読み取りに成功しても、接続可能な設定がインポートされたとは限りません。Import from Cloud JSONも、あらゆるURLに使える共通のインポート方法ではありません。名称が似ているだけで別の方法を使わず、提供された情報の形式に合わせてください。

サブスクリプション、サーバーリスト、完全な設定ファイルは用途が異なります。サブスクリプションは主にサーバー項目を更新し、設定ファイルにはルール、DNS、ポリシーが含まれる場合もあります。ルールファイルをサーバーのサブスクリプションとしてインポートすると、リストが空になることがあります。サーバーをインポートしても、新しい振り分け設定が有効になるわけではありません。インポート方法の比較はSubscribe、Add Server、QRコード、クリップボードの使い方を確認し、手元の情報に合った方法を選んでください。

# サブスクリプションURLの形式例のみ。接続には使用できません
https://example.com/sub?token=xxxx

元の項目を保持して更新結果を確認する

サブスクリプションを変更する前に、古い設定と引き続き利用できる項目を保存し、別のテスト用グループまたはコピーで更新内容を確認します。更新後は項目数の変化、選択中のSERVERが残っているか、手動で調整したパラメーターが上書きされていないかを確認してください。更新によって項目が再生成される場合があります。ローカルで編集した内容は別途記録し、リモート更新後も必ず残ると思い込まないでください。バックアップなしに全体を消去しないようにします。

インポート後にリストが空の場合は、検索条件、折りたたまれたグループ、フィルターによって項目が非表示になっていないかも確認します。一部の項目だけが見当たらない場合は、プロトコルと各フィールドの状態を比較し、情報の取得元から返されていないのか、解析時に除外されたのかを確認してください。まず新しい項目を1つ選んで詳細を開き、実際のリクエストを送信します。インポート、選択、接続の3段階が完了したことを確認してから、テスト結果を通常の設定に反映します。

「遅い」を具体的に観察できる現象にする

どのプラットフォームでも速度の問題を調べる際は、まず状況を具体的にします。Webページの読み込み開始まで時間がかかる、ダウンロードが遅い、動画が途中で止まる、初回アクセスだけが遅い、といった違いを記録してください。読み込み開始前の待ち時間にはDNS、ハンドシェイク、サーバーへの接続確立が関係することがあります。継続的なデータ転送には、経路の容量や接続先の応答がより影響します。現象が違えば、同じテスト数値で説明することはできません。サーバー名や所在地のメモだけから回線品質を判断しないでください。

同じ接続先と近いサイズのコンテンツに固定し、まず切断状態の通常ネットワークを記録してから、同じ項目でテストします。大容量ファイルをダウンロードしながらWebページを測定することは避け、システム更新、クラウド同期、ほかの端末によるネットワーク利用にも注意してください。ネットワーク、時間帯、サーバーを記録します。一度だけ速くなったり遅くなったりした結果で、特定のパラメーターが長期的に有効だと判断することはできません。設定全体を何度も調整する根拠にもなりません。

レイテンシとスループットの違いを理解する

Connectivity Testで確認できるのは、指定したテスト方法の結果であり、ダウンロード速度と同じではありません。応答が速い項目でも、継続的な転送時に容量や混雑の影響を受けることがあります。最初の応答に少し時間がかかる接続でも、確立後は安定したスループットを保つ場合があります。リスト上の数値だけで並べ替えず、実際のWebアクセスと継続的なデータ転送をテストし、最初の応答が遅いのか転送中に問題があるのかを判断してください。

特定の接続先だけが遅い場合は、同じサーバーでほかの接続先にアクセスした結果と比較します。接続先の負荷、コンテンツ配信経路、ログイン状態、アプリによる再試行も使用感に影響します。すべての接続先で同時に遅くなる場合は、ローカルネットワークとサーバー側のリソースを確認してください。特定の接続先だけのためにすべてのルールを同じポリシーに変更すると、正常だった通信経路が変わり、新たな問題を増やす一方で元の原因を説明できないことがあります。

Wi-Fi、モバイル通信、伝送経路を確認する

Wi-Fiではアクセスポイントに近づき、大容量通信を停止して、電波状況やローカルネットワークの混雑に応じて途切れ方が変わるか確認します。モバイル通信では、電波状況や移動中の変化に注意してください。同じ項目のままネットワークを変えるほうが、同じネットワークで項目を何度も切り替えるより、ローカル経路の問題を特定しやすくなります。公衆ネットワークではポートやUDPの扱いが異なる場合があります。通常のWeb閲覧ができても、すべてのプロトコルで継続的に安定した通信ができるとは限りません。

UDPを使うプロトコルやアプリだけに問題がある場合は、ネットワーク切り替えの結果と合わせてUDP経路を確認します。帯域幅のパラメーターをむやみに増やさないでください。サーバー設定とクライアントのパラメーターは対応させる必要があります。大きな数値を入力しても実際の容量は増えません。MTUを調整する場合は、フラグメンテーションや特定サイズのリクエストが失敗するなどの根拠を確認し、元の値を保存してください。再現できる症状がない場合、Web上の固定値をすべてのネットワークにそのまま適用することは推奨しません。

ルール、再試行、診断による追加負荷を減らす

簡単な設定では正常なのに複雑な設定で明らかに遅くなる場合は、ポリシーグループ、DNS、カスタムスクリプト、Rewriteを1つずつ戻し、どの段階で変化するか確認します。頻繁なヘルスチェック、失敗時の再試行、大量の診断ログは追加のリクエストを発生させ、短時間の測定結果を不正確にする場合があります。まず必要な機能だけを残して高頻度のテストを止め、同じ接続先で確認してください。ルールを削除する前に、ほかの機能が依存していないか確認します。

長時間使用したあとにだけ途切れる場合は、通信経路だけでなく、端末の温度、空き容量、バックグラウンドタスクも確認してください。端末が発熱すると、ブラウザー、デコード、ネットワーク処理にも影響することがあります。高負荷のタスクを停止し、通常の温度に戻ってから再テストします。問題が解決したら診断レベルを元に戻し、効果があった変更を記録してください。安定して再現できない場合はログと条件を残し、偶然の結果を確実な修正方法と考えないようにします。

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

どのプラットフォームでも、ドメイン名だけ開けない、初回アクセスの待ち時間が長い、ログに名前解決エラーが出る場合は、まずDNSを確認します。名前解決はドメイン名をアドレスに変換し、接続ではそのアドレスを使って通信を確立します。名前解決に成功しても接続先のポートが利用可能とは限りません。また、接続のタイムアウトが必ずDNSエラーとは限りません。ログから、名前解決前、接続時、TLSハンドシェイク時のどこで失敗したかを確認し、すべてを同じ問題に分類しないようにします。

「IPアドレスに変えたら開けた」ことだけを根拠にしないでください。多くのHTTPSサービスでは、証明書の検証やサイトの選択にドメイン名を使います。ブラウザーにIPアドレスを直接入力すると、別のページが表示されたり、証明書エラーになったりすることがあります。アプリのログにある名前解決結果と、その後の接続エラーを比較し、同じドメイン名が通常のネットワークと現在の設定で異なる動作をするかを確認します。テスト中も元の接続先名を使用してください。

システムDNSを基準にして設定を1つずつ戻す

現在のDNS設定を保存し、複数の参照先が同時に指定されていないか、カスタムHostがあるか、古いドメイン名のマッピングが残っていないかを確認します。以下の例は、システムDNSを使ったトラブルシューティングの基準を示すもので、すべてのネットワークに適しているとは限らず、完全な設定の代わりにもなりません。基準の設定に戻すと問題が解消する場合は、カスタムの名前解決項目を1つずつ戻し、異常の原因となった項目を特定します。すべてのアドレスを一度に置き換えないでください。

[General]
bypass-system = true
dns-server = system

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

暗号化DNSを使う場合は、名前解決サービス自体がどのように接続を確立するかも考慮します。サービスのドメイン名が別の名前解決経路に依存していることがあり、そのリクエストもルーティングポリシーの影響を受ける場合があります。現在まだ接続できていないサーバーを経由しないと名前解決できず、そのサーバーのドメイン名も同じ名前解決に依存する場合、依存関係が循環することがあります。まず起動可能な最小限の経路を復元し、現在のアプリが対応する設定で名前解決と接続の関係を明確にしてください。複数のフォールバックをむやみに重ねないようにします。

ルールの種類と名前解決のタイミングを確認する

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIPは、それぞれ異なる対象を扱います。ドメインルールは名前を直接判定しますが、IPルールでは判定時点ですでに名前解決されている必要がある場合があります。no-resolveを指定したIPルールは、そのルールのために名前解決するのを避けますが、実際の接続で以後DNSが不要になるわけではありません。トラブルシューティングではルールの記述だけでなく、その時点ですでに接続先アドレスがあるかも確認します。ドメイン名だけからマッチ結果を推測しないでください。

キャッシュ、IPv6、ローカルネットワーク名を確認する

DNSを変更しても、古いリクエストがキャッシュや既存の接続を使い続ける場合があります。テストページを閉じ、クライアントを接続し直して新しいリクエストを送信してください。アプリにキャッシュを消去する明確な機能がある場合だけ使用し、DNSを更新するためにすべての設定を消去しないでください。IPv4は正常でIPv6だけ失敗する場合は、サーバー、システム、実際のネットワークで一貫したIPv6経路が利用できるかを確認します。ルールに名前を追加するだけでは解決しません。

プリンター、ローカルネットワークサービス、内部ドメイン名は、現在のWi-Fiが提供するDNSに依存している場合があります。すべての名前解決をリモートに変更すると、見つけられなくなる可能性があります。外部ドメインにはアクセスできるようになったのに内部名が使えない場合は、ローカルネットワークのアドレス、システム権限、内部の名前解決経路を分けて確認します。ローカルネットワーク内だけで有効な条件を維持し、内部名を無関係な名前解決経路に送らないでください。復旧後は外部のページと必要なローカルサービスの両方を確認します。

システムのバッテリー統計を正しく読み取る

iPhone／iPadやAndroidでバッテリー消費が気になる場合は、まずシステムのバッテリー画面で集計期間、画面使用時間、バックグラウンド活動を確認します。バッテリーの割合は、その時間帯における各アプリの相対的な消費量です。クライアントが端末の全バッテリーを同じ割合で使い続けたことを示すものではありません。比較する2つの時間帯でWi-Fiと電波の弱いモバイル通信が異なる場合や、一方だけ大量に通信した場合は、割合だけで設定の異常を断定できません。

ネットワークトンネルは通過するデータを処理します。システム統計ではネットワーク処理の一部が関連プロセスの消費として集計される場合がありますが、アプリごとの通信コストを正確に分けて示すものではありません。まず使用状況が近い2つの時間帯を選び、ネットワーク、接続時間、主な作業を記録して比較します。トラブルシューティング中にプロトコルを変え、ネットワークを切り替え、バックグラウンド権限も無効にすると、電池の持ちが改善しても、どの要因が効果的だったのか判断しにくくなります。

失敗と再試行が繰り返されていないか確認する

安定した待機接続よりも、接続失敗が繰り返されていないかを優先して確認します。アプリを開いて接続状態が頻繁に変わるか、サブスクリプションが短時間に何度も更新されているか、ポリシーグループが利用できない項目を高頻度でテストしていないかを確認してください。ログに同じエラーが続く場合は、バッテリー消費を調べる前に、通常のネットワーク、認証、名前解決の問題を解決します。診断ログの詳細度を下げるだけでは、根本で失敗し続けるリクエストは止まりません。重要な手がかりが隠れることもあります。

On Demandの条件は実際の使い方に合うように設定します。移動中にWi-Fiとモバイル通信が頻繁に切り替わったり、電波の境界で何度も再接続したりすると、システムが接続を繰り返し確立することがあります。自動接続の条件を一時的にオフにし、安定したネットワークで手動接続を維持してエラーが止まるか確認します。テスト後は必要に応じて条件を元に戻し、すべての自動接続を長期的に無効にしないでください。特定のWi-Fiだけで起きる場合は、まずそのネットワークを確認します。

一律に常時起動させず、バックグラウンド制限を確認する

Androidでは、特に画面ロック後にだけ切断される場合、システムがShadowrocketのバックグラウンド通信やバッテリー使用を制限していないか確認します。システムにあるアプリごとの設定を調整し、すべてのアプリを無制限にする必要はありません。iPhone／iPadのVPN接続はシステムのネットワーク機能によって管理されます。メインアプリをバックグラウンドに移しただけで接続も終了するはずだとは考えず、システムのVPN状態、ログ、ネットワークを切り替えた時刻をあわせて確認してください。

Mac、Windows、Linuxでは、画面オフ、スリープ、システムの復帰を分けて確認します。スリープするとネットワーク経路が中断され、復帰後も以前の接続を使い続けられるとは限りません。まずシステムのネットワーク接続が正常に戻ったことを確認してから、クライアントを再接続してください。テストを続けるために端末全体の省電力機能を長時間無効にしないでください。バッテリー駆動時だけ問題が起きる場合は、システムの電源モードとネットワークアダプターの省電力設定が変わっていないか確認します。

スクリプト、ログ、ほかのバックグラウンドタスクを切り分ける

複雑なスクリプト、Rewrite、頻繁なチェック、長時間の詳細ログは処理負荷を増やすことがありますが、比較せずに特定の機能が原因だと決めつけないでください。設定をコピーして必須でない部分を一時停止し、同じ使い方でテストしてから1つずつ戻します。同時に、クラウド同期、大容量ファイルのアップロード、システム更新、メディア処理も確認してください。これらは通信量を増やすだけでなく、クライアントのネットワーク処理も増やし、発熱とバッテリー消費が同時に起きる原因になります。

端末が明らかに発熱している場合は、高負荷の作業を停止し、通常の温度に戻ってからテストしてください。発熱とネットワーク切断が同時に起きているときは、負荷テストを連続して実行したり、安定した結果を得るために充電しながら高負荷状態を維持したりしないでください。最小構成でも近い条件で問題が続く場合は、バッテリー画面、システム状態、個人情報を除いたログをまとめ、発生時刻を記録します。再インストールする前に、別のネットワークでも同じ症状が再現するか確認してください。

アプリ、システム、サブスクリプションの更新を区別する

どのプラットフォームでも「アップデート後に接続できない」場合は、更新されたのがShadowrocket、OS、サブスクリプション、設定ファイルのどれかを確認します。更新が同じ時期に起きても、影響する層は異なります。最後に正常に使えたときのネットワークと設定を記録し、その後の変更を列挙してください。すべての問題をすぐアプリのせいにしないようにします。サブスクリプション項目の置き換え、システム権限のリセット、ルール内容の変更が、アプリの更新後に初めて表面化することもあります。

まずアプリを一度再起動して接続し直し、システムの通常ネットワークが使えることを確認します。OSのアップデートで再起動が必要な場合は、先にシステムの手順を完了してください。以前の接続だけが使えなくなり、新しいリクエストは正常な場合、ネットワーク状態がすぐに復旧していない可能性があります。接続のたびに同じエラーが再現する場合は、ログを残して原因を調べます。再現可能な手がかりを隠すために何度も再起動したり、バックアップなしにアプリのデータを消去したりしないでください。

設定のコピーで互換性の問題を調べる

現在の設定と利用可能な古いコピーを保存し、セクション、ポリシー名、DNS、追加機能を比較します。設定の解析が厳格になると、以前は表面化しなかったスペルミスや参照エラーが明示される場合があります。実際のエラーに基づいて1つずつ修正してください。出所が不明な設定を全体にコピーして、現在の情報を上書きしないでください。まず手元にあるサーバーを1つと最小限のルールで接続し、基本機能を確認してからポリシーグループや拡張設定を戻します。

サブスクリプションの更新で項目の識別子、名前、パラメーターが変わり、以前のポリシー参照先がなくなる場合もあります。現在のSERVERが残っているか、ポリシーグループが空でないか、参照名が完全に一致しているかを確認してください。同名の項目が複数ある場合は、どれが選択されているか確認します。古い設定に戻しても、接続先サーバーの状態まで元に戻るとは限りません。設定ファイルを読み込めるかだけでなく、実際のリクエストも確認してください。

アプリを再取得する際もシステムのセキュリティを保つ

再インストールが必要な場合は、アプリのダウンロードから該当するプラットフォームを選択します。iPhone／iPad版はApp Storeから入手し、システム要件はApp Storeのページに記載された内容を確認してください。Mac、Windows、Android、Linuxのインストーラーは、当サイトの/dl/から入手できます。Macでは「このMacについて」でAppleシリコンかIntelかを確認してから選んでください。外観だけでインストーラーを選ばないでください。プラットフォームやアーキテクチャの不一致は、サーバー設定の問題ではありません。

デスクトップ版とAndroid版のインストーラーにはコード署名がありません。初回起動時にシステムによってブロックされる場合があります。WindowsのSmartScreenでは、入手元を確認してから「詳細情報」を開き、「実行」を選択します。Macで開発元を検証できないと表示された場合は、「プライバシーとセキュリティ」で該当アプリの「このまま開く」を確認してください。ダウンロードしたShadowrocketだけを対象に操作し、インストールのためにシステム全体のセキュリティチェックを無効にしたり、保護設定を長期間下げたりしないでください。

Androidでは、システム設定でインストールに使うブラウザーまたはファイル管理アプリに「不明なアプリのインストール」を許可します。完了後は必要に応じて権限を取り消してください。WeChat内でダウンロードできない場合は、システムのブラウザーを使います。Linuxではディストリビューションに合わせてdeb、rpm、AppImageを選び、インストール手順に従って権限を設定してください。詳しくはMac・WindowsのインストールガイドとAndroidのインストールガイドをご覧ください。

1つずつ設定を戻し、変更履歴を残す

再インストールする前に、バックアップからサーバー、ルール、必要な設定を復元できることを確認します。機密情報は自分の安全な場所にだけ保存してください。アンインストール後もすべてのデータが残るとは限りません。また、システムのVPN構成はアプリ全体のバックアップではありません。復元時はまず1つの項目をインポートして接続し、次にサブスクリプションとルールを戻し、最後に自動接続の条件を復元します。各段階で同じ接続先をテストすれば、問題がいつから始まったのかを特定しやすくなります。

新しいシステムや特定の設定の組み合わせでだけ再現する場合は、最短の再現手順、システム情報、エラーの全文、個人情報を除いた最小構成をまとめてください。報告にサブスクリプション全体や実際のパスワードを添付する必要はありません。公開すると別のリスクが生じます。原因がまだ分からない場合は、動作確認済みの設定コピーを残し、それ以上変更を重ねないでください。目標はすべての設定を変更することではなく、根拠を確認しながら機能を復旧することです。

iPhoneは正常でiPadだけ失敗する場合の比較方法

iPhoneでは使えるサブスクリプションがiPadでは接続できない場合、まず2台を同じWi-Fiに接続し、同じサーバー項目を選び、Global Routingと有効な設定を確認します。サブスクリプション名が同じだけでは、正確な比較になりません。2台で別の項目を選んでいたり、一方が古いルールを使っていたりすることがあります。確認後に同じ接続先へリクエストを送り、接続アイコンだけでなく実際の結果を記録してください。

次にiPadの日付、時刻、VPN権限、通常のネットワーク接続を確認します。Wi-FiモデルのiPadにはモバイル通信がないため、スマートフォンの切り替え手順をそのまま使うことはできません。許可を得たうえで別のネットワークやパーソナルホットスポットと比較してください。セルラーモデルでは、アプリのモバイルデータ通信がシステムで許可されているかも確認します。ネットワークの接続元だけを一度に1つ変更し、設定は変えずに保つことで、問題がネットワークに起因するか判断できます。

公衆Wi-Fi、ホットスポット、ローカルネットワークへのアクセス

公衆Wi-Fiで認証が必要な場合は、Shadowrocketを切断してWeb認証を済ませてから接続します。認証ページが自動で表示されない場合は、システムのWi-Fi画面で接続状態を確認し、そのネットワークが用意している通常の方法で認証してください。ホットスポットにも独自の上流ネットワーク条件があります。スマートフォン自体で目的のサイトにアクセスできても、iPadに共有された経路がスマートフォンのアプリと同じとは限りません。iPadで通常のアクセスを個別に確認してください。

プリンター、画面共有デバイス、ローカルネットワークサービスにアクセスできない場合は、まずシステムのローカルネットワーク権限、2台が同じネットワークセグメントにあるか、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
FINAL,PROXY

画面ロック後の復帰とマルチタスクでの接続確認

iPadの画面ロック後に再び使う際は、まずシステムのWi-Fiが復旧しているかを確認し、その後クライアントの状態を見ます。ネットワーク復旧中に一時的に失敗しても、サブスクリプションが無効になったとは限りません。通常のネットワークが使えるようになってから接続し直し、新しいリクエストでテストしてください。ロック解除のたびに同じ問題が再現する場合は、ロック前後のネットワーク、On Demandの条件、エラーの時刻を記録します。バッテリーの章でバックグラウンド動作と再接続を確認し、同じサブスクリプションを何度もインポートしないでください。

Split View、ステージマネージャ、外付けキーボードで変わるのは操作方法です。別の端末で選択したサーバーが自動的に同期されるわけではありません。トラブルシューティングではShadowrocketとテスト対象のアプリを順に開き、変更が保存されて適用されていることを確認してください。複数の設定編集画面を開いてコピーを取り違えないようにします。マルチタスク中に特定のアプリが古い接続を維持している場合は、そのリクエストを終了してから再試行し、古いセッションの経路を新しいルールが適用されていない証拠と誤認しないようにします。

設定の移行、端末の制限、問題の報告方法

iPhoneからiPadに設定を移した後は、サーバーの詳細、ポリシー参照、システム権限を端末ごとに確認します。ファイルをコピーしても、別の端末でVPN権限があることまでは確認できません。現在のネットワークに依存するローカルドメイン名やアドレスも、新しい端末で使えるとは限りません。利用中のサービスで同時接続数に制限がある場合は、比較のためにもう一方の端末を切断し、サービスの管理者に条件を確認してください。クライアントからリモートのアカウント制限を変更することはできません。

アプリでだけ問題が起き、同じ端末のブラウザーでは正常な場合は、そのアプリのネットワーク権限と接続先を確認してください。ブラウザーでの成功だけを根拠に、すべての通信が正常なはずだと判断しないでください。学校や企業の管理対象端末では管理設定を残し、管理者に相談します。制限を自分で解除しないでください。報告にはiPadのネットワークの種類、画面ロックからの復帰後かどうか、選択中の設定、エラーの全文を記載し、サブスクリプション、ユーザーID、パスワードは伏せます。