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

この記事の要点

Shadowrocketの接続スイッチをオンにしても、端末側で接続が有効になったことを示すだけで、リモートサーバーやDNS、アクセス先のWebサイトがすべて利用できるとは限りません。ご自身が契約しているサービスの設定をお持ちの方向けに、まず接続を切った状態のネットワークを確認し、次にHomeでサーバー、Global Routing、DNS、Configのルールをチェックします。一度に変更するのは1項目だけにし、同じWebページで再テストして、原因を説明できる結果を記録しましょう。

1. まず端末側のネットワーク障害と接続の問題を切り分ける

現在のConfigを保存し、Homeで選択中のサーバーとGlobal Routingのモードを記録します。最初からすべての設定を削除しないでください。Configを作り直すと、既存のルールやポリシーの選択、DNS設定が失われ、変更前後の比較もできなくなります。

普段アクセスできる、異なるサイトが提供するHTTPSページを2つ用意します。IPアドレスではなく、完全なドメイン名でアクセスしてください。証明書の検証や仮想ホストの選択にはドメイン名が使われるため、IPアドレスへの直接アクセスでエラーになっても、それだけでDNSの問題とは判断できません。

現在の設定を記録

Home → Global Routingの現在の選択肢、選択中のサーバー名、使用中のConfigを記録します。記録やスクリーンショットにサーバーアドレス、パスワード、UUIDが含まれる場合は、自分で管理できる場所にのみ保存してください。
オンデマンド接続を一時停止

Settings → On Demandを開き、現在の有効・無効の状態を記録します。切り分け中は一時的に無効にして、手動で切断した後に自動で再接続されないようにします。テスト後は元の設定に戻してください。
切断してテスト

Homeで接続スイッチをオフにし、Safariで用意した2つのページを開きます。どちらも開けない場合は、Wi-Fiのログイン認証、ルーター、モバイルデータ通信を先に確認し、ルールの変更は後回しにしてください。
ネットワークを切り替えて再テスト

Wi-Fiとモバイルデータ通信を切り替え、同じページにアクセスします。モバイルデータの使用量にも注意してください。一方のネットワークだけで失敗する場合は、ネットワークの種類を記録し、ポートや通信方式の制限がないか確認します。

ホテルや学校などのネットワークでは、Web認証が必要な場合があります。接続を切ってネットワーク認証を完了してから、Shadowrocketを再接続してテストしてください。別のネットワーク拡張機能が接続を管理している場合は、設定の競合を避けるため、切り分け中はその接続を一時停止します。

2. サーバーの状態を確認し、遅延値だけでWebの利用可否を判断しない

Homeに戻り、似た名前の古い項目ではなく、テスト対象として選んだサーバーが選択されていることを確認します。ご自身のサービス提供元から案内されたパラメーターに沿って、Type、アドレス、ポート、認証情報を照合してください。プロトコルとパラメーターは対応している必要があります。アドレスとポートだけを残してVMessをVLESSに変更したり、Trojanの認証方式をShadowsocksに流用したりしないでください。

HomeでConnectivity Testを実行し、結果を確認します。遅延値が表示されても、そのテスト方式による疎通確認が成功したことを示すだけです。すべてのHTTPSリクエストやUDP通信、アクセス先のサイトが正常に利用できるとは限りません。実際のアクセスが復旧したかどうかは、同じWebページで続けて確認してください。

443 / TCP

HTTPSで一般的なポート。サーバーの待ち受けポートは、現在の設定に従ってください

53 / UDP、TCP

従来型DNSで一般的なポート。ネットワーク切り替え時は到達可能か確認してください

1回につき1項目

変更は毎回1つだけにし、再接続してからもう一度テストします

登録済みのサーバーがすべてタイムアウトする場合：まず接続するネットワークを切り替え、サービスのアカウント状態とサーバーのメンテナンス状況を確認します。関係のない設定を次々に変更しないでください。
1つの項目だけ失敗する場合：利用できる別の設定と比較し、その項目のポート、認証、TLS、通信パラメーターを確認します。
サブスクリプションの更新は成功するのに接続できない場合：サブスクリプションの取得とサーバーへの接続は、別々の通信です。更新に成功しても、リスト内のすべてのサーバーが利用できるとは限りません。
Hysteria2を使用している場合：現在のネットワークでUDPが制限されていないか確認します。特定のWi-Fiだけで失敗する場合は、パラメーターを変更せずに別のネットワークで試し、すぐにDNSの問題と決めつけないでください。

判断のポイント：まず通信できる経路を確認

