Shadowrocketの接続表示はオンなのにネットにつながらない：サーバー・Global Routing・DNS・ルールの確認方法

この記事の概要

Shadowrocketのスイッチをオンにすると、端末上の接続が開始したことは分かりますが、リモートサーバーやDNS、アクセス先のWebサイトがすべて利用可能とは限りません。自分で設定を読み込んだもののWebページが開けない場合は、まず接続をオフにした状態でネットワークを確認し、次にサーバー、ルーティング、ドメインの名前解決、ルールの適用状況を順に検証します。一度に変更するのは1項目だけにして結果を記録し、最後に通常の振り分け設定へ戻しましょう。

1. 問題の範囲を確認し、現在の設定を保存する

確認を始める前に、現在の設定を複製して保存し、Homeで選択中のサーバー、Global Routingの現在の選択肢、Configで使用中の設定を記録します。以下ではiPhone / iPadのHome、Config、Settingsから操作する手順を説明します。他のプラットフォームでは該当する設定項目を確認してください。画面上の位置だけで接続成功と判断しないようにしましょう。手順は、利用者自身がサービスとサブスクリプションを用意していることを前提としています。

現在の状態を記録する

開けないURL、発生時刻、使用中のWi-Fiまたはモバイルネットワーク、ブラウザーに表示されたエラーを記録します。原因を特定できなくなるため、サブスクリプションの更新、DNSの変更、ルールの書き換えを同時に行わないでください。
自動接続を一時停止する

Settings → On Demandを開き、現在の設定を記録してから自動接続を一時的にオフにします。その後Homeに戻って接続をオフにしてください。ネットワークの基本状態を確認している間に、条件に応じて接続が自動でオンになるのを防げます。
通常のネットワーク接続を確認する

接続をオフにして、普段そのまま開けるWebサイトにアクセスします。それでも開けない場合は、まずWi-Fiのログイン画面、ルーター、モバイルデータ通信を確認してください。公衆Wi-Fiでは、先にネットワーク認証を完了します。
条件をそろえて比較する

接続を再びオンにし、最初に開けなかったWebサイトと、アクセスできることが分かっている別のサイトをそれぞれ試します。特定のドメインだけ開けない場合は、そのドメインのルール、名前解決、Webサイトの状態を優先して確認しましょう。クライアントをすぐに再インストールする必要はありません。

モバイルネットワークに切り替えると復旧し、同じ設定でもWi-Fiでは継続して失敗する場合、ネットワーク経路に関係する問題の手がかりになります。ただし、プロトコルの設定が正しいと断定できるわけではありません。以降の確認でも同じサーバーと同じアクセス先を使い、複数の条件を同時に変えないようにしましょう。

2. サーバーを確認する：Connectivity Testの成功はWebサイトの利用を保証しない

Homeで実際に選択されているサーバーを確認してから、Connectivity Testを実行します。リストにサーバーが表示されていても、デフォルトとして選択されているとは限りません。サブスクリプションを更新した後も、選択状態を確認してください。テストがタイムアウトする場合は、振り分けルールを変更する前にサーバーのアドレス、ポート、認証情報を確認します。応答があっても、確認した経路が使えることを示すだけで、すべてのWebサイトや通信方式が正常とは限りません。

アドレスとポート：サーバーの編集画面を開き、自分が入手した接続情報とAddress、Portを照合します。サーバーのポートはサーバー側の設定で決まります。WebサイトがHTTPSだからといって、一律に443へ変更しないでください。
認証情報とプロトコル：Shadowsocksの暗号化方式とパスワード、VMess / VLESSのUUID、Trojanのパスワードは、いずれもサーバー側の設定と一致させる必要があります。Typeだけ変更して、別のプロトコルのパラメーターを残さないでください。
TLSとトランスポート：TLSが必要な接続では、サーバー名と関連するトランスポート設定を確認します。証明書の検証を無効にして、サーバー名の不一致や端末の時刻の誤りを隠さないでください。
サブスクリプションの変更：サービス提供元がアドレスや認証情報を変更した場合は、自分のサブスクリプションを更新してからサーバーを選び直します。読み込みに成功したことは設定を読み取れたという意味であり、リモート側で接続が提供されているとは限りません。

エラー：`connection refused`

原因：接続先から明示的に拒否されています。ポートが待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく発生します。対処：サーバーの情報とAddress、Portを照合し、サービスが稼働中か自分のサービス提供元に確認します。DNSを繰り返し切り替えても、ポートによる拒否は通常解決しません。

エラー：`i/o timeout`

