Official Manual · Troubleshooting

Shadowrocket
トラブル対処ガイド

まず問題が発生している段階を特定してから、設定を変更してください。このページは症状別の公式マニュアルです。初回設定の場合は、まず使い方マニュアルのクイックスタートを完了し、その後、該当する章で問題を解決してください。ご自身が用意したサブスクリプションまたはサーバー情報があることを前提としており、接続先やサブスクリプションの提供、販売、推奨は行っていません。

アプリの買い切り購入と接続サービスの契約は別のものです。アプリの購入、サーバーサービス、設定ファイルはそれぞれ独立しています。購入や再インストールについてはApp Storeからの正規入手方法をご確認ください。短い質問と回答はよくある質問をご覧ください。システム要件はApp Storeの掲載内容をご確認ください。

Connection

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

まず「システムVPN構成が作成されていない」状態と、「構成は作成済みだが接続を維持できない」状態を区別します。前者はシステムの許可画面で止まり、後者はスイッチが一時的にオンになったあとオフになることがあります。スイッチの状態だけでサーバーの有効性を判断しないでください。スイッチが示すのは端末側の接続状態です。サーバー認証、ドメイン名の解決、実際の通信はそれぞれ別に確認する必要があります。まず、スイッチがオフに戻る前にダイアログが表示されたか、エラーが出たかを記録し、次の手順で確認してください。

システムの許可とデバイスの制限を確認する

初めて接続するとき、システムからVPN構成の追加を許可するよう求められる場合があります。要求元が使用中のShadowrocketであることを確認し、画面の案内に従って許可とデバイス認証を完了してください。そのときキャンセルした場合は、アプリに戻って接続をやり直します。スイッチを続けて何度もタップしないでください。システム設定で該当するVPN構成が存在するか確認します。メニュー名はシステムの表示によって異なるため、端末に表示される内容を確認してください。

許可画面が表示されない場合は、構成がすでに存在するか、別のVPNが接続中か、デバイスが管理ポリシーで制限されているかを確認します。学校や職場の管理下にあるデバイスでは、VPNの追加や変更が制限されている場合があります。この制限はサーバーを変更しても解決しないため、デバイスの管理者に権限を確認してください。システムによる制限とアプリのパラメータの誤りは別の問題です。まず前者を確認し、権限の問題を接続先の障害と誤認しないようにします。

Homeで選択中の項目と接続条件を確認する

Homeでサーバー項目が登録され、正しい項目が選択されていることを確認します。インポートしただけでは、使用可能な項目が選択されたことにはなりません。同じ名前の項目でも、アドレス、ポート、プロトコルが異なることがあります。選択中の項目を開き、ご自身が持つサーバー情報と一つずつ照合してください。スイッチの問題を調べている間に、パスワード、プロトコル、ルールファイルを同時に変更しないでください。接続が復旧しても、どの変更が有効だったのか判断できなくなります。

On Demandを一時的にオフにして手動接続すると、自動接続の条件と手動接続を切り分けられます。手動接続は安定し、画面ロック時やネットワーク切り替え後にだけ切断される場合は、そのときのネットワーク変化を記録してOn Demandの条件を確認します。手動接続でもすぐに失敗する場合は、システム構成、選択中の項目、エラーメッセージを確認してください。テスト後は本来の用途に合わせてOn Demandを戻し、一時的な無効化を恒久的な解決策にしないでください。

元に戻せる手順で構成の競合を解消する

まず、ほかのVPNを正常に切断してからShadowrocketを試します。システム設定とアプリの表示が一致しない場合は、接続をオフにしてHomeに戻り、アプリを開き直します。それでも一致しない場合は、端末を再起動して再確認してください。ネットワーク設定をすべて消去しないでください。ほかのVPN構成が職場や学校のネットワーク接続に必要な場合もあります。削除する前に用途と復元方法を確認してください。

問題がShadowrocketのシステムVPN構成に限られると確認できた場合にのみ、その構成を削除して再度許可することを検討します。操作前に必要なサーバー情報と設定ファイルを保存し、再インポートできることを確認してください。システムVPN構成を削除してもサーバー認証の問題は解決せず、バックアップの代わりにもなりません。再許可後にスイッチがオンのままでも通信できない場合は、次の章で実際の通信経路を確認してください。

この章の問題が解消したか確認する

復旧後、手動接続、通常の切断、実際のWebページへのアクセスをそれぞれ一度確認します。スイッチがオンのままでもサーバーへのリクエストが失敗する場合は、サーバーまたはルーティングの問題を調べます。システム構成の削除を繰り返さないでください。毎回同じ許可手順で失敗する場合は、システムに表示された文言を記録し、デバイスが管理対象かどうかも確認します。決まった条件で失敗しない場合は、ネットワークの切り替え、画面ロック、ほかのVPNの状態も記録してください。

さらに問い合わせる場合は、デバイスの種類、システム画面の表示内容、スイッチがオフに戻るタイミング、実施済みの確認事項を伝えてください。サーバーの認証情報一式は添付しないでください。許可前、トンネルの確立中、確立後のどの段階で問題が起きたかを記録すると、「スイッチが反応しない」という説明より原因を特定しやすくなります。初回接続の手順はクイックスタート、購入状況は購入済みアプリの復元方法で確認できます。

