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

01 / CONNECTION

スイッチがオンにならない：まずシステムの許可を確認

Homeの接続スイッチをタップしてもすぐオフに戻る、システムの許可を求めるメッセージが繰り返し表示される、または接続状態が想定どおりにならない場合が該当します。この段階では、サーバーを変更しないでください。スイッチで接続を確立できるかどうかと、接続先のサーバーが応答するかどうかは別の問題です。まず、現在のWi-Fiまたはモバイル通信で通常のWebページを開けることを確認し、Shadowrocketのスイッチをオフにして、基本的なシステム許可から確認します。端末がどのネットワークにも接続できない場合は、アプリ内の設定を切り替えるのではなく、端末のネットワークを先に確認してください。

初回の許可とシステムの状態を確認

初めて有効にするとき、VPN構成の追加を許可するようシステムから求められる場合があります。画面の案内に従って許可し、Homeに戻ってもう一度試してください。以前に許可を取り消した場合は、端末のシステム設定でVPN関連の構成を確認してから、アプリで再度許可を求めます。システム設定のメニュー位置は画面や端末によって異なることがあるため、特定の手順にこだわる必要はありません。システム上に接続中の表示があっても、構成が有効になったことを示すだけで、サーバーが利用できるとは限りません。次にWebページを開いて実際に確認してください。

スイッチをタップしてもシステムに何も表示されない場合は、アプリを終了して開き直し、システムに対応が必要な許可の通知がないか確認してください。端末を再起動してから試すと、一時的なシステム状態と継続的な構成の問題を切り分けやすくなります。テストのたびに「オンの状態を維持できない」のか、「オンにはなるがWebページを開けない」のかを記録してください。後者の場合は次の章に進み、ルーティングとサーバーを確認します。許可を何度も取り消す必要はありません。

接続構成の影響を切り分ける

システムの許可を確認したら、Homeで選択中の項目が、ご自身のもので情報がそろったサーバーまたはサブスクリプションであることを確認します。空の項目、削除済みの参照、期限切れの構成を誤って選択すると、スイッチを操作できても接続できないことがあります。最近複数の構成をインポートした場合は、元の名前を記録してから、今回テストする項目だけを一時的に選択してください。Global Routingを変更しながらサブスクリプションも再インポートすると、どちらの変更が影響したのか判断できません。

On Demandに現在のネットワークで接続を開始する条件が設定されているかも確認してください。たとえば、特定のWi-Fiで切断するルールが設定されていて、現在そのネットワークを使っている場合、手動操作が自動条件と競合することがあります。On Demandの自動接続を一時停止し、手動で接続して状態を確認してください。検証後は記録に沿って設定を元に戻します。組織や学校が管理する端末では、システムのVPN構成が制限されている場合もあります。同じ構成を繰り返し追加するのではなく、端末の管理者に許可範囲を確認してください。

02 / ROUTING

接続後にインターネットを利用できない：ネットワーク・サーバー・ルールを切り分ける

スイッチはオンのままなのに、ブラウザーや他のアプリで読み込みに失敗する場合が該当します。「端末から現在のネットワーク」「端末から選択中のサーバー」「ルールによるリクエストの処理」を分けて確認します。接続をオフにし、同じネットワークで普段開けるページにアクセスしてください。その状態でも失敗する場合は、Wi-Fiまたはモバイル通信を先に確認します。接続をオフにすると正常で、オンにすると失敗する場合は、アプリ内でサーバーとGlobal Routingを確認します。比較の際は同じページを使い、Webサイト側の状態の違いによる誤判定を避けてください。

Global Routingで範囲を絞り込む

Global RoutingのConfig、Proxy、Directでは、リクエストのルーティング方法が異なります。Configは設定内のルールに従って処理し、Proxyは選択中のプロキシ経由を優先し、Directは直接接続します。元の設定を記録してから、短時間だけ切り替えて比較し、テスト後に元へ戻してください。DirectではアクセスできてProxyではできない場合は、選択中のサーバーとそのパラメーターを確認します。ProxyではアクセスできてConfigではできない場合は、ルールの順序、ポリシー名、FINALを確認します。どのモードでも失敗する場合は、端末のネットワーク、システムの接続状態、テスト先を優先して確認してください。この比較は原因の特定に使うものであり、テスト時の設定を長期的に使うことを勧めるものではありません。

