Shadowrocketのサブスクリプションを解析できない・ノードが表示されない場合の確認方法｜リンク形式・提供元・更新タイミング

この記事の概要

現在のサブスクリプションは削除せず、「リンク、アクセス、応答内容、アカウント状態、更新タイミング」の順に確認しましょう。最初からすべてのノードを削除する必要はありません。この記事は、ご自身で利用中のサービスとサブスクリプションをお持ちのShadowrocketユーザー向けです。iPhone / iPadのHomeを例に説明します。Mac、Windows、Android、Linuxでも同じ順序で確認できますが、操作画面の位置は各プラットフォームの現行UIをご確認ください。

1. 解析エラー・空の一覧・接続エラーを区別する

Shadowrocketのサブスクリプション更新では、まずサーバーからコンテンツを取得し、そこからノードのパラメーターを読み取ります。リクエストのタイムアウト、ログインページや空の内容の返却、ノード情報の解析失敗は、それぞれ異なる段階で起きる問題です。「更新に失敗した」という表示だけでは原因を特定できず、既存のノードが使えるかどうかも判断できません。

リンクを読み取るサブスクリプションをリクエストする応答を受信するノードを解析する一覧に表示する

表示された状況	まず確認すること	すぐに行わないこと
更新がタイムアウトしたが、以前のノードは残っている	現在のネットワークからサブスクリプションURLにアクセスできるか	まだ使えるサブスクリプションを削除する
応答を受信した後に解析エラーが表示される	返されたのはサブスクリプションデータか、Webページやエラーページか	UUID、パスワード、プロトコルをむやみに変更する
サブスクリプショングループはあるが、ノードが空	提供元でのノード割り当て、応答内容、一覧の絞り込み	空の一覧をそのままローカル設定の破損と決めつける
ノードは表示されるが接続できない	ノードのパラメーター、ネットワーク、接続テストの結果	接続状況を調べず、同じサブスクリプションを何度も追加する

まずHomeで対象のサブスクリプショングループを表示していることを確認し、検索条件をクリアして折りたたまれたグループを展開します。ノード名が見えている場合、ノードデータは少なくとも取得済みなので、「一覧が空」の問題として扱う必要はありません。Configのルール設定とHomeのノードサブスクリプションは用途が異なります。ルール設定ファイルを追加しても、ノードサブスクリプションのインポートにはなりません。

2. サブスクリプションURLを確認する：再インポートよりURLの完全性が重要

ご自身が利用しているサービスのアカウントページから、Shadowrocket用のサブスクリプションURLをコピーし、保存済みのURLと一つずつ照合します。ブラウザーのアドレスバーに表示されたアカウントページのURLや、ページ内の説明文・ボタン名・ログイン後の転送先をサブスクリプションURLとして使わないでください。以下はURLの構造例であり、実際のインポートには使えません。

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

先頭を確認します。たとえば https:// のように、プロトコル部分が欠けていないか確認してください。コロンやスラッシュを省略しないでください。URLの前後に引用符、日本語の括弧、説明文を付けないでください。
末尾を確認します。?以降のクエリパラメーターがすべて含まれているか確認してください。メッセージのプレビューに表示される省略記号はURLの一部ではありません。プレビューカードからコピーするとtokenが欠けることがあります。
パラメーターはそのまま保持します。&はクエリパラメーターの区切り文字で、%2Fなどはエンコードされた文字列です。自分でデコードしたり、順序を入れ替えたり、不要に見える文字を削除したりしないでください。
コピー元を確認します。アカウントページに用意されたコピー機能を使ってください。貼り付けたURLに改行がある場合は、もう一度コピーして確認します。画面上の自動折り返しと、実際の改行を混同しないでください。
URLの用途を確認します。単一ノードの共有情報、ルール設定用リンク、サブスクリプションURLは、それぞれ別の入力形式です。拡張子だけで判断せず、提供元が指定する用途に従ってインポートしてください。

サービス提供元でサブスクリプションの認証情報がリセットされていると、URLの形式が正しくても古いURLは使えない場合があります。サブスクリプションの表示名だけでなく、保存済みのURLを新しいものに更新してください。トラブル対処のためにtokenを何度もリセットするのは避けましょう。同じURLを使うほかの端末にも影響することがあります。

3. 応答内容を確認し、アクセスの問題とコンテンツの問題を切り分ける

