Shadowrocketが接続中なのにネットにつながらない原因と対処法｜サーバー・Global Routing・DNS・ルールを確認

この記事の概要

Shadowrocketの接続スイッチをオンにすると、端末上の接続機能は起動しますが、リモートサーバーやDNS、アクセス先のウェブサイトまで正常に動作するとは限りません。利用中のサービスと設定があるのに接続後アクセスできない場合は、まずテスト条件をそろえ、サーバー、Global Routing、DNS、ルールの順に確認しましょう。一度に変更するのは一項目だけにし、同じ接続先で再テストして結果を記録してください。

トラブル対処の前に：端末の接続とリモート側の利用可否を区別

ステータスバーにVPNと表示されても、プロキシサーバーの認証が完了したことや、ウェブのリクエストが想定どおりの出口を経由したことの証明にはなりません。ウェブページへのアクセスには、ドメイン名の名前解決、ルート選択、リモート接続、ウェブサイトからの応答が関わります。いずれかで問題が起きると、ブラウザーが読み込み中のままになることがあります。最初のタイムアウト後に、サブスクリプションの更新、DNSの変更、Configの書き換えを同時に行うと、どの変更が影響したのか判断しにくくなります。

まず、普段問題なく開ける一般的なHTTPSページを比較用に選び、次に現在開けないページを用意します。テスト時は、完全なドメイン名、Wi-Fiかモバイル通信か、選択中のサーバー、Global Routingのモードを記録してください。本記事では接続サービスを提供していません。以下の手順は、利用中のサーバーまたはサブスクリプションがあることを前提としています。

接続をオフにしてもアクセスできない：まず端末の基本的なネットワーク接続を確認してください。ログインが必要なWi-Fiでは、ネットワークへのログインを済ませてからプロキシをテストします。
接続をオフにすると正常で、オンにするとすべて失敗する：サーバーへの到達性、認証情報、現在のルーティングモードを優先して確認してください。
一部のドメインだけ失敗する：該当するドメイン名を記録し、DNSの結果とそのリクエストに適用されたルールを確認してください。
スイッチをオフにしても自動でオンになる：Settings → On Demandを確認してください。切り分け中はOn Demandを一時的にオフにし、完了後に元の設定へ戻すと、自動接続による影響を避けられます。

手順1：サーバーへの接続と接続パラメーターを確認

Homeで実際に選択されているサーバーを確認し、HomeのConnectivity Testで接続をテストします。テスト結果が示すのは、そのテスト対象と方法での到達状況です。遅延が表示されてもすべてのウェブサイトにアクセスできるとは限らず、タイムアウトしてもアカウントが無効とは限りません。テスト結果と実際のウェブリクエストを合わせて判断してください。遅延の結果だけで、認証、TLS、サービスへのアクセスがすべて成功したと考えないようにしましょう。

選択中の項目を確認

Homeを開き、現在選択されているサーバー名を確認します。その項目の編集画面で、アドレス、ポート、プロトコル、認証情報がサービス提供元の情報と一致しているか確認してください。似た名前の項目でもアドレスが異なる場合があるため、表示名だけで判断しないでください。
テストを実行

HomeでConnectivity Testを実行し、選択中のサーバーの結果を記録してから、決めておいたテスト用ウェブページを開きます。「テストには応答があるがウェブページは開けない」場合と「テストもウェブページも失敗する」場合を分けて記録してください。次に確認すべき点が異なります。
ネットワークを切り替える

サーバーと設定はそのままにして、Wi-Fiとモバイル通信を切り替えて再テストします。一方のネットワークだけで失敗する場合は、すべてのプロトコル設定を変更するのではなく、そのネットワークのログイン認証、通信先の制限、UDPへの到達性を優先して確認してください。
元の設定を確認

