Shadowrocketのトラブル対処

まず、このサイトのダウンロードページからApp Storeの製品ページを開き、アプリIDが932747118であることを確認します。次に、現在のアカウントのストアでアプリが提供されているか確認してください。検索結果に表示されるかどうかだけでは、入手できるか判断できません。ストアの国または地域を確認するには、システムのSettingsからApple AccountのMedia & Purchasesを開き、View AccountでCountry/Regionを確認します。項目名はシステム言語によって異なる場合があります。国または地域を変更する前に、残高、サブスクリプション、支払い方法に関するAppleの案内を確認してください。

次の3点を確認してください。デベロッパがShadow Launch Technology Limitedであること、アイコンがこのサイトのヘッダーにある公式アイコンと一致すること、製品ページのURLにid932747118が含まれることです。名前が似ているか、検索結果のどこに表示されるかだけで判断しないでください。詳細ページで価格と互換性も確認し、システム要件はApp Storeの表示に従ってください。このサイトのダウンロードページに情報をまとめています。確認後、App Storeで購入してください。

購入時に使ったアカウントでApp Storeにサインインし、アカウントの購入済みアイテムからShadowrocketを探してください。復元の対象であれば、再ダウンロードできます。価格が表示される場合は、購入履歴、現在のサインインアカウント、ストアの国または地域を確認し、すぐに再購入しないでください。リストの項目名はシステムのバージョンによって異なる場合があります。アプリの再取得と設定の復元は別の作業です。サブスクリプション、サーバー情報、設定ファイルは別途バックアップしてください。復元の条件はApp Storeの表示に従ってください。

アプリの買い切り購入と、接続サービスの契約は別です。購入で得られるのはShadowrocketを使用する権利であり、接続にはユーザー自身が用意したサブスクリプションまたはサーバー情報が必要です。インポート後、パラメータを確認し、サーバーを選択して、システムの許可を完了してください。米国ストアの価格は2.99ドルですが、最新の価格はストアページで確認してください。ほかのストアでは現地通貨で表示されます。このサイトではサーバーやサブスクリプションを提供・販売・推奨していません。アプリの購入と既存の接続サービスは別々に管理してください。

Shadowrocketは、iPadでも同じApp Store製品ページから入手できます。購入時に使ったアカウントでサインインし、ストアにダウンロードボタンと価格のどちらが表示されるか確認してください。デバイスの互換性、システム要件、ユニバーサル購入の対象かどうかはApp Storeの表示に従ってください。iPadはiPhoneと画面の表示領域が異なりますが、使用中のサーバー、Config、接続の許可はそれぞれ確認が必要です。購入資格があっても設定が自動で同期されるとは限りません。機種変更後は情報が揃っているか確認してください。

まず、接続をオフにした状態でデバイスがインターネットに接続できることを確認し、ユーザー自身が用意したサブスクリプションまたはサーバー情報を準備します。Homeで情報をインポートするか、Add Serverでパラメータを入力します。項目が追加されたことを確認して使用するサーバーを選び、Global Routingを確認してください。初めて接続をオンにするときは、システムの案内に従ってVPN構成を追加します。最後に、特定のWebページにアクセスして動作を確認してください。まず1台のサーバーで接続を確認してからルールを調整すると、問題が発生した手順を特定しやすくなります。

これはアプリがVPN構成を作成することをシステムに許可する手順で、購入が完了したかどうかとは別のものです。直前に開いたShadowrocketからの通知であることを確認し、画面の案内に従って許可とデバイスの認証を完了してから、アプリに戻って接続状態を確認してください。以前にキャンセルした場合は、接続を再度オンにできます。デバイスが組織によって管理されている場合、構成の作成が制限されることがあります。システムの管理設定を確認し、デバイス管理者に問い合わせてください。ほかの目的で使っている構成をむやみに削除しないでください。

まず、アプリまたはシステムに具体的なエラーが表示されているか確認し、有効なサーバーが選択され、VPN構成の使用が許可されていることを確認してください。ほかのVPN接続が使用中でないか、デバイス管理によって構成が制限されていないかも確認します。次に接続をオフにし、アプリを開き直して、現在選択しているサーバーだけを試してください。それでも失敗する場合は、エラーの内容、発生した手順、接続中のネットワークの種類を記録します。ネットワークのリセット、構成の削除、複数のパラメータ変更を同時に行うと、どの変更が影響したのか分からなくなるため避けてください。

Configは現在の設定ファイルのルールに従って通信を振り分けます。Proxyは対象の通信に選択中のプロキシポリシーを適用し、Directは直接接続します。ルールに基づいて振り分ける場合はConfigを選び、Configで実際に有効になっているファイルを確認してください。問題を調べるときは、同じ接続先を異なるモードで試し、結果を記録してから通常の設定に戻します。Global Routingとルール内のPROXY、DIRECTは異なる階層です。個別のルールだけを見て、すべての通信先を判断することはできません。

まず、英語の画面表示を目印にしてください。Homeではサーバーと接続状態、Add Serverではサーバーの追加、Configでは設定ファイルの管理、Settingsでは設定項目、Global Routingでは接続モードを確認できます。公式マニュアルではこれらの画面名を英語のまま記載し、用途を説明しています。デバイスやシステム設定によって表示が異なる場合がありますが、言語の違いを理由にアプリを再インストールする必要はありません。項目が見つからないときは、現在の画面とアプリ内で実際に選べる項目を確認してから、手順を照らし合わせてください。