「ブラウザーで開ける」ことが示すのは、ブラウザーが何らかの応答を受け取ったということだけです。その応答をShadowrocketが解析できるとは限りません。ブラウザーにはログイン済みのCookieが保存されている場合がありますが、サブスクリプションのリクエストはブラウザーのログイン状態に依存できません。ログインページ、認証画面、メンテナンスのお知らせが表示されても、それはノードデータではありません。

443

HTTPSでポートを指定しない場合のデフォルトポート

401

HTTPステータス：有効な認証情報が不足しています

403

HTTPステータス：サーバーがリクエストを拒否しました

以下は、応答や診断情報に表示される可能性がある標準的なHTTPステータスです。各プラットフォームで同じ文言のポップアップが表示されるとは限りません。該当するステータスを実際に確認した場合に限り、その項目に沿って対処してください。「一覧が空」というだけで、サーバーが特定のステータスコードを返したと決めつけないでください。

HTTP 401 Unauthorized

原因と対処：有効な認証情報を含まないリクエストです。tokenが無効になっている可能性があります。アカウントページでサブスクリプションURLを確認し、ご自身のサービス提供元に認証情報の状態を問い合わせてください。

HTTP 403 Forbidden

原因と対処：サーバーがアクセスを拒否しています。アクセス方針やアカウント権限が関係している可能性があります。発生時刻と使用中のネットワークを記録し、サービス提供元に確認してください。ノードのパスワードを変更して解決しようとしないでください。

HTTP 404 Not Found

原因と対処：指定されたパスが存在しないか、対象のリソースが提供されていません。現在のアカウントページに表示されているURLをコピーし直し、パスが途中で切れていないか、移転されていないか確認してください。

HTTP 429 Too Many Requests

原因と対処：リクエスト頻度が制限されています。連続で更新するのをやめ、サービス提供元の案内または応答に含まれるRetry-Afterなどを確認し、指定された時間が経過してから一度だけ更新してください。

HTTP 200でも解析成功が保証されるわけではありません。HTML形式のエラー説明や空の本文が返されることもあります。応答を確認できる場合は、サービス提供元がクライアント向けに用意したサブスクリプション内容かどうかを確認してください。HTMLページ全体をAdd Serverに貼り付けないでください。エンコードされた文字列が表示されても、形式を確認せずにデコードして元のサブスクリプションを上書きするのは避けてください。

要点：まず返された内容を確認し、その後でクライアントの設定を見直す

同じURLからログインページ、メンテナンスページ、空の内容が返る場合は、サブスクリプションのインターフェースについてサービス提供元に確認してください。この段階でGlobal Routingを切り替えたりConfigのルールを変更したりしても、Webページがノードデータに変わることはありません。

4. サービス提供元側の確認：有効期限・使用量・ノード割り当て

アカウントにログインできることと、サブスクリプションが利用できることは別の条件です。利用期間、データ使用量の上限、アカウントの状態、ノードの割り当てがサブスクリプションの内容に影響する場合があります。対処方法はサービス提供元によって異なり、空の一覧、案内メッセージ、リクエストの拒否など、応答もさまざまです。表示だけを根拠にアカウントの期限切れと判断しないでください。

有効期限：アカウント登録状態だけでなく、サービスの利用権が有効か確認してください。更新手続きの直後は、アカウントページに反映されているかも確認します。
データ使用量：現在の期間に使えるデータが残っているか、リセット待ちの状態ではないか確認してください。利用再開の具体的な時刻は、ご自身のサービス提供元の案内をご確認ください。
ノードの割り当て：アカウントにノードが割り当てられているか、すべてのノードを除外するエクスポートの絞り込み条件が有効になっていないか確認してください。
エクスポート形式：アカウントページにクライアント形式の選択肢がある場合は、Shadowrocket用と明記された形式を選んでください。別の用途向けの設定ファイルを名前だけ変更してインポートしないでください。
メンテナンス状況：アカウントページにメンテナンス情報が掲載されていないか確認してください。インターフェースの一時的な障害を理由にShadowrocketを再インストールする必要はありません。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはそれぞれ異なるプロトコルです。サブスクリプション内のパラメーターは、対応するプロトコルに合っている必要があります。解析に失敗しても、表示させるためにプロトコルを別の種類へ変更しないでください。ポート、TLS、認証フィールドを推測して手動で変更するより、エクスポート内容がクライアントに対応しているかサービス提供元に確認する方が確実です。

5. 更新タイミングとネットワーク：変更する条件は一度に一つ

更新手続き、URLのリセット、ノード割り当ての変更後は、上流側の同期が完了していない場合があります。すべてのサービス提供元に共通する待ち時間はありません。アカウントページの状態とサービス提供元の案内を確認してください。何度も更新しても同期は早まりません。リクエスト頻度の制限を招き、元の問題と新たな制限が重なってしまうことがあります。

