ShadowrocketのDNSエラー対処法｜遅延テストは正常なのにWebページが開けないとき | Shadowrocket 公式サイト

この記事の要点

遅延テストに数値が表示されても、対象ドメインが名前解決できたことやWebページへの接続成功を示すわけではありません。Shadowrocketをインストール済みで、利用中のサービス事業者とサブスクリプションがある方を対象に、DNS、ルール、外向き接続を分けて確認します。同じURL・同じネットワークで一つずつ再テストし、変更は一度に一項目に絞って、元に戻せる設定の控えを残しましょう。

1. 遅延・DNS・Web接続を切り分ける

Shadowrocketの遅延テストで数値が表示されるのは、そのテストで対象となった宛先と方法で結果が得られたということです。サーバーアドレスへの到達、ドメインの名前解決、プロキシ認証、Webサイトからの応答は、それぞれ別の段階です。遅延の数値だけでアクセス経路全体が正常だと判断することはできません。

ドメインの名前解決ルール判定外向き接続 TLSハンドシェイク Webページの応答

この流れは問題の段階を切り分けるためのもので、すべてのリクエストが必ずローカルで名前解決されるという意味ではありません。ドメインルールはドメイン名に直接一致させられ、一部のプロキシ経路では宛先ドメインの処理をリモート側に委ねます。IPを扱うルール、サーバー自体のドメイン名、直接接続のリクエストでは、それぞれに応じた名前解決が必要になる場合があります。

Homeで接続がオンになっていることを確認し、現在のGlobal Routingの値を確認します。次に、普段アクセスできるHTTPSページと問題のページを開きます。完全なドメイン名、ネットワークの種類、テスト時刻、エラー内容を記録してください。特定のドメインだけで失敗する場合は、そのドメインと該当ルールから確認し、すぐにDNS設定全体を入れ替えないでください。

サーバーが見つからないという表示：ドメインの入力ミス、DNS応答、Hostの上書きを確認します。
ページの読み込みが長時間続いてタイムアウトする場合：名前解決のタイムアウトだけでなく、接続や外向き経路のタイムアウトも考えられます。ログとあわせて判断してください。
証明書エラーが表示される場合：リクエストはTLSの確認段階まで進んでいます。DNSだけが原因とは限らないため、デバイスの時刻、証明書、接続先アドレスも確認します。
HTTP 403または503が返る場合：HTTP応答は受信できています。DNSを繰り返し変更するのではなく、アクセス制限やWebサイトの状態を先に確認してください。

2. DNS設定とポートの意味

DNSはドメイン名をネットワーク接続に必要なアドレスへ変換します。AレコードはIPv4、AAAAレコードはIPv6に対応します。AAAAレコードが返っても、現在のネットワークに利用可能なIPv6の外向き経路があるとは限りません。一方、ドメインにAレコードしかないからといって、名前解決に異常があるわけでもありません。

従来のDNS：通常はUDPを使用し、TCPを使う場合もあります

443

DoH：HTTPSによる問い合わせで一般的に使われるポート

853

DoT：TLSによる問い合わせのデフォルトポート

ポートは通信方式を示すもので、到達できることを保証するものではありません。現在のネットワークから特定のリゾルバーに接続できない場合があります。ドメイン名を含む暗号化DNSアドレスでは、リゾルバー自身のドメインをどう名前解決するかも関係します。通常のDNSのIPアドレスを任意のHTTPSアドレスとして入力したり、DNS問い合わせ用のポートをプロキシサーバーのポート欄に入力したりしないでください。

確認項目	役割	確認方法
`dns-server`	設定ファイル内のDNSサーバー設定です。	Configで現在の設定を開き、Generalに該当項目があるか確認します。あわせてSettings → DNSの設定も確認してください。
`system`	システムが提供するリゾルバーを使用します。	現在のWi-Fiまたはモバイル通信で再テストします。ネットワークを切り替えると、名前解決の条件も変わります。
`Host`	指定したドメインに固定のアドレスを割り当てられます。	問題のドメインが古いアドレスに割り当てられていないか確認します。固定割り当てを最新のDNS応答と混同しないようにしてください。
A / AAAA	IPv4 / IPv6のアドレスをそれぞれ返します。	「名前解決の結果がある」ことと「そのアドレスに接続できる」ことを分けて確認します。

Settingsの全体設定とConfig内の設定が同時に動作へ影響する場合があります。確認時は、現在有効な設定と実際のログを基準にしてください。画面に保存されている値だけで、設定が適用中かどうかを判断しないでください。画面構成が変わった場合は、DNS、Config、Generalなどの英語表記を目印に探します。

