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

接続スイッチが入らない：まずシステムの許可を確認

スイッチがオンのままにならない場合は、「システムがトンネルを確立できていない」状態と「トンネルは確立したがアクセスできない」状態を区別します。前者では、オンにした直後にオフに戻る、許可を繰り返し求められる、またはシステム設定のVPN状態が変わらないことがあります。後者では接続状態を維持できても、コンテンツを読み込めないことがあります。まずHomeで一連の操作を一度確認し、正常な接続処理を無反応と誤認しないよう、スイッチを素早く何度も切り替えないでください。

初回の許可とローカル設定を確認する

初めて有効にするとき、VPN構成の追加を許可し、デバイスのパスコードやシステム認証で確認するよう求められる場合があります。Shadowrocketを自分で操作した直後に表示された場合に限り、許可を続行してください。ダイアログをキャンセルした場合は、アプリに戻って接続を再度開始できます。アプリ内のスイッチ操作とシステムの許可は別の手順です。サーバーを読み込んだだけでは、デバイスでトンネルを作成する許可が得られたことにはなりません。許可後、システムとアプリの状態が一致しているか確認してください。

システム設定でVPN構成を確認し、Shadowrocketに対応する項目があるか確認してください。システムの入口名はOSのバージョンなどによって変わるため、設定内の検索を使って探し、固定の手順にこだわる必要はありません。ネットワーク構成が複数ある場合は、名前と用途を記録してから、デバイスの通信を引き継ぐ他の接続を一時停止してください。まとめて削除しないでください。特に、職場や学校が管理するデバイスでは、管理ポリシーによって一部の構成が自動的に再設定される場合があります。

Homeで有効なサーバーが選択されているか確認します。リストに項目があるかだけでなく、選択済みのマークを確認してください。項目を開き、Address、Port、プロトコルの種類が正しく保存されているか確認します。編集後に画面を閉じた場合は、もう一度開いて変更が保存されていることを確認してください。項目の不足や設定の解析エラーは、接続開始時の失敗につながる場合があります。サーバーと実際に通信できるかは次の段階で確認してください。スイッチがオフに戻っただけで、リモート側の障害と判断することはできません。

On Demandとシステムの制限を確認

手動でオフにした後に自動でオンになる場合は、まずOn Demandを確認してください。On Demandは設定済みの条件に応じて接続を開始します。手動操作と自動接続が同時に働くと、スイッチが操作に反応していないように見えることがあります。現在の条件を記録し、On Demandを一時的にオフにして、手動接続と切断を比較してください。手動操作で状態が安定することを確認してから、自動接続の条件を一つずつ戻します。On Demandのルール変更とサーバーの変更を同時に行わないでください。

ボタンを操作できない、または許可のダイアログが表示されない場合は、デバイスが組織によって管理されているか、システムでVPNの変更が制限されていないか確認してください。管理ポリシーによる制限は、デバイス管理者に確認してください。アプリを何度も再インストールしても、通常はポリシーを変更できません。個人所有のデバイスでは、ネットワークを使用中のタスクを終了し、通常の手順でデバイスを再起動してから、もう一度テストできます。再起動は一時的な状態を解消するためのもので、サーバー設定やネットワーク条件を修正する方法ではありません。

Webページで認証が必要なWi-Fiでは、まずトンネルを切断してネットワーク認証を完了してから接続してください。認証ページに通信を遮られていても、システム上はWi-Fiに接続済みと表示される場合があります。Wi-Fiアイコンだけで判断せず、通常のWebページを開いて基本的なネットワーク接続を確認してください。ほかの利用可能なネットワークに切り替えるとスイッチが安定する場合は、アプリのデータをすぐに消去せず、元のネットワークの接続条件を確認してください。

VPN構成を再作成するタイミング

許可の記録に異常がある、システムとアプリの状態が継続的に一致しない、かつ前述の比較で解決しない場合に限り、該当するVPN構成の再作成を検討してください。まずサーバー情報とConfigをバックアップし、接続とOn Demandを停止します。その後、Shadowrocketのものと確認できたシステムVPN項目を削除し、アプリに戻って再度許可を求めます。システムVPN項目の削除と、アプリ内のサーバー削除は別の操作です。確認メッセージをよく読み、必要な情報を誤って削除しないようにしてください。

再作成後は、変数を最小限にしてテストします。確認済みのサーバーを一つ選び、手動で接続し、On Demandは一時的にオフにしてください。それでもすぐに切断される場合は、エラーメッセージ、再現手順、システムの接続状態を記録します。スイッチが安定してもアクセスできない場合は、次の章に進んでください。最初から「ネットワーク設定をリセット」しないでください。他のネットワーク情報にも影響し、比較に使える元の環境が失われる場合があります。

接続後にインターネットへアクセスできない：サーバーとルールを分けて確認

