Shadowrocketで接続済みなのにネットにつながらないときの対処法：サーバー・モード・DNS・ルールを確認

1. 接続済みなのにWebページが開けないのはなぜ？

まず、問題がどの段階で起きているかを確認します。端末でVPNトンネルを確立すること、リモートサーバーへ接続すること、アクセス先のドメインを名前解決すること、Webページの応答を受け取ることは、それぞれ別の段階です。Homeで接続スイッチがオンになっている、またはシステムにVPNアイコンが表示されているだけでは、Webサイトまでの経路全体が正常とはいえません。

最初に何をすればよいですか？まず、基準となるネットワークの状態を確認します。現在のネットワーク、選択中のサーバー、Global Routingのモード、使用中の設定を記録してください。その後、一時的にShadowrocketを切断し、今のネットワークから通常アクセスできるWebサイトを開きます。それでも失敗する場合は、ルールを変更する前に、Wi-Fiのログイン、モバイルデータ通信の権限、またはネットワーク自体を確認してください。

1. 現在の状態を記録

   Homeで選択中のサーバーとGlobal Routingの現在値を、Configで使用中の設定を記録します。トラブルシューティング後に元へ戻せるよう、設定のコピーを保存してください。

2. 自動接続を一時停止

   Settings → On Demandを開いて設定を記録し、On Demandを一時的にオフにします。次にHomeの接続スイッチをオフにし、直結テスト中にトンネルが自動で再接続されないようにします。

3. 基本ネットワークをテスト

   Safariで、普段そのままアクセスできるWebサイトを開きます。Wi-FiでWeb認証が必要な場合は先に認証を済ませ、同じURLをモバイル通信でも確認してください。

4. 接続をやり直す

   基本ネットワークに問題がなければ、Homeに戻って接続をオンにし、同じURLで再テストします。以降は設定を一つ変更するたびに、接続を確立し直して新しいリクエストを送信してください。

Wi-Fiとモバイル通信で結果が異なる場合、何がわかりますか？ネットワーク経路に関連する問題の可能性はありますが、特定のプロトコルの障害とはまだ断定できません。サーバーポートへの到達性、DNS、ネットワークの認証状態はネットワークごとに異なる場合があります。この差を記録し、次の確認に進みましょう。

2. サーバーテストに成功すれば、インターネットを使えますか？

いいえ。まずHomeで現在のサーバーの接続テストを実施し、テスト方法を確認します。ポートへの接続確認と、プロキシ経由でWebサイトへリクエストするテストでは、確認できる範囲が異なります。遅延時間が表示されても、すべてのドメイン、通信方式、接続先ポートが利用できるとは限りません。

テストに失敗した場合、まずどの項目を変更すればよいですか？現在のサーバーの編集画面を開き、利用中のサービス提供元から案内された情報と照らし合わせて、アドレス、ポート、Type、認証情報を一つずつ確認してください。経験則でポートを一律に443へ変更しないでください。443はHTTPSでよく使われるポートですが、リモートプロキシの待ち受けポートはサーバー側の設定と一致している必要があります。

手動で変更するか、サブスクリプションを更新するか、どちらを選べばよいですか？サーバーが自分のサブスクリプション経由で追加されている場合は、まずサブスクリプションの更新が成功していることと、選択中の項目がサービスの有効範囲内であることを確認してください。サブスクリプションを更新しても接続情報が更新されるだけで、リモートサーバーの稼働が確認できるわけではありません。コピーを保存せずに設定を何度も上書きすることも避けてください。この記事では接続先の情報を提供していません。パラメーターの有効性は、ご利用中のサービス提供元にご確認ください。

これらのエラーメッセージはどこで確認できますか？アプリの接続ログや診断情報、システムのネットワークエラーを確認し、実際に表示された原文と発生時刻を記録してください。リクエストによって表示される文言が異なる場合があります。該当するメッセージが表示されていない場合は、ここにある例を端末が出した診断結果とみなさないでください。

3. Global Routingの比較テスト方法

原因を切り分けやすいモードはどれですか？Home → Global Routingを開き、現在の値を記録したうえで、Direct、Proxy、Configを使い、同じURLに新しいリクエストを送ります。これは短時間の診断を目的としたテストで、特定のモードを継続して使うよう求めるものではありません。Directでの比較には、現在のネットワークから直接アクセスできる接続先を選んでください。

4. DNSの名前解決エラーを見分ける方法

Webページの読み込みが終わらない場合、必ずDNSが原因ですか？いいえ。DNSの障害と判断するには、レコードや明確な名前解決エラーによる裏付けが必要です。サーバーのアドレスがドメイン名の場合は、まずその名前を解決する必要があります。一方、アクセス先のWebサイトのドメイン名は、別の経路で解決されることがあります。前者で失敗すると、プロキシ接続自体を確立できない場合があります。

