Shadowrocket
Settingsの設定項目一覧

Global Routingと設定の適用範囲

Global Routingは、接続全体の処理方法を決めます。Settingsを確認する前に、まず現在の設定を確かめてください。画面のConfig、Proxy、Directは、それぞれ設定、プロキシ、直接接続を表します。画面上部の接続スイッチとは役割が異なります。スイッチはクライアントの接続が動作中かどうかを示し、Global Routingは接続中の通信をどのように処理するかを示します。システムにVPNの状態が表示されていても、特定の通信が選択したサーバーを経由しているとは限りません。

全体の接続方式と個別ルールを区別する

Configでは、現在有効な設定ファイルのルールに基づいて通信方法を決めます。通信先ごとに経路を分けたい場合に適しています。Proxyはプロキシ経由を基本とし、手元のサーバーで特定のアクセスが可能かを確認する際に使えます。Directは直接接続を基本とし、比較確認に役立ちます。実際に維持される動作は、現在のConfigとアプリの説明もあわせて確認してください。各モードの名称だけから、すべてのシステム通信が同じように処理されると判断しないでください。

Proxyに切り替えてアクセスできるようになっても、接続方式の変更と結果に関連があると分かるだけで、特定のルールに誤りがあるとは限りません。サーバーも同時に変更していないか、古い接続を再利用していないか、ドメイン名を再解決したかも確認してください。反対に、Directで接続先を開けても、プロキシの設定が正しいとは言えません。比較する際は、接続先、ネットワーク、サーバーを固定し、モードだけを一つずつ切り替えて、新しい接続でテストしてください。

Settings、Config、サーバー設定の違いを確認する

同じ現象に、Settingsのアプリ全体に関わる設定、Config内のルールや名前解決設定、サーバー編集画面のプロトコル設定という3つの層が関わる場合があります。ある場所に設定項目があるからといって、別の場所にある同名の設定を上書きするとは限りません。まず現在どのConfigが有効かを確認し、関連する項目が含まれているかを見てください。ファイルを読み込んだ後もアプリ全体の設定が有効かどうかは、ファイルの有無だけで判断せず、実際の動作とLogで確認します。

初期値も設定の層ごとに確認してください。初回インストール時、データ復元後、Config読み込み後では、表示される値が異なることがあります。本マニュアルでは、共通の値を確実に確認できない項目について「現在アプリに表示されている値を基準」としています。設定名、画面上の場所、変更前の値、変更によって期待する影響を記録しておくと便利です。たとえば「サーバーは変更せず、名前解決方式だけを比較する」のように記録します。前後関係の分からない画面だけを保存するより、元の状態に戻しやすくなります。

再現可能な基準を用意する

トラブル対処を始める際は、まず正常に動作することが分かっている、ご自身で管理するサーバーを一つ選びます。Homeで選択されていることを確認し、Global Routingと現在のConfigを記録してください。環境を安定させるため、自動サブスクリプション更新や再接続のきっかけになる条件を一時停止し、テスト中は状態を固定します。完了後は元の設定に戻してください。テストには状態を確認できるページを使い、異なるWebサイトの結果を混ぜて比較しないようにします。

テストごとに、操作の順序を記録します。接続を切断し、設定を一つ変更してから再接続し、新しいリクエストを発生させて、該当する記録を確認します。想定と異なる結果になった場合は、直前の状態に戻して再テストし、問題を再現できるかを確認してください。ブラウザーのキャッシュ、継続中のダウンロード、バックグラウンドの長時間接続では、以前の結果が引き継がれることがあります。そのため、ページの再読み込みが必ずしも新しい接続を意味するとは限りません。必要に応じて対象ページを閉じてから開き直しますが、一度の失敗でアプリのすべてのデータを消去する必要はありません。

On Demand：発動条件と自動接続

On Demandは、設定済みの条件に応じて接続を開始する機能です。サーバーを自動的に修復する機能や、サブスクリプションを更新する機能ではありません。条件に合致すると接続が試みられますが、接続できるかどうかは現在のサーバー、Config、ネットワークによって変わります。手動で接続を切った後に再び動作する場合は、まず有効な条件が残っていないか確認してください。上部のスイッチやアプリの状態表示に問題があるとすぐに決めつけないようにします。

