この記事の概要

Shadowrocketでサブスクリプションを更新してノードが表示されない場合は、まず既存の記録を残し、「リクエスト失敗」「応答内容の不一致」「リストに表示されない」の3つに切り分けます。利用者自身がサービス提供元とサブスクリプションを用意していることを前提に、URL、応答、ネットワーク、更新タイミングを順に確認し、最後に条件を絞って更新結果を検証します。

1. リストが空なのか、更新が完了していないのかを確認する

サブスクリプションの更新はいくつかの段階で行われます。アプリが保存済みのURLを読み取り、サブスクリプションのアドレスにリクエストを送信し、応答を受け取って、認識できたノード情報をHomeに表示します。どこかの段階で問題が起きると「新しいノードがない」ように見えますが、対処方法は原因によって異なります。サブスクリプション全体をすぐに削除したり、接続スイッチの状態だけで更新成功と判断したりしないでください。

URLを読み込む サブスクリプションにリクエスト 応答を受信 記録を解析 リストを表示
  1. Homeに戻り、検索を終了して該当するサブスクリプショングループを展開します。検索条件やグループの折りたたみが原因で空に見えていないか確認してください。
  2. 今回の更新でエラーが表示されたか、以前のノードが残っているか、空なのが1つのグループだけか全グループかを記録します。
  3. 操作対象を確認します。Configでは設定とルールを管理します。この記事で確認するのはHomeのサブスクリプションノード一覧です。設定ファイルの更新はノードサブスクリプションの更新とは異なります。
  4. サブスクリプション名と元のURLを、他人に見られない場所にバックアップしてください。接続できるノードがある場合は、唯一の有効なテスト手段を失わないよう、先に残しておきます。

「以前のリストは残っているが、新しい項目が追加されない」場合は、更新が完了していないか、リモート側の内容に変更がない可能性があります。「更新後に一部のグループが空になった」場合は、応答内容とアカウントの状態を重点的に確認します。「すべてのリストが見えない」場合は、まずHomeの表示範囲を確認してください。これらは次の確認箇所を決める手がかりであり、それだけで障害の原因が確定するわけではありません。

2. 完全なURLを確認する:アカウントページをサブスクリプションURLと取り違えない

サブスクリプションURLは、アプリが設定内容を取得するためのアドレスです。アカウントのトップページ、注文ページ、ブラウザーのログインページとは異なります。利用しているサービス提供元のアカウントからShadowrocket用のサブスクリプションURLをコピーし、アプリに保存されている値と一文字ずつ照合してください。URLが長く見えても完全とは限りません。クエリパラメーターの一部が欠けただけで認証に失敗することがあります。

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

以下は接続に使えない形式の例です。https://はアクセス方式、example.comは例示用ドメイン、/subは例示用パス、token=xxxxは架空の認証値です。実際のサービスではパス、パラメーター名、認証方式が異なる場合があります。この例をもとに、保存済みのURLを手作業で書き換えないでください。

3. 応答内容を確認する:ページが開けてもノードを解析できるとは限らない

ブラウザーでページを開けたとしても、確認できるのはブラウザーから該当ページにアクセスできたことだけです。ブラウザーにログインCookieが残っていたり、本人確認ページが表示されていたりする場合もあります。Shadowrocketがサブスクリプションを取得するとき、ブラウザーと同じセッション条件が利用できるとは限りません。HTTPステータスが200 OKでも、応答内容がログインページ、エラー説明、または空の本文であることがあります。

200
HTTPリクエストが成功していても、本文に解析可能な記録が含まれるか確認する
401 / 403
認証情報とサーバー側のアクセス制限をそれぞれ確認する
429
リクエスト頻度に制限がある場合は、サーバーの案内に従って待ってから再試行する

結論:まず応答内容を確認し、その後で解析に関する設定を見直す

ログインページや空の本文が返ってきた場合、ノードのプロトコルを切り替えても不足している記録は補えません。まず利用しているサービス提供元に、サブスクリプションのエンドポイントからShadowrocketで使える有効な内容が返されているか確認してください。

以下はリクエストの詳細、サーバーの記録、エラーメッセージなどに表示される可能性がある標準的なHTTPステータスです。アプリ内で毎回同じ形式で表示されるとは限りません。実際に確認できるステータスを基準にし、「リストが空」という現象だけからステータスコードを推測しないでください。

HTTP 401 Unauthorized

原因と対処:有効な認証情報がリクエストに含まれていない場合は、利用中のアカウントから現在有効な完全なサブスクリプションURLをコピーし直し、tokenがリセットされていないか確認します。

HTTP 403 Forbidden

原因と対処:サーバーが現在のリクエストを拒否している場合は、アカウントの権限とエンドポイントのアクセス要件を確認し、利用しているサービス提供元にアクセス制限を調べてもらいます。何度も更新して解決しようとしないでください。

HTTP 404 Not Found

原因と対処:指定したパスが存在しない、または変更されている場合は、古いURLをコピーしていないか、パスの一部が抜けていないか確認し、アカウントに現在表示されているサブスクリプションURLを使います。

HTTP 429 Too Many Requests

原因と対処:リクエストが頻度制限に達した場合は、連続で更新するのをやめます。応答にRetry-Afterが含まれていれば指定された時間だけ待ち、含まれていなければ利用しているサービス提供元に再試行までの間隔を確認してください。

