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

この記事の要点

Shadowrocketの接続をオンにしても、ブラウザや一部のアプリにアクセスできない場合の確認手順です。利用中のサービスと設定があることを前提に、まず直接接続の状態を確認し、サーバー、Global Routing、DNS、適用ルールの順に調べます。一度に変更するのは一項目だけにし、同じWebページで結果を記録したうえで、最後に元の設定へ戻してください。

1. VPNの起動とWebページへのアクセス可否を切り分ける

Homeの接続スイッチをオンにすると、端末上でVPN接続が開始されます。ただし、これだけではリモートサーバーの認証成功やWebサイトへのアクセスを確認できません。システムにVPNの表示があっても、DNS、サーバーの出口、ルールの設定が正常とは限りません。スイッチの状態だけで原因を判断しないでください。

まず、現在のネットワークで普段から直接開けるWebページを一つ、問題が起きているWebページを一つ選びます。以降はこの二つを使ってテストします。ページを再読み込みし、必要に応じて既存のタブを閉じてから開き直してください。キャッシュ済みのページを今回の接続成功と誤認しないためです。

4項目

確認する順番：サーバー → モード → DNS → ルール

1項目

1回の確認で変更するのは1項目だけ。テスト結果を記録

2件

テスト対象を固定：直接接続の対照ページと問題のページ

現在の設定を記録

Homeで選択中のサーバーとGlobal Routingのモードを、Configで選択中の設定ファイルを記録します。設定を変更する前にコピーを保存し、DNSの現在の設定も控えてください。
自動接続を確認

Settings → On Demandを開き、現在の設定を記録します。テスト中に接続が再開される設定の場合は、一時的にオフにし、確認後に元へ戻してください。
直接接続の状態を確認

Homeに戻って接続スイッチをオフにし、接続が停止したことを確認してから、直接接続の対照ページを開きます。それでも開けない場合は、現在のWi-Fiでログインが必要か、モバイルデータ通信が使えるかを確認してください。
問題を再現

接続を再びオンにし、元のサーバー、モード、設定ファイルのまま、二つのテスト対象にアクセスします。両方とも失敗するのか、特定のドメインやアプリだけが失敗するのかを記録してください。
テスト条件を固定

サーバーとモードの確認は、まず同じネットワーク上で行います。Wi-Fiとモバイルデータ通信を切り替えて試す場合は、別のテストとして実施し、設定の更新やサーバーの変更を同時に行わないでください。

2. サーバーを確認：接続可否を調べてから認証情報を照合

Home → SERVERで現在選択されている項目を確認し、Connectivity Testを実行します。遅延の結果から分かるのは、そのテスト方法で応答があったことだけです。テスト方法によって確認できる通信経路は異なります。一度の測定値だけで、すべてのドメイン、通信方式、実際のリクエストが正常だとは判断できません。

すべてのサーバーがタイムアウトする場合は、直接接続の結果と現在のネットワークを確認します。一つのサーバーだけ失敗する場合は、そのサーバーのアドレス、ポート、プロトコルの設定を照合してください。アドレスにはドメイン名を指定することもあり、その名前解決も必要です。サーバーへの接続がタイムアウトしても、リモート側のサービスが停止したとは限りません。

アドレスとポート：選択中のサーバーの編集画面を開き、利用中のサービス提供元から受け取った情報と一項目ずつ照合します。ポート 443 はHTTPSでよく使われますが、実際の設定に従ってください。TLSが設定されているからといって、ポートを 443 に変更してはいけません。
認証情報：Shadowsocksのパスワードと暗号化方式、VMessおよびVLESSのUUID、Trojanのパスワードをそれぞれ確認します。アドレスとポートだけが入力されていても、設定のインポートが完了しているとは限りません。
通信設定：TLSやWebSocketを使う設定では、TLSのサービス名、Host、Pathを確認します。サーバーアドレスと異なる場合もあるため、独自に統一せず、元の設定に従って入力してください。
サブスクリプションの内容：サービス提供元から設定変更の案内があった場合に限り、利用中のサブスクリプションを更新します。更新後は選択中の項目を再確認してください。更新が成功しても、設定内のすべてのサーバーが利用できるとは限りません。

ログの内容は、どの段階で失敗したかを特定する手がかりになります。以下に一般的なネットワークエラーの例を示します。プロトコルやシステム環境によっては、エラーの前後にアドレスやエラー領域が付加されます。実際のログに該当する文言がある場合にのみ、対応する原因を検討してください。ブラウザに何も表示されないだけで、特定のエラーだと決めつけないでください。

エラー：connection refused

原因と対処：接続先または途中の機器に明示的に拒否されています。ポートで待ち受けていない場合や、アドレス・ポートが一致しない場合によく発生します。まずサーバーのアドレスとポートを確認し、利用中のサービス提供元に接続先の状態を問い合わせてください。このエラーだけでは、パスワードが誤っているとは判断できません。

