ShadowrocketのDNSエラーを解決する方法｜遅延テストは正常なのにWebサイトが開けない場合

遅延テストが正常でも、確認できるのはテスト先の応答だけ

Shadowrocketの遅延テストと、ブラウザでWebサイトを開く操作は別のものです。テスト方法によって確認できる範囲も異なります。接続先のポートから応答があっても、プロキシ認証、対象ドメインの名前解決、TLSハンドシェイク、Webページのリソース読み込みが成功したとは限りません。HTTPリクエストを含むテストでも、そのテスト先にその時点で接続できたことを示すだけで、実際に開けないWebサイトの確認にはなりません。

この流れはアクセスに必要な主な段階を示したもので、すべてのプロトコルが必ずこの順序で動作するわけではありません。プロキシサーバーのアドレスにドメイン名を使う場合は、その名前も先に解決する必要があります。また、接続先Webサイトのドメイン名をリモート側で解決する場合もあります。まず「サーバーのアドレス」と「Webサイトのアドレス」のどちらで問題が起きているかを切り分けてから、変更箇所を判断してください。

• すべてのWebサイトが開けない：接続が確立しているか、プロキシサーバーのアドレスを解決できるか、現在のネットワークでWeb認証が必要かを確認します。
• 特定のドメインだけ開けない：完全なホスト名を記録し、入力ミス、DNSの応答状態、そのドメインに適用されるルールを確認します。
• ページの文字は表示されるが画像が出ない：画像などのリソースが使う別のドメインも確認します。アドレスバーに表示されたドメインだけでは不十分です。

状況を記録してから、条件を一つだけ変えて比較する

調査中は元の設定を残し、サーバー、DNS、ルールを同時に変更しないでください。以下ではiPhoneを例に説明しますが、iPadでも同じ考え方で確認できます。テストには、ユーザー自身が用意したサーバーとサブスクリプションを使用してください。サブスクリプションを更新できても、配信元のアドレスを読み取れたことを示すだけで、個々のサーバーやすべてのWebサイトに接続できるとは限りません。

1. Homeで選択中のサーバー、接続スイッチの状態、Global Routingの選択内容を記録します。Configでは、現在有効になっている構成ファイルを確認します。
2. 開けないURLのホスト名、発生時刻、Wi-Fiかモバイル通信か、ブラウザに表示されたメッセージを記録します。記録を共有する前に、サブスクリプションのURL、パスワード、トークンを隠してください。
3. 接続をオフにし、現在のローカルネットワークから通常直接アクセスできるWebサイトを試します。それでも開けない場合は、ローカルネットワークやWeb認証を先に確認してください。
4. 同じサーバーとWebサイトを使って再接続し、もう一度アクセスします。設定を変更するたびに古いタブを閉じ、新しいタブで試して、既存の接続による影響を減らします。
5. 必要に応じてWi-Fiとモバイル通信を一度比較しますが、DNSは同時に変更しないでください。ネットワークを切り替えたときの違いから、ローカルルーターや通信事業者のネットワークの影響を判断できます。

DNS設定ごとの役割

Settings → DNSでアプリのDNS設定を確認し、Configで現在の構成にある[General]を確認します。構成によっては、DNSサーバー、名前解決の方針、ドメインごとの指定結果が同時に関係します。実際に有効な構成を確認してください。入力欄にアドレスがあるだけで、すべてのリクエストがそのアドレスを使うとは限りません。

たとえば、構成ファイルの次の1行はシステムDNSを使う設定を示します。これは構文の例であり、既存の設定を置き換えるための完全なファイルではありません。変更前に元の値を保存してください。ユーザー自身が利用するサービス事業者から提供された構成の場合は、DNSに関する設定内容を確認してから、一部だけを変更してテストします。

[General]
dns-server = system

応答状態からDNSエラーを3種類に切り分ける

ブラウザの「サーバーが見つかりません」という表示だけでは、原因を特定できないことがほとんどです。利用できる接続ログや診断結果がある場合は、DNSの応答状態、クエリしたドメイン名、タイムアウトの情報を確認してください。以下は一般的なDNSの状態や診断用語です。Shadowrocketのすべての画面に、これらの文言がそのまま表示されるという意味ではありません。

