公式ガイド · トラブルシューティング

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

まず、問題がどの段階で起きているかを確認し、該当する設定を見直してください。このページでは症状別の確認手順を紹介します。初回接続がまだの場合は、先にクイックスタートガイドに沿って操作し、具体的な結果を確認してから該当する項目に進んでください。以下では、ご自身で用意したサブスクリプションまたはサーバー情報があることを前提としています。サーバーやサブスクリプションの提供・販売・推奨は行っていません。

iPhone / iPad向けです。システム要件はApp Storeのページをご確認ください。画面上の用語は英語表記のまま記載しています。項目の位置や利用できるオプションは、実際の端末の表示に従ってください。ここで紹介するテスト結果は原因の切り分けに使うもので、接続先の利用可能性を保証するものではありません。

[General]

スイッチが入らない、すぐ切れる、接続を繰り返す

システムの許可設定とサーバーの問題を切り分ける

Homeで接続スイッチをオンにしたとき、VPN構成の追加を許可するかシステムから確認されたら、内容を読んだうえで、ご自身の判断で許可し、端末の認証を完了してください。この操作は接続に必要な構成をシステムに追加するもので、購入確認やサブスクリプションの読み込みではありません。以前この確認をキャンセルした場合は、アプリに戻って接続を再試行してください。端末が管理対象の場合、VPN構成の追加が制限されることがあります。その場合は端末の管理者に確認してください。サーバーアドレスを何度も変更しても解決しません。

スイッチの動作を確認してください。接続状態にならない場合は、まず許可設定と端末の制限を確認します。一時的に接続状態になってから切れる場合は、設定内容、ネットワークへの到達性、接続中のエラーが関係している可能性があります。オンのままなのにWebページが表示されない場合は、次の章に進んでください。システムのステータスバーの表示でわかるのは接続状態の一部だけで、リクエストが接続先に届いたことまでは確認できません。「開かない」と一括りにせず、状況を分けて記録すると原因を絞り込みやすくなります。

システムの接続設定と自動接続条件を確認する

システムのSettingsを開き、「VPN」を検索して、Shadowrocketの構成があるか、ほかのVPN接続が使用中かを確認します。不要な接続を手動で切断してからHomeに戻り、テストしてください。システムのネットワーク構成をすべて削除しないでください。仕事や学校で必要な設定が含まれている場合があります。VPNの項目を編集できない、管理対象と表示される、または構成追加をシステムに拒否される場合は、Configを調整するのではなく、まず端末の管理上の制限を確認してください。

スイッチをオフにした後、勝手にオンへ戻る場合は、On Demandが有効かどうか、現在のネットワークが接続条件に該当するかを確認してください。手動で接続するテストの基準を作るため、一時的にOn Demandをオフにして試すことができます。テスト後は、記録しておいた状態に戻してください。自動接続と手動スイッチが同時に動作していると、「何度もオンになる」現象がアプリの不具合とは限りません。システム側に自動接続条件が設定されていないかも確認し、アプリ内の設定だけを変更して判断しないようにしてください。

変更を最小限にして再現可能なテストを行う

まず、接続を切った状態で端末が正常にインターネットへ接続できることを確認してください。認証が必要なWi-Fiでは、先に認証ページで手続きを完了します。その後Homeに戻り、既存のサーバーのうち、必要な設定がそろっているものを一つ選んで接続します。Configの読み込みエラーがある場合は、表示された内容と使用中のConfigを確認してください。スイッチのオン・オフを繰り返してエラーを隠そうとしないでください。動作確認済みの簡易な設定を比較用に使う場合も、元の設定ファイルを保存し、切り替え前後の名前とGlobal Routingの状態を記録してください。

Wi-Fiだけで失敗する場合は、モバイルデータ通信の利用が許可され、通信量にも問題がないことを確認したうえで、同じサーバーを使ってテストしてください。逆の場合も同様です。サーバー、設定、接続先を変えずにネットワークだけを変え、結果も変化するなら、まず接続ネットワークを調べます。どちらのネットワークでも同じ段階で失敗する場合は、サーバーの設定とサービスの状態を確認してください。サブスクリプションの更新、Configの切り替え、ネットワークの変更を同時に行うと、復旧しても何が有効だったのか判断できません。

システム構成を作り直すタイミング

ここまで確認しても接続できない場合は、いったん切断し、アプリを通常の手順で終了してから再度開いてください。必要に応じて端末を再起動し、もう一度試します。システムのVPN構成に問題があると確認でき、バックアップと復元方法も把握している場合に限り、Shadowrocketの構成を削除して、アプリから再追加を求める方法を検討してください。システム構成を削除しても、サーバー、サブスクリプション、ルールがバックアップされたことにはなりません。認証のやり直しを設定の復元と混同しないでください。再度許可した後も、Homeで選択中の項目を確認してください。

[Rule]

接続済みと表示されるのに、すべてまたは一部の通信に失敗する

