Shadowrocket サブスクリプションとサーバー管理ガイド

サブスクリプション、サーバー、Config を区別する

3種類の対象はそれぞれ役割が異なる

操作を始める前に、Shadowrocket で同時に登場しやすい3種類の対象を分けて理解しましょう。サーバー項目は、直接接続を確立するためのパラメータ一式で、通常はプロトコル種別、サーバーアドレス、ポート、認証情報、通信オプションを含みます。サブスクリプションは更新の入口で、クライアントが読み込むと複数のサーバー項目を生成できます。同じ元データから派生した複数のサーバーを管理するのに適しています。Config はルール、ポリシー、DNS などの動作を管理し、リクエストがどのルールに一致し、一致後に PROXY、DIRECT、その他のポリシーのどれへ渡るかを決めます。サーバーに接続できるかどうかと、トラフィックをどう振り分けるかは別の問題です。誤ったポートを Config の変更で補うことも、適用できないルールをサブスクリプションの再更新で直すこともできません。

Home に表示されるサーバー一覧は、日常的に接続先を選ぶ場所です。Subscribe はサブスクリプションの保存と更新、Add Server は単一サーバーの登録、Config はルール設定の選択または編集に使います。Global Routing は、現在どの設定、プロキシ、直接接続の方式を使うかを決めます。iPhone と iPad では画面上の配置が異なる場合がありますが、これらの英語名が示す機能の関係は変わりません。入口の位置が本稿の説明と少し違う場合は、画面上で同じ名前の項目を探してください。画面座標に従って機械的に操作する必要はありません。

登録前に元の資料を保存する

Subscribe を使う場合も Add Server を使う場合も、まず変更前の元データを保存してください。サブスクリプションでは、用途、完全なURL、最後に利用可能と確認した状態を最低限記録します。単一サーバーでは、プロトコル名、ホスト、ポート、認証項目、TLS の状態、通信方式、メモを記録します。長いURLや大文字・小文字、パス、クエリパラメータはスクリーンショットで切れることがあるため、画像だけに頼らないでください。登録前に不要そうな文字を勝手に削除するのも避けましょう。URL のスラッシュ、疑問符、シャープ、パーセント記号には構造上の意味がある場合があり、保存できても意味が保たれているとは限りません。

まず少数の項目で検証してから、完全な一覧へ広げることをおすすめします。順序は、デバイスの時刻とネットワークが正常であることを確認し、サーバー1台またはサブスクリプション1件を登録し、接続テストを実行し、対象項目を選択して、最後に Global Routing と Config を確認します。こうすれば、問題が元のパラメータ、サブスクリプションの解析、サーバー接続、ルール分岐のどの層にあるかを判断しやすくなります。アプリの入手元をまだ確認していない場合は、まずApp Store 正規版の確認方法をご覧ください。Shadowrocket の開発者は Shadow Launch Technology Limited、アプリ ID は 932747118 です。

Subscribe の登録と更新方針

サブスクリプション追加前にURLの完全性を確認する

Shadowrocket で Subscribe を開いて項目を追加する際は、通常サブスクリプションURLを入力し、画面に用意された項目で名前や更新動作を設定します。貼り付ける前に、URLの前後に空白や改行がないか確認してください。チャット、メール、ウェブページから長い文字列をコピーすると、文末の句読点まで選択されたり、画面上で省略された部分だけがコピーされたりすることがあります。保存済みの元データから完全な内容をコピーし、貼り付けた後にカーソルを先頭と末尾へ移動して確認するのが確実です。ドメイン部分の中央だけを目視で確認しないでください。

名前は用途や範囲を表すものにし、「サブスクリプション1」「新しいサブスクリプション」のような後で判別しにくい名前は避けましょう。名前はローカル整理のためのもので、URLの内容を修復するものではありません。同じURLを重複して追加すると、更新後に見分けにくいサーバーグループが現れ、選択やトラブルシューティングの妨げになります。追加前に Subscribe の一覧を確認し、用途、ドメイン、パスが同じ項目がないか確認してください。URL内の認証パラメータは1文字違うだけでも別データとして扱い、手作業で統合して推測しないことをおすすめします。

