Shadowrocketで遅延は正常なのにWebページが開けない：DNS解決エラーの原因と対処法

この記事の概要

この記事は、Shadowrocketに自分のサブスクリプションを追加して接続しても、Webページを開けない場合に役立ちます。まずサーバーへの到達、ドメイン名の解決、Webページへの接続を切り分け、次にGlobal Routingと現在のConfigを確認してから、DNS設定を1項目だけ変更して比較します。目的は障害箇所の特定であり、Webページが開けない原因をすべてDNSのせいにすることではありません。

1. 遅延が正常でもWebページを開けるとは限らない理由

Homeのサーバー項目に表示される遅延値は、現在のテスト方法で確認できる経路から応答があったことを示すだけです。テスト方法によって確認対象や手順は異なります。ポートへの接続が確立しても、対象ドメインの名前解決が成功したとは限りません。テスト用のWebサイトにアクセスできても、別のサイトのDNS、TLS、HTTPリクエストが正常だとは証明できません。

通常、HTTPSページを開くと、まずドメイン名に対応するアドレスを取得し、ポリシーに従って接続を確立した後、TLSハンドシェイクを行ってページをリクエストします。どの段階で失敗しても、ブラウザでは「ページを開けません」と表示されることがあります。Proxyポリシーを使用している場合は、対象ドメインの名前解決がリモート側で行われるかも確認が必要です。端末上のDNSテストだけで経路全体を判断しないでください。

従来のDNSで一般的に使用されるUDP / TCPポート

443

HTTPSとDoHで一般的に使用されるポート

853

DoTのデフォルトポート

ポイント：同じURLで変更前後を比較

継続して失敗するURLを1つ決め、同じネットワーク、同じサーバー、同じGlobal Routingの状態で変更前後を比較してください。サーバーとDNSを同時に変更すると、復旧してもどの変更が有効だったのか判断できません。

2. 障害の範囲を確認してからdns-serverを変更する

失敗するURL、現在のWi-Fiまたはモバイル通信、選択中のサーバー、Global Routingの状態、ブラウザに表示されたエラー全文を記録します。記録するのはドメイン名と発生状況だけにし、サブスクリプションのtoken、アカウント情報、設定の秘密情報は含めないでください。サブスクリプションURLは利用中のサービス提供元から取得するもので、トラブルシューティング用のスクリーンショットに公開しないでください。

テスト条件を固定する

Homeで現在のサーバーを記録し、Home → Global Routingで選択項目を確認します。Sceneを使用している場合は、実際に適用されているSceneとポリシーを確認してください。Configと同じものと決めつけないでください。
2つのドメインを比較する

Safariで、開けないURLと普段アクセスできる別のURLをそれぞれ開きます。1つのドメインだけ失敗する場合は、スペル、ドメインのDNSレコード、適用されるルールを優先して確認します。すべてのURLが失敗する場合は、ネットワーク経路全体を確認します。
ネットワーク環境を比較する

サーバーと設定を変えずに、Wi-Fiとモバイル通信を切り替えて同じURLを再試行します。特定のWi-Fiだけで失敗する場合は、先にWeb認証が必要なネットワークかどうかも確認してください。
自動接続を制御する

接続を切った状態と比較する場合は、Settings → On Demandで現在の状態を記録し、必要に応じて一時的にオフにします。オンデマンド接続によって再接続されると、「切断後にテストする」という条件が成立しなくなる場合があります。確認後は元の設定に戻してください。
元の設定を保管する

Configで現在の設定を複製するか、バックアップをエクスポートし、選択中のファイルを記録します。その後は該当ファイルのパラメータを1項目だけ変更し、保存して再接続してから再テストしてください。サブスクリプションの更新や別の設定ファイル全体のインポートを同時に行わないでください。

同じURLがシステム上では名前解決できてアクセスできるのに、接続後に失敗する場合は、設定内のDNS、適用ルール、リモート経路を重点的に確認します。切断後も失敗する場合は、システムのネットワークやWebサイト自体も調査が必要です。どちらの場合も、1回のテストだけでは原因を断定できません。

3. dns-server、システムDNS、カスタムDNSの違い