まず基本のネットワークを確認し、次にリクエストの経路を調べる

Shadowrocketを切断し、同じ端末・同じネットワークで、普段アクセスできるページを開いてください。それでも失敗する場合は、Wi-Fiの認証、モバイルデータ通信の許可、ルーター、接続ネットワークの問題を先に解決します。基本のネットワークが復旧してから接続をオンにし、接続環境の問題をルールの問題と取り違えないようにしてください。特定のアプリだけで問題が起きる場合は、ブラウザーで別の接続先を開いて比較します。アプリ独自のセッションキャッシュ、ドメイン群、接続方式が影響することもあるため、一つのアプリだけでネットワーク全体の障害と判断しないでください。

Homeに戻り、リストに利用可能な項目があるかだけでなく、現在選択されているサーバーを確認してください。リスト更新後に選択中の項目が変わっている場合があります。名前が似ていても同じ設定とは限りません。次にGlobal Routingを確認します。ConfigはConfigに対応し、プロキシはProxy、直接接続はDirectに対応します。この3つの状態によって主なリクエストの処理方法が決まりますが、いずれも、すべてのDNS、システムの動作、接続先Webサイトの状態を証明するものではありません。

状態	確認できること	判断上の注意
Config / Config	現在のConfigに基づいてルールとポリシーを確認します。	実際に有効なConfigと適用記録をあわせて確認してください。
Proxy / Proxy	Configと比較し、サーバー経由の通信経路を確認します。	成功しても、元のConfigにあるすべてのルールが正しいとは限りません。
Direct / Direct	プロキシサーバーを経由しない場合のリクエストと比較します。	VPNを完全に終了した状態や、すべてのDNS設定を元に戻した状態とは異なります。

状態を切り替えて原因を絞り込む

同じテストページとサーバーを使い、まずConfigでの結果を記録してから、一時的にProxyに切り替えて再試行します。Proxyでは利用でき、Configでは利用できない場合、すぐサーバーを変更するのではなく、そのリクエストに適用されたルールと最終ポリシーを確認してください。どちらの状態でも失敗する場合は、サーバーへの接続、DNS、接続先の状態を調べます。テスト後は元の状態に戻してからページを再度開いてください。古い接続が再利用されることがあり、一度の再読み込みでは新しい経路を使ったとは限りません。

DirectではアクセスできるのにProxyでは失敗する場合、まずサーバー経由の経路を調べます。ただし、ドメイン解決の違いやプロトコル設定の誤りも確認が必要です。DirectとProxyの両方で同じ接続先にアクセスできず、ほかの接続先は正常な場合は、接続先のWebサイトに問題があるか、その接続先が利用する共通のサービスに障害がある可能性があります。別の独立した接続先でも確認してください。同じログインサービスやリソースドメインに依存するページをいくつか試し、それぞれ別の事例として扱わないようにしましょう。

実際に適用されたルールからConfigを確認する

Configで意図したファイルが有効になっていることを確認し、失敗したリクエストのドメイン、適用されたルール、処理ポリシーを確認します。ルールは通常、記載順に評価されるため、先に一致したルールによって、後のより具体的なルールが適用されないことがあります。広範囲に一致するDOMAIN-KEYWORD、大きな範囲のIP-CIDR、意図せずREJECTを指定している項目に注意してください。以下はルールの順序を説明するための例で、利用可能なサーバー情報は含みません。使用中のConfig全体と置き換えないでください。

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

この順序では、api.example.comには先にDOMAINルールが適用され、DIRECTになります。そのほかのexample.comで終わるドメインには、次のルールでPROXYが適用されます。ローカルネットワークのアドレスとGEOIPの項目は、異なる種類のマッチ条件を示す例です。FINALは、それ以前のルールに一致しない場合の最終処理です。実際の結果は、リクエストから取得できるドメイン情報、名前解決の結果、Configのほかの項目にも左右されます。接続先の名前だけで特定のルールが適用されると決めつけず、現在のリクエスト記録を根拠にしてください。

一部のページで画像が表示されない、ログインできない

一つのページで複数のドメインにアクセスすることは珍しくありません。ページの文字は表示されるのに、画像、認証、ログインが失敗する場合は、失敗したリソースのリクエストを個別に確認してください。ページのドメインだけにルールを追加しても解決しないことがあります。まず、REJECTに一致していないか確認し、関連ドメインに異なるポリシーが適用されていないか調べます。必要性を確認したドメインにだけルールを追加し、広すぎるキーワードでほかのリクエストに影響を与えないようにしてください。ルールの用語がわからない場合は用語集を、初回接続の確認はクイックスタートガイドをご覧ください。

[General]

サーバーのタイムアウト、テスト失敗、プロトコル設定の不一致

テスト結果と実際のアクセス結果を分けて考える

