Shadowrocket
トラブル対処ガイド

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

接続スイッチをオンにしてもすぐオフに戻る場合は、まずVPN構成の追加がシステムで許可されているか、ほかの接続構成と競合していないかを確認します。この段階では、サーバーが利用可能かどうかは判断できません。システムトンネルが確立されていなければ、リクエストがサーバーに届いていない可能性があります。システムの確認画面が表示されたかを見て、「許可が完了していない」「構成を開始できない」「開始後すぐ停止する」を切り分けてください。これらをすべてサーバーのタイムアウトとして扱わないようにしましょう。

許可を完了してから、スイッチの状態を確認

初めて接続するとき、VPN構成の追加を許可するようシステムから求められることがあります。表示された確認画面が、現在使用中のShadowrocketからの要求であることを確かめ、システムの手順に従って認証を完了してから、アプリに戻ってスイッチの状態を確認してください。以前に拒否した場合は、もう一度接続を開始して許可します。確認画面が再表示されない場合は、システム設定で「VPN」を検索し、該当する構成があるか確認してください。設定画面の階層はシステムによって異なるため、デバイスに表示される項目名を目安にしてください。

システムのVPN構成はサブスクリプションの内容ではなく、サーバー一覧とも異なります。削除してもサーバー設定が自動的に修復されるわけではなく、アプリで再度許可が必要になることがあります。まず、どのアプリに対応する構成か確認し、職場や学校の管理用構成を誤って削除しないようにしてください。管理対象デバイスでは、VPNの追加や変更が制限されている場合があります。設定を編集できないときは管理者に制限を確認し、スイッチを何度も操作しても管理ポリシーの問題は解決しません。

許可が完了したら、まずアプリを開いたまま接続を一度オンにし、状態が安定するまで待ってから、システム設定でVPNが接続済みになっているか確認します。スイッチが戻るのが許可の前か後か、別のアプリに切り替えた後かを記録してください。バックグラウンドに移ったときだけ停止する場合は、On Demandの動作とシステム状態を確認します。アプリを開いたまますぐ停止する場合は、WebルールやDNSを変更する前に、その時点でアプリに表示されたエラーを確認してください。

自動接続と構成の競合を確認

オフにしたあと自動でオンに戻る場合は、On Demandが有効か、現在のネットワーク条件に一致しているかを確認してください。オンデマンド接続が有効だと、手動スイッチの動作が想定と異なることがありますが、故障とは限りません。切り分けのため、元の設定を記録してから自分で設定したOn Demandの条件を一時的に無効にし、手動で一度接続してみます。Wi-Fi条件、ドメイン条件、サーバーを同時に変更すると、どの変更が影響したのか判断しにくくなります。

システム内に別のVPN構成があり、自動接続していないか確認します。テストでは確認したい接続だけを使い、ほかの構成の自動起動を一時的に止めてからShadowrocketを再試行してください。管理対象のため変更できない構成はそのままにし、管理者に確認します。スイッチがオンのまま維持できたら、次に実際のアクセスを確認してください。システムにVPN接続中と表示されるのはトンネルの状態を示すだけで、すべてのドメイン、プロトコル、サーバーが正常であることを保証するものではありません。

複数の構成ファイルがある場合は、一覧に目的のファイルがあるかだけでなく、実際にそのファイルが有効になっているか確認してください。元ファイルのコピーを残し、動作を確認済みのサーバーと簡潔な構成でテストできます。簡素化した構成では起動し、元の構成では起動しない場合は、最近変更した設定項目や書式を確認します。サブスクリプションの更新成功は、構成の構文が正しい証拠にはなりません。両者が扱う内容は異なります。

データを残しながら順に復旧

未保存の編集がないことを確認してから、アプリを通常の方法で終了して開き直し、次にデバイスを再起動してシステムの状態が戻るか確認します。再起動後は、まず基本のネットワーク接続を試してから接続をオンにすると、元からある通信の問題と接続開始時の問題を切り分けられます。エラーが続く場合は、画面に表示された文言、再現手順、ネットワークの種類を記録してください。「開けない」だけでは原因を特定できず、すでに試した操作を繰り返すことにもなりかねません。

システムのVPN構成を作り直すのは、上記の確認を済ませた後にしてください。対象は、自分が使っていると確認できた構成に限ります。再作成後は許可をやり直し、On Demandと選択中のサーバーを確認します。アプリを再インストールすると、ローカルの構成、履歴、カスタム設定に影響することがあります。復元できる情報があるか先に確認してください。購入済みアプリの復元については購入済みアプリの復元、システムの許可についてはVPN構成の確認画面についてをご覧ください。

接続中なのにインターネットにアクセスできない：ルーティングと出口を分けて確認

スイッチがオンのままなのにWebページを開けない場合は、まず3点を確認します。接続をオフにした状態で基本のネットワークが使えるか、接続をオンにするとすべての接続先で失敗するか、Global Routingで何が選択されているかです。接続中と表示されるのはシステムトンネルが確立したことを示すだけです。実際のリクエストは、ドメインの名前解決、ルールの適用、出口の選択、サーバーでの転送を経ます。サーバー、ルール、DNSを同時に変更するより、この順に確認すると原因を特定しやすくなります。

