Settingsの設定項目ガイド

01 · Settingsと現在の状態を確認する

設定のトラブルシューティングでは、すべてを初期値に戻すのではなく、同じ手順で再確認できる基準を作ることから始めます。まずHomeで選択中のサーバーを確認し、Global Routingの状態とConfigで実際に有効な設定を見ます。Settingsの変更は、この条件と合わせて確認して初めて意味を持ちます。同じDNS値でも、ネットワーク、ルール、サーバーが異なれば結果は変わることがあります。3項目を記録してから変更する設定画面を開き、変更前の値、変更理由、テスト結果を残してください。

初期値、現在値、推奨値はそれぞれ異なる

初期値とは、特定の初期条件でアプリが採用する値です。現在値は、手動変更、設定の読み込み、以前の復元によって変わっている場合があります。使用済みの端末では、スイッチの位置だけを見て出荷時の状態を判断できません。本ガイドでは、すべての端末で確認できない数値を共通の初期値として記載しません。スイッチ、ポート、テスト方法は、まず端末に表示されている内容を確認してください。推奨値は用途に合った選択肢であり、あらゆるネットワークで速くなることを保証するものではありません。

初期状態の動作を確認する場合は、該当項目のアプリ内説明を先に読み、有効な設定ファイルに関連する指示が含まれているか確認してください。「まっさらな状態」にするために、すべての設定をすぐ削除しないでください。削除すると、復元に使うサーバー情報やルール、グループ情報まで失う可能性があります。まず既存の内容をバックアップし、テスト用に設定を複製して、普段使う設定との違いを記録する方法が安全です。

Global Routingの3つのモードを区別する

Configは現在の設定に含まれるルールに従ってリクエストの経路を決めます。Proxyはこのモードのプロキシ経由で通信を処理し、Directは直接接続します。これらは通信の処理方法の違いであり、速度のランクではありません。普段ルールで通信を振り分ける場合は、通常Configから確認します。ルールの影響を切り分けるには、一時的にモードを切り替えて同じ宛先を比較できますが、テスト後は元の状態に戻してください。モードを切り替えても、誤ったサーバー情報は修正されません。

一度に変更するのは1つの条件だけ

同じ操作を繰り返せるテスト対象のページを1つ決め、ネットワークの種類、接続状態、失敗時の状況を記録します。設定を1つ変更したら、必要に応じて再接続し、新たにリクエストを送信してください。サーバー、DNS、ルールを同時に変更すると、アクセスが回復してもどの変更が効いたのか判断できません。元に戻す場合は、変更した順に1つずつ戻し、新しい設定を重ねないようにします。結果は「どの手順が成功したか」を具体的に記録し、「問題なさそう」とだけ書かないようにしてください。

アプリ全体に適用される設定と、個別の設定ファイルに適用される設定も区別してください。Settingsに表示される全体設定、Configファイル内の指示、個別サーバーのパラメーターは、必ずしも同じ階層ではありません。変更が期待どおりに反映されない場合は、使用中の対象を変更したか確認し、アプリ内説明に記載された適用範囲を調べてください。同じ名前の設定が単純に上書きし合うとは限りません。また、無効な設定ファイルの内容を現在の動作状態と混同しないでください。

画面上の項目名が本文と多少異なる場合は、機能とアプリ内説明を照らし合わせてください。名称が似ているだけで変更しないようにしましょう。初回操作の詳しい手順はチュートリアル、症状から対処方法を探す場合はよくある質問とトラブルシューティングをご覧ください。以降の各セクションでは、「現在の状態を確認、最小限の変更、実際に検証、失敗したら元に戻す」という順で説明します。

02 · DNS：名前解決の経路とルールを確認する

DNSはドメイン名を接続に使うアドレスへ変換します。名前解決に成功しても、その後の接続が成功するとは限りません。また、接続できても、想定した経路で名前解決されたとは限りません。DNSを調べるときは、ドメイン名、名前解決の結果、その後に適用されるポリシーを合わせて確認してください。まず現在のConfigにDNS関連の指示が含まれているか確認し、次にSettingsで利用できるDNS項目と説明を見ます。ブラウザーに表示されたエラーだけを根拠に、DNS設定をすべて変更しないでください。

設定を一括で置き換えず、現在使えている状態から確認する

