Shadowrocketの設定ガイド

01 / Scope

設定の範囲・初期値・変更前の基準

Settings、Config、サーバー項目を区別する

Shadowrocketの設定は、すべての項目が同時に適用される一枚の一覧ではありません。Settingsのアプリ全体に関わる項目、Config内の設定ファイル、サーバー編集画面の接続パラメーターは、それぞれ異なる役割を持ちます。たとえばDNSはConfigとアプリ内設定の両方に関係する場合がありますが、サーバーアドレスは接続先の項目です。トラブルシューティングの前に、どの階層を編集しているか確認してください。正しく保存できても、実際のリクエスト処理に使われる設定が変わっていないことがあります。

Homeでは現在の接続状態とサーバー選択を確認し、Configでは設定ファイルを管理・選択し、Settingsではアプリの設定を確認します。本ページではこれらの画面上の表記をそのまま使用します。項目の配置や表示内容は端末の実際の画面で確認してください。同じ名前の設定を見つけたら、操作する前に説明、現在値、選択可能な範囲を確認しましょう。別の端末のスクリーンショットに表示された位置だけを頼りにスイッチを探さないでください。Configに存在しないフィールド名を、日本語の説明から推測して書き足すこともできません。

「初期値」には少なくとも、新規Configの初期内容、アプリ初回起動時の選択項目、サブスクリプションやConfigの読み込み後の値という3つの意味があります。これらは同じではありません。端末を移行して復元すると、以前の端末の設定が引き継がれていることがあります。また、Configを選び直すと別のファイルに切り替わる場合もあります。本ページでは、未確認の初期値よりも「変更前に実際に適用されていた値」を記録することをおすすめします。元に戻す際の基準になり、問題が今回の変更によって起きたかどうかも判断しやすくなります。

記録を残し、元に戻せる基準を作る

作業前に、現在のGlobal Routing、選択中のサーバー、使用中のConfig、問題発生時のネットワークがWi-Fiかモバイル通信かを記録します。サーバー名はご自身の記録で識別できれば十分で、公開する必要はありません。変更するConfigのコピーも保存し、「特定のドメインが想定したルールに一致するか確認する」など、変更の目的を記してください。この記録はアプリのログではなく、何度か試行した後に最初の状態を忘れないための作業メモです。

一度に変更する項目は1つだけにします。DNS、サーバー、ルーティングの設定、テスト方法を同時に変更すると、接続が復旧しても何が効いたのか分からず、同じ問題が起きたときにまたやり直すことになります。1回の検証では、変更前のテスト、1項目の変更、接続の再確立、同じ対象への再テスト、結果の記録、設定を残すか戻すかの判断を行います。Configを編集した場合は、保存後のファイルが現在のConfigとして選択されていることも確認してください。

「おすすめの設定値」は状況によって異なります。問題なく使えている端末では、検証済みの設定を維持するのが基本です。問題がある端末では、まず最小限で説明可能な設定に戻し、その後に機能を1つずつ戻します。数値を上げたり、タイムアウトを延ばしたり、選択項目を増やしたりしても、自動的に安定するわけではありません。特にネットワーク接続では、設定で変えられるのはクライアント側のリクエスト処理です。サーバーの稼働状況、認証情報の有効性、現在のネットワークからのアクセス条件を代わりに解決することはできません。

Config例のexample.comは説明用のドメインで、接続先のサービスを示すものではありません。PROXYとDIRECTはルールで使うキーワードです。画面上のGlobal RoutingにあるProxy、Directとは、表記と適用範囲を区別してください。例に含まれる予約済みアドレスは、マッチングの仕組みを示すためのものなので、そのままコピーする必要はありません。既存Configにカスタムポリシーが含まれている場合は、定義を確認してから参照し、解析できないポリシー名を書かないようにしてください。

まだ初回接続が完了していない場合は、複雑な設定調整に進まず、まず入門ガイドの手順を完了してください。すでに明確なエラーメッセージがある場合は、よくある質問も参考にして原因を絞り込めます。以降の章では、名前解決、ルーティング、接続条件、テスト、記録、同期、復元の順に説明します。「設定が正しそうに見える」だけでなく、「実際のリクエストを検証できる」ようにするための順序です。

02 / DNS

DNS設定とドメインの名前解決

DNSでできること

DNSはドメイン名をIPアドレスに変換しますが、「名前解決に成功した」ことは「接続に成功した」ことを意味しません。アドレスを取得できても、サーバーへの接続、暗号化セッションの確立、コンテンツの取得で失敗する場合があります。逆に、プロキシサーバーのアドレスにドメイン名を使っている場合は、プロキシへの接続前に名前解決が必要になることがあります。まず、接続先サイトの名前解決に失敗しているのか、プロキシサーバーのアドレス解決に失敗しているのかを切り分けてください。発生する段階が異なるため、同じ設定を変更しても両方が解決するとは限りません。

