Shadowrocket サブスクリプション・サーバー管理

第1章 · インポートする対象

Subscribe：登録済みサブスクリプションを追加

サブスクリプションはサーバー一覧を取得するためのアドレスであり、個々のサーバーそのものではありません。Shadowrocketがそのアドレスにアクセスして応答内容を解析し、認識できたサーバー項目を一覧に追加します。サブスクリプションアドレスは「どこから更新するか」を示し、各項目は「どのように接続するか」を示します。この違いを理解すれば、サーバーを個別に再入力してもサブスクリプションの更新エラーが直らない理由や、ログインページをサブスクリプションアドレスと取り違えてはいけない理由が分かります。

まずサブスクリプションアドレスか確認する

インポート前に、手元の情報が何に使うものか説明を確認してください。サブスクリプションアドレスは通常、長いパスやクエリパラメータを含む完全なURLです。一方、管理ページはログイン後に内容を確認する形式の場合があります。見た目が似ていても、返されるデータは異なります。URLに特定の英単語が含まれているだけで用途を判断したり、ランダムに見えるパラメータを削除したりしないでください。アクセス権の識別に使われている場合があり、1文字欠けるだけで異なる内容が返ることがあります。

コピーする際はURLの先頭から末尾まで選択し、チャットアプリや文書で長いURLが複数行に折り返されていないか確認してください。画面上の改行は元のテキストに含まれない場合がありますが、手作業でつなぐと空白が入ることがあります。元の情報にコピー機能があれば優先して使い、入力欄でスキーム、ドメイン、末尾のパラメータを確認してください。サブスクリプションアドレスを検索欄に貼り付けたり、公開の問い合わせに添付したりしないでください。完全なアドレスを知る人は、同じサーバー情報を取得できる可能性があります。

Add ServerからSubscribeを追加する

Homeを開き、Add ServerのTypeでSubscribeを選択して、手元のサブスクリプションアドレスをURLに入力します。画面構成はデバイスやアプリ内の表示によって異なる場合がありますが、選択中の種類が単体サーバーのプロトコルではなくSubscribeであることを確認してください。識別しやすい名前を入力して保存し、一覧の取得が完了するまで待ちます。初回は問題の原因を特定しやすいよう、サブスクリプションを1件ずつ追加してください。

保存後にHomeへ戻り、想定したサブスクリプションのグループとサーバー項目が表示されるか確認します。サブスクリプション名が表示されても、管理対象が作成されたことを示すだけで、サーバー情報の取得や解析が成功したとは限りません。項目数が手元の情報のおおよその数と合うか、プロトコルが認識されているか、エラーが表示されていないかを続けて確認してください。一覧が空でも、まずサブスクリプションを残してエラー内容を記録し、アドレスとネットワークを確認します。同じサブスクリプションをすぐに何度も追加する必要はありません。

インポートに成功したら、パラメータが正しいと分かっているサーバーを1台選び、ガイドに沿って接続と動作を確認します。サブスクリプションの更新成功、サーバーの選択、接続スイッチのオン、実際のリクエストの成功は、それぞれ異なる状態です。最初の状態だけでは、接続経路全体が使えるとは判断できません。サーバーの選択とスイッチを入れる順序については、初回接続の確認方法をご覧ください。

失敗した段階に応じて切り分ける

アドレスエラーやリクエスト失敗が発生したら、まずコピーが完全か、現在のネットワークでドメインを解決できるか、インターネットに正常に接続できるかを確認します。認証や権限に関するメッセージが表示された場合は、手元のアドレスがまだ有効か確認してください。関係のないプロトコルやポートを次々に変更しないでください。応答がWebページ、ログイン画面、通常のテキストの場合、URLにアクセスできてもサーバー一覧として解析できるとは限りません。元の情報が何をエクスポートするものか確認してください。