Connectivity Testの結果は、テスト方法、テスト先、現在のネットワーク、サーバーの状態によって異なります。失敗しても、あらゆるリクエストが失敗するとは限りません。成功しても、すべてのWebページや通信方式が利用できるとは限りません。まず選択中の項目を確認し、接続先を一つ決めて実際にアクセスし、テスト結果と一致するか記録してください。テスト先自体に到達できない場合は、テストが失敗しても一部のサービスは利用できることがあります。結果だけを理由にサーバーを削除せず、テスト設定を確認してください。

接続タイムアウト、接続拒否、認証エラー、証明書に関するメッセージを区別してください。タイムアウトは、一定時間内に必要な応答を受け取れなかったことを示しますが、それだけではサーバーの停止、ポートへの到達不能、名前解決の誤り、中間ネットワークでのパケット損失のどれが原因かはわかりません。接続拒否と認証エラーはそれぞれ異なる手がかりになるため、元のメッセージを記録してください。画面に詳しいエラーが表示されない場合は、すぐに失敗するのか、しばらく待ってから失敗するのかも記録しておくと、後で比較できます。

共通項目を確認してからプロトコル固有の項目を調べる

対象項目の編集画面、またはAdd Serverを開き、利用中のサービスの提供元から受け取った元の情報と照合してください。まず種類、Address、Portを確認します。アドレス欄に不要なパス、前後の空白、別のプロトコルリンクの内容が混ざっていないこと、ポートがそのサービスの指定と一致していることを確認してください。サーバー名は識別用のラベルにすぎず、名前を変更してもアドレスや認証の問題は解決しません。自動インポートした項目も、取り込み後の各フィールドを確認してください。スキャンやサブスクリプションの読み込みに成功しても、設定の組み合わせが必ず利用できるとは限りません。

プロトコル	確認する項目	よくある誤解
Shadowsocks	Address、Port、Password、Method。	Passwordが正しくても、Methodが一致しないと失敗することがあります。
VMess / VLESS	UUID、通信方式、TLS、サーバー側で指定された追加項目。	別の項目の通信パラメーターを流用しても、必要な設定はそろいません。
Trojan	認証情報、TLS、サーバー名、通信設定。	接続先アドレスと証明書の検証名を同じ項目だと考える。
Hysteria2	認証情報、TLS、現在のネットワークでのUDP到達性。	通常のWebページを開けても、該当するUDP経路が使えるとは限りません。

UUID、Password、Method、Host、Path、サーバー名などは、すべて同じ有効な設定に基づいて入力してください。別々の項目から寄せ集めてはいけません。通信方式によっては特定のパスやホスト名が必要で、これらは任意のメモではありません。大文字・小文字、スラッシュの有無、TLSの有効・無効も接続に影響します。VMessとVLESSの項目の違いはプロトコル項目の比較記事も参考になりますが、最終的には利用中のサーバー設定の指定に従ってください。

証明書や時刻のエラーを回避しない

TLS関連のエラーが出た場合は、まず端末の日付と時刻が正しいか確認し、サーバー名が証明書と一致しているかを調べます。接続先のアドレス、TLSの検証名、通信層のHostはそれぞれ異なる役割を持つ場合があります。見た目をそろえるために、すべてを同じ値に変更しないでください。証明書の期限切れや名前の不一致がある場合は、利用中のサービスの提供元にサーバーの状態を確認します。証明書検証を無効にすると安全性の条件が変わるため、一般的な修正方法として使わないでください。また、それで元の設定が正しかったと判断することもできません。

テストを繰り返すのではなく、ネットワークと項目を組み合わせて確認する

同じ項目を変えずに、利用可能な2つのネットワークでそれぞれ一度ずつテストします。次に、同じネットワークで、既存の項目のうち利用可能と確認済みの別のものを選んで比較します。すべての項目が一つのネットワークだけで失敗する場合は、そのネットワークの通信制限や品質を優先して確認します。一つの項目だけが異なるネットワークでも失敗する場合は、その項目の設定とサービスの状態を調べてください。UDPを使うプロトコルは、該当するネットワーク条件も個別に確認します。通常のWebページを開けるだけでは、その通信経路が正常とは判断できません。

利用中のサービスの提供元に問い合わせる場合は、プロトコルの種類、失敗した段階、ネットワークの種類、個人情報を伏せたエラーメッセージを伝えれば十分です。サブスクリプション全体、UUID、Password、QRコード、認証情報付きリンクを公開しないでください。サブスクリプションの更新後に問題が始まった場合は、まず項目の変更点を比較し、元の項目に戻すか、サーバー側の修正を待つか判断します。安定したテスト結果が得られたら、短時間に何度も再試行せず、再現可能な事例を一つ記録してください。繰り返しテストしても、遠隔サーバーの認証やポート設定は修正されません。

[General]

サブスクリプションの読み込み失敗、更新後に空になる、項目が重複する

サブスクリプションのURL、サーバーリンク、Configを区別する

