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

1. DNS名前解決と接続の振り分けを区別する

DNSはドメイン名をIPアドレスに変換します。たとえば www.example.com にアクセスすると、リゾルバーからIPv4のAレコードまたはIPv6のAAAAレコードが返される場合があります。アドレスを取得した後、クライアントは現在のルーティングモードとルールに基づいて接続方法を決定します。そのため、「名前解決に成功したこと」と「Webページを開けること」は別々に確認する必要があります。

この流れは、一般的なドメイン名解決の確認順序を示すもので、すべてのリクエストでDNS問い合わせが行われるわけではありません。アプリやクライアントのキャッシュ、ドメイン名をリモート側で処理する接続方式によって、実際の問い合わせ場所は変わることがあります。また、DNSで名前解決する前にドメインルールがマッチする場合もあります。DNSがすべてのルールより先に必ず実行されるわけではありません。

HomeでGlobal Routingを確認するときは、モードとDNS設定を分けて考えます。Configは現在の設定ファイルのルールを使用し、ProxyとDirectは接続全体の方針を切り替え、Sceneはシーンごとの設定に従って動作します。モードを切り替えても、誤ったリゾルバーアドレスは修正されません。また、DoHを設定しても、すべての通信がプロキシ経由になるわけではありません。

• DOMAIN-SUFFIX,example.com,DIRECT：ドメインのサフィックスでマッチします。特定の固定IPは判定に使用しません。
• IP-CIDR,192.168.0.0/16,DIRECT：宛先アドレスのネットワーク範囲でマッチします。名前解決が必要かどうかは、リクエストの形式やルールのパラメーターによって異なります。
• GEOIP,CN,DIRECT：宛先IPの位置情報データベース上の所属地域でマッチします。ドメイン名だけでは判定できません。
• FINAL,PROXY：それ以前のルールにマッチしなかった場合に適用される最終ポリシーです。DNSサーバーの設定ではありません。

2. 3種類のDNS方式を選ぶ

「システムDNS」と「カスタムDNS」は主に使用するリゾルバーを指定し、「DNS over HTTPS」は問い合わせの転送方式も定めます。この3つは完全に同じ分類軸ではありません。DoHエンドポイントを手動で指定することも、カスタムDNS設定の一種です。まず名前解決の対象とネットワークからの到達性を確認し、そのうえで転送の暗号化を検討してください。

DoHが暗号化するのは、クライアントからDoHリゾルバーまでの問い合わせの転送です。リゾルバーは引き続きドメイン名の問い合わせを処理します。Webサイト自体のHTTPS動作を変更するものではなく、アクセス速度が向上する保証もありません。TLS接続の確立によって初回の問い合わせに時間がかかることがあります。一方、接続の再利用やキャッシュは後続の結果に影響するため、ページの読み込みを一度試しただけでは比較できません。

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

変更前にConfigで現在使用中の設定を確認し、複製を保存してから、その設定のテキスト編集画面を開きます。変更するのは [General] セクション内の dns-server フィールドです。Homeにある接続項目のAddressではありません。編集方法は現在の画面に表示されるメニューに従い、サーバーアドレスとDNSアドレスを取り違えないようにしてください。

1. Configで現在選択されている設定名を確認し、元の dns-server の値を記録します。フィールドがなかった場合は、そのことも記録してください。
2. 設定のテキストを開き、既存の [General] セクションを探します。同じセクションがすでにある場合は、その中を編集し、セクション全体を重複して追加しないでください。
3. 今回のテストに必要な dns-server 設定だけを1つ残し、保存してからその設定を選び直します。
4. Homeに戻り、Global RoutingをConfigに設定してルールをテストします。短時間の通信切断が問題ない場合は、一度切断して再接続し、変更後の設定を読み込み直してください。
5. 同じテスト用ドメインに再度アクセスし、名前解決と接続の状況を記録します。失敗した場合は、リゾルバーを次々に追加するのではなく、まず元の値に戻してください。

システムDNS：最初の基準設定にする

[General]
dns-server = system