Configで使用中のファイルを開き、[General]にdns-serverが含まれているか確認します。次の例のsystemは、システムが提供する名前解決設定を使うことを示すもので、すべてのファイルにこの行が自動で含まれるという意味ではありません。実際の結果は現在のネットワーク環境に左右されます。アプリ内にもDNS関連の設定がある場合は、合わせて記録してください。Configの1行だけを見て、すべてのリクエストが同じ経路で名前解決されると判断することはできません。

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

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

この断片では、アプリ側の処理、名前解決元、ルールマッチングを示していますが、各設定行の役割は異なります。bypass-systemは個別のConfigオプションであり、「DNSを修復する」ための汎用スイッチではありません。dns-serverは名前解決の設定を指定し、[Rule]はマッチしたリクエストに適用するポリシーを決めます。行をコピーする前に、元ファイルの配置、重複フィールド、既存ルールとの競合がないか確認し、必要なセクションを残してください。

初期値とおすすめ設定の考え方

DNSの現在値は、使用中のConfigとアプリの画面で確認してください。本ページでは、すべてのネットワークに共通する名前解決アドレスを指定したり、特定のDNSサービスを一律に推奨したりしません。名前解決に問題がない端末では、検証済みの設定を維持します。特定のネットワークだけで失敗する場合は、別のネットワークでの結果と比較してください。問題の発生段階が名前解決だと確認できた場合に限り、名前解決元を変更し、同じドメインを繰り返しテストします。

既存Configで暗号化DNSを使っている場合は、その接続先に到達できるか、接続先のドメイン名を事前に解決する必要があるか、現在のルーティングでどのように接続するかを確認してください。別のプロトコルに変更しても、接続前に必要な処理が自動的に不要になるわけではありません。問題が起きたら、まず単純で確認しやすい条件で基本経路を検証し、その後に元の名前解決設定を戻します。接続先を次々に追加すると、失敗時にどの接続先が使われたのか分からなくなるため避けてください。

ドメインルールとIPアドレスルールも、確認結果に影響します。DOMAIN-SUFFIXはドメインのサフィックスでマッチし、IP-CIDRはIPアドレスの範囲でマッチします。IPアドレスを使う判定では、名前解決が関係する場合があります。同じドメインでもネットワークによって異なるアドレスが返ると、後続のIPアドレスルールの結果も変わることがあります。「なぜこのルールに一致したのか」を調べる際は、最後に表示されたポリシーだけでなく、リクエストのドメイン、名前解決結果、ルールの順序も確認してください。

キャッシュとLAN内の名前解決

名前解決のキャッシュは、アプリ、システム、上流側など複数の場所に存在することがあります。DNSを変更しても、古い結果がすぐにすべて消えるとは限りません。Webサイト側で既存の接続を再利用する場合もあります。検証時はConfigを保存して接続を確立し直し、その後にリクエストを再実行してください。キャッシュの影響を調べる場合は、手順を一定にして繰り返しテストします。むやみにすべてのデータを消すと、ログイン状態や原因特定に必要な情報まで失うおそれがあります。

LAN内のデバイス名、内部ドメイン、公衆向けドメインでは、同じ名前解決条件が使われるとは限りません。外部の名前解決元に切り替えると、内部名が以前と同じように解決されない場合があります。家庭や職場のネットワーク内にある機器だけで問題が起きる場合は、元のネットワークに必要な名前解決、アドレス範囲、Directルールを確認してください。公開サイトにアクセスできたことは、内部名の設定が正しい証拠にはなりません。内部名を1つ直すために、すべてのリクエストのルーティングを変更することも避けてください。

変更後は、少なくとも以前は正常だった接続先、以前失敗した接続先、必要な場合はLAN内の接続先をそれぞれ検証してください。アドレスを取得できたか、接続を確立できたか、コンテンツが返ったかの3点を記録します。名前解決が成功してもコンテンツを取得できない場合は、DNSの切り替えを続けるのではなく、ルーティング、サーバー設定、接続先サービスを確認してください。段階ごとの結果を残すと、後のLog分析に明確な手がかりができます。

03 / Routing & Proxy

Global Routing、ルール、Proxyポート

3つのモードはサーバー設定の違いではない