Routing

スイッチはオンだが、Webページやアプリに接続できない

まず基本ネットワークを確認してから、Global Routingの状態を比較します。システムにVPN接続中と表示されても、それは端末側の接続状態を示すだけです。各リクエストの名前解決、認証、通信が完了したことを保証するものではありません。普段正常にアクセスできるページを一つ選び、すべてのページが開けないのか、特定のドメインやアプリだけが失敗するのかを記録します。該当範囲によって確認箇所は異なるため、すぐにサーバー障害と決めつけないでください。

基本ネットワークと比較する

Shadowrocketを通常の手順で切断し、同じネットワークでテストページを開きます。それでも失敗する場合は、Wi-FiにWeb認証が必要か、モバイルデータ通信が利用できるか、アプリにネットワークアクセスが許可されているかを確認します。Wi-Fiに接続済みと表示されても、利用開始の確認が完了していないことがあります。まずネットワーク側の接続手順を済ませてからアプリを試してください。アプリの設定では、基本ネットワークのログインや認証を代替できません。

切断中にアクセスできるようになったら、Shadowrocketをオンにして同じページをもう一度確認します。比較の意味がなくなるため、ネットワークの切り替えとサーバー変更を同時に行わないでください。特定のアプリだけ失敗する場合は、アクセス先のドメイン、そのアプリ独自のネットワーク制限、ログイン時・コンテンツ読み込み時・バックグラウンド更新時のどこで失敗するかを確認します。ブラウザーで利用できても、アプリ内のすべての通信が同じ経路を通るとは限りません。

Global Routingの3つのモードを比較する

画面上の英語表記	日本語での意味	確認する内容
`Config`	Config	現在の設定ファイルのルールとポリシーに基づいて、リクエストの経路を判定します。
`Proxy`	Proxy	Proxy経由で接続した場合の結果を一時的に比較します。
`Direct`	Direct	クライアント接続中に、直接接続した場合の結果を比較します。

Proxyではアクセスでき、Configではできない場合は、正しい設定が選択されているか、該当ルールのポリシーが想定したサーバーを指定しているか、REJECTルールがないかを優先的に確認します。Directではアクセスでき、Proxyではできない場合は、サーバー情報またはサーバーから接続先までの経路を確認します。この比較だけで原因を確定することはできません。DNS、設定内の別の処理、接続先サービスの状態も結果に影響するため、リクエスト記録と照らし合わせてください。

キーワードだけでなくルールの順序を確認する

Configを開き、リスト内の似た名前の別ファイルではなく、実際に使用中のファイルを確認します。ルールは通常、記載順に評価され、マッチすると対応するポリシーが適用されます。広い範囲に適用されるルールが具体的なルールより前にあると、後者が評価されない場合があります。以下の例は順序を説明するためのものです。example.comは構文例のドメインであり、アクセス先として推奨するサービスでも、設定全体を置き換えるための内容でもありません。

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

この例では、まずexample.comのサフィックスを確認し、続いてGEOIPを判定し、最後にFINALで処理します。PROXYとDIRECTは意味が異なります。実際の設定で独自のポリシー名を使用している場合は、その名前が存在し、正しく参照されていることも確認してください。FINALがあるからといって、すべてのリクエストがそこに到達するとは限りません。前のルールが先にマッチする場合があります。IPベースのルールでは、どの段階でドメイン名が解決されるかも考慮してください。Webサイト名だけから最終的に適用されたルールを判断することはできません。

ルールの問題と接続先サービスの問題を切り分ける

利用可能な接続ログや診断情報で、失敗したリクエストのドメイン、ポリシー、エラーの種類を確認します。同じドメインが異なる経路でも同じサービスエラーを返す場合は、接続先サービス、アカウントのセッション、地域別の利用条件に原因がある可能性があります。トンネルの確立失敗とは限りません。Configの場合だけ失敗し、記録上も想定外のポリシーが適用されているなら、そのルールを優先して修正します。エラーを隠すためにConfig全体を常時Proxyにしないでください。

変更前に元のファイルを保存し、現在の症状を説明できる項目だけを一つ変更して、同じ接続先にアクセスします。確認後は日常の用途に合わせてConfigに戻し、ほかのよく使うページに影響がないか確認してください。設定の各セクションについては.confの構成ガイドをご覧ください。ルーティングが想定どおりでも名前解決に失敗する場合は、DNSの章に進み、同じルールを追加し続けないでください。

Server

サーバーがタイムアウトする、認証に失敗する、接続が不安定

まず、エラーが「サーバーに到達できない」ことを示すのか、「到達後にプロトコル処理を完了できない」ことを示すのか判断します。タイムアウトは、ある処理が制限時間内に完了しなかったことを意味し、サーバー停止を意味するとは限りません。認証エラーの場合は、認証情報とプロトコル設定を確認してください。Connectivity Testの結果が示すのは、そのテスト操作の範囲だけです。Webページへのアクセス、継続的な通信、すべてのプロトコル機能が正常であることを保証するものではありません。テスト結果と実際の接続エラーを合わせて確認します。

