Shadowrocket
完全ガイド

App Storeでの入手と正規品の確認

まずApp Storeでの正規品確認ページを開き、アプリ名、デベロッパ、アプリIDを照合してから購入してください。ShadowrocketはAppleプラットフォーム向けの有料・クローズドソースアプリで、入手先はApp Storeのみです。以下の操作説明は主にiPhoneとiPadを対象としています。Mac、Apple TV、Apple Visionとの互換性、システム要件、ユニバーサル購入の適用範囲はApp Storeの掲載内容をご確認ください。デバイス名だけで利用可否を判断しないでください。

購入前に確認する3項目

App Storeの製品ページで、アプリ名がShadowrocketであることを確認し、アイコンが本サイトに掲載されている公式アイコンと一致するかを見てから、デベロッパ情報を確認してください。デベロッパ名はShadow Launch Technology Limitedです。検索結果には名称が似たアプリが表示されることがあるため、日本語の通称や検索順位だけで判断しないでください。アプリ名は識別の手掛かりになりますが、デベロッパ名とアプリIDを確認すれば、対象の製品をより確実に特定できます。

製品ページのリンクでid932747118を確認してください。この数字932747118はアプリIDであり、購入証明や現在のバージョンを示すものではありません。共有された製品ページのURLから同じアプリを特定することもできます。リンク先に別の製品が表示された場合は購入を中止し、確認ページから開き直してください。似たアイコンや説明文中のキーワード、他人から聞いた情報だけで判断しないでください。

購入内容とデバイスの条件を確認する

価格ボタン付近に表示される現在のストア価格を確認し、システムの購入確認に進んでください。米国ストアでは約2.99米ドルの買い切り価格です。実際の金額、税金、通貨表示はApp Storeの製品ページをご確認ください。購入対象はクライアントアプリの利用権であり、サーバーアカウントではありません。アプリの買い切り購入と接続サービスのプランは別です。接続には、ユーザー自身が用意したサブスクリプションまたはサーバー情報が引き続き必要です。本サイトではその情報の使い方を解説しますが、接続サービスは提供しません。

互換性欄で、現在のデバイスとシステムにインストールできるか確認してください。システム要件はApp Storeの掲載内容を基準にし、古いチュートリアルの数値で現在の利用可否を判断しないでください。ストアで購入できない場合は、アカウントの状態、支払い方法、ストアの利用状況を確認してください。これはストアでの決済に関する問題であり、アプリ内のAddress、Port、ルール分岐とは関係ありません。この段階でサーバー設定を変更しても、購入結果は変わりません。

インストール後に復元方法を確認する

インストールが完了したら、ホーム画面からShadowrocketを開き、正常に起動することを確認してから設定を読み込んでください。購入履歴はApp Storeアカウントに紐づいています。機種変更や再インストールの際は、同じ購入アカウントの購入済み項目を確認してください。ファミリー共有の対応状況、デバイス間での利用範囲、復元条件はApp Storeの掲載内容とアカウントに表示される情報をご確認ください。一度インストールできたからといって、すべてのデバイスでそのまま使えるとは限りません。

復元時は、購入資格とアプリ内データを分けて確認してください。購入履歴からクライアントアプリを再入手できても、サーバー一覧、サブスクリプションURL、ルールの変更内容、秘密鍵まで復元されるとは限りません。アプリが再び表示された後、それぞれの内容を確認してください。アプリだけが復元され、設定がない場合、Homeに利用可能なサーバーが表示されないのは通常の準備段階であり、購入が無効になったわけではありません。設定のバックアップと移行については、メンテナンスの章で説明します。

初回起動とVPN設定の権限

Shadowrocketを初めて開いたら、まずHome、Config、Data、Settingsの場所を確認してから、設定の読み込みや接続を行ってください。Homeでは主にサーバーの確認、項目の選択、接続の操作を行います。Configではルール分岐の設定を管理し、Dataでは通信量やリクエストの記録を確認できます。Settingsには動作に関する項目がまとめられています。デバイスによって画面のレイアウトが異なる場合があります。ボタンの位置ではなく、英語の画面表示を目印にしてください。

初回接続時にシステムの確認画面を操作する