サブスクリプションは通常、サーバー項目の取得や更新に使います。Configはルールや関連設定に使うため、どちらもテキストだからといって同じ読み込み方法で扱うことはできません。まず、手元の情報がサブスクリプションのURL、単一サーバーのリンク、QRコード、設定ファイルのどれかを確認し、アプリで実際に用意されている対応する方法を使ってください。読み込みに成功したという表示は、その手順で内容が受け付けられたことを示すだけで、ネットワーク接続やサーバー認証が通ったことまでは意味しません。初回追加の手順がわからない場合は、先にクイックスタートガイドに沿って、いずれか一つの方法で読み込んでください。

利用中のサービスの提供元から完全なURLをコピーし直し、改行、日本語の句読点、空白、説明文が混ざっていないか確認してください。リンク内の認証情報は機密情報です。公開スクリーンショットや誰でも使えるテキスト処理サービスで確認しないでください。内容が完全かどうかだけを比較し、疑問符以降のパラメーターをむやみに削除しないでください。サブスクリプションを識別する情報が含まれている場合があります。URLが無効になっている場合は、認証情報を推測したり書き換えたりせず、利用中のサービスのアカウントページで状態を確認してください。

リクエストの失敗と、内容を解析できない問題を区別する

サブスクリプションのURLに接続できない場合は、現在のネットワークからサブスクリプションのサーバーに到達できるかを確認します。リクエストは成功しても解析エラーになる場合は、返された内容を重点的に確認してください。ログインページ、エラーの説明、アカウントの状態に関するメッセージがWebページとして返されることもあります。リクエストに成功しても、サブスクリプションのデータが返されたとは限りません。ステータスが正常に見える場合も、エラーメッセージをあわせて判断してください。HTMLページを設定ファイルとして保存して読み込み直さないでください。取得時の問題が形式エラーに置き換わり、最初の原因がわかりにくくなります。

利用可能な接続を経由しないとサブスクリプションを取得できない場合は、どの経路を使用するか確認してから、一つのサブスクリプションだけを更新してください。リストにまだ利用可能な項目があるなら、先に削除しないでください。反対に、サブスクリプションのリクエストがすでに使えないサーバーを経由していると、更新が完了しないことがあります。ルールとネットワークの条件を確認したうえで利用可能な経路に切り替えて比較できますが、DirectとProxyをやみくもに切り替えないでください。各テストで実際の状態と選択中の項目を記録してください。

更新後に空になった場合は、古いデータを残す

一度の更新で項目数が大幅に減った、またはリストが空になった場合は、メッセージ、サブスクリプションの提供元、アカウントの状態を確認してから次の操作を決めてください。一時的に空の内容が返される場合もあれば、提供元の変更で項目が入れ替わる場合もあります。何度も更新すると確認に使える情報が失われます。既存の利用可能な項目とConfigのコピーを残し、今回返された内容が想定どおりか、利用中のサービスの提供元に確認するのが安全です。内容が有効でも項目の設定が変わっている場合は、古い名前で判断せず、Homeで選択中の項目を確認してください。

サブスクリプション名やサーバー名は、サービスが有効である証拠にはなりません。同じ名前でもポート、プロトコル、認証情報が異なることがあり、名前が違っていても同じサービスを指す場合があります。更新後の初回接続では、実際の項目を開いて設定を確認してください。特に、プロトコルの種類、TLS、通信に関する項目を確認します。特定の種類や項目を処理できないとアプリに表示された場合は、現在アプリが対応する範囲と、サービス提供元の指定形式を確認してください。すべての解析エラーをネットワーク品質のせいにしないでください。

重複項目と複数のサブスクリプションの管理

同じサブスクリプションを重複して追加した場合、手動で追加した項目とサブスクリプションの項目が混在している場合、複数のサブスクリプションに同じサーバーが含まれている場合は、項目が重複して表示されることがあります。まず追加元を確認してから重複項目を整理してください。名前だけでまとめて削除すると、唯一利用できる設定まで消すおそれがあります。単一の項目を削除しても、サブスクリプションの提供元側の内容は変わらず、次回の更新で再び表示される場合があります。継続的に整理する場合は、残すサブスクリプションを決め、追加元ごとに更新と削除を管理してください。同じ情報を複数の場所で繰り返し管理しないようにしましょう。

複数のサブスクリプションを使う場合は、追加元と用途を区別できるローカル名を付け、それぞれ個別に更新して結果を確認してから次に進んでください。すべてを一度に更新すると、どのサブスクリプションに問題があったのか判断しにくくなります。詳しい整理方法は複数サブスクリプションの管理記事をご覧ください。更新できても、すべての項目で接続に失敗する場合は、設定確認の章に進んでください。更新時の経路とサーバーへの接続は別の問題です。前者が成功しても、後者が正常とは限りません。

[Rule]

速度が遅い、初回表示に時間がかかる、接続が断続的に切れる

どの段階で遅くなるかを明確にする

