Shadowrocketが接続中なのにインターネットにつながらない：サーバー・Global Routing・DNS・ルールの確認

この記事の要点

Shadowrocketの接続スイッチが示すのは、端末上のトンネル接続状態です。リモートサーバー、ドメイン名の名前解決、接続先サイトへの到達まで保証するものではありません。自分でサーバーとサブスクリプションを用意していることを前提に、ローカルネットワーク、サーバー設定、Global Routing、DNS、ルールの順に原因を切り分けます。一度に変更するのは1項目だけにし、同じ接続先へ再度アクセスしてください。たまたま復旧した状態を、設定変更の効果と誤認しないためです。

1. トンネル接続とWebページへの接続を区別する

iPhoneやiPadにVPNアイコンが表示されている場合、システム上でローカルネットワークトンネルが確立されています。Webページの表示には、名前解決、ポリシー選択、リモート接続、接続先からの応答など、複数の処理が必要です。どこか1つでも失敗すると、スイッチがオンでもページの読み込みが続くことがあります。スイッチを何度も切り替えるだけでは、どの段階で問題が起きているか判断できません。

アプリからのリクエストシステムトンネル名前解決と振り分け外向き接続接続先からの応答

まず、失敗するのがすべてのアプリか、すべてのWebページか、特定のドメインだけかを記録します。あわせて、失敗時にWi-Fiとモバイル通信のどちらを使っていたかも記録してください。ブラウザーでページを1つ開けても、そのリクエストが成功したことしか分かりません。他のプロトコルや接続先も利用できるとは限りません。以下の比較では、自分で決めた同じテストページを使い、多数の異なるサイトへ続けてアクセスする必要はありません。

現在の状態を記録する

Homeで選択中のサーバー、Global Routingの現在値、障害が起きた時刻を記録します。Configでは現在有効な構成の名前を確認し、変更前にコピーを保存してください。元の構成を直接上書きしないでください。
ローカルネットワークを確認する

Settings → On Demandを開き、現在の状態を記録してから自動接続を一時的にオフにします。次にHomeの接続スイッチをオフにし、通常プロキシなしでアクセスできるページを開いてください。それでも失敗する場合は、Wi-Fiのログイン、電波状況、ローカルネットワークの問題を先に解決します。
接続するネットワークを切り替える

Wi-Fiとモバイル通信で同じページをそれぞれテストしてから、Shadowrocketの接続を再開します。一方のネットワークだけで失敗する場合は、サーバーと構成を変えず、そのネットワークの名前解決、アクセス制限、接続状態を優先して確認してください。
リクエストをやり直す

設定を変更するたびに再接続し、新しいページを開いてリクエストを発生させます。既存の長時間接続やページキャッシュには以前の結果が残ることがあるため、開いたままのタブの表示だけで新しい設定の有効性を判断しないでください。

2. サーバー設定と実際の外向き接続を確認する

Homeで選択中のサーバーを確認し、その項目の編集画面を開いて、自分のサービスの元の設定と照合します。アドレス、ポート、Type、認証情報を確認してください。サーバー一覧に項目があっても、現在有効とは限りません。レイテンシテストに結果が表示されても、Webページへの接続に必要な通信全体が成功するとは限りません。

確認項目	確認する内容	判断時の注意点
アドレスとポート	自分のサービス設定と1項目ずつ照合し、アドレスの期限切れやポートの入力ミスがないか確認します。	リモート側のポートが443の場合もありますが、Webページが開かないからといって、サーバーのポートを一律に443へ変更しないでください。
Typeと認証情報	実際に利用しているサービスに応じて、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardの必要項目を確認します。	プロトコルごとのパスワード、識別子、鍵の項目は、そのまま別のプロトコルへ流用できません。
TLSとトランスポート	サービスでTLSを使用している場合は、サービス名と証明書の要件を確認します。追加のトランスポートを使う場合は、パスなどの設定も確認してください。	サービス名、証明書、端末時刻の問題を修正せず、証明書検証を無効にして済ませないでください。
サブスクリプションの状態	Homeで自分のSubscribe項目を更新し、更新後に有効なサーバーが選択されていることを確認します。	更新に成功したことは項目を取得できたことを示すだけで、すべてのリモートサーバーへの接続を保証するものではありません。

有効なサーバーが複数ある場合は、Global RoutingとDNSを変更せず、サーバーだけを切り替えて比較できます。特定の項目だけ失敗する場合は、その設定とリモート側の状態を優先して確認してください。すべての項目が失敗する場合は、ローカルネットワークと共通の名前解決設定をあわせて確認します。この記事ではサーバーやサブスクリプションの提供、販売、推奨は行っていません。

