Shadowrocket トラブル対処ガイド

接続スイッチがオンにならない、または自動でオフになる

スイッチがどの段階で止まるか確認する

接続をタップしても反応しない、一時的にオンになってからオフになる、オンの後に再接続を繰り返す、といった症状はそれぞれ異なります。まずHome画面で操作後にシステムの許可画面が表示されるか確認し、次にシステム設定でVPNの状態を見ます。システムの許可は接続に必要な設定の作成を認めるもので、サーバーの認証や接続先へのアクセス成功を意味するものではありません。許可画面が表示されている場合は、内容を確認して操作を完了してください。画面の背後にあるアプリのスイッチを何度もタップすると、許可待ちを接続の停止と誤認するおそれがあります。

初回接続時はVPN構成の追加を許可する必要があり、デバイスのパスコードやシステム認証を求められる場合があります。以前に許可を取り消した場合は、アプリから接続を再度開始してください。システム設定の項目名はOSによって異なる場合があります。設定内でVPNを検索して構成を確認してください。Shadowrocketのものと確認できる項目だけを確認し、組織や学校、デバイス管理で必要な構成をむやみに削除しないでください。管理対象デバイスでVPNの追加が制限されている場合は、デバイス管理者に確認します。サーバー設定を変えても、システムのポリシー制限は解除できません。

ネットワークと接続設定を分けて確認する

まず接続をオフにし、普段開けるページをブラウザーで表示して、Wi-Fiまたはモバイル通信が利用できることを確認します。公衆Wi-FiではWebページでのログインが必要な場合があります。Wi-Fiに接続済みと表示されても、インターネットにアクセスできるとは限りません。ネットワーク認証を済ませてから接続してください。通常のネットワーク接続にも問題がある場合は、電波、回線の状態、ルーターを先に確認し、Configも同時に変更しないでください。別の利用可能なネットワークに切り替えて同じテストを行うと、現在の接続環境だけで起きる問題か判断できます。

通常のネットワークが使えることを確認したら、Homeでサーバーが選択されているか確認します。サブスクリプションのグループ名だけが表示されている状態ではありません。選択した項目を開き、利用中のサービスから提供されたプロトコル、アドレス、ポート、認証情報と照合してください。まず現在のConfigのコピーを保存してから、利用可能と確認済みの設定と比較します。特定のConfigを有効にした直後に接続が切れ、別のConfigなら接続を維持できる場合は、そのConfigの構文や参照関係を優先して確認してください。唯一のコピーを直接上書きすると、問題発生時の状態と元に戻す手段を失います。

自動接続と繰り返しの起動を確認する

スイッチが一度オフになってから再びオンになる場合は、On Demandが有効か、現在のネットワークが接続条件に合っているか確認します。原因を調べている間はOn Demandを一時的にオフにし、手動でテストすると、自動ルールによる状態変化を避けられます。デバイス上でVPN構成を使うほかの機能も、接続に影響する場合があります。停止してよいと確認できた機能だけを一時停止し、再テストしてください。Wi-Fiの切り替え、画面ロック、アプリを前面に戻す操作など、状態が変わったきっかけを記録します。「時々切れる」とだけ記録するのは避けましょう。

スイッチが一時的にオンになった後すぐオフになる場合は、アプリに表示されるエラーや接続記録を確認します。設定の解析エラー、必須項目の不足、拡張機能の起動中断、接続先のタイムアウトでは、それぞれ対処方法が異なります。まず接続を停止し、ホーム画面に戻ってからアプリを開き直し、条件をそろえてテストしてください。それでも復旧しない場合は、デバイスを再起動します。再起動で一時的なシステム状態が解消することはありますが、誤ったパスワード、無効なサーバーアドレス、設定の構文エラーは修正されません。復旧後も同じ手順を再度試し、一時的に症状が隠れただけではないことを確認します。

接続中なのにインターネットに接続できない

再現可能なアクセス比較を行う

スイッチがオンという状態から分かるのは、ローカルの接続が動作中であることだけです。接続先のサーバー、DNS、ルールが正常とは限りません。普段アクセスできる用途の異なる対象を2つ選び、ページ全体が開かない、画像だけ表示されない、特定のアプリだけ接続できない、といった結果をそれぞれ記録してください。接続をオフにして同じ対象にアクセスし、通常のネットワークと比較します。オフでも失敗する場合は、Webサイトの障害、ネットワークのログイン状態、デバイスのネットワーク接続を先に確認してください。原因がないのにプロキシルールを調べ続けるのは避けましょう。