選択中の項目と失敗の範囲を確認

Homeに戻り、選択中のサーバーが想定しているサブスクリプションまたは手動構成のものか確認します。サブスクリプションの更新後は、項目名や並び順、利用可否が変わることがあります。リストに多数の項目があるだけでは、現在の選択項目が接続できる証拠にはなりません。以前正常に使えた別のサーバーがご自身で利用できる場合は、同じテストを行います。一つだけ失敗する場合は、その項目のアドレス、ポート、サーバー側の状態を確認します。すべて失敗する場合は、共通するネットワーク、構成ファイル、DNSを確認してください。遅延の数値だけで、すべてのWebページが正常に開けるかを判断しないでください。

特定のWebサイトだけ開けない場合は、ドメイン名、発生時刻、Global Routingごとの結果を記録してください。ConfigとProxyで結果が異なる場合は、該当するDOMAIN、DOMAIN-SUFFIX、FINALの確認が必要です。ブラウザーでは正常で特定のアプリだけ失敗する場合は、そのアプリのリクエスト先ドメインが想定どおりか確認します。ドメイン名がわからない場合は、アプリで利用できる診断情報から特定してから、一つのルールだけ変更して再テストしてください。初回接続の手順は使い方ガイド、よくある症状への簡潔な回答はよくある質問をご覧ください。

03 / SERVER

サーバーがタイムアウトする：テストの失敗と実際の接続不可を区別

サーバー一覧でタイムアウトが表示される、Connectivity Testで想定した結果が得られない、またはサーバー選択後にページが長時間応答しない場合が該当します。テスト結果は特定の時点、特定のネットワークで行った一度の確認結果であり、すべてのアプリでの実際のアクセス結果とは限りません。まず現在のネットワークが利用できることを確認し、同じ場所、同じネットワークで再度テストしてください。テスト先と普段利用するサイトが異なる場合、結果も異なることがあります。一度のタイムアウトだけでサブスクリプション全体を削除しないでください。

入力情報を先に確認

サーバーを手動で追加した場合は、プロトコルの種類、サーバーアドレス、ポート、必要な認証情報を一項目ずつ確認してください。アドレスの余分な空白、ポート番号の桁違い、プロトコルとサーバー側の設定の不一致は、タイムアウトの原因になります。Shadowsocks、VMess、VLESS、Trojan、WireGuardなどでは必要なパラメーターが異なります。ご自身が持つサーバー情報と項目ごとに照合し、別のプロトコルの設定を流用しないでください。Scan QR Codeからインポートした場合も、読み込み後の項目が元の情報と一致するか確認します。QRコードの読み込みに成功したことは、内容を認識できたことを示すだけです。

既存のサブスクリプションから追加した項目の場合は、前回の更新が成功したか確認し、更新後の有効な項目が選択されているか確かめてください。更新でサーバーアドレスや項目の順番が変わる一方、古い手動コピーがリストに残っていることがあります。混乱を避けるため、名前、グループ、登録元を記録し、対象を一つに絞ってテストしてください。パスワードやトークンを含む場合は、完全な情報を公開の掲示板に貼らないでください。確認に必要なのは項目が一致しているかどうかであり、実際の値を公開する必要はありません。

比較テストで共通の原因を探す

サーバーを固定したまま、Wi-Fiとモバイル通信で比較します。次にネットワークを固定し、ご自身が利用できる別のサーバーをテストします。特定のサーバーだけがどちらのネットワークでもタイムアウトする場合は、その構成とサーバー側の状態を優先して確認してください。同じサーバー群が特定のネットワークだけで失敗する場合は、ネットワークの接続条件、認証ページ、DNSを確認します。異なるネットワークですべてのサーバーが失敗する場合は、システムの接続状態、サブスクリプションの内容、共通の構成に戻って確認してください。一度に一つの条件だけを変えると、結果を後から検証できます。