名前：平日の利用
URL：https://example.com/sub?token=xxxx
更新前の確認：
1. https:// で始まっている
2. 末尾に空白、ピリオド、改行がない
3. token パラメータが完全である
4. 同じURLを重複保存していない

手動更新、自動更新、失敗時の保持

サブスクリプション更新とは、クライアントがリモートの内容を再読み込みし、その結果に基づいて関連するサーバー項目を調整する処理です。日常の管理では、まず手動更新で結果を確認するのが安全です。更新後は、サーバー数に明らかな異常がないか、既存のメモが変わっていないか、現在選択中の項目が残っているかを確認し、使用予定の項目を再テストしてください。自動更新はデータ管理が安定した場合に適していますが、間隔を短くしすぎないでください。頻繁なリクエストで接続品質が向上するわけではなく、トラブルシューティング中に一覧が変化し続け、同じ問題を同じ条件で再現しにくくなることがあります。

更新に失敗しても、すぐにサブスクリプションを削除したり、何度も連続でタップしたりしないでください。まず、どの層で失敗したかを分けて考えます。ブラウザで通常のウェブページも開けない場合は、現在のネットワークを復旧します。そのサブスクリプションだけ更新に失敗する場合は、URLが途中で切れていないか、デバイスの時刻が正しいか、URL内の認証情報が変わっていないか確認します。更新成功と表示されたのにサーバー一覧が空の場合は、元データに戻り、クライアントが解析できる形式になっているか確認してください。1回の失敗でローカルの項目がすべて無効になったとは限りません。削除前に、既存項目をテスト・接続できるか確認しましょう。

更新後は、「更新に成功したこと」と「サーバーが利用できること」を分けて判断します。更新成功は、クライアントがデータを取得して処理したことを示すだけで、すべてのサーバーが接続できるとは限りません。逆に、あるサーバーがタイムアウトしても、サブスクリプションURLが誤っているとは限りません。まず Subscribe で更新状態を確認し、次にサーバー一覧で Connectivity Test を実行し、最後に選択した項目で実際の接続を確認してください。層ごとに確認すれば、接続障害をサブスクリプション障害と誤認しにくくなります。

更新前後で管理できる変更にする

サブスクリプション管理でよくある難しさは、更新によってそのサブスクリプションから生成された内容が上書きされることです。サブスクリプション項目内のサーバー名やフィールドを直接変更すると、次回更新時にローカルの変更がリモートデータで置き換えられる場合があります。長期的に残したい個人メモは独立した記録に保存し、試したいパラメータは単独の手入力サーバーとして複製してから変更し、名前に「テスト用コピー」と明記してください。こうすればサブスクリプションを元の状態に保ち、次回更新で実験結果が中断されることもありません。

更新後に重複項目が大量に現れても、まず1件ずつ削除しないでください。同じサブスクリプションを重複追加したのか、複数のサブスクリプションに同じサーバーが含まれるのか、リモート側のメモ変更で見た目が似ているだけなのかを判断します。前2者は Subscribe の層で整理し、後者はプロトコル、ホスト、ポート、認証項目を比較します。重複項目を体系的に処理する方法は複数サブスクリプションの整理の章を参照してください。画面の表示だけでは判断しにくい場合は、トラブルシューティングで「サブスクリプションとサーバーインポート」の分類を確認できます。

Add Server の手入力項目と確認順序

まずプロトコルを選び、項目を対応させる

Add Server は、単一サーバーの完全なパラメータをすでに保有していて、項目ごとに入力したい場合や、独立したテスト用コピーを作りたい場合に適しています。最初に行うのはアドレスの入力ではなく、正しいプロトコル種別の選択です。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 では認証モデルが異なります。項目名が似ていても意味を置き換えることはできません。種類を間違えても保存できる場合がありますが、接続時にハンドシェイク、認証、通信構造の不一致で失敗します。

