公式サイト · 公式マニュアル症状から探す

Shadowrocket
トラブルシューティング完全ガイド

ネットワーク、サーバー、設定のどこに問題があるかを切り分けてから、変更は一度に1項目にします。接続スイッチがオンでも、サーバーが利用できるとは限りません。Connectivity Testに結果が表示されても、目的のアプリの通信が成功するとは限りません。

チュートリアルでは、設定の読み込みから初回接続までを順に説明します。このページでは接続に失敗した場合の切り分け方法を確認できます。以下の手順は、利用者が自身のサブスクリプションまたはサーバー情報をすでに持っていることを前提としており、サービスの入手先は扱いません。初回設定がまだ済んでいない場合は、まずチュートリアルに沿って再現可能な接続を確立し、該当する章に戻ってください。

01 / 接続の確立

接続スイッチが入らない

問題がシステム接続の確立前に起きるのか、接続後すぐに切断されるのかを確認します。前者では、システムの許可が完了していない、設定が保存されていない、端末が管理制限を受けている、といった原因が考えられます。後者ではエラー情報や接続記録を確認します。スイッチの問題をすべてサーバー障害と決めつけないでください。リモートサーバーに到達できない場合、リクエストには影響しても、端末側の接続開始を妨げるとは限りません。何度もタップするより、タップ後の挙動を記録するほうが原因の特定に役立ちます。

まずシステムの許可を完了する

iPhoneまたはiPadで初めて有効にするときは、VPN構成の追加を許可するようシステムから求められます。操作中に表示された確認画面であることを確かめ、システムの手順に従って許可し、端末の認証を完了してください。確認画面をキャンセルした場合は、Shadowrocketに戻ってもう一度試します。その後、システム設定のVPN管理画面に該当する構成が追加されているか確認してください。設定メニューの階層はシステムのバージョンによって異なる場合があります。固定のメニュー位置を探さず、設定内でVPNを検索できます。

学校や組織が管理する端末では、ネットワーク構成の追加が管理ポリシーで制限されている場合があります。その場合は端末の管理に関する説明を確認し、該当機能の使用が許可されているか管理者に問い合わせてください。構成を何度も削除しても解決にはなりません。システムの制限、ペアレンタルコントロール、組織の構成は、サーバー設定の問題とは異なります。端末に別のネットワーク接続構成がある場合は、使用中の接続を正しく切断してからShadowrocketを起動し、2つのサービスの状態を混同しないようにしてください。

ローカル設定と競合を確認する

Homeに戻り、選択可能なサーバーが登録されていること、メモだけを追加して必要なパラメーターが抜けていないことを確認します。次にConfigを開き、現在有効なファイルが実際に存在することと、最近ファイルの内容を変更していないかを確認してください。設定の構文エラー、存在しないポリシー名の参照、インポートファイルの不備は、起動時のエラーにつながることがあります。まず変更前のコピーに戻してください。コピーがない場合は元のファイルを残し、内容を絞った設定で検証します。すべてのデータをいきなり消去しないでください。

スイッチが一瞬オンになってからオフになる場合は、まずエラーの原文を確認し、設定の読み込み失敗、システムサービスの起動失敗、外部接続条件による切断のどれに当たるかを判断します。一時的にOn Demandを無効にし、手動で起動して再テストすると、自動接続条件による影響を減らせます。テスト後は元の条件に戻してください。自動接続を有効にしたままシステム構成を削除すると、構成が再び作成され、削除が反映されていないように見えることがあります。

システム接続構成の再作成は、バックアップを取ってから行ってください。まず接続を切り、サブスクリプション、手動サーバー、Configを復元できる状態にします。その後、システム設定からShadowrocketのものと確認できた古い接続構成を削除します。クライアントを開き直し、表示に従って許可してからテストしてください。内容を特定できた項目だけを処理し、組織管理用の情報は削除しないでください。また、ネットワーク設定のリセットを最初に行うのは避けてください。保存済みのネットワーク情報まで削除される可能性があります。

パソコン・Androidで起動できない場合

アプリ自体が開かない問題であれば、接続のトラブルシューティングではなく、インストールと起動の許可に関する説明を確認してください。MacではAppleシリコン版とIntel版のどちらが適合するか確認します。開発元を検証できないという警告が表示された場合は、プライバシーとセキュリティで入手元を確認してから「このまま開く」を選択します。WindowsでSmartScreenが表示された場合は、サイトからダウンロードしたことを確認し、「詳細情報」から「実行」を選択してください。システム全体の保護を無効にしないでください。

Androidのインストール時は、現在使用しているダウンロードアプリに不明なアプリのインストールを許可するよう、システムの案内に従ってください。インストール後は必要に応じて許可を取り消せます。これは接続時のVPN許可とは別の手順です。Linuxでアプリが起動しない場合は、インストール形式、実行権限、デスクトップ環境に関するエラーを確認してください。各プラットフォームのインストーラーはダウンロードページから、サイト内の /dl/shadowrocket/ を通じて提供しています。既存のプログラムを不明なファイルで置き換えないでください。

02 / リクエスト経路

接続後にインターネットへアクセスできない

まず接続を切った状態で基準となるテストを行います。Shadowrocketをオフにし、ブラウザで普段直接アクセスできるページを開いてください。それでも失敗する場合は、Wi-Fiのログイン認証、モバイルデータの利用許可、ルーターとの接続を先に確認します。公衆ネットワークでは認証ページでの確認が必要なことがあり、未完了だと他のリクエストも失敗します。基本のネットワークが使えることを確認してから、Config、Proxy、Directを比較してください。そうしないと、ネットワーク自体の切断をルールの問題と誤認するおそれがあります。

