Shadowrocketが接続中なのにインターネットにつながらないときの対処法｜サーバー・モード・DNS・ルールを確認

1. まず問題の範囲を確認する（すぐに再インストールしない）

まず、基本のネットワークに問題があるのか、接続をオンにした後に問題が起きるのかを切り分けます。Homeで接続をオフにし、Safariで普段そのまま開けるWebサイトを2つ表示します。次に接続をオンにして、同じページにアクセスします。テスト中は同じWi-Fiまたはモバイル通信を使い、ネットワーク、サーバー、設定を同時に変更しないでください。どの変更が影響したのか判断できなくなります。

1. 元の設定を記録する

   Homeで選択中のサーバーとGlobal Routingを、Configで現在有効な設定ファイルを記録します。設定ファイルを編集する場合は、先にコピーを保存してください。記録にパスワード、サブスクリプションURL全体、その他の認証情報を含めないでください。

2. オフにして比較する

   Homeの接続スイッチをオフにして、もう一度Webページを開きます。ネットワークが自動的に再接続する場合は、Settings → On Demandを確認します。テスト中は有効な起動条件を一時的にオフにし、確認が終わったら元に戻してください。

3. 基本のネットワークを確認する

   接続をオフにしても通常のWebサイトにアクセスできない場合は、まずWi-Fiのログイン認証、モバイルデータ通信の許可、電波状況を確認します。公共Wi-Fiで認証が必要な場合は、システムまたはSafariのログイン画面で認証を済ませてください。

4. テストするWebサイトを固定する

   そのままアクセスできることが分かっているページと、普段は自分のサーバー経由でアクセスするページを1つずつ選び、表示できたか、タイムアウトしたかを記録します。1つのWebサイトの結果だけで、ネットワーク全体の状態を判断しないでください。

接続をオフにしても失敗する場合は、まず基本のネットワークを確認してください。接続をオンにしたときだけ失敗する場合は、以降の項目を確認します。特定のWebサイトだけ失敗する場合は、サイト側の障害やアクセス制限、ルールの違いも考えられます。システムにVPNの表示があっても、リモートのWebサイトへの接続が確立した証拠にはなりません。

2. サーバーを確認する：テスト結果だけでは利用可能と判断できない

まず、選択中のサーバーで実際のリクエストが完了するか確認します。Home → Connectivity Testでテストを実行し、SERVERリストで選択中のサーバーも確認してください。遅延時間が表示されても、そのテスト条件で応答があったことを示すにすぎません。すべてのドメイン、ポート、アプリの通信が正常に通るとは限りません。

• アドレスとポート：選択中のサーバーの編集画面を開き、サービス提供元から案内されたアドレスとポートを一つずつ確認します。ポートに共通の値はありません。既存のパラメーターに443と明記されている場合に限り443を入力してください。すべてのプロトコルに使える既定の修正値ではありません。
• 認証パラメーター：使用するプロトコルに応じて、パスワード、UUID、鍵を確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardのパラメーターは、それぞれ別のものです。相互に流用しないでください。
• 通信パラメーター：サーバー側でTLS、SNI、パス、特定の通信方式が指定されている場合は、既存のパラメーターと一致させます。ホスト名や証明書の問題を隠すために、証明書の検証をオフにしないでください。
• サービスの有効状態：現在のサービスが有効か、サーバーがメンテナンス中でないか、接続数に制限がないかを、利用中のサービス提供元に確認します。同じデータを再度読み込んでも、リモート側のサービス停止は解決しません。

エラー文は、発生した箇所と合わせて確認してください。以下は接続ログに表示されることがある低レベルのエラー例です。実際の文言はプロトコルや失敗した段階によって異なります。同じエラー文だけでは、サービス提供元、DNS、ルールのどれに問題があるかは断定できません。

3. Global Routingを確認する：モードを切り替えて切り分ける

Global Routingはリクエストの振り分け方法を決める機能で、利用できなくなったサーバーを修復するものではありません。Home → Global Routingで現在の選択肢を記録し、ProxyとConfigを一時的に切り替えて比較します。テスト後は元の選択肢に戻し、診断操作によってすべてのリクエスト経路を変えたままにしないでください。

On Demandは接続を開始するタイミングを制御する機能で、Global Routingによるリクエストの振り分けを行うものではありません。接続をオフにした後に自動でオンになる場合は、まずSettings → On Demandを確認します。接続中なのに一部のWebサイトだけ失敗する場合は、On Demandを何度も切り替えるのではなく、モードと該当リクエストを確認してください。