「AAAAレコードがない」状態と「ドメイン名が存在しない」状態は区別してください。AAAAはIPv6アドレス、AはIPv4アドレスに対応します。ドメインにAレコードしかなくても、必ずしも問題ではありません。アドレスが返されているのに、その後の接続が止まる場合は、DNSを繰り返し変更せず、アドレスファミリーの到達性、ルーティング、TLSを確認します。

• A、AAAA、その他のどのタイプを照会したか記録し、異なるクエリ結果をそのまま比較しないようにします。
• プライベートアドレスや想定と異なるアドレスが返された場合は、アドレスの見た目だけで判断せず、ローカルネットワークの用途と静的マッピングを確認します。
• 「HTTPSのURLをIPアドレスに置き換える」方法だけで検証しないでください。証明書、SNI、仮想ホストが元のドメイン名に依存している場合があります。

Global RoutingでDNSの問題とルールの問題を切り分ける

Home → Global Routingで、Configは現在の構成に従って通信を処理し、Proxyは対象の通信をプロキシ経由にし、Directは対象の通信を直接接続します。モードを切り替えると原因の特定に役立つことがありますが、DNSだけを切り替える操作ではありません。接続先への経路やリモートで名前解決される可能性なども変わる場合があります。

1. まずConfigの状態で障害を再現し、ドメイン名と適用されたルールまたはポリシーを記録します。
2. 同じサーバーを使ったまま、一時的にProxyへ切り替えて同じドメインにアクセスします。開けるようになった場合は、Configの振り分けルールと選択中のポリシーを優先して確認します。ただし、これだけでDNSが正常だとは断定できません。
3. 現在のローカルネットワークから通常直接アクセスできる接続先は、一時的にDirectで比較できます。接続先自体にローカルネットワークからアクセスできない場合、Directで失敗してもDNS設定に問題があるとは限りません。
4. 比較が終わったら元のモードに戻します。Sceneを使用している場合は、現在のシーンで実際にどの接続動作が選ばれているかを確認し、シーンの変化が比較に影響しないようにします。

以下はルール構文の例です。example.comは例示用のドメインで、診断サービスではありません。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの地理情報、FINALは前のルールに一致しなかったリクエストに適用されます。ルールは上から順に確認されます。アドレス関連のルールでは名前解決の結果も関係する場合があるため、最後の行だけを見て判断しないでください。

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

no-resolveは、該当するアドレスルールとの照合のために追加のドメイン名前解決が行われるのを防ぐ指定です。「すべてのDNSの問題を修復する」設定ではありません。ドメインが前のルールによって利用できない経路に送られている場合、DNSだけを変更しても結果は変わらないことがあります。まず適用されたルールを確認し、そのルールのポリシーや順序を調整してください。

よくある質問：キャッシュ、サブスクリプション、接続の復旧

復旧後は同じ条件で再テストする

Webページを一度開けただけでは、そのときに成功したことしか分かりません。復旧後は、最初に失敗したネットワーク、元の対象ドメイン、普段使うモードで再テストし、ページ内の関連リソースもすべて読み込まれるか確認します。トラブル対応では、変更した設定の数ではなく「どの条件を変えたら復旧したか」を記録することが重要です。

• 動作設定を元に戻す：一時的に切り替えたGlobal Routingを元に戻し、必要に応じてSettings → On Demandも元の設定に戻します。
• 構成を確認する：Configで正しいファイルが有効になっていることを確認し、テストのために追加した静的マッピングや一時ルールが不要になった場合は削除します。
• 調査記録を残す：ネットワークの種類、失敗したドメイン名、DNSの応答状態、変更内容、再テストの結果を記録します。利用中のサービス事業者に共有するときは、認証情報を隠してください。
• 次に調べる箇所を見極める：正しいアドレスが返され、DNSも正常に応答しているのに接続できない場合は、サーバーの稼働状況、接続先ポート、TLSを確認します。すべての障害を名前解決のせいにしないでください。