ネットワークを変えると同じアドレスの結果が異なる場合は、各テスト時のネットワーク条件を記録し、DNS、アクセス経路、接続状態との関係を確認します。ネットワークを切り替えながらアドレスのパラメータを変更し、さらに選択中のサーバーまで変えるのは避けてください。複数の条件を同時に変えると、成功・失敗の原因を判断できなくなります。更新は必ずProxy経由で行うと決めつける必要もありません。実際に利用できる経路は、現在のネットワークとアドレスへの到達性によって異なります。

サブスクリプションをインポートできても、すべての項目が使えるとは限らず、ルール設定が含まれているとも限りません。サーバー一覧とConfig内のルールは別々に確認してください。次の章に進む前に、サブスクリプションのローカル名、最後に実行した更新の結果、現在選択中の項目を記録しておくと、以降の手動追加、更新、並べ替えの基準になります。

第3章 · 入力方法

Scan QR Codeとクリップボードからのインポート

QRコードとクリップボードは入力方法であり、独立したサーバープロトコルではありません。単体サーバーの共有リンク、サブスクリプションアドレス、または通常のテキストが含まれている場合があります。インポート前に、手元の情報からどの対象を追加するのか確認し、完了後に実際の結果を確認してください。QRコードを読み取れても、画像内のデータが読み取られたことを示すだけです。クリップボードの内容を読み取れても、現在のインポート先に適しているとは限りません。

スキャン前に読み取りやすさと情報の種類を確認する

Scan QR Codeを使うときは、QRコード全体が読み取り範囲に収まり、周囲に必要な余白があることを確認してください。強い反射やぼけも避けます。別の端末に表示したQRコードを読み取る場合は、画面を明るくし、距離を調整してください。中央の模様だけを切り抜かないでください。端の位置検出パターンが欠けると読み取りに影響します。何度も圧縮された画像は拡大してもぼやけるだけなので、可能であれば元の鮮明な画像を使ってください。

カメラで初めてスキャンするとき、システムからカメラへのアクセス許可を求められる場合があります。スキャンする際に必要な許可を与えてください。以前拒否した場合は、システム設定でShadowrocketの権限を確認してから再度試します。この権限はアプリがカメラを読み取れるかを決めるもので、QRコードの内容が有効かどうかとは関係ありません。許可後も読み取れない場合は、すべてのシステム権限を切り替えるのではなく、画像の鮮明さとデータの形式をそれぞれ確認してください。

読み取り後は、アプリが作成しようとしている項目の種類と、表示されたパラメータを確認してください。Subscribeをインポートするつもりが、通常のURLや単体サーバーしか表示されない場合は、保存せずに元の情報を確認します。読み取り結果が表示されたからといって、既存のサブスクリプションをすぐに置き換えないでください。QRコードがWebページへのログインや管理用のものなら、Shadowrocketで読み取ってもサーバー情報として使えるようにはなりません。

クリップボードからのインポートではテキスト全体を保つ

元の情報から共有テキスト全体をコピーし、Shadowrocketに戻って対応するクリップボードのインポート案内または操作を使います。システムがペーストの許可を求めた場合は、直前に行った操作に応じて判断してください。複数行のテキストは、各行の境界と元の形式を確認し、説明文、箇条書き番号、引用記号などが混ざらないようにします。長い文字列の途中に目に見えない空白が1つ入るだけで、解析結果が変わることがあります。

チャット画面で共有情報がプレビューカードに変換される場合、カードをタップして得られる内容と元のテキストをコピーして得られる内容が異なることがあります。インポートする際は、カードのタイトルではなく実際の共有リンクをコピーしてください。「形式を認識できません」などの表示が出たら、先頭の識別子が欠けていないか、末尾が省略されていないかを手元で確認します。認証情報をオンライン変換サイトにアップロードして試さないでください。機密情報が露出する範囲が広がるおそれがあります。

複数の項目を一度にコピーした場合は、インポート後に不足や重複がないか、プロトコル種別が想定どおりかを1件ずつ確認してください。一部の項目が成功しても、テキスト全体が正しく解析されたとは限りません。まず1件の完全な情報で入力方法を確認してから、長い一覧を処理してください。まとめて操作する前に、現在使えている項目を記録し、インポート後はメモを見ながら追加された範囲を確認します。後から整理するときに、新旧を見分けやすくなります。

