遅延の数値だけでは、WebサイトのDNS、接続、TLSがすべて正常とは判断できません。自分で用意したサーバーやサブスクリプションを利用中にWebサイトが開けなくなった場合は、まずテスト条件を固定し、DNSの応答を確認してから、Global Routingとルールの記録で名前解決と通信経路の問題を切り分けます。一度に変更する項目は一つにし、復旧に役立った元の設定は記録しておきましょう。
01 遅延が正常でもWebサイトへの接続が正常とは限らない
Shadowrocketのサーバーテストと、ブラウザで特定のドメインにアクセスする操作は、同じリクエストではありません。テスト方法によって確認できる範囲も異なります。サーバーのポートに接続できても、対象ドメインの正しいアドレスが取得できたとは限りません。また、テスト先が応答しても、別のWebサイトのすべてのリソースにアクセスできるとは限りません。
通常のWebアクセスは、以下の確認ポイントに分けて考えられます。実際にはルール判定とDNS検索が前後することもあります。たとえばドメインルールは先に照合できますが、IPルールの判定には名前解決の結果が必要になる場合があります。以下の流れは問題箇所を特定するための目安であり、アプリ内のすべてのリクエストが必ず同じ順序で処理されるという意味ではありません。
- サーバーが見つからない：ブラウザの表示だけでサーバーが利用できないと判断せず、ドメインの綴りとDNSの応答を確認してください。
- 待機が続いたあとタイムアウトする：名前解決、接続、接続先からの応答のいずれもタイムアウトする可能性があります。記録を確認して原因を切り分けましょう。
- 証明書の警告が表示される：端末の時刻、ドメイン、証明書の情報を確認してください。証明書の検証を無効にして解決しようとしないでください。
- 本文は表示されるが画像が出ない：ページのリソースが別のドメインから読み込まれている可能性があります。アドレスバーのドメインだけでなく、読み込みに失敗したリクエストを個別に確認してください。
02 状況を記録してから Settings → DNS を確認
Homeで現在のサーバーとGlobal Routingの選択内容を記録し、Configで使用中の設定を確認します。次にSettings → DNSを開き、現在のDNS設定を記録してください。設定ファイルにDNS関連の項目がある場合は、そちらも確認します。1つの画面だけを見ていると、設定ファイルが名前解決に与える影響を見落とすことがあります。
ここでは各設定の役割を説明します。特定の構成での初期値を、すべての端末に共通する初期値として扱わないでください。具体的な項目や選択肢は、現在のアプリ画面で確認してください。見るべき点は「どこに問い合わせるか」「どう接続するか」「検索結果がローカルで指定されていないか」です。すべてのスイッチを同時にオンにする必要はありません。
| 確認対象 | 役割 | 確認する内容 |
|---|---|---|
| DNSサーバー | ドメインの問い合わせを受け取り、結果を返す | アドレスが正しく入力されているか、現在のネットワークからそのサービスに接続できるか。 |
| DNSクエリの通信方式 | 問い合わせの送信方法を決める | 通常のDNSと暗号化DNSではアドレスの形式が異なります。ポート番号を変更しただけで通信方式も切り替わったと考えないでください。 |
| ローカルマッピング | 特定のドメインにアドレスを指定する | 古いアドレスが残っていないか、特定のWebサイトに無効なアドレスを固定していないか。 |
| 設定ファイル内のDNS項目 | 現在の設定での名前解決に関係する | 現在有効なConfigが変更したファイルと同じか、設定の重複や競合がないか。 |
| IPv4 / IPv6 | 異なるアドレスファミリーやネットワーク経路に対応する | AAAAレコードが返っても、現在のネットワークからIPv6で外部接続できるとは限りません。 |
以下はプロトコルで一般的に使われるポート番号です。Shadowrocketに入力する推奨値ではありません。サービスによっては標準以外のポートを使うため、自分が利用しているDNSサービスの実際の設定を確認してください。暗号化DNSでも接続を確立する必要があり、誤ったルーティングや利用できないサーバーが自動的に直るわけではありません。
ポイント：まず問い合わせ先に接続できるか確認し、次に応答が正しいかを調べる
現在のDNSサービスに接続できない場合は、記録しておいた利用可能な設定に戻してください。アドレスが返っている場合は、そのアドレスへの通信経路を確認します。「DNSの応答があること」と「Webサイトが開けること」は別々に確認しましょう。
03 同じドメインで再現可能なテストを行う
実際に開けない完全なURLをテスト対象にし、発生時刻と使用中のネットワークを記録します。Wi-Fiを切り替えながらサーバー、DNS、ルールも変更すると、アクセスが復旧しても、どの変更が効果をもたらしたのか分からなくなります。
- 現在の設定を保存：Homeのサーバー、Global Routing、Configファイル、Settings → DNSの内容を記録します。設定ファイルを編集する前にコピーを保存してください。
- 基準となる状態を記録：設定は変更せず、同じURLにもう一度アクセスして、そのリクエストに対応する接続記録やログを確認します。ドメイン、名前解決の結果、適用されたルール、ポリシー、エラー情報を確認してください。表示される項目は実際の記録に従います。
- 応答とタイムアウトを区別：DNSの応答コードが表示されている場合は、まずそのコードを確認します。応答がなく待機がタイムアウトした場合は、DNSサービスへの接続状況を確認してください。タイムアウトだけでドメインが存在しないとは判断できません。
- DNSだけを変更：自分で利用可能と確認したDNS設定がある場合は、一時的に切り替えて比較できます。保存後に接続し直し、同じURLにアクセスしてください。それ以外の条件は変更しないでください。
- キャッシュの影響を再確認：ページを再読み込みしても、既存の接続やキャッシュが使われることがあります。必要に応じて該当ページを閉じ、ブラウザを終了してから開き直してください。再接続しても、すべてのアプリのキャッシュがすぐに消えるとは限りません。
- 設定を戻して再テスト：改善しない場合は元のDNS設定に戻し、ルールと外向きの通信経路を確認してください。変更によって改善した場合も、もう一度テストして一時的な復旧を設定の修正と取り違えないようにしましょう。
04 DNSエラーを読み解き、すべてのタイムアウトを名前解決の失敗と決めつけない
以下はDNSの応答コードとシステムのネットワークエラーで使われる表記です。Shadowrocketで毎回同じ文言が表示されるとは限りません。ブラウザでは簡略化されたメッセージが表示されることもあります。診断結果やログに実際に該当する内容が記録されている場合に、その内容に沿って対処してください。
DNS応答：NXDOMAIN
原因：この応答は、問い合わせたドメインが存在しないことを示します。問い合わせ名が間違っている場合や、異常な応答が返された場合にも発生することがあります。
対処：まず完全なドメイン名と綴りを確認し、自分で利用可能と確認した別の名前解決経路と比較してください。異なる経路でも同じ結果が返る場合は、Webサイトの管理者にドメインの状態を確認します。
DNS応答：SERVFAIL
原因：DNSサーバーが今回の問い合わせを完了できませんでした。上流の名前解決、権威DNSサーバー、検証処理などが関係している可能性があります。
対処：ドメイン名と発生時刻を記録し、利用可能と分かっている別の名前解決経路で再テストしてください。この応答はドメインが存在しないことを意味するものではありません。また、これを理由にTLS検証を無効にしないでください。
システムエラー：The request timed out.
原因：リクエストが制限時間内に完了しなかったことを示します。このメッセージだけでは、DNS、接続、Webページの応答のどの段階でタイムアウトしたか分かりません。
対処：タイムアウト前に名前解決の結果や接続記録があったか確認してください。応答がない場合は問い合わせ経路を確認し、アドレスが返っている場合はポリシー、サーバー、対象サイトへの接続を調べます。
記録に有効なアドレスがあり、その後に接続失敗が表示されている場合は、外向きの通信経路を重点的に確認します。反対に、名前解決の結果が一度もないなら、Webのプロトコルを何度も切り替えたりFINALを変更したりしても、問題箇所に届かないことがあります。
05 Global Routingを比較し、Configのルール適用を確認
Home → Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なるルーティング方法です。トラブルの確認を始める前に、現在の選択内容を記録してください。Sceneを使っている場合は、そのシーンで実際に適用されている動作も確認します。接続がオンになっているだけで、Webサイトへの通信が選択中のサーバーを経由すると決めつけないでください。
同じネットワーク、同じサーバー、同じURLを使い、ConfigとProxyを一時的に比較できます。ProxyではアクセスできるのにConfigでは失敗する場合は、ルールの適用状況と設定の違いを優先して確認してください。ただし、この比較だけで原因を特定できるわけではありません。ルーティングの変更でDNS問い合わせの到達経路も変わることがあるため、記録もあわせて確認します。
| 比較結果 | 次に確認する項目 |
|---|---|
| Proxyではアクセスできるが、Configでは失敗する | 対象ドメインにDIRECT、REJECT、または誤ったポリシーが適用されていないか確認し、名前解決の結果も比較してください。 |
| Directではアクセスできるが、Proxyでは失敗する | 選択中のサーバーで実際に通信できるか、リモートでの名前解決と対象サイトへの接続を確認してください。遅延の数値だけで判断しないでください。 |
| 複数のルーティング方法で失敗する | ドメインの状態、DNSの応答、現在のネットワーク、Webサイト自体を確認してください。Configのルールが原因だと決めつけないでください。 |
| ネットワークを変えると復旧する | 2つのネットワークでDNSへの接続状況、IPv6の経路、接続制限を比較します。それ以外の設定は一時的に変えずに確認してください。 |
以下はルールの構文と順序の例です。予約済みのサンプルドメインを使っており、あらゆるWebサイトの問題を解決する設定ではありません。この2行でConfig全体を置き換えず、既存のルール欄で該当する項目を確認してください。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXはドメインのサフィックスで照合します。この例ではexample.comとそのサブドメインが対象になります。IP-CIDRとGEOIPはIPアドレスの条件で判定されます。実際に名前解決されたアドレスと、設定内の名前解決に関する制御項目を確認してください。- ルールは記載順に照合され、一致すると該当するポリシーが適用されます。より前に一致するルールがある場合、新しいルールを後ろに追加しても結果が変わらないことがあります。
FINALは、それ以前のルールに一致しないリクエストに適用されるフォールバックです。PROXYに変更すると、フォールバック対象のすべてのリクエストに影響します。単一ドメインの名前解決に失敗した際の標準的な対処として変更しないでください。
比較が終わったら、普段使っているGlobal Routingに戻してください。設定変更が原因の場合は、該当する変更を元に戻してから項目を一つずつ確認します。利用中のサブスクリプションの更新は主にサーバー情報を更新するもので、現在のConfig内のDNSやルールを修正するものではありません。別々に確認してください。
06 よくある質問と診断情報の共有
遅延がとても低いのに、一部のWebサイトだけ開けないのはなぜですか？
遅延テストでは、個々のWebサイトや各リソースのドメインまですべて確認できるわけではありません。開けないURLを記録し、Configで実際に適用されたポリシーを確認してからProxyと比較してください。画像の読み込みやログインだけに失敗する場合は、該当するリソースのドメインも調べます。同じサーバーポートを何度もテストするだけでは解決につながりません。
DNSを変更したら復旧しました。変更したままにするべきですか？
まず同じネットワークで再テストし、元のDNSがタイムアウトしたり異常な応答を返したりしていないか確認してください。新しい設定が安定しており、自分が利用しているサービスの設定にも合っているなら、そのまま使うこともできます。元の値も記録しておきましょう。一度の成功だけでは、キャッシュ、一時的なWebサイトの障害、ネットワーク切り替えの影響を除外できません。
Wi-Fiではつながらず、モバイル通信では正常です。IPv6をオフにすべきですか？
まず、名前解決で取得したAレコードとAAAAレコード、および実際の接続状況を比較してください。AAAAの応答があってもIPv6の経路が使えるとは限りませんが、IPv6を常に無効にすべきという意味でもありません。関連設定を変更する場合は、ほかの条件を変えずに一度比較し、結果を記録するか元の値に戻してください。
接続をオフにしても自動で再接続します。切断状態を比較するにはどうすればよいですか？
Settings → On Demandを開き、オンデマンド接続が有効になっているか確認します。現在の状態を記録してから一時的に無効にし、切断した状態で比較してください。テスト後は必要に応じて元の設定に戻します。On Demandは接続を開始する条件を制御する機能であり、DNSの応答やルールの内容を修正するものではありません。
さらにサポートが必要な場合は、遅延の数値だけでなく、再現できる条件を共有すると原因を特定しやすくなります。記録にサブスクリプションのURL、サーバーの認証情報、個人のリクエスト情報が含まれる場合は、機密情報を隠し、問題の特定に必要な項目だけを共有してください。
- 端末の種類、現在のネットワークの種類、特定のネットワークだけで発生するかどうか。
- アクセスに失敗するドメイン、発生時刻、Global Routingの選択内容、使用中のConfig。
- DNSの応答の有無と応答コード、その後に接続が確立したかどうか。
- 適用されたルールのポリシー、ConfigとProxyの比較結果、元に戻した設定変更。