まず不具合の範囲を確認

接続をオフにし、普段アクセスできる一般的なWebページを開いて、Wi-Fiでネットワーク認証が必要か確認します。基本のネットワークにもアクセスできない場合は、ルーター、電波状況、ネットワーク認証を先に確認してからアプリに戻ります。接続をオンにした後、同じ接続先を再テストし、別の接続先も試してください。Webサイトを1つしか試さないと、サイト側の障害、アカウントの状態、地域的なサービス障害をアプリの問題と誤認する可能性があります。

ブラウザーと問題が起きているアプリで、結果が同じか別々に記録してください。特定のアプリだけで失敗する場合は、そのアプリのキャッシュ、アカウントのリクエスト、独自の名前解決、接続の再利用などを考慮します。すべてのアプリで失敗する場合は、共通の出口や名前解決経路の問題が疑われます。比較は同じネットワークで近い時間に行い、Wi-Fiやサーバーを切り替えた後に、かなり前の成功記録と比べないようにしてください。

基本ネットワークにログイン画面がある場合は、接続をオフにして認証を済ませてから再接続します。ネットワーク認証が完了していないと、Wi-Fiに接続済みと表示されても、認証に必要なアドレスにしかアクセスできないことがあります。その場合、サブスクリプション更新、サーバーテスト、Webアクセスが同時に失敗する可能性があります。この状況を解決しようとルールを何度も変更せず、まず通常のネットワークにアクセスできることを確認してください。

Global Routingで条件を絞って比較

Global RoutingのConfig、Proxy、Directは、それぞれ構成ファイルに従う、プロキシ経由、直接接続を表します。元の設定を記録してから、短時間だけ切り替え、不具合がルールに関連しているか確認してください。Directでは直接接続の結果、Proxyではプロキシ経由の結果、Configではルール適用後の動作を確認できます。これらは原因を調べるための条件であり、特定の項目に切り替えれば必ず直るというものではありません。

Proxyでは接続できるのに、Configでは同じ接続先に失敗する場合は、ルールによって異なるポリシーに振り分けられていないか確認してください。Directでは正常でProxyでは全般的に失敗する場合は、選択中のサーバーと設定を優先して確認します。3つの設定すべてで失敗しても、すぐにDNSの問題と決めつけず、基本ネットワーク、接続先の障害、残っている接続状態も確認してください。切り替えるたびにリクエストを新しく開始し、ブラウザーが前の接続を再利用しないようにします。

アプリの接続ログや診断情報を使って、接続先のドメイン、適用されたルール、最終的なポリシーを確認してください。項目名は現在の画面に従います。REJECTが表示された場合は、意図したルールによる拒否かを確認します。DIRECTが表示され、接続先へのアクセスに自分のサーバーが必要な場合は、ルールの順序を確認してください。ファイル内にルールが存在するだけで、実際に適用されると判断しないようにしましょう。

適用順から構成の問題を特定

ルールは通常、上から順に評価されます。条件の範囲が広いルールが先にあると、後続の詳細な条件より先に適用されることがあります。以下は順序を説明するための例です。example.comは説明用のドメインであり、アクセスを推奨するサービスではありません。テスト前に元の構成をコピーし、問題の接続先に関係する最小限の箇所だけを変更してください。使用中の構成ファイル全体を例で置き換えないでください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

FINALが適用されるのは、それ以前のルールに一致しなかったリクエストです。先行するルールに一致した結果は変更できません。ローカルネットワークへのアクセスを調べるときは、接続先のアドレスと現在のネットワークの実際のサブネットが一致するかも確認してください。すべての家庭内ネットワークが例示したサブネットを使っているとは限りません。ドメインルールとアドレスルールでは確認方法が異なります。名前解決が関係する場合は、末尾のポリシーだけを変更せず、次の手順で実際の名前解決結果も確認してください。

簡素化した構成では正常で元の構成では問題が起きる場合は、ルールを段階的に戻して再テストすると、該当する条件を絞り込めます。テスト後は元のルーティング設定に戻し、必要な変更とその理由を記録しておきましょう。一時的なProxy設定をそのまま使い続けないようにしてください。適用順の詳しい例はルールの順序とFINAL、画面に表示される用語は用語集をご覧ください。

サーバーがタイムアウトする：設定を順に確認

Connectivity Testでタイムアウトと表示されても、そのテストが想定時間内に完了しなかったことを示すだけです。パスワードの誤り、サーバーの停止、サブスクリプション全体の無効を単独で証明するものではありません。テスト方法によって確認する接続段階が異なり、結果はネットワークや接続先にも左右されます。まず、失敗するのが1つの項目か、同じサブスクリプションの全項目か、特定のネットワークだけかを確認し、サーバー設定、サービスの状態、ローカルネットワークのどこを調べるか決めましょう。

元の情報と実際の項目を照合