3. 複数の条件を同時に変えず、順番に再テストする

現在の設定を複製して保存し、元のGlobal Routing、DNS、サーバー選択を記録してください。以下の各手順では、同じ問題のURLを使います。ページが開けるようになったら、もう一度アクセスしてログを確認し、そのうえで変更を残すか判断します。

基本ネットワークを確認します。Shadowrocketの接続を一時的にオフにし、普段問題なく開けるページにアクセスします。Wi-Fiでログインが必要な場合は、先にネットワークへのログインを済ませてください。その後、接続を戻します。基本ネットワーク自体が使えない場合、設定を変えても上流側の通信障害は解消できません。
現在のサーバーを確認します。Homeに戻り、選択中のサーバーが自分の有効なサブスクリプションに含まれていることを確認します。遅延テストが正常でも、認証、通信、リモート側の外向き接続に問題がある場合は、利用中のサービス事業者に接続パラメーターとサービス状態を確認してください。
ルーティングの状態を確認します。Home → Global Routingを開き、現在の設定がConfig、Proxy、Direct、Sceneのどれかを記録します。Sceneを使っている場合は、そのSceneで実際に適用される設定を確認し、Sceneの切り替えをDNSの変更と混同しないようにしてください。
有効なDNS設定を確認します。Settings → DNSを確認し、Configで現在使用中の設定を開いて、GeneralのDNS設定とHostのマッピングを確認します。一度に変更するのは一項目だけにし、変更後は再接続してテストしてください。
ネットワークを切り替えて比較します。モバイルデータ通信を利用できる場合は、設定とURLを変えずにWi-Fiからモバイル通信へ切り替えます。一方のネットワークだけで失敗する場合は、そのネットワークでのリゾルバーへの到達性、ネットワークログイン、外向き通信の制限を優先して確認します。
自動接続を確認します。接続をオフにしても自動的にオンへ戻る場合は、Settings → On Demandを確認してください。切り分け中は該当する条件を記録して一時的に調整し、終了後に元のオンデマンド接続設定へ戻します。

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

Configは現在の設定にあるルールに従って通信を振り分けます。ProxyとDirectは全体のルーティング状態を比較するために使い、Sceneは設定済みのシーンに従って動作します。一時的な切り替えは恒久的な解決策ではありません。問題の範囲を絞るために使い、再テスト後は普段の設定に戻してください。

比較結果	考えられること	次の確認
Configでは失敗し、Proxyでは成功	ルールで指定された経路や関連するDNSの動作を確認する必要があります。これだけでリゾルバーの故障とは断定できません。	問題のドメインに一致するルールとポリシーを調べ、Directなど指定された経路を通っていないか確認します。
Directでは成功し、Proxyでは失敗	プロキシ経路で認証、接続、リモート側の名前解決に問題がある可能性があります。	現在のサーバーパラメーターを確認し、名前解決と接続のどちらの段階で失敗したかログを調べます。
3つの状態すべてで失敗	共通する原因として、基本ネットワーク、ドメイン自体、または共通で使われているDNS設定が考えられます。	別のネットワークで比較し、ドメイン名とHostのマッピングも確認します。
特定のドメインだけで失敗	問題の範囲は限定的であり、すべてのDNSリクエストが失敗しているとは限りません。	そのドメインのルール、名前解決の応答、Webサイトの状態を確認します。

DOMAIN-SUFFIXはドメインのサフィックスで一致し、IP-CIDRはアドレスのネットワーク範囲で一致します。GEOIPはIPアドレスの地理的な分類で一致し、FINALは最後に適用されるフォールバックルールです。ルールは記載順に判定され、一致したルールに対応するポリシーが使われます。以下は構文の例であり、普段の設定をそのまま置き換えるためのルールではありません。

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

example.comと192.0.2.0/24は構文説明用の例です。例にあるno-resolveは、そのIPルールへの一致判定のためにドメインの名前解決を積極的に行わないという意味であり、以降の接続でも名前解決が不要になるという意味ではありません。IPルールを削除したり、全体をProxyに変更したりすると経路は変わる可能性がありますが、壊れたドメインレコードが自動で修復されるわけではありません。

結論：一致した経路を特定してからDNSを変更する

同じドメインがProxyでは開けてConfigでは開けない場合、まずConfig内のルールとポリシーを確認します。名前解決のタイムアウト、有効なアドレスがない、誤ったマッピングがあると確認できた場合に限り、該当するDNS設定を変更してください。ルーティングの変更で元の問題を覆い隠さないようにしましょう。

