この記事の要点

自分のサービス情報とサブスクリプション URL がある場合は、まず Home で手動更新し、URLへのアクセス、内容の解析、サーバーへの接続のどこでエラーが起きるかを確認します。その後、Settings → Subscribe で Update on Open を設定します。手動更新、起動時の自動更新、Update via Proxy の違いと、更新に失敗したときに既存のリストを残しておく理由を解説します。

サブスクリプションの更新とサーバー接続を区別する

Shadowrocketのサブスクリプション更新では、保存済みの URL にアクセスして内容を取得し、認識できたサーバー情報をリストに反映します。一方、Home の接続スイッチをオンにすると、選択中のサーバーに接続します。この2つは別の処理です。既存のサーバーが使えてもサブスクリプション URL が有効とは限らず、サブスクリプションを取得できても、含まれるすべてのサーバーに接続できるとは限りません。

この記事は、すでに自分のサブスクリプションをお持ちであることを前提としています。調査を始める前に、サブスクリプショングループ名、エラーの原文、発生時刻、使用中のネットワークを記録してください。個別に編集した項目がある場合は、必要な情報を先に保存しましょう。更新時にリモートの内容に基づいて項目が再構成されることがあるため、手動編集した内容が保持されるとは限りません。

2つの段階
サブスクリプション内容を取得 → 解析してリストを更新
401 / 403
HTTP認証またはアクセス権限に関するエラーの手がかり
443
HTTPSでポートを明示しない場合のデフォルトポート

ここでいうポートはサブスクリプション URL への HTTPS リクエストに使うもので、サーバー接続用のポートではありません。たとえば、URLがHTTPSのデフォルトポート443を使っていても、記載されたサーバーはサービス情報で指定された別のポートを使用できます。更新できないからといって、すべてのサーバーのポートを443に変更しないでください。

Homeでサブスクリプションを手動更新する

手動更新は、初回追加後の確認や、サービス情報が変更されたときの単発チェックに適しています。まず一度、処理が完了するまで確認してから次の手順に進みましょう。短時間に何度も下へ引っ張って更新するのは避けてください。リクエストを繰り返すと、サブスクリプション提供元のアクセス頻度制限にかかったり、複数回のエラーが混在して原因を特定しにくくなったりします。

  1. 項目を確認する

    Homeを開き、Subscribeタイプのサブスクリプションと対応するグループがあるか確認します。サーバーを手動で1件追加しただけで、リストにサブスクリプション URL がない場合、サーバー一覧全体を更新する元データはありません。

  2. URLを確認する

    対象のサブスクリプションの編集情報を開き、URLが完全か確認します。アカウントのログインページ、購入履歴ページ、単一サーバーの共有URIをサブスクリプション URL として使わないでください。また、スクリーンショットや公開記録に token 全体を表示しないでください。

  3. 下に引っ張って更新する

    Homeに戻り、リストを下に引っ張って更新を開始し、リクエストが完了するまで待ちます。サブスクリプションが複数ある場合は、グループごとに結果を確認してください。1つのグループに変化があっただけで、すべて更新できたと判断しないようにしましょう。

  4. 結果を確認する

    通知、グループの内容、想定した変更が反映されたかを確認します。サーバー数が変わらなくても、提供元から同じ内容が返された可能性があるため、更新失敗とは限りません。リストに変化があっても接続テストの代わりにはなりません。実際に使うサーバーを選び、アクセスできるか確認してください。

起動時に自動更新する:Update on Open

手動更新が成功したら、Settings → Subscribe → Update on Open に進み、アプリ起動時の更新をオンにします。この設定はアプリを開いたときにサブスクリプション更新を開始するもので、サーバーを継続的にポーリングしたり、決まった時刻に必ず実行されるバックグラウンドタイマーを設定したりするものではありません。

