Shadowrocketのトラブル対処ガイド｜Shadowrocket 公式サイト・ガイド

01 · システム接続

接続スイッチが入らない、またはすぐ切れる

まずシステムでトンネルが確立されているか確認し、その後トンネル内で使用するサーバーを調べます。

「起動できない」と「起動後に通信できない」を切り分ける

Homeの接続スイッチをオンにし、オンの状態が続くか、システムにVPN接続中と表示されるか確認します。スイッチがすぐオフに戻る場合は、システムの許可、トンネルの起動、設定の読み込み段階で問題が起きている可能性があります。スイッチがオンのままでもWebページを開けない場合は、次の章を確認してください。サーバーのテスト失敗は、システムがトンネルを確立できないことを意味するとは限りません。反対に、システムに接続中と表示されても、接続先サーバーが利用できるとは限りません。正確な症状を記録し、権限の問題をサブスクリプションの更新で解決しようとしないでください。

初回接続時、iPhone / iPadではVPN構成の追加を許可するよう求められます。自分でShadowrocketを起動した直後に表示された確認画面であることを確かめ、システムの案内に従って許可とデバイス認証を完了してください。以前に確認画面をキャンセルした場合は、アプリに戻って再接続します。画面が表示されない場合は、システムのSettingsでVPN構成が存在するか、デバイスに管理上の制限がないかを確認してください。システム要件はApp Storeの製品ページに記載された内容を確認してください。デバイスの外観や機種名だけで互換性を判断することはできません。

構成の競合と自動接続を確認する

ほかのVPN接続や、同種のネットワーク拡張を使用する可能性のあるフィルタリング機能を一時的に停止し、Shadowrocketだけを起動します。これは特定の機能に問題があると決めつけるためではなく、システムの通信経路を制御するコンポーネントを減らすためです。学校や職場の管理対象デバイスでは、管理プロファイルを自分で削除しないでください。個人用VPNの利用が管理ポリシーで許可されているか確認します。変更できないシステム制限は管理者に相談してください。サーバーの設定を変更しても、制限を回避することはできません。

手動で切断しても自動的に再接続する場合は、スイッチの故障と考える前にOn Demandを確認してください。ネットワークの切り替え時やアプリから通信が始まったときに、オンデマンド接続の条件が再度実行される場合があります。テスト前に元の条件を記録し、自動接続を一時停止してから手動で一度だけ接続します。切断後もVPN接続中と表示される場合は、システムでどの構成が使われているか確認してください。同じステータスアイコンでも、Shadowrocketが接続を確立したとは限りません。

最小限の設定で起動失敗の箇所を特定する

現在のConfigを複製し、構成がシンプルで入手元が明確な、以前に使えた設定と比較します。特定のConfigだけですぐ切断される場合は、最近追加したルール、スクリプトの参照、不完全な設定内容を重点的に確認してください。どのConfigでも起動できない場合は、システムの権限と拡張機能の状態を優先して確認します。ConfigまたはSERVERは一度に一項目だけ変更してください。複数を同時に変えると、復旧しても解決につながった操作が分かりません。リモート設定の更新とシステムの再起動を同時に行わないでください。

アプリが応答しない場合は、まずアプリを終了して開き直し、もう一度試してください。それでも変化がなければ、デバイスを再起動して一時的なシステム拡張の不具合を切り分けます。スイッチを短時間に何度も切り替えないでください。起動と停止には時間がかかるため、繰り返し操作すると状態を判断しにくくなります。システムに具体的なエラーが表示された場合は、メッセージの全文、発生したタイミング、再現手順を記録してください。「接続できない」だけの場合より原因の特定に役立ちます。

接続が戻ったら結果を記録する

再認証または設定の復元後は、On Demandをオフにしたまま、手動で接続と切断を一度ずつ行い、以前に開けなかったページへアクセスします。手動接続が安定してから、自動接続の条件を一つずつ戻してください。スイッチが正常でも、その後にアクセス失敗、タイムアウト、名前解決エラーが起きる場合は、次の段階に進んでいます。VPN構成の削除を繰り返さず、該当する章を確認してください。起動できるConfigや、一時停止したシステム機能による変化を記録しておけば、元の環境に戻す際に役立ちます。

02 · リクエスト経路

接続後にインターネットを利用できない

切断時のネットワークが正常か確認してから、Global Routingの3つの状態を比較します。

まず通常のネットワークが使えることを確認する

Shadowrocketを切断し、現在のWi-Fiまたはモバイル通信で通常どおりアクセスできるか確認します。公衆Wi-Fiでは、認証ページを開く、利用規約に同意する、再ログインするといった操作が必要な場合があります。認証が済んでいないと、サーバー設定が正しくても接続できないことがあります。ネットワークの認証を完了してからアプリを起動してください。切断中もアクセスできない場合は、ルーター、電波状況、通信制限、システムのネットワーク状態を先に確認し、ルールファイルから変更しないでください。

通常のネットワークに問題がなければ再接続し、確実に使えるテストページを一つだけ開きます。すべてのアプリで失敗するのか、ブラウザー、特定のアプリ、特定のドメインだけなのかを記録してください。特定のアプリだけに問題がある場合は、モバイルデータ通信の権限、アプリ内のネットワーク設定、キャッシュを確認します。すべてのリクエストに影響する場合は、SERVER、Global Routing、Configを調べます。キャッシュ済みのページを成功の証拠にしないでください。再読み込みするか、新しいWebページを開くほうが適切に比較できます。

