この記事は、Shadowrocketで利用するサービスと接続情報を設定済みなのに、遅延テストには結果が表示されてもWebサイトを開けない場合に役立ちます。サーバーへの接続、DNSの名前解決、Webサイトへのアクセスを切り分け、ConfigのDNS設定、Global Routing、ルールを確認しましょう。一度に変更するのは1項目だけにし、同じドメインで再テストします。ルールによるブロックや通信経路の問題をDNS障害と誤認しないためです。
1. 遅延テストに結果が出ても名前解決に失敗する理由
Home → Connectivity Testの結果は、選択中のテスト方式によって異なります。テスト対象がサーバーへの接続だけの場合もあれば、テスト用の宛先にアクセスする場合もあります。どちらの場合も、すべてのWebサイトでDNS、TLS、ページ内のリソースが正常に動作することを示すものではありません。サーバーのアドレスがキャッシュ済みなら、そのアドレスを再度名前解決せずにテストできることもあります。
新しいドメインを開くと、通常はまずアドレスを問い合わせ、実際に適用されるルールに従って接続し、その後TLSハンドシェイクとHTTPリクエストを行います。以下はトラブルシューティング用に簡略化した流れです。ローカルで名前解決するか、どのタイミングで行うかは、ルールの種類や通信プロトコルによって異なります。
そのため、「遅延テストが正常」というだけでは一部の状況しか確認できません。DNSからアドレスが返されても接続がタイムアウトする場合は、通信経路を確認してください。DNSからアドレスが返らない場合は、まず名前解決を調べます。ページのテキストは表示されても画像を読み込めない場合、画像が使う別のドメインの名前解決に失敗している可能性があります。アドレスバーに表示されたドメインだけでなく、画像のドメインも確認しましょう。
確認ポイント：まず名前解決の結果を確認
AまたはAAAAレコードを取得できてもページが開かない場合、DNSを何度も変更する必要はありません。返されたアドレスを記録し、その接続に適用されたルールと通信経路を確認してください。ポートに到達できることだけでは、DNSサービス全体が正常とは限りません。
2. Configで使用中のDNS設定を確認する
まずConfigを開き、現在選択されている設定ファイルを確認します。選択されていない別のファイルを編集しても、現在の接続には反映されません。変更前にコピーを保存してください。自分で用意したリモート設定を使っている場合、後日の更新でローカルの変更が上書きされることがあります。
Configで現在のファイルを編集し、[General]内のdns-serverを確認します。ここでは名前解決に使うDNSサーバーを指定します。以下は最小限の構文例であり、既存の設定ファイルと置き換えて使える完全なファイルではありません。
[General]
dns-server = systemsystemはシステムが提供するDNSを使う設定です。通常は接続中のWi-Fiまたはモバイル通信の影響を受け、特定のパブリックDNSを固定して使う意味ではありません。ここに1つ以上のアドレスを指定している場合は、それぞれの入手元と到達性を確認してください。「予備」として、検証していないDNSの接続先を次々に追加しないでください。
- 設定値：スペル、区切り文字、重複した設定がないか確認します。WebサイトのURLを通常のDNSアドレスとして入力しないでください。
- 暗号化DNS：DNS over HTTPSとDNS over TLSでは、対応する形式と接続可能なエンドポイントが必要です。利用中のサービスが指定する正確なパラメーターを使ってください。ポートだけを443や853に変更しても設定できません。
- ドメインの固定設定：ファイルに
[Host]の項目がある場合、問題のドメインが古いアドレスに固定されていないか確認します。この設定があると、DNSサーバーを変更しても効果がないように見えることがあります。 - ドメイン指定のエンドポイント：暗号化DNSのエンドポイント自体がドメイン名で指定されている場合、最初の接続に必要な名前解決も行う必要があります。この依存関係を見落とさないでください。
3. 複数の条件を同時に変えず、決まった順序で再テストする
普段アクセスできる完全なドメインを1つ選び、比較用に別のサイトも用意します。テスト中はサーバーとネットワークを固定してください。Wi-Fi、サーバー、DNSを同時に変更すると、復旧しても何が効果をもたらしたのか分からなくなります。
-
状況を記録する
Homeで選択中のSERVER、現在のGlobal Routingの値、Connectivity Testの結果を記録します。問題のドメイン、ネットワークの種類、ブラウザーに表示された具体的なエラーも控えてください。スクリーンショットを共有する前に、アカウント情報とサーバー情報を隠します。
-
モードを確認する
Home → Global Routingを開き、Config、Proxy、Direct、Sceneのどれが選択されているか確認します。Sceneを使用している場合は、実際に適用中のシーンも確認してください。元の値を記録してから比較し、モードの切り替えだけを最終的な解決策にしないでください。
-
設定を確認する
Configで現在選択中のファイルを開き、
dns-serverと[Host]を確認します。変更するのは1項目だけにしてください。保存したらHomeに戻って再接続し、同じドメインを開きます。 -
自動接続を確認する
Settings → On Demandを開き、有効かどうかと関連する条件を記録します。テスト中に接続が自動で復旧する場合は、On Demandを一時的に無効にして比較を繰り返し、終了後に元の設定へ戻してください。On Demandは接続を開始する条件を制御するもので、DNSサーバーの設定ではありません。
-
ネットワークを切り替える
設定とSERVERは変えずに、Wi-Fiとモバイル通信の両方で再テストします。特定のネットワークだけで失敗する場合は、そのネットワークからDNSに到達できるか、ログイン認証が済んでいるか、ネットワーク制限がないかを優先して確認してください。
-
元に戻して確認する
不要な一時変更を元に戻し、再接続して2つのサイトをテストします。名前解決で期待どおりの結果が得られ、Webページを読み込めることが成功の基準です。Connectivity Testに再び数値が表示されるだけでは、解決したとはいえません。
ブラウザー、システム、DNSサーバーには、それぞれキャッシュがある場合があります。再接続するとテスト条件を明確にしやすくなりますが、すべてのキャッシュが消去されるわけではありません。比較時は同じ結果が再利用されていないか記録してください。任意のHTTPS数値アドレスへのアクセスをドメインのテストに代用すると、証明書や仮想ホストの違いが生じます。
4. 実際のエラーを3種類に分けて対処する
以下は、DNSプロトコルや診断出力に表示されることのある原文です。Shadowrocketのすべての画面に、必ずこの表記で表示されるわけではありません。ブラウザーには概要だけが表示される場合もあります。実際に記録された内容を確認し、Webサイトを開けないというだけですべて同じ原因と判断しないでください。
NXDOMAIN
原因：DNSサーバーがドメインの存在を確認できないと応答しています。ドメインの入力ミス、レコードの削除、DNS側のポリシーなどが原因として考えられます。
対処法：まず完全なドメイン名を確認し、利用できることが確認済みの別のDNSを使って比較します。特定のドメインだけでこの状態が続く場合は、ドメインの管理者にレコードを確認してください。
SERVFAIL
原因：DNSサーバーが問い合わせを完了できていません。上流の障害、権威DNSサーバーの停止、DNSSECの検証失敗などが考えられます。ドメインが存在しないという意味ではありません。
対処法：ネットワークと通信経路を変えず、利用可能な別のDNS設定で再テストします。このドメインだけで問題が起きる場合は、発生時刻と応答ステータスを記録して、関係する管理者に伝えてください。
timeout
原因：制限時間内に応答がありませんでした。DNSのエンドポイントに到達できない、パケットが破棄されている、暗号化DNSの接続を確立できないなどの可能性があります。
対処法：設定のアドレス、プロトコル、ポートが一致していることを確認し、別のネットワークでも比較してください。到達できない状態が続いているのに、待ち時間を延ばして問題を覆い隠さないでください。
問い合わせが完了しても、要求した種類のレコードが返らないことがあります。たとえばドメインにAレコードしかない場合、AAAAを問い合わせると、応答自体は成功していても該当するレコードがないことがあります。応答ステータスとレコードの種類を併せて確認し、「IPv6アドレスがない」だけでDNSサービスの障害と判断しないでください。
5. 名前解決が正常ならGlobal Routingとルールを確認する
Global RoutingのConfigは、現在の設定ファイルにあるルールに基づいて接続先を決定します。ProxyとDirectはそれぞれの全体的なルーティング方法として使われ、Sceneは設定済みのシーンに従って動作します。これらはDNSサーバーを選ぶ4つの項目ではありません。モードを切り替えてWebサイトが開くようになっても、通信経路の変更が結果に影響したことが分かるだけです。該当するルールや通信経路の違いをさらに確認してください。
Configで現在のファイルにある[Rule]を確認します。以下は構文説明用の例で、ドキュメント用のドメインと予約済みアドレス範囲を使っています。実際の設定に修正方法としてそのまま追加しないでください。FINAL,DIRECTはこの例のフォールバック動作を示すだけで、一般的な推奨設定ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTDOMAIN-SUFFIX：ドメインの末尾に基づいて照合します。対象のドメインがREJECTに一致している場合、DNSを変更してもブロックは解除されません。IP-CIDR：接続先のIPアドレス範囲に基づいて照合します。例のno-resolveは、このIPルールのために追加のドメイン名解決を行わない指定です。すでにIPアドレスがある場合も、照合条件と併せて判断してください。GEOIP：IPアドレスの地理情報に基づいて判定します。ドメインの末尾ではなく、接続先のIPアドレスによる判定です。返されるアドレスが変わると、照合結果も変わることがあります。FINAL：それ以前のルールに一致しなかった接続を処理します。設定ファイルにこの行があるかだけでなく、指定先のポリシーが想定どおりか確認してください。
通常、同じ接続ではルールが上から順に評価されます。そのため、先にあるブロックやポリシーの指定によって、後続のルールが適用されないことがあります。ルールセットを使っている場合は、実際の内容と更新状態も確認してください。設定ファイル本体でドメインが見つからないだけで、関連するルールがないと判断しないでください。
6. 修復を確認し、後から検証できる記録を残す
修復できたかどうかは、同じ条件で再現できるか確認します。ネットワーク、SERVER、設定ファイルを固定した状態で、問題のドメインが名前解決でき、想定した通信経路を通り、ページと必要なリソースを読み込めることが基準です。その後、必要なOn Demand設定を元に戻し、ネットワークを切り替えても正常か確認してください。
- 設定の記録：現在のファイル名、Global Routingの値、今回変更したDNS項目。
- 結果の記録：テスト日時、Wi-Fiまたはモバイル通信、問題のドメイン、A/AAAAの結果、実際に表示されたエラーの原文。
- 比較結果の記録：変更前に失敗し、変更後に成功した状態を再現できるか。元の値に戻しても成功する場合は、一時的なネットワークやキャッシュの変化が原因かもしれません。
- 情報の保護：利用中のサービス提供元に問い合わせる際、サブスクリプションURL全体、アクセストークン、パスワード、UUIDを公開しないでください。原因の特定に必要な情報だけを、機密部分を伏せて伝えます。
2つのDNSで正常にアドレスを取得できても、同じサーバーへのWeb接続に失敗する場合は、サーバーの稼働状況、TLS、通信経路の制限、ルールを確認してください。DNSアドレスを追加しても、これらの問題が自動的に解決するわけではなく、確認項目が増えるだけです。さらに切り分ける場合は、当サイトのトラブル対処と用語クイックガイドをご覧ください。
ShadowrocketはAppleプラットフォーム向けのクローズドソースの有料アプリです。主にiPhoneとiPadで利用でき、入手先はApp Storeのみです。開発元はShadow Launch Technology Limitedです。アプリは買い切りですが、アプリの購入と接続サービスの契約は別です。この記事では、利用者が自身で用意したサービスと設定を使用することを前提とします。システム要件はApp Storeの掲載内容をご確認ください。