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

オンにできない場合と、オンになった後に戻る場合を切り分ける

スイッチがオンの状態を維持できない場合は、サーバーのパスワードをすぐに変更するのではなく、まずVPN構成の作成がシステムで許可されているか確認します。Homeで既存のサーバーを選択し、編集画面のままになっていないことを確認してから接続を試してください。初回接続時には、VPN構成を追加するためのシステム確認が表示されることがあります。使用中のShadowrocketからの要求であることを確認したうえで、システムの案内に従って許可します。以前に確認画面をキャンセルした場合は、アプリに戻って接続を再試行し、確認画面が再度表示されるか確かめてください。

現象を次の3つに分けて記録します。タップしても何も起きない、システム確認が表示されたが完了していない、スイッチが一時的にオンになった後に自動でオフになる、の3種類です。1つ目ではアプリがほかの操作に応答するか、2つ目ではデバイスの許可状態、3つ目では接続失敗時のアプリ内メッセージを確認します。「オンにできない」とだけ記録すると、画面の応答、システム権限、接続確立のどこに問題があるのか区別できません。現象ごとに確認と対処の順序が異なります。

画面が一時的に応答しない場合は、インポートやテストが終わるまで待ってからHomeに戻り、再試行してください。アプリを通常の手順で終了して開き直すと、一時的な画面の停止を切り分けられますが、サーバーの問題が解決するわけではありません。スイッチを何度もタップすると複数の接続処理が混在し、エラーメッセージと操作の対応がわかりにくくなります。連続して切り替えるより、一度の試行結果を最後まで記録するほうが原因究明に役立ちます。

システム構成とOn Demandを確認する

デバイスのSettingsを開き、VPN構成の管理画面でShadowrocketの構成が存在するか確認します。また、ほかのネットワークトンネルが接続中でないかも確認してください。管理画面の場所はシステムのバージョンによって異なる場合があります。Settingsの検索機能で探すこともできます。ほかのトンネルを切断してからアプリに戻り、手動接続を一度試してください。内容がわからない構成をすぐに削除しないでください。特に学校、勤務先、デバイス管理ポリシーによって追加された項目には注意が必要です。

スイッチをオフにしても自動でオンに戻る場合や、ネットワークを切り替えるたびに状態が変わる場合は、On Demandを確認します。設定された条件に応じて接続が再試行されることがあり、通常の手動接続の不具合とは原因が異なります。まず現在の条件を記録し、On Demandを一時的にオフにして、手動接続が安定するか確認してください。手動接続に問題がなければ、条件を一つずつ戻し、どのネットワーク条件が接続または切断を引き起こすか確認します。

管理対象のデバイスでは、システムポリシーによりVPN構成の追加や変更が制限される場合があります。許可の項目を操作できない場合や、構成が制限されていると明示される場合は、アプリを何度も再インストールするのではなく、デバイス管理者に許可されている設定範囲を確認してください。アプリ内の設定でデバイス管理ポリシーを変更することはできません。サーバーアドレス、プロトコル、ルールを調べる前に、システムが接続の作成を許可していることを確認してください。

必要な情報を保存してから復旧操作を行う

スイッチが一時的にオンになった後に戻る場合は、まず現在のサーバー情報が揃っているか確認します。アドレスやポートが空欄でないか、プロトコルの種類が正しいか、インポート後にすでに無効な項目を参照していないかを確認してください。サービス提供元の情報と項目ごとに照合し、名前だけで設定内容を判断しないでください。エラーが名前解決、認証、証明書を示している場合は、該当する章を確認します。この段階ではシステムの許可が済んでいる可能性があるため、VPN構成の処理を繰り返す必要はありません。

システムのVPN構成を作り直す前に、必要な構成ファイルとサーバー情報を保存し、購読情報をサービス提供元から再取得できることを確認してください。システムのVPN構成を削除する操作とアプリを削除する操作では、影響範囲が異なります。バックアップを取らずに両方を同時に実行しないでください。再作成後は、確認済みのサーバーを一つ使って手動接続を試します。原因を切り分けるため、最初は複雑なルールやOn Demandを戻さないでください。

最後に、「システムの確認は完了、ほかのトンネルは切断、手動接続しても元に戻る」のように、具体的な結果を記録します。デバイスを再起動しても再現する場合は、アプリに表示されるエラー情報と合わせて原因を調べてください。購入や入手元についてはApp Storeで正規版を確認する方法を参照し、入手に関する問題と接続設定の問題を混同しないでください。システム要件はApp Storeの掲載情報をご確認ください。

まず基本ネットワークを確認し、モードを比較する

接続済みなのにアクセスできない場合は、まずShadowrocketを一時的に切断し、同じデバイスとネットワークで、普段正常に開けるページにアクセスできるか確認します。切断しても失敗する場合は、Wi-Fi、モバイルデータ、ルーター、ネットワークのログイン認証を優先して確認してください。公衆ネットワークではログイン画面での認証が必要なことがあります。基本的なネットワークアクセスが可能になる前に、プロキシルールを変更しても解決しない場合があります。認証を済ませてから接続を再試行してください。