読み取り後も接続の確認が必要

保存後にHomeへ戻り、追加した項目のメモ、Type、アドレス、ポートを確認してから、サーバーを選択して接続します。名前だけが表示されて重要なパラメータがない場合は、元の情報に共有データがすべて含まれていたか確認してください。項目がそろっているのに接続できない場合は、認証、TLS、トランスポート、現在のネットワークを確認します。スキャン時の距離を変えても、保存済みのパラメータは変わらず、サーバー側の拒否も解決できません。

同じQRコードを繰り返しスキャンすると、重複した項目が作成されることがあり、既存項目の問題が自動的に直るわけではありません。再スキャンの前に、対応する項目がすでにあるか確認してください。同じ名前の項目でも内容が同一とは限りません。削除する前に、プロトコル、アドレス、ポート、所属グループを比較してください。すぐに判断できない場合は、元の利用可能な記録を削除せず、テスト対象に別のメモを付けてください。

インポート後も元の情報がクリップボードに残っている場合があります。通常のテキストをコピーして内容を上書きし、クリップボードを他の端末と同期する設定がないか確認してください。自分で保存したQRコード画像もバックアップ保護の対象に含めます。スキャンは手入力を減らす方法であり、元の認証情報の重要性を下げるものではありません。その後の更新や取り消しは、各項目が属するサブスクリプションまたはサーバーに応じて行ってください。

第5章 · データの更新

サブスクリプションの更新方法とエラーへの対処

サブスクリプションを更新すると、リモートの内容を再取得し、端末内のサーバー一覧を更新します。Shadowrocketアプリ自体のアップデートでも、現在のサーバーへの再接続でもありません。アプリの購入、インストール、アップデートはApp Storeから行います。詳しくはアプリの入手方法をご覧ください。サーバーを管理するときは、現在の操作対象がサブスクリプション、個別の項目、接続状態のどれなのかを確認し、誤った階層で再試行を繰り返さないようにしてください。

手動更新で確認の基準を作る

初回インポート後に手動更新を1回実行し、結果を確認してください。更新前にグループ名、選択中の項目、重要なパラメータを記録し、更新後にメッセージ、一覧の変化、選択状態が維持されているかを確認します。リモート側でサーバーの追加や削除、名前の変更、認証情報の更新が行われる場合があるため、項目数の変化だけでは異常と判断できません。反対に、成功と表示されても内容に変化がない場合、リモート側で変更がなかった可能性があります。一覧の見た目だけでリクエストの有無を判断しないでください。

サブスクリプションに属する項目を以前ローカルで編集した場合は、変更内容を事前に記録してください。すべてのローカル変更が更新後も保持されるとは限りません。更新によって項目が再作成されたり、リモート側が管理する項目が上書きされたりする場合があります。長期的に残す必要があるテスト用パラメータは、用途を明記した手動コピーとして別に作成し、元のサブスクリプションとの関係を記録します。コピーは元の更新に自動追従しないため、後で手動確認が必要です。

更新時は、ルールの変更、ネットワークの切り替え、サーバーの削除を同時に行わないでください。安定したネットワークで1回更新し、結果を確認してから次の操作を決めます。更新後に選択中のサーバーが消えた場合は、一覧から有効な項目を選び直して接続を確認してください。接続スイッチがオンのままでも、新しいサーバーに問題なく切り替わったとは限りません。実際のリクエスト結果を判断材料にしてください。

自動更新は端末とネットワークの条件を考慮する

アプリに自動更新や周期の設定がある場合は、必要に応じて有効にし、現在の画面に表示される選択肢に従ってください。更新頻度は高ければよいとは限りません。頻繁なリクエストは不要な通信を増やし、一時的なエラーが繰り返し表示される原因にもなります。設定時は、リモートの情報が通常どの程度の頻度で変わるか、端末がいつネットワークに接続されるか、利用前に手動確認が必要かを考慮してください。重要な操作の前に手動で確認するほうが、バックグラウンドで更新されたと思い込むより確実です。