3つのモードで範囲を絞る

同じネットワーク、同じ端末、同じサーバー、同じ接続先を使い、Global Routingの3つのモードを順番に比較します。切り替えるたびにリクエストを新しく実行してください。必要に応じて接続先のアプリを完全に終了してから開き直し、既存の接続を使い回さないようにします。このテストは差を見つけるためのもので、いずれかのモードを常に使うよう勧めるものではありません。接続先がもともと直接アクセスできない場合、Directの失敗だけで基本のネットワークに問題があるとは判断できません。

Global Routing	確認する項目	結果から分かること
Config（設定）	現在のConfigのRuleに従って通信する	このモードだけ失敗する場合は、適用されたルールとポリシーの参照先を確認する
Proxy（プロキシ）	現在選択中のサーバーを経由してリクエストする	失敗する場合はサーバー、プロトコルのパラメーター、リモート接続を確認する
Direct（直接接続）	選択中のプロキシサーバーを経由しない	接続を切った状態の結果と比較し、DNSとシステムネットワークの違いを確認する

ProxyではアクセスできてConfigでは失敗する場合、対象ドメインにRuleのどのルールが適用されているかを確認します。すぐにサーバーを変更しないでください。広い範囲を対象とするDIRECTやREJECTのルールが上にあり、後続のより詳細なルールを上書きしていることがあります。ルールは通常、上から順に照合されるため、例外を広い範囲のルールより前に置きます。変更する前に、現在有効なConfigを確認してください。無効なファイルを編集した結果、ルールの変更が反映されないと思い込むことがあります。

ポリシーと照合順を確認する

以下はルールの照合順を説明する断片であり、完全な設定ファイルでもサーバーを作成するものでもありません。例のドメインは構文の説明用です。実際の接続先と既存の設定に合わせて調整してください。テストのためにファイル全体を置き換えないでください。既存のポリシーグループや必要な設定が失われるおそれがあります。実際に適用されるポリシーは現在の設定構造にも左右されます。ルールを確認するときは、該当するポリシーが存在し、利用可能なサーバーを指していることも確認してください。

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

DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲に一致します。GEOIPはIPアドレスの地域情報に基づいて判定し、FINALはそれまでに一致しなかったリクエストを処理します。それぞれ対象が異なるため、ルール名だけで特定のリクエストが一致すると判断することはできません。アプリはログイン、リソース、コンテンツ配信の各ドメインに同時接続する場合があります。トップページのドメインだけを処理しても、ログインや画像のリクエストまで対応できるとは限りません。失敗したリクエストの接続先を確認してから、ルールの範囲を決めてください。

すべてのモードで失敗する一方、接続を切るとアクセスできる場合は、接続中に使われるDNS、システム側の接続との競合、Configの共通設定を確認します。まず直近の利用可能なコピーに戻し、ネットワークを同時に制御する他のサービスを停止してから再テストしてください。DNS、ルーティング、サーバーを一度に変更すると、復旧しても原因を特定できません。ドメイン解決を個別に確認する方法はDNSの問題の章を参照してください。

全体の問題か、特定アプリだけの問題かを切り分ける

ブラウザは使えるのに特定のアプリだけ失敗する場合は、そのアプリのログイン、メディア、リアルタイム通信のリクエストを個別に確認します。まずアプリが現在のネットワークを利用できるか確認し、完全に終了してから開き直してください。ログインだけ失敗する場合は、端末の時刻、システム証明書のエラー、アカウントの状態を確認します。ローカルネットワーク上の端末だけにアクセスできない場合は、ローカルアドレスが誤ってリモートに送られるルールがないか調べてください。問題を隠すためにConfig全体をDirectに変更しないでください。

修正を確認するときは、接続アイコンを見るだけでなく、最初に失敗した操作を少なくとももう一度実行してください。ウェブページのトップが開いても、画像、ログイン、ファイル転送がすべて復旧したとは限りません。一度成功しただけでは、キャッシュを使った可能性もあります。最終的に有効だった設定変更を記録し、トラブルシューティング中に一時的に加えた無関係な設定は元に戻してください。ルールの種類についてはDOMAIN-SUFFIX、GEOIP、FINALの解説を参照してください。

03 / リモート接続

サーバーがタイムアウトする

タイムアウトは、あるテストが設定された待ち時間内に完了しなかったことを示しますが、どの段階で失敗したかまでは分かりません。DNS解決、サーバーポートへの接続、プロトコルのハンドシェイク、テスト対象へのアクセスのいずれにも時間がかかることがあります。まずエラーがConnectivity Testで発生したのか、実際のアプリのリクエストで発生したのかを記録します。次に、同じサーバーを異なるネットワークで比較してください。タイムアウトの表示だけを見てサブスクリプションをすべて読み込み直すと、有用な比較条件まで失われることがあります。

アドレスとプロトコルの項目を確認する

該当するサーバーの編集画面を開き、利用者がすでに契約しているサービスから提供された元のパラメーターと一つずつ照合します。サーバーアドレスにウェブページのパス、空白、余分なプロトコルの接頭辞が含まれていないこと、ポートがサーバー側の設定と一致していることを確認してください。QRコードや共有リンクには追加項目が含まれることがあり、手入力では抜けが生じやすくなります。メモはローカルの名前にすぎません。同じメモの項目でも接続先が異なる場合があるため、表示名だけでなく実際のパラメーターを比較してください。