サービス提供元からアドレスや認証情報の変更通知があった場合は、利用中のサブスクリプションを更新してサーバーを選び直します。更新が成功したかも確認してください。サブスクリプションの更新失敗と、既存サーバーへの接続失敗は別の問題です。設定を何度も削除するのではなく、まず内容を確認しましょう。

プロトコルごとに必要な項目は異なります。Shadowsocksでは暗号化方式とパスワードを一致させる必要があります。VMess、VLESSではIDやトランスポート設定をサーバー側に合わせてください。TrojanもパスワードとTLS設定の一致が必要です。Hysteria2やWireGuardを使う場合は、利用中のネットワークがUDPに対応しているかも確認します。接続に失敗したからといってプロトコル名を適当に変更しないでください。サーバーがその設定に対応している必要があります。

エラー：connection refused

原因：接続先または途中のネットワーク機器によって、接続が明示的に拒否されています。ポートでサービスが待ち受けていない場合や、アクセスが拒否された場合によく発生します。

対処法：サーバーのアドレス、ポート、トランスポートの種類を確認します。元の設定と一致している場合は、その接続先が現在も稼働しているか、利用中のサービス提供元に確認してください。端末のDNSをむやみに変更しないでください。

エラー：i/o timeout

原因：ネットワークの読み書き処理のいずれかがタイムアウトしています。端末側のネットワーク、リモート側への到達性、プロトコルのハンドシェイクなどが関係する可能性があります。このメッセージだけでは原因箇所を特定できません。

対処法：エラー前後の情報を残し、同じサーバーを使ってネットワークを切り替えて再テストします。失敗した具体的な段階と合わせて確認してください。タイムアウトをそのままパスワードの誤りと判断しないでください。

エラー：no such host

原因：名前解決で該当ホストのアドレスを取得できていません。エラーに表示されたホストがサーバーのドメインなのか、アクセス先ウェブサイトのドメインなのかを確認してください。

対処法：ドメイン名の入力ミスとDNSの動作状況を確認します。サーバーのドメインを名前解決できない場合は、まず基本的な名前解決を復旧してください。まだ接続できていないプロキシに、接続前のすべての処理を任せることはできません。

ここではネットワークエラーによく見られるメッセージの一部を紹介しています。実際の表示にはアドレスやポート、より詳しいシステム情報が含まれることがあります。切り分けにはエラー全体の文脈を確認してください。証明書の検証エラーが発生した場合は、端末の日付、サーバーのドメイン名、TLS設定を確認します。証明書検証を無効にする方法を通常の解決策として使わないでください。

手順2：Global Routingでプロキシとルールの問題を切り分ける

Home → Global Routingを開き、まず現在のモードを記録します。Proxy、Direct、Config、Sceneは接続品質の段階ではなく、ルートの選択方法です。Proxyはプロキシ経由の確認、Directは直接接続の確認に使います。Configでは現在の設定ルールに従い、Sceneでは設定済みのシーンに応じて動作します。切り分け中にSceneのまま結果を推測せず、実際に有効なシーンと設定を確認するか、比較しやすいモードへ一時的に切り替えてください。

テストモード	結果の見方	次の手順
Proxy	同じウェブページが引き続き開けない	ルールをすぐ書き換えず、サーバー、DNS、またはウェブサイト自体を引き続き確認します。
Direct	通常のウェブページは開くが、Proxyでは失敗する	プロキシ経由の接続を重点的に確認します。直接接続が成功しても、サーバーが利用できるとは限りません。
Config	Proxyでは正常だが、Configでは失敗する	有効な設定、ルールの順序、リクエストに最終的に適用されたポリシーを確認します。
Scene	ネットワークを切り替えると結果が変わる	Sceneで実際に選択されているルーティング設定を確認し、モードを固定してから再テストします。

結論：Proxyで確認してからConfigを調べる

同じネットワーク、同じサーバー、同じウェブページでProxyなら成功し、Configでは失敗する場合、サーバー設定には触れず、現在のConfigとリクエストの記録を確認してください。ルールの問題をサーバーの故障と誤って扱うのを防げます。