入力は、プロトコル種別、サーバーアドレス、ポート、認証項目、TLS または暗号化関連オプション、通信方式、Path と Host、メモの順に進めると確認しやすくなります。各グループを入力するたびに元データへ戻り、一文字ずつ照合してください。サーバーアドレスはドメインまたは IP アドレスで、プロトコルの接頭辞を付けず、ポートをアドレス欄に重ねて入力しないでください。ポートには数字だけを入力します。名前やメモは自由に設定できますが、元パラメータの記録をメモで置き換えないでください。

認証、TLS、通信項目を独断で推測しない

認証項目は通常、大文字と小文字を区別します。UUID のハイフン、パスワードの記号、鍵の大文字・小文字は内容そのものなので、自動的に書き換えないでください。コピー後に接続できない場合は、不可視の空白を除外するため、項目をいったん削除してもう一度貼り付けます。TLS、SNI、Host、Path、Transport などは相互に関連するパラメータとして扱い、元データに明記されている場合は項目ごとに対応させます。記載がない場合は、別のサーバーの経験から値を補わないでください。特に Host と SNI は、設定によって同じ内容になることがあっても役割の層が異なります。文字列が同じだからといって自由に置き換えないでください。

Transport も元データと一致させる必要があります。WebSocket などの通信方式を選ぶと、画面に Path や Host などの追加項目が現れる場合があります。これらは対応する通信方式でのみ意味を持ちます。元データが別の通信方式を使っている場合、他の項目の Path を流用しても互換性は得られません。既存項目を編集するときは、まずプロトコルと Transport を確認し、選択変更によって追加項目が残っていないか確認してください。必要であればテスト用コピーを新規作成し、空の状態から入力すると、古い項目の残留による混乱を避けられます。

保存後の最小検証ループ

入力が終わったら保存しますが、すぐに残りをまとめて登録しないでください。Home に戻り、追加したサーバーを見つけて、利用できる Connectivity Test または遅延テストを実行します。テストに応答があれば、その項目を選択して現在のサーバーにし、Global Routing を確認します。初回の検証では Config を使い、現在の Config に内容を理解できるルールがあることを確認してください。ルールの影響だけを除外したい場合は、目的を明確にしたうえで Proxy と Direct を一時的に比較できますが、テスト後は想定していた状態に戻します。Global Routing の3つの状態は、設定、プロキシ、直接接続で、画面上では Config、Proxy、Direct と表示されます。

テストがタイムアウトした場合は、複数の項目を一度に変更せず、項目の順番に確認します。まずアドレスとポート、次に認証項目、続いて TLS、SNI、Transport、最後にデバイスの時刻と現在のネットワークを確認します。1回に1項目だけ変更して再テストすれば、どの変更が影響したか判断できます。すべてのパラメータが完全に一致しているのに接続できない場合は、元の項目とテスト記録を残し、正確なデータを上書きしないでください。プロトコルの基本項目については、Shadowrocket が対応するプロトコルも参照してください。

Scan QR Code、クリップボード、共有リンク

QRコードを読み込む前に内容を確認する

サーバー情報がQRコードにエンコードされている場合は、Scan QR Code を使って読み取れます。QRコードはテキストを別の形で保持するだけで、パラメータの正確性を高めるものではありません。スキャン前に、現在インポートしたいサーバー情報のQRコードか確認し、認証情報を含むQRコードを公開の場で表示しないでください。読み取り後は「インポート成功」と表示されただけで接続せず、新しい項目を開いてプロトコル種別、サーバーアドレス、ポート、メモが想定どおりか確認します。

別の個人デバイスの画面にQRコードを表示する場合は、画面を適度に明るくし、カメラを安定させてください。読み取りにくいときは、ぼやけた画像を何度も切り抜くより、元の共有テキストを使うほうが確実です。QRコードの端が切れている、画像が圧縮されすぎている、中央が隠れている場合は読み取れないことがあります。スキャンできないのは読み取り層の問題であり、サーバーパラメータが無効だとは限りません。読み取りに成功してテストに失敗する場合は、プロトコル種別、認証情報、Transport の追加項目を中心にパラメータを確認します。

クリップボードからのインポートでは空白と複数行を確認する

