Shadowrocketをオンにしてもインターネットに接続できないときの対処法｜サーバー・Global Routing・DNS・ルールを確認

この記事の要点

Shadowrocketの接続をオンにすると、この端末で接続処理が始まりますが、リモートサーバーやドメイン名の名前解決、個々のリクエストに適用されるポリシーまで正常とは限りません。利用中のサービス事業者とサブスクリプションがあることを前提に、基本的なネットワーク接続から順に、サーバー、Global Routing、DNS、ルールの問題を切り分けます。変更は一度に1項目にとどめ、同じWebページとリクエストログで結果を確認してください。

まず基本状態を確認：接続をオフにして通信できるか

サブスクリプションの削除やアプリの再インストールから始めないでください。まず、Shadowrocketの接続をオンにしたときだけ問題が起きるかを確認します。接続をオフにしても、現在のWi-Fiまたはモバイル通信で普段直接開けるWebページにアクセスできない場合は、基本的なネットワーク接続、Wi-Fiのログイン認証、システムのネットワーク権限を先に確認してください。接続アイコンだけでは、この確認の代わりになりません。

現在の状態を記録する

Homeで選択中のサーバー、Global Routingの設定、Configで使用中の構成を記録します。現在の構成のコピーを保管してください。記録にパスワード、サブスクリプションURL全文、認証情報を含めないでください。
接続をオフにする

Homeで接続をオフにし、Safariで普段直接アクセスできるHTTPSページを開きます。それでも失敗する場合は、Wi-Fiへのログインが必要か、モバイル通信が利用できるかを確認してから、アプリ内の確認に進んでください。
テスト対象を固定する

直接アクセスできるWebページを1つ、通常はProxy経由でないとアクセスできないWebページを1つ選びます。その後はURLを変えず、変更のたびに同じリクエストを再実行してください。異なるWebサイトの結果を比べないようにします。
自動接続を一時停止する

手動で切断しても接続が自動的に再開する場合は、Settings → On Demandを確認してください。元の設定を記録してから、テスト中は一時的にOn Demandをオフにします。比較テストが終わったら設定を戻し、自動接続が確認を妨げないようにします。

テストでは「Webページが開かない」場合と「特定のAppの機能が失敗する」場合を区別してください。Webサイト側の障害も考えられます。Webページは開けるのに動画再生や通話が失敗する場合は、該当する通信でUDPが使われているかも確認してください。接続全体が使えないとすぐに判断しないでください。

1つ目：サーバーへの接続と認証情報

Homeに戻り、テストするサーバーが選択されていることを確認してからConnectivity Testを実行します。まずタイムアウトが続くか、その後、応答が安定しているかを確認してください。テストに成功しても、テストに使われた経路や接続先に到達できたことしか確認できず、すべてのWebサイト、UDP通信、サーバー認証が正常とは限りません。遅延が小さくても、実際のWebページが開くとは限りません。

443

HTTPSでよく使われる接続先ポート。Proxyサーバーで必ず使うポートとは限りません

従来のDNSでよく使われるポート。名前解決とWeb接続は別の段階です

1項目

1回の確認で変更するのは1項目だけ。同じ接続先で再テストする

現在のサーバーの編集画面を開き、アドレス、ポート、認証情報を、利用中のサービス事業者から提供された情報と照合します。Shadowsocksの暗号化方式とパスワード、VMessまたはVLESSの識別情報、Trojanのパスワード、TLSが必要な場合のサーバー名や転送パラメータは、それぞれ別の設定です。Webページで一般的に443が使われるからといって、サーバーのポートを独断で443に変更しないでください。

すべてのサーバーでテストに失敗する：まず接続をオフにした状態のネットワークと比較し、サブスクリプションの状態、アカウントの有効期限、サーバーアドレスに変更がないか確認します。
1台のサーバーだけ失敗する：利用中のサーバー一覧から、使用できることが分かっている別のサーバーで再テストします。復旧した場合は、ルール全体を書き換えるのではなく、元のサーバーを優先して確認してください。
テストには成功するが目的の通信は失敗する：Global RoutingとDNSを確認します。また、テストがTCPだけを対象としていて、実際の通信にはUDPが必要ではないかも確認してください。
サブスクリプション更新後に問題が起きた：更新前後のアドレスとプロトコル設定を比較してください。更新が成功したのはデータを取得できたという意味であり、すべてのサーバーが使えるという意味ではありません。

まとめ：まずサーバーを1台ずつ切り分ける

同じネットワーク、同じWebページ、同じGlobal Routing設定のまま、利用中の別のサーバーに切り替えるとアクセスが復旧する場合は、元のサーバーの稼働状況と設定を優先して確認してください。この段階ではDNSとFINALを同時に変更しないでください。