エラー：connection timed out

原因と対処：制限時間内に接続が完了していません。通信経路、ポートのフィルタリング、サーバーから応答がないことなどが考えられます。同じ設定を別のネットワークで試し、利用可能な別のサーバーがあれば、他の条件を変えずに比較してください。

エラー：certificate verify failed

原因と対処：TLS証明書の検証に失敗しています。端末の時刻、サービス名の不一致、証明書チェーンの問題などが考えられます。システムの日付と設定内のTLSサービス名を確認し、証明書についてはサービス提供元に問い合わせてください。検証を無効にする方法を通常の対処法として使わないでください。

3. Global Routing：モードを切り替えて原因を絞り込む

Home → Global Routingで現在のモードを確認します。原因を調べる際は、ProxyとDirectを切り替えることで、プロキシ経由と直接接続の違いを比較できます。普段Configを使っている場合は、設定内の具体的なルールも確認してください。Sceneは選択中のシーン設定と合わせて判断し、名前だけから通信先を推測しないでください。

モード	確認目的	結果の見方
Proxy	通常の通信先を現在のプロキシ設定で接続し、一時的な比較に使います。	Proxyでは接続できてConfigでは失敗する場合、まずルールとポリシーの選択を確認します。DNSの通信経路に違いがないかも確認してください。
Direct	接続先に直接アクセスし、現在のネットワークから到達できるか確認します。	Directでは接続できてProxyでは失敗する場合、まずサーバーとプロキシ経路を確認します。すべての接続先をDirectにするべきだという意味ではありません。
Config	現在選択中の設定ファイルのルールに基づいて通信を振り分けます。	Configで選択中のファイル、ルールの順序、ルールが指定するポリシーの利用可否を確認します。
Scene	現在のシーン設定に基づいて通信を振り分けます。	選択中のシーンとその設定内容を確認します。シーンの影響を切り分ける場合は、現在の値を記録してから、動作が明確な比較用モードを一時的に使ってください。

判断の目安：Proxyで接続できたらConfigを確認

同じサーバー、ネットワーク、接続先を使い、Proxyでは接続できるのにConfigでは失敗する場合は、まずConfigで実際に適用されたルールとポリシーを確認してください。サーバーをすべて作り直す必要はありません。比較が終わったら元のモードに戻してください。

モードを切り替えた後は、リクエストを新しく実行してください。ブラウザやアプリが以前の接続を保持している場合があり、画面を更新するだけでは新しい接続が確立されないことがあります。特定のアプリだけで問題が起きる場合は、アプリを完全に終了して開き直し、同じサービスをブラウザでも確認して、アプリのキャッシュと通信経路の問題を切り分けてください。

4. DNSを確認：遅延が測定できても名前解決できるとは限らない

DNSはドメイン名をアドレスに変換します。サーバーに接続できることやConnectivity Testの結果が得られることと、接続先のドメイン名を解決できることは別の問題です。アドレスを取得できても、到達できないIPv6アドレスや誤ったアドレス、現在のネットワークに適さない結果が返されると、Webページがタイムアウトすることがあります。

Configを開き、現在選択中の設定ファイルのDNS関連項目を確認します。まず、リゾルバーのアドレス、暗号化DNSを使うかどうか、名前解決のリクエストがどのネットワーク経路を使うかを記録してください。選択されていない設定ファイルだけを確認したり、DNSとサーバーを同時に変更したりしないでください。どの変更が有効だったか判断できなくなります。

アドレス形式を確認：通常のDNSではポート 53 を使います。DoHは通常、HTTPSのポート 443 で接続します。異なるポートを設定する場合は、実際のサービス要件に従ってください。ポートが正しくても、プロトコルやアドレス形式が正しいとは限りません。
リゾルバーへの接続可否を確認：リゾルバーに特定のプロキシ経路からしか接続できず、そのプロキシサーバーのドメイン名解決にも同じリゾルバーが必要な場合、起動時の依存関係が問題になることがあります。元の設定説明に従って名前解決の経路を確認し、接続スイッチを何度も切り替えないでください。
失敗する範囲を確認：関連のない複数のドメインで名前解決エラーが起きる場合は、まずリゾルバーを確認します。一つのドメインだけ失敗する場合は、ドメイン名全体と応答内容を記録し、そのドメインに適用されるルールと接続先のサービスを確認してください。
変更が反映されたか確認：設定を保存したら再接続し、テストするアプリも開き直してください。DNSキャッシュが確認結果に影響することがあります。既存の接続でアクセスできたからといって、新しい設定が検証できたとは限りません。

5. ルールを確認：REJECTの有無ではなく、実際に適用されたルールを調べる

Homeに戻り、Global RoutingをConfigに戻してから、Configで現在選択中のファイルを確認します。通常、ルールは上から順に評価され、最初に一致したルールのポリシーが接続に適用されます。ファイル内にREJECTがあっても、すべてのリクエストが拒否されるわけではありません。対象の通信が実際に該当ルールに一致した場合にのみ、原因として考えられます。

