公式マニュアル · 機能と設定

Shadowrocket
プロキシモードと設定の解説

通常の利用では、まずConfigを選び、設定ルールと現在のサーバーを確認します。一時的な診断の場合のみProxyまたはDirectに切り替え、設定を変更するときは一度に1項目だけ調整してください。

iPhone / iPad / Mac / Windows / Android / Linuxに対応しています。以下ではiPhone / iPadの操作手順を例に説明します。他のプラットフォームでは、各画面で同じ機能名を探してください。項目の場所や利用可否は、現在のクライアントにより異なります。

モード・ルール・サーバーの役割を確認

Shadowrocketの接続結果は、1つのスイッチだけで決まるものではありません。Global Routingは通信全体の処理方法を決め、Config内のルールはリクエストごとのポリシーを指定します。Homeで選択したサーバーは、プロキシが必要な接続の出口になります。それぞれ役割が異なるため、サーバーを切り替えても誤ったルールは修正されず、サブスクリプションを更新しても現在のConfigが切り替わるわけではありません。

事前に、ご自身のサブスクリプションまたはサーバー情報をご用意ください。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。クライアントの買い切り料金と回線プランは別のものです。アプリの入手費用と、お手持ちの回線が利用できるかどうかも関係ありません。

Global Routingの3つのモード

Configはルールに従うモード、Proxyはプロキシモード、Directは直接接続モードです。説明は日本語ですが、操作時は英語の項目名を確認してください。

概要:Global Routingは通信全体のルーティング方法を選ぶ項目であり、サーバーのプロトコル設定ではありません。場所:HomeでGlobal Routingを探します。設定方法:通常はルールに従って通信を処理するConfigを選択します。プロキシ経由と通常のネットワークの状態を比較するときだけ、一時的にProxyまたはDirectを使用してください。

モード処理方法利用場面確認するポイント
Config現在のConfigに設定されたルールに従って接続ポリシーを決定します。普段のルール振り分けに使用。ドメインやアドレスごとに接続方法を分けます。現在のConfigが正しいか、ルールの順序が適切か、ポリシーの接続先が利用可能かを確認します。
Proxyクライアントが処理する通信をプロキシモードで処理します。ルール振り分けが問題の原因か、一時的に切り分ける場合に使用します。現在のサーバーに接続できるかを確認します。デバイス上のすべての通信を対象にするモードではありません。
Directクライアントが処理する通信を直接接続モードで処理します。通常のネットワーク経由とプロキシ経由の経路を一時的に比較します。通常のネットワークから接続先にアクセスできるかを確認します。このモードは接続スイッチをオフにすることとは異なります。

確認ポイント:あるWebサイトがProxyでは正常でConfigでは不調な場合、まず適用されたルールとポリシーを確認してください。ただし、これは切り分けの手がかりであり、設定ミスと断定はできません。DNSの名前解決や既存の接続が結果に影響する場合もあります。モードを切り替えたらリクエストを新たに実行し、必要に応じて古い接続を終了してから、同じ条件で比較してください。

切り分けが終わったら、普段使っているモードに戻してください。Proxyのまま長期間使用すると、通常のルール振り分けが変わります。Directのままでは、プロキシが必要なリクエストも直接接続される可能性があります。モードを切り替えても、不足しているサーバー情報は補えません。TLS、通信方式、認証情報を正しく設定する必要があります。

ルール振り分け:マッチ条件と実行ポリシー

まずリクエストに適用されるルールを確認し、次にそのルールが指定するポリシーを確認します。

ルールタイプでマッチ対象を確認

DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはドメインとそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン内のキーワードで判定します。IP-CIDRとIP-CIDR6はそれぞれIPv4、IPv6のアドレス範囲を指定し、GEOIPはアドレスの地域情報で判定します。USER-AGENTはリクエスト内の該当フィールドを対象とします。適用できる範囲は通信を識別できるかどうかによるため、すべての暗号化通信を識別できる汎用的な方法ではありません。

ポリシーで接続の処理方法を指定