端末に表示されている現在値は、トラブルシューティングの基準として扱い、初期値と決めつけないでください。設定によって、名前解決サーバー、問い合わせ方法、ドメインの処理条件が異なることがあります。現在の設定で問題なく名前解決できているなら、まずそのまま使うことをおすすめします。再現性のある名前解決の失敗、想定外のアドレスが返る場合、または特定のネットワーク条件が必要な場合に限って、対象を絞って変更してください。手入力するアドレスを増やしても、信頼性が高まるとは限りません。

学校、職場などの管理されたネットワークでは、内部ドメインの名前解決にネットワーク側から提供される情報が必要な場合があります。すべてのリクエストを別のDNSサーバーに送ると、内部サイトにアクセスできなくなる可能性があります。一方、現在のネットワークから特定のDNSサーバーに接続できない場合、リクエストが遅くなることもあります。「DNSサーバーに接続できない」のか、「サーバーから想定外の結果が返る」のかを区別してください。待ち時間だけを根拠に判断せず、状況に合わせて対処する必要があります。

ドメインルールとアドレスルールは用途が異なる

DOMAIN-SUFFIXはドメインの末尾に基づいて照合し、GEOIPはアドレスに対応する地理情報に基づいて判定します。照合する対象が異なるため、互いに完全な代替として扱うことはできません。通常、ルールは記述順に照合されるため、より具体的なドメインルールを適切な位置に置き、FINALを末尾の最終ポリシーとして設定します。以下の例は順序を説明するもので、個人の設定ファイル全体を置き換えるものではありません。PROXYは現在の設定で認識されるポリシー名である必要があります。

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

この例では、まずexample.comとそのサブドメインを処理し、次にアドレス条件を確認して、残りのリクエストを末尾のポリシーに渡します。DIRECTとPROXYのどちらを選ぶかは、利用目的と現在の設定に応じて決めてください。例をコピーするだけで特定のサイトにアクセスできるとは限りません。名前解決の問題を隠すために、すべてのドメインを同じポリシーにまとめるのも避けてください。指定したサイトだけをプロキシ経由にする方法は、DOMAIN-SUFFIXの設定と検証をご覧ください。

段階を分けて検証し、キャッシュの影響を抑える

まず同じドメインで問題を再現し、リクエストの記録からアドレスが取得されたか、どのルールに一致したか、どの段階で接続に失敗したかを確認します。DNSを変更したら、新しいリクエストを送信してください。既存の接続では変更前の名前解決結果が使われる場合があり、ブラウザーやシステムにキャッシュが残ることもあります。必要に応じて該当ページを閉じて開き直し、アプリの案内に沿って接続を再確立してください。ページを一度再読み込みしただけで、すべてのキャッシュが消去されたと判断しないでください。

失敗するドメインが1つだけなら、入力ミス、ドメインルール、アクセス先そのものを先に確認します。ほとんどのドメインで名前解決できない場合は、DNSサーバーへの到達性とネットワーク状態を確認してください。アドレスを取得できても接続時に失敗するなら、サーバー、TLS、ルーティング、アクセス先のサービスを調べます。DNSを繰り返し変更しても解決しません。アドレスを直接入力してアクセスする方法も、必ずしも比較対象にはなりません。HTTPSサイトでは正しいドメイン名と証明書の検証が必要な場合があります。

同じネットワーク、同じサーバー、同じドメインを使い、確認するDNS設定だけを変更した成功例と失敗例を記録してください。ネットワークを変えてテストする場合は、変更したネットワークも別に記録します。内部ドメインに問題が起きたときは、まず元の名前解決条件に戻して確認してください。広範囲で失敗する場合は、最後に変更した設定を元に戻します。結果をLogの記録と時刻で照合すれば、アドレスを何度も切り替えるより原因を特定しやすくなります。

03 · On Demand：条件に応じた接続と手動操作

On Demandは、システムがサポートする条件に応じてVPN接続を開始または管理する機能です。接続を試みるタイミングを扱うもので、特定のサイトに適用するルールを選んだり、利用できないサーバーを自動修復したりはしません。使用する前に、まず手動で安定して接続できる状態にしてください。自分の設定を読み込み、選択中のサーバーが使えること、Global Routingの状態、実際のアクセスを確認します。手動接続に失敗している場合は、条件を増やすことになる自動接続を先に有効にするのは避けてください。

有効にする前に現在の状態と条件を確認する

