OFFICIAL MANUAL / FIRST CONNECTION

Shadowrocketの使い方

既存設定の読み込み → Global Routing → 接続許可 → 実アクセスの確認。初回設定を順に済ませてから、具体的な問題を切り分けます。

このページではiPhoneとiPadを対象に、初回操作を順に確認できます。画面の項目や配置はアプリの表示言語によって異なる場合があるため、以下では見分けやすいよう英語表記を残しています。システム要件はApp Storeの記載をご確認ください。

1. サーバーを追加またはサブスクリプションを読み込む

まず手元の情報を確認し、種類に合った方法を選びます。サブスクリプションURLは通常、複数のサーバー情報の取得や更新に使います。個別のサーバー共有リンクには1つの接続情報が記載され、アドレス・ポート・パスワードなどが別々に渡されている場合は手動入力が必要です。見た目が似たURLでも用途は異なります。アカウント管理ページや説明ページは、サブスクリプションURLの代わりにはなりません。

既存のサブスクリプション：Subscribeを使用

Shadowrocketを開き、ConfigページでSubscribeを選び、サブスクリプションの操作画面に手持ちのURLを入力して、画面の指示に従って読み込みます。URLは完全な状態でコピーし、特に「?」以降のクエリパラメーターが欠けていないか確認してください。先頭や末尾に空白・改行・日本語の句読点が混入していないかも確認します。URLに含まれる認証情報は機密情報です。公開コメントに投稿したり、問題を見せるためにリンク全体を公開したりしないでください。

送信後はエラーが表示されていないか確認し、Homeに戻ってSERVER欄を見ます。選択できるサーバーが一覧に表示されたことを、読み込み完了の目安にしてください。入力画面が閉じただけで成功と判断しないでください。既存のサブスクリプションが更新に対応している場合、更新時にはサーバーから内容が再取得されます。サーバー名、件数、パラメーターは内容に応じて変わる場合があり、手動で変更した項目も更新後に確認してください。

サブスクリプションURLと設定ファイルのURLは別の情報です。前者は主にサーバー情報の管理に使われ、後者にはルールやドメインのマッピングなどが含まれる場合があります。読み込み後に設定項目だけが表示され、サーバーが見当たらない場合は、情報の用途を確認してください。同じURLを別の画面に何度も貼り付けないようにしましょう。

既存のサーバー情報を入力：Add Serverを使用

Homeに戻り、追加用のプラスボタンをタップしてAdd Serverを開きます。手元の情報に合うプロトコルを選び、サーバーアドレス、ポート、認証情報を入力してください。プロトコルを選ぶと入力欄も変わります。どちらにもパスワードやUUIDが含まれるからといって、異なるプロトコルを同じ設定として扱わないでください。

たとえばShadowsocksでは暗号方式とパスワードを確認します。VMessとVLESSでは、UUIDや関連項目を手元の情報に照らして入力します。Trojanではパスワードに加え、TLS関連の設定も確認してください。転送方式、TLS、サーバー名、パスなどの追加パラメーターも1つずつ照合します。情報にない項目を推測で入力しないでください。また、証明書の検証を無効にする方法を一般的な解決策として使わないでください。確認して保存したら、SERVERに戻って該当項目を選択します。

既存の共有リンクまたはQRコード

サーバー共有リンクの場合は、アプリのクリップボードから読み込む機能を使用できます。QRコードの場合はScan QR Codeを使い、システムの案内に従ってカメラの使用を許可してください。読み取り後もプロトコル、アドレス、ポートを確認します。読み込みに成功したのはアプリが情報を認識したということであり、接続先サービスの検証が済んだという意味ではありません。QRコードにもパスワードや認証情報が含まれることがあるため、元のリンクと同様に慎重に扱ってください。

この段階で、Homeにサーバー項目が表示され、使用する項目が選択されていることを確認します。その後、通信の処理方法を設定してください。入口や形式の違いはサブスクリプションの読み込み方法、各項目の意味は用語集をご覧ください。

2. Global Routingを選択

HomeでGlobal Routingをタップします。ここでは通信の処理方法を決めます。「使用するサーバーの選択」とは別の操作です。一覧でサーバーを選択しても、すべての接続がそのサーバー経由になるとは限りません。反対に、プロキシモードを選択しても、サーバー情報の誤りが自動で解消されるわけではありません。

Config：現在のルールに従って処理

Configは、既存のルール設定を日常的に使う場合に適しています。アプリは現在の設定にあるルールに基づいて接続先を判断し、PROXY、DIRECT、REJECTなどのポリシーを適用します。そのため、同じ接続セッションでもドメインによって処理結果が異なる場合があります。選択する前にConfigを開き、一覧にファイルがあるかだけでなく、どの設定が現在有効かを確認してください。

このページでは、初回操作でルールを作成する必要はありません。現在の設定の入手元や内容が不明な場合は、まずサーバーに接続できるか確認してから、その設定を使うか判断してください。ルールの照合順序、フォールバックポリシー、構文についてはルールと設定のリファレンスをご覧ください。初回接続時にまとめて変更する必要はありません。

