自分のサブスクリプションを利用している場合は、まずHomeで手動更新し、リストが正常に更新されたことを確認します。その後、Settings → SubscribeでUpdate on Openを有効にします。更新できないときは、サブスクリプションURLにリクエストが届いているか、返された内容を解析できるかを順に確認しましょう。サブスクリプションの更新、接続テスト、Configの更新は別の操作です。この記事では操作、確認、トラブル対処の順に説明します。
サブスクリプション更新の対象：リストの更新であり、アプリのアップデートではありません
Shadowrocketのサブスクリプション更新では、登録済みのサブスクリプションURLを再度読み込み、Homeの該当グループにある接続項目を更新します。接続先で名前、アドレス、ポートなどが変更された場合、通常は変更を反映するために再取得が必要です。この記事は、すでに自身のサービスとサブスクリプションを利用していることを前提としています。
この流れでは、内容を取得できることと、接続項目を解析できることは別の条件です。サブスクリプションサーバーからログインページが返された場合、リクエストに成功しても有効なサブスクリプションを取得できたとは限りません。リストが更新されても、各接続が正常に使えるとは限りません。接続の可否は、接続先の状態、認証情報、現在のネットワーク環境にも左右されます。
- Home：登録済みの接続やサブスクリプショングループを確認し、リストを更新して更新後の項目をチェックします。
- Settings → Subscribe：アプリ起動時の更新設定など、サブスクリプション関連の動作を管理します。
- Config：構成ファイルを管理します。ルールやリモート構成の更新は、Homeのサブスクリプションリスト更新と混同しないでください。
- App Store：アプリ本体の入手とアップデートに使います。サブスクリプションの内容は更新しません。
手動更新：URLを確認してからグループをチェック
初回の追加時や更新時に問題が起きた場合は、まず手動で更新してください。自動更新を待つのではなく、操作の結果をその場で確認できます。操作前に、対象グループの名前と現在の項目数、確認したい接続名を控えておきましょう。更新前後の比較に使います。サブスクリプションの認証情報を記録したり、公開したりする必要はありません。
-
サブスクリプションの種類を確認
Homeを開き、登録済みのサブスクリプショングループを探します。初めて追加する場合は、Home右上の「+」→ Type → Subscribeを選び、自分のサブスクリプションURLを入力して保存します。単一の共有リンクは、継続的に更新できるサブスクリプションリストではありません。
-
URL全体を確認
該当するサブスクリプションの編集画面を開き、URLを確認します。クエリパラメーターがすべて含まれていること、前後に空白や改行、説明文が混ざっていないことを確認してください。自分のURLだけを確認し、完全なURLを公開の場に投稿しないでください。
-
リストを下に引いて更新
Homeに戻り、リスト上で下にスワイプして指を離し、サブスクリプションを更新します。処理が終わるまで待ち、エラー表示がないか確認してください。複数のサブスクリプションを登録している場合は、対象のグループごとに結果を確認します。
-
更新結果を確認
対象グループの名前と項目数、変更を把握している項目を照合します。接続先で特定の接続情報が変更されたことが分かっている場合は、その項目の編集画面でアドレスやポートを確認してから接続テストを行います。
以下はURLの構造を示す例であり、接続には使えません。例のtokenはクエリパラメーターです。実際のURLでは別のパラメーター名が使われたり、パスに認証情報が含まれたりする場合があります。例に合わせて自分のURLの項目を書き換えないでください。
https://example.com/sub?token=xxxx起動時の自動更新：Subscribeで設定
手動更新が成功したら、Settings → Subscribe → Update on Openを開き、アプリ起動時の更新を有効にします。この設定はアプリを開いたときにサブスクリプションを取得するもので、一定間隔で実行するバックグラウンドの定期処理ではありません。接続を維持していてもアプリを開いていなければ、サブスクリプションが更新されたとは判断できません。
- まず手動更新を確認：URL自体が無効な場合、自動更新を有効にしても同じ問題が繰り返されるだけで、接続先の認証情報は修復されません。
- 有効にしたらHomeに戻る：次回アプリを開いたときに、対象グループと変更が分かっている項目を確認します。設定が有効になっていることだけで、更新成功と判断しないでください。
- 変更が分かっている場合は手動更新：接続先の変更をすぐに反映したいときは、次にアプリを開くまで待つより、手動更新して結果を確認するほうが確実です。
- トラブル対処の条件を絞る：2回の更新結果を比較する場合は、自動更新を一時的に無効にして、確認後に必要に応じて元に戻します。
Update on OpenとOn Demandは用途が異なります。前者はサブスクリプション取得のタイミングを制御し、後者は接続を必要に応じて開始するための設定です。Settings → On Demandを変更してもサブスクリプションURLの問題は解決せず、リスト更新の代わりにもなりません。サブスクリプションのトラブル対処では、両方の設定を同時に変更する必要はありません。
| 操作・設定 | 実行されるタイミング | 確認するポイント |
|---|---|---|
| Homeで下にスワイプして更新 | ユーザーが手動で操作 | 今回の表示、対象グループ、把握している項目の変更 |
| Update on Open | アプリ起動時に実行 | 設定の有効・無効ではなく、実際の取得結果 |
| On Demand | 接続条件に応じて実行 | 接続状態を確認。サブスクリプション更新の証拠にはなりません |
結論：手動更新の成功を確認してから自動更新を有効にする
まず再現可能な手動更新の成功を確認してから、Update on Openを有効にします。後で問題が起きた際に、URLの無効化と自動更新の未完了を切り分けやすくなり、複数の設定を同時に変更する必要もありません。
更新できないときの対処法：URL・ネットワーク・形式を分けて確認
まず画面に表示されたエラー全文を記録し、以下の3つの原因に分けて確認します。システムの表示言語やリクエストの段階によって文言は異なる場合があります。エラーは手がかりであり、一般的なメッセージだけでサブスクリプションの期限切れと断定することはできません。
エラー：Failed to load subscription
原因と対処：サブスクリプションの読み込みに失敗したことを示す一般的なメッセージです。URLの認証、リクエストの失敗、返された内容の形式などが原因として考えられます。まず利用中のサービスにURLが有効か確認し、ネットワークに到達できるか、返された内容を解析できるかを分けて調べます。
エラー：The request timed out.
原因と対処：制限時間内にリクエストが完了しませんでした。現在のネットワーク、リクエスト経路、サブスクリプションサーバーの応答などが影響している可能性があります。Wi-Fiとモバイル通信でそれぞれ手動更新し、どちらか一方だけで失敗するか比較してください。
エラー：A server with the specified hostname could not be found.
原因と対処：サブスクリプションURLのホスト名を解決できませんでした。まずドメインがすべて正しくコピーされているか確認し、ネットワークを切り替えて再度試します。ドメインが変更されている場合は、利用中のサービスに現在のURLを確認してください。
原因1：URLが無効、または認証情報が変更された
サービス側で認証情報がリセットされると、古いURLがHomeに残っていても内容を取得できなくなる場合があります。HTTP 401または403が返された場合は、まず認証状態とアクセス制限を確認します。404の場合はパスが変更されていないか確認してください。これらのステータスだけで特定のアカウントの問題と断定せず、自分のサービス情報と照らし合わせて判断します。
- 利用中のサービスの管理画面からサブスクリプションURLをコピーし直し、端末に保存した値と一つずつ照合します。
- アカウントのトップページやログインページ、単一接続の共有テキストではなく、サブスクリプションURLをコピーしたことを確認します。
- URLを変更したら、対象のサブスクリプションだけを更新して結果を確認します。無効だと分かった古いURLを繰り返し試さないでください。
原因2：ネットワークに接続できない、またはリクエスト経路に問題がある
Wi-Fiでは失敗し、モバイル通信では成功する場合は、サブスクリプションをすぐに作り直すのではなく、まず2つのネットワーク環境の違いを確認してください。ネットワークを切り替えて結果を比較した後、現在の接続がリクエストに影響していないか調べます。Global RoutingのProxy、Direct、Config、Sceneはルーティングの状態を示します。変更によってネットワークへのアクセスが変わることはありますが、サブスクリプションの認証情報の有効性は変わりません。
- 一度に変更する条件は1つだけにします。たとえばサブスクリプションURLはそのままにして、Wi-Fiからモバイル通信に切り替えます。
- 現在の接続を有効にした場合と無効にした場合を比較するには、先に元の状態を記録し、テスト後に戻してください。
- 1回のタイムアウトを解消するために、DNS、ルーティング、すべての接続パラメーターを同時に変更しないでください。どの変更が影響したのか分からなくなります。
原因3：返された内容を解析できない
HTTP 200はリクエストへの成功応答を示すだけで、内容が有効な接続リストであるとは限りません。サーバーからログインページやメンテナンスのお知らせなど、別のテキストが返される場合があります。ブラウザーでページを表示できても、Shadowrocketがサブスクリプションとして解析できるとは限りません。
- 接続先が、手動でログインして読むウェブページではなく、Shadowrocketで利用できるサブスクリプション内容を提供していることを確認します。
- リクエストが完了しても項目が表示されない場合は、そのURLから返されるはずの項目数と内容の種類を利用中のサービスに確認してください。
- 内容全体に独自のエンコードを追加したり、項目を削除したり、プロトコル名を書き換えたりしないでください。元の問題が分かりにくくなり、接続情報を壊すおそれがあります。
更新後も変化がない：項目の内容を照合する
サブスクリプションの更新に成功しても、見た目がまったく変わらないことがあります。接続先で内容が変更されていなければ、名前や項目数はそのままです。一方、項目数が同じでも、サーバーアドレス、ポート、認証情報が変更されている可能性があります。リストの長さだけではなく、変更が分かっている項目を選んで確認してください。
| 表示された現象 | 確認すること | 次の手順 |
|---|---|---|
| 名前も項目数も変わらない | 接続先で実際に内容が変更されたか、正しいグループを見ているか | 変更が分かっている接続の項目を確認 |
| リストは変わったが、接続できない | 接続先の稼働状況、認証情報、現在のネットワーク | 接続のトラブル対処に進み、リストの更新を繰り返さない |
| 一部の項目だけ表示されない | 接続先から返された項目数、項目の形式、パラメーターがそろっているか | 表示されない項目が現在もサブスクリプションに含まれるか、利用中のサービスに確認 |
| アプリを開いても古い内容のまま | Update on Openの状態と今回のリクエストが完了したか | 手動で一度更新し、表示されたメッセージを記録 |
たとえば接続先から特定の接続のポートを443から8443に変更したと案内された場合は、名前だけでなく更新後のポートを確認します。ここに示した数値は確認方法の例であり、実在する接続に推奨するポートではありません。実際の設定値は、利用者がすでに持っている構成に合わせてください。
問い合わせ前に：状況を記録し、認証情報を隠す
上記の比較を行っても解決しない場合は、必要最小限のトラブル記録をまとめます。「内容を取得できない」のか「取得できても解析できない」のかを切り分けられる情報を残しつつ、アクセス可能なサブスクリプションURL全体を漏らさないようにしてください。認証情報はクエリパラメーターだけでなくパスに含まれる場合もあるため、tokenという名前の項目だけを隠しても不十分です。
- 実行方法：Homeで下にスワイプして更新した際に失敗するのか、Update on Openを有効にした後だけ変化が見られないのかを説明します。
- ネットワーク環境：Wi-Fiとモバイル通信それぞれの結果と、テスト時に接続を有効にしていたかを記録します。
- エラー表示：エラーメッセージ全文を記録し、HTTPステータスコードがあれば併記します。
- 影響範囲：すべてのサブスクリプションで失敗するのか、特定のグループだけか、一部の項目だけ表示されないのかを説明します。
- 個人情報の保護：サブスクリプションURL全体、パスワード、UUID、その他の認証情報を隠し、必要な状況説明だけを残します。