公式マニュアル / 症状から探す

Shadowrocket トラブル対処ガイド

接続状態から確認し、サーバー、モード、ルール、DNSの順に調べます。一度に一項目だけ変更して同じ接続先で再テストし、異なる原因を混同しないようにします。

初めて設定する場合は、まず使い方ガイドを読み、基本手順に沿って読み込みと接続を完了してください。このページでは接続できないときの確認方法を説明します。基本操作に慣れている方は、下の目次から該当する症状を選べます。

以下の手順は、ご自身のサブスクリプションまたはサーバー情報をお持ちであることを前提としています。アプリの買い切り購入と接続サービスの契約は別です。当サイトは公式サイト・公式マニュアルとして、ノード、サブスクリプション、サービス事業者の提供・販売・推奨は行っていません。

01　スイッチをオンにできない：VPN構成の許可を確認

Homeのスイッチをオンにしても維持できない場合、まず端末上で接続を確立する段階に問題があります。Webページが開けない症状とは別です。スイッチを押したときにシステムの許可画面が出るか、すぐオフに戻るか、表示だけが変わるかを確認します。この3つを分けて記録すれば、その後の確認に役立ちます。この段階でサブスクリプションを何度も更新しても、通常はシステム権限の問題は解決しません。DNSも先に変更しないでください。

端末のネットワークとシステムの確認画面をチェック

まずShadowrocketの接続をオフにし、Safariで現在のネットワークから通常アクセスできるページを開きます。公衆Wi-Fiでログインが必要な場合は、先にネットワーク認証を済ませてからアプリに戻ってください。基本のネットワーク接続が確立していない状態では、VPNスイッチが一時的にオンになっても、接続先サービスが正常とは判断できません。モバイルデータ通信を使う場合は、システム設定でアプリのモバイルデータ通信が許可されているかも確認してください。Wi-Fiでしか操作できない状態を防げます。

初回接続時に、VPN構成の追加を許可するかシステムから確認されることがあります。要求元がShadowrocketであることを確認してから、画面の案内に従って許可し、必要な認証を完了してください。以前に確認画面をキャンセルした場合は、Homeに戻って再度接続し、もう一度表示されるか確認します。確認画面が表示されないからといって、許可済みとは限りません。システム設定のVPN管理画面で、該当する構成があるか確認してください。

システムメニューの名称や階層は、システム言語やバージョンによって異なる場合があります。設定内でVPNを検索してください。確認するのは、構成が存在するか、有効にできるか、端末に制限があるかです。決まったメニュー経路を探し続ける必要はありません。組織管理下の端末ではVPN構成の追加が制限される場合があります。その場合は端末の管理者に確認してください。サーバー設定を変更しても、端末側の制限は回避できません。

接続の競合を除外して、必要な構成を作り直す

端末にほかのVPN接続も登録されている場合、現在どの構成がネットワークを制御しているか確認してください。VPN経路を使うほかの機能を一時停止し、Shadowrocketだけでテストします。一部のネットワークフィルタリング機能も、関連するシステム機能を使用することがあります。設定を一度にすべてオフにせず、一つずつ停止して確認してください。ある機能を停止して問題が解消した場合は、その機能だけを再度有効にしてテストし、競合の有無を確かめます。

スイッチをオフにしても再びオンになる場合は、On Demandを確認してください。ネットワーク条件に応じた自動接続が、手動で切断した後にトンネルを再確立することがあります。切り分け中は条件を記録し、On Demandを一時的にオフにして手動スイッチで一連の動作をテストします。オンデマンド再接続をスイッチの故障と誤認しないようにしてください。条件を記録せずに自動接続の設定を消去するのも避けてください。

システムにShadowrocketの構成が存在するのに、有効にするたびすぐ失敗する場合は、現在の接続を終了して端末を再起動し、もう一度テストしてください。問題が継続して再現する場合に限り、該当するシステムVPN構成を削除し、アプリから再登録を申請することを検討します。事前にアプリ内の設定とサーバー情報を保存してください。システムVPN構成、Configファイル、サブスクリプション一覧はそれぞれ別のものです。ほかのデータまで一緒に削除しないでください。

この段階の確認が完了したか判断する

スイッチがオンの状態を維持し、システムのVPN状態とアプリの表示が一致していれば、端末上のトンネルは確立しています。ただし、サーバー認証、ドメイン名の解決、接続先へのアクセスまで成功したとは限りません。次は「接続後にインターネットを使えない」を確認してください。すぐ切断される場合は、エラーが出た場所と原文を記録し、許可前・許可後・ネットワーク切り替え時のどのタイミングかも書き添えます。「接続できない」とだけ記録するより、原因を特定しやすくなります。