DIRECTは直接接続、PROXYは指定されたプロキシポリシーで処理、REJECTは接続拒否を表します。ルールからConfigで定義されたポリシーグループを参照する場合は、グループ名とグループ内の選択項目も確認してください。FINALは、それ以前のルールに一致しなかったリクエストを処理します。優先度の高い強制ルールではなく、通常はルール一覧の末尾に配置します。

場所:Configを開き、使用中の設定を確認してから、ルールを表示または編集します。設定方法:まずConfigのコピーを保存し、対象範囲が狭く意図が明確なルールを、汎用的なルールより前に配置します。通常、ルールは上から順に照合され、一致した時点で該当ポリシーに従って処理されます。そのため、特定ドメイン向けのルールより前に範囲の広いルールが一致すると、後に置いた個別ルールは期待どおりに適用されません。

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

上記は構文と順序の例です。example.comとそのサブドメインにはPROXYを適用し、続いてGEOIPルールで判定し、それ以外はFINALで処理します。あらゆるネットワークに適した完全なConfigではありません。変更後は対象ドメインへ新しいリクエストを送り、接続ログでポリシーを確認してください。ホーム画面に接続済みと表示されているかだけでは判断できません。

確認ポイント:アドレスを対象とするルールには、DNSの名前解決結果が影響する場合があります。問題が起きるたびに似たルールを追加するのではなく、まずドメインの指定が正しいか、対象のポリシーが存在するかを確認し、その後にルールの順序やキャッシュの影響を切り分けてください。ほかのキーワードは用語クイックリファレンスをご覧ください。

サブスクリプションとサーバーの管理

Subscribeで一括管理する接続元を管理し、Add Serverで個別のサーバー情報を管理します。

概要:サブスクリプションは、サーバー一覧の取得や更新に使う接続元です。個別のサーバーには、プロトコル、アドレス、ポート、認証などの接続情報が含まれます。サブスクリプションを更新すると、その接続元の項目が更新されますが、サーバーの利用可能性やConfig内のルールが更新されたことを保証するものではありません。

場所:Homeの追加メニューからSubscribeを探します。手動で追加する場合はAdd Server、QRコードから読み込む場合はScan QR Codeを使います。設定方法:ご自身のサービス提供元から案内された完全なサブスクリプションURLを該当欄に入力し、保存して一覧を更新した後、使用するサーバーを選択します。手動で追加する場合は、まずプロトコルを選び、手元の情報に従ってアドレスと認証情報を入力してください。VLESS、VMess、Trojanなどのプロトコルでは、項目を互いに流用できません。

  1. 読み込む前に情報が揃っていることを確認してください。特に、コピー時に空白、改行、説明文が混入していないか注意します。
  2. 読み込み後、グループ名と項目名を確認し、想定した接続元の内容であることを確かめます。同じサブスクリプションを重複して読み込まないようにしてください。
  3. 更新する場合は、対象のサブスクリプションを更新します。クライアントに自動更新の設定がある場合は、必要に応じて有効にしてください。
  4. サーバーを選択したらConnectivity Testを実行し、実際のリクエストでも確認します。テストに成功しても、すべての接続先にアクセスできるとは限りません。

確認ポイント:サブスクリプションURLには個人の認証情報が含まれる場合があります。公開するスクリーンショット、ログ、投稿などに載せないでください。サブスクリプションから生成された項目は、更新時に上書きされることがあります。長期間保持したい設定を変更する場合は、事前に別のコピーを保存し、今後の管理方法と両立するか確認してください。サブスクリプションを削除する前に、含まれるサーバーを残す必要がないか確認し、「更新」のつもりで誤って「削除」しないよう注意してください。

一覧が空の場合は、まず接続元のURLと取得内容を確認し、その後、ご自身のサービスの状態を確認してください。項目があるのに接続できない場合は、サーバー情報やネットワークを確認します。問題の発生箇所が異なるため、何度も読み込み直して一緒に対処しないでください。具体的な読み込み手順ははじめにをご覧ください。

On Demandによるオンデマンド接続

接続を試みるタイミングを制御します。リクエストの経路を決めるルールとは別の機能です。

まず手動で接続できることを確認