プロトコルの種類はサーバー側と一致させる必要があり、テストを通すために適当に入れ替えることはできません。Shadowsocksの暗号化方式とパスワード、VMessやVLESSのID情報、TrojanのパスワードとTLSの条件は、それぞれ役割が異なります。WireGuardには鍵、アドレス、ピアの設定が関係し、Hysteria2では認証とトランスポートの条件を確認する必要があります。項目が不足している場合は、利用中のサービスの管理者に確認してください。他の項目からパラメーターを組み合わせて、見かけだけ整った設定を作らないでください。

項目の種類	確認内容	避けるべき変更
サーバーとポート	アドレスの表記、名前解決の結果、サーバー側で実際に待ち受けているポート	ウェブサイトのアドレスと接続先アドレスを混同する
IDと認証	パスワード、ID情報、鍵に不足がないか	認証パラメーターの代わりにメモをコピーする
TLSとトランスポート	サーバー名、トランスポート方式、パスなどが一致しているか	証明書エラーを無視する、または検証を根拠なく無効にする

ネットワークを変えて比較する

サーバーのパラメーターを変えずに、利用可能なWi-Fiとモバイルネットワークでそれぞれテストします。特定のネットワークだけ失敗する場合は、アカウントの無効化と決めつけず、ネットワークの認証状態、ポートへの到達性、トランスポート条件を確認してください。同じネットワークで利用者が持つ他のサーバーが正常なら、問題は特定のリモートサービスに絞られます。すべてのサーバーが失敗する場合は、基本ネットワーク、システムの許可、DNSの項目に戻って確認してください。

Connectivity Testの結果は、選択したテスト方法と接続先に対するものです。ポート接続に成功してもプロトコル認証が成功するとは限りません。テスト用ウェブページが応答しても、別のサイトにアクセスできるとは限りません。テストは失敗するのに実際のアプリが使える場合、テスト先に到達できないか、現在のサービスにテスト方法が適していない可能性があります。実際のリクエストで確認し、一覧のテスト結果をよく見せるためにサーバー設定を何度も変更しないでください。

サーバー名と接続先アドレスが異なることはありますが、どちらも元の設定と一致している必要があります。IPアドレスで接続する場合でも、TLSでは正しいサーバー名の指定が必要なことがあり、ドメインをIPに置き換えると証明書が一致しなくなる場合があります。端末の日付と時刻が正しくない場合も、証明書の有効性判定に影響します。証明書に関するエラーが出た場合は、時刻とサーバー名を確認してください。検証の省略を通常の解決策にしないでください。

次に誰へ確認すべきか判断する

同じ項目が複数の利用可能なネットワークで繰り返し失敗し、他の登録済み項目は正常な場合は、元のサービスの管理者にアドレス、ポート、認証状態、サービスの稼働状況を確認してください。共有するのは、個人情報などを隠したエラー原文と再現条件で十分です。共有リンクやサブスクリプションURLをそのまま公開しないでください。リモート側で最近パラメーターが変更された場合は、該当項目を更新します。更新後は実際に選択されている項目も新しいものか確認し、古い項目を使い続けないようにしてください。

ウェブページは開けるのに、大容量ファイルや特定アプリの通信が途切れる場合は、単純にサーバーのタイムアウトと分類しないでください。トランスポート経路、UDPの対応状況、パケット分割の条件が関係している可能性があります。安定したネットワークで同じ操作を比較してください。高度なネットワークパラメーターはサーバー側の要件に従い、バックアップを取ってから一つずつ変更します。明確な根拠がないままトランスポート方式と複数の低レベル設定を同時に変更すると、新たな非互換の原因を増やすおそれがあります。

04 / サブスクリプション

サブスクリプションの更新失敗は、アドレスからデータを取得できるか、取得した内容を解析できるか、読み込んだ結果を正しく使えているかの3つに分けて確認します。それぞれ対処方法が異なります。更新ボタンでエラーが出ても、現在使える項目をすぐに削除しないでください。登録済みのサーバーに接続できても、サブスクリプションの接続先までアクセスできるとは限りません。逆に、更新に成功しても、含まれるすべてのサーバーがその時点で接続できるとは限りません。

アドレスとアクセス条件を確認する

利用中のサービスの管理ページから、サブスクリプションURL全体をコピーし直します。ウェブページのタイトルや説明文をコピーしていないこと、URLが途中で切れていないことを確認してください。URLのクエリパラメーターにアクセス認証情報が含まれる場合があり、一部が欠けると使えなくなることがあります。コピー後は先頭と末尾の空白や改行に注意してください。URLを短く見せるためにパラメーターを手動で削除しないでください。サブスクリプションURLは機密性の高い接続情報です。公開コメントやスクリーンショットに載せないでください。

更新時のネットワーク経路を比較します。接続を切ると更新でき、接続後は失敗する場合、現在のリクエスト経路やDNSの条件がサブスクリプションの接続先に適していない可能性があります。逆の場合は、利用者がすでに使える接続を経由して更新できます。テストでは同じサブスクリプションURLを使い、接続状態だけを変更してください。そうすれば経路による違いを確認できます。何度もボタンを押してもアドレスの問題は解決せず、アクセス頻度の制限がかかることもあります。

認証、権限、アクセス頻度に関するエラーが表示された場合は、利用中のサービスのページに戻り、URLの状態とアクセス制限を確認してください。ウェブページを開けても、サブスクリプションの取得権限があるとは限りません。管理ページとサブスクリプションの入口で認証方式が異なる場合もあります。ブラウザでの確認は応答の有無を調べる補助にとどめ、返されたページを他人に転送しないでください。ページへのログインを求められる場合、ウェブページのURLをSubscribeに入力しても、正しいサブスクリプションURLの代わりにはなりません。