クリップボードからのインポートは、単一の共有リンクや、アプリが認識できる構造化テキストの処理に適しています。コピー時はスキーム識別子から最後の文字までを選択し、前後に説明文を混ぜないでください。1つのメッセージにタイトル、番号、複数のリンクが含まれる場合は、クライアントが有効な行を自動判定することに頼らず、1件ずつコピーします。共有リンクにはサーバーアドレスや認証情報が含まれる場合があるため、インポート後はクリップボードを消去するのも安全です。

一部のテキストツールは長いリンクを自動的に改行します。見た目の改行が実際の改行とは限りませんが、リッチテキストからコピーすると空白や改行文字が挿入されることがあります。「プロトコルは認識できるのに接続できない」場合は、リンクを信頼できるローカルのプレーンテキスト編集領域へ貼り付けて構造を確認し、元データと照合してください。途中の文字を削除して試行しないでください。クエリパラメータやエンコード文字が欠けても、リンク自体は認識され、不完全なサーバー項目が生成されることがあります。

共有リンクはパラメータの入れ物であり、長期保存用のバックアップ形式ではない

一般的な共有テキストは、接頭辞でプロトコル種別を示し、その後にアドレス、ポート、認証、メモを含みます。プロトコルごとに構造が異なるため、別のプロトコルのリンクへ変換する目的で接頭辞だけを書き換えることはできません。以下は構造を見分けるための例で、すべて利用できないサンプルです。実際の操作では、ユーザー自身が保有する完全な資料を使ってください。

ss://[email protected]:443#Example
vmess://ENCODED-DEMO-DATA
vless://[email protected]:443?type=ws&security=tls#Example
trojan://[email protected]:443?security=tls#Example
hysteria2://[email protected]:443?insecure=0#Example

リンク末尾のメモは表示名として使われることが多く、パーセントエンコードされていると読みにくい場合があります。これはプロトコル本体には影響しませんが、手動で書き換える際は前方のクエリパラメータを壊さないでください。インポート結果のメモが文字化けしている場合は、接続パラメータが完全であることを確認してから、アドレスや認証項目を変えずにローカルの名前だけを修正します。VMess のように全体をエンコードする形式は、手動で分解して再結合しないほうが安全です。元のリンクからインポートし、サーバー詳細画面で各項目を確認してください。

共有リンクは、管理された範囲で個人デバイス間の移行に使うのに適していますが、唯一のバックアップには向きません。ローカルのメモ、並び順、Config、その他の管理情報が含まれない場合があり、コピーが不完全だと利用できなくなることもあります。長期保存では、元のパラメータ説明、サブスクリプションURLの記録、Config ファイルを用途とともに保管してください。単一項目を別の個人デバイスへ渡す場合は、QRコードを生成・表示する周囲の環境に注意し、使用後は表示画面をすぐ閉じます。

複数サブスクリプションのグループ化、命名、重複項目の整理

まず出所の境界で管理し、その後に用途で命名する

Subscribe が1～2件だけなら、初期名でも使えるように見えます。しかし数が増えると、意味の曖昧な名前が更新やトラブルシューティングに直接影響します。名前には少なくとも用途、デバイスの利用場面、データの範囲を含め、「日常メイン」「一時テスト」「旧設定の確認」などとすると便利です。サーバー地域、プロトコル、サブスクリプション用途を1つの長い名前に詰め込まず、詳しい情報は独立した記録に保存してください。名前の目的は、更新前にどのサーバーグループへ影響する操作か分かるようにすることです。

整理するときはサブスクリプションを管理単位にし、混在したサーバー一覧から先に項目を移動しないでください。まず Subscribe を開き、各項目のURL、名前、直近の手動更新結果を確認し、その後サーバー一覧に戻って各グループが生成した項目を確認します。使用しなくなったサブスクリプションは、まず更新動作を停止するか状態を記録し、一定期間確認してから削除します。すぐに削除すると、関連項目と過去の判断材料が同時に消え、「本当に不要」なのか「一時的な更新失敗」なのかを区別しにくくなります。

重複項目は主要フィールドを比較する