現在選択中の項目を開き、ご自身のサービス提供元から受け取った情報と1つずつ照合します。まずプロトコル、サーバーアドレス、ポートを確認し、その後に認証と転送の項目を確認してください。貼り付け時の前後の空白、誤った改行、全角記号にも注意します。アドレス欄に説明文を混ぜないでください。インポート後に同じ名前が表示されても、設定が同一とは限りません。特に、似た名前の項目を複数回インポートした場合は、実際に接続で選択されている項目を確認してください。

サブスクリプションから追加した項目は、元のサブスクリプションと現在の記録を残し、すぐに個別編集しないでください。手動で変更した項目は次回更新時に上書きされる可能性があり、元の情報との比較も難しくなります。サービス提供元が設定を変更したと確認できたら、まず既存のサブスクリプションを更新し、成功したことを確認してから該当する項目を選び直します。更新に失敗した場合はサブスクリプションの章を確認し、古い項目のタイムアウトを更新成功と取り違えないようにしてください。

サーバーアドレスを確認するときは、ドメイン名と数値のアドレスを区別してください。ドメイン名は名前解決が必要ですが、数値のアドレスは証明書に記載された名前と異なることがあります。名前解決で得たアドレスに安易に置き換えると、証明書の検証やルーティングの結果が変わる可能性があり、一般的な修復方法にはなりません。ドメインの名前解決に問題があると思われる場合は、元のアドレスを残して状況を記録し、DNSの章の手順で比較してください。

プロトコルの設定項目をまとめて照合

プロトコルによって必要な認証項目と転送方式は異なります。Shadowsocksでは、サーバーが指定する暗号化方式とパスワードを確認します。VMess、VLESSなどでは、対応する識別情報と転送設定を確認してください。TLSを使う場合は、関連する名前と証明書の要件も照合します。項目を保存できても、サーバーの設定と一致しているとは限りません。ほかの項目にある「似ている」設定で、未入力の項目を置き換えないでください。

証明書に関するエラーが表示された場合は、まずデバイスの日付と時刻が正しいか確認し、次にサーバーが求める名前と証明書の状態を照合してください。証明書の検証を無効にしても設定が直った証拠にはならず、検証の範囲も変わるため、通常のトラブル対処として行わないでください。項目の意味が分からない場合は、異なる値を何度も試すのではなく、ご自身のサービス提供元に必要な設定一式を確認します。項目の表示名より、エラーの正確な文言が役立つこともあります。

Hysteria2、WireGuardなどには、それぞれ固有の転送設定や鍵の設定があり、ほかのプロトコルの組み合わせを流用できません。あるネットワークでは接続でき、別のネットワークでは失敗する場合、関連する通信に対するネットワーク側の処理が影響している可能性がありますが、一度のタイムアウトだけでは断定できません。同じ項目と接続先を使い、利用可能な2つのネットワークで条件を変えずにテストしてください。そうすることで意味のある比較ができます。

条件を組み合わせて原因を絞り込む

1つの項目だけが失敗し、同じ条件で自分が利用している別の項目は正常な場合は、失敗した項目の設定とサービスの状態を重点的に確認します。すべての項目が失敗する場合は、基本のネットワークやサブスクリプションの期限、古い内容が返されていないかを先に確認してください。短時間に多数のテストを連続実行しないでください。ネットワークの混雑、サーバー側の制限、デバイスの負荷が異常を増幅し、結果の判断が難しくなることがあります。

Wi-Fiでは失敗し、モバイル回線では正常な場合は、まずWi-Fiの認証が完了しているか確認し、次にルーターのネットワークと名前解決の環境を調べます。デバイスでモバイル回線を使えない場合は、可能であれば別の信頼できるWi-Fiで比較してください。一度成功しただけでは、その状態が長く続くとは限りません。比較後は元のネットワークに戻し、問題を再現できるか確認して、たまたまの成功を最終結論にしないようにしましょう。

ご自身のサービス提供元に問い合わせる際は、プロトコル、発生時刻、ネットワークの種類、エラーの正確な文言、影響する項目が1つだけかを伝えてください。パスワード、識別情報、秘密鍵、サブスクリプションの完全なURLは伏せてください。公開するスクリーンショットに、通常これらの情報は必要ありません。このガイドでは、手元にある情報の確認方法を説明しており、接続サービスは提供していません。サーバーテストに成功しても実際の通信が失敗する場合は、「接続中なのにインターネットにアクセスできない」の章に戻り、実際のルーティングを確認してください。

サブスクリプションの更新に失敗する：取得・解析・反映を切り分ける

サブスクリプションの更新には、URLの取得、現在のネットワークからの内容リクエスト、項目への解析、ローカル一覧への反映という独立した段階があります。接続できても更新できるとは限らず、更新に成功してもすべての項目が使えるとは限りません。まず表示された正確なメッセージを記録し、リクエストできない、想定と異なる内容が返る、解析に失敗する、更新後に件数が変わる、といった状態を切り分けます。削除して追加し直すだけで原因を見えなくしないようにしてください。

自分のサブスクリプションURLを確認

ご自身のサービス提供元から正式に案内された情報を使って、完全なURLをコピーし直してください。末尾のパラメーターが欠けていないか、空白や説明文が混ざっていないか確認します。Webの管理画面や説明書のURLはサブスクリプションのURLと似ていることがありますが、用途は異なります。ブラウザーでページを開けても、そのページをサブスクリプションとしてインポートできるとは限りません。URL内の単語から形式を推測せず、サービス提供元の案内に従ってください。

