Shadowrocket 初回接続ガイド
既存の情報を追加し、Global Routingを選んでから接続と動作確認を行います。
iPhone・iPad向けです。初回設定は以下の5つの手順で進めます。
手順1:サーバーまたはサブスクリプションを追加
まずHomeに選択可能なサーバーを表示してから、モードと接続スイッチを設定します。サブスクリプションリンクと個別サーバー情報は、入力方法が異なります。前者では更新可能なサーバー一覧を取得し、後者では1台分の具体的な設定を保存します。手元にある情報に合わせてどちらか一方を選び、同じ内容を重複して追加する必要はありません。
サブスクリプションリンクをお持ちの場合:Subscribeを選択
Shadowrocketを開いてHomeに進み、右上のプラスボタンをタップしてAdd Serverを開きます。TypeでSubscribeを選択し、自分の完全なサブスクリプションリンクをURLに入力します。識別しやすい名前を付け、右上のDoneをタップして保存します。Homeに戻り、サブスクリプションの取得が完了するまで待ってから、該当するグループにサーバーが表示されているか確認します。
リンクは元の内容から最後まで正確にコピーしてください。説明文、空白、改行を含めたり、末尾の複雑に見えるパラメーターを手動で削除したりしないでください。サブスクリプションリンクには認証情報が含まれる場合があり、パラメーターによって取得権限が決まることがあります。リンクは自分のデバイスだけで使用し、完全なURLを公開コメント、グループチャット、トラブルシューティング用のスクリーンショットに載せないでください。
保存後にサブスクリプション名だけが表示され、サーバーが表示されない場合は、現在のネットワークから内容を取得できるか確認してから、該当するサブスクリプションを更新してください。サービス提供元のWebサイトのURLがサブスクリプションリンクとは限りません。ログインページ、注文ページ、通常の案内ページはSubscribeに入力できません。Webページやエラーメッセージが返された場合は、プロトコル設定を何度も変更せず、リンクの用途をサービス提供元に確認してください。
個別サーバー情報をお持ちの場合:Add Serverに入力
サーバーアドレス、ポート、パスワード、UUIDなどの個別項目を受け取った場合も、HomeのプラスボタンからAdd Serverを開きます。TypeではSubscribeではなく、案内されたプロトコル(Shadowsocks、VMess、VLESS、Trojanなど)を選択してください。元の情報に従ってサーバーアドレス、ポート、認証項目を入力します。プロトコルによって表示される項目は異なるため、別のプロトコルの項目を補う必要はありません。
暗号化方式、TLS、Server Name、転送方式、パスなどの追加パラメーターには特に注意してください。これらは任意のメモではなく、サーバー側の指定と一致させる必要があります。アドレスとポートが正しくても、設定全体が正しいとは限りません。警告を消すためにプロトコルを変更したりTLSを無効にしたりしないでください。必要な情報が不足している場合は、サービス提供元の案内を確認してください。
対応するQRコードをお持ちの場合は、Scan QR Codeで読み取れます。カメラへのアクセスはQRコードの読み取りに使用します。読み取り後も、認識されたプロトコル、アドレス、ポートを確認してから保存してください。QRコードにも接続情報が含まれる場合があるため、公開しないでください。手入力とスキャンは登録方法が異なるだけで、その後のサーバー選択と接続手順は同じです。
Homeに戻り、使用するサーバーを選択
保存後、Homeのサーバー一覧で使用するサーバーをタップし、左側の選択マークが点灯していることを確認します。サーバー名が一覧に表示されても、インポートできたことを示すだけで、すべての項目のテストに成功したことや、特定の項目が既定のサーバーとして選択されたことを意味しません。初回は名前と用途が明確なサーバーを選び、サーバーの切り替えと他の設定変更を同時に行わないようにします。
この段階の完了条件は、Homeにサーバーが表示され、使用する項目が選択され、記録を開いて設定を確認できることです。Subscribeはサーバーの取得元を管理し、Configは設定ファイルを管理します。混同しないでください。用語を確認したい場合は、まず用語クイックガイドをご覧ください。基本的な追加が終わったら次に進みます。
手順2:Global Routingを選択
サーバーはプロキシ接続の出口を決め、Global Routingは通信の処理方法を決めます。HomeでGlobal Routingをタップし、目的に合わせてConfig/Proxy/Directを選択してください。初回の動作確認では、どのモードを選んだかを明確にします。そうしないと、接続スイッチがオンでも、通常の振り分け結果を接続失敗と誤認することがあります。
Config:現在の設定ファイルに従って処理
Configでは、現在使用中の設定ファイルとルールに従って通信を処理します。このモードを使う前にConfigを開き、使用する設定ファイルが選択されていることを確認してください。ファイルが一覧に表示されているだけでは、選択済みとは限りません。ファイル名だけで内部のルールを判断することも避けてください。設定ファイルがまだない場合は、まず接続の基本確認を行い、その後、公式マニュアルに沿って振り分けを設定すると、出所の不明な設定を複数読み込むよりトラブルを切り分けやすくなります。
ルールは通常、上から順に照合され、接続先にはDIRECT、PROXYなどの設定済みポリシーが適用されます。たとえば、DOMAIN-SUFFIX,example.com,PROXYは該当ドメインにPROXYを適用し、FINAL,PROXYはそれ以前のルールに一致しない接続の最終処理を指定します。ここでは構文を説明しているだけで、初回設定時にすぐルールを編集する必要はありません。既存の設定を上書きしないでください。
Proxy:プロキシ経路の確認に使用
Proxyはルーティング全体をプロキシ経由に設定し、選択したサーバーで実際にアクセスできるかを初めて確認する場合に適しています。Homeでサーバーを選択してからProxyを選び、次の手順で接続します。初回テストで振り分けルールの影響を減らせますが、どのような状況でもすべての通信が必ずリモートサーバーを経由するとは限りません。システム通信、除外項目、関連設定によって実際の経路が変わることがあります。
ProxyでテストとWebページの表示が正常なのに、Configに切り替えると特定の接続先だけに問題がある場合は、サブスクリプション全体を再インポートするのではなく、その接続先に適用されたルールやポリシーを確認してください。この比較により、「サーバーが利用できない」場合と「振り分け結果が想定と異なる」場合を切り分けられます。
Direct:プロキシ接続の成功確認には使わない
Directは通信を直接接続として処理し、通常のアクセス経路として選択中のプロキシサーバーを使用しません。デバイス本来のネットワークとの比較には使えますが、DirectでWebページを開けても、追加したプロキシサーバーが有効とは確認できません。また、アプリの接続スイッチをオンにすることとプロキシを使用することは別の判断です。スイッチの状態だけで結論を出さないでください。
この手順が終わったら、選択したモードとConfigで使用中の設定ファイルを記録しておきます。以後の再テストでは、できるだけこの2項目を変更しないでください。ルールの優先順位、ポリシー、設定項目の詳しい説明は公式マニュアルをご覧ください。ここでは、テストの目的と選択したモードが一致していることを確認します。
手順3:接続スイッチをオンにしてVPN構成を許可
Homeに戻り、既定のサーバーとGlobal Routingをもう一度確認します。問題がなければ、画面上部の接続スイッチをオンにしてください。初回接続時に、ShadowrocketによるVPN構成の追加を許可するようシステムから求められる場合があります。これはアプリがシステムのネットワーク処理を利用するための許可であり、サブスクリプションの検証成功を知らせるものではありません。
システムのダイアログで、要求元がShadowrocketであることを確認して許可し、デバイスの案内に従って本人確認を完了します。許可の途中でアプリを何度も切り替えたり、接続スイッチを連続してタップしたりしないでください。完了後にHomeへ戻り、接続状態が更新されるまで待ちます。許可を取り消していた場合は、もう一度接続を開始し、システムの案内に従って操作してください。
iPhoneとiPadでは、システムのダイアログの表示形式、認証方法、状態の表示位置が異なる場合があります。実際のデバイスの表示に従ってください。システム内の構成を確認する場合は、SettingsでVPN関連の項目を探し、Shadowrocketの構成が存在するか確認します。接続に一度失敗したからといって、用途がわからないデバイス管理構成を削除しないでください。
ほかに有効なVPN接続がないかも確認してください。複数の構成が現在の接続を取り合うと、接続直後に切断される、スイッチが自動で戻る、状態表示が想定と異なるといったことがあります。現在どの構成が有効かを確認してからテストしてください。管理対象デバイスでVPN構成の追加が制限されている場合は、デバイス管理のルールに従ってください。サーバー設定の変更でシステムの制限を回避することはできません。
この手順の完了条件はシステム接続の確立であり、すべての接続先が利用できることではありません。接続状態が正常でも、確認できるのはデバイス上のネットワーク処理が開始したことまでです。次の手順で、サーバーへの接続と実際のWebアクセスを確認します。スイッチがオンの状態を保てない場合は、許可とシステム状態の確認を優先してください。DNSやルールの変更はまだ行わないでください。
手順4:Connectivity Testと実際のアクセスを確認
接続が確立したら、HomeでConnectivity Testを見つけて一度実行し、結果が表示されるまで待ちます。このテストでは現在の条件での接続状況を確認します。成功、タイムアウト、その他のエラーのいずれかを記録してください。遅延の数値だけを記録するのではなく、一覧での遅延テストと接続後の実際のアクセスを分けて考えます。サーバーが応答しても、認証、転送、接続先へのアクセスがすべて正常とは限りません。
接続を確認してから実際の接続先を開く
テスト後、ブラウザーで利用したい通常のWebページを開きます。まず、URLが明確で、通常の状態を確認できる接続先を1つ選び、一度に多くのページを開かないでください。すでに開いていたページは再読み込みし、内容が実際に更新されたことを確認します。キャッシュされた内容が表示されても、現在の経路が使える証明にはなりません。結果をアプリの記録と照合しやすくするため、接続先は一度に1つずつテストします。
Connectivity Testに成功しても特定のWebページを開けない場合は、テスト先とWebページでアクセス条件が異なるか、DNS、ルールの適用、接続先サービス自体に問題がある可能性があります。逆に、テスト先に一時的に接続できなくても、すべてのサーバーが失敗したとは限りません。テスト結果と実際のアクセスを併せて判断し、1回の結果だけで結論を出さないでください。
Configを使用している場合は振り分けも確認
Configを使用している場合は、少なくとも、Directになる想定の接続先とプロキシを使用する想定の接続先をそれぞれ確認してください。アプリの接続記録で該当するリクエストと適用ポリシーを確認し、現在の設定ファイルのルール順と照合します。Webサイトが開けても、そのアクセスが想定した経路を通ったとは限りません。適用ルールの記録も確認してください。
Dataは接続中の通信量の変化を確認する参考になりますが、数値が増えてもルールが正しいとは限らず、すべてのアプリのアクセス経路を確認できるわけでもありません。初回確認で重要なのは、選択したサーバーとGlobal Routingが明確であること、Connectivity Testに結果が出ること、実際の接続先にアクセスできることです。Configを使用する場合は、適用されたポリシーも説明できる必要があります。
4項目が想定どおりなら、現在の設定のまま通常の利用を始められます。テストの数値を下げるためにサーバーを何度も切り替えたり、すぐにDNSを変更したりする必要はありません。現在正常に動作した設定の組み合わせを記録しておくと、後日問題が起きた際にネットワーク、モード、サーバーを比較できます。
手順5:失敗した段階に応じて確認
まず、「内容がインポートされない」「システム接続が確立しない」「接続後にアクセスできない」のどれに該当するかを切り分けます。段階ごとに確認すべき項目は異なります。一度に変更するのは1項目だけにし、変更後は同じ接続先で再テストしてください。サーバー、DNS、設定ファイルを同時に変えると、復旧しても原因を特定しにくくなり、同じ問題が再発するおそれがあります。
サブスクリプションに内容がない:入力と取得状況を確認
Subscribeの記録に戻り、URLが完全か、サービス提供元のWebページを誤って貼り付けていないか、現在のネットワークからサブスクリプションを取得できるかを確認します。元のサービス提供元によってリンクがリセット、無効化、変更されていないかも確認してください。更新に失敗した場合は、既存の利用可能な記録を残し、まずエラー表示を確認してから再インポートを検討します。同じサブスクリプションを何度も作成しても、元のリンクのアクセス権限の問題は解決しません。
新しいサブスクリプションのサーバー一覧が想定と異なる場合は、まずサブスクリプションの入手元とサービスの有効状態を確認してください。完全なURLを公開の場で共有しないでください。「更新後に一覧が空になった」「認証エラーが表示された」などの状況を伝え、アカウントとサブスクリプションの状態をサービス提供元に確認してもらいましょう。
スイッチをオンにできない:システムの許可を確認
スイッチをオンにしてもすぐ戻る場合は、VPN構成の追加を求めるシステムのダイアログをキャンセルしていないか、デバイスがその構成での接続を許可しているかを確認してください。Homeに戻って接続を開始し、システムの案内が隠れていないか、未確認のままになっていないかを確認します。この段階ではまだシステム接続が確立していないため、サブスクリプションのサーバーを何度も切り替えても、最初の対処にはなりません。
状態表示に問題がある場合は、現在有効なVPN構成とデバイス管理の制限も確認してください。通常のネットワークが使えても、基本的なネットワーク問題の一部を除外できるだけで、Shadowrocketに必要なシステムの許可を確認したことにはなりません。
接続済みなのにテストに失敗する:サーバーとネットワークを確認
まずHomeで選択されているサーバーが、入力したもの、またはテストする予定のものと一致しているか確認します。次に、アドレス、ポート、パスワードまたはUUID、TLS、転送パラメーターを確認してください。名前が似ているサーバーは選び間違えやすいため注意が必要です。既存のサブスクリプションに利用可能と確認済みの別の項目がある場合は、ほかの設定を変えずにその項目へ切り替えて比較できます。すべてを再インポートする必要はありません。
次に、デバイス本来のネットワークが使えることを確認し、必要に応じて利用が許可されている別のネットワークでも再テストしてください。ネットワークを切り替えても、同じサーバーと接続先を使うことで比較できます。テスト失敗はサーバー側の状態に関係する場合もあります。クライアントの接続スイッチがオンでも、サービス提供元で認証やサービスが有効とは限りません。
一部の接続先だけ失敗する:ルールとDNSを確認
Proxyでは正常でConfigでは問題がある場合は、Configに戻り、現在の設定ファイルと接続先に適用されたポリシーを確認します。より上位のDIRECTまたはREJECTルールに一致していないかを確認し、最後のルールだけを調べないでください。ルールを変更する前に元の設定を保存し、1か所だけ変更して再テストし、該当する接続先の処理が実際に変わったことを確認します。
ドメイン解決に関するエラーが表示された場合は、すべての失敗をDNSのせいにせず、現在のDNS設定を確認してください。変更前に元の値を記録し、内容を理解したうえで明確な根拠がある設定を使用します。Webページを開けないという理由だけで複数のDNSサーバーを次々に変更すると、確認すべき要因が増えます。DNS、IP-CIDR、FINALなどの用語は、まず用語クイックガイドで確認し、必要に応じて公式マニュアルで詳しく確認してください。
解決しない場合:必要最小限の記録をまとめる
サービス提供元へ問い合わせる前に、使用プロトコル、Global Routingのモード、失敗した手順、Connectivity Testの結果、ネットワークを切り替えても同じかどうかをまとめます。個人情報を伏せたエラーメッセージは共有できますが、完全なサブスクリプションリンク、パスワード、UUID、QRコード、認証パラメーターは含めないでください。「接続できない」とだけ伝えるより、具体的なエラーを説明すると原因を特定しやすくなります。
初回設定後の日常操作はシンプルです。必要に応じて既存のサブスクリプションを更新し、既定のサーバーと現在の設定を確認してから接続し、実際のアクセスを確認します。App Storeはアプリの入手と更新、Subscribeは既存のサーバー一覧の更新、Configは設定ファイルの管理に使用します。それぞれ役割が異なるため、サーバー接続の問題が一度起きただけでアプリを再購入する必要はありません。