ShadowrocketのDNS設定ガイド｜システムDNS・カスタムDNS・DNS over HTTPSの選び方

DNS名前解決とプロキシ接続を区別する

DNSはドメイン名をIPアドレスに変換します。たとえばAレコードの問い合わせではIPv4アドレス、AAAAレコードではIPv6アドレスが返されます。名前解決に成功しても、接続先のポートに到達できるとは限らず、プロキシ接続が確立したことにもなりません。逆に、Homeでサーバーのテストに応答があっても、すべてのWebサイトのドメインを正しく解決できるとは限りません。

この流れは各処理の依存関係を理解するためのもので、すべてのリクエストが必ずローカルで先に名前解決されるという意味ではありません。DOMAIN-SUFFIXはドメイン名をもとに照合できます。IP-CIDRやGEOIPなどのルールでは、IPアドレスが必要な場合に名前解決が行われることがあります。プロキシに渡すドメイン名をリモート側で解決するかどうかは、プロトコルや設定、実際の接続経路によって異なります。

3種類のDNS方式：経路と選び方

「カスタムDNS」はリゾルバーを手動で指定することであり、特定の暗号化プロトコルを指すものではありません。ここでは従来のIPアドレス形式のDNSとDNS over HTTPSを分けて比較し、設定値をどこに入力するか、失敗時にどのネットワーク経路を確認するかを整理します。

内部ドメインを使うネットワークでは、システムDNSが適していることがよくあります。社内システムやプリンター、家庭内ストレージが、ルーターから配布されたリゾルバーに依存している場合があります。外部リゾルバーに置き換えると、一般のWebサイトにはアクセスできても、内部名が存在しないという応答や誤ったアドレスを返すことがあります。これはプロキシプロトコルの障害ではなく、リゾルバーが該当する内部レコードを持っていないためです。

DNS over HTTPSにすれば必ず速くなるわけではありません。初回接続ではエンドポイントの名前解決、TCP接続、TLSハンドシェイクが発生することがあり、その後の問い合わせでは接続やキャッシュが再利用されます。同じネットワーク、同じドメイン名で、名前解決エラーやアクセス結果を確認してください。ポートが443だから安定している、と判断するのは避けましょう。

SettingsとConfig：有効な設定場所を確認してから変更

iPhone / iPadでは、まずHomeでGlobal Routingを確認し、ルールをテストする場合はConfigを選択します。次にConfigで現在有効な設定ファイルを確認してください。Settings → DNSで全体のDNS設定を確認し、現在の設定ファイルにあるDNS項目も確認します。設定ファイルが独自の名前解決設定を持つこともあるため、Settingsのアドレスだけを見て最終的な動作を判断することはできません。

1. 現在の状態を記録。現在のネットワーク、Global Routing、有効なConfig、DNSの設定値、問題が起きるドメイン名を書き留めます。まず、現在の設定で問題を再現できるか確認してください。
2. 現在の設定をバックアップ。Configで元の設定ファイルを複製して保存します。設定テキストの[General]セクションにdns-serverがすでにあるか確認し、重複項目の追加を避けてください。
3. 変更する場所は1か所だけ。システムDNSを検証する場合は、該当するシステムの名前解決設定に戻します。カスタムDNSを検証する場合は、すでに利用しているリゾルバーのアドレス、またはDNS over HTTPSの完全なエンドポイントを入力してください。
4. 接続を再確立。保存後も設定が選択された状態であることを確認し、Homeの接続スイッチをいったんオフにしてから再度オンにします。対象のドメイン名に再アクセスし、ログと接続結果から設定が反映されたか判断してください。
5. 最後に自動接続を元に戻す。テスト中はSettings → On Demandを確認し、自動接続によってテスト条件が変わらないようにします。結果を確認したら、元のオンデマンド接続設定に戻してください。

以下の2つのカードは、設定項目の形式を示すものです。192.0.2.53は文書用の例示アドレス、resolver.exampleは例示ドメインで、どちらも利用可能なDNSサービスではありません。実際の値には、使用を許可されたネットワーク設定を使用してください。この記事ではDNSサービスや接続サービスを推奨しません。

ユーザーがすでに利用しているサブスクリプションやリモートファイルで設定を管理している場合、更新時にローカルの変更が上書きされることがあります。更新前に差分を保存し、更新後は選択中のConfigとDNS項目を確認してください。サーバーサブスクリプションの更新と設定ファイルの更新は別の操作です。前者でサーバー項目が更新されても、DNS設定が変更された証拠にはなりません。