基本ネットワークに問題がなければ、同じページと同じサーバーを使い、Global RoutingのConfig、Proxy、Directを順に比較します。これらはそれぞれ設定、プロキシ、直接接続にあたる画面上の英語表記です。切り替えるたびに新しいリクエストを実行し、すでに表示されているページだけで判断しないでください。アプリによっては以前の接続を再利用するため、ルーティングの変更がすぐに反映されないことがあります。

比較結果から原因を読み取り、特定のモードをそのまま恒久的な解決策にしないでください。Directでは正常でProxyでは失敗する場合、直接接続は可能ですが、サーバー経由の経路を確認する必要があります。Proxyでは正常でConfigでは失敗する場合は、ルールのマッチ、ポリシーの指定、DNSを優先して確認します。すべてのモードで失敗する場合は、宛先そのもの、デバイスのネットワーク権限、名前解決を確認し、異なる層の問題を一つの原因にまとめないようにします。

影響範囲からルールを確認する

一部のページやアプリだけが失敗する場合は、まず成功する宛先と失敗する宛先を一つずつ記録します。失敗したリクエストで実際に使われたドメインと、想定したポリシーが適用されたかを確認してください。一つのページから複数のドメインにリクエストが送られることがあります。本文は開いても、画像やログインに失敗する場合は、関連するリソースのリクエストも確認します。一つのページを直すために、設定全体を広範囲なプロキシまたは直接接続のルールに置き換えないでください。

Configでは通常、ルールの順序に従ってマッチングが行われます。広い範囲を対象にするルールが前にあると、後ろの詳細なルールに到達しない場合があります。カスタムルールの位置、ポリシー名、最後のFINALを確認してください。また、リクエストを拒否するREJECTと、ルールの決定後にアクセス経路で失敗する現象を区別します。アプリ内の記録に拒否ポリシーへのマッチが明記されている場合は、そのルールが意図どおりか確認してください。

以下の例はマッチングの順序を示すもので、既存設定と置き換えられる完全なファイルではありません。ドメインのサフィックス、指定地域のアドレスの順に処理し、最後にマッチしなかったリクエストのポリシーを指定しています。例のドメインは構文説明用です。実際のトラブルシューティングでは、確認済みの宛先を使ってください。FINALを変更すると、多数の未マッチリクエストに影響するため、変更前の値を記録せずに書き換えないでください。

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

新しいリクエストで復旧範囲を確認する

モードを切り替えた後は、失敗したページの古いリクエストを終了し、宛先を開き直してください。ブラウザでは新しいタブを使い、ほかのアプリでは該当ページを閉じてから再度開きます。キャッシュされた内容だけが表示され、更新すると失敗する場合は、ネットワークが復旧したとはいえません。ページの本文、画像、ネットワークを使う操作をそれぞれ確認し、ローカルキャッシュや既存のセッションを完全なアクセス成功と誤認しないでください。

ブラウザでは正常でも特定のアプリだけが失敗する場合は、そのアプリのモバイルデータ通信の許可、特定の地域からのアクセス要件、独自の接続やアカウント状態への依存も確認します。アプリ側が返すアクセス制限は、トンネルの不具合とは限りません。ログイン確認を繰り返し発生させるためにサーバーを次々と切り替えないでください。エラーメッセージを記録し、接続中に失敗したのか、サーバーから応答を受け取った後に失敗したのかを確認します。

復旧後はGlobal Routingを本来使用するモードに戻し、最初に失敗した宛先を再確認します。Proxyだけで一時的に使えてConfigでは失敗する場合は、ルールを修正してください。一時的な比較結果を根本解決として扱わないでください。初期設定を確認したい場合はGlobal Routingの設定ガイドを、個別の質問はよくある質問を参照してください。

テストの失敗を確認可能な段階に分ける

Connectivity Testの失敗が示すのは、そのテストが想定どおり完了しなかったことだけです。サーバーが恒久的に使えないとは限りません。まず、テスト対象が現在選択中のサーバーか確認し、テスト方法を記録します。方法によって確認する段階は異なります。ポートに到達できてもプロトコル認証が成功するとは限らず、認証後に特定のページへアクセスできるとも限りません。テスト結果は実際のリクエストと合わせて判断してください。

まずアドレスとポートを確認し、アドレス欄にプロトコルの接頭辞、空白、改行、ホスト名以外のパスが混入していないか確認します。購読リンクをサーバーアドレスとして使わないでください。また、Web管理画面のアドレスをAdd Serverに入力しないでください。アドレスがドメイン名の場合は、デバイスで名前解決できるかも確認します。名前解決の失敗はサーバーへの接続より前に起きるため、認証項目を何度も変更せず、まずDNSを確認してください。