dns-serverは、設定ファイルの[General]にあるDNS上流サーバーの設定です。Configを開き、現在のファイルの操作メニューからEdit Configを選択して、既存の[General]セクションを確認します。メニューの表示は使用中の画面に従ってください。パラメータを[Rule]に記述したり、同じファイルに同名の設定を複数重ねて記述したりしないでください。

設定方法	意味	確認ポイント
`dns-server = system`	システムが提供するDNS上流サーバーを使用します。	ネットワークを切り替えると上流サーバーが変わる場合があります。特定のパブリックDNSを固定で使用する設定ではありません。
`dns-server = 1.1.1.1`	比較用の例として、通常のDNS上流サーバーアドレスを指定します。	現在のネットワークからDNSサービスにアクセスできるか確認します。アドレスに到達できても、名前解決が必ず成功するとは限りません。
暗号化DNS上流サーバー	使用中の設定でサポートされる構文に従い、DoHまたはDoTでクエリを送信します。	名前解決サービスに加えて、エンドポイントへの接続、証明書、場合によっては初期の名前解決も必要です。

システムDNSは現在のネットワーク環境に応じて取得されるため、システムのデフォルトに近い状態と比較する際に適しています。カスタムDNSでは上流サーバーを明示的に指定できますが、すべてのWi-Fiやモバイルネットワークからアクセスできるとは限りません。また、誤ったルール、サーバー障害、Webサイトの証明書に関する問題を自動で解決するものでもありません。企業内ネットワークの専用ドメインは、社内DNSでしか名前解決できない場合があります。

[General]
dns-server = system

上記は設定項目の位置を示す例であり、完全な設定ファイルではありません。元のファイルにすでに[General]がある場合は、そのセクション内で該当行だけを書き換えてください。この2行でファイル全体を置き換えないでください。カスタム上流サーバーと比較する場合は、該当行だけをdns-server = 1.1.1.1に変更し、保存して再接続後、同じドメインを再テストします。このアドレスは構文を説明するための例であり、すべてのネットワークでの使用を推奨するものではありません。

4. エラーからNXDOMAIN、サービス障害、タイムアウトを見分ける

ブラウザの簡易的なメッセージだけでは原因を特定できないことがほとんどです。診断ログにDNS応答コードやエラーテキストが記録されている場合は、以下の3種類を参考に原因を切り分けます。ここに記載する英語はDNS応答コードや一般的なネットワークエラーの文言です。Shadowrocketのすべての画面に必ず同じ表記で表示されるとは限りません。

エラー：NXDOMAIN

原因：DNS応答では、問い合わせたドメイン名が存在しないことを示しています。上流サーバーの応答に起因する場合もあります。

対処法：まずドメイン名のスペルを確認し、同じドメインをシステムDNSとアクセス可能なカスタム上流サーバーで比較します。どちらもこの応答を返す場合は、ドメインの管理者またはサービス提供元にレコードの状態を確認してください。

エラー：SERVFAIL

原因：DNSサービスがクエリを完了できなかった状態です。上流サーバーでの再帰問い合わせや検証の失敗などが考えられ、ドメインが存在しないことを意味するわけではありません。

対処法：接続ポリシーを変えずに、アクセス可能と確認済みの別の上流サーバーで再テストします。特定のドメインだけで発生するかも記録し、既存ルールをすぐに削除しないでください。

エラー：timed out

原因：処理のどこかで、制限時間内に応答がありませんでした。クエリの段階が示されていない場合、DNSではなく接続やハンドシェイクのタイムアウトである可能性もあります。

対処法：まずDNSクエリと接続先への通信のどちらでエラーが発生したかを確認し、次にネットワーク環境を比較します。DNSクエリのタイムアウトと確認できた場合に限り、名前解決の上流サーバーへの接続性を優先して調べてください。

NOERRORが返っても、利用可能なアドレスを取得できたとは限りません。応答に該当するAレコードやAAAAレコードが含まれていない場合があります。アドレス取得後にTLS証明書エラーやHTTPエラーが発生した場合は、端末の時刻、接続先サイト、接続経路、適用ルールを確認してください。DNSだけの問題として調査を続けないでください。

5. 名前解決後にGlobal Routingとルールの適用状況を確認する