サブスクリプションのURLにはアクセス情報が含まれる場合があるため、パスワードと同様に安全に管理してください。問い合わせの際に完全なURLを公開したり、よく分からないオンライン確認ツールに貼り付けたりしないでください。返された内容の種類、エラーコード、表示された文言を伝える場合も、アカウントを特定できるパラメーターは隠します。URLが漏れた疑いがある場合は、まずご自身のサービス提供元の管理画面などから対処し、その後アプリに保存したURLを更新してください。

手動で一度更新し、項目名が変わったかだけでなく、アプリに表示される結果を確認してください。サービス提供元が項目名を変えずに設定だけを変更する場合もあります。反対に、ローカルに古い項目が表示されたままでも、今回のリクエストが成功したとは限りません。更新前に元のグループと選択中の項目を記録し、更新後に内容を照合すると、どの段階で変化したか分かります。

リクエストの失敗と返却内容の不一致を区別

接続できない、タイムアウト、ドメインの名前解決に失敗するなどの表示が出た場合は、まず現在のネットワークから基本的なアクセスができるか確認します。次に、サブスクリプションのドメインへ特定の接続条件でしかアクセスできないか確認してください。利用可能なサーバーをすでにお持ちの場合は、サービス提供元が認める条件の範囲で、接続の前後に更新結果を比較できます。更新のために、提供元が分からない構成を何度も追加しないでください。ネットワークへのアクセスと返却内容は別々に確認し、すべてを形式の問題と決めつけないようにしましょう。

サーバーからログイン画面、認証画面、エラーページ、空の内容が返された場合、アプリがサブスクリプションとして認識できないことがあります。ステータスコードは原因の手がかりになりますが、返された内容の確認に代わるものではありません。正常な応答でも、想定したデータではなくWebページが返ることがあります。アクセス拒否の表示が出た場合は、URLが有効か、自分のサービスが利用可能な状態かを確認します。認証情報が正しいと確認できるまでは、リクエストを何度も繰り返さないでください。

形式が一致しない場合は、サービス提供元が案内するサブスクリプションの種類と、現在のインポート方法が合っているか確認してください。サーバー項目のサブスクリプションと構成ファイル全体は別の種類の内容です。どちらもURLから取得できるというだけで、同じ場所にインポートできるわけではありません。インポート後に想定していた一覧ではなく構成ファイルが表示された場合は、元の案内に戻って用途を確認してください。ファイルの拡張子を変更して解決しようとしないでください。

更新後の不具合と自動更新を確認

更新が完了したら、選択中の項目が残っているか、所属グループが変わったか、設定が置き換わったかを確認してください。サービス提供元が項目を削除した場合、以前選択していた項目が利用可能な一覧に残っていないことがあります。現在の一覧から選び直して動作を確認してください。件数が減っても、必ず解析漏れとは限りません。更新通知とサービス提供元の案内も確認し、配信内容が変更された可能性を考慮しましょう。

アプリ起動時の自動更新と手動更新では、開始するタイミングが異なります。起動のたびにエラーが起きる場合は、関連する自動更新の設定を一時的にオフにし、手動更新で処理の流れを確認して記録してから元に戻してください。起動時だけ失敗して少し時間をおくと手動更新できる場合は、起動直後に基本ネットワークの準備ができていない可能性があります。まずネットワークの状態を確認し、すぐにサブスクリプション全体を削除しないでください。

サブスクリプション由来の項目を手動で編集していた場合、更新後の変化はサーバーから再度書き込まれた内容による可能性があります。個別のカスタム設定を残す必要がある場合は、アプリがローカル編集とサブスクリプション更新をどう扱うかを確認し、必要なコピーを保存してください。サブスクリプション項目への一時的な変更を確実なバックアップとして扱わないでください。復元に必要なのは、有効な元のURL、ご自身のサービス情報、構成の差分を明確に記録したものです。

サブスクリプションの追加し直しは、URLと形式を確認した後に行います。まず古い記録を残し、テスト用の項目には区別しやすい名前を付けてください。更新に成功したことを確認してから重複分を整理します。新旧どちらも失敗する場合、古い項目を削除してもリクエスト経路は改善しません。更新方法の詳しい説明はサブスクリプションの手動更新と自動更新、初回のインポート手順ははじめにをご覧ください。

速度低下・接続の中断：条件をそろえて原因を特定

Webページの表示が遅い、動画が途切れる、ファイル転送が遅い、接続が頻繁に中断する――これらはそれぞれ異なる指標です。一度の接続テストの応答時間だけでは、継続的な転送性能は分かりません。1つのファイルの速度だけで、すべての通信を判断することもできません。まず症状を具体的に記録してください。最初の表示まで時間がかかるのか、開始後の転送量が少ないのか、しばらくすると停止するのかを区別すると、名前解決、通信経路、接続先、デバイスのどこを調べるか決めやすくなります。

再現できるテスト条件を整える