まず自動化する場面を決める

設定を始める前に、目的を具体的にします。たとえば、特定のネットワークでのみ接続したいのか、ネットワークを切り替えても接続状態を維持したいのかを決めてください。次に、現在のアプリで選べる条件の種類と一致方法を確認します。別の画面にある項目名をそのまま当てはめないでください。Wi-Fiネットワーク名で環境を区別する場合は、空白や見た目の似た文字を含め、名前を正確に確認します。同じ名前のネットワークが異なる場所にあることもあり、名前だけではネットワークの正当性を確認できません。

スイッチの初期状態や最初の条件は、現在アプリに表示されている内容を確認してください。初回接続をトラブル対処中の場合は、まずOn Demandを一時停止して、単一のサーバーが正常に動作することを手動で確認してから、自動接続の条件を追加することをおすすめします。そうしないと、接続エラーと条件による再試行が重なり、Logに似た記録が何度も残って、どの手動操作の結果か判断しにくくなります。自動接続を再開するときは、目的が明確な条件を一つずつ追加してください。

システムの許可とネットワーク切り替え

初回接続時、システムからVPN構成の追加許可を求められる場合があります。アプリ名を確認し、システムの案内に従ってください。許可済みであっても、すべての自動接続条件が有効とは限りません。また、条件が有効でも、システムの許可が完了しているとは限りません。アプリでは有効に見えるのにシステムが接続を確立できない場合は、許可の状態と接続エラーを分けて確認します。システム要件とデバイスの互換性はApp Storeのページに記載された内容を確認し、以前のデバイスでの経験から現在の状態を推測しないでください。

Wi-Fiとモバイル通信を切り替えると到達経路が変わり、既存の接続が切断されることもあります。On Demandをテストするときは、まずネットワークを固定して条件が発動するかを確認し、その後、ネットワークを一度だけ切り替えて前後の状態を記録してください。サーバーとConfigを同時に変更すると、接続が復旧しても自動接続の条件が正しいかどうか分かりません。Webブラウザーでログインが必要なネットワークでは、先にネットワークへの接続手続きを完了してからプロキシ接続を確認します。

自動接続と手動接続の違いを確認する

手動接続は正常で、自動接続だけが想定どおりに動作しない場合は、プロトコル設定ではなく発動条件を優先して確認してください。条件が保存されているか、現在のネットワークが条件を満たしているか、別の条件が異なる動作を引き起こしていないか、システム構成が有効かを確認します。手動接続も失敗する場合は、サーバーと名前解決の確認に戻ってください。2つの状況を分けることで、自動接続の問題を解決するために既存のデータをすべて作り直すことを避けられます。

アプリが前面に表示されなくなった後、切断したと思っていても、システムの接続が残っていることがあります。アプリ画面が前面にあるかどうかと、システムのネットワーク拡張が動作しているかどうかは別の状態です。システムの接続状態と、アプリを再度開いたときの表示をあわせて確認してください。バックグラウンドのアプリ一覧を接続スイッチと見なさないでください。自動接続を停止する場合は、まず有効なOn Demand条件を無効にしてから切断し、状態を確認します。条件がすぐに再発動するのを防げます。

継続して使う前に、少なくとも3種類の確認を行ってください。条件に合致したとき接続できること、条件に合致しないときの動作が想定どおりであること、サーバーに到達できない場合にエラーを判別できることです。自動接続は操作を減らすために使い、問題を見えにくくするために使わないでください。組織が管理するデバイスでは、システム設定に管理上の制限がある場合があります。デバイスに表示された内容を確認し、条件や許可の確認をせずに構成の削除と追加を繰り返さないでください。

LogとData：失敗した段階を記録から確認する

Logは接続がどのように行われたかを確認するために、Dataは通信量に関する情報を見るために使います。どちらも対象となる時間帯を明確にして解釈してください。合計値が増えていても、集計対象の範囲でデータが計上されたと分かるだけで、特定のページが正常に読み込まれた証拠にはなりません。接続の記録があっても、リクエスト全体が完了したとは限りません。トラブル対処では、まず対象と操作した時刻を特定し、記録から名前解決、ルールの選択、接続の確立、エラーの各段階を確認します。