表示名が同じでも、サーバーが完全に同一とは限りません。重複を判断する際は、少なくともプロトコル、サーバーアドレス、ポート、認証識別子を比較します。TLS や Transport が関係する場合は、SNI、Host、Path、関連オプションも比較してください。これらの主要項目が一致して初めて、接続上の重複と判断できます。逆に、名前が違っても主要項目が同じなら、別のサブスクリプションが同じサーバーに異なるメモを付けているだけかもしれません。

重複を見つけたら、まずそれぞれがどのサブスクリプションに属するかを確認します。同じサブスクリプションの重複追加が原因なら、URLが正確で更新も正常な項目を残し、重複した Subscribe の記録を削除します。別のサブスクリプションに由来する場合は、日常の管理範囲に応じて残し方を決め、同じアドレスの項目を無条件にすべて削除しないでください。別のサブスクリプションにある同じサーバーは、今後異なる更新結果になる可能性があります。今日重複していても、将来も同じとは限りません。Home を読みやすくしたいだけなら、分かりやすい命名、並べ替え、不要なグループの削減で改善でき、重複ゼロを目指してサブスクリプション構造を壊す必要はありません。

安定した整理のリズムを作る

複数サブスクリプションを毎日並べ替える必要はありません。実用的な流れは、追加時に命名して手動更新し、更新後に主要項目を抜き打ち確認し、異常時はテスト記録を残し、無効だと確認してから削除することです。並べ替えは日常の選択に役立ちますが、サーバー品質の永続的な結論ではありません。ネットワーク環境、テスト対象、時刻によって遅延は変わります。テストのたびに大きく並べ替えると、慣れた位置が変わり続けてしまいます。

短いローカル一覧を1つ用意し、サブスクリプション名、用途、自動更新の有無、直近の手動確認結果、関連する Config を記録することをおすすめします。完全な認証情報を複製する必要はなく、管理関係を説明するために使います。実験用の新しいサブスクリプションは独立した名前で仮置きし、更新、抜き打ち確認、実際の接続を終えてから日常グループへ加えます。これなら重複や項目異常があっても、安定した一覧をすぐに乱さずに済みます。

一括整理の前は、Config も同時に変更しないようにします。サーバー一覧とルールが同時に変わると、接続異常がどの層から発生したか分かりにくくなります。まずサブスクリプションとサーバー項目を安定させ、その後に Global Routing と Config を確認するか、サーバーを固定してルールだけをテストしてください。複数サブスクリプション整理の目的は、一覧を最短にすることではなく、各記録の出所、更新方法、用途を再び理解できる状態にすることです。

Connectivity Test、遅延による並べ替え、トラブル特定

テスト結果が示すのは現在のテスト条件だけ

Connectivity Test とサーバー一覧の遅延テストは、現在のデバイス、ネットワーク、時刻において対象とのテスト接続を確立できるかを素早く確認するためのものです。明らかにタイムアウトする項目の選別や並べ替えには役立ちますが、すべてのアプリ通信の長期的な性能を示すものではありません。テスト対象、プロトコルのハンドシェイク、ネットワーク混雑、無線信号が結果に影響するため、1回の低い数値が永久的な安定性を意味するわけではなく、1回のタイムアウトだけで削除してはいけません。

一括テストの前に、デバイスがネットワーク切り替え中でないことを確認してください。モバイル通信から Wi-Fi へ切り替え中、または Wi-Fi の再接続直後は、グループ全体がタイムアウトしやすくなります。ネットワークが安定してから再テストし、可能なら画面を前面に表示したままにします。初回の結果が異常な場合は、少し間隔を空けて2回目のテストを行います。少数の項目だけが継続してタイムアウトするなら、単一項目のパラメータ確認へ進みます。

範囲から障害の層を判断する

テスト結果で最も重要なのは単一の数字ではなく、失敗した範囲です。すべてのサーバーが同時にタイムアウトする場合は、現在のネットワーク、システム時刻、Shadowrocket の接続状態を優先して確認します。同じサブスクリプションだけがすべてタイムアウトし、他のサブスクリプションが正常なら、そのサブスクリプション更新後の共通項目やデータ状態を確認します。単一サーバーだけがタイムアウトする場合は、その項目のアドレス、ポート、認証、通信パラメータを優先して確認します。テストに応答があるのに対象コンテンツを開けない場合は、選択中のサーバー、Global Routing、Config のルール、DNS を確認し、サブスクリプションURLを繰り返し編集しないでください。