テストでは同じブラウザー、同じページ、近い時間帯を使い、キャッシュ表示を復旧と誤認しないようにします。必要に応じてページを再読み込みするか、以前開いたことのない一般的なページを選んでください。アプリのトップ画面に内容が表示されるだけで、ネットワークが正常とは判断できません。ローカルキャッシュを表示している場合があります。ブラウザーは正常で特定のアプリだけに問題がある場合は、そのアプリのモバイル通信の許可、バックグラウンド処理、ログイン接続の再確立が必要かも確認してください。すぐにデバイス全体の問題と判断する必要はありません。

Global Routingでルールと接続経路を切り分ける

Global Routingで現在選択されているConfig、Proxy、Directを確認します。診断では一時的に状態を変更し、元の値を記録してください。Directは通常のネットワーク経路、Proxyは現在のサーバーを経由するアクセス、Configは現在の設定に基づくルール適用を確認するために使います。3種類のサーバーや速度設定ではありません。Proxyはルールの問題を切り分ける比較手段になりますが、すべての対象へのアクセスに同じサーバーを使うのが適切とは限りません。

Proxyでは正常でConfigでは失敗する場合、接続先がDIRECT、REJECT、または利用できないポリシーグループに振り分けられていないか確認してください。設定を読むときは先頭から順に照合し、範囲の広すぎるDOMAIN-KEYWORD、ネットワーク範囲のルール、早い段階にあるフォールバックルールに注意します。Directでは正常でProxyでは失敗する場合は、ドメインルールを急いで変更せず、現在のサーバーを先に確認してください。比較が終わったら元の状態に戻し、次の項目を変更します。一時的なテスト設定を普段の環境に残さないようにしてください。

適用ルールと関連リクエストを確認する

Webページはアドレスバーのドメインだけでなく、画像、スクリプト、ログイン、APIのドメインにもアクセスする場合があります。メインページは開くのにログインできない場合は、アプリで確認できる接続記録を開き、失敗時のリクエストと適用されたポリシーを探します。記録上で対象にREJECTが適用されている場合は、ルールの意図を確認してから、コピー上で対象範囲を絞って調整してください。画像リクエスト一つのためにルール一式を削除したり、ドメイン名だけで用途を推測したりしないでください。実際の失敗記録とサービスの説明を優先します。

以下はルールの構文と順序を示す例です。例示ドメインはPROXY経由、地理データベースに一致するアドレスはDIRECT、それ以外の通信はFINALに渡します。これはそのまま使える完全な設定ではありません。実際の環境でPROXYが利用可能なポリシーを正しく参照する必要があります。ルールを試す前に、編集中のファイルが現在有効なConfigか確認してください。保存後、必要に応じて接続を確立し直し、同じ対象で再テストします。有効でないファイルを変更しても、現在の動作結果は変わりません。

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

どちらの経路でも接続できるのにドメインへのアクセスだけ失敗する場合は、DNSを確認します。特定のサーバーだけ失敗する場合は、タイムアウトの章に進んでください。ブラウザーに表示されるすべてのネットワークエラーをルールの問題と決めつけないでください。証明書、接続先のメンテナンス、アカウントのログイン状態もアクセスを妨げることがあります。「対象、状態、サーバー、結果」を記録してから相談すると、スイッチのスクリーンショットだけを共有するより原因を絞り込みやすくなります。接続中なのにインターネットに接続できない場合の確認リストも、手順の見直しに役立ちます。

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

テスト結果から分かることを見極める

遅延テスト、プロトコル接続の確立、実際のWebページの表示は、それぞれ異なる段階です。テストに応答があっても、そのテストで使われた経路がその時点で利用できたことしか分からず、すべてのWebリクエストが通るとは限りません。反対に、テストがタイムアウトしても、テスト方法や接続先の影響である可能性があり、一つの数値だけでサーバーが恒久的に使えないと判断することはできません。まずテスト方法を記録し、同じサーバーで固定した接続先にアクセスしてください。実際のエラーも確認し、接続前、認証中、リクエスト転送後のどの段階で起きるかを判断します。

複数のサーバーが同時にタイムアウトする場合は、まず通常のネットワークを切り替えて比較します。同じネットワークで一つの項目だけ失敗する場合は、その設定と接続先の状態を優先して確認してください。現象に影響するおそれがあるため、テスト中にまとめて何度も速度を測定するのは避けます。各回、利用可能と確認済みの項目を一つ、失敗する項目を一つ残して比較すれば十分です。利用中のサービスからメンテナンスやアカウント状態の案内が出ている場合は確認してください。本ガイドは設定の使い方を説明するもので、サーバーの提供元を案内・推奨するものではありません。

アドレス、認証、通信方式の順に確認する