次に、同じ設定のまま基本ネットワークを一度切り替えます。たとえばWi-Fiからモバイルデータに変更します。一方のネットワークだけでタイムアウトする場合は、ローカルネットワーク、経路、使用する通信方式へのネットワーク制限を優先して確認します。両方で失敗する場合は、サービス提供元にサーバーの状態、ポート、設定値に変更がないか確認してください。比較中はサーバーと宛先を固定し、ネットワークの違いを判断材料にできるようにします。

プロトコルごとに設定を確認し、項目を混同しない

Shadowsocksでは暗号化方式とパスワードを確認します。VMessとVLESSでは識別情報とサーバー側が指定する通信設定を確認し、TrojanではパスワードとTLS関連項目を重点的に確認してください。プロトコルごとに項目の意味は異なり、同じアドレスを使うからといってすべての設定をコピーすることはできません。インポートに成功したことは、テキストを解析できたことを示すだけで、インポート内容がサーバーの現在の設定と一致するとは限りません。

TLSを使う接続では、サーバー名、証明書の有効性、デバイスの日時も確認が必要です。SNIはサーバー提供元の指示に従い、アクセスできるドメインを適当に入力しないでください。証明書エラーが出た場合は、まずデバイスの日時を確認し、ドメイン名、SNI、サーバー証明書を照合します。証明書検証を無効にする方法は通常の解決策ではありません。名前や証明書の設定ミスを見えなくし、接続先の検証を弱めることになります。

サーバー側がWebSocketなどの通信方式を使う場合は、パス、Host、TLSの組み合わせも確認します。パスは大文字と小文字を区別することがあり、先頭のスラッシュが必要な場合もあります。説明文の注釈までフォームにコピーしないでください。どれか一つでも不明な場合は、サービス提供元の原資料に戻って確認します。値を次々に推測して試すと、再現できない組み合わせになり、原因を特定しにくくなります。

継続的な障害と一時的なタイムアウトを区別する

特定の時間帯だけタイムアウトする場合は、失敗結果のスクリーンショットだけでなく、発生時刻、ネットワーク、サーバー、テスト対象を記録します。一時的なネットワークの混雑、ネットワークの切り替え、サーバー負荷の変化は、一度のテストに影響することがあります。間隔を空けて少数回比較してください。高頻度でテストを続けるのは避けます。並行リクエストが増えると干渉が起き、断続的な問題が継続的な不具合のように見えることがあります。

テストが完了しても実際のページにアクセスできない場合は、アクセス可能と確認済みの小さなページを使い、「サーバーへの接続」と「サーバー経由の宛先へのアクセス」を切り分けます。宛先側の制限、名前解決の違い、ルールの指定が後者の失敗につながることがあります。反対に、テスト対象そのものが使えないためにテストが失敗しても、アプリからのアクセスは正常な場合があります。一つのテスト結果だけでサーバーを削除しないでください。

サービス提供元に連絡する際は、プロトコル、エラーの種類、ネットワークの比較結果、再現手順を伝えます。パスワード、識別情報、購読リンク全体は共有しないでください。Trojanの各項目についてはTrojanのパラメーター解説を参照してください。設定を確認してもリモートサーバーに到達できない場合は、サービス提供元の確認を待ち、関係のないローカルルールを変更して問題を広げないでください。

取得失敗、解析失敗、項目の接続不能を切り分ける

Subscribeの更新に失敗した場合は、どの段階で問題が起きたかを確認します。リモートの内容を取得できない、取得した内容を解析できない、更新は完了したがサーバーに接続できない、の3つです。それぞれ対処方法が異なります。購読の更新はリモート情報をアプリに取り込む機能であり、リモートにあるすべてのサーバーが現在も接続できることを保証するものではありません。サーバーがタイムアウトする場合は、購読の更新結果を記録してから前の章で個別に確認してください。

購読リンクはサービス提供元から入手してください。コピーするときは完全なアドレスとクエリパラメーターを保ちます。長いリンクがチャット画面で改行されたり、切れたり、前後に空白が入ったりしていないか特に注意してください。ランダムな文字列に見える部分を削除しないでください。認証に使われている可能性があります。サービス提供元のアカウントページ、案内ページ、設定表示ページを購読アドレスとして使うのも避けてください。ブラウザに文字が表示されても、アプリが読み込めるデータとは限りません。

更新する前に、現在の購読グループと利用できる項目を記録します。その後、手動更新を一度実行し、表示されたメッセージを確認します。接続可能なサーバーが残っている場合は、その情報を保ち、再試行のためにグループ全体を削除しないでください。更新方法によって項目の名前、順序、内容が変わることがあります。接続前に選択中の項目を確認してください。以前の名前が見つからないことと、購読が完全に無効になったことは別の問題です。項目が置き換えられたり、分類し直されたりしていないか確認します。