並べ替えは選択のために使い、検証の代わりにしない

遅延順に並べ替えると、今回のテストで応答が速かった項目が上位に表示されます。大量のサーバーから候補を絞るには便利ですが、接続前にプロトコルパラメータと用途を確認してください。テスト応答は速くても現在の Config では使いにくい項目があり、短時間の揺らぎで2回の並べ替え結果が変わることもあります。まず遅延で少数の候補に絞り、各項目を実際に接続確認することをおすすめします。毎回先頭の項目を選ぶだけにしないでください。

複数サブスクリプションの一覧を一括テストする場合は、グループごとに実行すると結果を観察しやすくなります。継続してタイムアウトする項目を記録したら、同じアドレス、プロトコル、サブスクリプションを共有していないか確認します。共通する特徴は、単一の数値より問題を示しやすい場合があります。長期的に無効だと判断する前に、ネットワークが安定している状態で少なくとも再テストし、直近のサブスクリプション更新が成功しているか確認してください。削除は最後の手段であり、初回タイムアウトへの即時対応ではありません。

接続は成功するが分岐結果が想定と違う場合

サーバーテストが正常で、全体の接続も有効なのに、特定のドメインの行き先が想定と異なる場合、問題は通常ルール層にあります。まず Global Routing が Config になっているか確認します。Proxy の場合、各リクエストは Config の状態に従って判定されません。Direct の場合、サーバー項目は現在の通信を担当しません。Config にした後、ルールを上から順に確認し、より具体的な DOMAIN、DOMAIN-SUFFIX、IP-CIDR などのルールが、先に置かれた広範なルールに覆われていないか確認します。さらに FINAL の最終的な行き先も確認してください。

すべてのドメインで異常がある場合は、Config で想定したファイルが選択されているか、設定内で参照されるポリシー名が存在するかも確認します。ルールに PROXY と書かれていても、設定内に対応するポリシーや利用可能なサーバーがなければ、構文が正しくても想定どおりには動きません。接続失敗の詳しい確認手順はサーバーのタイムアウトと接続失敗チェックリストを、初回接続の最短手順は初回接続ガイドを参照してください。

削除、バックアップ、復元、デバイス移行

削除前に対象の階層を確認する

Shadowrocket で削除できる対象には、単一サーバー、サブスクリプション全体、Config があり、それぞれ影響範囲が異なります。手入力した単一サーバーを削除しても、そのローカル記録だけに影響します。サブスクリプションから生成された項目を削除しても、次回更新で再生成される場合があります。Subscribe を削除すると、そのグループの更新入口が失われます。Config を削除するとルール選択に影響しますが、サーバーは自動削除されません。操作前に現在どの一覧にいるかを確認し、名前、アドレス、関連用途を確認してください。

一時的にタイムアウトしている項目は、まず印を付けるか記録し、すぐに削除しないことをおすすめします。削除するサブスクリプションは、完全なURLと用途説明を保存してから、他のサブスクリプションが同じ管理構成に依存していないか確認します。Config を削除する場合は、現在使用中かどうか、ローカル変更があるかを先に確認してください。削除後に判断を誤ったと気づいても、元データを保存していなければ正確に復元できません。長いURLや複雑なルールを記憶だけで再入力すると、新たな誤りが生じやすくなります。

バックアップは4種類の資料を対象にする

完全な管理バックアップには、少なくとも次の4種類を含めます。サブスクリプションURLの記録、手入力サーバーのパラメータ、Config ファイル、それらの関係を説明する短い一覧です。サブスクリプションURLだけでは独立した手入力項目を保存できず、Config だけをエクスポートしてもすべてのサーバー認証情報が含まれるとは限りません。バックアップ前に Home、Subscribe、Config、Settings で移行に関係する表示項目を確認し、対象ごとに処理してください。