3つの状態で問題の範囲を切り分ける

画面上の状態	リクエストの処理方法	確認するポイント
Config	現在の設定ルールに従って経路を選択する。	ルールの一致状況とポリシーの参照を確認する。
Proxy	主なリクエストを選択中のプロキシ経由で処理する。	ルールによる影響を一時的に減らす。
Direct	主なリクエストを直接接続する。	現在の通常のネットワーク経路と比較する。

Proxyではアクセスでき、Configではできない場合、少なくとも一つのプロキシ経路が利用できるため、Config内のルール順、ポリシー名、最終的なフォールバックを重点的に確認します。Directでは正常でProxyでは失敗する場合は、選択中のサーバーとリモート接続を先に確認し、すぐにDNSを変更しないでください。この3つの状態は問題を切り分けるための手段であり、特殊な構成すべてに対応するわけではありません。ローカルネットワークのアドレス、DNSリクエスト、システム通信には、ほかの設定が影響することもあります。テスト後は普段必要な状態に戻してください。

ルールが正しいポリシーに割り当てられているか確認する

Configを開き、ファイルがリストにダウンロードされているだけでなく、想定したファイルが実際に有効になっているか確認します。通常、ルールは上から順に照合されます。前の広範なルールが一致すると、後ろの詳細なルールが適用されない場合があります。以下の例は順序を説明するためのもので、あらゆるネットワークで使える完全な設定ではありません。PROXYが現在のConfigで利用できるポリシーを参照していることを確認します。独自のポリシー名を使用しているファイルでは、その名前が存在し、綴りが一致しているか確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

特定のドメインだけに問題がある場合は、そのリクエストに一致したルールと、最終的に選択されたポリシーを確認します。REJECTに一致したリクエストは設定に従って拒否されます。それだけでサーバーの故障とは判断できません。変更する場合は、すべてのルールを削除するのではなく、対象範囲が明確なテストルールを追加してください。検証後に元のルールを調整するか判断します。照合順序については、プロキシモードのルール解説を参照し、一時的なテスト設定を残さないようにしてください。

再現できる比較で確認を終える

ProxyとConfigの両方で失敗する場合は、自分がすでに利用していて設定が有効だと確認できているサーバーに変更し、さらに別のネットワークでもテストします。一つのネットワークだけで失敗する場合は、ネットワークの認証、UDPへの到達性、ローカルの制限を確認してください。同じサーバーが複数のネットワークで失敗する場合は、サーバーのタイムアウトの章に進みます。ドメインだけにアクセスできない場合は、DNSの章を確認してください。原因が分かったら、関係のない設定を元に戻します。複数のテストで使った一時的な設定を重ねて、新たな問題を作らないようにしてください。

03 · リモート接続

サーバーのタイムアウトとハンドシェイク失敗

通信経路の不通、認証失敗、接続先へのアクセス失敗を切り分け、すべてをタイムアウトと決めつけないでください。

接続先を確認してからテスト結果を判断する

現在有効なサーバー情報をサービス提供元から入手し、アドレス、ポート、プロトコル、認証情報を確認します。サブスクリプションに表示される名称は識別用のラベルであり、サーバーのアドレスではなく、有効性の証明にもなりません。手動入力では、前後の空白、全角記号、コピー漏れに注意してください。Webページの説明文まで一緒に貼り付けないようにします。サブスクリプションのサーバーを使う場合は、更新日時と、選択中のサーバーが同じグループに属しているか確認してください。別の項目を変更している可能性があります。

Connectivity Testの結果は、テスト方法と接続先によって変わります。テスト失敗は、リモート接続の失敗だけでなく、テスト先にアクセスできないことが原因の場合もあります。テスト成功も、その一回のテストが完了したことを示すだけで、継続的なダウンロードやすべてのアプリでの動作を保証しません。Settingsで現在使われているテスト方法を確認し、実際のWebページへのアクセスでも検証してください。異なるテスト方法の数値をそのまま比べたり、一度の結果で回線の長期的な品質を判断したりしないでください。

プロトコルごとに必要な設定項目を確認する

Shadowsocksでは暗号化方式とパスワードがサーバー側の設定と一致しているか確認します。VMess、VLESSでは対応するID情報とトランスポート設定を確認してください。TrojanではパスワードとTLS関連の情報を確認します。Hysteria2はUDP通信を使用するため、現在のネットワークでUDPが安定して通らない場合、TCPのWebページが正常でも動作するとは限りません。WireGuardでは、鍵、アドレス、許可するルートの範囲を確認してください。プロトコル名だけを変更しても解決しません。ほかの項目もサーバー側と一致させる必要があります。

エラーの症状	優先して確認する項目	すぐに判断できないこと
接続タイムアウト	アドレス、ポート、ネットワーク経路、サーバーの稼働状況。	パスワードが間違っているとは限らない。
認証失敗	ID情報、パスワード、サブスクリプションの有効状態。	DNSを変更しても認証の問題は解決しない。
TLSハンドシェイクエラー	システム時刻、SNI、証明書名、トランスポート設定。	証明書の検証をすぐに無効にしない。

