OFFICIAL MANUAL / DIAGNOSTICS

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

接続、サブスクリプション、設定の問題を症状から切り分けます。一度に変更する項目は一つに絞り、元の設定を残したうえで同じ条件で結果を確認してください。

このページでは、公式マニュアルのトラブルシューティングを解説します。既存のサブスクリプションの読み込みからGlobal Routingの選択、接続までの手順は使い方ガイドをご覧ください。設定後に問題が起きた場合は、下の目次から該当する項目を選んでください。

01 / CONNECTION SWITCH

接続スイッチがオンにならない、またはすぐオフになる

スイッチがオンの状態を保てない問題と、オンにした後にWebページを開けない問題は別です。前者では、VPN構成の追加がシステムで許可されているか、別の接続構成が使用中でないか、現在の設定を読み込めるかを先に確認してください。この段階でDNSやルールを何度も変更しても、有効な手がかりは得にくいでしょう。スイッチが戻るのが認証前、認証後、接続から数秒後のどの時点かを記録し、その状況に応じて対処します。

認証の問題と接続の問題を切り分ける

初めて接続を有効にするとき、VPN構成の追加を許可する確認や、デバイス認証が求められることがあります。これはシステムの認証手順であり、サブスクリプションの認証ではありません。確認画面に表示されたアプリを読み、接続元を確認してから許可してください。以前に確認画面をキャンセルした場合は、Homeに戻って再度有効化してみてください。デバイスに制限のメッセージが表示される場合は、デバイス管理ポリシーを確認してください。制限を回避するためにスイッチを何度もタップしないでください。

Shadowrocketの接続をオフにしてから、システムのSettingsを開き、VPN関連の項目で別の構成が接続中でないか確認します。
自分で有効にした他のVPN接続や自動接続機能を一時停止し、Shadowrocketに戻って一度だけ接続を試します。
それでもすぐオフになる場合は、Homeで実際に存在するサーバーが選択されているか確認し、Configで現在の設定を読み込めるか調べてください。
システムのメッセージとアプリ内のエラーを記録してから、権限の問題、設定の復元、サーバー情報の確認のどれを行うか判断します。

デバイスに複数のVPN構成があっても、すべて削除する必要はありません。切り分けるべきなのは、同時に動作している接続や自動再接続の設定です。会社や学校が管理する構成はポリシーで保護されている場合があり、削除すると通常のアクセスにも影響する可能性があります。まず管理上の要件を確認してください。一方の接続を停止した直後に別の接続が再開する場合は、アプリのスイッチ故障と決めつけず、双方のOn Demandやシステムの自動接続設定を確認します。

変更を最小限にして設定の起動を確認する

設定を読み込んだ後に問題が始まった場合は、元のファイルを残し、以前に起動を確認した設定に戻してください。サーバー、ネットワーク、ルールを同時に変更したり、VPNを作り直したりしないでください。復旧しても、どの変更が効いたのか分からなくなります。設定の読み込みエラーは、セクション見出し、オプションの綴り、ポリシーの参照先、ファイルの欠落などが原因になることがあります。表示されたエラー位置を確認し、起動失敗をすべてサーバーへの接続不可と判断しないでください。

スイッチはオンのまま通信できない場合は次の章へ、オンのままサーバーのテストがタイムアウトする場合は「サーバーのタイムアウト」の章へ進んでください。スイッチの色やシステムの接続表示で分かるのは接続状態の一部であり、実際のリクエスト確認の代わりにはなりません。テストには同じWebページを使い、接続できるか、アプリ内に対応するリクエスト記録が残るかを確認してください。アイコンだけを見て判断しないようにしましょう。

設定を変更しても問題が続く場合は、デバイスを通常の手順で再起動してから、もう一度再現するか確認してください。再起動で一時的な動作状態は解消できますが、パスワードやサーバー情報の誤りは直りません。ローカル情報をバックアップし、アカウント復元の条件を確認したうえで、通常の再起動と設定の切り替えでも解決しない場合に限り、自分のVPN構成の再作成を検討してください。ネットワーク設定のリセットは影響範囲が広いため、最初に行う方法ではありません。

復旧後の確認項目

接続が安定してオンになったら、ネットワークを変えずにWebページを開き、Homeに戻り、画面をロックしてから解除する操作を続けて行い、新たな切断メッセージが出ないことを確認します。その後、必要なOn Demandの条件を戻し、接続が繰り返し発生しないか観察してください。画面ロック後に限って問題が起きる場合は、そのときにWi-Fiからモバイル通信へ切り替わったか記録すると、「バックグラウンドで切断する」という説明だけより原因を特定しやすくなります。