ご自身が適切にアクセスでき、内容が比較的安定している接続先を選び、近い時間帯にテストしてください。ネットワークの種類、選択中のサーバー、ルーティング方式、バックグラウンドで転送しているかを記録します。アプリの更新、写真の同期、大きなファイルのダウンロードを同時に行い、その結果から接続速度を判断しないでください。ほかのデバイス作業がネットワークや処理能力を使うため、テストに関係のない大容量通信を一時停止して、影響を減らしましょう。

2回の結果を比べるときは、接続先と操作をそろえてください。初回のページ表示ではドメインの名前解決、接続の確立、リソースのダウンロードが必要ですが、2回目はキャッシュが使われることがあります。そのため、2回目が速くても、直前に変更した設定が原因とは限りません。対象への既存の接続を閉じて再テストするか、同じ順序で何度か試して傾向を見てください。最も速い結果や遅い結果だけで結論を出さないようにしましょう。

接続をオフにしても、直接アクセスできるはずの同じ接続先が遅い場合は、基本ネットワークと接続先のサービスを優先して確認します。Wi-Fiの電波が強くても、上流の回線に空きがあるとは限りません。ルーターの負荷やネットワークの混雑も実際の速度に影響します。別の信頼できるネットワークで比較するときは、同じサーバーと接続先を使ってください。ネットワークだけを変えて改善した場合は、まず元のネットワーク環境を調べましょう。

応答時間と実際の転送速度を区別

Connectivity Testは、そのテストが完了したかどうかを確認するためのものです。数値を単純に並べて、ある項目がどの用途にも最適だと判断しないでください。Webページは複数のドメインやリソースで構成され、継続的な転送は出口の帯域、接続先の負荷、通信経路の品質にも左右されます。応答時間が短くてもファイル転送が遅い場合や、応答時間が長くても転送が安定する場合があります。実際に使う接続先で確認してください。

1つの接続先だけが遅い場合は、まず想定したポリシーが適用されているか、リソースのドメインが別の出口を経由していないか確認します。ページのメインドメインにアクセスできても、画像、ログイン、メディアのリソースが同じ経路を通るとは限りません。接続ログで失敗したリクエストや繰り返し再試行されているリクエストを探してください。1つのページを改善するためにすべてのルールを同じポリシーに変更すると、原因を細かく特定できなくなります。

自分が利用できる項目が複数ある場合は、同じ時間帯に同じ接続先をそれぞれテストしてください。1つの項目だけが継続して遅い場合は、そのサービスの状態を確認して、ご自身のサービス提供元に問い合わせます。すべての項目が遅い場合は、ローカルネットワークや接続先に共通する原因も考慮してください。複数の項目を同時に頻繁に接続するのではなく、順番に比較すると、結果と出口を対応させやすくなります。

通信の中断、長時間接続、ネットワーク切り替えを確認

Wi-Fiからモバイル回線に切り替わると、ネットワークアドレスや経路が変わり、確立済みの通信を再接続する必要が生じることがあります。一度短く停止しただけで、すぐプロトコル設定を変更しないでください。ネットワークが安定してから同じ操作をやり直します。切り替えの瞬間だけ失敗し、接続が安定した後は正常なら、継続的なサーバー接続不能ではなく、ネットワーク切り替え時の現象として記録してください。

一定時間後に中断する場合は、おおよその経過時間、画面ロックの有無、ネットワークを切り替えたか、スイッチがオンのままかを記録します。長時間の通信が途切れる問題とトンネルが切れる問題では、確認すべき箇所が異なります。前者は接続先、転送、セッションの復旧を、後者は権限、On Demand、システム状態を確認してください。デバイスが熱くなっている場合やバックグラウンド処理が多い場合は、環境を落ち着かせてから同じ条件で再テストします。

MTUなどの低レベルの設定を、経験だけを頼りにまとめて変更しないでください。再現性のある特定の症状があり、サーバー側やネットワーク側の根拠もある場合に限り、コピー上で1項目ずつ比較し、変更前の値と結果を記録します。複数の設定を無作為に変更すると、たまたま成功しても原因を確認できません。明確な根拠がない場合は、電波状況、同時実行中のタスク、ルールの適用状況、サーバーの状態を先に調べたほうが、原因を特定しやすくなります。

最後に、ネットワーク、接続先、項目、操作、再現するかどうかを簡潔に記録してください。ご自身のサービス提供元への問い合わせでは、一時的な速度測定のスクリーンショットだけでなく、これらの条件を優先して伝えます。テスト後は自動更新と通常のルーティング設定に戻し、不要な連続テストを停止してください。速度テストを続けること自体が通信量と電池を消費し、確認中のネットワーク負荷も変えてしまいます。

DNSの問題：名前解決の経路とルールの適用を確認

DNSはドメイン名をアドレスに変換しますが、ドメインにアクセスできない原因が必ず名前解決とは限りません。接続の確立、TLSの検証、接続先からの応答の失敗でも、Webページが開けないことがあります。まず、表示されたエラーに名前解決の失敗が明記されているか確認し、アプリの名前解決設定とリクエストの記録を照合してください。数値のアドレスを直接入力してWebページを開く方法は、同じ条件のテストにはなりません。証明書、仮想ホスト、リソースのドメインが元の名前に依存することがあるためです。

