Shadowrocketが接続済みなのにネットにつながらない？サーバー・モード・DNS・ルールの確認方法

この記事の要点

Shadowrocketの接続スイッチがオンになっている状態は、端末のトンネルが起動していることを示しますが、接続先のWebサイトにアクセスできるとは限りません。自分で用意したサービス設定を読み込み済みの方を対象に、サーバー、Global Routing、DNS、ルールの順で切り分けます。ローカルネットワーク、リモート接続、名前解決、通信の振り分けを確認し、一度に変更するのは1項目だけにして、テスト後は元の設定に戻してください。

始める前に：テスト条件をそろえ、ネットワークの基本接続を確認

まずHomeで選択中のサーバーとGlobal Routingの状態、Configで使用中の設定を記録します。確認中は同じ端末、同じネットワーク、同じドメインを使ってください。Wi-Fi、サーバー、設定を同時に変えると、結果が変わった原因を特定できません。この記事では、利用者自身がサービスとサブスクリプションを用意していることを前提としています。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。

Shadowrocketの接続スイッチをオフにし、普段なら直接開けるWebサイトにアクセスしてください。それでも開けない場合は、Wi-Fiでログインが必要か、モバイルデータ通信が使えるか、端末が制限付きネットワークに接続されていないかを先に確認します。この段階ではプロキシルールを変更しても切り分けになりません。まず通常のネット接続を復旧し、その後、接続スイッチをオンにして再テストしてください。

元の状態を記録する

Homeで選択中のサーバーとGlobal Routing、Configで現在の設定名を記録します。編集前に設定のコピーを保存してください。元ファイルやサブスクリプションに含まれる認証情報は、自分の端末だけに保存します。
自動接続を確認する

Settings → On Demandを開き、現在の設定を記録します。スイッチをオフにしても接続が自動で再開する場合は、比較テスト中だけOn Demandを一時的にオフにして、自動接続が結果に影響しないようにしてください。
ネット接続の基準を確認する

接続スイッチをオフにして、直接アクセスできることが分かっているWebサイトをテストします。ネットワークへの認証が必要な場合は、先にネットワーク提供元のログイン手続きを完了してください。認証が済んでいない状態をサーバーの障害と取り違えないようにしましょう。
再テストする対象を固定する

直接アクセスできるドメインと、問題が起きているドメインをそれぞれ1つ選び、接続スイッチがオフのときとオンのときの結果を記録します。以降は項目を変更するたびに、この2つの対象へ再アクセスしてください。

1つ目：Homeで選択中のサーバーがリクエストを処理できるか確認する

Homeに戻り、似た名前の古い項目ではなく、テスト対象のサーバーが選択されていることを確認します。該当項目の編集画面を開き、サーバーアドレス、ポート、プロトコル、認証情報を照合してください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは必要な項目が異なります。利用中のサービス提供元から取得した情報と一つずつ照合し、Typeだけ変更して他の項目をそのままにしないでください。

HomeでConnectivity Testを実行するときは、「遅延の数値が表示された」ことと「ブラウザーのリクエストが成功した」ことを区別してください。テスト方法によって確認できる段階は異なります。TCP接続の確立に成功しても、認証、TLSハンドシェイク、UDP通信、接続先Webサイトへのアクセスまで正常とは限りません。後続の通信経路を確かめるには、ブラウザーから実際にリクエストを送ってください。

アドレスとポート：サーバーのドメイン名またはIPアドレス、サービスポートが元の情報と一致するか確認します。ポート443はHTTPSでよく使われますが、すべてのサービスが使うわけではなく、入力すれば接続できるという意味でもありません。
認証とトランスポート：パスワード、UUID、TLS Server Nameなどは、該当プロトコルで使う項目だけを確認してください。エラーをなくすために証明書の検証を安易にオフにせず、サーバー名、端末の時刻、サーバー証明書を先に確認します。
既存のサブスクリプション：自分のサブスクリプションから設定を読み込んでいる場合は、Homeで該当するサブスクリプションを更新し、更新後の項目を選び直してください。更新に成功しても、リストを取得できたことを示すだけで、掲載されているすべてのサーバーから目的のWebサイトへアクセスできるとは限りません。
ネットワークの違い：同じ項目がモバイルデータ通信では使えてWi-Fiでは失敗する場合は、そのWi-FiでポートやUDPが制限されていないかを優先して確認します。ネットワークの切り替えは比較テストにのみ使い、プロトコルやDNSを同時に変更しないでください。

以下はネットワークログに表示されることがある一般的なエラー文字列です。すべてのプロトコルで同じ文言が表示されるとは限りません。前後のログも含めて、エラーの対象がサーバー、DNSリゾルバー、接続先Webサイトのどれなのかを確認してください。

エラー：connection refused