取得の成功と解析の成功を区別する

データを受信できても読み込みに失敗する場合は、クライアントが対応するサブスクリプションデータではなく、ログインページ、エラーの説明、完全な設定ファイルが返されていないか確認してください。URLが使えない場合でも、画面に表示できるウェブページが返されることがあります。ブラウザに文字が表示されるだけでは、形式が正しいとは判断できません。エラーの原文と照らし合わせ、内容の形式、空の結果、項目の不足のどれが原因か確認してから、利用中サービスの管理者に状況を伝えてください。文字コードを推測で変更しないでください。

Subscribeが管理するサーバー一覧と、Configが管理するルール設定は別の種類のデータです。ルールファイル全体をサーバーのサブスクリプションとして読み込んだり、サーバー共有情報を設定ファイルとして有効にしたりすると、解析に失敗することがあります。手元のデータの用途を確認してから、適切な読み込み先を選んでください。読み込み後は、項目が想定したグループに表示されているか、件数に大きな変化がないか、以前手動で追加した項目が残っているかを確認します。

以前のサブスクリプションと現在使えるサーバーを残し、今回の更新エラーの原文を記録します。
アドレス全体をコピーし直し、同じネットワークで一度だけ試して、同じエラーが出るか確認します。
取得、認証、解析のどの段階で起きたかに応じて、該当する手順に進みます。
更新に成功したらグループと実際のパラメーターを確認し、使用するサーバーを選び直してリクエストをテストします。

更新後に一覧が変わった場合の対処

更新後に同じ名前の項目が表示されても、名前だけでまとめて削除せず、所属するサブスクリプションと実際のアドレスを確認してください。異なるサブスクリプションで同じ命名規則が使われることも、手動で追加した項目がサブスクリプションの項目と同じ名前になることもあります。削除する前に、現在選択中の項目の提供元と、Configのポリシーが有効な項目を参照しているかを確認します。サーバー側で削除された項目は、以前の選択状態をそのまま新しい接続に使えない場合があります。利用可能な項目を選び直してください。

更新に成功したのに古いパラメーターが使われる場合は、正しいサブスクリプションを更新したか、現在選択中のサーバーが手動で作成した別のコピーではないかを確認してください。同じURLを繰り返し読み込んで状態を上書きしないでください。提供元が重複して分かりにくくなります。提供元を識別できるメモを残し、1つのサブスクリプションを順に更新して、アドレスや項目の変更を比較する方法が確実です。削除は、新しい項目が使えると確認してから行ってください。

サブスクリプションや接続先の利用条件は、利用者がすでに契約しているサービスによって決まり、クライアント自体がそれを提供するものではありません。クライアントの買い切り価格 ≠ 接続サービスのプラン料金。当サイトではサーバーやサブスクリプションの提供・販売・推奨は行わず、すでにお持ちの情報の読み込みとトラブルシューティングを説明しています。正しい読み込み順を確認する場合はクイックスタートチュートリアルに戻ってください。用語や操作に関する簡単な質問はよくある質問をご覧ください。

05 / パフォーマンスの比較

接続速度が遅い

まず「遅い」という状態を再現可能な現象として具体化します。ウェブページの最初の表示に時間がかかる、画像が一枚ずつ読み込まれる、ファイル転送がずっと遅い、動画が途切れる、といった症状を確認してください。それぞれ原因となる段階が異なります。最初の表示だけ遅く、その後は正常なら、名前解決や接続確立を優先して確認します。長時間の転送が遅い場合は、基本ネットワーク、リモート側の出口、接続先のサービスを比較してください。Connectivity Testの1回の結果だけで、すべての利用状況における速度を判断しないでください。

条件をそろえて比較する

同じ端末、同じ場所、近い時間帯に、同じ接続先で比較してください。大容量の通信を行う他のタスクを終了し、システム更新やクラウド同期を一時停止して、バックグラウンドの通信を現在のリクエストと混同しないようにします。次に、接続を切った状態の結果を記録し、利用中のサーバー同士を比較します。接続先のファイル、アプリでの操作、ネットワークの種類をそろえてください。条件が異なると、コンテンツ配信先やキャッシュの状態の違いで速さが変わることがあります。

Wi-Fiの電波強度が良好と表示されても、通信が安定しているとは限りません。距離、同じ周波数帯の干渉、ルーターの負荷、上り通信の使用状況が実際の速度に影響します。ルーターの近くで再テストし、可能であればモバイルネットワークでも比較してください。ネットワークを切り替えると同じサーバーの速度が明らかに改善する場合は、まずローカルネットワークを確認します。テスト中はモバイルデータの使用量にも注意してください。大きなファイルを何度もダウンロードする必要はありません。問題を再現する最小限の操作で十分です。

複数の登録済みサーバーを比較するときも、テスト方法をそろえてください。接続確立が速くても、持続的な転送性能が高いとは限りません。ある接続先への応答が速くても、すべての接続先で同じとは限りません。パラメーターが明確で、正常に接続できる登録済みの項目を2つ選び、同じ操作を一つずつ実行します。複数の項目で特定の接続先だけ遅く、他のリクエストは正常なら、その接続先のサービスと該当するリクエスト経路を優先して確認してください。

ルールと通信の問題を切り分ける

ConfigとProxyを比較し、ルールに従った通信のときだけ遅くなるか確認します。Proxyでは正常でConfigでは遅い場合、対象リクエストが誤ってDirectに送られていないか、想定外のポリシーを参照していないか、関連するリソースドメインが異なる経路を使っていないかを確認してください。1つのページから複数のドメインにリクエストが送られることがあります。ページの本文は正常に表示されても画像が遅い場合、サーバー全体が遅いと判断せず、遅延しているリソースを特定してください。

