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

接続スイッチがオンにならない・VPN構成の権限

スイッチをオンにしてもすぐオフに戻る場合は、サブスクリプションを変更する前に、システムがVPN構成の作成を許可しているか確認してください。サーバーに接続できない問題は通常、接続確立後のリクエスト段階で発生します。システム構成が許可されていなければ、サーバー情報が正しくても通信は正常に行われません。まず接続をオフにし、端末自体で通常のWebページを表示できることを確認します。そのうえでスイッチを再度オンにし、システムの許可、認証、管理上の制限に関するメッセージが表示されるか確認して、全文を記録してください。

初回の許可と、誤って拒否した場合の対処

iPhoneまたはiPadで初めて接続を開始すると、VPN構成の追加を求めるシステムメッセージが表示される場合があります。開いたばかりのShadowrocketからの要求であることを確認して追加を許可し、システムの指示に従って端末の認証を完了してください。追加を許可しても、サブスクリプションが有効であることやサーバーが稼働中であることは保証されません。以前に拒否した場合は、アプリに戻ってもう一度試してください。メッセージが表示されない場合は、システム設定のVPN管理画面で該当する構成があるか確認します。

システム設定のメニュー構成はOSの更新により変わることがあります。設定内検索でVPNを探してください。構成名と関連付けられたアプリを確認し、別の用途の構成をShadowrocketのものと取り違えないようにします。該当する項目が破損または重複している場合は、まずアプリ内の設定を保存し、接続をオフにしてから、Shadowrocketのものと確認できた無効な項目だけを削除し、アプリに戻って再度許可してください。学校、勤務先、またはデバイス管理から配布された構成は一緒に削除しないでください。管理ポリシーで制御されている可能性があるため、端末の使用権限を先に確認してください。

スイッチが戻る・自動再接続・構成の競合

許可した後もスイッチがすぐオフに戻る場合は、VPNインターフェースを持つネットワークフィルタリングツールを含め、別のVPN接続がネットワークを引き継いでいないか確認してください。他の接続を一時停止してからテストし、DNSとルールを同時に変更しないでください。スイッチをオフにしても自動でオンに戻る場合は、On Demandとシステム側の対応するオンデマンド接続設定を確認します。接続のトリガー条件と手動操作が重なっている可能性があり、スイッチの変化だけでアプリのクラッシュとは判断できません。

管理対象の端末では、VPNの追加やネットワーク拡張の変更が制限されている場合があります。何度再インストールしてもポリシーは解除されず、既存の設定を失うおそれもあります。まずシステムに管理プロファイルが表示されているか確認し、制限のメッセージを端末管理者に確認してください。個人所有の端末では、設定を保存してから一度再起動し、ネットワーク拡張が一時的に解放されていない状態を解消します。再起動後は最小限の設定と既存サーバー一つでテストし、スイッチが安定してからOn Demandなどの自動化条件を戻してください。

権限の問題とアプリの終了を見分ける

アプリがバックグラウンドに移行しても、接続が停止したとは限りません。システムのVPN状態と実際のリクエストで判断してください。特定の設定を開くとアプリが終了する場合は、その設定のコピーを別に保存し、最近追加したルール、外部リソース、異常に長い設定内容を確認します。同じファイルを何度もインポートしてコピーを増やさないでください。以前正常に動作していた設定で再テストします。古い設定では正常で新しい設定では異常が出る場合は、設定の差を引き続き調べればよく、アカウントやサブスクリプションの有効期限を先に確認する必要はありません。

Mac、Windows、Androidで初回起動がブロックされた場合は、まずダウンロードページのインストール許可手順に沿ってシステム上で許可し、その後に接続を確認してください。Macでは「プライバシーとセキュリティ」で「このまま開く」を確認し、Windowsではパッケージの入手元を確認してからSmartScreenの「詳細情報」を確認します。Androidでは、インストールを実行するアプリに「不明なアプリのインストール」を許可してください。インストール時に起動できない問題と、接続後にインターネットを利用できない問題は別です。それぞれ分けて記録し、起動許可をネットワークの修復と混同しないようにしてください。

接続済みなのにインターネットを利用できない：まずルーティングモードを確認

システムにVPN接続済みと表示されても、ネットワーク拡張が動作していることを示すだけで、すべてのリクエストが宛先に届いているとは限りません。すべてのWebページが開かない場合は、Shadowrocketをオフにし、同じネットワークで以前直接アクセスできたページを開いてください。オフにしても失敗する場合は、Wi-Fi、モバイルデータ通信、ネットワーク認証、システム時刻を先に確認します。オフにすると直る場合は、選択中のサーバー、Global Routing、DNSを比較します。テスト対象は毎回同じものを使い、Webサイト側の変化が混ざらないようにしてください。

