ShadowrocketのDNSエラー対処法｜遅延は正常なのにWebページが開けない場合

1. 遅延が正常でもDNSが正常とは限らない理由

ShadowrocketのConnectivity Testは、選択したテスト方式に応じて通信状態を確認します。表示される時間が示すのは、そのテストで使われた対象と経路だけです。テストに成功しても、すべてのWebサイトのドメインが解決できること、すべての通信経路でアクセスできること、HTTPSのハンドシェイクが必ず成功することは分かりません。遅延の数値だけで判断せず、テスト方式と対象を確認しましょう。

Webページを開くには、ドメインに対応するアドレスの取得、アクセス方針の選択、接続の確立、TLSハンドシェイクが必要です。以下は問題を切り分けるための論理的な整理であり、クライアント内部の処理が常にこの順番で進むという意味ではありません。たとえば、ドメインルールはIPアドレスの取得前に判定できる一方、IPルールの適用には名前解決が必要な場合があります。

DNSの問題かどうかを判断するには、名前解決に失敗した証拠を確認します。ブラウザーにサーバーが見つからないと明示される場合や、システムの検索ツールでアドレスを取得できない場合は、「ページが読み込み中のまま」という状況よりDNSの問題を特定しやすくなります。アドレスを取得できているのに接続や証明書の検証で失敗する場合は、通信経路、ルール、システム時刻、またはWebサイト自体を確認してください。

• すべてのドメインにアクセスできない：まず、使用中のリゾルバーに到達できるか、現在のネットワークでWeb認証が必要か、VPN接続が維持されているかを確認します。
• 一部のドメインだけ失敗する：ドメインの入力ミス、個別DNS設定、ルールの適用状況、接続先サイトの状態を確認します。
• ページの文字は表示されるが画像が読み込まれない：読み込みに失敗したリソースのドメインを記録してください。メインサイトと画像、APIでは、異なるドメインやルールが使われることがあります。
• IPアドレスを直接指定しても失敗する：それだけでDNSの問題を否定したり、通信経路の障害と断定したりはできません。HTTPSサイトでは正しいドメイン名、SNI、証明書が必要なことが多く、IPアドレスへの直接アクセスは確実な比較方法ではありません。

2. 現在の設定を記録してから、3つの条件で比較する

変更する前に、Home → Global Routingの現在の選択肢、使用中のサーバー、Configで有効な設定、Settings → DNSの現在値を記録してください。Configを複製して調査用のコピーを作り、唯一の設定ファイルを続けて変更しないようにします。サブスクリプションの内容は更新時に上書きされる場合があるため、手動設定とサービス提供元の設定も区別してください。

1. 同じネットワークで比較：現在のWi-Fiで、通常は直接アクセスできるサイトと問題が起きているサイトをそれぞれ試します。「開かない」だけでなく、エラーメッセージ全文を記録してください。接続を切って比較する場合は、直接アクセスが許可されているサイトだけを試し、Settings → On Demandの条件によって自動再接続されないか確認します。
2. 別のネットワークで比較：サーバー、Config、DNSは変えずに、Wi-Fiからモバイル通信に切り替えるか、利用可能と分かっている別のネットワークで試します。特定のWi-Fiだけで失敗する場合は、そのネットワークの認証ページ、DNS制限、ルーター設定を優先して確認してください。
3. 接続モードを変えて比較：元の選択肢を記録したうえで、Home → Global Routingで一時的にConfigとProxyを比較します。Proxyは一般的なWeb通信がプロキシ経由で出ていく場合の比較に使いますが、すべてのDNSリクエストが自動的にプロキシ経由になるわけではありません。確認後は元の選択肢に戻してください。

3. Settings → DNS：アドレス、初期値、推奨設定

Settings → DNSを開き、現在の設定がシステムの名前解決を使っているか、カスタムリゾルバーを使っているかを確認します。すべての端末で共通の「初期アドレス」があるわけではありません。プラットフォーム、既存の設定、読み込んだConfigによって有効な値は変わることがあります。端末の現在の画面と有効なConfigを基準にしてください。カスタム設定を使っている場合は、先に元の値を保存してから1項目ずつ比較します。

リゾルバーのアドレスは問い合わせ先を指定し、通信方式は問い合わせの送信方法を決めます。ドメイン別設定は、特定のドメインに別の名前解決経路を使うかどうかを決めます。この3つは分けて確認してください。リゾルバーを変更しても、誤ったPROXYポリシーが自動で直るわけではなく、到達不能なプロキシサーバーが接続可能になるわけでもありません。

DNSアドレスを複数追加しても、自動的に問題が解決するわけではありません。実装によって問い合わせやフォールバックの仕組みは異なり、リストの2番目のアドレスが1番目のタイムアウト後に必ず使われるとは限りません。まずリゾルバーを1つに絞って到達性を確認し、必要に応じて設定を戻してください。

暗号化DNSのサーバーにドメイン名が使われ、その名前の解決にも、まだ接続できていない同じサービスが必要な場合、起動時に依存関係の問題が起きることがあります。証明書検証を無効にするのではなく、設定の提供元が指定する起動時の名前解決やルーティング設定を確認してください。暗号化DNSのアドレスを安易にIPアドレスへ置き換えると、証明書のホスト名検証に失敗するおそれがあります。

