2026年10月21日 · トラブル対処 · 約10分

ShadowrocketのDNS設定とトラブル対処｜遅延テストは正常なのにWebページが開かない原因

遅延テストとDNS名前解決の違いを解説。DNS設定の意味を確認し、名前解決エラーやページが読み込めない場合の対処を手順に沿って紹介します。

この記事の概要

Shadowrocketで遅延の数値が表示されても、その時点で該当のテストが完了したことを示すだけで、すべてのドメインを名前解決できることや、すべてのWebページに接続できることを保証するものではありません。すでに利用中のサービスを設定していて、Webページが読み込めない場合の確認手順を「接続状態の確認、失敗段階の特定、DNSの確認、ルールの確認、設定を戻して再検証」の順に説明します。作業前に現在の設定を保存し、一度に変更する項目は一つに絞って、名前解決の問題とプロキシの接続先の問題を混同しないようにしましょう。

1. 遅延テストが正常でも、Webページの読み込み成功とは限らない

Webページへのアクセスには、対象ドメインの処理、ルートの選択、接続の確立、アプリケーション層での通信が必要です。DNSはドメインに対応するアドレスなどのレコードを取得します。HTTPSページでは、さらに接続先とのTLSハンドシェイクが必要です。遅延テストはサーバーのポートだけを確認する場合もあれば、指定されたテスト用アドレスにリクエストする場合もあり、方法によって異なります。実際に開いているページや、その画像・スクリプト・ログイン用APIを一つずつ確認しているわけではありません。

ドメインの処理 ルートの選択 接続の確立 TLSハンドシェイク ページの読み込み

この流れは問題の切り分けに使うもので、すべてのリクエストでDNS名前解決を先に端末側で行うという意味ではありません。ドメインルールは対象IPの取得前に適用されることがあり、一部のプロキシプロトコルや設定ではドメインをリモート側に渡して処理できます。一方、IPベースのルールでは名前解決の結果が必要になる場合があります。「端末側での名前解決」「プロキシサーバーのアドレス解決」「接続先ドメインのリモート側での名前解決」を区別し、遅延の数値だけでDNSの問題をすべて除外しないでください。

2. 状態を記録して、同じ条件で再現テストを行う

まず、問題を安定して再現できる完全なURLを一つ選び、ネットワークの種類、発生時刻、エラーの原文を記録します。「どのページも開かない」とまとめず、具体的なURLを使ってください。サーバー、設定ファイル、DNSを同時に変更するのも避けます。以下ではiPhone / iPadのHome、Config、Settingsを基準に説明します。他のプラットフォームでは対応する機能を確認してください。システムのVPN表示はトンネルの状態を示すもので、リモートサービスが利用可能であることを保証しません。

  1. 現在の設定を保存

    Configで現在有効な設定を確認し、編集前にバックアップします。Homeで選択中のサーバー、Global Routingの状態、Settings → On Demandに設定済みの条件を記録し、元の設定は削除しないでください。

  2. 接続状態を確認

    Homeに戻り、接続スイッチを確認します。比較テストのために手動で接続を切る場合は、先にSettings → On Demandを確認してください。既存の条件によってシステムが接続を再確立すると、「接続を切った状態でのテスト」が意味をなさなくなることがあります。

  3. ルーティング設定を確認

    Home → Global Routingを確認します。Configは設定に基づいてルーティングし、Proxyはプロキシ経由の経路との比較に、Directは直接接続との比較に使います。Sceneは設定済みのシーンに従って動作します。テストでは使うモードを明確に選び、Sceneを固定のプロキシモードと考えないでください。

  4. 同じリクエストを再試行

    同じネットワーク、同じサーバーで同じURLに再度アクセスし、エラーが一致するか記録します。その後、Wi-Fiとモバイル通信だけを切り替えて再テストします。一方のネットワークだけで失敗する場合は、そのネットワークでのDNS到達性、ログイン認証、アクセス制限を優先して確認してください。

  5. 設定を元に戻す

    比較テストが終わったら、Global RoutingとOn Demandの条件を元に戻します。変更内容と結果を一つずつ記録してください。一時的にProxyで成功しても、元のConfigで発生しているルーティングの問題が解消したとは限りません。

3. DNSはアドレス、通信方式、名前解決の場所を分けて確認する

DNSを確認するときは、問い合わせ先、通信方式、問い合わせの通信経路の3点を確認します。DNSアドレスを入力しても分かるのは問い合わせ先だけで、現在のネットワークからそのアドレスに到達できるとは限りません。暗号化DNSでは、名前解決サービスへの接続も必要です。サービスのアドレスにドメイン名が使われている場合は、最初の名前解決に必要な経路も考慮してください。