3つのモードで比較する

Global RoutingのConfigは現在の設定に従って通信を処理し、Proxyは該当するリクエストをプロキシ経由にし、Directは直接接続の比較に使います。トラブルシューティングでは一時的に切り替えられますが、元のモードと選択中の設定を先に記録してください。Proxyでは正常でConfigでは失敗する場合は、ルールの一致、ポリシーの指定、設定リソースを優先して確認します。Proxyでは失敗しDirectでは正常な場合は、サーバーまたはプロキシ経路を確認します。どちらも失敗する場合は、基本ネットワーク、DNS、接続先のサービスを確認してください。

これらの結果は原因を絞り込む手がかりであり、確定的な証明ではありません。接続先によっては現在の直接接続経路からアクセスできず、Directでの失敗は比較にならない場合があります。また、アプリが確立済みの接続を使い続け、モードを切り替えた直後のリクエストが以前の経路を通ることもあります。切り替え後は接続先アプリの古いページを閉じ、新しいリクエストを実行してください。必要に応じてShadowrocketを切断して再接続します。長時間開いたままのページを更新しただけで結論を出したり、VPNアイコンだけで実際のアクセスを判断したりしないでください。

ルールの順序と最終ポリシーを確認する

Configでは、ファイル一覧に最近インポートした名前があるかではなく、現在実際に選択されているファイルを確認します。ルールは通常、上から順に照合されます。広範囲に一致するルールが先にあると、後続のルールより先に適用されることがあります。最後のFINALは、それまでに一致しなかったリクエストの処理先を決めます。以下は構文の例であり、現在の設定全体と置き換えられるファイルではありません。例のドメインは説明用です。変更前に、設定内のPROXYとDIRECTがそれぞれどの処理を示しているか確認してください。

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

特定のWebサイトだけ失敗する場合は、そのサイトに対するDOMAIN、DOMAIN-SUFFIX、REJECTのルールがないか確認し、リクエストに実際に適用されたルールを調べてください。Webサイトはログイン、画像、APIに複数のドメインを使うことがあります。トップページが開いても、すべての関連リソースに適切なポリシーが適用されているとは限りません。ルールファイル全体を削除するのではなく、失敗したリクエストのドメインから調べます。適用されたポリシーが存在しないポリシー名や利用できないサーバーを参照している場合は、参照先を修正してから再テストしてください。

根拠を確認してから設定を変更する

元の設定を残し、必要なルールだけを含むテスト用コピーを作成して、同じ既存サーバーで比較できます。テスト用コピーで正常に戻る場合は、複雑なルール、リソース参照、追加設定が原因である可能性が高いです。どちらも失敗する場合は、サーバーと名前解決を再確認してください。設定、サブスクリプション、システムネットワークを同時に変更すると、復旧しても原因が分からなくなります。3つのモードの使い分けについては、Global Routingの3つのモードの解説をご覧ください。

修復後は日常使用するConfigに戻し、以前失敗したページ、通常の直接接続ページ、よく使うアプリをもう一度確認してください。一時的なProxyテストが成功しても、ルーティングが修復されたとは限りません。変更したルール、ポリシー、名前解決設定を記録し、テスト用に追加した項目を取り消します。再発時に設定全体を推測し直さずに済むよう、最小限の再現手順を残してください。

サーバーのタイムアウトとプロトコル設定の不一致

サーバーのタイムアウトは、「名前解決」「ポート接続」「プロトコルのハンドシェイク」「接続先へのリクエスト」の4段階に分けて考えます。Connectivity Testで結果が返らなくても、サーバーが完全にオフラインとは限りません。テスト対象に到達できない、テスト方法が適していない、プロトコルのハンドシェイクに失敗しているなど、似た症状が起こることがあります。まず、失敗が単一のサーバーかサーバーグループ全体か、特定のネットワークだけで起きるかを記録してください。サーバー情報はご利用のサービス提供元から取得した最新の内容を確認し、名前からプロトコルを推測しないでください。

まずアドレスとポートに到達できるか確認する

サーバーの詳細画面で、アドレスに空白、改行、プロトコルのプレフィックスが混入していないか、ポートがサーバー側の情報と一致しているか確認します。通常、アドレス欄に入力するのはホスト名またはIPアドレスで、WebページのURL全体ではありません。ドメイン名を使う場合は正常に名前解決できるか確認してください。IPアドレスを使う場合でも、TLS用のサーバー名を別途入力する必要があることがあります。特定のWi-Fiだけ失敗しモバイルネットワークでは正常な場合は、そのネットワークのログイン認証、UDPの利用条件、外部接続の制限を確認し、すべてのサーバーをすぐにリセットしないでください。