4. DNSを確認する：サーバーのドメインと接続先のドメインを切り分ける

DNSを確認する際は、まずどの名前の名前解決に失敗したかを特定します。サーバーアドレスがドメイン名の場合は、接続の確立前に名前解決が必要になることがあります。接続先のWebページがドメイン名の場合は、そのリクエストがどの経路で名前解決されるかも関係します。前者の失敗はサーバーに接続できない原因になり、後者の失敗は一部のWebサイトだけに影響する場合があります。

ポートに接続できても、正しく名前解決できるとは限りません。暗号化DNSでは、名前解決サービスのアドレスに到達できることと、TLS検証が正常に行われることも必要です。ドメイン名を使う名前解決サービスでは、最初の名前解決が別途必要になる場合もあります。よく分からない名前解決先を複数まとめて設定すると、確認項目が増え、原因を特定したことの証明にもなりません。

1. Configで現在有効なファイルを確認し、編集画面を開いて[General]内の既存のdns-server設定を確認します。元の値を先に保存し、設定全体をそのまま上書きしないでください。
2. DNSを手動で変更した直後に問題が起きた場合は、まず以前に使えていた設定へ戻します。比較が必要な場合は、設定ファイルのコピーでdns-server = systemを使い、システムの名前解決経路をテストできます。これは切り分けの基準であり、すべてのネットワークに適した最終設定ではありません。
3. テスト用の設定を保存して有効にしたら、再接続して新しいWebリクエストを送信します。ブラウザーが既存の接続やキャッシュを再利用する場合があるため、一度更新するだけでは新しい設定が反映された証拠になりません。
4. [Host]に手動のドメインマッピングがある場合は、古いアドレスを参照していないか確認します。DNS設定を元に戻しても、設定ファイルに個別に指定した静的マッピングは自動で削除されません。

5. ルールを確認する：最初に一致するルールからFINALまで

Configモードでは、ファイルが存在するかどうかだけでなく、実際に有効なルールを確認します。通常、ルールは上から順に照合されるため、上位の大まかなルールが一致すると、下位の詳細なルールが適用されないことがあります。まずConfigで有効なファイルを確認し、次に[Rule]内で失敗するドメインに関係するルールと最終ポリシーを確認してください。

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

このコードは構文を示す例であり、日常利用の設定全体を置き換えるものではありません。example.comは例示用のドメインです。PROXYには利用可能なプロキシポリシーが必要です。設定ファイルで名前付きポリシーを使っている場合は、Homeのリストだけでなく、そのポリシーで実際に選択されているサーバーを確認してください。

• DOMAIN-SUFFIX：DOMAIN-SUFFIX,example.com,PROXYは、そのドメインとサブドメインに一致します。Webサイトが別のドメインもリクエストする場合があるため、トップページが開いても、画像、ログイン、APIが同じルールに一致するとは限りません。
• IP-CIDR：192.168.0.0/16はアドレス範囲を表します。例のno-resolveは、そのIPルールだけを適用するためにドメイン名の名前解決を行うのを避ける指定です。接続全体でDNSを使わなくなるという意味ではありません。
• GEOIP：GEOIP,CN,DIRECTは、IPアドレスの地理的な分類に基づいてポリシーを決定します。ドメインのサフィックスによる分類とは異なり、結果は使用するデータベースにも左右されます。
• FINAL：FINAL,DIRECTは、それより前のルールに一致しなかった場合に直接接続します。接続先が既存のプロキシ経由である必要があるのにここへ一致すると、接続スイッチがオンでもアクセスできないことがあります。

ルールを修正するときは一度に一か所だけ変更し、同じ接続先で再確認してください。Proxyモードでも失敗する場合、FINALをプロキシに変えるだけではサーバーの認証エラーは解決しません。Configモードだけで失敗する場合は、一致したルールとそのポリシーを優先して確認します。テスト後、残す必要のない一時ルールは元に戻してください。

6. よくある質問と確認後の作業

確認後は、認証情報を含む設定ファイル全体ではなく、再現可能な症状を記録してください。ネットワークの種類、サーバーのプロトコル、Global Routing、接続できない対象、エラーが起きた段階を記録すると、「スイッチはオン」という情報だけより原因を絞り込みやすくなります。利用中のサービス提供元に問い合わせる場合は、パスワード、UUID、秘密鍵、サブスクリプショントークンを削除してください。