02　接続済みなのにインターネットを使えない：モードとルールを切り分ける

VPNの表示は端末上にローカルトンネルが確立したことを示しますが、すべての通信が接続先まで届いているとは限りません。選択中のサーバー、Global Routingのモード、現在のConfig、DNSが最終的な通信結果に影響します。もともとアクセスできるはずのテスト先を2つ用意してください。1つはローカルネットワークの確認用、もう1つは既存サーバー経由の通信確認用です。どちらも普段使う一般的なページを選び、特定のアプリのコンテンツ読み込みだけで判断しないでください。

サーバーを固定して、3つのモードを比較する

Homeに戻り、SERVERで実際に選択されている項目を確認します。リストに表示されていても選択中とは限りません。サブスクリプション更新後に並び順が変わり、選択項目を取り違えることもあります。選択中の項目でConnectivity Testを実行し、結果を記録してください。数値が出ても、そのテスト経路から応答があったことを示すだけです。すべてのWebサイト、通信方式、DNSクエリが正常とは限りません。

次にGlobal Routingを確認します。Configモードは現在の設定に基づいて通信先を決定します。Proxyモードは現在のサーバー経由のアクセスを確認するために使います。Directモードはローカルネットワーク経由の経路との比較に使います。一時的なモード切り替えは原因の特定が目的であり、恒久的な修正ではありません。元のモードを記録してから切り替え、毎回同じ接続先でテストしてください。テスト後は元に戻します。

モード	確認する内容	結果の見方
Config	現在のルールとポリシーを確認	このモードだけ失敗する場合は、まずルールの適用先を確認
Proxy	現在のサーバー経路を確認	失敗する場合はサーバーと名前解決を確認
Direct	基本ネットワークと比較	失敗する場合は、まずローカルネットワークの状態を確認

ProxyでアクセスできてConfigではできない場合、パスワードを調べ続ける必要はありません。Configを開き、現在有効なファイルを確認します。接続先にREJECTが適用されていないか、存在しない、または正しく設定されていないポリシーに振り分けられていないか調べてください。Directでは正常でProxyでは失敗する場合も、すぐルールの問題と断定せず、「サーバーがタイムアウトする」と「DNS」の章で切り分けます。

実際の適用結果からルールの順序を確認

ルールは通常、上から順に照合されます。先にある広範なルールが通信を先取りすることがあります。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに適用され、IP-CIDRはアドレス範囲を対象とし、FINALはそれまでのルールに一致しなかった通信を処理します。切り分けでは、ファイル内に関係がありそうなルールがあるかだけでなく、実際の接続先と適用結果を確認してください。1つのWebページでも複数のサブドメインへリクエストを送ることがあります。トップページが表示されても、画像やログインAPIまで正常とは限りません。

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

これはルール順序の例であり、あらゆるネットワークに使える完全な設定ではありません。より具体的なads.example.comを、範囲の広いexample.comより前に置くと、先行するサフィックスルールに先取りされません。GEOIPはアドレスの地域情報に依存するため、すべてのドメインルールを代替するものではありません。この例全体を現在使用中のConfigに上書きしないでください。設定を複製し、問題が確認できたルールだけを変更します。

アプリの問題とネットワークの問題を分ける

Safariではアクセスできるのに特定のアプリだけ失敗する場合は、そのアプリが別のドメイン、リアルタイム通信、追加の通信方式を使っていないか確認します。アプリを開き直すと新しい接続が発生することがありますが、すぐにログイン情報を消去しないでください。ページがキャッシュから表示されている場合、古い内容が見えるだけでは確認になりません。更新して新しいリクエストが完了したことを確かめ、接続ログの時刻と接続先を照合してください。

ルールを1つ変更するたびに、同じリクエストを再実行してエラーが解消したか確認します。ネットワークを切り替えた後にだけ復旧する場合は、その条件を記録し、ローカルネットワークと名前解決を調べてください。関係のない直前の変更のおかげで偶然直ったと判断しないようにします。簡潔な確認リストはスイッチがオンでもインターネットに接続できない場合の確認項目をご覧ください。初回接続の手順は使い方ガイドに戻って確認できます。

03　サーバーのタイムアウト：通信、TLS、認証を切り分ける

「タイムアウト」は、ある処理が制限時間内に完了しなかったことを示しますが、パスワードの誤りを直接示すものではありません。ドメイン名を解決できない、アドレスに到達できない、ポートに接続できない、TLSハンドシェイクが中断する、サーバーが応答しないなど、さまざまな原因で待機後に失敗します。まず使用中のネットワーク、サーバー項目、エラーの原文を記録し、「アドレスとポート、通信パラメータ、TLS、認証」の順に確認してください。最初からすべての項目を同時に変更するのは避けます。