サーバーグループ全体が同時にタイムアウトする場合は、同じドメイン、同じサブスクリプション、同じネットワーク出口を使っていないかも確認してください。名前が違っていても、実際には同じベースアドレスを共有している場合があります。以前使えていたと分かっている項目と比較し、サービス側のメンテナンス状況や利用権限の有効性を確認します。テストを際限なく繰り返さないでください。並行して連続テストするとネットワーク負荷が増え、サーバー側の制限に触れることもあります。前のテストが終わるまで待ち、代表的な項目を少数に絞ると傾向をつかみやすくなります。

ハンドシェイクの条件を項目ごとに確認する

ポートに到達できても実際のリクエストが失敗する場合は、認証、暗号化方式、通信設定を重点的に確認します。Shadowsocksの暗号化方式とパスワードは一致している必要があります。VMessとVLESSのユーザーID、通信設定はサーバー側と一致させてください。TrojanではパスワードとTLSの条件を確認します。サーバーアドレスが同じだからといって、以前の項目をそのまま流用しないでください。サブスクリプションの更新で通信方式が変更されることがありますが、手動作成した項目には自動で反映されません。最新情報と各項目を比較してください。

証明書エラーが発生した場合は、まず端末の日付、時刻、タイムゾーンを確認し、サーバー名と証明書が一致しているか確認してください。証明書検証を無効にすることを通常の解決策にしないでください。接続先の誤りやサーバー証明書の期限切れは解決できず、接続先の本人確認を弱めることになります。WebSocketでは、接続先アドレス、Host、パスがそれぞれ異なる役割を持ちます。一見重複しているように見えても、安易に削除しないでください。曖昧なタイムアウト結果より、エラー全文に含まれるハンドシェイク、認証、証明書のメッセージの方が診断に役立ちます。

テスト結果と実際のアクセスを照合する

遅延テストの結果は、特定の方法でテストした際の応答を示すもので、ページの読み込み、継続的なダウンロード、動画再生がすべて正常であることを示すわけではありません。テストが失敗しても実際のアクセスが正常なら、まずテスト対象と方法を確認します。テストが正常でもWebページが失敗する場合は、DNS、ルール、接続先のサービスを引き続き確認してください。同じネットワーク、接続先、設定で複数の既存サーバーを比較し、変数を絞り込みます。選び方については、遅延テスト、地域、プロトコルの種類に関する解説をご覧ください。

サービス提供元に問い合わせる際は、プロトコルの種類、失敗したネットワーク、エラーが発生した時間帯、全サーバーに影響しているか、情報を隠したエラーメッセージを伝えてください。サブスクリプションURL全体、ユーザーID、パスワード、秘密鍵は送らないでください。クライアント側で確認できるのは、設定項目の整合性と問題の範囲です。サーバー側のログを確認することはできません。複数のネットワークで同じハンドシェイク段階に失敗する場合は、関係のない項目を端末側で変更し続けるのではなく、サーバー側で認証、待ち受けポート、証明書を確認してもらってください。

Subscribeの更新失敗・リストが空・項目の重複

Subscribeの取得失敗と、サブスクリプション内のサーバーが使えない問題は別です。前者はサブスクリプション内容のダウンロード、認証、解析時に発生し、後者はインポート済みの項目への接続時に発生します。まず古いリストを残し、更新時のエラー全文を記録してから、URLにアクセスできないのか、応答ステータスに問題があるのか、内容を解析できないのかを確認します。一度の更新失敗で、まだ使える古い項目を削除しないでください。削除して再追加すると、比較に使える設定の差まで失われることがあります。

URLの完全性とアクセス経路を確認する

サブスクリプションURLはご利用のサービス提供元から取得し、コピーする際はクエリパラメーターを含めてすべて選択してください。チャットアプリによる自動改行、末尾の句読点、前後の空白、文字参照を元の記号として貼り付けてしまうことなどでURLが変わる場合があります。例に含まれるtokenは書式を示すだけで、実際の更新には使えません。公開スクリーンショット、問い合わせの件名、ブラウザーの共有履歴に本物のURLを表示しないでください。URLには個人用サーバーリストを読み取るための認証情報が含まれていることがあります。

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

ホスト名の名前解決、TLS、タイムアウトに関するエラーが出る場合は、まず接続をオフにし、基本ネットワークが使えることと端末の時刻を確認します。次に、現在の更新リクエストが無効になったプロキシ経路に依存していないかを確認してください。プロキシを有効にした場合だけ更新に失敗するなら、元の設定を記録してから、一時的に利用可能なネットワーク経路で再試行できます。サブスクリプション更新の経路が特定のGlobal Routingの動作に必ず従うとは限りません。現在の設定、リクエスト記録、実際のテスト結果をもとに判断してください。