Global Routingは、リクエストをどのように処理するかを大まかに決めます。ConfigはConfigのルールを使い、Proxyはプロキシ経由、Directは直接接続します。Configでは使用中のConfigにあるルールに従ってポリシーが適用されます。Proxyでは、通常このルーティング設定の対象となるリクエストをプロキシ経路に送ります。Directでは直接接続します。ただし、システム通信や除外項目、Configの内容などによる制限もあります。どのモードも、端末上のすべてのネットワーク動作を例外なく決めるものではありません。

ConfigでDIRECTと表示された場合でも、Configの内容に沿った結果であれば、サーバーの故障を意味しません。Proxyに切り替えて接続先が復旧したとしても、処理経路の変更が結果に影響したと分かるだけで、ルールの誤りが証明されたわけではありません。Configに戻り、対象が一致した行、その前にあるより広い条件のルール、実際に指定されているポリシーを確認してから変更を検討してください。

どのモードを普段使うかは、設定の目的によって異なります。確認済みのルールで通信を振り分ける場合はConfig、プロキシ経路を一時的に比較する場合はProxy、直接接続できる条件を調べる場合はDirectを使用できます。テスト後は元のモードに戻し、接続を確立し直してください。誤ったルールを隠すためにテスト用のモードを常用すると、LAN内の接続先やその他の通信経路まで変わる可能性があります。

ルールの順序とポリシーの意味

通常、ルールは上から順に照合され、個別のルールはフォールバックルールより前に置きます。次の例では、例示用ドメインとプライベートアドレスを先に処理し、一致しなかったリクエストを最後のFINALで処理します。FINAL,PROXYは、フォールバックとしてProxyを選ぶ意図的な例であり、すべてのユーザーが使うべき初期値ではありません。FINAL,DIRECTに変更すると、一致しなかったリクエストの経路が変わります。影響範囲は特定のドメインだけにとどまりません。

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

同じルールを重複して追加し、「優先度を上げる」ことは避けてください。前にあるルールですでに一致している場合、後に追加した同じ対象のルールは判定に使われないことがあります。まず一致記録を確認し、必要に応じてルールの順序を変更するか、条件を絞り込んでから保存・検証します。REJECTは一致したリクエストを拒否するものであり、リクエストを修復するものではありません。適用範囲についてはREJECTルールの順序と適用範囲をご覧ください。

リモートサーバーのポートとローカル待ち受けポートを区別する

サーバー編集画面のポートは、リモートサービスが接続を受け付けるポートです。手元にあるサーバー情報と一致している必要があります。SettingsにローカルProxyポートがある場合、それは端末上のローカルプロキシ入口が待ち受けるポートです。両方に同じ数字が表示されていても、互いに置き換えられるわけではありません。リモートサーバーの項目にローカルポートを入力したり、リモート側のポートをローカル待ち受け設定として使ったりすると、接続先が根本的に変わってしまいます。

ローカルポートの現在値、プロトコル、利用条件は実際の画面で確認してください。本ページでは特定のポート番号を指定しません。ポート番号が有効でも、サービスが待ち受けているか、リクエスト側がどのプロキシプロトコルを使うか、待ち受けが端末内のみに限定されているか、ネットワークからアクセス可能かを確認する必要があります。通常のiPhoneやiPadでシステムVPN設定を使って接続する場合、「速度向上」を目的にローカル待ち受けポートを変更する必要はありません。

ローカルProxyを使う必要がある場合は、まず現在の設定を保存し、リクエストの送信元が端末自身かLAN内の別の機器かを確認します。そのうえで、アプリが実際にサポートする方式を選んでください。HTTPとSOCKS5の設定項目を混在させることはできません。また、Webアドレスのパスはポート欄に入力する内容ではありません。接続できない場合は、待ち受けが有効か、プロトコルが一致しているかを先に確認し、その後に接続先を調べます。ポート番号が同じというだけで設定完了とは判断できません。

ルーティングやポートを変更した後は、通常のネットワークリクエストと特定のローカル入口を別々に検証してください。ポートを変えても通常の接続結果が変わらない場合、そもそも通常の接続がその入口を使っていない可能性があります。実際のリクエスト経路に沿って、送信元、接続先、使用プロトコル、適用ルールを確認してから、数値を変更する必要があるか判断してください。

04 / On Demand

On Demandの接続条件と停止方法

On Demandはサーバーの問題を修復する機能ではない

On Demandは、設定した条件に応じてVPN接続を開始する機能です。制御するのは「いつ接続を試みるか」であり、サーバーの確認、サブスクリプションの更新、ルーティング設定の代わりにはなりません。まず手動接続が安定し、使用中のConfigとサーバーが明確になってから、自動接続を設定してください。そうしないと、失敗する経路を同じ条件で何度も試し、アプリが設定を勝手に変えているように見えることがあります。実際には、条件が成立し続けているだけの場合があります。