遅延テストは明らかに応答しない項目の発見に役立ちますが、数値が小さくてもWebページが速く読み込まれるとは限りません。接続確立後にも、ドメインの名前解決、ルールのマッチング、接続先サイトの応答などが続きます。テスト結果が出てもWebページを開けない場合は、ルーティングの確認とDNSの確認に進んでください。入力情報に誤りがないのに長時間タイムアウトする場合は、ご自身のサーバー情報の提供元にサーバー側の状態を確認してください。サーバー選びでテスト結果をどう見るかは、遅延・地域・プロトコルの種類もご覧ください。

04 / SUBSCRIBE

サブスクリプションを追加・更新できない：リンク・ネットワーク・内容を確認

この章では、ご自身がすでにお持ちのサブスクリプションリンクのみを扱います。追加に失敗する、更新時にエラーが出る、更新後もリストに変化がない、の三つは別々に判断する必要があります。操作対象がSubscribe形式のサブスクリプションであり、個別のサーバー情報や構成ファイルではないことを確認してください。アプリ内での用途はそれぞれ異なります。リンクをコピーするときは、先頭や末尾の空白、文字の抜け、意図しない改行がないか確認してください。特にメッセージを分けてコピーした場合は注意が必要です。リンクに含まれる認証情報は個人情報です。公開のスクリーンショットや問い合わせ文に載せないでください。

リンクから内容を取得できるか確認

追加する前に、端末がネットワークに接続できているか確認してください。ネットワーク自体が使えなければ、サブスクリプションを取得できません。以前は更新できたのに現在は失敗する場合、ご自身が持つ元のリンクが差し替えられていないか、認証情報が変更されていないかを確認し、情報の提供元に有効性を問い合わせてください。同じ名前のSubscribe項目を繰り返し作成して再試行するのは避けましょう。登録元が似たグループが複数でき、どれを選択しているのか分かりにくくなります。元の項目を残し、エラー表示を記録してから手動で一度更新すると比較しやすくなります。

リンクにアクセスできても、内容を正しく解析できるとは限りません。更新の応答はあるのにリストが空、または項目の内容が明らかにおかしい場合は、返された形式とインポート方法が合っていないか、サーバーデータではなくエラーメッセージが返されている可能性があります。コピーしたのがサブスクリプションの入口であり、紹介ページやログインページのURLではないことを確認してください。WebサイトのページURLをSubscribeに入力しないでください。Import from Cloud JSONまたは構成ファイルを使う場合は、内容の種類に合った入口を選び、すべてをサブスクリプションリンクとして扱わないでください。

更新前後でリストが異なる場合

手動で更新した後、項目が想定したグループに入っているか確認し、実際に選択中のサーバーも確認してください。更新によって名前や順番が変わることがあります。新しい項目が追加されても、古い手動項目を選択したままでは接続状況は改善しません。アプリ起動時の自動更新を設定している場合は、まず手動更新でテストしてください。手動更新は成功するのに自動更新が不安定な場合は、アプリを開いた時点でネットワークに接続できていたか、短時間にWi-Fiとモバイル通信を切り替えていなかったかを確認します。自動更新は内容を取得するタイミングを設定する機能であり、無効なリンクや解析できないデータを修復するものではありません。

すでに複数のサブスクリプションを利用している場合は、登録元ごとにグループを見分け、まず一つだけ更新して、項目名と件数の変化を比較してください。重複項目は何度かインポートした結果の場合もあれば、異なるサブスクリプションから同じサーバーが返された場合もあります。削除する前に登録元を確認し、使用中の構成を誤って消さないようにしてください。詳しくはサブスクリプションの更新に失敗したときの対処法と複数のサブスクリプションを整理する方法をご覧ください。手動で追加したサーバーが一つ使えないだけなら、その確認のためにすべてのサブスクリプションを更新する必要はありません。

