Shadowrocket
プロキシモードと設定方法

日常的にルールで振り分ける場合はConfig、一時的にプロキシ経由を確認する場合はProxy、直接接続の状態を確認する場合はDirectを選びます。これらの選択肢はサーバーの追加やサブスクリプションの更新を行うものではありません。HomeでGlobal Routingを開いて必要なモードを選び、Homeに戻ってデフォルトサーバーと接続スイッチを確認してください。モードを切り替えたら、既存の長時間接続の状態を新しいモードの結果と混同しないよう、対象へのアクセスを改めて実行します。

設定、プロキシ、直接接続は、それぞれ画面上のConfig、Proxy、Directに対応します。Configモードは下部のConfig画面に関係しますが、操作は別です。前者は通信の処理方法を選び、後者は構成ファイルを管理します。構成ファイルをインポートしただけでは、そのファイルが選択されたことにも、Global RoutingがConfigに切り替わったことにもなりません。

モードを切り替えても接続が保証されるわけではありません

Proxyは有効なサーバー情報と到達可能なネットワークが必要です。Configは正しいルールに依存し、Directも現在のネットワークや対象サービスの状態に左右されます。問題が起きたら、まず現在のモードを記録し、変更する項目は一度に1つにしてください。ProxyではアクセスできてConfigではできない場合、サーバーをすべて再インポートするのではなく、ルールの一致状況とDNSを先に確認します。

比較が終わったら、通常の利用目的に合ったモードに戻してください。一時的なテスト状態をそのまま使い続けると、Dataの通信量の内訳、ローカルネットワークへのアクセス、その後の調査結果が想定と異なる場合があります。

ルールによる振り分けは、Config画面で実際に選択されている構成に基づきます。編集前に復元できるコピーを保存し、構成の[Rule]セクションを確認してから、HomeのGlobal RoutingがConfigになっていることを確かめてください。通常、対象を明確に絞ったルールを上の方に置き、前のルールに一致しなかったリクエストを最後のルールで処理します。

DOMAINは完全一致のドメイン、DOMAIN-SUFFIXは指定したドメインの末尾とそのサブドメイン、DOMAIN-KEYWORDはドメインに含まれるキーワードに一致します。アドレス関連のルールにはIP-CIDRとIP-CIDR6があり、それぞれ対応するアドレス範囲に使用します。GEOIPはアドレスの地域情報に基づいて一致しますが、結果はデータベースと解決されたアドレスに左右されるため、対象サービスの実際の設置場所を示す確実な証拠にはなりません。

ポリシーのPROXYはプロキシ経由、DIRECTは直接接続、REJECTはリクエストの拒否を意味します。これらはルールの処理結果であり、プロトコル名ではありません。構成でカスタムポリシーグループを使用している場合、ルールの末尾にグループ名が指定されていることもあります。その場合はグループ内の選択肢も確認してください。ルールにPROXYが含まれているかどうかだけでは判断できません。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

一致範囲を絞ってから最終ポリシーを調整

ルールをテストするときは、対象が完全一致のドメイン、サブドメイン、IPアドレスのどれかを明確にします。キーワードルールは範囲が広く、意図しないドメインまで対象にすることがあります。アドレスルールでは、先にDNS解決が必要な場合もあります。互いに重なるルールを一度に複数追加しないでください。アクセスが復旧しても、どのルールが作用したのか判断しにくくなります。

USER-AGENTは、該当するリクエスト情報を取得できることが前提となるため、すべてのアプリ通信に適用する汎用的な条件として使うのは適切ではありません。リクエスト情報を確認できない場合は、ドメインまたはアドレスに基づく一致を優先して確認してください。キーワードの詳しい説明は用語クイックガイド、構成手順の全体像は完全マニュアルをご覧ください。

HomeでAdd Serverを使い、ご自身がお持ちのサーバー情報を追加します。サービス提供元のサブスクリプションURLをお持ちの場合は、画面でSubscribeを選び、URLを入力してください。インポート前に情報の種類を確認しましょう。個別サーバーの共有情報、サブスクリプションURL、構成ファイルはそれぞれ別の形式です。文字列であるという理由だけで、同じ入力欄に入れないでください。

手動入力では、まず情報に合ったプロトコルを選び、アドレス、ポート、認証情報、転送関連の項目を一つずつ確認します。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2、HTTP、SOCKS5では、必要な設定がすべて同じではありません。あるプロトコルの入力方法を別のプロトコルにそのまま適用しないでください。情報が不足している場合は推測せず、情報の提供元に確認してください。

インポート・更新・選択はそれぞれ別の操作

インポート後、Homeに想定した項目が表示されていることを確認し、使用するデフォルトサーバーをタップして選択状態を確かめます。サブスクリプションの更新はサーバー一覧を再取得する操作です。各項目の利用可否を自動で確認するものでも、現在のデフォルトサーバーを自動で変更するものでもありません。更新後は、特に項目名や件数が変わった場合、現在選択されている項目をもう一度確認してください。