実際のOn Demand設定を開き、現在有効か、どの条件が設定されているか、システム上のVPN構成が残っているかを確認してください。初期状態は端末の画面で確認します。以前のデータを復元した場合、アプリを再インストールした場合、再度認証した場合でも、初回使用時と同じ状態とは限りません。システムとアプリに表示される状態が異なる場合は、まず手動接続に戻って基本設定が有効か確認し、その後に自動接続の条件を調べてください。

おすすめの設定は「すべて有効にする」ことではなく、内容を説明できる条件だけを残すことです。ネットワークの種類や識別情報に応じて設定できる項目がある場合は、必要性を確認して1つずつ設定してください。他の人のネットワーク名をそのまま使わないでください。自動接続が不要な場合は、手動操作のままにすると状態を確認しやすくなります。複数のネットワークを頻繁に切り替える端末では、普段使うネットワークごとに接続条件を確認してください。現在のWi-Fiだけで検証しても不十分です。

自動接続を再現可能な手順でテストする

まず同じネットワークに接続したまま手動で接続し、検証に使えることが分かっている接続先を開いて、適用されたポリシーを確認します。次に接続を切断し、正常に停止することを確認します。最後に必要なOn Demand条件を設定し、実際にネットワークの状態を変えて接続結果を確認します。テスト中にサーバーを切り替えたり、サブスクリプションを更新したり、Configを変更したりしないでください。結果が変わっても、どの操作が原因か分からなくなります。

結果を確認する際は、条件が成立したか、システムが接続を開始したか、接続が確立したか、接続後のリクエストが正常だったかを分けて考えます。自動接続が始まった後に接続できない場合は、サーバーやネットワークを調べてください。接続自体が始まらない場合は、条件とシステム設定を確認します。ステータスバーにVPNの表示があっても、接続先から想定どおりのコンテンツが返ることまでは保証されません。

ネットワークを切り替えると、IPアドレスの再取得、名前解決条件の変化、既存接続の切断が起こる場合があります。一時的な再接続と、接続失敗が続く状態は分けて考えてください。切り替え前後のネットワーク、接続が始まった順序、失敗した段階を記録すると、スイッチを何度も切り替えるより原因を特定しやすくなります。ネットワークへの接続時にWeb認証が必要な場合は、ネットワーク自体の接続を完了してからOn Demandを確認してください。接続条件の設定で、ネットワーク側の認証を代替することはできません。

切断したのに再接続する理由

On Demandの条件が成立したままの場合、手動で一度切断しても自動接続の仕組みが無効になるとは限りません。自動接続を確実に停止するには、該当する設定でOn Demandを無効にしてから切断し、システムの状態を確認してください。原因を特定しにくくなるため、すぐにすべてのConfigを削除しないでください。停止を確認した後、記録をもとに必要な設定を戻します。

ほかのVPN構成や組織によるネットワーク制限がある端末では、システムで許可されている接続方法も確認してください。似た名前の構成を何度も作ると、アプリがどれを使用しているのか判断しにくくなります。管理対象の端末では、端末管理の要件に従ってください。本ページの一般的な手順で管理者の手続きを代替することはできません。個人端末の場合も、すべての接続失敗をアプリの設定が原因だと決めつけず、まずシステムに表示される内容を確認してください。

On Demandの検証では、端末をロックした後の通常利用も一度確認してください。ただし、バックグラウンドでの状態変化を、そのままバッテリー消費や性能の結論と見なしてはいけません。端末のネットワーク通信、システムの動作、ほかのアプリも影響します。一時的なテストなら終了後に元の設定へ戻してください。長期間使う場合は、Configやネットワーク条件を変更した後に動作を再確認し、自動接続が明確な目的に役立っていることを確認します。

05 / Ping & Connectivity Test

Ping、Connectivity Testと結果の見方

まずテストの対象範囲を確認する

一般にPingは遅延テストを指す言葉として使われますが、実際のテスト方法はさまざまです。ネットワークの応答確認、トランスポート接続の確立、Proxy経由での接続先へのリクエストでは、確認する経路が異なります。テストを実行する前に、方法と接続先の設定を確認してください。ボタン名だけから、Proxy経路全体を検証できると判断しないでください。対象が同じでも方法が異なれば、結果をそのまま並べたり比較したりすることはできません。