Homeで接続スイッチをオンにすると、システムからVPN設定の追加を求められる場合があります。確認画面にShadowrocketが表示されていることを確認し、システムの手順に従って許可した後、デバイスの認証を完了してください。この権限により、クライアントがシステムのネットワーク拡張を設定し、現在のモードに応じてトンネルに流れる通信を処理できるようになります。サービスの接続資格を購入する操作ではなく、サーバー情報がリモートで検証済みであることを示すものでもありません。

許可を拒否した場合は、まずアプリに戻って再度接続し、許可の手順がもう一度表示されるか確認してください。それでも進めない場合は、システムのSettingsでVPN関連の設定を探し、該当項目があるか、管理上の制限がないか確認します。システム設定の階層はデバイスの環境によって異なるため、画面に表示される名称を手掛かりにしてください。用途が分からないネットワーク設定をまとめて削除しないでください。特に、仕事で使用している接続がデバイスに設定されている場合は注意が必要です。

設定の追加を許可した後、Homeで接続状態を確認してください。システム権限の許可によって解決するのは、デバイス上でネットワーク拡張を開始できるかどうかです。Address、Password、SNIなどの項目が自動で修正されるわけではありません。権限を許可しても接続できない場合は、権限を何度も取り消すのではなく、次の章でサーバー情報とネットワークを確認してください。システム権限とリモート認証を分けて考えると、誤った箇所で同じ操作を繰り返さずに済みます。

必要な権限と任意の機能を区別する

Scan QR Codeでユーザー自身が用意したサーバーのQRコードを読み取ると、カメラへのアクセスを求められる場合があります。この権限が必要なのはQRコードを読み取る場合だけです。手入力や既存リンクの貼り付けにカメラは必要ありません。読み取り後は、保存する前にプロトコルの種類と重要な項目を確認してください。QRコードにはサーバーの認証情報が含まれている場合があります。元画像を公開アルバムに保存したり、質問の際にそのままアップロードしたりしないでください。

クリップボードから読み込む際は、システムから貼り付けの許可を求められる場合があります。まず、コピーした内容が自分の設定情報であることを確認してから、今回の読み取りを許可してください。通常のWebページURLがサブスクリプションURLとは限りません。説明文をまとめてコピーした場合も認識できないことがあります。解析に失敗したら、元の情報に戻り、リンク全体をコピーし直してください。必要な句読点やエンコードを保ち、形式が分からないまま末尾の文字を削除しないでください。

デバイスの現在のネットワーク状態を確認する

初回確認の前に、デバイスが現在のWi-Fiまたはモバイル通信に正常に接続できることを確かめてください。Wi-FiにWeb認証が必要な場合は、Shadowrocketに接続する前に認証を済ませてからアプリに戻ってください。基礎となるネットワーク自体が使えないと、クライアントからのサーバーテストも失敗します。この順序で確認すれば、ローカルネットワークの接続問題とサーバーの問題を切り分けやすくなり、タイムアウトをすべて同じサブスクリプションのせいにせずに済みます。

デバイスにほかのVPN設定がある場合は、現在どの設定が有効かを確認してください。ネットワークを制御する複数の設定が互いに影響することがあります。トラブルの確認中は、今回のテストに必要な接続だけを有効にしてください。組織の管理下にあるデバイスには制限が設けられている場合があります。管理上のルールに従い、内容が分からないポリシーを変更しないでください。システムにVPNの表示が出るのはトンネル動作の手掛かりですが、利用可能かどうかはアプリの状態と実際のリクエストも確認する必要があります。

初回テストでは、On Demandをいったん無効にし、手動スイッチで接続と切断を一度ずつ行ってください。自動接続がネットワーク環境の変化に反応すると、手動操作が反映されていないように見える場合があります。手動接続が安定してから、Settingsで自動動作を一つずつ設定してください。状態が変わるたびに理由を確認できるため、後から自動再接続の原因も調べやすくなります。

既存のサーバー情報とサブスクリプションを追加する

まず、ユーザー自身が用意した情報が、単体サーバーの設定、サーバー共有リンク、サブスクリプションURL、ルール設定ファイルのどれに当たるかを確認し、適切な入口を選んでください。これらは別々の種類のデータです。サーバー情報はリモートへの接続方法を示し、サブスクリプションは複数のサーバー情報を更新するために使われます。設定ファイルはルール分岐などの動作設定を定義します。ルールファイルをサブスクリプションとして読み込んだり、製品紹介ページをサーバーリンクとして貼り付けたりすると、接続可能な項目ではなく解析エラーになることがあります。

