Shadowrocketで接続を設定済みで、DNSを確認したい方を対象にしています。まず名前解決サーバー、問い合わせの転送方式、通信ルールを区別し、Configでdns-serverを確認します。そのうえで、タイムアウト、返されたIPアドレスの異常、ネットワーク切り替え時の問題を一つずつ切り分けます。利用者がすでに契約しているサービスを前提としており、利用可能な接続先や公開DNSサービスの一覧は掲載していません。
1. DNSの名前解決と通信の出口を区別する
ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリです。主にiPhone / iPadで利用でき、購入・インストールはApp Storeのみです。買い切り型で、アプリの購入と接続サービスの契約は別です。本サイトでは接続先、サブスクリプション、サービス提供事業者を提供・販売・推奨していません。価格、システム要件、購入条件はApp Storeの記載をご確認ください。DNS設定はアプリの設定項目の一つであり、利用中の接続サービスに代わるものではありません。
DNSの役割は、ドメイン名をIPアドレスなどの情報に変換することであり、Webサイトへの接続を確立することではありません。ブラウザがドメインにアクセスするとき、キャッシュを使う場合も、新たに問い合わせる場合もあります。IPアドレスを取得した後も、ルーティング、通信接続、TLSハンドシェイクが必要です。そのため、名前解決できてもサイトに接続できるとは限らず、接続失敗の原因がDNSとは限りません。
この流れは処理の依存関係を理解するためのもので、すべてのリクエストが端末上で常に同じ順序をたどるわけではありません。キャッシュが使われれば問い合わせは省略されます。プロキシの処理方式によっては、ドメイン名がリモート側で名前解決されます。また、アプリが独自の暗号化DNSを使う場合、設定で指定したサーバーを使うとは限りません。トラブルシューティングでは、まずどの種類のリクエストを確認しているかを特定してください。
2. システムDNS、カスタムDNS、DoHの違い
「システムDNS」と「カスタムDNS」は主にサーバーの指定元を表し、「DNS over HTTPS」は問い合わせの転送方式を表します。完全に並列の選択肢ではなく、DoHのアドレスを手動で指定する場合もカスタムDNSに含まれます。システムの名前解決経路も、端末のDNS構成プロファイルなどの影響を受けることがあるため、必ず平文で通信すると決めつけることはできません。
| 設定方式 | サーバーの指定元・通信方式 | 利用条件 | まず確認する項目 |
|---|---|---|---|
| システムDNS | 現在のシステムの名前解決設定を使用 | 現在のネットワークで名前解決でき、基準となる状態を確認したい | Wi-Fiとモバイル通信で結果が異なるか |
| カスタムDNS（従来方式） | サーバーを手動指定。通常はUDP / TCP 53を使用 | サーバーアドレスとアクセス権限が確認済み | サーバーへの到達性、ポート、ローカルネットワーク内のアクセス範囲 |
| DNS over HTTPS | HTTPSで名前解決エンドポイントにリクエスト | 信頼でき、到達可能な完全なDoHアドレスがある | ドメイン名、パス、TLS証明書、初回の名前解決 |
ポート番号だけではサービスの利用可否は判断できません。あるアドレスで443番ポートに接続できても、DoHを提供しているとは限りません。従来方式のDNSも、大きな応答や特定の条件ではTCPを使うことがあるため、UDPだけを確認しても不十分です。DoHが暗号化するのはクライアントと名前解決サービス間の問い合わせ通信です。名前解決サービスは問い合わせ内容を処理でき、Webサイトへの接続が同じ経路を使うとも限りません。
要点：利用できる基準を保ち、DNS方式は一つずつ変更する
現在のネットワークで問題がなければ、まずシステムDNSの状態を記録します。名前解決サービスの指定や暗号化通信が必要な場合に限り、DNSだけを変更してください。ルール、接続、DNS設定を同時に変えないようにします。
3. Configでdns-serverを確認・変更する
まずHomeでGlobal Routingの現在の選択肢を確認し、次にConfigで使用中の設定ファイルを確認します。似た名前でも、選択されていないファイルだけを変更しないでください。ここでは設定テキストの[General]とdns-serverを使って場所を説明します。画面レイアウトによるボタンの配置には依存しません。
- Configで現在の設定ファイルを選び、元に戻せるようにファイルのコピーを保存するか、変更前のDNS行を控えてください。
- 設定ファイルの編集メニューを開き、設定テキストを編集できる画面に進んで
[General]セクションを探します。メニューの表示は現在のアプリ画面に従ってください。 - 既存の
dns-serverを探し、元の行を編集します。ファイル末尾や別のセクションに同じ設定を追加しないでください。 - 保存後、対象の設定ファイルが引き続き選択されていることを確認します。再読み込みが必要な場合は、Homeで接続をいったんオフにしてからオンにします。この操作中は接続が一時的に切断されます。
- 同じネットワークと同じテスト用ドメインで再確認し、変更前後の結果を記録します。失敗した場合は元の行に戻し、問題が解消するか確認してください。
システムDNSの基準設定
- 設定セクション
[General]- 設定キー
dns-server- 設定値
system- 確認する操作
- 保存し、選択状態を確認してから接続し直す
systemはシステムDNSを使用する指定であり、固定のサーバーアドレスを示すものではありません。
DoHアドレスの確認
- 設定セクション
[General]- 設定キー
dns-server- アドレスの構成
- HTTPS scheme、ホスト名、サービスのパス
- ドキュメント上の例
https://dns.example.com/dns-query
example.comは説明用のドメインです。利用可能な名前解決サービスではないため、接続に使用できません。
システムDNSに戻すには、該当する設定を次の形式に変更します。コードは関連するセクションのみを示すもので、完全な設定ファイルではありません。ファイル全体を置き換えないでください。現在の設定がリモート更新で管理されている場合、更新によってローカルの変更が上書きされることがあります。コピーを保存し、更新後に再確認してください。
[General]
dns-server = system4. DNSとGlobal Routing・ルールの関係
Home → Global Routingは通信の処理方法を制御するもので、DNSサーバーの選択画面ではありません。Configでは現在の設定ファイルのルールに従って通信を処理します。Proxyは通常の通信をプロキシ経由で処理し、Directは直接接続します。Sceneは設定済みの条件に応じて通信を処理します。これらの選択を切り替えてもdns-serverの確認には代わりません。また、選択肢の名前だけでDNS問い合わせが暗号化されているか、特定の経路を通るかを判断することもできません。
DOMAIN-SUFFIXはドメインの末尾に基づいて一致を判定します。ルール自体は対象のIPアドレスを事前に取得する必要はありませんが、実際の接続には後から名前解決が必要になることがあります。IP-CIDRとGEOIPはIP情報に基づいて一致を判定します。実際の挙動は、リクエストにIPアドレスが含まれているか、また名前解決に影響するオプションがルールに付いているかによっても異なります。FINALは、それ以前のルールに一致しなかった場合に適用される最終ポリシーです。「DNS失敗時の予備サーバー」ではありません。- Settings → On Demandは、条件に応じて接続を開始する機能です。従来方式のDNSをDoHに変換するものではありません。トラブルシューティングでは、実際の接続状態が変化したかを記録してください。
DNSが返すIPアドレスは、その後のIPベースのルール判定に影響することがあります。ただし、ルールの判定結果の違いをすべて名前解決のせいにすることはできません。DNS変更後にアクセス経路が変わった場合は、A / AAAAレコード、適用されたルール、最終的な通信経路も確認してください。一度のアクセス結果だけを理由に、ルール全体を書き換えないでください。
5. 名前解決の不具合を一つずつ切り分ける
まず現象を具体的に記録します。失敗するのは一つのドメインだけか、すべてのドメインか。問い合わせがタイムアウトするのか、IPアドレス取得後に接続できないのか。Wi-Fiだけで起きるのか、モバイル通信でも再現するのか。一度に変更する項目は一つにし、元の設定に戻すとアクセスも復旧するかを記録してください。関連性を確かめながら、検証可能な原因に絞り込めます。
- 設定が反映されているか確認します。Configに戻り、選択中のファイルと
[General]内の実際の値を確認してください。サブスクリプションの更新と設定ファイルの更新は別の操作です。接続先リストが更新されても、DNS行が変更されたとは限りません。 - システムDNSの基準に戻します。一時的に
dns-server = systemに戻し、Global Routingと選択中の接続は変更しません。すぐに復旧した場合は、接続設定をさらに変更せず、カスタムDNSのエンドポイントを重点的に確認してください。 - ネットワークごとに分けて確認します。Wi-Fiとモバイル通信でそれぞれテストしてください。ローカルネットワーク内のDNSがWi-Fiでしか使えないのは、想定される制約です。Web認証が必要なネットワークでは、先に認証を完了してください。
- DoHの前提条件を確認します。完全なアドレス、サービスのパス、端末の日付と時刻、証明書エラーを確認してください。通常、エンドポイントのホスト名は先にIPアドレスを取得する必要があります。最初の名前解決に失敗すると、その後のHTTPS問い合わせを確立できないことがあります。
- キャッシュと新しい結果を区別します。テストページを開き直し、アプリとシステムそれぞれのキャッシュに注意してください。接続し直しても、すべてのキャッシュが消えるとは限りません。古い結果が引き続き使われているだけで、設定が保存されていないと判断しないでください。
- アドレスファミリーを確認します。AAAAレコードが返された場合にだけ失敗するなら、現在のネットワークと通信経路でIPv6に到達できるか確認してください。AAAAがあるという理由だけでIPv6関連の設定をすべて削除せず、まず失敗が名前解決段階か接続段階かを特定します。
| 確認された現象 | 優先して確認する項目 | その現象だけでは判断できないこと |
|---|---|---|
| システムDNSは正常、カスタムDNSはタイムアウト | 接続先アドレス、ポート、ネットワークからの到達性 | すべてのカスタムDNSが利用できないとは限りません |
| DoHでTLS関連のエラーが発生 | ホスト名、証明書の有効性、端末の時刻 | 証明書検証を無効にしてエラーを回避しないでください |
| IPアドレスは返るが、Webサイトに接続できない | ルール判定、通信経路、接続先ポート、TLS | Webサイトに接続できないだけでは、DNSのタイムアウトとは判断できません |
| Wi-Fiは正常だが、モバイル通信では失敗 | 名前解決エンドポイントがローカルネットワークのアドレスか、各ネットワークから到達できるか | 同じアドレスが両方のネットワークから利用できるとは限りません |
DoHエンドポイントをブラウザで直接開き、空白ページやエラーページだけを見てサービス停止と判断しないでください。DoHにはプロトコルに準拠したDNSリクエストが必要で、通常のWebアクセスとは同じテストになりません。また、WebサイトのIPアドレスに直接接続すると、HTTPS証明書、SNI、仮想ホストの設定が原因で失敗する場合があります。「DNSを使わなければ必ず正常」と判断する材料にはなりません。
6. よくある質問
DoHに変更したら遅くなりました。待ち続けるべきですか？
まずシステムDNSに戻し、同じネットワーク、同じドメインで再テストしてください。DoHでは接続確立の負荷が増えることがあり、キャッシュや接続の再利用も結果に影響します。1回のページ読み込み時間だけで名前解決の速度を判断しないでください。差が繰り返し確認できたら、エンドポイントへの到達性とリクエストの経路を確認します。
DoHのドメイン名をIPアドレスに置き換えてもよいですか？
自分で置き換えないでください。HTTPS証明書とホスト名の検証が一致しなくなったり、エンドポイントが特定のホスト名を必要としたりする場合があります。名前解決サービスから案内された完全なアドレスをそのまま使用してください。初回の名前解決に問題がある場合は、まず利用可能な基準設定に戻し、サービスの正式な設定案内に従ってください。
DNSを複数設定すれば、順番に予備として使われますか？
複数アドレスのリストが厳密な優先順位で処理されるとは限りません。並列処理、キャッシュ、具体的な処理方式によって結果が異なる場合があります。問題を切り分けるときは、まず利用可能と確認済みの設定を一つだけ使って動作を確かめてから、ほかのアドレスを追加してください。どのサーバーの応答か分からなくなるのを防げます。
サブスクリプションの更新は成功したのに、Webサイトを開けないのはなぜですか？
サブスクリプションの更新成功が示すのは、その内容を取得して読み込む処理が完了したことだけです。すべてのドメインや通信経路が正常とは限りません。Configに戻ってDNSを確認し、HomeでGlobal Routingと選択中の接続も確認してください。DNSからIPアドレスが返されている場合は、サブスクリプションを繰り返し更新せず、ルールと通信経路を確認します。
元に戻せる設定と、簡潔な記録を残してください。記録するのは、使用したネットワーク、DNS設定、テスト用ドメイン、IPアドレスが返されたか、失敗した段階、設定を戻した後の結果です。利用中のサービスのサポートに問い合わせる際は必要な情報だけを伝え、サブスクリプションのトークン、認証情報、個人のネットワーク情報を隠してください。設定ファイル全体を公開しないでください。