ShadowrocketのDNS設定は、まず動作確認できる状態を基準として残し、必要に応じて変更します。システムDNSは現在のネットワークで名前解決できるか確認する際に適しています。カスタムDNSでは使用するDNSサーバーを指定でき、DNS over HTTPSでは指定したDNSサービスとの問い合わせ通信を暗号化します。この記事では、利用中のサービスやサブスクリプションがあることを前提に、設定ファイル内のdns-serverの場所、3つの記述方法、順を追った確認手順を解説します。DNSの変更でサーバーへの接続確認が不要になるわけではなく、Webサイトへの通信経路が自動で決まるわけでもありません。
1. ドメインの名前解決と接続の振り分けを区別する
DNSは、ドメイン名の問い合わせを接続に使うアドレス情報へ変換します。たとえばwww.example.comにアクセスする場合、アプリがAレコードまたはAAAAレコードを問い合わせ、取得したIPv4またはIPv6アドレスに接続することがあります。名前解決に成功したのは応答を取得できたという意味であり、接続先のポートに到達できること、TLSハンドシェイクが成功すること、Webページが正常に読み込まれることを保証しません。
この流れはトラブルの切り分けに使うもので、すべての接続が内部で同じ順序で処理されることを示すものではありません。ドメインルールに一致すると、クライアントがドメイン名をもとにポリシーを決めることがあります。ドメイン名の処理をリモート側で行う接続では、ローカルで接続先のアドレスを取得するとは限りません。アプリ独自の暗号化DNS、キャッシュ、設定内のほかのDNSオプションによっても、実際に観察される処理は変わります。
Global RoutingとDNSは別の設定です。Proxy、Direct、Config、Sceneは通信の処理方法を選ぶためのものです。dns-serverは名前解決に使うDNSサーバーを指定します。DNSサーバーのアドレスを入力しても、すべての接続がProxyになるわけではなく、問い合わせが選択中のプロキシサーバー経由で送信されるとも限りません。
2. 3種類のDNS設定で変わること
設定ファイルの[General]では、dns-serverにシステムのDNS、指定したDNSサーバーのアドレス、または対応する暗号化DNSのアドレスを設定できます。以下では設定方法を比較します。速度を順位付けするものではありません。実際の応答時間は、ネットワークの状態、DNSサービスへの到達性、キャッシュ、応答内容によって変わるため、利用中のネットワークで確認してください。
| 方法 | 設定例 | 適したケース | 注意点 |
|---|---|---|---|
| システムDNS | system |
現在のネットワークで名前解決できるか確認したい場合や、LAN内の名前にアクセスする場合 | Wi-Fiとモバイル通信を切り替えると、DNSの参照先が変わることがあります |
| カスタムDNS | 1.1.1.1 |
到達できることを確認済みのDNSサーバーを指定したい場合 | 通常のDNS問い合わせは通信が暗号化されません |
| DNS over HTTPS | https://cloudflare-dns.com/dns-query |
クライアントと指定したDNSサービス間の問い合わせ通信を暗号化したい場合 | エンドポイントへの到達性、TLS検証、エンドポイントのドメイン名の初回名前解決が必要です |
表にあるパブリックDNSのアドレスは記述方法の説明用で、すべてのネットワークに適しているわけではありません。会社や家庭内の名前は、内部DNSでのみ管理されていることがあります。パブリックDNSに変更すると、一般公開されているWebサイトにはアクセスできても、内部名を解決できない場合があります。これは名前解決の範囲が変わったためであり、公開Webサイトが開けるだけでは設定全体が正しいとは判断できません。
判断のポイント：まず確認可能なDNSを選び、必要に応じて通信の暗号化を検討する
現在の名前解決に問題がなければ、まず設定を基準として記録します。DoHを使う場合は、エンドポイントへの到達性と証明書検証が正常であることを確認してから、対象のドメインをテストしてください。アドレスがhttpsで始まるという理由だけで、サーバー接続やルールの確認を省略しないでください。
3. 使用中の設定でdns-serverを変更する
変更前にHome → Global Routingで現在のモードを確認し、Configを開いて使用中の設定ファイルを確認します。複数のファイルを保存している場合、未選択のファイルだけを変更しても、期待した動作にはなりません。混乱を避けるため、まず現在の設定を複製またはバックアップし、元のdns-serverの内容を記録してから、ファイルの編集画面を開きます。
- Configで使用中の設定ファイルを見つけ、その編集画面を開きます。ボタンの表示はアプリ内の現在の画面に従ってください。
[General]セクションと、既存のdns-server行を探します。この行がすでにある場合は値を置き換えてください。同じ設定をファイル末尾に何度も追加しないでください。- 以下の3つの例から1つだけ選びます。ほかに必要な設定は残し、この行だけで設定ファイル全体を置き換えないでください。
- 保存後もこの設定ファイルが選択されていることを確認し、Homeに戻って切断してから再接続し、テストをやり直します。
システムDNS：比較の基準を作る
[General]
dns-server = systemsystemはシステムが提供するDNSを使う指定です。設定ファイルに特定のパブリックDNSアドレスを固定するものではありません。ネットワーク認証が必要なWi-Fiでは、先に認証を完了してください。ネットワークへの接続が許可されていない状態では、パブリックDNSやDoHエンドポイントに変更してもアクセスできるとは限りません。
カスタムDNS：DNSサーバーを指定する
[General]
dns-server = 1.1.1.1ここで指定するIPアドレスはDNSサーバーのアドレスであり、プロキシサーバーやアクセス先Webサイトのアドレスではありません。通常のDNSアドレスを複数指定する場合は、半角カンマで区切ります。例：dns-server = 1.1.1.1, 8.8.8.8。リストの順番が厳密なプライマリ・バックアップ切り替えを保証するとは限りません。問題の切り分けを始めるときは、まず1つだけ指定すると確認しやすくなります。
DNS over HTTPS：エンドポイントを完全な形で指定する
[General]
dns-server = https://cloudflare-dns.com/dns-queryDoHには、DNSサービスが提供するHTTPSエンドポイントを完全な形で指定します。サービスの紹介ページを指定するものではありません。https://を省略したり、/dns-queryのパスを独断で削除・変更したりしないでください。ドメイン名形式のエンドポイントでは、接続を確立する前にアドレスを取得する必要があります。DoHを使っても、初回の名前解決が一切不要になるわけではありません。
設定ファイルの確認項目
- 場所
- Config → 使用中の設定ファイル
- セクション名
[General]- キー名
dns-server- 操作
- 既存の値を変更し、保存して再接続
例はDNSの行のみを示したものです。設定ファイル全体の代わりにはなりません。
DoHエンドポイントの確認項目
- プロトコル
https://- ホスト
cloudflare-dns.com- パス
/dns-query- 前提条件
- エンドポイントに到達でき、TLS検証が正常に動作すること
通常のWebページでエラーページが表示されても、それだけでDoHの問い合わせ失敗とは判断できません。
4. DNSとルール、On Demandの関係
ルールによる通信の振り分けを確認するには、まずHome → Global RoutingでConfigを選び、使用中のファイルの[Rule]を確認します。ドメインルールとアドレスルールでは、照合に使う情報が異なります。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの所在地データベースをもとに照合します。アドレスの取得が必要なルールでは、DNSの応答結果が影響する場合があります。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECTは、該当するドメインとそのサブドメインに一致させるルールです。DNSサーバーを指定するものではありません。IP-CIDRの例はプライベートアドレスの範囲を対象とします。no-resolveは、このルールへの照合のためにドメイン名の追加の名前解決を行わない指定であり、DNS全体を無効にするものではありません。GEOIP,CN,DIRECTはIPアドレスをもとに判定します。結果はWebサイトの言語やドメインのサフィックスと単純に同じとは限りません。FINAL,PROXYは、それ以前のルールに一致しない場合に適用されます。例は記述方法を示すものなので、既存のルールセット全体と置き換えないでください。
Settings → On Demandは、条件に応じて接続を開始または切断する機能であり、DNSサーバーを選択する機能ではありません。テスト中にWi-Fiの切り替えで接続状態が自動変更されると、変更前後のリクエストが異なる条件で実行されることがあります。テストに影響する条件を記録するか、一時的に無効にし、確認後に元の設定へ戻してください。
利用中のサブスクリプションの更新とConfigファイルの更新も、別のものとして考えてください。サーバーリストが変わっても、現在の設定のDNS行が同期されるとは限りません。設定ファイルを再取得または置き換えた場合は、[General]をもう一度確認し、変更内容が残っているか確認してください。
5. 変更後は条件をそろえて確認する
「あるWebページがたまたま開いた」ことだけを根拠にしないでください。ネットワーク、サーバー、Global Routing、テスト対象を固定し、dns-serverだけを変更します。キャッシュによって変更直後も以前の結果が使われたり、既存の接続が継続したりすることがあります。テストでは再接続後にリクエストをやり直し、すでに開いているページへ戻るだけで済ませないでください。
- 変更前の状態を記録する。元のDNS値、使用ネットワーク、Global Routingのモードを保存し、同じサーバーでConnectivity Testを実行して成否を記録します。
- 1項目だけ変更する。DNS値を1つだけ変更して、現在の設定を保存し、切断してから再接続します。ルール、サーバーのプロトコル、On Demandの条件は同時に変更しないでください。
- リクエストをやり直す。アクセスできることが分かっているドメインを開き直し、以前失敗したドメインにもアクセスします。LAN内のサービスが必要な場合は、その内部名もテストしてください。
- 接続状況を確認する。Dataの接続ログで対象、ルール、処理結果を確認します。画面に名前解決の詳細が表示されない場合、通信量のカウントだけから使用されたDNSサービスを推測しないでください。
- ネットワークごとに再テストする。Wi-Fiとモバイル通信のそれぞれで確認し、結果を記録します。一方のネットワークだけで失敗する場合は、そのネットワークからDNSサーバーまたはDoHエンドポイントに到達できるか、まず確認してください。
- 元の設定に戻して比較する。元の値に戻して再テストします。設定変更に応じて失敗が再現する場合に、新しいDNSの参照先やエンドポイントを詳しく確認してください。変更を重ねて原因を分かりにくくしないようにします。
Connectivity Testは接続可能かどうかを確認する機能ですが、1回成功しただけでは、すべてのドメインが指定したDNSサーバーを使ったことや、DNS問い合わせの送信経路までは証明できません。同様に、DataにDIRECTやPROXYと表示されても、まず分かるのは該当する接続の処理結果です。それをすべてのDNS問い合わせに当てはめて判断しないでください。
6. よくある質問と元に戻す方法
DoHを設定したら、かえってWebページが開けなくなったのはなぜですか？
まずConfigで使用中のファイルのdns-serverを元の値に戻し、再接続してテストします。元に戻すと正常になる場合は、エンドポイントの記述、ネットワークからの到達性、デバイスの時刻を確認してください。エンドポイントには初回の名前解決が必要で、証明書検証にも正確な時刻が必要です。原因を切り分けられなくなるため、サーバーとルールを同時に変更しないでください。
カスタムDNSにしたら、自宅の内部名を使えなくなりました。
同じWi-Fiでsystemに戻し、内部名をもう一度問い合わせてください。パブリックDNSサービスは、通常、自宅のルーターや職場の内部で管理されている名前を知りません。この種の要件がある場合は、内部名を解決できるDNSを維持し、実際のネットワーク構成に応じてパブリックドメインを扱ってください。内部名の解決失敗を、すぐにプロキシサーバーの問題と判断しないでください。
変更を保存したのに、まったく変化がないように見えるのはなぜですか？
Configで実際に選択されているファイルを確認し、別のコピーを編集していないか、dns-serverを重複して記述していないか確認します。保存後、Homeから切断して再接続し、リクエストをやり直してください。対象アプリが独自の暗号化DNSやキャッシュを使う場合、表示される結果にこの設定が直接反映されないことがあります。
DoHを使えば、すべてのDNSが暗号化されていると言えますか？
いいえ。この値で指定できるのは該当する問い合わせのエンドポイントであり、エンドポイントの初回名前解決、アプリ独自の名前解決、ほかの設定経路までは網羅できません。まず設定が反映されていることを確認し、表示可能なログとあわせて実際のリクエストを確認してください。DoHが暗号化するのはDNSサービスまでの通信であり、DNSサービス側では問い合わせ内容の処理が必要です。
最後に、動作確認済みの設定とテスト記録を保存してください。元に戻す場合は、今回変更したDNS行だけを復元して保存し、再接続します。設定ファイル全体も入れ替えた場合は、バックアップを復元してGlobal Routingを再確認してください。こうすることで、「DNSの参照先の変更」と「通信ポリシーの変更」を分けて確認でき、複数の項目を何度も切り替えて試す必要がありません。
ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリで、入手先はApp Storeのみです。主にiPhone/iPadで利用でき、システム要件はApp Storeのページに記載された内容をご確認ください。アプリの買い切り購入に回線サービスは含まれません。この記事ではサーバーやサブスクリプションを提供、販売、推奨していません。接続と名前解決の確認は、利用者がすでにサービスを用意していることを前提としています。