4. Config内のDNS上書き設定とルールの順序を確認

Settings → DNSを変更しても状況が変わらない場合は、Configに戻り、有効な設定の [General]、[Host]、[Rule]を確認します。DNS関連の設定、ドメインの対応付け、ルールが組み合わさって実際の通信経路を変えることがあります。設定画面に表示されたアドレスが、そのドメインで最終的に使われるリゾルバーだとは限りません。Configと、利用できるリクエスト記録を照らし合わせて確認してください。

ルールは上から順に評価され、一致した時点で対応するポリシーが使われます。以下は順序の例であり、既存のConfigと置き換えられる完全な設定ファイルではありません。PROXYは現在のConfigで利用できるポリシーまたはポリシーグループに対応させ、例示のドメインは実際に調査する対象へ置き換えてください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX,example.com,PROXY：このドメインとそのサブドメインに一致します。前に関連ルールがある場合、後から追加したルールが適用されないことがあります。
• IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このプライベートアドレス範囲にDIRECTを指定します。no-resolveは、このIPルールに一致させるためにドメインの名前解決を積極的に行わない指定であり、クライアント全体のDNSを無効にするものではありません。
• GEOIP,CN,DIRECT：IPのジオロケーションデータベースに基づいて判定します。結果はIPアドレスとデータベースに左右されるため、実際に名前解決されたIPと適用されたルールを照合してください。
• FINAL,PROXY：前のルールに一致しなかった場合に使われるフォールバックポリシーです。DNS設定の代わりにはならず、誤ったドメインの対応付けも修正できません。

ドメインにREJECTが適用されている場合は、意図して有効にしたフィルタールールか確認してください。DIRECTが適用されてアクセスできず、プロキシ経由ならアクセスできる場合は、DNS全体を変更する前に対象ドメインのポリシーを調整します。社内ドメインでは、社内DNSとDIRECTの組み合わせが必要なことがあります。パブリックリゾルバーでは社内ドメインの名前解決を代替できません。

5. エラーメッセージから名前解決、接続、証明書の問題を切り分ける

以下はブラウザーやコマンドラインツールに表示されることがあるエラーメッセージの原文であり、Shadowrocketの全プラットフォームで共通の表示ではありません。エラーが発生したアプリ、対象ドメイン、発生時刻を記録し、クライアントのリクエスト記録と照らし合わせてください。ブラウザーに表示されるエラーをすべてDNSの失敗と判断しないようにします。

Mac、Windows、Linuxでは、システム標準のnslookupを比較用に利用できます。以下のexample.comは例示用のドメインなので、実際に失敗しているドメインに置き換えてください。1つ目のコマンドはツールが現在使用する既定のリゾルバーを使い、2つ目はパブリックリゾルバーを指定します。

nslookup example.com
nslookup example.com 1.1.1.1

応答に表示される問い合わせ先サーバー、アドレスの有無、タイムアウトやNXDOMAINの発生を確認してください。このツールではブラウザー独自の暗号化DNSやShadowrocketのすべてのドメインポリシーを再現できるとは限りません。そのため、比較の手がかりにはなりますが、クライアント内部の問い合わせ結果の代わりにはなりません。ブラウザーでセキュアDNSを個別に有効にしている場合は、その状態も記録し、条件をそろえてシステムの名前解決を使った場合と比較してください。

6. 変更後の再テストと元に戻す手順

DNSの応答は、クライアント、システム、ブラウザーそれぞれでキャッシュされることがあります。設定を変更した後も、古い接続や応答が結果に影響する場合があるため、Webページを一度更新しただけで変更が無効だと判断しないでください。キャッシュを消す目的でサブスクリプションを何度も更新するのも避けましょう。更新によってサーバーや設定も変わり、条件をそろえた比較ができなくなることがあります。

1. 変更を1項目保存：現在有効なConfigが切り替わっていないことを確認し、DNSまたはルールの変更前後の値を記録します。
2. 接続を再確立：一時的に接続が切れても問題ないことを確認してから、Homeの接続スイッチを一度オフにし、再びオンにします。Settings → On Demandによる自動再接続にも注意してください。
3. リクエストを再実行：問題のページを閉じて開き直し、必要に応じてブラウザーも終了して再起動します。プライベートブラウズは一部のサイトデータの影響を調べるのに役立ちますが、システムDNSのキャッシュが消えるとは限りません。
4. 同じ対象を再テスト：同じドメイン、ネットワーク、Global Routingの選択肢を使い、エラーの種類が変わったか比較します。通常は問題なく開くサイトも引き続き正常に表示されるか確認してください。
5. 変更を維持するか元に戻す：結果を再現できる場合に限り変更を維持します。改善しなければ元の値に戻して次の項目を確認し、未検証の変更を重ねないでください。

7. DNSのトラブル対処でよくある質問

詳しくはルールマニュアルで適用順を確認するか、接続に関する説明で名前解決と通信経路の問題を切り分けてください。当サイトでは接続先やサブスクリプションの提供・販売・推奨は行っていません。アカウントの状態やサーバー設定については、ご利用中のサービス提供元にお問い合わせください。