同じ項目を使ってネットワークを比較する

同じSERVER項目を選んだまま、利用可能なWi-Fiとモバイルデータ通信でそれぞれテストします。片方のネットワークだけで失敗する場合、そのネットワークの接続条件、名前解決、アドレスファミリー、通信制限が関係している可能性があります。それだけで項目を削除しないでください。同じネットワークで、ご自身がすでにお持ちの別の項目が正常なら、問題を現在のサーバー、ポート、プロトコル設定に絞り込みやすくなります。アプリ全体の問題とは限りません。

サーバーアドレスに余分な空白、改行、貼り付け時の不要な文字が含まれていないか確認します。アドレスとポートは、サービス事業者から提供された値をそれぞれの欄に入力してください。Webページ全体のURLをホスト名欄に入力してはいけません。ドメイン名を使う場合は、現在も想定したアドレスを指しているか確認します。接続先の変更が案内されている場合は、ご自身の最新の設定を使ってください。よくある値だからという理由でポートを変更せず、サーバー側の待ち受けポートと一致させます。

Connectivity Testのテスト方法は、実際の通信と完全に同じとは限りません。テスト結果が出なくても、すべてのリクエストが必ず失敗するとは限りません。反対に、結果が表示されても、TLS、認証、すべての通信が正常とは限りません。実際のページへのアクセスも試し、どの段階でエラーになるか確認してください。遅延テストを繰り返すだけでは、診断に必要な情報が十分に増えないことがあります。

一般的な値を流用せず、プロトコルのパラメータを一つずつ確認

Add Serverまたは項目の編集画面で、まずプロトコルの種類を確認します。Shadowsocksの暗号化方式とパスワード、VMessまたはVLESSのUUID、Trojanの認証情報は、いずれもサーバー側の設定と一致している必要があります。異なるプロトコルの項目を流用することはできません。TLSの表示が同じでも、通信経路、ホスト名、ポートまで同じとは限りません。ご自身がすでにお持ちの元の設定と、一項目ずつ照合してください。

項目	確認内容	よくある混同
アドレスとポート	接続先ホスト、待ち受けポート	管理画面のURLをサーバーアドレスとして入力する
認証	UUID、パスワード、鍵	コピー時の空白、古い認証情報
TLS	サーバー名、証明書、端末の日時	接続先アドレスと証明書名を無理に一致させる
通信方式	種類、Host、パスなど	パスの先頭のスラッシュを付け忘れる、または大文字・小文字を変える

TLSのサーバー名は証明書の検証とハンドシェイクに使われ、接続先アドレスと同じとは限りません。Hostやパスは通信層で必要になる場合があり、サーバーのドメイン名で安易に置き換えないでください。証明書エラーが発生した場合は、まずシステムの日付と時刻が正しいか確認し、次に名前と証明書の有効性を照合します。証明書検証の無効化を通常の修正方法にしないでください。名前の不一致や接続先の誤りを隠してしまう可能性があります。

サーバー側への確認が必要なケースを見極める

設定項目がすべて一致し、複数のネットワークで失敗する一方、ローカルネットワークが正常な場合は、ご自身のサービス事業者に接続先が現在も有効か、認証情報が変更されていないか、サーバーが正常に待ち受けているかを確認してください。発生時刻、プロトコル、エラーの種類、実施済みの比較テストは伝えて構いませんが、公開の場に認証情報をそのまま投稿しないでください。応答を停止したリモートサーバーは、クライアント側でDNSを変更しても修復できません。

WireGuardではハンドシェイクの成功と実際の通信は別です。Hysteria2では、現在のネットワークでUDPが利用できるかも確認してください。「すべてに対応する」ためにオプションをすべて有効にする必要はありません。各プロトコルでは、サーバー側で明示的に必要とされているパラメータだけを設定します。必要に応じてVMessとVLESSの項目の違いを確認し、内容を理解してから変更してください。

04　サブスクリプションの更新に失敗する：取得と内容の解析を分けて確認

サブスクリプションの読み込みには、URLから内容を取得する処理と、その内容をサーバー項目として解析する処理の少なくとも2段階があります。URLにアクセスできても、有効なサブスクリプションが返るとは限りません。項目を読み込めても、それらに現在接続できるとは限りません。アドレスの取得、返された内容、項目の解析、サーバーへの接続のどの段階で失敗したかを確認してください。既存のサーバーが使えない場合も、サブスクリプションの更新が原因だと決めつけないでください。

まずURLとアカウントの状態を確認

