ShadowrocketのDNSを調べるときは、まず現在の設定を確認してからリゾルバーを選びます。通常のネットワークではsystemを基準にし、リゾルバーを固定する場合はIPアドレスを指定します。DNS通信を暗号化したい場合は、DNS over HTTPSをテストします。利用中のサービスやサブスクリプションがあり、接続できている方向けに、差し替え可能な設定例と、名前解決の失敗・ルール選択の誤り・接続先への接続失敗を切り分ける方法を説明します。
DNSの名前解決とWebページへの接続を切り分ける
DNSはドメイン名をIPアドレスに変換します。Webページが開けるかどうかは、その後のルーティング、接続先ポートへの接続、TLSハンドシェイクにも左右されます。Homeの遅延テストに数値が表示されても、それはテスト条件下で応答があったことを示すだけです。Safariでアクセス中のドメインが必ず名前解決できることや、ページに必要なすべての接続が確立できることを意味しません。
上記はローカルで名前解決する場合の流れです。プロキシ接続のすべてで、端末が接続先のIPアドレスを事前に調べる必要があるわけではありません。ドメイン名をリモート側で処理する場合や、先にドメイン名でルールを照合する場合もあります。トラブル時は「名前解決できたか」と「解決後に接続できたか」を分けて確認し、すべての失敗をDNSの問題と決めつけないでください。
ポート番号は通信方式を見分けるための目安にすぎません。443番ポートに接続できても、特定のDNS over HTTPSエンドポイントが使えるとは限りません。53番ポートに接続できても、応答が正しいとは限りません。実際に返されたアドレスやエラーの種類、その後のアクセス結果を確認してください。
DNS設定3種類の選び方
systemは初期状態の基準として適しており、ローカルネットワークでの名前解決が必要な場合にも便利です。IPアドレスを指定するカスタムDNSは、同じ条件でのテストに向いていますが、IPを入力しただけでクエリが暗号化されるわけではありません。DNS over HTTPS（DoH）はクエリをHTTPSで送信する方式で、通信経路上でクエリ内容を直接読み取られにくくしたい場合に適しています。ただし、到達可能で信頼できるエンドポイントが必要です。
| 設定方法 | 速度と信頼性 | プライバシー上の範囲 | 優先して試す場面 |
|---|---|---|---|
system | 現在のシステムとネットワークが提供する名前解決経路によります。通常、ローカルリソースへのアクセスに便利です。 | systemという設定だけでは、クエリが暗号化されるかどうかは判断できません。 | 基準の確認、社内ネットワーク、LAN内の名前解決。 |
| カスタムDNSのIPアドレス | 指定したリゾルバーまでの通信経路によって結果が変わります。アドレスを固定すると問題を再現しやすくなります。 | 通常のDNSクエリには、HTTPSによる通信保護がありません。 | ネットワーク既定のリゾルバーに問題があるか切り分ける場合。 |
| DNS over HTTPS | 初回接続ではエンドポイントの名前解決やTLSハンドシェイクが発生することがあります。接続の再利用やキャッシュによって、2回目以降の所要時間は変わります。 | DoHエンドポイントまでの通信は保護されますが、エンドポイントの運営者はクエリを処理できます。 | クエリを暗号化したい場合で、HTTPSエンドポイントに到達できることを確認済みのとき。 |
3種類の設定に決まった速度順位はありません。距離が近くても混雑したリゾルバーは、遠方のリゾルバーより遅い場合があります。また、リゾルバーを変えるとCDNが返すアドレスが変わり、DNSクエリは速くなってもWebページの表示が遅くなることがあります。そのため、DNSクエリの所要時間だけでなく、実際のページ表示も含めてテストしてください。
Configでdns-serverを変更する：一度に試す設定は1種類
まずConfigを開き、現在有効な設定ファイルを確認します。元のファイルを複製してから、対象ファイルの編集画面を開いてください。既存の[General]セクションを見つけ、その中のdns-serverを変更します。以下の3つは互いに置き換えて試す設定例です。すべてを同時に貼り付ける完全な設定ではありません。
方法1：systemを使って基準を確認する
[General]
dns-server = systemsystemはシステムが提供するリゾルバーを使います。動作は端末と現在のネットワークによって異なります。Wi-Fi接続時にはLAN内の名前を解決できるのに、パブリックDNSに切り替えると失敗する場合、その名前がネットワーク内でのみ有効な可能性があります。この場合は、パブリックDNSアドレスを追加し続けるのではなく、ネットワーク側の名前解決条件を確認してください。
方法2：従来のDNSリゾルバーを指定する
[General]
dns-server = 1.1.1.1ここに記載したアドレスはIPアドレスの記述例であり、リゾルバーの速度や利用可能性を保証するものではありません。実際に使う前に、現在のネットワークから到達できることと、自分の要件に合っていることを確認してください。基準を記録せずにリゾルバー、ルールファイル、プロキシの選択を同時に変更すると、どの変更が影響したのか判断しにくくなります。
方法3：DNS over HTTPSを使う
[General]
dns-server = https://cloudflare-dns.com/dns-queryここではDoHエンドポイントの完全な形式を示しています。https://、ホスト名、/dns-queryパスを組み合わせたものがリクエスト先です。通常のWebサイトのトップページでは代用できません。ホスト名を使うエンドポイントでは、HTTPS接続の確立前にホスト名を名前解決する必要があります。この段階で問題が起きている場合、宛先DNSをDoHに変えるだけでは自動的に解決しません。
- 現在の
[General]にある該当設定だけを置き換え、ほかの項目は残してください。同じセクションやキーを重複して作成しないようにします。 - 保存後、変更した設定ファイルが有効になっていることを確認します。いったん接続を切ってから再接続し、アクセスをテストしてください。
- Homeに戻り、Global Routingを確認します。ファイル内の振り分けルールを検証する場合はConfigを使います。Proxy、Direct、Sceneの結果は、現在選択されているモードに応じて別途確認してください。
- リモート設定ファイルを使っている場合は、更新によってローカルの変更が上書きされないか確認してください。テスト用のコピーは、日常的に自動更新するファイルと分けて管理します。
DNS設定の範囲：DNSはアドレスを返し、Ruleは通信方針を決める
dns-serverは、特定のWebサイトをDIRECTまたはPROXYに指定する設定ではありません。ルールは[Rule]セクションに記述し、上から順に照合されます。ドメインルールはドメイン名に基づいて判定できますが、IP系ルールでは宛先アドレスが関係します。そのため、名前解決の結果が変わると後続のIPルールの照合に影響する場合がありますが、DNSを変更しても通信の振り分け方針が変わるわけではありません。
名前解決設定の確認
- 設定セクション
[General]- 項目
dns-server- システムが提供するリゾルバー
system- 暗号化エンドポイント
https://cloudflare-dns.com/dns-query
まずエンドポイントが応答することを確認し、その後で接続先を調べてください。
ルール構文の確認
- DOMAIN-SUFFIX
example.com,DIRECT- IP-CIDR
192.168.0.0/16,DIRECT,no-resolve- GEOIP
CN,DIRECT- FINAL
PROXY
ここではキーワードとパラメーターを分けて示しています。完全な設定では、両者をカンマでつなぎます。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこのルールは構文の説明用であり、あらゆるネットワークに適用できる完全な設定ではありません。no-resolveは、このIPルールとの照合のために追加のドメイン名解決を行わないという意味で、すべてのDNSを無効にする設定ではありません。FINALはルールセクションの最後に置き、それ以前のルールに一致しなかったリクエストに適用するフォールバックとして使います。
名前解決でアドレスを取得できてもWebページがタイムアウトする場合は、一致したルールと、そのルールに従う接続を確認してください。利用者がすでに持っているShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardの接続情報は別の設定レイヤーです。DNSを切り替えても、認証情報、ポート、サーバー設定の誤りは解決しません。
手順を固定して速度と信頼性を比較する
一度成功しただけでは設定の長期的な信頼性は証明できず、一度失敗しただけでリゾルバーが使えないとも判断できません。テストでは同じ端末、同じネットワーク、同じ設定ルール、同じアクセス先を使い、system、固定DNS IP、DoHの順に比較します。Wi-Fiとモバイル通信を切り替える場合は、別のテストとして記録してください。
- 基準を記録する：systemを使い、普段問題なく使えるドメインと現在アクセスできないドメインを開きます。名前解決とページ表示の可否、具体的なエラーを記録してください。
- リゾルバーだけを変更する：
dns-serverを置き換えて再接続します。Global Routingと選択中の接続は変更しないでください。 - キャッシュを切り分ける：初回アクセスと再アクセスをそれぞれ確認します。端末、ブラウザー、リゾルバーのいずれも結果をキャッシュすることがあり、ページを再読み込みしても新しいクエリが発生するとは限りません。
- 応答内容を確認する：アプリ内の該当する診断情報や記録にDNSの結果が表示される場合は、AまたはAAAAの応答があるか、タイムアウトしているか、NXDOMAINが返されているかを確認します。アドレスが異なるだけで応答が誤りだと判断しないでください。
- 実際の接続を確認する：名前解決できてもページが開けない場合は、接続先、ルールの方針、IPv4 / IPv6の経路を確認してください。DNSアドレスを次々と追加するのは避けましょう。
- 確認できた設定だけを残す：安定して改善を再現できる設定だけを使い続けます。改善しない場合は複製した元の設定に戻し、一時的なテストを常用設定にしないでください。
NXDOMAINは、リゾルバーがドメイン名の存在しないことを報告した状態で、「応答待ちのタイムアウト」とは異なります。AAAA応答がないことも、名前解決の失敗を意味しません。接続先がIPv4アドレスだけを提供している場合があります。AとAAAAの両方で応答があっても、端末が接続しているネットワークのIPv6経路に問題があると、一部のページで読み込みに時間がかかることがあります。DoHが使えないとすぐに判断せず、アドレスファミリーと接続エラーを分けて確認してください。
よくある質問：DoHのタイムアウト、LAN接続、プライバシーの範囲
DoHを設定したらWebページがすべて開けなくなりました。まず何を戻せばよいですか？
まずConfigで現在のファイルを開き、dns-serverをsystemに戻して保存し、再接続してください。アクセスが戻った場合は、DoHのURLが完全か、エンドポイントのホスト名を名前解決できるか、現在のネットワークがHTTPS接続を制限していないか、端末の時刻が正しいかを個別に確認します。ルールと接続情報を同時に変更しないでください。
一般のWebサイトは開けるのに、プリンターや社内ドメインにアクセスできません。
systemに戻し、同じWi-Fiで同じ名前に再度アクセスしてください。内部ドメインはローカルDNSだけが名前解決できる場合があり、パブリックリゾルバーでは応答できません。また、通常のDNS名とローカル検出機能を必要とする名前を区別してください。LANアクセスの問題がすべてdns-serverで制御されるわけではありません。
DoHを使っているのに、なぜルールも確認する必要がありますか？
DoHが定めるのは名前解決の通信方式だけです。Homeに戻ってGlobal Routingを確認してください。ファイルのルールを検証する場合はConfigを使い、対象のリクエストに適用されたDIRECTまたはPROXYも確認します。IPアドレスを取得できても接続がタイムアウトする場合は、リゾルバーだけでなく送信経路を調べる必要があります。
DNSアドレスを複数指定すれば、必ず安定しますか？
まず単一のリゾルバーで比較テストを行ってください。複数アドレスの使い分けや失敗時の処理は実装によって異なるため、入力順だけで優先・予備の関係を判断できません。通常のDNSとDoHを混在させても、すべてのクエリが暗号化されるとは限りません。各アドレスを単独で使えることを確認してから、アプリ内の説明に沿って調整してください。
DoHを使えば、リゾルバーにクエリを見られなくなりますか？
DoHエンドポイントはクエリを処理するため、運営者は送信された名前解決リクエストを確認できます。HTTPSが主に保護するのは、端末とエンドポイント間の通信内容です。リゾルバーを選ぶ際はサービスの説明を確認し、「通信の暗号化」「リゾルバーへの信頼」「プロキシのルーティング」をそれぞれ別の問題として扱ってください。
最終的に使う設定は、現在のネットワークからの到達性、実際のページ表示、必要なプライバシー保護の範囲を基準に選んでください。各項目の詳細は設定項目リファレンスをご覧ください。特定のネットワークでのみ問題が起きる場合は、トラブルシューティングも参考にしてください。ShadowrocketはiPhone / iPadを主な対象デバイスとしています。システム要件とデバイスの互換性は、App Storeの記載をご確認ください。