ShadowrocketのDNS設定ガイド：システムDNS・カスタムDNS・DNS over HTTPSの選び方

1. DNS設定で変わること・変わらないこと

ShadowrocketのDNS設定は、ドメイン名を後続の接続に必要なIPアドレスへ変換する名前解決に関わります。システムDNSは、現在のネットワークでシステムが利用するDNSサーバーを使う方式です。カスタムDNSは、DNSサーバーのアドレスを明示的に指定する方式です。DNS over HTTPSは、DNS問い合わせをHTTPSで送信する方式を指します。この3つは完全に排他的な分類ではありません。手動で指定したDNSサーバーを、DNS over HTTPSで利用することもできます。

DNSの名前解決と、プロキシ経由の接続は別の処理です。IPアドレスが返されたからといって、その後の接続で必ずProxyが使われるわけではありません。暗号化DNSを使っても、すべてのDNS問い合わせが既存のサーバーを経由するとは限りません。実際の動作は、現在の設定、Global Routing、DNS問い合わせ自体のルーティング、対象ドメインをリモート側で解決するかどうかによっても変わります。

この流れは各処理の役割を区別するためのもので、接続のたびにローカルで問い合わせが完了することを意味しません。ドメイン名が分かっている場合は、DOMAIN-SUFFIXなどのドメインルールをそのまま照合できます。また、接続によってはドメイン名の処理をリモート側に任せる場合もあります。IP-CIDRやGEOIPなど、IPアドレスの情報を使うルールは、実際の名前解決結果やルールのオプションとあわせて確認してください。

2. システムDNS・カスタムDNS・DNS over HTTPSの選び方

まずは安定して動作する設定を基準にします。現在のネットワークのDNSで必要なドメインを正常に解決できるなら、システムDNSはWi-Fi、モバイル通信、社内・家庭内ネットワークに合わせて使いやすい方法です。特定のDNSサーバーを調べたい場合や、問い合わせ先を固定したい場合はカスタムDNSを試します。端末からDNSサーバーまでの問い合わせを暗号化したい場合は、DNS over HTTPSを検討してください。

DNS over HTTPSが保護するのは、端末からDNSサーバーまでの問い合わせ通信です。DNSサーバーは問い合わせ内容を処理できます。また、Webサイトへのアクセスに使うHTTPSの代わりにはならず、遅延が短くなる保証もありません。暗号化接続の初回確立、ネットワークによる遮断、DNSサーバーまでの距離、キャッシュの状態などで、問い合わせ時間は変わります。

3. Configでdns-serverを変更する

まずHome → Global Routingで現在のモードを確認し、Configで実際に有効な設定を確認します。以下の検証手順ではConfigモードを基準にします。ProxyとDirectでは接続処理が変わります。Sceneを使っている場合は、ネットワーク切り替え時に基準が変わらないよう、現在のSceneに対応する設定とルーティング状態を先に確認してください。

1. Configで現在使っている設定を確認し、元の設定を複製して保存します。現在のdns-serverの値も記録しておきます。
2. 対象の設定の編集メニューを開き、Edit Plain Textに進みます。既存の[General]セクションを探し、同じ名前のセクションを重複して追加しないでください。
3. 既存の[General]内でdns-serverの値を置き換えます。以下の3つは選択肢であり、同じフィールドを3行まとめて貼り付けないでください。
4. 保存後、変更した設定が有効になっていることを確認して再接続し、新しいドメインへのアクセスを試します。古い接続を再利用しているページを更新するだけでは不十分です。

システムDNSの設定例

[General]
dns-server = system

systemはシステムが提供するDNSサーバーを使う指定であり、特定のアドレスではありません。Wi-Fiとモバイル通信を切り替えると、システムが取得するDNS情報も変わることがあります。社内や家庭内ネットワークでのみ使える内部ドメインがある場合、パブリックDNSに変更すると名前解決できなくなる可能性があります。

従来方式のDNSアドレスを指定する

[General]
dns-server = 1.1.1.1

ここに示すアドレスはフィールドの書式例であり、DNSサービスの推奨や速度を示すものではありません。複数のDNSサーバーを指定する場合は、dns-server = 1.1.1.1, 1.0.0.1のようにカンマで区切ります。ただし、リストの順番が「1つ目に失敗したら2つ目を問い合わせる」動作を保証するわけではありません。問題を切り分けるため、最初のテストではDNSサーバーを1つだけ指定してください。

DNS over HTTPSの設定例

[General]
dns-server = https://1.1.1.1/dns-query

このエンドポイントは、URL全体の記述例です。DoHアドレスには、DNSサービスが実際に提供するHTTPS問い合わせエンドポイントを指定してください。一般的なWebサイトのトップページはDNSサーバーとして使えません。IPアドレス形式のHTTPSエンドポイントを使う場合、サーバー証明書がそのIPアドレスに対応している必要があります。ドメイン名のエンドポイントを、名前解決で得たIPアドレスに置き換えないでください。また、接続失敗に対処するために証明書検証を無効にしないでください。

4. 再現可能な手順でDNSの反映を確認する