接続状態が示すのは、デバイスで該当するネットワーク経路が開始されたことです。すべてのリクエストが目的のサービスに到達したことを示すものではありません。確認には、正常にアクセスできると分かっているWebページと、実際に失敗する対象を一つずつ選びます。すべてのアプリで失敗するのか、特定のWebサイトだけか、一部のコンテンツだけ読み込めないのかを記録してください。ブラウザーに表示される一般的なエラーには、名前解決、接続、証明書の問題が含まれる場合があります。元のメッセージを記録し、すぐにサーバーが利用不能だと判断しないでください。

Global Routingで比較する

まず現在のGlobal Routingを記録し、各モードの用途を確認します。Configは現在の設定にあるルールに応じてポリシーを選択します。Proxyは、プロキシ経路を利用できるリクエストの比較に使います。Directは、直接接続する経路の比較に使います。これらは「効果の強さ」で並ぶ選択肢ではありません。テスト後は元のモードに戻してください。一時的にProxyで成功しても、ルール設定が修正された証拠にはなりません。

DirectではアクセスできてProxyでは失敗する場合、デフォルトサーバーとプロトコル設定を優先して確認します。ProxyではアクセスできてConfigでは失敗する場合は、ルールの適用先とポリシーの行き先を重点的に確認してください。すべて失敗する場合は、接続を完全に切断して基本ネットワークをテストしてから、DNSの章に進みます。Directでも現在のネットワーク処理や名前解決の設定が影響する場合があります。「Directに切り替える」と「接続を切断する」は、別々の比較項目として記録してください。

ルールの順序に沿って適用先を確認

Configで、名前が似たファイルを開いているだけではなく、実際に有効になっているファイルを確認してください。通常、ルールは順番に照合され、先に一致した項目が後続ルールの適用に影響します。対象が広すぎるDOMAIN-KEYWORD、ドメインサフィックスのルール、IPルールによって先に処理されていないか確認し、適用されたポリシーが存在するか、想定したサーバーを指しているかも確認してください。ルールの記述が正しくても、ポリシーを利用できなければアクセスに失敗することがあります。

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

上の例は一致判定とフォールバックの関係を示すもので、現在のファイルにそのまま上書きするためのものではありません。DOMAIN-SUFFIXは例のドメインとそのサブドメインに適用されます。DOMAIN-KEYWORDは範囲が広いため、変更前に意図しない一致が起きないか確認してください。FINALは、それまでのルールに一致しなかったリクエストを処理します。例のドメインは実際の対象に合わせて変更し、PROXYについても現在のデフォルトサーバーを確認してください。独自のポリシー名を使う場合は、名前と参照先が一致しているかを確認します。綴りの違いをネットワークの問題と混同しないでください。

ページのテキストは表示されるのに画像、ログイン、動画が失敗する場合、アドレスバーのドメインだけを確認しないでください。一つのページが複数のドメインからリソースを読み込むことがあり、認証中に別のドメインへ移動する場合もあります。問題を一度再現し、アプリで確認できるリクエスト記録を見て、成功したリクエストと失敗したリクエストの宛先やポリシーを比較してください。調整が必要だと根拠を確認できたルールだけを追加します。一つのリソースが失敗したからといって、範囲の広いキーワードルールを先頭に置かないでください。変更範囲を広げると、本当の原因を見えにくくします。

アプリと対象サービスの問題を切り分ける

特定のアプリだけで問題が起きる場合は、まずブラウザーから同じサービスのWebページにアクセスして比較します。Webページが正常でも、アプリ内部のAPIが正常とは限りませんが、問題の範囲を絞り込めます。そのアプリに古い接続が残っていないか確認し、ポリシーを切り替えた後はアプリを完全に終了して再起動し、リクエストをもう一度実行してください。既存の接続は以前の経路を使い続ける場合があります。ルール変更後、古い接続すべてで即座にポリシーが再選択されるわけではありません。

ログイン制限、アカウントに関するメッセージ、コンテンツの利用権限に関する問題は、対象サービスからの応答とネットワークのタイムアウトを分けて考えてください。接続に成功しても、サービス側のアカウント状態は変わりません。設定を元に戻した後、特定のWebサイトだけに適用するルールの書き方を参照して、必要な例外を整理してください。対象リクエストが想定したポリシーに安定して振り分けられ、接続を作り直した後もアクセスが成功することを確認して、今回のルール確認を完了とします。

サーバーがタイムアウトする：到達性からプロトコル認証まで確認

サーバーのタイムアウトに原因が一つだけあるとは限りません。アドレスの名前解決失敗、宛先ポートに到達できない、プロトコル項目の不一致、TLS検証の失敗などが、待機後のエラーとして表示される場合があります。まずアプリでどのテストを実行したかを確認し、実際の接続時に何が起きているかを調べてください。ある遅延テストで結果が返っても、そのテストで対象となった段階が応答したことを示すだけです。認証、目的のリクエスト、継続的なデータ転送まで正常とは限りません。

サーバー情報が一致しているか確認