2つ目：Global Routingでモードとルールの問題を切り分ける

Home → Global Routingで現在の設定を確認します。Proxy、Direct、Config、Sceneは4種類のプロトコルではなく、通信の振り分け方法です。診断のために一時的に切り替えた場合は、テスト後に普段の設定へ戻してください。Proxyで一度成功したからといって、すべての振り分けルールが正しいとは限りません。

設定	主な意味	確認すること
Proxy	通信をProxy経由にする。除外設定などは別途確認が必要	選択中のサーバーで対象のリクエストを処理できるか
Direct	通信を直接接続で処理する	現在のネットワークから対象に直接アクセスできるか
Config	現在のConfigに設定されたルールに基づいてリクエストの処理方法を決める	どのルールに一致し、最終的にどのポリシーが適用されたか
Scene	設定済みのSceneに応じたルーティング方法を適用する	設定名だけでなく、現在のSceneで実際に適用されている設定

最初に現在の設定を記録し、一時的にProxyを選択して、同じ失敗対象に再アクセスします。Proxyでは使えてConfigでは使えない場合は、現在のConfigとルールの一致状況を優先して確認してください。ただし、モードによってDNSの経路が異なる可能性もあります。どちらでも失敗する場合は、ルールだけに注目せず、サーバーとDNSの確認に戻ってください。

3つ目：DNSの名前解決と接続経路を確認する

リクエストの処理中にドメイン名の名前解決が行われます。DNSの失敗もサーバー接続の失敗も「Webページが読み込み中のまま」という同じ症状に見えることがあります。リクエストログを開き、失敗が名前解決中なのか、アドレス取得後の接続中なのかを確認してください。Safariの一般的なエラーメッセージだけでDNSの問題と決めつけないでください。

Configで現在使用中の構成を開き、テキスト内の[General]とdns-serverを確認します。DNSサーバーを手動で指定している場合は、アドレスが正しいか、現在のネットワークから到達できるか、まだ確立していないProxy経路に依存していないか確認してください。よく分からないDNS設定を複数重ねないでください。まず以前正常に使えていた構成のコピーに戻し、1項目ずつ比較します。

ドメイン名のIPアドレスを取得できない：DNSサーバーへの到達性、アドレスの入力ミス、現在の構成にある名前解決の設定を優先して確認します。
アドレス取得後に接続がタイムアウトする：接続先への経路、サーバーの状態、ルールのポリシーを確認します。DNSサーバーを変えるだけでは解決しない場合があります。
特定のドメイン名だけ失敗する：ドメイン名、関連ルール、そのWebサイトが別のリソース用ドメイン名に依存していないかを確認します。
ネットワークを切り替えた後に失敗する：Wi-Fiとモバイル通信のそれぞれで再テストし、現在のネットワークがDNSサーバーやサーバーへのアクセスを制限していないか確認します。

エラー：`Could not resolve host`

原因と対処：ドメイン名の名前解決に失敗したときによく表示されるエラーです。具体的な文言は診断ツールによって異なります。まず接続先のドメイン名とDNS設定を確認し、現在のネットワークからDNSサーバーに到達できるかを調べてください。サーバーの認証情報はすぐに変更しないでください。

エラー：`Connection timed out`

原因と対処：制限時間内に接続が完了しなかったことを示します。サーバー側または接続先までの経路で発生した可能性があります。ログで失敗した接続先とポートを確認し、同じネットワークから利用中の別サーバーを試して、個別の障害かネットワーク全体の問題かを切り分けてください。

エラー：`Connection refused`

原因と対処：接続先または経路上の機器によって接続が明示的に拒否されたことを示す場合が多くあります。ログの接続先がProxyサーバーかWebサイトかを確認し、該当するポートとサービスの状態を調べてください。Webページを何度も再読み込みしても、間違ったポートは直りません。

4つ目：ルールの順序、ポリシー参照、FINALを確認する

Global RoutingでConfigを使う場合、リクエストの経路は現在の構成にあるルールで決まります。まずConfigで選択中のファイルを確認し、次に[Rule]を確認してください。通常、ルールは上から順に照合されます。先に一致したリクエストは、後ろにあるより具体的なルールまで進みません。そのため、ルールの内容が正しくても配置場所が誤っていると、アクセスに失敗することがあります。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上の例は構文を示すもので、既存の構成にそのまま置き換えて使える汎用設定ではありません。example.comは例示用のドメイン名です。PROXYは、現在の構成に定義されていて利用可能なポリシーまたはポリシーグループに対応させる必要があります。名称だけをコピーして定義を省略しないでください。FINAL,PROXYの実際の動作は、そのポリシーで最終的に選択されるサーバーにも左右されます。