3. Global Routingで問題の範囲を絞る

Home → Global Routingを開き、現在のモードを確認します。Proxy、Direct、Config、Sceneでは動作が異なるため、トラブルシューティングでは通信が実際にどのポリシーで処理されているかを先に確認してください。Proxyへの一時的な切り替えは比較に使えますが、あらゆるネットワーク問題を解決する設定ではありません。

モード	確認ポイント	比較の目的
Proxy	リクエストをグローバルプロキシモードで処理し、使用するサーバーまたはポリシーの選択も確認します。	同じ接続先がProxyでは開けてConfigでは失敗する場合は、ルールとポリシーの参照先を重点的に確認します。
Direct	リクエストを直接接続モードで処理します。接続先へは現在のローカルネットワークから直接アクセスできる必要があります。	プロキシ経由と直接接続の違いを切り分けるのに役立ちますが、システムトンネルをオフにする操作と同じではありません。
Config	Configで現在有効な構成に設定されている振り分けルールを使用します。	Homeで選択中の項目だけでなく、適用されたルール、ポリシーグループ、FINALも確認します。
Scene	自分で設定したシーンの条件と、それに対応する動作を確認します。	ネットワーク環境によってモードが変わる場合は、結果を比較する前にシーンの切り替えが影響していないか確認します。

比較時はサーバーと対象ドメインを固定し、まず元のモードで問題を再現します。次に一時的にProxyへ切り替えて再接続し、テスト後は元のモードに戻してください。Proxyでも失敗したからといって、DNSの問題を除外できるわけではありません。Configでは失敗しProxyでは成功しても、その1点だけでFINALの設定ミスとは断定できません。該当するポリシーが別の利用不能なサーバーを参照していないかも確認してください。

Configだけで失敗する場合：現在有効な構成、接続先に適用されたルール、ポリシーグループで実際に選択されている項目を確認します。
特定のSceneだけで失敗する場合：現在のネットワーク環境を記録し、Sceneの条件と結果を確認します。接続ネットワークを切り替えた後、以前の状況に基づいて判断しないようにしてください。
ProxyとConfigの両方で失敗する場合：共通するサーバー設定、名前解決経路、ローカルネットワークを引き続き確認します。

4. DNSを確認する：名前解決の成功は接続成功を意味しない

サーバーアドレスにドメイン名を使っている場合、その名前も先に解決する必要があります。接続先Webサイトのドメイン名の名前解決は、それとは別のリクエストです。そのため、「サーバーのレイテンシが測定できる」ことと「Webサイトのドメイン名を解決できる」ことは同じではありません。DNSを確認する際は、サーバーのドメイン名と接続先のドメイン名のどちらで失敗しているかを切り分け、それぞれの名前解決経路を確認してください。

従来型DNSは通常、UDPまたはTCPのこのポートを使用します

443

DoHは通常、HTTPS経由でこのポートを使用します

1項目

各回で変更するDNS設定は1つだけにして、再テストする

Configを開き、現在有効な構成のDNS項目を確認します。あわせてSettings → DNSの関連設定も確認し、無効な別の構成の値を現在の結果と取り違えないようにしてください。
リゾルバーのアドレス、使用方法、到達可能性を確認します。暗号化DNSもネットワーク接続を必要とします。HTTPSのリゾルバーアドレスを入力しただけでは、現在のルーティングで必ずアクセスできるとは限りません。
以前DNSを変更していた場合は、元の値を記録し、自分で利用できることを確認済みの設定に一時的に戻して、同じ接続先へ新しいリクエストを送ります。サーバー、リゾルバー、ルールを同時に変更しないでください。
ログに接続先のIPアドレスが取得済みと表示され、その後に接続がタイムアウトする場合は、外向きの通信経路と接続先サービスを確認します。名前解決の段階で明確に停止している場合は、リゾルバーへの接続とドメイン名を確認してください。

接続先のIPアドレスをブラウザーに直接入力する方法だけで確認しないでください。HTTPSサービスでは通常、ドメイン名、TLSのサービス名、仮想ホストの設定が必要です。IPアドレスへの直接アクセスでは、証明書エラーが発生したり、別のコンテンツが表示されたりすることがあります。IPv4とIPv6で到達性が異なる場合もあります。どちらかのアドレスファミリーを長期的に無効にして問題を隠すのではなく、ログに記録されたアドレスの種類をもとに原因を特定してください。

