ShadowrocketのDNSエラー対処法｜遅延テストは成功するのにWebサイトが開けないとき

1. 遅延テストが正常でもWebサイトが開けないのはなぜ？

Homeの遅延テスト結果が示すのは、選択したテスト方法に対応する接続先と経路だけです。テストが完了しても、ブラウザーでアクセスするすべてのドメインが名前解決できるとは限らず、WebサイトとのTCP・TLS接続や、その後のリソース読み込みまで成功することを保証するものでもありません。開けないドメイン、発生時刻、Wi-Fiとモバイル通信のどちらを使っていたかを記録し、「ネットにつながらない」だけで済ませないようにしましょう。

Webサイトにアクセスするには通常、ドメイン名をIPアドレスに変換し、その後に接続を確立してTLSハンドシェイクを行います。設定によっては一部のドメインの名前解決をプロキシ側で行う場合もあれば、端末側で先にアドレスを取得する場合もあります。すべてのリクエストが常に同じ経路を通るわけではありません。以下はトラブル切り分けのための概略であり、各プロトコルの実際のパケット順序を示すものではありません。

• アドレスを取得できない場合：DNS応答、リゾルバーへの到達性、ローカルの名前解決設定を確認します。
• アドレスは取得できても接続がタイムアウトする場合：適用されたルール、接続先ポート、アドレスファミリーを確認します。DNSの障害と即断しないでください。
• HTTP 403または503が表示される場合：少なくともそのリクエストは、HTTP応答を返せるサーバーに到達しています。サイト側のアクセス制限やサービス状況を確認してください。
• トップページは表示されるのに画像が読み込まれない場合：画像やスクリプトが使うドメインを記録します。メインのドメインが正常でも、リソース用ドメインに同じルールが適用されるとは限りません。

2. まずは一度に一項目だけ変更して確認する

作業前に現在の設定を複製し、Home → Global Routingの状態と選択中のサーバーを記録します。日常的なルール振り分けの基準としてConfigを使用します。Proxy、Direct、Sceneの動作はそれぞれの設定に応じて判断してください。モードを切り替えるだけでDNSの問題が解決するわけではありません。

1. 現在の状態を記録

   Homeで選択中のサーバーとGlobal Routingの状態を記録します。同じドメインをブラウザーで再度開き、表示されたエラーメッセージを書き留めてください。サブスクリプションの更新、サーバー変更、DNS変更を同時に行わないでください。

2. 設定を確認

   Configを開き、現在実際に有効な設定ファイルを確認してから、[General]と[Rule]を調べます。バックアップを作成し、唯一の設定ファイルを直接変更せず、ローカルの複製でテストしてください。

3. ネットワークを切り替える

   サーバーと設定はそのままにして、Wi-Fiとモバイル通信で結果を比較します。Wi-Fiだけで失敗する場合は、まずネットワークへのログイン認証が必要か確認し、その後DNSとネットワーク制限を調べてください。

4. DNSを比較する

   テスト用の複製でdns-serverだけを変更し、保存してその複製を有効にしてから、一度切断して再接続します。同じドメインで再テストし、アドレスを取得できるか、ページが表示されるかを記録してください。

5. 元に戻して確認

   変更しても改善しない場合は、元の値に戻して再テストします。接続を切断する場合は、Settings → On Demandを先に確認してください。必要に応じて自動接続条件を一時的に無効にし、テスト後に元に戻すと、自動再接続による影響を避けられます。

3. dns-server、システムDNS、設定ファイルの関係

dns-serverは設定ファイルの[General]セクションにあり、使用するリゾルバーを指定します。systemはシステムが提供するDNSを使う指定です。システムDNSには、現在のWi-Fiで自動設定されたものや手動設定したものが使われる場合があり、特定のパブリックDNSを固定で使うという意味ではありません。ネットワークを切り替えると、システムが使うDNSの条件も変わることがあります。

現在有効な設定ファイルでdns-serverを検索し、重複した定義や以前のテスト値が残っていないか確認します。次に、ローカルのテスト用複製を二つ用意し、それぞれに以下のいずれかの書き方を設定してください。二つの[General]セクションを一つのファイルにそのまま連結してはいけません。ここに示すパブリックDNSアドレスは到達性の比較用であり、すべてのネットワークで使えるとは限りません。

比較A：システムが提供するDNSを使う

[General]
dns-server = system

比較B：一般的なDNSアドレスを指定する

[General]
dns-server = 1.1.1.1

テストでは原因を特定しやすくするため、候補のリゾルバーを一つだけ設定します。複数のリゾルバーを同時に使うと、リクエストの振り分け、キャッシュ、応答の違いにより結果の原因を特定しにくくなります。指定したアドレスが応答せず、systemなら正常な場合は、サブスクリプションを何度も読み込み直すのではなく、そのネットワークから指定リゾルバーまでの経路を優先して調べてください。

ポートに到達できることと、プロトコルを利用できることは別です。通常のDNSでは、UDP応答が切り詰められた場合にTCPが必要になることがあります。DoHではHTTPS接続を確立する必要があります。通常のDNSアドレスを書き換えてHTTPSアドレスにすればDoHになる、というわけではありません。DoHには有効な実サービスのエンドポイントが必要です。エンドポイントがドメイン名の場合は、最初の接続前にその名前をどう解決するかも考慮してください。

4. DNSエラーの内容から原因を切り分ける