まず、サーバーアドレスにプロトコル接頭辞、パス、空白、改行が誤って含まれていないか、ポートが提供された情報と一致するか確認します。ホスト名を入力する欄にサブスクリプションURL全体を貼り付けないでください。コピー時にパスワードや識別情報へ全角の記号が混入すると、一見正しく見えても認証に失敗することがあります。経験だけを頼りにポートや暗号化方式を変更せず、元の設定と項目ごとに照合してください。機密情報はデバイス上で確認し、公開するスクリーンショットではパスワード、識別情報、サブスクリプションの認証情報をすべて隠します。

次に、プロトコルで必要な認証情報と通信パラメーターを確認します。Shadowsocksではパスワードと暗号化方式を一致させる必要があります。VMessとVLESSではUUID、通信方式、TLS関連の項目を混同しないでください。Trojanでは通常、パスワードとTLS情報の両方を確認します。Hysteria2とWireGuardにもそれぞれ必須項目があり、別のプロトコルの設定を流用できません。同じプロトコル名でも、すべてのサーバーで同じオプションが使われるとは限りません。実際の設定は、利用者がすでに契約しているサービスの情報に従ってください。

TLS、時刻、ネットワークの違いを確認する

TLSを有効にした接続では、サーバーが要求する名前を確認します。サーバーアドレス、SNI、通信レイヤーのHostはそれぞれ用途が異なる場合があり、名前が違うからといってすべて同じ値に変更しないでください。デバイスの時刻が大幅にずれていると証明書の有効期間の判定にも影響するため、システムの日付とタイムゾーンが正しいか確認します。証明書エラーが発生した場合は、名前、時刻、サーバー側の設定を先に確認してください。証明書検証のスキップを通常の解決策にしないでください。検証の範囲が変わり、本来見つけるべき設定や証明書の問題を隠してしまいます。

Wi-Fiでは失敗するのにモバイル通信では正常、またはその逆の場合は、接続ネットワークの違いを調べる必要があります。通信方式によってはUDPに依存しており、ネットワーク機器がUDPと通常のWeb接続を異なる方法で扱う場合があります。利用中のサービスが提供し、対応を確認済みの設定を使って比較してください。プロトコル名をむやみに変更したり、根拠なくMTUを調整したりしないでください。プロトコル、認証、経路が正しいことを確認し、小さいデータは通るのに大きなリクエストは失敗する現象を再現できた場合に限り、経路やパケット分割に関する問題を詳しく調べます。

サブスクリプションの更新失敗、または読み込み結果の問題

URLの種類と失敗した段階を確認する

サブスクリプションはサーバー一覧を取得するためのURLで、単一のサーバーやConfigファイルとは異なります。まず利用中のサービスから提供された情報がどの種類に当たるか確認し、対応する方法で読み込んでください。WebサイトのURL、アカウント管理画面のURL、単一サーバーの共有情報をサブスクリプション欄に入力すると、期待した一覧を取得できない場合があります。確認するのはURLの形式と提供元の説明だけにし、URL全体を公開の場に貼り付けないでください。クエリパラメーターにアクセス認証情報が含まれていることが多く、漏えいするとアカウントの利用に影響するおそれがあります。

更新失敗は、リクエストを開始できない、エラーレスポンスを受け取る、内容を解析できない、一覧更新後に接続できない、の4種類に分けて考えます。リクエストできない場合はネットワークと名前解決を確認します。アカウントやURLが無効という表示が出た場合は、元のサービスのアカウントとURLの状態を確認してください。解析に失敗する場合は、返された内容がアプリの対応するサブスクリプション形式か確認します。一覧が変わった後に接続できなくなった場合は、取得自体は完了している可能性があります。更新ボタンを何度も押さず、サーバーの設定や接続先の状態を調べてください。

サブスクリプションのリクエスト経路を切り分ける

まず通常のネットワークでアクセスできることを確認してから、手動で一度更新します。現在の接続がすでに使えず、サブスクリプションのリクエストもその接続に依存していると、更新も接続の復旧もできない状態に陥る場合があります。古い一覧を残したまま現在の接続を停止し、利用可能なネットワークで再試行して、それぞれの状態で結果を記録してください。すべてのサブスクリプションで同じリクエスト経路が必要とは限りません。失敗が一度あっただけで元のURLを上書きせず、利用中のサービスの接続要件と実際の比較結果に基づいて対処します。

公衆Wi-Fiの認証が完了していない場合、リクエストに対してログインページが返されることがあります。サービスに問題がある場合は、サーバー一覧ではなくWebページの説明が返されることもあります。ブラウザーで表示できても、サブスクリプション形式が正しいとは限りません。解析エラーが発生したら、まずレスポンスの内容を確認し、Webページ全体をAdd Serverに貼り付けないでください。さらに確認が必要な場合は、表示されたエラーの種類を利用中のサービスに伝え、個人情報を隠した情報だけを共有してください。アカウント情報を含むレスポンス本文を公開しないでください。

