Configで現在有効な設定のDNS項目を確認し、利用中のネットワークに応じて、システムの名前解決を維持するか、DNSサーバーを指定するか、DNS over HTTPSを使うかを選びます。DNSやルールの不具合を調べたい方は、利用中のサービスと設定を用意してください。一度に変更するのは一項目だけにし、名前解決の結果、ルールの一致、実際の接続を個別に確認しましょう。
DNSの名前解決と接続の振り分けを区別する
Homeで接続状態とGlobal Routingを確認し、Configで使用中の設定をチェックします。ShadowrocketのDNS設定は一部のドメイン問い合わせの処理方法を決め、Global Routingとルールは接続に適用するポリシーを決めます。DNSサーバーを変更しても、すべてのリクエストの接続先が変わるわけではありません。
この流れは、問題が起きた段階を切り分けるためのものです。すべてのリクエストで毎回新たにDNS問い合わせが行われるわけではありません。アプリ、システム、DNSサーバーが結果をキャッシュすることがあります。また、ドメインルールによって、アドレスを解決する前にポリシーが決まる場合もあります。接続先でドメイン名を処理する通信もあるため、すべてのリクエストが端末上でIPアドレスを取得してから進むとは限りません。
Global RoutingでConfigを使用している場合は、ルールと合わせてリクエストの行き先を判断します。ProxyとDirectは全体のルーティング方針であり、どちらか一方だけでDNS問い合わせの実際の経路を推測することはできません。Sceneを使用している場合は、そのSceneに関連付けられた設定も確認してください。調査中はルーティング方針を固定し、DNSの変更と同時にSceneを切り替えないようにします。
システムDNS・カスタムDNS・DoHの選び方
まず、現在のネットワークで正常にアクセスできるドメインを記録し、3つの方式を比較します。システムDNSはシステムで利用可能な名前解決環境を使います。カスタムDNSは問い合わせ先を指定する方式です。DNS over HTTPS（DoH）は、問い合わせをHTTPSで送信する方式です。後者2つは併用できます。DoHのアドレスを指定することも、カスタムDNS設定の一つです。
| 方式 | 設定する内容 | 適した条件 | 確認事項 |
|---|---|---|---|
| システムDNS | system |
現在のネットワークで名前解決できる場合、またはネットワーク内のドメインが必要な場合 | Wi-Fiとモバイル通信を切り替えると、名前解決環境が変わることがあります |
| カスタムDNS（従来方式） | 利用可能と確認済みのDNSサーバーIPアドレス | 問い合わせ先を固定したい場合。そのサーバーに現在のネットワークから接続できること | 従来方式の問い合わせは、通常、通信が暗号化されません |
| DNS over HTTPS | 完全なhttps://エンドポイント |
問い合わせをHTTPSで送信する必要があり、エンドポイントに接続できる場合 | エンドポイントのパス、TLS証明書、初回の名前解決への依存 |
ルーターの管理用ドメイン、社内サービスなどのイントラネット名が必要な場合は、まずネットワークが提供する名前解決経路を維持してください。パブリックDNSサーバーは通常、内部名を認識しません。すべての問い合わせを外部のDNSサーバーに切り替えると、一般のWebサイトにはアクセスできても、イントラネットのサービスに接続できないことがあります。
要点：使える状態を基準にし、必要な場合だけDNSサーバーを変更
現在、システムDNSで正常に名前解決できているなら、まず設定のコピーを保存します。問い合わせ先を固定したい場合やHTTPSで問い合わせを送信したい場合に限って変更し、同じドメイン、同じネットワークで結果を比較してください。
Configでdns-serverとDoHアドレスを確認する
Configで現在有効な設定を見つけ、まずコピーを保存してから編集画面を開きます。テキストで編集する場合は、[General]内のdns-serverを確認してください。すでに項目がある場合は既存の値を変更します。同じセクションに同名の項目を複数追加すると、どの値が有効か判断しにくくなります。
[General]
dns-server = system上の例はシステムDNSを使用する設定です。DNSサーバーを指定する場合は、利用可能と確認済みのアドレスに置き換えます。DoHを使う場合は、サービス提供元が案内する完全なHTTPSエンドポイントを入力してください。ドメイン名だけを入力したり、通常のDNSサーバーIPアドレスの前にHTTPSを付けたりするものではありません。
システムDNSの基本設定
- 設定画面
- Config → 現在の設定 → 編集画面
- 設定セクション
[General]- 項目
dns-server = system- 確認する環境
- 同じWi-Fiまたはモバイル通信を維持する
保存後、この設定が有効になっていることを確認し、再接続して動作を確かめます。
DoHエンドポイントの確認
- 項目
dns-server- アドレスの形式
https://example.com/dns-query- デフォルトポート
- HTTPSは443を使用
- セキュリティ要件
- ホスト名と証明書が一致し、パスがDoHに対応していること
example.comのアドレスは形式を示す例であり、利用可能なDNSサービスではありません。
保存後、Configに戻って編集した設定が有効になっていることを確認し、Homeで再接続します。有効になっていないファイルを編集しただけでは、現在の接続に変更は反映されません。リモートで管理されている設定は、更新後に項目を再確認してください。リモート設定のローカルコピーを直接編集すると、次回の更新で上書きされることがあります。
- 元の
dns-serverの値と現在有効な設定を記録し、復元用のコピーを保存します。 - 一度に変更するDNSサーバーは一つだけにし、ルール、プロトコルのパラメーター、接続ポリシーを同時に変更しないでください。
- 保存して有効化し、再接続したうえで、同じドメインを使って結果を確認します。
- 結果が悪化した場合は、元の値に戻して再テストし、変化がDNS設定によるものか確認します。
DoHエンドポイントにドメイン名を使う場合、HTTPS接続の確立前にエンドポイント自体のアドレスを取得する必要があります。これが初回の名前解決への依存です。まだ確立されていない同じDoH経路だけに、エンドポイントのアドレス取得を依存させないでください。設定で利用できる導入用の名前解決経路を維持し、ログでどの段階に失敗したかを確認します。
DNSがDOMAIN-SUFFIX、GEOIP、IP-CIDRに与える影響
Configでルールの順序を確認する際は、ドメインによる判定とIPアドレスによる判定を区別します。DOMAIN-SUFFIXはドメインの末尾に基づいて判定します。GEOIPとIP-CIDRはアドレスに基づいて判定します。ルール判定に接続先アドレスが必要な場合、DNSの応答結果が判定に影響することがあります。先にドメインルールが一致すれば、後続のIPルールを判定する必要はありません。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの構文はルールの順序を示す例であり、既存の設定全体を置き換えるためのものではありません。1行目は一致したexample.comのドメインにDIRECTを適用します。2行目は対応するプライベートアドレス範囲に一致し、no-resolveはこのルールのために新たなドメイン解決を行わないことを示します。3行目はアドレスの所属情報を使います。最後に、どのルールにも一致しないリクエストをFINALで処理します。実際に適用するポリシーは、設定で利用可能なものと一致させてください。
- ドメイン情報：ドメインルールで判定できるのは、リクエストの処理時に判定可能なドメイン情報がある場合です。IPアドレスを直接指定したリクエストは、ドメイン末尾のルールだけでは識別できません。
- アドレスの結果：キャッシュ、ネットワーク上の位置、サービスの振り分けなどにより、DNSサーバーごとに異なるアドレスが返ることがあります。その結果、後続のIPルールの判定も変わる場合があります。
- ルールの順序：広い範囲に一致するルールを先に置くと、後続の詳細なルールが実行されないことがあります。DNSを変更する前に、どのルールが一致したかを確認してください。
- レコードの種類：AレコードはIPv4、AAAAレコードはIPv6のアドレスに対応します。いずれかのアドレスを取得できても、そのネットワークから必ず接続できるとは限りません。
順番に確認する：タイムアウト、空の応答、Webページにアクセスできない
同じネットワークで問題を再現し、ドメイン名、時刻、現在の設定、Global Routingを記録します。利用できる接続履歴やログを確認し、まず名前解決の結果があるか、その後の接続が成功したかを調べてください。すべての失敗をDNSの問題と決めつけないようにします。
- ネットワーク自体が使えることを確認する。Web認証が必要なWi-Fiでは、先に認証を完了させます。Wi-Fiで問題があり、モバイル通信では正常な場合は、両方のネットワークでDNSサーバーに接続できるか、ネットワークの制限に違いがないかを優先して比較します。
- 設定が実際に有効か確認する。Configに戻り、有効な設定を確認して
dns-serverも再チェックします。システムが自動的に接続を再確立する場合は、Settings → On Demandで自動接続の条件を確認し、テスト時の接続状態を取り違えないようにします。 - 問い合わせの失敗を区別する。タイムアウトは、待機時間内に必要な応答が得られなかった状態です。NXDOMAINは、DNSサーバーがその名前は存在しないと判断したことを示します。SERVFAILは、DNSサーバーが処理を完了できなかったことを示します。これらを同じ原因で説明することはできません。
- DoHではHTTPSを個別に確認する。完全なパス、端末の時刻、エンドポイントの証明書、接続可能性を確認します。エンドポイントのWebサイトを開けても、入力したパスがDoHに対応しているとは限りません。証明書エラーを検証の緩和で回避しないでください。
- アドレスを取得できている場合は、接続を確認する。DNSからAまたはAAAAが返った後に接続がタイムアウトする場合は、DNSサーバーを次々と変更するのではなく、接続先ポート、IPv4/IPv6の到達性、一致したポリシー、利用中の接続パラメーターを確認します。
- 元の状態に戻して比較する。保存しておいたシステムDNSの設定に戻し、再接続してもう一度テストします。戻しても問題が解消しない場合は、DNSの変更を重ねず、調査範囲を広げてください。
2回のテストの間に、検証に使うアプリを終了して開き直し、必要に応じてDNSレコードのTTLが切れるまで待ちます。再接続しても、すべての階層のキャッシュが消えるとは限りません。同じドメインが短時間に同じ結果を返しただけでは、変更が反映されていない証拠にはなりません。
テスト結果は、「アドレスを取得できたか」「どの種類のアドレスが返ったか」「どのポリシーに一致したか」「接続のどの段階で失敗したか」に分けて記録します。「使える」「使えない」だけの記録より、原因を特定しやすくなります。接続手順の詳しい確認は、接続トラブルの確認方法をご覧ください。
DNS設定でよくある質問
DoHに変更してもWebページが開けない場合、次に何を確認すればよいですか？
まずConfigで、有効な設定とエンドポイントの完全なアドレスを確認します。再接続して、どの段階で失敗するかを調べてください。接続先アドレスを取得できている場合は、一致したルールと接続先への接続を確認します。エンドポイントでTLSエラーが出る場合は、端末の時刻と証明書を確認してください。検証を無効にする方法を通常の解決策として使わないでください。
Wi-Fiでは正常なのに、モバイル通信に切り替えるとDNSがタイムアウトします。どうすればよいですか？
同じ設定とドメインを使い、2つのネットワークでの結果をそれぞれ記録します。カスタムアドレスがルーターのプライベートアドレスなど、ローカルネットワーク内のものなら、モバイル通信から直接アクセスできないことがあります。systemに戻して比較し、両方のネットワークから到達できるDNSサーバーが必要か判断してください。
DoHを設定すれば、すべてのDNS問い合わせが暗号化されますか？
設定項目一つだけで、すべてを判断することはできません。その項目が示すのは該当する問い合わせ経路です。アプリ独自の名前解決、エンドポイントの初回名前解決、その他の経路についても個別に確認が必要です。現在の設定と実際の問い合わせ記録を確認し、対象のリクエストが想定した経路を通っているか判断してください。
既存の設定を更新したら、手動で入力したDNSが変わりました。どうすればよいですか？
Configで更新前後のファイルを比較し、編集したのがリモート設定か、独立したローカルコピーかを確認します。個人設定を残したい場合は、まずバックアップを取り、明確に有効化したローカルコピーを管理してください。その後、設定の同期時に項目ごとに比較し、接続パラメーターとDNSの変更を混同しないようにします。
確認が終わったら、正常に使える設定を基準として保存し、今回の変更内容も記録してください。DNSはネットワークからの到達性、内部名の必要性、問い合わせの通信要件に基づいて選びます。DNSサーバーの数だけで効果を判断することはできません。複数のサーバーを指定しても、記述順に必ず一つずつ切り替わるとは限りません。