Add Serverで項目を確認する

HomeのAdd ServerからTypeを選び、元の情報に従ってAddressとPortを入力してください。Addressは通常、ドメイン名またはIPアドレスです。任意のWebパスを付け加えないでください。Portはサーバー側の待ち受けポートであり、プロトコル名ではありません。続けて、選択した種類に必要なPassword、UUID、鍵などの認証情報を入力します。Typeを誤ると入力欄の構成が合わなくなり、アドレスとポートが正しくても意図したハンドシェイクを完了できません。

TLSを使用する場合は、サービス提供元の情報に従ってSNIと証明書の条件を確認してください。Addressは接続先、SNIはTLSハンドシェイクでサーバー名を識別するための情報です。同じ値の場合も異なる場合もあるため、機械的にコピーしないでください。証明書エラーが出たら、名称、デバイスの時刻、サーバー証明書を確認してください。Allow Insecureを通常の解決策として使用しないでください。各項目の詳細はTrojanの設定項目ガイドをご覧ください。

Subscribeとリンクから読み込む

サブスクリプションURLがある場合は、現在の画面にあるSubscribeまたはサブスクリプション追加の入口にURL全体を貼り付け、見分けやすい名前を付けて更新してください。Configページのリモート設定の入口では、ルール設定のURLを受け付けることもあります。入口がどちらもURLに対応しているからといって、データの種類を混同しないでください。読み込みが完了したら、想定したサーバーまたは設定項目が表示されることを確認します。Webページの内容だけが表示される場合は、実際のリソースURLではなく紹介ページをコピーしていないか確認してください。

サブスクリプションURLのクエリパラメーターは、認証に使われることがあります。大文字・小文字、エンコード、末尾の文字が意味を持つ場合もあります。コピー時に余分な空白や改行が入っていないか確認し、URL全体を保ってください。短くするためにパラメーターを削除しないでください。更新に失敗したら、ドメイン名の解決、リクエストのタイムアウト、認証拒否、コンテンツの解析失敗のどれかを記録します。原因に応じて確認箇所が異なります。同じURLを繰り返し追加しても、グループが重複するだけです。

単体の共有リンクは、アプリが対応するリンク認識、クリップボード、またはScan QR Codeから読み込めます。読み込み後に項目の詳細を開き、Type、Address、Port、認証情報がすべて正しく認識されているか確認してください。自動認識で手入力を減らせても、すべてのオプション項目がサーバーの要件に合うとは限りません。各入口の操作の違いはサブスクリプションとサーバー情報の読み込み方法をご覧ください。

保存後に管理しやすい一覧を整える

一覧から保存したサーバーを選択し、選択中のマークが目的の項目に移動したことを確認してからテストしてください。メモには用途や情報元を記載し、Passwordは名前に書かないことをおすすめします。サブスクリプションから作成された項目と手動で追加した項目は区別できるようにしてください。更新によって一部の項目が再生成される場合があり、生成された項目を直接編集しても変更が保持されないことがあります。長期的に維持する必要がある変更については、上書きの仕組みや個別保存の方法を先に確認してください。

最初に読み込むときは、情報元が明確な項目を一つだけ残し、内容が分からない設定を複数まとめて読み込まないでください。サービス提供元の情報に一部の項目しかない場合は、その情報元に確認し、認証方式やポート番号を推測しないでください。本サイトではサーバーやサブスクリプションを提供、販売、推奨していません。この章の終了時には、使用中のサーバー情報、元になった既存の資料、次回の更新に使う入口を説明できる状態にしてください。

Global Routingの3つのモードとルールの順序

HomeでGlobal Routingを開き、現在Config、Proxy、Directのどれが選択されているか確認してください。3つはそれぞれ設定、プロキシ、直接接続のモードに対応し、通信の処理方法を決めます。異なる3台のサーバーを指しているわけではありません。サーバーの選択は「プロキシ接続にどのサーバーを使うか」、Global Routingの選択は「各リクエストをどのように処理するか」を決めます。この2つを分けて考えると、同じサーバーを使っていてもWebサイトごとに結果が異なる理由を理解できます。

有効なConfigを確認する