更新前後でグループと選択状態を比較する

更新前に現在のグループ、選択中のサーバー名、手動で追加した項目を記録し、必要に応じて別のコピーを保存します。サブスクリプションの更新で、その管理対象の項目が置き換わることがあり、手動で変更した項目も新しい内容で上書きされる場合があります。そのため、サブスクリプション管理下の項目への一時的な変更を、長期保存の方法として使わないでください。更新後は項目数とグループが想定どおりか確認し、選択中の項目が残っていることも確かめます。名称の変更、同名項目の重複、サーバーの削除によって、使い慣れた選択先が別の接続を指していることがあります。

更新後に一部の項目しか表示されない場合は、データが欠けていると判断する前に、フィルター、グループの折りたたみ、表示範囲の変更を確認してください。同名の項目で設定が異なる場合は、名前だけでなくプロトコルとアドレスを確認します。サブスクリプションを取得できても、アカウントのサービスが利用可能とは限りません。契約期間、接続先のメンテナンス、認証情報はそれぞれ別に確認が必要です。グループ全体を何度も削除して再読み込みしても、サーバーから返された内容の問題は解決しにくく、比較に必要な情報を失って原因の特定が難しくなることがあります。

確認できる状態にサブスクリプションを戻す

復旧時は提供元が明確なサブスクリプショングループを一つ残し、まず手動更新を行って一覧が使えることを確認してから、自動更新の設定を検討します。自動更新の項目や利用条件は、現在のアプリ画面に表示される内容に従ってください。無効なURLを直すための機能ではありません。アプリを開くたびに更新されて一時的な変更が上書きされる場合は、関連する自動更新設定を確認してから、テスト用の項目を別に保存する方法を決めます。テストが終わったら重複して読み込んだグループを整理し、後で古い項目を誤って選ばないようにしてください。

接続は正常でも通信速度が遅い、または断続的に止まる

「遅い」と感じる状況を具体的にする

ページの初回表示が遅い、ダウンロード速度が低い、動画が断続的にバッファリングする、ゲームの応答が遅れる、といった症状は、一つの遅延値だけでは説明できません。遅いのが接続の確立時か転送中か、すべての接続先か一つのアプリだけか、常に起きるか特定の時間帯だけかを記録します。初回だけ遅く、その後のリクエストは正常な場合は、DNS、ハンドシェイク、キャッシュに注目します。接続はすぐ確立するのに大きなファイルの転送が止まり続ける場合は、テスト一覧の数値だけでなく、経路の安定性、スループット、接続先の負荷を確認します。

テストでは接続先、サーバー、ネットワークを固定し、システムアップデート、写真の同期、ほかの大容量転送を一時停止して、同じ作業を確認します。複数の速度テストを同時に実行しないでください。帯域を取り合い、結果を比較できなくなります。ネットワーク負荷の時間帯による変化を設定の効果と誤認しないよう、なるべく近い時間に比較します。利用中のサービスに通信量や速度の条件がある場合は、現在のアカウント状態を確認してください。クライアントの設定によって、接続先のサービスが実際に提供できる容量を超えることはできません。

通常のネットワーク、サーバー、接続先の順に比較する

まず接続をオフにし、通常のネットワークからアクセスできる固定の接続先を表示します。Wi-Fiの電波、ルーターの上り回線、ほかのデバイスの通信状況を確認してください。電波の表示が良好でも、電波干渉、距離、アクセスポイントの負荷によって転送が不安定になることがあります。次に接続先はそのままにして現在のサーバーで再テストします。その後、利用中で利用可能と確認済みの別のサーバーに切り替え、特定の経路だけ遅いか比較してください。サーバーとDNSを同時に変更すると、どちらが改善につながったのか判断できません。

同じサーバーで大半の接続先は正常なのに、特定の接続先だけ遅い場合は、Webサイトの負荷、コンテンツ配信の場所、両者間の経路が影響している可能性があります。Configで該当ドメインが想定したポリシーに振り分けられているか、特にメインサイトと画像・動画のドメインが別々に処理されていないか確認します。必要なら一時的にProxyで比較し、その後元の状態に戻してください。特定の動画で画質が期待どおりにならないだけでは、接続全体の問題とは言えません。再生サービスの自動画質調整、アカウントの権限、キャッシュの状態も確認します。

遅延、パケットロス、スループットを分けて考える