02 / TRAFFIC PATH

接続はオンだがインターネットに接続できない

接続がオンであることは、システムが関連するネットワーク経路を確立したことを示しますが、サーバー、DNS、ルール、接続先のWebサイトがすべて正常とは限りません。まず、すべてのアプリで失敗するのか、ブラウザーだけか、特定のドメインだけかを切り分けます。ページがまったく開かない場合と、本文は表示されるが画像やログインに失敗する場合も区別してください。後者はドメインごとに異なるポリシーが適用されている可能性があり、接続全体の障害とは限りません。

通常のネットワークを確認してからルーティングモードを切り分ける

Shadowrocketの接続をオフにし、同じデバイスで普段開けるWebページにアクセスしてください。通常のネットワークでも失敗する場合は、Wi-Fiのログイン認証、モバイルデータ通信の許可、ルーターとの接続を先に確認します。公衆Wi-Fiの認証ページは、接続をオフにしてから開く必要があることがあります。通常のネットワークが復旧してから接続をオンにし、インターネットに接続できないネットワークを設定の問題と誤認しないようにしてください。

通常のネットワークが使えることを確認したら、現在のGlobal Routingの選択肢を記録します。Configモードでは現在の設定のルールに従って経路が決まります。Proxyモードは選択したサーバーでリクエストを処理できるかの一時的な確認に使えます。Directモードは接続中の直通経路との比較に使えますが、接続をオフにした状態での通常のネットワーク確認の代わりにはなりません。テスト後は元のモードに戻し、特定のWebページを開くためだけにすべての通信の処理方法を変更したままにしないでください。

Global Routing	トラブルシューティングでの用途	この結果だけでは分からないこと
Config（設定）	設定ルールに沿って実際のマッチとポリシーを確認する	一つの接続先が正常でも、すべてのルールが正しいとは限らない
Proxy（プロキシ）	ルールによる振り分けを一時的に切り離し、選択したサーバーを確認する	リクエストが成功しても、Configモードのポリシー参照が正しいとは限らない
Direct（直接接続）	接続中の直接接続経路と比較する	接続をオフにした状態での通常のネットワーク確認の代わりにはならない

失敗したリクエストからルールとポリシーを確認する

ProxyではアクセスできるのにConfigで失敗する場合は、そのドメインに実際にマッチしたルールと、ルールに対応するポリシーが想定したサーバーを指しているかを確認します。ルールは順番に評価されるため、より広い範囲を対象とするルールが先にあると、リクエストが先に処理されることがあります。想定していたルールだけを見るのではなく、そのときのリクエスト記録から実際の判定結果を確認してください。特にDIRECT、REJECT、最後に適用されるFINALに注意します。

以下はルールの順序を説明するための例であり、そのまま置き換えて使える設定ではありません。example.comは説明用のドメインです。PROXYには実際の設定内で有効な対応先が必要です。1行目はこのドメインとサブドメイン、2行目は地理データベースに基づいてアドレスを判定し、最後の行はそれ以前のルールにマッチしなかったリクエストを処理します。実際の設定は自分の利用目的に合わせ、使用するポリシー名も確認してください。

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

Proxyでも失敗する場合は、まず手元にある別の利用可能なサーバー（過去に接続を確認済みのもの）で比較します。すべてのサーバーで失敗する場合は、DNS、現在のネットワーク、共通の設定を確認してください。一つだけ失敗する場合は「サーバーのタイムアウト」の章に進みます。この段階で設定を一括更新しないでください。複数の変更を同時に加えると、以前の正常な状態と比較できなくなり、切り分けの範囲が広がります。

Webサイト側の問題とクライアントの通信経路の問題を切り分ける

一つのWebサイトだけで失敗する場合は、ログイン、動画、添付ファイルのドメインだけに問題がないか確認します。Webページは通常、複数のドメインにリクエストを送るため、メインページが表示されても関連するリソースのドメインすべてが正常とは限りません。システム時刻、証明書の警告、接続先サービスの状態も確認してください。証明書の警告が出た場合、検証をすぐに無効にしないでください。デバイスの時刻の誤り、認証ページによる遮断、サーバー情報で指定された名前の不一致のいずれかを確認します。

設定を調整したら、同じ接続先で再度テストし、ネットワーク、モード、サーバー、マッチしたポリシーを記録してください。さらに別のポリシーが適用される接続先も選び、一部の問題を直したことで別のアクセスが損なわれていないか確認します。ルールのマッチ方法はルールキーワードとマッチ順序、接続に関するよくある質問はよくある質問をご覧ください。

03 / SERVER REACHABILITY

サーバーのタイムアウト、認証失敗、接続の中断