記録の範囲を絞ってから問題を再現する

ログのスイッチ、詳細度、保存方法は、現在アプリに表示されている内容を確認してください。問題を再現する間だけ、特定に必要な範囲のログを記録し、終了後は通常の設定に戻すことをおすすめします。記録が詳細になるほど、バックグラウンドのアプリ、ページ内の関連リソース、重複した接続が混在しやすくなります。対象を絞らずに記録を増やすと、かえって判断しにくくなります。開始前に関係のないテストやサブスクリプション更新を一時停止し、現在の状態を記録してから、対象の操作を一度だけ実行してください。

画面から記録を消去できる場合は、必要な情報を保存したか確認してから、今回の観察範囲の記録を消去します。消去しない場合は、開始位置や操作時刻を記録してください。その後、対象との接続を新たに確立し、ブラウザーが古い接続を再利用して新しい記録が残らない状況を避けます。一度の再現で関係のないページを複数開かないでください。ページ本体のリクエストと他のリソースを区別しにくくなります。記録の末尾に近いエラーを、現在の対象に関係するものと決めつけないでください。

名前解決、接続、認証、サービス応答を区別する

名前解決の段階で結果が得られない場合は、DNSを確認します。アドレスを取得してから接続がタイムアウトする場合は、ネットワーク、ポート、選択中の経路を確認します。認証やハンドシェイクのエラーが出た場合は、サーバーの各項目が手元の情報と一致するかを確認してください。TLS関連のエラーでは、名前、証明書の条件、デバイスの日時も確認します。接続先サービスから拒否やサービス応答を受け取った場合は、ネットワーク上の前段階が完了していることがあります。次はその応答自体を確認してください。

ルールのトラブル対処では、「記録にドメイン名があるか」ではなく、どのルールに一致し、どのポリシーが選択され、最終的にどこへ接続しようとしたかを確認します。一つのページで複数のドメイン名が使われることがあり、メインのドメイン名が正常でも、他のリソースが異なるポリシーで処理される可能性があります。まず実際に失敗したリクエストを特定し、その一致結果を確認してください。Logに必要な項目がない場合は、不足情報を推測で補わず、一つのルールだけを変えて比較し、テストを繰り返して仮説を確認します。

通信量の記録とプライバシーへの配慮

Dataの集計範囲、累積の開始時点、表示単位は、現在の画面の説明に従って解釈してください。接続中に他のアプリも通信することがあり、ページのキャッシュによって今回の通信量が少なくなる場合もあります。そのため、合計値から特定のリクエスト全体のサイズを直接計算することはできません。比較する場合は、観察する時間を固定し、明確な操作を一度だけ実行して、前後の変化を記録します。統計がリセットされたり、デバイスを再接続したりした場合は、集計範囲が変わったことを結論に記載してください。

ログには、接続先のドメイン名やアドレス、サーバー名など、利用状況を特定できる情報が含まれる場合があります。共有する前に、サブスクリプションのアドレス、認証情報、個人を特定できる情報、関係のないアクセス記録を削除し、問題の特定に必要な最小限の範囲だけを残してください。一見すると普通のアドレスに見えるリンクにも、認証情報が含まれることがあります。エクスポートしたファイル全体を公開の場に貼り付けないでください。実際のドメイン名をexample.comに置き換える場合も、エラーの種類と項目の構造は維持してください。

トラブル対処が終わったら、変更した設定を元に戻すか、新しい基準として保存し、不要になった詳細ログをオフにします。問題の原因がまだ分からない場合は、「期待する動作、実際の動作、固定した条件、唯一の変更点、対応するエラー」の5項目を整理して、さらに範囲を絞ってください。再試行を繰り返さず、判断に必要な情報も残せます。「接続できない」という一文や、途中で切れたエラー画面だけでは、どの設定を変更すべきか判断できないことがほとんどです。

Proxyポートとサーバー設定：ローカルとリモートを区別する