5. エラーの原文から名前解決と接続の失敗を見分ける

ブラウザーの表示、アプリのログ、システムエラーでは、異なる文言が使われることがあります。以下はブラウザーやAppleのネットワークエラー記録に表示される可能性がある原文とコードで、Shadowrocketが常に出力する固定の文面ではありません。どこに表示されたエラーかを記録し、同じ時刻の前後に名前解決済みのアドレスがあるか確認してください。

エラー：ERR_NAME_NOT_RESOLVED

原因：ブラウザーが対象ドメインの有効な名前解決結果を取得できていません。

対処：まずドメイン名の入力ミスを確認し、現在のDNSとHostのマッピングを調べます。ルーティング設定は変えずに、ネットワークを切り替えて同じドメインを再テストしてください。

エラー：NSURLErrorDomain Code=-1003

原因：AppleのURL読み込みエラーで「cannot find host」と表示される場合、指定したホストが見つからないことを示します。

対処：失敗しているのがWebサイトのドメインかサーバーのドメインかを切り分け、該当する名前解決設定を確認します。NXDOMAINが繰り返し明確に記録される場合は、待ち時間を延ばすだけでなく、ドメインの有効性を確認してください。

エラー：NSURLErrorDomain Code=-1001

原因：リクエストがタイムアウトしています。このコードだけではDNSの段階でタイムアウトしたかどうかは判断できません。

対処：タイムアウト直前にアドレスや接続の記録があるか確認してください。アドレスが記録されている場合は外向きの到達性を優先して調べ、名前解決結果がない場合はリゾルバーへの経路を確認します。

NXDOMAINは、リゾルバーが「その名前は存在しない」と応答したことを示します。応答がない場合は別の状態であり、パケット損失、リゾルバーへの到達不能、応答待ちのタイムアウトなどが考えられます。どちらも「DNSがブロックされた」とまとめないでください。アドレスがあるのに接続できない場合は、IPv6経路、プロキシのパラメーター、接続先ポートも確認します。HTTPSで一般的なポートは443ですが、サーバー側で使用するポートは、利用中のサービスの設定値を確認してください。

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

遅延テストは正常なのに、Webページが開けないのはなぜですか？

遅延テストとWebページへのリクエストでは、確認する通信段階が異なります。Homeで選択中のサーバーとGlobal Routingを記録し、ブラウザーから実際に問題が起きているドメインへアクセスします。名前解決の結果、一致したポリシー、接続エラーをそれぞれ確認し、遅延テストだけを繰り返さないでください。

DNSを変更しても解決しません。さらに変更すべきですか？

まず、変更した設定が現在有効か確認します。Config → 現在の設定 → Generalと、Settings → DNSを確認し、再接続してから試してください。ログにアドレスが記録されていて接続段階で失敗している場合は、リゾルバーをむやみに変更せず、外向き経路を調べます。

Wi-Fiだけで失敗し、モバイル通信では正常な場合はどうすればよいですか？

設定とサーバーを同じままにして、Wi-Fiでネットワークへのログインが完了しているか、使用中のリゾルバーにそのネットワークから接続できるか確認してください。systemを使用している場合、システムDNSはネットワークに応じて変わるため、2つのネットワークで名前解決の条件は同じではありません。

サブスクリプションを更新するとDNSの問題は直りますか？

通常、サブスクリプションの更新はサーバー項目を更新するもので、ローカルのDNS設定が修復されたことを意味しません。利用中のサービス事業者からサーバーアドレスや接続パラメーターの変更を確認できた場合に限り、案内に従って既存のサブスクリプションを更新し、現在選択中の項目をあらためて確認してください。

ページが開けるようになったら、Global Routingを元の状態に戻し、必要なOn Demandの条件も復元してから、問題のページとよく使うページをテストします。変更前後のログを比較し、一時的なネットワークやルールの切り替えが解決の理由ではないことを確認してください。ブラウザーのリクエストをやり直すには、問題のタブを閉じて開き直せます。ただし、これはシステムのDNSキャッシュをすべて消去する操作ではありません。

最終的に残す変更について、設定項目、変更前の値、変更後の値、確認に使ったURLを記録します。
現在のConfigが想定した設定であり、テスト用に残した固定マッピングがHostにないことを確認します。
普段のルールが想定どおりに通信を振り分けており、一時的な比較用の状態のままになっていないことを確認します。
解決しない場合は、機密情報を削除したログとネットワーク比較の結果を添えて、利用中のサービス事業者に確認してください。その他の手順はトラブルシューティングをご覧ください。