Homeで現在選択されている項目を開き、自分が持つ元の情報とType、Address、Port、認証項目を一つずつ比較します。アドレスの前後に空白が入る、完全なリンクをAddressに貼り付ける、サブスクリプションURLを単一サーバーのアドレスと取り違える、といったミスが起こりやすいので注意してください。Portには資料に記載された番号を使い、プロトコル名から推測しないでください。QRコードから読み込んだ場合も、読み込み後に項目を開いて再確認します。読み込みが成功したことは、内容が認識されたことを示すだけです。

情報がまだ有効か、サーバー側で接続先や認証情報が変更されていないか確認します。自分が利用中のサブスクリプションを更新し、新旧の項目に違いがあるか確認できます。手動で保存した専用パラメーターがある場合は、更新で上書きされた後に記憶を頼りに入力し直さないでください。「元の資料の記載」「アプリに保存された内容」「現在選択中の項目」を並べて確認すると、異なる設定を何度も試すより原因を見つけやすくなります。

現在のネットワークでテストしてから、利用可能な別のネットワークでも同じテストを行います。両方で失敗する場合は、サーバーの状態と設定を優先して確認してください。一方のネットワークだけで失敗する場合は、そのネットワークのポート、転送方式、接続条件を検討します。この比較だけでどちらに問題があるか断定はできませんが、特定ネットワークの条件を設定ミスと誤認するのを防げます。比較するには、テスト中に同じサーバーと同じ方法を使ってください。

プロトコルごとに重要な項目を確認

TLSを使う設定では、接続先アドレスと証明書名がそれぞれ異なる役割を持つ場合があります。Addressは接続先を決め、Peer/SNIはサーバー名や証明書の処理に関係します。元の資料に名前が指定されている場合は、そのまま対応させ、すべての項目を同じIPに置き換えないでください。デバイスの日付と時刻が大きくずれていると、証明書の有効期間の判定に影響することもあります。まず時刻と名前を確認し、エラーメッセージに応じて次の原因を調べてください。

証明書エラーを隠すために、Allow Insecureを常時有効にしないでください。この設定は検証条件を変更します。一時的に接続できても、サーバー設定が正しいことの証明にはなりません。サーバーから提供されたドメイン、証明書名、TLS要件を確認してから、検証を再び有効にしてください。情報が不足している場合は、自分が利用しているサービスの提供元に必要な項目を確認してください。マニュアルの例は実際の接続パラメーターの代わりにはなりません。

実際のリクエストで最終確認する

Connectivity Testを実行した後、アクセスできると分かっているWebページを開き、コンテンツを最後まで読み込めるか確認してください。テスト結果が返ってもWebページが失敗する場合は、DNSとルールを引き続き確認します。大きなリクエストだけが失敗する場合は、速度の章で転送と経路を調べてください。異なるテストの測定値をそのまま比較しないでください。テストごとに方式、宛先、タイムアウト条件が異なる場合があり、数値の違いが同じ接続の性能変化を示すとは限りません。

WireGuardでは、Allowed IPsとローカルアドレス範囲にも注意してください。これらは、接続先Webサイトを指定する一般的なルール一覧ではありません。ハンドシェイクの状態とWebアクセスは別々に確認してください。ルーティング範囲の誤りで、一部の宛先にアクセスできなくなる場合があります。各項目の意味を確認するにはWireGuardの設定項目の説明を参照してください。ただし、自分のものではないアドレスや鍵をそのまま使わないでください。

トラブルシューティングの記録には、プロトコル、テストしたネットワーク、エラーが発生した段階、すべてのサーバーで失敗するかを残してください。一つの項目だけが失敗し、ほかの利用中の項目が使える場合は、確認済みの設定を一時的に使い、失敗した項目だけを自分が利用しているサービスの提供元に確認します。記録を共有する際は、認証情報と完全なサーバーアドレスを隠してください。項目名とエラーの種類があれば、通常は問題の説明に十分です。接続情報一式を公開する必要はありません。

サブスクリプションの更新失敗：リクエスト・内容・読み込み結果を切り分ける

Subscribeの更新には、アプリによるアドレスの読み込み、ネットワーク経由のリクエスト、応答の取得、内容の解析、項目のローカル保存という複数の段階があります。どの段階でも失敗する可能性があります。まず元のメッセージと発生したタイミングを記録し、失敗が表示されたからといって既存のグループを削除しないでください。以前保存したサーバーがまだ使える場合もあります。グループを削除すると比較用の情報を失ううえ、上流からのエラーが解決するとは限りません。

リンクが完全で、正しい情報源のものか確認

利用中のサービス提供元からサブスクリプションURLをもう一度コピーし、何度も転送されたテキストが途中で切れていないか確認してください。改行、空白、文末の句読点が混入していないか、特にクエリパラメーターの文字列が完全かを確認します。リンク内の認証パラメーターは機密情報です。公開スクリーンショット、オンライン変換ページ、コメント欄などに載せないでください。項目の構造だけを確認する場合は、実際のURLではなくサンプルを使用し、トラブル対応のために認証情報の共有範囲を広げないでください。

