ShadowrocketのDNS設定とトラブル対処｜遅延は正常なのにWebページが開けない場合

1. 遅延テストとWebアクセスを区別する

遅延テストで分かるのは、そのテスト方法で確認できる通信経路が、その時点で応答したことだけです。エラーが出ているWebサイトにアクセスしているとは限らず、ブラウザのリクエストで行われる名前解決や接続のすべてを確認できるとも限りません。そのため、遅延が表示されていても、ドメイン名の名前解決、ポリシーの選択、TLSハンドシェイク、Webページのリソース読み込みで失敗することがあります。

まず、失敗したドメイン名、発生時刻、接続中のネットワーク、HomeのGlobal Routingを記録します。「どのWebページも開けない」と一括りにせず、具体的にテストしてください。同じページでも、メインサイト、画像用ドメイン、ログイン用APIなどに接続する場合があります。メインページは表示されるのに一部のリソースだけ失敗するケースと、メインドメインをまったく名前解決できないケースは別の問題です。

2. Home、Config、On Demandのテスト条件をそろえる

トラブル対処を始める前に、現在の設定を複製または書き出してバックアップし、元のGlobal Routingも記録してください。この記事では、設定内のルールを確認するため、主にConfigで切り分けます。ProxyとDirectは短時間の比較に使えますが、それだけでDNSが正常か異常かを判断することはできません。Sceneも条件を記録しないまま比較するのには適しません。現在のSceneでどのような動作になるか、先に確認してください。

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

   Home → Global Routingを開き、現在の設定がConfig、Proxy、Direct、Sceneのどれかを記録します。現在選択されている既存のサーバーも控えてください。テスト中はサーバーとDNSを同時に変更しないでください。

2. 有効な設定を確認する

   Configを開き、現在選択されている設定ファイルを確認します。そのファイルの右側にある情報ボタンからEdit Plain Textを開き、まだ選択されていないファイルではなく、実際に保存されている[General]と[Rule]の内容を確認してください。

3. 自動接続を確認する

   Settings → On Demandを開き、有効かどうかと設定済みの条件を記録します。接続を切っても自動的に再接続する場合は、まずここを確認してください。一時的に無効にする場合は変更前の状態を控え、テスト後に元に戻します。

4. 変更する項目は一度に一つ

   同じWi-Fiまたはモバイル通信に接続したまま、Home → Global Routing → Configの状態で同じドメイン名に繰り返しアクセスします。設定を変更するたびに保存して再接続し、新しいリクエストを実行して結果を記録してください。

特定のWi-Fiでのみ問題が起きる場合は、そのネットワークでWeb認証が必要かどうかも確認してください。認証が完了していないと、DNSリクエストやHTTPS接続が制限されることがあります。その場合、ルールを何度編集してもネットワーク認証は完了しません。ネットワークを切り替えて比較する場合は、独立したテストとして行い、ほかの設定変更と同時に実施しないでください。

3. DNS設定で確認する項目

DNSの上流サーバーはドメイン名に対応するアドレスを返し、ルールはリクエストに使うポリシーを選択します。両者は別の設定です。現在の設定ファイルの[General]にあるdns-serverでDNSサーバーを指定します。まず実際の値、アドレス形式、到達可能性を確認してから、変更を検討してください。見慣れたアドレスだからといって、現在のネットワークで利用できるとは限りません。

以下は設定項目の位置を確認するための最小限の例であり、設定全体を置き換えるテンプレートではありません。DNSの上流サーバーにシステムが提供するサーバーを指定するため、条件を明確にして比較できますが、すべてのネットワークに適しているとは限りません。編集時は既存の項目を変更し、ほかの設定を残してください。同じ名前の項目を重複して追加しないでください。

[General]
dns-server = system

ドメイン名を含む暗号化DNSのエンドポイントを使う場合は、上流サーバーのドメイン名を最初にどう名前解決するか、エンドポイントに接続できるかも考慮します。暗号化で変わるのはクエリの転送方法です。正しい名前解決結果やWebサイトへの接続が保証されるわけではありません。上流サーバーへの接続自体に失敗している場合は、アドレスを追加して問題を覆い隠すのではなく、まず上流サーバーへの到達性を確認してください。

