Shadowrocketの遅延値が示すのは、テスト対象となった通信経路の状態です。Webサイトのドメインが名前解決できたことまでは確認できません。利用中のサービスとサブスクリプションがあり、接続後にWebページを開けない場合は、ネットワーク、現在のConfigのDNS、Global Routing、リクエスト記録を順に確認しましょう。一度に変更する項目は一つにし、名前解決の結果と接続段階から原因を特定します。
1. 遅延が正常でもWebアクセスが成功したとは限らない
まず、選択したサーバーへの接続と、Webサイトへのアクセスを分けて考えます。遅延テストの対象はサーバーへの接続、または指定されたテスト先だけの場合があります。一方、Safariでページを開くには、接続先ドメインの名前解決、出力先ポリシーの選択、接続の確立、TLSハンドシェイクが必要です。最初の段階で応答があっても、後続の処理は失敗することがあります。遅延値が表示される場合も、サーバーやネットワーク全体が正常だと判断せず、まずDNSを確認してください。
この流れは確認箇所を整理するためのもので、すべての接続で処理される順序を示すものではありません。ドメインルールが先に照合される場合がある一方、IPルールの一部ではアドレスの取得が必要です。実際の確認では、「IPアドレスを取得できたか」「最終的にどのポリシーが使われたか」「どの段階で接続に失敗したか」をそれぞれ記録してください。証明書エラーやHTTPステータスコードが表示される場合、単純なDNS無応答だけが原因とは限りません。
ポートの説明は、サービスで一般的に使われる方式を示すもので、ルーターで受信ポートを開放する必要があるという意味ではありません。AまたはAAAAレコードが返っても、名前解決でアドレスを取得できたことを示すだけです。誤ったアドレスが返る、IPv6経路に到達できない、後続のポートが制限されている場合も、Webページを開けないことがあります。
2. ネットワークと現在の設定の基準を確認する
変更を始める前に、現在の設定を複製して保存し、問題が起きる完全なドメイン名、使用中のWi-Fiまたはモバイル通信、Global Routingの現在の選択肢、エラーが発生した時刻を記録します。同じWebページでテストし、現在のネットワークから通常アクセスできる別のページも比較用に用意してください。1つのサイトだけを確認すると、そのサイト固有の障害をDNS全体の問題と取り違えるおそれがあります。
-
自動接続を一時停止する
Settings → On Demandを開き、現在の有効状態と条件を記録して、確認中は一時的に無効にします。続いてHomeで接続を切り、切断直後にオンデマンド条件で再接続されないようにします。
-
接続元のネットワークを確認する
切断した状態でSafariから比較用のWebページにアクセスします。公衆Wi-Fiで認証が必要な場合は、先にネットワークへログインしてください。接続元のネットワークでもアクセスできない場合は、Wi-Fi、モバイル通信、ネットワーク認証を先に確認します。
-
現在の設定を確認する
Configを開き、実際に選択されている設定ファイルを確認してから、該当ファイルの内容を調べます。選択されていない別のファイルだけを編集しても、現在のリクエスト処理には反映されません。
-
接続後に再テストする
Homeに戻り、利用中のサーバーに接続してから、Safariで同じページを再度開きます。切断時と接続時の違いを記録し、サーバー、DNS、ルールを同時に切り替えないようにします。
-
ネットワークを切り替えて確認する
設定とサーバーは変えずに、Wi-Fiとモバイル通信を切り替えて再テストします。一方のネットワークだけで失敗する場合は、そのネットワークでのDNS到達性、認証、アクセス制限を優先して確認してください。
利用中のサーバーアドレスがドメイン名の場合、接続を確立する前にその名前解決が必要になることがあります。「接続先WebページのDNS」と「サーバードメインの初回名前解決」は、別々に確認してください。前者に問題があっても接続自体は維持される場合がありますが、後者に失敗すると接続を確立できないことがあります。ステータスバーの接続表示だけで、両方の処理が完了したと判断しないでください。
3. [General] の dns-server を確認する
Configで現在のファイルの[General]セクションを確認し、dns-serverを探します。システムのDNS、明示的に指定したDNSアドレス、DNS over HTTPSのどれを使っているかを確認し、入力ミスがないか、現在のネットワークから指定先へ到達できるかを調べてください。異なる設定元の値をそのまま連結したり、サービス提供元の別の項目をDNSアドレスとして入力したりしないでください。
[General]
dns-server = system上記はシステムDNSを使う最小限の例で、完全な設定ではありません。比較テストを行う場合は、バックアップを取ったうえで、既存の同名設定を置き換えてください。[General]を重複して追加したり、dns-serverを複数並べたりしないでください。保存後に再接続して新しいリクエストを実行します。正常に戻っても、名前解決経路の変更が有効だったことを示すにすぎません。元の設定と比較して原因を調べてください。
- システムDNS：
systemはシステムが提供する名前解決設定を使います。Wi-Fiやモバイル通信を切り替えると実際の名前解決環境も変わる場合があり、現在のネットワークを基準として確認するのに適しています。 - 明示的なDNSアドレス：アドレスに誤りがないか、現在のネットワークからそのDNSサーバーに到達できるかを確認します。アドレスを設定しただけではリクエストが到達するとは限らず、サーバーの遅延値だけでも確認できません。
- DNS over HTTPS：HTTPSエンドポイントの完全なパス、ホスト名、TLS接続条件を確認します。DNSサーバーのホスト名を最初に名前解決できるかどうかも接続に影響する場合があります。「HTTPSを使う」だけで利用可能になるとは限りません。
- ローカルネットワークのドメイン：会社や家庭内の名前は、ローカルDNSだけが応答を返す場合があります。外部DNSに変更すると、公開Webサイトにはアクセスできるようになっても、内部の名前を解決できなくなることがあります。
4. Global Routingでルールと名前解決の問題を切り分ける
Home → Global Routingを開き、まず現在の選択肢を記録します。Configは現在の設定にあるルールに従ってリクエストを処理します。ProxyとDirectは出力経路の比較に使えます。Proxyに切り替えてページが表示されても、すぐに「DNSが直った」と判断しないでください。接続先ドメインは常に解決できていて、元のルールが適切でない出力ポリシーに接続を振り分けていた可能性があります。
| テスト状態 | 確認できた結果 | 次に確認する項目 |
|---|---|---|
| Configでは失敗、Proxyでは正常 | 選択した出力経路でWebページのリクエストが完了する | ルールの適用状況、ポリシーの転送先、DNS関連の設定を確認する |
| Directでは正常、Proxyでは失敗 | 直接接続ではアクセスできるが、プロキシ経路では結果が異なる | 選択中のサーバー、出力先への接続、名前解決経路を確認する |
| 複数の状態で失敗 | 特定の振り分けルールだけが原因とは限らない | ネットワーク、DNSサーバーへの到達性、接続先Webサイトを確認する |
| 1つのドメインだけ失敗 | 特定の接続先に問題が集中している | そのドメインの名前解決結果、専用ルール、Webサイトの状態を確認する |
ルールは上から順に照合され、一致したルールのポリシーが適用されます。DOMAIN-SUFFIXが対象ドメインをカバーしているか、GEOIPまたはIP-CIDRによって名前解決後のアドレスが別の経路に振り分けられていないか、FINALがルールセクションの最後にあるかを確認します。以下は構文と順序を示す例です。example.comはドキュメント用の例示ドメインであり、Webページへの接続テスト先ではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYno-resolveは、該当するIPルールの照合を目的として積極的にドメインを名前解決しないことを示します。すべてのDNSを無効にする設定ではありません。対象IPをすでに取得しているか、前段でドメインルールに一致したかによって、その後の照合結果は異なります。名前付きポリシーを使っている場合は、そのポリシーの最終的な転送先も確認してください。ルール行の名前だけでは、想定したサーバーが使われているとは判断できません。
まとめ：違いを再現できる比較条件を残す
ConfigとProxyで結果が異なる場合は、まず同じドメインに適用されたルールと最終的な出力先を記録し、該当項目を変更してください。DNSとサーバーを同時に切り替えると、どちらの変更が有効だったか判断できません。
5. エラーが発生した段階からDNS・接続・TLSを見分ける
Safariのエラーメッセージは、システムの表示言語によって異なる場合があります。エラーの詳細や診断記録にシステムエラー識別子が表示されている場合は、以下の原文を段階の切り分けに使えます。これらはApple URL Loading Systemのエラー名であり、Shadowrocketに同じ文言がそのまま表示されることを意味しません。アクセスした時刻に対応するリクエスト記録を確認し、名前解決の失敗、接続先IP、適用されたポリシー、その後の接続結果を優先して調べてください。
エラー：NSURLErrorCannotFindHost（-1003）
原因：指定されたホストが見つかりません。ドメイン名の入力ミスや名前解決の問題が考えられます。対処：まず完全なホスト名を確認し、システムDNSと現在のDNS設定のそれぞれでアドレスを取得できるか比較します。
エラー：NSURLErrorDNSLookupFailed（-1006）
原因：DNSクエリの失敗です。DNSサーバーに到達できない場合や、名前解決の処理に異常がある場合に発生します。対処：現在のDNSサーバーとネットワーク経路を確認します。他の条件は変えずにネットワークを切り替えるか、システムDNSで比較テストを行ってください。
エラー：NSURLErrorTimedOut（-1001）
原因：リクエストがタイムアウトしました。名前解決、接続、応答待ちのいずれかの段階で起きる可能性があります。対処：まず記録に接続先IPがあるかを確認し、その後に該当する出力先と接続結果を調べます。タイムアウトの表示だけでDNSの問題と決めつけないでください。
エラー：NSURLErrorSecureConnectionFailed（-1200）
原因：セキュア接続の確立に失敗しました。TLS、証明書、ネットワーク上の接続への干渉などが考えられます。対処：端末の日付と時刻、接続先ホスト名を確認し、TLS関連の記録を調べてください。証明書検証を無効にしてトラブル対処の代わりにしないでください。
記録に接続先IPがあり、そのIPへの接続がタイムアウトする場合は、DNSを繰り返し変更せず、サーバーの出口、接続先ポート、IPv4 / IPv6の経路を確認します。DNSクエリが送信されても長時間応答がない場合は、DNSサーバーへの到達性を重点的に調べてください。以前から開いていたページだけが表示され、新しいドメインで失敗する場合は、キャッシュによって問題が見えにくくなっている可能性があるため、新しいリクエストでも確認します。
6. 復旧を確認してからオンデマンド接続を戻す
設定を変更した後は現在の設定を保存し、いったん切断してから再接続し、対象のWebページを開き直します。Safariやアプリに既存の接続やキャッシュが残ることがあるため、一度の再読み込みで表示できても原因が解消したとは限りません。同様に、古い接続で失敗が続いても、新しい設定が反映されていないとは限りません。問題が起きたページ、比較用ページ、別のネットワークで繰り返し確認し、結果が一致するか記録してください。
- 名前解決を確認：対象ドメインから妥当なアドレスを取得でき、今回の問題を再現したときの名前解決エラーが再発しないことを確認します。
- 振り分けを確認：通常利用するGlobal Routingの状態に戻し、対象のリクエストが想定したルールとポリシーに一致することを確認します。
- ネットワーク切り替えを確認：普段使うWi-Fiとモバイル通信のそれぞれで検証し、切り替え後にDNSサーバーへ到達できなくなる現象がないか確認します。
- 自動接続の条件を戻す：Settings → On Demandを開き、記録しておいた条件に戻してから、想定どおりに接続が開始されるか確認します。
- 有効な設定を保存：変更前と変更後の設定を保存します。リモート設定の更新でローカル編集が上書きされる場合は、更新内容を確認し、一時的な修正を恒久的な解決とみなさないでください。
それでも解決しない場合は、利用中のサービス提供元またはネットワーク管理者に、発生時刻、ネットワークの種類、接続先ドメイン、Global Routingの状態、適用されたポリシー、機密情報を伏せたエラー記録など、必要最小限の情報を伝えてください。サブスクリプションURL全体、認証パスワード、アクセストークンを含む設定は送信しないでください。「DNSから応答がない」のか「アドレス取得後の接続に失敗する」のかを明確にすると、遅延テストの結果だけを共有するより原因を特定しやすくなります。