Homeでサーバーを選択済みで、ドメインの名前解決方法を調整したい方を対象にしています。まずシステムDNSで正常に動作する基準を確認し、Configの現在の設定でdns-serverを確認します。DNS over HTTPSを使う場合は、利用可能と確認済みの完全なエンドポイントを設定し、名前解決、ルール、接続結果をそれぞれ確認してください。プロキシ接続に関する操作は、すでにご自身で利用しているサービスとサブスクリプションがあることを前提としています。
DNS設定が変えるのは名前解決。接続方法とは別の設定です
ShadowrocketのDNS設定は、ドメイン名からIPアドレスを取得する方法を指定します。ブラウザでドメインにアクセスするとき、アドレスの取得と接続の確立は別々の段階です。名前解決に成功しても、取得したアドレスのサービスに到達できることや、現在のサーバーで接続できることを示すわけではありません。
Homeではサーバーの選択と接続を管理し、Configでは設定ファイルを管理し、Settingsではアプリの設定を調整します。この記事では変更箇所を明確に記録できるよう、Configのテキスト設定を使ってDNSを説明します。作業を始める前に、現在選択中の設定ファイルを確認してください。有効化されていないコピーだけを編集してしまうのを防げます。
Global RoutingのConfigは設定ルールに従って接続を処理します。ProxyとDirectは全体のルーティング方式を指定し、Sceneは選択したシーンに応じて設定を適用します。これらはDNSの通信方式とは別のものです。Proxyを選んでも、すべての名前解決が自動的にDoHになるわけではありません。Directを選んでも、システムDNSが使われているとは限りません。
システムDNS・カスタムDNS・DoHの選び方
ここでいう「カスタムDNS」は、従来型のDNSサーバーアドレスを手動で入力する設定を指します。広い意味では、DoHエンドポイントの手動入力もカスタム設定に含まれます。比較するときは「名前解決の問い合わせ先」と「問い合わせの通信方式」を分けて考えましょう。そうしないと、アドレスの変更だけで通信が暗号化されたと誤解することがあります。
システムDNS
おすすめシステムで現在使われている名前解決環境を利用します。初回設定やトラブルシューティングの基準として使うと、到達できないエンドポイントや証明書エラーなど、余計な要因を減らせます。おすすめしているのは設定を始める順序であり、あらゆるネットワークでの最終的な選択肢という意味ではありません。
適しているケース：初回接続、基準状態への復帰、ローカルDNSに依存するネットワークリソースへのアクセス
カスタムDNS（従来型）
既知のDNSサーバーのIPアドレスを指定します。従来型DNSには通信の暗号化機能がなく、実際に到達できるかどうかはネットワークとルーティングによります。IPアドレスを変更するだけで、あらゆるドメインへのアクセス問題が解決するわけではありません。
適しているケース：ネットワーク管理者からDNSサーバーを指定されている、名前解決の結果を比較したい
DNS over HTTPS
DNSクエリをHTTPSでDoH対応エンドポイントに送信します。DNSサービスが指定する完全なURLを使ってください。一般のWebサイトのトップページはDNS APIとして使えません。保護されるのはエンドポイントまでの通信であり、DNSサービスは問い合わせ内容を処理できます。
適しているケース：信頼でき、到達可能なDoHエンドポイントがあり、DNS通信を暗号化したい
結論：まず正常に動作する基準を確認する
システムDNSで対象ドメインに正常にアクセスできる場合は、まずその設定を保存してからDoHに切り替えます。切り替え後に問題が起きた場合は、エンドポイントとその接続を優先して確認してください。サーバーとルーティングルールを同時に変更するのは避けましょう。
ConfigでDNSを設定する：バックアップしてから一項目ずつ変更
テキスト設定では通常、[General]セクションにあるdns-serverを編集します。以下の手順では、現在の設定にある名前解決の項目だけを変更します。既存のサブスクリプションを再インポートする必要はありません。リモート設定を使っている場合は、後の更新でローカルの変更が上書きされる可能性があるため、先にコピーを保存してください。
-
現在の設定を記録する
Homeで選択中のサーバーとGlobal Routingの現在値を記録します。Configで選択中の設定を確認し、その設定の操作メニューからコピーを保存します。
-
テキスト設定を開く
Config → 現在の設定の右側にあるⓘ → Edit Plain Textを開きます。既存の
[General]セクションとdns-serverを探し、同じキーを重複して追加せず、既存の値を直接編集してください。 -
DNSを設定する
システムDNSに戻す場合は、
dns-server = systemを設定します。従来型DNSを使う場合は、利用可能と確認済みのDNSサーバーIPアドレスを入力します。DoHを使う場合は、サービスの案内に記載された完全なHTTPSエンドポイントを入力してください。 -
保存して再接続する
保存後、Configに戻り、編集した設定が引き続き有効になっていることを確認します。Homeに戻って接続を切断し、再接続してください。設定を再読み込みした状態でテストできます。
-
ドメインを再確認する
同じネットワーク、同じサーバー、同じルーティング方式で対象ドメインに再度アクセスします。名前解決の結果が返るか、その後の接続に成功するかを記録してから、設定を維持するか元に戻すか判断してください。
システムDNSに戻す最小限の設定例は次のとおりです。これは設定内容の例であり、ファイル全体を置き換えるものではありません。既存の[General]セクションがある場合は、該当する行だけを変更し、ほかの設定や後続のルールはそのまま残してください。
[General]
dns-server = systemDoHアドレスの設定：完全なURL・証明書・初回の名前解決
DoHアドレスには、プロトコル、ホスト名、サービスパスが含まれます。一般的なパスは/dns-queryですが、すべてのサービスがこのパスを使うわけではありません。自分で組み立てず、利用中のDNSサービスが提示するエンドポイントをそのまま指定してください。エンドポイントにデフォルト以外のポートが指定されている場合は、そのポートも残します。
[General]
dns-server = https://resolver.example.com/dns-query上記のresolver.example.comは形式を説明するための予約済みサンプルドメインであり、実際に利用できるDNSサービスとして貼り付けてテストするものではありません。実際の設定には、ご自身の有効なエンドポイントを使ってください。URLの大文字・小文字、パス、必要なパラメーターはサービスの指定どおりに保ちます。一般のWebページのURLやサブスクリプションリンクをDNS欄に入力しないでください。
- HTTPSハンドシェイク：デバイスの時刻が大きくずれている、証明書が信頼されていない、またはエンドポイントのドメイン名と証明書が一致しない場合、クエリの送信前に失敗することがあります。時刻とサーバー証明書を確認してください。証明書の検証を無効にして対処するのは避けてください。
- 初回の名前解決：エンドポイントがホスト名を使う場合、接続前にそのIPアドレスを取得する必要があります。最初の名前解決ができなければ、DoHに切り替えてもタイムアウトすることがあります。原因を対象ドメインの問題と決めつけないでください。
- エンドポイントへのルーティング：DoHサービス自体へのアクセスも一つの接続です。そのルートと必要条件が成立する必要があります。「DNSサービスに接続するために、同じDNSサービスでの名前解決が必要」という循環を避けてください。
- 応答内容：通常のWebページが開けても、同じホスト名のDoH APIが有効とは限りません。APIパスの誤り、認証の失効、Webページの応答は、いずれもDNS応答とは異なります。
HTTPSの問題を解決するために、ドメイン名を任意に調べたIPアドレスへ置き換えないでください。証明書のホスト名検証が失敗したり、サービスが必要とするホスト名情報が失われたりする可能性があります。アドレスを固定する必要がある場合は、DNSサービスとアプリが対応する設定方法に従ってください。
名前解決のトラブルシューティング：応答なし・誤った応答・接続失敗を切り分ける
問題を調べる際は、まず発生時の状況を記録します。ネットワークの種類、対象ドメイン、有効な設定、Global Routingの値、おおまかなエラー内容を控えてください。各回で変更する条件は一つだけにします。サブスクリプションの更新、サーバー変更、DNS変更を同時に行うと、アクセスが回復しても何が有効だったのか判断しにくくなります。
| 確認できる症状 | まず確認する項目 | 次に行う操作 |
|---|---|---|
| DoHに切り替えると複数のドメインがタイムアウトする | エンドポイントの完全なURL、証明書、エンドポイントへの到達性 | systemに戻して再テストし、基準状態に戻った後でDoHを確認する |
| 名前解決はできるが、ページへの接続がタイムアウトする | 実際に適用されたルールとサーバーへの接続 | Global Routingと設定ルールを確認し、DNSを何度も変更しない |
| 一般のドメインは正常だが、社内ドメインにアクセスできない | LAN内で提供される名前解決結果に依存しているか | 現在のネットワークのシステムDNSに戻して確認し、ローカルDNSが必要か検討する |
| Wi-Fiでは正常だが、モバイル通信では失敗する | 各ネットワークからDNSエンドポイントに到達できるか | サーバーと設定を固定し、ネットワークだけを切り替えて結果を記録する |
| 変更しても動作に違いがない | 編集した設定が有効か、古い接続が再利用されていないか | Configで選択中の設定を確認し、再接続してからサービスに再アクセスする |
ルールを調べるには、ドメイン条件とアドレス条件の両方を理解する必要があります。DOMAIN-SUFFIXはドメインのサフィックスに一致します。IP-CIDRとGEOIPはIPアドレスの条件に基づいて一致します。FINALは、それまでのルールに一致しなかった接続を処理します。名前解決の結果が変わると、IPアドレスを使うルールの判定に影響することがありますが、ルールの順序が自動で修正されるわけではありません。
Global RoutingのConfigとProxyを切り替えて比較すると、ルールの影響を判断する手がかりになります。ただし、一時的なテスト方法を恒久的な解決策としないでください。Configでのみ失敗する場合は、実際に適用されたルールを確認します。IPアドレスを使うルールでは、no-resolveなど、名前解決に影響するオプションの有無も確認してください。
結論：IPアドレスを取得できたら接続経路を調べる
同じドメインから安定してIPアドレスが返り、その後の接続で失敗する場合は、ルール、サーバー、接続先サービスを重点的に確認してください。DNSを繰り返し切り替えると要因が増え、問題の範囲を特定しにくくなります。
設定の保存前に確認する項目と復元手順
DNS設定は、実際に使うネットワークで確認してください。パブリックDNSサービスでは、自宅や職場のネットワーク内の名前を解決できないことがあります。通信が暗号化されていても、結果が現在のネットワークに適しているとは限りません。社内ネットワークと一般のサービスの両方にアクセスする場合は、まずローカルDNSの必要性を確認し、そのうえで詳細な設定を検討してください。
- 設定の提供元を確認：リモート設定を更新した後は、
dns-serverを再確認してください。サブスクリプションの更新は、主にサービス提供元が配布するサーバー情報を同期するためのものです。DNSの問題を直すための定型手順として扱わないでください。 - 自動接続を確認：Settings → On Demandで、オンデマンド接続が有効になっているか確認します。手動で切断してもすぐ再接続する場合は、設定が保存されていないと判断する前に、自動接続の条件を確認してください。
- IPv6を確認：AAAAレコードが返ることと、IPv6で接続できることは別です。アドレスがあるのに接続できない場合は、レコードの種類だけで判断せず、現在のネットワークでIPv6が到達可能か確認してください。
- 最小限の基準状態に戻す：バックアップした設定、または
dns-server = systemに戻してから再接続し、テストします。基準状態で問題が解消した後、必要な設定を一つずつ追加してください。
ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリです。主にiPhoneとiPadで利用でき、入手先はApp Storeのみです。システム要件はApp Storeの掲載内容をご確認ください。アプリの買い切り購入と通信サービスの契約は別のものです。DNS設定によって、利用中の通信サービスが追加されたり置き換えられたりすることはありません。