現在の状態を記録します。更新時刻、エラーの全文、ノードが残っているか、Wi-Fiとモバイルネットワークのどちらを使っていたかを記録してください。利用できる内容を先に消さないでください。
ネットワークへの接続を完了します。Wi-FiでWeb認証が必要な場合は、認証を完了してからHomeに戻り、サブスクリプションを更新してください。認証ページが表示されると、サブスクリプションのリクエストに想定外の内容が返ることがあります。
一度だけ手動で更新します。Homeで対象のサブスクリプションを更新します。下に引っ張って更新を実行し、対象グループに反映されたか確認してください。接続スイッチの状態だけで判断しないでください。
ネットワークを切り替えて再試行します。可能であればWi-Fiからモバイルネットワークへ、またはその逆に切り替えます。ネットワークとの関連を判断できるよう、サブスクリプションURLは変更しないでください。
結果に応じて対処します。特定のネットワークでのみ失敗する場合は、まずそのネットワークのアクセス条件を確認してください。異なるネットワークでも同じ権限エラーやコンテンツエラーが返る場合は、ご自身のサービス提供元に問い合わせてください。

「更新するには先に接続を有効にする必要がある」と一律に考えないでください。サブスクリプションにアクセスできるかは、ネットワークや関連設定によって異なります。現在のノードが使えない場合、そのノード経由でサブスクリプションにアクセスしようとすると、解決できないループになることがあります。Global RoutingのConfig、Proxy、Direct、Sceneはルーティング方法であり、サブスクリプション形式を修復する設定ではありません。ルーティング条件をテストする場合は、一度に一つの設定だけ変更し、元の値を記録して、テスト後に戻してください。

Settings → On Demandは、条件に応じた接続を制御する機能であり、サブスクリプション内容を生成するものではありません。空の一覧を調べるためにOn Demandを何度も切り替えると、確認すべき条件が増えてしまいます。設定はそのままにし、まずリンクと応答内容を確認してください。自動更新では無効になったtokenを修復できません。手動更新が成功したことを確認してから、その後の自動更新結果を確認しましょう。

6. よくある質問と問い合わせ時の記録

ブラウザーではサブスクリプションを開けるのに、なぜ解析に失敗するのですか？

表示されているのがサブスクリプションデータであり、ログインページやお知らせページではないことを確認してください。ブラウザーのログイン状態によって、インターフェースの権限に関する問題が隠れている場合があります。ご自身のアカウントページからクライアント用のサブスクリプションURLをコピーし直し、Homeで一度更新してください。

更新手続き直後なのに、ノードが表示されないのはなぜですか？

まずアカウントページで利用権が有効になっていることと、ノードが割り当てられていることを確認し、サービス提供元の案内に従って同期を待ちます。待機中に同じサブスクリプションを何度も追加しないでください。更新後に、どのグループを確認すべきか分かりにくくなります。

ほかの端末にはノードがあるのに、この端末にはありません。再インストールが必要ですか？

まず2台の端末でサブスクリプションURL、更新時刻、検索フィルターを照合してください。もう一方の端末には古いキャッシュが表示されている可能性があり、現在のインターフェースが正常だとは限りません。両方の端末でそれぞれ更新し、結果を記録してから端末間の違いを判断してください。

再インポートする前に、古いサブスクリプションを削除すべきですか？

古いサブスクリプションと、引き続き使えるノードはそのまま残してください。新しいURLをテストする必要がある場合は、区別できる名前を付けて追加し、更新結果を確認します。新しいサブスクリプションが正常で、残す必要のあるローカル変更もないことを確認してから、重複項目を整理してください。

原因を特定できない場合は、認証情報を含まない記録を作成して、ご自身のサービス提供元に問い合わせてください。「使えなくなった」という説明だけでなく、再現に役立つ情報を添えると、確認のやり取りを減らせます。サブスクリプションのQRコード全体や、個人アカウントを特定できるスクリーンショットは添付しないでください。

端末とOSの種類、問題がWi-Fi、モバイルネットワーク、または両方で起きるか。
問題が発生した時刻とタイムゾーン、最後に更新が成功したおおよその時刻。
エラーメッセージの原文または実際のHTTPステータス、Webページや空の内容が返されたか。
アカウントの利用権が有効か、tokenを変更したか、エクスポート形式を変更したか。
実施した操作とそれぞれの結果。例：「同じURLでネットワークを切り替えても403が返る」。