Shadowrocketの遅延値が正常でも、Webページへの接続が最後まで成功するとは限りません。利用中のサービスやサブスクリプションがある場合は、ネットワーク、対象URL、接続先を固定してから、DNSの名前解決、Global Routing、接続エラーを確認します。名前解決の失敗、ルールの選択ミス、接続先への接続失敗を再現性のある手順で切り分け、毎回一項目だけ変更しましょう。DNSを何度も切り替えて、本当の原因を見えにくくしないことが大切です。
1. 遅延テストが正常でも、確認できるのはテスト対象の応答だけ
Webページを表示するには、ドメイン名の名前解決、接続の確立、TLSハンドシェイク、コンテンツの取得が必要です。DNSはドメイン名をIPアドレスに変換しますが、アドレスを取得できても、接続先のポート、ネットワーク経路、証明書、サーバーの状態によって接続できないことがあります。遅延テストは対象や方法が異なり、確認する範囲も同じではありません。表示されたミリ秒の数値だけでWebサイトが使えるかどうかは判断できません。
この流れは問題の切り分けに使うもので、すべてのリクエストが必ず同じ順序で処理されるという意味ではありません。ドメインルールはIPアドレスの取得前に適用される場合があり、接続方式によってはドメイン名を接続先に渡して処理することもあります。すべてのドメインが同じDNSサーバーで名前解決されると決めつけず、現在の設定とリクエスト記録を確認してください。
- サーバーアドレスに接続できる：テスト対象のアドレスとポートが応答したことを示すだけで、任意のWebサイトにアクセスできるとは限りません。
- 特定のテスト用URLを開ける：その時点で対象サイトにアクセスできたことを示すだけです。ほかのドメインは異なるルールやアドレスファミリーを使う場合があります。
- Webページの読み込みが終わらない：DNSの応答待ちだけでなく、接続、ハンドシェイク、ページ内リソースのタイムアウトも考えられます。エラー内容を確認してください。
2. DNS設定を確認し、ポートと名前解決サーバーを混同しない
まずConfigで現在選択している設定を確認し、その中のDNS設定を見ます。設定ファイルの[General]セクションにはdns-serverを指定できます。systemはシステムDNSを使う設定です。ほかの名前解決サーバーが設定されている場合は、変更前に元の値を控え、セクション全体を上書きしないでください。
[General]
dns-server = systemこの記述は設定項目を見分けるためのもので、完全な設定例でも、すべてのネットワークでsystemに変更する指示でもありません。システムDNSの応答は接続中のネットワークに左右されます。カスタムDNSを使う場合は、指定したアドレスと通信経路に到達できる必要があります。暗号化DNSは問い合わせの通信を保護しますが、接続先のWebサイトへの接続を保証するものではありません。
上記は各プロトコルで一般的に使われるポート番号で、Add Serverのサーバー追加画面に順番に入力する値ではありません。接続先サーバーのPortは、サービス提供元から案内された値と一致させてください。DoHはHTTPSのリクエストパスを使うため、IPアドレスだけの文字列を完全なDoHアドレスとして指定することはできません。
まず名前解決の結果を確認し、DNSを変更するか判断する
同じリクエストで対象IPアドレスを取得した後に接続がタイムアウトした場合は、まず接続先への経路とポートを確認します。DNSの問い合わせ失敗、想定外のアドレス、アドレスファミリーの違いなど、根拠がある場合にDNSの調査を続けてください。
3. 5つの手順で再現可能な調査記録を作る
普段アクセスでき、現在は安定して問題を再現できるURLを1つ選びます。完全なドメイン名、テスト時刻、接続中のネットワーク、エラーメッセージを記録してください。ネットワーク、接続先、DNS、ルールを同時に切り替えると、ページが表示されても何が影響したのか判断できません。
- ネットワーク接続が完了していることを確認します。認証ページが表示されるネットワークでは、信頼できる環境で認証を済ませてください。接続スイッチをオフにした場合とオンにした場合の結果をそれぞれ記録します。この比較は問題の範囲を絞るためのもので、どちらの状態でもすべての接続先にアクセスできる必要はありません。
- 現在の接続先を確認します。Homeに戻り、接続スイッチと選択中の項目を確認してください。Subscribeから追加した項目の場合、リンクは利用中のサービス提供元から入手します。サブスクリプションの状態と項目のパラメーターを確認し、更新が成功していてもサーバーに接続できるとは限らないことに注意してください。
- ルーティングの状態を記録します。Home → Global Routingを開き、Config、Proxy、Direct、Sceneのどれが選択されているか記録してください。Sceneでは適用条件も確認します。名前だけで実際の接続経路を判断しないでください。
- 条件を変えずにリクエストを1回送信します。同じURLにアクセスし、確認できるリクエスト記録やログで、ドメイン名、解決されたアドレス、適用ルール、接続ポリシー、エラーメッセージを確認します。記録されていない項目は不明として扱い、推測で補わないでください。
- 一項目だけ変更して再テストします。ほかの条件を保ったままConfigとProxyを比較する、または現在のDNSと到達可能と確認済みの名前解決方法を比較するなど、変更は一度に一つだけにしてください。毎回結果を記録し、改善しなければ元の値に戻してから次の仮説を確認します。
4. エラーから名前解決・接続・証明書の失敗を見分ける
以下はネットワークログで見られることのあるエラー文字列の例で、すべての画面に必ず表示されるとは限りません。同じ問題でも、ブラウザーの警告、リクエスト記録の短いエラー、詳細ログなど、表示のされ方は異なります。エラーに関連するドメインも確認してください。対象はWebサイトだけでなく、接続先サーバーやDNSエンドポイントの場合もあります。
エラー：no such host
原因：現在の名前解決で必要なホストアドレスを取得できていないか、ドメイン名に誤りがある可能性があります。
対処：まずエラーに表示されたドメイン名を確認し、使用中のDNSに到達できるか調べます。接続先サーバーのドメインで発生している場合は、対象Webサイトのルールを変更するのではなく、そのドメインの名前解決を先に解決してください。
エラー：i/o timeout
原因：ネットワークの読み書きがタイムアウトしています。DNS問い合わせ中、接続中、またはその後のデータ転送中に発生することがあります。
対処：エラーの直前に記録されたアドレスと処理段階を確認してください。DNS問い合わせのタイムアウトなら名前解決の経路を、接続タイムアウトなら接続先アドレス、Port、現在のネットワークを確認します。
エラー：connection refused
原因：接続が拒否されています。接続先ポートでサービスが待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく見られます。
対処：拒否された接続先がWebサイトか接続先サーバーかを確認し、該当するポートを調べます。サービス提供元から案内された接続パラメーターの場合は、提供元に状態を確認してください。
エラー：certificate has expired or is not yet valid
原因：証明書の有効期間と現在時刻が一致していません。デバイスの時刻、Webサイトの証明書、接続先のTLSエンドポイントが関係している可能性があります。
対処：まずシステムの日付と時刻を確認し、次にエラーに関連するドメインを特定してください。証明書の検証は維持し、検証を無効にして問題を回避しないでください。
WebサイトからHTTP 403またはHTTP 404が返ってきた場合、通常は対象のリクエストがHTTPサービスまで到達しています。その応答を単純なDNSの名前解決失敗とみなすことはできません。対象アドレスが正しいか、サイトへのアクセス条件やサーバーの状態を確認してください。誤ったサーバーに名前解決されている可能性がある場合は、DNSの応答も確認します。
5. 名前解決できた場合はルールとIPv6の経路を確認する
Configを使っている場合、リクエストは設定内のルールに従います。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲を対象とします。GEOIPはIPアドレスの地域判定に依存し、FINALは最後に適用されるフォールバックルールです。名前解決できていても、リクエストが想定した接続先を通るとは限りません。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY上記はルールの順序を示す例です。example.comとそのサブドメインにはDIRECTを適用し、それ以外のリクエストにはFINALでPROXYを適用します。これは完全な設定でも、すべてのユーザーに適した推奨ルールでもありません。対象ドメインが前段のREJECTルールに一致する場合、DNSを変更しても通常はルールの判定結果は変わりません。
| 症状 | 優先して確認する項目 | 次の操作 |
|---|---|---|
| Proxyではアクセスできるが、Configではできない | 現在の設定にあるルール、ポリシー、関連する上書き設定 | 対象ドメインに適用されたルールと実際の接続先を確認し、DNSが原因だと決めつけない。 |
| 同じ設定でもネットワークによって結果が異なる | ネットワーク認証、DNSサーバーへの到達性、UDPおよびアドレスファミリーの経路 | URLと接続先は変えず、接続するネットワークだけを切り替えて違いを記録する。 |
| AとAAAAの両方が返るが、一部の接続がタイムアウトする | IPv4とIPv6の実際の到達性 | 失敗した接続で使われたアドレスファミリーを確認し、一項目ずつ比較する。 |
| トップページは開くが、画像やログインが失敗する | リソースのサブドメインと、そのルール、名前解決、接続先 | 読み込みに失敗したリソースのドメインを記録し、サイトのドメインだけでなく個別に確認する。 |
AレコードはIPv4アドレスを、AAAAレコードはIPv6アドレスを返します。DNSから正しいAAAAレコードが返っても、現在のネットワークでIPv6が使えるとは限りません。また、IPv6アドレスがあるだけで、それが原因とは判断できません。比較結果からアドレスファミリーの違いが原因と考えられる場合に限り、関連するIPv6設定を確認し、元に戻す方法も確保してください。
見落としやすい要素にキャッシュがあります。ブラウザー、システム、中継するDNSサーバーが結果を保持している場合、DNSを変更して一度ページを再読み込みしても、新しい問い合わせが行われたとは限りません。まず接続を確立し直してページを開き、新しいリクエスト記録も確認してください。閲覧データをすべて消去するのは最初の手段にしないでください。
6. よくある質問と復元時の確認
遅延が数十ミリ秒なのに、なぜ接続先も確認する必要があるのですか？
遅延の数値は、任意のWebサイトへのリクエスト全体を確認するものではありません。Homeに戻って選択中の項目を確認し、アクセスできないURLでどの接続段階が失敗しているか記録してください。テスト対象に接続できても、Webサイトの443番ポートに到達できないことはあり、両方の現象が同時に起きる場合もあります。
URLをIPアドレスに置き換えれば、DNSの問題かどうか分かりますか？
それだけでは判断できません。HTTPSでは証明書の検証やバーチャルホストの選択にドメイン名が使われるため、IPアドレスに直接アクセスすると証明書エラーになったり、別のサイトが表示されたりすることがあります。IPアドレスへのアクセスに失敗したことをDNSの問題と結論づけず、名前解決と接続の記録を確認してください。
DNSを変更しても開かない場合、さらに変更すべきですか？
まずIPアドレスを取得できているか確認します。取得後にタイムアウトする場合はDNSを元に戻し、Global Routing、実際の接続先、Portを確認してください。DNS問い合わせ自体がタイムアウトする場合は、名前解決の通信経路を調べます。
サブスクリプションの更新だけ失敗し、Webページは開けます。DNSを変更すべきですか？
まず、サブスクリプションのドメイン名を解決できないのか、HTTPステータスエラーなのかを切り分けます。リンクは利用中のサービス提供元から入手し、URLが完全にコピーされているか、有効な状態かを確認してください。Webページが開けてもサブスクリプションのURLが正常とは限りませんが、それだけでDNS全体の問題とも判断できません。
復旧後は、普段使うConfig設定と想定するポリシーに戻し、On Demandの条件も元に戻してから、トップページ、画像、ログインなど必要なリソースを再テストしてください。一時的にProxyへ切り替えたときだけ成功する場合は、ルールの見直しを続けます。一時的な比較結果だけでDNSの原因が特定できたと判断しないでください。
- 動作確認済みの設定をバックアップし、最終的に変更した項目を記録してください。
- サービス提供元に問い合わせる際は、発生時刻、ネットワークの種類、プロトコル、対象ドメイン、エラーメッセージを伝えてください。
- ログを共有する前に、サブスクリプションのtoken、UUID、パスワード、認証情報全体を伏せてください。サブスクリプションURLをそのまま公開する必要はありません。