Webページが開いたとしても、そのアクセスが完了したことが分かるだけで、どのDNSサーバーが使われたかは証明できません。ブラウザーが既存の接続を再利用したり、アプリがアドレスをキャッシュしたりする場合があります。また、アプリによっては独自の暗号化DNSを使うこともあります。「問い合わせが行われたか」「どのような応答が返ったか」「その後どのように接続したか」を分けて記録してください。

1. テスト条件を固定する。同じ端末、同じネットワーク、同じ既存サーバー、同じGlobal Routingモードを使います。設定ファイル名と現在のdns-serverの値を記録してください。
2. システムDNSを基準にする。まずsystemを使い、正常に動作することが分かっているドメインと、問題が発生しているドメインをテストします。成功、タイムアウト、ドメインが存在しないなどの結果をそれぞれ記録してください。
3. DNSだけを変更する。DNSサーバーを1つだけ指定して再接続し、テストに使うアプリを終了してから開き直して再試行します。新しい接続にすることで既存接続の再利用による影響を減らせますが、システムやアプリのキャッシュがすべて消えるわけではありません。
4. 確認できる記録を調べる。Shadowrocketのログまたはリクエスト記録で、テストしたドメイン、問い合わせタイプ、返されたアドレス、エラー内容を確認します。DNSサーバーや出力先が確認できる場合は、それも記録してください。Dataの通信量が増えただけでは、DNS設定が反映された証拠にはなりません。
5. 最後にDoHをテストする。HTTPSエンドポイントに変更し、同じ手順を繰り返します。エンドポイントがWebページ、HTTPエラー、TLSエラーを返す場合は、まずエンドポイントの問題を解決してください。ルールも同時に変更しないでください。

DNSサーバーによって異なるIPアドレスが返っても、必ずしも異常ではありません。CDNの振り分け、DNSサーバーの場所、キャッシュの更新、ネットワーク環境によって応答は変わります。接続先に接続できるか、証明書が正しいか、障害が再現するかをあわせて確認してください。2回の結果でIPアドレスが違うだけで、名前解決の異常と判断しないでください。

5. 症状から確認範囲を絞る

問題が発生したら、まず一つ前の単一項目テストに戻ります。DNS、Global Routing、既存サーバー、ルールファイルを同時に変更しないでください。接続が復旧しても、どの変更が効いたのか分からなくなります。

• システムDNSは正常だが、カスタムDNSがタイムアウトする：現在のネットワークからDNSサーバーのUDP/TCP 53にアクセスできるか確認します。通常のHTTPSサイトに接続できても、従来方式のDNSポートに到達できるとは限りません。
• 従来方式のDNSは正常だが、DoHが失敗する：エンドポイントのパス、ポート443、端末の時刻、証明書エラーを確認します。エンドポイントがドメイン名を使う場合、初回接続時にエンドポイント自体のアドレスを取得する必要があります。これは名前解決の初期処理に関する問題です。
• 内部ドメインが使えなくなった：まずsystemに戻して確認します。パブリックDNSは通常、ローカルネットワークや組織内のドメインを認識しません。通信を暗号化しても、必要なDNS情報がなければ名前解決はできません。
• アドレスは返るが、Webページがタイムアウトする：実際に適用されたDOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALのルールと、選択中の出力先を確認します。DNSが成功しても、接続先への接続が成功するとは限りません。
• 一部のWebサイトで断続的に失敗する：AとAAAAの応答、およびそれぞれのネットワーク接続を確認します。AAAAレコードが返っても、現在のネットワークでIPv6経路が使えるとは限りません。一方のアドレスファミリーの応答だけで、すべて正常だと判断しないでください。
• 変更しても動作が変わらない：有効化されていない設定を編集していないか、古い接続を使っていないか、テストするアプリが独自のDNSを使っていないか確認します。リモート設定を使っている場合は、更新時に手動の変更が上書きされていないかも確認してください。

6. 結果を記録して元の設定に戻す

再現性のある結果を確認してから、変更を継続するか決めます。システムDNSは現在のネットワークによる名前解決が必要な環境に、指定DNSサーバーは問い合わせ先を明確に制御したい場合に、DoHは暗号化された問い合わせ通信が必要で、エンドポイントにも安定して接続できる環境に適しています。いずれも実際のネットワークで確認が必要です。フィールド名だけで一律に最適な設定を決めることはできません。

1. 有効だった設定のdns-server、テストしたネットワーク、発生した症状を記録します。既存のサブスクリプションに含まれる認証情報は記録しないでください。
2. 普段使うWi-Fiとモバイル通信でそれぞれ再テストし、ネットワーク切り替え後に到達できないDNSサーバーへ依存しないことを確認します。
3. リモート設定を使っている場合は、更新後に[General]を再確認してください。サーバーのサブスクリプション更新とDNS設定の変更は別の操作です。
4. 元に戻す場合は、バックアップした元の値に戻して再接続します。以前システムDNSを使っていた場合は、dns-server = systemに戻してください。

この記事では、主にiPhoneとiPadでの設定編集とトラブルシューティングを説明しています。ShadowrocketはAppleプラットフォーム向けの有料クライアントです。入手先はApp Storeのみです。システム要件、その他のデバイスの互換性、購入に関する情報はApp Storeのページをご確認ください。アプリの購入と、ユーザーがすでに利用しているサブスクリプションは別々に管理されます。アプリの買い切り購入に通信サービスのプランは含まれません。