「遅い」をいくつかの症状に分けて考えます。初回表示まで長く待つ、ページの主要部分は表示されるがリソースの読み込みが遅い、連続通信の速度が出ない、しばらく使うと止まる、ネットワークの切り替え後に一時的に使えない、といったケースです。それぞれ、名前解決、接続の確立、接続先のリソース、通信品質、既存接続の再確立が関係している可能性があります。まず再現しやすい症状を一つ記録し、テストの数値一つだけを比較しないでください。Connectivity Testの所要時間を持続的な通信速度に換算することはできず、すべての接続先での動作を示すものでもありません。

接続を切った状態で基本のネットワークを確認し、アクセス可能な同じ接続先、同じ内容、できるだけ近い時間帯で比較してください。大きなファイルを転送しながらテストを実施するのは避け、画質やページサイズの異なるものを同じ負荷として比較しないでください。モバイルデータ通信では通信量と電波の変化に注意します。Wi-Fiでは距離、電波干渉、ほかの端末の利用状況を確認してください。基本のネットワークが不安定な場合、ルールを変更しても接続環境の変動は解消しません。

条件を固定してサーバーとネットワークを比較する

設定が正しいと確認済みの既存サーバーを一つ選び、同じネットワークで互いに独立した接続先を二つ開きます。一つの接続先だけが遅い場合は、そのサービス自体か、そこまでの経路をまず確認してください。複数の接続先が遅い場合は、別の既存サーバーに切り替えて比較します。その後、サーバーを変えずにネットワークだけ変更して再テストしてください。これにより、サーバー、接続先、ネットワークに関係する違いを切り分けられます。各組み合わせのテストは必要な回数にとどめてください。頻繁な速度テストで負荷が増えると、一時的な混雑を恒常的な傾向と誤認するおそれがあります。

Configでは遅くProxyでは正常な場合は、すぐプロトコルを変更せず、ルールの適用状況と使用中のポリシーを確認してください。リソースによって経路が異なり、ページ本体は速くても、ログインや画像の読み込みが遅くなることがあります。Directが速くProxyが遅い場合も、その比較でプロキシ経由に追加の要因があることを示すだけで、クライアント側の処理に異常があるとは限りません。サーバーの状態、通信方式、ネットワーク条件を確認してから、利用中の別の項目に切り替えるか判断してください。

DNSの待ち時間、接続確立、持続的な通信速度を切り分ける

初回アクセスに時間がかかり、同じページが次回は明らかに速く表示される場合、DNSキャッシュ、接続の再利用、接続先のキャッシュが関係していることがあります。次の章で名前解決とルーティングをそれぞれ確認してください。キャッシュを消した後の一度きりのアクセスを、安定した速度の基準にしないでください。新しい接続のたびに遅い場合はTLSと通信設定を確認します。継続的な通信中に限って途切れる場合は、ネットワークの切り替わり、サーバー側の切断、特定種類の通信だけに起きる問題を確認してください。結果をすべて「タイムアウト」とまとめず、症状ごとに記録します。

通信方式によって必要なネットワーク条件は異なります。特にUDPを使う場合は、接続ネットワークでの到達性や安定性が結果に影響することがあります。ただし、プロトコル名だけで速度を判断することはできず、利用中のサーバーの設定と一致している必要があります。数値を上げるために別の種類へ変更したり、帯域幅や接続関連の項目をむやみに変えたりしないでください。設定を誤ると、利用できていた項目まで使えなくなることがあります。サービス提供元から対応する設定が明示されている場合に限り、指定された項目をすべて使って比較用の項目を別に作成してください。

ネットワーク切り替え、バックグラウンドアプリ、長時間接続

Wi-Fiからモバイルデータ通信に切り替えた後は、既存の接続を確立し直す必要がある場合があります。ネットワークが安定するのを待ってからテストページを開き直すか、アプリから新しいリクエストを送ってください。古いページが引き続き失敗しても、新しい経路も失敗するとは限りません。新しいリクエストも復旧しない場合は、On Demandの条件に変化があったか記録し、いったん切断して再接続します。ネットワークとスイッチを何度もすばやく切り替えないでください。接続の確立やキャンセルとシステム側のネットワーク変更が重なり、結果を判断しにくくなります。

速度の問題が特定の時間帯だけに起きる場合は、そのときのネットワーク、サーバー、接続先を記録し、別の時間帯に同じテストを繰り返してください。長時間続けて速度を測定する必要はありません。一つのアプリだけで起きる場合は、同期中か、古いセッションを再利用していないか確認します。状態を切り替えた後は、新しいリクエストを発行してください。関連のない大量のデータより、違いを再現できる一組の比較結果が役立ちます。既存サーバーまたは接続先までの経路に原因があるとわかったら、個人情報を伏せた結果を該当するサービス提供元に伝えてください。

[Host]

DNSの名前解決、ローカルネットワークへの接続、ルールが適用されない問題

まず、実際に名前解決が失敗しているかを確認する

