Shadowrocketのサブスクリプションを更新できないときの対処法｜手動更新・起動時の自動更新・原因の切り分け

まず確認：サブスクリプションの更新失敗か、接続失敗か

Shadowrocketのサブスクリプション更新とは、ユーザーが用意したURLからサーバー情報を取得し、Homeのリストに反映する処理です。アプリ自体のアップデートや、特定のサーバーへの接続とは異なります。リストに以前の項目が表示されていても、端末に保存されたデータが残っているだけで、今回の更新が成功したとは限りません。

まず、どの段階で失敗したかを記録します。更新直後にエラーが表示されたのか、待機後にタイムアウトしたのか、更新完了と表示されたのに項目が増えなかったのかを確認してください。更新自体は完了し、特定のサーバーに接続できない場合は、接続テストで原因を調べます。サブスクリプションを何度も削除して追加し直す必要はありません。

この流れを理解すると、よくある2つの状況を区別できます。以前のサーバーには接続できても、サブスクリプションURLはすでに無効になっている場合があります。一方、更新は正常に完了しても、リスト内の特定のサーバーが一時的に利用できないこともあります。前者はリストの取得段階、後者はリストを使った後に起きる問題であり、両者は矛盾しません。

手動更新：Homeから始め、既存のサブスクリプションを残す

まず手動で1回更新し、結果を確認しましょう。最初に「再追加」するのは避けてください。同じURLを重複して読み込むと、Homeに複数のグループができ、状況を判断しにくくなることがあります。URLを入力し直す必要がある場合は、新しいものを追加するのではなく、既存のサブスクリプションを確認して編集しましょう。

1. サブスクリプションを見つける

   Homeを開き、更新するサブスクリプショングループを確認します。グループ名と現在の項目数を記録し、個別に追加したサーバーをサブスクリプションと取り違えないようにしてください。

2. URLを確認する

   対象のサブスクリプションの編集画面を開き、URLがサービス提供元から案内されたものと一致するか確認します。初回の読み込みは Home → 右上の「+」→ Type → Subscribe の順です。すでにサブスクリプションがある場合、もう一つ作成する必要はありません。

3. 下に引いて更新する

   Homeに戻り、リストの上部を下に引いて更新を開始し、処理が終わるまで待ちます。複数のサブスクリプションがある場合は、グループごとの結果を確認してください。1つのグループが成功しても、すべて更新できたとは限りません。

4. 結果を確認する

   成功または失敗の表示を記録してから、対象のグループを確認します。項目数が変わらないのは、配信元の内容に変更がなかっただけかもしれません。リクエストと解析が完了したかどうかは、更新時の表示もあわせて確認してください。

起動時の自動更新：Settingsで設定する

自動更新を使うと、日々の手動操作を減らせますが、無効なリンクは修復されません。まず手動更新が成功することを確認してから、起動時の更新を有効にしましょう。Settings → Subscribeを開き、Update On Openをオンにします。アプリの更新により、表示名や場所が変わる場合があります。実際の画面で確認してください。

この設定は、アプリを開いたときにサブスクリプションを更新するものです。一定間隔で常時バックグラウンド更新する機能ではありません。アプリに戻った後、更新されたか判断できない場合は、スイッチを何度も切り替えるより、Homeで手動更新して結果を確認する方が確実です。

• まず設定を確認：Settings → Subscribe → Update On Open。サーバーリストの自動更新設定をConfigで探さないでください。
• 次に動作を確認：有効にした後、アプリを開き直してリクエストが終わるまで待ち、対象のサブスクリプションに更新結果が表示されたか確認します。Home画面が表示されただけでは、リクエストの成功を確認できません。
• 現在のネットワークにも注意：アプリを開いたときにインターネットへ接続されていない場合や、接続中のWi-Fiで認証が必要な場合は、自動更新に失敗することがあります。ネットワークが復旧したら、手動でもう一度更新してください。
• 機能を混同しない：Settings → On Demandはオンデマンド接続を管理する設定で、Subscribeの更新設定の代わりにはなりません。接続の開始とサブスクリプションの更新は別の操作です。

