Shadowrocketで遅延が正常に表示されても、Webアクセス全体が正常とは限りません。まずDNS解決エラー、ルールによる出力先の選択ミス、接続ハンドシェイクの失敗を切り分け、現在のConfigのDNS設定を確認しましょう。一度に変更するのは1項目だけにし、同じドメインで再テストします。接続はできるもののWebページを正常に閲覧できない方に向けて、設定を次々に変えるのではなく、問題の発生箇所を特定する方法を説明します。
1. 遅延は正常なのにWebページが開けないのはなぜ？
遅延テストの結果はテスト方法によって異なります。サーバーへの接続だけを確認する場合もあれば、指定されたテスト用アドレスにアクセスする場合もあります。テストに成功しても、すべてのWebサイトのドメインが解決できること、すべてのルールが正しく適用されること、接続先とのTLSハンドシェイクが必ず成功することまでは確認できません。つまり、遅延の数値が表示されたことは、通信経路の一部が使えることを示すにすぎません。
この流れは問題を切り分けるためのモデルであり、内部処理の固定された順序を示すものではありません。ドメインルールは名前解決より前に適用される場合があり、IPアドレスを対象にするルールでは、先にアドレスの取得が必要な場合があります。プロキシ経由の通信では、接続先のドメイン名をリモート側で解決することもあります。また、サーバーのアドレス自体がドメイン名の場合は、プロキシ接続を確立する前にその名前を解決する必要があります。
- すべてのドメインで失敗する：DNSサーバーへの接続状況、現在の設定が有効かどうか、ネットワークでログイン認証が必要かを優先して確認します。
- 一部のドメインだけ失敗する：該当ドメインの名前解決結果と適用ルールを確認します。ネットワーク設定をすぐにすべてリセットする必要はありません。
- テキストは表示されるのに画像が読み込まれない：ページ内のリソースが別のドメインから読み込まれている可能性があります。読み込みに失敗したリソースのリクエストを個別に確認します。
- IPアドレスを取得できてもタイムアウトする：出力先、IPv6経路、接続先のサービスを引き続き確認します。すぐにDNSの問題と決めつけないでください。
2. まずはネットワーク・モード・設定を一つずつ確認
現在のネットワーク、Homeで選択中のサーバー、Global Routingの設定、Configで使用中の構成を記録しておきます。テスト後に元の状態へ戻すために必要です。テスト中にサブスクリプションの更新、サーバーの切り替え、DNSの変更を同時に行うと、どの操作で状況が変わったのか判断できません。
- 基本のネットワークを確認します。Shadowrocketの接続を一時的に切り、現在のWi-Fiまたはモバイル通信で、普段直接アクセスできるWebサイトを開きます。公衆Wi-Fiで認証ページが表示された場合は、先に認証を済ませてください。基本のネットワーク自体が使えない場合、DNSを変更しても通常は解決しません。
- 再接続して問題を再現します。Homeに戻り、自分の有効な接続設定を使用していることを確認してから、同じドメインにアクセスします。リクエスト記録やログで該当箇所を見つけやすいよう、失敗した時刻を記録しておきます。
- Global Routingを確認します。ルールを使って通常利用する場合はConfigを選択します。一時的にProxyへ切り替えると、ルールによる振り分けが関係しているかを確認できます。Directは現在のネットワークから直接接続する場合との比較に使います。テスト後は元のモードに戻してください。
- 実際に使われている設定を確認します。Configを開き、確認対象の構成が選択されていることを確かめます。有効になっていない別のファイルを編集しただけでは、設定は反映されません。Sceneを使用している場合は、シーンに対応するモードと構成も確認し、シーンの切り替えでテスト条件が変わらないようにします。
- 同じ条件で再テストします。「ホームページを開く」「失敗したページを再読み込みする」「別のドメインにアクセスする」の結果をそれぞれ記録します。1つのドメインで復旧しても、問題がすべて解決したとは限りません。
3. DNS設定項目の意味を確認してから、現在のConfigを変更
Configで現在使用中の構成を開き、編集画面からDNS関連の項目を確認します。テキスト形式の構成を使っている場合は、[General]内のdns-serverを重点的に確認してください。画面に表示される項目は、構成やアプリの画面によって異なります。システムのWi-Fi設定にあるDNS、構成内のDNS、ブラウザー独自の暗号化DNSは、それぞれ別の設定です。
| 項目・概念 | 用途 | 確認ポイント |
|---|---|---|
dns-server | 構成で使用するDNSサーバーの指定元です。対応形式はアプリの最新の説明を確認してください。 | 入力ミス、アドレスの形式、接続可否を確認します。検証していないアドレスを一度に多数設定しないでください。 |
system | システムが提供するDNSの参照先を使用します。 | 比較テストに適しています。ただし、ネットワーク側のDNSに問題がある場合は、システムの参照先を使っても失敗することがあります。 |
| DNS over HTTPS | DNSクエリをHTTPSで送信します。一般的にはTCP 443を使用します。 | 正確なサービスエンドポイントが必要です。ホスト名の名前解決、TLS、ネットワーク接続がすべて正常である必要があります。 |
| DNS over TLS | DNSクエリをTLSで送信します。標準的なサービスではTCP 853を使用します。 | ネットワークで該当ポートへの接続が許可されているか、証明書に対応するホスト名が正しいかを確認します。 |
| IPv6とAAAA | AAAAレコードはIPv6アドレスを返します。アドレスを取得できることと、そのアドレスに接続できることは別の条件です。 | AAAAレコードを取得できてもIPv6経路に問題がある場合、ほかのアドレスが試されるまでWebページの読み込みがタイムアウトすることがあります。 |
| Fallback | 条件を満たす場合に、代替の名前解決先を使用します。 | まず適用条件を確認してください。すべての代替先に同時に問い合わせる、あるいは自動的に最速の結果を返すとは限りません。 |
最小限の比較を行うには、まず元の構成を複製して保存し、DNSの参照先だけをシステムの参照先に変更します。以下はテキスト形式の構成に関する項目例です。構成全体ではないため、既存ファイルのほかの内容を上書きしないでください。
[General]
dns-server = system保存後、対象の構成が引き続き有効になっていることを確認し、切断してから再接続してテストします。システムの参照先では動作し、元の暗号化DNSでは動作しない場合は、元のエンドポイントまでの接続経路を確認してください。暗号化DNSのホスト名は、接続前に名前解決が必要な場合があります。接続を確立できない状態では、Webページを何度再読み込みしてもこの前提は解消されません。
4. 適用ルールを確認：名前解決に成功しても出力先が誤っている場合がある
HomeでGlobal Routingを一時的にConfigからProxyへ変更し、同じWebページが表示されるようになった場合は、ルールの選択、直接接続の経路、または出力先ごとの名前解決方法が関係している可能性があります。ただし、それだけでは元のDNSに問題があるとは断定できません。Configに戻し、リクエストに実際に適用されたルールを確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY以下は構文の説明用です。example.comと192.0.2.0/24は文書内の例であり、アクセス対象のサービスや、そのまま使うべき振り分けルールを示すものではありません。実際のルールは構成内の上から順に照合され、最初に一致したルールが適用されます。FINALは最後に置き、ほかのルールに一致しなかったリクエストを処理します。
DOMAIN-SUFFIX：ドメインのサフィックスに一致します。対象のドメインやリソースのドメインが、適切でない出力先に先行して振り分けられていないか確認します。IP-CIDR：接続先のIPアドレス範囲に一致します。例にあるno-resolveは、このルールとの照合だけを目的とした能動的な名前解決を避ける設定です。アプリが接続先にアクセスするとき、DNSが常に不要になるという意味ではありません。GEOIP：IPアドレスが属する地域のデータベースに基づいて照合します。ドメインのリクエストで事前の名前解決が必要かどうかは、照合処理や関連設定によって異なります。ルール名だけで判断しないでください。FINAL：それまでのルールに一致しなかったリクエストを処理します。最終的な出力先が使えない場合は、DNSでアドレスを取得できていてもアクセスに失敗します。
まとめ：失敗したリクエストの適用ルールを確認してから、DNSと出力先のどちらを変更するか判断
Proxyでは接続できてConfigでは接続できない場合は、Configに戻して対象ドメインのリクエスト記録を確認します。名前解決のタイムアウトや誤った応答を示す根拠がある場合に限り、DNSを変更してください。記録に接続先アドレスが表示され、接続段階に進んでいる場合は、適用ルールと出力先を優先して確認します。
5. ログから名前解決エラー・タイムアウト・TLSエラーを見分ける
アプリのリクエスト記録またはログで、直前にアクセスに失敗した時刻とドメインを手がかりに該当箇所を探します。ネットワーク層によってエラーの表現は異なります。以下はログに表示される可能性のあるエラー例であり、どの画面にも同じ文言が表示されるとは限りません。判断するときは、どのアドレスへの処理で、どの段階にエラーが発生したかも確認してください。
エラー：no such host
原因：名前解決の段階で有効なホストアドレスを取得できていません。ドメイン名の誤り、レコードの不存在、上位のDNSサーバーからの否定応答などが考えられます。
対処：まずドメイン名の入力を確認し、同じネットワークで別の名前解決先と比較します。サービス事業者から提供されたサーバーのドメイン名だけが解決できない場合は、事業者にアドレスが有効か確認してください。
エラー：i/o timeout
原因：ネットワーク処理が制限時間内に完了していません。DNSクエリで発生する場合も、出力先への接続で発生する場合もあり、この文言だけでは原因を特定できません。
対処：前後のログを確認し、DNSサーバー、Webサイト、プロキシサーバーのどこが示されているかを調べます。DNSクエリの段階でタイムアウトしている場合に限り、別の名前解決先を試します。
エラー：connection refused
原因：接続先がリクエストを明示的に拒否しています。名前解決を待ち続けるのではなく、接続先のサービスとポートを確認してください。
対処：実際に接続したアドレスとポートを確認します。暗号化DNSのエンドポイントで拒否された場合は、サービスが該当ポートで待ち受けているか確認してください。
エラー：certificate verify failed
原因：TLS証明書の検証に失敗しています。デバイスの日時、エンドポイントのホスト名、証明書チェーンが関係している可能性があります。
対処：システムの日付と時刻、エンドポイントのアドレスを確認し、該当サービスの提供元に設定を確認してください。証明書検証を無効にして問題を隠さないでください。
ログに名前解決後のIPアドレスがすでに表示され、その後に接続エラーやTLSエラーが発生している場合は、該当する段階を重点的に確認します。また、HTTPSの検証としてWebサイトのIPアドレスをブラウザーに直接入力しないでください。証明書名、SNI、仮想ホストの選択が変わる可能性があり、ドメイン名でアクセスする場合と同じテストにはなりません。
6. 変更後の確認手順とよくある質問
変更するたびに保存し、現在のConfigを確認して再接続したうえで、同じドメインにアクセスしてください。ブラウザーのキャッシュや既存の接続により、変更前の結果が一時的に残ることがあります。該当ページを閉じてから開き直してください。まずこうした影響の小さい操作を行い、その後に必要であればシステム設定の変更を検討します。
- 元のネットワークで、問題が起きるドメインと普段は正常に開けるドメインを試し、それぞれ名前解決できるか記録します。
- サーバー、Global Routing、Configはそのままにして、Wi-Fiとモバイル通信を切り替えて比較します。モバイル通信ではデータ通信料が発生する場合があります。
- 一方のネットワークだけで失敗する場合は、そのネットワークのDNS接続状況、認証状態、ポート制限を重点的に確認します。
- 元のConfigモードとOn Demandの条件に戻し、通常のルール、ページ内のリソース、ほかのアプリに正常にアクセスできることを確認します。
遅延が表示されていれば、サービス事業者への接続に問題はないと判断できますか？
いいえ。Homeに戻り、同じサーバーを使って問題のドメインにアクセスし、接続段階でリクエスト記録にエラーが出ていないか確認してください。テスト用アドレスへの接続成功と、対象Webサイトへの接続成功は別の結果です。サブスクリプションやサーバーの設定情報を確認する場合は、利用中のサービス事業者から有効な情報を入手してください。
DNSを暗号化DNSに変更すれば、必ず復旧しますか？
必ず復旧するとは限りません。先にConfigで元の設定を保存し、DNSの参照先だけを変更して比較してください。DNS over HTTPSとDNS over TLSを使うには、接続可能なエンドポイントと正常なTLS接続が必要です。ルールや出力先が原因の場合、リゾルバーを変更しても根本的な解決にはなりません。
Wi-Fiだけで開けず、モバイル通信では正常な場合は、どこを変更すればよいですか？
Shadowrocketの設定は変えずに、Wi-Fiで認証が必要か、システムのWi-Fi詳細でDNSが手動設定されていないかを確認します。暗号化DNSを使用している場合は、そのネットワークから該当ポートに接続できるかも確認してください。複数の設定項目を同時に変更しないでください。
サブスクリプションを更新しても開けない場合、何度も再読み込みする必要がありますか？
必要ありません。サブスクリプションの更新で取得するのは接続項目であり、現在のConfigのDNSやルールが修復されるわけではありません。まずHomeで実際に選択されている項目を確認し、その後Configを確認してください。サブスクリプションの更新自体に失敗する場合は、サブスクリプションのマニュアルで更新方法を確認できます。
IPv6を無効にすると復旧しました。今後も無効のままにすべきですか？
アドレスファミリーまたは該当する経路を引き続き確認する必要がある、ということだけが分かります。元の設定を記録し、AレコードとAAAAレコードの結果、接続ログを比較してください。ネットワークのIPv6経路が正常か確認したうえで、どの設定を使うか判断します。一度の比較結果をすべてのネットワークに当てはめないでください。
さらに詳しく調べる場合は、利用中のサービス事業者に、失敗したドメイン、発生時刻、使用中のネットワーク、Global Routing、エラーが起きた段階を伝えてください。ログを共有する前に、サブスクリプションURL、token、パスワードなどの認証情報を削除してください。基本操作は使い方ガイドのトラブル対処、サブスクリプションの更新方法はSubscribeの更新ガイドをご覧ください。