サーバーのテストがタイムアウトしても、制限時間内にテストが完了しなかったことしか分かりません。この結果だけで、サーバーが恒久的に利用できないとは判断できません。テスト方法、ドメインの名前解決、通信のハンドシェイク、接続先へのリクエストなどが結果に影響します。まずテスト名とエラーの原文を記録し、実際のWebアクセスと比較してください。テストは失敗しても実アクセスが正常な場合は、テストの接続先や方法を確認し、すぐに登録済みのサーバーを削除しないでください。

アドレス、ポート、認証、通信方式を順に確認する

既存サーバーの編集画面を開き、自分の元の情報と項目ごとに照合してください。特にコピー時に空白、改行、全角の句読点が混入していないか確認します。アドレス欄にはその項目が求めるサーバーアドレスだけを入力し、共有リンク全体を貼り付けないでください。ポートはサーバー側の設定と一致している必要があります。サーバー名は端末内で識別するためのラベルです。名前を変えてもアドレスや認証情報は修復されず、サーバー側の識別用パラメーターにもなりません。

項目	確認する内容	よくある症状
アドレスとポート	アドレスの綴り、ポート、現在のネットワークから到達できるか	名前解決の失敗、接続タイムアウト、接続拒否
認証情報	パスワード、UUID、暗号化方式、サーバー側の要件	ハンドシェイク後の失敗、認証エラー、接続切断
TLS	サーバー名、証明書、デバイスの時刻	証明書の検証またはハンドシェイクの失敗
通信設定	通信方式、Host、Pathなどの関連パラメーター	基本ポートには到達できるが、アプリのリクエストを確立できない

プロトコルごとに使用する項目は異なります。Shadowsocksではパスワードと暗号化方式の組み合わせを確認してください。VMess、VLESSでは対応する認証情報と通信設定、TrojanではパスワードとTLS関連のパラメーター、Hysteria2ではUDPを使った通信条件も確認が必要です。サーバーアドレスが同じだからといって、あるプロトコルの設定を別のプロトコルへ丸ごとコピーしないでください。自分のサーバー情報を基準にし、エラーメッセージからパスワードを推測しないようにしてください。

条件を一つずつ変えてネットワークとサーバーの境界を確認する

まず現在のネットワークで、手元にある別の利用可能なサーバーをテストします。次に、問題のサーバーを別の利用可能なネットワークで試します。前者ではネットワークを固定してサーバーを変更し、後者ではサーバーを固定してネットワークを変更します。同じサーバーが一つのネットワークでのみ失敗する場合は、そのネットワークのアクセス制限、認証状態、UDPの条件を確認してください。異なるネットワークでも失敗し、他のサーバーは正常な場合は、サーバーまたはアカウントの状態が原因である可能性が高まります。

テスト中に複数の速度測定を同時に実行しないでください。短時間に接続を何度も確立すると、サーバー側の同時接続制限に触れることがあり、デバイスの負荷やネットワークの混雑によってテスト条件も変わります。一つのテストが終わってから次へ進み、少なくとも一つの完全なエラー記録を残してください。ネットワークを切り替えた後は接続を再確立し、以前の接続が復旧していない状態を新しいネットワークの結果と誤認しないようにします。

認証に失敗した場合は、通常、元の認証情報、アカウントの有効状態、サーバー側の変更を確認する必要があります。DNSを変更してもパスワードの誤りは直りません。接続拒否と接続タイムアウトも異なります。前者は接続先のポートで想定したサービスが提供されていない場合があり、後者はより手前の経路やハンドシェイクの段階で発生することがあります。ログのエラーは手がかりとして扱い、再現可能な条件での比較と合わせて判断してください。一つのエラーフレーズだけで結論を出さないでください。

検証を緩めて根本原因を隠さない

証明書の問題では、まずデバイスの日付、サーバー名、元の設定を確認します。証明書検証を安易にスキップすると、身元を確認する仕組みが失われ、本当の名前設定の誤りも残る可能性があります。サーバー側で特殊な証明書設定を使っている場合は、把握している構成情報に従ってください。確かな情報がない場合は元の状態を保ち、既存サービスの管理者にエラーを伝えます。セキュリティ設定を一般的な速度向上のスイッチとして扱わないでください。

04 / SUBSCRIPTION UPDATE

サブスクリプションの読み込み・更新失敗やリストの異常

サブスクリプションの更新には、URLの内容を取得する、形式を認識する、サーバーリストに保存する、という少なくとも3つの段階があります。読み込みエラーが起きても、サーバー自体に接続できないとは限りません。同様に、更新に成功してもリスト内のすべてのサーバーが使えるとは限りません。まず失敗した段階を特定します。リクエストに応答がないのか、エラーページが返ったのか、内容は取得できたが認識できないのかによって、必要な対処は異なります。