Home → Global Routingでは、Configは現在の設定ルールに従ってポリシーを決定し、Proxyは通信をプロキシポリシーに渡し、Directは直接接続を使用します。Sceneは現在のScene設定に基づいて確認してください。これらのモードによる制御とDNS上流サーバーの選択は別の設定です。Proxyに切り替えても、特定のDNSサービスに必ずアクセスできるとは限りません。

Configでは失敗し、Proxyでは使える：同じ条件で再テストして確認したうえで、対象ドメインにDirect、REJECT、または意図しない別のポリシーが適用されていないか確認します。これはルール経路を調べる手がかりであり、DNSが原因ではないと完全に証明するものではありません。
アドレス取得後もタイムアウトする：接続先との通信が成功しているか確認し、必要に応じてIPv4とIPv6の経路を個別に調べます。AレコードはIPv4、AAAAレコードはIPv6に対応します。AAAAレコードが返っても、IPv6経路が利用できるとは限りません。
画像の表示やログインだけ失敗する：アドレスバーに表示されているドメインだけでなく、失敗しているリソースのドメインも確認します。1つのページが複数のドメインに依存していることがあり、そのうち1つで名前解決やポリシーに問題があると、一部が表示されなくなる場合があります。

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

以下はルールの意味を示す例であり、既存のルールをそのまま置き換えるためのものではありません。DOMAIN-SUFFIXはexample.comとそのサブドメインに一致します。FINALは、それ以前のルールに一致しなかった場合に適用されるフォールバックです。ルールは上から順に評価されるため、先にある範囲の広いルールでポリシーが決まっている場合があります。IP-CIDRとGEOIPは接続先IPに関係するため、アドレス取得後にどのルールが適用されるかも確認してください。これらはDNSサーバーの設定ではありません。

6. 復旧後の確認とよくある質問

有効な変更を見つけたら、最終的な設定と、元の症状・変更した行・使用ネットワーク・再テストしたURLと結果を簡潔に記録します。一時的に変更したGlobal RoutingとOn Demandを普段の状態に戻し、もう一度テストしてください。Configに戻すと問題が再発する場合は、ルールを引き続き確認します。一時的な切り替えだけで問題を覆い隠したままにしないでください。

DNSを変更しても結果が変わらないのはなぜですか？

まず、Configで現在選択中のファイルを変更したことと、変更が保存されたことを確認します。再接続してからテストアプリを終了し、再度開いて試してください。キャッシュに古い結果が一時的に残る場合があります。初回の再テストで変化がなくても、複数の設定を続けて変更することは避けてください。

WebサイトのIPアドレスを直接入力すれば、DNSに問題があると証明できますか？

確実な判断には使えません。HTTPSでは証明書の検証や接続先サイトの選択にドメイン名が使われるため、IPアドレスに直接アクセスすると別のサイトが表示されたり、証明書エラーが発生したりすることがあります。IPアドレスでURLを置き換えるのではなく、同じドメインのDNS応答と、その後の接続結果を比較してください。

モバイル通信に切り替えると直るのはなぜですか？

サーバーと設定を変えずに再テストしてください。差が安定して再現する場合は、Wi-Fiの認証状態、システムDNS、使用中のDNS通信方式に対する制限を確認します。dns-server = systemに戻して比較してから、カスタム設定を維持するか判断してください。

Webページは開けるようになったのに、サブスクリプションを更新できない場合は？

サブスクリプションの更新は別のリクエスト経路を使用します。まず既存のサブスクリプションURLが有効か確認し、利用中のサービス提供元にアクセス制限やアカウント状態の問題がないか問い合わせてください。Webページが復旧したからといって、サブスクリプションのドメイン、認証パラメータ、サーバーからの応答も正常だと判断しないでください。

同じ失敗URLを続けて開けることを確認し、ページの主要なリソースも読み込めている。
普段使用するGlobal Routingに戻しても利用でき、一時的なテストモードが残っていない。
On Demandを元の設定に戻し、サブスクリプションと設定のバックアップを保管している。
トラブルシューティング用の情報を共有する前に、サブスクリプションURL内のtoken、認証情報、接続キーを削除している。