ShadowrocketのDNS設定とトラブルシューティング｜遅延テストは正常なのにWebページが開けない場合

この記事の概要

この記事では、Shadowrocketに利用中のサービスを追加済みで、接続スイッチも正常なのに、ドメインにアクセスできない場合を扱います。サーバーへの接続、Global Routing、DNS、ルール、ネットワーク環境の順に確認し、設定を一つずつ変えて、名前解決・接続・Webサイト自体のどこに問題があるかを切り分けます。設定例はトラブルシューティングの説明用であり、サーバーやサブスクリプションを提供するものではありません。

1. 遅延が正常でもWebページを開けるとは限らない理由

遅延テストで確認できるのは、そのテスト方法が対象とする通信経路だけです。サーバーのポートに接続できるかを調べるテストでは、対象ドメインの名前解決や、サーバーからWebサイトまでの接続が正常かどうかは分かりません。HTTPテストの場合も、結果はテスト先とその時点の経路に限られ、実際に開けないWebサイトの状態を示すものではありません。

ブラウザでHTTPSサイトを開くには、通常、ドメインの名前解決、接続先への接続、TLSネゴシエーション、HTTPリクエストの順に処理が進みます。DNSはドメインに対応するアドレスを返す仕組みであり、期限切れのサーバー認証情報を修復したり、Webサイト側のアクセス制限を解消したりするものではありません。「接続正常」と表示されても、リクエストがどの段階で止まっているかを確認してください。

確認できた現象	分かること	次に確認する項目
サーバーの遅延テストで結果が表示される	テスト対象の経路が応答している	対象ドメインの名前解決と実際のリクエスト
ドメインの検索でAまたはAAAAが返る	IPv4またはIPv6アドレスを取得できた	アドレスに到達できるか、TLS接続が成功するか
WebページでHTTP 403が返る	応答可能なHTTPサービスまでリクエストが届いている	Webサイトのアクセス方針と接続元の制限
特定のWebサイトだけ開けない	問題がそのドメインまたはパスに限られる可能性がある	該当するルール、名前解決結果、Webサイトの状態

結論：まず、どの段階で失敗しているかを特定する

開けないドメインとエラーの原文を記録してください。HTTPステータスコードが表示されている場合は、まずWebサイトからの応答を確認し、DNSの変更を最初の手段にしないでください。

2. 再現可能な確認環境を整える

確認を始める前に、Configで現在の設定をバックアップし、Homeで選択中のサーバーとGlobal Routingの状態を記録します。利用中のサブスクリプションを更新した直後なら、サーバーアドレス、ポート、認証情報に変更がないかも確認してください。サブスクリプションの更新に成功しても、取得リクエストが完了したことを示すだけで、各サービスが利用できるとは限りません。

開けないドメインを記録する

開けないドメインと、通常アクセスできるドメインを一つずつ選び、エラー全文、発生時刻、使用中のWi-Fiまたはモバイル通信を記録します。その後のテストでは同じページにアクセスし、対象を変えたことによる誤判定を防ぎます。
サーバーを確認する

Homeで選択中のサーバーを確認し、利用可能な遅延テストまたは接続テストを実行します。サーバー自体に接続できない場合は、利用中サービスの情報を参照してアドレス、ポート、認証情報を確認してください。DNS設定の試行に進む必要はありません。
ルーティングモードを記録する

Home → Global Routingを開き、Proxy、Direct、Config、Sceneのどれが選択されているか記録します。確認中はモードを固定してください。Sceneを使っている場合は、実際に適用中のSceneを確認し、ネットワークの切り替えと同時にルーティング動作が変わらないようにします。
自動再接続を確認する

Settings → On Demandを確認します。接続のオン・オフで違いを比較する場合は、まず現在の設定を記録し、一時的に自動接続を無効にしてください。接続を切った直後に再接続されるのを防げます。確認後は元の状態に戻します。
設定を一つずつ変更して再テストする

一度に変更する設定は一つだけにし、保存後に接続を確立し直して、同じドメインで再テストします。結果を記録してから変更を維持するか元に戻すか判断してください。サーバー、DNS、設定全体を同時に変更しないでください。

3. DNS設定ではシステムの名前解決と設定による上書きを区別する

Configで現在使用中の設定を開き、編集画面で[General]にdns-serverが設定されているか確認します。無効な別の設定だけを確認しないようにしてください。ほかにもDNS関連の設定がある場合は、変更した項目が別の有効な設定で上書きされないよう、併せて記録します。

systemは、システムが提供するDNSを使用する設定です。比較の基準として使えますが、どのネットワークでも同じ結果になるわけではありません。Wi-Fi、モバイル通信、デバイスのDNS設定によって、システムの名前解決結果は変わることがあります。DNSサーバーを手動指定する場合は、アドレスが正しく入力されているかだけでなく、現在のネットワークからそのサーバーに到達できるかも確認してください。