Configページで現在有効な設定を確認し、必要に応じて内容を開いて確認してください。ファイル名だけでは判断できません。リストに表示されていても、そのファイルが有効とは限りません。Configモードでは通常、ルールが上から順に照合され、最初に一致したルールの処理方法が適用されます。そのため、具体的な条件を広い条件より前に置き、FINALは最後のフォールバックとして残してください。後続のルールが使われなくなるのを防げます。

以下は構文を説明するための.conf形式のルール例であり、サーバー情報を含む完全な設定ファイルではありません。example.comは説明用のドメイン、PROXYはプロキシポリシーの参照名です。使用時には、現在の設定でそのポリシーを認識できるか確認してください。この行をコピーしただけではサーバー情報は得られず、ユーザー自身が用意したサーバーにも自動で紐づきません。既存の内容をバックアップしてから、実際の設定構成に合わせて調整してください。

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

マッチ条件と処理方法を理解する

DOMAINは指定した完全一致のドメイン名に、DOMAIN-SUFFIXはドメインのサフィックスとそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで照合します。後者は対象範囲が広いため、一見珍しい単語だからといって誤一致しないとは限りません。IP-CIDRとIP-CIDR6はIPアドレスのネットワーク範囲で照合します。入力時はプレフィックス長を残してください。ドメイン名による判定とは別の条件です。

GEOIPはIPアドレスの地域情報データに基づいて照合するもので、Webサイトの言語や運営主体を判定するものではありません。1つのWebサイトが複数の分散IPアドレスからコンテンツを配信している場合があります。ページの言語が同じだからといって、すべてのリクエストが同じ地域に一致するとは限りません。DIRECTは直接接続、REJECTは拒否を意味します。その他のポリシー名は、設定内に定義されている必要があります。FINALは「すべてのルールを再確認する」という意味ではなく、それまでのルールに一致しなかった場合に使う最後の処理方法です。

ルールを照合して問題箇所を特定する

ある接続先がProxyでは正常でConfigでは失敗する場合、まずそのリクエストに一致したルールとポリシーを記録し、ルールの順序と条件を確認してください。Proxyで比較できる結果が得られているため、すぐにすべてのサーバーを変更する必要はありません。Proxyでも同じように失敗する場合は、サーバー、認証、TLS、ネットワーク条件を先に確認します。Directで接続できるかどうかは直接接続の結果を示すだけで、プロキシの設定が正しいことの証明にはなりません。

ルールを変更するときは一度に一項目だけ変更し、保存後、画面の案内に従って設定を有効にしてから対象へ再度リクエストしてください。既存の長時間接続では以前の経路が使われ続ける場合があり、ブラウザーのキャッシュも結果に影響します。必要に応じて対象ページを閉じてから再試行してください。ルールのテストでは、トップページのドメインだけでなく、問題が起きたサブドメインも確認します。ページ内の画像、API、ログインのリクエストが別のドメインで、異なるルールに一致する場合があります。

接続・確認と段階的なトラブルシューティング

Homeで確認済みのサーバーを選び、Global Routingを確認してから接続スイッチをオンにしてください。アプリの状態が変わるまで待ち、繰り返しテストできる、使い慣れた接続先にアクセスして実際のリクエスト記録を確認します。「スイッチがオン」「システムにVPN表示がある」「テストで数値が表示された」を一つの成功判定にまとめないでください。それぞれ、アプリの動作状態、システムのトンネル状態、特定のテスト条件での結果を示しています。

テスト結果と実際のアクセスを分けて確認する

Connectivity Testを実行すると、現在のテスト方法で選択中のサーバーが応答するか確認できます。テスト対象、プロトコルの対応状況、ネットワーク環境が結果に影響します。一度の所要時間がすべてのWebサイトの速度を示すわけではなく、テスト失敗だけであらゆるリクエストが利用できないとも判断できません。テストが正常でWebページが開かない場合は、テストを繰り返すのではなく、対象ドメイン、ルール分岐、アプリ内の実際のリクエストを確認してください。

検証時は、同じデバイス、同じネットワーク、同じサーバー、同じリクエストを使ってください。まずConfigモードでの結果を記録し、ルールの影響を切り分ける必要がある場合だけ、一時的にProxyへ切り替えて比較します。テスト後は元の設定に戻してください。ネットワーク、サーバー、DNSを同時に変更すると、結果が改善してもどの変更が効いたのか分からず、次の問題で再利用できる判断材料が残りません。