画面にICMP、TCP、リクエスト型のテストがある場合、それぞれの範囲を理解してください。ICMPの応答確認では、プロキシプロトコルの認証は検証できません。TCP接続の確立では、暗号化やアプリケーションのリクエストまで確認できるとは限りません。リクエスト型のテストは接続先への実アクセスに近いものの、接続先サービスや名前解決の影響を受けます。利用可能なテスト方法、フィールド、選択肢は現在の画面で確認してください。本ページの説明に合わせるために、存在しないスイッチを探す必要はありません。

Connectivity Testでは、選択したテスト方法で接続できるかを確認します。すべてのWebサイト、プロトコル、利用時間帯での接続を保証するものではありません。1回成功しても、その時点のテスト条件で成功したことが分かるだけです。失敗した場合も、テスト先に到達できなかっただけで、サーバー全体が利用できないとは限りません。まず検証済みのテスト方法を使い、対象と経路を明確にします。必要がある場合に限り、方法や対象を変更してください。

テスト対象・タイムアウト・初期値

テスト対象の初期値、待機時間、その他のパラメーターは、まず現在のSettings画面で確認します。本ページでは一律のタイムアウト秒数を指定せず、タイムアウトを際限なく延ばすことも推奨しません。待ち時間が短すぎると一時的な変動を失敗と記録する場合があり、長すぎると到達不能な状態の判定に時間がかかります。同じ条件で比較できる値を選び、変更前後の結果を記録してください。テスト一覧に数字をすべて表示させることが目的ではありません。

テスト対象を指定できる場合は、ご自身にアクセス権があり、安定した検証に使えるアドレスを選び、画面の形式要件に合っていることを確認します。ドメイン欄、完全なURL欄、サーバーアドレス欄は混同できません。ログイン情報や個人情報を含むアドレスを、公開するトラブルシューティング資料に使わないでください。テスト対象でリダイレクト、認証、アクセス制限が発生すると、その条件も結果に含まれます。プロキシサーバーの通信遅延だけを示す値とは限りません。

複数の接続先を一括テストすると、同時に送信される探査がネットワークリソースを共有し、接続先側の応答方針の影響も受ける場合があります。一覧の結果は、サーバーの変わらない特性を示すものではありません。特定の接続先に問題がある場合は、個別にテストを繰り返し、実際のリクエスト結果と比較してください。大きなファイルをダウンロードしながら結果の差をサーバーのせいにしたり、1回の並べ替え結果でルーティングやプロトコル設定の確認を代用したりしないでください。

遅延・通信速度・安定性を分けて見る

応答時間が短くても、継続的な通信速度が高いとは限らず、長時間の接続が安定するとも限りません。応答時間は1回のやり取りにかかる時間を示します。継続的なデータ転送は、帯域幅、混雑状況、接続先の配信状況、プロトコルの動作にも左右されます。動画の停止やファイル転送の中断が問題なら、発生状況と時間を記録し、該当するリクエストのログを確認してください。Pingを繰り返すだけでは、こうした問題の原因を特定できません。

テストには失敗するが実際のアクセスは正常な場合は、テスト対象に特別な応答条件がないか確認し、正常なアクセス結果を比較材料として残します。テストは成功するのに実際のアクセスが失敗する場合は、サービスの対象ドメイン、ルールの一致、接続段階、応答内容を確認します。どちらの場合も、すぐにサブスクリプションを削除しないでください。「テスト手順の失敗」と「実際のサービスへのアクセス失敗」を分けてから、テスト設定と接続設定のどちらを変更する必要があるか判断します。

Hysteria2など特定のトランスポート条件に依存する接続では、TCPの応答確認で実際のトランスポート接続を検証できない点にも注意してください。プロトコルの動作条件についてはHysteria2とQUICの基礎解説をご覧ください。VMessとVLESSの項目確認についてはUUID、暗号化、トランスポート方式の解説を参照してください。テスト方法を変えても、誤ったプロトコル設定は修正されません。

最後に残すのは、具体的な問題に答えられるテストです。テスト数を増やすことが目的ではありません。問題が分かったら、一時的な対象とタイムアウトの変更を普段の検証済み設定に戻し、使用するテスト方法を選んだ理由を記録してください。同様の症状が起きた際に同じ条件を再現してから、診断範囲を広げるか判断できるようになり、毎回異なる条件でテストを始めずに済みます。

06 / Log & Data

Log、Data、段階別のトラブル記録

1回のリクエストを観察する

Logではリクエストと接続の過程を確認し、Dataではアプリが提供する通信量などの記録を確認します。表示内容、保存方法、画面へのアクセス方法は実際の画面で確認してください。通信量のカウントが増えても、接続先のページが正しく読み込まれたとは限りません。接続記録があっても、コンテンツの受信成功を示すわけではありません。ログは障害がどの段階で起きたかを把握するためのもので、記録の数だけでアプリが正常に動作しているか判断するものではありません。