53
従来のDNSで使用されるUDP / TCPポート
853
DNS over TLSで一般的に使用されるTCPポート
443
DNS over HTTPSで一般的に使用されるHTTPSポート
確認項目意味確認ポイント
System DNS現在システムが提供するDNS設定を使用します。通常は接続中のネットワークに依存します。同じ端末でも、ネットワークを切り替えると結果が変わる場合があります。Wi-Fiでの成功をモバイル通信でも同じとは考えないでください。
カスタムDNS名前解決サーバー、または対応する名前解決サービスのアドレスを明示的に指定します。形式と到達性を確認してください。IPアドレスのみを受け付ける欄に、HTTPSサービスのURLを入力しないでください。
DNS over HTTPSDNSクエリをHTTPSで送信します。サービスへの接続経路全体、TLS接続、名前解決サービス自身のドメインが解決できるかを確認します。ポートに接続できるだけでは、利用可能とは判断できません。
DNS over TLSDNSクエリをTLSで送信します。サービスのポート、証明書の検証、現在のネットワークで接続が許可されているかを確認します。
A / AAAAIPv4とIPv6のアドレスレコードにそれぞれ対応します。AAAAレコードがあっても、現在のIPv6ルートが利用できるとは限りません。接続結果とあわせて判断してください。

現在の設定がテキスト形式の[General]セクションを使っている場合は、dns-serverの設定を確認できます。以下はシステムDNSを使う例であり、あらゆる環境に適した「最適な設定」ではありません。条件を限定した比較にのみ使用してください。先にバックアップを取り、既存の項目を編集します。同じ名前の項目をファイル末尾に重複して追加したり、この項目がブラウザー独自のSecure DNSを上書きすると決めつけたりしないでください。

[General]
dns-server = system

4. エラーから名前解決、接続タイムアウト、証明書の問題を切り分ける

「開かない」という説明よりも、エラーの原文のほうが原因を特定しやすくなります。以下はブラウザーやネットワークツールに表示される可能性のある実際のエラーテキストです。Shadowrocket内で同じ名前のメニューを探すという意味ではなく、すべてのプラットフォームで同じ文言が表示されるとも限りません。エラーが出たら、発生箇所やログとあわせて判断してください。一つの単語だけを根拠に設定を変更しないでください。

エラー：ERR_NAME_NOT_RESOLVED

原因と対処：ブラウザーが有効な名前解決結果を取得できていません。まずドメインの入力ミスを確認し、システムの名前解決と現在の設定のDNSを比較します。ブラウザー独自のSecure DNS経路で問題が起きていないかも確認してください。

エラー：DNS_PROBE_FINISHED_NXDOMAIN

原因と対処：診断結果はドメインが存在しないことを示しています。ただし、誤ったDNSサービスが異常な否定応答を返す場合もあります。完全なドメイン名を確認し、信頼できる既知の名前解決経路で再確認してください。ページを繰り返し更新するだけでは解決しません。

エラー：ERR_CONNECTION_TIMED_OUT

原因と対処：規定時間内に接続が完了していません。DNSだけが原因とは限りません。接続先の解決結果、適用されたポリシー、リモートへの接続を確認し、同じURLでConfigとProxyの結果を比較してください。

エラー：ERR_CERT_DATE_INVALID

原因と対処：証明書の日付検証に失敗しています。端末の時刻やサイト証明書の有効期間が関係している可能性があります。まずシステムの日付とタイムゾーンを確認し、接続先サイトの状態も確認してください。証明書検証を無効にして対処しないでください。

問い合わせツールがNXDOMAINを返した場合、その応答ではドメインが存在しないと判断されています。SERVFAILは名前解決サービスが問い合わせを完了できなかったことを示します。どちらも応答が届かないタイムアウトとは異なります。応答の種類、問い合わせたドメイン、使用したDNSサーバーを記録すると、単に「DNSエラー」と記録するより後から確認しやすくなります。

5. ルールを確認する：名前解決が正しくても通信経路が誤っている場合がある

Global RoutingでConfigを選択している場合、通常は上から順にルールが評価され、一致すると対応するポリシーが適用されます。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPの位置情報データベースに基づいて照合します。FINALは前のルールに一致しなかったリクエストを処理します。DNSから正しいアドレスが返っても、名前解決が完了しただけで、その後のポリシーがリクエストに適しているとは限りません。

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