遅延は往復やテストの応答にかかる時間、スループットは単位時間あたりに実際に転送されるデータ量を表します。関係はありますが、同じ指標ではありません。経路の応答が速くても、継続転送中に速度が制限される場合があります。応答が多少遅くても、ダウンロードが安定していることもあります。アプリのConnectivity Testは到達性を確認する目安であり、すべての利用状況を評価する総合点ではありません。サーバーを選ぶ際は日常の作業での結果も考慮し、表示される数値を下げるためだけに頻繁に切り替えて再接続やハンドシェイクを増やさないようにします。

断続的な停止では、接続の継続性を確認します。短時間で状態が変わる場合は、Wi-Fiのローミング、モバイル通信への切り替え、画面ロックからの復帰、バックグラウンドでの大容量通信が同時に起きていないか記録してください。UDPに依存する通信では、Webページが使えることと、その通信が使えることを区別します。Webの主要経路が正常でも、すべての通信が同じ扱いを受けるとは限りません。テスト目的でMTU、並列数、通信パラメーターをむやみに変更しないでください。明確な根拠と元の設定がある場合に限り、コピー上で変更し、元に戻せる比較テストを行います。

最適化を重ねるより、安定した設定を保つ

ルールによる迂回が原因と分かった場合は、ルールの範囲を修正した後、ほかのよく使う接続先でも再確認します。一部の改善によって別のアクセスに問題が起きないようにしてください。特定のネットワークだけで発生する場合は、そのネットワークと別のネットワークでの結果を記録し、接続機器をさらに確認します。複数のネットワークで同じサーバーが遅い場合は、サーバーの状態と接続先までの経路を重点的に調べます。理由の分からないオプションをまとめて有効にしないでください。最適化項目を重ねるほど、接続の挙動を変えた原因が分かりにくくなります。

DNSの名前解決失敗とルールの適用結果が一致しない

名前解決、接続、証明書のエラーを区別する

DNSは、後続の接続に使うアドレスへドメイン名を変換します。ドメイン名を解決できない、アドレスを取得できたが接続できない、接続後に証明書が一致しない、といった問題はそれぞれ別の段階で発生します。エラーが名前解決に関係しているか確認し、複数のドメインで結果を比較してください。ドメイン名を特定サイトのアドレスに置き換えて、すべての手順を確認しようとしないでください。HTTPSでは通常、正しいホスト名と証明書も必要です。アドレスを直接指定して失敗しても、それだけでネットワーク経路に到達できないとは判断できません。

複数のアプリで新しいドメインを開くと待たされる一方、既存の接続は使い続けられる場合は、名前解決の経路を優先して確認します。特定の接続先だけ異常な場合は、接続先自体の状態と関連ルールを先に確認してください。ブラウザー、アプリ、システムはそれぞれキャッシュを保持する場合があるため、設定を変えても結果がすぐに揃うとは限りません。テスト前に元の設定を記録し、接続を確立し直して同じアクセスを繰り返します。新しいリクエストと、既存の接続を再利用しているページを区別し、キャッシュの違いを不規則な障害と誤認しないでください。

現在のConfigで名前解決の経路を確認する

現在有効なConfigを開き、DNS関連の設定が実行中のファイルに含まれているか確認します。まず元の設定でどの経路を使って名前解決する想定かを把握し、次にDNSサーバーへ到達できるか確認してください。使い慣れたアドレスに変更するだけで、現在のネットワークに適するとは限りません。もともと使えていた経路が使えなくなることもあります。暗号化された名前解決を使う場合、その接続自体にもネットワーク、正しい時刻、適切なハンドシェイクが必要です。「暗号化」すれば、どのネットワークでも自動的に利用できるわけではありません。

循環依存にも注意してください。サーバーアドレスの名前解決が必要なのに、その名前解決リクエストがまだ確立していない接続を経由する場合、起動時に停止することがあります。利用中の設定の説明に基づいて初期の名前解決経路を確認し、サーバーのドメイン名とDNS設定を同時に置き換えないでください。サービスから接続用アドレスとハンドシェイク用の名前が別々に提供されている場合は、それぞれ該当する項目に入力します。名前解決を回避するために、調べたアドレスで恒久的に置き換えるのは避けてください。接続先アドレスは変更される可能性があり、通信条件にも影響する場合があります。

ドメインルールとアドレスルールの適用範囲を理解する

DOMAINはドメイン全体、DOMAIN-SUFFIXは指定したドメインとサブドメイン、DOMAIN-KEYWORDはより広い範囲の文字列を照合します。IP-CIDR、IP-CIDR6、GEOIPはアドレスまたはアドレスデータベースに基づいて判定します。リクエストがドメイン情報を使って判定されるかどうかは、リクエスト元、名前解決の方法、現在の設定によって異なります。すべての接続でドメインルールが必ず適用されるとは限りません。まず実際の記録を確認してからルールを判断し、アドレスバーの表示だけで適用結果を推測しないでください。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