概要:On Demandは、システムがサポートする条件に応じて接続を開始します。場所:SettingsでOn Demandを探してください。設定できる条件は、現在のシステムやクライアントの表示をご確認ください。設定方法:まず自動起動を無効にし、サーバー、Config、接続許可が正常に動作することを手動で確認してから、必要な条件を1つずつ追加します。

次に起動・停止条件を確認

確認ポイント:有効にしていると、条件が満たされたままの場合、手動で切断しても接続が再開することがあります。必ずしもスイッチの故障ではありません。テスト時はネットワークの状態を記録し、条件に入った場合と条件から外れた場合の両方を確認してください。自動接続を一時停止する場合は、接続スイッチを操作する前にOn Demandの条件を変更するか、機能を無効にしてください。再接続を故障と誤認しないためです。

ネットワークを切り替えても、既存の接続が必ず維持されるとは限りません。Wi-Fiとモバイル通信の切り替えで再接続が必要になる場合があり、バックグラウンドでの動作はシステムのスケジュールにも左右されます。On Demandは、無効になったサブスクリプションやサーバーを修復する機能でも、ルール設定の代わりでもありません。起動条件をテストした後も、実際のリクエストに想定したポリシーが適用されているか確認してください。

Dataで通信量を確認

概要:Dataでは、クライアントが記録した通信量を確認できます。一定期間にリクエストが発生したか、通信量の内訳が想定どおりかを判断する際に役立ちます。場所:Dataを開き、現在の画面で利用できる集計項目を確認してください。項目の詳細や集計期間は、プラットフォームによって異なる場合があります。

確認方法:まず表示が累計値か現在の集計期間の値か確認し、再現可能なアクセスを1回行って前後の変化を比較します。統計をリセットする場合は、必要な数値を事前に記録してください。リセットすると、問題発生時の比較対象が失われることがあります。アップロードとダウンロードでは通信方向を区別し、瞬間的な速度と累計通信量を混同しないようにしてください。

確認ポイント:クライアント、デバイスのシステム、サービス提供元では、集計対象が異なる場合があります。プロトコルのオーバーヘッド、接続時間、集計期間も異なるため、Dataの数値をそのまま回線の請求額と見なすことはできません。通信量が増えていても、通信が発生したことを示すだけで、特定のWebサイトへのリクエストが成功した証拠にはなりません。増加がない場合も、対象期間と集計範囲が正しいか先に確認してください。

Settingsの主な項目

変更前の値を記録し、1項目ずつ変更してください。Config内の設定と全体設定の両方を確認します。

DNS:ドメイン名の名前解決

概要:DNSはドメイン名をアドレスに変換します。接続や一部のルール判定に先立つ処理です。場所:SettingsでDNSを探し、現在のConfigにも関連設定が含まれているか確認してください。設定方法:実際に適用されている設定元を確認し、ネットワーク環境から到達できるDNSサーバーを指定します。元の値は戻せるように記録しておいてください。

確認ポイント:「接続できない」という理由だけでDNSを変更しないでください。ドメイン名の解決と接続先への接続は別の段階です。変更後もキャッシュや既存の接続が影響する場合があります。問題がIPv6に限られる場合は、アドレスと経路が一致しているか確認し、DNS、プロトコル、ルールを同時に変更しないでください。

Test Method:テスト方法

概要:Test Methodは、対象の接続テストに使用する方法を指定します。場所:SettingsでTest Methodを探し、HomeのConnectivity Testと併用します。設定方法:現在の画面で選べる方法を使用し、同じネットワークとサーバーで、なるべく近い時間に結果を比較してください。

確認ポイント:テスト方法によって測定対象が異なるため、数値をそのまま比較することはできません。テストのタイムアウトはテスト先に起因する場合があります。また、テストが成功しても、すべてのWebサイトやアプリが正常に動作するとは限りません。最終的には実際の接続先へのリクエストと診断ログで判断してください。

Today Widget:クイックアクセス

概要:Today Widgetは、システムが対応している場合に利用できるクイック操作用のウィジェットです。場所:SettingsでToday Widgetを探し、システムのウィジェット管理画面から追加できるか確認してください。設定方法:現在表示されている項目を設定し、まずアプリ内で接続を確認してから、ウィジェットの操作をテストします。