TLSエラーを検証のスキップで隠さない

サーバーアドレス、TLSで使用する名前、トランスポート層のHostは、それぞれ異なる場合があります。サービス提供元の情報に従って入力し、表示名から推測しないでください。システムの日付や時刻が大きくずれていると、証明書の有効期間を正しく判定できないことがあります。まずシステムの自動設定を有効にし、タイムゾーンを確認してください。証明書名が一致しない場合は、SNIとサーバー証明書を確認します。検証のスキップを通常の解決方法にしないでください。接続の信頼境界を変えても、根本の設定ミスが直るとは限りません。

同じサーバーがWi-Fiではタイムアウトし、モバイル通信では正常な場合は、SERVERとConfigを変えずにネットワークだけ切り替えて、再現するか確認します。UDPに依存するプロトコルなら、自分がすでに利用している別のトランスポート方式と比較できます。ただし、ポートを無作為に変更したり、サーバー側で設定されていないプロトコルに切り替えたりしないでください。クライアントとサーバーの設定は対応している必要があります。片側だけを変更しても、サーバーで許可されていない機能は使えるようになりません。

サービス提供元に確認してもらう情報を整理する

複数のネットワークで失敗する場合は、プロトコル、問題が発生した時間帯、エラーの種類、実施した比較テストの結果をサービス提供元に伝え、サーバーの状態とアカウント権限を確認してもらいます。サブスクリプションURL全体、パスワード、秘密鍵、ID情報を公開しないでください。サーバーを説明する必要がある場合は、表示名または一部を伏せたアドレスを伝えます。完全な情報は、必要性とサポート窓口の信頼性を確認してから送ってください。当サイトではクライアントの使用方法を案内しています。サーバー側の調査や、タイムアウト時の代替サービスの推奨は行っていません。

修正後は同じ接続先にもう一度アクセスし、テストボタンが正常になっただけではないことを確認してください。ハンドシェイクに成功してもページの表示が遅い場合は、速度の章を確認します。リモートのドメインを名前解決できない場合は、DNSの章を先に読んでください。有効だった設定の入手元と変更内容を記録しておけば、次回のサブスクリプション更新で手動変更が上書きされた際に、サーバー側の設定変更かローカルの修正の巻き戻りかを判断できます。

04 · インポートと更新

サブスクリプションの更新失敗、またはリストが空

ダウンロード失敗、内容の解析失敗、更新後にサーバーが使えない状態を分けて確認します。

リンクの種類と入力場所を確認する

サブスクリプションURLはサービス提供元から入手してください。クライアント用のサブスクリプションURLを使い、アカウントのログインページ、注文ページ、ブラウザーに保存した管理ページを入力しないでください。ガイドのインポート手順に従って既存のサブスクリプションを追加し、入力欄とリンクの内容を確認します。コピー時の改行、空白、途中での切り取りに注意してください。特殊文字を含むURLのパラメーターを手作業で削除しないでください。QRコードにはサブスクリプションではなく単一のサーバー情報が含まれる場合もあります。外観だけで種類を判断せず、インポートした内容を確認してください。

サブスクリプションURLにはアクセス認証情報が含まれることが多いため、パスワードと同様に管理してください。公開コメント、スクリーンショット、不明なオンライン変換サイトに貼り付けたり、トラブルの説明にURL全体を載せたりしないでください。構造を示す場合はドメインとパスの形式だけを残し、クエリパラメーターの機密情報を隠します。URLを公開してしまった場合は、サービス提供元に連絡して認証情報を再発行してください。ローカルの履歴を削除しても、すでに漏えいしたアクセス権を取り消すことはできません。

ダウンロードエラーと解析エラーを切り分ける

更新時に接続失敗、ドメイン名の解決失敗、タイムアウトが表示される場合、クライアントはまだ想定した内容を取得できていません。通常のネットワーク、DNS、サブスクリプションサーバーへの到達性を確認してください。応答を取得できるのにインポートできない場合は、返された内容がクライアント対応のサブスクリプション形式か確認します。アカウントの期限切れ、Web認証ページ、アクセス拒否のページもテキストとして返されることがありますが、サーバーリストではありません。何度更新しても有効な設定にはなりません。

HTTPステータスは、応答内容とあわせて判断してください。権限に関するエラーではリンクやアカウントの状態を確認します。リクエストが多すぎる場合は連続更新をやめ、しばらく待ってから再試行してください。サーバーエラーはサーバー側の復旧が必要です。あらゆるエラーを「形式に対応していない」と一括りにしないでください。サービス提供元が複数のクライアント向けのサブスクリプションを用意している場合は、Shadowrocket用と明記されたものを選びます。名前が似ているだけで別形式を使ったり、URLのパラメーターを勝手に書き換えたりしないでください。

古いリストを残してから一度だけ更新する

更新前に、古いリストがまだ使えるか記録し、必要であれば手動で追加したサーバーをバックアップします。新しい内容を取得できなくても、保存済みのサーバーが同時に使えなくなったとは限りません。反対に、更新に成功してもすべてのサーバーが接続できるとは限りません。手動更新を一度行い、サーバー数、グループ、名称が想定どおり変化したか確認してから、項目を一つ選んで接続を検証します。連続タップでテストしないでください。サービス側の頻度制限が作動し、判断できる問題が複雑になる場合があります。

