Shadowrocketの接続をオンにしただけでは、リモートサーバーやドメイン名の解決、ルールに沿った通信経路がすべて正常とは限りません。自分で用意したサービスの設定を読み込んだものの、端末全体がネットにつながらない、または一部のアプリが開けない場合に向けた内容です。まず接続を切った状態でネットワークの基準を確認し、サーバー、Global Routing（グローバルルーティング）、DNS、Config（設定ファイル）の順に調べます。設定を変更するときは、一度に一項目だけ変更してください。
1. まず通信できない範囲を確認し、元に戻せる状態を保つ
最初にアプリを削除したり、設定をすべて消去したりしないでください。サーバー情報や現在のルール、原因を調べる手がかりが失われます。Home（ホーム）で選択中のサーバー、Global Routingの現在の値、Configで使用中の設定ファイルを記録します。認証情報を含むスクリーンショットは端末内だけに保存してください。
この図は確認する範囲を示したもので、すべての通信が常に同じ内部処理順になるわけではありません。ルールの判定時に名前解決が行われる場合や、サーバーのドメイン名を先に解決する必要がある場合もあります。システムにVPNの表示が出ていても、通信経路の最後まで到達して応答を受け取れたとは限りません。
- Shadowrocketの接続を切り、普段直接アクセスできるWebサイトと、ルーターの管理画面などのローカル宛先にそれぞれアクセスします。インターネット側の問題か、LAN側の問題かを切り分けてください。
- 接続を切ってもネットにつながらない場合は、まずWi-Fiのログイン認証、モバイルデータ通信の許可、ルーターや通信事業者との接続を確認します。この段階でルールを変更しても、基本のネットワーク接続は復旧しないことがあります。
- 基本のネットワーク接続が正常になったら接続をオンにし、同じURLでもう一度試します。すべてのサイトで失敗するのか、特定のドメインやアプリだけなのか、ビデオ通話だけなのかを記録してください。
- Wi-Fiとモバイルデータ通信の両方で試します。一方のネットワークだけで失敗する場合は、そのネットワークからサーバーのアドレスやポートに接続できるか、UDP通信が可能かを優先して確認してください。
2. サーバーの状態を確認する：遅延が測定できてもWebサイトが開くとは限らない
Homeでテストするサーバーが実際に選択されていることを確認し、Connectivity Test（接続テスト）で結果を確認します。テストに応答があっても、その時点でテスト対象の通信経路から応答があったことしか分かりません。すべての宛先、DNSクエリ、UDP通信が正常とは限らないため、遅延の数値だけで判断せず、サーバーの設定も確認してください。
- アドレスとポート：サービス提供元から案内された情報と照らし合わせ、サーバーのホスト名とポートを確認します。ポートにはリモートサービスが実際に待ち受けている値を指定してください。ローカルプロキシの待ち受けポートと混同しないようにします。
- プロトコルと認証情報：Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは必要な項目が異なります。元のプロトコルを維持し、パスワード、UUID、鍵などの認証情報を確認してください。接続を試すためだけにプロトコルを変更しないでください。
- TLSの設定：元の設定を参照し、サーバー名、証明書、端末の日時を確認します。サーバーのアドレスに到達できても、TLSの検証に成功するとは限りません。証明書検証を無効にして問題を隠さないでください。
- サービスの状態：アカウントが有効で利用可能な残量があり、リモートサービスが正常に動作していることを確認します。利用中のサブスクリプションが更新された場合は、更新が完了したことを確認してからサーバーを選び直してください。古い項目のままテストを続けないようにします。
エラー：Connection refused
原因：接続先または経由する機器が接続を明示的に拒否しています。ポートで待ち受けていない場合や、アクセス制御で拒否されている場合によく見られます。
対処：まずリモート側のポートとサービスの状態を確認し、サービス提供元に待ち受け設定とファイアウォール設定を確認してもらいます。拒否応答を受信している場合、DNSを何度変更しても解決しません。
エラー：Connection timed out
原因：制限時間内に接続が完了していません。アドレスに到達できない、パケットが失われる、通信がフィルタリングされる、またはリモート側が応答しないなどの可能性があります。
対処：設定は変えずにネットワークを切り替え、同じサーバーで再テストします。すでに利用できる別の設定があれば結果を比較し、ネットワーク側とサーバー側のどちらに原因があるかを絞り込みます。
エラー：certificate verify failed
原因：TLS証明書の検証に失敗しています。証明書チェーン、サーバー名、端末の日時に問題がある可能性があります。
対処：システムの日付と時刻を自動設定にし、元のTLS設定を確認します。証明書の問題はサーバー管理者に修正してもらってください。
上記は接続ツールや低レベルログに表示されることがある英語のエラー例です。大文字・小文字や接頭辞は異なる場合があります。問い合わせる際は原文を残し、ブラウザー、サブスクリプションの更新、プロキシ接続のどこで発生したエラーかを明確にしてください。それぞれリクエストの経路が異なることがあります。
3. Global Routingを確認する：一時的な比較で振り分けの問題を特定
HomeでGlobal Routingを開き、まず現在の選択内容を記録します。Proxy（プロキシ）、Direct（直接接続）、Config（設定に従う）、Scene（シーン）はそれぞれ異なるルーティング方法であり、接続プロトコルの種類ではありません。サーバーの設定が正しくても、ルートの選択によってリクエストが適切でない出口に送られることがあります。
| モード | 確認する動作 | 結果の見方 |
|---|---|---|
| Proxy | プロキシ経由の通信を主な経路として比較します。 | 同じURLがProxyでは開き、Configでは失敗する場合は、ルールとポリシーの選択を確認します。 |
| Direct | 選択中のプロキシサーバーを出口に使わず、直接接続します。 | 本来プロキシが必要な宛先がこのモードで開かなくても、サーバーの故障とは限りません。 |
| Config | 現在の設定ファイルのルールに従って通信先を決定します。 | 宛先に適用されたルールがDIRECT、プロキシポリシー、拒否のどれかを確認します。 |
| Scene | 設定済みのシーン条件に従ってルーティングします。 | 現在のネットワークでどのシーンが適用されているかを確認します。Sceneを選択しただけで最終的な出口を判断することはできません。 |
- 同じサーバーとテスト用URLを使い、短時間だけProxyに切り替えてリクエストを再実行します。
- 次にConfigに戻し、同じ宛先にもう一度アクセスします。必要に応じてテスト対象のアプリを終了して開き直し、以前の接続が再利用されないようにしてください。
- Configだけで失敗する場合は、現在の設定のルール順とポリシーを確認します。どちらでも失敗する場合はサーバーとDNSの確認を続け、すぐにルールの誤りと決めつけないでください。
Proxyで利用できることは原因を絞り込む手がかりであり、長期的な解決策として常に使うべき設定ではありません。テスト後は元のモードに戻してください。LAN内の機器にアクセスする必要がある場合は、ローカルアドレスの実際の通信経路も確認します。
4. DNSを確認する：名前解決の失敗と接続の失敗を切り分ける
DNS（ドメインネームシステム）は、ドメイン名をIPアドレスに変換します。名前解決に失敗するとブラウザーでWebサイトが開かないことがありますが、原因がリモートプロキシとは限りません。まずSettings → DNSを確認し、次にConfigの有効な設定ファイルにあるDNS項目を調べます。実際に適用されている設定と、設定の上書き関係を確認してください。有効になっていない設定ファイルだけを変更しないようにします。
これらはプロトコルでよく使われるポートであり、サーバーのポートをこの番号に変更するという意味ではありません。暗号化DNSを使う場合、上流の名前解決サービスにも現在のネットワーク経路から接続できる必要があります。プロキシ接続にサーバーのドメイン名の解決が必要なのに、DNSサービスが確立前のプロキシに依存していると、起動時の依存関係の問題が発生することがあります。
- まず現在の値を保存：DNSの上流アドレス、名前解決に関するオプション、有効な設定ファイルを記録し、変更を試した後でも元に戻せるようにします。
- 一項目ずつ比較：一時的に以前利用できていたDNS設定に戻すか、現在のネットワークから実際に接続できる名前解決サービスを使います。DNSサービス、ルール、サーバーを一度に変更しないでください。
- アプリのキャッシュを考慮：変更後は再接続し、テスト対象のアプリを終了して開き直します。ブラウザーのセキュアDNS、システムの暗号化DNSプロファイル、アプリのキャッシュが結果に影響することがあります。
- IPv6を確認：ドメイン名からIPv6アドレスが返されても、現在の出口に利用可能なIPv6経路がない場合があります。名前解決とルーティングの設定が一致しているかを確認し、デュアルスタック環境の問題をすべてサーバー停止と判断しないでください。
5. ルールの順序を確認する：適用されたルールと最終的な出口を特定
Global RoutingがConfigの場合に限り、現在の設定ファイルのルールを重点的に確認します。まずConfigで有効なファイルを確認し、失敗する宛先のリクエスト記録から、ドメイン、宛先アドレス、適用ルール、実際の出力ポリシーを記録してください。記録にドメインがない場合、共有IPだけを根拠にサイトを特定しないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY上記はルールの適用順を示す例であり、そのまま読み込める完全な設定ではありません。example.comは例示用のドメインです。PROXYは実際に利用できるポリシー名または組み込みポリシーに合わせる必要があります。192.168.0.0/16が対象とするのはプライベートアドレス範囲の一つであり、LAN内のすべての範囲を表すものではありません。
DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。先に適用される可能性のある広範なルールより前に、対象を絞ったルールを配置します。IP-CIDRは宛先IPアドレスの範囲で照合します。例のno-resolveは、このIPルールのためにドメイン名の解決を積極的に行わないという意味であり、DNSを全体的に無効にするものではありません。GEOIPはIPアドレスの地理情報データに基づいて照合します。ドメインのコンテンツを分類する機能ではなく、特定サイトへのすべての接続が同じ経路になるとは限りません。FINALは、それ以前のルールに一致しなかった場合の最終的な振り分け先です。最後に配置してください。先にある広範なルールがすでに一致している場合、FINALを変更してもそのリクエストの経路は変わりません。
トップページは開くのにログイン、画像、動画が失敗する場合は、それぞれのリクエストを確認してください。一つのページから複数のドメインへアクセスすることがあり、メインドメインのルールが正しくても、ほかのリソースに同じポリシーが適用されるとは限りません。根拠のある宛先だけを修正し、ポリシーグループで有効な選択肢が選ばれているかを確認します。すべてのルールを同じ出口に変更するのは避けてください。
6. よくある症状から原因を絞り込む
接続をオンにしてVPNの表示もあるのに、なぜまったく通信できない？
接続を切って基本のネットワークが正常かを確認し、Homeに戻って選択中のサーバーを確認します。同じURLでProxyとConfigを比較してください。どちらも失敗する場合は、システムのVPN表示だけで判断せず、サービスの状態、認証情報、DNSを確認します。
Webサイトは開くのに、音声通話やゲームに接続できない？
失敗するアプリがUDPを必要とするか、現在のプロトコル設定、サーバー側、接続中のネットワークで該当する通信が許可されているかを確認します。TCPを使うWebサイトが開いても、UDPが正常とは限りません。サーバーは変更せず、Wi-Fiとモバイルデータ通信を切り替えて比較し、該当するリクエスト記録も確認してください。
サブスクリプションの更新は成功したのに、接続がタイムアウトするのはなぜ？
サブスクリプションの更新が成功したということは、設定のURLに接続して内容を取得できたという意味であり、登録されたサーバーすべてが利用できるとは限りません。Homeに戻り、選択中の項目を確認してから、サービス提供元が案内する状態を確認してください。サブスクリプションのURLを個別サーバーのアドレス欄に入力しないでください。
画面をロックした後やWi-Fiを切り替えた後に使えなくなる？
ネットワークを切り替えたタイミングと障害の発生時刻を記録し、Settings → On Demandの条件と、Global RoutingでSceneを使っているかを確認します。一時的にネットワークを固定し、ルーティング方法を明示して再テストしてから、自動接続の条件を一つずつ戻してください。
一つのアプリだけ使えない場合、Shadowrocketを再インストールする必要はある？
まずブラウザーと対象アプリで同じサービスにアクセスした結果を比較し、アプリのネットワーク権限、個別のDNS設定、リクエスト記録を確認します。他のアプリが正常なら、まず対象アプリに関係する経路を調べてください。再インストールすると原因を調べる手がかりが失われるため、切り分けの代わりにはなりません。
7. 設定を元に戻し、再現できる形で状況をまとめる
原因を特定したら、原因に関係のない試験用設定を元に戻します。必要なOn Demandの条件とルーティング方法を復元し、効果を確認できた変更だけを残してください。その後、再接続して普段使うネットワークでWebサイト、ログイン、UDPを必要とするアプリをテストし、ほかの通信に影響がないことを確認します。
- OSの種類、ネットワークの種類、障害が起きた時刻、ネットワークの切り替えがあったかを記録します。バージョン情報はアプリの実際の画面で確認し、記憶で記入しないでください。
- 「接続を切るとアクセスできる。接続をオンにするとConfigで失敗する。同じサーバーでもProxyならアクセスできる」のように、再現手順を記載してください。各手順で接続を張り直したかどうかも明記します。
- 必要に応じて英語のエラー、適用されたルール、出力ポリシーを添えてください。送信前にサブスクリプションのトークン、パスワード、UUID、秘密鍵、個人のネットワーク情報を隠します。
- サーバーが利用できない、またはアカウントの状態に問題がある場合は、サービス提供元にお問い合わせください。設定の確認方法は、こちらの使い方マニュアルとよくある質問もご覧ください。
この記事は、サービス提供元とサブスクリプションをすでに利用している方を対象としています。当サイトではクライアントの設定とトラブル対処のみを解説します。クライアントの購入と接続サービスは別のものです。クライアントの買い切り購入に接続サービスのプランは含まれません。