すべてのリクエストで初回の表示が遅く、その後は正常な場合は、接続記録から、名前解決、ハンドシェイク、接続先の応答のどこに時間がかかっているか確認します。速度を上げるためにDNSとサーバーを同時に変更しないでください。サーバーを固定して名前解決の条件だけを比較し、元に戻してから別の項目を比較します。ある接続先に有効だった設定がConfig全体に適しているとは限りません。比較結果を記録し、出所不明の「最適化パラメーター」を積み重ねないようにしてください。

リアルタイム通信、一部のゲーム、その他UDPを使うアプリでは、通常のウェブページとは異なる要件がある場合があります。ウェブページが開けても、該当する通信ができるとは限りません。利用中のサービスが必要な通信方式に対応しているか確認し、クライアントの項目とConfigの関連条件を調べます。プロトコル名だけで速度が保証されるわけではありません。症状と再現可能なテストの根拠がないまま、MTUなどの低レベル設定を変更しないでください。

変更を最小限にして復旧する

サーバー側から特定のトランスポートパラメーターが指定されている場合は、異なるサービスの設定を参考にせず、現在の項目と一つずつ照合します。TLSなどのハンドシェイクに時間がかかる場合は、端末の時刻、サーバー名、ネットワークの安定性を確認してください。証明書の検証を無効にしてもパフォーマンスの調整にはなりません。ネットワークを切り替えた後も対象アプリが遅い場合は、アプリを終了して開き直し、切り替え前の経路を使う既存の接続を解消してください。

長時間の転送中に周期的な停止が起きる場合は、端末が省電力状態に入っていないか、バックグラウンドの動作が制限されていないか、無線ネットワークが切り替わっていないかも確認してください。パソコンでシステムプロキシを使う場合は、クライアントが動作中という表示だけでなく、対象アプリが実際にその経路を使っていることを確認します。「特定のネットワーク、接続先、モードで改善した」と具体的に記録し、特定の設定がすべての端末で速いと結論づけないでください。

06 / ドメイン解決

DNSの問題

DNSのトラブルシューティングでは、ドメイン名から利用可能なアドレスを取得できるか、リクエストが想定した名前解決経路を使っているかを確認します。ドメインにアクセスできない原因はDNSとは限りません。その後の接続、TLS、ルールによって失敗することもあります。まずエラーが名前解決と接続のどちらの段階で発生したかを確認し、システムネットワークと接続中の挙動を比較します。よく使われるDNSアドレスに変更するだけでは原因を特定できず、もともと使えていたローカルネットワーク名が解決できなくなる場合もあります。

サーバーのドメインと接続先ドメインを区別する

名前解決が必要な対象には、少なくとも2種類あります。プロキシサーバー自体のドメインと、ブラウザやアプリがアクセスしようとしている接続先ドメインです。前者が解決できないと、すべてのプロキシ接続が確立できないことがあります。後者の問題は、特定のウェブサイトだけに影響する場合があります。エラーの対象となっている名前を確認し、接続先のページが失敗しただけでサーバーアドレスを変更しないでください。表記を確認するときは完全なドメイン名を保持し、サブスクリプションURLのパスをサーバー名と混同しないようにしてください。

基本ネットワークが使える状態で、まずサーバーのドメインを解決できるか確認し、その後に接続中の対象ドメインの結果を調べます。サーバーアドレスにIPを使う場合でも、TLSの名前照合が必要なことがあるため、問題をすべて回避する目的でドメインをIPに置き換えないでください。ウェブサイトのIPアドレスへ直接アクセスする方法も、一般的なテストにはなりません。多くのサイトは正しいホスト名と証明書を必要とします。IPへのアクセスが失敗しても正常な場合があり、それだけでネットワークに到達できないとは判断できません。

以下のGeneralの断片は、システムDNSを使う設定例を示すもので、基本状態を説明するためのものです。すべてのネットワークで使える完全な設定ではありません。変更前に現在のファイルに同じ項目がないか確認し、競合する定義を追加しないようにしてください。元のコピーを保存してから、比較したい項目だけを変更し、新しいリクエストを実行します。実際のネットワークで特定の名前解決方式が必要な場合は、そのネットワークと利用中サービスの説明に従ってください。

[General]
bypass-system = true
dns-server = system

ルールとあわせて名前解決の結果を確認する

ドメインを対象とするルールとアドレスを対象とするルールでは、判定条件が異なります。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDは名前を、IP-CIDR、IP-CIDR6、GEOIPはアドレスを対象とします。すべての失敗をルール順の問題と決めつけたり、ドメインルールがあるからDNSは無関係だと判断したりしないでください。実際のリクエスト記録から接続先、適用されたルール、使用されたポリシーを確認し、どの段階を調べるか決めてください。

特定のWi-Fiでだけ内部ドメイン名やローカル端末が使えない場合は、そのネットワークが独自のDNSを必要としているか確認してください。すべての名前解決を外部経路に変更すると、ローカル名を解決できなくなることがあります。プリンターやストレージなどのローカルネットワーク上の機器では、アドレス範囲、ネットワーク分離、該当するDIRECTルールも確認してください。機器を検出できてもサービスに接続できない場合は、ポートや機器側の権限が原因かもしれません。DNSだけを変更し続けないでください。

