Shadowrocket の使い方
Subscribe の追加と接続確認
iPhone / iPad の画面を例に、情報の追加、モード選択、接続、リクエストの確認、問題点のチェックの順に進めます。まず接続を検証し、その後にルールを調整します。
既存の設定は残し、一度にまとめて変更しないでください。確認用に普段使うページのアドレスを準備します。問題が起きた場合は、どの手順で何が表示されたかを記録すると、再インストールを繰り返すより原因を特定しやすくなります。バージョンによって画面の配置が多少異なる場合があります。英語の画面表示を目印に該当する項目を探してください。
Add Server：サーバーの追加または Subscribe の読み込み
まず手元の情報の種類を確認します。Subscribe リンク、個別サーバーのパラメーター、設定ファイルは、それぞれ入力方法が異なります。
Shadowrocket を開き、Home の下にある SERVER グループを見つけて、Add Server をタップします。追加画面では、まず Type を確認してください。Type によって入力が必要な項目が決まります。右側の公式画面は特定のサーバータイプを示しています。Type を切り替えると項目が変わるのは正常です。画面に表示された項目の組み合わせを、すべてのプロトコルに共通する入力方法と考えないでください。
Subscribe リンクがある場合：Subscribe を選択
Subscribe アドレスを受け取っている場合は、Type で Subscribe を選択し、完全なアドレスを URL 欄に貼り付けて、見分けやすい名前を入力します。貼り付けた後、先頭から末尾まで確認してください。先頭のプロトコル、パス、疑問符以降のパラメーターをすべて残し、改行、引用符、説明文を一緒に入力しないようにします。https://example.com/sub?token=xxxx は構造を説明するための例で、実際の Subscribe ではなく、アクセスする必要もありません。
保存後に Home に戻り、Subscribe の取得が完了してからグループにサーバー項目が表示されているか確認します。保存できても、アドレスがアプリに記録されたことを示すだけで、リモートの内容を取得できたとは限りません。グループが空の場合は、取得時の表示を確認し、アドレスの有効期限、追加認証の要否、現在のネットワークからのアクセス可否を調べてください。通常のウェブページのアドレスを Subscribe の代わりに使わないでください。ページの内容はサーバー一覧とは異なります。
個別のサーバー情報がある場合：Type に合わせて入力
個別のサーバー情報がある場合は、Shadowsocks や Trojan など、資料と一致するプロトコルを選んでから Host と Port を入力します。Host には通常、ホスト名または IP アドレスだけを入力し、ウェブページのパスは付けません。Port には資料に記載されたポートを入力します。次に、そのタイプで必要となる Password、Method、UUID、TLS 関連の項目を確認してください。特定のプロトコルにのみ使われる項目もあるため、名前が似ているだけで別の項目を代用しないでください。
手入力ではパスワードに空白や改行が混ざることがあります。コピーした後、先頭と末尾を確認してください。資料に QR コードが含まれている場合は、Scan QR Code から読み込み、システムの案内に従ってカメラの使用を許可してから、解析された Type、Host、Port を確認して保存します。Import from Cloud JSON は、手元の情報がその形式に対応している場合に限って使用してください。任意の Subscribe やテキストを入力しないでください。
追加後、SERVER グループに戻って使用するサーバーをタップし、選択マークが対象の項目に付いていることを確認します。この段階では情報を準備しただけで、システム接続やルールの適用はまだ確認できていません。Subscribe に複数の項目がある場合は、まず1つ選んで後の確認に進みます。サーバーの選択は変えず、次の手順でリクエストに使う Global Routing モードを決めてください。
Global Routing：Config / Proxy / Direct
サーバーが接続パラメーターを決め、Global Routing がリクエストの処理方法を決めます。
Home に戻り、Global Routing をタップして現在のモードを確認します。初回に混同しやすいのは、「サーバーを選択した」ことを「すべてのリクエストがそのサーバーを使う」と捉えることです。実際には、Global Routing の選択と現在の設定にあるルールの両方でリクエストの経路が決まります。サーバー自体を検証するのか、既存の振り分け設定を検証するのかを明確にしてから選択してください。
Config：現在の設定にある Rule に従って処理
Config を選択すると、リクエストは現在の設定にあるルールと順に照合され、一致したルールが指定するポリシーで処理されます。Config を開き、実際に有効になっている設定ファイルを確認してから、編集画面で Rule を開きます。画面にある General、Rule、Hosts、URL Rewrite、HTTPS Decryption はそれぞれ異なる設定項目です。初回接続では、関連するルールとポリシーがあることを確認するだけで十分です。各項目をすべて有効化したり変更したりする必要はありません。
たとえば DOMAIN-SUFFIX,example.com,PROXY は、指定されたドメインのサフィックスに一致するリクエストを PROXY というポリシーで処理することを示します。このポリシー名が現在の設定で有効な接続先として解決される必要があります。ルールの記述があるだけで、ポリシー参照が正しいとは限りません。ルールは通常、記載順に確認されるため、より具体的な条件を適切な位置に置き、末尾のフォールバック FINAL も確認してください。Add Rule で変更する前に、元の設定のコピーを残しておくことをおすすめします。
Proxy：一時的に確認範囲を絞る
選択したサーバーでリクエストを処理できるか先に確認する場合は、一時的に Proxy を選択すると、振り分けルールによる影響を抑えて判断できます。ここでの Proxy は Global Routing のモードであり、ルール内の PROXY はポリシー名です。混同しないでください。Proxy を選択していても、システムルーティング、アプリの動作、既存の設定の影響を受けます。端末上のすべての通信が必ず同じ経路を通ると判断することはできません。
Direct：プロキシサーバーを介さずに接続
Direct は接続先へ直接接続するモードです。SERVER でサーバーを選択していても、自動的にそのサーバーを使うことはありません。プロキシサーバーをテストする場合は、誤って Direct を選択していないか確認してください。端末の基本ネットワークと比較する場合は、Direct を対照として使えます。基本ネットワークから接続できない接続先について、Direct に切り替えただけでサーバーの故障と結論づけることはできません。
この手順では、選択したモードを記録してください。信頼でき、用途を把握している設定がある場合は Config から始められます。設定の内容がまだ分からない場合は、まず Proxy でサーバーを確認してから Config に戻り、振り分けを調べます。ルールの順序、プロトコルの項目、選び方の詳しい説明は技術リファレンスをご覧ください。初回接続では変更範囲を広げず、未知の要因を同時に増やさないようにします。
Home：接続スイッチをオンにしてシステム構成を許可
選択内容を確認してから接続します。システムの許可と、リモートサーバーが使用できることは別の確認事項です。
最初の2つの手順が終わったら Home に戻り、SERVER の対象サーバー、Global Routing のモード、Config で使用中の設定を順に確認します。確認中に Subscribe の更新や複数のサーバー切り替えを同時に行わないでください。後で接続できるようになっても、どの変更が影響したのか分からなくなります。端末で別の VPN 接続が有効になっている場合は、Shadowrocket をテストする前に切断してください。
Home 上部の接続スイッチをタップします。システム構成を初めて作成するとき、iPhone / iPad に VPN 構成を追加する許可画面が表示される場合があります。内容を読み、今行った操作に対する表示であることを確認してから許可し、システムの要求に従って端末認証を完了してください。必要なのは端末のネットワーク構成に対するシステムの許可です。Subscribe のパスワードではなく、端末認証情報を Add Server に入力する必要もありません。
許可後に Shadowrocket に戻り、上部の Not Connected 表示が変わったか、スイッチがオンの状態を保つか確認します。公式画面は未接続の Home を示しているため、画面の状態を完了の基準にしないでください。状態が変わったことから分かるのは、端末上の接続手順が進んだということだけです。次の手順で実際のリクエストを使い、リモート接続とルールの処理結果を確認してください。
オンにした直後に自動でオフになる場合は、許可画面、システム構成のエラー、アプリ内のエラー記録が表示されていないか確認します。以前に許可を拒否した場合は、接続を再度開始してシステムの案内を確認してください。端末が組織によって管理されている場合、関連する権限が管理ポリシーで制限されている可能性があります。端末管理者に確認し、知らない管理設定をむやみに削除しないでください。スイッチを繰り返しタップしても、不足しているパラメーターは修正されず、表示や記録との照合が難しくなります。
テスト中は On Demand を有効にせず、スイッチの操作を手動で行うのがおすすめです。有効にすると条件に応じてシステムが再接続し、スイッチの動作不良と誤認する場合があります。まずアプリを前面に表示した状態で基本的な確認を行い、その後ブラウザーへの切り替え、画面ロック、ネットワーク変更後の状態を確認してください。初回のテストですべての状況をまとめて判断しないでください。
ここまでで、情報の保存、モードの選択、システム接続の開始が完了しました。次はサーバーとモードをそのままにして、Connectivity Test とページのリクエストを確認します。これらの結果が一致することを確かめてから、日常の振り分けやオンデマンド接続を調整してください。
Connectivity Test：テスト結果と実際のリクエストを確認
Home で Connectivity Test を使ってサーバーを確認します。テスト結果は、選択したテスト方法、テスト先、現在のネットワークによって変わります。すべてのウェブサイトやアプリが利用できることを保証するものではなく、トラブル対処の手掛かりとして扱ってください。テストに失敗しても、対象サーバーとエラーの状況を記録し、すぐに項目を削除する必要はありません。テストに成功した場合も、実際のリクエストを続けて確認します。
先にリクエストを送り、その後に記録を確認
ブラウザーを開き、普段使っていて正常にサービスが提供されているページにアクセスし、新しいリクエストが完了するまで待ちます。キャッシュ済みのページだけを確認したり、アプリに表示された古い内容だけで接続の成功を判断したりしないでください。ページが変わらない場合は更新するか、開き直してから Shadowrocket に戻り、Data または現在のバージョンで利用できる接続記録を確認します。
記録では、今回のリクエストの宛先、処理ポリシー、時刻が直前の操作と一致しているかを確認します。Config モードでは、適用された Rule と、最終的な処理が DIRECT、PROXY、またはほかの定義済みポリシーのどれかを特に確認してください。DIRECT は有効な振り分け結果であり、接続が失敗したことを必ずしも意味しません。一方、プロキシのポリシー名が記録されていても、リモートから正常な応答が返ったとは限りません。エラー記録と実際の応答も合わせて確認してください。
モードを比較して問題の箇所を切り分け
Proxy では実際のリクエストが成功し、Config では同じ新しいリクエストが失敗する場合は、現在の設定にある一致ルール、ポリシー参照、DNS 関連の設定を先に確認してください。検証済みのサーバーパスワードを優先して再入力する必要はありません。どちらのモードでも失敗する場合は、サーバーのパラメーターと基本ネットワークを確認します。比較では Global Routing だけを変更し、サーバー、ページ、ネットワークは同じにして、確認後は必要なモードに戻してください。
複数のドメインを使うリクエストもあります。ページ本体は表示されても画像、ログイン、動画に失敗する場合は、アドレスバーのドメインだけでなく、失敗したリソースに対応する接続を確認してください。アプリのキャッシュ、既存の長時間接続、システムのネットワーク設定も結果に影響します。ルールを変更した後は、新しいリクエストを送ってから確認してください。記録が予想と異なる場合は、宛先と適用ポリシーを整理してからよくある質問のルール・トラブル対処をご覧ください。
Settings：やり直す前に失敗した段階を確認
最後に正常だった手順を見つけ、その直後の入力、権限、リクエストを確認します。
読み込みに失敗する場合：入力と形式を確認
Subscribe の内容を取得できない場合は、完全な URL、有効期限、認証条件を確認してください。取得できても項目が表示されない場合は、返された内容が対応する Subscribe 形式かどうかを確認します。手動追加に失敗した場合は Add Server に戻り、元の情報と Type、必須項目を照合してください。QR コードを読み込めても、それは内容を解析できたことを示すだけです。保存前にパラメーターを確認してください。Subscribe 全体を公開して質問しないでください。リンクのパラメーターがアクセス権を持つ場合があります。
サーバーテストに失敗する場合：パラメーターとネットワークを確認
Settings を開いて Test Method を確認し、現在のテスト対象と方法を把握します。1回のテストがタイムアウトしただけでは、実際のすべてのリクエスト状況は分かりません。前の節で説明したページ確認と組み合わせてください。続いて Host、Port、認証情報、端末時刻を確認します。TLS を使う場合は、資料で指定されたサーバー名と証明書の条件も確認してください。証明書チェックを無効にして、名前や時刻の誤りを隠さないでください。
元の設定を残したまま、Wi-Fi とモバイル通信で同じリクエストを行い、問題がどちらか一方の基本ネットワークだけで起きるか確認できます。切り替え後はネットワークが安定するまで待ってからテストし、切り替え直後のタイムアウトを継続的なサーバー障害と誤認しないようにしてください。複数の項目で問題が起きる場合は、既知の直接接続先に端末自体から正常にアクセスできるかを先に確認します。
スイッチの異常や一部のリクエストの失敗：Diagnostics を確認
接続スイッチがオンの状態を保てない場合は、システム権限と VPN 構成を確認してください。スイッチが正常でも一部のリクエストが失敗する場合は、Settings の Diagnostics を開き、現在のバージョンで表示できる記録から具体的なエラーを確認します。画面にある Proxy、TCP、UDP は異なる設定項目であり、すべてを変更する必要はありません。先にエラーを読み、該当する項目を確認する必要があるか判断してください。
問題を整理する際は、使用中の Global Routing、失敗した手順、特定の接続先だけに影響するか、基本ネットワークの切り替えで変化するかを記録します。記録を共有する前に、Subscribe アドレス、パスワード、キー、個人のネットワーク情報を隠してください。プロトコルのパラメーターについては技術リファレンス、読み込み、権限、ルールの順序に関する問題はよくある質問をご覧ください。このページの手順を最初からすべて繰り返す必要はありません。
基本確認の後に On Demand を設定
手動接続が安定してから On Demand を開き、必要な接続条件を設定してください。これは条件を満たしたときに接続を開始するかどうかを管理する機能で、Global Routing の振り分けルールを置き換えるものではなく、使えなくなったサーバーのパラメーターを補うものでもありません。有効にした後は、対象ネットワークへの接続、ネットワークからの切断、手動でオフにしたときの動作をそれぞれ確認します。予想と異なる場合は、On Demand を無効にして手動テストに戻り、条件を個別に調整してください。
最後に、日常の利用に必要なモードに戻し、検証済みの設定を1つ保存しておきます。今後 Subscribe の更新やルールの変更を行う場合は、変更する項目を1つに絞り、同じページで再確認してください。変化があったときに、すべてのパラメーターを推測し直さず、直近の正常な状態に戻せます。
