この記事では、Shadowrocketに自分の設定を読み込み済みの方を対象に、遅延テストで分かることを確認したうえで、Global Routing、現在のConfig、DNSの応答結果、IPv6経路を順に調べます。名前解決の失敗と、名前解決後の接続失敗を切り分けましょう。調査中は元の設定を残し、一度に変更する項目は一つだけにして、同じドメインで再テストしてください。
1. 遅延テストが正常でも、名前解決が正常とは限らない
Homeに遅延時間が表示されても、それはテストで使用した宛先、プロトコル、経路から応答があったことを示すにすぎません。テスト方法によって確認できる範囲は異なります。ポートに接続できてもWebページのTLSハンドシェイクが完了するとは限らず、HTTPテストが一度成功しても、すべてのサイトにアクセスできるとは限りません。DNSに問題があるかどうかを判断するには、遅延の色だけでなく、問題のドメインの名前解決結果を確認します。
ブラウザでWebサイトを開くと、通常はまずドメインをIPアドレスに変換し、実際のルーティングに従って接続した後、TLSとHTTPのリクエストを行います。プロキシプロトコル、ドメインルール、リモートDNSによって処理される場所が変わることがあります。以下は切り分けの手順であり、すべてのリクエストが同じ流れで処理されるわけではありません。
ログにアドレスの応答がなければ、まずDNSを確認します。AまたはAAAAアドレスを取得できているのに接続時にタイムアウトする場合は、実際の送信経路、宛先ポート、ネットワーク経路を調べます。証明書の検証に失敗した場合は、端末の時刻、宛先ドメイン、証明書情報も確認してください。DNSが原因だと決めつけるのは避けましょう。
IPアドレスを直接開いても、十分な確認にはなりません。多くのHTTPSサイトでは、証明書やサイトの内容を決めるためにドメイン名が使われます。アドレス欄のドメインをIPアドレスに置き換えて開けなくても、そのIPアドレスに到達できない証拠にも、DNSが正常である証拠にもなりません。
2. Home、Config、接続状態を確認する
DNS設定を正しく判断するには、実際に有効なConfigと通信経路を確認する必要があります。まずHomeで現在使用している接続項目を確認し、次にGlobal Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング方法です。いずれか一つの方法で成功または失敗しただけでは、DNSサーバーに問題があるとは判断できません。Sceneの動作結果は、設定済みの条件にも左右されます。
-
現在の状態を記録する
Homeで選択中の接続項目とGlobal Routingの値を記録し、接続中のネットワークがWi-Fiかモバイル通信かも控えておきます。実際に開けないドメインを一つ選び、テストのたびにWebサイトを変えないようにしてください。
-
Configを確認する
Configを開き、現在選択されている設定ファイルを確認します。そのファイルの編集画面を開く前に、元の内容を保存してから
[General]と[Rule]を確認してください。選択されていない別のファイルだけを変更しても、現在の接続動作は変わりません。 -
自動接続の影響を切り分ける
Settings → On Demandを開き、現在の状態を記録します。手動で切断して比較する場合は、条件に応じてシステムが再接続しないよう、On Demandを一時的にオフにできます。テストが終わったら元の設定に戻してください。
-
一項目ずつ再テストする
設定を一つ変更して保存したら、Homeに戻って切断し、再接続して同じドメインにアクセスします。必要に応じてブラウザで新しいタブを開いてください。以前のページやシステム、ブラウザのキャッシュによって、結果がすぐに変わらない場合があります。
異なるGlobal Routingの状態を比較する場合は、元の値を記録し、短時間だけテストしたらすぐに戻します。Directでは対象の通信が直接接続経路を通り、Proxyでは送信先の選択が変わります。この比較でネットワーク経路の違いが分かる場合はありますが、一般的な設定修正として使えるわけではありません。重要な通信を行う場合は、経路を切り替える影響を事前に確認してください。
3. DNS設定項目の見方
現在のConfigの内容を確認するときは、まず[General]にあるdns-serverを探します。この項目はDNSリゾルバーを指定します。systemはシステムが提供するDNSを使用する設定です。ほかのDNS関連項目がある場合は、アプリのパラメータ説明に従って一つずつ確認し、用途の異なるアドレスを同じ項目にまとめて指定しないでください。
| 項目 | 意味 | 確認ポイント |
|---|---|---|
dns-server | Configで使用するDNSリゾルバー | アドレスが正しいか、現在のネットワークから到達できるか、現在のConfigで有効になっているか |
system | システムが提供するDNSを使用 | Wi-Fiとモバイル通信を切り替えると、システムのリゾルバーやアクセス条件が変わる場合がある |
A | ドメインのIPv4アドレスレコード | 応答が返るか、返されたアドレスに接続できるか |
AAAA | ドメインのIPv6アドレスレコード | アドレスを取得できても、現在のIPv6経路が使えるとは限らない |
TTL | DNSレコードのキャッシュ有効期間 | 設定を変更しても、以前の結果がしばらくキャッシュに残る場合がある |
以下はConfigの構造を確認するための最小限の例であり、完全なConfigではありません。元のファイルに上書きしないでください。システムのリゾルバーと比較する場合は、既存の[General]にある該当キーだけを変更し、セクションやキーを重複して追加しないようにします。
[General]
dns-server = systemポート番号から分かるのは通信方式であり、到達可能性が保証されるわけではありません。通常のDNSリクエストは現在のネットワークでタイムアウトする場合があります。DoHもHTTPS接続が必要で、ドメイン名で指定されたDoHエンドポイントには最初の名前解決も必要です。どのリゾルバーを使うかは、既存の設定要件、ネットワークからの到達性、データの取り扱いを踏まえて判断してください。暗号化通信だから必ず速いとは限りません。
4. 応答結果からDNSの障害を3種類に切り分ける
アプリ内のリクエスト記録や診断ログでは、問題のドメイン、クエリタイプ、応答ステータス、その後の接続結果を確認します。以下はDNSの応答コードやよくあるタイムアウト表示の例です。Shadowrocketのすべての画面に、これらの文字列がそのまま表示されるわけではありません。ブラウザに日本語のメッセージだけが表示された場合は、表示内容をそのまま記録し、独自にエラーコードを推測して補わないでください。
NXDOMAIN
原因：リゾルバーが、そのドメインは存在しないと応答しています。ドメインの入力ミス、ドメインの失効、または現在のリゾルバーによる否定応答が考えられます。
対処法：まず完全なホスト名を確認し、確実に有効な別のドメインで比較します。そのドメインだけで問題が続く場合は、サイトの管理者に問い合わせてください。待ち時間を延ばすだけでは解決しません。
SERVFAIL
原因：リゾルバーがクエリを完了できていません。上流からの応答、権威DNSサーバー、検証処理などが関係する場合があります。ドメインが存在しないという意味ではありません。
対処法：元の値を記録してから、既存の到達可能な別のリゾルバーで一度比較します。特定のドメインだけに影響する場合は、問い合わせ時刻と応答コードを記録し、サイトの管理者に調査を依頼してください。
timeout
原因：制限時間内に応答を受け取れませんでした。リゾルバーへの通信経路で停滞している場合も、名前解決後の宛先への接続で停滞している場合もあります。
対処法：まず、どの段階でタイムアウトしたかを確認します。DNSの応答がない場合はリゾルバーのアドレスとネットワークからの到達性を調べ、アドレスを取得できている場合は送信経路と宛先ポートを確認します。
一度の失敗だけで結論を出すことはできません。同じドメインに繰り返しリクエストし、確実に有効な別のドメインでも比較してください。すべて失敗する場合はDNSの共通経路、特定のドメインだけ失敗する場合はそのドメインや権威DNSに問題がある可能性が高くなります。記録にはクエリタイプも残してください。AAAAレコードが一度返らなかっただけで、ドメイン全体が名前解決できないと誤判断しないようにします。
- アドレスが返らない：入力ミス、応答コード、リゾルバーへの通信経路を確認します。
- Aアドレスは返るが接続がタイムアウトする：そのリクエストで実際に使われたルールと送信先を確認します。DNSの変更を繰り返す必要はありません。
- AAAA経由の接続だけ失敗する：IPv4とIPv6の接続結果を比較してから、アドレスファミリー関連の設定を変更するか判断します。
- トップページは開くが一部のリソースが失敗する：失敗したリソースのドメインを個別に確認します。一つのページで複数のドメインが使われている場合があります。
5. ルールやIPv6がDNS障害のように見える理由
Global RoutingでConfigを使用している場合、ルールに基づいて送信先が選ばれます。DOMAIN-SUFFIXはドメインのサフィックスで照合し、IP-CIDRとGEOIPはアドレスに関する条件で判定します。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ルールの順序、名前解決が必要かどうか、どこで名前解決するかによって、最終的に観察される動作が変わります。
以下は、照合対象を説明するためのルール構文例です。example.comと192.0.2.0/24はドキュメント用の例であり、追加すべきサイトや経路ではありません。この例全体を既存ルールの末尾に追加しないでください。既存のFINALやその前にあるルールによって、追加しても実際には動作しない場合があります。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXYno-resolveは、このIPルールに一致させるためのドメイン名解決を積極的に行わないことを示します。すべてのDNSを無効にする設定でも、名前解決失敗を直すための設定でもありません。ドメインルールが意図しない経路に一致した場合、DNSが正常でもページを開けないことがあります。Configのテキストだけで判断せず、リクエスト記録で実際に適用されたルールを確認してください。
IPv6の調査では比較が必要です。AAAAレコードを取得できても、リゾルバーからIPv6アドレスが返されたことを示すだけです。現在のネットワークでIPv6接続が正常に機能しない場合、接続待ちやIPv4へのフォールバックが発生することがあります。まず現在のConfigにあるIPv6関連の設定を記録し、一項目だけ一時的に比較してください。DNS、Global Routing、IPv6を同時に変更すると、どの設定が結果に影響したのか分からなくなります。
6. よくある質問と再現可能な調査記録
DNSを変更しても、結果が変わらないのはなぜですか？
まずConfigで、変更したファイルが現在選択中のものか確認します。保存後にHomeへ戻って再接続し、新しいタブで同じドメインにアクセスしてください。システム、ブラウザ、アプリがキャッシュを保持している場合があります。古いページを何度も再読み込みしても、新しいリゾルバーが使われた証拠にはなりません。
Wi-Fiでは開けないのに、モバイル通信では開ける場合はどうすればよいですか？
接続項目、Global Routing、Configは同じまま、ネットワークだけを切り替えて比較します。差が生じる理由として、ネットワークが提供するDNS、リゾルバーへの到達性、IPv6経路などが考えられます。現在systemを使っている場合は、ネットワークの切り替えも特に重要な比較条件として記録してください。
遅延は正常なのに、登録済みのサブスクリプションを更新できません。DNSの問題ですか？
まず、サブスクリプションのホスト名の名前解決失敗、接続タイムアウト、HTTPエラー応答を切り分けてください。名前解決が成功しても401や403が返る場合は、認証とリンクの有効性を利用中のサービス提供元に確認します。DNSを変更しても、アクセス認証情報の問題は解決しません。
Proxyに変更して開けるなら、DNSが直ったということですか？
いいえ。Global RoutingをProxyに変更すると、送信経路や名前解決に関わる経路も同時に変わる場合があります。元の値に戻し、Configで失敗したリクエストに適用されたルールと応答アドレスを確認してから、問題が確認できた設定だけを変更してください。
引き続き相談する場合は、遅延画面のスクリーンショットよりも、再現条件を共有する方が役立ちます。以下の情報は一連のテスト中に記録してください。ログに含まれるサブスクリプションの認証情報、アカウント情報、Config全体は削除し、障害の判断に必要な項目だけを残します。
- 利用環境：iPhoneまたはiPad、Wi-Fiまたはモバイル通信、On Demandの有効・無効。
- 状態：Homeに表示されるGlobal Routingの値、現在のConfig名、直前に再接続したかどうか。
- リクエスト：失敗したドメイン、発生時刻、AまたはAAAAの検索結果、DNS応答コードまたはエラーの原文。
- 接続状況：アドレスを取得できた場合は、適用されたルールと送信先を記録します。また、接続、TLS、HTTPのどの段階で失敗したかも記録してください。
- 比較結果：各回で変更した設定項目、変更前後の状況、元の値に戻した後に再発したかどうか。
調査の終了条件は遅延時間が短くなることではなく、同じドメインを安定して名前解決でき、リクエストが想定どおりのルールで送信され、ページから応答が返ることです。特定のドメインやネットワーク経路だけに問題があると確認できたら、有効な比較結果を記録しておけば十分です。正常な設定まで変更し続ける必要はありません。