Shadowrocketのスイッチは端末側の接続状態を示すもので、サーバー、DNS、接続先のWebサイトがすべて利用可能であることを意味しません。利用中のサービスと設定があることを前提に、ネットワーク、サーバー設定、Global Routing、DNS、ルールの順に確認します。変更は一度に1つにして、同じURLで再テストし、最後に通常の設定へ戻してください。
1. 端末のトンネルと実際の通信を切り分ける
システムにVPN状態が表示されている場合、端末上にネットワーク経路が確立されています。ただし、接続先サーバーが接続を受け付けるか、ドメインを名前解決できるか、ルールでどの経路が選ばれるかは、それぞれ確認が必要です。スイッチがオンのままだからといって、原因が必ずブラウザーにあるとは限りません。また、Webページが開かない原因をすべてDNSの問題と決めつけないでください。
この流れは確認範囲を分けるためのもので、すべてのリクエストが常に同じ順序で名前解決・振り分けされるという意味ではありません。ドメインルールが先に一致する場合もあれば、IPルールの判定に名前解決の結果が必要な場合もあります。まず次の項目を確認し、基本のネットワーク自体が利用できるかを切り分けましょう。
- 現在Homeで選択しているサーバー、Global Routingのモード、Configで有効になっている設定を記録します。変更前に元へ戻せるコピーを保存してください。
- Shadowrocketを一時的にオフにし、Safariで普段直接アクセスできるWebページを開きます。それでも開けない場合は、まずWi-Fiの認証ページを完了するか、モバイルデータ通信の権限と現在のネットワーク状態を確認してください。
- 基本のネットワークが復旧したら接続をオンにし、同じWebページにアクセスします。すべて失敗するのか、一部のドメインだけか、特定のアプリだけかを記録してください。
- 可能であればWi-Fiとモバイルデータ通信の両方で再テストします。ネットワークを切り替えたらリクエストを新たに実行し、以前のページのキャッシュ結果を新しい結果として扱わないでください。
2. Homeのサーバーと利用中のサブスクリプションを確認する
Homeで選択中のサーバーが、有効な自分の設定に含まれるものであり、古い無効な項目ではないことを確認します。Connectivity Testは到達可能性を判断する手がかりになりますが、テスト先や方法は実際にアクセスするWebサイトと同一ではありません。遅延時間が表示されてもすべてのWebページにアクセスできるとは限らず、テストがタイムアウトした場合も、実際の接続ログとあわせて判断してください。
- アドレスとポート：サーバーのドメイン名またはIPアドレスとポートを正確に照合します。サブスクリプションのWebページのURLをサーバーアドレスとして入力しないでください。たとえばサービスの設定がポート
443の場合、クライアント側も同じ値にします。一般的なポート番号だからといって、サービスが利用できるとは限りません。 - 認証情報：Shadowsocksのパスワードと暗号化方式、VMess/VLESSのUUID、Trojanのパスワードなどは相互に置き換えられません。プロトコル名からほかの項目を推測せず、自分のサービスの設定値を確認してください。
- トランスポートとTLS：設定でWebSocket、TLS、その他のトランスポートを使用している場合は、path、Host、SNIなどの該当項目も確認します。IPアドレスに接続する場合でも、TLSで必要となるサーバー名がそのIPアドレスとは限りません。
- プロトコルの違い：Hysteria2とWireGuardはUDP通信を使用します。あるネットワークでTCP通信が正常でも、同じネットワーク上のUDP経路も正常であるとは限りません。プロトコルをむやみに変更せず、正しい既存の設定値で再テストしてください。
項目がサブスクリプション由来の場合は、サブスクリプションが正常に更新されたか、リストに古い情報が残っていないかを確認します。更新が必要な場合はHomeで既存のサブスクリプションを更新し、Settings → Subscribeで関連設定を確認してください。サブスクリプションの更新は設定情報の取得であり、サーバーへの接続は実際の外向き通信です。更新が成功しても項目が使えるとは限らず、更新に失敗しても既存項目がすべて無効とは限りません。
エラー：connection refused
原因と対処：通常、接続先アドレスまたは中間機器が接続を明示的に拒否したことを示します。まず該当ログの接続先がサーバーかWebサイトかを確認し、アドレス、ポート、接続先で待ち受けが有効かを調べてください。すぐにDNSを変更する必要はありません。
エラー：i/o timeout
原因と対処：いずれかのI/O処理がタイムアウトしたことを示します。この1行だけでは障害箇所を特定できません。前後のログを確認し、名前解決、サーバー接続、接続先へのアクセスのどの段階で発生したかを判断してから、別のネットワークでも比較してください。
上記は接続ログに表示されることがあるエラーの例であり、すべての端末に同じメッセージが表示されるわけではありません。問い合わせ時はエラーの原文と発生した段階を残し、パスワード、UUID、秘密鍵、サブスクリプショントークンは伏せてください。設定全体を公開しないでください。
3. Global Routingでモードとルールを比較する
Home → Global Routingで現在のモードを確認します。Proxy、Direct、Config、Sceneはそれぞれ用途が異なります。「接続がオン」でも、すべてのリクエストが選択中のサーバーを経由するとは限りません。特にDirectでは、スイッチをオンにしてもリクエストが自動的にリモートプロキシ経由になることはありません。
| モード | 意味 | 確認ポイント |
|---|---|---|
Proxy | リクエストをプロキシ経由で処理 | 一時的に選択中のプロキシ経路を検証し、Configのルールによる振り分けの影響を切り分ける |
Direct | リクエストを直接接続で処理 | 現在のネットワークで直接接続できるか確認する。リモートサーバーの利用可否を証明するものではありません |
Config | 現在の設定にあるルールに基づいて通信方式を決定 | 一致するルール、ポリシーグループ、最終的な通信経路を確認 |
Scene | 設定済みのシーンに基づいてルートを選択 | 現在のネットワークに適用されるシーンと、実際に有効な設定を確認 |
サーバーとアクセス先のURLを変えずに、ProxyとConfigを一時的に切り替えて比較します。ProxyではアクセスできてConfigでは失敗する場合は、ルールやポリシーグループを重点的に確認します。ただし、モードによってDNSやリクエスト経路が異なる可能性もあります。両方のモードで失敗する場合は、Config全体をすぐ削除せず、サーバー、基本ネットワーク、DNSを引き続き確認してください。
Sceneは設定済みのシーンに応じて判断してください。Configと同じものだと決めつけないでください。テスト後は元のモードに戻します。比較用のProxyは、日常設定の汎用的な代替ではありません。
4. DNSは根拠を確認してから変更する
DNSはドメイン名をアドレスに変換します。サーバーアドレス自体がドメイン名の場合、リモートサーバーへの接続前に名前解決が必要になることがあります。Webサイトへのリクエストでも、別途名前解決が行われる場合があります。そのため、「サーバーのドメイン名を解決できない」問題と「Webサイトのドメイン名を解決できない」問題は分けて記録してください。
- 影響範囲を確認：普段使うドメインを2つ、それぞれテストします。1つのドメインだけ失敗する場合は、まずそのドメインとDNSレコードを確認し、すぐに全体設定を変更しないでください。
- 有効な設定を確認：Configで現在使用中のファイルを確認し、DNS関連の設定を調べます。さらにSettingsで実際に有効になっているDNSオプションと照合してください。無効な設定ファイルだけを確認しても、原因の特定には役立ちません。
- 上流への到達性を確認：カスタムDNSアドレスには、現在の通信経路からアクセスできる必要があります。DoHを使用している場合は、HTTPS接続、証明書の検証、DoHサービスのドメイン名解決も事前条件になることがあります。
- 変更を1つずつ戻す：DNSを変更した後に問題が発生した場合は、まず変更前の設定に戻し、再接続してリクエストを送ります。DNS、サーバー、ルールを同時に変更すると、どの変更が影響したのか特定できません。
ログに証明書名の不一致や証明書の期限切れが表示される場合は、まず端末の日付と時刻、サービス設定のサーバー名、接続先の証明書を確認してください。証明書検証を無効にして問題を隠したり、TLSエラーを通常のDNSタイムアウトとして扱ったりしないでください。
5. FINAL、REJECT、ルールの順序を確認する
問題が主にConfigモードで発生する場合は、現在のConfigを開き、ルールの順に対象ドメインがどの項目に一致するか確認します。ルールは通常上から順に評価され、先に一致した時点で後続の例外ルールには進みません。末尾に許可ルールを追加しただけでは、それより前にあるREJECTを上書きできません。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTこの例は構文の説明用です。example.comと192.0.2.0/24は例であり、設定全体をそのまま現在のConfigと置き換えないでください。例のFINAL,DIRECTは、それ以前のルールに一致しないリクエストを最終的に直接接続することを意味します。すべてのユーザーにこの方針が適しているという意味ではありません。
DOMAIN-SUFFIXは、指定したドメインのサフィックスとそのサブドメインに一致します。対象範囲を広くしすぎていないか、特に共有リソースやログイン関連のドメインを確認してください。IP-CIDRはIPv4のアドレス範囲に基づいて一致します。no-resolveは、このルールのためだけに積極的な名前解決を行わないようにする指定であり、DNS全体を無効にするものではありません。GEOIPはIPアドレスの地理的な割り当て先に基づいて一致します。判定はアドレスに依存するため、Webサイトの表示言語から一致する地域を推測することはできません。REJECTは通信を拒否するポリシーであり、プロトコルではありません。ドメインルール、ルールセット、その他の項目によって、Webページに必要なリクエストがREJECTに振り分けられていないか確認してください。FINALは、それ以前のルールに一致しなかった場合に適用される最終ポリシーです。ポリシーグループを指定している場合は、ルールの最終行だけでなく、グループ内で現在選択されている項目も確認してください。
ページ自体は開くのに画像、ログイン、APIに失敗する場合は、アドレスバーのメインドメインだけでなく、失敗しているリソースのドメインも確認してください。特定のルールが誤って通信を遮断していると分かった場合は、まずバックアップを取り、そのルールの範囲、順序、ポリシーを調整します。再テストに成功したら変更は最小限にとどめ、1つのページを直すために拒否ルールをすべて削除しないでください。
6. 症状に応じて再テストし、必要な情報を記録する
変更を1つ行うたびに、元と同じURLで再テストします。ネットワークの種類、サーバー項目名、Global Routingのモード、失敗するドメイン、エラーの原文、テスト時刻を記録すると、一時的な失敗と再現性のある問題を区別しやすくなります。以下のQ&Aでよくあるケースを確認しましょう。
「遅延テストでは数値が表示されるのに、Webページが開かないのはなぜ？」
テストで確認できるのは、テスト対象とその経路に限られます。Homeで選択中の項目を確認し、同じWebページをProxyとConfigの両方で試します。Configだけで失敗する場合は、そのドメインに適用されるルールと最終ポリシーを確認してください。
「Wi-Fiでは接続できないのに、モバイルデータ通信に切り替えると使えるのはなぜ？」
まず接続をオフにし、Wi-Fiの認証が完了していることを確認してから、サーバーと設定を変えずに再テストします。そのWi-Fiだけで引き続き失敗する場合は、DNS、関連ポート、UDP経路の到達性を確認してください。それだけで設定全体が間違っていると判断しないでください。
「Webページは表示されるのに、特定のアプリが読み込み中のままです」
該当アプリを開き直し、実際にリクエストしているドメインを確認します。API、メディア、ログイン関連のリクエストがREJECTされていないか、別のポリシーに振り分けられていないかを調べてください。メインのWebページが使えても、アプリが必要とするすべてのドメインにアクセスできるとは限りません。
「サブスクリプションの更新に失敗しました。サーバーをすべて削除すべきですか？」
最初にリストをすべて消去する必要はありません。既存の項目を残したままサブスクリプションリンクの状態を確認し、Settings → Subscribeで更新関連の設定を確認してください。既存の設定値が無効だと確認できた場合に限り、自分が利用している有効なサービス情報に基づいて更新します。
原因を特定できない場合は、個人情報などを伏せたエラーの抜粋と上記の比較結果を、利用中のサービスのサポート窓口に伝えてください。Shadowrocketアプリの購入とリモートサービスの状態は別の問題です。アプリを再入手しても、無効なサーバーや誤ったルールは修復されません。当サイトではサーバーやサブスクリプションの提供、販売、推奨は行っていません。
- 確認のために一時変更したGlobal RoutingとOn Demandの設定を元に戻します。
- 動作確認済みの最小限の修正を残し、変更前後の設定コピーを保存します。
- サブスクリプションリンク全体、パスワード、UUID、秘密鍵、すぐに利用できるQRコードを送信しないでください。