Proxy：まずルールの影響を切り分ける

Proxyは初回の確認や問題の切り分けに利用できます。通常アプリが処理する接続をプロキシ経由にすることで、「サーバー自体に接続できない」のか「ルールによって接続先が変わっている」のかを切り分けやすくなります。サーバー品質テストの代わりにはならず、すべての接続先へのアクセスを保証するものでもありません。システム側の通信例外やアプリ自身の通信動作が、実際の結果に影響する場合もあります。

Direct：宛先に直接接続

Directは、選択したプロキシサーバーを経由せず、宛先に直接接続します。サーバーが機能しているか確認中にこのモードのままでは、Webページが開いてもプロキシ経由の接続が使える証拠にはなりません。また、このモードに切り替えてもHomeの接続スイッチはオフになりません。ルーティングの選択とシステムの接続状態は分けて考えてください。

初回設定ではProxyを選び、同じサーバーを使って次の手順で接続を確認します。使用できることを確認したらConfigに切り替え、通常のルールが意図どおり動作するか確認してください。切り替えるたびに新しくアクセスし、ブラウザーの既存接続による影響を避けましょう。

3. スイッチをオンにして許可する

Homeに戻り、SERVERで選択中の項目とGlobal Routingの現在のモードを再確認してから、接続スイッチをオンにします。未接続の場合はNot Connectedなどの状態が表示されます。操作後に状態が変わるか、すぐに切断状態へ戻らないかを確認してください。システムの確認画面に対応している間は、スイッチを連続して切り替えないでください。

初回使用時に、ShadowrocketがVPN構成の追加を求めるシステム画面が表示されることがあります。この画面はアプリがシステムのネットワーク構成を作成できるようにするためのもので、アプリの再購入やサーバー情報の入力を求めるものではありません。直前に起動したShadowrocketからの要求であることを確認し、システムの指示に従って許可して、デバイスのパスコードまたは認証で承認してください。認証はデバイスのシステム画面で行ってください。デバイスのパスコードをサーバーの入力欄やWebページに入力しないでください。

以前に確認画面をキャンセルした場合は、アプリに戻って接続を再試行し、実際に表示される案内に従ってください。システム設定でVPNを検索し、Shadowrocketの構成状態を確認する方法もあります。操作前に、デバイスが組織によって管理されているか、関連する制限があるかを確認してください。明確な管理上の制限がある場合は、デバイスの管理要件に従って対応し、見覚えのないシステム構成をむやみに削除しないでください。

許可後はHomeに戻り、接続状態を確認します。システムでVPN接続が確立されていても、ローカルの通信処理が開始されたことを示すだけで、接続先サーバー、DNS、アクセス先のすべてが正常とは限りません。次に実際のアクセスを確認してください。スイッチをオンにした直後にオフへ戻る場合は、すぐに再インストールするのではなく、システムの案内とアプリのエラー内容を記録してください。

初回の確認中はOn Demandの設定を変更せず、自動接続の条件と手動操作を混同しないようにしてください。スイッチをオフにしても再接続する場合は、On Demandが有効か、どの条件で接続する設定かを確認します。手動接続が安定した後で、必要に応じて自動接続の動作を設定してください。

4. 接続が実際に機能しているか確認

確認する項目は3段階です。サーバーのテストが成功するか、システム接続が維持されるか、アクセス先へのリクエストが期待どおり完了するかをそれぞれ確認します。関連はありますが、どれか1つの結果でほかを判断することはできません。各段階の結果を分けて記録すると、「つながらない」とだけ記すより原因を絞り込みやすくなります。

まずConnectivity Testを確認

HomeでConnectivity Testを実行し、現在のサーバーのテスト結果を確認します。テスト方法やテスト先によって結果は異なるため、1回成功してもすべてのWebサイトが正常とは限りません。また、1回タイムアウトしただけで、すべての接続が使えないとも判断できません。既存サーバーが複数ある場合は、結果がどの項目に対するものか、実際にどの項目を選択しているかを確認してください。

テストの数値だけで結論を出さないでください。テスト時の経路や接続先と、実際の通信リクエストは異なる場合があります。失敗が続く場合に、設定値、現在のネットワーク、接続先の状態を確認してください。1回のテスト結果を改善するために、DNS、TLS、プロトコル、ルーティングモードを同時に変更するのも避けましょう。変更後の比較が難しくなります。

次に新しいリクエストを送信

接続をオンにしたままブラウザーに切り替え、普段使っている、正常に応答することが分かっているHTTPSページを開き直します。古いタブを更新するとキャッシュが表示される場合があるため、新たにリクエストを送信し、ページの内容が実際に読み込まれるか確認してください。いくつかの接続先を使って確認すれば十分です。1つのサイトだけの失敗で接続全体を判断しないでください。