自動更新は失敗するのに手動更新は成功する場合は、2回の操作時のネットワーク環境と接続状態を比べてください。アプリを開いた瞬間に、Wi-Fiとモバイル通信が切り替わっていた可能性もあります。1回の違いだけで設定が機能していないとは判断できません。同じネットワークで再度確認しましょう。

ステップ1：サブスクリプションURLの無効化や権限変更を確認する

まず、利用中のサービス提供元にサブスクリプションURLが有効か確認してください。WebサイトのログインURLをサブスクリプションURLの代わりに使ったり、記憶だけを頼りにクエリパラメーターを削除したりしないでください。長いURLには、アカウント識別情報、アクセス認証情報、出力形式の指定などが含まれている場合があります。パラメーターが1つ欠けるだけで、異なる結果になることがあります。

https://example.com/sub?token=xxxx

上記は実際の読み込みには使えない例です。実際に確認するときは、端末上でURLと入手元を一文字ずつ照合してください。特に、先頭のプロトコル、ドメイン、パス、疑問符以降のパラメーター、コピー時に混入した空白や改行を確認します。実際のURLを公開ページや不明な変換ツールに入力しないでください。

• URLが再発行された：サービス提供元がサブスクリプションURLを再発行すると、古いtokenが無効になることがあります。新しいURL全体を既存のサブスクリプションに保存してから更新してください。
• アクセス権限が変わった：アカウントの状態、サービスの有効期間、サービス提供元のアクセス制限が、サブスクリプションの応答に影響する場合があります。アプリの購入状態で、これらの権限が得られるわけではありません。
• 401または403が返る：エラーの詳細にこれらのHTTPステータスが表示された場合は、まず認証とアクセス制限を確認してください。数値だけで原因を特定することはできず、同じ原因とは限りません。
• 404が返る：URL全体のパスと、アクセス先が変更されていないか確認してください。この場合、サーバーのポートを手当たり次第に変更しても、サブスクリプションAPIのパスの問題は解決しません。
• 429が返る：連続更新を止め、サービス提供元の案内に従って時間をおいてから再試行してください。何度も続けてリクエストすると、頻度制限が再度適用されることがあります。

ブラウザーで同じドメインのトップページを開けても、サブスクリプションAPIが有効とは限りません。トップページとサブスクリプションのパスで、異なる権限確認が行われることがあります。ログインページに転送されても、サーバーリストを取得できたことにはなりません。ドメインにアクセスできるかではなく、サブスクリプションURL全体への応答を確認してください。

ステップ2：現在のネットワークとリクエストのタイムアウトを確認する

URLが有効と確認できたら、端末からサブスクリプションのホストに安定してアクセスできるか調べます。まずWi-FiのWeb認証を完了し、一般のWebページが正常に読み込めることを確認してから、Wi-Fiとモバイル通信を比較してください。URL、モード、ネットワークを同時に変更すると比較できなくなるため、条件は一度に1つだけ変えます。

上記は、トラブルシューティング時に表示されることがある英語のメッセージです。システム言語やエラーの発生元によって表示は異なります。特定の文言に当てはめようとして、エラーの詳細を見落とさないでください。証明書に関するメッセージが表示された場合は、端末の日付と時刻を確認し、サービス提供元に証明書を確認してもらいます。証明書の検証を無効にして回避しないでください。

1. システム設定でネットワークに接続されていることを確認します。Web認証が必要なWi-Fiでは、先に認証を完了してください。
2. Shadowrocketの現在の接続状態とGlobal Routingの選択内容を記録し、まず設定を変えずに更新します。
3. Wi-Fiまたはモバイル通信のどちらか一方だけを切り替え、同じサブスクリプションを更新して結果を比較します。
4. 現在の接続がリクエストに影響していると思われる場合は、条件を制御できる状況で接続を切って再度試します。On Demandが有効なら、接続が再び開始されないか確認してください。