該当する設定を開き、まず全体のスイッチと既存の条件を記録してから、各条件が適用される範囲を確認してください。現在の状態は以前の設定を引き継いでいることがあるため、アプリを開き直しただけで初期状態に戻ったとは判断できません。ネットワークや条件ごとの項目が表示される場合は、1つずつ確認してください。表示されていない機能を、別の端末のスクリーンショットから推測しないようにします。自動接続が必要な場面だけに適用するため、まず条件を最小限にしてください。

条件が満たされてから接続が成功するまでには、いくつかの段階があります。システムが条件を認識し、接続を許可し、ネットワーク経路を確立した後、クライアントがサーバーに接続します。現在のネットワークでまだ有効なアドレスを取得できていない場合や、先にネットワークへのログインが必要な場合は、自動接続も一時的に失敗することがあります。On Demandが有効だからといって接続が常に成功するわけではなく、リクエストが必ず想定どおりに処理される保証にもなりません。

ネットワーク切り替え時の確認方法

まず利用可能なWi-Fi環境で動作を確認し、次に別のネットワークへ切り替えて、VPNとアプリ内の接続状態が条件どおりに変わるかを確認してください。切り替え後はネットワーク接続が完了するまで待ち、新しいアクセスを1回試します。既存の接続が中断後に再確立されることがあり、バックグラウンドのアプリに古い状態が残る場合もあります。切り替え前から開いているページが見えるかだけではなく、新しいリクエストと現在の記録を基準にしてください。

条件にWi-Fi名が含まれる場合は、大文字と小文字、空白、見分けにくい文字を含め、名前が完全に一致しているか確認してください。同じ名前でも信頼できるネットワークとは限らないため、名前の条件だけで本人やネットワークを認証することはできません。端末に設定されている別のVPNや管理ポリシーも、接続結果に影響することがあります。接続が切り替わり続ける場合は、どの設定が現在の接続を管理しているかを確認してください。

手動切断と自動接続の条件を区別する

On Demandを有効にしている場合、手動で切断する操作と、その後に接続条件が再び満たされることは別のイベントです。切断後に再接続した場合は、まずOn Demandの条件を確認し、スイッチの不具合と決めつけないでください。オフライン状態を明確に調べるには、該当する自動接続を一時的に無効にしてから手動で切断し、システムとアプリの状態を確認します。調査後は記録に沿って設定を戻し、一時的に変更した接続条件を忘れないようにしてください。

システム権限、端末管理の制限、現在のネットワーク状態は、いずれもOn Demandの動作に影響する場合があります。画面にVPN設定の処理を求めるメッセージが表示されたら、システムの案内を読んでから操作してください。表示元が分からないまま、確認を繰り返さないでください。初回の許可と、その後の自動接続は別のものです。設定が存在していても、すべての条件が有効とは限りません。現在の状態を確認できない場合は、手動接続に戻して基本ネットワークとサーバー情報を検証してください。

推奨設定は自動接続が必要かどうかで決まり、一律に有効化するものではありません。ルールを頻繁に手動でテストする場合は、影響を減らすため手動操作のままにしておく方法があります。安定した設定があり、特定の条件で自動接続する必要がある場合は、有効にして条件を1つずつ検証してください。操作回数を減らすために、一度に多くの条件を追加しないでください。追加する条件ごとに、どの場面で使い、意図しない接続が起きたときにどう解除するかを明確にします。

接続が不安定な場合は、発生前に画面をロックしたか、ネットワークを切り替えたか、ネットワークへのログインを完了したかを記録し、Logでの診断と照らし合わせてください。接続ボタンを何度も押すと、確認に必要な情報が増えてしまいます。自動接続を一時的に無効にして手動接続を1回再現すれば、ネットワーク、サーバー、接続条件の3つに分けて調べやすくなります。

04 · PingとConnectivity Test：測定結果の見方

PingとConnectivity Testは、異なる段階の到達性を確認する機能です。テスト結果が、あらゆる実際のアクセスを保証するものではありません。まず現在のテスト方式、対象、タイムアウトの設定を確認してから結果を解釈してください。似た名前のテストでも確認する段階は異なります。ホストやポートへの到達性を測るものもあれば、プロキシ経由でリクエストを送るものもあります。端末に表示される項目の説明を読み、表示されたミリ秒をすべて同じ種類の遅延と見なさないでください。

数値を比べる前に、測定対象を確認する