原因：接続、ハンドシェイク、データ読み取りなどの処理が制限時間内に完了しませんでした。対処：エラー前後に記録された接続先と処理段階を確認し、別のネットワークでもう一度テストします。timeoutだけを根拠にDNSの問題と決めつけないでください。

3. Global Routingを確認する：ProxyとConfigを比較する

Home → Global Routingで現在の選択肢を確認します。Directでは通常の通信が直接接続されます。そのため、プロキシ経由が必要なアクセス先がこの設定で失敗しても、サーバーが利用できない証拠にはなりません。Configは現在の設定に基づいて通信を振り分けます。Proxyはプロキシ経路を一時的に検証するのに適しています。Sceneは選択中のSceneの設定を確認して判断してください。名称だけで実際の通信経路を決めつけないようにしましょう。

選択肢	トラブル確認時の用途	次の手順
Proxy	通常の接続先を一時的にプロキシ経由にして、ルールによる影響を抑えます。	開けなかった同じURLを再度試します。失敗する場合は、サーバーと名前解決を続けて確認してください。
Direct	接続先へ直接アクセスできるか確認します。	直接接続の失敗を、プロキシサーバーの障害と判断しないでください。
Config	現在の設定に含まれるルールに従って通信の処理方法を決めます。	この選択肢だけで失敗する場合は、ルールの適用状況と転送先のポリシーを重点的に確認します。
Scene	選択中のSceneの設定を使用します。	現在のSceneの内容を確認し、トラブル確認中は動作が明確な比較用の選択肢に切り替えます。

結論：Proxyでは使えてConfigで失敗する場合は、まずルールを確認

同じサーバーとネットワークを使ったまま、Global RoutingをProxyからConfigに戻して再度試します。選択肢を切り替えるたびに同じ問題が再現する場合は、まず対象ドメインに適用されるポリシーを確認してください。サブスクリプション全体をすぐに読み込み直す必要はありません。DNSも設定経路によって結果が異なることがあるため、名前解決の記録も確認しましょう。

4. DNSを確認する：名前解決の失敗と接続の失敗を切り分ける

DNSはドメイン名をIPアドレスに変換します。ブラウザーにサーバーが見つからないと表示された場合は、名前解決の問題が考えられますが、ログも確認してください。アドレスを取得できたか、IPv4とIPv6のどちらか、続いて接続が開始されたかを調べます。「WebサイトのIPアドレスを直接入力する」だけでは判断できません。HTTPSの証明書やバーチャルホストは通常ドメイン名に依存するため、IPアドレスでエラーが出てもDNSが正常か異常かは分かりません。

従来型のDNSでは一般的なサービスポートを使用し、通常はUDPで通信しますが、TCPを使う場合もあります。

A / AAAA

それぞれIPv4とIPv6のアドレスレコードに対応し、経路によって結果が異なることがあります。

1項目

名前解決に関する設定は1回につき1項目だけ変更し、同じドメイン名で再テストします。

Configを開き、現在有効な設定を表示して、[General]内のdns-serverを確認します。同じドメインに影響する[Host]のマッピングがないかも調べてください。有効になっていない設定を編集しても、テスト結果は変わりません。
カスタムDNSを使用している場合は、現在のネットワークからそのDNSサービスにアクセスできるか確認します。到達できない別のアドレスにDNSを変更しても改善しません。プロキシサーバーとDNSを同時に変更しないでください。
暗号化DNSを設定している場合は、ホスト名、証明書、アクセス経路を確認します。DNSサービス自体に接続できないと、特定のドメインだけでなく複数のWebサイトで一斉に問題が起きることがあります。
変更を保存して接続し直し、エラーが出たページを閉じてから再度開きます。ブラウザー、システム、クライアントにはキャッシュが残ることがあるため、古いタブに表示されたエラーだけで判断しないでください。

ログで接続先のIPアドレスを取得できており、その後タイムアウトする場合は、DNSを手当たり次第に変更せず、そのアドレスへのネットワーク経路、IPv6の到達性、最終的なポリシーを確認します。IPv6経路に問題が疑われる場合は、AAAAレコードの結果と接続先アドレスを記録して一時的に比較します。確認後は元の設定に戻し、IPv6を全体で無効にすることを万能な解決策にしないでください。

5. ルールの順序を確認する：最初に適用されるルールを特定する

ファイル名だけでなく、Configで実際に有効な設定を確認します。通常の振り分けルールは上から順に評価され、先に一致したルールでポリシーが決まります。そのため、後ろにある適切なルールが実行されない場合があります。広範囲に一致するDOMAIN-SUFFIX、対象アドレスを含むIP-CIDR、最後の受け皿となるFINALを特に確認してください。

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