アクセス経路と取得した内容を確認する

取得に失敗する場合は、現在の基本ネットワークから購読先のサービスにアクセスできるか確認します。必要に応じて、接続を切断した場合と、既存の接続を利用した場合の更新結果を比較します。ただし、変更するアクセス経路は一度に一つだけにしてください。更新リクエストは、通常のWebページへのリクエストと必ずしも同じ経路を使うとは限らないため、アプリに表示される結果を基準にします。サービス提供元が特定のアクセス条件を指定している場合は、その案内を確認してください。エラーを回避するために購読アドレスのドメイン名やプロトコルを適当に変更しないでください。

認証失敗やアクセス拒否が表示される場合は、購読情報がリセットされていないか、アカウントの許可状態に変更がないか、リンクが最新の有効なものかを確認します。無効になった認証リンクを繰り返しリクエストしても、通常は許可状態を復旧できません。リクエスト頻度が高すぎるというメッセージが表示された場合は、連続更新を止め、サービス提供元の指示に従って待ってください。アプリの購入状態とリモートの購読認証は別々です。クライアントを再購入しても、無効になった購読は復旧しません。

内容を取得できても解析に失敗する場合は、サービス提供元が案内した形式とインポート先が一致しているか確認します。取得内容がサーバー情報ではなく、ログインページ、エラーの説明、メンテナンス画面であることもあります。文字が表示されるだけでは形式が正しいとは限りません。Webページ全体を設定ファイルにコピーしたり、エンコードされた内容の記号を手作業で削除したりしないでください。サービス提供元に返却データの種類を確認し、現在のインポート画面に対応する情報を入手してください。

更新後の選択項目と保存状態を確認する

更新後はHomeに戻り、選択中のサーバーが残っているか、正しいグループに属しているか確認します。次に、項目を一つ選んで接続テストを実行してください。新しい項目がすべて失敗する場合は、プロトコルとサービス提供元の状態を重点的に確認します。一部だけ失敗する場合は、その項目の名前とエラー情報を記録して問い合わせてください。グループ内の項目数が変わっただけでアプリの不具合と判断しないでください。リモートの内容が変更された場合も、端末上の表示は変わります。

購読項目を手動で変更する前に、次回更新で変更が上書きされるか確認してください。特定の項目を検証する場合は、変更前の値を保存し、必要なら独立した手動テスト項目を作成して購読項目と比較します。同じサーバーを複数のグループにコピーして変更しないでください。後で接続している項目が元のものか、一時的な複製か判断しにくくなります。検証後は一時的な項目を整理し、区別しやすい名前を付けてください。

長期間更新されていない場合は、まず更新時に必要なネットワーク条件をアプリが満たしているか確認し、その後、更新設定を確認します。バックグラウンドでの実行はシステムのスケジュールに左右されるため、予定した時刻に更新されなかっただけで購読が無効とは限りません。手動更新は成功するのにバックグラウンド更新が想定どおり動かない場合は、サーバー設定をすべて作り直すのではなく、デバイスの利用環境とシステムの制限を優先して確認します。

最終的に、リンクの入手元、取得の成否、解析の成否、更新後に接続できた項目を一続きの記録にします。原因を判断できない場合は、認証情報を除いたエラーメッセージと発生段階をサービス提供元に伝えてください。公開の場にリンク全体を送らないでください。購読の簡単なQ&Aはよくある質問を、初回インポートの手順は使い方ガイドを参照してください。

まず遅い操作の種類を特定する

「速度が遅い」という症状は、初回表示が遅い、転送が遅い、動画がバッファリングする、ときどき停止する、ネットワーク切り替え後に接続が切れる、に分けて確認します。初回表示には名前解決、接続確立、ハンドシェイクが関わります。継続的な転送には帯域、混雑、接続先のサービスも影響します。両者を一つの遅延値だけで説明することはできません。繰り返しやすい操作を一つ選び、開始時と継続中の状況を記録してから確認する層を決めてください。

同じデバイスで基本ネットワークの状態を確認し、大きなファイルの同期、システムアップデート、複数アプリの継続的な通信が同時に行われていないか調べます。Dataの通信量の変化は通信中かどうかを判断する手がかりになりますが、通信量が多いからといって特定のサーバーが速いとは限りません。少ないからといって接続に失敗しているとも限りません。ほかのアプリが大量に通信している場合は、通信が終わってから比較し、デバイス全体の負荷をプロキシの性能と混同しないようにします。

テスト対象、サーバー、Global Routingのモードを固定し、近い時間帯に少数回のテストを行います。ネットワーク、サーバー、プロトコルを一度に変更すると、改善の原因を特定できません。まず同じサーバーを二つのネットワークで比較し、次にネットワークを固定して、利用中のサーバーを二つ比較します。各手順で変更する変数を一つにすれば、結果からボトルネックを特定しやすくなります。