リンクの内容と種類を確認する

単一の共有リンク、サーバーリストのサブスクリプション、完全な設定ファイルは用途が異なります。単一の共有リンクは一つのサーバーを示し、サブスクリプションURLは更新可能なリストを取得するために使います。設定ファイルにはルール、DNS、ポリシーが含まれる場合もあります。リンクの見た目だけで用途を判断せず、手元にある説明と照合してください。内容に合わない読み込み画面を使っても、貼り付けを繰り返すだけでは種類は変わりません。リスト内に重複項目が増えて見分けにくくなる場合もあります。

URLをコピーするとき、チャットアプリが付けた末尾の句読点、改行、省略記号が混入していないか確認してください。URLにクエリパラメーターが含まれる場合、1文字欠けただけで認証に失敗することがあります。見慣れた形式に見せるために、URLのプロトコル、パス、パラメーターを勝手に変更しないでください。サブスクリプションURLはアクセス権限を持つ場合があるため、認証情報として保管し、相談のために内容全体を公開しないでください。

現在のサーバーグループ名と項目数のおおよその変化を記録し、更新前に利用できていた内容を残します。
元のサブスクリプションURLが完全であり、その内容に適した読み込み画面を使っているか確認します。
手動で一度更新し、エラーメッセージを確認して、ネットワーク、認証、形式認識のどの段階で失敗したかを切り分けます。
更新後、選択中のサーバーとポリシーの参照先を確認してから、実際に接続をテストします。

サブスクリプションのリクエストに使われるネットワーク経路を確認する

更新時に名前解決エラーや接続タイムアウトが起きる場合は、通常のネットワークが使えるかを確認してから、現在の接続がすでに使えなくなっているために更新リクエストも失敗しているのか判断してください。URLによっては、直接接続と既存の接続経路で結果が異なります。更新ボタンを何度も押さず、一度に一つの条件だけを変えて確認します。利用可能な接続を通さないとサブスクリプションを取得できない場合は、すでに利用できることを確認した自分のサーバーを使って更新し、依存関係が循環しないようにします。

ログインページ、認証ページ、アクセスエラーの説明が返された場合、クライアントはそれをサーバーリストとして正常に解析できません。ブラウザーにページが表示されても、内容を受信したことしか分からず、有効なサブスクリプションだとは限りません。ページを保存したテキストを設定として無理に読み込まないでください。アカウントの状態、URLの有効性、元の情報を確認し、必要に応じて既存サービスの管理者にURLが実際にどの種類の内容を返すのか尋ねてください。

更新後にリストが空になったり項目が大きく変わったりした場合は、連続して更新せず、別のURLを読み込んでいないか、元のサブスクリプションが無効になっていないか、サーバー側で返されるリストが変更されていないか確認します。更新前の記録があればグループ名やサーバー名を比較できますが、名前だけで接続情報が完全に一致すると判断しないでください。同じ名前の項目でもアドレスや認証情報が変わっている可能性があるため、実際の接続を確認します。

重複項目と無効な参照を整理する

手動で追加したサーバーとサブスクリプションから作成されたサーバーが、同時に存在することがあります。削除する前に各項目の出所を確認し、残す必要がある手動追加の項目まで消さないようにしてください。ルールのポリシーが特定のサーバー名を直接参照している場合、サブスクリプション更新後に名前が変わると参照が無効になることがあります。リストに多くのサーバーが残っているかだけで判断せず、ポリシーの参照先を確認してください。重複項目を整理するのは、参照を修正してからです。

クライアントのリスト、サブスクリプションサービスのアカウント状態、設定内のルールはそれぞれ別の要素です。サーバーリストを更新しても、すべてのルールが更新されるとは限らず、手動で変更したDNSが自動修復されるわけでもありません。復旧後は、更新時刻や結果のメッセージ、リストの内容、選択中のサーバー、実際のアクセスを確認してください。内容の種類が分からない場合は、共有リンクとサブスクリプションの違いをご覧ください。

05 / PERFORMANCE

レイテンシは正常なのに速度が遅い、動画が止まる

レイテンシ、スループット、Webページの読み込み時間は、それぞれ異なる指標です。レイテンシのテストは特定のやり取りにかかる時間を示すもので、継続的なダウンロード速度にそのまま換算できません。動画再生は接続先のサービス、キャッシュ、ビットレート、分割リクエストにも左右されます。まず「遅い」という状態を観察できる症状に置き換えてください。初回表示に時間がかかる、最初は速いがすぐ止まる、大きなファイルだけ遅い、など症状に応じてテストを選びます。