1回の測定結果は、特定のネットワークと対象における状態を示します。サーバーアドレスへのテストと、そのサーバー経由でウェブページにアクセスするテストでは、確認できる範囲が異なります。前者の成功は、その経路の一部に到達できたことを示すにすぎません。後者では、ドメインの名前解決、プロトコルのハンドシェイク、アクセス先のサービスも影響する場合があります。方式や対象が異なる測定結果をそのまま順位付けしたり、小さい数値ならすべてのアプリが速くなると考えたりしないでください。

現在の値が変更されている可能性があり、利用できる項目もアプリの表示に依存するため、本ガイドでは共通のタイムアウトやテスト対象を指定しません。まず現在使える方法を維持し、繰り返しテストして基準を作ってください。調整が必要な場合は、同じ対象でネットワークだけを変える、または同じネットワークでテスト方式だけを比較するなど、変更する条件を1つにします。タイムアウトが短すぎると、時間をかければ接続できる場合も失敗と判定されます。長すぎると、到達できない状態の発見が遅れます。

結果を判断しやすいテストの進め方

まず、サーバー情報が使用する権限のある設定に含まれていることを確認し、アドレス、ポート、プロトコルを照合してください。同じネットワークで少数回のテストを続け、最も良かった結果だけでなく、成功と失敗の傾向を記録します。結果のばらつきが大きい場合は、ネットワークの切り替え、電波状態の変化、端末での大量通信を先に確認してください。複数のテストを同時に実行すると、ネットワークリソースを奪い合い、結果を比較しにくくなります。

次に接続を確立し、同じ条件で確認できる対象へアクセスして、実際のリクエストが完了するか確認してください。ページが開いた後は、用途に応じてリソースの追加読み込みや通常の操作も試します。最初の応答が速くても、通信が継続して安定するとは限りません。1回のダウンロード結果だけで、小さなリクエストの遅延を判断することもできません。測定は見栄えのよい数値を得るためではなく、調べている現象を確認するために行います。

タイムアウトしても、サーバーが利用できないとは限らない

ネットワークによっては特定のプローブ方式が制限され、サーバーが特定のプローブに応答しないこともあります。そのため、Pingのタイムアウトと、実際のプロキシリクエストの失敗を同じものとして扱わないでください。実際のアクセスが正常でプローブだけ失敗する場合は、利用できている設定を維持し、現在の環境に合うテスト方法がないか確認してください。一方、ポートに到達できても認証情報が正しいとは限りません。パスワード、UUID、TLSパラメーターの誤りは、後のハンドシェイク段階で初めて分かる場合があります。

登録済みのサーバーがすべて同じ時刻に似た失敗を示す場合は、まず端末がネットワークに正常接続できているかを確認し、次に共通の名前解決条件やテスト対象を調べてください。特定の項目だけに問題がある場合は、そのサーバーのパラメーターとサービス状態を優先して確認します。複数のテストが失敗したからといって、すべてのサーバーが同時に故障したとは限りません。特に同じ対象を使うテストでは、対象そのものが共通の原因である可能性があります。

TLSを使う接続では証明書の検証を維持し、テストを成功させるためだけにセキュリティ関連の項目を安易に変更しないでください。失敗したら、まずサーバーのアドレス、ポート、ドメイン名、端末の時刻を確認し、次にサーバー側の要件を調べます。プロトコル設定の誤りは、タイムアウトを延ばしても直りません。具体的な設定項目を確認する場合は、Trojanの設定パラメーターを参照してください。最終的には自分の実際の設定を基準にします。

最終的には、テスト値の低さだけではなく、「必要なリクエストを安定して完了できるか」を基準に設定を選んでください。テストした時刻、ネットワークの種類、結果を簡潔に記録し、同じ時刻の失敗段階をLogで確認します。測定方法が環境に合わない場合、基本接続に失敗した場合、アクセス先への接続に失敗した場合を区別でき、誤った段階の設定を繰り返し変更せずに済みます。

05 · LogとData：記録から失敗の段階を特定する

Logは実際のリクエストがどのように処理されたかを確認するもので、英語の単語が表示されたというだけで故障と判断するためのものではありません。調査を始める前に、現在時刻、対象ドメイン、ネットワークの種類、Global Routing、選択中のサーバーを記録します。再現できるリクエストを1回送り、その前後の記録を探してください。複数のアプリがバックグラウンドで同時に通信するため、リストの最上部だけを見て判断すると、関係のないリクエストを問題の原因と誤認することがあります。

名前解決、ルール、接続、応答の順に確認する