# 関連する項目のみを示しています。この部分だけで設定全体を置き換えないでください。
[General]
dns-server = system

上記の例は、設定項目の位置を示すものです。実際にテストする際は、既存の[General]内にある該当行を変更し、ほかの設定はそのまま残してください。同じセクションや項目を重複して追加しないようにします。変更前の値を記録して保存し、接続を確立し直して再テストしてください。改善しない場合は元の値に戻してから、次の項目を確認します。

項目	意味	確認ポイント
A	ドメインに対応するIPv4アドレスのレコード	結果が返ったら、そのIPv4経路に到達できるか確認する
AAAA	ドメインに対応するIPv6アドレスのレコード	アドレスを取得できたことと、IPv6経路が実際に使えることを区別する
従来型DNS	通常はUDP 53を使用し、必要に応じてTCP 53を使用する	現在のネットワークで検索が制限されていないか、異常な結果が返っていないか
DNS over HTTPS	HTTPS経由でDNSクエリを送信する方式。通常はTCP 443を使用する	名前解決のエンドポイントに接続できるか、エンドポイントのドメインを最初にどう解決するか
DNSキャッシュ	有効期間中、以前の検索結果を再利用する	設定変更後も古い接続や古い結果を参照していないか

暗号化DNSはクエリの通信方式を保護するもので、あらゆる名前解決の問題を自動で解決するわけではありません。名前解決のエンドポイントに到達できない場合や、エンドポイントのドメインを最初に解決できない場合も、タイムアウトすることがあります。ブラウザなどのアプリが独自の名前解決方式を使う場合は、Shadowrocketの設定結果と異なる可能性もあります。テスト中は同じアプリを使ってください。

4. エラーから未登録・サーバーエラー・タイムアウトを見分ける

以下はDNSの診断でよく見られるステータスやエラー文字列です。Shadowrocketのすべての画面に同じ文字列が表示されるとは限りません。ブラウザには概要だけが表示されることもあります。確認できるログ、リクエスト記録、検索結果と照らし合わせて判断し、「Webページを開けない」という表示だけで原因を決めつけないでください。

エラー：NXDOMAIN

原因：問い合わせ先が、指定されたドメインは存在しないと応答しています。入力ミス、期限切れのドメイン、異常なDNS応答などが原因として考えられます。

対処方法：まずドメイン全体のつづりを確認し、別のネットワークでも比較します。一方の名前解決経路でのみ発生する場合は、両方の結果を記録し、使用中のDNSとローカル設定による上書きを確認してください。

エラー：SERVFAIL

原因：DNSリゾルバーが問い合わせを完了できませんでした。上位DNSへの問い合わせ失敗、ドメインの権威DNSの障害、検証上の問題などが考えられます。ドメインが存在しないことを意味するものではありません。

対処方法：ほかの正常なドメインにも同じ問題が起きるか確認します。ルーティングを変えずに、到達可能と確認できている別の名前解決方式に切り替えて再テストしてください。

エラー：connection timed out

原因：指定された処理が制限時間内に完了しませんでした。DNSの検索段階で発生したと確認できた場合に限り、名前解決のタイムアウトと判断できます。

対処方法：タイムアウトした対象がDNSリゾルバー、サーバー、接続先Webサイトのどれかを確認してから、該当するポートとネットワーク経路を調べます。WebサイトへのTCP接続タイムアウトをDNSの問題と取り違えないようにしてください。

AAAAレコードがないこと自体はエラーではありません。Aレコードのみを提供するドメインもあります。また、問い合わせに成功しても指定した種類のレコードが返らないケースは、NXDOMAINとは異なります。「IPアドレスがない」とだけ記録するのではなく、問い合わせた名前とレコードの種類、応答ステータスを記録してください。

5. 名前解決に成功したらGlobal Routingとルールを確認する

Global RoutingのProxy、Direct、Config、Sceneはルーティング方式であり、DNSサーバーの設定ではありません。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定、Sceneは現在のSceneに従って動作します。切り替えて比較することはできますが、いずれかのモードなら必ずローカルまたはリモートで名前解決がすべて行われる、と判断することはできません。

同じドメインがProxyでは開けてConfigでは失敗する場合、次にConfigで実際に適用されたルールを確認してください。Directでは開けてProxyでは失敗する場合は、サーバーから対象サイトまでの経路も確認します。どちらの状況だけでも、DNSに問題があるとは断定できません。