繰り返し比較できる条件を整える

同じネットワーク、同じデバイス、同じ接続先、同じサーバーを使い、他の大容量通信を終えてからもう一度テストしてください。テストサイトとサーバーを同時に変えると、結果を比較しにくくなります。Webページのキャッシュは2回目の表示速度にも影響するため、初回か再読み込みかを記録してください。動画の場合は、シーク後に限って止まるかも記録します。テスト先自体の負荷も結果を左右するため、一度の結果だけで経路全体を判断しないでください。

接続をオフにして通常のネットワーク速度を確認し、その後接続をオンにして、接続先に想定したポリシーが適用されているか確認します。通常のネットワーク自体が遅い場合は、Wi-Fiの電波、ルーターの負荷、モバイル通信の電波状況を先に確認してください。Wi-Fiに接続済みと表示されても、電波の品質や外部への通信速度が良好とは限りません。ルーターから離れている、アクセスポイント間を頻繁に切り替える、他のデバイスが回線を使っているなどの条件では、接続テストが一時的に成功しても継続的な通信が不安定になることがあります。

バックグラウンドのバックアップ、アプリのアップデート、他の通信を一時停止し、デバイスが発熱していないか記録します。
同じ接続先を使い、通常のネットワークと接続オンの状態を比較して、Global Routingとマッチしたポリシーを確認します。
他の条件を変えず、手元にある別の利用可能なサーバーに切り替えて、同じリクエストを再度実行します。
最後にネットワークを切り替え、問題がサーバー、接続先、ネットワークのどれと連動するか比較します。

名前解決、ハンドシェイク、継続的な通信を切り分ける

最初の表示まで長く白い画面が続き、その後すぐ内容が表示される場合は、DNSや接続時のハンドシェイクが関係している可能性があります。少しずつ読み込みが進む場合は、スループット、再送、リソースのリクエストに問題が近いかもしれません。体感だけで設定をすべて変更せず、リクエスト記録から失敗したドメイン、接続の確立状況、エラーを確認します。メインページは正常で画像だけ遅い場合は、画像のドメインに別のポリシーが適用されていないか調べ、全体の速度測定ではなくルールを確認してください。

サーバーの所在地、テスト時の負荷、接続先Webサイトとの接続品質、経路の混雑は、いずれも通信性能に影響します。レイテンシが低いサーバーでも、現在の接続先でスループットが高いとは限りません。同じサーバーでも、アクセスするWebサイトによって結果が変わる場合があります。手元にあるサーバーで比較すればよく、トラブルシューティングのために新たなサービスを追加する必要はありません。同じ条件で複数回、同じ結果が得られた場合に限り、その経路が現在の用途に合わないと判断しやすくなります。

UDPを使うアプリやプロトコルは、個別に確認してください。ネットワークによってはUDPの扱いが通常のWeb接続と異なります。Webページが開けても、リアルタイムの音声・映像やUDPを使う通信が正常とは限りません。通信方式、ポート、高度な設定を一度に変更しないでください。まずサーバー側の対応条件を確認し、変更内容を記録したうえで一項目ずつテストします。帯域幅の値をむやみに大きくしても、実際の外部回線の性能は上がらず、混雑が目立つ可能性があります。

高度な設定の変更は必要な範囲に絞る

MTUなどのネットワークパラメーターは、汎用的な速度向上設定ではありません。大きなリクエストだけが止まり、小さなリクエストは繰り返し成功する場合は、具体的な再現手順とネットワークの比較結果を集めてから、確認済みの環境要件に合わせて調整してください。変更前に元の値を記録し、変更後は同じリクエストを再度試します。改善しなければ元に戻してください。明確な症状がない場合は、未検証の設定を重ねるより既定値を維持するほうが管理しやすくなります。

テスト中のデバイスの過熱、バッテリー残量の低下、継続的な画面収録も、実際の使用感を変える可能性があります。デバイスが通常の温度に戻ってから、短時間の比較を行ってください。日常のWeb閲覧の問題を確認するために、ネットワークを長時間使い切るテストは避けましょう。復旧の基準は、以前失敗した操作が安定して完了することです。一度の測定値が良くなっただけでは十分ではありません。初回の名前解決に時間がかかる場合はDNSの章へ、発熱が続く場合はバッテリー消費の章をご覧ください。

06 / NAME RESOLUTION

DNSの名前解決に失敗する、特定のドメインだけ開けない