認証エラーと内容の形式エラーを見分ける

認証されていない、アクセス禁止、アドレスが存在しないなどの応答がある場合は、サービス提供元から受け取った情報を確認し、URLが無効化、リセット、期限切れになっていないか確認してください。何度更新しても無効な認証は修復されません。ログインページ、ネットワーク認証ページ、エラーメッセージが返ってきた場合は、ネットワークリクエスト自体が成功しても、クライアントにインポートできるサーバーデータではありません。公共Wi-Fiで認証が完了していない場合によく起こるため、接続をオフにしてネットワークにログインしてから、もう一度取得してください。

リクエストが完了してもインポート結果が空の場合は、提供された形式が現在のインポート方法に適しているか確認してください。Subscribe、単一サーバーのリンク、QRコード、Configファイルは用途が異なり、相互に置き換えられるものではありません。ファイルの拡張子だけで内容を判断せず、Webページの説明用URLをサブスクリプションURLとして使わないでください。複数の形式が提供されている場合は、Shadowrocket用と明記されたものを選びます。説明がなければ、同じURLをすべてのインポート方法で試すのではなく、形式を問い合わせてください。

更新後に消えた項目・重複・手動編集への対処

更新後にサーバー数が変わった場合は、サーバー一覧の変更、フィルター条件の変更、既存項目の置き換えなどが考えられます。クライアントが誤って削除したとは限りません。まずSubscribeに対応するグループを確認し、手動追加した項目とサブスクリプションの項目が同じ画面に表示されていないか調べます。サブスクリプションで管理される項目は、次回の更新でサーバー側の内容に上書きされる場合があります。個別の変更を残す必要がある場合は、管理方法を確認し、必要に応じて分かりやすい名前の手動コピーを作成してください。その項目は今後サブスクリプション更新に自動追従しないことも記録します。

項目の重複は、同じURLを複数回追加した、別のサブスクリプションに同じサーバーが含まれている、手動コピーと自動更新リストが共存しているなどの理由で起こります。整理する前に、各項目の取得元と更新日時を確認し、表示名だけを見て削除しないでください。有効と確認できたSubscribe項目を一つ残し、重複している取得元を一つずつ削除します。新しいリストで古いパラメーターが上書きされて接続に失敗する場合は、削除していないコピーとアドレス、ポート、TLS、通信設定を比較し、明確な違いをサービス提供元に確認してください。

復旧後は、必要のない手動更新を何度も繰り返さず、必要に応じて更新し、直近の正常な設定コピーを保存してください。再インポートする前に、Subscribeのインポート手順を読み、同じ方法と正しい形式を使ってください。QRコードから追加する場合は、Scan QR Codeの操作ガイドをご覧ください。認証URLが漏えいした可能性がある場合は、ローカルの表示名を変更するだけでなく、サービス提供元に認証のリセットを依頼してからクライアント側を更新してください。

通信速度が遅い・ページが重い・接続が切れる

速度が遅い場合は、まず「何が遅いのか」を具体的にします。最初のページ表示に時間がかかる、画像の読み込みが続く、大容量ファイルの転送速度が低い、しばらく使うと切断される、などです。それぞれDNS、ハンドシェイク、継続的な帯域、パケットロス、ネットワーク切り替えが関係している可能性があります。発生時のネットワーク、接続先、選択中のサーバー、他のダウンロードの有無を記録し、Shadowrocketをオフにした同じ操作と比較してください。一度の遅延値から通信全体のスループットを推測したり、接続先サイトの速度制限をクライアントの性能問題と見なしたりしないでください。

再現可能なテスト条件を整える

普段安定して使っている接続先を一つ選び、同じ場所、同じネットワークで繰り返し操作します。テスト中はシステム更新、クラウド同期、その他の大容量通信を一時停止し、帯域の競合をプロキシの速度低下と取り違えないようにしてください。Wi-Fiの電波表示だけでは通信品質を判断できません。無線環境の混雑、ルーターの負荷、上り回線の飽和も待ち時間の原因になります。まずルーターに近い場所と通常の位置を比較し、その後Wi-Fiとモバイルネットワークを比べると、ローカルネットワークと遠方の通信経路の問題を分けやすくなります。

複数の既存サーバーを比べる際は、接続先、プロトコルの使い方、テスト時間帯をできるだけそろえてください。サーバー名に含まれる地域名だけでは経路の長さは分かりません。また、遅延が小さくても混雑時に十分な帯域があるとは限りません。最初の応答と継続的な転送の両方を確認します。前者が遅く後者が安定している場合は、名前解決やハンドシェイクを調べます。前者が速くても後者が途切れる場合は、パケットロス、サーバー負荷、接続先の制限を重点的に確認してください。テスト結果はそのときの条件に限られるため、固定的な順位付けには使えません。