例にある2つのネットワーク範囲は文書内のサンプルアドレスです。未確認の広い実ネットワーク範囲に置き換えないでください。no-resolveは、該当するアドレスルールを照合するための追加の名前解決を避ける設定で、DNS全体を無効にするものではありません。DNSサーバーに到達できない問題も解決できません。ルールは順に処理されるため、先にある範囲の広すぎるルールが、後ろの詳細なルールの適用を妨げる場合があります。変更する際は対象を最小限にして検証し、その後に範囲を広げるか判断してください。一部の問題をほかのアプリへ広げないようにします。

IPv6とデバイス側で重なる設定を確認する

同じドメインでも異なる種類のアドレスが返される場合があり、Wi-Fiとモバイル通信ではIPv6の利用条件も異なることがあります。特定のネットワークだけ失敗する場合は、関連機能をすぐにすべて無効にするのではなく、アドレスの種類と現在の経路が対応しているか確認してください。システムの構成プロファイル、ネットワークフィルター、ほかの名前解決設定によって実際の動作が変わることもあります。自分で確認できる設定だけを調べ、管理対象デバイスは管理者に確認してください。変更後は接続を確立し直し、古いセッションによる誤判定を避けます。

バッテリー消費の増加、発熱、バックグラウンド動作の問題

まず集計期間と実際の使用状況を見る

システムのバッテリー画面に表示される割合は、選択した期間内での相対値であり、どの状況でもアプリが同じ量の電力を消費することを示すものではありません。その日にほかのアプリの使用が少なければ、同じ接続動作でも割合が高く表示される場合があります。まず集計期間、画面の使用時間、実際の電池残量の減少、通信が継続していたかを記録してから判断します。割合だけでは、長時間の通常の通信転送、通常のネットワークの電波状況、接続を繰り返し失敗したことによる追加の動作を区別できません。

比較には、同じ種類のネットワーク、近い画面輝度、似た作業、同じくらいの継続時間など、近い条件を選びます。動画再生、クラウド同期、インターネット共有はいずれもデバイス全体の負荷を変えるため、作業内容がまったく異なる2日間を直接比較できません。充電中の発熱と、充電していないときの発熱も混同しないでください。デバイスが明らかに高温になる、システムから温度の警告が表示される、電池残量が異常に減る場合は、高負荷の作業を停止して通常の状態に戻してから、短時間の制御された診断を行います。

接続の再試行とバックグラウンドの大容量通信を確認する

接続が不安定なときは、名前解決、ハンドシェイク、セッションの再確立を繰り返すことで、動作が増える場合があります。まずスイッチとシステムのVPN状態が頻繁に変化していないか確認し、特定のサーバーやネットワークだけで発生するかを調べます。サーバーがタイムアウトし続ける場合、自動再試行を続けても接続先の状態は直りません。接続を一時停止し、通常のネットワークを確認してから、利用中で使用可能な項目と比較します。オンラインだった時間だけを比べるより、失敗の回数と発生条件の方が原因の説明に役立ちます。

写真の同期、コンテンツのダウンロード、データの復元を行っているアプリも確認してください。接続を有効にした後、ネットワーク待ちだったバックグラウンド処理が始まる場合があります。電池消費の変化が接続自体によるものとは限りません。システムで可能な範囲で関連処理を一時停止し、変化があるか確認します。特定の集計値を下げるために必要なセキュリティ設定を無効にしたり、アプリのデータを何度も消去したりしないでください。通信量と電池残量の変化を同じ時間帯で見て、通常のデータ処理を障害と誤認しないようにします。

On Demandと診断時の動作を確認する

On Demandは設定した条件に応じて接続を開始します。ネットワークが頻繁に切り替わり、条件も何度も成立したり外れたりすると、接続を繰り返し確立する場合があります。調査中はルールを記録してからOn Demandを一時的にオフにし、手動で安定した接続を保ってください。動作が明らかに減る場合は、機能自体が使えないと決めつけるのではなく、個別の接続条件とネットワークの変化を確認します。復旧時は条件を一つずつ有効にし、画面ロック、ネットワーク切り替え、アプリを前面に戻す操作で想定どおり動作するか確認してください。

継続的な一括テスト、詳細な診断記録の長時間保存、サブスクリプションの繰り返し更新も、ネットワークやデバイス側の処理を増やします。診断が終わったら不要なテストを停止し、原因の特定に必要な範囲で個人情報を隠した記録だけを残します。複雑なConfigを使っている場合は、まずコピーを保存してから、今回のテストに関係しない追加処理を停止し、違いを確認します。ルールをすべて削除しないでください。ルールを減らせば電池消費が改善するとは限りません。継続的な動作や接続の失敗を引き起こしている項目を検証することが重要です。