Add Serverの各項目を確認する

Homeで現在の項目を開き、ご自身が持つ元の情報と照らし合わせて、まずプロトコルの種類、サーバーアドレス、ポートを確認します。アドレスにWebページのパス、空白、余分な改行を含めないでください。ポートはサーバー側で指定された情報と一致させます。貼り付け後に、入力方法によって句読点が変わっていないかも確認してください。表示名は識別用のラベルにすぎません。名前が正しくても、実際のアドレスや認証情報が正しいとは限りません。

次に、認証項目を確認します。Shadowsocksではパスワードと暗号化方式の組み合わせが正しい必要があります。VMessやVLESSのIDなどの項目は、元の情報と一致しているか確認します。Trojanのパスワードも、別のプロトコルの項目と混同しないでください。Hysteria2、WireGuard、追加のトランスポート設定を含む項目は、手元の情報に従って一つずつ確認します。プロトコル名やポートが似ていても、種類を置き換えて接続できるとは限りません。

項目の種類	確認する内容	よくある誤解
基本情報	サーバーのホスト名、ポート、プロトコルの種類	項目名を実際のアドレスだと思い込む。
認証情報	パスワード、IDなどの識別情報、暗号化方式	インポートできたので認証も有効だと思い込む。
トランスポートとTLS	トランスポート方式、パス、Host、SNIなど、元の情報に含まれる設定	推測した値を元の情報の代わりに入力する。

トランスポートとTLSの設定の関係を保つ

サーバーアドレス、Host、SNIは異なる役割を持つ場合があり、同じ値を入力すればよいとは限りません。アドレスは接続先を指定し、関連するホスト名はトランスポートや証明書の検証に使われることがあります。パスもサーバー側で定められた設定の一部かもしれません。すべての項目をサーバーアドレスに統一しないでください。元の情報に記載のない項目は、経験だけで補わず、情報の提供元に正確な接続要件を確認します。

端末の日付や時刻が正しくないと、証明書の検証に影響することがあります。システム時刻を確認し、証明書に関連するエラーの原文も確認してください。サーバーとの識別情報が一致しない問題を、証明書の検証を恒常的に無効にして処理しないでください。設定の誤りを隠してしまいます。証明書名や有効性が元の情報と一致しない場合は、サーバー側に確認が必要です。クライアント側でパスワードを何度変更しても、証明書の問題は直らず、正しいサーバーに接続している証明にもなりません。

条件を一つずつ比較して原因を絞る

同じ項目と同じ設定を使い、利用可能なWi-Fiとモバイルネットワークでそれぞれテストします。一方のネットワークだけでタイムアウトする場合は、その接続環境に関連した問題の可能性があります。ただし、名前解決、ポートへの到達性、トランスポートのサポートは切り分けて確認する必要があります。両方で失敗する場合は、ご自身が持つ別の有効なサーバー情報と比較します。ほかの情報がない場合、新しい入手先を探す必要はありません。まず、現在のエラーと元の設定情報を照合してください。

特定のプロトコルやトランスポート方式だけが失敗する場合は、そのネットワークが必要な通信を許可しているか、サーバーが該当方式に対応しているかを確認します。MTU、接続タイムアウト、低レベルのオプションを最初にむやみに変更しないでください。設定を変えるだけでは、誤った認証情報は直りません。継続的な接続が切れる場合は、画面ロック、ネットワークの切り替え、サーバー側のセッション制限と同時に起きているかも記録します。

テスト結果の見方

Connectivity Testが成功しても、実際の接続先にアクセスしてリクエストが完了するか確認してください。テストの数値は、同じテスト方法と近い環境でのみ比較できます。失敗した場合は、どの段階でエラーになったかも確認します。テストは完了するのにWebページにアクセスできない場合は、Global RoutingとDNSを確認します。実際の接続で認証エラーが明示される場合は、遅延テストを繰り返すより先に認証情報の有効性を確認してください。

最後に、テストしたネットワーク、プロトコル、エラーの原文、発生したタイミング、確認済みの設定項目を簡潔に記録します。利用中のサービスの情報提供元に問い合わせる際は、ネットワークを変えても再現するか、特定の項目だけに起きるかを伝えます。パスワードやIDなどは隠してから送信してください。アカウントの状態、待ち受けポート、証明書の設定を確認できるのはサーバー側です。クライアント側の確認は、検証可能な設定と環境の事実までにとどめてください。

Subscribeの更新失敗、インポート後に項目が空、内容が違う

まず現在使える項目を残したまま、Subscribeへのアクセスと内容の解析を確認します。Subscribeの更新には、アドレスへのアクセス、認証、応答内容、クライアントによる識別が関係します。更新に失敗しても、登録済みのサーバーは引き続き使える場合があります。すぐにグループ全体を削除しないでください。クライアント接続とSubscribeの更新は別の機能です。サブスクリプションのアドレスが別のホストにあり、異なるアクセス条件を必要とする場合もあります。

アドレスが有効で、完全な状態か確認する