取得したものがサブスクリプションのコンテンツURLであり、アカウント管理ページ、支払い履歴ページ、ログインが必要なWebページではないことを確認します。ブラウザーでページを開けても、アプリが解析できるサーバー情報が返されるとは限りません。応答がログイン画面、エラー説明、メンテナンス画面の場合、アプリは通常それをサーバー一覧として読み込めません。プロトコル項目を繰り返し変更せず、自分が情報を取得した場所に戻ってURLの種類を確認してください。

初回の読み込みと日常的な更新も分けて考えてください。初回に失敗する場合は、URL、応答形式、ネットワークを重点的に確認します。以前は成功していたのに今は失敗する場合は、サブスクリプションの変更、認証の失効、サーバー側の内容変更も確認してください。ローカルのグループ名が同じだからといって、URLも同じとは限りません。グループ名が変わらなくても、実際に保存されたリンクが異なる場合があります。記録を取る前に、完全なURLを隠してください。

再現できる方法で更新をテスト

まず現在のネットワークで手動更新を一度行い、結果が分かるまで次の操作をしないでください。続けて何度もタップすると、複数のリクエストが重なったり、サーバー側の頻度制限が作動したりする場合があります。一時的にリクエストできないというメッセージが出た場合は、現在の項目を残し、少し時間をおいて一度だけテストしてください。ネットワークを切り替える前に、接続中かどうかと、どのGlobal Routingを使っていたかを記録します。更新リクエストの経路が変わって成功しただけかもしれず、リンクの内容が修正されたとは限りません。

既存の接続がサブスクリプションのリクエストに影響している可能性がある場合は、基本ネットワークが利用できることを確認したうえで、接続を切断して試せます。また、利用可能と確認済みの接続経由で比較する方法もあります。実際のリクエスト経路はアプリ内の関連設定にも左右されるため、決めつけず、確認できる記録を基準にしてください。依存関係が循環する状態にも注意が必要です。唯一のサーバーが利用できなくなっているのに、更新内容を取得するためにそのサーバーが必要になる場合があります。

リクエストは成功したのに項目が空の場合は、応答に有効なサーバー情報が含まれているか、アプリがその形式に対応しているか確認します。一部の項目だけ表示される場合は、表示されない項目のプロトコルや設定項目を比較し、すぐに既存情報をすべて上書きしないでください。自分が情報を取得した場所から単一サーバーの情報を得られる場合は、一つを手動で追加して接続を確認できます。これにより、「サーバー自体が利用できない」のか「一括データを正しく解析できていない」のかを切り分けられます。

更新後に選択項目とローカル変更を確認

サブスクリプションの更新後、Homeでデフォルトサーバーをもう一度確認してください。選択していた項目が置き換えられた、名前が変更された、または削除された場合、現在の選択が以前と同じ接続先とは限りません。更新後の項目を開いて重要な設定を確認し、Connectivity Testと実際のリクエストを行ってください。リストの件数が正常に見えても、項目が読み込まれたことを示すだけです。認証が有効か、サーバーに到達できるか、現在のルールでその項目が選ばれるかは別に確認する必要があります。

サブスクリプション内のサーバー情報と、Config内のルールファイルを区別してください。Subscribeを更新してもConfigのルール順が自動で修正されるとは限りません。Configを再読み込みしても、失効したサブスクリプションは復旧しません。サブスクリプションの項目を手動で変更していた場合、更新時に上流の内容と再度対応付けられることがあります。継続して使う独自設定は、保存場所と更新時の動作を確認してから管理方法を決めてください。問題が起きるたびに記憶を頼りに入力し直すのは避けてください。

復旧時は、できるだけ小さな範囲で確認します。まず既存のグループを残し、新しいURLの内容とサーバーを一つ検証してください。問題がないことを確認してから重複項目を整理します。削除前に、ルールやポリシーがその名前を参照していないか確認してください。読み込みの基本操作ははじめにを、アプリの購入と既存情報の違いはよくある質問を参照してください。このページでは利用者がすでに持っている情報の扱い方を説明し、サブスクリプションの提供元は推奨しません。

速度低下や頻繁な停止：発生する段階から原因を探る

まず、どの段階で遅いのかを整理します。タップ後に長く反応しない、最初の画面は表示されるが画像の読み込みが遅い、再生中に何度も止まる、大きなデータの転送が途中で止まるなど、症状によって確認方法は異なります。遅延テストの値が小さくても、継続的な転送速度が高いとは限りません。Webページの読み込みが一度遅かっただけなら、サービス側の応答が遅い可能性もあります。同じ対象で繰り返し確認してから、すべてのリクエストに影響する問題か判断してください。

名前解決・接続確立・データ転送を切り分ける

最初のアクセスは遅く、直後の再アクセスは速い場合、DNSキャッシュ、接続の再利用、対象サービスのキャッシュなどが関係している可能性があります。それだけでプロキシの速度を判断しないでください。異なるサービスの一般的なWebページを二つ選び、初回と再アクセスの状態を記録します。同じネットワークとサーバーを使い、各回の間に再接続したかどうかも記録してください。条件が明確であれば、待ち時間が接続確立前に発生したのか、データ転送開始後なのかを判断しやすくなります。

