Shadowrocketの接続をオンにしてもネットにつながらないときの対処法：サーバー・モード・DNS・ルールを確認

1. 基本のネットワークとプロキシ接続の問題を切り分ける

最初にアプリを削除したり、すべての設定をリセットしたりする必要はありません。まずHomeで接続スイッチをオフにし、現在のWi-Fiまたはモバイルデータ通信で、通常そのままアクセスできるWebサイトが開くか確認します。公衆Wi-Fiでログインが必要な場合は、先にネットワーク認証を済ませてください。接続をオフにしても一般的なWebページが開かない場合は、端末の通信またはネットワーク接続を先に確認します。

スイッチをオフにすると正常で、オンにすると問題が起きる場合は、通信経路が有効化後に変わったことが関係していると考えられます。ただし、原因がサーバーだとは限りません。DNSの誤設定、ルール内のREJECT、無効なサーバー情報、ほかのネットワーク拡張機能との競合でも、似た症状が起こることがあります。

1. 現在の設定を記録

   Homeで選択中のサーバーとGlobal Routingを記録し、Configで現在有効な設定ファイルを確認します。編集前に設定のコピーを保存してください。パスワード、サブスクリプションURL、アクセストークンを公開の場に送らないでください。

2. 直接接続を確認

   接続スイッチをオフにして、ブラウザで直接アクセスできることがわかっているページを開きます。公衆Wi-Fiの認証画面が表示された場合は、認証を済ませてからHomeに戻ります。

3. テストするページを固定

   問題が起きているページのURLを1つ決めます。以降は変更のたびに同じURLを再読み込みし、ページのタイムアウト、ドメインの名前解決失敗、正常に返されたHTTPエラーを区別します。

4. ネットワークを比較

   モバイルデータ通信を利用できる場合は、Wi-Fiと比較します。サーバー、モード、設定は変えず、片方のネットワークだけで失敗する場合は、そのネットワークの制限や名前解決の条件を優先して確認します。

2. HomeでサーバーとConnectivity Testを確認する

Homeで、選択中のサーバーが有効な自分のサービス情報に基づくものか確認し、Connectivity Testを実行します。テストに応答があっても、確認できるのはテスト方式が利用した経路で応答があったことだけです。ブラウザのDNS、ルールの一致、Webサイトへのアクセスが正常とは限りません。逆に、1回タイムアウトしただけでサーバーの無効を断定することもできません。実際のリクエストや別のネットワークでの再テストとあわせて判断してください。

現在のサーバーの編集画面を開き、自分のサービス情報と照らし合わせて、タイプ、アドレス、ポート、認証項目を確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは必要な項目が異なります。「試しに」Typeを変更しないでください。元の情報でTLSが有効になっている場合は、関連するサーバー名と証明書の検証設定も確認します。検証を無効にすることを通常の対処法にしないでください。

• アドレス：余分な空白が含まれていないか、ドメインのスペルが正しいか確認します。サーバーにドメイン名を使っている場合は、ドメインの名前解決も必要です。
• ポート：手元のサービス情報に記載された値を使います。たとえば資料に 443 とある場合は、443 になっているか確認します。一般的によく使われるからといって、自分のポートを 80 や 443 に変更しないでください。
• 認証：パスワード、UUID、鍵、暗号化パラメータがサーバー側の情報と一致している必要があります。サーバーとの基礎的な接続が確立しても、認証が成功したとは限りません。
• サブスクリプション：サービス提供元がサーバー情報を変更した場合は、Homeで既存のサブスクリプションを更新してから、選択中の項目を確認します。更新に成功しても、リスト内のすべてのサーバーが利用できるとは限りません。

エラー文の内容から原因を絞る。「タイムアウト」だけで判断しない

接続ログや診断結果に次の英語のエラーが表示された場合は、それぞれの観点から確認します。表示される具体的なエラーは失敗した段階によって異なり、Webページが開かないたびに必ず同じエラーが出るわけではありません。

サブスクリプションの更新だけが失敗し、既存のサーバーでWebページにアクセスできる場合は、サブスクリプションURLへのアクセスの問題として扱います。利用可能な設定まで削除しないでください。サブスクリプションURLのトークンは機密情報です。問い合わせる際は、完全なURLを送らず、エラー内容と発生した段階だけを伝えてください。

3. Global Routingでモードを比較する

Home → Global Routingで現在の選択肢を確認します。Configは有効な設定ファイルのルールに従ってリクエストを処理します。Proxyはプロキシモードとの比較に、Directは直接接続との比較に使います。Sceneは利用中のシーン設定とあわせて判断する必要があり、Configと常に同じ意味の選択肢ではありません。一時的な切り替えは診断のためだけに行い、確認が終わったら必要なモードに戻してください。

4. DNSとdns-serverの設定を確認する

DNSはドメイン名をIPアドレスに変換します。サーバー自体にドメイン名を使っている場合、プロキシ接続を確立する前にも名前解決が必要になることがあります。そのため、「サーバーアドレスの名前解決失敗」と「Webサイトのドメイン名の名前解決失敗」は別の段階として記録し、どちらも一括してサーバーの利用不可と判断しないでください。