• 現在使用中の設定ファイルだけを編集してください。リモート設定を再度更新した後は、ローカルでの変更が保持されているか確認します。
• WebサイトのURL、サブスクリプションリンク、サーバー接続パラメータをdns-serverに入力しないでください。
• IPv6の問題は、同じネットワーク上で条件を比較して切り分けます。IPv6を恒久的に無効にすることを、あらゆる名前解決問題に共通する解決策と考えないでください。

4. ルールの適用状況からDNSとルーティングの問題を切り分ける

Global RoutingがConfigの場合、ルールの順序によって最終的なポリシーが変わります。一般に、より具体的なドメインルールを先に確認し、次にアドレスルールと末尾のFINALを確認します。ドメイン名を正しく名前解決できても、リクエストが利用できない経路に振り分けられることがあります。この場合、DNSを変更してもポリシーの誤りは直接解決しません。

以下の例はルールの構文を示すもので、例示のドメイン名や文書用アドレスは特定のサービスを表しません。全体をコピーして既存のルールと置き換えないでください。自分の設定内に同種の項目があるか確認し、接続ログと照らし合わせて適用状況を確認します。特にFINAL,DIRECTは、この例における最終ポリシーを示すだけで、一般的な推奨値ではありません。

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

5. 実際のエラーに応じて次の確認を行う

エラーは、発生した処理段階とあわせて確認してください。以下はDNS応答やネットワークログに表示される可能性がある原文であり、Shadowrocketが障害のたびに必ず表示する固定メッセージではありません。実際の記録に該当する文言がある場合に限り、対応する内容を参考にしてください。ブラウザの「ページを開けません」という一般的な表示だけで、NXDOMAINと判断することはできません。

証明書エラーが発生した場合は、端末の時刻、アクセス先のドメイン名、証明書の名称、HTTPS接続環境を確認してください。証明書検証を無視してDNSの「修復」を試みないでください。本文は表示されるのに画像が読み込めない場合は、画像リソースのドメイン名に関するルールと名前解決を個別に確認します。メインサイトだけを繰り返しテストしないでください。

• 特定のドメイン名だけ失敗する：スペル、該当ドメイン名のDNS応答、個別ルールを確認し、Webサイト自体に障害がないかも調べます。
• 同じネットワークで広く失敗する：認証状態、システムDNS、上流サーバーへの到達性を確認します。ネットワークを切り替える場合は、ほかの条件を変えずに比較してください。
• 名前解決できるのに接続できない：名前解決先を繰り返し変更するのではなく、アドレスへの到達性、IPv4 / IPv6の経路、ポリシー、TLSを確認してください。
• 変更後に一時的に復旧する：キャッシュの期限切れ、再接続、設定変更それぞれの影響を区別してください。一度成功しただけでは根本原因を特定できません。

6. 再テスト、設定の復元、調査記録

DNSを変更しても、既存の接続がすぐに再名前解決するとは限りません。ブラウザやシステムにキャッシュが残っている場合もあります。設定を保存して再接続した後、新たにアクセスしてください。必要に応じて、開いていたページを閉じてから再度開きます。古いページを何度も再読み込みして別個の再テストの代わりにしないでください。また、再接続ですべてのアプリのキャッシュが消えるとは限りません。

アクセスが復旧したら、一時的な変更を一つずつ元に戻し、繰り返し比較して効果を確認できた設定だけを残します。特に、On DemandとGlobal Routingは元の状態に戻してください。トラブル対処後も一時的なProxyやDirectのままにしないよう注意します。設定を再更新した場合は、有効な設定ファイルと関連項目に変更がないか確認してください。

利用中のサービスの提供元やサポート窓口に記録を送る前に、サブスクリプションの完全なリンク、token、UUID、パスワードなどの認証情報を伏せてください。設定ファイル全体をそのまま公開しないでください。この記事ではクライアントのトラブル対処方法を説明しますが、サーバーやサブスクリプションの提供、販売、推奨は行いません。クライアントの買い切りと通信サービスの契約は別です。