現在のアプリ画面に Data、Import from Cloud JSON、または同様のインポート・エクスポート入口がある場合は、画面の説明を読み、対象となるデータ範囲を確認してください。「特定の JSON をインポートできる」ことを、すべての設定が自動復元される意味だと解釈しないでください。エクスポート後は、既存データを上書きせずにファイルが生成されたか、名前を識別できるかを確認し、エクスポート時の用途を記録します。バックアップファイルとサブスクリプションURLには機密情報が含まれる場合があるため、管理された個人用ストレージに保存してください。

デバイス移行時は順番に復元する

新しい iPhone または iPad で復元する場合は、まず App Store の購入済み項目から Shadowrocket を取得し、その後データを層ごとに復元します。購入と購入済み項目からの復元方法はデバイス変更と購入復元の説明を参照してください。システム要件は常に App Store の掲載内容を基準とします。アプリの準備ができたら、まず Config を1つインポートするか初期状態を維持し、次にサブスクリプションを1件復元して手動更新し、サーバー1台をテストします。基本的な流れが正常だと確認してから、残りのサブスクリプションと手入力項目を追加してください。

初回起動後にすべての資料を一度にインポートし、すぐに既存内容を上書きしないでください。分割して復元すれば、問題の範囲を小さくできます。サブスクリプションが更新できない場合はその項目だけを確認し、サーバーをテストできない場合はそのパラメータだけを確認し、分岐結果が違う場合は Config を確認します。Import from Cloud JSON を使った場合も、完了後に項目を抜き打ち確認してください。項目数だけを見て判断しないでください。名前、並び順、現在の選択状態が旧デバイスと異なっていても、必ずしもパラメータが失われたとは限りません。

復元後は3回に分けて確認します。1回目は Subscribe を手動更新できるか、2回目は主要サーバーの Connectivity Test と実際の接続、3回目は Global Routing が Config のとき、よく使うドメインが想定したポリシーへ入るかを確認します。その後で On Demand などの自動接続動作を確認し、基本接続が未確認の段階で変数を増やさないようにします。旧デバイスの資料は、新しいデバイスで安定した検証が完了するまで残し、その後に個人のデータ管理方針に従って処理してください。

保存するだけでなく復元できる記録を作る

有効なバックアップかどうかは「ファイルが存在するか」ではなく、「復元方法を説明できるか」で判断します。各 Config に用途を書き、各 Subscribe の記録に対応する名前を付け、手入力サーバーには項目一覧を保存し、復元後の確認手順も記録してください。説明のない長いリンクを保存するだけでは、数か月後に Subscribe へ入れるべきか、単一サーバーとしてインポートすべきか判断しにくく、現在の利用範囲に属するかも確認できません。

重要な設定変更後はコピーを再保存しますが、似たファイルを大量に保存する必要はありません。「現在の安定版」「変更前」「実験中」の3種類に分け、ファイル名に認証情報を入れないようにします。実験が成功したら確認済みの版を現在の安定版とし、失敗したら変更前のコピーへ戻します。このバージョン分けは個人のデータ管理方法であり、クライアントに表示されるアプリのバージョンに依存せず、画面が変更されても意味を失いません。

Config、Global Routing、ルール分岐

3種類の Global Routing の状態を理解する

サーバー管理は最終的にトラフィック方針と組み合わせて使います。Global Routing の設定、プロキシ、直接接続は、それぞれ Config、Proxy、Direct に対応します。Config は現在の設定ファイルのルールを順番に判定し、Proxy はリクエストを現在のプロキシポリシーへ一律に渡し、Direct はリクエストを直接接続します。日常的にルール分岐を使う場合は Config を選択してください。Proxy と Direct は、異常がルール層にあるか確認するなど、明確な目的の比較テストに適しています。テスト後は想定した状態へ戻してください。

ルールは上から順に最初の一致を適用する

Config のルールは通常、記述された順番に処理されます。リクエストがあるルールに一致すると、そのルールで指定されたポリシーを実行し、後続のルールは探しません。そのため、具体的なルールを広範なルールより前に置きます。たとえば単一の DOMAIN ルールは対象範囲の広い DOMAIN-SUFFIX より前に、ローカルネットワークの IP-CIDR ルールは FINAL より前に配置します。FINAL は前のルールに一致しなかったリクエストを受けるため、通常はルール一覧の末尾に置きます。