Global RoutingのProxy、Direct、Config、Sceneは、通信全体の処理方法を選ぶ設定であり、「サブスクリプションを修復」するボタンではありません。1つのURLを更新するために、通信全体の処理方法を長期間強制的に変更しないでください。動作を確認せずにDIRECTルールを追加するのも避けましょう。サブスクリプションリクエストの実際の経路は、現在の接続と設定を踏まえて判断してください。

ステップ3：取得内容と形式の認識エラーを確認する

ネットワークリクエストが完了しても、読み込み可能な項目がない場合があります。HTTP 200はHTTPレベルでリクエストが成功したことを示すだけです。応答本文がログインページ、メンテナンスページ、エラー説明だったり、現在の読み込み方法で認識できないデータだったりすることがあります。この場合、ネットワークを切り替えても解決しない可能性があります。

• まず読み込み方法を確認：Home →「+」→ Type → Subscribeは、サブスクリプションの読み込みに使用します。Configは設定ファイルを管理する機能です。設定ファイル全体のURLとサーバーのサブスクリプションURLを、同じ種類の入力として扱わないでください。
• 次に出力形式の用途を確認：利用中のサービス提供元にShadowrocketを使用していることを伝え、案内されたサブスクリプションの出力が現在の読み込み方法に対応しているか確認してください。ファイルの拡張子だけで判断しないでください。
• 空の結果を確認：応答内容が空の場合や、認識可能なサーバー項目が含まれていない場合、リストが期待どおりに更新されないことがあります。まずローカルのリストを消去するのではなく、サービス提供元に応答本文を確認してもらってください。
• 項目の完全性を確認：Address、Port、およびプロトコルで必要となる認証情報がサーバー側の設定と一致している必要があります。サブスクリプションを読み込めても、各項目のパラメーターがすべて揃っているとは限りません。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロトコル名です。Subscribeはサブスクリプションの読み込みタイプを指します。同じプロトコル名が記載されていても、2つのサービスのサブスクリプション形式が同一とは限りません。プロトコル、サブスクリプション形式、完全な設定ファイルの構造はそれぞれ異なるものです。

更新後の確認：項目をテストし、重複を整理する

更新に成功したら、まず対象のグループを確認し、その中から1つの項目を選んで接続をテストします。Connectivity Testでは、テスト時の到達性や遅延を確認できますが、帯域幅を測定するものではありません。表示された数値だけで、すべてのWebサイトやサービスが正常に使えるとは判断できません。

1. 更新結果を確認：対象グループの名前と項目の変化を確認します。サービス提供元の内容に変更がなければ、項目数や名前が変わらないことも正常な結果として考えられます。
2. 接続を個別にテスト：既存の項目を選び、Connectivity Testを実行した後、アクセスしたいページを実際に開いてみます。リストの更新成功とページへのアクセス成功は、別々に記録してください。
3. 重複した読み込み元を確認：同じサブスクリプションを複数回読み込んだ場合は、正しいURLが設定されているグループを確認してから、不要なグループを削除します。サーバーの表示名だけで重複を判断しないでください。
4. メンテナンス記録を残す：今回変更したのがURL、ネットワーク、自動更新設定のどれかを記録します。同じ現象が再発したとき、該当する箇所からすぐに確認できます。

それでも失敗する場合は、ネットワークの種類、発生時刻、エラー全文、試した手順を利用中のサービス提供元に伝え、非公開のサポート窓口でサブスクリプションの権限を確認してください。公開するスクリーンショットでは認証情報を隠します。「更新できない」とだけ伝えるより、URL、APIの応答、形式のどこに問題があるかを特定しやすくなります。

Shadowrocketは買い切りのクローズドソースの商用アプリです。主にiPhoneとiPadで利用でき、入手先はApp Storeのみです。システム要件はApp Storeのページに記載された内容をご確認ください。アプリの購入 ≠ サーバー利用プラン。アプリを購入しても、サーバーやサブスクリプションが自動的に付属するわけではありません。このサイトでは、ユーザーがすでに利用しているサブスクリプションの管理方法を解説しており、サーバーやサブスクリプションの提供、販売、推奨はしていません。