原因：該当する接続が拒否応答を受け取っています。接続先ポートでサービスが待ち受けていない場合や、接続が明示的に拒否された場合によく見られます。

対処：まずログに記録されたアドレスとポートを確認します。対象が自分のサーバーの場合は、利用中のサービス提供元にサービスの稼働状況と正しいポートを問い合わせてください。

エラー：i/o timeout

原因：読み取りまたは書き込みの処理が制限時間内に完了していません。ネットワーク上のパケット損失、到達できないポート、リモート側から応答がないことなどが考えられます。

対処：設定項目は変更せず、利用可能な別のネットワークで再テストします。そのうえで、エラーが発生した段階に応じてサーバー接続またはDNSリクエストを確認してください。

エラー：no such host

原因：該当するホスト名を有効なアドレスに解決できていません。解決できない名前はサーバーのドメイン名の場合も、接続先Webサイトのドメイン名の場合もあります。

対処：まずドメイン名の入力と有効性を確認し、その後DNSを調べます。サーバーのドメイン名自体を解決できない場合、プロキシポリシーを切り替えるだけでは解決しません。

2つ目：Global Routingでプロキシ経路と設定の問題を切り分ける

Home → Global Routingで現在の選択を確認します。Proxyはプロキシ可能なリクエストをプロキシ経路へ送ります。Directは直接接続し、Configは現在の設定に従って処理します。Sceneはシーンの設定に応じて動作します。SceneはProxyやConfigのどちらかに固定されるものではないため、切り分けの際は現在のシーンで適用されている設定を確認してください。

同じサーバー、同じネットワークのまま、まず一時的にProxyを選択して問題のドメインを再テストし、次にConfigへ戻して試します。ProxyではアクセスできてConfigでは失敗する場合、サーバー全体の障害ではなく、ルール、ポリシーの転送先、その他の設定が原因である可能性が高くなります。比較テストが終わったら元のモードに戻してください。一時的なテスト設定を恒久的な解決策と誤認しないようにしましょう。

モード	確認する内容	結果の見方
Proxy	選択中のプロキシ経路をテスト	アクセスできれば、現在の条件でそのリクエストをプロキシ経由で処理できたことを示します。すべてのドメインが使えるという意味ではありません。
Direct	直接接続との比較	直接アクセスできると分かっているWebサイトだけを使ってテストします。接続先が現在の環境で直接アクセスできない場合、失敗しても障害の特定にはつながりません。
Config	現在の設定を確認	Proxyでの結果と異なる場合は、ルールの一致状況、ポリシーの転送先、DNSなど設定の違いを調べます。
Scene	シーンの選択を確認	まず現在のシーンで適用されている設定を確認し、固定モードと比較します。シーンの切り替えによる余分な変数を避けてください。

結論：Proxyが正常なら次にルールを確認

同じ接続先がProxyでは使えてConfigでは失敗する場合は、使えるサーバーはそのままにして、現在の設定と適用されるポリシーを確認します。サーバー項目を同時に作り直すと、すでに確認できた比較結果を失う可能性があります。

3つ目：サーバーのドメイン名とWebサイトのドメイン名の名前解決を切り分ける

DNSは少なくとも2つの段階で使われる可能性があります。まずサーバーのドメイン名をアドレスに変換し、その後、接続先のアドレスを取得します。前者の失敗はサーバーへの接続を妨げ、後者の失敗は接続済みでもWebページが読み込めない原因になります。ログを確認するときは、名前解決に失敗した完全なドメイン名を特定してください。DNSという文字だけを見て、すべての名前解決設定を置き換えないようにしましょう。

Configで現在の設定を開き、[General]内のdns-serverを確認します。同時に、接続先ドメインに影響する[Host]のマッピングがないかも確認してください。古い社内DNSや到達できないリゾルバーが残っている場合、あるいはドメイン名が期限切れのアドレスに割り当てられている場合、接続結果に影響することがあります。DNS設定が複数ある場合は、現在有効な設定を確認し、使われていないファイルを変更しないようにしてください。

2か所

サーバーと接続先のドメイン名をそれぞれ確認

従来型DNSで一般的に使われるUDPまたはTCPのポート

443

DoHは通常HTTPSのポートを使用します。すべてのDNSで使われるポートではありません。

まずエラーに記録されたドメイン名の綴りを確認し、サーバーのドメイン名が無効になっていたり、Webアドレスが誤っていたりしないか調べます。
設定のコピーを保存したうえで、システムの名前解決と比較するために一時的にdns-server = systemを使用できます。ただし、これは一般的な推奨値ではなく、システムDNSも現在のネットワークの影響を受ける場合があります。
[Host]に問題のドメイン名の古いアドレスが登録されていないか確認します。問題があると確認できたマッピングだけを取り消し、用途の異なる他の記録までまとめて削除しないでください。
設定を保存し、その設定が選択されていることを確認します。接続を確立し直して同じドメイン名へ再度アクセスし、変更前との違いを記録してください。