モバイル端末のバックグラウンド処理は、システムのスケジュール、ネットワーク状態、バッテリー条件の影響を受けます。自動更新を設定しても、常に予定どおり実行されるとは限りません。長時間アプリを開いていない場合、ネットワークが復旧した直後、端末が制限状態にある場合は、まずアプリを開いて実際の一覧を確認してください。バックグラウンド更新を確認できなかっただけでサブスクリプションが無効だと決めつけたり、端末の時刻から前回のリクエストが成功したと推測したりしないでください。

リモートアドレスへのアクセスに特定の経路が必要な場合、更新結果は現在のネットワークや接続状態によって変わることがあります。原因を調べる際は、更新時に接続中だったか、どのサーバーを選んでいたか、Wi-Fiとモバイル通信のどちらだったかを記録します。条件を1つだけ変えて再試行すれば、アクセス経路との関係を判断できます。更新を成功させるために、用途の分からないルーティング変更を長期間残さないでください。

リクエスト、認証、解析の段階ごとに対処する

リクエスト段階の失敗では、インターネット接続、DNS、アドレスの入力、接続タイムアウトを確認します。認証段階の失敗では、アドレスのアクセスパラメータが完全か、変更されていないか、現在の権限が有効かを確認してください。解析段階の失敗では、応答の用途が正しいか、ログインページやエラー説明に置き換わっていないかを確認します。段階によって対処方法は異なります。更新を何度もタップしても、不足しているパラメータが補われたり、リモートから返されるデータ形式が変わったりすることはありません。

更新に失敗しても元の一覧が残っている場合、「一度きれいに更新し直す」ためにサブスクリプションをすぐ削除しないでください。元の記録には使える項目が含まれている可能性があり、削除すると復元が難しくなります。まずエラーと元のパラメータを保存し、アドレスを確認してから再試行してください。更新に成功したのにすべてのサーバーで問題が起きた場合は、各項目のメモを個別に変更するのではなく、認証やトランスポート設定など更新前後で共通する項目を比較します。

サブスクリプションの状態と通常のリクエストの状態は分けて記録します。更新時刻が示すのは一覧の更新、Connectivity Testが示すのは特定の条件で行ったテスト、実際のアクセスが示すのは現在のリクエスト結果です。3つを合わせて問題の範囲を判断してください。サブスクリプションを長期間更新できない場合は、機密パラメータを隠したうえでエラーの段階とネットワーク条件を記録し、手元の情報を確認します。アドレス全体を送るよりも安全です。

第7章 · 診断結果の読み方

Connectivity Test、接続テスト、並べ替え

接続テストは、そのときの条件における特定のテストリクエストへの応答を確認するものです。継続的な通信速度、すべてのWebサイトへの到達性、将来の安定性を示すものではありません。テスト方法によって確認する通信経路の段階が異なるため、測定値は実際の方法を踏まえて解釈してください。まず現在の画面で使われているテストの種類を確認し、同じネットワーク、同じ方法で得た結果を比較します。異なる日時やネットワークで測った数値を並べて、長期的に最適なサーバーを決めないでください。

条件をそろえてテストする

テスト前に端末が正常にインターネットへ接続されていることを確認し、帯域を大きく使う作業を一時停止して、Wi-Fiかモバイル通信かを記録してください。ネットワークを切り替えた直後なら、接続状態が安定してからテストします。端末とアクセスポイント間の無線品質、ネットワークの混雑、接続先サービスの状態は、いずれも結果に影響します。1回の変動だけでサーバーの設定が間違っているとは判断できません。

