この記事は、Shadowrocket が接続済みと表示され、ステータスバーの接続表示も正常なのに、Webページやアプリがネットワークにアクセスできない場合を対象としています。まずローカルネットワークの基準を確認し、サーバー、Global Routing、DNS、Config のルールを順番に検証します。複数の設定を同時に変更せず、症状との照合で問題の層を特定できます。
再現可能なネットワーク基準を作る
「接続済み」は、Shadowrocket がシステム上にネットワーク経路を確立したことを示すだけで、経路内のすべてが正常に通信できるとは限りません。サーバーに到達できない、認証情報が無効、DNS クエリに失敗、Config のルールが誤ったポリシーを選択している、といった原因で、接続をオンにしてもリクエストが応答しないことがあります。
トラブルシューティングを始める前に、現在のサーバー名、Global Routing のモード、使用中の Config を記録してください。一度に変更する項目は1つだけにし、変更後は同じテストページへ再度アクセスします。サーバー、DNS、ルールを同時に変更すると、復旧してもどの変更が有効だったのか判断できません。
元のネットワークを確認する
まず Shadowrocket の接続スイッチをオフにし、現在の Wi-Fi またはモバイルデータ通信で、これまで開いていないWebページを2つ開きます。この時点でもアクセスできない場合は、ローカルネットワーク、ルーターのログインページ、またはモバイルデータ通信の権限を先に確認してください。
現在の設定を記録する
Home で選択中のサーバーと Global Routing を、Config で有効な構成名を、Settings → DNS で現在の DNS 項目を記録します。これにより、確認後に元の設定へ戻せます。
接続を再確立する
Home に戻り、接続スイッチをオフにして数秒待ってから、もう一度オンにします。ネットワーク構成の確認を求められた場合は、システムの指示に従って許可し、接続状態が安定して維持されるか確認します。
比較テストを行う
Direct、Proxy、Config の順にテストします。毎回 Global Routing だけを切り替え、サーバーは変更しません。3つの結果を比較すると、ローカルネットワーク、サーバー経路、ルールのどこに問題があるかをすばやく切り分けられます。
第1層：サーバーの状態とパラメータを確認する
Shadowrocket をオフにするとローカルネットワークは正常で、Global Routing を Proxy にするとすべてのリクエストが失敗する場合は、まず現在のサーバーを確認します。Home に表示される遅延結果は、テストリクエストが制限時間内に返ったかを示すだけで、実際の通信が必ず利用できることを単独で証明するものではありません。ただし、継続的なタイムアウト、遅延値の空欄、テスト結果の急上昇は、サーバー経路の異常を示す重要な手がかりです。
Home のサーバー一覧を開き、現在のサーバーで可用性または遅延テストを実行します。次に、ユーザーが契約しているサービス設定にある別のサーバーでも比較してください。同じネットワークで1台だけ失敗するなら、問題は通常そのサーバー、ポート、認証情報にあります。すべて失敗する場合は、サブスクリプションの更新、本体ネットワークによる対象ポートの制限、サーバーのドメインを DNS が解決できるかを確認します。
エラー：Request timed out
原因と対処：待機時間内に応答を受信できていません。サーバーの停止、経路上のパケットロス、対象ポートへの到達不能がよくある原因です。ユーザーが契約している設定内の別サーバーへ切り替え、元のサーバーだけが失敗する場合は、サービス提供者にサーバー状態とポートを確認してください。
エラー：Failed to resolve hostname
原因と対処：サーバーアドレスがドメイン名で、現在の DNS が利用可能なアドレスを返していません。Settings → DNS を開いて DNS 設定を確認し、サーバーのドメイン名に余分な空白や入力ミスがないか確認してください。
エラー：Network is unreachable
原因と対処：現在利用できるネットワーク出口がないか、Wi-Fi のポータル認証が完了していません。接続をオフにして通常のWebページへアクセスし、元のネットワークを確認します。必要に応じて Wi-Fi にログインしてから、Shadowrocket を再度オンにしてください。
エラー：Failed to load subscription
原因と対処：サブスクリプション URL の無効化、アクセスのタイムアウト、サーバーから有効な内容が返ってこないことが原因です。https://example.com/sub?token=xxxx のような形式例を参考に自分のリンクを確認し、サービス提供者にリンクの状態を確認してから Home で下にスワイプして更新してください。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard ではパラメータ構造が異なります。確認時に、あるプロトコルのポート、認証フィールド、通信設定を別のプロトコルへそのまま適用しないでください。サブスクリプションの更新に成功しても、すべてのサーバーが稼働しているとは限りません。更新成功が示すのは、Shadowrocket が設定内容を取得して解析できたことだけです。
- サーバーアドレスがドメイン名の場合は、まず DNS でそのドメインを解決できるか確認します。
- サーバーアドレスが IP の場合、サーバー接続への DNS の影響は小さいため、先にポートと認証情報を確認します。
- 同じサーバーが Wi-Fi では失敗し、モバイルデータ通信では成功する場合は、現在の Wi-Fi の出口とルーターのポリシーを確認します。
- 2種類のネットワークで全サーバーが失敗する場合は、サブスクリプションの更新日時、アカウント状態、サービス側の状態を確認します。
第2層：Global Routing で通信の行き先を特定する
Global Routing は、リクエストに統一ポリシーを適用するか、Config に従って判定するかを決めます。Proxy はすべてのリクエストにプロキシポリシーを適用し、Direct は直接接続、Config はルールを順番に判定します。Scene はあらかじめ設定したシーンに応じて動作を選びます。トラブルシューティングでは、Proxy、Direct、Config の3つを比較するのが効果的です。
| テスト結果 | 優先して確認する点 | 次の手順 |
|---|---|---|
| Direct は成功、Proxy は失敗 | ローカルネットワークは利用可能で、サーバー経路またはサーバーパラメータに異常があります | 別の既存サーバーをテストし、サーバーのドメイン、ポート、認証フィールドを確認します |
| Proxy は成功、Config は失敗 | サーバーは利用可能で、Config のルールまたはポリシー名に誤りがあります | ルールの順序、ポリシーグループ名、FINAL を確認します |
| Proxy と Config は成功、Direct は失敗 | 対象が現在の直接接続ネットワークから到達できないか、直接接続時の DNS 結果に異常があります | DNS の応答結果と、Config で対象に設定されたポリシーを確認します |
| 3つのモードすべてが失敗 | ローカルネットワーク、システムのネットワーク権限、DNS の基本設定がより疑わしい状態です | 接続をオフにして元のネットワークを確認し、Settings → DNS を確認します |
| Scene では失敗し、手動の Config では成功 | Scene のトリガー条件または選択中の設定が現在のネットワークに合っていません | Wi-Fi、ネットワーク状態、構成に対する Scene の判定条件を確認します |
結論：サーバーを固定してからモードを比較する
同じサーバーで Proxy はアクセスでき、Config はアクセスできない場合、サーバー障害の優先度はすでに低くなります。この時点でサーバーを頻繁に切り替えると変数が増えるだけなので、ルールのマッチ結果とポリシーグループ名を直接確認してください。
Scene を使用している場合、トラブルシューティング中は一時的に手動の Direct、Proxy、Config へ切り替えます。基本経路が復旧したら Scene に戻り、トリガー条件を確認してください。これにより、シーン切り替えとルール判定が同時に影響するのを避けられます。
第3層：DNS の名前解決が中断していないか確認する
DNS はドメイン名をアドレスへ変換します。DNS に失敗すると、サーバーの遅延テストには結果が表示されるのに、ドメイン名を入力した後でWebページが長時間読み込み中になることがあります。接続済みのアプリやキャッシュを利用する一部のアプリだけが一時的に正常な場合もあるため、「一部は使える」ことだけで DNS 問題を除外することはできません。
Settings → DNS を開き、まず現在の項目を記録してから、アクセスできない DNS アドレス、誤った暗号化 DNS URL、重複設定がないか確認します。従来の DNS は通常 UDP または TCP 53 ポートを使用し、DNS over HTTPS は通常 HTTPS 443 ポートを使用します。通信経路が異なるため、障害時は分けて検証してください。
DNS を記録する
Settings → DNS を開き、現在のアドレス、プロトコル方式、関連するスイッチの状態を保存します。元に戻す必要が生じた場合に、トラブルシューティング前の設定へ復元できるようにします。
形式を確認する
従来の DNS には有効なアドレスを入力し、DNS over HTTPS には完全な HTTPS URL を使用します。行頭と行末の空白を削除し、パスが途中で切れていないか確認してください。
変数を減らす
一時的に、アクセスできることを確認した DNS 項目を1つだけ残してテストします。結果が不明な項目を同時に追加しないでください。変更後は再接続し、新しい設定を現在のネットワークセッションに反映させます。
名前解決を比較する
これまで一度もアクセスしていないドメインと、アクセス済みのドメインをそれぞれテストします。新しいドメインだけ失敗し、キャッシュ済みのページを開ける場合は、DNS クエリの経路を優先して確認します。
リクエスト結果を確認する
Shadowrocket で確認できるリクエストまたはログ情報から、resolve、DNS、timeout などの表示を探し、失敗したドメインを記録します。ブラウザの一般的なエラーページだけで判断しないでください。
従来の DNS：
サーバーアドレス → UDP/TCP 53 → A または AAAA レコードを返す
DNS over HTTPS:
HTTPS URL → TCP 443 → 暗号化クエリ → 名前解決レコードを返すサーバー自体がドメイン名を使用している場合、DNS 障害はサーバー接続の確立前に発生します。サーバーが IP を使用し、対象Webサイトがドメイン名を使用している場合は、サーバー接続は成功しても、対象ドメインを解決できずWebリクエストが失敗することがあります。どちらも接続スイッチはオンに見えますが、障害の位置は異なります。
結論：サーバーのドメインと対象ドメインを区別する
ログに最初にサーバーホスト名の名前解決失敗が表示される場合は、接続確立前の DNS を確認します。サーバーには接続できていて、対象ドメインへのアクセスだけが失敗する場合は、トンネル内の対象ドメインの解決経路と、Config が DNS リクエストをどう処理しているかを確認します。
第4層：Config のルール順序と FINAL を確認する
Proxy ではアクセスできるのに Config ではアクセスできない場合、重点をルールへ移します。Shadowrocket の Config は通常、ルールを上から順に照合し、最初に一致したルールがポリシーを決定します。FINAL はそれまでに一致しなかったリクエストを処理するため、通常はルールの末尾に置かれます。
次の例は、指定したドメインサフィックスに PROXY を適用し、ローカルネットワークのアドレスと GEOIP 条件に一致するアドレスに DIRECT を適用し、それ以外のリクエストを FINAL から PROXY へ渡します。PROXY は現在の Config に実際に存在するポリシーまたはポリシーグループ名と一致している必要があります。別の名前を使用している場合は、ルール名とポリシー名を完全に一致させてください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：ドメインサフィックスで照合します。メインドメインとサブドメインを対象にできます。
- DOMAIN-KEYWORD：ドメインに指定したキーワードが含まれる場合に照合します。通常、サフィックスルールより広い範囲を対象にします。
- IP-CIDR：アドレス範囲で照合します。no-resolve を付けると、照合のために追加のドメイン解決を行いません。
- GEOIP：対象 IP の地理データベース結果で照合するため、通常は先に対象 IP を取得する必要があります。
- FINAL：それまでに一致しなかった残りのリクエストを処理します。欠落や誤ったポリシーにより、未照合の通信が想定外の動作になることがあります。
ルールでよくある問題は、構文の数が不足していることではなく、順序が競合していることです。たとえば、範囲の広い DOMAIN-KEYWORD が正確な DOMAIN-SUFFIX より前にあると、リクエストを先に取得する可能性があります。対象ルールより前に広範囲の IP-CIDR がある場合も、後続ルールが照合されなくなることがあります。
Config を開き、現在チェックされているものが実際に編集している設定か確認します。変更後に保存して再接続し、Config モードでテストしてください。Shadowrocket のリクエスト詳細で対象が DIRECT に一致し、PROXY を想定していた場合は、ルールの順序または内容を調整します。ポリシー名が存在しないと表示される場合は、ルールの参照先を修正します。
症状：Proxy は利用できるが、Config ではアクセスできない
原因と対処：統一プロキシによるサーバー経路の確認は成功しています。Config に誤った DIRECT、REJECT、またはポリシー参照が含まれている可能性があります。対象リクエストの一致結果を確認し、最初の関連ルールから順番を確認してください。
症状：一部のドメインだけ開けない
原因と対処：失敗したドメインが範囲の広すぎる DOMAIN-KEYWORD に一致しているか、想定した DOMAIN-SUFFIX の対象になっていない可能性があります。完全なホスト名を記録し、より正確なルールを追加して、広範なルールより前に置いてテストしてください。
症状：設定を変更しても結果が変わらない
原因と対処：有効化されていない Config を編集したか、現在の Global Routing が Proxy、Direct、Scene のままになっている可能性があります。Home に戻り、Config モードと選択中の設定を確認してから、再接続してください。
第5層：On Demand、サブスクリプション、ローカルネットワークの影響を除外する
Settings → On Demand では、ネットワーク条件に応じて接続を開始できます。手動で切断してもすぐ再接続する場合や、Wi-Fi を切り替えた後のモードが想定と異なる場合は、On Demand を一時的にオフにして基準テストを行います。手動接続が正常だと確認してから、トリガー条件を1つずつ戻してください。
サブスクリプションの更新も独立した工程です。クライアントを開けることは、サブスクリプション URL が現在有効であることを意味しません。更新に成功しても、含まれるすべてのサーバーが利用できるとは限りません。サブスクリプションの有効性、アカウント状態、サーバーのメンテナンス状況は、ユーザー自身のサービス提供者の情報で確認してください。
接続スイッチがいつも自動でオンになる場合
Settings → On Demand を開き、オンデマンド接続を一時的にオフにしてから、Home に戻って手動で切断します。自動接続が止まる場合、トリガーは On Demand から発生しています。その後、Wi-Fi やネットワーク状態などの条件を確認し、1つずつ戻してテストしてください。
Wi-Fi では失敗するのに、モバイルデータ通信では正常な場合
まず Shadowrocket をオフにし、その Wi-Fi で通常のページにアクセスしてポータルログインが必要か確認します。元のネットワークが正常になったら、同じサーバーと同じ Global Routing に固定してテストし、現在の Wi-Fi が対象経路を制限しているか判断します。
サブスクリプションの更新に成功したのに、なぜ接続できないのか
更新成功が示すのは、設定内容を取得して解析できたことだけです。Home に戻り、特定のサーバーでテストを実行し、Proxy モードで実際のリクエストを確認してください。複数のサーバーで結果が異なる場合は、それぞれ記録し、更新状態をサーバーの稼働状態と同一視しないでください。
Direct は使えるのに、Config と Proxy は使えない場合
ローカルネットワークの基本接続はおそらく正常です。まず1台のサーバーに固定し、Proxy でサーバー経路を確認します。Proxy が失敗する場合は、サーバー状態、ドメイン、ポート、認証情報を確認し、いったん Config ルールを変更しないでください。
1つのアプリだけネットワークに接続できない場合
まず Shadowrocket をオフにした状態で、そのアプリがネットワークに接続できるか確認します。次に、そのアプリのリクエストドメインとルールの一致結果を確認してください。他のアプリが同じモードで正常なら、対象ドメイン、IP-CIDR、REJECT ルール、アプリ自身のネットワーク権限を重点的に確認します。
システム時刻が正確かどうかも確認できます。一部のプロトコルは TLS や時刻に関係する検証に依存するため、端末の時刻が大きくずれるとハンドシェイクに失敗することがあります。システムの「日付と時刻を自動設定」を使用し、接続を再確立してください。Wi-Fi とモバイルデータ通信を切り替えた後も、切断して再接続し、ルーティングと DNS セッションを再確立することをおすすめします。
結果を整理して設定を戻す
テストが終わったら、結果を「ネットワーク条件 + サーバー + Global Routing + DNS + Config」の組み合わせとして記録します。たとえば「同じ Wi-Fi で Direct は成功、固定サーバーの Proxy はタイムアウト、別の既存サーバーへ切り替えると復旧」のように記録します。これにより、単にインターネットへ接続できないと書くのではなく、問題がサーバー経路にあることを明確にできます。
自分のサービス提供者へ問い合わせる場合は、発生時刻、ネットワーク種別、サーバー名、プロトコルの種類、ポート、エラー原文、比較結果を伝えれば十分です。サブスクリプション URL に含まれる token、パスワード、Private Key などの認証情報は、スクリーンショットや公開記録に載せないでください。
- 元のネットワークが失敗：まず Wi-Fi、モバイルデータ通信、ポータル認証を確認します。
- Direct は成功、Proxy は失敗：サーバー状態、ポート、認証、サーバーのドメイン解決を確認します。
- Proxy は成功、Config は失敗：ルール順序、ポリシー名、FINAL、現在有効な Config を確認します。
- ドメインだけ失敗し、既存の接続は動作する：Settings → DNS と名前解決エラーを確認します。
- 手動設定は正常、自動シーンは失敗：Settings → On Demand と Scene の条件を確認します。
- 復旧後は、一時的に使用したモード、DNS、テストルールを確認済みの設定へ戻します。
Shadowrocket は App Store でのみ提供されています。製品ページの開発者名は Shadow Launch Technology Limited、アプリ ID は 932747118 と表示されます。主な利用端末は iPhone と iPad です。対応範囲とシステム要件は App Store ページの記載に従ってください。再インストールする前に、設定のバックアップと購入済み項目の復元方法を確認し、再インストールを最初の対処にしないでください。