更新後にリストが空になった場合は、アカウントが有効か、サーバーから空の内容が返されていないか、フィルターで項目が非表示になっていないかを確認します。一部の項目だけが消えた場合、サービス側の内容変更やインポート時の解析失敗が考えられます。応答の種類とエラーメッセージをサービス提供元に確認してもらってください。古いリストや比較に必要な情報も失われるため、最初にサブスクリプショングループ全体を削除しないでください。手動で変更したサーバーは次回の更新で上書きされることがあります。サブスクリプションの項目か、ローカルの項目かを事前に確認してください。

自動更新を戻す前に経路を確認する

サービス提供元のサブスクリプションページに特定のネットワーク経路からしかアクセスできない場合は、利用可能な既存の接続を使って一度更新し、そのときのGlobal Routingを記録します。利用できるサーバーがない状態で、唯一のサブスクリプション更新経路まで使えないプロキシに通さないでください。Configによってサブスクリプションリクエストの経路が変わることがあります。すべてのリクエストが必ず直接接続する、または必ずプロキシを通ると決めつけず、ログと結果を確認してください。

手動更新が安定してから、起動時の自動更新設定と実行タイミングを確認します。自動更新だけが失敗する場合は、手動更新が成功した環境との違いを記録してください。たとえば、ネットワーク接続前、認証ページの未完了、アプリがバックグラウンドから復帰した直後などです。詳しい手順はShadowrocketのサブスクリプション更新方法をご覧ください。最終確認では、リストの取得、内容の解析、サーバーへの実際の接続の3段階をすべて確認します。

05 · パフォーマンスと通信

通信速度が遅い、断続的に止まる

待ち時間、転送速度、接続の安定性を分けて測定し、一つの遅延値だけで使用感のすべてを判断しないでください。

「遅い」を再現できる症状として記録する

ページの表示開始が遅い、表示後のダウンロードが遅い、動画が何度もバッファリングする、通信が時々完全に止まる、といった症状はそれぞれ異なります。最初の応答までの待ち時間には名前解決、ハンドシェイク、接続先サーバーが関係する場合があります。継続的な転送速度には回線帯域、パケットロス、デバイスの状態も影響します。対象を一つ、操作を一つ、観察する時間帯を決めて比較してください。異なるWebサイト、ファイルサイズ、時間帯の結果をまとめて、サーバーが急に速くなった、または遅くなったと結論づけないでください。

テスト前に、システムアップデート、クラウド同期、大容量通信を一時停止し、デバイスが明らかに過熱していないことを確認します。そのうえで同じ接続先をテストしてください。速度測定自体も帯域を使用するため、複数のテストを同時に実行しないでください。特定のアプリだけに問題がある場合は、アプリのコンテンツサーバー、キャッシュ、バックグラウンドダウンロードを確認します。ほかのアプリが正常なら、クライアントがボトルネックとは限りません。テスト記録にはGlobal RoutingとSERVERも記載し、直接接続した対象をプロキシ性能の証拠と取り違えないようにしてください。

ローカルネットワーク、リモート回線、プロトコルの順に比較する

サーバーと設定を変えずに、Wi-Fiとモバイル通信でそれぞれテストします。Wi-Fiだけ遅い場合は、アクセスポイントに近づき、ルーターの負荷や周波数帯の干渉を確認し、同じネットワークで通常のアクセス速度と比較します。モバイル通信だけ遅い場合は、電波状況、通信制限、移動中かどうかを確認してください。クライアントを切断しても同じように遅い場合は、通常のネットワークを先に調べます。プロキシで失われたローカル回線の容量を補ったり、混雑した接続を安定させたりすることはできません。

通常のネットワークが安定したら、自分がすでに利用している別のサーバーと比較します。一つの接続先だけが遅い場合は、そのサーバーの負荷、出口経路、接続先との通信が関係している可能性があります。すべての接続先で特定のWebサイトだけ遅い場合は、接続先サービス自体も確認対象に含めます。サーバー名に含まれる地域表示は実際の経路を示すものではなく、地理的に近いから速いとも限りません。まず差を記録し、名称だけで品質を判断せずにサービス提供元へ回線状況を確認してください。

遅延、パケットロス、スループットの違いを理解する

低遅延は操作への応答性に役立ちますが、ダウンロード速度の高さを直接示すものではありません。パケットロスがあると再送が発生し、通信の揺らぎはリアルタイム通信や動画のバッファリングに影響します。短時間のテスト一回では、こうした問題を検出できない場合があります。リストの数値だけを見るより、普段の作業を繰り返して確認するほうが確実です。ダウンロード中にサーバーを何度も切り替えないでください。既存の通信が終わらず、新旧のリクエストが混在すると、どの経路の結果か分からなくなります。

Hysteria2はQUIC関連の通信方式を使用するため、ネットワーク条件によってTCP経路とは異なる動作をする場合があります。ただし、現在のネットワークでUDPを安定して通せることが前提です。プロトコル名だけで速度が保証されるわけではなく、遅さの原因をすべて暗号化に求めることもできません。通信パラメーターを変更する場合は、サーバー側の指定とクライアントの対応状況を確認し、元の値を保存してから一項目ずつ検証します。プロトコルの基本はHysteria2のプロトコル解説をご覧ください。現在のサーバーに適用できない設定をコピーしないでください。