まずドメインが名前解決され、アドレスを取得できたか確認します。次に、リクエストがどの種類のルールに一致し、どのポリシーが使われたかを見ます。その後、アクセス先またはサーバーとの接続が確立したかを確認し、最後にハンドシェイクとデータ転送を調べます。記録に表示される項目はアプリの実際の表示を基準とし、すべてのリクエストで同じ詳細を確認できるとは限りません。特定の記録がない場合も、その処理が行われなかったとは限らないため、記録範囲と現在の設定を合わせて判断してください。

たとえば、ドメインとアドレスが表示された後にタイムアウトした場合は、接続経路を調べる必要があり、DNSだけを変更しても解決しません。リクエストが想定外のルールに繰り返し一致する場合は、Configとルールの順序を確認してください。ポリシーは正しいのに認証に失敗する場合は、サーバーのパラメーターを調べます。処理全体の流れに現象を当てはめることで、見慣れたエラーの単語だけを頼りに、本当の失敗箇所を見落とすのを防げます。

ログの詳細度と保存範囲を選ぶ

まず現在のログ関連設定とアプリ内説明を確認し、端末の現在値を共通の初期値として扱わないでください。通常利用では、必要な情報を確認できる範囲に保ちます。問題を再現するときだけ、必要な記録の詳細度を一時的に上げてください。詳細な記録は、ストレージや処理の負担を増やし、アクセス状況に関する情報を多く含む場合があります。診断が終わったら普段の設定に戻し、すべてのテスト記録を長期間保存する必要がないか見直してください。

必要な情報を保存する前に記録をすぐ消去しないでください。まず現象と時刻を記録し、必要な部分を保存し、元に戻すための情報があることを確認してから、必要に応じて整理します。再接続すると記録の時系列が変わる場合があるため、接続と切断の時刻をそれぞれ記録してください。断続的な失敗では、脈絡のないログを大量に集めるより、「いつ始まったか、どれくらい続いたか、ネットワークを切り替えたか」を記録する方が役立ちます。

Dataの統計値を請求額と同一視しない

Dataでは、アプリが記録できる通信量を確認できます。まず集計範囲、通信の方向、対象期間、途中でリセットしたかを確認してください。アプリ、システム、通信事業者、接続サービスの統計は、集計方法が異なる場合があります。プロトコルのオーバーヘッド、計測の開始・終了地点、更新時刻も一致しないことがあります。そのため、Dataはテストで通信が発生したかを確認するのに役立ちますが、他のシステムの請求や精算の根拠として直接使うものではありません。

通信量が増え続ける場合は、設定の異常と決めつけず、前面でのダウンロード、メディアの読み込み、バックグラウンドのタスクを確認してください。接続が確立していても、新しいリクエストが発生していなければ数値が変わらないことがあります。まず短く再現できるアクセスを行い、その前後の変化を見てください。統計を確かめるために、大量の通信を繰り返さないようにします。長期間比較する場合は、集計期間とリセット時刻をそろえてください。

共有前に個人情報につながる内容を取り除く

サブスクリプションURL、認証情報、アクセス先のアドレス、サーバー識別情報は、診断時の記録に含まれる場合があります。公開の場で共有する前に、画面中央のパスワードを隠すだけでなく、テキスト全体を確認してください。エラーの種類、時系列、必要な項目名は残しつつ、個人のアカウントや接続先を特定できる値を置き換えます。ルールの問題を説明するだけなら、サブスクリプションや設定ファイル全体を共有する必要は通常ありません。

最後に、「観察した事実」と「個人の推測」を分けて記録します。事実は、どのリクエストがいつ失敗し、どのポリシーに一致したかです。推測は、どの設定が原因かという考えです。この最小限の記録を用意してよくある質問とトラブルシューティングを確認すると、適切な対処方法を見つけやすくなります。調査後は一時的に有効にした詳細ログを元に戻し、普段使う設定が元のものか確認してください。

06 · Widget：ショートカットと状態の確認

Widgetは、状態の確認や操作画面への移動をすばやく行うためのもので、Homeでの詳細な確認に代わるものではありません。Widgetの更新や操作はシステムが管理するため、表示内容が最新の接続結果とは限りません。Widgetとアプリ内の状態が異なる場合は、まずShadowrocketを開き、現在のサーバー、Global Routing、接続状態を確認してから実際のリクエストを試してください。Widgetに古い表示があるだけで、接続がずっと成功していると判断しないようにしてください。