ルーティングや接続の再利用による見かけの問題を確認する

Webページのリソースごとに異なるルールが適用される場合があり、一部のリクエストが失敗するとページ全体の読み込みが止まることがあります。トップページのドメインだけでなく、読み込みが止まったリソースのドメインを確認してください。Configで失敗し一時的なProxyで正常な場合は、ルールとポリシーを調べます。どちらも遅い場合は、サーバーと基本ネットワークを比較してください。サーバーを切り替えた後も、既存の長時間接続が以前の経路を使い続けることがあります。該当する接続を終了して新しいリクエストを開始してください。切り替えが反映されたかを判断するには、新しい接続の結果を使います。

通話、ゲーム、その他のリアルタイムアプリで接続が切れる場合は、UDPが必要か、現在のプロトコルとネットワークでその通信が許可されているかを別途確認してください。Webページが開いてもUDPが正常とは限りません。UDPを使うプロトコルでも、特定のWi-Fiでは接続できないことがあります。MTUや通信設定を手当たり次第に変更せず、特定の種類のパケットまたはネットワークだけで問題が起きることを確認してください。調整が必要な場合はサーバー側の推奨値を参考にし、元の値を保存してから一項目ずつ再テストします。別の問題を増やさないようにしてください。

Dataとリクエスト記録で原因を絞る

Dataを確認する際は、まず集計範囲、時間帯、現在の接続状態を確認します。特定のサーバーの通信量が増えていても、その経路でデータが処理されたことを示すだけで、接続先の読み込みがすべて完了したとは限りません。アプリごとの使用量を見る場合は、システムサービス、バックグラウンド更新、キャッシュも考慮してください。キャッシュから開いたページは実際の速度テストには使えません。基準となる値を記録し、明確なリクエストを一度実行してから、通信量の増加とリクエスト記録が対応しているか確認します。数値について詳しくは、Dataの通信量統計の解説をご覧ください。

画面を消した後、Wi-Fiから離れた後、またはモバイルネットワークに切り替えた後に接続が切れる場合は、まずネットワーク切り替えの問題として記録してください。再接続ですぐ復旧するなら、サーバーをすべて交換し続けるのではなく、On Demandの条件や元のセッションが無効になっていないか確認します。モバイル環境ではネットワークアドレスが変わることがよくあり、長時間接続は再確立が必要な場合があります。古いセッションが維持されるかより、新しいリクエストが復旧するかの方が、現在の設定の有効性を判断する材料になります。移動による影響を避けるため、静止した環境でも再テストしてください。

原因を特定したら、テスト用に追加した一時的なルールや特殊な設定を取り消し、日常使用する設定に戻してから、Web閲覧、継続的な転送、ネットワーク切り替えの3つを確認します。互いに重なる「最適化」設定を複数残さないでください。追加設定そのものが診断を難しくすることがあります。どの変更がどの症状を解決したか明確に記録できて初めて、再利用できる修復記録になります。一度のテストで偶然速くなっただけでは十分ではありません。

DNSの名前解決失敗とルールの適用異常

DNSの問題は、ドメインを開けない、初回アクセスに時間がかかる、一部のリソースだけ失敗する、ネットワークによって同じWebサイトの結果が異なる、といった形で現れます。確認するのは、名前解決が完了したか、返されたアドレスに到達できるか、名前解決リクエストがどの経路を通ったかです。「ドメイン名では失敗し、IPアドレスを直接入力すると成功する」ことだけを決め手にしないでください。HTTPS証明書、仮想ホスト、Webサイトのルーティングはドメイン名に依存することが多く、IPアドレスへの直接アクセスでは別のサービスが返る可能性があるため、信頼できる比較になりません。

名前解決のタイムアウトと、名前解決後の接続失敗を区別する

まずリクエスト記録でエラーが起きた段階を確認します。アドレスを取得する前にタイムアウトする場合は、DNSサーバーへの到達性とリクエストの経路を確認してください。アドレスを取得した後に接続できない場合は、接続先、ルール、IPv6経路を調べます。複数の異なるドメインで同時に問題が起きる場合は、名前解決経路を優先して確認してください。単一のドメインだけで起きる場合は、そのドメインのレコード、証明書、サービスの状態も考慮します。失敗した完全なホスト名を記録し、APIのサブドメインとトップページのドメインを混同しないでください。