ご自身がすでに利用している情報源でサブスクリプションアドレスを確認し、コピー時にクエリ部分が欠けていないか、ピリオド、空白、改行が混入していないかを確認します。アドレス内の認証情報によって返される内容が決まることがあります。見た目を整えるために削除しないでください。サブスクリプションアドレスを再発行した場合は、以前のアドレスが無効になっている可能性があります。現在有効な情報を使い、古いアドレスの文字を適当に変更しないでください。

サブスクリプションアドレスは認証情報として扱ってください。公開のQ&A、スクリーンショット、共有ドキュメントに貼り付けたり、不要な相手に送ったりしないでください。問い合わせ時は、ホストへのアクセスエラーとステータス情報を伝えるだけで構いません。アドレスを公開してしまった場合は、利用中のサービスの管理手段で該当する認証情報を変更してください。ブラウザーのアドレス欄やシステムの共有プレビューに完全な内容が表示される場合もあるため、確認の前に情報が残る可能性を考慮します。

アクセスエラーと返された内容の問題を分けて確認する

更新時に接続タイムアウト、名前解決の失敗、証明書エラーが発生する場合は、ネットワークとDNSの章を参照してSubscribeのホストを確認します。認証やアクセス権限に関するエラーが明示される場合は、元の情報でSubscribeがまだ有効か確認してください。Webページにアクセスできても、Subscribeのホストにアクセスできるとは限りません。Subscribeのホストに接続できても、クライアントが必要とする内容が返されるとは限りません。

返される内容がサーバー一覧ではなく、ログインページ、エラー説明、別の形式の場合があります。更新が完了したのに項目が追加されない場合は、元のサービスが提供する形式がShadowrocketに適合しているか、応答が空でないかを確認します。Webページのテキストをサーバー情報として取り込むために、プロトコルの種類を変更しないでください。リダイレクト、アカウント状態の変更、形式の変更により、同じアドレスから異なる内容が返されることがあります。

SubscribeとConfigの役割を区別する

サーバーのサブスクリプションは主にサーバー項目の提供や更新に使い、Configの設定ファイルはルールや関連設定に使います。両者には関係がありますが、互いに置き換えることはできません。サーバー一覧をインポートしても、正しい振り分けルールが設定されたことにはなりません。.confファイルを読み込んでも、認証情報が有効になるわけではありません。手元の情報に両方のアドレスがある場合は、それぞれの用途に従って操作してください。ConfigのアドレスをSubscribeに入力して、何度も試さないでください。

更新後に項目名や件数が変わった場合は、サービス提供元の現在の情報と照合します。サーバーの名前が変更または置き換えられ、以前選択していた項目がなくなっている場合があります。Homeで実際に選択されている項目を確認してください。カスタムポリシーが固定名を参照している場合は、参照先がまだ存在するかも確認します。リストが短くなっただけで解析エラーと判断せず、情報提供元から返された内容を先に確認してください。

更新リクエストの通信経路を確認する

通常のWebページにはアクセスできるのにSubscribeだけ更新に失敗する場合は、更新時の接続状態とSubscribeのホストへの経路を確認します。設定やConfigによって、このリクエストの送信経路が変わることがあります。まず通常どおり接続を切り、基本ネットワークで一度試します。次に、元の接続条件に戻して比較します。毎回同じアドレスを使い、ネットワークの切り替え、アドレスの変更、ルールの修正を同時に行わないでください。

一方の経路でしか内容を取得できない場合は、すべてのサーバー設定を変更するのではなく、Subscribeのホストへのアクセス条件を見直します。どちらの経路でも同じ権限エラーが返る場合は、情報提供元のアカウントやアドレスの有効性を確認する必要があるでしょう。リダイレクトや証明書の問題では、エラーの原文を残して情報提供元に確認します。検証要件をむやみに下げて失敗を隠さないでください。

更新後に接続を確認する

更新に成功したら、使用する項目を選び直し、Global RoutingとConfig内のポリシー参照を確認してから実際にアクセスします。Subscribeの更新成功が示すのはリストの更新だけで、その後の認証に失敗する可能性は残ります。リストの問題が解消しても接続がタイムアウトする場合は、サーバーの章に進んでください。インポート方法がわからない場合は使い方マニュアルを確認し、項目の削除で原因調査の代わりにしないでください。

Performance

遅延テストは正常なのに速度が遅い、または断続的に止まる

まず、速度の問題を再現できる操作として説明します。Webページの最初の表示が遅い、動画が繰り返しバッファリングする、ファイル転送が遅い、ネットワーク切り替え後に短時間止まる、といった症状はそれぞれ異なります。遅延、スループット、安定性も別々の指標です。小さなリクエストがすぐに完了しても、大容量の通信に十分な余裕があるとは限りません。Connectivity Testの数値が最も低い項目を選んで、すべての通信が速くなると判断しないでください。

同じ接続先で比較する

普段使うWebページまたはファイルを一つ選び、端末、ネットワーク、接続先を変えずに、直接接続時とProxy経由の状態をそれぞれ記録します。接続先にキャッシュや速度制限がある場合もあるため、連続して測定しても完全な比較にはならないことがあります。最終的な速度だけでなく、最初の応答が遅いのか、継続的な転送が遅いのか、失敗が繰り返されるかを確認する方が役立ちます。