ご自身のサービス事業者からサブスクリプションURLをコピーし直し、先頭、末尾、クエリパラメータがすべて含まれているか確認します。アカウントを識別する認証情報が含まれるURLでは、1文字欠けるだけでアクセスを拒否されることがあります。説明文、引用符、末尾の句読点をURL欄に一緒に入力しないでください。長いクエリパラメータも、見た目が長いという理由で削除しないでください。長いURLの確認はプライベートな環境で行い、公開の掲示板に貼り付けないようにします。

ページでログインを求められる場合やアカウントに関する案内が返る場合、直接取得できるサブスクリプションとは入口が異なります。管理画面ではなく、サービス事業者がクライアント用として明示しているサブスクリプションURLを使用してください。サブスクリプションの内容にはさまざまなエンコードや形式があります。ブラウザーに文字列が表示されるだけで誤りと判断したり、Webページの本文を保存して設定ファイルとして読み込んだりしないでください。

ご自身が利用するサービスの有効期限や利用条件も確認してください。アプリの買い切り購入とリモートサービスの契約は別です。アプリを一度購入しても、接続サービスが付属するわけではありません。当サイトでは読み込みと確認の方法のみを案内し、サブスクリプションURLは提供していません。アカウントの状態やURLの有効性は、ご自身のサービス事業者に確認してください。

返された結果を見て次の確認項目を決める

更新中にネットワークのタイムアウトが発生する場合は、まず基本のネットワークを確認し、サブスクリプションのドメイン名の解決とアクセス経路を調べます。認証エラーの場合は、URLの期限切れや認証情報のリセットを優先して確認してください。解析エラーの場合は、返された内容がサブスクリプション形式か、ログインページ、案内ページ、空の内容に置き換わっていないかを確認します。すべてのエラーを「ノードの故障」とひとまとめにしないでください。サーバー一覧を取得する前に失敗している場合もあります。

接続が利用できる状態では、現在の接続、ルーティング、名前解決がサブスクリプションの取得に影響することがあります。URLは変えず、接続を切った状態と、現在利用できる接続を使った状態でそれぞれ試し、違いを記録します。確認の目的はURLへのアクセス経路を特定することであり、特定のモードを継続して使うことではありません。どちらでも失敗する場合は、基本ネットワークを変えて再テストします。何度も更新するだけで済ませないでください。

短時間に何度も更新すると、リモート側でリクエストが制限されることがあります。制限の案内が出た場合は、サービス事業者が示す条件に従って待ち、同じURLを何度も削除して追加し直さないでください。再読み込みの前にサブスクリプションの記録を変更する必要がある場合は、元の名前と必要な設定を保存し、古い項目がほかの設定から参照されていないか確認します。安易に消去すると、元々使えていた選択関係まで損なうことがあります。

読み込み後に一覧と選択中の項目を確認

更新後、項目数と名前が想定どおりか確認し、現在選択中のSERVERも確認します。古い項目が削除または改名されると、以前の選択が使いたい接続先を指さなくなることがあります。ご自身がすでにお持ちの項目を1つ選び、Connectivity Testを実行してから実際のページにアクセスしてください。一覧の更新、正しい項目の選択、接続の成功がすべて確認できて初めて、更新の目的を達成したと判断できます。

サブスクリプションから生成された項目を手動で変更すると、次回の更新で変更が上書きされる場合があります。維持したい変更は別途記録し、必要に応じて元のサブスクリプションに影響しない複製で確認してください。サブスクリプションは通常サーバー情報を管理するために使い、Configはルールなどの設定を制御するために使います。両者は自動的に置き換えられるものではありません。サーバーを読み込んだ後も、ConfigとGlobal Routingが元の使い方に合っているか確認してください。

05　速度が遅い：遅延、通信量、サイトの応答を切り分ける

まず「遅い」という症状を具体化します。ページの読み込み開始まで時間がかかる、読み込み開始後のダウンロードが遅い、動画が何度もバッファリングする、特定のサイトだけ応答が遅いなどです。それぞれ関係する段階が異なる場合があります。Connectivity Testの数値は主にテスト経路の応答を比較するためのもので、ダウンロード速度に直接換算できません。テスト値が小さいサーバーでも、現在の時間帯により多くの通信量を確保できるとは限りません。

比較できる条件を整える

同じ端末、同じWi-Fiの場所、同じサーバー、同じテスト用ファイルを使い、端末上の大容量通信を一時停止します。クラウド同期、システムアップデート、動画再生はネットワークを共有するため、条件の異なるテストになりやすくなります。テスト中にサーバーとネットワークを同時に変えると、結果が変化しても原因を特定できません。一度に一つだけ条件を変え、おおよその時刻も記録してください。