以下は構文を読むための例です。example.comは例示用ドメイン、192.0.2.0/24は文書用の予約アドレス範囲であり、日常的に使うルールとしてそのまま設定しないでください。no-resolveは、このIPルールのために名前解決を積極的に行わないことを示します。リクエストにすでにIPアドレスが含まれていれば、ルールに一致する場合があります。例のPROXYを使うには、現在の環境に利用可能なプロキシの選択先が必要です。この記述だけで通信経路が用意されるわけではありません。

ログにリクエストのドメイン、接続先アドレス、適用ポリシーが表示される場合は、3つをまとめて保存します。診断情報を共有する前に、認証情報、プライベートアドレス、サブスクリプショントークンを隠してください。トラブル対処のために設定全体を公開しないでください。この記事は、利用者がすでに自分のサービスを持っていることを前提としており、当サイトではノードやサブスクリプションの提供、販売、推奨は行っていません。

6. IPv6、キャッシュ、ブラウザーのDNSに関するよくある質問

DNSを変更しても、同じエラーが出るのはなぜですか？

Configで現在使用中のファイルを変更し、保存したか確認してください。接続を確立し直し、開いていたページを閉じて新しいリクエストを送ります。ブラウザー、システム、リモート側でキャッシュが保持されている場合があり、DNSを変更してもすべての階層の結果がすぐに消えるとは限りません。新しいリクエストの時刻を記録し、古いタブのエラーを新しい結果と取り違えないようにしてください。

IPv6を無効にすると開けます。ずっと無効にしておくべきですか？

IPv6の経路またはアドレス選択を引き続き確認する必要があるということです。AAAAの問い合わせ結果を記録し、同じネットワークでIPv4とIPv6それぞれの到達性を検証して、ルートとサービス側の対応状況を確認してください。関連する設定を一時的に無効にして比較することはできますが、すべてのDNS障害に対する恒久的な対処にはしないでください。

特定のブラウザーだけで開けない場合は、どう調べればよいですか？

同じ端末の別のブラウザーで、まったく同じURLにアクセスします。問題のブラウザーでSecure DNS、独自のプロキシ設定、拡張機能を確認してください。一時的にシステムの名前解決に戻して比較し、テスト後は元の設定に戻します。シークレットウィンドウは一部のサイトデータを切り分けるのに役立ちますが、DNSキャッシュを回避できるとは限りません。

IPアドレスでは開けるのに、ドメイン名では開けない場合、DNSが原因ですか？

必ずしもそうとは限りません。HTTPSサイトでは通常、SNIや証明書の検証にドメイン名が必要です。IPアドレスに直接アクセスすると、別のサイトが表示されたり、証明書エラーになったりする場合があります。名前解決の結果と、正しいドメイン名を指定した接続テストをあわせて判断してください。IPアドレスを直接開けるかどうかだけを判断材料にしないでください。

サブスクリプションを更新できるのに、Webページが開かないのはなぜですか？

サブスクリプションを更新できたことが確認するのは、その時点でサブスクリプションURLにアクセスできたことだけです。すべてのサーバーや接続先サイトへの通信を確認するものではありません。Homeに戻って実際に選択されているサーバーを確認し、Global Routingと接続できないドメインを調べてください。サブスクリプションを何度も更新しても、DNSやルールの問題の切り分けにはなりません。

7. 同じURLで再テストし、変更は最小限にする

トラブル対処の完了は「遅延の数値が表示された」ことではありません。想定しているネットワークとルーティングモードで、以前開けなかったURLが繰り返し読み込め、重要なリソースにも正常にアクセスできることを確認します。小さなリクエストは成功するのに大きなデータの読み込みが止まる場合は、MTUやトランスポート層の問題も検討します。特にWireGuardを使用している場合、Webページが開かないというだけでMTUを安易に変更せず、DNS以外の問題を混在させないでください。

  1. 普段使うGlobal Routingに戻し、元のURLと、以前読み込めなかったリソースのドメインを再試行します。
  2. Wi-Fiとモバイル通信のそれぞれで確認し、一方のネットワークだけに問題があるか記録します。
  3. On Demandの条件を元に戻し、ネットワーク切り替え後の接続動作が想定どおりか確認します。
  4. 比較テストで効果を確認できた変更だけを残し、効果がなかったDNS、IPv6、ルールの変更は元に戻します。
  5. それでも解決しない場合は、エラーの原文、発生時刻、ネットワークの種類、適用ポリシー、実施した比較テストをまとめ、利用中のサービスの管理元に確認してください。
Shadowrocketをダウンロード