ShadowrocketのDNS設定方法|システムDNS・カスタムDNS・DNS over HTTPSの違い

ShadowrocketのシステムDNS、カスタムDNS、DNS over HTTPSの役割と違いを解説。設定ファイルのdns-serverの書き方も紹介します。

この記事の概要

iPhoneやiPadでShadowrocketを使っていて、ドメインに接続できない、または想定と異なる名前解決結果になる場合は、まず「どこに問い合わせるか」「問い合わせをどう送るか」「リクエストが最終的にどの経路を通るか」を切り分けましょう。この記事では、3種類のDNS設定の選び方、dns-serverの書き方、順を追った確認方法を解説します。記載のアドレスは書式例です。

接続時にDNSが担う処理

ドメインにアクセスする際、通常はまず対応するIPアドレスを取得し、その後で接続先に接続します。DNSはこの名前解決を担いますが、Shadowrocketの接続スイッチとは別のもので、リクエストがProxyとDirectのどちらを使うかを直接決めるものでもありません。Shadowrocketの Global Routing が通信のルーティング方式を決定します。Config を選択した場合は、設定内のルールもリクエストの処理方法に影響します。

そのため、「接続はオンなのに、ドメインを入力しても開けない」という症状だけでDNSが原因とは断定できません。まず現象を切り分けます。ドメインでは失敗する一方、接続可能とわかっているIPアドレスならつながる場合は、名前解決を優先して確認します。ドメインもIPアドレスも失敗する場合は、接続状態やルーティング方法、利用中のサービスの状態も確認してください。ページを一度読み込めなかっただけで、すべてのDNS設定に問題があると判断しないようにしましょう。

53
一般的なDNS問い合わせで使われるポート。利用するかどうかは設定とネットワーク経路によって異なります
443
DNS over HTTPSで通常使用されるHTTPSポート
3項目
名前解決の参照先、問い合わせの転送方式、Global Routingをそれぞれ確認

もうひとつ、混同しやすい点があります。アプリがキャッシュ済みの名前解決結果を使うことや、リクエスト先でドメイン名を処理することもあります。ページが再び表示されても、変更したローカルDNSがその問い合わせに使われたとは限りません。確認時は、変更前後の対象ドメイン、ネットワーク環境、具体的な症状を記録し、キャッシュが使われた場合と設定が反映された場合を区別しましょう。

システムDNS・カスタムDNS・DNS over HTTPSの選び方

システムDNSは、現在のネットワークから提供される、またはシステムが使用中のDNS設定を利用します。Wi-Fiとモバイル通信を切り替えると、実際の名前解決先も変わることがあります。まずは原因を切り分けるための基準として、初期設定のまま接続とルールが正常に動作するか確認し、DNSを変更する必要があるか判断しましょう。

カスタムDNSでは、名前解決サーバーのアドレスを指定します。利用可能なサーバーアドレスがわかっていて、ネットワークごとの名前解決の違いを確認したい場合に適しています。サーバーに接続できるか、現在のネットワーク環境に対応しているかは、それぞれ確認が必要です。アドレスを入力しても、すべてのドメインが同じ結果になるとは限らず、問い合わせが自動的に暗号化されるわけでもありません。

システムDNS

おすすめ

まずは現在のネットワークのDNS設定をそのまま使い、比較できる基準を作りましょう。ネットワークを切り替えた後も結果を確認してください。

おすすめのケース:初期設定時、問題が名前解決に起因するかまだわからない場合

カスタムDNS

設定ファイルに、利用可能と確認済みのDNSサーバーのIPアドレスを指定し、現在のネットワークで応答があるか個別に確認します。

おすすめのケース:使用するDNSサービスのアドレスがわかっていて、問い合わせ先を指定したい場合

DNS over HTTPS

対応するDNS問い合わせをHTTPS経由で指定のエンドポイントへ送信します。エンドポイントに接続できるか、リクエストがどの経路を通るかも確認が必要です。

おすすめのケース:利用可能なDoHエンドポイントがあり、問い合わせの転送方式を確認したい場合

DNS over HTTPSは、通常DoHと略されます。これはDNS問い合わせの転送方式を示すもので、Global Routingに新しいルーティング方法を追加するものではありません。また、通常のDNSサーバーのIPアドレスにhttps://を付けるだけで使えるようになるわけでもありません。DoHには有効なHTTPSエンドポイントが必要です。最初にエンドポイントへ接続するときのホスト名の名前解決方法や、接続が実際に通る経路も結果に影響します。

確認の順序:まず初期設定のまま試し、変更は1項目ずつ

システムDNSで正常にアクセスできる場合は、DNSサーバー、DoHエンドポイント、ルーティング方法を同時に変更しないでください。一度に変更するのは1項目だけにすると、違いがDNS、転送方式、ルールの適用のどれによるものか判断できます。

Configでのdns-serverの書き方と適用範囲

設定ファイルを編集する場合は、まずConfigで現在使用中の設定を確認し、未適用のコピーを編集していないか確かめてください。dns-serverは設定ファイルの[General]セクションに記述する項目で、[Rule]のルール行ではありません。変更を保存したら、Homeに戻り、現在の設定とGlobal Routingを確認します。設定内のルールに従って動作させるには、ルーティング方法としてConfigを選択してください。

[General]
dns-server = system

上の例のsystemは、システムDNSを使用する指定です。カスタムアドレスの書き方を示す場合は、同じ項目にIPアドレスを記述し、半角カンマで区切ります。以下のアドレスはドキュメント用の例示範囲に属するため、書式の説明にのみ使用しています。利用可能なDNSサービスのアドレスとして、そのまま入力しないでください。