ページのタイトルはすぐ表示されるのに画像やメディアの読み込みが続く場合は、関連するリソースが別のポリシーで処理されていないか確認してください。一つのWebページでも、メインのドメインとリソースのドメインで経路が異なる場合があります。メインのドメインにルールを追加しただけで、すべてのコンテンツがプロキシ経由になったとは限りません。まず失敗したリソースのリクエスト先を確認し、必要最小限のルールを調整します。経路が同じだと確認できてから、サーバーと現在のネットワークで継続的な転送を比較してください。

写真の同期、大きなファイルのアップロード、その他ネットワークを継続的に使用するタスクを一時停止してください。アップロードで帯域を使い切ると、通常のWebページも遅くなることがあります。この状態でサーバーを何度も切り替えても、デバイス内の通信競合は解消しません。まず一台のデバイスで一つのタスクだけを実行し、その後でほかのタスクを一つずつ再開してください。複数の速度テストを同時に実行しないでください。互いに帯域を使い、結果の判断が難しくなります。

ネットワークの切り替えと転送条件を確認

Wi-Fiの電波が強くても、外部への接続が安定しているとは限りません。デバイスを動かさず、現在のネットワークを確認してから、利用可能な別のネットワークと比較します。特定の場所やWi-Fiだけで停止する場合は、そのネットワークの接続品質、認証状態、他のデバイスの負荷を確認してください。移動中にWi-Fiとモバイル通信が何度も切り替わると、既存の接続が切断され、再確立される場合があります。静止した状態のテストと移動中のテストを分けて記録してください。

特定のネットワークで一部のプロトコルだけに問題が起きる場合は、そのプロトコルが必要とする転送条件を確認してください。UDPを使うプロトコルでは、現在のネットワークで実際に利用できるか確認します。別のテストで応答があっても、すべての転送方式が使えるとは限りません。比較には、自分が持っている設定済みの情報を使用してください。テストのためにポート、認証、転送方式を推測しないでください。「同じネットワークで異なるプロトコル」を比較する場合も、別々のサーバーを使っていないか記録してください。

小さなリクエストは正常でも、大きなリクエストが何度も停止する場合は、アドレス、ルール、DNS、認証を確認した後で、経路やMTUに関する問題を調べられます。MTUは万能の速度向上スイッチではありません。値が小さすぎるとオーバーヘッドが増え、大きすぎると一部の経路で分割やパケット処理の問題が起きる場合があります。利用中のプロトコルと設定が対応している場合に限り、元の値を記録してから、資料の推奨に沿って一項目ずつテストしてください。転送関連の設定を複数同時に変更しないでください。

テストを絞り、実行可能な結論を得る

サーバーを比較する際は、ネットワーク、対象、リクエストの種類、おおよそのテスト時間を揃えてください。サーバーごとに接続先の地域やサービス入口が異なると、結果を完全に比較できないことがあります。目的は最小の数値を探すことではなく、利用中の設定で実際のリクエストを安定して完了できるか確認することです。短時間に何度も切り替えると、接続の再利用条件が変わり、停止が以前からの問題か判断しにくくなります。

同じ条件で他の対象には問題がないのに、一つだけ遅い場合は、対象サービス自体やリソースの経路を先に確認してください。すべての対象が遅い場合は、ローカルネットワークと選択中のサーバーを改めて確認します。利用中のサービスには、独自の状態、使用量、同時接続数の制限がある場合があります。自分のサービス情報で確認し、アプリの画面だけから判断しないでください。アプリの買い切り購入とサーバー側の転送条件は別のものです。購入状態に問題がなくても、リモート側の通信経路が常に同じとは限りません。

テスト後は、一時的なモード、テスト用ルール、転送パラメーターを元に戻し、根拠が確認できた変更だけを残します。有効な記録には、「どの条件で遅くなったか」「どの比較条件で復旧したか」「どの項目を変更したか」を記載してください。現在のネットワークと対象を記録せず、一度のテスト結果だけを残しても、後から再現して確認するのは困難です。初回接続がまだ確認できていない場合は、初回接続の確認方法を先に読み、基本状態が分からないまま速度調整を始めないでください。

DNSの問題：名前解決の結果とリクエスト経路を確認

DNSは、ドメイン名を後続の接続に必要なアドレスへ変換します。ドメイン名でアクセスできない原因が名前解決にある場合もありますが、証明書エラー、接続拒否、対象サービスからの異常な応答は、名前解決に成功した後に起きることもあります。まずエラーや記録に名前解決の失敗があるか確認してから、DNSを変更するか判断してください。IPアドレスに応答があるからといって、ドメインの名前解決に問題があるとは限りません。IPアドレスへ直接接続すると、対象のホスト名が不足したり、別の証明書や異なるサービスに接続されたりする場合があります。

基本ネットワークと設定の参照元を確認

