Shadowrocket 公式マニュアル · はじめに
Shadowrocketの使い方:
追加・接続・確認
まず既存の設定をアプリに追加し、Global Routingを選んで接続を開始します。最後に実際の通信で結果を確認します。以下の5つの手順に沿って進めてください。途中でつまずいた場合は、その段階を確認し、すべてのSettingsを同時に変更しないようにしましょう。
Add Server:サーバーの追加/サブスクリプションの読み込み
まず、手元にあるのがサブスクリプションURLか、サーバー情報一式かを確認します。いずれか一方の方法で追加すればよく、両方を登録する必要はありません。
Shadowrocketを開いてHomeに移動し、SERVERの近くにあるAdd Serverを選びます。画面上の追加ボタンから同じ編集画面を開くこともできます。入力を始める前にTypeを確認してください。Typeによって表示される項目が変わります。入力欄が少ないという理由だけで、プロトコルを選ばないでください。サブスクリプションURLはサーバー一覧を取得するためのアドレスです。一方、個別のサーバー情報には通常、プロトコル、アドレス、ポート、認証情報が含まれます。用途が異なるため、混同しないようにしてください。
サブスクリプションURLがある場合:Subscribeを選択
Add ServerのTypeでSubscribeを選び、ご自身のサブスクリプションURLをすべてURLに入力します。貼り付けた後、前後に空白や改行がないか、URLの一部だけをコピーしていないか確認してください。URLのクエリパラメーターも必要な情報です。短くするために削除しないでください。メモ欄は設定元の識別に使えますが、誤ったURLを修正するものではありません。内容を確認し、画面上の保存または完了操作を行ってHomeに戻り、一覧の取得が終わるまで待ちます。
保存できたことと、一覧を取得できたことは別です。戻ったら、サブスクリプション名だけでなく、その下に実際のサーバー項目が表示されているか確認してください。一覧が空、または取得エラーが表示された場合は、サブスクリプションURLにネットワークからアクセスできるか、URLが有効かを確認し、利用中のサービス提供元にサブスクリプションの状態を問い合わせてください。この段階で接続スイッチを何度も操作しても、項目は追加されません。サブスクリプションの内容が更新された場合は、該当する更新操作で再取得できます。更新前に必要なローカルメモを残し、削除済みの古い項目を選んでいないか確認してください。
個別のサーバー情報がある場合:該当する項目を入力
サーバー情報をお持ちの場合は、Typeで情報に記載されたプロトコルを選び、HostやPortなどを入力します。Hostにはサーバーのドメイン名またはアドレスを入力し、サブスクリプションURL全体は入力しないでください。Portには指定されたポート番号を入力します。たとえばShadowsocksでは、PasswordとMethodをサーバー側の設定に合わせる必要があります。その他のプロトコルでは、認証、TLS、通信方式の項目が異なる場合があります。元の情報と照らし合わせて入力し、別のプロトコル用の設定を流用しないでください。
確認時は、数字と英字の違い、パスワード前後の空白、TLS関連の名称が元の設定と一致しているかに注意してください。情報にない項目がある場合は、そのプロトコルで必須かどうかを確認し、ネット上の別の設定例から値を推測しないでください。画面下部のScan QR Codeは、ご自身に利用権限のある設定のQRコードを読み取るための機能です。Import from Cloud JSONは対応形式のデータ向けで、任意のテキストを設定に変換する汎用機能ではありません。初めて設定する場合は、原因を特定しやすくするため、読み込み方法を1つに絞りましょう。
保存したらHomeに戻り、SERVERに識別できる項目が表示されていることを確認して、今回使用するサーバーを選びます。サブスクリプションには複数の項目が含まれる場合があり、読み込みが完了しても正しい項目が選択されているとは限りません。ここまででサーバーを1つ選択できたら、次にどのリクエストをそのサーバーに通すかを決めます。SubscribeとConfigの違いは用語早見表をご覧ください。
Global Routing:3つのモードを選択
サーバーの追加は「どこに接続するか」を決め、Global Routingは「リクエストをどう処理するか」を決めます。まずこの違いを理解してから接続を開始してください。
Homeに戻り、Global Routingを開いてConfig、Proxy、Directを確認します。ここで選ぶのはリクエストの処理方法であり、サーバーのプロトコルやサブスクリプションの種類ではありません。切り替えた後はHomeに戻り、現在の表示名を確認してください。選択したつもりでも、前のモードのままになっていることがあります。
Config:現在の設定ファイルのルールに従う
Configは、現在の設定ファイル内のルールに基づいて、DIRECT、PROXYなどのポリシーをリクエストに適用します。使用前にConfigを開き、どのファイルが選択されているか確認してから、その中のRuleを確認してください。ファイル名だけで内容を判断せず、一覧に表示されていることと、そのファイルが実際に適用されていることを混同しないでください。ルールが特定のポリシーやサーバーを参照している場合は、現在の設定に該当する項目があることも確認します。
スクリーンショットに表示されているGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは、設定ファイル内の各セクションです。初回接続でそれぞれを編集する必要はなく、接続のために関連機能をすべて有効にする必要もありません。内容を理解し、利用権限のある設定を使い、元のコピーを保管してください。まず基本的なリクエストが通ることを確認してから、必要なルールを1つずつ追加します。Add Ruleはルールの追加に使うもので、サーバーの追加画面ではありません。サーバー項目は引き続きHomeで管理します。
ルールの順序によって結果が変わります。対象のリクエストが先にDIRECTに一致すると、後にある、より具体的なPROXYルールは判定されないことがあります。そのため、「サーバーを選んだのにWebサイトが直接接続される」場合も、サーバーの保存に失敗したとは限りません。Configのマッチ結果が原因の可能性もあります。ここでは選択方法と確認方法を把握し、ルールのキーワードや設定の詳細はSettingsとルールのリファレンスで確認してください。初回接続時に複雑な設定を同時に変更するのは避けましょう。
Proxy:選択したサーバーのプロキシ経路を確認する
Proxyでは、通常このモードで処理されるリクエストをプロキシ経由にできます。ルール選択による影響を一時的に切り分ける場合に便利です。確認できるのは、「現在の振り分けルールに頼らず、選択中のサーバーで対象にアクセスできるか」という点です。あらゆる問題を解決するスイッチではなく、誤ったパスワード、ポート、TLS項目を自動で修正する機能でもありません。比較が終わり、普段どおりルールに基づいて振り分ける場合は、Configに戻してルールを確認してください。
Direct:直接接続との比較に使う
Directは直接接続するためのモードです。このモードでは、選択中のサーバーを経由することは期待できません。直接接続とプロキシ接続を比較する場合は、同じ宛先のままモードだけ切り替えて、リクエストを再実行します。原因を特定できるよう、変更する条件は毎回1つにしてください。選択後は、現在のモードとサーバー名を控えます。次の接続と確認は、この状態を基準に行います。
Home:接続を開始して許可を行う
サーバーとモードを確認してから、画面上部のスイッチを操作します。システムの許可は、設定がネットワークを制御することを認めるもので、外部へのアクセスが成功したことを証明するものではありません。
Homeに戻り、SERVERで選択中の項目を確認し、Global Routingが先ほど選んだConfig、Proxy、Directのいずれかになっていることを確かめます。サブスクリプションを更新した場合は、選択中の項目がまだ存在するかも確認してください。初回テストでは、現在のネットワークを安定させます。接続を開始する際にWi-Fiの切り替え、設定変更、サブスクリプションの更新を同時に行うと、結果が変わった原因を特定しにくくなります。
Home画面上部の接続スイッチをオンにします。初回接続時には、システムからVPN構成の追加を許可するよう求められる場合があります。案内を確認し、現在開いているShadowrocketからの操作であることを確かめてから、システムの指示に従って許可し、端末の認証を完了してください。この許可は、アプリが端末上のネットワーク接続を確立するためのものです。アプリの購入、サブスクリプションURLの入力、サーバーのパスワード確認とは別の手順であり、互いに代用できません。
以前に許可を取り消した場合は、アプリに戻ってもう一度試し、システムの案内が再度表示されるか確認してください。許可を得るために、端末の認証に関係のないアカウント情報を入力しないでください。組織管理下の端末では、VPN構成の追加が制限されることがあります。既存の構成を繰り返し削除するのではなく、端末の管理ルールを確認してください。システム設定の場所はOSのバージョンによって異なる場合があります。実際の端末に表示される案内に従ってください。
許可が完了したらHomeに戻り、接続状態が変わるまで待ちます。公式スクリーンショットのNot Connectedは、撮影時点で未接続だったことを示すもので、この状態に保つという意味ではありません。実際の操作では、スイッチがオンのままか、状態が接続済みに変わるかを確認します。すぐにオフになる、または接続できない場合は、まずよくある失敗を参照して許可と入力情報を確認してください。接続が確立していない状態を、ルールの問題として扱わないようにしましょう。
接続状態が確立したことは、端末上の接続処理が対応する状態に進んだことを示すだけです。特定のWebサイトがPROXY経由で通信したことや、外部サービスが利用できることまでは証明しません。システムのVPNアイコンが表示されても、各リクエストの最終的なポリシーは判断できません。次にConnectivity Test、実際のアクセス、リクエストログを照らし合わせて確認します。初回の確認が終わるまでは、On Demandなどの自動化設定を追加しないでください。
Connectivity Test:動作を確認
「接続を確立できる」「対象にアクセスできる」「リクエストが想定どおり振り分けられる」をそれぞれ確認します。必要な証拠は、結論ごとに異なります。
HomeでConnectivity Testを実行し、アプリが返すテスト結果を確認します。結果は現在のTest Method、テスト対象、ネットワーク状態に左右され、そのときの条件だけを反映します。ある項目にテスト結果が表示されても、すべてのWebサイトにアクセスできるとは限りません。テストがタイムアウトしても、認証情報が間違っているとは限りません。テスト対象に到達できない場合や、現在のネットワークが特定の確認方法を制限している場合も、結果に影響します。まず結果を記録し、その後に実際のアクセスを確認してください。単一の数値だけで設定の正否を判断しないようにしましょう。
ブラウザーを開き、利用権限があり、想定する経路が明確なページにアクセスして、内容を再読み込みできるか確認します。できるだけ新しいリクエストを発生させてください。既に表示されているページは、キャッシュから読み込まれたり、以前の接続が使われたりする場合があります。2つのモードを比較する場合は、対象とネットワークを変えず、切り替えるたびにページを再読み込みします。サーバーと対象を同時に変えると、成功しても何が作用したのか判断しにくくなります。
Configを使用している場合は、アプリのリクエスト記録やLog関連の情報も確認し、対象ドメイン、一致したルール、最終的なポリシーを照合します。プロキシ経由を想定した対象は該当するプロキシポリシーに、直接接続を想定した対象は対応する直接接続の結果になっている必要があります。ページが開けたことだけでは、正しく振り分けられたとは証明できません。同様に、設定ファイルにルールが記載されていても、そのリクエストが実際に一致したとは限りません。記録の確認方法とDNSのチェック方法は、Log設定のリファレンスとDNS設定のリファレンスをご覧ください。
ProxyではアクセスできるのにConfigでは失敗する場合は、現在の設定ファイル、ルールの順序、ポリシーの参照先、名前解決の経路を優先して確認します。どちらのモードでも失敗する場合は、サーバー自体、入力情報、現在のネットワークを確認してください。Directで正常にアクセスできても、対象がもともと到達可能かを踏まえて判断し、プロキシが有効になったと結論づけないでください。テスト対象は1、2件に絞り、条件を明確に比較しましょう。項目を次々と切り替えるのは避けてください。
検証後は、再現可能な基準として、使用したサーバー、Global Routingのモード、現在の設定ファイル、対象アドレス、結果を記録します。今後On Demandを有効にしたり、DNSやRuleを変更したりした場合は、この条件で再テストできます。初めての設定はここまでで完了です。「設定をすべて整える」ために機能を一通り有効にする必要はありません。用語を確認したい場合は用語早見表をご覧ください。
Settingsとトラブルシューティング:変更は一度に1つ
最初に失敗した段階から確認します。読み込み、接続、名前解決、振り分けはそれぞれ別の段階です。すべての設定を一度にリセットしないでください。
一覧に項目がない:サブスクリプションの取得を確認
Homeに選択可能なサーバーが表示されない場合は、SubscribeのURLが完全か、サブスクリプションの取得時にエラーが発生していないか、ご自身のサブスクリプションがまだ有効かを確認してください。取得が完了してから項目を選択します。サブスクリプションの取得エラーと個別サーバーへの接続エラーは、分けて対処してください。サーバーのHostとサブスクリプションURLを取り違えたり、認証情報を含むURLを公開の場に投稿したりしないでください。有効性は利用中のサービス提供元に確認します。アプリの購入記録では代わりになりません。
項目はあるが接続できない:Typeと認証情報を確認
該当項目の編集画面を開き、元の情報とType、Host、Port、認証情報を一つずつ照合します。次に、そのプロトコルで必要な通信方式とTLSの項目を確認してください。不一致が見つかった項目だけを修正し、保存後に同じ対象へ再テストします。一般的なトラブル対策として証明書の検証を無効にしないでください。証明書名、システム時刻、設定情報は、それぞれ別に確認する必要があります。すべて一致しているのに接続できない場合は、現在のネットワークとエラーの内容を記録し、サーバー側の状態確認が必要か判断します。
接続スイッチがオンのままにならない:許可と自動接続条件を確認
接続が確立する前にスイッチが自動でオフになる場合は、まずシステムでVPN構成の追加が許可されているか、ほかに有効なネットワーク構成が現在の接続に影響していないか確認します。SettingsのOn Demandは条件に応じて接続を開始する機能であり、誤ったサーバー情報を修正するものではありません。既にOn Demandを設定している場合は、トラブルの確認中にその条件が自動接続を開始したり、想定外の動作を引き起こしたりしないか確認してください。手動接続の基本確認を終えてから、必要に応じて設定します。詳しくはOn Demandのリファレンスをご覧ください。
テスト結果と実際のアクセスが異なる:テスト方法とリクエスト記録を確認
SettingsのTest Methodによってテスト方法が変わります。前後の結果を比較する際は、同じテスト方法を使用してください。方法を変更した後に結果が変わっても、すぐにサーバー性能の変化と判断しないでください。さらに調べる場合はDiagnostics関連の項目を確認し、Logに記録された実際のエラーと照らし合わせます。LanguageやToday Widgetは、認証エラーを解決するために必要な設定ではありません。明確な根拠がないまま、Proxy、TCP、UDPの設定をまとめて変更するのも避けてください。
特定のドメインだけ失敗する場合は、そのリクエストに一致したルール、DNSの結果、対象側の状態を優先して確認します。すべてのリクエストが失敗する場合は、接続と入力情報の段階に戻ります。特にProxyでは使えてConfigでは使えない場合、サブスクリプションをすぐに再入力するのではなく、設定の違いを確認してください。変更するたびに手順4で記録した条件を使って再検証し、改善が再現することを確かめてから変更を残します。
トラブル情報を共有する前に:機密情報を削除
失敗した手順、現在のモード、使用プロトコル、エラーメッセージ、再現性は記録できます。ただし、サブスクリプションURL全体、パスワード、認証情報、個人情報を含む設定ファイルを公開しないでください。スクリーンショットやログにも情報が含まれる場合があるため、共有前に項目ごとに確認します。元の設定のコピーを保存し、試行を重ねた後も元に戻せるようにしてください。状況別の詳しい説明はトラブルシューティングをご覧ください。Settingsを項目ごとに確認する場合は設定リファレンスをご利用ください。