問題が発生した段階に応じて確認する

接続スイッチがすぐにオフへ戻る場合は、システム権限、ネットワーク拡張の起動、ローカル設定のエラーで止まっていないか確認してください。VPN設定が存在し、デバイスで有効化できることを確かめた後、設定の解析エラーやポリシーの参照エラーがアプリに表示されていないか確認します。この段階では、リクエストが安定した状態のクライアントに届いていない可能性があるため、特定のWebサイトのルールを調べる必要はありません。「開けない」とだけ記すより、エラーの原文を残すほうが原因を切り分けやすくなります。

スイッチがオンのままでもすべての接続先にアクセスできない場合は、基礎となるネットワークを確認し、サーバーのAddress、Port、認証情報、稼働状況を調べてください。接続タイムアウトは、制限時間内に処理が完了しなかったことを示しますが、Passwordの誤りを直接示すものではありません。認証拒否の場合は、アカウントまたは設定の問題が考えられます。TLSエラーが出たら、SNI、証明書の名称、デバイスの時刻を確認してください。「失敗」のアイコンだけで原因を判断しないでください。

一部の接続先だけ失敗する場合は、記録から該当する接続先と関連するサブドメインを探し、選択されたポリシーが想定どおりか確認してください。トップページが表示されても、画像やログインに失敗する場合は、リクエストごとに異なる経路が使われていることがあります。また、サービス側から返されたエラーとネットワークエラーを区別してください。アカウントの利用権限に関するページが返されているなら、少なくとも一部の接続は完了しています。本機のVPN権限を何度も確認する必要はありません。

再現に必要な最小限の記録を残す

問題が発生した時間帯、Wi-Fiまたはモバイル通信の環境、現在のモード、接続先ドメイン、エラーの種類を記録してください。ログにサブスクリプションURL、認証情報、秘密鍵、リクエスト全体のパラメーターが含まれている場合は、共有する前に機密部分を隠してください。初期判断には、通常、プロトコルの種類とエラーが起きた段階が分かれば十分です。設定全体を公開する必要はありません。調査後は不要なアクセス記録が長期間残らないよう、一時的に有効にした詳細記録をオフにしてください。

ネットワークを切り替えた後は、接続とリクエストを改めて実行してください。切り替え前の結果を現在の状態として扱わないでください。プロトコルによっては転送条件が必要です。あるネットワークで使えたからといって、別のネットワークでも使えるとは限りません。問題を再現できない場合は、直近で動作を確認できた設定に戻し、変更点を記録してから一項目ずつ再度試してください。操作の流れは接続と確認のチュートリアルで確認できます。この章の目的は原因を絞り込むことであり、すべての設定を一度に変更することではありません。

Dataの通信量とリクエスト記録

接続後にDataを開き、画面に表示されている集計範囲を確認してから、アップロード、ダウンロード、リクエストの変化を観察してください。ここに表示されるデータは、クライアントから見える現在のネットワーク動作を把握するためのもので、通信事業者の請求明細と同じものではありません。また、デバイス上のすべての通信が含まれるとは限りません。カウンターはセッション、動作中の期間、または画面に表示される期間ごとに集計される場合があります。数値を解釈する前に単位と範囲を確認し、合計値だけから特定のアプリの通信量を推測しないでください。

通信方向・単位・時間範囲を確認する

アップロードはデバイスから外部へ送信されたデータ、ダウンロードは外部から受信したデータです。速度は一定時間の変化量、累積量は観察範囲内の合計値であり、直接比較できません。Webページの読み込み後に速度が下がるのは、今回の通信が完了しただけの場合があります。接続が切れたとは限りません。バックグラウンド同期によって少量の通信が発生することもあるため、操作中でなくても数値がわずかに変化するだけで異常とは判断できません。

調査を始める前に、現在の数値を記録するか、画面で用意されているリセット方法を使って新しい観察区間を設定し、目的の操作を一つだけ行ってください。完了後に数値の変化を比べれば、今回のリクエストとそれ以前のバックグラウンド通信を区別できます。画面に集計期間が明示されていない場合、独自に「今月の使用量」と呼ばないでください。課金の確認には、サービス提供元または通信事業者のアカウント記録を参照してください。クライアントの一部の統計だけを根拠にしないでください。

リクエスト記録からルールの適用結果を確認する