モードを切り替えるたびにウェブページへ再度アクセスし、必要に応じて接続をいったん切ってから再接続すると、古い接続が再利用される影響を抑えられます。テスト後は普段使うモードに戻してください。Proxyは比較用の手段であり、ウェブページが開けない問題すべてに対する最終設定ではありません。

手順3：DNSの失敗と、その後の接続失敗を切り分ける

DNSはドメイン名をアドレスに変換します。名前解決できなければ、通常はその後の接続を開始できません。一方、アドレスを取得できても、それは名前解決が成功したことを示すだけで、接続先への到達や証明書の有効性までは証明しません。SettingsでDNS設定を開き、まず現在の設定を記録します。システムDNS、カスタムDNS、DNS over HTTPSのどれを使っているかを確認し、設定内容を一項目ずつ見直してください。

従来のDNSで一般的に使われるサービスポートです。UDPまたはTCPを使う場合があります。

443

HTTPSのデフォルトポートです。DNS over HTTPSは通常、HTTPS経由で通信します。

1項目

一度に変更する設定は1つだけにし、同じドメイン名で繰り返し確認します。

これらはプロトコルで一般的に使われるデフォルトポートであり、自分のサーバーポートを53や443に変更する指示ではありません。カスタムDNSを使うには、端末から指定したDNSサーバーに到達できる必要があります。DNS over HTTPSの場合も、対応するHTTPSサービスへの接続が必要です。DNSサービス自体にドメイン名が使われている場合、その名前を先に解決する必要があることもあります。暗号化DNSに切り替えれば、接続前の問題がすべて解決するとは限りません。

すべてのドメインで名前解決できない：まずDNSアドレスに誤りがないか確認し、変更前の利用可能な設定に戻して比較します。端末の基本的なネットワーク接続も確認してください。
1つのドメインだけ失敗する：ドメイン名の入力ミスや、特定のサブドメインだけの問題がないか確認し、具体的な検索結果を記録してください。すぐにDNS設定全体を置き換えないでください。
アドレス取得後に接続がタイムアウトする：そのアドレスへのルートとリモート接続を引き続き確認します。これは、単に「名前解決できたかどうか」だけの問題ではありません。
変更しても変化がないように見える：設定を保存し、接続を再確立してからリクエストをやり直します。既存の接続やアプリのキャッシュが古い結果を使い続けている可能性があります。

手順4：Configとルールの実際の適用状況を確認

サーバーとDNSに基本的な問題がないことを確認したら、Configを開き、現在実際に有効な設定を確認します。ファイルを編集しただけでは、その設定で接続しているとは限りません。まず選択中のConfigを確認し、次に[Rule]内の順序を確認します。ルールは通常上から順に照合され、該当した時点で対応するポリシーが適用されます。FINALは個別ルールの後に配置してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

この最小限の例では、example.comとそのサブドメインにPROXYを適用し、それ以外のリクエストにはDIRECTを適用します。これは照合の仕組みを説明する例であり、すべてのユーザーに適した完全な設定ではありません。また、利用可能なサーバーを作成するものでもありません。目的のページが別のドメインにもリクエストを送る場合、それらが最初のルールに一致するとは限りません。メインページは開くのに画像、ログイン、APIが失敗する場合は、アドレスバーのメインドメインだけでなく、失敗した個別のリクエストを確認してください。

DOMAIN-SUFFIX：ドメイン名そのものとそのサブドメインに一致します。任意の文字列を含むかどうかで判定するものではありません。実際のリクエスト先ドメインが指定したサフィックスに該当するか確認してください。
IP-CIDR：アドレスのネットワーク範囲で照合します。例：IP-CIDR,192.168.0.0/16,DIRECT。ドメインのサフィックスではなく、アドレスに基づく条件です。
GEOIP：アドレスが地理データベース上でどこに属するかを基に照合します。例：GEOIP,CN,DIRECT。結果は名前解決で取得したアドレスとデータベースに左右されるため、ウェブサイトの表示言語や運営地を示すものではありません。
FINAL：それ以前のルールに一致しなかったリクエストに適用されます。FINAL,DIRECTを前方に置くと、後続の個別プロキシルールが照合されなくなります。