テスト中はほかの大容量通信を一時停止し、システムのバックグラウンド同期、クラウドへの写真アップロード、同じWi-Fiを使うほかの端末の通信にも注意します。基本ネットワークが混雑している場合、Shadowrocketのルールを変更しても回線の帯域は増えません。モバイル通信の電波、Wi-Fiの干渉、ルーターの負荷、ネットワークの利用認証も結果に影響します。まず基本ネットワークでも同じ問題が起きるか確認してから、Proxy経由の通信を調べてください。

リクエストが想定したポリシーを使っているか確認する

Configモードでは、遅いリクエストに適用されたポリシーと実際のサーバーを確認します。Webページは複数のドメインを使うことがあります。メインページは直接接続でも、画像や動画などのリソースは別の経路を使う場合があります。「ページは開くが内容の表示が遅い」場合、すべてが同じリクエストとは限りません。メインドメインにルールを追加するだけで確認を終えず、遅いリソースの実際のドメインも調べてください。

ポリシーグループを使っている場合は、グループ名だけでなく実際に選択されている項目を確認します。Subscribeの更新後にグループ内の項目名や利用可能な状態が変わり、固定参照が無効になることがあります。一時的にProxyへ切り替えて比較することはできますが、検証後は通常のモードに戻してください。ProxyとConfigで結果に大きな差がある場合は、どの種類のリソースが異なる経路を通るか特定してからルール変更を検討します。

通信容量の不足と不安定な転送を区別する

接続は安定しているのにダウンロード速度が継続的に低い場合は、サーバーの容量、接続先サービスの制限、経路の混雑が関係している可能性があります。速度が大きく変動して再試行も頻発する場合は、接続の切断、ネットワークの切り替え、エラーの種類を記録してください。同じ接続先でご自身が持つ別のサーバー情報と比較すれば、サーバーに関連する要因を絞れますが、一度のテストだけで特定のプロトコルが原因と決めつけないでください。テスト時間帯によって混雑状況も変わります。

同じサーバーが特定のネットワークでのみ止まる場合は、そのネットワークが使用中のトランスポート方式に対応しているかを確認します。接続でUDPを使う場合は、そのネットワークが該当する通信を許可しているかも確認してください。MTUを根拠なく小さくしたり、すべてのタイムアウトを延長したり、複数の詳細設定を一度に変更したりしないでください。明確な根拠のない変更は、一時的な復旧を安定した解決と誤認させる原因になります。

不要な処理負荷を確認する

複雑な設定に含まれる追加処理が、リクエストの負荷を高めることがあります。用途を把握しているURL Rewrite、スクリプト、HTTPS関連の処理を有効にしている場合は、バックアップを取ってから一度に一種類だけ停止し、同じ接続先で比較します。速度改善のために見知らぬ設定を読み込んだり、内容を理解していないシステム証明書を削除したりしないでください。まず用途が明らかな設定で基準を作り、追加処理が症状に関係するか確認します。

端末の発熱、低電力モード、アプリによるリソース読み込みも、測定結果に影響します。複数のテストを長時間続けると端末の温度が上がり、その後に全体の応答が遅くなることがあります。その場合は端末が通常の温度に戻ってから比較してください。特定のアプリだけが遅く、ブラウザーやほかのアプリは正常な場合は、そのアプリのデータ使用設定と接続先サービスの状態も確認します。あらゆる待ち時間をProxyの速度の問題と考えないでください。

再現に役立つ結果を記録する

遅くなる具体的な操作、ネットワークの種類、使用中のポリシーとサーバー、発生した時間帯を記録し、直接接続とProxy経由の結果も書き添えます。ご自身が持つ別のサーバー情報に変更して解消した場合は、元のサーバーの状態を確認してください。すべての経路で遅い場合は、基本ネットワークまたは接続先サービスを先に確認します。通信量の統計についてはDataの通信量統計ガイドをご覧ください。集計範囲が異なる数値をそのまま性能比較に使わないでください。

DNS

DNSの名前解決に失敗する、ドメインを開けない、想定外のアドレスが返る

まず名前解決と、その後の接続を区別します。通常、Webページにアクセスするには、最初にドメイン名をアドレスに変換し、その後に通信とアプリケーションのセッションを確立します。どの段階で失敗しても、ページが開かないことがあります。Connectivity Testが完了してWebページにアクセスできない場合も、DNSの問題とは限りません。エラーメッセージ、リクエスト記録、再現可能な比較から名前解決の段階に問題があると判断できる場合にのみ、DNS設定を確認します。認証やルールの問題を、DNSサーバーの変更で隠さないでください。

失敗する対象とエラーの段階を確認する

開けないドメインがWebページのものか、Proxyサーバーのホスト名か、Subscribeのホスト名かを記録します。これらは異なる経路で処理される場合があります。サーバーのホスト名を解決できない場合は、トンネル自体の確立に失敗することがあります。トンネルが正常でも接続先ドメインで失敗する場合は、そのリクエストの名前解決とルーティングを確認します。すべてを「DNSが使えない」とまとめないでください。後続のテストとの照合が難しくなります。