同じサーバーがモバイルデータ通信では使えてWi-Fiでは使えない場合は、まずWi-Fi側のアクセス制限を確認します。両方のネットワークで失敗する場合は、サーバーのパラメーターと稼働状況を確認してください。この段階でDOMAIN-SUFFIXやFINALを変更しても、通常はサーバーとのハンドシェイク失敗を解決できません。

3. Global Routingでサーバーの問題とルーティングの問題を切り分ける

Home → Global Routingを開き、現在の選択肢を確認してから切り替えます。Proxyは複雑なルールによる影響を一時的に切り分けるときに使い、Directは直接接続を確認するときに使います。Configは現在の設定に基づいて通信を振り分けます。Sceneを使用している場合は、現在のシーンで実際に適用される設定も確認してください。選択肢の名前だけで通信経路を判断することはできません。

モード	確認できること	再テスト後の判断
Proxy	プロキシ経由でテストし、まずConfigのルールによる影響を減らします。	それでも失敗する場合は、選択中のサーバー、DNS、アクセス先のサイトを優先して確認します。
Direct	リモートプロキシを経由せず、現在のネットワークから直接アクセスできるか確認します。	Directで成功しても、サーバーが利用できることや、すべてのアクセス先に直接接続できることの証明にはなりません。
Config	現在のConfigに設定されたルールとポリシーに従って通信を処理します。	Proxyでは成功しConfigでは失敗する場合は、ルールの適用結果とポリシーの選択を重点的に確認します。
Scene	シーン設定を使用している場合は、現在のシーンに適用されている設定を確認します。	シーンの条件と実際のリクエスト記録を合わせて判断し、固定の接続先とみなさないでください。

「Proxyでテスト → Configでテスト」の順に行い、切り替えるたびにリクエストを新しく送信します。必要に応じて接続をいったん切り、再接続して新しい設定を反映させてください。ブラウザーの既存の持続接続は古い経路を使い続けることがあるため、すでに読み込まれたページだけを見て判断しないでください。

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

DNSはドメイン名をIPアドレスに変換します。リモートサーバーのアドレスにドメイン名を指定している場合、接続の開始前にも名前解決が必要になることがあります。このときDNSに接続できないと「サーバーに接続できない」ように見えることがあります。アクセス先サイトの名前解決に失敗した場合は、接続がオンでもWebページの読み込みが終わらないことがあります。

Settings → DNSで現在の設定を確認し、使用中のConfigにDNS関連の設定が含まれていないかも確認します。Settingsだけを変更すれば、現在の接続に関するDNSの動作がすべて変わるとは限りません。実際に有効な設定とリクエストの記録を照らし合わせて判断してください。元に戻せなくならないよう、変更前の値を保存しておきます。

ドメインを解決できない場合：名前解決エラーが表示されていないか確認し、DNSアドレスの形式と現在のネットワークから到達できるかを調べます。出所が不明なDNSアドレスを複数同時に設定しないでください。
暗号化DNSを使用している場合：DNSサービスのドメイン名を最初に解決できることを確認します。また、まだ確立されていないプロキシ経路にリクエストがルールで送られ、起動に必要な接続が互いに依存する状態になっていないか確認してください。
IPアドレスが返されている場合：続いてTCP接続やTLSハンドシェイクを確認します。名前解決に成功しても、接続先に必ず到達できるとは限りません。
一部のサイトだけ失敗する場合：返されたアドレスがIPv4かIPv6かを記録します。IPv6経路の異常を示す根拠がある場合に限り、一時的にアドレスファミリーを比較テストし、元に戻す方法も確保してください。

エラー：connection refused

原因と対処：接続先のポートが接続を明示的に拒否しています。ポートの入力ミスや、サービスが待ち受けていない場合によく発生します。現在の設定にあるポートを確認し、ご自身のサービス提供元に稼働状況を問い合わせてください。まずDNSを変更する必要はありません。

エラー：i/o timeout

原因と対処：ネットワーク処理が制限時間内に完了しませんでした。前後の記録と合わせて、名前解決、接続、データ読み込みのどの段階で発生したかを確認します。まず接続ネットワークを切り替えて再テストし、該当する段階を調べてください。

エラー：no such host

原因と対処：ドメイン名から利用可能な名前解決結果を取得できませんでした。アドレスの入力ミス、ドメインの有効性、現在のDNSへの到達性を確認します。サーバーのドメイン名に誤りがある場合は、元の設定を確認してください。