Dataまたはリクエスト記録の入口で、直前にアクセスしたドメインを探し、現在の画面に表示されている接続先、ポリシー、マッチ情報、エラーを確認します。記録される項目は、実際の画面や有効な記録オプションによって異なります。すべての詳細が各記録に含まれるとは限りません。まず、リクエストが記録に現れたか、どの経路が使われたか、どの段階で終了したかを確認してください。記録にリクエストが確認できてから、具体的なルールの分析に進みます。

想定したリクエストが見つからない場合は、対象アプリが新しい接続を実際に開始したか確認してください。ブラウザーのキャッシュ、既存接続の再利用、ページを再読み込みしていないことなどにより、操作したように見えても新たなネットワーク記録が作られない場合があります。対象ページを閉じて再試行するか、確実にネットワーク通信が発生する操作を行ってください。記録のフィルター条件も確認します。エラーや特定のポリシーだけが表示されている場合、ほかのリクエストがクライアントを通っていないと誤解することがあります。

DIRECTが表示されても、必ずしも故障ではありません。現在のGlobal Routingと一致した条件を踏まえて判断してください。Configモードで直接接続になった場合、ルール設計どおりの結果である可能性があります。Proxyモードでの挙動は、対象範囲と実際の記録をあわせて確認してください。ルールに一致したことが示すのは選択された経路であり、接続先サーバーがリクエストに応答する保証ではありません。「ルールが意図どおり経路を選んだか」と「接続先が正常な応答を返したか」を別々に確認すると、誤判定を防げます。

同じ操作を繰り返して通信量の違いを調べる

ある操作の通信量が異常に多いと感じたら、同じ接続先、同じ操作でテストを繰り返し、記録されたリクエスト数、再試行、接続時間を比較してください。動画、画像、同期タスクではデータ量が異なるため、テキストページの読み込みと動画再生を比較することはできません。失敗によってリクエストが繰り返されると、累積通信量が増える場合があります。通信量が増えたことは、目的の処理が完了したことを意味しません。

統計値がリモートアカウントの通信量と異なる場合は、集計時間、アップロードとダウンロードの合算方法、プロトコルのオーバーヘッドを確認してください。クライアントが表示するのはクライアント側の範囲内で処理した通信量であり、リモート側では異なる基準で集計している場合があります。差があるだけで記録の誤りと判断したり、ルール分岐を変えれば両方の数値が一致すると考えたりしないでください。同じ時間範囲の記録を残し、集計方法を既存サービスの情報元に確認してください。

アクセス記録の保存と共有を慎重に行う

リクエスト記録から、アクセス先、時間、一部のURLパラメーターが分かる場合があります。慎重に扱ってください。調査では問題に関係する期間だけを残し、共有する前に個人情報、サブスクリプションの認証情報、無関係なドメインを隠します。設定内のサーバー名に個人的な用途が記載されている場合もあります。スクリーンショットや書き出しの前に確認してください。記録を消去するとトラブルの調査に必要な情報も失われるため、必要な部分を匿名化して控えてから削除します。

Settings、DNS、On Demand

Settingsを開く前に、正常に接続できたときの条件を記録し、解決したい問題を明確にしてください。Settingsの項目は設定ファイルとあわせて動作に影響する場合があり、一部はプロトコルやデバイスの条件によって利用可否が変わります。実際の画面に表示された項目を基準に、説明を確認してから変更してください。画面を「設定済み」に見せるためだけにすべての項目を有効にする必要はありません。使わない機能を事前に調整しないでください。

DNSの名前解決の仕組みを理解する

DNS関連の項目を探す際は、システムのDNS、カスタムDNS、設定ファイル内の指定のどれを使っているか確認してください。DNSはドメイン名をIPアドレスに変換します。ルールはドメイン名と名前解決の結果の両方を参照することがあるため、DNSの問題がWebページにアクセスできない原因になったり、IPベースのルール判定に影響したりする場合があります。DNSを変更する前に、ドメインの名前解決に失敗しているのか、サーバーへの接続に失敗しているのかを切り分けてください。DNSの接続先を変えただけで、サーバーの接続問題が自動的に解決するわけではありません。

