Shadowrocketの遅延は正常なのにWebページが開かない：DNS名前解決エラーの確認手順

1. 遅延が正常でもWebページに接続できるとは限らない

まず、遅延がどのテストで測定されたものか確認してください。サーバーのポートへの接続テストと、Webページへのリクエストでは、確認できる通信経路が異なります。サーバーアドレスがIPアドレスなら、そのサーバーのドメイン名を解決せずにテストできる場合もあります。一方、ブラウザでWebサイトを開くには、接続先ドメインのIPアドレスを取得してから接続する必要があります。そのため、Homeに遅延が表示されていても、DNSの問題がないとは言い切れません。

ページの読み込みが終わらない原因は、DNSエラーだけではありません。名前解決に成功していても、その後の接続が遮断される、接続先サーバーが応答しない、TLSハンドシェイクに失敗するといった理由でページが開かないことがあります。まずエラーメッセージと発生した段階を記録し、DNSを変更する必要があるか判断してください。すべての接続エラーを同じ設定項目の問題と決めつけないようにしましょう。

ポート番号は通信方式の違いを理解するためのものです。現在のネットワークで必ず接続できることや、サーバーポートをこの番号に変更すべきことを示すものではありません。プロキシサーバーのポートとDNSサービスのポートは別の設定項目です。前者は、利用中のサービス設定と一致させる必要があります。

2. 再現可能な確認の基準を作る

最初からサーバー、DNS、ルールを同時に変更しないでください。問題が起きるURLを一つ決め、現在のネットワーク、選択中のサーバー、Global Routing、使用中の設定を記録します。比較には完全なドメイン名を使い、DNSの確認のためにHTTPS URLのドメイン名をIPアドレスに置き換えないでください。証明書の検証、SNI、Webサイトのバーチャルホスト選択が変わるため、結果を直接比較できなくなります。

1. 現在の状態を記録

   Homeで選択中のサーバーと接続状態を記録し、Home → Global Routingを開いて現在の選択肢を控えます。Configでは使用中の設定を記録し、変更前に元に戻せるコピーを保存してください。

2. ネットワークの基本状態を確認

   一時的に接続を切り、現在のネットワークで通常アクセスできるWebサイトを開いてください。公衆Wi-FiでWeb認証が必要な場合は、先に認証を済ませます。接続を切ってもサイトが開かない場合は、まずWi-Fiまたはモバイル通信自体を確認してください。

3. テスト条件を固定

   再接続し、Home → Global Routingで一時的にProxyを選択します。同じサーバーを使って、問題のドメインに再度アクセスしてください。この手順はConfigとの比較に使うもので、最終的な設定を推奨するものではありません。

4. ネットワークを切り替えて再テスト

   サーバーと設定はそのままにして、Wi-Fiとモバイル通信で一度ずつ比較します。一方のネットワークだけで失敗する場合は、そのネットワークでのDNSリクエストと接続エラーを記録し、すぐに設定を上書きしないでください。

5. 元の設定に戻す

   比較が終わったら、Global Routingを元の設定に戻します。接続を切った後に自動で再接続する場合は、Settings → On Demandで有効な条件を確認し、該当する条件を一時的に無効にしてから切断テストを行ってください。

3. 実際に適用されているDNS設定を確認

Configを開き、現在有効な設定を確認してから、そのDNS設定を確認します。無効なファイルを変更しても、現在の接続には反映されません。リモート設定の更新でローカルの変更が上書きされることもあります。まずコピーを保存し、変更後に再接続して、同じドメインで再テストしてください。Homeのサーバーサブスクリプションを更新しても、ConfigのDNS設定まで同期して変更されたとは限りません。

以下は設定構文の例であり、どの環境にも使える修正方法ではありません。システムのDNSを使用する例で、条件をそろえた比較のために一つの項目だけを変えています。現在のネットワークでシステムDNSに問題がある場合は、この設定でも失敗することがあります。既存設定の該当項目だけを変更し、テストのために他のルール、ポリシー、サーバー設定を削除しないでください。

[General]
dns-server = system

DoHを使う場合は、エンドポイントの名前解決が先に必要となる点も確認してください。DoHエンドポイントがドメイン名で指定されている場合、HTTPS接続の確立前にそのアドレスを取得する必要があります。エンドポイントに接続できない、証明書の検証に失敗する、またはエンドポイントのドメイン名を解決できない場合、接続先Webサイトの名前解決も止まることがあります。暗号化によって変わるのはDNSクエリの転送方法です。エンドポイントへの接続が保証されるわけではなく、現在のネットワークの確認に代わるものでもありません。