最初に動作を確認するときは、まず手動更新を成功させてから Update on Open をオンにします。アプリを終了して再度開き、更新結果を確認してください。別の画面からHomeに戻るだけでは、「起動時に更新」が実行されたと確実には判断できません。ネットワークの状態やアプリの実行状況によって、リクエストが完了しない場合もあります。

Settings → On Demand は接続を開始する条件を管理する設定で、サブスクリプション更新とは別です。On DemandをオンにしてもUpdate on Openはオンにならず、起動時の更新をオフにしても既存の接続条件は無効になりません。原因を調べる際は、この2つの設定を別々に記録し、同時に変更しないようにしてください。

タイムアウトやネットワーク制限:Update via Proxyを使う場合

まず現在のネットワークが使えることを確認し、次にサブスクリプションのドメインへ現在の経路からアクセスできるかを調べます。通常のWebページも開けない場合は、Wi-Fi認証、モバイル通信の利用許可、ネットワーク切り替えなどを先に確認してください。サブスクリプション URL へのリクエストだけがタイムアウトする場合は、すぐにURLを変更せず、アクセス経路の違いを確認します。

現在の直接接続ではサブスクリプション URL にアクセスできないものの、既存のサーバーは使える場合、まず接続を確立します。その後、Settings → Subscribe → Update via Proxy を開いてオンにし、Homeに戻って手動更新してください。この設定で変わるのはサブスクリプション更新リクエストのアクセス方法です。期限切れの認証情報、誤ったURL、非対応の応答内容を修復するものではありません。

確認できた状況まず行う操作判断できること
通常のWebページもサブスクリプションリクエストもタイムアウトする基本ネットワークを確認し、Wi-Fiまたはモバイル通信に切り替えて再試行するサブスクリプション URL が無効とは、まだ判断できない
直接接続では失敗するが、既存の接続は使える接続を確立してからUpdate via Proxyを試す成功しても、今回のリクエスト経路が使えたことを示すだけ
既存の接続を経由しても401が返る自分のサービス提供元にサブスクリプションの認証情報を確認する経路を変えても、通常は認証情報の問題は解決しない
既存のサーバーがすべて使えないまず基本ネットワークとサブスクリプション提供元の状態を確認する使えない接続を使ってプロキシ経由の更新を行うことはできない

結論:一度に変更する条件は1つにする

同じサブスクリプション URL のまま、まず基本ネットワークを切り替えて一度テストし、次にUpdate via Proxyだけを個別に試します。各結果を記録し、URL、接続モード、更新設定を同時に変更しないようにしてください。

Home → Global Routing のProxy、Direct、Config、Sceneは、通信の処理方法を選ぶためのもので、サブスクリプションの形式を表すものではありません。ConfigモードのDOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALなどのルールは、該当する通信の経路に影響します。ただし、ルールを手当たり次第に追加しても、無効になったtokenは復旧しません。ルールを確認する前に、今回のリクエストがどの経路を使ったかを特定してください。

エラー内容からURLの無効と形式の問題を見分ける

以下はネットワーク応答やシステムエラーに表示されることがある原文です。実際の画面にはステータスコード、短い説明、またはローカライズされた通知だけが表示される場合があります。今回の記録を基準に確認してください。ステータスコードは問題の種類を特定する手がかりですが、数字だけを根拠にアカウントの期限切れやサーバーの恒久停止と断定することはできません。

エラー:401 Unauthorized

原因:サブスクリプション提供元が受け付ける認証情報を含めずにリクエストしたためです。URL内のtokenが欠落している、無効になっている、または再設定されている可能性があります。

対処法:自分のサービス管理ページで現在のサブスクリプション URL を確認し、全体をコピーして古いURLと置き換えてから、手動更新してください。疑問符より前の部分だけをコピーしないようにしてください。

エラー:403 Forbidden

原因:サブスクリプション提供元が今回のリクエストを拒否しています。アカウント権限、アクセス元、サーバー側のポリシーが関係している可能性があります。