比較テストで変更の効果を確かめる

3段階で確認できます。通常のネットワークで普段の作業を行い、手動接続を安定させて同じ作業を行い、On Demandを戻して再び同じ作業を行います。各回の時間と作業をそろえ、電池残量の変化と接続の再確立が起きたかを記録してください。特定のWi-Fi環境だけで明らかな問題が起きる場合は、電波とルーターを調べます。複数のネットワークで同じ設定の問題が繰り返される場合は、Configのコピーと発生手順を保存してください。再起動直後に一時的に改善しても、長期的に解決したとは限りません。少なくとも以前に問題が起きやすかった状況でもう一度確認します。

アプリまたはシステムのアップデート後に問題が発生した

まず何が変わったのかを確認する

アップデート後に問題が起きても、原因がアップデートそのものとは限りません。同じ時期にサブスクリプションの自動更新、サーバーのメンテナンス、ネットワークの切り替え、Configの変更があった可能性もあります。最後に正常に使えた時点から最初に失敗した時点までの変化を書き出し、更新したのがアプリかシステムか、サブスクリプションも更新したか確認してください。既存の設定を残し、再インストール、データ消去、再読み込みを続けて実行しないでください。複数の変更が重なると、どの操作が結果に影響したのか分からなくなり、その後の調査に役立つ状況も失われます。

アプリをアップデートしたら、まずHomeを開き、サーバー一覧、選択中の項目、有効なConfigが想定どおりか確認してください。画面上の項目の位置が変わっても、設定内容が消えたとは限りません。先にグループと現在のファイルを確認し、必要かどうか判断してから再度読み込みます。項目名や位置が変わっただけなら、古いスクリーンショットを頼りに操作せず、現在の画面に従ってください。アプリの入手とアップデートはApp Storeから行います。購入済みアプリの復元方法は購入済みアプリの復元ガイドを参照し、ほかの入手方法を探さないでください。

システムの状態、設定、接続先の順に再テストする

まず接続をオフにして通常のネットワークを確認し、手動で一度接続を確立します。システムからVPNの許可を再度求められた場合は、内容を確認して許可してください。デバイスに管理制限がある場合は、管理者にポリシーを確認してもらいます。システムアップデート後に接続の問題が起きた場合は、接続を停止してデバイスを再起動し、同じテストを行うことはできますが、再起動直後の一時的な成功を解決とみなさないでください。画面ロックからの復帰やWi-Fiの切り替えなど、以前失敗した操作も再現し、同じ条件で接続が維持できるか確認します。

次に同じサーバーを使い、Direct、Proxy、Configで条件をそろえて比較し、元の状態に戻します。Configだけで異常が起きる場合は、設定の構文、ポリシーの参照先、ルールの順序を確認してください。サーバー経由のアクセスがすべて失敗する場合は、アドレス、認証、通信パラメーターに戻って確認します。古い設定では厳密な項目間の関係が必要な場合があります。利用中のサービスが現在提供している設定の説明と項目ごとに照合し、知らないオプションをむやみに追加したり、すべての検証条件を緩めたりしないでください。

設定の移行とサブスクリプションによる上書きを確認する

サブスクリプション更新直後に問題が起きた場合は、更新前に保存したコピーと現在の項目を比較し、プロトコル、アドレス、ポート、TLS、通信に関する項目を重点的に確認します。名前が変わっていなくても、内部の設定が変わっていることがあります。サブスクリプション管理下の項目を手動で変更していた場合、更新によってサブスクリプションの内容に戻る可能性があります。使用できることを確認したテスト設定は別に保存し、利用中のサービスに差分を確認してください。同じサブスクリプション項目を何度も変更してすぐ更新すると、テストごとに異なる設定になり、比較しにくくなります。

設定の移行では、ファイルの選択やポリシーの参照関係も影響する場合があります。想定したファイルが有効か確認してから、その中で参照されるポリシーに対応する項目があるか調べてください。ファイルをコピーしても、外部の依存項目がすべて複製されるとは限りません。読み込みに成功しても、すべての参照先が使えるとは限りません。解析エラーが発生した場合は、具体的なエラーと該当行付近の個人情報を隠した記述を保存し、原因を説明できる部分だけを修正します。検証のために、提供元が不明なConfig全体に置き換えないでください。振り分け、名前解決、処理の仕組みを一度に変更することになります。

最後に再構築や再ダウンロードを検討する