Dataで利用可能なリクエストまたは接続記録を確認し、時刻、接続先ドメイン、接続先アドレス、最終的なポリシーを照合します。具体的な項目は現在の画面表示に従ってください。画面に適用されたルールが直接表示されない場合は、同じリクエストをProxyとConfigで実行した結果を補助情報として使います。対象ルールより前にあるルールや、ポリシーグループが想定したサーバーを指しているかも確認してください。

DIRECTが適用され、想定ではプロキシを使うはずの場合は、まず対象ルールとその順序を調整します。PROXYが適用されているのに失敗する場合は、同じルールを重ねるのではなく、サーバーと接続先への接続を再確認してください。ルールを1つ変更したら保存し、そのConfigが実際に使用中であることを確認してから、再接続してテストします。記録を残さずに設定全体を一括置換しないでください。

よくある質問：一部のページ、サブスクリプション、自動再接続

テストでは遅延が表示されるのに、ブラウザーが読み込み中のままなのはなぜですか？

Connectivity Testの結果は、ウェブアクセスの一連の処理がすべて成功したことを示すものではありません。同じサーバーを使い、Global RoutingでProxyを選択して元のウェブページを再度開き、次にDNSと接続エラーを確認します。1つのサイトだけが失敗する場合は、そのサイトと関連ドメインも調べてください。遅延が表示されただけで、すべて正常と判断しないようにしましょう。

Wi-Fiでは使えないのに、モバイル通信に切り替えると使えるのはなぜですか？

ほかの設定は変えずに、同じ結果を再現できるか確認します。Wi-Fiへのログインが必要か、接続先ポートやUDPが制限されていないかを調べてください。また、ネットワークの切り替えによってSceneやSettings → On Demandの接続動作が変わっていないかも確認します。1つのネットワークでだけ起きる障害を、すぐにサブスクリプションの無効化と結びつけないでください。

サブスクリプションの更新に失敗したら、すべての項目を先に削除すべきですか？

先に削除する必要はありません。現在の設定を残したまま、利用中のサービス提供元から案内されたサブスクリプションURLが有効か確認し、Homeで該当するサブスクリプションを更新します。サブスクリプションURLへの到達性と、既存サーバーの利用可否は分けてテストしてください。問い合わせ時は、アクセス認証情報が漏れないよう、URL内のtokenを隠します。

スイッチをオフにしても自動で再接続されます。比較テストするにはどうすればよいですか？

Settings → On Demandを開き、元の設定を記録してから自動接続を一時的にオフにします。その状態で、接続を切ったときの基本的なネットワーク接続をテストしてください。トラブル対処後は元の設定に戻します。それでもスイッチの動作が想定と異なる場合は、端末内のほかの自動接続管理設定を確認してください。アプリを何度も再インストールする必要はありません。

原因を特定できない場合は、発生時刻、ネットワークの種類、選択中のサーバー名（個人情報を伏せたもの）、Global Routingのモード、ProxyとConfigの比較結果、失敗するドメイン、DNSでアドレスを取得できたか、エラーの全体を含む最小限の記録をまとめます。サーバーの状態を利用中のサービス提供元に問い合わせる際は、「スイッチがオン」という情報だけよりも、これらの記録のほうが問題箇所の特定に役立ちます。

トラブル対処が終わったら、On Demand、普段使うルーティングモード、維持する設定を元に戻し、一時的なテストルールを削除します。復旧の確認は、実際のウェブアクセス、想定したポリシー、複数回の新しいリクエストの結果を合わせて行ってください。一度の遅延テストやステータスバーの表示だけで判断しないようにしましょう。