05 / PERFORMANCE

通信速度が遅い：どの段階で遅いかを確認

「速度が遅い」には、ページの読み込み開始まで時間がかかる、ページが開いてからデータ転送が遅い、特定のアプリやサイトだけ遅い、という少なくとも三つの症状があります。まずどれに当たるかを記録し、Wi-Fi、モバイル通信、または両方で起きるか確認してください。同じ端末、同じページを使い、接続をオフにした場合とオンにした場合をそれぞれテストします。現在のネットワークが混雑している場合、Shadowrocketの設定だけを変えても、ネットワーク自体の問題は解消できません。内容が頻繁に変わるページは比較に適さないため、同じ条件でテストできるページを選んでください。

接続確立とコンテンツ読み込みを区別

リンクをタップしてから内容が表示されるまで長くかかる場合は、DNSの名前解決、接続確立、サーバーの応答が関係している可能性があります。ページは表示されるものの、画像の読み込みが遅い場合は、継続的なデータ転送や接続先サイトの状態を確認してください。Connectivity Testで選択中の項目の基本的な応答を確認し、実際にアクセスして再テストします。テストの数値は検査の過程を表すものであり、動画、画像、大容量ファイルの読み込み全体を示すものではありません。特定のドメインだけ遅い場合は、Config、Proxy、Directごとの違いを記録し、全体の設定を切り替えて他の正常なリクエストまで見えにくくしないようにしてください。

ご自身が利用できるサーバーが複数ある場合は、ネットワークとテスト先を固定し、毎回サーバーだけを変えて比較してください。地域間の距離、サーバーの負荷、プロトコルの設定、接続先サイトの応答などが結果に影響します。名前に含まれる地域名や一度の遅延テストだけで性能を判断できません。同じWi-Fiでどのサーバーも遅く、モバイル通信では比較的安定する場合は、Wi-Fiの実効速度、電波状態、接続状況を優先して調べます。一つのサーバーだけが継続して遅い場合は、そのサーバーの情報とサーバー側の状態を確認してください。

ルールによる経路の違いを確認

Global RoutingがConfigの場合、リクエストはルールに従って経路が決まります。範囲が広すぎるDOMAIN-SUFFIXルールによって、本来DirectにすべきリクエストがPROXYに送られることがあります。逆に、選択中のサーバーを経由させたい接続先がDirectになる場合もあります。まず遅いドメインを特定し、最初にマッチする有効なルールを確認してから、他のルールに影響しない範囲で修正してください。すべてのルールを削除し、一度の速度テストだけで判断するのは避けましょう。関係のない多数のリクエストの処理方法まで変わってしまいます。

アプリをバックグラウンドにしてしばらく経った後の最初のアクセスだけ遅い場合は、接続の再開にかかる時間と、継続的なデータ転送速度を分けて確認してください。On Demandの条件、Wi-Fiからモバイル通信への切り替え、端末のスリープからの復帰などにより、最初のリクエストとその後のリクエストで結果が異なることがあります。続けて二回テストし、差を記録してください。一回目だけ遅い場合は、接続のトリガーやネットワーク切り替えを確認します。毎回遅い場合は、サーバーとDNSを比較してください。サーバーの選び方についてはサーバーの遅延と実際の使用感もご覧ください。

06 / DNS & RULES

DNS・ルールの問題：ドメインから最終ポリシーまで確認

特定のドメインが開かない、ネットワークによって結果が異なる、またはConfigでは失敗するのにProxyでは正常、といった症状が典型です。DNSはドメインをIPアドレスに変換し、ルールはリクエストの処理方法を決定します。互いに関係しますが、同じ設定ではありません。まず入力したドメインが正しいか確認し、以前から安定して開けるページと比較してください。特定のドメインだけに問題がある場合は、完全なドメイン名、現在のネットワーク、Global Routing、マッチしたルールを記録します。すべてのドメインで問題が起きる場合は、先にネットワークとサーバーの章を確認し、共通の問題を除外してください。