Widgetの表示と実際の操作を区別する

利用できるWidgetの種類や操作は、端末の環境によって異なる場合があります。システムのWidget追加画面に表示される項目とアプリ内説明を確認してください。操作によってはアプリを開く必要があったり、システムの確認を求められたりします。タップして画面がすぐ変わらないだけで、機能が動作していないと判断しないでください。追加後に、切断状態から接続状態へ、さらに接続状態から切断状態へ操作して、アプリ内の状態とWidgetの更新タイミングを確認します。

SettingsのWidget関連項目は、変更を決める前に現在値を確認してください。Widgetの配置やシステムの対応範囲によって表示が変わるため、本ガイドでは共通の初期表示を指定しません。日常の判断に役立つ情報に絞り、似た操作項目が多くなって誤操作を招かないようにします。サーバーやプロトコルの詳細、複雑なルールを変更する場合は、アプリ内の該当画面に戻って全体を確認してください。

Widgetの表示が更新されないときの確認方法

まずアプリ内で状態が変わっているかを確認し、システムの更新を待ってからWidgetを見直してください。アプリ内で接続中のままなら、Widgetを作り直すのではなく接続処理を先に確認します。アプリ内の表示と実際のアクセスが正常で、Widgetだけ更新されない場合は、システムの手順に沿って再設定または再追加してください。このとき、通常は表示の問題とは直接関係のないConfig、DNS、サーバー情報まで同時にリセットしないでください。

ネットワークの切り替え、画面ロック、バックグラウンドの状態によって見え方が変わることがあります。問題がどの操作の後に起きたかを記録し、「Widgetが更新されない」「タップしても操作が完了しない」「接続を確立できない」の3つを区別してください。前の2つは表示や操作の経路に関する問題で、3つ目はPingとLogを使ったネットワークの確認が必要です。これらを混同すると、正常な接続パラメーターまで繰り返し変更してしまいます。

On Demandと併用する場合は操作の順序に注意する

On Demandが有効な場合、Widgetから手動で切断した後に条件が再び満たされると、新たな接続が試行されることがあります。Widgetのボタンが反応しなかったとは限りません。動作を確認するには、まずOn Demandを一時的に無効にしてショートカットだけを検証します。正常に動作することを確認したらOn Demandの設定を戻し、併用したときの結果を試してください。毎回、アイコンの見た目ではなくアプリ内の実際の状態を確認します。

ショートカットは、アプリで最後に選択したサーバーや設定をそのまま使う場合があります。操作前に現在の状態を把握してください。一時的なテスト後に普段の設定へ戻していないと、次にWidgetから接続したときテスト条件が使われる可能性があります。ルールの確認を終えるたびに、設定を戻し、Global Routingを復元し、サーバーを確認してからショートカットの動作を確認する習慣をつけましょう。

Widgetに表示する情報の範囲を調整する

Widgetは、周囲の人から見える場所に表示されることがあります。表示内容を設定できる場合は、サーバー名や状態を他人に見せる必要があるか考えてください。個別項目の名前に、アカウント全体、サブスクリプションURL、認証情報を含めるのも避けましょう。名前は識別に必要な範囲にとどめ、詳細は該当する設定に保存してください。日常の選択がしやすくなるだけでなく、画面を撮影・共有したときに情報が漏れるリスクを減らせます。

Widgetに表示される通信量がアプリの統計に基づく場合は、Dataの集計範囲も確認してください。Widgetの数値だけで端末全体の通信量を判断することはできません。システムの更新間隔やアプリの集計期間によって表示が変わることがあります。アクセス前後の変化を比べる場合は、アプリ内で集計範囲を確認してから条件をそろえてテストし、異なる時刻のWidgetの数値をそのまま差し引かないようにしてください。

Widgetは簡潔なショートカットとして使い、複雑な変更はアプリ内で行うことをおすすめします。Widgetだけに問題があり、アプリと実際のアクセスが正常なら、まず表示の問題として対処してください。3つとも異常な場合は、基本的な接続の確認に戻ります。ショートカットの利便性を保ちながら、表示の遅れに対して接続設定を何度もリセットするのを避けられます。

07 · iCloud：同期、バックアップ、機種変更時の復元

