この記事は、Shadowrocketが接続でき、ノードの遅延テストにも結果が出る一方で、Webページにサーバーが見つからないと表示される、特定のドメインだけ読み込みが続く、またはサブスクリプションの更新に失敗する場合を対象とします。接続と名前解決を切り分け、Settings → DNS、Global Routing、現在のconfigを確認したうえで、Logから問題がDNS、ルール照合、プロキシ出力のどこで止まっているかを判断します。
遅延が正常でもDNSが使えるとは限らない
Shadowrocketがノードの遅延を測定するとき、テスト対象、接続方法、Webページへのアクセス手順は完全には同じではありません。遅延値が示すのは、その時点でクライアントが既存のサーバーアドレスへ接続または探測できたことだけで、任意のドメインを正しく解決できることまで保証するものではありません。Webアクセスでは、ドメイン検索、ルール照合、TCPまたはQUIC接続の確立、TLSハンドシェイク、コンテンツ転送を順に行います。どこか一つでも失敗すると、ページが空白になったり読み込みが続いたりします。
DNSの役割はドメイン名をIPアドレスに変換することです。ドメインから結果を取得できない場合、後続のDOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALルールが想定どおり処理できないことがあります。誤ったアドレスが返ると、ルールには正常に一致しても利用できない宛先へ接続する可能性があります。そのため、「ノードは80 msなのにWebページを開けない」ことを、ノードの速度だけが原因だと判断することはできません。
ポート番号はクエリ経路を理解するためのもので、手動で開放したり一つずつ入力したりする必要があるという意味ではありません。既存のconfig、サービス提供元の案内、現在のネットワークによって異なる名前解決方式が指定されている場合があります。トラブルシューティングでは、まず元の設定を記録し、その後は一度に一項目だけ変更してください。DNS、ノード、Global Routing、configを同時に変更すると、結果を比較できなくなります。
Settings → DNSの各項目を理解する
ShadowrocketのSettingsを開き、DNS関連のページへ進みます。表示される項目は現在の設定やconfigの影響を受けるため、実際の端末に表示される英語ラベルを基準にしてください。一般的に、DNS Serverは主なクエリに使用し、Fallback DNS Serverは主経路での名前解決に失敗した場合の代替処理に使います。Bootstrap DNSは、暗号化DNSサービス自体のドメイン名を最初に解決するためのものです。Bootstrap DNSですべての通常クエリを代替できるわけではなく、「DNSサービスへ接続するには、まずそのサービスのアドレスを知る必要がある」という開始時の問題を解決します。
Systemまたはsystemは、システムが提供する名前解決経路を使用することを示します。カスタムアドレスを入力しておらず、configにも上書きされていない場合は、クライアントに現在表示されている初期状態を維持し、他の端末のスクリーンショットを見てそのまま設定しないでください。configを読み込むと、[General]内のdns-server、fallback-dns-server、ipv6などの項目が実際の動作を変える場合があります。そのため、Settingsページと現在のconfigを併せて確認する必要があります。
| 項目 | 役割 | トラブルシューティングでの判断 |
|---|---|---|
| DNS Server | 主なドメイン検索を担当 | すべてのドメインで結果が出ない場合は、到達性と形式が正しいかをまず確認する |
| Fallback DNS Server | 主な検索に失敗した場合に代替結果を提供 | 主経路が一時的にタイムアウトするとき、代替経路も現在のネットワークで遮断されていないかを確認する |
| Bootstrap DNS | DoHまたはDoTサービス自体のホスト名を解決 | 暗号化DNSのアドレスがドメイン名で、起動時に失敗する場合に重点的に確認する |
| IPv6 | AAAAクエリとIPv6接続を制御または左右する | ネットワークがIPv6を部分的にしかサポートしない場合、AAAAが先に返されても接続がタイムアウトすることがある |
現在のconfigにDNS項目が明記されている場合は、そのconfigの処理ロジックを中心に確認します。以下は構文を識別するための例であり、公開設定をそのまま使うことを求めるものではありません。アドレスにはドキュメント用の例示ネットワークを使用しているため、実際のDNSサービスとしては利用できません。
[General]
dns-server = system, 192.0.2.53
fallback-dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT
FINAL,PROXY結論：まずDNSを制御している設定を確認する
Settingsと現在のconfigの両方にDNS設定がある場合、一方のページだけを見ないでください。まず現在有効なconfigを記録し、その中の[General]を確認すると、DNS Serverを何度も切り替えて変化が見えない問題を避けられます。
すべてのドメインが開けない場合の確認手順
すべてのWebページでサーバーが見つからないと表示される場合は、まず現在のノードとconfigを変更しないでください。これにより、DNS変更前後の違いを確認できます。確認の各段階で同じ普段使うドメインを再テストし、先に失敗したページを完全に閉じてから開き直してください。ブラウザが古いエラーを表示し続けるのを避けるためです。
接続状態を確認する
Homeに戻り、上部の接続スイッチが有効になっていること、現在のノード名とconfigが想定どおりであることを確認します。スイッチがすぐに戻る場合は、まず接続問題を解決し、DNSの調整には進まないでください。
Routingを切り替える
HomeでGlobal Routingを確認します。一時的にProxyへ変更して1回テストし、その後Directでも1回テストして、最後に元のConfigまたはSceneへ戻します。Configだけが失敗する場合はルールとconfigを確認し、複数の方式で失敗する場合はDNSまたはローカルネットワークを重点的に確認します。
DNSを確認する
Settings → DNSを開き、DNS Server、Fallback DNS Server、Bootstrap DNS、IPv6の現在値を記録します。直前に手動で追加した、出所の不明な重複項目は削除し、アプリの元の状態または自分で利用可能と確認した設定を残してください。
接続を再確立する
Homeに戻り、接続をオフにして数秒待ってから再びオンにします。DNS設定を変更した後はトンネルを再確立する必要があり、Webページを更新するだけでは以前のセッションやキャッシュ結果が使われる場合があります。
ネットワークを切り替える
Wi-Fiとモバイルデータ通信を切り替え、同じテストを繰り返します。特定のネットワークだけで失敗する場合は、そのネットワークの名前解決の到達性、IPv6対応、アクセス制限を重点的に確認し、Shadowrocketのノードを交換し続けないでください。
Logを確認する
DataまたはSettingsにあるLogの入口を開き、失敗したドメインをもう一度開きます。resolve、DNS、timeout、hostnameなどの記録が出ていないか確認し、発生時刻を記録してください。
Global Routingの4つの代表的な方式は、原因の範囲を絞るために使います。Proxyでは対応するリクエストをプロキシ方針へ統一し、Directではリクエストを直接接続します。Configではルールを上から順に照合し、Sceneでは設定した利用場面に応じて動作を選択します。一時的な切り替えは原因特定のためだけに行い、テスト後は元の設定へ戻してください。Proxyでは開けるのにConfigでは開けない場合は、DNSアドレスを変更し続けるのではなく、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALの順序を優先して確認します。
エラー：指定されたホスト名のサーバーが見つかりません。
原因と対処：システムがそのホスト名に利用可能なアドレスを取得できていないか、現在の接続に使えない結果が返されています。まずSettings → DNSを確認し、Shadowrocketの接続を再確立して、Logにクエリのタイムアウトがないか確認します。
エラー：インターネット接続がオフラインのようです。
原因と対処：接続経路上のDNS、ルーティング、ネットワークインターフェースがリクエストを完了できていません。まずHomeスイッチが安定していることを確認し、ProxyとDirectを個別に試して、特定の方式だけで起きる問題か判断します。
エラー：サブスクリプションの読み込みに失敗しました
原因と対処：サブスクリプションのドメイン解決に失敗した、リンクが無効になった、または利用中のサービス提供元がアクセスを制限している可能性があります。元のサブスクリプションリンクで形式と有効性を確認してください。https://example.com/sub?token=xxxx は形式のみを示す例です。確認後、Homeでプルダウンして更新します。
一部のドメインだけ失敗する場合はルールとIPv6を確認する
一部のWebサイトは正常で、少数のドメインだけ失敗する場合は、主なDNS経路が完全に停止している可能性は低いでしょう。この場合は、失敗したドメインが特定のルールに先に一致していないか確認します。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、そのサフィックスをDirectへ送ります。対象がプロキシ経路でしか到達できない場合、他のWebサイトは正常なのにそのドメインだけタイムアウトします。ルールは上から下へ照合されるため、より具体的なルールを広範なルールより前に置きます。FINALは、それまでに一致しなかったリクエストを受け持ちます。
GEOIPは、解決済みの宛先IPを基に方針を判断し、IP-CIDRはアドレス範囲に直接一致させます。DNSが想定と異なるアドレスを返すと、GEOIPの結果も変わる可能性があります。Logで失敗したドメインの解決結果、適用されたルールキーワード、最終方針を確認し、Configに戻って該当行を確認してください。ドメインの地域だけから推測しないことが重要です。
- DOMAIN-SUFFIX：サフィックスが完全に記述されているか、前方のDOMAINまたはDOMAIN-KEYWORDルールが先に一致していないかを確認します。
- GEOIP：DNSが先に利用可能なIPを返しているか、ルールで選ばれた方針が現在のconfig設計に合っているかを確認します。
- IP-CIDR：アドレス範囲とマスク長を確認します。たとえば/24と/32では一致する範囲が大きく異なります。
- FINAL：前のルールに一致しなかったリクエストが、最終的にPROXY、DIRECT、または別のポリシーグループのどこへ入るかを確認します。
- IPv6：LogでAAAAの結果が出た後に長時間待機する場合は、元の値を記録してから現在のネットワークでIPv6が利用できるかテストし、configと一致する設定に戻します。
On Demandが原因で「特定のネットワークに切り替えると失敗する」こともあります。Settings → On Demandを開き、Wi-Fi SSID、インターフェースの種類、ドメイン条件によって異なる接続動作が有効になっていないか確認します。Wi-Fiから離れた後にShadowrocketが想定どおり接続しない場合、WebエラーはDNSの問題に見えても、実際にはOn Demandの条件が発動していない可能性があります。テスト時はまずルールを記録し、On Demandを一時的に無効にして手動接続し、同じドメインを再テストしてください。
DNSを切り替えても失敗するときの次の確認
DNS Serverを切り替えても変化がないからといって、必ずしもDNSと無関係とは限りません。以前の検索結果がアプリ、システム、Webプロセスに残っている場合があり、暗号化DNS自体のドメインもBootstrap DNSに到達できず起動しないことがあります。Shadowrocketの接続を再確立し、テストページを開き直し、同じタイミングでLogを確認してください。複数のアドレスを続けて入力するのは避けます。
プロトコル層とDNS層も分けて判断する必要があります。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardの接続パラメータは、利用中のサービス設定によって決まります。Logにドメインの解決成功と想定どおりの方針への一致が表示された後で接続タイムアウトやハンドシェイク失敗が起きる場合は、DNSではなく、現在のノード、プロトコルパラメータ、ネットワークのパケットロス、サービス側の状態を確認します。DNSが担当するのはアドレスの取得だけで、その後の通信問題を修復することはできません。
エラー：DNSリクエストがタイムアウトしました
原因と対処：クエリは送信されたものの、制限時間内に応答がありません。Wi-Fiとモバイルデータ通信を切り替えて比較し、従来型DNSの53番ポート、または暗号化DNSで使う443番・853番の経路が現在のネットワークから到達可能か確認します。
エラー：サーバーに接続できませんでした。
原因と対処：前のLogに解決結果が記録されている場合、これは通常、名前解決後の接続段階の問題です。適用された方針、現在のノード状態、プロトコルパラメータを確認し、DNSを何度も切り替えるのはやめてください。
- 失敗した時刻、ネットワークの種類、Global Routingの方式、現在のconfig、ノード名を記録します。
- Logでドメイン検索が行われたか、検索結果としてAまたはAAAAアドレスが返ったかを確認します。
- アドレスがある場合は、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALのどのルールに一致したかを確認します。
- ルールが正しいのに接続がタイムアウトする場合は、ノード接続、プロトコルパラメータ、利用中のサービス状態を確認します。
- サブスクリプションの更新だけが失敗する場合は、サブスクリプションのドメイン、リンクの有効性、サービス提供元の更新要件を確認します。
結論：Logで最後に成功した段階から担当範囲を切り分ける
解決結果がなければDNSを確認し、IPがあるのに方針が誤っていればConfigを確認します。方針が正しいのにハンドシェイクに失敗する場合は、ノードとプロトコルを確認します。最後に成功した段階から後ろへ順に確認するほうが、DNS Serverを何度も置き換えるより効率的です。
安定した設定に戻し、確認記録を残す
原因を特定したら、一時的に使用したGlobal Routingを元のConfig、Proxy、Direct、またはSceneへ戻し、On Demandもテスト前の状態に戻します。トラブルシューティングのためだけに追加した重複DNS項目は削除してください。問題がconfig内のルールにある場合は、誤りを確認できた行だけを修正します。現在のネットワークが原因の場合は、別のネットワークでの比較結果を残しておくと、後で再現しやすくなります。
利用中のサービス提供元へ問い合わせる際は、障害発生時刻、使用ネットワーク、失敗したドメイン、ShadowrocketのLogでそのリクエスト付近にある数行、DirectとProxyの両方で再現するかを伝えます。サブスクリプションの内容とアクセス認証情報は機密情報です。スクリーンショットを共有する前に、token、サーバーアドレスに含まれる認証情報、WireGuardの秘密鍵を隠してください。
ShadowrocketはAppleプラットフォーム向けの有料商用アプリです。主な利用端末はiPhoneとiPadで、Mac、Apple TV、Apple Visionの互換性とシステム要件はApp Storeページの記載に従います。入手先はApp Storeのみです。開発者名はShadow Launch Technology Limited、アプリIDは932747118です。アプリの買い切り購入と回線サービスは別のものであり、アプリを購入してもノードやサブスクリプションが付属するわけではありません。