接続をオフにした状態で、一般的なページが安定して読み込めるか確認してから、接続をオンにして同じ接続先をテストします。オフの状態ですでに明らかに遅い場合は、Wi-Fiの電波、ルーターの負荷、ネットワークへの接続状態を先に確認してください。モバイルデータ通信では電波状況や混雑も変化します。アンテナの本数だけで通信品質のすべては判断できません。プロトコルをすぐに変更するのではなく、電波が安定した場所に移動して再テストしてください。

短時間に大きなファイルのテストを何度も行わないでください。速度テストはご自身の通信量を消費し、端末の温度上昇につながることもあります。確認すべきなのは安定性、応答開始までの時間、通信の継続性であり、特定の数値を達成することではありません。初回アクセスだけ時間がかかり、その後のリクエストが速くなる場合は、サーバーの帯域不足と決めつけず、DNS、初回ハンドシェイク、キャッシュを確認してください。

影響範囲に応じて確認先を選ぶ

複数の接続先が遅く、ローカルのDirect接続が正常な場合は、現在のサーバー経路、リモート側の負荷、プロトコルの通信方式を確認します。特定のサイトだけ遅い場合は、サイト自体、コンテンツ配信の場所、そのドメインに適用されるルールが原因の可能性があります。まず接続ログで実際にどのポリシーが使われたか確認してから、ルールを変更してください。すべてのドメインをProxyに統一すると問題を見えにくくするだけで、改善につながらない場合があります。

画像は速いのに動画がバッファリングする、またはWebページは正常でもリアルタイム通信が不安定な場合は、通信の種類の違いを考慮してください。機能によってはUDPを使い、別の機能では長時間接続を維持することがあります。TCPのテストに成功しても、すべてのアプリの利用状況を確認できるわけではありません。必要な通信に現在の項目が対応しているか、ご自身のサービス事業者に確認し、ローカルネットワークの状態も確認してください。一度の遅延テストだけでプロトコル全体の機能を判断しないでください。

Wi-Fiとモバイルデータ通信を切り替えても同じサーバーで速度低下が起きる場合は、サーバーまたはリモート経路を優先して確認します。特定のネットワークでだけ発生する場合は、サーバー設定を変えず、ローカルの接続経路、アドレスファミリー、ネットワーク接続条件を調べてください。同じネットワークでご自身がすでにお持ちの別の項目が正常なら、その事実も記録して、関係のない設定変更を減らします。

MTUの変更や再試行は慎重に行う

小さなリクエストは正常でも、大きなリクエストが途中で止まる場合、経路MTUが関係していることがあります。ただし、これは後から確認する項目であり、通常の最初の手順ではありません。まずパケットロス、サーバーの負荷、接続先サイトの問題を除外します。現在のプロトコルと設定に該当項目があり、元の値を保存している場合に限り、既知のネットワーク条件に合わせて一項目ずつ試してください。出所の不明な共通値を使ったり、速度低下をすべてMTUのせいにしたりしないでください。

接続を切って何度も再接続すると、ハンドシェイクや名前解決の負荷が増え、維持できていた長時間接続が切断されることもあります。リクエストを観察する時間を適切に取り、新しい接続の確立が遅いのか、確立後の通信が遅いのかを区別してください。再接続後に一時的に改善し、通信量が増えると再び低下する場合は、その傾向を記録します。再接続を繰り返すことを解決策にしないでください。こうした条件は、リモート側の制限、経路の混雑、端末の温度状態を判断する助けになります。

同じ条件で対象の通信が安定して回復したかどうかが、解決の判断基準です。テストの数値が偶然改善しただけでは十分ではありません。原因を特定したら、元の用途に合ったGlobal Routingに戻し、根拠のないテスト用パラメータを解除してください。例外ルールを残す場合は、対象と理由を記録します。一時設定を忘れると、次の切り分けで原因不明の条件が増えてしまいます。

06　DNSの問題：名前解決と接続を分けて確認

DNSはドメイン名をアドレスに変換します。サーバーの遅延テストが成功しても、Webページでホストが見つからない、長時間待たされる、一部のリソースが表示されない場合は、名前解決を個別に確認してください。ブラウザーに表示される証明書エラーと、ドメイン名の解決失敗は別の問題です。具体的なドメイン名、エラー表示、発生時の接続モードを記録し、リクエストでアドレスが取得できたか、どの種類のアドレスだったかを確認します。

現在の設定とDNSクエリの経路を確認