上記はネットワークエラーによく含まれる原文の一部です。実際の表示には前後に情報やアドレスが追加される場合があります。前後の状況を含めて記録しつつ、認証情報やサブスクリプションURL全体を公開しないでください。TLSエラーの対処として証明書検証を無効にしないでください。まず端末の日時、サーバーのドメイン名、TLSパラメーターが一致しているかを確認します。

5. Configのルール順序と最終ポリシーを確認する

同じページがProxyでは開き、Configでは開かない場合は、Configを開いて実際に有効なファイルを確認します。該当ドメインに適用されたルール、そのルールが指定するポリシー、そしてポリシーで選択されているサーバーが利用可能かを調べてください。ファイル名が同じでも、内容や現在の有効状態が同じとは限りません。

ルールは通常、上から順に照合され、最初に一致したルールで後続の処理が決まります。範囲の広いルールが上にあると、その下にある詳細なルールが適用されないことがあります。以下は構文と順序の例です。既存のConfigをそのまま置き換えるための完全な設定ではありません。また、ポリシー名が現在の設定内で正しく解決できる必要があります。

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

DOMAIN-SUFFIX,example.com,PROXY：example.comとそのサブドメインに一致します。実際のサイトを調べるときは、リクエストで使われているドメイン名を確認してください。ページ内のリソースが複数のドメインから読み込まれる場合があります。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このIPv4ネットワークに一致します。no-resolveは、このIPルールのためにドメイン名の解決を明示的に行わないという意味で、DNSを全体的に無効にするものではありません。
GEOIP,CN,DIRECT：IPアドレスの地理情報データベースに基づいて一致します。Webページの言語、ドメインの末尾、サーバー名で判定するものではありません。
FINAL,PROXY：それ以前のルールに一致しなかったリクエストを処理します。FINALを上に置くと、それより後のルールが正しく機能しなくなります。

ルールの適用先がポリシーグループの場合は、グループ内で現在選択されている項目も確認します。ルールが正しくても、利用できなくなったサーバーにリクエストを送る場合があります。修正する際は、問題の対象に関係する項目だけを変更し、再接続して同じページにアクセスします。新しいリクエストの記録が想定どおりかも確認してください。

6. 症状ごとに再確認し、再現できる結果を記録する

アクセスが復旧したら、必要なOn Demandを再び有効にし、Global Routingを普段使うモードに戻します。まずWebページを再テストし、その後、最初に失敗したアプリを確認してください。「キャッシュされたページが正常に見える」だけではネットワーク復旧の証拠になりません。新しいリクエストが成功したことを確認します。

接続スイッチがオンなのに、なぜつながらないのですか？

接続状態だけでは、リクエストの経路全体が成功したことは確認できません。まずHomeで選択中のサーバーを確認してConnectivity Testを実行し、次にProxyとConfigを比較します。最後にDNSと適用されたルールを確認してください。

特定のサイトだけ開けません。再インストールが必要ですか？

まず再インストールはしないでください。別のサイトと比較し、失敗するサイトの実際のリクエストドメイン、名前解決の結果、適用されるルールとポリシーを確認します。1つのサイトだけで失敗する場合は、接続先サービスの状態や接続元からのアクセス制限も考えられます。

Wi-Fiではつながらず、モバイルデータ通信では使える場合は？

サーバーとConfigは変更せず、Wi-FiのWeb認証を完了してから再度試します。それでもWi-Fiだけで失敗する場合は、接続のどの段階で発生するかと通信方式を記録し、ネットワーク管理者またはご自身のサービス提供元に確認してください。

サブスクリプションを更新してもアクセスできない場合は？

Homeで更新後の有効な項目が選択されていることを確認し、アカウントの利用枠、有効期限、サーバーの状態を調べます。サブスクリプションの更新で新しくなるのは設定データです。サーバー側の障害や端末内のルールの誤りが自動で修正されるわけではありません。

問い合わせ前に記録しておく4項目

接続ネットワークを記録します：Wi-Fiまたはモバイルデータ通信、およびネットワーク切り替え後の違い。
Global Routingのモード、Config名、ProxyとConfigの比較結果を記録します。
エラーが発生した段階を記録します：DNS、サーバー接続、TLSハンドシェイク、接続先からの応答。
機密情報を削除したエラー原文と再現手順を保存し、パスワード、UUID、サブスクリプションのトークンなどの認証情報は削除します。

タイムアウトの原因をさらに切り分けるには、トラブル診断のタイムアウトに関する説明を確認してください。ルールの用語を確認するには、用語集をご覧ください。ここでの確認は、利用者がすでにサービス提供元と設定をお持ちであることを前提としています。クライアントの購入と通信サービスは別のものです。