DNSは、ドメイン名を後続の接続に必要なアドレスへ変換します。サーバーのレイテンシテストが正常なのにWebページを開けない場合は、テストとWebページで異なるドメイン、名前解決経路、ルールが使われている可能性があります。まず名前解決の段階で失敗したのか、アドレス取得後の接続に失敗したのかを確認してください。どちらもブラウザーの待ち時間として現れることがありますが、対処方法は異なります。アプリ内で確認できるエラーやリクエスト記録は、白紙のページだけより有用な手がかりになります。

具体的なドメインを一つ選んで確認する

繰り返し失敗するドメインを一つ選び、失敗した時刻と現在のネットワークを記録します。普段正常に開けるドメインも一つ選び、名前解決がすべて失敗しているか比較してください。すべてのドメインで失敗する場合は、設定内のDNSアドレスに誤りがないか、その名前解決サービスへ想定した経路で到達できるかを確認します。特定のドメインだけで失敗する場合は、そのドメインのレコード、キャッシュ、ルールによる振り分け、アドレスファミリーの違いを確認してください。DNS設定全体をすぐに置き換えないでください。

設定には、システムの名前解決、指定したDNSサービス、リクエストごとに異なる経路の設定が含まれる場合があります。まず実際に有効なConfigを確認し、使われていないファイルを編集していないか確かめてください。サーバーアドレス自体がドメイン名の場合も、先に名前解決が必要です。名前解決の経路がまだ確立していないサーバー接続に依存すると、依存関係の問題が起きることがあります。トラブルシューティングでは「サーバードメインの名前解決」と「接続先Webサイトの名前解決」を分けて記録してください。

ルールを踏まえて名前解決と接続の関係を確認する

ドメインルールとアドレスルールは、それぞれ異なる対象にマッチします。DOMAINは特定のドメインに、DOMAIN-SUFFIXはドメインの末尾と対応するサブドメインにマッチします。IP-CIDRはアドレス範囲、GEOIPはアドレスとデータベース情報に基づいて判定します。リクエストに最終的にどのポリシーが適用されるかは、実際のマッチ結果を確認してください。設定内に特定のドメインが記述されているからといって、それより前のルールより優先されるとは限りません。

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

この例は、ルールがどの対象にマッチするかを示すものです。例示するネットワーク範囲は文書用のアドレスであり、利用可能なサービスを示すものではありません。no-resolveは、そのアドレスルールの判定時に名前解決を積極的に実行しないことを示し、すべてのDNSを無効にする意味ではありません。この違いを理解せずにアドレスルールへ一律にこのパラメーターを追加すると、名前解決の結果に基づく判定が想定どおりに行われなくなる可能性があります。完全なルールは、既存のポリシーと実際の接続先に合わせて設計してください。

名前解決の設定を変更する前に元の設定を保存し、名前解決元または関連オプションを一つだけ変更してから、接続を再確立して同じリクエストを再現してください。ブラウザー、アプリ、システム、接続内にはそれぞれキャッシュがある場合があります。変更後しばらく古い結果が出ても、新しい設定が無効とは限りません。一方で、環境全体を何度も消去する必要もありません。まず対象のアプリを終了して開き直し、必要であればデバイスを通常の手順で再起動してから、記録された名前解決と接続の結果を比較します。

アドレスファミリー、暗号化DNS、接続先の問題を切り分ける

IPv4とIPv6の両方のレコードがある場合、ネットワークによって到達性が異なることがあります。特定のネットワークだけで待ち時間が発生する場合は、ドメインが存在しないとすぐに判断せず、最終的に使用されたアドレスと接続エラーを確認してください。WebサイトのIPアドレスを直接入力してアクセスしても、ホスト名、証明書名、仮想ホストが必要な場合があるため、信頼できる代替テストにはなりません。IPアドレスでアクセスできなくても、元のドメインの名前解決が間違っているとは限りません。

暗号化DNSを使う場合、そのサービスへ到達できる接続経路が必要であり、証明書やシステム時刻も関係します。暗号化を有効にしても、すべてのネットワークで名前解決できるとは限りません。変更後にすべてのドメインで失敗する場合は、以前使えていた設定に戻し、名前解決サービスに到達できるか、経路に依存関係がないか確認してから、一項目ずつ調整してください。名前解決の接続における本人確認の問題を隠すため、証明書検証を無効にしないでください。

同じドメインが他の正常なネットワークでも名前解決できない場合は、ドメイン自体に問題がある可能性があります。名前解決は成功するのに接続できない場合は、サーバーとルールの章に戻って確認してください。修復後は、以前失敗したドメイン、正常な比較用ドメイン、現在のサーバードメインを少なくとも一つずつ確認し、一部だけ直っている状態でないことを確かめます。症状ごとの詳しい確認方法はDNS名前解決エラーのチェックリストをご覧ください。