原因を特定した箇所の設定だけを変更する

MTUが適切でない場合、小さなリクエストは成功しても大きな転送が止まることがあります。ただし、あらゆる通信停止の原因がMTUとは限りません。症状が安定して再現し、ほかの層を除外できてから、サーバーやネットワーク環境の指定に従って小さく変更し、元の値を記録してください。MTUをむやみに小さくすると余分な通信が増えます。DNS、MTU、プロトコルを同時に変更すると、改善しても原因が分かりません。モバイルネットワークで時々発生する揺らぎは、一度の変更より複数の時間帯の結果を記録するほうが有用です。

最後に実際の利用で確認します。同じページを安定して開けるか、同じコンテンツを継続して転送できるか、ネットワークを切り替えたあと復旧するかをテストしてください。一時的に速くなっただけでは根本原因が解決したとは限りません。少なくとも以前失敗した状況を再テストします。段階的な記録方法はShadowrocketの速度低下を段階別に調べる方法をご覧ください。主な待ち時間がドメインの名前解決で発生している場合は、すべてのサーバーを変更する前に次の章を確認してください。

06 · 名前解決

DNSの失敗とドメインの問題

接続先ドメイン、サーバーのドメイン、暗号化DNSの接続先、それぞれの名前解決経路を確認します。

どのドメインで失敗しているか確認する

DNSはドメイン名を接続先のアドレスに変換します。名前解決が必要なのは、アクセス先のWebサイト、プロキシサーバー自体、またはDNS over HTTPSの接続先ドメインの場合があります。サーバーのドメインを解決できないと、プロキシ接続はまだ確立されていません。接続先ドメインの解決に失敗した場合は、プロキシ接続がすでに確立されていることもあります。まずエラーログから対象を特定し、通常のネットワークのDNS、現在のConfigのDNS設定、リモート側の名前解決経路のどれを確認するか判断してください。

「ドメイン名では開けないが、IPアドレスなら開ける」という状況は手がかりにはなりますが、それだけでDNSの問題とは断定できません。HTTPSサイトは正しいドメイン名と証明書名も必要とするため、アドレスを直接開くと別のページが表示されたり、証明書エラーになったりする場合があります。該当するリクエストの名前解決エラー、所要時間、応答状態を確認し、同じドメインを通常のネットワークで開いた結果と比較してください。テストのために証明書検証を無効にしたり、一時的に取得したIPアドレスをすべてのアクセスルールに固定で登録したりしないでください。

システムDNS、カスタムDNS、DoHの違い

システムDNSは通常、現在のネットワーク設定に従うため、ローカルネットワークや認証環境に適応しやすい一方、Wi-Fiの切り替えで結果が変わる場合があります。カスタムDNSでは指定したサービスに名前解決を任せるため、現在のネットワークからアクセスできることを確認してください。DNS over HTTPSはHTTPSで名前解決リクエストを送信しますが、接続先まで到達できるネットワーク経路が必要です。有効にしてもリモートプロキシが利用可能になるとは限らず、ローカルネットワーク内のすべての名前を解決できるわけでもありません。

DoHの接続先ドメインを、まだ確立されていないプロキシ経由で解決する必要がある場合、循環依存が起こることがあります。プロキシの接続にはサーバーの名前解決が必要なのに、その名前解決もプロキシ経由で行う設定になっている状態です。調査時は、まず起動時の名前解決ができる経路を確保してから、暗号化DNSを一項目ずつ確認してください。インターネット上で見つけたIPアドレスにサーバーアドレスをむやみに変更しないでください。接続先アドレス、証明書名、SNIの関係がサーバーの指定と合わないと、名前解決エラーがハンドシェイクエラーに変わるだけの場合があります。

ルールと名前解決の関係を確認する

DOMAIN、DOMAIN-SUFFIXはリクエストのドメイン情報に基づきます。IP-CIDR、IP-CIDR6、GEOIPはアドレスに関する条件で判定します。アドレスが必要なルールでは名前解決が発生する場合があるため、ルール順の変更で動作が変わることもあります。以下はルールの例です。アドレス範囲は説明用であり、実際のサービスを示すものではありません。現在のConfigで定義されているポリシーと、実際に一致したルールの記録をあわせて確認してください。この例を完全なDNS設定としてそのまま使わないでください。

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

no-resolveを関連するIPルールで使うと、そのルールとの照合のためにドメイン名を積極的に解決しないことを示します。すべてのDNSを無効にする指定ではありません。ドメイン名で明確に経路を分けたい場合は、対象範囲が分かりやすいドメインルールを優先し、アドレスルールが引き続き必要か確認してください。一度の名前解決失敗を避けるために、すべてのドメインを広範なキーワードルールに割り当てないでください。誤って一致し、ほかの正常なリクエストまで不適切な経路に送られる可能性があります。

キャッシュ、IPv6、ローカルネットワークの名前に注意する