以下は構文を説明するための例であり、完全な設定ではありません。現在のルールをそのまま置き換えることも推奨しません。例示ドメインと文書用アドレスは項目の説明だけを目的としています。最初の列はルールタイプ、次の列は通常、照合条件、最後の列はポリシーです。FINALには照合条件の列がありません。

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

DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,REJECTは、example.comとそのサブドメインに一致します。実際のサービスのドメインが同種のルールに一致する場合、サーバーだけを変更しても拒否される状況は変わらないことがあります。
IP-CIDR：接続先IPのネットワーク範囲で照合します。例にある 192.0.2.0/24 は文書用の例示ネットワークです。no-resolveは、このルールの照合のためにドメイン名を積極的に解決しないという意味であり、「設定全体でDNSを無効にする」という意味ではありません。
GEOIP：接続先IPの地理情報に基づいて照合します。Webページの言語やドメインの末尾で判定するものではありません。名前解決の結果が変わると、その後のIP関連ルールの照合にも影響する場合があります。
FINAL：それ以前のルールに一致しなかった接続を処理します。例ではPROXYを指定しています。実際の設定でカスタムポリシーグループを使っている場合は、ルール末尾の名前だけでなく、そのグループで現在選択されている項目も確認してください。

アプリのリクエスト記録やログで、問題のドメイン、一致したルール、最終的なポリシーを確認します。Webページはメインのドメインに加え、ログイン用や静的リソース用のドメインにもアクセスすることがよくあります。ページは開けてもログインボタンが反応しない場合は、アドレスバーのメインドメインだけでなく、失敗したリクエストを調べてください。

6. よくある質問：一部だけ接続できない、自動接続、設定の復元

遅延が表示されるのに、Webページが開けないのはなぜですか？

遅延テストとWebページへのアクセスでは、接続先や通信経路全体が異なる場合があります。まずHomeで選択中のサーバーを確認し、Proxyで問題のWebページにアクセスしてください。それでも失敗する場合は、サーバーの認証情報とDNSを確認します。遅延の数値だけでWebページが利用できるとは判断できません。

特定のWebサイトだけ開けない場合も、サーバーを変更する必要がありますか？

まず、そのWebサイトで失敗している具体的なドメインを記録し、ProxyとConfigで結果を比較します。Configだけ失敗する場合は、そのドメインに適用されたルールを優先して確認してください。両方のモードで失敗する場合は、名前解決の結果、接続先サービスの状態、プロキシの出口経路を確認します。

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

Settings → On Demandを開き、自動接続の条件が設定されているか確認します。確認中は現在の設定を記録してから一時的にオフにし、Homeに戻って接続が停止したことを確かめてください。確認が終わったら元の設定に戻し、自動再接続をスイッチの不具合と誤認しないようにします。

モバイルデータ通信に切り替えると直る場合、サーバーに問題はないといえますか？

同じ設定が別のネットワークでは少なくとも利用できることを示しており、問題は元のネットワーク経路にある可能性が高まります。元のWi-Fiに戻り、ネットワーク認証、リゾルバーへの接続可否、ポート制限を確認してください。同じサーバーとモードで再テストします。この結果だけで、すべてのネットワークから接続できるとはいえません。

7. 復旧を確認：後から確認できる結果を残す

接続スイッチが再び点灯することではなく、以前アクセスできなかった接続先に、想定したモードでリクエストできることを成功の基準にします。普段使うGlobal Routing、設定ファイル、On Demandの設定に戻した後、直接接続の対照ページと問題のページをもう一度テストしてください。元の設定に戻すと問題が再発する場合は、一時的な比較によって問題を回避しただけで、解決には至っていません。

最終的に利用できたネットワークの種類、選択中のサーバー、設定ファイル、Global Routingのモードを記録します。
問題が起きていたアプリを開き直し、トップページの見出しが表示されるかだけでなく、ページの読み込み、ログイン、リソースの取得も確認してください。
一時的に変更したDNS、ルールの例外、自動接続の設定が普段の使い方に合っているか確認し、変更前の設定のコピーも保管してください。
利用中のサービス提供元に問い合わせる場合は、失敗した時刻、プロトコルの種類、エラー文、モードを切り替えた結果を伝えます。パスワード、UUID、サブスクリプショントークンなどの機密情報は伏せてください。

ShadowrocketはAppleプラットフォーム向けの有料クライアントです。入手先はApp Storeのみで、開発者はShadow Launch Technology Limitedです。クライアントの買い切りと通信サービスの契約は別です。この記事では、利用中の設定を前提に確認方法を説明します。ノード、サブスクリプション、サービス提供元の提供・販売・推奨は行っていません。システム要件はApp Storeの掲載内容をご確認ください。