DOMAIN は完全なドメイン名に一致し、DOMAIN-SUFFIX はドメインのサフィックスで一致し、DOMAIN-KEYWORD はドメイン内のキーワードで一致するため、通常はより広い範囲を対象とします。GEOIP は対象 IP の地理データベース結果で判定し、IP-CIDR と IP-CIDR6 はアドレス範囲に使い、USER-AGENT はリクエスト識別子で一致します。ルール右側の PROXY、DIRECT、REJECT は処理ポリシーであり、サーバープロトコル名ではありません。PROXY には利用可能なポリシーまたはサーバーを割り当てる必要があり、DIRECT は直接接続、REJECT はリクエスト拒否を意味します。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-KEYWORD,media,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

例は構文の関係を示すもので、すべてのネットワーク環境に適するとは限りません。実際の Config は、ユーザー自身の目的と保有する設定に基づいて確認してください。変更前に元ファイルをコピーし、変更のたびに少数のルールだけを調整します。大量のルールを同時に移動し、ポリシー名を書き換え、DNS まで変更すると、異常の原因をほぼ特定できなくなります。まず具体的な DOMAIN ルールを1つ追加して一致を確認し、その後 DOMAIN-SUFFIX など、より広い種類へ段階的に広げると安全です。

サーバー名、ポリシー名、ルールの行き先を対応させる

ルールの末尾に PROXY と書いても、任意のサーバーが自動的に利用可能になるわけではありません。Config のポリシー名は、実際に存在するポリシー構造と対応している必要があり、そのポリシー内で有効なサーバーを選べなければなりません。サブスクリプション更新後にサーバー名が変わった場合、特定の名前を手動で参照するポリシーは再確認が必要です。安定させるには、ルールから分かりやすいポリシー名を参照し、サーバーの選択はポリシー側で管理します。多数のルールに具体的なサーバー名を分散して書く方法は避けてください。

「Connectivity Test は正常なのにルールが反映されない」場合は、次の順序で確認します。Global Routing が Config か、選択中の Config が正しいか、対象ドメインが先行ルールに一致していないか、ルール末尾のポリシー名が存在するか、そのポリシーに利用可能なサーバーがあるか、FINAL が早すぎないかを確認します。範囲の非常に小さい DOMAIN ルールを一時的に追加して検証し、確認後に適用範囲を広げるか判断できます。トラブルシューティング中は、サーバー一覧の変化がルールテストに影響しないよう、すべてのサブスクリプションを同時に更新しないでください。

Config の変更、インポート、切り戻し

Config を変更する前に元のコピーを保存し、テスト用コピーには識別しやすい名前を付けます。新しい設定ファイルをインポートしたら、まずセクション名、ルール部分、FINAL を確認し、既知のドメインを少数選んでテストします。ファイルをインポートできたからといって、すべてのポリシー参照が有効だとは限りません。構文を読み取れることと、ポリシーを実行できることは別の確認です。ポリシー名を解析できないと表示された場合は、設定内容に戻って綴りと対応するグループを確認してください。

ルールのデバッグでは、切り戻しの経路を残してください。変更前に現在の安定版コピーを記録し、ルールを1グループ変更したらすぐテストし、変更目的を書き残します。結果が想定と違う場合は、一時的なルールを重ね続けず、直前の安定版へ戻します。出所の異なる Config を2つ、そのまま連結することはおすすめしません。同じセクション、同名ポリシー、重複する FINAL、異なる DNS 設定が上書きし合う可能性があります。統合する場合は、各部分を理解してから処理し、段階ごとに検証してください。

サーバーと Config の管理が完了したら、日常の管理は固定した流れにまとめられます。必要に応じて Subscribe を更新し、主要サーバーを抜き打ち確認し、分かりやすい名前を保ち、Config の状態で接続し、異常時はネットワーク、サブスクリプション、サーバー、ルールの4層で原因を特定し、重要な変更前にコピーを保存します。初回接続の手順だけを確認したい場合はShadowrocket 使い方ガイドへ戻り、問題を分類して確認したい場合はトラブルシューティングを開いてください。