ShadowrocketのDNS設定はドメイン名の名前解決を担うもので、プロキシの出口選択とは異なります。利用可能な接続設定があることを前提に、まずシステムDNSを基準として、カスタムDNSやDNS over HTTPSを使う場面、設定が上書きされるケース、DNSレコードとルールの判定結果による変更の確認方法を解説します。
1. DNSサーバー・問い合わせ方式・通信経路を区別する
Webサイトにアクセスする際、通常はドメイン名をIPアドレスに変換する必要があります。DNSは「この名前に対応するアドレス」を返し、Global Routingとルールは「どの経路で接続するか」を決めます。両者は影響し合いますが、DNSを変更してもWebサイトへの通信が自動的にPROXYへ切り替わるわけではなく、利用中の接続サービスが置き換わることもありません。
「システムDNS」と「カスタムDNS」の違いは、主にDNSサーバーをどこから取得するかです。一方、DNS over HTTPS（DoH）は問い合わせの転送方式を指します。そのため、カスタムDNSでDoHを使うこともでき、3つの排他的な設定から1つを選ぶわけではありません。実際の設定方法を以下の3種類に分け、順番にテストできるようにします。
ポート番号は一般的な慣例であり、利用可能であることの証明にはなりません。DoHには正しいHTTPS endpoint、有効な証明書、到達可能なネットワーク経路が必要です。WebページがHTTPSで開けても、同じホストがDNS問い合わせ用のインターフェースを提供しているとは限りません。本文に記載する予約済みアドレスやサンプルドメインは形式の説明用であり、利用可能なDNSサービスを示すものではありません。
2. システムDNS・カスタムDNS・DoHの選び方
システムDNS：トラブル調査の基準にする
おすすめシステムで現在利用できる名前解決の設定を引き継ぎます。通常は接続中のネットワークによって異なり、Wi-Fiとモバイル通信を切り替えると実際の名前解決環境も変わる場合があります。システムにインストールされたDNS設定が関係することもあるため、常にルーターのアドレスと同じとは限りません。
適している場面：初回の動作確認、標準の動作への復帰、カスタム設定が原因かどうかの切り分け
カスタムDNS：名前解決先を指定する
DNSサーバーを明示的に指定し、ネットワーク切り替えによる変数を減らします。通常のIPアドレスを指定して従来のDNSを使う場合、「カスタム」であることを理由に問い合わせが暗号化されるわけではありません。また、実際の問い合わせ経路からそのサーバーにアクセスできる必要があります。
適している場面：使用するDNSサーバーが決まっている場合、社内ドメインが必要な場合、条件をそろえてテストしたい場合
DNS over HTTPS：DNS問い合わせを暗号化して送信する
DNS問い合わせをHTTPSにカプセル化し、クライアントからDNSサービスまでの通信を保護します。ただし、DNSサービス側から見える問い合わせが隠れるわけではなく、Webサイトへの通信経路、最終的な接続品質、期待どおりのDNS応答が保証されるわけでもありません。
適している場面：信頼でき、接続可能なDoH endpointがあり、DNS通信の暗号化が必要な環境
結論：まず標準の名前解決を確認し、DNSだけを変更する
まずシステムDNSでのアクセス結果を記録し、その後、名前解決方式だけを変更します。サーバー、Global Routing、ルールファイルを同時に変更すると、アクセスが復旧しても、どの変更が効果をもたらしたのか判断できません。
DoHを使っても「すべてのDNS問い合わせがプロキシ経由になる」わけではありません。問い合わせが直通かプロキシ経由かは、現在の設定と実際のログを確認してください。endpointに接続できない場合や、そのホスト名を最初に名前解決できない場合、DoHを有効にしたことで複数のWebサイトが同時に名前解決タイムアウトを起こすこともあります。
3. 変更前にSettingsとConfigの有効な設定を確認する
まずHomeで現在のサーバーとGlobal Routingを記録し、Settings → DNSに設定済みの項目があるか確認します。続けてConfigで現在選択中の設定ファイルを確認してください。有効な設定ファイルに独自のDNSパラメーターが含まれていることがあります。入力欄の値を変更しただけで、すべての接続に新しいDNSが使われると判断しないでください。画面の分類や設定ファイルによって選べる項目は異なる場合があるため、実際に表示される項目を確認してください。
- 元の設定を記録する。現在のDNSアドレス、使用中のConfig名、ルーティングモードを控え、元に戻せる設定ファイルを保存します。サブスクリプションやリモートファイルで設定を管理している場合は、後の更新でローカル変更が上書きされるかも事前に確認してください。
- 基準となる状態を確認する。同じWi-Fi、同じサーバー、同じテスト用ドメインを使い、システムDNSでアクセスします。成功、タイムアウト、名前解決エラーのいずれかを記録し、ページの表示速度だけで判断しないでください。
- 変更箇所は1か所に絞る。SettingsのDNS項目を使うか、自分で管理している有効なConfigを編集します。複数の場所に意味の異なる設定を追加して、どれが優先されるか推測する状況は避けてください。
- 入力形式を確認する。通常のDNSではサーバーアドレスを入力します。DoHでは完全なHTTPS endpointを入力し、パスもDNSサービスの案内と一致させてください。サブスクリプションのURLやWebサイトのトップページをDNS endpointとして指定しないでください。
- 接続し直す。保存後、Shadowrocketを切断して再接続します。古いWebページの接続を終了してから、新たにドメインへアクセスしてください。その後は新しいリクエストのログを確認し、以前のセッションを使って判断しないようにします。
自分で管理しているテキスト形式の設定ファイルでは、dns-serverの記述例を3種類示します。使用するのは毎回1種類だけにし、3つの[General]セクションをまとめてコピーしないでください。システムDNSの記述は基準状態に戻す際に使えます。ほかの2つはそのままでは使用できない形式例なので、利用可能であることを確認した自分のDNS情報に置き換えてください。
# システムDNS
[General]
dns-server = system
# カスタムDNS：192.0.2.53はドキュメント用の予約済みアドレス
[General]
dns-server = 192.0.2.53
# DoH：example.comはendpointの形式例
[General]
dns-server = https://example.com/dns-query4. DNSの応答がDOMAIN-SUFFIX・GEOIP・IP-CIDRに与える影響
ドメインルールとIPルールでは、判定する対象が異なります。DOMAIN-SUFFIXはドメイン名とそのサブドメインを確認し、IP-CIDRは接続先IPが指定されたネットワーク範囲に含まれるかを確認します。GEOIPはIPデータベースに基づいて分類します。DNSの応答アドレスが異なると、後者2種類のルールで判定結果が変わる場合がありますが、ドメインのサフィックス自体は変わりません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- まずドメインで判定される。リクエストのドメイン名が
www.example.comの場合、1つ目のルールに一致してPROXYが選択されれば、後続のIPルールはこのリクエストの処理を決めません。 - IPアドレスも判定に使われる。ドメインルールに先に一致しないリクエストでは、後続のIPルールが既知の接続先アドレスやDNSの応答に依存することがあります。追加の名前解決が行われるかどうかは、ルールのオプションとリクエストの状態によって異なります。
- no-resolveの意味を確認する。2つ目の例にある
no-resolveは、そのルールへの一致判定のためにドメイン名を積極的に名前解決しないという意味であり、すべてのDNSを無効にするものではありません。リクエストに接続先IPがすでに含まれている場合は、ネットワーク範囲との照合が行われます。 - FINALを最後のルールとして残す。
FINALは前のルールに一致しなかったリクエストを処理するため、末尾に置きます。例の予約済みネットワーク範囲は構文の説明用であり、実際のネットワーク範囲を表すものではありません。
この種類のルールを確認する前に、Home → Global RoutingでConfigを選択してください。ProxyとDirectでは、このConfigのルール一覧と同じ方法で振り分けられるわけではありません。Sceneの場合は、現在のシーンで実際に使用される設定も確認する必要があります。そうしないと、出口の変化をDNSの影響と誤認し、モードの変更を見落とす可能性があります。
同じドメインから異なるIPアドレスが返されても、直ちに名前解決の異常とは限りません。CDNの振り分け、キャッシュ、DNSサーバーの設置場所、A / AAAAの問い合わせ種別などが違いを生むことがあります。「返されたアドレス」「一致したルール」「実際の接続先」を分けて記録し、毎回同じ応答になることを求めないでください。
5. 設定変更後の確認方法：名前解決とアクセスを別々にテストする
「ページが開いた」という結果だけでは、そのアクセスが完了したことしか確認できず、DoHが有効になった証拠にはなりません。ブラウザーが古い接続を再利用したり、デバイス、アプリ、DNSサーバーにキャッシュが残っていたりすることがあります。まず、自分で管理でき、問い合わせログを確認できるテスト用ドメインを使ってください。管理できるドメインがない場合は、少なくともテスト時刻を記録し、以前のログと新しいログを区別します。
テスト方法：同じ設定で2種類のネットワークを個別に確認
Wi-Fiでテスト
- サーバー、Config、Global Routingを固定し、ルールは同時に変更しないでください。
- 再接続してテスト用ドメインにアクセスし、A / AAAAの応答と名前解決エラーを記録します。
- endpointへの接続可否を確認し、社内ドメインが引き続き名前解決できるかも確認します。
モバイル通信で再テスト
- 接続ネットワークだけを切り替え、同じDNS設定を維持します。
- 新たにリクエストを送り、特定のネットワークだけでタイムアウトするか比較します。
- DNSの応答が正常でもアクセスできない場合は、ルール、出口、IPv6の経路を確認します。
両方のネットワークでテストに成功してから新しい設定を維持してください。一方だけで失敗する場合は、そのネットワークからDNSサービスまでの経路を優先して確認します。
- まず名前解決のログを確認する。利用可能なDNSログや接続ログでテスト用ドメインを検索し、時刻、返されたアドレス、エラーを確認します。ログにDNSサーバーや転送方式が記録されていない場合、そのログだけを根拠にDoHが使われたと断定することはできません。
- 次にルールの判定を確認する。ログに記録されたポリシーとルール行が一致しているか確認します。たとえばドメインが
DOMAIN-SUFFIXに一致するはずなのにFINALに到達する場合は、実際のリクエストドメインと有効なConfigを確認してください。 - 最後に接続結果を確認する。有効なIPアドレスがあるのにTCP接続がタイムアウトする、またはTLSハンドシェイクに失敗する場合は、接続経路と接続先のWebサイトも確認してください。あらゆるエラーをDNSの問題と決めつけないでください。
- 必要に応じて元の設定と比較する。DNSを元の設定に戻し、ほかの設定は変えずに同じドメインをテストします。復元後すぐに正常化した場合に、新しいDNSサービスやendpointまでの経路をさらに調べる根拠が得られます。
問い合わせが実際にDoH経由だったことを確認するには、DNSサービス側の問い合わせログ、またはHTTPSの問い合わせ先を明示する診断情報が最も直接的な証拠です。名前解決が速くなった、応答アドレスが変わった、ブラウザーに鍵マークが表示された、といった事実はその証拠の代わりにはなりません。
6. よくある質問：タイムアウト・社内ドメイン・更新による上書き
DoHアドレスを設定したら、すべてのWebサイトにアクセスできなくなりました。
保存しておいたシステムDNSの設定に戻し、再接続してください。アクセスが復旧したら、endpointの完全なパス、証明書、ポート、接続可否を順に確認します。ホスト名自体を名前解決できない場合は、初回の名前解決条件も確認してください。問題を見えにくくするために、複数の不明なendpointを一度に追加しないでください。
Webページは開けますが、会社の社内ドメインにアクセスできません。DNSを変更すべきですか？
まずデバイスが必要な社内ネットワークに接続されていることを確認し、そのドメインの応答に社内DNSが必要か確認してください。一般向けのDNSサービスには、通常、企業内のレコードはありません。社内で利用できるDNS設定に戻すか、組織が指定するドメイン振り分けの要件に従ってください。社内ドメインを関係のないDNSサーバーに繰り返し問い合わせないでください。
設定を変更したのに、ログに古いIPアドレスが表示されるのはなぜですか？
まずログの時刻を確認し、古いWebページのセッションを終了して再接続してから、新しいリクエストを送信してください。キャッシュの有効期間が残っている場合や、アプリが古い接続を再利用している場合は、新しいDNS問い合わせが記録されないことがあります。それでも変化がなければ、同じアドレスを何度も入力するのではなく、Configで実際に選択されている設定ファイルを確認してください。
一部のWebサイトだけ失敗します。IPv6を無効にするべきですか？
まずAとAAAAの応答を個別に確認し、接続に失敗した際に実際に使われたアドレスの種類を調べてください。AAAAの応答があっても、現在の出口から利用できるIPv6経路があるとは限りません。ログがその判断を裏付ける場合に限り、ほかの設定を変えずに比較テストしてください。原因を特定せずにIPv6を一律に無効にしないでください。
更新後にDNS設定が元に戻るのはなぜですか？
Configで使用中の設定がリモート更新の対象か確認し、更新前に保存したファイルと比較してください。サブスクリプションの更新と設定ファイル全体の更新は同じではないため、まず何が更新されたかを確認します。ローカルのDNS変更を維持する必要がある場合は、自分で設定ファイルを管理し、今後の変更をどのように統合するか決めてください。
調査中に接続状態が自動で変わる場合は、Settings → On Demandも確認し、自動接続の条件が設定されているか確認してください。テスト時は現在の状態を記録し、手動で切断した直後に再接続されて誤った判断をしないようにします。テスト後は元の自動接続設定に戻してください。
設定を維持する基準は、対象ネットワークで名前解決が安定していること、必要な社内ドメインが利用できること、ルール判定が想定どおりであること、元の設定に戻せることです。DNS over HTTPSが変更するのは問い合わせの転送方式です。サーバーへの接続性、Global Routing、ルールの順序の確認に代わるものではありません。