Webページでサーバーが見つからないと表示される、接続の確立前にアプリが失敗する、記録に名前解決エラーがある場合は、DNSを調べます。ただし、TLSエラー、認証失敗、接続先から返されたエラーはDNSの問題とは限りません。複数の独立したドメインを比較し、一つのドメインだけか、特定の種類の内部名だけで起きているか確認してください。ドメインをIPアドレスに置き換えてアクセスしても、有効な確認になるとは限りません。HTTPSの証明書、サーバー名、仮想ホストはドメインに依存することがあり、置き換え後に失敗しても、元の名前解決が正常だった証拠にはなりません。

基本のネットワークが正常か確認し、現在のConfigにあるDNS関連の設定、[Host]の内容、システムで追加のDNS設定が使われていないかを調べます。設定箇所が複数ある場合は、まずそれぞれの由来を記録し、同時に削除しないでください。アプリ、システム、特定アプリ独自の名前解決動作は異なる場合があります。一つのリクエスト記録にドメインが表示されないからといって、名前解決がまったく行われていないとは限りません。リクエストの種類、実際の接続先、接続結果を合わせて判断し、一つの項目が記録されていないだけで設定を大幅に変更しないようにしてください。

DNSサーバーへの到達経路を確認する

カスタムDNSアドレスは、現在のネットワークと接続状態で到達可能である必要があります。DNSサーバーへの接続に特定のプロキシ経路が必要で、その経路の確立にも、まだ名前解決できていない同じサーバーのドメインが必要な場合、依存関係の問題が起きることがあります。まず到達できると確認済みの元の設定を基準として使い、DNS関連の項目を一度に一つだけ変更してください。出所がわからないDNSアドレスをいくつも追加しないでください。数を増やしても、各リクエストに信頼できる経路ができるとは限りません。

ネットワークを切り替えた後に問題が起きる場合は、以前のネットワーク専用のDNSサービスが引き続き使用されていないか確認してください。たとえば、内部名が特定のWi-FiのDNS環境でしか有効でなく、モバイルデータ通信では同じ結果を取得できないことがあります。サービス側で指定されたHostやサーバー名をDNSアドレスとして入力していないかも確認してください。変更後は該当するリクエストを再度実行し、必要なら切断してから再接続して古いセッションの影響を除外します。ただし、再接続を繰り返せばキャッシュがすべて消えるという保証はありません。

ルールは順番に評価され、ドメインとIPアドレスは別々に確認する

DOMAINは完全なドメイン名との一致、DOMAIN-SUFFIXはドメインの末尾との一致、IP-CIDRとIP-CIDR6はアドレス範囲を扱います。FINALは最後に適用する処理です。それぞれ判定に使う情報が異なるため、ドメインルールが適用されない場合は、リクエストに照合可能なドメイン情報があるか、先行するルールがすでに処理していないかを確認します。すべてのドメインルールをIP範囲に置き換えないでください。一つのドメインが複数のアドレスに解決されたり、一つのアドレスが複数のサービスに使われたりすることがあり、範囲を広げすぎるとほかの接続先にも影響します。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.com,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fc00::/7,DIRECT
FINAL,PROXY

この例は、ルールの順序による問題を示しています。blocked.example.comは先行するDOMAIN-SUFFIXルールでPROXYに一致するため、後にある同じドメインのREJECTは意図どおりに適用されません。このドメインだけに別の処理を指定する場合は、より具体的なDOMAINルールをサフィックスルールより前に置きます。Configのコピーを使って変更し、実際のリクエストで適用状況を確認してください。ここに記載したドメインは構文例で、テスト用サービスではありません。アドレス範囲のルールが適切かどうかも、実際のネットワークと現在のポリシーに照らして判断してください。

ローカルネットワークの端末と内部ドメインの確認

プリンター、家庭内ストレージ、内部サービスが接続後に使えなくなった場合は、まず接続を切って端末にアクセスできるか確認します。その後、接続先がIPアドレスか内部ドメインかを切り分けてください。アドレスには到達できるのに名前でアクセスできない場合は、まず名前解決を確認します。どちらも到達できない場合は、ローカルネットワークアドレスの処理ポリシー、ネットワーク分離、アプリの許可設定を確認してください。ブロードキャストやマルチキャストによる検出は通常のユニキャスト通信とは異なります。DIRECTルールを一つ追加するだけで自動検出が復旧するとは限らないため、既知のアドレスへのアクセスと端末検出を分けてテストしてください。

システムのSettingsで対象アプリのローカルネットワークへのアクセス許可を確認し、端末が同じローカルネットワークに接続しているか調べてください。ゲスト用Wi-Fiやネットワーク分離によって、端末同士が見えなくなる場合があります。[Host]で固定の割り当てを設定している場合は、特にネットワークを切り替えた後やルーターの割り当てが変わった後に、指定したアドレスが引き続き対象端末のものか確認してください。一時的な復旧のために、未確認のアドレスを恒久的に登録しないでください。修正後は元のDNS設定を一つずつ戻し、どの変更が有効だったか確認します。重複する一時設定を残したままにしないでください。

