この記事は、Shadowrocketで自分の接続サービスを設定済みで、ドメインの名前解決を調整したい方を対象としています。まずDNSサーバーの選び方と通信方式を整理し、使用中のConfigを確認したうえで、同じネットワーク・ドメイン・接続記録を使って結果を検証します。DNSの変更とサブスクリプションの更新は別の操作です。ウェブページが開かない原因が、必ずしもDNSとは限りません。
1. DNSの名前解決と接続の振り分けを区別する
DNSはドメイン名に対応するレコードを検索します。たとえば、ウェブサイトのドメイン名からIPv4のAレコードやIPv6のAAAAレコードを取得します。アドレスが分かった後も、クライアントは現在のルールに従って接続を確立する必要があります。名前解決に成功しただけでは、接続先ポートへの到達、TLSハンドシェイク、ウェブサーバーの正常動作までは確認できません。
ShadowrocketではDNSとGlobal Routingは関連しますが、同じ設定ではありません。Global RoutingのProxy、Direct、Config、Sceneはルーティング動作を決め、DNS設定は名前解決に使う情報源と問い合わせ方法を決めます。一方を変更しても、もう一方まで連動して変更されたとは限りません。
これは簡略化した流れであり、すべてのリクエストでデバイス上の名前解決が先に行われるわけではありません。ドメインルールが先に適用される場合や、プロキシ接続でドメイン名がリモート側に渡される場合があります。キャッシュが使われると、新たな上流DNS問い合わせが発生しないこともあります。そのため、新しいDNSリクエストが見当たらないだけで、設定が反映されていないとは判断できません。
- ドメインルール：
DOMAIN-SUFFIX,example.com,DIRECTはドメインの末尾で照合するルールであり、DNSサーバーを指定するものではありません。 - IPアドレスのルール：
IP-CIDRやGEOIPは接続先のIPアドレスを判定します。照合の過程で、先にドメイン名の解決が必要になる場合があります。 - 最終ルール：
FINALは、それまでのルールに一致しなかったリクエストを処理します。DNSサーバーを選ぶ機能ではありません。
2. システムDNS・カスタムDNS・DoHの違い
「システムDNS」と「カスタムDNS」は、主にどのDNSサーバーを使うかを示します。一方、DNS over HTTPS（DoH）は問い合わせをどのプロトコルで送るかを示します。この3つは厳密に排他的な選択肢ではありません。DoHのエンドポイントを手動で指定することも、カスタムDNSの設定にあたります。選ぶ際は「どこに問い合わせるか」と「どの方法で送信するか」を分けて考えましょう。
| 設定の種類 | DNSサーバーと通信方式 | 用途 | 確認するポイント |
|---|---|---|---|
| システムDNS | 現在のシステムネットワークが提供するDNSサーバーを使用します。通信方式はシステム側の設定によって異なります。 | 初期状態の比較基準として使う場合や、現在のネットワーク内にあるドメインへアクセスする場合。 | Wi-Fiとモバイル通信では、提供されるDNSサーバーが異なることがあります。 |
| カスタムDNS（従来方式） | DNSサーバーのアドレスを手動で指定します。通常の問い合わせにはUDP 53を使い、TCP 53を使う場合もあります。 | 利用可能なDNSサーバーが分かっている場合や、職場・家庭のネットワーク内にあるレコードを検索する場合。 | サーバーに到達できるか、現在の接続元からの問い合わせを受け付けるか、ポート53が制限されていないか。 |
| DNS over HTTPS | DoH対応エンドポイントへHTTPSリクエストを送信します。通常はポート443を使用します。 | 問い合わせを暗号化して送信したい場合。エンドポイントと接続経路が利用可能であることを確認してください。 | 完全なエンドポイントURL、証明書の検証、エンドポイントのドメイン名の初回名前解決、実際の通信経路。 |
DoHが暗号化するのは、クライアントとDNSサーバー間の問い合わせ通信です。DNSサーバーから問い合わせたドメイン名が見えなくなるわけではなく、その後のウェブ通信の出口が自動で決まるわけでもありません。システムDNSも、必ずしも暗号化されていないとは限りません。デバイスのシステムDNSに別の暗号化設定がある場合もあるため、トラブルシューティングでは条件のひとつとして記録してください。
選ぶときのポイント：まず到達性を確認し、次に通信方式を比較する
現在のシステムDNSで安定して名前解決でき、内部ドメインにもアクセスできるなら、まずは比較基準としてそのまま使います。DNSの不具合や暗号化通信の必要性を確認してから、カスタムDNSまたはDoHを個別にテストしてください。DNSサーバーとルーティング設定を同時に変更しないことが重要です。
3. 変更前に使用中のConfigを確認する
Homeで現在の接続状態とGlobal Routingを確認し、Configで使用中の設定ファイルを確認します。別のファイルを編集して保存しても、現在の接続にそのDNS設定が適用されたことにはなりません。画面上の項目や編集方法は、アプリに表示される内容に従ってください。設定ファイルを確認する場合は、[General]とdns-serverを検索します。
- 現在の状態を記録：ネットワークがWi-Fiかモバイル通信か、Global Routingの選択内容、使用中の設定ファイル名、実際に問題が起きているドメインを記録します。
- 設定のコピーを保存：DNSを変更する前に、Configで元に戻せる設定のコピーを保存します。1回のテストでルール、接続プロトコル、DNSを同時に変更しないでください。
- 既存の設定を確認：設定ファイルでDNSサーバーが指定されているか、またSettingsに現在の名前解決へ影響する設定がないかを確認します。入力欄の内容だけを見て、最終的に適用される値を判断しないでください。
- 変更は1項目ずつ：システムDNSから、利用可能であることを確認したDNSサーバーに切り替えます。DoHをテストする場合は、DNSサーバーの管理者が案内する完全なHTTPSエンドポイントを使ってください。
- 保存して再接続：Homeに戻って接続を確立し直し、同じドメインを再テストします。現在のネットワークでWi-Fiの認証ページを通過する必要がある場合は、先に認証を済ませてください。
次の2つのカードは、別々に行うテストの説明です。両方の設定を同時に入力する必要はありません。システムDNSを使う設定は、Config内でdns-server = systemと記述できます。カスタムDNS（従来方式）では、実際に到達可能なDNSサーバーのアドレスが必要です。DoHは別の通信方式です。通常のIPアドレスにhttps://を付けるだけで、そのサーバーがDoHに対応するわけではありません。
テストA：システムDNSの基準値
- 確認する場所
- Configで使用中の設定ファイル内にある[General]
- 設定名
- dns-server
- 設定値
- system
- 固定する条件
- 同じネットワーク、同じGlobal Routing、同じ対象ドメイン
ほかのDNS関連設定がある場合は、その内容を先に記録します。1行追加しただけで、既存設定の優先関係がすべて解消されたと判断しないでください。
テストB：カスタムDNS（従来方式）
- 確認する場所
- Configで使用中の設定ファイル内にある[General]
- 設定名
- dns-server
- アドレスの条件
- 利用可能であることを確認したDNSサーバーのIPアドレスを入力
- ポートの確認
- 通常のDNSではUDP 53またはTCP 53への到達性が必要
たとえば192.168.1.1は、現在のネットワークで実際にDNSサーバーとして使われている場合に限り適切です。どのネットワークでも使える汎用アドレスではありません。
4. DNS over HTTPSで確認する4つの条件
DoHのエンドポイントは、一般的なウェブサイトのトップページとは異なります。所定のDNSメッセージ形式に対応している必要があります。HTTPSサイトをブラウザーで開けても、そのドメインがDoHサービスを提供している証明にはなりません。入力時は管理者から案内された完全なパスや必要なパラメーターを保持し、ホスト名、パス、プロトコルヘッダーを独自に変更・削除しないでください。
- エンドポイントの形式：
https://example.com/dns-queryは形式の例であり、そのまま使えるDNSサービスではありません。実際のパスが/dns-queryとは限りません。 - 証明書と時刻：HTTPS接続には証明書の検証が必要です。デバイスの時刻が正しくない、エンドポイントの証明書に問題がある、ネットワークの認証ページに通信を遮られる、といった原因で接続に失敗することがあります。
- 初回の名前解決：エンドポイントがドメイン名の場合、接続を確立するには最初にそのドメインのIPアドレスを取得する必要があります。初回の名前解決に使う経路へ到達できなければ、DoH接続も確立できません。
- 通信経路：DoHが特定のプロキシ出口を必ず使うとは限りません。使用中のConfig、ルール、接続記録を確認し、実際の経路と到達性を調べてください。
DoHの不具合を解消するために、証明書の検証を無効にしないでください。まず動作が確認できているDNSに戻し、デバイスの時刻が正しいことを確認します。そのうえで、エンドポイントに到達できるか、設定が元のアドレスを参照しているかを調べてください。特定のWi-Fiだけで失敗し、モバイル通信では正常な場合は、Wi-Fiの認証状態やネットワーク制限を優先して確認します。
5. DNS変更後に適用を確認する方法
確認ではウェブページが開くかどうかだけでなく、「名前解決の結果」と「実際の接続」の両方を見ます。サイトのキャッシュが使われたり、ブラウザーが既存の接続を再利用したりすることがあります。ネットワークとGlobal Routingを固定し、変更前後の記録を保存してから、新しいリクエストを使って比較してください。テスト中にWi-Fiとモバイル通信を切り替えないでください。
- 変更前の状態を記録：問題のドメイン、テスト時刻、使用中の設定、エラーの種類（名前解決の失敗、接続タイムアウト、TLSエラーなど）を記録します。
- 設定を保存して再接続：Homeで接続をいったん切り、再接続します。テストするページの古いタブを閉じ、新しいアクセスを試してください。再接続で新しい設定が適用されやすくなりますが、システムやアプリのキャッシュがすべて消えるとは限りません。
- 名前解決の記録を確認：利用可能なDNS問い合わせ記録や診断記録で、ドメイン名、A/AAAAレコードの応答、エラー状態を確認します。上流DNSサーバーの情報が表示される場合は、想定どおりかも確認してください。
- 接続の記録を確認：リクエストに適用されたルール、接続先アドレス、実際の出口を確認します。名前解決で得られたアドレスが変わっても、それだけでは出口が変わったとは言えません。
- 繰り返しテストして元の設定とも比較：同じ条件で数回テストした後、元の設定に戻して再確認します。安定して再現する違いを記録し、1回の読み込み速度だけで結論を出さないでください。
| 確認できた現象 | 分かること | 次に確認すること |
|---|---|---|
| NXDOMAINが返る | DNSサーバーが、そのドメイン名は存在しないと応答しています。問い合わせのタイムアウトとは異なります。 | ドメイン名の入力、完全なドメイン名、内部ネットワーク内だけで使われる名前かどうかを確認します。 |
| 問い合わせがタイムアウトし、応答がない | 現在の問い合わせ経路では、待ち時間内に処理が完了していません。 | DNSサーバーのアドレス、ネットワークへの到達性、エンドポイントへの接続を確認します。ウェブサイトの振り分けルールは、まず変更しないでください。 |
| A/AAAAレコードは取得できるが、ウェブページがタイムアウトする | 名前解決は完了しています。問題はその後の接続段階にある可能性があります。 | 接続先への通信、IPv6経路、適用ルール、リモート側への到達性を確認します。 |
| DNS変更後に異なるIPアドレスが返る | DNSサーバー、キャッシュ、コンテンツ配信の振り分けによって違いが生じた可能性があります。 | 実際のアクセスが安定しているかを続けて確認します。IPアドレスが違うだけで、正誤を判断しないでください。 |
切り分けの順序：DNS応答があるのに接続できない場合は、まず接続段階を確認
問題のドメインでAレコードまたはAAAAレコードを取得できている場合は、DNS設定を維持し、適用ルールと接続先への通信を確認します。DNS問い合わせがタイムアウトする、異常な応答が返る、内部ドメインを解決できない場合に限り、DNSサーバーを比較してください。関係のない設定を繰り返し変更しないことが大切です。
6. よくある質問：DNS・ルーティング・自動接続の違い
DNSを変更しても、確認ページに以前と同じネットワーク情報が表示されるのはなぜですか？
ページに表示されているのが、インターネット上の出口IPアドレスなのか、ページが観測した再帰DNSサーバーのアドレスなのかを確認してください。DNS設定でインターネット上の出口が直接変わるわけではなく、DNSサーバーが複数の出口アドレスを使うこともあります。Homeに戻ってGlobal Routingを確認し、新しいリクエストのDNS記録と接続記録を合わせて判断します。ページ上の単一の表示だけを根拠にしないでください。
一般のウェブサイトは開けるのに、家庭内のデバイス名にアクセスできません。どうすればよいですか？
まずシステムDNSに戻して比較し、家庭用ルーターがそのデバイス名のレコードを提供しているかを確認します。一般向けのDNSサーバーは、プライベートネットワーク内の名前を知らないことが多くあります。末尾が.localの名前は、通常の上流DNSではなくmDNSを使う場合もあります。内部名の問題を解決するために、安易に一般向けDNSサーバーへ切り替えないでください。
DoHを有効にした後、すべてのドメインがタイムアウトします。まず何を変更すればよいですか？
まず変更前のDNS設定に戻して再接続し、基本的なアクセスが回復することを確認します。その後、DoHの完全なエンドポイント、デバイスの時刻、エンドポイントの初回名前解決を個別に確認してください。接続サーバーを変更したり、すべてのルールを削除したりすると、エンドポイントへの到達不能とルーティング変更を区別できなくなります。
切断しても自動的に再接続されるため、DNSの比較テストに影響します。どうすればよいですか？
Settings → On Demandを確認し、テスト中は関連する自動接続条件を記録するか、一時的に無効にします。Homeに戻って実際の接続状態を確認してからテストし、終了後に元の設定へ戻してください。On Demandは条件に応じて接続する機能であり、DNSサーバーを選ぶ画面ではありません。
ウェブページが開くようになれば、すべての問い合わせでDoHが使われていると確認できますか？
いいえ。キャッシュ、アプリ独自の名前解決方法、リモート側での名前解決などが結果に影響します。新しいリクエストの診断記録を確認してください。問い合わせの通信方式まで厳密に確認するには、管理されたネットワークやDNSサーバー側のログも必要です。そうした証拠がなければ、現在アクセスできるようになったことは確認できますが、すべての問い合わせ経路について結論を出すことはできません。
動作が確認できているConfigを保存し、変更は毎回1項目に絞ることが、その後のトラブルシューティングの基本です。ルールや接続の許可設定をさらに確認する場合はトラブルシューティングガイドをご覧ください。初期設定や自分のサブスクリプションの追加は、設定ガイドに沿って進められます。