ドメイン名とアドレスの関係を確認

問題が起きているドメインを記録し、そのドメインだけが失敗するのか、新たに名前解決が必要な接続先すべてで失敗するのかを確認します。以前開いたページにアクセスできても、DNSが正常とは限りません。既存の接続やキャッシュされたアドレスを再利用している可能性があります。反対に、1つのドメインだけが失敗する場合は、そのドメインのレコード自体が変更された可能性もあります。別のドメインでも比較し、失敗が特定の接続先やネットワークに集中しているか確認してください。

現在の構成にあるDNS設定を確認する前に、コピーを保存し、どの構成が使われているか、上書き設定や条件別の名前解決経路がないかを確認してください。ファイル内に見つけたアドレスを1つ変えただけで、すべてのリクエストに反映されたと思い込まないでください。構成ファイルが有効になっていない場合や、アプリに別の関連設定がある場合もあります。静的なテキストだけでなく、実際の診断情報を見て判断しましょう。

DNSリゾルバーのアドレス自体がドメイン名の場合は、最初にその名前がどのように解決されるかも確認します。安全な接続を確立する名前解決方式では、接続先への到達性と名前の検証も関係します。リゾルバーを追加しても成功率が上がるとは限らず、待ち時間が増えたり、結果が一致しなくなったりすることがあります。自分で理解し、動作を確認できる設定を使い、よく分からないアドレス一覧を万能な解決策として扱わないでください。

名前解決の結果とルーティングルールを合わせて確認

ドメインルールは名前の条件を判定し、IP-CIDR、IP-CIDR6、GEOIPなどのルールはアドレスやその所属に関する条件を判定します。これらは異なる段階で最終ポリシーに影響することがあります。同じドメインでも、名前解決の結果が異なれば、アドレスルールの適用結果が変わる可能性があります。そのため、「名前解決できたか」だけでなく、「どのアドレスに解決され、その結果どの出口に振り分けられたか」も確認してください。

接続ログに想定外のポリシーが表示された場合は、ドメイン条件の記述ミス、先行するルールによる上書き、末尾のFINALのポリシーを確認します。DOMAIN-SUFFIXはDOMAINとは一致する範囲が異なり、DOMAIN-KEYWORDはより多くの名前に一致する可能性があります。1つの接続先を直すために範囲の広すぎるキーワードルールを追加すると、無関係なリクエストまで変わることがあるため注意してください。

ローカルアドレスのルールがある場合は、デバイスの実際のサブネットとサービス名を確認してください。ローカルネットワーク上のデバイス名の解決は、接続中のネットワークが提供する仕組みに依存することがあります。遠隔地のリゾルバーが家庭内デバイスの名前を解決できるとは限りません。家庭内デバイスだけにアクセスできず、一般的なWebページは開ける場合は、名前とデバイスの実際のアドレスで違いがあるかを比較し、ローカルネットワークの経路と関連する権限を確認します。

IPv6、キャッシュ、ネットワークの違いを確認

ドメインによっては複数のアドレスファミリーの結果が返されます。現在のネットワーク、サーバー、接続先がそれぞれの経路に対応しているかも影響します。断続的に失敗する場合は、特定の種類のアドレスが返されたときに失敗するか観察できますが、IPv6アドレスが表示されたというだけで原因と決めつけないでください。元の構成を残して比較し、アプリにある関連項目の意味を確認します。毎回1項目だけ変更し、テスト後は元に戻すか、変更を維持する理由を記録してください。

名前解決設定を変えた後も、古いキャッシュや既存のセッションが使われることがあります。新しい接続を確立してから接続先に再アクセスし、必要なら対象のアプリを通常の方法で終了して開き直し、古い状態の影響を減らしてください。最初のテストで失敗したからといって、設定に効果がないと判断したり、キャッシュが一度使われたからといって解決したと判断したりしないでください。同じ条件で複数の新しいリクエストが安定して完了するかを確認してから、変更を残すか決めましょう。

同じ構成があるWi-Fiでは正常で、別のネットワークでは失敗する場合は、元のネットワークで認証が必要か、異なる名前解決環境が使われているか、リゾルバーに到達できるかを確認してください。ネットワークを切り替えるときも、サーバーと接続先は同じにします。名前解決エラーが解消しても接続に失敗するなら、転送の段階を引き続き確認してください。すべての症状を1つのDNS設定で説明しようとせず、複数の問題がある可能性も考慮しましょう。

元に戻す場合は、以前に動作を確認した名前解決設定に戻し、必要な変更を1つずつ加えてください。問題のドメイン、エラーの正確な文言、ネットワークの種類、適用されたポリシーを記録すれば十分です。閲覧履歴全体を公開する必要はありません。関連用語は用語集で確認できます。DNSの処理が成功してもリクエストに失敗する場合は、サーバー設定またはルールの章に戻り、正常な名前解決設定を繰り返し変更しないようにしてください。

電池消費・アップデート後の不具合：基準を残して比較