Configを開いて現在有効なファイルを確認し、編集内容の [General] にある dns-server を確認します。以下はシステムの名前解決を使う単項目の診断例で、すべてのユーザーに既存設定の上書きを勧めるものではありません。ネットワーク側のシステム名前解決に問題がある場合、system に変更しても自動的には解決しません。

[General]
dns-server = system

1. 元の dns-server の行と関連するDNS設定を保存し、変更後に元へ戻せるようにしておきます。
2. 入力ミス、無効なアドレス、コピー時の不要な文字がないか確認します。DNSサーバーは現在のネットワークとルーティング条件で到達可能である必要があります。アドレスの形式が正しいだけで、利用可能とは判断できません。
3. システムの名前解決と比較する場合は、この項目だけを置き換えて保存します。変更後の設定が使われていることを確認し、接続を確立し直してからWebページを読み込みます。
4. 結果に変化がなければ元の値に戻し、ルールとサーバーの確認に進みます。アクセスが復旧した場合は、ネットワーク環境を踏まえて、元のリゾルバーに到達できなかった理由を確認します。

5. REJECT、ルールの順序、FINALを確認する

一部のWebサイトだけ開かない場合、特にProxyでは正常でConfigでは異常な場合は、Configで有効なファイルの [Rule] を確認します。ルールは上から順に照合され、一致するとそのルールに指定されたポリシーが適用されます。範囲の広いルールが前にあると、後続の細かいルールが照合されないことがあります。

DOMAIN-SUFFIX はドメインとそのサブドメイン、IP-CIDR はIPアドレスの範囲、GEOIP はIPの地理データベースをもとに照合します。それぞれ判定方法が異なり、IP関連のルールではドメインの名前解決結果も関係する場合があります。切り分けでは、失敗したリクエストのドメイン名と実際に一致したルールを確認し、ルールキーワードを相互に置き換えないでください。

[Rule]
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT

この例では example.com とそのサブドメインへの接続を拒否し、それ以外で一致しないリクエストは DIRECT に送ります。原因の説明を目的とした例であり、推奨設定ではありません。実際のWebサイトが似たルールに誤って一致すると、接続スイッチがオンでサーバーテストに応答があっても、ページを読み込めないことがあります。

• まずREJECTを確認：拒否ルールの対象範囲が広すぎないか確認します。Webサイトではログイン、画像、APIなど別のドメインも使われる場合があります。トップページは表示できてもログインに失敗する場合は、どのリクエストが失敗したか確認してください。
• 次に適用先のポリシーを確認：ルールが DIRECT の場合は直接接続されます。PROXY の場合は、現在選択されているプロキシが有効か確認します。カスタムのポリシーグループ名を使う場合は、定義済みの名前と一致している必要があります。
• 最後にFINALを確認：FINAL,DIRECT と FINAL,PROXY では、どの経路を最終的に選ぶかが異なります。FINALはルール一覧の末尾に置き、照合が必要なルールより前に配置しないでください。
• 編集対象を確認：変更して保存するファイルが、現在有効な設定ファイルであることを確認します。設定がリモート更新される場合は、後続の更新で診断中の変更が上書きされないよう、先にローカルのコピーを保存してください。

ルールを修正したら、Global Routing → Configで同じURLを再テストします。トップページが表示されても一部のリソースが失敗する場合は、FINALを繰り返し変更するのではなく、失敗したリソースのドメインを特定してください。複数のドメインを使うWebサイトでは、メインドメインだけを許可しても、すべてのリクエストをカバーできるとは限りません。

6. On Demandと接続が繰り返される現象を確認する

スイッチをオフにしてもすぐに自動接続される場合や、ネットワークを切り替えるたびにテスト条件が変わる場合は、Settings → On Demandで現在の状態を記録します。診断中は、有効になっているOn Demandを一時的にオフにしてからHomeに戻り、接続を手動で操作します。自動接続によって比較結果が変わるのを防げます。確認後は、元の用途に合わせて設定を戻してください。

• 接続が自動的に再開する：まずOn Demandが原因か確認します。自動再接続をすぐにサーバーの接続切れと判断しないでください。
• ほかのネットワーク拡張機能がある：端末のシステム設定で、ほかのVPNやネットワークフィルタの設定を確認します。一時停止してよいと確認できた場合に限り、1つずつ停止して再テストしてください。複数の設定をまとめて削除しないでください。
• 特定のアプリだけ失敗する：ブラウザから同じサービスにアクセスして比較し、そのアプリのネットワーク権限とサービスの状態を確認します。すべてのリクエストを同じポリシーに変更しないでください。
• 追加の問い合わせが必要：発生時刻、ネットワークの種類、Global Routingの設定、一部のドメインだけで問題が起きるか、エラーの原文、すでに行った比較テストをまとめます。サーバーのパスワード、UUID、秘密鍵、サブスクリプショントークンは伏せてください。

アプリの再インストールは、比較に使う設定や記録を失う可能性があるため、最初に行う対処ではありません。サーバー情報が無効な場合は利用中のサービス提供元に確認し、ルールの誤一致はルールを修正し、基本のネットワークに問題がある場合はネットワーク接続を先に解決します。問題が起きている段階を特定すると、スイッチを何度も切り替えるより結果を検証しやすくなります。

7. よくある質問と設定を戻す手順