DNSを変更しても、アプリ、システム、クライアントに古い名前解決結果や既存の接続が残っている場合があります。関連する接続を切り、新しいリクエストを送ってからログを確認してください。確立済みのページを再読み込みするだけでは、新しい経路を確認できないことがあります。ドメインがIPv4とIPv6の両方を返す場合、一方の経路だけに到達できず、断続的な失敗になることもあります。失敗したリクエストが実際に使ったアドレスファミリーを確認し、現在のネットワークに合わせて調整してください。IPv6の無効化をすべてのデバイスに適用する定番の最適化にしないでください。

プリンター、ルーターの管理画面、社内ドメインではローカルの名前解決方式が必要な場合があります。パブリックDNSでこうした名前を解決できるとは限りません。ローカルネットワークにアクセスできない場合は、プロキシ設定でローカルのアドレス範囲や名前解決経路が変わっていないか確認してください。DNS設定は一度に一項目だけ戻し、一般的なドメインと内部名の両方が使えることを確認してからテストを終えます。詳しい選び方はShadowrocketのDNS設定ガイドをご覧ください。DNSの選定とトラブル対応は分けて進めましょう。

07 · バックグラウンドとリソース

バッテリー消費の異常とバックグラウンド動作

条件が近い状況で実際の動作を比較し、再接続の繰り返しや大量通信がないか確認します。

まずシステムのバッテリー統計を確認する

システムのバッテリー画面に表示されるのは、選択した期間中の使用割合であり、アプリの固定的な消費電力ではありません。ほかのアプリの使用が少ないと、バックグラウンドのネットワーク機能の割合が、実際の消費量に大きな変化がなくても上がる場合があります。比較する際は、画面の使用状況、電波、充電状態、通信内容をできるだけ近づけ、デバイスが発熱しているかも記録してください。一度の割合だけでアップデートが原因だと判断しないでください。システムの移行直後や写真の同期中も、最終的な判断を避けてください。

プロキシの動作中はほかのアプリのネットワーク通信も処理されるため、システムの使用量の分類がユーザーの直感と異なる場合があります。クラウドバックアップ、動画再生、アプリ更新、インターネット共有など、大量通信が続いていないか確認してから、クライアントのDataと接続記録を確認します。記録とシステム統計では対象時間が異なる場合があり、2つの合計を単純に引き算して異常な通信量を判断することはできません。比較する場合は明確な開始時点を決め、同じ長さの時間で観察してください。

失敗の継続と自動再接続を調べる

リモート接続に到達できない状態でハンドシェイク、名前解決、再接続を繰り返すと、余分なリソースを消費します。ログに同じエラーが頻繁に記録されている場合は、「省電力プロトコル」を探して失敗を隠すのではなく、サーバー、DNS、認証の問題を解決してください。電波が弱い環境では無線通信の消費も増える場合があります。同じ設定のまま、電波が安定したWi-Fiで比較してください。特定のサーバーだけで再接続が続く場合は、エラーを記録してから、すでに利用していて有効な別のサーバーで確認します。

On Demandの接続条件が現在のネットワークと繰り返し衝突していないか確認します。複数のアクセスポイント間を頻繁に移動したり、認証状態が変化し続けたりすると、接続と切断を繰り返す場合があります。テスト前に元の条件を記録し、自動接続を一時停止して手動接続をしばらく観察してください。その後、一つずつ条件を戻し、繰り返し動作の原因を特定します。自動動作を確認せずにアプリを何度も強制終了しないでください。原因の説明にならず、次回の接続時に最初から処理をやり直すことにもなります。

診断機能と普段の設定を分ける

トラブルシューティングで有効にした詳細ログ、広範な接続記録、高頻度のテストは、必要がなければ長期間有効にしないでください。特にリクエストが多い場合、処理やストレージの使用量が増えることがあります。確認が終わったら、普段の使用に適した記録レベルに戻し、一時的に追加した定期テストを停止して、必要な結果だけを伏せ字で保存してください。すべての機能をまとめて無効にして省電力になったと結論づけないでください。何の機能を停止したか、その前後で症状を安定して再現できるかを記録します。

サブスクリプションの頻繁な更新でも、ネットワークリクエストが増える場合があります。変更が必要かどうかは、実際の実行頻度を確認して判断してください。アプリを開くたびに更新されるのか、失敗後に繰り返し再試行するのかを確認し、必要に応じて無駄な更新を減らします。リモートConfigの定期更新とサブスクリプション更新は別の処理なので、それぞれ確認してください。内容を把握していないスクリプトや追加処理がConfigに含まれる場合は、バックアップを取り、シンプルな設定と比較してから残すか決めます。不明な処理をバックグラウンドで使い続けないでください。

比較できる観察時間を設定する

ネットワークと日常の作業が近い状態で、現在の設定と簡易設定をそれぞれ観察します。画面の明るさ、テザリングの状態、ダウンロード内容をそろえ、動画を見ながらの状態と何もしていない状態を比べないでください。まず短時間の比較を行い、継続的なエラーがないことを確認してから、代表的な日常利用の時間帯まで観察を延ばします。デバイスが明らかに発熱したり、通常のネットワーク異常とともにバッテリーが減ったりする場合は、Shadowrocketだけでなく、システムのほかのバックグラウンド処理も確認してください。