接続を切断した状態で通常のドメインにアクセスし、次に現在の設定で同じ対象をテストします。基本ネットワークで名前解決できない場合は、Wi-Fi認証、ネットワーク接続状態、システム内の既存のDNS設定を確認してください。基本ネットワークでは正常で、有効にした後だけ失敗する場合は、現在のConfigとアプリの名前解決設定を重点的に確認します。設定ファイル由来の項目と後から手動で追加した項目を記録してください。一つの設定場所だけ変更しても、別の場所の設定が影響する場合があります。

入力した名前解決先の形式が、選択した方式に合っているか確認してください。通常のサーバーアドレスと暗号化された名前解決のエンドポイントは、自由に置き換えられる文字列ではありません。完全なエンドポイントが必要な設定にドメイン名だけを入力するとパスが不足することがあります。逆に、アドレスだけを受け付ける項目に完全なURLを入力しても失敗します。画面の説明と自分の設定資料に従い、異なる例から一部ずつ取り出して新しいアドレスを作らないでください。

暗号化された名前解決でもネットワーク接続が必要です。エンドポイントにドメイン名を使う場合は、まずそのエンドポイントのアドレスをどう解決するかも関係します。名前解決リクエストがプロキシに依存し、プロキシサーバーのアドレスも同じ未使用の名前解決経路に依存していると、起動時の依存関係が発生する場合があります。「最初にどの名前を解決するか」「リクエストがどの経路を通るか」「その経路がすでに使えるか」を明確にしてください。名前解決先を追加し続けても、依存関係が解決するとは限りません。

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

ドメインルールは宛先名を基準に判定し、アドレスルールはIP範囲を基準に判定します。アドレスによる判定では、先に名前解決が必要になる場合があります。ルールを確認するときは、リクエストの情報、名前解決の結果、最終的なポリシーを併せて確認してください。GEOIPをファイル内のどこかに置けばすべてのドメインルールを代替できる、とは考えないでください。ルールの順序は引き続き重要です。先に一致した項目によって、後続のルールが同じリクエストを処理できなくなる場合があります。

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

この設定例は、ドメイン、地理情報に基づくアドレスルール、フォールバックの順序を示すもので、すべてのネットワークに適した完全な設定ではありません。GEOIPの判定は、使用するデータと実際に解決されたアドレスに関係します。Webサイトの内容やアカウントの所属地域を判定するものではありません。変更前に元のファイルを保存し、PROXYで使用するサーバーを確認してください。一つのドメインに例外が必要なだけなら、対象範囲を明確にしたルールを優先し、すべてのリクエストのフォールバック先を変更しないでください。

同じドメインから複数のアドレスが返される場合や、IPv4とIPv6の両方が返される場合があります。一部のネットワークまたは対象だけで失敗する場合は、現在のネットワークで該当するアドレスファミリーに実際に到達できるか、失敗した接続でどのアドレスが使われたか確認してください。IPv6を無効にすることを決まった解決策にしないでください。記録を取るための一時的な比較としてのみ使い、テスト後は実際のネットワーク対応状況に基づいて元の設定を維持するか判断します。

キャッシュを消去して新しいリクエストを確認

名前解決の設定を変更した後も、古いキャッシュや確立済みの接続がテストに影響することがあります。まずアプリで利用できるキャッシュ消去操作を使ってください。該当する操作が見当たらない場合は、接続を停止して再接続し、対象アプリを完全に終了してから再び開きます。一つのドメインの状態を消去するために、アプリのデータをすべて削除しないでください。テストのたびに失敗したリクエストを新たに実行し、画面に残っている古いエラーページだけを見て判断しないようにします。

Webページの一部だけが読み込めない場合は、メインドメイン、リソースのドメイン、認証用ドメインをそれぞれ確認してください。異なる名前解決結果やルールが使われる場合があり、一つのドメインが復旧してもページ全体の通信が正常になったとは限りません。アプリが独自の名前解決方法を使う場合、通常のシステムリクエストとは異なる動作になることがあります。確認できる記録を基に原因を探し、一つのDNS設定を変更すればすべてのアプリの名前解決が変わるとは考えないでください。

この章の確認完了条件は、対象ドメインから有効な結果を取得でき、後続の接続が想定した経路を通り、再接続後も成功することです。名前解決に成功してもハンドシェイクに失敗する場合は、プロトコルの章に戻ってください。Configだけが失敗する場合は、ルールの章に戻ります。使用する名前解決方式と変更理由を保存しておけば、ネットワークを切り替えたときに、環境の変化なのか設定による依存関係の再発なのかを判断しやすくなります。

バッテリー消費やアップデート後の問題：比較できる基準を整える

バッテリー消費とアップデートの問題を調べるには、変更前後の条件を比較できる状態にする必要があります。異常が始まる前に何が変わったかを記録してください。アプリのアップデート、システムのアップデート、サブスクリプションの更新、Configの変更、ネットワークの変更、自動接続条件の追加などが考えられます。同じ日に複数の変更があっても、どれか一つが原因とは限りません。現在の状態を残してバックアップを取り、すぐにアプリを削除しないでください。ローカル情報を失う可能性があり、比較に使える元の状態も失われます。

