接続スイッチがオンでも、起動しているのは端末側の接続機能だけです。サーバー、名前解決、Webリクエストがすべて正常とは限りません。この記事では、ご自身が利用しているサービスとサブスクリプションがあることを前提に、ネットワーク、サーバー、Global Routing、DNS、ルールの順に確認します。手順はiPhone / iPadのHome、Config、Settingsを基準にしています。Mac、Windows、Android、Linuxでも同じ順序で確認できますが、設定画面の場所はプラットフォームによって異なります。
1. まず基本ネットワークに接続できるか確認する
Shadowrocketの接続表示がオンなのにブラウザーが読み込み中のままでも、サーバー、DNS、設定ファイルを一度に変更しないでください。条件を一つずつ変更し、同じWebページの変更前後の結果を記録すると、原因がネットワークにあるのか、プロキシ接続やルーティング設定にあるのかを切り分けやすくなります。
テストには、普段直接アクセスできるHTTPSページと、利用中のサーバー経由でアクセスするページを一つずつ使います。特定サイトのメンテナンス、アカウント状態、アクセス制限を、接続全体の障害と混同しないでください。また、キャッシュされたページが表示されるだけで、ネットワークが正常だと判断するのも避けましょう。
-
自動接続を一時停止する
Settings → On Demandを開き、現在の条件を記録してから自動接続を一時的にオフにします。その後Homeに戻り、接続スイッチをオフにしてください。ネットワークの切り替えをきっかけに、手動切断後すぐ再接続されるのを防げます。
-
基本ネットワークを確認する
ブラウザーで、直接アクセスできるWebページを再読み込みします。接続をオフにしても開けない場合は、Wi-Fiのログイン認証、モバイルデータ通信の許可、現在のネットワークを先に確認してください。すぐにConfigを変更する必要はありません。
-
別のネットワークで再テストする
可能であれば、同じ端末をWi-FiとCellularにそれぞれ接続し、同じURLを開きます。一方のネットワークだけで失敗する場合は、ネットワーク条件が関係している可能性があります。ただし、サーバーのポート、DNS、認証制限のどれが原因か、さらに切り分けが必要です。
-
現在の状態を記録する
Homeで選択中のサーバー、Global Routingのモード、Configで有効な設定ファイルを記録します。接続を再度オンにしてから次の確認に進み、テスト中に設定全体をまとめて更新しないでください。
2. サーバーを確認する：遅延が表示されてもWebページが開くとは限らない
Homeで、選択中のサーバーがご自身の有効なサブスクリプションに含まれているか確認します。リストにサーバーが表示されるのは、設定が読み込まれていることを示すだけです。サブスクリプションの内容が変更された、アカウントの有効期限が切れた、接続先が無効になった場合でも、古い情報が端末に残っていることがあります。まずご自身のサブスクリプションを更新し、選択中のサーバーが引き続き有効か確認してください。
サーバーアドレス、ポート、プロトコル、認証情報が、ご自身のサービス提供元から案内された情報と一致しているか確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは必要な項目が異なります。あるプロトコルのパスワード、UUID、鍵を別のプロトコルに流用しないでください。TLSを使う接続では、サーバーが要求するサーバー名と端末の時刻も確認します。証明書検証を無効にして対処することは避けてください。
サーバーテストに遅延が表示されても、Webページへのリクエスト全体が成功するとは限りません。テストは特定の方法と接続先だけを確認している場合があり、実際の閲覧では名前解決、ハンドシェイク、認証、接続先サイトの応答も関係します。逆に、テストがタイムアウトしただけでアカウントが無効だとは断定できません。実際のリクエスト記録もあわせて確認してください。
エラー：Connection timed out
原因：制限時間内に接続が完了していません。ネットワークのパケットロス、到達できないポート、リモート側から応答がないなどの可能性があります。
対処：記録にある接続先アドレスとポートを確認し、別のネットワークでも試します。そのうえで、ご自身が利用できる別のサーバーと比較してください。このエラーだけを根拠に認証情報を変更しないでください。
エラー：Connection refused
原因：接続先ポートから明示的に拒否されています。ポートの入力ミス、サービスが待ち受けていない状態、中継機器による拒否などが考えられます。
対処：ご自身のサービス情報とポートを照合してください。設定が一致しているのに同じエラーが続く場合は、ご利用のサービス提供元にポートの稼働状況を確認してください。
上記はネットワーク診断で表示されることがある英語のエラー文です。プラットフォームやログの種類によって、大文字・小文字や前後の文言が異なる場合があります。接続先アドレスもあわせて確認してください。プロキシサーバーへの接続失敗と、接続先Webサイトへの接続失敗は、障害が起きている場所が異なります。
3. Global Routingを確認する：ProxyとConfigで一つずつ比較する
Home → Global Routingで現在のモードを確認します。Directはリクエストを直接接続するモードで、「利用可能なサーバーを自動選択する」という意味ではありません。Configでは、現在の設定ファイルのルールに従って通信先が決まります。Sceneは設定済みのシーン条件に基づいて動作するため、Configと同じ動作だと決めつけないでください。
| モード | トラブルシューティングでの役割 | 次に確認すること |
|---|---|---|
| Proxy | 通常のWebリクエストを現在選択中のプロキシに送ります。一般的なルール分岐の影響を抑えて比較できます。 | Homeで現在選択中の項目を確認します。固定サーバーではなく、ポリシーグループが選択されている場合があります。 |
| Direct | プロキシサーバーを経由せず、直接接続して比較します。 | 接続先に通常から直接アクセスできない場合、このモードで失敗してもサーバーが無効とは限りません。 |
| Config | 現在のConfigのルールに照らして通信先を判定し、ポリシーを適用します。 | 失敗したリクエストに実際に適用されたルールと、最終的なポリシーを確認します。 |
| Scene | 設定済みのシーン条件に応じて動作を選択します。 | 現在のネットワークに適用されるシーンを確認します。トラブルシューティングの途中で条件を追加しないでください。 |
一時的にProxyへ切り替え、サーバー、ネットワーク、テストするURLは変えずに、同じページへ再度アクセスします。Proxyでは開けてConfigでは開けない場合は、ルールとポリシーグループを優先して確認します。両方で失敗する場合は、FINALの誤りと決めつけず、サーバーとDNSを調べてください。テスト後は元のモードに戻し、診断用の設定をそのまま使い続けないようにします。
ポイント：モードの違いから原因を絞り込む
同じネットワーク、同じサーバー、同じURLでProxyは成功し、Configだけ失敗する場合に限り、次の確認でルールの適用状況とポリシー選択を重点的に調べます。
4. DNSを確認する：名前解決の失敗と接続の失敗を切り分ける
名前解決に失敗すると、接続に使う宛先アドレスが得られません。一方、サーバーへの接続失敗は、名前解決の成功後に起きている可能性があります。どちらもブラウザーには「ページを開けません」と表示されることがあるため、ブラウザーの表示や接続スイッチだけで判断せず、具体的なリクエスト記録を確認してください。
Configを開き、現在有効な設定ファイルの[General]にあるDNS関連のパラメーターを確認します。Settingsに設定済みのDNSと、設定がどのように上書きされるかも確認してください。まず元の値を記録し、設定ファイルとDNSアドレスを同時に変更しないでください。カスタムDNS自体への接続も必要です。暗号化DNSを使う場合は、接続経路と最初の名前解決も考慮します。
- ドメイン関連のリクエストだけ失敗する：名前解決エラーが発生していないか、現在のネットワークからDNSサーバーへ接続できるか確認します。IPアドレスへの直接アクセスは補助的な確認にとどめ、HTTPSでのドメイン名テストの代わりにはしないでください。
- 名前解決はできるが接続がタイムアウトする：接続先IP、適用されたポリシー、サーバーへの接続を引き続き確認します。DNSを何度も切り替える必要はありません。
- Wi-Fiだけで失敗する：まずネットワーク認証が完了していることを確認し、Cellularでも比較します。ネットワーク内の名前解決制限は、サーバー障害と似た症状になる場合があります。
- 変更後も結果が変わらない：既存のWeb接続を閉じて再接続し、同じURLを読み込み直してください。キャッシュや再利用された接続を、新しい設定の効果と誤認しないようにします。
エラー：Could not resolve host
原因：リクエストを行ったコンポーネントが、ドメイン名に対応するアドレスを取得できませんでした。端末側の名前解決、またはリモート側の名前解決処理でエラーが起きている可能性があります。
対処：まずドメイン名の入力とDNSへの到達性を確認します。次に、リクエストの経路から、どちら側で名前解決に失敗したかを判断してください。テストツールが表示したエラーの場合は、そのツールの接続経路を基準に確認します。
5. ルールを確認する：リクエストが本当にFINALに到達しているか
Global Routing → Configに戻り、現在有効な設定ファイルの[Rule]を確認します。ルールは通常、上から順に照合されます。有効な先行ルールに一致すると、それ以降のルールは評価されません。FINALは先行ルールに一致しなかった場合のフォールバックであり、すべての通信が必ず通る固定の段階ではありません。
以下はルール構成の例であり、完全な設定ファイルではありません。example.comと192.0.2.0/24はドキュメント用の例示アドレスです。この内容でご自身のConfig全体を置き換えないでください。また、ポリシー名は設定内で実際に利用できるポリシーと一致させる必要があります。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：指定したドメインとそのサブドメインに一致します。失敗したページのドメインが先行するDIRECTルールに一致している場合、FINALを変更してもそのリクエストには影響しません。
- IP-CIDR：接続先IPの範囲に一致します。例にある
no-resolveは、このルールに一致させるための名前解決を明示的に行わない指定です。アプリ全体のDNSを無効にするものではありません。 - GEOIP：接続先IPの地理情報に基づいて一致を判定します。Webページの言語やドメインの末尾で判定するものではありません。名前解決の結果が変わると、その後の判定に影響する場合があります。
- FINAL：先行ルールに一致しなかったリクエストに最終ポリシーを適用します。ポリシーグループを指定している場合は、グループ内で現在選択されているサーバーが有効かどうかも確認してください。
失敗するリクエストを一度再現し、接続ログで宛先ドメイン、適用されたルール、最終ポリシーを確認します。1つのWebページが複数のドメインにリクエストを送ることがあります。メインの文書は表示されても、スクリプトや画像の読み込みに失敗すると、ページが白くなったり、一部しか表示されなかったりします。失敗したリソースのドメインを個別に確認し、ページ全体のドメインを別のポリシーにまとめて変更しないでください。
ログでFINALに一致していても、最終ポリシーが無効なサーバーを指しているなら、サーバーまたはポリシーグループの選択を修正します。広すぎる先行DIRECTルールに一致している場合は、まずバックアップを取り、そのルールの対象範囲を絞ってください。一度に変更するルールは一つにし、テストを繰り返します。ルール全体を削除して、原因を判断する手がかりを失わないようにしてください。
6. よくある質問と、確認後に設定を戻す方法
遅延が表示されるのに、Webページが読み込み中のままなのはなぜですか？
遅延テストでは、Webリクエストのすべての処理を確認できません。同じサーバーを選んだままHome → Global Routingで一時的にProxyへ切り替え、同じURLを開きます。その後、リクエストで名前解決とリモート接続が完了しているか確認してください。遅延の数値だけを見てサーバーを何度も切り替えないでください。
Proxyに切り替えたら直りました。このまま使い続けてもよいですか？
Configのルールとポリシーを重点的に確認する必要があるということです。Proxyを長期間使う必要があるとは限りません。Configで失敗したリクエストに適用されたルールを確認し、修正後にGlobal Routing → Configへ戻して、同じWebページと関連リソースを再テストしてください。
サブスクリプションを更新できたのに、接続できないのはなぜですか？
更新成功は、サブスクリプションの内容を取得して処理できたことを示すだけで、すべてのサーバーがその時点で利用可能とは限りません。Homeに戻って選択中のサーバーを確認し、アドレス、ポート、有効期限を調べます。認証情報はご自身のサービス情報と照合してください。
接続をオフにしても、すぐに自動でオンになる場合はどうすればよいですか？
Settings → On Demandで自動接続の条件を確認し、一時的にオフにしてから手動でテストします。確認が終わったら必要な条件を元に戻し、Wi-FiとCellularを切り替えたときに想定どおり動作するか確かめてください。
確認後は、一時的に変更したGlobal Routing、DNS、On Demandの設定を元に戻します。問題を安定して再現できる範囲で、端末のプラットフォーム、ネットワークの種類、発生時刻、宛先ドメイン、エラー文、適用ルール、最終ポリシーを記録してください。ご自身のサービス提供元に問い合わせる際は、サブスクリプションURL全体、認証パスワード、鍵を公開しないでください。
- 基本ネットワークで失敗する：まずネットワークへのログイン、ルーター、端末のネットワーク接続権限を確認します。
- ProxyとConfigの両方で失敗する：サーバー設定、リモート側への到達性、名前解決を優先して確認します。
- Configだけ失敗する：先行ルール、FINAL、ポリシーグループで現在選択中の項目を確認します。
- 一部のリソースだけ失敗する：リソースのドメインごとにリクエスト結果を確認し、有効なルールは残したまま、原因を特定した項目だけ変更します。
再インストールする場合や、プラットフォーム別のインストール手順を確認する場合は、このサイトの全プラットフォーム対応ダウンロードページをご利用ください。Shadowrocketはクローズドソースの商用アプリです。アプリの入手と接続サービスは別のものです。アプリの買い切り購入に接続サービスのプランは含まれません。インポートやテストには、ご自身が利用しているサブスクリプションが必要です。iPhone / iPadのシステム要件はApp Storeの掲載内容をご確認ください。Mac版はAppleシリコンとIntelの2種類があります。