Configを開いて実際に有効なファイルを確認し、DNSに影響する設定を探します。有効になっていないファイルを変更しても、動作は変わりません。カスタムDNSサービス、Hostのマッピング、その他の名前解決設定がある場合は、元の値を記録し、現在のリクエストをどの層が処理しているか確認します。システム、ルーター、アプリ内の設定が組み合わさる場合もあります。すべてのクエリが同じDNSを直接使うとは限りません。

問題が発生する完全なドメイン名を一つ選び、正常なドメイン名と比較します。アプリで利用できる診断機能と接続ログを使い、名前解決の結果があるか、タイムアウトするか、その後の接続が続くかを確認してください。ドメイン名からアドレスを取得できるのに、その後のTCPやTLSで失敗する場合、問題の中心はネットワークやハンドシェイクに移っています。その段階でDNSを何度も変更しても、接続先のアドレスが変わるだけで根本的な問題は解決しないことがあります。

カスタムDNSサービス自体にもネットワーク経路が必要です。そのアドレスの名前解決に、まだ確立できていない接続が必要な場合、起動時に依存関係の問題が生じることがあります。設定でDNSクエリが実際にどこへ送られるか、接続の確立前後で動作が異なるかを確認してください。DNSサービス、Global Routing、ルールを同時に変更したり消去したりすると、どの操作が名前解決の経路を変えたのか判断できません。

Host、IPv6、ネットワークごとの差を確認

古いHostマッピングがドメインを以前のアドレスに固定し、通常のDNSの変更を妨げている場合があります。まず設定の複製で、問題のドメインに関係するマッピングを無効にし、リクエストを再実行します。コンテンツ配信を利用するサイトでは、アドレスを固定すると現在のネットワークに適した接続先が選ばれなくなることもあります。一度だけ使えたアドレスを長期的に固定したり、アドレスを直接指定した結果で通常のドメインアクセスを代用したりしないでください。

IPv6アドレスを返すネットワークでも、IPv6接続が安定しているとは限りません。特定のネットワークだけで問題が発生する場合は、失敗した接続がIPv4とIPv6のどちらを使用したか確認し、基本ネットワークのテスト結果と照らし合わせます。特定の種類のアドレスが返っただけで、名前解決の誤りと判断しないでください。アドレスファミリーに関連する設定を一時的に変更する場合は、元の値を記録し、ネットワークを切り替えて再確認します。ある環境を直して別の環境を損なわないようにしてください。

ローカルネットワークの端末名、内部ドメイン、パブリックドメインでは、異なる名前解決経路が必要になることがあります。パブリックDNSサービスでは、ローカル端末の名前を解決できない場合があります。会社や家庭内のリソースは、接続中のネットワークが提供するDNS情報を必要とすることがあります。内部リソースだけが失敗する場合は、まずローカルネットワークとアクセス経路を確認し、そのドメインが誤ってリモート側へ送られていないか調べてください。すべてのドメインを同じDNSサービスに送ることを、万能な解決策にしないでください。

ドメインルールとアドレスルールの違いを理解する

DOMAINとDOMAIN-SUFFIXはドメイン名を直接対象とし、IP-CIDRとGEOIPはアドレスを対象とします。アドレスルールの判定で名前解決の結果が関係する場合があるため、ルールの適用とDNSは完全に独立していません。具体的なドメインルールでポリシーを確認してから、アドレスルールが結果を変えていないか調べます。対象のドメインを特定する前に、広範なキーワードルールを次々に追加しないでください。関係のない通信に影響するおそれがあります。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

ここでの例は具体的なルールを広範なルールより先に置く方法を示すもので、実際のネットワーク設定を代替するものではありません。portal.example.comは説明用のドメインであり、実際のサービス接続先ではありません。変更後は新しい接続でリクエストを再実行し、新しい結果が使われるようにします。システムやアプリのキャッシュにより、古い結果がしばらく残ることがあります。保存後すぐに変化がないからといって、設定が反映されていないと判断しないでください。

名前解決が成功したと判断するには、ドメイン名から妥当なアドレスが得られ、リクエストが想定したポリシーを通り、実際のページが読み込まれることを確認します。詳しくはDNS設定と名前解決の失敗を確認する方法をご覧ください。用語がわからない場合は、まず用語集を確認し、問題のドメインに戻って検証します。DNS設定全体を一度に書き換える必要はありません。

07　バッテリー消費と発熱：通信状況を確認してから再接続を調べる

VPNを継続して有効にしている間は、トンネルを通過するデータの処理がシステム上の関連アクティビティに計上されます。ただし、バッテリー画面の割合は独立した電力測定値ではありません。ほかのアプリの使用が減れば、Shadowrocketの割合が上がることもあります。異常かどうかを判断するには、総電池残量の変化、画面の使用状況、通信量、端末温度、再接続の頻度を合わせて確認してください。一つの割合だけでアプリの不具合と決めつけないでください。