接続中に電池消費が増えた場合は、通信量、電波状況、再試行、デバイスの処理を合わせて確認する必要があります。システムのバッテリー情報に表示されるアプリの使用割合は、追加の電池消費を直接測定した値ではありません。割合だけを見て構成の異常と決めつけないでください。アップデート後の問題も同様に切り分けます。アプリ、システム、サブスクリプションの更新、構成の変更が近い時期に行われても、影響する内容は異なります。まず変更の順序を整理してください。

電池消費時に実行していた処理を確認

まずシステムのバッテリー情報で該当する時間帯を確認し、動画再生、ファイル同期、大量のダウンロード、電波の弱さが関係していないか調べます。トンネル経由の通信処理はデバイスの使用状況と合わせて電池消費に影響します。接続をオンにした時間だけでは消費量を推定できません。比較時は画面の明るさ、ネットワーク、使用内容、時間をできるだけそろえ、待機中と再生中を比較しないようにしてください。

ほとんど操作していないのに発熱が続く場合は、更新処理の繰り返し、頻繁な接続テスト、失敗したリクエストの再試行がないか確認します。自分で設定した自動処理を一時停止し、通常の接続だけで比較してください。改善した場合は1つずつ戻して、きっかけを特定します。すべての機能を一度にオフにしても、特定のプロトコルが電池消費の原因だとは判断できません。同時に動いているタスクやネットワークの再試行が主な違いかもしれません。

電波環境とネットワークの切り替えも確認します。不安定なネットワーク間をデバイスが何度も切り替えたり、到達できない接続先への接続を長時間試みたりすると、追加の処理が発生することがあります。安定した利用可能なネットワークに切り替え、同じ構成で確認してください。明らかな発熱が続く場合は高負荷のテストを止め、デバイスの状態が落ち着いてから記録を続けます。テスト自体が電池消費や発熱の原因にならないようにしましょう。

アップデート後は、何が更新されたかを特定

最近変更されたのがアプリ、システム、サブスクリプション、手動編集した構成のどれかを記録してください。サブスクリプションの更新でサーバー設定が置き換わることがあり、構成の更新でルールが変わることもあります。アプリの更新によって、ご自身のサービスの状態が同期されるわけではありません。選択中のサーバー、有効な構成、Global Routingが以前と同じか確認します。「更新後に使えなくなった」ように見えても、実際には現在の選択項目が変わった後に起きていることがあります。

アプリの入手とアップデートはApp Storeから行います。正規のアプリか確認するには、デベロッパ名がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認してください。手順は正規アプリの確認方法をご覧ください。システム要件はApp Storeのページに記載された内容をご確認ください。画面の見た目だけでアプリの入手元を判断したり、確認できていない構成内容でアプリの正当性を判断したりしないでください。

変更前は元の構成で正常だった場合は、保存したコピーと比較し、ルールの変更かサーバー自体の問題か確認してください。バックアップ内のサーバーもすでに利用できなくなっている可能性があるため、「古い構成でも失敗した」だけではアプリのアップデートが原因とは限りません。基本ネットワーク、サービスの状態、簡素化した構成を合わせて確認し、時間が近いことだけで原因を推測せず、再現できる最小限の条件を探してください。

リスクを抑えた順に復旧し、状況を伝える

保存していない編集があれば先に保存し、アプリを通常の方法で終了して開き直します。その後、ネットワークが安定した状態で接続を一度確立し直してください。システムのアップデートが完了したばかりの場合は、デバイスを再起動して再テストできます。ただし、再起動は一時的な状態を整理するための比較手順であり、どの不具合にも当てはまる解決策ではありません。復旧後は自動更新、On Demandのルール、ルーティング設定も確認し、一時的な変更で普段の使い方が変わっていないか確かめてください。

問題が特定の構成だけで起きる場合は、そのファイルをコピーして最近追加した部分を少しずつ取り除くほうが、すべての設定を消去するより原因を特定しやすくなります。サーバーのパスワード、鍵、識別情報を含む元ファイルを公開しないでください。必要最小限のルール、エラーの正確な文言、再現手順を残します。ある設定項目を削除して復旧した場合は、その項目をさらに細かく確認し、すぐに構成全体を置き換えないでください。

再インストールの前に、有効なサブスクリプションURL、必要なサーバー情報、ローカルのカスタム設定を手元に確保してください。App Storeからアプリを入手し直しても、すべてのローカルデータが自動的に復元されるわけではありません。購入記録と構成のバックアップは別のものです。手順はデバイス変更・再インストール後の復元をご覧ください。データを復元できると確認できていない場合は、現状を保ち、削除を伴わない確認を続けてください。

問い合わせる際は、実際のシステムとアプリの情報、変更の順序、再現手順、すでに確認した結果を記載してください。「アップデート後に壊れた」だけでは情報が足りません。このページではアプリのバージョンやアップデート日時を固定して掲載していません。最新の公開情報はApp Storeのページをご確認ください。電池消費については、同じ条件で使用した時間帯とタスクを、接続についてはスイッチの状態とエラーの正確な文言を添えてください。異なる症状を1つの結論にまとめないようにしましょう。

iPadでの確認：デバイス、ネットワーク、構成の違いを切り分ける