07 / BATTERY AND ACTIVITY

バッテリー消費の異常、発熱、バックグラウンドでの再接続

システムのバッテリー統計に表示される割合は、集計時間とデバイス全体の使用状況と合わせて判断してください。あるアプリの割合が上昇していても、他のアプリの使用が減ったためかもしれません。接続経由の通信、継続的な再試行、画面を開いた状態での診断が関係している場合もあります。一つの割合だけを見て消費電力の異常と決めつけないでください。まず充電状態、画面の使用時間、ネットワークの種類、実際の発熱を記録し、近い条件で比較します。

アイドル時と通信中のバッテリー消費を分ける

ファイルのダウンロード、高画質動画の再生、クラウド同期、インターネット共有はいずれも継続的な通信を発生させます。接続がこれらの通信を処理することでデバイスの負荷が増える場合がありますが、リクエストを発生させているアプリがShadowrocketとは限りません。自分で把握している大容量通信を一時停止し、他の使い方を変えずに、アイドル状態でも発熱が続くか確認してください。テストを何度も実行しながら、日常の待機時のバッテリー消費を評価しないでください。

システムのSettingsにあるバッテリー記録で、問題が起きた時間帯を選び、バックグラウンドとフォアグラウンドの動作や、他のアプリが同時に動作していたかを確認してください。充電中、システムアップデート直後、写真の処理中であれば、その条件も別に記録します。これらは温度やバッテリー消費に影響するため、まとめて比較しても原因を切り分けられません。「同じネットワークで画面をオフにし、同期を止めても再接続が繰り返される」のように記録し、「電池の減りが早い気がする」だけで済ませないようにしましょう。

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

On Demandは条件に応じて接続を確立する機能であり、トラブルシューティングで常に有効にする必要はありません。接続をオフにしても自動的にオンになる場合は、自分のOn Demand条件とシステム内の他の自動接続設定を確認してください。関連する自動動作を一時的に停止し、手動接続と比較します。安定したことを確認してから一つずつ元に戻し、複数の条件が同時に影響して接続の開始と停止を繰り返さないようにします。

Wi-Fiの電波が弱い、Wi-Fiの圏内への出入りが頻繁に起きる、モバイル通信の電波が変化するといった状況では、接続の再確立が発生することがあります。再試行が続くとリソースを消費し、Webページへのアクセスが一時中断する場合もあります。電波が安定した場所でテストしてから、移動中の状態と比較してください。ネットワークの切り替え時だけ問題が起きる場合は、切り替え前後のネットワークを記録します。バックグラウンドの動作をすべてクライアントの問題と決めつけないでください。

システムのバッテリー統計の時間帯、現在のネットワーク、デバイスの温度を記録し、速度テストを停止します。
把握している大容量通信を一時停止し、アイドル状態でもリクエストが続くか確認します。
On Demandを一時停止し、手動接続でも再接続が繰り返されるか比較します。
手元にある安定した別のサーバーだけに切り替え、再試行と発熱が同時に減るか確認します。
必要な機能を戻した後に再度確認し、問題を再現できる最小限の条件を残します。

不要な診断負荷を減らす

詳細な診断記録を長時間残す、Connectivity Testを継続して実行する、すべてのサブスクリプションを何度も更新するといった操作は、ネットワークと処理の負荷を増やします。トラブルシューティング中は必要な記録を短時間だけ有効にし、有効なエラー記録を一度取得したら停止してください。診断処理をバックグラウンドに長時間残し、接続状態の表示代わりにしないでください。通常の設定に戻した後も、他の自動処理がテストやリクエストを繰り返していないか確認します。

特定のサーバーでハンドシェイクの失敗が続く場合、接続の再試行は安定した接続よりも多くのリソースを消費することがあります。この場合はログを減らすだけでなく、「サーバーのタイムアウト」の章に従ってアドレス、認証、ネットワーク条件を確認してください。特定の接続先アプリだけがリクエストを繰り返し失敗する場合は、対応するルールとDNSも確認します。ポリシーの誤りによるリクエストの繰り返しでバッテリー消費が増えても、根本原因は特定の接続先への経路にある可能性があります。

デバイスが明らかに発熱している場合は、高負荷の作業を止め、通常の換気がある場所に置いて、温度が戻ってから短時間のテストを行います。異常な温度のまま何度も長時間測定しないでください。デバイスの性能やネットワークの動作がすでに変化している可能性があります。短時間のバッテリー変化をそのまま一日の消費量に当てはめないでください。判断には、同程度の時間、ネットワーク、使用量で記録した結果を比較する必要があります。

08 / RECOVERY AND IPAD