4つ目：Configのルール順序と実際に適用されるポリシーを確認する

Proxyで接続できてConfigで失敗する場合は、Configで選択中のファイルを確認し、その中の[Rule]を調べます。ルールは通常上から順に照合され、一致すると対応するポリシーが適用されます。前方にある広範囲なルールが、後方の詳細なルールより先に一致することがあります。有効になっていない別のファイルを変更しても、現在の接続に使われているルールは変わりません。

DOMAIN-SUFFIXは指定したドメイン名とそのサブドメインに一致し、IP-CIDRはアドレス範囲に一致します。GEOIPはIPの地理情報データベースを使って分類し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。ドメインルールとIPルールでは照合対象が異なります。IP分類を使う場合はアドレスがすでに取得されているかも考慮してください。ルールの順序をDNSと無関係なものとして扱うことはできません。

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

この設定例は構文の説明だけを目的としています。example.comは例示用ドメイン、192.0.2.0/24は文書用の例示ネットワークです。実際のサービスに接続できるかの判断には使わず、ご自身の運用設定をこの内容で丸ごと置き換えないでください。no-resolveは、このIPルールのために名前解決を積極的に行わないことを示します。グローバルDNSを無効にするスイッチではありません。

DIRECTに一致：リクエストは直接接続されます。現在のネットワークから接続先に直接アクセスできない場合は、広範囲なドメインルールやアドレスルールが先に一致していないか確認してください。
REJECTに一致：ルールによってリクエストが拒否されています。該当するルールと用途を特定し、誤って対象になっていることを確認してから、必要な箇所だけを調整してください。拒否ルールをすべて削除するのは避けましょう。
PROXYに一致：現在使用中のプロキシ転送先を確認します。ルールがカスタムポリシーグループを参照している場合は、そのグループで実際に選択されている項目も確認してください。Homeの選択表示だけでは判断できません。
FINALに到達：それ以前のルールに一致しなかったことを示します。最後に適用されるポリシーが意図どおりかを確認し、必要な詳細ルールが広範囲なルールに上書きされる場合は、その前に配置してください。

再テスト時はShadowrocketのリクエスト記録またはログで同じ接続先ドメインを探し、一致したルールと最終的なポリシーを確認します。1つのWebページから画像、スクリプト、ログイン用APIへもリクエストが送られる場合があります。メインのドメインには接続できてもページが表示されないときは、メインのドメインに同じルールを追加し続けず、失敗しているリソースのドメインを確認してください。

よくある質問：症状に応じた次の確認

遅延の数値が出ているのに、ブラウザーで開けないのはなぜ？

まずConnectivity Testで使われたテスト方法を確認し、実際のWebページへのリクエストで検証してください。ポートに接続できても認証に失敗すれば、このような状態になります。Homeでプロトコルと認証情報を確認し、接続、ハンドシェイク、リクエストのどの段階で失敗したかを調べてください。

Wi-Fiだけ使えず、モバイルデータ通信では使える場合、まず何を確認すればいい？

サーバーとGlobal Routingは変えず、まずWi-Fiの基本接続と認証ページを確認し、その後DNSとポートへの到達性を比較します。サービスがUDPに依存する場合は、そのネットワークでUDPが制限されていないかも確認してください。ネットワークによる違いだけでアカウントが無効だと判断しないでください。

1つのWebサイトだけ開けないとき、すべての設定をリセットする必要はある？

まずProxyとConfigを切り替えて比較し、その後、該当ドメインの名前解決と適用されるポリシーを確認してください。他のWebサイトにアクセスできるなら、通信経路の少なくとも一部は使えています。どちらのモードでも同じ接続先だけ失敗する場合は、接続先サイトの応答やアクセス制限も考慮してください。

設定を変更しても変化がないとき、どこを確認すればいい？

Configで変更後のファイルが実際に選択されていることを確認します。Homeに戻り、Global RoutingがConfigになっていることを確かめてから、接続を確立し直してテストしてください。Sceneを使用中の場合は、シーンで実際に適用されている設定を先に確認します。テスト後はSettings → On Demandを元の設定に戻してください。

原因を特定できない場合は、発生時刻、ネットワークの種類、プロトコル名、Global Routingの状態、接続できないドメイン名、個人情報を伏せたエラーの一部をまとめて、利用中のサービス提供元に確認してもらってください。サブスクリプションのURL全体、パスワード、UUID、秘密鍵、アクセストークンを含むスクリーンショットは公開しないでください。これらの情報と、問題の切り分けに必要な症状の記録は分けて保管しましょう。