同じネットワークで別のよく使うドメインも試し、基本ネットワークでも比較します。一つのドメインだけが失敗する場合は、そのドメインのレコード、キャッシュ、Hostのマッピング、個別のルールに関係している可能性があります。関連のない複数のドメインで失敗する場合は、名前解決サービスへの到達性をより詳しく確認します。Webサイトにアドレスを直接入力する方法は一般的な検証にはなりません。証明書、Host、サーバー側の仮想ホストが正しいドメイン名を要求することがあります。

現在のConfigにあるDNSとHostを確認する

まず実際に使用中のConfigファイルを特定してから、Generalに既存のDNS関連設定とHostセクションがあるか確認します。Settingsの項目を一つ変更しただけで、ファイル内の設定が影響しなくなるとは限りません。各設定項目の適用範囲はアプリの現在の説明に従ってください。元の値を記録し、どの設定がファイルに由来し、どの設定がアプリに由来するのかを明確にしておくと、テスト後に元へ戻せます。

Hostに固定マッピングがあると、ドメインが長期間同じアドレスを参照する場合があります。マッピングが古くなっていれば、DNSサービスを変更しても固定された結果は変わりません。まずマッピングの用途を確認し、該当項目だけを一時的に外して比較します。Hostセクション全体を消去しないでください。手元の情報で必要とされているマッピングは、復元方法も含めて保持します。検索で見つけたアドレスを根拠なく上書きしないでください。

名前解決サービスへの通信経路も必要

DNSサービスのアドレスは、設定すれば必ず使えるというものではありません。通常のクエリ、暗号化されたクエリ、Proxy経由のクエリには、それぞれ対応するネットワーク経路が必要です。解析サービスへの接続にProxyを使う設定で、Proxyサーバーのホスト名もまだ確立されていない同じ経路で解決する必要がある場合、依存関係の問題が発生することがあります。最初に名前解決が必要な対象を特定し、起動できない経路にすべてのクエリを無理に通さないでください。

DNS設定を選ぶ際は、用途を理解している既存の情報を使い、現在のネットワークから到達できるか先に確認します。サーバーを追加すれば必ず信頼性が高まるとは限りません。応答結果や待機順序が異なると、問題の再現が難しくなることがあります。変更前に元の値を保存し、条件は一度に一つだけ変えます。改善した場合も、日常的なルーティングやローカルネットワークへの接続に影響がないか確認してください。

IPv4、IPv6、キャッシュを分けて確認する

ドメインからIPv4とIPv6の両方のアドレスが返される場合があります。名前解決が成功しても、一方のアドレスファミリーに到達できないと、長時間待ってから別の経路に切り替わったり、一部のリソースだけ失敗したりすることがあります。これはアドレスへの到達性の問題であり、名前解決サービスが応答しないこととは異なります。まずエラーと現在のネットワーク環境を確認し、対象を絞って比較してください。一つの接続先のために、端末の関連機能を長期的にすべて無効にしないでください。

DNSやHostを変更しても、既存の接続やキャッシュが以前の結果を使い続けることがあります。テスト中のリクエストを終了し、通常どおり切断して再接続してから同じ接続先を確認してください。必要に応じて接続先のアプリも開き直します。設定を何度も続けて変更した直後に、古いページだけで結果を判断しないでください。再接続後に一時的に直って再発する場合は、再び失敗したドメインとタイミングを記録し、設定の切り替えやネットワークの変化を確認します。

ルールの適用結果も名前解決に影響される

DOMAIN系ルールはドメイン名を条件として判定し、IP-CIDR、IP-CIDR6、GEOIPはアドレスを条件とします。具体的な動作はルールのパラメータや名前解決の段階にも左右されます。名前解決で異なるアドレスが返ると、リクエストに適用されるポリシーが変わることがあります。確認時はまず実際に適用されたルールを調べてください。DNSを「直す」目的でIP系ルールをすべてドメイン系ルールの前に移動しないでください。FINALが処理するのはどのルールにも一致しない場合で、誤った名前解決結果を修復するものではありません。

修正後は、対象ドメイン、普段使う別のドメイン、必要なローカルネットワークサービスを最低限確認します。名前解決のエラーが消えてもアクセスに失敗する場合は、ルーティングの章で後続の接続を確認し、DNS設定を変更し続けないでください。症状の詳しい見分け方はDNS名前解決エラーのトラブル対処ガイドをご覧ください。問い合わせ時はエラーの原文と設定項目の種類を伝え、内部ドメイン名や個人用アドレスは伏せてください。

Lifecycle

バッテリー消費、バックグラウンドでの再接続、アップデート後の問題

まず変化した時期と条件を確認してから、Shadowrocketとの関連を判断します。システムのバッテリー統計では、異なる動作がアプリやシステムサービスにまとめられることがあります。一度の使用割合だけで余分な消費とは判断できません。アップデート後に問題が起きても、アップデートが原因とは限りません。同じ時期にシステム設定の変更、Subscribeの更新、ネットワーク環境の変化があった可能性もあります。まず元の設定と症状を記録し、比較せずに再インストールしないでください。

