Shadowrocketの遅延テスト結果が示すのは、テスト対象にその時点で到達できたことだけです。Webサイトのドメイン名が正常に解決されたことまでは確認できません。ここでは、利用中のサービス情報とサブスクリプションがすでにあることを前提に、基本ネットワーク、DNS応答、Global Routing、IPv6、設定の上書きの順で確認します。まず現在の設定を保存し、一度に変更する項目は一つだけにして、同じドメイン名で再テストしてください。
1. 遅延テストが正常でもWebサイトを開けない理由
Webサイトへのアクセスは、遅延テストだけでは確認できません。通常、ブラウザはまずドメイン名をIPアドレスに解決し、その後に接続を確立してTLSハンドシェイクを行い、最後にページをリクエストします。サーバーのアドレスや特定のテスト対象だけを調べるテストでは、Webサイトが使うDNS、ルールによる振り分け、証明書の検証までは確認できません。テスト結果が数ミリ秒と短くても、DNSの問題がないとは判断できません。
この流れは問題が起きた段階を特定するためのもので、DNSの照会とWebサイトへのリクエストが必ず同じ経路を通るという意味ではありません。DNSの送信方法が個別に設定されている場合や、ドメイン名の処理がリモート側で行われる接続もあります。そのため、「ノードへの遅延は正常」と「ローカルDNSは正常」は別々に判断する必要があります。
- すべてのWebサイトにアクセスできない場合：まず基本ネットワーク、トンネルの状態、DNS上流への到達性を確認してください。特定のWebサイトのルールをすぐに変更する必要はありません。
- 特定のドメイン名だけ失敗する場合：ドメイン名の入力、DNS応答、適用されたルールを確認してください。Webサイト側の障害の可能性もあります。
- トップページは開くのに画像の表示やログインに失敗する場合：失敗するリソースが実際に使用しているドメイン名を確認してください。アドレスバーのメインドメインだけをテストしても不十分です。
- 証明書の警告やHTTP 403が表示される場合：すでに別の段階で問題が発生しています。「ページが開かない」という理由だけでDNSエラーと判断しないでください。
2. 再現可能な確認条件を整える
確認を始める前に、Homeで現在選択されている接続を、Configで使用中の設定を確認し、設定のコピーを保存してください。以降のテストでは同じ完全なURLを使い、ネットワークの種類、時刻、Global Routingのモード、エラーの内容を記録します。サブスクリプションの更新、接続先の変更、DNSとルールの変更を同時に行うと、どの変更が影響したのか判断できません。
- 基本ネットワークを確認：一時的にShadowrocketを切断し、普段アクセスできるWebサイトを開いてみてください。公共Wi-FiでWeb認証が必要な場合は、先に認証を完了します。基本ネットワーク自体に接続できない場合は、Wi-Fiまたはモバイル通信を先に確認してください。
- 自動再接続を確認：Settings → On Demandで自動接続が有効になっているか確認してください。切断時との比較を行う場合は、関連する条件を一時的に無効にし、確認後に元に戻します。自動再接続を手動切断のテストと取り違えないためです。
- 失敗を再現する：再接続して問題のURLを開き、長時間読み込み中になるのか、ドメイン名エラー、接続タイムアウト、TLSエラーのどれが発生するか記録してください。ブラウザの簡略化されたエラー表示だけでは、DNSの照会結果は確認できません。
- ネットワークを切り替えて再テスト：可能であれば、同じ端末でWi-Fiからモバイル通信に切り替え、接続と設定は変えずにテストしてください。一方のネットワークだけで失敗する場合は、そのネットワークでDNS通信や接続先に到達できるかを重点的に確認します。
- 関連する記録を確認：Shadowrocketの接続ログ、DNS照会結果、または利用可能な診断ツールを使って、失敗したドメイン名、応答アドレス、実際に適用されたポリシーを確認してください。具体的な画面の場所は現在のアプリ画面に従ってください。
「WebサイトのIPアドレスを直接開く」方法を、一般的な確認手段として使わないでください。HTTPSサイトではドメイン名に対応したSNI、証明書、仮想ホストが必要な場合があります。IPアドレスへの直接アクセスに失敗しても、ネットワークが使えないとは限りません。
3. DNS応答のエラーと応答なしを区別する
DNSの問題は大きく二つに分けられます。サーバーから明確なエラーが返される場合と、有効な応答がまったく返ってこない場合です。対処方法はそれぞれ異なります。以下はDNSプロトコル上の実際のステータス名であり、Shadowrocketやブラウザの画面に必ず同じ表記で表示されるとは限りません。ログには「名前解決に失敗」や「タイムアウト」とだけ表示されることもあります。
エラー：NXDOMAIN
原因：照会した名前が存在しないことを示す応答です。ローカルのマッピング誤りや、上流からの異常な応答が関係する場合もあります。対処：まず完全なドメイン名を確認し、正常に使えることが分かっている別の名前解決経路で同じレコードを照会してください。名前が存在しない問題を、待ち時間を延ばして解決しようとしないでください。
エラー：SERVFAIL
原因：リゾルバーが照会を完了できませんでした。上流の権威DNSサーバー、検証処理、一時的なサービス障害などが原因として考えられます。対処：同じリゾルバーで正常な別のドメイン名を照会した後、問題のドメイン名も別経路から照会します。これにより、リゾルバー全体の障害か特定ドメインの問題かを切り分けられます。
エラー：REFUSED
原因：サーバーが照会を拒否しています。アクセス制御や、現在の接続元からの再帰問い合わせが許可されていない場合によく発生します。対処：そのDNSサービスの利用条件を確認し、現在のネットワークまたは既存の設定で使用が許可されているリゾルバーに戻してください。
応答がまったくない場合は、DNSサーバーのアドレス、通信方式、送信経路を重点的に確認します。なお、NOERRORでも必ず利用可能なアドレスが取得できるとは限りません。照会自体は成功していても、該当するレコードタイプが存在せず、回答欄が空の場合があります。AAAAレコードだけ取得できず、Aレコードが正常なら、ドメイン名全体の名前解決に失敗したわけではありません。
- A：IPv4アドレスを返します。IPv4の名前解決が正常か確認する際に使います。
- AAAA：IPv6アドレスを返します。アドレスを取得できても、現在のネットワークでIPv6経路が使えるか確認が必要です。
- CNAME：別名を示します。別名の参照先も引き続き解決する必要があるため、メインのドメイン名から応答があっても、別名の連鎖全体が正常とは限りません。
4. DNS設定項目の役割を確認する
Shadowrocketで実際に使われるDNSの動作は、現在の設定とあわせて確認してください。Configで有効な設定とGeneralの設定を確認します。テキストで確認する場合は、[General]などの関連セクションが該当します。無効な別の設定にある値だけを見て現在の状態を判断したり、サービス情報に記載されたサーバーアドレスをDNSサーバーとして入力したりしないでください。
| 設定項目・用語 | 役割 | 変更するタイミングと注意点 |
|---|---|---|
dns-server |
DNSの上流サーバーを指定します。使用できるアドレスの形式や通信方式は、現在のアプリの設定説明に従って入力してください。 | 現在の上流サーバーに接続できない、または異常な応答があると確認できた場合に変更します。アドレスを複数指定しても、必ず順番に一つずつ試すとは限りません。 |
system |
この値に対応するDNS設定では、現在のシステムネットワークが提供するリゾルバーを使用します。 | 元の設定に戻して比較する際に使えます。実際に使われるサーバーは、Wi-Fi、モバイル通信、ネットワーク管理の設定によって変わる場合があります。 |
fallback-dns-server |
予備のDNS上流サーバーを設定し、メインの名前解決処理を補います。 | 有効になる条件は現在の設定方式によって異なります。すべての失敗した照会が自動的に解決されるわけではありません。 |
ipv6 |
IPv6関連の処理に影響します。システム、トンネル、実際のネットワーク機能をあわせて判断してください。 | AAAAが正常に返る一方でIPv6接続に失敗する場合に、他の条件を変えずに比較します。すべてのDNS障害に対する万能策として無効にしないでください。 |
[Host] |
ローカルのドメイン名マッピングを設定します。特定のドメイン名が最終的に使用するアドレスに影響する場合があります。 | 一部のドメイン名だけに問題がある場合は、古いマッピングがないか確認してください。Webサイトのアドレスは変わるため、一時的なIPアドレスで通常の名前解決を長期間置き換えるのは避けてください。 |
ドメイン名を使う暗号化DNSのエンドポイントを利用する場合は、まずエンドポイント自体の名前解決と接続の問題を解決する必要があります。エンドポイントに接続できない状態では、通常のDNSを暗号化DNSに変えるだけでアクセスが自動的に復旧することはありません。証明書の検証、端末の時刻、エンドポイントが通る経路も確認してください。
まとめ：上流への到達性を確認してから名前解決方式を変更する
ポート番号は通信方式を見分ける手がかりにすぎず、エンドポイントが使えることを保証しません。現在のネットワークから同じ上流サーバーに接続できない場合は、まず動作確認済みの設定に戻してください。その後、通常のDNSと暗号化DNSを個別にテストし、正しい応答が返る方式を使用します。
5. Global Routingで名前解決とルールによる振り分けを切り分ける
Home → Global Routingで現在のモードを確認してください。ルール設定を普段使っている場合は、通常Configを確認します。一時的にProxyまたはDirectに切り替えると比較できますが、DNSに関する個別設定をすべて上書きできるとは限りません。Sceneはシーンの選択に関する項目であり、常に直結またはプロキシになる固定のポリシーとして解釈しないでください。
| モード | 確認する内容 | 結果の見方 |
|---|---|---|
| Config | 現在の設定に基づいて、リクエストに適用されたルールとポリシーを確認します。 | このモードだけで失敗する場合は、ルールの順序、ポリシーグループの選択、設定内のDNS項目を重点的に確認します。 |
| Proxy | プロキシ経由で対象のWebサイトに到達できるか、一時的に比較します。 | アクセスが復旧しても、送信経路の確認が必要だと分かるだけで、DNSが修復された証拠にはなりません。 |
| Direct | 対象に直接接続した場合の結果を一時的に確認します。 | 対象自体が直接アクセスを許可し、実際に接続できる場合にのみ、有効な比較になります。 |
| Scene | 現在のシーンで実際に選択されている設定と動作を確認します。 | まずシーンの内容を確認し、シーン切り替えによる違いをDNSの不規則な障害と誤認しないようにしてください。 |
正しいIPアドレスを取得できているのに接続がタイムアウトする場合は、引き続き送信ポリシーを確認してください。ドメイン名ルールとIPルールは同じではありません。DOMAIN-SUFFIXはドメイン名のサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの所在地データベースを使って照合し、FINALはそれ以前のルールに一致しないリクエストを処理します。照合に対象IPが必要なルールでは、名前解決が行われる場合があります。no-resolveを使う場合、ルール照合のために積極的に名前解決が実行されるとは考えないでください。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY上記はルール構文の例であり、現在の設定をそのまま置き換えるためのものではありません。example.comは例示用ドメイン名で、PROXYも現在の設定で有効なポリシーとして定義されている必要があります。問題を調べるときは、実際に適用されたルールの記録を先に確認してください。上にある広い条件のルールがすでに適用されている場合、後続の修正用ルールは実行されません。FINALは末尾に置いてください。
6. 名前解決後も失敗する場合：IPv6、キャッシュ、設定の上書きを確認
DNSからアドレスが返されても、完了したのは最初の段階だけです。AとAAAAの両方が返る一方、一部のネットワークでIPv6経路だけに問題があると、ブラウザは失敗する経路を待ってから別の経路を試すことがあります。その結果、読み込みが長く続いたり、アクセスできたりできなかったりします。この場合はDNSを何度も変更するのではなく、接続に使われているアドレスファミリーを確認してください。
- アドレスファミリーを比較：失敗した接続でIPv4とIPv6のどちらが使われたかを記録してください。必要に応じて設定のコピーでIPv6関連の項目を変更してテストします。元の値を保存し、テスト後に結果を見て元に戻すか判断してください。
- キャッシュの影響を除外：設定を変更したら、接続を確立し直してからWebサイトに再度アクセスしてください。ブラウザ、システム、リゾルバーはそれぞれキャッシュを保持する場合があり、1回更新しただけでは新しいDNS照会が行われないことがあります。
- 有効な設定を確認：Configに戻り、変更した設定が引き続き有効になっているか確認してください。コピーを編集しても有効化していないと、「変更が反映されない」と感じることがあります。
- 2種類の更新を区別：HomeにあるSubscribeの更新は、主に該当するサービス情報を更新するものです。リモートConfigの更新では設定内容が上書きされる場合があります。DNSパラメーターの修正にサブスクリプションの更新が必須だと思わないでください。
- 変更が上書きされていないか確認：リモート設定を更新するたびに問題が再発する場合は、更新前後のDNS、Host、Ruleの内容を比較し、ローカルでの変更が置き換えられていないか確認してください。
サブスクリプションの完全なURL、認証情報、未加工のログを他人に送らないでください。問い合わせる際は、エラーの種類、対象のドメイン名、ネットワークの種類、ポリシー名を残せば十分です。アカウントやトークンに関する情報は先に削除してください。
7. 確認結果から判断する：DNSの変更を終えるタイミング
確認を終えたら、問題が「応答なし」「明確なエラー応答」「誤ったアドレスが返る」「正しいアドレスなのに接続できない」のどれに当たるか説明できる状態を目指します。毎回の照会で期待するアドレスが返り、ログから接続確立またはTLSハンドシェイクの段階で失敗していると分かった場合は、DNSの変更をやめ、利用中のサービスへの接続状態、対象のWebサイト、端末の時刻、ポリシーの経路を確認してください。
- DNSが原因と判断できる：同じドメイン名が元の上流では失敗し、動作確認済みの別の名前解決経路では成功する。ほかの条件を変えずにWebサイトへアクセスできるようになった場合です。
- ルールによる振り分けの可能性が高い：DNSの結果は同じでもConfigだけで失敗し、実際に適用されたルールを調整すると復旧する場合です。
- ネットワーク経路の問題の可能性が高い：設定を変えていないのにWi-Fiでは失敗し、モバイル通信では成功する場合、または特定のアドレスファミリーだけ接続できない場合です。
- 接続先の問題の可能性が高い：特定のWebサイトだけで問題が起き、名前解決は正常で、同じ接続とポリシーでほかのWebサイトにはアクセスできる場合です。
利用中のサービス提供元に問い合わせる場合は、発生時刻、Wi-Fiまたはモバイル通信の別、問題のドメイン名、DNS応答の状態、返されたアドレスファミリー、Configと一時的な比較モードでの違いを伝えてください。「遅延は正常なのに使えない」だけでなく、「ドメイン名の照会でSERVFAILが返る」と報告すると、原因を特定しやすくなります。確認後は一時的に無効にしたOn Demandを元に戻し、最終的に動作した設定のコピーを保存してください。