Proxy関連のポートは、まず設定場所を区別してください。Add Serverのポートは、手元のリモートサーバーの設定項目であり、対応するサーバー情報と一致させる必要があります。Settingsにローカルプロキシの待ち受け設定がある場合、そのポートはデバイス上のローカル接続先です。用途が異なるため、数値が同じでも互いに置き換えることはできません。変更前に画面上の項目名、アドレス、利用者を記録し、「誰がこのポートに接続するのか」を確認してから変更箇所を判断してください。

ローカル待ち受けのアドレス、ポート、公開範囲

ローカルHTTPまたはSOCKS5の接続先が使えるか、有効か、初期ポートが何番かは、現在アプリに表示されている内容を確認してください。固定の番号を前提にしないでください。デバイス上のアプリだけで使う場合は、必要最小限の範囲に制限することをおすすめします。LANからの接続を許可すると、アクセスできる利用者の範囲が変わります。認証、ネットワークの信頼性、実際の用途をあわせて検討してください。Webページの不具合を調べるためだけに待ち受けを追加し、関係のない条件を増やさないでください。

ポートの競合とポート設定の誤りは別の問題です。待ち受けを開始できない場合は、別の機能がポートを使用していないか、その設定が実際に有効かを確認します。リモートサーバーへの接続に失敗する場合は、サーバーアドレス、リモートポート、ネットワーク経路を確認してください。リモートポートをローカル待ち受けのポートに変更しても、サーバー側の設定は直りません。システムのネットワーク環境が変わると、アクセス可能なローカルアドレスも変わることがあります。以前のネットワークで使えたアドレスだけを根拠に、現在の接続状態を判断しないでください。

プロトコルの項目は手元の情報と一致させる

Add Serverでは、まずプロトコルの種類を確認し、選択したプロトコルに必要な項目を確認します。Shadowsocksの暗号化方式とパスワード、VMessまたはVLESSのIDと転送設定、TrojanのパスワードとTLS関連の項目は、それぞれ意味が異なります。画面上の項目名が似ていても、相互に置き換えられるとは限りません。手元のサーバー情報に従って一つずつ入力し、接続を試すためにプロトコルを無作為に変更したり、別の項目の設定をコピーしたりしないでください。

サーバーアドレス、TLSで使う名前、特定の転送方式で使うHostは、別々の項目である場合があります。アドレスは最初に接続する先を決め、名前に関する項目は該当するハンドシェイクやリクエストの処理に使われます。既存のサーバー設定を確認してください。証明書エラーが出たときに、検証を無効にすることを通常の対処としてすすめないでください。まず名前が一致しているか、デバイスの日時が正しいか、設定の情報がすべてそろっているかを確認し、その後サーバー証明書の状態を確認します。項目の誤りをチェックの緩和で隠さないでください。

転送方式への対応状況から原因を確認する

TCPリクエストは正常でも別の種類のリクエストが失敗する場合は、プロトコル、サーバー、ネットワークがその転送方式に対応しているか確認します。Webページを開けるからといって、すべてのUDP通信やリアルタイム通信も使えるとは限りません。WireGuard、Hysteria2などのプロトコルにも、それぞれアドレス、認証、転送方式の要件があります。実際の項目を確認してください。ここでは確認方法を説明しており、接続に使える認証情報を提供したり、サーバーで特定の機能が有効だと推測したりするものではありません。

サブスクリプションから読み込むと手入力を減らせますが、解析後の項目が元の情報と一致しているかは確認が必要です。サブスクリプションから生成された項目を編集する場合は、次回更新でローカルの変更が上書きされないか確認してください。テストする場合は、元の項目を残してテスト用の複製と分かるようにしておきます。次回更新後にアプリが変更を保存しなかったと誤解するのを避けられます。手動追加の手順はAdd Serverのチュートリアル、既存サブスクリプションの読み込みはSubscribeのチュートリアルをご覧ください。

確認は、アドレスとポート、プロトコルと認証、TLSと転送の項目、実際の接続先へのアクセスの順に行います。各段階を確認するたびに、新しい接続でテストし、Logで失敗した段階が変わったかを見てください。エラーがタイムアウトから認証エラーに変わった場合、確認できた範囲が変わったことは分かりますが、問題が解決したとは限りません。設定が手元の情報と一致し、実際のリクエストが完了して初めて、その項目をルールのトラブル対処の基準として使えます。