4. ルールの適用と名前解決結果を分けて確認

Global RoutingのDirect、Proxy、Config、Sceneは、4種類のDNSプロトコルではありません。DirectとProxyは異なる通信処理方法を指定し、Configは使用中の設定に従って処理します。Sceneでは選択中のシーンの設定を確認してください。確認中にシーンとDNS設定を同時に変更すると、同じURLでも前後で通信経路が変わる可能性があります。

Configでは、ルールの順序も確認してください。ドメインルールとIPルールでは判定対象が異なり、IPベースの照合では接続先ドメインの名前解決が必要になる場合があります。ログにアドレスが記録されていて、リクエストに適切でないポリシーが適用されている場合、DNSを変更しても解決しないことがあります。以下の予約ドメインと文書用アドレスは構文の説明に使うもので、接続先サービスではありません。

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

• DOMAIN-SUFFIXはドメインのサフィックスを確認します。前にある広範なルールがすでに適用されている場合、後続のルールはこのリクエストには適用されません。
• IP-CIDRはアドレスのネットワーク範囲を確認します。例のno-resolveは、このルールのためにドメイン名の名前解決を積極的に実行しないという意味で、アプリ全体のDNSを無効にする設定ではありません。
• GEOIPはIPアドレスの地理情報で照合します。ドメインの言語やWebサイト名だけで、ルールが適用されるかどうかを判断することはできません。
• FINALは、それ以前のルールに一致しなかった場合に使う最終ポリシーです。設定ファイルにこのキーワードがあるかだけでなく、実際にどのポリシーを指定しているか確認してください。

AレコードとAAAAレコードも区別してください。前者はIPv4アドレス、後者はIPv6アドレスを返します。名前解決に成功していても、特定のアドレスファミリーを使った場合だけ接続できないなら、アドレスへの到達性に関する手がかりです。DNSの応答とその後の接続結果を記録してから対処してください。AAAAレコードがあること自体を障害とみなしたり、IPv6、DNS、ルールを同時に変更したりしないでください。

5. エラーメッセージに応じて次の確認項目を判断

以下はAppleのネットワークエラー領域で使われるエラー識別子です。エラー詳細や診断情報に同じ文言が表示された場合の判断材料としてお使いください。Shadowrocketが毎回これらの文言を表示するという意味ではありません。ブラウザには日本語のメッセージだけが表示されることもあります。実際に表示された内容を省略せず記録し、「開かない」という状況だけで原因を決めつけないでください。

特定のWebサイトだけ開かず、ほかのドメインには安定してアクセスできる場合は、そのドメインと関連リソースのドメインを個別に記録してください。Webページ本体、画像、スクリプトが別々のドメインから読み込まれることがあります。ページ本体が表示されても画像の読み込みが続く場合、メインドメインの名前解決に失敗しているとは限りません。DNS全体を変更するより、読み込めないリソースのドメインに適用されるルールを確認するほうが原因を特定しやすくなります。

• ネットワークの種類、Global Routing、使用中の設定、エラーが発生した接続先ドメインを記録します。
• 「名前解決結果を取得できない」状態と、「IPアドレスは取得できたが接続がタイムアウトする」状態を区別し、該当するエラーメッセージを保存します。
• 診断情報を共有する前に、サブスクリプションのtoken、パスワード、UUID、個人のネットワークアドレスをマスキングしてください。原因の特定に必要な部分だけを共有します。

6. よくある質問と修正後の確認

修正後は一時的なProxyテストの状態ではなく、元の利用条件に戻して確認します。必要なGlobal RoutingとOn Demandの条件を復元して再接続し、最初に開けなかったWebサイトと比較用のWebサイトを開いてください。ページ本体と必要なリソースが読み込まれること、ネットワークを一時的に切り替えなくても復旧することを確認します。

1. 最終的に使用するDNSと設定のコピーを保存し、根拠のない一時変更は元に戻してください。
2. 普段利用するネットワークで再テストします。Wi-Fiとモバイル通信を切り替えて確認する場合は、それぞれの結果を記録してください。
3. 問題が再現する場合は、機密情報を伏せたエラーメッセージ、接続先ドメイン、適用されたルールの情報を用意して、原因の確認を続けてください。同じサブスクリプションを何度も読み込み直す方法では解決しません。