iCloud同期と書き出しによるバックアップは用途が異なります。同期は対応範囲の内容変更を端末間で反映し、バックアップは特定の時点のコピーを保存するものです。同期を使っても、任意の過去の状態にいつでも戻せるアーカイブが作られるわけではありません。設定の整理や機種変更を始める前に、アプリで利用できるiCloud項目、現在のスイッチの状態、書き出し可能な内容を確認し、別途コピーを保存してください。データの状態を確認する前に、複数の端末を同時に変更しないようにします。

すべてが複製されると考えず、同期の範囲を確認する

サーバー情報、Configファイル、アプリの設定がそれぞれどのように保存・同期されるかを確認してください。項目ごとに処理が異なる場合があるため、設定ファイルの1つが表示されたからといって、すべてのパスワード、選択状態、統計記録も移行済みだとは限りません。適用範囲はアプリ内説明と実際の結果を基準にします。まず、見分けやすく機密情報を含まない項目を使って同期を確認してから、大規模な整理を行うか決めてください。

システム設定で現在のiCloudアカウントと関連するアクセス権を確認し、利用可能なストレージ容量とネットワーク状態も調べてください。アプリ内のスイッチがオンでも、それは同期条件の一部にすぎず、データがすでにサーバーへ保存された証拠ではありません。内容が更新されない場合は、まずこれらの基本条件を確認し、別の端末から読み取れるかを確かめます。同期を促すために設定を何度もオン・オフしたり、同じファイルを繰り返し読み込んだりしないでください。重複や判別しにくいコピーが作られる場合があります。

機種変更はインストール、確認、復元、検証の順に進める

まずApp StoreからShadowrocketを入手してください。購入済み項目の確認と復元については、購入済みアプリの復元方法をご覧ください。アプリの購入記録と個人の接続設定は別のデータです。アプリを復元してもサーバー情報まで戻るとは限りません。インストール後にiCloudの条件を確認し、既存のバックアップから必要な内容を復元してください。最後に、現在のサーバー、Config、Global Routing、必要なシステム権限を確認します。

初回の復元後は、複雑なOn Demand条件をすぐ有効にせず、まず手動接続をおすすめします。使い慣れた対象への実際のリクエストを完了し、DNSとルールが想定どおりか確認してください。内容が復元されていても接続に失敗する場合は、同期の問題と決めつけず、サーバーの設定と現在のネットワークを調べます。以前の端末で正常だった状態は比較材料にできますが、両方の端末で相反する変更を同時に行わないでください。

差分や競合を処理するときは、両方の根拠を残す

2台の端末で同じ内容を変更した場合、システムが意図した方を必ず残すとは限りません。まずそれぞれの端末にあるコピーを保存し、今後使う基準を決めてから、アプリが提供する手順に沿って処理してください。比較するときは、ルールの順序、最終ポリシー、サーバー参照、必要なパラメーターを確認します。ファイル名が同じでも内容が同じとは限りません。表示時刻が新しいことだけで判断しないでください。

重複した項目がある場合は、内容が異なるのか、同じものを重複して読み込んだのかを確認してから、不要な項目を削除してください。名前だけを見て一括削除しないようにしましょう。同じ名前のサーバーでも、ポートや通信パラメーターが異なることがあります。整理後は1台の端末で動作を確認してから、もう1台の結果を確かめてください。同期対象の削除は特に慎重に行います。影響範囲が分かるまでは、一覧を整理することよりも個別に復元できるコピーを残すことが重要です。

バックアップにもアクセス制限を設定する

書き出した設定ファイルにアドレス、パスワード、UUID、サブスクリプションURLが含まれる場合があります。ファイル名が一般的だからといって、公開してよい資料とは限りません。アクセス範囲を自分で管理できる場所に保存し、共有前に内容を確認してください。ルールの相談だけに使う場合は、個人情報を除いた最小限のサンプルを別に作成します。バックアップの完了は「ファイルが存在する」だけでなく、読み込めて保存内容を識別できることも含みます。

重要な変更の前に、正常に動作しているコピーを保存し、用途も記録しておくと安心です。意味のないテストのたびに長期保存用のバックアップを増やす必要はありません。機種変更の手順と復元時の確認事項は、設定のバックアップとiCloud移行をご覧ください。移行後に自動接続とショートカットを戻し、テスト用の古いコピーを普段使う設定として誤って選ばないよう確認します。

08 · Proxyポート：ローカルリスニングとアクセス範囲