同じサブスクリプションがiPhoneでは正常で、iPadでは問題が起きる場合も、すぐにそのサブスクリプションがiPadに対応していないと判断しないでください。2台で接続しているネットワーク、使用中の構成ファイル、ルーティング設定、サーバー項目が異なる場合や、更新した時期の違う内容が保存されている場合があります。「同じ」と考える要素を具体的な設定に分けて、1つずつ比較してください。iPadのシステム要件と互換性はApp Storeのページに記載された内容をご確認ください。

アプリとシステムの状態をそろえる

iPadで該当するApp Storeの製品ページを開き、アプリの識別情報と互換性を確認してください。購入と入手の手順はiPadでの利用についてをご覧ください。同じアカウントの購入記録と、このデバイスに保存された構成は別のものです。インストールが完了しても、ご自身のサブスクリプションやサーバー情報がインポート済みか確認する必要があります。別のデバイスで正常に動作していることを、このデバイスにも必要な設定がすべて揃っている証拠と考えないでください。

初回接続時には、システムのVPN許可も必要です。画面サイズによってレイアウトが異なる場合は、Home、Config、Settingsなど、画面に表示される英語の項目名を目印にしてください。iPhoneでのボタン位置だけを覚えて操作しないようにしましょう。画面分割やウインドウ幅の変更で表示範囲は変わることがありますが、確認する順序は同じです。まず選択中の項目、次に構成とルーティングを確認し、最後に接続して実際にアクセスできるかを確かめます。

Wi-Fi専用のiPadでは、同じデバイスでモバイル回線と比較できません。可能であれば、別の信頼できるWi-Fiで試してください。モバイル回線に対応したデバイスでは、切り替え前後の結果を記録します。iPhoneとiPadを比較する際は、できるだけ同じネットワークに接続し、近い時間にテストしてください。一方がモバイル回線、もう一方が認証前のWi-Fiに接続している状態で、デバイスの違いが原因だと判断しないようにしましょう。

名前だけでなく設定内容を比較

2台それぞれで、選択中のサーバーアドレス、ポート、プロトコルを確認し、有効な構成とGlobal Routingも照合してください。表示名が同じでも、特に複数回インポートした場合、手動編集後、サブスクリプション更新後は異なる項目である可能性があります。iPadの内容をすべて上書きしないでください。まず違いを記録し、必要ならコピー上で1項目だけ変更して、症状が変わるか確認します。

両方のデバイスで同じタイミングのサブスクリプション更新が完了しているか、返された内容が同じか確認してください。一方に古い設定が残り、もう一方が更新済みの場合、内容の時期の違いが原因かもしれません。問題が起きているデバイスで手動更新し、結果を確認してから、現在利用できる項目を選び直してください。更新自体に失敗した場合はサブスクリプションの章を確認し、内容が異なる2台をそのまま比較しないでください。

特定の接続先で1台だけ失敗する場合は、そのデバイスにローカルルール、異なる名前解決設定、別のシステム構成がないか確認してください。ファイルを同期しても、すべてのアプリ設定が含まれるとは限らず、システムの許可も完全に同じとは限りません。設定を合わせるときは元の値を残し、「完全に同じ」にするためだけに、ローカルネットワークや仕事環境で必要な設定を削除しないでください。

ローカルネットワーク、On Demandの条件、長時間の利用を確認

iPadを同じWi-Fiで長時間使う場合、印刷、画面共有、家庭内ストレージへのアクセスでは、ローカルネットワーク経由と外部ネットワーク経由を区別する必要があります。これらの機能だけに問題がある場合は、まず接続をオフにして比較し、デバイスの実際のアドレスとサブネットを確認してから、関連ルールとシステムのローカルネットワーク権限を調べてください。ローカルサービスを復旧させるために、すべてのインターネット通信をDirectに変更しないでください。

On Demandの条件は、現在のiPadが接続している実際のネットワークに合わせて確認してください。同じ条件をコピーしても、2台が使っているWi-Fi、ネットワークの種類、ドメインの判定状況が異なる場合があります。自分で設定したOn Demandの条件を一時的に無効にし、手動スイッチで基準を確認してから、条件を1つずつ戻してテストします。条件設定の考え方はOn Demandの設定をご覧ください。

長時間画面をロックした後にアクセスできない場合は、スイッチがオンのままか、システムのVPNが接続中か、接続先を開き直すと復旧するかを確認してください。古いセッションが無効になっただけなのか、接続全体が停止したのかは別の問題です。バックグラウンド接続が使えないとすぐに判断せず、画面ロックの前後でネットワークが変化したかを記録します。画面分割中にほかのタスクを実行しているとネットワークを使うことがあります。速度を測るときはデバイスの負荷をそろえてください。

最後に、同じネットワーク、同じ項目、同じ構成、同じ接続先を使い、各デバイスでどうなったかを記録してください。基本条件をそろえても差が安定して再現する場合は、システム情報とエラーの正確な文言をまとめて問い合わせます。簡潔な解説はよくある質問をご覧ください。手順を最初から確認する場合ははじめにに戻り、インポート、ルーティング、許可、動作確認の順に進めてください。