Shadowrocketの使い方｜遅延テストは正常なのにWebページが開かない原因とDNS設定

遅延が正常でもWebページへの接続が正常とは限らない

遅延テストで確認できるのは、テスト対象が指定された方法で応答したことだけです。テスト方法によって、ドメイン名の解決、プロキシ認証、Webページへのアクセスが含まれるかどうかは異なります。テストが一度成功しても、すべてのWebサイトにアクセスできるとは限りません。ブラウザでHTTPSページを表示するには、ドメイン名の解決、接続先への接続、TLSハンドシェイク、サーバーからの応答が必要です。どの段階で失敗しても、ページを読み込めない状態になります。

上記の流れは障害箇所を特定するための目安であり、内部処理が必ずこの順序で進むという意味ではありません。ドメインルールは接続先IPアドレスの取得前に適用されることがあり、IPルールの適用には名前解決が必要な場合があります。また、名前解決は2種類に分けて考える必要があります。プロキシサーバーのアドレスにドメイン名を指定している場合は、まずそのサーバーの名前解決が必要です。接続先Webサイトのドメイン名をどこで解決するかは、プロトコル、アウトバウンド方式、設定によって異なります。

• どのドメインにもアクセスできない：まず基本ネットワーク、接続状態、DNSへの到達性を確認してください。すぐにサブスクリプションを再設定する必要はありません。
• 特定のドメインだけアクセスできない：ドメイン名の入力、該当するDNSの応答、ルールの適用状況、Webサイト自体の稼働状況を確認してください。
• トップページは開くが、画像やログインに失敗する：画像やログイン機能が別のドメインから読み込まれている可能性があります。アドレスバーのドメインだけでなく、リクエストごとに確認してください。
• Wi-Fiでは失敗し、モバイル通信では正常：まずネットワーク認証、DNSの通信経路、IPv6経路を比較し、そのうえでサービス側のパラメータが原因かどうかを確認してください。

再現可能なテスト条件を整える

テストの前に、アクセスできないURL、使用中のネットワーク、Homeで選択しているサーバー、Global Routingの状態を記録してください。普段アクセスできるWebサイトを2つ、アクセスできないWebサイトを1つ用意して比較します。設定は一度に1項目だけ変更し、同じページをテストしてください。以下の手順は、自分のサーバーまたはサブスクリプションをすでに利用していることを前提としています。クライアントの購入に接続サービスは含まれません。

1. 現在の設定を記録する

   Configで現在使用中の設定を確認し、先にバックアップを残してください。Home → Global Routingの選択状態、選択中のサーバー、現在のDNS設定を記録し、切り分けのための変更を恒久設定と取り違えないようにします。

2. 基本ネットワークを確認する

   一時的に接続をオフにし、通常そのままアクセスできるWebサイトを開いてください。それでもアクセスできない場合は、まずWi-Fi認証を完了するか、利用可能なネットワークに切り替えます。Settings → On Demandを確認し、切り分け中は接続を自動的に再確立する条件を一時的に無効にしてください。終了後は元に戻します。

3. アウトバウンドを固定する

   Homeに戻り、自分の利用可能なサーバーを選択して接続をオンにします。Home → Global Routingで一時的にProxyを選び、同じURLに再度アクセスしてください。Proxyはルールの影響を切り分けるための設定で、すべてのDNSリクエストが必ずそのサーバーを経由するという意味ではありません。

4. 名前解決を確認する

   Settings → DNSを開いて現在の設定を記録し、Configで有効になっている設定のDNS項目と照合します。まず、参照元が明確な設定に戻してください。検証していない複数のDNSリゾルバーを同時に追加するのは避けましょう。

5. 設定を戻して再テストする

   Global Routingを元の設定に戻し、同じページに再度アクセスしてください。Proxyでは正常でConfigでは失敗する場合は、ルールを確認します。どちらでも失敗する場合は、DNSクエリ、接続先への接続、TLSエラーのどの段階で失敗しているかをさらに切り分けます。

DNS設定はリゾルバー、通信方式、適用範囲を確認する

DNSはドメイン名をIPアドレスに変換します。AレコードはIPv4アドレス、AAAAレコードはIPv6アドレスを返します。レコードを取得できても、そのアドレスに現在のネットワークやアウトバウンド経路から到達できるとは限りません。DNSを設定するときは、「どこに問い合わせるか」「どのように通信するか」「どのリクエストに設定を適用するか」の3点を確認してください。

設定テキストでシステムDNSの基本設定を確認する場合は、次の構文を参照してください。これは設定例の一部であり、完全な設定ファイルではありません。また、既存のファイルを丸ごと置き換えるものでもありません。バックアップしたファイル内の該当項目を編集し、[General]セクションを重複して作成しないでください。