キーワード	照合対象	よくある確認点
DOMAIN-SUFFIX	ドメイン名とそのサブドメイン	前にある広範なルールに一致していないか、関連するリソースのドメイン名が漏れていないか
IP-CIDR	接続先のIPアドレス範囲	ネットワーク範囲とマスクが正しいか、no-resolveが想定どおりか
GEOIP	接続先IPアドレスの地理情報データベース上の地域	ブランドの所在地から推測せず、名前解決で得たIPアドレスをデータベースで確認する
FINAL	それ以前のルールに一致しなかった場合のフォールバック	末尾に配置されているか、参照先のポリシーが存在し利用可能か

no-resolveは、そのIPルールとの照合のためにドメイン名の追加の名前解決を行わないようにする設定であり、アプリ全体のDNSを無効にするものではありません。REJECTは該当するリクエストをブロックします。トップページは開くのに画像やログインAPIが失敗する場合は、すべてのルールを削除するのではなく、該当するリソースのドメイン名が拒否ルールに一致していないか確認してください。

まとめ：一致したルールを確認して修正する

失敗したリクエストが誤ったポリシーに一致したことを確認してから、該当するルールを移動または変更してください。リクエストがFINALまで到達していない場合、FINALを変更しても解決しません。想定したProxyポリシーに一致している場合は、そのポリシーで実際に選択されているサーバーを確認してください。

よくある質問：テスト成功後も一部の通信で問題が続く

Connectivity Testに成功したのに、Webページが開かないのはなぜですか？

テスト対象とWebページの接続先は異なる場合があります。また、テストでは認証、TLS、DNS、Webページに必要なすべての接続を確認できないことがあります。まずHome → Global Routingで一時的にProxyを選び、再テストしてください。その後、失敗したリクエストが名前解決、接続、ポリシー選択のどの段階で止まっているかを確認します。

Proxyでは通信できるのに、Configにすると失敗します。最初に何を確認すればよいですか？

まずConfigで現在選択中のファイルを確認し、失敗したリクエストに一致したルールとポリシーグループの選択を調べます。誤ってDIRECTに流れていないか、REJECTに一致していないか、利用できないポリシーを参照していないか確認してください。DNS経路が異なる可能性も考慮し、すべてのリクエストを同じポリシーにすぐ変更しないでください。

Wi-Fiでは使えるのにモバイル通信では失敗します。プロトコルに対応していないのでしょうか？

同じサーバーと同じURLで再テストし、モバイルデータ通信の権限、Settings → On Demand、Sceneの設定を確認してください。ネットワークによってポートやUDPの扱いが異なる場合があります。一度の失敗だけでプロトコル自体が非対応だと判断しないでください。

Webページは使えるのに、通話や動画に問題がある場合はどうすればよいですか？

該当する通信でUDPが使われているか確認し、現在のプロトコル、サーバー側の設定、必要な転送機能が利用可能かを調べてください。Hysteria2の通信にはUDPが必要です。他のプロトコルでUDPが使えるかどうかもサーバー側の設定によるため、プロトコル名だけでは判断できません。

サブスクリプションの更新に成功すれば、サービスの問題は除外できますか？

いいえ。更新が成功したことから分かるのは、サブスクリプションの内容を取得して処理できたということだけです。Homeに戻り、現在のサーバーのアドレス、認証情報、接続状況を確認してください。利用中のサービス事業者に問い合わせる場合は、個人情報を伏せたエラーの発生段階、ネットワークの種類、再現手順を伝えてください。

最後に：設定を戻し、再現できる記録を残す

問題が特定できたら、検証済みの必要な変更だけを残します。一時的にオフにしたOn Demandを元に戻し、Global Routingを普段の設定に戻してから、基本的なWebページと最初に失敗した接続先をそれぞれテストしてください。特定のネットワークやサーバーでしか再現しない場合は、その条件を記録し、アプリ全体の問題だと結論づけないでください。

環境を記録：Wi-Fiまたはモバイル通信、ネットワークへのログインが完了しているか、接続をオフにした状態で基本的なWebページにアクセスできるか。
選択内容を記録：現在のサーバーのカスタム名、Global Routingの設定、Configファイル名。パスワードやサブスクリプションの認証情報は記録しないでください。
発生段階を記録：名前解決の失敗、接続タイムアウト、認証失敗、または想定外のポリシーへの一致。個人情報を伏せた元のエラー内容も残してください。
変更内容を記録：今回変更した項目、同じ接続先が復旧したか、元の設定に戻すと再発するか。

各項目を確認したい場合はConfigの項目ガイドをご覧ください。初回の読み込みや、現在のConfigの入手元が分からない場合は、まず入門ガイドで手順を確認してください。アプリの買い切り購入に回線プランは含まれません。アプリの購入状況と、利用中サービスの有効状況はそれぞれ確認が必要です。