ブラウザーではアクセスできるのに特定のアプリで問題が起きる場合は、そのアプリに以前の接続が残っているか、ログイン、権限、サービスの状態に問題がないか確認します。該当アプリを再度開いてから、テスト結果と比較してください。アカウントのエラー、接続先のメンテナンス、Webページ自体のエラーを確認せずにShadowrocketの問題と判断しないでください。

最後にルールの処理結果を確認

Proxyでの確認後にConfigへ切り替え、同じ接続先へアクセスし直します。さらに調べる場合はDataで確認できる接続情報を見て、接続先のドメイン、適用ルール、ポリシーから通信先を判断します。通信量が増えただけでは、選択したサーバーを経由した証拠にはなりません。記録だけで判断できない場合は「未確認」とし、推測を検証結果として扱わないでください。

Proxyでは正常でConfigでは問題が起きる場合、確認すべき対象はサーバー情報ではなく、現在の設定、ルール、DNSです。動作しているサーバー設定はそのままにして、ルールのリファレンスで該当する照合内容を確認してください。すべての手順を最初からやり直す必要はありません。

5. 失敗した段階ごとに確認

まず、どの段階で止まっているかを確認します。読み込みができない、サーバーはあるがテストに失敗する、システムの許可に失敗する、接続は維持されるが目的のページが開かない、のいずれかを特定してください。一度に変更するのは1項目だけにし、テスト後に結果を記録します。改善しなければ元の値に戻してから次の項目を確認してください。これにより、確認済みの設定を維持しながら、該当するトラブル対処を参照できます。

読み込み後にサーバーが表示されない

入力した情報がサブスクリプションURL、個別の共有リンク、設定ファイルのURLのどれかを確認し、情報の種類に合った画面を使っているか確認します。リンクがメッセージアプリで途切れていないか、クエリパラメーターがすべて含まれているか、認証情報が有効かも確認してください。更新時にログインページやエラー説明が返された場合、URLを開けても、アプリが認識できるサブスクリプション内容が返されたとは限りません。

現在のネットワークでサブスクリプションの内容を取得できるか、元の管理ページでサブスクリプションの状態を更新する必要がないかも確認してください。同じURLを何度も追加するのではなく、まず返されたエラーを確認します。外部に問題を説明するときはエラーの種類だけを伝え、サブスクリプションURL全体と認証情報を隠してください。

サーバーはあるがテストに失敗し続ける

まずアドレス、ポート、プロトコルの種類を確認し、次にパスワード、UUID、暗号方式などの認証情報を確認します。最後にTLS、サーバー名、転送に関するパラメーターを確認してください。ポート番号の入力ミス、パスワードへの空白混入、パスの入力漏れにも注意します。サーバー名だけでなく、すべての項目を手元のサーバー情報と照合してください。

自分が利用できる別のネットワーク環境でも同じテストを行い、現在のWi-Fiまたはモバイル通信が関係しているか確認できます。ネットワークを切り替える前に、デバイスのデータ通信設定を確認してください。同じ項目が異なるネットワークでも失敗する場合は、テスト結果を記録し、元のサービス提供元にサーバーの状態と設定情報を確認します。認証エラーを解消するためにモードを何度も切り替えないでください。

接続はオンだがページが開かない

まずDirectのままになっていないことを確認し、ProxyとConfigで同じ接続先へのアクセスを比較します。Configだけで失敗する場合は、現在有効な設定に意図しないREJECT、適切でないDIRECT、または誤ったフォールバックポリシーがないか確認してください。両方のモードで失敗する場合は、サーバー、DNS、接続先の状態を引き続き確認します。ルールだけを変更し続けないでください。

証明書エラーが発生した場合は、デバイスの時刻、サーバー名、TLSパラメーターを確認します。証明書の検証を省略する設定を既定の対処にしないでください。一部のドメインだけで失敗する場合は、該当ドメインと発生時刻を記録し、関連する接続情報を確認します。設定全体を消去する必要はありません。DNSの変更でドメインの名前解決結果が変わることがありますが、エラーの根拠を確認してから調整し、やみくもに設定を追加しないでください。

次回の確認に役立つ情報を記録

次の4項目を記録しておくと、後から確認しやすくなります。失敗した段階、その時のGlobal Routingモード、アプリに表示されたエラーの原文、ネットワークまたはモードを切り替えた後の変化です。記録にパスワード、UUID、サブスクリプションURL全体、認証情報を含むQRコードを含めないでください。相談する前に、スイッチの色だけではなく「どこまで成功し、どこで失敗したか」を説明できるようにしておきましょう。

初回接続後の日常的な操作では、既存サブスクリプションの管理、現在のサーバーと設定の確認、異常な変化の把握が中心になります。接続や読み込みの詳しいケースはよくある質問をご覧ください。On DemandやFINALなどの用語は用語集で確認できます。設定の詳細はルールのリファレンスで扱います。このページの完了条件は、既存サーバーに接続でき、実際のリクエストで動作を確認でき、問題発生時にどの段階から調べればよいか分かることです。