トラブルシューティングの前に、現在のネットワーク、Global Routing、使用中のConfig、選択したサーバー、アクセスする接続先を順番に記録します。その後、判別できるリクエストを1回、または少数だけ実行してください。複数のアプリを同時に開いて何度も更新すると、システム通信、バックグラウンドのリクエスト、再試行がLogに混ざります。最新の行だけを見ると、無関係なリクエストの失敗を調査中のサービスの問題と誤認することもあります。

ログの詳細度や保存に関する設定がある場合は、現在の端末に表示された値を基準にします。まず問題を判断できる最低限の記録にし、必要な場合にだけ一時的に詳細度を上げてください。確認が終わったら普段の設定に戻します。詳細な記録を増やすと、扱う情報が増え、ストレージや処理リソースを多く使う場合があります。常に最も詳細な記録を残すことは、接続品質を高める設定ではありません。

リクエストの段階に沿って記録を読む

まずリクエスト先が正しいか確認し、名前解決、ルールとポリシーの一致、接続したサーバー、その後の結果の順に確認します。ログの形式によっては、これらの項目がすべて個別に表示されるとは限りません。それでも確認の順番は同じです。ある段階の情報がない場合は、証拠が不足していることを前提に、該当するテストを追加してください。概要だけのエラーから、接続経路全体を推測しないでください。

たとえば「接続タイムアウト」は、異なる接続先で起きる可能性があります。タイムアウトしたのがプロキシサーバー、名前解決先、接続先サービスのどれか確認してください。「認証失敗」の場合は、手元にある情報の認証項目と、意図したサーバーが選択されているかを優先して確認します。証明書に関する表示があった場合は、アドレス、名称、サーバー設定を照合してください。エラーを消すために検証をむやみに緩めてはいけません。エラー表示を隠すことと、接続を正しく修復することは別です。

ログに表示されるDIRECT、PROXY、REJECTは、一致したルールと合わせて解釈してください。DIRECTの場合は、意図した通信振り分けか確認します。REJECTの場合は、前にあるルールの条件が広すぎないか確認してください。想定外のリクエストをすべてPROXYに変更するのは避けましょう。ドメインの誤り、接続先サービスの状態、アプリ側の認証手順が原因の可能性もあります。

Dataのカウントとプライバシー

Dataに表示される統計は、まず集計対象と期間を確認してください。接続時間、累積通信量、特定のリクエストにかかった時間は、それぞれ異なる指標です。再接続、データの消去、画面の切り替え後には、集計方法も改めて確認する必要があります。アプリの数値をそのまま通信事業者の請求額と見なしたり、アップロード量が増えただけで異常だと判断したりしないでください。通常のバックグラウンド通信、再試行、実行中のテストを切り分けます。

ログにはドメイン、IPアドレス、サーバー識別情報、リクエスト情報が含まれる場合があります。エクスポートしたファイルにはさらに多くの状況情報が含まれることもあります。共有前に、パスワード、サブスクリプションURL、トークン、個人のアドレス、個人を特定できる情報を削除してください。UUIDはランダムな文字列に見えても接続用の認証情報である可能性があり、公開の質問欄にそのまま貼り付けてはいけません。エラーの種類、発生順序、個人情報を除いた項目だけを残すほうが、通常は安全に状況を説明できます。

ログを消去する前に、問題に直接関係する少量の記録、特に変更前後の比較を保存してください。失敗するたびにすべての記録を消して、記憶だけで状況を説明しないでください。再度記録する場合は、新しい開始点を決めて問題を1回だけ再現します。障害がまれにしか起きない場合は、条件と最後に正常だったときの条件を記録するほうが、目印のない大量のログを集めるより結論を導きやすくなります。

基本接続が成功しているのに特定のサービスだけ失敗する場合は、そのサービスに適用されるルールと応答条件を調べます。サーバーへの接続前にログが終わっている場合は、DNSとネットワークに戻って確認します。結果を「条件、操作、症状、証拠、元に戻した後の結果」の5項目にまとめると、本ページの各章に対応させやすくなります。さらによくある質問の症状別トラブルシューティングを使って原因を絞り込めます。

07 / Widget & iCloud

Widget、iCloud同期、Configのバックアップ

Widgetは操作の入口であり、独立した接続設定ではない

Widgetはアプリをすばやく操作したり、状態を表示したりするためのものです。追加できる種類、操作方法、表示内容は、アプリとシステムが現在サポートする機能によって異なります。Widgetに別のサーバー設定があるわけではなく、バックグラウンドの接続状態を確認する唯一の手段でもありません。WidgetとHomeの表示が異なる場合は、まずアプリを開いて接続状態を確認し、システムの表示が更新されているか調べてください。すぐにDNSやサーバーのポートを変更する必要はありません。

