iPhoneまたはiPadでShadowrocketを設定済みで、自分のサーバーまたはサブスクリプションを利用しているものの、遅延テストは正常なのにWebページを読み込めない場合に役立つ手順です。「症状を確認 → ルーティングを比較 → DNSを確認 → IPv6を確認 → 再テスト」の順に進めると、名前解決、サーバー接続、ルールによる振り分けのどこに問題があるかを切り分けられます。一度に複数の設定を変更して原因が分からなくなるのを防ぎましょう。
1. 遅延テストが正常でもWebページの表示成功とは限らない
Shadowrocketの遅延テストで分かるのは、その時点でテスト方法に応じた接続処理が完了したことです。TCPテストでは通常、サーバーのポートに接続できるかを確認します。HTTP系のテストでも、結果が示すのはテスト対象とその経路に限られます。問題のWebサイトに対するDNS問い合わせ、TLSハンドシェイク、ページ内リソースの読み込みを確認する代わりにはなりません。
Webページを開くには通常、ドメイン名をIPアドレスに解決し、選択した直結またはプロキシ経路で接続したうえで、TLSハンドシェイクとHTTPリクエストを行います。プロキシ経由では、接続先のドメイン名をリモート側で解決する場合もあります。遅延の数値だけでは、ローカルDNSとリモートDNSの両方が正常かどうかは分からず、Webサイトにアクセスできるとも判断できません。
これらはDNSの通信方式を説明するポートであり、サーバーのポートをそのいずれかに変更するという意味ではありません。DNS over HTTPSで接続できても、目的のWebサイトにアクセスできるとは限りません。反対に、通常のWebページを開けても、すべてのDNS通信方式へのアクセスがネットワークで許可されているとは限りません。
2. 再現可能な条件で症状を比較する
同じ完全なURL、同じブラウザ、同じデバイスを使って確認します。Webサイトのトップページ、サイト内リンク、動画再生をひとまとめにしてテストしないでください。ページ本体は表示できても、画像、ログイン、メディアに使われる別のドメインで失敗することがあります。各回で変更する条件は一つにし、結果を記録しましょう。
- 影響範囲を確認します。問題のWebサイトと、以前は正常に開けたWebサイトをそれぞれ表示します。すべてのページが失敗するのか、特定のドメインだけなのか、テキストは表示されても画像の読み込みが続くのかを記録してください。
- 基本のネットワーク接続を確認します。一時的にShadowrocketの接続を停止し、現在のネットワークでWebログイン認証が必要か確認します。この手順は基本のネットワーク接続を検証するためのもので、問題のWebサイトに直結でアクセスできることを求めるものではありません。
- 元の接続に戻します。Homeに戻り、自分が利用しているサーバーを選択して接続を有効にし、同じURLにアクセスします。遅延テストだけを繰り返さないでください。
- 接続ネットワークを比較します。サーバーと設定は変えず、Wi-Fiとモバイル通信を切り替えて再テストします。特定のWi-Fiでだけ失敗する場合は、まずそのネットワークのDNS到達性、認証状態、アクセス制限を確認してください。
- 自動再接続の影響を除外します。接続を停止しても自動的に再接続される場合は、Settings → On Demandを確認します。現在の設定を記録し、必要に応じてテスト中だけ一時停止してください。テスト後は元に戻します。
ブラウザが既存の接続を再利用したり、DNSのキャッシュが残っていたりする場合があります。設定を変更したら、Shadowrocketの接続をいったん停止して再接続し、問題のページを開き直してください。結果が安定しない場合は、該当するブラウザータブを閉じてから再試行します。一度表示できただけで解決したと判断しないでください。
3. Global RoutingでルーティングとDNSの問題を切り分ける
Home → Global Routingで現在の設定を確認します。Configは現在の設定に従って通信を処理するモードであり、すべてのリクエストがプロキシ経由になるわけではありません。Proxyは主に、選択したプロキシを経由する場合との比較に使います。Directは直結での比較に使います。Sceneではシーン設定に応じて動作が変わるため、現在適用されているシーンも確認してください。名称だけで実際の接続先を判断することはできません。
| 比較結果 | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| Configでは失敗し、Proxyでは成功 | ルールの一致、ポリシーの選択、経路による名前解決の違い | 現在のConfigで対象ドメインに適用されるルールとポリシーを確認する |
| ConfigとProxyの両方で失敗 | 現在のサーバー、DNSの到達性、または対象Webサイト | 設定は変えず、自分が利用している別のサーバーで比較する |
| Directでは成功し、Proxyでは失敗 | プロキシの出口、リモートDNS、または接続先による出口制限 | サーバーの状態を確認し、ルール全体をすぐに書き換えない |
| 特定の接続ネットワークでのみ失敗 | そのネットワークの通信制限とDNS経路 | Wi-Fiとモバイル通信を比較し、DNSの通信方式も確認する |
結論：Proxyで成功する場合は、まずConfigを確認
同じサーバーとネットワークでConfigだけが失敗する場合は、対象ドメインに一致するルールと実際のポリシーを確認してからDNSを調整します。問題が解決したと確認できるまで、Proxyを使い続けるだけでルールの問題が直ったと判断しないでください。
これらの結果は原因を絞り込む手がかりであり、一度のテストで確定できるものではありません。Global Routingを切り替えると接続経路と名前解決の条件が同時に変わる場合があるため、次のセクションのDNS設定も一つずつ確認してください。比較が終わったら、普段使う設定に戻します。
4. DNSアドレス、通信方式、設定元を確認する
Settings → DNSを開き、現在表示されているDNS設定を記録します。次にConfigを開き、実際に使っている設定ファイルにDNS関連の項目があるか確認してください。アドレスを一か所変更しただけで反映されたと判断しないでください。設定ファイル、全体設定、各オプションの組み合わせが動作に影響するため、再接続後のリクエスト結果で確認します。
- 入力先の項目が正しいか確認します。通常のDNSアドレス、DNS over HTTPSの完全なURL、DNS over TLSのサーバー名は、自由に置き換えられる文字列ではありません。画面で指定された形式に従い、サブスクリプションのURLをDNS欄に貼り付けないでください。
- 接続先の情報が完全か確認します。DNS over HTTPSでは通常、HTTPSエンドポイントの完全なURLが必要です。WebサイトのトップページのURLだけを見て、DNSサービスを提供していると判断することはできません。利用中の名前解決サービスの案内を確認し、パスを推測で組み立てないでください。
- 最初の名前解決が必要か確認します。DNSエンドポイントがドメイン名の場合、接続前にそのドメイン名を解決する必要があることがあります。基本の名前解決が使えない状況では、ドメイン名形式の別エンドポイントに変更するだけでは解決しない場合があります。
- 通信経路に到達できるか確認します。現在のネットワークでHTTPSが許可されていても、別のポートは制限されている場合があります。プロキシサーバー自体にドメイン名を指定している場合は、プロキシ接続の確立前に名前解決が必要かも確認してください。DNSリクエストとプロキシ接続の確立が互いに依存する構成は避けましょう。
- 一項目ずつ変更して再テストします。まず現在の設定をバックアップし、利用可能だと確認済みのDNS設定と比較します。サーバー、Global Routing、テストURLは変えずに、再接続後の結果を記録してください。
DNSを変更して復旧した場合は、再接続やネットワーク切り替え後も有効か確認します。一度だけ成功して再発するなら、キャッシュ、エンドポイントの到達性、自動切り替えの条件を見直してください。サブスクリプションの更新で主に更新されるのはサーバー情報です。現在のConfigにあるDNS設定も必ず更新されるわけではありません。
5. エラーメッセージに応じて確認箇所を絞る
エラーはブラウザー、システムのネットワーク層、リクエストログに表示されることがあり、Shadowrocket自体が表示したメッセージとは限りません。以下はよくあるネットワークエラーの表現ですが、すべてのデバイスで同じ文言が表示されるとは限りません。「開けない」とだけ記録するより、エラーが対象Webサイト、プロキシサーバー、DNSエンドポイントのどのドメインに関係するかを記録するほうが役立ちます。
エラー：The server with the specified hostname could not be found.
原因と対処：ホスト名を解決できず、有効な結果が得られていません。ドメイン名の入力ミスや、ドメイン自体が無効になっている可能性もあります。完全なドメイン名を確認し、Settings → DNSと現在のConfigを照合したうえで、別の接続ネットワークから同じURLを再テストしてください。
エラー：NXDOMAIN
原因と対処：DNSリゾルバーが、ドメイン名が存在しないことを示しています。応答待ちのタイムアウトとは異なります。ドメイン名の入力ミスや、不要なサブドメインを追加していないか確認し、利用可能と確認済みの別のDNS経路と比較してください。待ち時間を延ばし続けても解決しません。
エラー：SERVFAIL
原因と対処：DNSリゾルバーが問い合わせを完了できていません。上流側の障害やドメインの検証に関する問題が考えられます。他の条件は変えず、利用可能な別のDNS経路と比較してください。同じドメインだけで発生する場合は、結果を記録して利用中のサービス提供元に問い合わせます。
エラー：The request timed out.
原因と対処：リクエストのいずれかの段階でタイムアウトしていますが、このメッセージだけではDNSの障害と断定できません。まず名前解決でアドレスを取得できているか確認し、その後に接続経路を調べます。名前解決が成功している場合は、TCP、TLS、接続先サービスの応答を確認してください。
証明書エラーが発生した場合は、デバイスの日付と時刻、対象ドメイン名、設定したエンドポイントが正しいかを確認してください。「ドメイン名が見つからない」エラーとは別の問題です。表示を消すためにTLS検証を無効にしたり、どの段階で失敗しているか確認する前にDNS、サーバー、プロトコルを同時に変更したりしないでください。
6. 特定のドメインだけ失敗する場合：ルール、AAAAレコード、ページ内リソースを確認
ほとんどのWebサイトは正常で、一部のドメインだけ失敗する場合は、違いがある箇所を優先して確認します。AレコードはIPv4アドレス、AAAAレコードはIPv6アドレスを返します。AAAAレコードがあっても、現在のネットワークでIPv6経路を利用できるとは限りません。名前解決は成功しているのに接続が遅い場合は、元に戻せることを確認したうえでIPv6関連の設定を比較します。一度に変更する項目は一つにし、テスト後は元に戻すか、最終的な設定を記録してください。
ルールは上から順に照合されます。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とそのサブドメインに先にDIRECTが適用されます。そのドメインへの接続に利用者自身のプロキシが必要な場合は、前方に不適切なルールがないか確認してください。 - no-resolveの意味を確認します。この指定は、IPルールのためにドメイン名の解決を積極的に開始しないようにするものです。DNSを修復する汎用スイッチではなく、リクエストで名前解決が一切発生しなくなることを保証するものでもありません。
- ポリシーが定義されているか確認します。例の
PROXYは、実際に利用できるポリシーに対応している必要があります。名前だけをコピーし、現在の設定に対応する定義があるか確認しないまま使わないでください。 - ページ内の関連リソースを確認します。ページのテキストは表示されるのに画像が読み込めない場合は、画像、スクリプト、ログインのリクエストで使われているドメインを確認してください。メインのドメインのルールを変更するだけでは、別のリソース用ドメインに適用されないことがあります。
結論：アドレスを取得できているのに接続できない場合は、次の段階を確認
問題のドメインからアドレスが返されていると確認できたのに、接続またはTLSの段階で止まる場合は、実際の接続先、IPv4 / IPv6経路、対象Webサイトの応答を優先して確認してください。すべての失敗をDNSの名前解決の問題とみなす必要はありません。
7. よくある質問と最終チェック
遅延テストは常に正常なのに、サーバーを変えるとWebページが開くのはなぜですか？
遅延テストで確認できるのは、テスト対象と接続処理の一部に限られます。別のサーバーでは、出口、リモート側の名前解決、対象Webサイトへの到達性が異なる場合があります。DNSとConfigは変えずに両方のサーバーを比較し、サーバーを変えると問題のWebサイトの表示結果も変わるか記録してください。それだけでローカルDNSに問題があるとは判断できません。
Proxyに切り替えると開けます。Configは確認しなくてもよいですか？
原因を絞り込む手がかりにはなりますが、Configに戻ってルールの順序、対象ドメインに適用されるポリシー、DNS関連設定を確認してください。修正後は普段使う設定に戻し、同じWebページとページ内リソースがすべて読み込めることを確認します。
Wi-Fiだけでエラーになり、モバイル通信では正常です。再インストールが必要ですか？
まず再インストールは不要です。同じサーバーと設定を維持したまま、Wi-Fiのログイン認証とDNS通信の到達性を確認してください。接続を停止しても自動的に再接続される場合は、テスト条件が変わらないようにSettings → On Demandも確認します。
サブスクリプションを更新するとDNSも復旧しますか？
必ずしもそうとは限りません。サーバーのサブスクリプションとConfigでは、管理する内容が異なります。まずHomeで選択中のサーバーが変わったか確認し、次にConfigで実際に使われている設定を確認します。最後にSettings → DNSを確認してください。サーバー一覧の更新を、すべてのネットワーク設定のリセットと混同しないでください。
変更後は、問題が起きたURL、正常に表示される比較用URL、接続ネットワークを切り替えた状態で少なくとも一度ずつ再テストします。利用中のサービス提供元に問い合わせる場合は、失敗したドメイン、発生時刻、接続ネットワーク、Global Routingの設定、エラーメッセージ、変更前後の比較結果を伝えてください。サブスクリプションのトークン、サーバーのパスワード、その他の認証情報はスクリーンショットやログから削除します。
- ドメインの名前解決エラー、接続タイムアウト、TLSエラーを区別し、遅延テストの結果だけで判断していない。
- Homeで選択中のサーバー、Configファイル、Global Routingの設定を確認した。
- DNSアドレスの形式、エンドポイントへの到達性、最初の名前解決が必要となる可能性を確認した。
- 一時的に変更したOn Demand、ルーティング、IPv6関連の設定を元に戻すか、維持する設定を記録した。
- 再接続後も問題が解決した状態を保てることを確認した。一度だけ読み込めた状態ではない。