上から順にマッチするルールを理解

構成のルールは上から順に確認され、マッチすると該当するポリシーで処理されます。その後のルールはそのリクエストに適用されません。DOMAINは完全なドメイン名、DOMAIN-SUFFIXはドメインのサフィックス、DOMAIN-KEYWORDはキーワードにマッチします。IP-CIDR、IP-CIDR6、GEOIPはアドレスに関する条件を扱います。FINALは、それ以前のルールにマッチしなかったリクエストを処理するもので、通常はルールの最後に置きます。使用中の構成に該当するポリシー名が存在するかも確認してください。ポリシーグループが一致しないサンプルをそのままコピーしないでください。

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

この例は文法と順序を示すものです。example.comは例示用のドメインであり、PROXY、DIRECTはポリシー名です。すべてのユーザーに適したアクセス要件を示すものではありません。範囲の広いDOMAIN-KEYWORDを、より具体的なDOMAINより上に置くと、後者が適用されないことがあります。FINALを早い位置に置くと、その後のルールが意図どおり機能しません。変更前に現在の構成を保存し、一度に一つのルールだけを移動または変更してください。優先順位とフォールバックの詳しい例はルールのマッチ順序とFINALをご覧ください。

名前解決の失敗と経路の誤りを区別

ブラウザーにドメインが見つからないと表示された場合は、まず接続オフとオンで結果を比較し、次にConfig、Proxy、Directを比較します。同じドメインでもモードによって結果が異なる場合は、DNS設定とルールがそのドメインにどう影響するか確認してください。同じネットワークで他のドメインが正常なら、すべての設定をすぐにリセットする必要はありません。DNS設定は現在のネットワークと既存構成の要件に照らして確認します。以前は適切だったカスタムアドレスが現在も有効か、ネットワークによって結果が変わらないか、特定のドメインに例外を設定していないかを確認してください。すべてのタイムアウトに「DNSを変更する」だけで対処しようとしないでください。

IP-CIDRやGEOIPで判定する場合は、ルールが必要なアドレス情報を取得できるかも確認してください。ドメイン名の見た目だけでは、最終的にどのアドレスルールにマッチするか判断できません。「ルールは正しそうなのに別のポリシーが使われる」場合は、先にDOMAIN系のルールにマッチしていないか、前の位置に範囲の広いルールがないか確認します。原因を特定したら、一時テストで使ったGlobal Routingを元に戻し、Configで対象サイトと無関係な別のサイトをテストして、修正の影響が広がっていないことを確認してください。DNSの用語は用語早見表で確認できます。

07 / POWER

バッテリー消費が多い：発生条件とバックグラウンド動作を記録

Shadowrocketの使用中に、端末のバッテリー持ちが普段と明らかに異なる場合が該当します。バッテリー消費には、画面の明るさ、モバイル通信の電波状況、バックグラウンドアプリ、頻繁なネットワーク切り替えなど、さまざまな要因が影響します。接続中のアイコンが表示され続けていることだけを根拠に、特定の設定が原因だと判断しないでください。端末のバッテリー使用状況を開き、同じ時間帯のアプリや動作ごとの割合を確認します。ネットワークの種類、移動中かどうか、接続を長時間維持していたかも記録してください。使用時間や状況が近い条件で比較し、動画を多く見る使い方と待機状態を直接比べないようにします。

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

Wi-Fiとモバイル通信を頻繁に切り替えたタイミングでバッテリー消費が変わった場合は、On DemandでWi-Fi、Cellular、Domainに重複する条件が設定されていないか確認してください。接続、切断、再接続が繰り返されると、ネットワークの動作が増えることがあります。元の条件を記録し、自動接続を一時停止して、比較可能な時間だけ手動で接続してください。症状がなくなった場合は、条件を一つずつ元に戻して、現在の環境で頻繁に実行されるものを特定します。On Demandは接続するタイミングを決める機能であり、あらゆるバッテリー問題を解決する設定ではありません。