ローカルネットワーク、サーバー、接続先を分けて比較する

特定のWi-Fi環境だけで遅い場合は、電波強度、デバイスとアクセスポイントの距離、ルーターの負荷、ネットワークへのログイン状態を確認します。プロトコルの設定を変更するより、電波が安定した場所に移動して再試行するほうが原因を判断しやすくなります。モバイルデータと比較する場合も、電波強度や通信方式の変化に注意してください。移動中に行った一度のテストは、場所を固定したときの通常の状態を示すものではありません。

同じネットワークで特定のサーバーだけが遅く、ほかの利用中サーバーは正常な場合は、サーバーの負荷とそのサーバーまでの経路を重点的に確認します。複数のサーバーが遅くてもDirectで正常だからといって、すぐにアプリ自体の問題とは判断できません。同じような経路やリモート出口を共有している可能性があります。接続先、時間帯、プロトコルを追加で比較し、変化に一貫性があるか確認してから、再現可能な情報をサービス提供元に伝えてください。

特定のWebサイトやサービスだけが遅い場合は、同じサーバーからほかの接続先へアクセスしたときの状況を確認します。コンテンツ配信、アカウント制限、サービスの状態、アクセス元の地域によって結果が変わることがあります。速度測定用ファイルの転送速度は、すべてのWebサイトの表示速度を示すものではありません。ダウンロードが速くても、短時間の接続に必要なハンドシェイクがスムーズとは限りません。見栄えのよい数値を探すのではなく、実際に問題が起きた操作を中心にテストします。

通信特性を確認し、根拠のない設定変更を避ける

プロトコルによってはUDPを使用し、ネットワークごとに到達性や継続的な通信の状態が異なる場合があります。Hysteria2またはWireGuardを使う場合は、まずネットワークとサーバーが該当する通信方式に対応していることを確認し、その後プロトコル設定を調べます。別のTCP接続が使えるからといって、UDP経路にも問題がないとは限りません。プロトコルはサーバーの設定に合わせて選び、クライアント側の種類だけを変更して従来の設定を流用しないでください。

MTU、同時接続数、接続維持などの設定を最初に変更するのは避けてください。特定の経路で起きるフラグメンテーションやパケットロスは、小さなリクエストは成功するのに大きなデータ転送が停止する、といった症状になることがあります。ただし、似た症状は混雑や接続先の制限でも起きます。比較結果なしにMTUを下げると、ほかのアプリの動作に影響する場合があります。テストが必要な場合は元の値を記録し、一項目ずつ変更し、改善しなければ元に戻してください。

ネットワーク切り替え後に停止する場合は、新しいネットワークへの接続がシステムで完了するまで待ってから、リクエストを再試行します。アプリによっては古い接続を維持し、切り替え後に再接続が必要な場合があります。これはすべての通信が継続的に使えないことを意味しません。ブラウザで新しいリクエストを実行し、元のアプリの古いセッションと比較すると、基本トンネルの問題かアプリのセッション復旧の問題か判断しやすくなります。接続のオン・オフとネットワークの切り替えを同時に繰り返さないでください。再接続の処理に干渉することがあります。

改善を確認するときは、以前遅かった操作を最初から最後まで再実行し、安定しているか確認してください。一度だけ速く開いたからといって、未検証の設定をたくさん保存しないでください。どの変更で改善したか、元に戻したときに再び遅くなるかを記録します。詳しい切り分け方法は速度低下を段階的に調べるメモを、通信量の集計方法はData画面の通信量の見方を参照してください。

本当に名前解決の段階で起きているか確認する

DNSの問題は、サーバーのドメイン名を解決できない、一部の接続先でアドレスが見つからない、ネットワーク切り替え後に同じドメインへのアクセス結果が変わる、といった形で現れます。サーバーアドレスを解決できない場合と、接続先のドメインを解決できない場合をまず区別してください。前者ではプロキシ接続を確立できず、後者は接続確立後に起きることがあります。具体的なドメインとエラーが起きた段階を記録し、ローカルネットワーク、アプリ内のDNS設定、サーバー経由の経路のどれを確認すべきか判断します。

ブラウザで接続先のIPアドレスに直接アクセスする方法を、すべての名前解決確認の代わりにしないでください。多くのサービスはTLSや仮想ホストの照合に正しいドメイン名を必要とします。IPアドレスでアクセスできなくても、ネットワークに問題があるとは限りません。同様に、あるIPアドレスに接続できても、ドメインに対応するページへ必ずアクセスできるとは限りません。アプリ内で確認できる名前解決やリクエストの記録を参照し、ドメインが解決されているか、その後どのポリシーに進むかを確認してください。