バックグラウンド通信と接続の再試行を切り分ける

システムのバッテリー使用状況で該当する時間帯を確認し、画面の使用、メディア再生、ファイル同期、ネットワークの切り替えも記録します。VPNアプリはデバイスのネットワーク処理に関わるため、統計の表示を「すべての通信をアプリが自発的に開始した」と単純に解釈しないでください。他のアプリがアップロードやダウンロードを続けていれば、ネットワーク処理も継続します。比較する前に大量の通信を一時停止し、画面の使用状況やネットワーク条件が似ている状態で確認してください。まったく異なる使い方の結果を直接比較しないでください。

タイムアウトの繰り返しや自動再接続も、ネットワーク活動を増やす場合があります。特定のサーバーだけが使えないのか、電波の弱い場所でネットワークが何度も切り替わっているのか確認してください。自分が持っている、利用可能と確認済みの設定に一時的に切り替え、再試行が減るか観察します。接続が安定した後にバッテリーの状態も改善する場合は、失敗している項目を引き続き調べてください。問題のあるサーバーを残したまま、別のスイッチで隠そうとしないでください。バッテリー残量だけでなく、再試行とネットワーク変化が起きた時刻を記録してください。

On Demandを一時的にオフにし、手動接続と手動切断が安定して維持できるか確認します。自動接続の条件が頻繁に働くと、接続、切断、再試行を繰り返す場合があります。確認後は条件を一つずつ戻し、一度にすべてを有効にしないでください。継続的な診断記録や頻繁な手動テストを有効にしている場合は、必要な情報を得た後で停止します。診断そのものが活動量を増やすため、負荷を発生させ続けながらアイドル時の状態を評価しないでください。

アップデート後に残っている設定を確認

アプリのアップデート後は、Homeで選択中の項目、Global Routing、現在のConfig、On Demandの条件を確認し、接続を再確立してください。リストに項目があるだけでは、デフォルト選択が維持されているとは限りません。ファイル名が同じでも、有効状態が同じとは限りません。アップデート前の記録に基づいて基準状態を戻し、確認済みのサーバー一つと通常のWebページ一つで検証します。アクセスできる場合は、独自ルールや他の設定を一つずつ戻してください。すべての問題をアップデートのせいと決めつけないようにします。

同時期にサブスクリプションも更新した場合は、サーバーの内容が変わったか確認してください。システムも更新した場合は、VPNの許可と他のネットワーク構成の状態を再確認します。時期が近いことは手掛かりにはなりますが、比較による確認の代わりにはなりません。既存の接続が再確立されていないだけの問題なら、通常の手順で切断して再接続し、対象アプリを再起動することで確認できます。デバイスのシステム状態が継続的に同期しない場合は、接続スイッチの章を参照してください。すべての設定をすぐに作り直す必要はありません。

アップデートはApp Storeから行ってください。アプリの確認には、デベロッパー名のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を使用します。システム要件はApp Storeの製品ページの記載を確認してください。再インストールが必要な場合は、購入済みアプリの復元方法を先に確認します。購入履歴はアプリを再取得する資格を復元するためのもので、ローカルのサーバー、ルールファイル、独自パラメーターが完全にバックアップされていることを意味しません。

バックアップ・復元・問題の記録

バックアップでは、Config、サーバー情報、その他保存が必要な設定をそれぞれ確認してください。ルールファイルを一つ書き出しただけで、すべて保存できたと考えないでください。バックアップを開いて読み取れることを確認し、各ファイルの用途と復元方法を把握しておきます。認証情報を含むファイルは、管理された安全な場所に保存してください。公開共有用のフォルダーに置かないでください。iCloudを使う場合は、スイッチがオンという表示だけでなく、実際に同期が完了したことを確認してから、元のデバイスの情報を削除します。

再インストールが必要な場合は、まずバックアップと購入に使ったアカウントを確認し、App Storeの購入・デバイス適用条件に従って復元します。初回の復元では、必要最小限の情報だけを読み込み、接続を確認してから他の設定を一つずつ戻してください。特定のファイルを戻した直後に問題が再発する場合は、そのファイルと関連する設定を優先して調べます。具体的な移行手順は設定のバックアップと新しい端末への復元を参照してください。

問題が引き続き再現する場合は、操作手順、現在のネットワーク、失敗した段階、特定のプロトコルだけに影響するか、どの比較テストが成功したかをまとめます。共有する前に、サブスクリプションURL、認証情報、個人的なリクエスト内容を隠してください。バッテリー消費の記録には実際の使用状況を、アップデートの問題には同時期に変更した設定も記載します。復旧後は一時的な診断を終了し、確認済みのバックアップを保管してください。次に環境が変わったときに戻れる状態を残しておきます。

iPadでの確認：アカウント・ネットワーク・設定の違いを切り分ける