対処法:発生時刻とステータスコードを記録し、自分のサービス提供元にアクセス条件を確認してください。経路の変更は原因の切り分けには使えますが、権限の制限が解除されるとは限りません。

エラー:404 Not Found

原因:リクエスト先のパスが見つかりません。古い入口が無効になっている、URLのコピーが不完全、パスが誤って変更されている場合によく見られます。

対処法:ドメイン、パス、クエリパラメーターを確認し、自分のアカウントに表示されている現在有効なサブスクリプション URL を使ってください。新しいパスを推測して試すのは避けましょう。

エラー:The request timed out.

原因:制限時間内にリクエストが完了しませんでした。ネットワーク接続、サブスクリプション提供元の応答、中継するアクセス経路で発生する可能性があります。

対処法:まず基本ネットワークを確認し、前のセクションの手順に沿ってネットワークの切り替えとUpdate via Proxyを別々にテストします。タイムアウトだけでURLが期限切れと判断しないでください。

HTTPリクエスト自体は完了していても、返された内容を解析できない場合があります。ステータスコード200はHTTPレベルでリクエストが成功したことを示すだけで、本文が有効なサブスクリプションであるとは限りません。ログインページ、ネットワーク認証ページ、メンテナンスのお知らせ、HTML形式のエラーページも、200で返されることがあります。

URLの完全性と機密情報を確認する

サブスクリプション URL はアクセス認証情報を兼ねていることがあります。以下はURL構造の例であり、ドメイン名とtokenは実際には使えません。トラブルの確認時に自分のURLの構造と比較することはできますが、実際のリンクを公開ページやスクリーンショットに載せないでください。

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

トラブルの記録には通常、グループ名、時刻、ネットワークの種類、エラーの原文、Update via Proxyがオンかどうかがあれば十分です。自分のサービス提供元に問い合わせる場合は、既存のサポート窓口を使い、まず機密情報を伏せた内容を送ってください。リクエストログを確認できるかどうかは、提供元の実際の機能によります。

よくある質問:更新後のリストと自動更新の動作

自動更新をオンにしたのに、起動後もリストが古いままなのはなぜ?

まずHomeで手動更新し、リクエストが成功するか確認します。次にSettings → SubscribeでUpdate on Openの設定を確認してください。手動更新も失敗する場合は、URLまたはネットワークの問題を先に解決します。提供元から同じ内容が返された場合は、更新が成功していてもリストに目立った変化がないことがあります。

サブスクリプションは更新できたのに、選択中のサーバーが使えないのはなぜ?

更新で確認できるのは、サブスクリプションの内容を取得して解析できたことだけです。Homeに戻って選択中のサーバーを確認し、Global Routingと既存のサービスパラメーターを確認してから、実際にアクセスできるかテストしてください。「更新成功」は、すべてのサーバーが利用可能であることを示すものではありません。

更新に失敗したら、元のサブスクリプションを削除して追加し直すべき?

まず元の項目を残し、URLとエラーの原文を確認してください。削除すると比較に必要な情報が失われ、タイムアウトや権限の問題も解決しません。URLを置き換える必要がある場合は、グループ名と必要な設定を記録してから既存のサブスクリプションを編集し、何度も追加してリストが重複しないようにしてください。

複数のサブスクリプションのうち、1つのグループだけ更新に失敗する場合は?

失敗したグループのURLと応答ステータスを個別に確認してください。ほかのサブスクリプションが更新できても、一部のリクエストにアクセスできたことが分かるだけで、そのドメイン、パス、tokenが有効とは限りません。それを理由にすべてのグループの設定を一括変更しないでください。

Shadowrocketを購入すると、サブスクリプションも自動で使えるようになりますか?

アプリの買い切り購入と接続サービスの契約は別です。ShadowrocketはApp Storeで入手するクローズドソースの商用アプリです。サブスクリプションの内容は、ユーザーがすでに利用しているサービス情報から取得します。アプリの購入とサブスクリプション URL の有効性は、それぞれ別に確認してください。