この記事の要点

まずシステムDNSを基準にし、名前解決に使うサーバーを固定したい場合はカスタムDNSを設定します。DNS over HTTPSは、DNSクエリを解析サービスまで暗号化して送信したい場合に検討します。利用可能なサービス設定があり、ドメインにアクセスできない、またはネットワーク切り替え後に名前解決が不安定になった方に向けて、3つの方式の違い、dns-serverの設定方法、変更後に名前解決と接続のどちらで問題が起きているかを見分ける方法を説明します。

DNSは名前解決を担うもので、接続経路そのものではありません

ShadowrocketのDNS設定で決まるのは、主にドメイン名からIPアドレスを取得する方法です。HomeのGlobal Routingとは別の設定で、前者は名前解決、後者は接続のルーティング方式に関わります。ウェブページが開けないときは、まず「アドレスを取得できていない」のか「取得後に接続できない」のかを切り分けましょう。DNS、ルール、サーバー設定を一度に変更するのは避けてください。

ドメイン名の問い合わせ 参照先DNS アドレスの返却 接続経路の判定 宛先へのアクセス

この流れは、端末側で名前解決する一般的なアクセス例です。すべての接続が同じ手順をたどるとは限りません。アプリがキャッシュを再利用したり、独自に暗号化DNSを使ったりすることがあります。また、プロキシ接続の一部では、宛先ドメインの解決をリモート側に任せる場合があります。そのため、dns-serverを変更しても、端末上のすべての名前解決がすぐ新しい設定に切り替わるとは限りません。

システムDNS・カスタムDNS・DoHの違い

システムDNSは、現在のネットワーク環境でシステムが提供するDNSサーバーを使う方式です。通常はWi-Fiやモバイル通信の設定に基づきます。カスタムDNSは、参照先サーバーを手動で指定します。通常のIPアドレスだけを設定する場合、一般的なDNS通信が使われます。DNS over HTTPS（DoH）は、HTTPSを介してDNSメッセージをDNSサーバーとやり取りする方式です。この3つは完全に別々の選択肢ではありません。DoHも、参照先を手動で指定する方法の一つです。

3種類のDNS設定を比較
設定方式 参照先と通信方式 まず確認したい場面 注意点
システムDNS システムが提供するDNSサーバーを使用。通信方式はシステムのネットワーク設定によって異なります。 比較の基準を作りたい場合や、LAN内・組織内のドメインにアクセスする場合。 Wi-Fiとモバイル通信を切り替えると、参照先や名前解決の結果が変わることがあります。
カスタムDNS（通常のDNS） 指定したDNSサーバーのIPアドレスを入力します。通常はUDP 53で問い合わせ、必要に応じてTCP 53を使います。 現在のネットワークが提供するDNSサーバーに問題があるかを確認する場合。 IPアドレスを変更しただけでは、DNSクエリは暗号化されません。
DNS over HTTPS HTTPSのエンドポイントを完全な形で入力します。通常はTCP 443を使用します。 クライアントからDNSサーバーまでの問い合わせを暗号化したい場合。 エンドポイントへの接続、証明書の検証、エンドポイントのドメイン名の初回名前解決が、利用可否に影響することがあります。

要点：同じドメインで一度に1項目ずつ比較する

ネットワーク、Global Routing、選択中のサーバーは変えず、DNS設定だけを変更します。結果を再現できることを確認してから設定を残しましょう。複数の項目を同時に変更すると、ページが開けるようになっても、どの変更が効いたのか判断できません。

DoHが暗号化するのは、DNSクエリがDNSサーバーに届くまでの通信です。アクセス全体を暗号化するわけではありません。DNSサーバーは引き続きクエリを処理し、ウェブサイトへの接続は適用されるルーティング方式に従って確立されます。「DoHを使っている」ことから、「すべてのDNS通信がプロキシ経由」や「接続元の経路が変わった」とは判断できません。

Configの[General]でdns-serverを設定する

