ShadowrocketのDNS設定は、一部のドメイン検索先を決めるもので、すべての通信の接続経路を決めるものではありません。すでに利用中のサービスを登録し、名前解決の問題を調べたい方やDNSを変更したい方に向けて、まず現在のネットワークでシステムDNSが使えるか確認し、カスタムDNSとDNS over HTTPSを比較します。最後に、同じドメイン・ネットワーク・ルールで結果を検証しましょう。初期値や選択肢は、現在のアプリ画面で確認してください。
1. DNS検索と通信接続を分けて考える
DNSは、ドメイン名を接続に必要な情報へ変換します。一般的なAレコードはIPv4アドレス、AAAAレコードはIPv6アドレスを返します。アドレスを取得した後、クライアントはTCP、UDPなどで通信を確立する必要があります。そのため、「名前解決できること」と「ウェブサイトを開けること」は別々に確認します。DNSがアドレスを返しても、接続先のポートに到達できる、プロキシ接続が成功する、あるいはサイトの証明書が正常であるとは限りません。
以下は、端末側で名前解決する一般的な流れです。すべてのリクエストが端末側のDNSを経由するとは限りません。プロキシ接続によってはドメイン名をリモート側で解決する場合があり、アプリが独自の暗号化DNSを使うこともあります。問題を調べる際は実際のリクエスト記録を確認し、一つのDNS設定ですべてのアプリの問い合わせを強制的に制御できると考えないでください。
たとえば「サーバーが見つかりません」と表示された場合は、名前解決がタイムアウトしていないか、存在しないという応答が返っていないかを確認します。アドレスを取得できたのに接続がタイムアウトする場合は、出力経路、接続先ポート、ネットワーク環境を調べてください。ブラウザーのエラー表示だけを根拠に、DNSを何度も変更するのは避けましょう。
2. システムDNS・カスタムDNS・DoHの違い
システムDNSは通常、Wi-Fi、モバイル通信、デバイス管理設定など、現在のネットワークに設定された名前解決方法に従います。カスタムDNSは使用するDNSサーバーを指定する設定です。DNS over HTTPS（DoH）は、HTTPS接続を通じてDNSクエリを送信します。この二つは別々の分類ではありません。DoHサービスのアドレスを手動で入力することも、カスタムDNS設定の一種です。
| 方式 | 主な通信方式 | 適した状況 | 主な確認ポイント |
|---|---|---|---|
| システムDNS | システムと現在のネットワーク設定による | 現在のネットワークで名前解決が正常な場合、または内部ドメインへアクセスする場合 | ネットワーク切り替え後にDNSサーバーや内部ドメインの解決結果が変わるか |
| カスタムDNS（従来方式） | 通常はUDP 53。一部の応答ではTCP 53 | 到達可能なDNSサーバーのアドレスが明確な場合 | サーバーへの経路、ポート53、応答レコードが想定どおりか |
| DNS over HTTPS | 通常はHTTPS 443 | 到達可能なDoHサービスがあり、クエリの通信を暗号化したい場合 | 完全なURL、証明書、サービスドメインの名前解決、接続経路 |
DoHは端末とDoHサービス間のクエリ通信を保護しますが、DNSサービスにはクエリの内容が伝わります。また、すべての通信を暗号化するものではありません。プロキシ経由になるかどうかは、実際の名前解決経路と出力ルールを別途確認してください。URLがhttps://で始まるからといって、通信接続もプロキシ経由に変わったとは限りません。
設定の目安：まず安定した状態を記録し、必要に応じて暗号化DNSを試す
現在のネットワークで名前解決が安定しているなら、まずシステムDNSの動作を記録します。再現性のある問題がある場合や、クエリ通信を暗号化する明確な理由がある場合に限り、到達可能と確認できているカスタムDNSまたはDoHサービスを一つ試してください。一度に複数の不明な設定を追加しないでください。
3. Settings → DNSの設定手順と値の記録
Settings → DNSを開き、現在の値を記録します。次に、Configで現在有効な設定にDNS関連の項目が含まれているか確認してください。アプリ設定とConfigの両方が実際の動作に影響する場合があるため、片方の入力欄だけを見て判断しないでください。項目名、初期値、対応する形式は現在のアプリ画面で確認しましょう。古い設定の値を、すべてのデバイスの初期値とみなさないでください。
- 現在の設定を保存する。Settings → DNSの内容と有効なConfigを記録し、必要なら元のConfigのコピーを保存します。使える設定を上書きしないでください。
- 方式を一つ選ぶ。システムDNS、従来方式のカスタムDNS、DoHを試す際は、各テストで変更する項目を一つに絞ります。Global Routing、サーバーの選択、テストするネットワークは同じ条件に保ってください。
- 実際のサービス情報を入力する。従来方式のDNSには到達可能なサーバーアドレスを、DoHにはサービス提供元が明示する完全なURLを入力します。パスを推測したり、通常のウェブサイトのトップページをDoHエンドポイントとして使ったりしないでください。
- 画面の案内に従って保存・適用する。現在の画面で再接続後に反映すると表示された場合は、案内どおりに操作してから新しいクエリを送信します。既存の接続やキャッシュには、以前の結果が残ることがあります。
- 検証してから設定を残す。同じドメインで名前解決と通信接続を確認し、Wi-Fiとモバイル通信を切り替えて再テストします。新たな問題が起きた場合は、記録した元の設定に戻してください。
従来方式DNSの記録カード
- 確認項目
- Settings → DNS
- アドレス形式
- DNSサーバーのIPv4またはIPv6アドレス
- 一般的なポート
- UDP 53。必要に応じてTCP 53
- 記録例
192.0.2.53（ドキュメント上の例）
例示用アドレスは、実際に使えるDNSサービスではありません。実際の値は、利用中のネットワークまたはDNSサービスの案内を確認してください。
DoHの記録カード
- アドレス形式
- scheme・ドメイン・パスを含む完全なURL
- 形式例
https://dns.example.com/dns-query- 一般的なポート
- HTTPS 443
- 事前条件
- サービスドメインを名前解決できること、証明書が有効であること、エンドポイントに到達できること
このURLは形式を示す例であり、利用可能なサービスではありません。パスには実際のサービスが指定する値を使用してください。
複数のアドレスを設定しても、記載順に必ず一つずつ試すとは限りません。クエリの振り分け方法やフォールバックの有無、現在の名前解決に使われる設定は、アプリとConfigの実際の動作によって異なります。問題の切り分けでは、複数のアドレスを並べるより、明確な参照先を一つだけ使うほうが結果を判断しやすくなります。
4. DoHに接続できないときは、サービスドメインの初期名前解決を確認
DoHエンドポイントも通常はドメイン名です。HTTPS接続を確立する前に、端末はそのドメインのアドレスを取得する必要があります。この処理は初期名前解決と呼ばれることがあります。唯一の名前解決経路が、まだ確立していないDoH接続に依存していると、循環依存が起こる可能性があります。DoHを有効にすると新しいドメインがすべてタイムアウトする一方、元のDNS設定に戻すとアクセスできる、といった症状が現れることがあります。
- URLを確認する。前後に空白がないか、パスが欠けていないか、コピー時に途中で切れていないか確認します。
/dns-queryはよく使われるパスですが、すべてのサービスで必須ではありません。 - 証明書を確認する。端末の時刻が正しいか、HTTPS証明書がサービスドメインと一致するかを確認します。接続問題を隠すために証明書検証を無効にしないでください。
- 初期名前解決を確認する。以前から使えている名前解決方法でサービスドメインのアドレスを取得できるか確認し、現在の設定に循環依存がないか調べます。
- 通信経路を確認する。ポート443に到達できることは必要条件の一つにすぎません。通常のウェブページが開けても、DoHクエリへの応答が有効とは限りません。
DoH URLのドメインを、任意のIPアドレスに置き換えないでください。HTTPS証明書やサービスのルーティングが元のドメイン名に依存している場合があり、置き換えると証明書が一致しなくなることがあります。サービス提供元が初期名前解決やアドレスの固定方法を案内している場合は、実際のドキュメントとアプリの対応項目に従って設定してください。経験則でパラメーターを組み合わせないでください。
5. DNSとGlobal Routing・ルールによる振り分けの関係
Home → Global RoutingのProxy、Direct、Config、Sceneは、ルーティング方式を選ぶ項目です。DNSサーバーアドレスとは別の設定です。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定ルールに従い、Sceneは選択中のシーン設定に従って処理します。ルールの適用状況を調べる前に、現在の方式が想定したルールを使っているか確認してください。
以下はルール構文の例であり、現在のConfigと置き換えて使える完全な設定ではありません。PROXYを使うには、現在の設定で有効なポリシーを参照できる必要があります。ドキュメント用のアドレス範囲は、実際の通信先を示すものではありません。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXはドメインのサフィックスで照合します。通常、そのルールを照合するためだけに、先に対象IPを問い合わせる必要はありません。このルールはDNSサーバーの設定ではありません。IP-CIDRは接続先IPが属するネットワーク範囲で照合します。例のno-resolveは、このルールのためにドメイン名を積極的に名前解決しないことを示します。対象IPがすでに分かっていれば、ネットワーク範囲の判定は可能です。GEOIPはIPアドレスの地理情報データを使って照合します。アドレスをまだ取得していないドメインへのリクエストでは、判定に名前解決が関わることがあります。また、地理情報による判定が接続先の実際の所在地を保証するわけではありません。FINALは、それ以前のルールに一致しなかった場合に適用するフォールバックポリシーを指定します。DNS応答の誤りや到達不能なDNSサーバーを修正するものではありません。
DNSを変更すると、返される接続先アドレスが変わり、IPアドレスを使うルールの照合結果に影響することがあります。反対に、プロキシの出力経路やネットワーク環境が、DNSサービスへの接続に影響する場合もあります。問題を調べるときは、「ドメイン名をどう解決したか」と「解決後にどの経路で接続したか」を分けて記録してください。両方を同時に変更すると、原因を特定しにくくなります。
6. 条件を固定して検証し、一度のページ表示だけで判断しない
DNSキャッシュ、接続の再利用、ウェブサイト側の複数アドレスの振り分けは、テスト結果に影響します。設定を変更しても既存のページ接続は継続する一方、新しいドメインへの接続が失敗することがあります。設定が保存されていないとは限りません。正常に動作すると確認済みの公開ドメインと、実際に問題が発生しているドメインを一つずつ選び、条件をそろえて名前解決の段階と接続の段階を別々に記録してください。
- 基準を記録する：同じWi-Fiを使い、現在のDNS方式、Global Routing、選択中のサーバー、対象ドメイン、エラーメッセージを記録します。
- 基本接続を確認する：HomeのConnectivity Testで、テスト対象への接続状況を確認します。テスト成功は、そのテスト経路が使えることを示すだけで、すべてのドメインやDNSクエリが正常であることを意味しません。
- 一項目だけ変更する：DNS方式のみを切り替え、アプリの案内に従って設定を適用します。同じ対象に新たに3回アクセスし、成功・タイムアウト・明確なエラーを記録してください。3回分の結果を長期的な性能評価として扱わないでください。
- ネットワークの違いを確認する：次にモバイル通信へ切り替え、ほかの条件は変えずにテストします。Wi-Fiだけで失敗する場合は、まずそのネットワークの名前解決とポート制限を確認してください。
- 元の設定に戻して再確認する：元の設定を復元し、同じテストをもう一度行います。設定を切り替えるたびに問題が安定して再現する場合に限り、その名前解決経路が原因であると判断する根拠になります。
判断の目安：名前解決できてもタイムアウトする場合は、接続を確認
記録で接続先アドレスを取得済みと分かり、その後の接続段階で失敗している場合は、ルールの照合結果、出力ポリシー、接続先ポートを確認します。アドレスを取得できない場合は、DNSサービスへの到達性、DoHの初期名前解決、キャッシュの影響を重点的に調べてください。
7. DNS設定に関するよくある質問
DoHを有効にしたらウェブページの表示が遅くなりました。使い続けるべきですか？
同じネットワーク、同じGlobal Routingの条件で、以前の名前解決方法と比較します。DoHは初回接続時に初期名前解決やTLS接続の時間がかかることがあり、その後の接続では再利用される場合があります。新しいアクセスを複数回試しても明らかに遅い、またはタイムアウトするなら、まず元の設定に戻し、エンドポイントに到達できるか確認してください。「暗号化されているから速い」とは限りません。
会社や自宅の内部ドメインが開けません。パブリックDNSに変更すれば解決しますか？
内部ドメインの名前を知っているのは、現在のネットワークのDNSサーバーだけという場合があります。まずネットワーク本来のDNSに戻して、内部ドメインにアクセスできるか確認してください。複数の名前解決経路を使い分ける必要がある場合は、現在のConfigが対応する設定で明確に分けます。そのレコードを持たない外部DNSサービスへ、内部専用ドメインを継続的に送信しないでください。
DNSを変更しても一部のウェブサイトが開けません。IPv6の問題でしょうか？
一部のサイトが失敗するだけでは判断できません。AAAAレコードが返されているか、IPv6での接続段階に失敗しているかを確認してください。AAAAレコードがあるのはIPv6アドレスが存在することを示すだけで、現在のネットワークから利用できる経路があるとは限りません。既存のIPv6関連設定を記録してから、一項目ずつテストします。DNS、ルール、ネットワーク設定を同時に変更しないでください。
サブスクリプションの更新に失敗しました。DNSを変更すれば直りますか？
まずHomeで利用中のサブスクリプションを更新し、具体的なエラーを記録します。ドメインの名前解決に失敗したという表示なら、サブスクリプションドメインの名前解決を確認してください。HTTPステータスエラー、認証情報の失効、応答内容の解析エラーであれば、DNSを変更しても通常は解決しません。サブスクリプション更新と通常の通信では異なる経路が使われる場合があるため、別々に検証してください。
最終的に使う設定を残す際は、テストしたネットワークと現在のConfigも記録してください。次回、ネットワークの変更やConfigの更新後に問題が起きた場合は、まず条件を比較してからDNSを変更するか判断します。Global Routingやルールの確認方法は、項目ガイドのGlobal Routingの説明とルールの説明をご覧ください。