確認ポイント:ウィジェットを追加できるか、更新されるか、どの情報が表示されるかは、システムのバージョンによって異なります。使用中のシステムに該当する項目がない場合は、存在しない設定を探す必要はありません。Homeから接続を操作してください。ウィジェットの表示には遅れが生じる場合があるため、接続状態はアプリに戻って確認します。

iCloud:設定の同期

概要:iCloud関連機能では、対応するAppleデバイス間で、クライアントが許可するデータを保存または同期できます。場所:SettingsでiCloudを探し、システム側のiCloud権限とアカウントの状態を確認してください。設定方法:操作前にローカルコピーを保存し、アップロード、復元、同期のどれを行うか確認してから、画面の指示に従ってください。

確認ポイント:同期対象は画面の説明に従ってください。すべてのサーバー認証情報や動作状態が同期されるとは限りません。複数のデバイスで編集すると、上書きや競合が発生する場合があります。残すコピーをあらかじめ決めてください。ここでのiCloud機能は、すべてのプラットフォーム間で設定を共有するものではなく、App Storeの購入履歴を復元するための機能でもありません。

Diagnostics:問題の発生段階を特定

概要:Diagnosticsでは、現在のクライアントが提供する診断情報を確認し、名前解決、接続、認証、ルール処理など、どの段階で問題が起きているかを切り分けられます。場所:SettingsでDiagnosticsを探してください。プラットフォームによって別の場所にある場合は、実際の画面を確認します。使い方:必要に応じて診断を有効化または実行し、問題を1度再現してから、該当する時間帯の結果を確認してください。

  1. 問題が起きたときのネットワーク環境、Global Routingの選択、現在のConfigとサーバーを記録し、比較できる条件を整えます。
  2. 対象を1つに絞ってアクセスし、エラーが発生した時刻とメッセージを記録します。大量のテストを同時に実行して、結果が混在しないようにしてください。
  3. まずドメイン名を解決できるか確認し、次に接続が確立するかを確認します。認証またはTLSに関するメッセージが表示された場合は、サーバー情報とデバイスの時刻を確認してください。
  4. Configだけで問題が起きる場合は、ルールとポリシーを確認します。Proxyでも問題が起きる場合は、サーバーとネットワーク経路を確認してください。

確認ポイント:診断結果は問題を切り分けるための手がかりであり、自動的に修復を判断するものではありません。1つのタイムアウト情報だけでネットワーク全体が使えないと判断しないでください。記録を保存する場合は、サブスクリプションURL、サーバーアドレス、認証情報が含まれていないか確認し、共有する前に機密情報を削除してください。調査後は、一時的に追加した記録設定を適切な状態に戻します。

設定を確認する順番

設定を一度に複数リセットするより、段階ごとに確認するほうが、問題を再現しやすく元に戻すのも簡単です。

  1. 接続元を確認。既存のサブスクリプションを更新できるか、サーバー情報が揃っているか、古い項目を誤って選んでいないかを確認します。
  2. モードを確認。通常はConfigを使用しているか、一時的なテストの後に元のモードへ戻し忘れていないかを確認します。
  3. Configを確認。現在有効なConfigが、直前に編集したファイルかどうか、ポリシー名が存在するかを確認します。
  4. 名前解決と経路を確認。DNS、サーバーへの接続、実際の接続先へのリクエストをそれぞれ確認します。1つのテスト数値だけですべてを判断しないでください。
  5. 自動動作を確認。On Demandが接続を再開していないか、iCloudやサブスクリプションの更新でローカルの変更が上書きされていないかを確認します。
  6. 記録して元に戻せるようにする。設定を1項目変更するたびに再テストし、変化を記録します。改善しない場合は元の値に戻してから、次の項目を確認してください。

初回の読み込みがまだの場合ははじめにをご覧ください。ルールのキーワードを確認するには用語クイックリファレンスをご利用ください。ストアからの入手、OSへのインストール、購入済みアプリの復元については、全プラットフォームのダウンロード案内とよくある質問をご覧ください。これらはGlobal Routingとは異なる問題のため、ルールを書き換えて対処する必要はありません。