DNSとGlobal Routing、ルールの順序

Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なるルーティング動作を決めます。ルールを確認するときはConfigを使ってください。ProxyとDirectは経路の比較に使えますが、切り替えた後の同じ現象から、元のルールのどれに一致したかを判断することはできません。Sceneを使う場合は、そのScene内で実際に有効な設定も確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

このルールは構文の説明用で、汎用的な振り分け設定ではありません。example.comと192.0.2.0/24はいずれも文書用の例です。現在の設定で対応するポリシーが正しく使われていることを前提に、ルールは上から順に確認されます。例を適用するために、既存の完全なルールを上書きしないでください。

• DOMAIN-SUFFIX：ドメインのサフィックスで照合します。対象のドメイン名が明確な場合に適しています。このルールに先に一致した場合、後続のGEOIPでポリシーを決める必要はありません。
• IP-CIDR：IPアドレスの範囲で照合します。例のno-resolveは、このルールの照合のために追加のドメイン解決を行わないという意味です。接続全体でDNSが一切使われなくなるわけではありません。
• GEOIP：宛先IPアドレスを地理情報データベースで分類します。名前解決で返されるアドレスが異なると、その後の分類結果も変わることがあります。データベース上の分類は、実際のネットワーク遅延を示すものではありません。
• FINAL：それ以前のルールに一致しなかった場合に最終ポリシーを選択します。失敗したDNS問い合わせを修復したり、到達できないサーバーアドレスを訂正したりするものではありません。

プロキシサーバー自体にドメイン名が使われている場合、その名前を最初に解決する経路も必要です。DNS over HTTPSのエンドポイントをプロキシ経由に設定し、そのプロキシサーバーのドメイン名が、まだ到達できないエンドポイントに依存していると、接続開始時に依存関係の循環が起きることがあります。サーバーのドメイン名とDNSエンドポイントが接続確立前に解決できるか、それぞれ確認してください。プロトコルを何度も切り替えても解決にはなりません。

ネットワークとエラー発生段階からDNSの問題を切り分ける

テスト中はサーバーとConfigを固定し、DNS方式だけを変更してください。Wi-Fiとモバイルネットワークで結果を別々に記録し、サーバー、ルール、リゾルバーを同時に変更しないようにします。Webページが開けない原因がDNSとは限りません。アドレス取得後に、接続先への接続、TLS、アプリケーション層で失敗する場合もあります。

NXDOMAINは、リゾルバーがその名前は存在しないと応答したことを示します。タイムアウトは、制限時間内に有効な応答を受け取れなかった状態です。両者を混同しないでください。特定のネットワークだけでタイムアウトする場合は、そのネットワークからリゾルバーまでの経路を確認します。一般のドメインは正常なのに内部名でNXDOMAINが続く場合は、誤ったリゾルバーが選択されていないか確認してください。

「ブラウザーにIPアドレスを直接入力する」方法だけで確認するのも避けましょう。多くのHTTPSサイトは、証明書の検証や仮想ホストの選択にドメイン名を必要とします。IPアドレスへの直接アクセスに失敗しても、ルーティング不能とは限りません。リクエストログの名前解決結果、宛先アドレス、接続段階をあわせて確認し、DNSエラーとTLSエラーを切り分けてください。

DNS設定のよくある質問と復元方法

最後に、ネットワークの種類、Global Routing、現在のConfig、DNS方式、対象ドメイン、エラーが発生した段階、復元操作を記録した簡潔なトラブル対応メモを残します。記録を共有する場合は、利用中のサブスクリプションに含まれるトークンや認証情報、内部ドメインを削除してください。当サイトではサーバーやサブスクリプションの提供・販売・推奨は行っていません。この記事では、ユーザーがすでに利用している設定の確認方法のみを説明します。

• 一般のWebサイトと内部ドメインの両方が正常：現在の設定を維持し、DNS方式を一律に変更する必要はありません。
• リゾルバーを固定したい：アドレスへの到達性、使用許可、内部ドメインの要件を確認してから変更します。
• 問い合わせを暗号化したい：DNS over HTTPSの完全なエンドポイント、TLS、最初の名前解決経路を検証します。
• 変更後に問題が発生：バックアップから復元し、接続を再確立してから、設定を1項目ずつテストします。設定を追加して重ねないでください。