5. FINALとポリシーの参照先をルール順に確認する

Global RoutingがConfigの場合は、Configで実際に有効な構成を開いて、ルールの順序を確認します。通常、振り分けルールは上から順に適用されるため、先に一致したルールによって、後続のルールが適用されないことがあります。FINALは他のルールに一致しなかった場合の最終ルールです。先行するすべてのルールの代わりにはならず、サーバー認証の失敗を解決するものでもありません。

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

以下は構文の説明用であり、そのまま置き換えて使える完全な構成ではありません。example.comは例示用のドメイン名です。PROXYは、現在の構成で有効なプロキシポリシーまたはポリシーグループに対応している必要があります。この名前が構成内で別の対象を指している場合は、実際の定義を確認してください。英語の名前だけから最終的な外向き接続先を推測しないでください。

DOMAIN-SUFFIX：接続先のホスト名が指定したサフィックスに一致するか確認します。1つのページが複数のリソースドメインにリクエストを送ることがあります。メインのページが開けても、画像、API、ログインのリクエストが同じ経路を使うとは限りません。
IP-CIDR：IPアドレスの範囲に基づいて一致します。例のno-resolveは、このルールの照合のためにドメイン名を積極的に解決しないことを示します。リクエストにすでに含まれるアドレス情報を踏まえて結果を判断してください。
GEOIP：IPアドレスの地理情報データベースに基づいて一致します。Webサイトの言語、ドメインのサフィックス、ユーザーの所在地とは別の情報です。
FINAL：それ以前のルールに一致しなかったリクエストを処理します。利用できないポリシーグループを指定していると、先行ルールに一致しなかったページがまとめて失敗することがあります。

変更前に構成をコピーし、失敗する接続先に関係するルールまたはポリシーを1か所だけ調整してから、構成を再度有効にして接続をテストします。調整後に復旧した場合も、リクエスト記録で想定したルールに実際に一致したか確認してください。ページがたまたま開いたからといって、すべてのルールを置き換えたり、恒久的にProxyへ変更したりしないでください。

6. エラーログを見て再テストし、設定を元に戻す

アプリ内の接続記録またはログから、問題を再現した時刻と対象ドメインに該当するリクエストを探し、名前解決の結果、ポリシー、エラー情報を確認します。以下はネットワークログに表示されることがあるエラーの一部です。実際の表示にはアドレスや追加情報が含まれる場合があります。失敗した段階を判断するための手がかりであり、特定の設定ミスを直接証明するものではありません。

エラー：connection refused

原因と対処：接続先のポートが接続を拒否している場合によく見られますが、中継機器が拒否している可能性もあります。まず、記録がプロキシサーバーと接続先サイトのどちらを指しているかを確認し、該当するアドレス、ポート、サービスの待ち受け状態を確認してください。

エラー：i/o timeout

原因と対処：ネットワーク操作が制限時間内に完了しなかったことを示します。これだけでパスワードの誤りとは判断できません。同じ記録にある接続段階をもとに、接続ネットワーク、サーバー、リゾルバーをそれぞれ確認して再テストしてください。

エラー：no such host

原因と対処：ドメイン名の名前解決で有効な結果を取得できていません。ドメイン名の入力ミス、DNSレコードの状態、名前解決経路などが原因として考えられます。まず失敗したドメイン名を特定し、アドレスとDNS設定を確認してください。関係のないルールを変更しないでください。

明確なエラーが見つからない場合は、「接続ネットワーク、サーバー、Global Routing、接続先ドメイン、発生時刻、症状」を1つの記録にまとめます。たとえば、「Wi-FiでConfigを使うとタイムアウトする。サーバーは変更せずProxyに切り替えると同じページが開く」のように記録すると、「接続済みだが使えない」よりも原因を調べやすくなります。これは記録方法の例であり、この記事で実際にテストした結果ではありません。

テストのために一時変更したGlobal Routing、DNS、構成を元に戻し、比較によって必要性を確認できた変更だけを残します。
手動接続が安定したことを確認してから、元の要件に合わせてSettings → On Demandを再設定し、ネットワーク切り替え後の動作を確認します。
通常どおり直接アクセスできるページと、以前開けなかったページをそれぞれテストします。ページ内のAPIやリソースも正常に読み込まれるか確認してください。
自分のサービス提供元に問い合わせる場合は、プロトコル、ポート、発生時刻、個人情報を伏せたエラー記録を伝えます。サブスクリプションの完全なURL、パスワード、鍵、アカウント識別情報は隠してください。