同じ条件で観察できる時間帯を設ける

システムのバッテリー画面で対象の期間を選び、画面点灯中と消灯中の消費を区別します。期間中に動画の視聴、ファイル転送、ナビゲーション、クラウド同期を行ったか記録してください。大容量通信がVPNを通ると、関連する処理も増えます。これは待機中に継続して端末が起動する問題とは異なります。使用状況が近い2つの期間を比べ、忙しかった日とほとんど端末を使わなかった日を比較しないでください。

ネットワークの種類と電波状況も同時に記録します。電波の弱いモバイルネットワークでは通信維持の負荷が増え、Wi-Fiの電波が届きにくい場所でも再試行が起きやすくなります。特定の場所でだけ端末が発熱する場合は、まずネットワークが安定した場所に移動して様子を見てください。先にルールを変更する必要はありません。充電しながら大容量通信を行うときだけ発熱する場合は、通信を停止し、端末の温度が正常に戻ってから比較を続けてください。

システムの大規模なアップデート後や、端末にデータを復元した直後は、バックグラウンドでの整理や同期がバッテリーに影響することがあります。関連する処理が落ち着いてから、接続による消費が継続して増えているか判断してください。端末が高温のときに速度テストを繰り返さないでください。負荷を増やしてバッテリー消費を強めるうえ、その後の性能データも比較しにくくなります。システムから温度に関する警告が表示された場合は、まずその案内に従ってください。

On Demandと接続の繰り返しを確認

接続ログを開き、短時間に切断と接続が繰り返されていないか確認します。再接続のたびに名前解決、ハンドシェイク、認証が必要になることがあり、安定して接続を維持する場合より余分な処理が増えます。Wi-Fiとモバイルデータ通信の切り替え時に再接続が起きる場合は、ネットワークの安定性を確認してください。特定の項目だけで起きる場合は、「サーバーのタイムアウト」の章に戻り、設定項目とリモート側の状態を確認します。自動再接続の回数が多いことを、接続の信頼性が高い証拠とみなさないでください。

On Demandの条件が頻繁に変化すると、想定と異なる接続動作につながることがあります。まず条件を記録し、制御できる環境で自動接続を一時的にオフにして、手動接続後も再接続が繰り返されるか確認してください。オフにすると安定する場合は、条件を一つずつ戻して、動作の違いを生む要因を特定します。スイッチを何度も手動でオフにする方法を常用しないでください。オンデマンド接続を使う場合は、理由を説明できる明確な条件を設定します。

プロトコルによっては、ネットワークのマッピングや接続状態を維持するためのKeep Alive設定があります。間隔が短すぎるとネットワーク処理が増える場合がありますが、安易に無効にすると特定のネットワークで接続できなくなることもあります。ご自身の設定にこの項目が明示されており、目的を理解している場合に限って変更してください。別のプロトコルの値を流用したり、待機中の数値を良く見せるために必要な接続機能を損ねたりしないでください。

バックグラウンド処理と診断を必要な範囲に抑える

切り分け中は、Connectivity Testを広範囲にわたって連続実行しないでください。診断ログも、必要以上に詳細な状態で長期間記録しないようにします。テストやログの記録にも処理とストレージが必要です。十分な情報が集まったら、普段使う設定に戻し、通常使用時のバッテリー変化を確認してください。設定に追加の処理が含まれている場合は、複製上で一つずつ停止して検証します。説明できない内容をそのまま削除しないでください。

接続中にアプリが繰り返しリクエストを再試行していないかも確認します。対象がREJECTされた後に、アプリが継続してリクエストを送る場合があります。名前解決の失敗でも同様の動作が起きることがあります。その場合はテストの頻度を下げるだけでなく、ルールや名前解決の経路を修正してください。接続ログで頻繁に現れる接続先と、その時に動作していたアプリを照合すると、バックグラウンド通信とトンネル自体の維持処理を区別しやすくなります。

「同じネットワークで、特定の項目だけ再接続が続くと発熱する」のように、再現可能な結論を記録してください。「接続するとバッテリーを消費する」だけでは不十分です。大容量通信を停止し、ネットワークを安定させ、必要な設定を戻しても明らかな異常が続く場合は、個人情報を伏せた記録とバッテリーの観察条件を保存して、詳しく確認します。検証のために端末を高温のまま使い続けたり、この種の問題で通常の手順として初期化したりしないでください。

08　アップデート後の問題とiPad：端末ごとの差を確認