確認には、正常に使えるとわかっている接続先を使い、現在のネットワークを変えずにテストします。一つのドメインだけ失敗する場合は、スペル、ドメイン自体の状態、サービス提供元から指定されたサーバーアドレスを確認してください。関係のない多数のドメインが同時に失敗する場合は、名前解決サービス、またはそのサービスへアクセスする経路を優先して調べます。サーバー側が返したエラー、アカウント認証の失敗、空白ページをすべてDNS障害と呼ばないでください。

名前解決の経路、キャッシュ、アドレス種別を確認する

現在のConfigでDNS関連の設定を確認し、デバイスに追加のDNS設定やネットワーク管理ポリシーがないかも調べます。まず、名前解決に関わる可能性がある設定を一覧にしてから、どれをテストするか決めてください。DNSサーバーを変更する前に、選択するアドレスのプロトコルとネットワーク経路が使えることを確認します。到達できないDNSサーバーを設定すると、一つの接続先だけの問題がすべてのドメインの失敗に広がる可能性があります。

暗号化された名前解決を使う場合は、サーバー名、証明書、アクセス経路も確認します。暗号化された名前解決への接続自体がサーバー名の事前解決を必要とする場合があり、依存関係が正しくないと起動時に失敗します。「暗号化」と表示されているだけで、名前解決の経路が正しいと判断しないでください。使用中の設定の説明に従って、通常のDNSアドレス、暗号化DNSのアドレス、Webページのアドレスを混同しないようにします。

設定を変更した後は、キャッシュと既存の接続も考慮してください。システム、アプリ、接続先のアプリが以前の結果を保持している場合があり、一度更新しただけでは新しい名前解決が行われないことがあります。該当するリクエストを終了し、接続を再確立してもう一度テストしてください。必要なら接続先のアプリを再起動します。結果を記録せずに複数のDNSサービスを次々に切り替えると、キャッシュが更新されていないときに見た現象を、直前の設定変更の影響と誤認するおそれがあります。

IPv4とIPv6で経路が同じ状態かも確認します。ネットワークによっては両方のアドレスが返されても、片方の経路が不安定な場合があります。一方、特定のアドレス種別を必要とするサービスもあります。一つの接続先を直すために、IPv6関連の機能をすべて無効にしないでください。異なるネットワーク、具体的なドメイン、失敗したアドレス種別を比較し、問題の範囲を確認してから、現在の設定で利用可能な項目を最小限変更します。

名前解決結果とルールの順序を合わせて確認する

ドメインルールとアドレスルールでは、確認対象が異なります。DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインの末尾、IP-CIDRとIP-CIDR6はアドレス範囲を対象にします。リクエストが先に広範囲のルールにマッチすると、後ろにある詳細な項目が判定されないことがあります。名前解決結果が変われば、アドレスルールのマッチ結果が変わることもあります。「DNSで結果が得られた」ことと「正しいルールにマッチした」ことは、別々に確認してください。

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

上記のルール例は、対象となるマッチ条件の違いを示すもので、完全な設定ではありません。この例では、同じポリシーを指定するドメイン完全一致の行がサフィックスの行に包含されています。構文を比較するために両方を記載していますが、実際の設定で不要な重複は避けてください。プライベートアドレスのルールが処理するのは、該当するアドレス範囲だけです。この一行でLAN内のすべての検出やデバイス間通信が解決するわけではありません。LANの問題は最後の章も確認してください。

復旧後は、サーバーのドメイン名が解決できること、失敗した接続先が解決できること、新しいリクエストが想定したポリシーにマッチすること、実際のページを利用できることを個別に確認します。いずれかがまだ異常な場合は、対応する層を調べてください。DNSアドレスを次々に追加しないでください。サービス提供元への問い合わせには、機密情報を隠したドメイン名、エラーの種類、ネットワークの比較結果を伝えます。アカウントを識別できる専用アドレスや完全な設定ファイルは公開しないでください。

継続的な通信や再接続がないか確認する

バッテリーの異常な消費を調べるときは、デバイスのSettingsにあるバッテリー使用状況、画面の使用時間、当時のネットワーク通信を合わせて確認します。VPN接続はほかのアプリの通信も中継するため、システム上の表示だけでは、個々のアプリが発生させたすべての活動を正確に示さない場合があります。一つの割合だけで設定に問題があると判断しないでください。まず異常が起きた時間帯を記録し、動画再生、同期、アップロード、長時間の通信が同時に行われていないか確認します。

調査は、デバイスを静置した状態と使用中の状態に分けて行います。静置時の比較では、同じネットワーク、近いバッテリー残量、同程度の観察時間を保ち、同時に充電、ダウンロード、場所の移動を行わないでください。使用時の比較では、同じ操作を行い、継続時間を記録します。短時間のバッテリー表示は、温度やシステムの推定に左右されるため、正確な消費量を判断する材料には適しません。継続的な通信や繰り返しの接続といった、直接確認できる手がかりを優先してください。