接続が繰り返し切れ、同時にサーバーのタイムアウトも発生する場合は、まず電波状況とサーバー情報を確認してください。ネットワーク品質が低いと、リクエストの繰り返しで動作量も増える可能性があります。Global Routingだけを変更しても、原因を解決できるとは限りません。安定したWi-Fi環境に固定し、同じ既存サーバーでテストして、移動中の状態と比較してください。特定の場所や移動経路だけで発生する場合は、電池残量の感覚的な比較より、ネットワークが切り替わった時刻を記録するほうが役立ちます。

使用状況と再テストの結果を確認

アプリがバックグラウンドで同期、メディア転送、大量のデータリクエストを続けていないか確認してください。Shadowrocketがそれらのリクエストを処理しているときの動作は、アプリがアイドル状態のときとは異なります。まず、明らかにデータ量の多いタスクを一時停止し、近い時間帯に端末のバッテリー使用状況を再確認します。テストのためにDNS、サブスクリプション、すべてのルールを同時に変更しないでください。バッテリー消費が減っても原因を特定できなくなります。比較する場合は、元の設定を記録し、一項目だけ変更して、同じ状況で再テストし、元に戻すか判断してください。

端末の異常な発熱や急激なバッテリー減少が、Shadowrocketの接続をオフにしても続く場合、現在のプロキシ構成以外に原因がある可能性があります。端末のシステムや他の実行中アプリを優先して確認してください。接続をオフにすると症状が収まる場合は、接続条件、ネットワークの種類、テスト時刻を記録し、頻繁な再接続、On Demandの条件、継続的なデータ転送を確認します。一度の待機結果だけで、特定のプロトコルやルールが必ず省電力になると結論づけず、繰り返し確認できる発生条件を見つけてください。

08 / CHANGES

アップデート後の不具合：変化した対象をアプリ・構成・ネットワークに分ける

「アップデート後に使えなくなった」という場合、何を更新したのかを明確にしてください。App StoreのShadowrocket、端末のシステム、既存サブスクリプションの内容、自分で管理するConfigファイルでは、確認の方向が異なります。最後に正常に使えたときの状況と、不具合の前に行った操作を書き留めてください。時期が近いというだけで、特定のアップデートを原因と決めつけないでください。アプリの入手とアップデートはApp Storeから行い、互換性とシステム要件はApp Storeのページに記載された情報をご確認ください。ストア上の開発者名とアプリIDを確認する場合は、正規版の確認方法をご覧ください。

アップデート前の確認可能な状態と比較

まずShadowrocketを介さずに端末のネットワークをテストし、次にHomeのスイッチがオンのまま維持されるか確認します。その後、選択中のサーバー、Global Routing、固定したWebページを確認してください。スイッチの状態が以前と異なる場合は、システムの許可に関する項目に戻ります。スイッチは正常なのにすべてのサーバーで失敗する場合は、ネットワークとルーティングの項目に戻ってください。すべての構成をすぐに削除するよりも、このように段階を分けて確認するほうが安全で、後から元の状態も確認できます。

サブスクリプションが変わった場合は、「更新成功」の表示だけでなく、サーバー名、グループ、アドレス、選択中の項目に変化がないか確認してください。Configが変わった場合は、新しいルールが古いルールより前に置かれていないか、FINALが適切な位置にあるか、構成で参照しているポリシー名が存在するかを確認します。自分で保存した元の構成がある場合は、具体的な差分を比較し、不具合のある接続先に関係する項目だけを変更してください。異なる時点の構成を混ぜて貼り付けないでください。ルールの重複や無効な参照が増え、原因の判断が難しくなります。

元に戻せる再テストの記録を作成

設定を変更する前に、選択中のサーバー、Global Routing、On Demandの条件、カスタムDNSなど、現在の状態を記録します。一項目変更するたびに同じネットワークとページで再テストし、改善がなければその項目を元に戻してから次を確認してください。こうすれば、実際の原因がネットワークの変化だった場合でも、確認していない設定変更がいくつも残りません。特定のアプリだけで発生する場合は、ブラウザーとそのアプリを別々にテストし、同じドメインまたはネットワークを使っているか記録してください。