まずConfigで現在選択している設定ファイルを確認し、元の内容をバックアップしてから、そのファイルのテキスト編集画面を開きます。以下のコード例はそれぞれ独立しており、互いに置き換えて使うものです。3つをまとめて貼り付けないでください。ファイルにすでに[General]がある場合は、同じ設定を重複して追加せず、既存のセクション内でdns-serverを変更します。

  1. Homeで現在のGlobal Routingの選択肢と、選択中のサーバーを記録し、比較時の条件をそろえます。
  2. Configで現在使用中のファイルを開き、[General]と既存のdns-serverを確認します。
  3. この項目だけを置き換えて保存し、引き続き同じファイルが選択されていることを確認します。検証しやすくするため、いったん切断してから再接続してもよいでしょう。
  4. 対象ドメインに再度アクセスして結果を確認します。既存の接続やキャッシュで以前の結果が使われる場合があるため、ページを一度更新しただけで結論を出さないでください。

システムのDNSサーバーを使う

[General]
dns-server = system

systemは設定値であり、置き換えるドメイン名ではありません。問題の切り分けに使う基準として適しています。特に、ネットワーク内で内部ドメイン、ルーター名、組織専用のDNSレコードを使っている場合に有用です。一般向けのDNSサーバーはこうしたレコードを知らないことが多く、切り替えると内部サービスにアクセスできなくなる場合があります。

通常のDNSサーバーのアドレスを指定する

[General]
dns-server = 1.1.1.1

ここでの1.1.1.1は、公開DNSサーバーの設定例です。どのネットワークでも速いという意味ではありません。複数のDNSサーバーは半角カンマで区切って指定できますが、記載順がそのまま「優先・予備」の切り替え順になるとは限りません。問題を切り分けるときは、まず1つだけ設定すると、接続可否や返される結果を確認しやすくなります。

DNS over HTTPSのエンドポイントを指定する

[General]
dns-server = https://cloudflare-dns.com/dns-query

DoHの値には、https://、ホスト名、サービスで指定されたパスを含める必要があります。一般的なウェブサイトのトップページURLでは、DNSエンドポイントの代わりになりません。この例は書式を示すものです。実際に設定する前に、DNSサービスが公開しているエンドポイントを確認してください。ホスト名を安易にIPアドレスへ置き換えないでください。証明書の識別、サービスのルーティング、エンドポイントの仕様によっては置き換えられない場合があります。

ポート番号と設定値で記述を確認する

53
従来のDNSで使う標準ポート。UDPまたはTCPで通信します。
443
HTTPSの標準ポート。DoHも通常このポートを使用します。
2種類
一般的なアドレスレコード：AはIPv4、AAAAはIPv6に対応します。

ポート番号は通信方式を見分けるためのもので、速度の順位を示すものではありません。通常のDNSで53番ポートに接続できても、DoHエンドポイントへのHTTPS接続が正常とは限りません。一般的なHTTPSサイトを開けても、指定したDoHサービスが使えるとは限りません。任意のウェブサイトへの接続ではなく、実際に使うDNSサーバーをテストしてください。

システムDNSを基準にする

設定セクション
[General]
設定名
dns-server
設定値
system
確認するポイント
同じネットワークで、一般のドメインと内部ドメインの両方を解決できるか。

まず基準となる結果を記録してから、DNSサーバーを切り替えます。

DoHエンドポイントの確認

プロトコルの接頭辞
https://
サンプルのホスト名
cloudflare-dns.com
サンプルのパス
/dns-query
確認するポイント
エンドポイントの初回名前解決、HTTPS接続、証明書検証が正常か。

エンドポイントの各項目を確認してください。プロトコルの接頭辞だけでは不十分です。

