この記事は、Shadowrocketの接続設定が済んでおり、ドメインの名前解決方法を調整したい方を対象にしています。まずDNSサーバー、DNSの通信方式、リクエストの出力先ポリシーを区別し、Configの最小限の設定で一つずつ確認します。システムDNSは比較の基準として、カスタムDNSは使用するリゾルバーを指定したい場合に、DNS over HTTPSはクライアントとリゾルバー間の問い合わせを暗号化したい場合に適しています。いずれも、利用中のネットワーク、ルール、実際の名前解決結果を踏まえて判断してください。
1. DNSの名前解決と接続の出力先を区別する
ShadowrocketのDNS設定は「ドメイン名に対応するアドレス」を解決し、Global Routingとルールは「接続をどこへ出力するか」を決めます。Webページが開かない原因は、このどちらかにある場合も、接続先サービス自体にある場合もあります。DNSを変更しても、サービスのポートに到達できない、接続認証に失敗する、Webサイト側でアクセスが拒否されるといった問題は解決できません。
以下は、ローカルで名前解決する場合の簡略図です。実際には、ドメインルールがアドレスルールより先に適用されることがあります。また、プロキシ接続によってはドメイン名の処理をリモート側に委ねるため、すべての接続が同じローカルDNS経路をたどるとは限りません。
アプリ独自の名前解決方式にも注意が必要です。ブラウザーなどのアプリが独自の暗号化DNSを使う場合があり、既存の接続やキャッシュが古いアドレスを再利用することもあります。Configにリゾルバーを設定しても、端末上のすべてのアプリの問い合わせが必ずそこを経由するとは限りません。切り分ける際は、同じアプリ、同じドメイン名、同じネットワークを使い、条件の異なるリクエストを混同しないようにしてください。
2. システムDNS・カスタムDNS・DoHの違い
システムDNSは通常、現在のネットワークで設定されているDNSを使用します。Wi-Fiとモバイル通信を切り替えると、実際に使われるリゾルバーが変わる場合があります。カスタムDNSでは、設定でリゾルバーのアドレスを明示します。「カスタム」は選択方法を表すもので、通信が暗号化されていることを意味するわけではありません。DNS over HTTPS（DoH）は、DNSの問い合わせをHTTPSで送信する方式です。DoHも、リゾルバーを指定して利用できます。
| 設定方式 | リゾルバーの指定元 | 通信上の特徴 | 優先して確認したい状況 |
|---|---|---|---|
| システムDNS | 現在のシステムおよびネットワーク設定 | 名称だけでは暗号化の有無を判断できない | ネットワークのログインページ、自宅のネットワーク、内部ドメイン |
| カスタムDNS（通常のDNS） | Configで指定したIPアドレス | 通常はUDP 53を使用。TCP 53を使う場合もある | リゾルバーを固定して応答を比較したい場合 |
| DNS over HTTPS | Configで指定したHTTPSエンドポイント | 一般的なポートは443。TLS接続が必要 | DNS問い合わせを暗号化したい場合（エンドポイントに到達できることが前提） |
まず基準を確認し、その後DoHへの切り替えを検討
まずシステムDNSで対象ドメインを解決できるか記録し、DNS方式を一つだけ切り替えて再確認します。通常のDNSは使えるのにDoHがタイムアウトする場合は、ルールや接続設定を同時に変更せず、DoHエンドポイントへのHTTPS接続を先に確認してください。
DoHが暗号化するのは、選択したリゾルバーまでの問い合わせ通信です。リゾルバーは問い合わせ内容を処理します。また、応答アドレスが速いことや、内部ドメインを解決できることを保証するものではありません。リゾルバーから返されるアドレス、接続先サービスの地域別振り分け、ネットワーク経路などが、実際のアクセスに影響します。
3. ConfigでDNSを設定する：バックアップ後に一項目ずつ変更
操作前に、利用するサービスとサブスクリプションを自分で用意し、基本的な接続確認を済ませてください。Subscribeによるインポートや更新は、すでに用意した接続情報を扱う機能であり、DNS設定の完了を意味するものではありません。この記事では現在のConfigの名前解決設定のみを変更し、接続先の選び方は扱いません。
- Configを開き、現在実際に使用している設定ファイルを確認して、コピーを保存します。有効になっていないファイルだけを編集しないでください。
- 該当する設定の編集画面を開き、
[General]セクションとdns-server項目を探します。編集画面のラベルやアイコンは、アプリの表示に応じて異なる場合があります。 - すでに
dns-serverがある場合は、既存の項目を編集してください。ファイル末尾に同じ設定を重複して追加しないでください。 - 保存後もそのConfigが選択されていることを確認します。Homeに戻り、接続を中断できる状態で再接続してから、同じドメイン名をテストしてください。
- 変更前後の名前解決結果とエラーメッセージを記録します。改善しない場合は、次のテストに進む前に保存したコピーへ戻してください。
以下は互いに置き換えて使う最小限の設定例です。一度に一つだけ選び、現在の設定内の該当項目と置き換えてください。完全な設定ファイルではないため、既存のルールや接続情報を上書きしないでください。例のパブリックリゾルバーは構文の説明用です。利用するかどうかは、到達可能性とサービスのポリシーを踏まえて判断してください。
設定例 A：システムDNSを使用
[General]
dns-server = systemsystemはシステムDNSを使用する指定です。比較の基準を作る場合や、ローカルリゾルバーが必要な環境に適しています。未接続時には内部ドメインを解決できるのに、パブリックDNSへ変更すると使えない場合は、まずそのドメインを認識しているリゾルバーがローカルネットワーク内に限られていないか確認してください。
設定例 B：通常のDNSを明示的に指定
[General]
dns-server = 1.1.1.1ここでは変数を切り分けるため、リゾルバーを一つだけ指定します。通常のDNSアドレスにhttps://を付ける必要はありません。また、WebページのURLを通常のDNSサーバー欄に入力しないでください。現在のネットワークで外部DNSが制限されていると、IPアドレスを指定してもタイムアウトする場合があります。その場合はアドレスを次々に追加せず、まずシステムDNSに戻して確認してください。
設定例 C：DNS over HTTPSを指定
[General]
dns-server = https://1.1.1.1/dns-queryDoHには完全なエンドポイントが必要です。プロトコル、ホスト、パスのすべてが重要で、リゾルバーのトップページを指定してもDoHアドレスにはなりません。この例では、記載のIPアドレスに対応する証明書を持つエンドポイントを使用しています。他のドメイン名のエンドポイントを安易にIPアドレスへ置き換えると、証明書の検証に失敗する可能性があります。
4. DNSとGlobal Routing・ルールの連携
HomeでGlobal Routingを確認します。Configは現在の設定にあるルールに従って接続を処理します。ProxyとDirectは、それぞれプロキシ経由と直接接続のモードです。Sceneでは、設定済みのシーンに応じて動作が選択されます。ルールの問題を調べる際は、まずモードを固定してください。ProxyまたはDirectのままConfigの振り分けルールでアクセス結果を説明しようとすると、誤った結論に至ることがあります。
DNS設定の確認
- 場所
- Config → 使用中の設定 → 編集
- 設定セクション
[General]- 設定項目
dns-server- 確認条件
- 保存し、設定を選択してから再接続
無効な設定を変更しても、現在のセッションの名前解決設定には反映されません。
ルールキーワードの確認
- DOMAIN-SUFFIX
- ドメインの末尾で照合
- IP-CIDR
- IPv4アドレス範囲で照合
- GEOIP
- IP地理データベースで照合
- FINAL
- それ以前のルールに一致しない場合に使われる最終ルール
ルールは上から順に判定されます。アドレスを使うルールでは、名前解決結果が関係する場合があります。
以下はルールの構文例のみで、完全な設定の代わりにはなりません。192.0.2.0/24はドキュメント用の例示ネットワークであり、接続先サービスのアドレスではありません。DOMAIN-SUFFIXはドメイン名で照合します。アドレスを使うルールでは、既知の宛先IPと組み合わせてください。no-resolveを付けると、そのアドレスルールのために名前解決を明示的に行いません。接続全体でDNSを使わなくなるという意味ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDNSからアドレスが返っても、その後の接続が意図どおりに出力されるとは限りません。名前解決結果とルールの適用記録を別々に確認してください。ドメイン名が先行するルールに一致している場合、後続のGEOIPやFINALを変更しても、その接続の判定は変わりません。また、Global Routingの名称だけからDNS問い合わせの出力経路を推測しないでください。実際の経路は、DNS関連の設定と記録によって異なります。
5. 名前解決に問題がある場合の確認手順
Connectivity Testで確認できるのは、選択した接続のテスト結果です。特定のWebサイトについて、DNS、TLS、実際のサービスへのアクセスまで完全に検証する機能ではありません。テストが正常でもWebページが開かない場合は、「アドレスを取得できない」問題と「アドレス取得後に接続できない」問題を分けて調べてください。以下の手順では根拠のない速度データを使わず、再現可能な現象を一つずつ記録します。
- ネットワークとテスト対象を固定する。Wi-Fiかモバイル通信か、対象ドメイン、現在のConfig、Global Routingを記録します。まず実際に失敗するドメインを選び、正常に使えることが確認済みのドメインも比較対象として用意してください。
- 設定が反映されているか確認する。保存して再接続した後、変更したファイルが引き続き使用されているか確認します。設定がリモート更新で上書きされる場合は、コピーでテストし、更新後にもう一度確認してください。
- エラーが発生した段階を区別する。アドレスが返らない、問い合わせがタイムアウトする、ドメインが存在しないという状態と、アドレス取得後の接続タイムアウトは別の問題です。利用できる接続記録や対象アプリのエラーメッセージを確認し、「Webページが開かない」という理由だけでDNS障害と判断しないでください。
- 比較のためシステムDNSに戻す。戻した直後に使えるようになり、指定したリゾルバーでは繰り返し失敗する場合は、現在のネットワークからそのリゾルバーに到達できるか、内部ドメインの名前解決が必要かを優先して確認してください。
- DoHの条件を個別に確認する。エンドポイントのスペル、HTTPSのパス、端末の時刻、証明書エラーを確認します。通常のHTTPSサイトが開けても、一部のHTTPS接続が使えることを示すだけで、特定のDoHエンドポイントへの到達を保証するものではありません。
- AとAAAAを確認する。アドレスが返っているのにアクセスできない場合は、どちらか一方のアドレスファミリーだけに問題がないか確認してください。IPv6経路の問題を単純にリゾルバーのエラーと決めつけたり、IPv6関連の設定をまとめて削除したりしないでください。
- 最後にキャッシュと自動接続を確認する。接続を確立し直し、対象アプリも開き直してください。テスト中に自動再接続で接続状態が変わらないよう、Settings → On Demandも確認します。キャッシュの消去を、前の確認手順に代わる定型の解決策と考えないでください。
アドレス取得後は、接続とルールを確認
同じ対象からAまたはAAAAレコードが安定して返るのに、接続段階でタイムアウトする場合は、ルールの適用結果、選択中の接続、接続先サービスのポートを確認してください。この段階でリゾルバーを次々に切り替えても、根本原因の特定にはつながらないことがほとんどです。
6. よくある質問：設定後も問題が続く場合
DoHに変更した後、最初のWebページの表示が遅くなるのはなぜですか？
DoHでは、エンドポイントの名前解決、TLS接続、問い合わせの各処理が必要になる場合があります。同じネットワークで同じドメインを続けてテストし、初回接続と再利用時を分けて確認してください。毎回長く待たされる場合は、システムDNSに戻して比較し、エンドポイントへの到達性を確認します。一度の表示速度だけで判断しないでください。
一般のWebサイトは開くのに、自宅の内部ドメインが開かない場合はどうすればよいですか？
まずdns-serverをsystemに戻し、元の自宅のWi-Fiで再確認してください。戻すと使える場合は、内部ドメインの名前解決にローカルリゾルバーが必要な可能性があります。パブリックドメインと内部ドメインの両方を解決する必要がある場合は、現在のネットワーク設計に合わせてドメインごとのリゾルバー設定を行ってください。パブリックリゾルバーがプライベートネットワーク内の名前を認識するとは限りません。
DNSを複数設定すると、記載順に厳密な優先・予備として使われますか？
アドレスの記載順だけで、厳密な優先・予備の動作を判断しないでください。問い合わせ先の選択や切り替え方法は、実装と設定によって異なります。切り分ける際は、到達できることが確認済みのリゾルバーを一つだけ残し、保存して再接続します。一つずつの確認が終わった後、現在の設定で対応している方式に沿って他のリゾルバーを追加してください。
Subscribeの更新に成功したのに、DNS設定が変わらないのはなぜですか？
接続情報のSubscribe更新と、現在のConfigにあるDNS項目は別々に確認する必要があります。Configに戻り、選択中のファイルを確認してから、[General]内のdns-serverを確認してください。リモート設定ファイルを更新した場合は、リモート側の内容がローカルの変更を上書きしていないかも確認します。
再現できる確認記録として、使用ネットワーク、Config名、Global Routingのモード、DNS設定値、対象ドメイン、エラーが起きた段階を残してください。記録を共有する前に、サブスクリプションのURL、認証情報、プライベートなドメイン名を削除します。複数の項目を一度に変更するより、一つずつテストし、正常に動作する状態へ戻せるようにすると、問題の発生箇所を判断しやすくなります。