IPv4とIPv6の利用可否に違いがある場合、名前解決では正常にアドレスが返されていても、その後の経路の一部に到達できないことがあります。問題が特定のネットワーク、接続先、アドレスの種類に限られるかを比較してください。根拠のないまま一方のアドレス方式を全体で無効にしないでください。ネットワークの切り替え、ルーターの設定、リモートサービスのいずれも結果に影響します。システムの初期状態を比較基準として残し、失敗箇所が特定できた場合に限って変更してください。

キャッシュと再テストを確認する

設定を変更した後も、ブラウザ、対象アプリ、システム、リモート側に古い結果が残っている場合があります。まず進行中のリクエストを終了し、対象アプリを閉じて開き直します。必要に応じて接続を切ってから再接続し、新しい記録を確認してください。ページを一度再読み込みしただけでは既存の接続が使われ、新しいDNS設定が反映されたか分からないことがあります。端末を何度も再起動して確認の代わりにしないでください。一時的に状態が消えても、どの設定が問題を引き起こしたかは分かりません。

同じドメインが1台の端末だけで失敗する場合は、ルーター全体を変更する前に、端末の時刻、システムネットワーク設定、現在のConfigを比較してください。同じネットワークの複数の端末で同じ失敗が起きる場合は、ネットワークが提供する名前解決条件を優先して調べます。結果にはネットワークの種類、対象名、エラーが起きた段階、使用したモードを記録してください。サブスクリプションや認証情報全体を公開する必要はありません。内部ドメイン名を含む記録も、適切に伏せてください。

07 / バックグラウンド動作

バッテリー消費・バックグラウンドの問題

まず、バッテリー使用状況の割合と、端末が実際に消費した電力を区別します。あるアプリの割合が増えていても、他のアプリの使用が減っただけの場合があり、そのアプリの消費電力が急増したとは限りません。画面の明るさ、電波状況、使用時間、ネットワーク条件が近い状態で比較し、端末の温度、バックグラウンドタスク、システム更新にも注意してください。他のアプリの通信を接続が中継している場合、その動作が使用状況に記録されることもあります。割合だけでクライアントの異常と判断しないでください。

頻繁な再接続とバックグラウンド通信を確認する

接続が不安定でセッションの確立を繰り返すと、無線通信や処理の負荷が増えることがあります。頻繁な切断、ネットワークの切り替え、認証失敗が発生していないか確認し、安定したネットワークで比較してください。同じネットワーク上で同じサーバーが再接続を繰り返す場合は、まずリモート接続の問題に対処します。テストの頻度を下げれば余分な通信は減らせますが、再接続の根本原因は解決しません。電波の弱い場所にいる場合も、別途記録してください。

On Demandでは、条件が満たされると接続が自動的に確立されることがあります。手動でオフにした後に接続が再開しても、スイッチが壊れているとは限りません。現在のネットワークに関係する条件や、互いに重複する自動接続ルールが設定されていないか確認します。調査中は元の条件を記録し、自動接続を一時的に無効にして手動で比較してください。動作の規則が分かったら、必要な条件だけを戻します。自動接続を常に求めながら、接続のたびに異常と判断しないでください。

写真のアップロード、ファイルの同期、メッセージの更新、オフラインコンテンツのダウンロードを続けているアプリがないか確認してください。バックグラウンド通信は、ブラウザを開いていなくても接続をアクティブなままにすることがあります。該当するタスクを一時停止し、同じネットワークで待機中の状態を確認してから、一つずつ再開します。システム機能を大量にまとめて無効にして問題が解決したと判断しないでください。原因を特定できず、日常の通知や同期にも影響するおそれがあります。

調査用ツールの影響を抑える

Connectivity Testの実行、頻繁な更新、詳細なログ記録も、それ自体が追加の通信や書き込みを発生させます。調査が終わったら、不要な繰り返しテストを停止し、アプリで変更できる場合は通常のログレベルに戻してください。ログを残す必要がある場合は、記録する時間を限定し、開始と終了の操作を明確に記録してから必要な部分だけを収集します。長時間にわたって蓄積したログは確認しにくくなるだけでなく、公開すべきでない接続先や通信情報を含むことがあります。

バッテリー消費を判断するときは、接続を有効にした直後の瞬間的な変化ではなく、同じような操作を含む時間を使って比較してください。充電、端末の発熱、システムのバックグラウンド処理も結果に影響します。まず通常の使用状態で比較してから、待機中の状態を確認します。高負荷の転送中だけ消費電力が増える場合は、実際の転送量とあわせて判断してください。通信がほとんどないのに消費が続く場合は、頻繁な再接続、バックグラウンドタスク、診断動作を重点的に確認します。

Androidでは、バッテリー管理によってバックグラウンドのアプリ動作が制限され、画面をロックしてしばらくすると接続が切れ、ロック解除後に復旧することがあります。まずシステムがShadowrocketのバックグラウンド動作を制限していないか確認し、端末の使用状況に応じて必要な設定だけを変更します。最初からすべてのアプリの制限を解除する必要はありません。システムによって設定項目の名称は異なるため、使用中の端末の説明を確認してください。変更後は通知、待機中の動作、接続の継続性を比較し、画面を開いた状態でのウェブ閲覧だけで判断しないでください。

発熱とスリープを個別に確認する

パソコンをスリープから復帰させた後、ネットワークがまだ復旧していないことがあり、接続が一時的に再確立される場合があります。システムのネットワークが利用可能になるまで待ってから、元のリクエストを再実行し、問題が復帰直後に限られるか確認してください。スリープ後に毎回アプリを開き直す必要がある場合は、前後のネットワークの種類とエラーを記録し、ネットワークインターフェースが切り替わっていないか確認します。問題を隠すために端末のスリープを長期的に無効にしないでください。消費電力の比較条件が変わるだけで、接続の復旧手順は直りません。