以下は、DNS応答コードやネットワーク診断でよく見られるエラーテキストです。Shadowrocketのすべての画面で同じ文言が表示されるとは限りません。ログや診断結果に該当する文字列があれば、問い合わせたドメイン、レコードタイプ、リゾルバーのアドレス、発生時刻も記録してください。エラーの一行だけでは、どの段階で問題が起きたか特定できないことがほとんどです。

「レコードがない」ことと「ドメイン自体が存在しない」ことは区別してください。AAAAの問い合わせでアドレスが返らなくても、Aが正常に返るなら、そのドメインがIPv6アドレスを提供していないだけかもしれません。使用可能なアドレスを取得できているのに、その後TLS証明書エラーが発生する場合は、DNSを変更し続けるのではなく、システム時刻、証明書の名前、接続先を確認してください。

5. 特定のドメインだけ開けない場合：ルールとHostマッピングを確認

一部のWebサイトだけ開けない場合は、そのリクエストに実際に適用されたルールとポリシーを確認します。DOMAIN-SUFFIXはドメインのサフィックスで直接照合できます。IP-CIDRとGEOIPはアドレスに基づいて判定するため、名前解決が関係することがあります。ルールは上から順に評価され、先に一致したルールが後続の経路に影響します。FINALは、それ以前のルールに一致しなかったリクエストを処理します。

以下の記述例は構文の説明用です。設定全体を置き換えるためのものではありません。example.comと192.0.2.0/24はドキュメント用の例です。PROXYは、実際の設定内に利用可能なポリシー参照がある場合に使用してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

一時的にHome → Global Routing → Proxyに切り替えて復旧し、Configでは失敗する場合、分かるのは二つのルーティング条件に違いがあることだけです。特定のDNS設定が原因だと断定することはできません。両方の適用ポリシー、接続先アドレス、失敗した段階を記録し、Configに戻して原因を絞り込んでください。テスト後は元の設定に戻し、一時的な比較設定を普段の設定として残さないようにしましょう。

6. アドレス取得後にIPv6、キャッシュ、ネットワーク条件を確認

AレコードはIPv4アドレスを、AAAAレコードはIPv6アドレスを返します。AAAA応答があっても、現在のネットワークからそのアドレスへ接続できるとは限りません。ドメインが両方のレコードを持つ場合は、「レコードがない」「レコードは取得できたが接続がタイムアウトする」「アプリがどちらのアドレスを選択したか」の三つを区別して調べてください。

• IPv4では接続できるがIPv6ではタイムアウトする場合：DNS応答を記録として残し、現在のネットワークでIPv6通信ができるか確認します。関連する設定を変更する場合は、先に元の値を記録し、一時的な比較にとどめてください。DNSと振り分けルールを同時に変更しないでください。
• 設定を変更しても古い結果が残る場合：新しい設定が実際に有効になっていることを確認し、接続を切断して再接続した後、ブラウザーを終了してから試してください。ブラウザー、アプリ、リゾルバーがそれぞれ結果をキャッシュしている場合があり、再接続してもすべてのキャッシュが消えるとは限りません。
• ホテルや公衆Wi-Fiだけで失敗する場合：まずネットワークが求めるWeb認証を完了してください。ネットワークの利用が許可されていないと、DNS応答やHTTPS接続にも影響することがあります。
• 特定のブラウザーだけで失敗する場合：別のアプリで同じドメインにアクセスして結果を比較し、アプリ独自の名前解決、キャッシュ、接続設定がないか確認します。すぐに全体設定を変更しないでください。
• サーバーアドレスがドメイン名の場合：接続を確立する前にサーバーのドメイン名を解決できるかも確認してください。接続の確立に必要な名前解決を、まだ確立されていない接続に頼ることはできません。

7. 設定を元に戻し、再現できる記録をまとめる

問題が解決したら、テスト中に一時的に無効にしたOn Demandの条件を元に戻し、Global Routingと現在の設定を確認してから、メインのドメインとリソース用ドメインをそれぞれテストします。ページが一度開いただけで解決と判断しないでください。キャッシュによって問題が隠れる場合があるため、少なくとも再接続後に同じ手順をもう一度試してください。

サブスクリプションはサーバー情報の提供と更新を行うもので、現在のネットワークのDNSを修復するものではありません。サブスクリプションは利用中のサービス事業者から取得します。更新後にサーバー一覧が正常でも、アクセス先のWebサイトが名前解決できるとは限りません。ローカル設定だけを変更した場合は、次回の設定更新で変更が上書きされないかも確認してください。

1. 開けないドメインとエラーの原文を記録し、すべてのサイトで起きるのか、特定のドメインだけなのかを明確にします。
2. Wi-Fiまたはモバイル通信の別、Global Routingの状態、現在の設定とサーバーを記録します。第三者に共有するときは、機密性のあるアドレスや認証情報を伏せてください。
3. dns-serverの変更前後の値と、A・AAAAそれぞれでアドレスを取得できたかを記録します。
4. リクエストに適用されたルールとポリシー、最終的に失敗した段階を記録し、DNS、接続、TLS、HTTP応答を区別します。
5. どの項目を単独で変更したときに状況が変わったのかを記録します。サブスクリプションの完全なURL、token、パスワードは共有しないでください。

接続の問題をさらに調べる場合はトラブル診断を、キーワードの意味を確認する場合は用語集をご覧ください。複数の設定を続けて変更するより、一度に一項目だけ変更した記録を残すほうが、再現や原因の判断に役立ちます。