Widgetを追加する前に、アプリ内で接続と切断を正常に行えることを確認します。その後、システムの追加・編集手順に従い、Shadowrocketが提供する項目を選んでください。選択肢がある場合は、必要なものだけを選びます。画面に表示される初期項目は、現在の端末で確認してください。システムによる違いを設定不足と誤認しないよう、本ページではWidgetのサイズ、レイアウト、ボタン数を固定しません。

Widgetから操作した後は、Homeまたは実際のアクセス結果で状態を確認してください。端末のロック状態、システムの更新、アプリの状態によって表示が変わるタイミングは異なります。「Widgetの表示が変わらない」ことと「接続できていない」ことは分けて検証してください。アプリ内の操作が正常でWidgetだけが更新されない場合は、Widgetとシステム側の表示条件を確認します。アプリ内の操作も失敗する場合は、前述のネットワークとログの手順で調べてください。

iCloud同期は独立したバックアップではない

iCloud同期では、アカウントとシステムの条件を満たす場合に、アプリが対応するデータを同期できます。ただし、同期対象を名称から推測しないでください。実際の設定で対象項目と有効状態を確認し、2台の端末で条件を満たすiCloudアカウントを使っているか確認します。App Storeでの購入に使うアカウントと、システムで使うiCloudアカウントは、同じアカウントの概念とは限りません。アプリを再入手できても、Configが同期済みとは限りません。

まず内容が揃っている端末で現在の状態を確認し、その後でもう一方の端末を操作します。2台で同じ名前のConfigを同時に大幅変更すると、最後に表示された内容がどちらの端末から来たのか判別しにくくなります。オフラインだった端末が再接続した後は、反映された結果を再確認してください。同期が完了したかどうかは、同期オプションが有効かどうかだけで判断せず、ファイル内容、サーバー情報、実際の接続で確認します。

同期によって変更が反映されるため、同期を変化しない過去のバックアップとして扱うことはできません。誤って削除・変更した内容も、同期を通じて別の端末に反映される場合があります。ルールを大幅に変更する前にConfigのコピーを保存し、ご自身が管理できる場所で用途を記録してください。バックアップファイルを識別できるようにしつつ、パスワードや完全なサブスクリプションURLをファイル名に含めないでください。ファイル自体も機密情報として扱い、公開場所へ安易にアップロードしないでください。

エクスポート内容と移行後の再確認

Configを書き出したら、Settings、すべてのサーバー、システムの許可が1つのファイルにすべて含まれると思い込まず、コピーを開いて実際のセクションを確認してください。サブスクリプションの内容、手動で追加したサーバー、ローカルルールは別々に保存される場合があります。実際のエクスポート内容をアプリで確認してください。端末の移行前には、元のサブスクリプション情報、必要なサーバー設定、ローカルルールのコピーを用意し、それぞれを何の復元に使うか記録しておくと安心です。

復元後は、まずファイルの内容を確認し、使用中のConfig、Global Routing、選択中のサーバーを確認します。システムのVPN許可はシステム側の手順です。新しい端末に表示される案内に従って完了してください。テキスト形式のConfigで代替することはできません。次に手動接続を確認し、その後On DemandとWidgetを検証します。この順序なら、データの復元と自動接続の問題を切り分けられ、すべての機能を一度に戻したときの漠然とした失敗を避けられます。

古い端末は使えるのに新しい端末で接続できない場合、比較対象として古い端末の設定を維持してください。両端末のネットワーク、使用中のConfig、認証項目、同期結果を順に比較し、まず差異を見つけてから新しい端末を変更します。「同期を強制する」ために古い端末を先に消去しないでください。正常な状態を確認できる貴重な基準が失われます。アプリの入手に関するアカウントの問題は、Configの移行と分けて購入済みアプリの復元案内を確認してください。

データの整理方法と移行手順についてはiCloud同期、Configのエクスポート、端末移行の手順をご覧ください。購入済み項目の復元に使うアカウントについては端末移行後の再インストールと購入済み項目を参照してください。役割を分けて確認すれば、同期の問題を購入の問題と取り違えたり、不要な編集を繰り返したりせずに済みます。

08 / Verification & Recovery

設定の検証、障害の切り分け、復元手順

影響範囲に合わせて確認を始める