貼り付けたものが、ユーザー自身の完全なサブスクリプションURLであり、アカウント管理ページや説明ページではないことを確認してください。前後の空白、改行、パラメータの欠落も確認します。次に、現在のネットワークからURLにアクセスできるか、サブスクリプションが有効か、応答形式がアプリのインポート方法に対応しているかを確認してください。エラーが出た場合は、ステータスやエラー内容を記録し、続けて何度も送信しないでください。URLにアクセス認証情報が含まれることがあります。確認時は機密部分を隠し、URL全体が見えるスクリーンショットを公開しないでください。

まずプロトコルの種類を確認し、サーバーアドレス、ポート、プロトコルで必要となる認証情報を順に確認してください。手元の情報にTLS、Server Name、転送方式、パスが含まれる場合は、推測せず原文どおり入力します。表示名は識別用で、接続可否には影響しません。アドレス欄に説明文を混ぜないでください。一度に修正するのは1項目にして、保存してから接続を試します。デバイスの日付と時刻が正しいことを確認し、照合用に元の情報を保管してください。パスワードなどの認証情報は公開しないでください。

QRコードに含まれているのが通常のWebページではなく、ユーザー自身のサーバーまたはサブスクリプション情報であることを確認してください。Scan QR Codeを使うときは、カメラの使用許可、画像の鮮明さ、QRコードの端まで写っているかを確認します。読み取りに成功しても、項目を開いてプロトコルと必須項目を確認してください。読み取り成功が設定の正しさを保証するわけではありません。元の資料にテキスト情報もある場合は、対応するインポート方法を使うか、Add Serverで項目を入力し、重要な値を照合してください。同じ不完全な画像を繰り返し読み取るのは避けましょう。

更新前に、選択中のサーバーとサブスクリプショングループを記録し、必要に応じて設定をバックアップしてください。更新後、項目が元のサブスクリプションに属しているか確認し、選択していた項目が削除、改名、置換されていないか調べます。名前が変わっても、接続情報が同じとは限りません。更新に失敗した場合は、何度も削除して追加し直すのではなく、エラー表示とURLの有効性を確認してください。サブスクリプションの内容とConfigファイルは別々に管理されています。更新後は有効な項目を選び直してテストし、以前の選択が維持されていると決めつけないでください。

サーバー項目には、接続に必要なプロトコルと認証パラメータが保存されます。サブスクリプションは、ユーザー自身のサーバー情報をまとめて取得または更新するために使います。Configファイルには、ルールやDNSなどの設定動作が記述されています。サブスクリプションのインポートに成功しても、適切なConfigが有効になったとは限りません。Configを切り替えても、サーバーの認証情報は更新されません。問題を調べる際は、接続パラメータとルール動作のどちらに関係するかを特定してから、該当箇所を変更してください。重要な設定は個別にバックアップし、復元後に有効なファイルとサーバーを確認してください。

まず接続をオフにしてローカルネットワークを確認し、次に同じ接続先へ接続をオンにしてアクセスします。これにより、基本のネットワークとプロキシ経路の問題を切り分けられます。その後、現在のサーバー、Global Routing、実際に有効なConfigを確認し、接続先へのリクエストに対応するルールとエラー情報を調べてください。一部のドメインだけ失敗する場合は、ルールとDNSを優先して確認します。複数の接続先で失敗する場合は、サーバーのパラメータとネットワーク環境を調べてください。一度に変更するのは1項目にし、変更前後の結果を記録します。設定全体をすぐに置き換えないでください。

Connectivity Testの結果で分かるのは、その時点で選択した方法によるテストが完了したことだけです。DNSによる名前解決、認証、ルールの選択、接続先へのアクセスがすべて正しいとは限りません。まずテスト対象と現在選択中のサーバーが一致していることを確認し、失敗したWebページへの実際のリクエストを調べてください。接続テストに結果が出てもドメインにアクセスできない場合は、DNSを確認します。特定の接続先だけで問題が起きる場合は、ルールのポリシーと接続先自体の状態を確認してください。遅延の数値は手がかりとして使い、唯一の判断材料にしないでください。

まずGlobal RoutingがConfigになっていることと、編集したファイルではなく実際に使用中の設定ファイルを確認してください。ルールは上から順に評価され、条件に一致すると対応するポリシーが適用されます。具体的な条件は前方に置き、FINALは[Rule]セクションの最後に置きます。対象がより広いDOMAIN-SUFFIX、GEOIP、IP-CIDRの条件に先に一致していないか確認し、PROXY、DIRECT、REJECTが意図した動作かも調べてください。変更後は新しいリクエストを発行して確認し、既存の接続だけを見て判断しないでください。

まず、複数のドメインで失敗するのか、特定のドメインだけで問題が起きるのかを確認します。次に、現在のConfigの[General]セクションと、アプリ内で実際に有効なDNS設定を確認してください。到達できないカスタムDNSアドレス、Hostの上書き、DNSリクエストに影響するルールがないか調べます。元の設定をバックアップしてから、DNS関連の項目を1つだけ変更して再テストしてください。DNS over HTTPSを使う場合も、DNSサービスのアドレス自体に到達できる必要があります。接続成功や一度の遅延値だけで、DNSが正常だと判断しないでください。

まずシステムのバッテリー設定で該当時間帯の使用量を確認し、画面の使用状況、ネットワーク環境、実際の通信量も比較してください。消費量の割合だけでは、アプリが単独で余分な電力を消費したとは判断できません。次に、On Demandの条件が頻繁に接続を開始していないか、ネットワークの切り替わりで再接続を繰り返していないか確認します。似た使用状況でオンとオフを比較し、必要な条件を設定してください。On Demandは必要に応じて接続を制御する機能で、必ず節電できるとは限りません。通常と異なるネットワーク通信の確認に代わるものでもありません。