端末では、システムDNS、Wi-Fiの手動DNS、アプリ内設定、その他のネットワークフィルタリング設定が同時に影響する場合があります。まず各層の元の値を記録し、現在どの設定が実際に使われているか確認してください。システムとアプリで複数のアドレスを次々に変更すると、テスト結果を解釈できなくなります。暗号化DNSを使う場合は、そのホスト名自体を名前解決できることと、TLS接続が確立できることも確認してください。名前解決方式を別の方式に変更しても、DNSサーバーまでのネットワーク障害が自動的に解消されるわけではありません。

DNSとルーティングが互いに依存していないか確認する

一部の設定では、プロキシ接続を確立するために先にサーバーのドメインを名前解決する必要があります。しかし、その名前解決リクエストをまだ確立されていないプロキシ経路に送ると、依存関係が循環することがあります。起動時に名前解決が失敗する場合は、Webサイトのドメインだけでなく、サーバーアドレスの名前解決経路も確認してください。以前正常だった設定と比較し、どのリクエストにシステムの名前解決を使い、どれに設定内の名前解決を使うかを確認します。まず接続を開始できる最小限の経路に戻し、サーバー接続が確立してから他のDNS条件を段階的に戻してください。

ドメインベースのルールとアドレスベースのルールでは、対象が異なります。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致し、IP-CIDR、IP-CIDR6、GEOIPはアドレスを対象とします。no-resolve付きのアドレスルールを追加すると、通常、そのルールに一致する通信のために名前解決を積極的に行わないという意味であり、クライアント全体のDNSを無効にするわけではありません。以下はルール構造の例です。ドキュメント用の予約アドレスとexample.comは説明用の素材であり、ご利用のLANの範囲や実際の要件を示すものではありません。

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

IPv6、キャッシュ、LANの範囲

ドメインがIPv4とIPv6の両方を返す場合、各経路の到達性が異なることがあります。特定のネットワークだけで長時間待たされる場合は、利用できないアドレス経路が優先されていないか確認してください。元の設定を保存したうえで、関連するIPv6オプションを一時的に変更して比較できますが、IPv6を恒久的に無効にすることを一般的な解決策としないでください。新しいリクエストが復旧するかを確認し、別のネットワークでも再テストします。そうしないと、特定のネットワークで一時的に回避できただけなのに、設定と実際のネットワーク機能の不一致を見落とすことがあります。

DNSを変更しても、古いキャッシュや既存の接続が残っている場合があります。いったん切断して再接続し、接続先への新しいリクエストを開始してください。必要に応じて接続先アプリも再起動します。キャッシュを消すためにShadowrocketを何度も再インストールしないでください。LAN機器の名前、プリンターサービス、社内ドメインはローカルの名前解決に依存している場合があり、すべてをリモートで名前解決するとかえって失敗することがあります。必要なローカル名とネットワークには適切な経路を設定し、内部アドレスは信頼できるネットワークでのみテストしてください。機密性の高い名前を公開の問い合わせに含めないようにします。

最終確認では、通常のドメイン、以前失敗したドメイン、必要なローカルサービスをすべてテストします。ルールの適用と名前解決結果が想定どおりであることを確認したら、一時的な比較設定を削除してください。「特定のネットワークでは名前解決がタイムアウトし、別のネットワークでは正常」という状態を安定して再現できる場合は、その違いを記録して、該当するネットワークまたはサーバーの管理者に伝えます。Webページのエラー画面だけでは、名前解決、ハンドシェイク、接続先の応答のどの段階に問題があるのか分からないことがほとんどです。

バッテリー消費が多い・発熱・バックグラウンドで接続を繰り返す

バッテリー消費を判断する際は、システムのバッテリー一覧に表示される割合だけでなく、使用状況と観察した時間帯を確認してください。VPN関連の処理には、ネットワーク拡張を経由する他のアプリの通信も含まれる場合があります。特定項目の割合が増えていても、同じ時間帯に他のアプリの消費が減っただけかもしれません。通信が継続していたか、電波の弱い環境だったか、端末を充電していたか、どの設定変更から問題が始まったかを記録します。OS更新、データの復元、クラウド同期の直後に起きた短時間の発熱を、すぐにプロキシが原因だと判断しないでください。

継続的な通信と異常な再試行を見分ける

ネットワークが安定し端末の温度が正常な環境で、接続をオンにしたまま少量だけ使う場合、継続的にダウンロードする場合、接続をオフにした場合を、それぞれ同じ条件で観察します。画面の明るさ、前面のアプリ、ネットワークをできるだけそろえないと、有意義な比較になりません。大量の通信時だけバッテリー消費が増えるなら、無線通信や暗号化処理が主な原因かもしれません。操作していないのに発熱が続く場合は、まずバックグラウンドアプリ、接続の再試行、ログ記録、自動更新タスクを確認し、プロトコルの設定を先に変更しないでください。