システムDNSを選択した場合、結果は現在のネットワークが提供する名前解決の条件に左右されます。カスタムDNSでは、既存の接続経路からDNSサーバーに到達できることを確認してください。DNS over HTTPSはHTTPSを使って問い合わせを送信しますが、接続先のサービス自体に到達できる必要があります。初回接続時にはドメイン名の解決が必要になる場合もあります。暗号化された転送方式を有効にしただけですべての名前解決が正しいと考えず、実際の問い合わせ結果を確認してください。

DNSをテストするときは、一度に変更する設定を一つにし、変更前の値を記録してから対象へのリクエストをやり直してください。必要に応じてアプリが提供する方法で関連キャッシュを消去するか、再接続します。以前の結果が判断に影響しないようにしてください。特定のドメインだけで問題が起き、ほかは正常な場合は、そのドメインと関連リクエストを確認します。すべてのDNS設定を一度に変更しないでください。具体的な設定方針はDNS設定ガイドをご覧ください。

手動接続が安定してからOn Demandを有効にする

On Demandの設定画面で起動条件を確認し、自動接続または接続の維持が必要なネットワーク環境を設定してください。On Demandが決めるのは接続を開始するタイミングであり、サーバー認証の可否を決めるものでも、Global Routingの代わりになるものでもありません。手動接続が安定する前に自動動作を有効にすると、状態変化の原因が分かりにくくなります。まず手動接続、動作確認、切断を一度行い、その後On Demandの条件を追加して個別にテストしてください。

設定後は予定した方法でネットワークを一度切り替え、想定した動作が起きるか確認してください。切断後に自動再接続する場合は、すぐにスイッチの故障と判断せず、On Demandの条件を確認します。トラブル調査のため接続状態を維持したい場合は、該当する自動動作を一時停止してからシステムの状態を観察してください。ネットワークの変化、デバイスのスリープ、アプリのバックグラウンド移行では条件が異なります。一度動作しただけで、あらゆる状況を確認できたとは限りません。

転送設定や詳細項目を慎重に変更する

特定のプロトコルに関係する問題がある場合に限り、サーバー設定または設定ファイルの詳細項目を確認してください。MTUは一度に送信できるデータ量に影響します。値が大きすぎると一部の経路で問題が起き、小さすぎると通信のオーバーヘッドが増える場合があります。根拠がないまま他人の数値をそのまま設定しないでください。WireGuardを使用する場合は、Allowed IPsとアプリのルールが適用される範囲の違いも確認してください。詳しくはWireGuardの設定項目ガイドをご覧ください。

証明書やTLSに関する設定では、接続先の識別情報を検証する意味を保ってください。証明書エラーが出たら、名称、有効期限、デバイスの時刻を確認します。検証を無効にすると信頼条件が変わるため、通常の高速化手段として使わないでください。追加の証明書信頼、リクエストの書き換え、コンテンツ処理などの高度な機能は、このガイドで基本接続を確立するために必要な手順ではありません。影響範囲が分からない場合は、複雑な設定をそのまままねるより、現在動作している設定を維持するほうが管理しやすくなります。

設定の上書きと反映のタイミングを確認する

変更後はConfigに戻り、別のファイルに切り替わっていないか確認してから、画面の案内に従って保存または再接続してください。設定によっては新しいリクエストから反映されるものもあれば、接続を再確立しないと反映されないものもあります。以前から開いているページに同じ結果が表示されているだけで、保存に失敗したと判断しないでください。ファイルの更新後に設定が元へ戻った場合は、同じ箇所を繰り返し編集する前に、リモート設定によって上書きされたか確認してください。

サブスクリプションの更新、バックアップ、日常のメンテナンス

日常の利用では、動作を確認した設定を一つ保持し、必要に応じてサブスクリプションやアプリを更新してください。メンテナンスは、定期的にすべての設定を変更することではありません。情報元、変更内容、結果を追跡できる状態に保つことが大切です。変更のたびに、何を変更したのか、なぜ変更したのか、どうすれば元に戻せるのかを説明できるようにしてください。接続状況に変化があったとき、最初のインストール時から調べ直さず、直近の変更から確認できます。

3種類の更新を区別する

サブスクリプションの入口で更新するのはサーバー情報です。項目数、アドレス、認証情報、メモが変わる場合があります。Configでリモートファイルを更新すると、ルールや動作設定が変わる場合があります。App Storeでアプリを更新すると、クライアント自体が更新されます。この3種類の操作は互いに代替できません。サブスクリプションの更新が成功してもルール設定ファイルが更新されたとは限らず、アプリを更新しても期限切れのサーバー認証情報が有効に戻るわけではありません。