この例はルールの構造を確認するためのもので、現在の設定全体を置き換える必要はありません。example.comは例示用のドメイン名、PROXYとDIRECTはポリシー名です。実際の設定でカスタムポリシーグループを使用している場合は、グループ内に有効なサーバーがあることと、現在選択中の項目が無効になっていないことを確認してください。

DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,PROXYは、指定したドメインとそのサブドメインに一致します。個別に処理したい接続先は、先に一致する可能性がある広範なルールより前に配置してください。
IP-CIDR：IPアドレスの範囲に基づいて一致します。例のno-resolveは、このIPルールとの照合のためにドメイン名を積極的に解決しないことを示します。接続全体でDNSが不要という意味ではありません。
GEOIP：接続先IPの地理情報に基づいて一致します。Webサイトの表示言語やドメインの末尾から場所を判定するものではありません。名前解決で得られるアドレスが変わると、適用結果も変わることがあります。
FINAL：先行するルールに一致しなかったリクエストを処理し、通常は末尾に配置します。最後のポリシーがDIRECTの場合、プロキシが必要な未分類の接続先は直接接続に失敗することがあります。

再テストでは、同じドメインに適用されたルールと最終ポリシーを確認します。Webページは画像、API、ログイン用のドメインにもアクセスすることがあります。トップページは開けてもログインできない場合は、トップページのドメインだけでなく、失敗した個別リクエストも確認してください。検証が終わったらConfigを元に戻し、診断用の一時ルールを削除します。

6. よくある質問：サブスクリプション更新、自動接続、一部機能の失敗

サブスクリプションを更新しても接続できないのはなぜですか？

更新に成功したことは、サブスクリプションの内容を取得できたことを示すだけです。Homeでデフォルトのサーバーを確認し、Connectivity Testを実行してください。その後、サービス提供元の情報とアカウントの状態、接続パラメーターを照合します。更新前の項目が使えたからといって、更新後の項目も利用できるとは限りません。

スイッチをオフにしたのに、また自動接続するのはなぜですか？

Settings → On Demandを開き、現在のネットワークに合う接続条件が有効になっていないか確認します。トラブルの確認中は、元の設定を記録して一時的にオフにしてください。通常のネットワーク状態を比較した後に設定を戻し、自動再接続が確認を妨げないようにします。

Webページは開けるのに、動画や通話が失敗する場合はどうすればよいですか？

まず、問題が発生する機能で別のドメインやUDPが使われていないか確認し、該当するリクエストのポリシーとサーバー側の対応状況を調べます。WebページのTCP接続が成功しても、UDPが使えるとは限りません。Hysteria2とWireGuardはUDP経路に依存するため、ネットワークの制限も確認してください。

設定をすべて変更しても直らない場合、再インストールが必要ですか？

まず保存した設定のコピーに戻し、サーバー、Global Routing、DNS、ルールの順に再確認します。失敗した時刻、ネットワークの種類、接続先ドメイン、機密情報を隠したログを記録して、リモート側の状態を自分のサービス提供元に確認してもらいましょう。再インストールしても、リモート側のポートが待ち受けていない問題や、認証情報の失効は解決できません。

7. 通常の設定に戻し、再現できる結果を記録する

問題が解消したら、どの変更が有効だったかを特定してから、一時的な変更を元に戻します。Proxyへの切り替えで使えるようになっただけなら、「修復済み」とは判断できません。Configに戻して、必要な振り分けルールが機能することも確認してください。ネットワークの変更で復旧した場合は、元のネットワークでどの範囲に問題があったかを記録し、次回そのネットワークの制限を設定破損と誤認しないようにします。

普段使用するGlobal Routingの選択肢に戻し、現在有効なConfigとデフォルトサーバーを確認します。
記録した設定をもとにSettings → On Demandを元に戻し、ネットワークを切り替えた後に想定どおり接続されるか確認します。
直接接続する接続先、プロキシが必要な接続先、最初に失敗した具体的な機能をそれぞれテストします。
修正後の設定を複製して保存し、変更した項目と比較結果を記録します。認証情報を含むログを公開用に保存したり共有したりしないでください。

クライアントを入手し直す場合は、ダウンロードページで該当するプラットフォームを選択してください。iPhone / iPad版の開発者はShadow Launch Technology Limitedです。システム要件はApp Storeのページに記載された内容をご確認ください。クライアントの入手費用と、利用者が別途契約する接続サービスの費用は異なります。クライアントの買い切り購入に接続サービスの料金は含まれません。