# ルールの構文と順序の説明用です。この部分だけで設定全体を置き換えないでください。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECTは、そのドメインとサブドメインに一致します。開けないドメインが、意図しないポリシーのルールに先に一致していないか確認してください。
IP-CIDRはアドレス範囲に一致します。例にある192.0.2.0/24はドキュメント用の例示ネットワークであり、実際のサービスアドレスではありません。
no-resolveは、そのIPルールとの照合のためにドメイン名を積極的に解決するのを避ける指定です。設定全体でDNSを無効にするものではなく、ほかの段階でリクエストがアドレスを取得するのを防ぐものでもありません。
GEOIPはIPアドレスの所属地域に基づいて照合します。ドメイン宛てのリクエストで名前解決が必要かどうかは、既存のアドレスとルールのパラメーターを踏まえて判断してください。
FINALは末尾に置き、それ以前のルールに一致しなかったリクエストを処理します。最後に適用されるポリシーが意図した経路を指しているか確認し、個別ドメインのルールだけで判断しないでください。

結論：アドレス取得後も失敗する場合は、実際に適用されたルールを確認する

DNSを変更せず、ProxyとConfigのアクセス結果だけを比較してください。差が安定して再現する場合は、ルールと選択された接続経路を優先して確認し、DNS設定をさらに重ねて変更しないでください。

6. Wi-Fi・モバイル通信・IPv6を比較する

同じ設定でWi-Fiでは失敗し、モバイル通信では成功する場合、ネットワーク環境が重要な要因だと分かります。ただし、Wi-FiのDNSに問題があるとは限りません。サーバーのポートが制限されている、IPv6の経路に問題がある、先にログイン認証が必要といった可能性もあります。ネットワークを切り替えたら接続を確立し直し、Global Routingとサーバーの選択がSceneによって変わっていないことも確認してください。

ネットワーク認証を先に完了する：公共Wi-Fiでログインが求められる場合は、Shadowrocketをテストする前に認証を済ませてください。認証前のリダイレクトや接続制限によって、複数のWebサイトにアクセスできないことがあります。
同じドメインで比較する：両方のネットワークから同じページにアクセスし、DNSの検索結果、接続のタイムアウト、HTTPステータスコードの有無を記録してください。遅延の数値だけを比較しないでください。
IPv6経路を確認する：ドメインからAAAAレコードが返っても、現在のネットワークでIPv6接続を利用できない場合、読み込みが止まったり、一部のリソースだけ失敗したりすることがあります。まず失敗したリクエストで実際に使われたアドレスファミリーを確認し、一時的な比較テストを行ってください。IPv6の無効化を一般的な解決策と見なさないでください。
キャッシュの影響を確認する：接続を確立し直して、テストページを再度開きます。アプリが独自のDNSキャッシュや接続プールを保持していることがあるため、必要に応じてアプリを終了して開き直してください。再接続しても、すべてのアプリのキャッシュが消えるとは限りません。

7. よくある質問と確認の終了条件

遅延がずっと正常なら、DNSを変更するだけでよいですか？

まずHomeでサーバーとGlobal Routingを確認し、開けないドメインのアドレスを取得できているか調べてください。HTTPエラーやTLSエラーが返っている場合は、それぞれの段階を確認します。DNSを主な原因として扱うのは、名前解決の段階で失敗している場合に限ります。

dns-serverを変更しても結果が変わらないのはなぜですか？

Configで、変更した設定が現在有効なものか確認し、同じ項目の重複やほかの有効な設定がないか調べてください。保存後に接続を確立し直し、テストアプリを開き直して、同じドメインで再テストします。アプリ独自のDNS設定とキャッシュにも注意してください。

一つのWebサイトだけ開けない場合、設定を作り直す必要がありますか？

まずドメインのつづり、名前解決結果、Configで実際に適用されたルールを確認し、ProxyとDirectの結果を比較してください。ほかの正常なWebサイトを比較対象として残し、特定のドメインだけの問題で設定全体を置き換えないでください。

サブスクリプションの更新に成功したのに、Webページが開けないのはなぜですか？

サブスクリプションの更新とWebサイトへのアクセスは別のリクエストです。Homeに戻って実際に選択中のサーバーを確認し、利用中サービスの情報を参照して設定値を確認してください。その後、この記事の順序に沿って対象ドメイン、ルーティング、DNSを調べます。更新に成功しても、接続が使えることの確認にはなりません。

確認を終える前に、最初に開けなかったドメインと正常な比較対象のドメインをそれぞれ再テストし、一時的に無効にしたOn Demandと元のScene設定を戻してください。改善の理由を説明できる最小限の変更だけを残し、効果のなかった試行は元に戻します。利用中サービスのサポート窓口に問い合わせる場合は、発生時刻、ネットワークの種類、関連するエラー、機密情報を伏せた設定の一部を伝えてください。サブスクリプションのトークン、パスワードなどの認証情報は削除してください。