比較可能な条件でバッテリー消費を観察する

システムのバッテリー画面で、該当時間帯の画面使用、バックグラウンドでの動作、端末全体の消費量を確認します。動画再生、大量のダウンロード、インターネット共有、電波の弱い環境は、それ自体で電力を多く消費します。時間帯を比較するときは、ネットワーク、画面点灯時間、実際の操作をできるだけ同じにしてください。アプリの使用割合だけを比較すると、ほかのアプリの消費が減った結果、割合が増えているだけのこともあり、誤解につながります。

端末が発熱していないか、充電中か、継続的な通信中かを記録します。VPN経由の通信は端末のリソースを使用しますが、異常な消費がある場合は、接続の繰り返し、頻繁なテスト、追加処理を確認してください。統計上の数値を下げるために、すぐにすべての機能をオフにしないでください。端末全体の電池残量が異常に減っているのか、バックグラウンド動作が長いのか、特定画面の割合が高いだけなのかを先に見極めます。

On Demandと接続失敗時の再試行を確認する

画面ロック後に接続状態が変わり続ける場合は、まずOn Demandの起動条件と、そのときのネットワークの安定性を確認します。ほかの条件を変えずにOn Demandを手動でオフにし、近い時間帯で様子を見ます。再接続が明らかに減った場合は、ネットワーク切り替え時に元の条件が繰り返し満たされていないか確認してください。On Demand自体を障害と決めつけず、具体的な起動条件と接続を維持できない原因を特定します。

サーバー認証の失敗、Subscribeへのアクセス失敗、特定リクエストの繰り返し再試行も、動作を増やす原因になります。同じエラーが繰り返されていないか確認し、該当する処理を優先して修正してください。テスト中はConnectivity Testや手動更新の回数を減らし、確認作業自体が負荷を生まないようにします。変更後も通常の利用を続けて確認してください。通信を完全に止めた時間帯を、設定の省電力効果の証明にしないでください。

安全性を保ちながら設定の追加処理を減らす

設定に追加のURL Rewrite、スクリプト、HTTPS処理が含まれる場合は、それぞれ現在も用途があるか確認します。元のファイルを保存してから、一度に一種類だけ停止し、同じ操作でバックグラウンド動作を比較します。内容をすべて一度に削除したり、証明書の検証を恒常的に無効にしたりしないでください。内容を説明できない設定がある場合は、用途の明確な基本設定に戻してから、追加処理が問題に関係しているか確認します。

アップデート後はデータを消去する前に状態を確認する

アプリのアップデートはApp Storeから行います。アップデート後は、Homeで選択中の項目、Configで使用中のファイル、Global Routingが元の用途に合っているかを確認し、次にシステムVPN構成の状態を確認します。接続方法が変わったように見えても、別の項目を選択していたり、ポリシーの参照先が無効になっていたりする場合があります。これらを確認してから通常の手順で一度切断し、再接続してください。続けて操作すると、問題発生時の状態がわからなくなることがあります。

App Storeのページにあるアップデート内容と互換性情報を確認してください。システム要件はApp Storeの掲載内容をご確認ください。現在の画面で設定の位置や名称が変わっている場合は、実際の英語表記を基準にして、古いガイドの位置情報をそのまま使わないでください。アプリのページに表示された関連情報を問い合わせ用に記録できますが、このマニュアルでは特定のバージョン番号や公開日を前提にしません。

再認証や再インストールを検討するタイミング

アップデート後にシステムの接続状態だけが異常な場合は、まず接続スイッチの章で許可と構成を確認します。スイッチが正常なのにアクセスできない場合は、ルーティングまたはサーバーの問題を調べてください。再インストールは最後の手段とし、元のサブスクリプション、サーバー情報、設定のバックアップ、購入時のアカウントをすべて復元できることを確認します。バックアップには認証情報が含まれることがあるため、トラブル対処のために公開の場所へアップロードしないでください。

アプリは引き続きApp Storeから入手します。購入済みアプリの復元方法は購入済みアプリの復元方法をご覧ください。復元後は、用途の明らかな設定を一つ使ってテストし、元の設定を一つずつ戻します。基本状態が正常で、特定の処理を戻した後に再び問題が起きるなら、原因を比較できる証拠になります。すべて同じ条件でも再現する場合は、操作の順序、システムの表示内容、影響範囲を記録してから問い合わせてください。

この章の完了基準は、通常の操作で接続が安定し、エラーによる再試行が減り、近い条件でのバッテリー観察でもその状態を再確認できることです。特定の設定で必ず消費電力が下がると約束したり、一度短時間復旧しただけでアップデート後の問題が完全に解消したと判断したりしないでください。元の値と実際に有効だった変更を保存しておけば、同じ症状が再発したときに同じ根拠に基づいて確認できます。

iPad

iPadの購入済みアプリの復元、画面レイアウト、ネットワークの確認