[General]

バッテリー消費の増加、発熱、バックグラウンドでの頻繁な再接続

割合だけでなく、近い使用条件で比較する

システムのバッテリー画面に表示される割合は、選択した期間における相対値であり、特定アプリが常に消費する一定量ではありません。端末全体の使用量、画面の明るさ、電波状況、バックグラウンド同期、ほかのアプリの動作によっても割合は変わります。まずシステムのSettingsでバッテリー情報を開き、活動した時間帯を確認して、問題が起きたときの操作内容と比較してください。Shadowrocketがリストに表示されているだけで異常と決めつけないでください。使用負荷が大きく異なる時間帯を比べても、有効な判断にはなりません。

短時間の比較では、ネットワーク、画面の状態、前面で使うアプリ、内容をできるだけそろえ、データ量の多い通信、サブスクリプションの更新、診断の実行があったか記録してください。接続を切っても明らかに発熱する場合は、ルールだけを変更せず、ほかの継続的な動作や基本のネットワークを調べます。バッテリーの状態、端末温度、充電中かどうかも使用感に影響します。確認の目的は再現できる変化を見つけることであり、観察を一度行っただけでクライアントの一定の消費電力を算出することではありません。

電波の弱さと再接続の繰り返しを確認する

電波が弱い、Wi-Fiの電波が届きにくい場所にいる、ネットワークが頻繁に切り替わるといった条件では、接続が何度も再確立されることがあります。端末が複数のネットワーク間を行き来している場合は、まず安定したネットワーク一つに固定して確認してください。特定のサーバーだけで繰り返し失敗する場合は、利用可能と確認済みの別の項目を比較に使います。接続自体を確立できない状態で再試行を続けると、追加の通信が発生することがあります。表示上の接続状態を保つために再試行間隔を短くしたり、使用していないテストを長時間繰り返したりしないでください。

現在のネットワーク条件でOn Demandが常に動作していないか、手動でオフにした後も自動的に再接続していないかを確認してください。必要であれば一時的にOn Demandをオフにして基準を作り、手動で接続してテストします。終了後は必要な条件に戻してください。自動接続ルールは実際の使い方に合わせて設定し、トラブルシューティングのためにすべてのネットワークを常時接続の条件にして、戻し忘れないようにしてください。システムにほかの自動VPN接続条件が設定されている場合は、それも記録します。複数の設定元の動作を、同じアプリが接続を繰り返していると誤認しないためです。

実際のリクエストを確認し、バックグラウンド通信を障害と決めつけない

前面のアプリを終了した後も、システムの同期、メッセージの接続、ほかのバックグラウンドリクエストが続くことがあります。利用できる接続記録に継続的な通信がある場合は、リクエストの発生元と時刻を確認し、写真やファイルなどの同期と重なっていないか調べてください。通信が続いているだけでは、接続機能の異常とは言えません。リクエストが繰り返し失敗して再試行されている場合に、該当するドメイン、ルール、サーバー経路を確認します。表示されるリクエストを減らすために一括でREJECTを設定しないでください。必要な通信を誤って遮断すると、かえって再試行が増えることがあります。

一部の診断設定を有効にすると、記録の量が増えることがあります。調査に必要な場合だけ短時間有効にして、一度再現させ、個人情報を伏せた情報を保存したら、普段の設定に戻してください。詳細な記録、連続テスト、手動でのサブスクリプション更新を頻繁に行う状態を長期間続けないでください。記録ファイルにはドメインやアドレスなどの個人のネットワーク情報が含まれることがあります。共有前に内容を確認してください。特定の診断機能を有効にした後だけ問題が発生する場合は、ほかの条件を変えずにその機能だけをオフにして比較します。判断材料を失わないようにしてください。

ルール、利用時の負荷、設定を戻す順序

特定のアプリを使うときだけバッテリー消費が明らかに増える場合は、まずそのアプリが高負荷の処理をしていないか確認し、関連リクエストが繰り返し失敗していないかを調べます。Config内の不適切なREJECTや経路選択によって、アプリが何度も接続しようとすることはあります。ただし、ルールが少ないほどバッテリー消費が抑えられるとは限りません。明確に失敗しているリクエストに関係する項目を一つ調整し、機能とリクエストが復旧するか確認してください。現在のバッテリー問題に比べて影響範囲が大きいため、ルールファイル全体を削除したり、必要なTLS検証を無効にしたりしないでください。

有効な比較には、開始時の状態、使用内容、接続の有無、ネットワーク、終了時の状況を記録します。使用履歴全体を公開する必要はありません。安定したネットワーク、利用可能と確認済みのサーバー、通常の設定でも問題を再現できる場合は、簡易なConfigのコピーを使ってテストし、特定の処理だけで起きるか記録してください。端末の発熱が続く場合は、高負荷の処理と連続診断を停止し、システムの案内に従って端末の温度に対処します。状態が正常に戻ってから調査を続け、テスト自体で負荷を増やさないようにしてください。