ドメインからAAAAレコードが返された後にアクセスが不安定になる場合は、DNSが誤ったアドレスを返したとすぐに決めつけず、IPv6の通信経路を確認してください。DNSサーバーがアドレスを返せることと、現在のネットワークからそのアドレスに接続できることは別の条件です。また、ブラウザーでIPアドレスに直接アクセスした結果だけを判断材料にするのも避けましょう。HTTPSサイトでは、証明書の検証や仮想ホストの選択にドメイン名が必要な場合があります。

DNSとGlobal Routing・ルールの関係

HomeのGlobal Routingでは、Configは現在の設定に含まれるルールに従って接続を判定します。ProxyとDirectは、それぞれプロキシ経由と直接接続のルーティング方式です。Sceneでは、設定済みのシーンを選択します。DNSの問題を調べる際は現在の選択肢を記録し、ルーティングを変更した結果をすべてDNSサーバーの違いのせいにしないようにしましょう。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

これはルール間の関係を説明するための抜粋であり、完全な設定ではありません。既存のルールを置き換えるためのものでもありません。GEOIPとIP-CIDRはアドレスに基づく判定で、名前解決後のIPアドレスが関係する場合があります。一方、DOMAIN-SUFFIXはドメイン名を条件にします。接続先を調べるときは、一致したルールと最終的なポリシーの両方を確認してください。DNSが返したアドレスだけでは判断できません。

ドメインにアクセスできないときの確認手順

以前アクセスできたドメインを1つ選び、Wi-Fi、モバイル通信、または両方のどの環境で問題が起きるか記録します。以下は、観察した状況に応じた確認項目であり、このページで実測した結果ではありません。設定を変更するたびにリクエストを再実行し、時刻、ネットワーク、結果を記録してください。条件の異なる結果を比較しないようにします。

DNSの問題で見られる症状と次の確認項目
確認された症状 優先して確認する項目 検証方法
DoHに切り替えた後、複数のドメインを解決できなくなった。 エンドポイントの入力ミス、エンドポイントのドメイン名の初回名前解決、HTTPSへの接続可否。 systemに戻して比較します。正常に戻った場合は、すべてのルールを書き換えるのではなく、DoHエンドポイントを重点的に確認します。
一般のウェブサイトは開けるが、内部ドメインにアクセスできない。 内部レコードを含まない公開DNSサーバーに切り替えていないか。 同じネットワークでシステムDNSに戻し、同じ内部ドメインをもう一度テストします。
アドレスは取得できるが、接続がタイムアウトする。 適用されたポリシー、サーバーへの接続、宛先ポート、IPv6の通信経路。 接続ログで適用されたポリシーと宛先を確認し、DNSをむやみに切り替えないでください。
設定を変更しても、一部のアプリの動作が変わらない。 キャッシュ、既存の接続、アプリ独自の名前解決方式。 関連するリクエストを終了してから再試行し、すでに開いているページではなく新しいリクエストを比較します。

Connectivity Testはサーバーへの接続確認に役立ちますが、すべてのサービスドメインが正しく名前解決できることを単独で証明するものではありません。反対に、DNSクエリが一度成功しても、選択中のサーバーや接続先のウェブサイトにアクセスできるとは限りません。名前解決の結果、接続テスト、実際のページへのリクエストを分けて記録してください。

要点：問題が起きている段階を特定してから設定を変更する

アドレスを取得できない場合はDNSサーバーとエンドポイントを確認します。アドレスを取得できても接続できない場合は、ルーティングと接続経路を確認します。特定のアプリだけで問題が起きる場合は、キャッシュや名前解決の動作を調べましょう。元の設定を保存し、検証に失敗したら元に戻してください。確認できていない変更を次々に重ねないようにします。

利用環境に合わせて設定を決める

最終的に残すべきなのは、内容を説明でき、再現でき、元に戻しやすい設定です。DNSサーバーの数を増やすこと自体が目的ではありません。この記事は、利用者が自分で使用するサービス設定をすでに持っていることを前提としており、サービスのサブスクリプションを提供・推奨するものではありません。設定ファイルと接続確認について詳しくは、マニュアル全文または使い方ガイドをご覧ください。