接続が不安定だと再試行が繰り返され、ネットワークの使用量が増える場合があります。Wi-Fiとモバイルデータの間で何度も切り替わっていないか、電波の弱い場所にいないか、On Demandが近い条件の間で繰り返し動作していないか確認します。まず基本ネットワークを安定させ、On Demandを一時的にオフにして手動接続を比較します。再接続が止まってバッテリーの状態が改善する場合は、すべての機能を一度に無効にするのではなく、条件を一つずつ戻してください。

通常の確認を損なわず、診断による影響を抑える

トラブルシューティング中は、一時的に詳細ログを有効にしたり、Connectivity Testを頻繁に実行したりすることがあります。必要な記録が取れたら、ログのレベルを元に戻し、繰り返しのテストを止めてください。診断作業そのものを日常的な通信負荷と混同しないためです。Dataで通信量が増え続けている場合は、ほかのアプリの動作も確認します。クラウド同期、メディアのアップロード、バックグラウンド通信は画面をオフにした後も続く場合があり、デバイスが静止して見えるだけでは通信がないとは限りません。

デバイスが明らかに熱くなった場合は、高負荷のテストを止め、温度が安定してから接続状況を比較してください。温度の変化はシステムの性能や無線通信に影響する場合があります。充電しながら通信を続けることも、判断を難しくします。データ収集のために負荷テストを続けないでください。日常のトラブルシューティングでは、実際の問題を再現し、改善を確認することが目的です。デバイスやネットワークの限界を測ることではありません。

バッテリーの問題では、デバイス全体の状態も確認する必要があります。接続を切っても同じようにバッテリーが消耗する場合は、プロキシ設定を調整し続けるのではなく、システムのバッテリー記録やほかのアプリの動作を確認してください。特定のネットワークとサーバーの組み合わせでのみ起きる場合は、接続の再試行と通信の安定性を優先して調べます。再現できる組み合わせに範囲を絞ることで、デバイスのバッテリー状態を単一のアプリ設定の問題と誤認しにくくなります。

アップデート後は最小限の設定から戻す

アップデート後に問題が起きた場合は、アプリ、システム、購読、Configのどれを更新したのか切り分けます。更新時期が近くても、それぞれ影響する対象は異なります。最後に正常に使えたときのネットワークと設定を記録し、現在のサーバー、Global Routing、設定ファイルが以前と同じ選択か確認してください。購読の名前変更、ポリシーの参照先変更、システム権限の状態変化によって、アプリの更新が直接の原因のように見えることもあります。

まずアプリを通常の手順で開き直し、必要ならデバイスを再起動します。その後、確認済みのサーバーを一つ選び、簡単な接続先でテストしてください。自分で追加した複雑なルール、On Demandの条件、その他の拡張設定は、元の内容を保存してから一時的に無効にします。設定を一つ戻すたびに動作を確認してください。基本接続が正常で、特定の設定を追加した後だけ失敗するなら、アプリのデータをすべて削除せず、その設定に調査範囲を絞れます。

Configで無効になったポリシー参照、削除済みのサーバー名、形式の誤りを確認します。古い設定を保存できても、参照先の項目が現在も存在するとは限りません。解析エラーが表示される場合は、該当する行を特定し、変更前後の差分を残してください。一つのエラーを直すために、異なる入手元のパラメーターを大量に組み合わせないでください。設定間の依存関係により、一つずつ見れば正しい内容でも、組み合わせると動かなくなることがあります。

必要な情報をバックアップし、明確な理由がある場合に限り、システム構成の削除やアプリの再インストールを検討してください。アプリの入手とアップデートはApp Storeから行います。購入済みアプリの復元とデバイスの互換性は購入済みアプリの復元方法を参照してください。システム要件はApp Storeの掲載情報をご確認ください。復元後は基本接続を確認してから、保存した情報を少しずつ戻します。「アップデート後に壊れた」という未検証の説明より、完全に再現できる手順のほうが原因究明に役立ちます。

デバイスを比較する前にネットワークと設定を揃える

同じ購読を使っていてiPhoneでは正常、iPadでは失敗する場合は、まず2台が実際に同じネットワークを使っているか確認します。iPhoneはモバイルデータに切り替わっていて、iPadは認証が必要なWi-Fiや電波の弱いWi-Fiに接続したままのことがあります。実際のネットワーク状態を確認し、選択中のサーバー、Global Routing、Config、購読の更新日時を照合してください。サーバー名の表示が同じだけでは不十分です。同じ名前の項目でも設定が異なる場合があります。

2台で同じ接続先、同じサーバー、同じモードを使い、新しいリクエストをそれぞれ実行します。一方のデバイスですでに読み込まれたページを、もう一方での初回アクセスと比較しないでください。条件を揃えてもiPadだけ失敗する場合は、そのデバイスのVPN許可、日時、デバイス管理ポリシー、追加のネットワーク設定を確認します。別のデバイスでサーバーが動作していても、iPad側の権限や設定の違いを除外することはできません。