サーバー情報、サブスクリプションの提供元、Configのコピーを適切に保存し、復元方法が明確になってから、アプリのVPN構成の再構築やアプリの再ダウンロードを検討してください。再ダウンロードする前に、購入時と同じアカウントを使用しているか確認し、App Storeのアカウントの問題と接続の問題を混同しないようにします。外部に保存したファイルは、ファイル名が見えるだけでなく、実際に開けることを確認してください。アプリ内の履歴が完全に復元されるとは限りません。履歴を使って原因を調べる場合は、消去する前に必要な記録を保存します。

iPadの接続、復元、複数デバイス間の違い

購入状態と設定状態を分けて確認する

同じ購入アカウントでのアプリの入手と、デバイス上のサーバー設定は別のものです。iPadのApp Storeでアプリの購入状態を確認してください。システム要件、互換性、ユニバーサル購入の対象かどうかは、App Storeのページに記載された内容をご確認ください。アプリを再ダウンロードできても、iPhoneのサブスクリプション、サーバーの選択、Configが自動でiPadに表示されるとは限りません。初回起動後に実際の内容を確認し、クイックスタートガイドに従って自分がすでに持っている情報を読み込みます。購入が完了しただけで、接続前の確認を省略しないでください。

App Storeに表示される購入状態が想定と異なる場合は、システム画面上部のアカウント名だけでなく、App Storeで使用しているアカウントを確認します。アプリIDは932747118、開発者はShadow Launch Technology Limitedです。復元方法はiPadでの入手方法を参照してください。購入に関する問題はまずApp Storeで対処し、サーバー認証やアクセスに関する問題はこのページの手順で確認します。どちらか一方で、もう一方の問題を解決することはできません。アプリの買い切り購入で得られるのはアプリの利用権であり、サーバーサービスは含まれません。

2台のデバイスで実際の設定を比較する

iPhoneでは正常なのにiPadでは失敗する場合は、2台を同じ利用可能なWi-Fiに接続し、近い時間に同じ接続先へアクセスします。サーバー名だけでなく、選択中のサーバー、Global Routing、現在のConfig、DNSの条件を比較してください。サブスクリプションの更新時期、同名項目の設定の違い、有効になっているファイルの違いが原因の場合があります。比較する際は、両方のデバイスを記録したテスト状態にそろえ、各回で変更するのは片方の一項目だけにします。両方を同時に変更すると、比較対象が失われます。

設定を転送する場合は、内容を確認できる管理された方法を使い、読み込み後にアドレス、ポート、プロトコル、必要な認証項目を一つずつ確認します。サブスクリプションURL全体を公開ドキュメントや画像で共有しないでください。QRコードにも機密情報が含まれる場合があります。Configファイルだけが同期される方法では、参照先のサーバーやポリシーがiPad側にも存在するか確認してください。ファイルが開けても、すべての依存項目がそろっているとは限りません。不明なポリシーがある場合は、別の名前にむやみに変更せず、対応する参照先を確認します。

iPadのネットワークとシステムの制限を確認する

一部のiPadはWi-Fiのみ対応のため、モバイル通信を使った比較手順をそのまま適用できません。利用可能で信頼できる別のWi-Fiを使って確認してください。モバイル通信に対応するモデルでは、ネットワークの許可と現在のデータ通信をそれぞれ確認します。スマートフォンのインターネット共有を使う場合、iPadは共有元が提供するネットワークに接続します。通常のネットワーク自体が正常か確認してください。iPhoneでアクセスできるからといって、共有接続中のiPadも同じ経路を使えるとは限りません。共有接続、電波、セッションの条件が異なる場合があります。

学校、職場、家庭で管理されているiPadでは、VPN、アカウント、ネットワークのポリシーによって利用が制限される場合があります。初回接続時にVPN構成を追加できない場合は、システムの表示を確認し、管理者に相談してください。管理上必要な項目を削除しようとしないでください。公衆ネットワークでWebログインが必要な場合は、接続を始める前に通常のネットワーク認証を完了します。特定のアプリだけ失敗する場合は、そのアプリのネットワーク権限とアカウント状態を確認してください。すべてのアプリが失敗する場合に限り、サーバー、DNS、ルールの順に調べ、特定アプリの権限問題をデバイス全体の問題として扱わないようにします。

画面ロック、マルチタスク、長時間利用時の動作を確認する

iPadでは、Split Viewなどのマルチタスクや長時間の待機を切り替えて使うことが多く、アプリがバックグラウンドにあるからといって接続が停止したとは限りません。アプリが前面に表示されているかだけで判断せず、システムのVPN状態と実際の通信を合わせて確認してください。画面ロックから復帰した後に失敗する場合は、復帰前後のWi-Fi、On Demandの条件、スイッチの状態を記録し、手動で接続し直して比較します。自動接続の条件下でのみ再現する場合は、接続条件を優先して確認してください。手動接続でも失敗する場合は、通常のネットワークとサーバーへの到達性を確認します。