更新に失敗した場合は、現在のネットワークからサブスクリプションURLにアクセスできるか、URLが完全か、サービスが現在も有効かを確認します。サブスクリプションURLにはアクセス認証情報が含まれている場合があります。URL全体を公開スクリーンショット、ログ、コメントに載せないでください。古いサブスクリプションを削除する前に、どの項目がそのサブスクリプションに属するかを確認し、まだ使用中の設定情報を失わないようにしてください。

サーバーのテスト結果は、使用したテスト方法とその時点のネットワーク状況を反映します。数値が小さくても、すべての接続先で高速とは限りません。テストに応答があっても、認証、転送、対象サービスまでの通信経路全体が正常とは限りません。項目を選択した後は、実際に接続し、目的のサイトやサービスにアクセスできるか確認してください。

On Demandは、設定した条件に応じて接続動作を開始する機能です。適切なサーバー設定やルールを自動で選ぶ機能ではありません。SettingsでOn Demandを開き、まず既存の条件を確認します。その後、必要に応じてWi-Fi、モバイル通信、ドメインに関する条件を設定してください。選択できる項目は、現在のアプリ画面で確認してください。

設定を始める前に、Homeの接続スイッチで手動接続を一度確認します。デフォルトサーバーが有効で、Global Routingが想定どおりであり、目的のアクセスが完了することを確かめてください。その後、条件を一度に1つずつ追加します。たとえばWi-Fi名を条件にする場合は、ネットワーク名の正確な表記を確認します。ドメインを条件にする場合は、どのアクセスをトリガーにするかを明確にします。自動接続の条件を[Rule]内の振り分けルールと混同しないでください。

自動接続と通信の振り分けは別々に確認

On Demandは接続をいつ開始するか、またはトリガーするかを扱います。Global Routingと構成内のルールは、接続後に通信をどう処理するかを扱います。自動接続が成功しても、特定のドメインが最終的にPROXY経由になったとは限りません。同様に、接続が維持されていても、自動接続の条件が検証済みとは限りません。

テストでは対象のネットワークに実際に切り替え、接続状態を確認してから、条件に関連するアクセスを行います。複数の条件がある場合は、リストの順序と各項目の動作を確認し、範囲の広い条件がより具体的な条件を上書きしないようにします。接続をオフにしても再接続される場合は、まずOn Demandを一時停止して比較し、その後システムのVPN状態を確認してください。自動接続の問題に対処するために、サーバー情報を何度も変更しないでください。

デバイスのスリープ、ネットワークの切り替え、システムのスケジュール実行は、接続動作の観察結果に影響することがあります。トリガー条件、ネットワークの種類、実際の結果を記録し、個別に再現して確認してください。Wi-Fi、モバイル通信、ドメインを条件にした設定については、On Demandの自動接続設定をご覧ください。

Data画面では、アプリが記録した通信量の統計や接続情報を確認できます。調査を始める前に、画面に表示されている集計範囲、分類、記録内容を確認してください。その後、対象を明確にしたアクセスを一度行い、表示に変化があるか比べます。統計項目によって集計範囲が異なる場合があるため、画面の表示に従ってください。累計値を特定のアクセスによる通信量とそのまま解釈しないでください。

ConfigとProxyの動作を比較する場合は、現在のモードと統計値を記録してから、同じアクセスをそれぞれ行います。記録に接続先、ポリシー、サーバー情報が表示される場合は、想定したルールと照らし合わせてください。バックグラウンド処理でもリクエストが発生するため、総通信量が増えたことだけでは、特定のルールに一致したとは判断できません。

統計は問題の切り分けに使い、契約残量の推定には使いません

アプリの記録とサービス提供元の請求情報では、集計期間、プロトコルのオーバーヘッド、計算方法が異なる場合があります。Dataの数値をサブスクリプションの残量とみなしたり、特定の接続先への全通信が同じ経路を通った証拠としたりしないでください。アカウントの利用量を確認するには、ご利用中のサービス提供元の記録を参照してください。

記録を削除したり統計をリセットしたりする前に、今回の調査に必要な情報を保存してください。記録を共有する場合は、サーバーアドレス、アカウント、その他の機密情報を隠します。再現した時刻、現在のモード、使用したプロトコル、発生した症状を伝えると、問題を段階的に絞り込みやすくなります。

DNS：実際に適用される設定を確認

DNSはドメイン名をアドレスに解決し、一部のアドレス関連ルールの判定にも影響します。SettingsのDNS関連項目を確認するときは、現在のConfigにDNS設定が記述されていないかも確認してください。画面上の設定を1つ変更しただけで、すべての名前解決の動作が変わったと判断しないでください。システムのDNSを使う構成では、dns-server = systemと記述できます。