どこを確認すればよいですか？Configを開き、現在使用中の設定にあるDNS関連の項目を確認します。まず設定のコピーを保存してから、[General]内のdns-serverと、特定のドメインに適用される別のDNS設定がないかを確認してください。システムのWi-Fi設定でDNSを変更しても、設定ファイルで指定された名前解決経路には反映されない場合があります。

• アドレス形式を確認：スペルミス、区切り文字の抜け、到達できないDNSリゾルバーがないか確認してください。暗号化DNSのアドレスでは、ホスト名とHTTPS接続の到達性も関係します。
• 通信経路を確認：通常のDNSではUDPまたはTCPの53番ポートがよく使われ、DoHはHTTPSを使うため通常は443番ポートを利用します。ただし、ポートの用途だけでは、現在のネットワークからそのサービスへ接続できるかどうかはわかりません。
• 一項目だけ元に戻す：DNSを手動変更した後に問題が発生した場合は、複数のリゾルバーやモード、サーバーを同時に変更せず、まず変更前の設定コピーに戻してください。
• 新しいリクエストで再テスト：再接続してページを読み込み直し、新しく記録された情報を確認してください。ブラウザーやアプリにキャッシュが残る場合があります。一度の成功または失敗だけでは、すべてのドメインの状態は判断できません。

WebサイトのIPアドレスを直接入力すればDNSを切り分けられますか？それだけでは判断できません。HTTPSでは証明書の検証やバーチャルホストの選択にドメイン名が必要です。IPアドレスへ直接アクセスすると、証明書エラーが表示されたり、別のサイトが表示されたりする場合があります。まずドメイン名が有効な結果に名前解決されているかを確認し、その後の接続が成功するかを調べてください。

5. ルールの適用ミスで確認するキーワード

Configモードで一部のWebサイトだけ開けない場合、まず何を見ればよいですか？Configで選択中の設定を確認し、失敗したリクエストの接続ログを見て、対象のドメイン名またはIPアドレス、適用されたルール、最終ポリシー、使用サーバーを確認してください。Shadowrocketはルールを上から順に照合するため、条件に一致する先行ルールが結果に影響します。設定ファイルに対象ドメインの記述があるかを見るだけでは不十分です。

ルールの構文はどう確認すればよいですか？以下は3種類のルールと順序の例です。そのままインポートできる設定ではありません。example.comと192.0.2.0/24はドキュメント用の例です。PROXYの実際のプロキシ出口も、自分の設定で確認してください。

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

ここでno-resolveを指定する理由は何ですか？このIPルールに対して、ルール照合のためにドメインの名前解決を自動で行わないことを示します。DNS全体を無効にする指定ではありません。また、後続のルールで引き続き照合する場合、その前にFINALを置かないでください。後続ルールで意図した振り分けができなくなります。

• ページのテキストは表示されるのに画像が読み込めない場合は、ページ、画像、APIの各ドメインのログを確認してください。メインサイトのルールを追加するだけでは解決しない場合があります。
• ルールでポリシーグループを選択している場合は、グループ内で実際に選択されているサーバーも確認してください。グループ名が存在していても、メンバーが利用できるとは限りません。
• 手動変更後に一時的に復旧した場合は、変更前後の差分を保存し、サブスクリプションまたは設定の更新によってローカルの変更が上書きされていないか確認してください。

6. トラブルシューティング後に設定を戻し、有効な情報を残す方法

問題が解消したらすぐ終了してもよいですか？まず普段使うGlobal Routingのモードに戻し、Configで想定した設定が選択されていることを確認してください。普段On Demandを使用している場合は、Settings → On Demandで元の条件に戻します。Wi-Fi、モバイル通信、ネットワーク切り替え後のそれぞれで動作を確認してください。一時的な診断モードを最終設定として残さないようにしましょう。

原因を特定できない場合、何を伝えればよいですか？「接続済みなのに開けない」とだけ伝えるのではなく、再現可能な手順として情報を整理してください。サービスのパラメーターや稼働状況はサービス提供元に、アプリ内の設定はモード、設定、接続ログをもとに確認します。情報を外部に送る前に、サブスクリプションのトークン、パスワード、UUID、秘密鍵、その他の認証情報を隠してください。

• テスト環境：端末の種類、システム情報、Wi-Fiまたはモバイル通信の別、基本ネットワークが正常かどうか。
• ルーティングの比較：同じURLがDirect、Proxy、Configでそれぞれ開けたかどうか。
• サーバーの状態：プロトコルのType、接続テストの方法と結果。認証キーは送信しないでください。
• リクエストの記録：発生時刻、個人情報を伏せたエラーメッセージ、適用されたルール、最終ポリシー。
• 変更履歴：最後に正常に使用できた後、サーバーの変更、サブスクリプションの更新、DNSまたは設定の変更があったかどうか。