復旧後はネットワークの切り替え、画面ロックからの復帰、On Demandが想定どおり動作するかを確認します。前面表示中に安定しているだけでは、バックグラウンドも正常とは限りません。問題を報告する場合は、バッテリー統計の対象時間、当時のネットワーク、通信が続いていたか、繰り返されたエラーの種類を伝え、サブスクリプションとサーバーの認証情報は伏せてください。アプリを停止しても発熱やバッテリー消費が続く場合は、システムやハードウェアの状態を確認し、別の問題をプロキシ接続のせいにしないようにしてください。

08 · 変更と復元

アップデート後の不具合と設定の復元

同時期に起きた変更を洗い出し、アプリ、システム、サブスクリプション、Configを一つずつ検証します。

発生時期が近いだけで原因と決めつけない

アプリのアップデート後に初回の接続が失敗した場合、システムのアップグレード、サブスクリプションの期限切れ、サーバー設定の変更、リモートConfigの更新も同時に起きている可能性があります。最近変更した項目を洗い出し、アップデート前に最後に正常だった環境を記録してください。「アップデート直後」という理由だけで設定を削除しないでください。同じ時期のサーバー側の変更でも同じ症状が起きることがあります。現在の設定のまま別のネットワークで再テストし、続いて簡単な設定で確認すると、アプリの起動問題とリモート接続の問題を切り分けやすくなります。

現在有効なConfigとSERVERが想定どおりか確認し、Global Routingが変更されていないか、On Demandが再度動作していないかを調べます。アプリは開くのにアクセスできない場合は、前述のリクエスト経路を確認してください。アプリが開かない、システム拡張のエラーが出る、クラッシュが続く場合は、取得可能な診断情報を保存してからシステム側の復旧を進めます。エラーを記録せずに何度も再インストールすると、原因調査に役立つ情報や手動設定を失う可能性があります。

バックアップするのはサブスクリプションURLだけではない

サブスクリプションからサーバー側の項目を再取得できても、ローカルに手動追加したサーバー、ポリシーの選択、ルールの変更、その他の個人設定が含まれるとは限りません。バックアップの対象範囲を確認し、自分が保持する権利のある元データとConfigのコピーを保存してください。バックアップにはパスワード、ID情報、サブスクリプションの認証情報が含まれる場合があります。安全な場所に保管し、公開スペースにアップロードしないでください。サーバー名の一覧をスクリーンショットで残すだけでは、完全な設定を復元できないことがほとんどです。

復元時は、まず基本となるサーバーまたはサブスクリプションを一つだけインポートし、接続を確認してからConfigと追加設定を戻します。バックアップ全体を一度に復元すると、問題の原因となった古い設定まで戻る可能性があります。特定の設定を戻した直後に問題が再発した場合は、その設定の前後の差を記録して調べてください。原因が分からないまま残りの設定を続けてインポートし、発生箇所を分からなくしないでください。内容を判断できないリモート設定の変更は、提供元に確認し、理解していない項目を削除しないでください。

プラットフォームに応じて安全にアップデートする

iPhone / iPadではApp Storeの製品ページでアプリを確認してください。開発者はShadow Launch Technology Limited、アプリIDは932747118です。システム要件はApp Storeの製品ページに記載された内容を確認してください。Mac、Windows、Android、Linux版のShadowrocketインストーラーは当サイトの全プラットフォーム向けダウンロードページから入手できます。インストーラーは当サイトの/dl/shadowrocket/パスにあります。不明な通知からリンク先に移動してアップデートしないでください。

インストール時にシステムにブロックされた場合は、ファイルが当サイトから入手したもので、デバイスのアーキテクチャに合っているか確認します。Macでは「このMacについて」でAppleシリコンかIntelかを確認して選択してください。開発元を検証できないという警告が表示された場合は、システムの「プライバシーとセキュリティ」で「このまま開く」を確認します。WindowsのSmartScreenでは、入手元を確認してから「詳細情報」と「実行」を選択できます。Androidではシステムの案内に従って現在のインストール元からのアプリインストールを許可し、完了後に権限を取り消せます。組織が管理するデバイスでは管理者のポリシーに従ってください。

Linuxではシステムに合ったdeb、rpm、AppImageを選びます。AppImageを実行するには実行権限が必要です。Macでアプリが破損していると表示された場合、入手元を確認し、アプリをApplicationsに移動したうえで、ダウンロードページの案内に従って以下のコマンドで隔離属性を解除できます。この操作は指定したアプリだけに行い、ディレクトリ全体に適用しないでください。各プラットフォームの注意点と手順はインストール時のブロック解除方法をご覧ください。アップデートのためにシステム全体のセキュリティ機能を無効にする必要はありません。

xattr -cr /Applications/Shadowrocket.app

復元後、以前失敗した状況を再確認する

アップデートまたは復元のあと、アプリが開くかだけでなく、接続、サブスクリプションの更新、ルールの照合、ネットワーク切り替えも確認してください。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac、Windows、Android、Linux版は無料です。クライアントの購入費用と利用中の接続サービスは別々に管理されます。アプリを復元してもサービス提供元のアカウント権限が復元されるわけではありません。最小限の設定でも問題を安定して再現できる場合は、システム環境、エラーメッセージ全文、操作順を記録し、アプリ内のサポート窓口から機密情報を伏せて送信してください。