iPadでは、購入の復元と設定の移行を分けて考えてください。購入時に使用したご自身のApple IDでApp Storeの購入済み項目を開き、アプリを再入手します。購入の適用条件とシステム要件はApp Storeの掲載内容をご確認ください。アプリを再入手しても、別の端末にあるサーバー、Subscribe、Configが自動ですべて移行するわけではありません。起動後にリストが空の場合は、購入が無効だと判断する前に、設定情報の移行状況を確認してください。

購入済みアプリに価格が表示される場合の確認方法

システムのほかのサービスに表示されるアカウントではなく、現在App Storeで購入に使っているアカウントが購入時のものか確認します。次に、製品名、開発者名のShadow Launch Technology Limited、アプリIDの932747118を照合してください。アカウントと製品を確認する前に再購入しないでください。確認方法は正規アプリを見分ける3つのポイントをご覧ください。アプリの入手先はApp Storeのみです。

現在のストアに購入済み項目が表示されない場合は、ネットワーク、アカウントの購入履歴、現在のストアの状態を確認し、App Storeに表示された案内に従ってください。ファミリー共有を利用できるかどうかはストアページとご自身のファミリー設定によります。ほかの人の購入が必ず復元できるとは限りません。アプリの購入とサーバーサービスの状態は別です。アプリを復元した後も、ご自身が用意した有効な接続情報が必要です。

横向き、Split View、狭いウインドウでの画面操作

iPadの横向き表示やSplit Viewでは、リストや詳細の表示位置が変わる場合があります。「左下から3番目のボタン」のような位置だけに頼らず、Home、Config、Data、Settingsなど画面上の英語表記を目印にしてください。編集パネルに前回選択した内容が残っている場合があります。変更前に項目名と実際のアドレスを確認し、保存後は現在選択中の項目に戻って確かめます。同じ名前の隣接項目を誤って変更しないようにしてください。

画面の回転やウインドウ幅の変更だけで、ルーティングの状態が変わったとは限りません。画面の見え方が変わった場合は、Global Routingの現在のモードとConfigで実際に選択されているファイルを確認してください。サーバー情報の入力時は、外付けキーボード、文字の自動置換、貼り付けによって空白が混入することもあります。保存後にアドレス、ポート、認証情報を一つずつ確認してください。入力時にエラーが出なかっただけでは、有効性の証明になりません。

2台の端末で同じ情報を使っても結果が異なる場合

まず同じWi-Fi、同じ接続先、同じサーバー情報を使って比較します。iPhoneのモバイルネットワークとiPadのWi-Fiを、そのままアプリの比較に使わないでください。項目名が同じでも、実際のパスワード、トランスポート設定、選択中のポリシー、設定ファイルが異なることがあります。項目の種類ごとに違いを確認し、認証情報一式を第三者に送って比較しないでください。

設定が完全に一致しているのに一方の端末だけ失敗する場合は、その端末のネットワーク権限、ほかのVPN、管理上の制限、システム時刻、DNS環境を確認します。Wi-Fiのみ対応のiPadでは、ご自身が利用できる別のネットワークで比較できます。個人用ホットスポットを使う場合は、ホットスポット側のネットワーク変化も結果に記録してください。ネットワークを変えて復旧しても、接続環境が問題に関係していたとわかるだけで、アプリの設定が直った証明にはなりません。

スリープ復帰時とネットワーク切り替え時の問題

長時間の画面ロック後、復帰直後、Wi-Fi切り替え後のどのタイミングで問題が発生したか記録します。復帰直後は基本ネットワークがまだ回復しておらず、アプリのリクエスト失敗とVPNの再接続が同時に起きる場合があります。まずネットワークが安定したことを確認してから、手動で一度アクセスします。復帰のたびに再接続が必要なら、On Demandの条件、システムVPNの状態、サーバー側のセッション動作を確認し、接続の章に沿って段階ごとに調べます。

バックグラウンドに長時間表示されていることだけで、接続が維持されていると判断しないでください。画面に以前の状態が表示されていても、現在のリクエストが使えるとは限りません。実際のアクセス、システムの状態、エラー記録を照合します。Split Viewでのみ失敗する場合は、接続先アプリ独自のセッションやネットワーク制限を確認してください。ほかの条件を変えずに全画面表示へ切り替えて同じ操作を行うと、ウインドウの変更と同時に起きただけの現象か判断できます。

設定の移行後は一つずつ復元して確認する

ご自身で管理するバックアップから設定を復元したら、まずSubscribeの有効性と現在選択中のサーバーを確認し、次にConfigファイルとポリシーの参照先を確認します。ファイルが固定名を参照している場合、別の端末では名前の違いによってルールが正しく適用されないことがあります。復元は、情報が揃っていること、接続できること、実際のリクエストが完了すること、ルールが用途に合っていることを順に確認してから、最後にOn Demandや追加処理を戻します。複雑な設定を一度にすべて有効にしないでください。

少なくとも、普段使うWebページへのアクセス、既存の用途でProxy経由が必要なリクエスト、通常の切断後に基本ネットワークへ接続できることを確認します。特定の段階だけ失敗する場合は該当する章に戻り、購入手続きを最初からやり直さないでください。アカウントの復元と画面操作についてはiPadでの購入済みアプリの復元と使い方をご覧ください。画面上の用語は英語インターフェース用語ガイドで確認できます。