Shadowrocketで接続テストの遅延は表示されるものの、SafariやほかのアプリでWebページを開けない場合が対象です。まずDNS、接続タイムアウト、TLSエラーを切り分け、Home → Global RoutingとConfig内のdns-serverを確認します。同じ接続先で設定を一つずつ変更し、ネットワークを切り替えて原因を特定しましょう。利用者がすでにサービス提供元とサブスクリプションを用意していることを前提とし、サービスの入手先は扱いません。
1. 遅延が正常でも、ドメイン名の解決が正常とは限らない
Webページを開く際には通常、ドメイン名の名前解決、接続の確立、TLSハンドシェイク、コンテンツの受信が行われます。Homeに表示されるテスト値が示すのは、選択したテスト方法で確認できる範囲だけです。TCP接続ができることや、テスト用アドレスに到達できることは、対象サイトのドメイン名が解決できることや、HTTPSリクエストが成功することを意味しません。異なるテスト結果をそのまま比較しないよう、まずConnectivity Testのテスト方法を記録してください。
DNSはドメイン名をIPアドレスに変換します。プロキシサーバーに接続できても、端末が使うリゾルバーに到達できない、応答が空である、または名前解決の結果が現在の出口に適していない場合は、Webページを開けないことがあります。一方、IPアドレスを取得した後に接続がタイムアウトした場合、DNS障害と決めつけることはできません。
判断のポイント：失敗した段階を特定してから、リゾルバーを変更する
証明書またはTLSハンドシェイクのエラーが明確な場合は、まず端末の時刻、対象ドメイン名、接続時の出口を確認します。名前解決エラー、DNSタイムアウト、異常な応答が見られる場合に限り、DNSの経路を優先して調べてください。ポートに接続できるだけでは、名前解決サービスが正常に応答するとは限りません。
2. Homeのテスト条件を固定する
切り分け中は、同じドメイン名と既存の設定を使います。サーバーの変更、ルールの編集、サブスクリプションの更新、DNSの変更を同時に行うと、復旧しても原因を特定できません。まず、普段アクセスしていて、アドレスの入力が正しいと確認できるサイトを選び、比較用に別のドメイン名も追加してください。
- 現在の状態を記録します。Homeで接続スイッチの状態、選択中のサーバー、Global Routingのモード、Connectivity Testのテスト方法と結果を記録します。認証情報は記録に残さないでください。
- ルーティングモードを確認します。Global RoutingのConfigは現在の設定ルールに従って通信を処理します。Proxyは通常の通信を選択中のプロキシに転送し、Directは直接接続の比較に使います。Sceneは設定済みのシーンに従って動作します。Sceneは名前だけで実際のポリシーを判断できないため、シーンの内容を確認してください。
- 短時間の比較テストを行います。現在のネットワークでアクセスできることを確認したうえで、同じドメイン名をDirectとProxyで比較します。一方のモードで失敗しても、経路に違いがあることを示すだけで、DNSが原因とは限りません。テスト後は元のモードに戻してください。
- 自動接続による干渉がないか確認します。Settings → On Demandを確認します。手動で比較する間は、関連する接続条件を記録して一時的に無効にすると、手動で切断した後にオンデマンド接続が再開するのを防げます。テスト後は元に戻してください。
- ネットワークを切り替えて再テストします。Wi-Fiとモバイル通信を切り替え、同じ設定で再テストします。一方のネットワークだけで失敗する場合は、そのネットワークでのDNS到達性、ログイン認証、アクセス制限を重点的に確認してください。
Wi-FiでWebログインによる認証が必要な場合は、先に認証を済ませてからテストしてください。すべてのサイトで失敗し、現在のサーバーのドメイン名も解決できない場合は、まず接続先の名前解決を解決する必要があります。このとき、サイトごとのルールを何度も切り替えても、通常は改善しません。
3. dns-serverの意味と最小限の変更
Configで管理するのは設定ファイルであり、サブスクリプションのサーバー一覧そのものではありません。変更前に現在のファイルを複製して保存し、使用中のConfigを確認してから編集画面を開いてください。以下はフィールドの位置を示す最小限の例です。既存ファイルの該当項目だけを置き換え、設定全体をこの内容で上書きしないでください。
[General]
dns-server = system| フィールドまたは値 | 意味 | 確認時の注意点 |
|---|---|---|
[General] | Configの一般設定セクション | 同じ名前の設定を重複して追加すると混乱するため、既存のセクションを編集してください。 |
dns-server | Configで使用するDNSリゾルバーを指定 | 現在のバージョンでサポートされている値を入力します。プロキシサーバーのアドレスやサブスクリプションのURLではありません。 |
system | 現在のシステムネットワークが提供するDNSを使用 | 基準となる比較に適していますが、Wi-Fi、モバイル通信、ネットワークプロファイルによって結果が変わることがあります。 |
| リゾルバーのIPアドレス | 従来型のDNSサーバーを直接指定 | アドレスが正しく、サービスに到達できることを確認してください。WebサイトのIPアドレスやプロキシのポートをDNSサービスとして指定することはできません。 |
| DoHアドレス | HTTPSリクエストでDNS応答を取得 | 現在のバージョンがサポートする形式と完全なエンドポイントを使用してください。通常のWebサイトのトップページをDoHエンドポイントの代わりにすることはできません。 |
まずdns-server = systemを設定して比較します。元のConfigでリゾルバーを指定していて、systemに変更すると復旧する場合は、元のリゾルバーの到達性、アドレス形式、経路を確認してから、変更を維持するか判断してください。systemでも失敗するからといって、アプリの異常とは限りません。システムから通知されたDNSにアクセスできない、またはそのリゾルバーから対象ドメインの有効な応答が返らない可能性があります。
- 一度に変更するフィールドは一つだけにし、保存後もそのConfigが現在使用中のファイルであることを確認してください。
- 再読み込みが必要な設定は、切断して再接続してからテストしてください。失敗した場合に戻せるよう、変更前の値を残しておきます。
- すでに利用していて、信頼でき、到達性を確認できるリゾルバーを比較に使ってください。出所の分からない設定から、不明なエンドポイントをコピーしないでください。
- 暗号化DNSも、基盤となるネットワークに到達できる必要があります。エンドポイントにドメイン名を使う場合は、最初の名前解決と証明書検証が完了するかどうかも考慮してください。
4. エラー表示に応じた切り分け
以下はネットワーク診断で見られることのある標準的なエラーテキストやシステムエラーコードです。Shadowrocketのすべての画面で同じメッセージが表示されるとは限りません。記録する際は、エラーの発生元、対象ドメイン名、失敗した段階も併せて残してください。アプリ内、Safari、リモートサーバーのログでは表現が異なることがあります。「開けない」というだけで原因を判断しないでください。
エラー：NSURLErrorDomain Code=-1003
原因：AppleのURL読み込みシステムが指定されたホストを見つけられませんでした。名前解決の失敗やドメイン名の入力ミスがよくある原因です。
対処法：まずドメイン名の入力を確認します。同じドメイン名でsystemと元のリゾルバーを比較し、特定のネットワークだけで発生するかも確認してください。
エラー：NXDOMAIN
原因：DNS応答は、問い合わせた名前が存在しないことを示しています。「リゾルバーが応答しない」状態とは異なり、使用中のリゾルバーのポリシーが関係する場合もあります。
対処法：完全なホスト名を確認し、別の信頼できる既存のリゾルバーでも再確認します。結果が同じ場合は、ドメインの管理者にレコードを確認してください。
エラー：SERVFAIL
原因：リゾルバーが問い合わせを完了できませんでした。上位DNSの障害、権威サーバーの異常、DNSSEC検証の失敗などが考えられます。
対処法：複数のネットワークやリゾルバーで結果を比較し、発生時刻を記録してください。ドメインが恒久的に存在しないと決めつけて、Hostを直接書き換えないでください。
エラー：NSURLErrorDomain Code=-1001
原因：リクエストがタイムアウトしました。名前解決、接続、応答待ちのいずれの段階でも発生する可能性があり、このコードだけではDNS障害と判断できません。
対処法：診断記録から対象IPアドレスを取得できているか確認します。取得済みの場合は、ルーティング、接続、接続先サービスの応答を調べてください。
「AAAAレコードがない」ことを、ドメイン全体が名前解決できないという意味に取らないでください。有効なAレコードが存在する場合があります。一方、AAAAの応答があっても、現在のネットワークでIPv6経路が正常とは限りません。一部のドメインだけ失敗する場合は、すべてのIPv6設定をまとめて変更するのではなく、名前解決の応答と実際の接続で使われるアドレスファミリーをそれぞれ確認してください。
5. 名前解決後にルールと上書き設定を確認する
DNSの成功は応答を取得できたことを示すだけで、Webリクエストが適切なポリシーで処理されるとは限りません。Global RoutingがConfigの場合、通常はルールが上から順に評価され、最初に一致したルールでリクエストの処理方法が決まります。ルールの順序、ポリシー名、フォールバックの設定を誤ると、名前解決済みのリクエストが利用できない経路に送られることがあります。
| 確認対象 | 役割 | 具体的な確認方法 |
|---|---|---|
DOMAIN-SUFFIX | 指定したドメインとそのサブドメインに一致 | パスを含むURLではなくドメイン名を指定しているか確認し、それより前に一致するルールがないか調べてください。 |
IP-CIDR | IPアドレスの範囲で一致 | 対象IPアドレスが、より上位のネットワーク範囲ルールに一致していないか確認してください。no-resolveが付いている場合は、その修飾子の影響も確認します。 |
GEOIP | IP地理データベースの分類で一致 | データベース上の分類を、Webサイトの所在地と同じと考えないでください。実際に適用されたポリシーを確認します。 |
FINAL | それ以前のルールに一致しなかったリクエストを処理 | 最終的にDIRECT、プロキシ、または定義済みのポリシーグループのどれが適用されるか確認してください。 |
[Host] | 指定したホストにConfig内の名前解決マッピングを適用 | 古いアドレスが残っていないか確認します。バックアップを取ってから、疑わしいマッピングを一つだけ削除して比較してください。 |
たとえばDOMAIN-SUFFIX,example.com,DIRECTは、example.comとそのサブドメインをDIRECTに振り分けます。そのリクエストが利用者の既存プロキシ経由でないと接続できない場合、リゾルバーが正しい応答を返してもWebページは開けないことがあります。ここでのexample.comはルールの書式例であり、実際のテスト対象を示すものではありません。
判断のポイント：対象IPを取得できたら、実際に適用されたポリシーを確認する
診断で名前解決の応答が確認できた場合は、そのドメインに一致したルール、最終的なポリシー、選択中の出口を確認します。ルーティングの誤りをDNSの連続変更で直そうとしたり、一時的な接続のために変動するWebサイトのアドレスをHostへ固定したりしないでください。
6. よくある質問と復旧後の確認
DNSを変更しても、同じエラーが表示されるのはなぜ？
まずConfigで、変更が現在使用中のファイルに保存されていることを確認してから、切断して再接続します。エラーが出たページを閉じてリクエストを再実行し、キャッシュが更新される時間を確保してください。それでも失敗する場合は、新しいリクエストのエラーを記録します。ブラウザーに残った古いページだけで判断しないでください。
Wi-Fiでは開けず、モバイル通信では開ける場合、どこを変更すればよい？
サーバーとConfigは変更せず、まず両方のネットワークでsystem DNSの結果を比較し、Wi-FiでWebログイン認証が必要か確認します。そのWi-Fiだけで失敗する場合は、クライアント側のフィールドを変更する前に、ネットワーク側の名前解決と通信制限を確認してください。
Webページは復旧したのに、サブスクリプションの更新が失敗する場合は？
サブスクリプションの更新では別のURLにアクセスするため、通常のWebページの表示テストとは異なります。利用中のサブスクリプションのドメイン名、有効期限、返されたエラーを確認してください。記録を共有する前に、tokenなどの認証情報を削除します。サブスクリプションURLをdns-serverに入力したり、DNSの比較の代わりに何度も更新を試したりしないでください。
WebサイトのIPアドレスを直接入力すれば、DNSの問題を証明できる？
決定的な証拠にはなりません。HTTPSでは証明書の検証と接続先サイトの選択にドメイン名が使われ、同じIPアドレスで複数のサイトがホストされている場合もあります。元のドメイン名を使い、名前解決の応答と接続段階の記録から原因を特定してください。IPアドレスでページを開けるかどうかだけで判断しないでください。
復旧後は、ホームページを一度開いただけで終わらせないでください。以下のチェックリストに沿って、同じ結果を再現できることを確認してから最終的な変更を残します。サービス提供元やネットワーク管理者に相談する場合は、設定全体を送らず、個人情報を除いた記録を共有してください。
- 動作確認：以前開けなかったドメインと比較用の別ドメインを再度開き、読み込み済みページのキャッシュに依存していないことを確認します。
- 設定確認：普段使うGlobal RoutingのモードとOn Demandの条件に戻し、自動接続後もアクセスできることを確認します。
- ネットワーク確認：普段使うWi-Fiとモバイル通信のそれぞれで再テストし、ネットワークによる差があるか記録します。
- 記録確認：テスト時刻、ネットワークの種類、エラーの原文、名前解決の成否、適用されたポリシー、変更した項目を一つ記録します。サブスクリプションのtoken、パスワード、その他の認証情報は削除してください。