iPhoneでは正常でiPadだけ問題が起きても、すぐに機種の違いが原因だと決めつけないでください。二台のデバイスで、ネットワーク、購入アカウント、デフォルトサーバー、Config、名前解決設定が異なる場合があります。まず比較対象を、アプリの取得資格、アプリの起動、接続の確立、実際のアクセスのどれにするか確認してください。一度に一段階だけ比較し、正常なデバイスを基準にします。ただし、バックアップを取らずに、もう一方のデバイス固有の設定を上書きしないでください。

アプリの取得と許可の状態を確認

iPadでもアプリの取得先はApp Storeです。以前に購入している場合は、現在App Storeでの購入に使用しているApple IDが購入時の記録に対応しているか確認し、購入済み項目の状態を確認してください。デバイスのiCloudへのサインインに使うアカウントと、App Storeでの購入に使うアカウントは別の場合があります。実際の購入記録を基準にしてください。システム要件、購入の適用条件、ファミリー共有の条件はApp Storeの製品ページの記載を確認してください。別のデバイスにインストールできたことだけで判断しないでください。

アプリを取得できたら、iPad自身のVPN許可も確認します。別のデバイスで許可済みでも、このiPadで構成の追加が許可されているとは限りません。初回接続時にシステムのダイアログを確認し、デバイス認証を完了してください。管理対象のiPadでは、組織のポリシーで該当するネットワーク構成が許可されているかも確認します。スイッチを維持できない場合は第1章を参照してください。購入の復元でシステムの許可を代替したり、許可の問題をサブスクリプション形式の問題と混同したりしないでください。

アプリの画面は、ウインドウのサイズ、縦横の向き、システムの表示方法に応じて変わる場合があります。Home、Config、Settingsを確認するときは、実際に開いているページと現在の選択項目を確認し、別のデバイスのボタン位置に機械的に当てはめないでください。編集後は一覧に戻り、もう一度開いて保存内容を確認します。特に画面分割中は、まだ確定していない編集内容が表示されたままになっていないか確認してください。

二台のデバイスで最小限の比較を行う

まず二台とも同じ利用可能なWi-Fiに接続し、同じサーバー、同じGlobal Routing、同じWebページを使って比較します。一方をモバイル通信、もう一方をWi-Fiに接続した状態で、接続結果をそのまま比較しないでください。同じネットワーク名でも、それぞれでWeb認証が必要か確認します。iPadで接続を切断した状態でも基本ネットワークに問題がある場合は、アプリ内の確認に進む前にネットワーク接続を直してください。

iPadでインターネット共有を利用している場合は、共有元デバイスのネットワークと接続状態も確認し、iPadで通常のWebページを開いて基本的なアクセスをテストしてください。インターネット共有でネットワークに接続できても、iPadが共有元デバイスのすべてのルールや接続設定を引き継ぐとは限りません。iPad上で実際に確立された接続とリクエストの記録を基準にしてください。共有元デバイスの状態アイコンだけで、iPadの通信経路を判断しないでください。

Type、Address、Port、認証項目、TLS関連項目を一つずつ比較し、その後に現在のConfigとDNSを比較します。同期の完了と接続の成功は別の問題です。両方のデバイスにファイルが表示されても、実際に同じファイルが有効とは限りません。サーバー名が同じでも内容が異なる場合は、各項目を照合してください。内容が同じなのに結果が異なる場合は、システムのネットワーク構成、アドレスファミリーへの到達性、現在の接続条件を比較します。

バックグラウンド・スリープ・復帰後の接続を確認

画面ロック中や復帰後に限って問題が起きる場合は、スリープ前後のWi-Fi状態、ネットワークの切り替え、On Demandの動作を記録してください。まず固定したネットワークで手動接続を行って問題を再現し、その後にロックと復帰の操作を加えます。アプリの画面に状態変化が継続して表示されないことだけで、トンネルが停止したと判断しないでください。実際のリクエストとシステムの状態を併せて確認します。反対に、システム上で接続中と表示されても、スリープ前のリモート接続がすべて有効とは限りません。

復帰後の最初のリクエストは失敗するものの、再接続後に成功する場合は、古い接続が適切に再確立されていないのか、現在のネットワークが変わったのか確認してください。まず対象アプリを完全に終了して再起動し、次に接続を切断して作り直します。どの手順で復旧したかをそれぞれ記録してください。手動操作で安定したことを確認してから、On Demandの条件を変更します。自動再接続を常時有効にして長期的な解決策にしないでください。電波が弱い、認証が期限切れ、特定サーバーが継続的に使えないといった問題を隠す可能性があります。

設定を移行した後は、Connectivity Testを実行し、実際のWebページへのアクセスを確認してから、普段使うアプリもテストしてください。安定したことを確認したら、このiPadで確認済みのバックアップを保管します。すべてのデバイスで設定を完全に同じにする必要はありません。接続先ネットワークが異なる場合は、根拠に基づいて調整が必要なことがあります。アプリの取得先を改めて確認する場合はiPadでのアプリ取得方法を、接続を最初から設定する場合ははじめにに戻って基本手順を進めてください。