サーバーを比較するときは、同じテスト方法を使ってください。ポートへの接続時間を主に測る方法もあれば、TLSやアプリケーション層の応答まで含める方法もあり、数値を直接比較できません。画面に方法の詳しい説明がない場合、結果は同じ回の候補を絞るための参考とし、精密なネットワーク測定結果とは見なさないでください。テストの対象が異なれば、同じサーバーでも結果が変わることがあります。

パラメータが正しいと分かっているサーバーを基準として選び、異常が疑われる項目を確認します。すべての項目が同時にタイムアウトする場合は、まず端末のネットワーク、DNS、一般的なテスト先への到達性を調べてください。特定の項目だけに問題がある場合は、そのアドレス、ポート、認証、トランスポート設定を確認します。全体に共通する問題と個別の問題を分けて対処するほうが、すべてのパスワードを無差別に入力し直すより効果的で、現在使える状態も保ちやすくなります。

測定に成功しても実際の接続を確認する

Connectivity Testの後に対象サーバーを選び、実際のリクエストを行ってください。テスト成功は、その条件でテスト経路から期待した応答が得られたことを示します。Configのすべてのルールが同じ経路を選ぶとは限りません。テストに成功しても特定のドメインにアクセスできない場合は、そのリクエストに適用されるルール、名前解決、接続先サービスの状態を確認してください。一覧の遅延値が低いからといって、DNSやルールの問題を除外することはできません。

テストに失敗した場合も、発生した段階を確認してください。アドレスを解決できない、接続がタイムアウトする、認証が拒否される、TLSエラーが発生する場合では、対処方法が異なります。エラーが表示されたら原文を記録し、機密情報を隠してください。明確なエラーがない場合は、まず同じネットワークでもう一度試し、その後に条件を1つ変えて確認します。短時間に繰り返しテストすると余分なリクエストが増えるため、計画的に問題の範囲を絞るほうが効果的です。

よく使うリクエストにアクセスできない一方で他のリクエストは正常な場合、現在のConfigでそれぞれに適用される方針を比較します。必要に応じてGlobal Routingを一時的に切り替えて確認し、終了後は元のモードに戻してください。切り替え後に状況が変わっても、すべてのルールに問題があるとは限りません。経路の選択を確認する必要があることを示すだけです。DNSの選択や名前解決の問題は、DNS設定の説明も参考にしてください。

並べ替えは検索を助けるもので、選択を代替しない

遅延順に並べ替えると、今回のテスト結果が良かった項目をまとめて表示でき、続けて試す際に便利です。並べ替え後は、現在選択中のサーバーを改めて確認してください。先頭の項目が自動で選択されたとは限りません。並べ替えと自動選択は別の機能なので、アプリ内の実際の状態を確認してください。一覧の順序は次回の更新やテストで変わることもあります。日常の記録では、名前と所属を使って項目を識別してください。

タイムアウトした項目を後ろに並べると誤選択を減らせますが、1回のタイムアウトだけで削除しないでください。一時的なネットワーク障害、テスト先の異常、接続先のメンテナンスでも同様の結果になることがあります。まずもう一度テストして、問題が続くか確認してから整理します。サーバーがすべてサブスクリプションに属している場合、端末内で個別に削除しても次回更新時に再び表示される可能性があります。長期的な変更はサブスクリプションの管理方法を踏まえてください。

テスト後は、現在のリクエストに適したパラメータが明確なサーバーを選び、通常のConfigに戻して実際に使って確認してください。テスト中にDNS、ルーティングモード、トランスポート設定を一時変更した場合は、項目ごとに元へ戻すか、最終的に残した変更を記録します。この手順を省くと、一時的な設定の組み合わせだけで使えた状態を見落とし、次にネットワークを切り替えたとき再現できなくなる可能性があります。

繰り返し発生する問題は、比較に必要な最低限の記録だけを残してください。認証情報を含むログやスクリーンショットを長期間ため込む必要はありません。同じ条件で問題が再現するか、1つの項目を変えると安定して解消するかに注目します。こうした記録は一時的な変動と設定ミスの切り分けに役立ち、後日サーバー情報を更新した際の再確認にも使えます。