アップデート後の問題とiPadでの復旧

アップデート後に問題が起きた場合は、実際に何が変わったかを確認してください。アプリ、システム、サブスクリプションの更新、設定の切り替えが近い時期に行われている可能性があり、すべてをアプリの問題と決めつけられません。最後に正常に使えた環境と現在の違いを記録し、前の章に沿って症状を切り分けてください。価格、システム要件、対応デバイスはApp Storeの記載をご確認ください。アプリの入手とアップデートはApp Storeから行います。正規の購入確認はダウンロード案内をご覧ください。

先にバックアップを取り、影響範囲に応じて復旧する

現在の設定、自分で追加したサーバー情報、必要なサブスクリプションURLを保存し、バックアップが自分で管理できる場所にあることを確認してください。パスワードやサブスクリプション情報を含むファイルを公開しないでください。その後、デバイスを通常の手順で再起動し、元のネットワークと接続先で再現するか確認します。復旧した場合は、一時的な動作状態が原因だったか観察してください。まだ失敗する場合は、通常のネットワーク、接続スイッチ、サーバー、ルール、DNSを個別に確認します。すべてのデータをすぐに消去しないでください。

設定の編集直後に問題が起きた場合は、以前使えていた設定のコピーに戻してください。サブスクリプションの更新直後であれば、サーバーの変更とポリシーの参照先を確認します。システムのアップグレード後にVPNの認証状態だけが異常になった場合は、システムのSettingsで自分のVPN構成を確認してください。再インストール、設定の削除、ネットワークのリセットをまとめて続けて行うのではなく、分かっている変更に沿って一つずつ復旧します。

アプリを再取得する前に、購入時に使用したAppleアカウントと購入済み記録を確認してください。アプリの購入記録はサーバー情報のバックアップではなく、再ダウンロードしても無効なサブスクリプションは修復されません。購入済みアイテムの復元方法と注意点は機種変更・再インストール後の復元をご覧ください。元のアカウントで購入を復元する方法も確認できます。接続の問題を調べるために、先にアカウントからサインアウトして変数を増やさないでください。

iPadで購入、設定、実際の接続を切り分ける

iPadでは、アプリを入手できるか、自分の設定を読み込み済みか、接続が実際にオンになっているかをそれぞれ確認してください。この3つは互いに代わりになりません。同じ購入アカウントでの購入済みアイテムの入手や、共通の購入範囲はApp Storeの記載をご確認ください。アプリを入手できても、自分のサブスクリプション、サーバー、ルールの確認は必要です。別のデバイスで正常に使えても、このデバイスに同じ設定があるとは限りません。

横向き、縦向き、画面分割によって画面内の操作項目の位置は変わりますが、確認の順序は変わりません。編集前に選択中のサーバーグループとConfigを確認し、分割表示で別の項目を変更していないか確かめてください。ウインドウを切り替えた後に選択肢が想定と異なる場合は、Homeに戻って現在の選択を確認してから実際のリクエストをテストします。画面上の位置や直前に開いていたページだけで、現在の有効状態を判断しないでください。

Wi-Fiのみで接続するiPadと、モバイル通信も利用できるデバイスでは、実行できるネットワーク比較が異なります。モバイル通信に切り替えられない場合は、自分が利用できる別の正常なWi-Fiでテストしてください。同じ設定でも2台のデバイスで結果が異なる場合は、ネットワーク、システムの認証、Global Routing、選択中のサーバー、実際の設定内容を比較します。サーバー名だけを比較すると、パラメーターの違いを見落としやすくなります。

画面ロック、ネットワーク切り替え、特定アプリの問題を確認する

iPadで画面ロック後にアクセスの復旧が遅い場合は、まずWi-Fiが再接続されたか、その後VPNが再確立されたかを確認します。ステータスバーの表示だけを判断材料にしないでください。画面の表示環境によって確認できる情報は異なります。ロック解除後に同じWebページを開いて再現し、最初のリクエストが失敗したか、その後自動的に復旧したか記録します。特定のネットワークだけで起きる場合は、そのネットワークの接続安定性と自動認証の条件を先に確認してください。

外付けキーボード、ブラウザーの複数ウインドウ、別のアプリで開いたWebページでは、キャッシュやセッションが異なる場合があります。一つのウインドウだけで問題が起きる場合は、そのウインドウを閉じて対象を開き直し、ログインやキャッシュの問題か確認してください。他のアプリが正常なら、デバイス全体のネットワーク設定をすぐに作り直す必要はありません。すべてのアプリで失敗する場合は、通常のネットワークとGlobal Routingの確認に戻り、局所的な問題から全体へと対象範囲を広げます。