端末が明らかに発熱している場合は、高負荷の通信を停止して通常の温度に戻ってから、パフォーマンスを確認してください。温度管理は処理速度に影響するため、速度低下とバッテリー消費増加が同じ負荷から生じることがあります。接続を切っても発熱が続く場合は、ルールを変更するのではなく、システムや他のアプリの動作を確認します。バッテリーの状態、充電環境、無線の電波強度も結果を変えるため、クライアントの設定とは分けて考えてください。

08 / 変更後の復旧

更新後の不具合

更新後に問題が起きても、アプリの更新だけが原因とは限りません。同じ時期にサブスクリプションの内容、Config、システム、ネットワークが変更された可能性があります。最後に正常に使えた時点から、最初に失敗した時点までの変更を整理してから、確認する順番を決めてください。アプリの削除、サブスクリプションの消去、ネットワークのリセットを同時に行わないでください。比較に必要な元の状態が失われ、限定的な問題が再設定を要する複雑な問題に変わることがあります。

まずデータを残し、問題の範囲を確認する

現在のConfig、手動サーバー、必要なサブスクリプション情報をバックアップし、コピーをローカルで確認できることを確かめます。バックアップファイルにはパスワード、ID情報、完全なサブスクリプションURLが含まれることがあるため、管理された場所に保管し、公開しないでください。次に、アプリが起動しない、接続直後に切れる、すべてのリクエストが失敗する、特定の接続先だけ失敗する、のどれに当たるか確認します。問題の範囲に応じて起動、許可、接続、ルールを調べます。何でも再インストールで解決しようとしないでください。

アプリ更新後の初回起動時に新しいシステム許可の画面が表示された場合は、画面の表示元を確認してから必要な許可を完了し、再テストします。システム更新によって以前の許可状態が変わることがあり、接続構成が残っていても許可の条件が同じとは限りません。特定のConfigだけ読み込めない場合は、エラーの原文を残し、最近使えたローカルコピーを有効にしてみてください。コピーが動作するなら、サーバーを次々と変更するのではなく、設定内容の差を重点的に確認します。

Subscribeとアプリの両方を最近更新した場合は、まず現在選択中のサーバーの実際のパラメーターが変わっていないかを確認し、Configのポリシー参照が引き続き有効かを確認します。古い名前の削除、グループの変更、項目の置き換えによって、更新後に接続が失敗したように見えることがあります。利用者がすでに持つ、パラメーターが明確な項目を1つ使ってテストすると、一覧の変更による影響を抑えられます。バックアップがない状態でサブスクリプション全体を削除しないでください。

プラットフォーム別にインストールと起動許可を確認する

iPhoneとiPad版のアプリはApp Storeから更新します。システム要件はApp Storeの製品ページに記載された内容を確認してください。再インストールする前にバックアップと購入時のアカウントを確認します。アプリを削除するとローカル設定も削除されることがあります。App Storeの購入履歴があっても、設定のバックアップがあるとは限りません。正規版か確認するには、公式アイコン、開発者名Shadow Launch Technology Limited、アプリID 932747118を確認してください。手順は正規版の確認をご覧ください。

Mac、Windows、Android、Linux向けの新しいインストーラーは当サイトのダウンロードページから入手できます。ページ内の動的なリンクは /dl/shadowrocket/ を参照します。Macでは「このMacについて」でAppleシリコン版とIntel版のどちらかを確認してください。Windowsではページの案内に従ってインストーラーを選び、Linuxではディストリビューションに合った形式を選択します。更新時に問題が起きても、異なるアーキテクチャや出所不明のファイルを使わないでください。別の起動問題が加わる可能性があります。

初回起動がブロックされた場合は、Macでは入手元を確認してから「プライバシーとセキュリティ」で「このまま開く」を選択します。WindowsではSmartScreenの「詳細情報」で確認し、「実行」を選びます。Androidでは案内に従って現在使用しているダウンロードアプリに不明なアプリのインストールを許可し、完了後は必要に応じて許可を取り消してください。Macでアプリが破損しているという警告が出た場合は、まずダウンロードが完了していることと入手元を確認し、インストールページの該当手順を参照してください。システム全体のセキュリティ設定は無効にしないでください。

xattr -cr /Applications/Shadowrocket.app

上記のコマンドは、入手元を確認済みで、アプリが指定のパスにある場合に限り、Macファイルの拡張属性を処理するためのものです。すべての起動エラーを修正する汎用コマンドではありません。アプリを終了してから実行し、パスが実際のインストール場所と一致することを確認してください。LinuxのAppImageでは実行権限も必要です。debとrpmは、それぞれのパッケージ管理手順で依存関係を確認してください。インストール時の問題を解決してから、接続とリクエストのテストに進みます。2種類の問題を混同しないでください。

復旧を確認して報告内容をまとめる

変更を1つ行うたびに、最初に失敗した操作をもう一度実行し、更新前に使えていたコピーと比較します。新しく追加したConfigだけが失敗するなら、その差を残してください。同じネットワークですべてのConfigが失敗する場合は、システムネットワークと許可の変更を確認します。メイン画面が開いただけで復旧したと判断せず、接続、名前解決、対象アプリをテストしてください。修正後は調査用ファイルと通常使用するファイルを区別し、次回、テスト用コピーを誤って選ばないようにします。