09 · タブレットとネットワーク切り替え

iPadの問題とデバイス間の比較

タブレットの購入履歴、設定データ、ネットワーク環境を個別に確認します。

アプリを入手済みでも設定が自動で表示されるとは限らない

iPhoneとiPadで同じ購入履歴を使う場合は、正しいApp Storeアカウントで購入済みの項目を確認してください。ただし、購入情報と設定データは別のものです。別のデバイスにサブスクリプションがあっても、現在のiPadに同じサーバーやConfigが自動的に設定されるわけではありません。iPadで初めて使う場合は、クイックスタートガイドに従い、インポート、Global Routing、接続の許可をあらためて確認してください。リストが空でも、アプリの不具合や購入未完了とは限りません。

iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac（Appleシリコン・Intel）、Windows、Android、Linux版は無料です。クライアントの買い切り料金と接続サービスのプランは別です。サービス提供元によるアカウント、デバイス台数、同時接続数の制限は、提供元に確認してください。iPhoneで正常に動作しiPadで失敗する場合は、同時接続が許可されているか確認します。クライアントを何度も購入したり、アカウント権限の問題をiPad特有のネットワーク障害と考えたりしないでください。

「同じネットワーク」を具体的な接続方法まで確認する

iPhoneはモバイル通信、iPadはWi-Fiを利用している場合があり、同時にアクセスしているように見えても、実際の外部接続経路は異なります。デバイス間で比較する際は、両方の接続方法、選択中のSERVERとConfigを明確にし、できるだけ同じテスト先を使ってください。これらの条件が近い場合にのみ、結果の違いを分析できます。iPadがiPhoneのテザリングを使う場合、通信はテザリングとiPhoneの接続経路を経由します。iPhone上のアプリ自身の接続経路と同じではありません。

学校、ホテル、オフィスのWi-Fiでは、iPadでも個別の認証が必要な場合があります。プロキシを切断して通常のページを開き、認証が完了していることを確認してから接続してください。ローカルネットワークにはアクセスできるのに外部へ接続できない場合は、ログインが完了していない可能性があります。外部にはアクセスできるのにプリンターや共有デバイスが使えない場合は、ローカルネットワークのルーティングと名前解決を確認します。プリンターの問題を解決するために、すべてのリクエストを恒久的にDirectに変更しないでください。対象範囲が明確なローカルルールを使ってください。

画面ロック、マルチタスク、バックグラウンド復帰を確認する

画面ロック中に新しい通信がないからといって、トンネルが切断されたとは限りません。画面を点灯したら、まずシステムのVPN状態を確認し、新しいリクエストを送って、接続が維持されていたか、自動再接続したか、アプリの復帰が遅いかを切り分けます。マルチタスクやステージマネージャは前面に表示するアプリの構成を変える機能です。Shadowrocketが現在のウィンドウに表示されていないだけで、プロキシが停止したとは判断できません。画面を復帰した後だけ失敗する場合は、Wi-Fiが切り替わったか、On Demandが動作したか、復旧にどの操作が必要だったかを記録します。

モバイル通信対応モデルでは、システムで該当アプリの通信が許可されているか、現在のデータプランが利用できるかも確認します。Wi-Fiモデルでは、無線ネットワークとテザリングの経路を重点的に調べます。システムのバージョン、デバイス管理ポリシー、省電力設定も、デバイスごとの違いに影響する場合があります。別のデバイスのシステム設定をすべてそのままコピーせず、症状に関係する違いを見つけてから一項目ずつ変更してください。システム要件はApp Storeの製品ページに記載された内容を確認し、画面サイズから対応状況を推測しないでください。

比較表で次の対応を判断する

比較結果	優先して確認する項目	次の手順
iPadだけ失敗する	このデバイスの許可、Config、時刻、デバイスの制限。	最小限の設定で再確認する。
2台とも同じWi-Fiでのみ失敗する	ネットワークの認証、ルーター、現在の接続経路。	サーバーは変えずに、接続ネットワークを切り替える。
同じサーバーが複数デバイス・複数ネットワークで失敗する	サーバーの状態と設定の有効性。	サービス提供元に確認する。

設定を移行したあと一部のアプリだけ通信できない場合は、カスタムポリシー、手動ルール、DNS設定の移行漏れを確認してください。QRコードや単一サーバーの共有ではConfig全体を移行できるとは限らず、インポートに成功してもルールが同期されたとは限りません。両方のデバイスで実際に有効になっている項目を一つずつ確認してから結果を比較してください。認証情報を隠したスクリーンショットは画面の識別には役立ちますが、設定の差を確認する代わりにはなりません。機密情報を含む場合、比較のために設定ファイル全体を公開しないでください。

トラブルシューティングを終える前に、一時停止した自動接続条件を戻し、不要になったテストルールを削除して、検証済みの設定と簡潔な記録を残します。記録には失敗する条件、有効だった対処、未解決の範囲を記載し、「再起動で直った」だけで終わらせないでください。引き続き確認する場合は、接続の問題なら本ページの前半、サブスクリプションの問題なら該当する章を参照してください。よくある操作の疑問については、初めて使う方向けのよくある質問をご覧ください。次回同じ症状が起きたとき、すべてのスイッチを試し直さず、残した情報から調査を続けられます。