[General]
dns-server = system

システムDNSを使うと、問題が元のカスタムリゾルバーに起因するかを切り分けやすくなります。ただし、どのネットワークでも同じ結果が返るとは限りません。元の設定で特定のドメインに個別の名前解決方式を指定している場合は、該当する設定も確認してください。DNSリゾルバーを増やすことは、あらゆる問題に対する解決策ではありません。参照元によって応答が異なる場合があり、混在させると問題を再現しにくくなることがあります。

エラーを発生段階ごとに分類する

以下はAppleのネットワークリクエストで発生する可能性がある実際のエラー識別子です。ブラウザやShadowrocketに、これらの文字列がそのまま表示されるとは限りません。実際に表示されたエラー文、発生時刻、リクエスト先のドメイン名を記録し、失敗した段階ごとに分類してください。「タイムアウト」だけではDNSの問題とは断定できません。

DNSクエリの結果も区別が必要です。NXDOMAINは、リゾルバーがその名前は存在しないと応答したことを示します。SERVFAILは、サーバーがクエリを完了できなかったことを示します。クエリのタイムアウトは、待機時間内に応答を受信できなかった状態です。この3つは異なる問題です。有効であることを確認した同じドメイン名を使い、DNS設定を固定して繰り返しテストすると、ブラウザの「ページを開けません」という表示だけを見るより原因を判断しやすくなります。

Global Routingとルールの影響を切り分ける

名前解決に成功していても、適切でないアウトバウンドが選ばれるとWebページへの接続に失敗する場合があります。Global Routingでは、Proxyはプロキシ経由のアウトバウンド、Directは直接接続、Configは有効な設定に従った処理、Sceneは選択中のシーンに従った処理です。切り分けの際は、サーバーが選択されているかだけでなく、現在のモードで実際にそのサーバーが使われているかも確認してください。

Proxyでは同じページを開けるのにConfigでは開けない場合、先に一致するドメインルールまたはIPルールがないか確認してください。ルールは記載順に照合されます。DOMAIN-SUFFIXはドメインのサフィックスを確認し、GEOIPとIP-CIDRはIPアドレスの条件に関係します。FINALは最後のフォールバックとして使われます。以下は構文例です。既存の設定全体と置き換えないでください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
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ルールとの照合のために追加の名前解決を行わないことを示します。DNS全体を無効にする設定ではありません。
• ルールが先に対象をDIRECTへ振り分けた場合、後続のFINAL,PROXYによってそのリクエストがプロキシ経由に変更されることはありません。
• サブスクリプションの更新成功が示すのは、サブスクリプションの内容を取得できたことだけです。接続先WebサイトのDNS、ルール、接続が正常であることまでは確認できません。サーバーリストを更新しても、現在のConfigの問題が解決するとは限りません。

HTTPSの確認方法として、「ブラウザで接続先IPアドレスを直接開く」ことだけに頼らないでください。HTTPSではドメイン名に対応する証明書、SNI、サイトのルーティングも必要です。IPアドレスを直接入力すると、別のエラーが発生する場合があります。同じドメイン名でアドレスを取得できるか、どのアクションのルールに一致したか、その後の接続がどの段階で失敗したかを確認するほうが確実です。

キャッシュ、IPv6、再テスト時によくある疑問

DNSを変更しても、アプリ、システム、DNSサービスにキャッシュが残っている場合があります。設定を保存して反映を確認したら、接続をいったん切断して再接続し、ブラウザからリクエストをやり直してください。これですべての階層のキャッシュが消えるとは限りません。一度の再読み込みだけで修復したと判断せず、同じページを繰り返し確認し、ネットワークが変わっていないかも記録してください。

自分のサービス提供元に問い合わせる場合は、障害の発生時刻、ネットワークの種類、Global Routingの選択肢、アクセスできないドメイン名、実際に表示されたエラー、A/AAAAレコードを取得できたかを記録してください。サブスクリプションのトークン、認証情報、秘密鍵は隠し、設定ファイル全体を公開しないでください。「名前解決には成功したが接続できない」「特定のネットワークだけDNSがタイムアウトする」のように伝えると、遅延のスクリーンショットだけを送るより原因を特定しやすくなります。

• テスト中に変更したOn DemandとGlobal Routingの設定を元に戻します。
• 再現性を確認できた変更だけを残し、効果のなかった変更は取り消します。
• 元のネットワークとテストURLを使って再テストし、問題が一時的に解消しただけではないことを確認します。