App Storeではアプリの情報を確認できますが、他人が記載した特定のバージョン番号だけで適用可否を判断しないでください。ご自身の端末に表示されるストアページと実際のアプリ画面を基準にしてください。端末のシステムアップデート後に許可を求められた場合は、画面の案内に従ってからスイッチを再テストします。サブスクリプションの更新後に問題が起きた場合は、まずリンクと内容の確認に進んでください。「アップデートの操作」と「不具合の症状」を分けて記録すると、どの段階で変化したのか正確に判断できます。

09 / IPAD

iPadでの確認事項：画面レイアウトと接続状態を分けて考える

iPadでもiPhoneと基本的な確認の順序は同じですが、画面のレイアウト、ネットワークへの接続方法、利用状況が異なる場合があります。iPhoneでのボタンの位置だけを頼りに、iPadで同じ場所を探さないでください。Home、Settings、Global Routingなどの画面上の名称と機能を基準にしてください。まずiPadが使用中のネットワークで通常のWebページを開けることを確認し、Shadowrocketのスイッチ、選択中のサーバー、ルーティングのモードを確認します。iPadだけで問題が起きる場合は、端末のハードウェアが故障していると決めつけず、二台のネットワークと構成を優先して比較してください。

ネットワークの種類とシステムの許可を確認

Wi-Fi環境を中心に使うiPadもあれば、モバイル通信を使う端末もあります。利用できるネットワークはお手元の端末で確認してください。iPadで接続に失敗した場合は、Wi-Fiで接続認証が必要か、別のネットワークから切り替えた直後ではないかを確認します。ネットワークがまだ接続されていないと、Subscribeの更新、Connectivity Test、Webページへのアクセスがすべて失敗することがあります。接続の許可はシステムの案内に従ってください。スイッチをオンのまま維持できない場合は、許可に関する確認を順に行い、サブスクリプションの更新失敗だけを原因と決めつけないでください。

iPhoneでは使える既存サーバーがiPadでは使えない場合は、同じ名前の項目ではなく、同じサーバー情報を比較しているか確認してください。二台の端末で、異なる時期にインポートしたサブスクリプションや手動コピーが別々に残っている場合があります。プロトコル、アドレス、ポート、選択中の項目の登録元を確認してください。その後、同じWi-Fiで二台をテストし、ネットワークの違いをできるだけ除外します。iPadが別のWi-Fiを使っている場合は、構成を比較する前にネットワークの違いを記録してください。

大画面での操作と自動接続条件を確認

iPadで画面の縦横を切り替えたり、複数のウインドウを使用したりすると、画面上の項目が並び替わることがありますが、Global RoutingのConfig、Proxy、Directの意味は変わりません。設定を変更した後はHomeに戻って選択中の項目を確認し、同じ接続先にアクセスして再テストしてください。リストの位置が変わったために別のサーバーを誤って選ばないようにします。端末のスリープ解除後だけアクセスに失敗する場合は、現在のWi-FiまたはDomainに対するOn Demandの条件を確認し、手動接続が正常か比較してください。手動では正常で自動接続だけ想定と異なる場合は、サーバーのパラメーターをすべて変更する前に、接続条件を確認します。

端末を変更した後の購入済みアプリの入手と初回起動の手順は、iPadでの入手方法をご覧ください。システム要件と互換性はApp Storeのページに記載された情報をご確認ください。別の端末とiPadでサブスクリプションの内容が異なる場合は、それぞれのインポートと更新結果を個別に確認します。一方の端末で構成を変更しても、もう一方が自動的に変わるとは限りません。最後に「同じネットワーク、同じサーバー情報、同じ接続先ページ」で比較してください。条件をそろえることで、iPad固有の問題と一般的なネットワークやサーバーの不具合を区別できます。