サービス提供元が応答に記録を含むことを確認したにもかかわらず、アプリで解析できない場合は、出力形式も確認します。サブスクリプションは任意のテキストファイルではありません。ノード一覧、完全な設定ファイル、Webページでは構造が異なります。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardもそれぞれパラメーター構造が異なるため、名前を1つ変えても、形式が合わない内容を有効なサブスクリプションにはできません。

4. 更新経路を確認する:直接接続とUpdate via Proxyを分けて検証

ノード接続に使う通信経路と、サブスクリプションURLの取得に使う経路は分けて確認する必要があります。ノードに接続できても、サブスクリプションのドメインにアクセスできるとは限りません。サブスクリプションを更新できても、含まれるすべてのノードが接続できるとは限りません。まず現在のネットワークで一度更新して結果を記録し、次に条件を1つだけ変えて再試行してください。ネットワーク、URL、設定を同時に変更すると、原因を特定できなくなります。

  1. ネットワーク接続を確認:Wi-FiでWeb認証が必要な場合は、先に認証を完了してください。システムの日付と時刻も正しく設定します。時刻が間違っているとHTTPS証明書の検証に影響することがあります。
  2. 更新方法を確認:Settings → Subscribeを開き、Update via Proxyを確認します。関連項目の表示はアプリ内の実際の画面に従ってください。
  3. プロキシ経由の更新をテスト:利用可能なノードがあり、接続が確立されている場合に限り、Update via Proxyを有効にしてテストしてください。リストが空の状態から、使えるプロキシが自動的に得られるわけではありません。
  4. 別のネットワークでテスト:可能であればモバイル通信または別の信頼できるWi-Fiに切り替え、同じサブスクリプションを一度だけ更新して、同じエラーが出るか比較します。
  5. 不要な変更を元に戻す:テスト後は、結果を説明するために必要な設定だけ残します。サブスクリプション更新のために、関係のないルーティング変更を恒常的に残さないでください。

Global RoutingのProxy、Direct、Config、Sceneは接続やルーティングの選択に関する機能であり、無効なtokenや空の応答を修復するものではありません。On Demandは条件に応じて接続を開始するための機能で、サブスクリプション内容を生成するスイッチではありません。Global RoutingやSettings → On Demandの変更を、あらゆるサブスクリプションエラーに対する共通の解決策と考えないでください。

5. アカウントの状態と更新タイミングを確認してから、一度だけ更新する

tokenをリセットした直後、アカウント権限を変更した直後、またはサーバーのメンテナンス中は、サブスクリプションの内容がまだ用意されていない場合があります。サーバーが新しいリストを生成するタイミングはクライアント側では決められず、「更新処理が終了した」ことだけでアカウントに利用可能な記録があるとは判断できません。利用中のアカウントの状態と、サービス提供元から確認した情報を基準にしてください。一律の待ち時間は設定できません。

問い合わせを行う場合は、「発生時刻、ネットワークの種類、Update via Proxyの有効・無効、実際のエラー、以前のリストが残っているか、アカウントに最近変更があったか」をまとめると、再確認しやすくなります。PrivateKey、パスワード、完全なtokenは共有しないでください。トラブル対処に必要なのは現象と条件であり、認証情報の公開ではありません。

6. サブスクリプションが空になるときによくある質問

更新後にすべて空になりました。先にサブスクリプションを削除して追加し直すべきですか?

最初の手順としてはおすすめしません。まず検索を終了してグループを展開し、保存済みURLと更新エラーを確認してください。元のURLをバックアップし、リモート側から有効な内容が返されていることを確認できた場合に限り、ローカルの記録の問題を切り分けるために再追加を検討します。削除してもサーバーから空の応答が返る問題は直りません。

同じURLをブラウザーで開けるのに、アプリにノードが表示されないのはなぜですか?

ブラウザーに表示されているのがノード情報かアカウントページかを確認し、ログインセッションに依存していないか調べます。利用しているサービス提供元に、アプリのリクエストで実際に返された本文と出力形式を確認してもらってください。ブラウザーのページが読み込めたことだけでは、有効性を判断できません。

以前のノードには接続できていますが、サブスクリプションの更新がタイムアウトします。どうすればよいですか?

Settings → SubscribeでUpdate via Proxyを確認し、現在の接続自体が利用できることも確認します。更新方法かネットワークのどちらか一方だけを変更して試してください。別の経路でもタイムアウトする場合は時刻を記録し、サブスクリプションのエンドポイントの状態を確認します。

ノードは復旧しましたが、Connectivity Testはまだ失敗します。解析に失敗したのでしょうか?

リストに記録が表示されているなら、少なくとも何らかの内容は解析されています。次にノードのアドレス、ポート、認証パラメーター、ネットワークからの到達性を確認してください。接続エラーをサブスクリプションが空であることに結び付けたり、ポートをすべて443に変更したりしないでください。

Shadowrocketを購入したのに、ノードが自動で表示されないのはなぜですか?

クライアントの買い切り購入と接続サービスの契約は別です。Shadowrocketはクローズドソースの商用アプリで、App Storeでの購入によりアプリを利用できます。この記事のサブスクリプションの追加とトラブル対処は、利用者自身がサービス提供元とサブスクリプションを用意していることを前提としています。