既存のサブスクリプションを更新する前に、URLがユーザー自身のサービス情報に由来することを確認し、現在選択中の項目を記録してください。更新後は、グループ、サーバー情報、選択状態を確認してから、同じ接続先でテストします。以前の項目がなくなった場合は、サービス情報に変更がないか確認してください。古い名前を恒久的な識別子として扱わないでください。更新に失敗した場合は具体的なエラーを残し、リソースの取得に失敗したのか、内容の解析に失敗したのかを判断します。まだ使える一覧をすぐに削除しないでください。

バックアップでは秘密情報と通常の説明を区別する

アプリが提供する書き出しやバックアップの方法を使う前に、どのデータが含まれるか確認してください。ルールファイル、サーバー情報、サブスクリプションURL、秘密鍵が別々に保存される場合があります。一つのファイルを書き出しただけで、すべてのデータが含まれているとは限りません。バックアップ後は、保存範囲と保存先を確認し、復元できる状態であることを確かめてください。重要な復元手順は、機器変更の後に初めて試すのではなく、現在の設定に影響しない方法で事前に検証してください。

バックアップにはPassword、UUID、Private Key、認証情報を含むサブスクリプションURLが含まれる場合があります。適切なアクセス保護があり、ユーザー自身が管理する場所に保存してください。ルールを説明する際は必要な部分だけを提示し、バックアップ全体をそのまま他人に送らないでください。説明用ドメインは公開できますが、実際の認証情報は設定テキストに含まれていても通常の説明として扱えません。認証情報が漏えいした疑いがある場合は、元のサービスの情報管理画面で無効化や再発行を行ってください。

機種変更や再インストール後の復元手順

新しいデバイスでは、まずApp Storeの購入済み項目からShadowrocketを再入手し、デバイスの互換性を確認してアプリを開いてから、既存のバックアップを読み込んでください。購入資格の復元と設定の復元は別の段階です。前者はストアアカウント、後者は保存したデータに依存します。読み込み後は権限、サーバーの選択、Global Routing、有効なConfigを改めて確認してください。以前のデバイスに設定されていたシステム権限が、新しいデバイスにもそのまま引き継がれるとは限りません。

復元後は、まず手動接続で正常なリクエストとルールの適用結果を確認してから、On Demandなどの自動動作を有効にしてください。バックアップが古い場合は、サーバーの認証情報がまだ有効か確認します。サブスクリプションを更新する必要がある場合は、更新後に選択中の項目をもう一度確認してください。新しいデバイスで検証が完了し、必要なデータを復元できると確認するまでは、古いデバイスの記録をすべて削除しないでください。その後、個人データの管理方針に応じて古いデータを処理してください。

変更前後の記録を簡潔に残す

個人用のメモに変更日、対象、確認結果を記録できますが、PasswordやサブスクリプションURL全体は書き込まないでください。「DOMAIN-SUFFIXのポリシーを変更した後、対象のAPIが復旧した」という記録は、「設定を変更した」だけより役立ちます。問題が再発したら、まずこれらの変更点を照らし合わせ、接続トラブルの確認を参照しながら、権限、ネットワーク、サーバー、ルール、接続先サービスの順に範囲を絞ってください。

長期間使用していなかった場合は、再接続する前に基礎ネットワークとApp Storeでのアプリの状態を確認し、既存のサービス情報も照合してください。過去のテスト結果が現在の条件でも有効だと考えたり、画面のレイアウトが変わっただけで設定をすべて作り直したりしないでください。画面の入口が変わった場合は、英語の表示を手掛かりに機能を探してください。設定項目の意味が変わっていなければ、本ガイドの判断方法を引き続き利用できます。使用できる項目は現在のアプリ画面で確認してください。

メンテナンス後は、必要最小限の状態に戻してください。選択中のサーバーが明確で、有効な設定ファイルが分かり、テスト結果を再現でき、一時的な記録の処理が済んでいることを確認します。初回操作を続けて確認する場合はクイックスタートガイドへ、プロトコルの背景を調べる場合は技術ノートへ進んでください。本ガイドでは各段階の役割を説明します。ユーザー自身のサービスに関するアカウント管理や設定情報に代わるものではありません。