[General]

アップデート後の不具合、設定の復元、iPadでの確認

変更がアプリ、システム、設定のどれにあったかを確認する

アップデート後に問題が起きても、アップデートが原因とは限りません。同じ時期にサブスクリプションを更新したか、Configを切り替えたか、ネットワークを変更したか、システムの許可設定を変えたかを確認してください。アプリのアップデート、システムの変更、Configの内容変更を分けて記録し、前述の手順で最小限のテストを行います。確認できない原因を決めつけたり、バックアップを取らずに何度も再インストールしたりしないでください。特定のConfigとエラーの関連が明確な場合は、購入状況から調べ始めるのではなく、まず設定内容を比較してください。

アプリの入手とアップデートはApp Storeから行ってください。製品を確認する場合は、正規アプリの確認方法を参照し、公式アイコン、デベロッパ名のShadow Launch Technology Limited、アプリID 932747118を確認してください。システム要件はApp Storeのページをご確認ください。アプリを正常に開けてもサーバーに接続できない場合は、接続設定やサービスの状態も確認する必要があります。購入履歴が正常でも、サブスクリプションが有効であるとは限らず、接続先サーバーが利用可能だとも限りません。

バックアップを取ってから、元に戻せる方法で復元する

変更または復元の前に、サーバー項目、サブスクリプションの追加元、Configそれぞれについて、利用可能なコピーがあるか確認してください。Configをエクスポートしても、サーバーの認証情報すべてがバックアップされたことにはなりません。同期が有効か、何が同期されているかは、実際の画面と復元結果で確認してください。バックアップには機密情報が含まれる場合があるため、ご自身で管理できる場所に保存します。手順はConfigのバックアップと移行の記事を参考にできますが、実行前に現在の端末で利用できる項目を確認してください。

復元するときは、まず設定内容が明確な既存サーバーの項目を作成し、システムの許可を完了して基本の接続を確認します。次にConfigを戻し、最後にほかの設定を一つずつ復元してください。最初から古い内容をすべて戻すと、問題が起きたときに原因を切り分けられません。内容を一種類復元するたびに、同じ接続先でテストし、結果を記録してください。不具合が再発したら、直前に戻した範囲を調べます。すべてのデータを削除して記憶を頼りに入力し直すより、元に戻しやすく、まだ使える情報も保護できます。

iPadの動作をiPhoneの結果だけで判断しない

同じ情報を使ってiPhoneでは接続でき、iPadでは失敗する場合は、両方の端末が本当に同じネットワークに接続しているか確認してください。iPhoneはモバイルデータ通信を使っている一方、iPadは認証が必要なWi-Fiにつながっていることがあります。モバイル通信対応のiPadでも、実際の接続状態と許可設定を確認してください。ネットワーク条件をそろえてから、Homeで選択中の項目、Global Routing、使用中のConfigを比較します。項目名だけで判断せず、アドレス、ポート、認証情報、通信関連の項目も確認してください。

iPadでは、画面の向き、分割表示、ウィンドウのレイアウトによって、項目の位置がiPhoneと異なる場合があります。位置が違うからといって、機能がないと判断しないでください。スクリーンショットの座標をそのまま探すのではなく、実際の画面に表示されるHome、Config、Settingsなどの用語を目印にします。初回のVPN追加に必要なシステムの許可は、端末ごとに完了する必要があります。別の端末で許可済みでも、iPadで許可されているとは限りません。システムのSettingsで、ローカルネットワークへのアクセス許可や管理上の制限も個別に確認してください。

新しい端末での購入復元と設定の復元は別々に行う

端末を変更した後は、App Storeで以前購入したアカウントを使って購入済み項目を確認し、ページの表示に従って再入手してください。利用可否、互換性、購入した権利は、ストアページの表示に従います。アプリを再び入手できても、以前のサーバー、サブスクリプション、Configがすべて自動で復元されるとは限りません。購入の復元方法は購入済みアプリの復元方法をご覧ください。Configは保存済みのコピーを使って一つずつ確認します。接続の問題を直すために何度も支払わず、まず不足しているのがアプリの購入権利か、利用に必要な設定情報かを確認してください。

プリンターや内部ネットワークの端末にアクセスするときだけiPadで失敗する場合は、DNSとローカルネットワークの章に戻り、許可設定、ネットワーク分離、内部名の名前解決を確認してください。画面ロック中やネットワーク切り替え後だけ問題が起きる場合は、バッテリー消費とOn Demandの確認手順に進みます。最後に、端末の種類、ネットワークの種類、接続が確立したか、使用した状態、問題が起きた段階、条件を一つだけ変えた比較結果をまとめ、個人情報を伏せて記録してください。Password、UUID、サブスクリプション全体、QRコードを除き、エラーメッセージを残せば、認証情報を漏らさず再現可能な問題報告を作成できます。