Proxy関連のポートでは、ローカルの待ち受けポートとリモートサーバーのポートを区別する必要があります。Add Serverに入力するポートは、自分のサーバーへの接続に使います。ローカルプロキシの待ち受けポートは、対応するプロキシ方式のリクエストを端末上の待ち受けサービスに接続するためのものです。設定場所、用途、通信経路はそれぞれ異なります。ローカルポートを変更してもリモートサービスのポートは変わらず、認証情報の誤りや利用できなくなった接続サービスも修正されません。

プロトコル、アドレス、ポートの3点を確認する

該当する待ち受け設定がアプリにある場合は、表示されているプロトコルの種類、待ち受けアドレス、ポートの説明を確認してください。HTTPとSOCKS5は異なるプロキシ接続方式のため、利用側も対応する方式を選ぶ必要があります。アドレスは接続先、ポートは具体的な待ち受け口を示します。数字が正しくても、プロトコルまたはアドレスが誤っていれば利用できません。他の端末の例にある一般的な数字を、自分の端末の初期値だと決めつけないでください。

該当する機能は、実際に利用する必要がある場合に限って有効にし、端末に表示された元の値を記録してください。Shadowrocketの通常のVPN接続とルールによる振り分けだけを使う場合は、まず基本の接続を確認し、「設定を完成させる」ためだけに待ち受け項目を変更する必要はありません。入口ごとに適用条件が異なる場合があるため、アプリ内説明を確認してください。画面にない待ち受け機能やアクセス制御を、設定項目名の推測だけで存在すると考えないでください。

ループバックアドレスとローカルネットワークのアドレスは異なる

ループバックアドレスは、リクエストを開始する端末自身を示します。別の端末でループバックアドレスを入力すると、Shadowrocketを実行している端末ではなく、その別の端末自身を指します。用途が端末間のアクセスであれば、まずアプリがその接続方法に対応しているかを確認し、待ち受け範囲、ネットワーク、必要なアクセス制御を調べてください。待ち受け範囲を広げるだけで、別の端末から必ず接続できると考えないでください。

待ち受け範囲を広げると、より多くのネットワークから入口への接続が試みられる可能性があります。必要な範囲に絞って設定してください。画面に認証やアクセス制限がある場合は、用途に合わせて確認します。アクセス範囲を特定できない場合、信頼できないネットワークに待ち受けサービスを公開しないでください。ネットワークを切り替えると端末のアドレスが変わり、以前入力したアドレスが使えなくなることもあります。使用後は不要になったアクセス設定を元に戻してください。

接続拒否、タイムアウト、認証失敗を分けて調べる

接続が拒否された場合は、該当する待ち受けが有効か、アプリが必要な状態か、ポートが正しいかを確認します。タイムアウトでは、アドレス、ネットワークの到達性、アクセス範囲も調べてください。接続後に認証エラーやプロトコルエラーが起きる場合は、利用側が選んだプロトコルと双方の要件を確認します。失敗した段階を特定する前にポートを次々に変更しないでください。利用側と待ち受け側の記録を対応させにくくなります。

テストでは通常のVPN経路を比較基準として残し、待ち受けへの接続を個別に確認します。利用側のアプリでプロキシ設定ができる場合は、必要な項目だけを変更し、テスト後に元に戻してください。戻し忘れると、その後の別アプリの不具合が、すでに停止した待ち受けアドレスを参照していることが原因になる場合があります。あるアプリからプロキシ経由でアクセスできても、端末内のすべてのアプリが同じ設定を自動的に使うとは限りません。実際のリクエストがどの範囲に適用されるか確認してください。

一連の確認の最後にポートの動作を検証する

ローカルの入口に接続できた後も、リクエストに適用されたポリシーとサーバーを確認する必要があります。待ち受けへの接続成功は、リクエストが入口に届いたことを示すだけであり、その後の名前解決、ルール、接続の検証に代わるものではありません。Logから同じ時刻のリクエストを探し、対象から応答があったか確認してください。該当する記録がない場合は、リモートサーバーの設定を変える前に、利用側が入力したプロキシを実際に使っているか確認します。

最後に、普段使うConfigとGlobal Routingに戻し、選択中のサーバーを確認します。一時的に変更したDNSとログ設定を元に戻し、On Demandを確認してからWidgetを見直してください。変更を残す場合は、まずバックアップの記録を更新します。問題を特定できない場合はよくある質問とトラブルシューティングを確認するか、チュートリアルに戻って最小限の接続手順を試してください。原因が分からないまま、関係のないスイッチを追加して現象を覆い隠さないようにしましょう。