報告には、端末のシステム、インストール元、問題が発生した段階、エラーの原文、最短の再現手順を含めてください。バージョン情報が必要な場合は、使用中のアプリに実際に表示されている内容を確認し、古いスクリーンショットから推測しないでください。サーバーの認証情報とサブスクリプションURLを隠してから、必要な記録を共有します。MacとWindowsのチップ選択および初回起動手順についてはパソコンへのインストールと起動許可の説明をご覧ください。

09 / 端末別の確認

iPadのトラブルシューティング

iPadでも、ネットワーク、サーバー、設定、リクエストの順に確認します。そのうえで、Wi-Fi専用モデルかモバイル通信対応モデルか、マルチタスク中のアプリの挙動かを区別してください。iPhoneで同じ名前の項目が接続できたからといって、iPad側に問題があるとすぐに判断しないでください。2台でネットワーク、Config、実際のパラメーターが異なる可能性があります。まずテスト条件をそろえてから端末の違いを比較し、環境差をプラットフォームの問題と混同しないようにしてください。

2台の端末で比較条件をそろえる

iPhoneと比較する場合は、まず両方の端末を同じ利用可能なWi-Fiに接続し、パラメーターが同じ登録済みサーバーを選びます。有効なConfigの内容が同じであることを確認し、Global Routingもそろえてから、ブラウザで同じリクエストを実行してください。サーバー名をそろえるだけでは不十分です。同じ名前の項目でも異なるサブスクリプションや更新時点のものかもしれません。設定ファイル名だけでなく、実際のルール内容と最近の変更も照合してください。

Wi-Fi専用のiPadでは、Wi-Fiを切るだけでモバイルネットワークとの比較を行うことはできません。可能であれば、利用できることが分かっている別のネットワークに接続してください。スマートフォンのテザリングを使う場合は、元のWi-Fiを再テストしているのではなく、新しいネットワーク経路であることに注意します。モバイル通信対応モデルでは、データ通信が正常か、対象アプリがそのネットワークを使えるかも確認してください。どの比較でも、接続を開始する前に基本ネットワークが利用可能であることを確かめます。

画面分割などのマルチタスク中は、対象アプリが以前のセッションを維持していることがあります。Global Routingを切り替えた後は、実行中のリクエストを終了してから対象ページを開き直してください。必要に応じて対象アプリを終了し、再試行します。画面分割中のページに内容が表示されているだけでネットワークが正常だと判断しないでください。キャッシュが表示されている可能性があります。逆に、バックグラウンドのアプリがすぐに更新されなくても接続が切れたとは限りません。新しいリクエストを実行して確認してください。

画面ロックとネットワーク切り替えに対処する

画面ロック後にだけ問題が起きる場合は、ロック解除時にシステムネットワークが復旧しているか、クライアントの接続が維持されているか、対象アプリを開き直すと復旧するかを記録します。アプリがバックグラウンドで停止することと、システム接続が使えるかどうかは別の問題です。まずブラウザで新しいリクエストを実行し、特定のアプリだけのセッション復旧の問題か確認してください。復旧途中にスイッチを何度もタップすると接続が再確立され、進行中の復旧を妨げることがあります。

学校、オフィス、公衆Wi-Fiでは、定期的な再認証が必要な場合や、端末ごとに利用許可が必要な場合があります。iPhoneで認証を完了していても、iPadが同じ条件を満たすとは限りません。接続を切った状態で認証ページを開き、ネットワークの利用が許可されていることを確認してから、Shadowrocketに接続してください。組織が管理するiPadではVPN構成やネットワーク動作が制限されている場合もあります。管理者に許可されている使い方を確認し、内容を特定できない管理用情報を削除しないでください。

ローカルプリンター、ストレージ、その他のローカルネットワーク上のサービスにアクセスする場合は、iPadと接続先の端末が相互通信できるネットワークにあるかを確認し、Configがローカルアドレスをどう処理するか調べてください。ローカルネットワークの権限、ネットワーク分離、ルール経路が影響することがあります。まず接続を切った状態でアクセスできるかを確認し、その後ConfigとDirectを比較します。ローカル端末1台を使えるようにするために、すべてのリクエストを常に直接接続に変更しないでください。対象を絞った調整のほうが管理しやすくなります。

購入済みアプリの復元とデータ移行

iPhone / iPad版はApp Storeで$2.99の買い切りです。どちらの端末でも同じ購入アカウントを使って購入済みアプリを復元できます。Mac、Windows、Android、Linux版は無料です。価格と入手方法は分けて考えてください。パソコン版はモバイル版のストア購入手順には含まれません。iPadの具体的なシステム要件はApp Storeの製品ページで確認し、別の端末にインストールできたかどうかから推測しないでください。

機種変更や再インストールの際は、購入時のアカウントでサインインしていることを確認してから、購入済み項目でアプリを探してください。アプリを復元しても手動で設定した内容が自動的にすべて復元されるわけではありません。移行前に利用中のサブスクリプション情報とConfigを保存してください。アプリを復元できても一覧が空の場合は、再購入ではなくデータ移行の問題として対処します。詳しい手順は購入済みアプリの復元方法をご覧ください。初回の再読み込みはチュートリアルに従ってください。

最後に、元の利用状況に沿って確認します。接続後に新しいウェブページのリクエストを実行し、以前失敗したアプリを開き、画面をロックしてから解除して再テストしてください。必要に応じてローカルネットワーク上のサービスも確認します。どの手順で復旧したか、どの条件で問題が続くかを記録すると、「iPadが使えない」とだけ記すより次の切り分けに役立ちます。用語や仕組みについての質問はよくある質問をご覧ください。明確なエラーが出る場合は、該当する章に戻り、同じ情報に基づいて調査を続けてください。設定全体を消去し直す必要はありません。