Shadowrocketのテストに遅延時間が表示されても、アクセス先のドメイン名が正常に解決されたとは限りません。利用中のサービスとサブスクリプションがあり、現在の設定を確認できることを前提に、ネットワーク、Global Routing、DNS、ルール、接続ログを順に確認します。一度に変更する設定は1つにし、同じURLで再テストしてください。最後に、名前解決エラー、接続タイムアウト、TLSエラーを切り分けます。
1. 遅延テストが正常でもWebページが開けるとは限らない
Webページを開くには複数の段階があります。まずクライアントが対象ドメインに対応するアドレスを取得し、設定に応じて接続経路を選択します。その後、通信接続とTLSセッションを確立してからページの内容をリクエストします。名前解決は端末上で行われる場合も、リモート側で行われる場合もあります。いずれかの段階で失敗すると、ブラウザが読み込み中のままになることがあります。
HomeのConnectivity Testで確認できるのは、選択したテスト方法による結果です。テスト対象やプロトコルは、Webページへのアクセス先と異なる場合があります。数値が表示されても、すべてのドメイン、ポート、リクエストが利用可能だとは判断できません。
たとえば、テスト結果が80 msでも、ブラウザにサーバーが見つからないと表示されることがあります。この数値はあくまでそのテストの記録であり、失敗したドメインの名前解決結果を示すものではありません。確認の際は遅延時間を何度も比較するのではなく、URLのドメイン部分、エラーメッセージ、発生時刻を記録してください。
- 特定のサイトだけ開けない場合：ドメインの入力ミス、サイトの名前解決結果、適用されるルールを確認します。
- 複数のサイトが開けない場合：まずネットワーク接続、接続状態、共通設定を確認します。
- ページの枠組みは表示されるのに画像が読み込まれない場合：画像やスクリプトが実際にリクエストするドメインも記録してください。アドレスバーのドメインだけでは不十分です。
- HTTP
403または502が表示される場合：何らかのHTTPサービスから応答が返っています。DNSの問題と決めつけず、応答元を確認してください。
2. DNSを変更する前にHomeとGlobal Routingを確認
まず、端末から現在のネットワークにアクセスできることを確認します。ログインが必要なWi-Fiでは、先にネットワーク認証を済ませてください。次にHomeへ戻り、接続スイッチ、選択中のサーバー、Global Routingを確認します。サーバーを選択している状態と、接続が確立している状態は別です。
- 現在のネットワークがWi-Fiかモバイル通信かを記録し、同じ条件で再現できるURLを1つ用意します。
- Homeで接続状態を確認します。
Not Connectedと表示されている場合は、まず接続確立の問題を解決してください。この状態での失敗を、設定内のDNS障害と判断しないでください。 - Home → Global Routingを開き、現在の選択内容を記録します。特に
Directになっていないか確認してください。 - Connectivity Testを1回実行し、テスト方法と結果を記録してから、同じ失敗URLを開きます。
- 比較が必要な場合は、現在の値を記録してから一時的にルーティング方式を切り替え、1回テストしたら元に戻してください。DNS、サーバー、ルールを同時に変更しないでください。
| ルーティング方式 | 確認するポイント |
|---|---|
Proxy | Proxy経由の通信での状態を確認できます。ただし、すべてのDNSリクエストが必ず同じ経路で名前解決されるという意味ではありません。 |
Direct | 通信は直接接続されます。Proxy経由でのアクセスを想定していた場合は、まずルーティング方式を見直してください。 |
Config | 現在の設定に基づいてルールで振り分けます。失敗したドメインに適用されるルールとポリシーを確認してください。 |
Scene | 設定済みのシーンに応じてルーティング動作が決まります。選択中のサーバーだけでなく、現在のシーンも確認してください。 |
確認のポイント：ルーティング方式を切り替えて範囲を絞る
同じネットワーク、同じサーバーでもProxyでは開けてConfigでは失敗する場合、次にルールと設定に関わる名前解決経路を確認してください。接続情報一式をすぐに入れ替える必要はありません。
3. DNS設定ごとの役割
DNSはドメイン名をアドレスに変換します。AレコードはIPv4アドレスを、AAAAレコードはIPv6アドレスを返します。アドレスが返っても、そのアドレスへの経路が利用可能とは限りません。特にAAAAレコードを取得しても接続できない場合は、「IPv6アドレスが返されたこと」と「IPv6接続が利用できること」を分けて考えてください。
Settings → DNSで関連設定を確認し、Configで現在使用中の設定ファイルも確認してください。グローバル設定と設定ファイルの両方が実際の動作に影響することがあります。エディターでファイルを確認しただけで、その内容が適用中だと判断しないでください。次の表は各項目の概要であり、すべてを手動でカスタム値に変更する必要はありません。
| 項目 | 役割 | 確認ポイント |
|---|---|---|
| システムDNS | 現在のシステムネットワークが提供するDNS設定を使用します。 | Wi-Fiとモバイル通信を切り替えると、名前解決環境も変わる場合があります。 |
| カスタムDNS | 名前解決に使用するサーバーを指定します。 | サーバーアドレスが正しくても、現在のネットワークからアクセスできるとは限りません。 |
| DNS over HTTPS | HTTPS経由でDNSクエリを送信します。 | 通常はTCP 443を使用します。サービスのアドレス、TLS、サービスまでの経路が利用可能である必要があります。 |
| DNS over TLS | TLS経由でDNSクエリを送信します。 | 通常はTCP 853を使用します。ネットワークの制限は通常のDNSと異なる場合があります。 |
[Host] | 設定ファイルでドメイン名とアドレスの対応を指定します。 | 古いアドレスが引き続き使われる場合があります。失敗したドメインに手動のマッピングがないか確認してください。 |
従来のDNSは通常UDP 53を使用し、状況によってはTCP 53も使用します。暗号化通信に変わるのはクエリの経路であり、接続先サイトの停止、誤ったルール、到達できないアドレスが自動的に解決するわけではありません。「暗号化」のために、出所不明のDNSアドレスを複数追加しないでください。
システムDNSと比較する場合は、まず現在の設定をバックアップし、Configでテスト用のコピーを編集して、既存の[General]セクションにあるdns-serverを確認します。以下は該当項目のみの例で、完全な設定ではありません。元ファイルの他のセクションを上書きしないでください。
[General]
dns-server = system既存の[General]セクションがある場合は、該当する項目を編集し、同じセクションを重複して追加しないでください。保存後、テスト用コピーが使用中であることを確認してから、接続を確立し直して再テストします。手動のDNS設定がある場合は、それも記録してください。複数の変更を同じ結果の原因と取り違えないためです。
4. 変更は1つずつ、決めた順序で確認
目的は「どの層を変更したときに結果が変わるか」を特定することです。まず元の設定と変更前の状態を記録し、次の順序で確認します。比較できるよう、各手順で同じ失敗ドメインを使ってください。
- 失敗する範囲を確認。普段アクセスできるサイトを2つ開いてから、失敗するサイトを開きます。すべて失敗するのか、特定のサイトだけなのか、静的リソースだけなのかを記録してください。
- 接続ネットワークを切り替えて確認。可能であれば、同じ設定のままWi-Fiとモバイル通信を比較します。一方のネットワークだけで失敗する場合は、そのネットワークの認証状態、DNSへの到達性、アクセス制限を確認してください。
- 設定の適用状態を確認。Configで使用中のファイルを、Home → Global Routingでルーティング方式を確認します。ファイルを編集しただけで、そのファイルが使用中だとは限りません。
- 名前解決元を比較。元の値を記録したうえで、システムDNSと現在のカスタムDNSを一時的に比較します。結果が異なる場合は、DNSサーバーに到達できるか、返されたアドレスに違いがあるかを確認してください。
- ローカルマッピングとルールを確認。現在の設定で失敗したドメインと親ドメインを検索し、
[Host]と[Rule]も確認します。より広い範囲のルールが先に適用されている可能性があります。 - 接続を確立し直して再テスト。設定を保存したら接続をいったん切り、再接続してからページを再読み込みします。アプリが以前の接続やキャッシュを保持している場合は、関連アプリを終了して開き直してください。
- 効果のなかった変更を元に戻す。ある手順で改善しなかった場合は、その設定を元の値に戻します。原因を説明できない変更が複数残らないようにしてください。
ブラウザにサイトのIPアドレスを直接入力する方法だけでDNSを比較しないでください。HTTPSでは証明書の検証や接続先サイトの選択にドメイン名が使われます。IPアドレスへの直接アクセスでは、証明書エラーが発生したり別のサイトが表示されたりすることがあり、元のDNSに問題がなくても同様の結果になります。
バックグラウンドで接続が自動的に再確立される場合は、Settings → On Demandも確認してください。On Demandは接続を開始する条件を管理する機能で、ドメイン名をアドレスに変換するものではありません。切断状態で比較する際は、有効になっているかを記録し、自動再接続後のリクエストを直接接続の結果と取り違えないようにしてください。
5. 名前解決エラー、タイムアウト、ルール適用を切り分ける
「開けない」という説明より、エラーの原文のほうが原因の特定に役立ちます。以下はAppleのネットワークフレームワークで表示されることがある英語のエラーメッセージです。ブラウザやShadowrocketのすべての画面で、同じ文言が表示されるとは限りません。ログにエラーのドメイン名やコードがある場合は、原文と一緒に記録してください。
エラー：A server with the specified hostname could not be found.
原因と対処：NSURLErrorDomain -1003は指定されたホストが見つからないことを示します。まずドメイン名の入力を確認し、次に名前解決結果、DNSへの到達性、ローカルマッピングを確認してください。
エラー：The request timed out.
原因と対処：NSURLErrorDomain -1001はリクエストのタイムアウトを示しますが、DNSの失敗を単独で証明するものではありません。名前解決、接続確立、サーバー応答のどの段階で止まったかを時系列で確認してください。
エラー：A server with the specified hostname could not be found.
原因と対処：エラーがカスタム暗号化DNSサービスのホスト名に関するものなら、DNSサービス自体の初回名前解決で失敗している可能性があります。サービスのアドレスを記録し、対象サイトのルールを変更するのではなく、システムDNSで比較してください。
エラー：An SSL error has occurred and a secure connection to the server cannot be made.
原因と対処：NSURLErrorDomain -1200は安全な接続の確立に失敗したことを示します。端末の日付と時刻、接続先ホスト、証明書に関する情報を確認してください。証明書検証を無効にして問題を隠さないでください。
Configのルーティング方式では、ルールによっても状況が変わります。ルールは通常、上から順に確認され、最初に一致したルールのポリシーが適用されます。以下は順序を説明するための例示用ドメインであり、そのまま置き換えて使える完全な設定ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECTはexample.comとそのサブドメインに一致します。このルールが前にある場合、該当するリクエストのポリシーは後続のFINALでは決まりません。IP-CIDRはIPアドレスの範囲に一致します。例の192.0.2.0/24はドキュメント用のアドレス範囲であり、追加する接続先サービスではありません。no-resolveは、そのIPルールに一致した場合にドメイン名の名前解決を自動的に開始しないことを示します。以降のリクエストでDNSが一切不要になるという意味ではありません。GEOIPはIPアドレスの地理情報に基づいて一致します。Webサイトの使用言語やドメインの末尾で判定するものではありません。FINAL,PROXYは、それ以前のルールに一致しなかった場合に使われるフォールバックです。確認時は、PROXYに対応する実際の送信先も確認してください。
確認のポイント：アドレス取得後に失敗する場合は接続段階を確認
ログに接続先アドレスが表示された後、接続タイムアウトが記録されている場合は、適用されたポリシー、接続先ポート、送信経路を優先して確認してください。Webページが開けないという理由だけでDNSを変更し続けないでください。
6. よくある質問と確認記録のまとめ方
Connectivity Testに数値が表示されるのに、Safariでページが開かないのはなぜですか？
まずHomeでテスト方法を記録し、Home → Global Routingを確認してください。テスト先とWebページの接続先は異なる場合があります。同じ失敗URLで名前解決結果と適用ルールを確認し、遅延の数値だけであらゆるサイトにアクセスできると判断しないでください。
モバイル通信に切り替えたら直りました。すべてのDNS設定を変更すべきですか？
まず設定を変えずに、ネットワークによる違いを再現してください。Wi-Fiで認証が必要か、そのネットワークから現在のDNSサービスにアクセスできるかを確認します。名前解決元が結果に影響すると比較で確認できてから、該当する設定を変更してください。
DNSを変更しても以前の結果が表示される場合は？
まずConfigで変更後の設定ファイルが使用中であることを確認し、接続を確立し直してページを再度開いてください。Settings → DNSと設定ファイルの[Host]に手動設定が残っていないか確認します。dns-serverの項目を続けて追加しないでください。
サブスクリプションの更新だけ失敗する場合も、DNSが原因だと判断できますか？
いいえ。サブスクリプションのリクエストは、リンクの有効性、認証、サーバーの応答状況にも左右されます。更新時のエラー原文を記録し、利用中のサービス提供元にサブスクリプションが有効か確認してください。調査記録にサブスクリプションURL全体を公開しないでください。
さらにサポートが必要な場合は、以下の情報をまとめてください。再現条件を明確にするほうが、個人情報を隠していない設定ファイル全体より役立ちます。サブスクリプションの認証情報、パスワード、秘密鍵、アクセストークン全体は必ず伏せてください。
- 失敗したドメイン、発生時刻、Webページに表示されたエラーの原文。
- Wi-Fiとモバイル通信のどちらを使用したか、ネットワークを切り替えると状況が変わるか。
- Homeの接続状態、Global Routingの選択内容、Connectivity Testの方法と結果。
- 使用中の設定名、関連するDNS項目、対応する[Host]マッピングの有無。
- 関連するルールとその順序、ログで確認できる接続先アドレス、適用ポリシー、接続エラー。
- 試した設定変更と各結果、元に戻した設定。
ShadowrocketはiPhoneとiPadを主な対象とするクローズドソースの有料アプリで、入手先はApp Storeのみです。アプリの購入と接続サービスは別のものであり、買い切り購入にユーザー自身の接続サービスは含まれません。システム要件はApp Storeのページでご確認ください。