[General]
dns-server = 192.0.2.53, 198.51.100.53
  1. [General]セクションはそのままにし、項目名はdns-serverと記述します。等号とアドレスの間のスペースは、読みやすさのために入れています。
  2. 実際に使う際は、例示アドレスを、到達可能と確認済みのDNSサーバーのIPアドレスに置き換えてください。サブスクリプションURL、ドメインルール、DoH URLを、このIPアドレスの例に入力しないでください。
  3. 保存後、現在有効な設定を確認します。テストのためにDirectまたはProxyに切り替える場合は、それぞれの結果を記録してください。同じルール環境として扱わないようにしましょう。

複数のアドレスを指定しても、「常に先頭のアドレスですべての問い合わせを処理し、失敗したときだけ2番目に切り替える」と保証されるわけではありません。実際の選択やフォールバックの動作は、設定やネットワーク環境によって変わります。特定のサーバーを検証する場合は、まずそのアドレスだけを指定してテストし、その後、元の設定に戻してください。dns-serverのアドレス一覧を速度ランキングと見なさないでください。

DNS over HTTPSの設定時に確認すること

Settings → DNSで、現在利用できるDNSオプションを確認します。画面にDNS over HTTPSの入力欄がある場合は、利用可能と確認済みの完全なHTTPSエンドポイントを入力し、画面の案内に従って保存してください。DoHエンドポイントはhttps://dns.example.com/dns-queryのような形式です。このドメインはURLの構造を示す例であり、そのまま使えるサービスのアドレスではありません。このURLを、前述のサーバーIPアドレスを記述するdns-serverの行に入力しないでください。

DoHは、対象となるDNS問い合わせの転送方法を変更しますが、Webリクエストも同じ経路を通ることを保証するものではありません。現在のネットワークから指定したエンドポイントに接続できない場合や、エンドポイントのホスト名を最初に名前解決できない場合、問い合わせが失敗することがあります。まずエンドポイントのアドレスが完全で、サービスが実際に利用可能か確認し、接続状態とルールをあわせてリクエストの経路を確認してください。

DNSとリクエストのルーティングを分けて記録

名前解決を確認
  • システムDNS、カスタムアドレス、DoHエンドポイントのどれを使用中か記録
  • ネットワークを切り替え、同じドメインで再テスト
  • 設定変更後、編集したファイルが有効になっているか確認
ルーティングを確認
  • Homeで接続状態を確認
  • Global RoutingがConfig、Proxy、Directのどれかを記録
  • Config使用時は、該当するルールが適用されているかも確認

両方の情報を記録すると、「ドメインを名前解決できない」のか「名前解決はできたが、その後の接続に失敗した」のかを切り分けられます。

たとえば、DOMAIN-SUFFIX,example.com,DIRECTは、該当ドメインに一致した場合にDIRECTを使う指定です。DNSサーバーを指定する書式ではありません。GEOIPやIP-CIDRなどのルールはアドレスを照合し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。DNSを変更すると取得されるIPアドレスが変わることがありますが、それだけで、すべてのルールの一致結果も必ず変わるとは限りません。

変更後も開けない場合:症状ごとに確認

まずテスト条件を固定します。同じネットワーク、同じドメイン、同じGlobal Routingを維持し、変更するDNS設定は1項目だけにします。「ドメインを解決できない」「名前解決後に接続がタイムアウトする」「特定のアプリだけ失敗する」など、具体的な症状を記録すると、「使えない」という記録より原因を特定しやすくなります。テストが終わったら元の設定に戻し、症状も元に戻るか確認してください。

dns-serverを設定しても変化がわからないのはなぜ?

まずConfigで、現在使用中のファイルに保存した[General]項目が含まれているか確認し、次にHomeでGlobal Routingを記録します。同じネットワークとドメインで再テストしてください。すでに開いているページだけで判断しないようにしましょう。既存の接続やキャッシュにより、以前の結果が使われていることがあります。

DoHに変更したら、かえってドメインに接続できない?

URLにhttps://が含まれているか、エンドポイントのパスが完全かを確認し、指定したサービスに現在のネットワークから接続できるか確かめてください。その後、以前使えていたDNS設定に一時的に戻します。症状が解消する場合は、DoHエンドポイントと最初の名前解決を個別に確認しましょう。

Wi-Fiでは正常なのに、ネットワークを変えると失敗する?

2種類のネットワークそれぞれで、DNS設定とテスト結果を記録します。システムDNSを使っている場合、ネットワークの切り替えで名前解決先が変わることがあります。カスタムアドレスやDoHを使っている場合は、指定したサービスに新しいネットワークから接続できるかも確認してください。ルールとDNSを同時に変更しないようにしましょう。

名前解決はできるのに、Webページの読み込みが終わらない?

Homeに戻り、接続状態とGlobal Routingを確認します。Configを使っている場合は、DOMAIN-SUFFIX、IP-CIDR、FINALなどのルールがどのように一致するかも確認してください。名前解決に成功しても、その後の接続が成功するとは限りません。

確認が終わったら、動作を検証済みの設定を保存しておきましょう。Home、Config、接続手順について詳しく知りたい場合は、サイト内の入門ガイドもご覧ください。ShadowrocketはApp Storeで提供されるAppleプラットフォーム向けの有料アプリです。iPhone、iPadなどの対応状況とシステム要件は、App Storeの製品ページをご確認ください。アプリの購入と、DNSサービスや利用中のサブスクリプションの内容は別のものです。

Shadowrocketの入手先と基本操作を確認

まず当サイトでApp Storeの製品ページとデベロッパ情報を確認し、入門ガイドに沿って現在の設定と接続状態を確認してください。

正規の入手先を確認 使い方を見る
App Storeでの正規品確認