システムDNSは現在のネットワークを調べる基準として、カスタムDNSは使用するリゾルバーを明示する方法として、DNS over HTTPSはクライアントとリゾルバー間の問い合わせを暗号化する方法として使えます。利用中のサービスやサブスクリプションがあるShadowrocketユーザーを対象に、ConfigのGeneralセクションの変更方法、DNSの問題と接続の問題の見分け方、変更後の確認と元に戻す手順を説明します。
1. DNSの名前解決とWebサイトへの接続を区別する
DNSはドメイン名をIPアドレスに変換します。たとえばAレコードを問い合わせるとIPv4アドレス、AAAAレコードを問い合わせるとIPv6アドレスが返されます。アドレスを取得した後、HTTPSサイトにアクセスするには接続を確立し、TLSハンドシェイクを完了してコンテンツを取得する必要があります。そのため、「DNS応答がある」ことは「Webページが必ず開く」ことを意味せず、「Webページが開かない」からといって「DNSに問題がある」とは限りません。
この流れは問題の切り分けを示したもので、すべてのリクエストが端末上で名前解決されるという意味ではありません。Shadowrocketで実際にどこで名前解決されるかは、リクエストの種類、ルール、プロキシの出力方法にも左右されます。接続によっては、宛先ドメインの処理をリモート側に任せることもあります。端末にDNSアドレスを設定しただけで、すべてのドメインがそのリゾルバーを使うと判断しないでください。
問題を調べるときは、まずHomeで現在のサーバーを確認し、次にGlobal Routingを確認します。Configは現在の設定に従って通信を振り分けます。ProxyとDirectは全体のルーティング方針を切り替え、Sceneでは選択中のシーンの設定が適用されます。DNSを比較する間は同じルーティング方針を保ち、送信経路とリゾルバーを同時に変更して、どちらが影響したのか分からなくなる事態を避けましょう。
- 問い合わせがタイムアウトする：リゾルバーに到達できるか、使用する通信方式が現在のネットワークで制限されていないかを確認します。
- NXDOMAINが返る：リゾルバーがドメイン名は存在しないと応答しています。ネットワークのタイムアウトとは異なるため、ドメイン名の入力とレコードの状態も確認してください。
- アドレスは返るが接続できない：DNSを何度も変更するのではなく、ルールの適用状況、送信先への到達性、IPv4/IPv6の経路、TLSを確認します。
2. システムDNS・カスタムDNS・DoHの違い
ここでいう「カスタムDNS」は、HTTPSエンドポイントと区別するため、リゾルバーのIPアドレスを直接指定する従来型DNSを指します。設定方法という観点では、DoHエンドポイントを手動で指定することもカスタム設定に含まれます。選ぶ際は名称の印象ではなく、ネットワーク環境、リゾルバーへの到達性、問い合わせの通信方式を基準にしてください。
| 方式 | 名前解決の経路 | 適した状況 | 確認するポイント |
|---|---|---|---|
| システムDNS | システムで現在利用できるリゾルバーを使用します。通常は接続中のWi-Fiまたはモバイル通信の影響を受けます。 | 切り分けの基準にする場合や、現在のネットワークで提供される内部ドメインの名前解決が必要な場合。 | ネットワークを切り替えると、リゾルバーや応答結果が変わることがあります。 |
| カスタムDNS | 指定したリゾルバーのIPアドレスに、従来型DNSの問い合わせを送信します。 | リゾルバーを固定したい場合。指定したアドレスに現在のネットワークから到達できることが必要です。 | UDP/TCP 53番ポートへの到達性と、リゾルバーが現在の接続元からの問い合わせを許可しているか。 |
| DNS over HTTPS | DNSの問い合わせをHTTPSリクエストに含めてDoHエンドポイントへ送信します。 | 問い合わせの通信を暗号化したい場合。HTTPSエンドポイントに到達でき、証明書が有効であることが必要です。 | エンドポイントの完全なパス、TLS証明書、エンドポイントのドメイン名を最初に名前解決する方法、実際のルーティング。 |
DoHが暗号化するのは、クライアントからリゾルバーまでの通信です。リゾルバーは受信した問い合わせを処理でき、その内容も確認できます。Webサイトへの接続には、引き続き個別の送信経路が適用されます。DoHを有効にしても、すべての通信が自動的にProxyになるわけではありません。ルールやサーバーの状態を確認する代わりにもなりません。
まとめ：まず到達性を確認し、DoHを使うか判断する
システムDNSでは安定して名前解決できる一方、DoHの問い合わせがタイムアウトする場合は、まずエンドポイントとTLSの経路を確認します。Global Routingを同時に変更しないでください。内部ドメインの名前解決が必要な場合は、システムDNSでのテスト結果を記録したうえで、外部リゾルバーにも同じレコードがあるか確認します。
3. Configでdns-serverを変更する
dns-serverは設定ファイルの[General]セクションに記述し、[Rule]セクションには記述しません。以下のコード例はそれぞれ独立した設定案です。3つをそのまま1つのファイルにまとめないでください。既存の設定を変更する場合は、ルールやほかの項目を残し、今回テストするDNS設定だけを置き換えます。
- Configで現在有効な設定ファイルを確認し、まずローカルにコピーを保存して、元の
dns-serverの値を記録します。 - そのファイルの編集画面を開き、
[General]を探します。すでにdns-serverがある場合は既存の行を変更し、同じキーを重複させないでください。 - 一度に選ぶ設定案は1つだけにします。保存後も同じファイルが有効になっていることを確認してください。有効化されていないコピーを編集しても、現在の接続には反映されません。
- Homeに戻り、接続を切断してから再接続し、保存後の設定で新しい接続をテストします。既存の接続やキャッシュが観察結果に影響することがあります。
設定案A：システムDNSを使う
[General]
dns-server = system[General]：共通設定のセクションを指定します。dns-server = system：システムで現在利用できるDNSを使用します。カスタム設定と比較する際の基準に適しています。
設定案B：従来型DNSのアドレスを指定する
[General]
dns-server = 192.0.2.53[General]：こちらも共通設定のセクションです。DNSという名前のセクションを別途作る必要はありません。dns-server = 192.0.2.53：IPv4アドレスを直接指定する構文例です。このアドレスはドキュメント用の例示ネットワークに属し、実際に使えるリゾルバーではありません。テストする前に、利用権限があり、到達性を確認済みのリゾルバーアドレスに置き換えてください。
設定案C：DoHエンドポイントを指定する
[General]
dns-server = https://dns.example.com/dns-query[General]：前の2つの設定案と同じセクションを使います。https://：HTTPS通信を指定します。省略してもアプリがDoHとして扱うと想定しないでください。dns.example.com：説明用のドメイン名であり、この記事が提供するDNSサービスではありません。実際に使用している名前解決サービスのエンドポイントを指定してください。/dns-query：DoHでよく使われるパスですが、すべてのエンドポイントで使われるわけではありません。名前解決サービスが提示する完全なURLをそのまま記述し、パスを追加したり短縮したりしないでください。
4. 名前解決の設定とルール・Hostを分けて確認する
DNSはアドレスを取得し、ルールはリクエストの処理方針を選び、Hostは特定のドメイン名に固定の対応付けを設定できます。それぞれ影響する段階が異なります。設定にHostのマッピングがあると、想定した上位リゾルバーへ問い合わせが行われない場合があります。アプリに以前のアドレスが残っている場合は、ページをすぐ再読み込みしても変化が分からないことがあります。
名前解決設定の確認
- 設定画面
- Config → 現在有効なファイル → 編集
- 設定セクション
- [General]
- 項目
- dns-server
- マッピングの確認
- [Host]に対象ドメインの設定があるか
まずテスト対象のファイルを確認し、結果に影響する固定マッピングがないか調べます。
ルーティング方針の確認
- 設定画面
- Home → Global Routing
- Config
- 現在の設定に従って通信を振り分ける
- Proxy / Direct
- 全体の送信方針を切り分ける
- Scene
- 選択中のシーンで実際に適用される設定を確認する
DNSのテスト中はルーティング方針を変えず、リゾルバーの変更と送信経路の変更を同じテストで行わないでください。
たとえばDOMAIN-SUFFIXはドメインのサフィックスに一致し、IP-CIDRはアドレス範囲に一致します。GEOIPはIP地理データベースに基づいて一致し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。IP系のルールを使う場合は、名前解決の結果とルールのオプションをあわせて実際の一致状況を確認してください。ドメインルールが一致したことを、DNSが正常に機能した証拠とみなすことはできません。
- ドメインルール：対象ドメインとサフィックスが一致しているか確認し、最後に適用される方針を確認します。
- IP系ルール：実際の宛先アドレスを記録します。名前解決結果が異なると、アドレスルールの一致状況が変わることがあります。
- Hostマッピング：対象ドメインに固定アドレスが設定されている場合、そのマッピングが現在の用途に合っているか確認します。
- FINAL：ルーティングのフォールバック先であり、DNSの問い合わせに失敗したときの代替リゾルバーではありません。
5. 変更後の確認手順と記録方法
「同じネットワーク、同じ対象、同じルーティング方針で、変更する項目は1つだけ」という方法で検証します。アクセス権があり、正常に管理されているドメインを選び、まずシステムDNSでの結果を記録してから、従来型DNSまたはDoHをテストします。ページを一度開いたときの速さだけでリゾルバーの優劣を判断しないでください。接続の再利用、ページキャッシュ、Webサイトの応答時間によって、名前解決の違いが分かりにくくなることがあります。
- 基準を記録：Wi-Fiまたはモバイル通信、Homeで現在選択中のサーバー、Global Routingの方針、有効なConfigファイル、対象ドメインを記録します。
- 保存して再接続：
dns-serverだけを変更し、設定を保存して再接続します。対象アプリで以前のリクエストを終了し、新しくドメインにアクセスしてください。 - 名前解決を確認：アプリで利用できるDNS問い合わせツールやログで、対象ドメインの結果を確認します。A、AAAA、タイムアウト、エラー応答を記録します。ツールでリゾルバーを個別に選べる場合は、今回テストするリゾルバーが使われていることも確認してください。
- 接続を確認：実際のリクエストが成功したか、どの方針が適用されたか、接続エラーやTLSエラーが発生したかを確認します。遅延時間の数値だけを記録して終わらせないでください。
- ネットワークを変えて再テスト：同じネットワーク内での比較を終えてから、Wi-Fiとモバイル通信をそれぞれテストします。一方のネットワークだけで失敗する場合は、まずそのネットワーク特有の到達性の違いを確認します。
| 確認された現象 | 次に確認すること | この時点では判断できないこと |
|---|---|---|
| 従来型DNSはタイムアウトするが、DoHでは応答がある | 現在のネットワークからリゾルバーまでのUDP/TCP 53番ポートの経路を確認します。 | すべてのWebサイトへの接続が正常だとは判断できません。 |
| DoHでTLSエラーが発生する | エンドポイントのドメイン名、証明書の有効性、システム時刻、接続経路を確認します。 | 証明書エラーを通常のDNS遅延と同じものとして扱うことはできません。 |
| Aは応答するが、AAAAは応答しない | 対象ドメインがAAAAレコードを提供しているか確認し、レコードがない場合と問い合わせがタイムアウトした場合を区別します。 | AAAAレコードがないことは、DNS全体の障害を意味しません。 |
| アドレスは返るが、Webページがタイムアウトする | ルールの適用状況、現在の送信経路、返されたアドレスへの到達性を確認します。 | リゾルバーを変更すれば必ず解決するとは限りません。 |
| 変更後も結果がまったく同じ | 有効なファイル、Hostマッピング、キャッシュ、既存の接続を確認します。 | 結果が同じというだけで、変更が反映されていないとは断定できません。 |
まとめ：問い合わせ結果と接続結果の両方で判断する
名前解決の応答が正常で、実際のアクセスにも成功した場合に限り、今回の設定が現在の用途に適していると判断できます。特定のネットワークだけで失敗する場合は、そのときのエラーを記録してから確認済みの設定に戻し、失敗した段階を個別に調べてください。
6. よくある質問と安全な元への戻し方
リゾルバーを複数記述すると、左から順に自動で切り替わりますか？
記述順だけから、問い合わせ順、並列処理の有無、失敗時の切り替え動作を判断することはできません。最初の切り分けでは、到達性を確認済みのリゾルバーを1つだけ設定してください。正常に動作することを確認してから、実際の設定要件に応じて調整します。システムDNS、従来型DNS、DoHを同時にリストへ入れると、応答がどの方法によるものか判別しにくくなります。
DoHを有効にすると、問い合わせは必ずProxy経由になりますか？
必ずしもそうではありません。DoHは問い合わせの通信方式を示すもので、ルーティング方針とは別です。実際の経路は、現在の設定、Global Routing、DNS関連の設定をあわせて確認してください。https://だけでは、問い合わせが特定の送信経路を通ることも、すべてのアプリが同じ名前解決経路を使うことも証明できません。
Wi-Fiを切り替えると問題が再発する場合、何を確認すればよいですか？
まず、システムDNSがネットワークの切り替えに応じて変わるか、カスタムエンドポイントに新しいネットワークから到達できるかを確認します。Settings → On Demandを設定している場合は、オンデマンド接続の条件も確認し、テスト中に自動ルールで接続状態が変わっていないか調べてください。On Demandは接続を開始する条件を制御するもので、dns-serverの代わりにはなりません。
変更前の状態に戻すにはどうすればよいですか？
Configで元のdns-serverの行に戻すか、保存しておいたローカルコピーを再度有効にしてから、Homeに戻って再接続します。元のファイルにこの項目がなかった場合は、推測した値を追加せず、元の状態に戻してください。同じ対象に再度アクセスして復元を確認し、その後は一度に1項目だけ変更します。
DNS設定では、用途に合った検証可能な名前解決結果を得ることが大切です。すべてのネットワークで特定の方式を使うことが目的ではありません。システムDNS、従来型のカスタムDNS、DoHはいずれも実際のネットワーク環境で確認が必要です。設定を何度も切り替えるより、設定ファイルのコピーとテスト記録を残すほうが、問題の切り分けに役立ちます。