リクエスト記録で失敗の繰り返しを探します。同じホストへの連続タイムアウト、サブスクリプションの繰り返し更新、サーバー認証の連続失敗などは、端末が接続を繰り返し確立する原因になります。最初に発生したエラーを修正してください。その後の再試行も減ることがあります。すべてのタイムアウト値を短くしても省電力にはなりません。待機時間が短すぎると再接続が増える場合があります。また、Connectivity Testをサーバーグループ全体に頻繁に実行しないでください。広範囲のテスト自体が追加の通信となり、バッテリー消費の観察を妨げます。

On Demandとネットワーク切り替えを確認する

On Demandの条件は、実際の使用環境に合わせてください。Wi-Fiの電波が不安定な場所、モバイルネットワークへの切り替え、不適切なネットワーク名の条件などにより、接続の開始と停止が繰り返されることがあります。まずトリガー条件を記録し、自動接続を一時的にオフにして、一定時間手動接続で比較します。バッテリー消費と頻繁な再接続が同時に減る場合は、条件を一つずつ戻し、繰り返しを引き起こす項目を特定してください。アプリ画面を閉じただけでバックグラウンド接続が停止したとは限りません。システムのVPN状態を確認してください。

2つのWi-Fi間を移動することが多い端末や、スリープ後に再接続する端末では、既存のセッションが無効になって再確立される場合があります。接続し直した後にすぐ安定するかを確認し、毎回の再確立を異常と判断しないでください。注意が必要なのは、失敗が続く、短時間に何度も切り替わる、通信がないのに端末が長時間動作し続けるといった状態です。固定した場所と単一のネットワークで再テストしてください。固定環境では正常で移動中にだけ異常が出る場合は、まず無線の電波状況、ネットワークの切り替え、オンデマンド条件を確認します。

診断中の余分な負荷を減らす

トラブルシューティングのために有効にした詳細ログ、長時間の通信記録、大量のテストは、必要な情報が得られたら通常の設定に戻してください。問題を再現できる記録を少量残せば十分で、すべてのリクエストを記録し続ける必要はありません。設定に定期更新などのタスクがある場合は、頻度と失敗時の再試行を一つずつ確認します。まず不要な項目を一つだけ停止して比較してください。各回で一つのタスクだけを変更し、同じ条件で温度とバッテリーの変化を観察します。すべての機能を同時に停止すると、本当の原因が分からなくなります。

プロトコル、通信方式、ネットワーク品質によって処理負荷は変わりますが、サーバー側の条件を無視して自由に切り替えることはできません。まず設定が有効で、接続が安定していることを確認し、利用可能な既存サーバー間で比較してください。電波が弱い環境での再送、パケットロス後の再送、少量のリクエストの多発は、プロトコル名以上に影響する場合があります。前提条件のない固定の消費量を目指さないでください。バッテリーの劣化状態、画面の使用状況、周囲の温度でも結果は変わるため、同じ端末での変更前後の比較を重視してください。

Shadowrocketをオフにしても同じ状況で問題が続く場合は、サブスクリプションを何度もインポートし直さず、システムのバッテリー記録、バックグラウンド同期、ネットワークの電波状況を確認してください。特定の設定でのみ問題が起きる場合は元のファイルを保存し、最小限のテスト設定で再現して、自動タスク、接続トリガー、失敗時の再試行を重点的に比較します。修正後は、静置時と通常使用時の両方を少なくとも一度ずつ確認し、再接続が続かないことを確かめてください。システムのバッテリー統計には集計期間があるため、変更直後に結果へ完全に反映されるとは限りません。

バッテリー消費の問題を報告する際は、端末の種類、システム環境、使用ネットワーク、接続時間、主な操作を記載し、情報を隠した失敗記録を添えてください。バッテリー使用率のスクリーンショットだけでは、通信量や観察期間が分かりません。Dataの通信量の増加も記録すると、「大量に通信した」場合と「通信量が少ないのに再試行を続けた」場合を区別でき、適切な確認方法を選びやすくなります。

更新後の問題とiPadの確認項目

更新後に問題が発生した場合は、発生時期が近いというだけで因果関係を決めつけず、クライアント、システム、設定、サブスクリプションのどこが変わったかを確認してください。最後に正常に使えたときのネットワークと設定を記録し、現在の環境で再現します。クライアントの更新で、すでに無効になったサーバー側の認証が修復されるわけではありません。同様に、サブスクリプション更新後に設定が変わり、アプリの更新が原因だと誤解することもあります。復元や再インストールを検討する前に、現在のファイル、グループ、必要なスクリーンショットを保存し、原因を特定するための情報を失わないようにしてください。

すべての設定を消去せず、変更元ごとに復元する

