DNSに問題がなければ、まずはシステム設定のままにします。特定のリゾルバーを使う場合はカスタムDNS、DNS通信を暗号化する場合はDNS over HTTPSを選びます。利用するサービスや設定がすでにあり、ドメインに接続できない、またはルールの振り分け結果に問題がある方を対象に、設定場所、ルールの照合、変更項目を一つずつ試す方法を解説します。元に戻せる状態も確保しましょう。
1. ドメインの名前解決と接続の出先を切り分ける
ShadowrocketのDNS設定は「ドメインに対応するアドレス」を調べるためのものです。一方、Global Routingや設定ルールは「接続をどの経路に送るか」を決めます。DNSを変更しても接続先サーバーは切り替わらず、サーバーの認証失敗、ポートへの接続不可、回線の混雑も自動では解消されません。Webページが開かないときに複数の設定を同時に変更しないよう、まずこの2つを区別しましょう。
この流れは、問題を切り分けるための考え方を示したもので、すべての接続で端末上の名前解決が先に行われるという意味ではありません。DOMAIN-SUFFIXはドメイン名で直接照合できます。IP-CIDRやGEOIPなど、アドレスを基準とするルールでは名前解決の結果が必要になる場合があります。プロキシ接続で名前解決をリモート側に任せるかどうかは、プロトコル、リクエスト形式、設定によって異なります。Webページが開けたからといって、すべてのDNS通信がプロキシ経由だとは限りません。
ポート番号はプロトコルを見分ける手がかりであり、設定全体の代わりにはなりません。DoHサービスでは指定された非標準ポートを使う場合があります。また、普段はUDPが使われているように見えても、従来のDNSでTCPへのフォールバックが必要になることがあります。ファイアウォールの制限、ネットワークの認証画面、リゾルバー自体の障害も最終的な結果に影響します。
2. システムDNS・カスタムDNS・DoHの選び方
「システムDNS」と「カスタムDNS」は、リゾルバーをどこから取得するかを表します。「DNS over HTTPS」は、クエリをどのような通信方式で送るかを表します。この3つは完全に別々の選択肢ではありません。DoHのエンドポイントを手動で入力する場合も、カスタムリゾルバーの設定にあたります。まず現在の名前解決結果を変える必要があるかを判断し、そのうえで通信方式を変えるか検討してください。
| 設定方法 | 適した状況 | 変更前の確認事項 |
|---|---|---|
| システムDNS | 現在のネットワークで名前解決が正常に動作している場合、または職場・学校・家庭のイントラネット上のドメインにアクセスする必要がある場合 | Wi-Fiまたはモバイル通信で提供されるリゾルバーが利用できるか |
| カスタムDNS（従来方式） | 特定のリゾルバーを使いたい場合。信頼できるリゾルバーのアドレスを入手済みであること | 現在のネットワークからそのリゾルバーにアクセスでき、UDP / TCP 53番ポートが遮断されていないか |
| DNS over HTTPS | DNSクエリをHTTPSで送信したい場合。利用可能なエンドポイントを入手済みであること | エンドポイントの完全なパス、TLS証明書、ドメインの初期名前解決、接続経路がすべて正常か |
システムDNSなら、現在のネットワーク内にあるドメインを引き続き名前解決しやすい場合があります。パブリックリゾルバーでは職場の内部ホスト名を解決できないこともあります。固定のパブリックリゾルバーに切り替えると、外部サイトは開けても社内システムに接続できなくなる場合があります。これは名前解決の対象範囲が変わったためで、Shadowrocketの接続障害とは限りません。
DoHが暗号化するのは、端末と選択したリゾルバー間のDNS通信です。リゾルバーからクエリが見えなくなるわけではなく、Webサイト自体のHTTPSの代わりにもなりません。エンドポイントへの接続やTLSの確立が必要になるため、実際の遅延はネットワーク、接続の再利用、キャッシュによって変わります。従来のDNSより必ず速くなるとは限りません。
結論：イントラネットのドメインに接続できない場合は、まずシステムDNSに戻す
リゾルバーを変更した後にだけ内部ドメインへ接続できなくなった場合は、まずシステムDNSに戻してください。サーバーとGlobal Routingはそのままにして、同じドメインへ再アクセスします。ルールやプロトコルも同時に変更しないでください。
3. ConfigでDNSを設定し、元に戻せる状態を確保する
ここではiPhone / iPadの構成ファイル設定を例に説明します。Configを開き、現在有効な構成ファイルを選んで編集メニューに進み、GeneralのDNS Serverを確認します。編集画面の開き方や項目の配置はバージョンによって異なる場合があるため、テキスト編集画面で照合できる設定キーも記載しています。DNSエンドポイントをHome → Add Serverのサーバーアドレス欄に入力しないでください。
- Homeで選択中のサーバーとGlobal Routingの状態を記録し、Configで現在有効なファイルを確認します。
- 構成ファイルを複製または書き出し、復元用の控えを作成します。コピーだけを編集し、元の構成は変更せずに残してください。書き出した内容は機密情報として保管します。
- Config → 現在の構成の編集メニュー → General → DNS Serverを開きます。テキスト編集を使う場合は、
[General]の下にあるdns-serverを探してください。 - 利用中のリゾルバーのアドレス、またはDoHの完全なエンドポイントを入力します。保存後、コピーした構成が有効になっていることを確認してください。必要に応じて接続をいったん切断してから再接続し、現在のセッションに設定を反映させます。
- 同じドメインを使ってテストし、接続できるか、どのようなエラーが出るかを記録します。失敗した場合は変更を重ねず、元の構成に戻してください。
システムDNSの基準設定
- 場所
- Config → 構成の編集 → General
- 設定セクション
- [General]
- 設定キー
- dns-server
- 値
- system
システムリゾルバーを基準にして、まず元のネットワークで利用できるか確認します。
DoHの設定項目
- プロトコル
- https://
- ホスト名
- リゾルバーが指定するエンドポイントのドメイン名
- パス
- サービスの説明に記載された完全なパスを使用
- デフォルトポート
- 443
パスの慣例だけでエンドポイントを推測しないでください。ブラウザーでWebページが表示されるかどうかだけで、サービスが利用可能かを判断することもできません。
以下の2つはどちらか一方を使う設定例です。同じ構成にdns-serverを2つ重ねて記述するものではありません。2つ目は構文を示すため、予約済みの例示用ドメインを使っています。そのままでは利用できません。実際には、すでに入手しているリゾルバーのエンドポイントを入力してください。この記事では特定のリゾルバーを推奨しません。
# システムDNSの基準設定
[General]
dns-server = system# DoHの構文例：例示用アドレスはそのまま使用できません
[General]
dns-server = https://dns.example.com/dns-queryホスト名を含むDoHエンドポイントでは、最初の名前解決が必要です。端末はHTTPS接続を確立する前に、エンドポイントのドメイン名に対応するアドレスを取得する必要があります。ホスト名を安易にIPアドレスへ置き換えると、証明書の名前照合やサービスのルーティングに失敗する場合があります。現在のネットワークでエンドポイントのドメイン名を解決できない場合は、まず正常に動作する基準設定に戻し、初期の名前解決についてサービスの説明を確認してください。
4. DNSとルールによる振り分けの関係
構成ファイルのルールを検証する場合は、HomeでGlobal RoutingをConfigに設定します。ProxyとDirectは全体に適用される異なるルーティング設定です。この状態でのテスト結果だけでは、構成ルールが動作している証明にはなりません。Sceneを使う場合は、実際に有効なSceneと、そのSceneに対応する設定も確認してください。DNSを変更する前後で同じ設定状態を保つと、結果を比較しやすくなります。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY：指定したドメインとそのサブドメインに一致します。アドレスの割り当て先ではなく、ドメイン名で判定します。例示用ドメインはサービスの推奨を意味しません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このプライベートアドレス範囲に一致します。no-resolveは、このルールのためにドメイン名の名前解決を行わないことを示します。宛先アドレスがすでに分かっている場合は、引き続き照合できます。GEOIP,CN,DIRECT：対象IPの地理情報データベース上の分類に基づいて判定します。Webページの言語やドメインの末尾で判断するものではありません。名前解決の結果が変わると、間接的にルールの一致結果も変わる場合があります。FINAL,PROXY：前のルールに一致しなかった場合に適用されるフォールバックです。名前解決の失敗を解消するものではなく、DNSクエリ自体が同じ経路で送信される証拠にもなりません。
ルールは上から順に照合されます。上の例では、まず特定のドメイン、次にアドレス範囲を処理し、最後にフォールバックを適用します。「DNSを直す」ために広範囲のルールを先頭へ移動すると、後にある詳細なルールが適用されなくなる場合があります。例をコピーする前に、現在の構成で使われているポリシー名を確認し、既存のポリシーグループを上書きしないようにしてください。
5. 項目を一つずつ変えて名前解決の問題を切り分ける
テストを始める前に、Homeで使用するサーバーが選択されていることを確認し、Connectivity Testを実行します。これは接続状態の基準を確認するためのもので、すべてのDNSリクエストを検証するものではありません。テストに成功しても、リゾルバーが誤った結果を返す、ルールが誤って一致する、Webサイト側に問題があるなどの理由で、特定のドメインに接続できない場合があります。
- 条件を固定します。同じWi-Fi、同じサーバー、同じドメイン、同じGlobal Routing設定を使います。プロトコルの変更やサブスクリプションの更新は、いったん行わないでください。
- まず基準を確認します。システムDNSを使う構成を有効にし、ページが開くか、ドメイン名解決エラーが表示されるか、一部のサイトだけに影響するかを記録します。
- リゾルバーだけを変更します。カスタムDNSまたはDoHの構成を有効にし、接続し直して同じページにアクセスします。初回リクエストとキャッシュが使われたときの結果は分けて記録してください。
- 次にネットワークを切り替えます。DNS設定は変えずに、Wi-Fiからモバイル通信へ切り替えます。一方のネットワークだけで失敗する場合は、ネットワーク認証、ポート制限、エンドポイントへの到達性を確認してください。
- 元に戻して再確認します。システムDNSに戻して、もう一度テストします。一度成功しただけでは原因を特定できません。同じ結果を繰り返し確認できるかを調べてください。
| 確認された状況 | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| システムDNSは正常だが、DoHが繰り返しタイムアウトする | エンドポイントのドメイン名と完全なパス、接続経路、ネットワークの制限 | 基準設定に戻し、エンドポイントの説明を確認してから個別にテストする |
| 外部サイトは正常だが、職場の内部ドメインに接続できない | 内部ドメインを解決できないリゾルバーに変更していないか | 同じネットワークでシステムDNSに戻して比較する |
| ドメイン名は解決できるが、接続がタイムアウトする | 一致したルール、宛先ポート、サーバーへの接続 | 接続ログで実際に適用されたポリシーを確認し、DNSをむやみに切り替えない |
| 設定を変更しても一時的に変化がない | アプリのキャッシュ、既存の接続、構成が有効になっているか | 接続を再確立し、対象アプリを開き直して、現在の構成を確認する |
表に示したのは問題の切り分け手順であり、この記事で測定した速度の結果ではありません。コマンドラインツールで名前解決を確認する場合は、どのリゾルバーが使われているかも確認してください。システム上で個別に実行した一度のクエリだけでは、Shadowrocket内のリクエストも同じ経路を通ったとは証明できません。また、HTTPSサイトのURLをIPアドレスに置き換えて比較しないでください。証明書や仮想ホストの違いが結果に影響します。
6. よくある質問と設定を保つためのポイント
DoHを設定したらWebページがすべて開かなくなりました。まず何を変更すればよいですか？
まずConfigで、控えておいたシステムDNSの構成に戻します。再接続し、同じページにアクセスしてください。正常に戻った場合は、DoHエンドポイントのプロトコル、ドメイン名、パス、ポートを確認します。サーバーを同時に変更しないでください。元に戻しても解決しない場合は、Homeで接続状態とGlobal Routingを確認します。
DoHアドレスをブラウザーで開ければ、設定は正しいですか？
いいえ。DoHエンドポイントは、所定の形式で送られるDNSリクエストを処理します。通常のブラウザーでアクセスするとエラーが返る場合もあれば、説明ページが表示される場合もあります。ページに内容が表示されるかだけでなく、クライアントでの実際の名前解決結果、接続ログ、サービス提供元のエンドポイント説明を合わせて確認してください。
Wi-Fiを切り替えるとDNSの動作が変わるのはなぜですか？
システムリゾルバーはネットワークに応じて変わる場合があります。また、エンドポイントへの到達性や内部ドメインの範囲も異なることがあります。まず同じ構成を使い、Wi-Fiとモバイル通信で結果を比較してください。接続のオン・オフも自動で切り替わる場合は、Settings → On Demandの起動条件を確認し、自動接続の動作をDNSの問題と取り違えないようにしてください。
サブスクリプション更新後、変更したDNS設定が元に戻ってしまった場合はどうすればよいですか？
まず、サーバーサブスクリプションの更新とリモート構成ファイルの更新を区別してください。前者は主にサーバー項目を更新し、後者は構成内容を置き換える場合があります。Configで現在有効なファイルの取得元を確認し、ローカルコピーを保管したうえで、更新後にdns-serverを確認してください。認証情報を含む構成全体を公開ページに貼り付けないでください。
安定した設定の目安は、必要なドメインを名前解決でき、接続に想定どおりのポリシーが適用され、よく使うネットワークで繰り返し確認でき、元に戻す方法も確保されていることです。システムDNSでこれらを満たせるなら、設定変更そのものを目的に変更する必要はありません。DoHが必要な場合も、効果を切り分けにくい設定を一度に複数追加せず、利用可能と確認できたエンドポイントから試してください。