system はシステムのDNS情報を使用する指定です。ルーターが必ず直接回答することを保証するものではなく、他のアプリもまったく同じ経路で名前解決するとは限りません。ネットワークを切り替えた後は、特にネットワークログインが必要なWi-Fiで、再度動作を確認してください。

カスタムDNS（従来方式）：到達性を確認したアドレスを使う

[General]
dns-server = 192.168.1.1

192.168.1.1 はLAN用の例示アドレスです。その機器が実際にDNSサービスを提供し、現在のネットワークから到達できる場合にのみ使用できます。ゲートウェイアドレスがDNSアドレスとは限りません。また、自宅のネットワークで使うプライベートアドレスをモバイル通信でもそのまま使うことはできません。実際に入力する値は、利用中のネットワークまたはDNSサービスの設定情報で確認してください。

DoH：Webサイトのトップページではなく、完全なエンドポイントを入力する

[General]
dns-server = https://dns.example.com/dns-query

上記の dns.example.com は形式を示すための例であり、そのまま接続には使用できません。利用可能であることを確認したDoHの完全なエンドポイントに置き換えてください。パスは必ずしも /dns-query とは限らないため、DNSサービスの説明を確認します。通常のHTTPSページを開けても、そのサイトがDNS問い合わせを処理できるとは限りません。

4. エンドポイント、ネットワーク、通信経路を確認する

DoHエンドポイントは通常ドメイン名で指定され、HTTPS接続の確立前にエンドポイント自身のアドレスを解決する必要がある場合があります。最初の名前解決ができなければ、問い合わせはDoHサービスに届く前に失敗します。ドメイン名形式のエンドポイントをリストに追加するだけでは解決しません。初回の名前解決、ルーティング、現在のネットワークからの到達性も確認してください。

DoHの失敗を証明書検証の無効化で解決しないでください。完全なアドレス、デバイスの日付と時刻、ネットワークへのログインが必要かどうかを確認します。「Shadowrocketを有効にしたときだけ失敗する」場合は、Configのルールとエンドポイントの通信経路も確認し、エンドポイントが到達できない経路に送られていないかを調べてください。

• LAN内の名前解決に内部リゾルバーが必要な場合、外部リゾルバーに切り替えると、該当するレコードがないという応答が返ることがあります。
• AAAAレコードが返っても、現在のIPv6接続経路が利用できるとは限りません。名前解決の結果と接続できるかどうかは別々に確認してください。
• アプリが独自のDoHや長期間有効なキャッシュを使っている場合、クライアントのDNSを変更しても、新しい問い合わせが確認できないことがあります。
• リクエストによってはドメイン名をリモート側で処理します。ローカルログに問い合わせの記録がないだけで、設定が無効だと判断しないでください。

5. 決まった手順でDNSの動作を確認する

確認中は、同じネットワーク、同じルール、同じ接続項目を使います。まずシステムDNSの結果を記録し、その後カスタムリゾルバーを1つずつ試してください。各テストでは同じドメイン名を使用します。既存のサブスクリプションの更新、ネットワークの切り替え、DNSの変更を同時に行わないでください。アクセスが回復しても、どの変更が有効だったのか特定できなくなります。

1. 基準を記録する：ネットワークの種類、有効な設定、Global Routingのモード、テスト用ドメイン名、変更前の状態（名前解決のタイムアウトか接続のタイムアウトか）を記録します。
2. 設定を再読み込みする：保存後に設定を選び直して再接続します。アプリが古い接続を再利用している場合は、アプリを完全に終了してから開き直し、テストしてください。
3. 名前解決の段階を確認する：利用可能な診断情報やログで、同じドメイン名の問い合わせ、応答、タイムアウトを確認します。キャッシュがある場合、新しい問い合わせが記録されるとは限りません。記録がないだけで失敗と判断しないでください。
4. 接続の段階を確認する：宛先IPが取得できているのに、その後の接続確立でタイムアウトする場合は、マッチしたポリシー、宛先ポート、使用中の接続項目が利用可能かを確認します。
5. 条件をそろえて比較する：同じ条件で数回アクセスし、初回の問い合わせとキャッシュヒットを区別します。一度だけ偶然成功した結果を、長期的に安定する根拠にしないでください。

6. DNS設定に関するよくある質問