問題が起きたら、まず「すべての接続先で失敗するのか、一部の接続先だけなのか」を確認します。すべて失敗する場合は、端末の基本的なネットワーク接続、システムのVPN設定、現在のサーバー、認証条件を確認してください。一部だけ失敗する場合は、該当ドメインの名前解決、ルールとの一致、接続先からの応答を優先して調べます。「DNSとポートのどちらを変更するか」を先に決めるより、この切り分けのほうが重要です。次に集めるべき情報が変わるためです。

次に、問題が初回接続から発生しているのか、設定変更後に起きたのか、ネットワーク切り替え後に起きたのかを確認します。初回接続で失敗する場合は、手元にあるサーバー情報とプロトコル項目を確認します。設定変更後に起きた場合は、直近の変更を優先して元に戻します。ネットワーク切り替え後に起きた場合は、Configを変更せず、新しいネットワークへの接続と名前解決条件だけを確認してください。この3つを無計画な設定変更と一緒に扱うと、原因を特定する手がかりを失いやすくなります。

以前は接続できていて、Settingsの変更後に問題が起きた場合は、設定を追加し続けるより記録しておいた基準に戻すほうが有効です。一時的なOn Demand条件を無効にし、Global Routingを元に戻し、元のConfigとサーバーを選んで手動接続します。手順ごとに結果を記録してください。すべてを一度に復元すると「今は直った」ことは分かっても、原因が分からなくなります。

Configの断片を安全に比較に使う

次の例は、読みやすい部分的なConfigの構成を示すためのものです。関連する基本設定を[General]に、順序のあるルールを[Rule]に記述します。既存ファイルを置き換えるための推奨設定ではなく、サーバー接続に必要な情報もすべて含んでいません。実際に編集する場合は、コピーを開いて該当セクションを探してください。同じフィールドを重複して作らず、既存のポリシーや必要な設定を貼り付けによって削除しないように注意します。

[General]
dns-server = system

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

ルールを検証するには、新しいルールが関係するリクエストを1つ選び、一致結果を確認します。例示用ドメインは書式の説明に使うものであり、そのコンテンツが取得できるかどうかで、ご自身のサービスの状態を判断することはできません。新しいルールが一致しない場合は、使用中のConfigと前にあるルールを確認してください。一致していても接続に失敗する場合は、そのポリシーに対応する接続経路を調べます。ルールの構文が正しいこと、ポリシーが一致したこと、コンテンツ取得に成功したことは、別々の検証結果です。

最小限の復元と長期利用の判断基準

最小限の復元とは、すべてのデータを削除することではなく、説明可能で再現可能な手動接続経路をまず確保することです。有効なサーバー情報を残し、明確なルーティングモードと使用中のConfigを使い、自動接続や不要なテスト項目を一時的に減らします。それでも失敗する場合はログを使って原因を調べます。接続できた場合は、機能を1つずつ戻し、その都度同じ接続先で確認してください。

長期間使う設定を残す前に、次の3点を説明できるか確認します。どの具体的な目的に役立つか、動作をどう確認するか、問題が起きたときどう元に戻すか。答えられない場合は、さらに調整するより現在値を維持するほうが適切です。特にDNSの接続先、ローカルProxyの待ち受け、自動接続条件は、管理が必要な条件を増やします。他の人が使っているという理由だけで、ご自身の端末に追加しないでください。

トラブルシューティング中にアプリを再入手することを、最初の手順にしないでください。アプリはApp Storeから入手します。再インストールでは、購入済みアプリの再入手、Configのデータ、システムの許可など複数の要素が関係し、原因を調べるための状態が失われる可能性があります。解決したい問題が明確で、必要な情報を保存し、復元手順を理解している場合に限って検討してください。正規アプリのデベロッパーはShadow Launch Technology Limited、アプリIDは932747118です。確認方法は正規アプリを確認する3つのポイントをご覧ください。

問題を整理して詳しく調べる場合は、次の内容を簡潔に記録してください。使用したネットワーク、Global RoutingとConfig、実行した操作、発生した症状、ログが止まった段階、変更を元に戻した後の結果。サブスクリプション情報や認証項目を公開しないでください。この記録があれば、アプリの設定、手元にあるサーバー側の条件、接続先サービスの問題を切り分けやすくなります。「すべて試したが動かない」という説明より、原因の特定に役立ちます。

トラブルシューティングが終わったら、一時的なテスト対象を削除し、Logの詳細度を普段の設定に戻します。On DemandとWidgetが必要な動作になっていることを確認し、最終的なConfigのコピーを保存してください。以降は、サブスクリプションを更新したときやネットワークを変更したときに、影響する部分だけ再検証します。接続手順を最初から確認する場合は入門ガイドへ、症状ごとの原因を調べる場合はよくある質問へ進んでください。本ページの設定をすべて変更し直す必要はありません。