iPhone / iPad版はApp Storeから入手・更新できます。システム要件はApp Storeの製品ページに記載された内容をご確認ください。iPhone / iPad版はApp Storeで2.99ドルの買い切りです。Mac（Appleシリコン・Intel）、Windows、Android、Linux版は無料で、その他のプラットフォームのインストーラーは当サイトのダウンロードページから入手でき、当サイトの/dl/パスを使用します。クライアントの買い切り料金とサーバー回線のプランは別です。クライアントを再入手しても、サービス提供元が無効にしたサブスクリプションの利用権限は復元されません。

iPhone / iPadのアプリを確認する際は、デベロッパー名がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認してください。機種変更または再インストール後は、購入時のアカウントで購入済みアイテムを探します。詳しい手順は購入済みアプリの復元方法をご覧ください。アプリを復元した後も、サブスクリプション、サーバー、Configがそろっているか確認してください。システムバックアップだけで現在の設定がすべて復元されたとは判断できません。パスワード、秘密鍵、認証情報も一台の端末だけに保存しないでください。

更新後は、まず次の3点を最小限の確認として実施します。システムの基本ネットワークが正常か、VPN構成の使用が引き続き許可されているか、既存サーバーの一つが簡易設定で動作するか。古い設定では失敗し簡易設定では正常な場合は、ルールと外部リソースを一つずつ戻します。すべての設定で失敗する場合は、権限、DNS、サーバーのパラメーターを確認してください。すべての設定を一度に保存し直すのは避けてください。無差別な変更で元の手がかりが上書きされることがあります。アプリが終了する場合は、「更新後に使えない」とだけ記録せず、終了を引き起こした操作を記録してください。

iPadのWi-Fi、テザリング、マルチウィンドウでの使用

Wi-Fi専用のiPadでは、ルーターの問題とプロキシの問題を分けて確認してください。利用可能な別のネットワークや個人用ホットスポットを比較に使えます。モバイル通信対応モデルでは、Wi-Fiとモバイルネットワークを別々にテストします。学校、勤務先、公共のWi-FiではWeb認証が必要な場合があるため、接続をオフにして認証を済ませてからShadowrocketをオンにしてください。iPhoneでは正常でiPadでは失敗しても、サブスクリプションが原因とは限りません。2台でDNS、Config、システムのVPN構成が異なる場合があります。

画面分割やマルチウィンドウで操作すると、「現在表示中の設定」と「実際に有効な設定」を混同しやすくなります。Shadowrocketに戻って、選択中のサーバー、Global Routing、Configを確認し、接続先アプリで新しいリクエストを実行してください。2台の端末で同じ表示名だからといって同じ設定とは限りません。名前が同じでも、ポート、TLS、通信設定が異なることがあります。端末全体の設定を消去してやり直すより、項目を一つずつ比較する方が原因を特定しやすく、正常なアプリのネットワーク状態も保てます。

外付けキーボードでサブスクリプションやサーバー情報を貼り付ける際は、先頭と末尾の空白、スマート句読点、改行に注意してください。端末間クリップボードを使う場合は、最新の内容をコピーしたか確認します。Scan QR Codeでインポートした後は、解析された項目の種類を確認してください。読み取りに成功したからといって、設定項目の確認を省略しないでください。iPadをスリープから復帰させた後、画面に古い状態が残っている場合は、接続が切れたと判断する前に新しいリクエストを開始します。古いページや長時間接続は、復帰後の実際のネットワーク状態を示しません。

日常設定への復帰と問題記録の完了

再インストールが必要な場合は、安全に復元できるConfigとサーバー情報を先に保存し、サブスクリプションURLをサービス提供元から再取得できることを確認してください。エクスポートした内容には機密性の高い情報が含まれる場合があるため、適切に管理された場所に保存し、公開のファイル共有で送らないでください。PCやAndroidで再入手後にシステムの警告が表示された場合は、ダウンロードページのインストール許可手順に従ってください。Macの「このまま開く」、Windowsの「詳細情報」、Androidのインストール権限は起動の問題を解決するものです。完了後は接続とルールを改めて確認してください。

トラブルシューティングが終わったら、日常使用するGlobal Routing、On Demand、必要なルールを復元し、一時的なDNS設定やテスト項目を取り消します。少なくとも、以前失敗した操作、通常のネットワークリクエスト、スリープ後またはネットワーク切り替え後の新しいリクエストを確認してください。最後に問題の範囲、原因、実際に変更した項目、再テスト結果を記録します。解決していない場合は、端末の機種だけでなく、再現可能な情報を添えて引き続き問い合わせてください。初回設定で確認し忘れた手順は、クイックスタートガイドに戻って順に確認できます。