アプリの購入と設定の移行は分けて確認します。同じアカウントでの購入済みアプリの入手、デバイスの互換性、システム要件はApp Storeの掲載情報をご確認ください。アプリがインストール済みでも、サーバー情報がすべて自動で表示されるとは限りません。まずiPadでの入手方法を確認し、次にサービス提供元から購読情報を入手してインポートします。その後に接続状況を比較し、設定不足を購入の復元失敗と混同しないようにしてください。

マルチタスク、スリープ、ネットワーク復帰を確認する

iPadで画面分割やマルチタスクを使うと、アプリの表示領域が狭くなり、設定項目を表示するために画面の展開やスクロールが必要な場合があります。ウインドウが狭くなってもパラメーターの意味は変わりませんが、下に隠れた項目を見落としやすくなります。Add Serverを確認するときは項目ごとにスクロールし、保存後に項目へ戻って再確認してください。編集画面の上部だけが正しく見えるからといって、すべての設定が保存済みとは限りません。

画面を閉じた後、長時間静置した後、またはネットワーク切り替え後に問題が起きた場合は、システムのネットワーク復帰、VPN接続の状態、接続先アプリのセッションを分けて確認します。まず基本ネットワークに正常にアクセスできることを確認し、次にShadowrocketの接続を調べます。最後に接続先のページを開き直してください。新しいリクエストは正常でも、以前の動画、ファイル転送、セッションが停止したままの場合は、接続先アプリが古い接続を再開できていない可能性があります。すぐにサーバー設定全体を作り直す必要はありません。

iPadのOn Demandも、実際のネットワーク条件ごとに確認します。同じWi-Fiに長時間接続していても、途中でスリープしたり、認証が切れたり、アクセスポイントが切り替わったりする場合があります。まず手動接続で基本動作を確認し、その後On Demandを戻して、スリープ解除、ネットワークから離れた後、再接続後の動作をそれぞれテストしてください。一度のスリープ解除が正常だっただけで、すべてのネットワーク条件を確認したことにはなりません。実際の利用状況に即した検証記録を残します。

LAN内アドレス、デバイス検出、プロキシ経路を区別する

自宅のストレージ、プリンター、ほかのLANサービスに接続できない場合は、まず接続を切断して比較し、デバイスが相互通信できる同じネットワークに接続しているか確認します。ゲストWi-Fi、アクセスポイントの分離、異なるサブネットによって、デバイス間通信が妨げられることがあります。切断してもアクセスできない場合は、まずルーターやデバイスの権限を確認してください。基本的なLAN経路が正常な場合に限り、Configのルーティングルールを確認します。

LAN内のデバイス検出と、既知のアドレスへの直接アクセスは別の動作です。アドレスを指定すればアクセスできるのに自動検出だけが失敗する場合は、検出用パケット、ネットワークの分離、システムのローカルネットワーク権限が関係している可能性があります。ドメインルールを一つ追加するだけで解決するとは限りません。関連アプリにローカルネットワーク権限が必要な場合は、デバイスのSettingsで許可状態を確認してください。あらゆる検出の問題をDNSのせいにしたり、ネットワーク全体に広範囲なポリシーを安易に追加したりしないでください。

特定のプライベートアドレス範囲を直接接続させる必要がある場合は、実際のサブネットを確認し、対応するIP-CIDRまたはIP-CIDR6ルールを使用します。そのルールを妨げる広範囲のルールより前に配置してください。例示されたサブネットを家庭内ネットワークの実際の設定だと思い込まないでください。ドメインとアドレスの両方を使うサービスでは、ドメインがどのアドレスに解決されるかも確認します。ドメインがリモートのアドレスへ接続される場合、ローカルのプライベートアドレスルールだけを変更しても解決しません。

テストでは、既知のアドレスへのアクセス、ドメイン名でのアクセス、デバイス検出を個別に確認し、それぞれの結果を記録します。検出だけが失敗する場合は検出の仕組みを調べます。ドメイン名では失敗してアドレス指定では正常な場合は、DNSの章を確認します。LAN内の宛先すべてが失敗する場合は、ネットワーク分離とルールの順序を調べます。こうして切り分けると、一つのアクセス方法を直すためにほかの経路まで変更し、新たな問題を引き起こすのを防げます。

最後に、デバイスの機種区分、現在のネットワーク、接続モード、接続先の種類、エラーメッセージ、比較結果を含む再現可能な記録を作成します。共有する前に、購読アドレス、認証情報、アカウント情報を隠してください。基本接続が復旧したら使い方ガイドに戻り、日常的な確認を行います。よくある結論をすぐに確認したい場合はよくある質問を参照してください。この記録を残しておけば、似た症状が再発したときに、設定全体を変更し直さず、確認済みの段階から調査を続けられます。