DNSをカスタマイズする場合は、現在のアプリが対応する形式で入力し、DNSサービスに現在のネットワークから到達できることを確認してください。DNS over HTTPSはDNSリクエストの転送方法を変更するもので、サーバーの認証エラーを自動で解決するものではありません。変更後に接続を確立し直して対象にアクセスし、名前解決と接続の成否をそれぞれ確認します。設定の選び方はDNS設定ガイドをご覧ください。

Test Method：遅延テストの内容を確認

SettingsのTest Methodで現在のテスト方式を確認し、Homeに戻って登録済みサーバーをテストします。方式によって確認する接続段階が異なるため、数値を比較できるのは、同じ方式、近い時間帯、同じネットワークの場合に限られます。Test Methodを変更した後、新しい数値を別の方式で測定した過去の結果と単純に比較しないでください。

テストに応答があってもWebページを表示できない場合は、認証情報、対象ルール、DNS、実際のリクエスト結果を引き続き確認してください。テストに応答がない場合も、テスト対象に制限があるのか、サーバー自体が利用できないのかを切り分けます。最終的には、必要な接続先に正常にアクセスできるかどうかで判断してください。

Today Widget：ショートカット操作後も状態を確認

SettingsでToday Widget関連の項目を確認し、デバイスのシステムが提供する方法でウィジェットを設定してください。アプリの接続機能を手軽に表示または操作するためのもので、利用できる内容は現在のアプリとシステム画面に従います。初めて使う前に、Homeでサーバーを選択し、接続を許可してください。

ウィジェットから操作した後は、アプリに戻り、接続スイッチと現在のサーバーを確認してください。ウィジェットは独立した接続設定ではなく、Global Routingの選択に代わるものでもありません。想定した項目がデバイスに表示されない場合は、システムのウィジェット一覧とアプリの設定を確認してください。それだけでサブスクリプションのインポートに失敗したと判断しないでください。

iCloud同期：同期は確認や完全なバックアップとは異なります

SettingsでiCloud同期関連のスイッチを確認し、デバイスでご自身のAppleアカウントにサインインして、該当するiCloudの使用が許可されていることも確認してください。同期対象は現在のアプリに表示されている項目に従います。接続状態、診断記録、すべてのローカルデータが一括して移行されるとは限りません。

別のデバイスでアプリを開いたら、サーバー、構成ファイル、現在の選択項目を一つずつ確認してから接続テストを行います。構成をまとめて削除または変更する前に、コピーを保存してください。同期によって変更がほかのデバイスにも反映される場合があります。アプリの購入履歴の復元と構成データの同期は別の操作です。購入に関する問題は購入済みアイテムの復元方法をご覧ください。

Diagnostics：接続失敗時の情報を収集

SettingsでDiagnosticsを開き、画面に表示される診断項目を使って現在の接続環境を確認します。始める前に、ネットワークの種類、Global Routing、選択中のサーバー、接続できない対象を記録してください。その後、明確な問題を一度だけ再現し、その時間帯に関する診断結果を確認します。無関係な過去の情報を大量に混ぜて調査しないでください。

診断結果は、HomeのConnectivity Test、実際の接続先へのアクセス、Dataの記録と照らし合わせて確認します。ログに失敗が1件あっても、すべての接続が失敗したとは限りません。同様に、特定のテストに成功しても、すべてのアプリが正常にアクセスできるとは限りません。情報をエクスポートまたは共有する前に、サブスクリプションURL、認証情報、個人のアクセス記録が含まれていないか確認してください。

1. 現在の状態を記録します。Global Routing、選択中のサーバー、有効な構成、On Demandの条件を記録し、構成を変更する前にコピーを保存します。
2. まず手動接続をテストします。自動接続の影響を一時的に除外し、Homeでデフォルトサーバーを選択して接続スイッチをオンにします。システムの案内に従ってVPN構成を許可してください。
3. 次に実際のアクセスをテストします。Connectivity Testを実行してから目的の接続先にアクセスし、テストの失敗、ドメインの名前解決失敗、対象サービスから応答がない状態を区別します。
4. モードとルールを照合します。必要に応じてProxyとConfigの結果を一時的に比較し、ルールの順序、最終ポリシー、DNSを確認します。設定は一度に1つだけ変更してください。
5. 最後に自動接続の条件を戻します。手動接続と通信の振り分けが正常だと確認してからOn Demandを再び有効にし、実際にネットワークを切り替えてトリガー動作を確かめます。

問題の原因を特定できない場合は、現象を再現できる最小限の手順を残し、完全マニュアルに沿って段階ごとに確認してください。初期設定は接続手順から始められます。購入、システム要件、対応状況はApp Storeの正規品確認ページをご覧ください。システム要件と対応デバイスはApp Storeの表示を基準とします。