Shadowrocketで遅延は正常なのにWebページが開けない場合｜DNS解決エラーの確認方法とDNS設定

1. 遅延が正常でもWebページへのアクセス成功とは限らない

Webページを開く際には通常、ドメイン名の名前解決、接続の確立、TLSハンドシェイク、HTTPリクエストが行われます。Homeの遅延結果は、そのテストで使用された宛先と方法を反映するだけです。すべてのWebサイトで名前解決できることや、サーバー認証、通信設定、ページの応答が正常であることを示すものではありません。テストに成功していても、ブラウザーが名前解決の段階で止まることがあります。一方、ページが開けない原因は接続やTLSの問題かもしれません。遅延の数値だけでDNS障害と判断しないでください。

まず、開けないURLの完全なドメイン名、発生時刻、現在のサーバー、Global Routingのモード、ネットワークの種類を記録します。以前アクセスできたWebページを比較対象にし、Webサイト、サーバー、DNSを次々に変更しないでください。どの変更が結果に影響したのか判断できなくなります。以下の現象は原因を絞る手がかりです。後述の再テストで確認してください。

2. DNSの各設定項目の役割

DNSはドメイン名を接続可能なアドレスに変換します。システムDNSは通常、接続中のWi-Fiまたはモバイル通信から提供されます。設定内のdns-serverは、Shadowrocketで使用するリゾルバーを指定します。これは同じ階層の設定ではありません。ブラウザー独自の暗号化DNS、設定内のルール、接続方式によって実際のクエリ経路が変わることもあります。リゾルバーのアドレスを指定しても、すべてのリクエストが必ずそこを経由するとは限りません。

ポート番号はプロトコルで一般的に使われる値であり、サーバー設定で一律に変更する値ではありません。DNSのポートと、利用中のサーバーへの接続ポートは別々です。名前解決の確認のために、HomeにあるサーバーのPortを53に変更しないでください。

3. 元に戻せる方法で順番に確認する

開始前に現在の設定を複製し、DNSの元の記述を記録します。設定が利用中のサブスクリプションで管理されている場合、後から更新するとローカルの変更が上書きされることがあります。確認用の複製は元の設定と区別してください。パスワード、UUID、サブスクリプショントークン、サーバーアドレス全体を含む設定を公開アップロードしないでください。

1. 現在の状態を記録する

   Homeで現在のサーバーと接続状態を記録し、Home → Global Routingを開いて現在の選択肢を控えます。Safariで同じURLにアクセスし、実際に表示されたメッセージとテスト時刻を記録してください。

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

   一時的に接続を切断し、現在のWi-Fiでネットワークへのログインが必要か確認します。ネットワークを比較する場合は、Wi-Fiとモバイル通信で同じURLをテストしてください。モバイル通信ではデータ通信料が発生する場合があります。

3. モードを比較する

   Home → Global Routingで、Configを選択したときの結果を記録し、一時的にProxyへ切り替えてテストします。結果が変わった場合は、まずルールと通信経路を確認してください。DNS全体が修復されたと判断することはできません。

4. 設定を確認する

   Configに戻り、現在有効なファイルを確認します。そのファイルの編集画面を開き、[General]内のdns-serverを確認してください。変更は複製したファイルでこの項目だけに行い、サーバー認証や通信パラメータは同時に変更しないでください。

5. 再テストする

   変更を保存し、その設定が使用されていることを確認します。接続を切断してから再接続し、同じURLにアクセスしてください。再接続しても、すべてのアプリのキャッシュが消えるとは限りません。必要であればブラウザーを終了して開き直し、結果が安定して変わったか記録します。

6. 設定を元に戻す

   Global Routingを元の値に戻します。テスト中に接続が自動で復旧する場合は、Settings → On Demandを確認して元の設定を記録してください。一時的に無効にして手動接続でテストし、終了後は必要に応じて元の状態に戻します。

以下はシステムDNSを使用する最小限の設定例です。項目の位置を確認するためのものであり、そのまま接続できる設定ではありません。編集時は既存の該当行を変更してください。テストのために[General]セクションを重複して追加したり、元の設定にある他の必須項目を上書きしたりしないでください。システムDNS自体に到達できない場合もあるため、この例が汎用的な解決策になるわけではありません。

[General]
dns-server = system

4. エラーの原文から名前解決エラーを見分ける

以下はDNSツールや診断ログでよく見られる応答コードとエラーメッセージです。Shadowrocketのすべての画面に同じ文言が表示されるとは限りません。ブラウザーの「サーバーが見つかりません」という表示だけでは、NXDOMAINとタイムアウトを区別できません。具体的なクエリ結果が確認できた場合に限り、該当する手順で対処してください。

5. DNSが正常な場合はルールとアドレスファミリーを確認する

Global RoutingのProxy、Direct、Config、Sceneは、リクエストの処理モードを選択します。ProxyとDirectは比較に使用でき、Configは現在の設定に従って処理し、Sceneは設定されたシーンに応じて実際の方式を決定します。これらを4種類のDNSスイッチと捉えることはできません。モードを切り替えて結果が変わった場合は、該当するリクエストのルールと通信経路も確認してください。

DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPの地理情報データベースに基づいて照合します。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ドメインルールの照合に、接続先IPアドレスの取得は必要ありません。IP関連のルールでは名前解決が必要になる場合があり、詳細はルールのオプションによって異なります。以下は構文の例です。既存のルールをそのまま置き換えないでください。

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

• no-resolveは、このIPルールだけを適用するためにドメイン名を解決するのを避ける設定です。DNS全体を無効にするものではありません。
• ルールの順序によって適用結果が変わります。Configでは特定のドメインにアクセスできず、Proxyでは開ける場合は、先行するルールによって異なる経路に振り分けられていないか確認してください。
• Aレコードは利用できるのに、AAAAレコードに対応する経路で問題が起きる場合は、現在のネットワークとサーバーのIPv6対応状況を確認します。元の値を保存したうえでIPv4のみを使う比較テストを行うことはできますが、IPv6の無効化をあらゆる問題への決まった対処法にしないでください。
• サーバーアドレスをドメイン名で指定している場合、その名前解決も必要です。サーバーアドレスをIPに変更すると、TLS検証、SNI、サービス事業者による接続先の振り分けに影響する場合があります。利用中のサービス事業者から提供されたパラメータに従ってください。

6. よくある質問と確認終了の目安

確認を終える目安は3つです。同じURLを繰り返し開けること、Global Routingが普段使うモードに戻っていること、再接続後も結果が変わらないことです。「Wi-FiでシステムDNSのクエリがタイムアウト。テスト用の複製を変更して復旧し、Configモードでも再テスト済み」のように、簡潔な記録を残すことをおすすめします。「DNSを変えたら直った」だけでは、再発時にネットワークの問題か設定の上書きかを見分けにくくなります。

• 問い合わせる場合は、開けないドメイン、発生時刻、Wi-Fiまたはモバイル通信の別、Global Routingの選択肢、個人情報を伏せたエラーメッセージを伝えてください。
• DNSでアドレスを取得できても、その後のハンドシェイクに失敗する場合は、利用中のサービス事業者から提供されたPort、TLS、通信パラメータを確認してください。
• 変更しても効果がない場合は、保存しておいた元の設定に戻し、一時的なテスト項目を長期設定として残さないでください。