アップデート後に問題が起きた場合は、変化した層を特定します。アプリのアップデート、システムのアップデート、サブスクリプションの更新、Configの差し替え、ネットワークの切り替えなどが考えられます。同じ日に複数の変化が起きても、時期が近いだけで原因が同じとは限りません。最後に正常に使えたときのサーバー、モード、ネットワークを記録し、現在の状態と比較してください。目的は動作の違いを特定することであり、確認していない古い設定で全体を上書きすることではありません。

データを保存してから最小限の範囲で再テスト

まず現在のConfig、カスタムルール、必要なサーバー情報を保存します。どの情報がサブスクリプション由来で、どれが手入力かを確認し、再設定時に復元できるようにしてください。次に、現在の設定のままアプリを再起動してテストします。必要であれば端末も再起動し、システムのネットワーク状態を再確立します。それでも問題が続く場合は、設定を複製し、必要なルールとご自身がすでにお持ちのサーバー項目を一つだけ残して比較します。正常なデータを先に消去しないでください。

最小構成が正常で元の構成では失敗する場合は、元のルールと設定をグループごとに戻し、違いを特定します。戻すたびに同じ接続先で再テストし、すべてを一度に追加しないでください。どちらも失敗する場合は、システムのVPN許可、基本ネットワーク、サーバー設定を確認します。エラーが設定構文を示している場合は、表示箇所の前後にある区切り文字、ポリシー名、項目を確認してください。直前に変更した行だけに注目しないでください。

アップデート履歴とシステム要件はApp Storeの掲載内容を確認してください。アプリの正規性を確認する場合は、正規版の確認方法を参照し、デベロッパ名がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認します。ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリです。アップデートも再取得もApp Storeから行います。ネットワーク設定の修復を目的にアプリを再購入しないでください。

iPadとiPhoneの違いを一つずつ確認

同じサーバー情報がiPhoneでは使えてiPadでは使えない場合、まず2台が実際に同じネットワークに接続しているか確認します。iPhoneはモバイルデータ通信中でも、iPadはWi-Fiに接続されていることがあります。表示されるネットワーク名が似ているだけでは同じ接続とは判断できません。iPadでWi-Fiしか使えない場合は、別の利用可能なネットワークでも再テストし、その端末では使えないモバイルデータ通信の確認手順を当てはめないでください。

アプリの購入履歴があっても、端末内のすべての設定が一致しているとは限りません。2台で選択中のSERVER、Global Routing、有効なConfig、DNS関連項目、On Demandの条件を確認します。手入力した項目は特に一つずつ照合してください。設定をコピーする場合は、現在使っているファイルをコピーしたか、以前保存した古いファイルではないかも確認します。項目名だけの比較では不十分です。同じ名前でも、アドレスや設定値が異なることがあります。

iPadの画面レイアウトは、縦横の向き、ウインドウサイズ、マルチタスクの状態によって変わります。一部のリストや編集欄が同時に表示される場合は、画面の左右の位置だけで探さず、Home、Config、Settingsなどの画面表示から現在の場所を確認してください。長いURLを入力する際は、キーボードの自動補正で空白や句読点が入っていないか確認し、保存前に内容を見直します。

スリープ復帰、ローカルネットワーク、再インストールの確認

iPadを長時間スリープさせた後だけ接続できなくなる場合は、まず復帰後にネットワークが戻っているか確認し、手動で一度切断してから再接続します。再接続で復旧した場合は、ネットワークの切り替えやOn Demandの条件変更が伴っていたか記録し、再接続と名前解決を確認してください。復帰のたびにすべての設定を作り直す操作を習慣にしないでください。復旧までの時間的な問題を隠し、切り分けに必要な情報を失うことがあります。

ローカルネットワークの端末、家庭内ページ、プリンターだけが使えない場合は、関連するシステム権限と、対象の通信が想定どおりDirectになっているかを確認します。内部アドレス範囲、内部ドメイン、パブリックなインターネット接続先では処理条件が異なります。実際のアドレスと名前解決の結果を踏まえて判断してください。ローカルの接続先を一つ直すために、すべての通信を長期的にDirectへ変更したり、範囲の広すぎるアドレスルールを追加してほかの通信に影響させたりしないでください。

再インストールが必要な場合は、設定のバックアップを読み込めること、手動で追加した項目を復元できること、ご自身のサブスクリプションURLの保存場所を把握していることを先に確認します。購入済みアプリの復元方法と購入対象の条件はApp Storeの掲載内容を確認してください。詳しくはiPadでの入手方法と機種変更時の復元方法をご覧ください。購入済みアプリの復元でアプリを入手できても、元のサーバーやルールが自動的に再作成されるわけではありません。