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

この記事の概要

自分で利用しているサービス提供元とサブスクリプションがあるものの、Shadowrocketにノード一覧が表示されない場合の確認手順です。「URLの完全性、リクエスト結果、応答形式、サービス提供元の状態、更新時のネットワーク環境」の順に確認し、取得エラー・解析エラー・接続エラーを切り分けます。既存の設定を残したうえで一度ずつ検証し、削除や更新を繰り返して原因が分からなくなるのを防ぎましょう。

1. サブスクリプションの取得エラーとノードの接続エラーを区別する

ShadowrocketはAppleプラットフォーム向けの有料アプリで、入手先はApp Storeのみです。開発元はShadow Launch Technology Limitedで、買い切り方式です。アプリを購入しても接続サービスが付属するわけではありません。この記事では、利用者自身がサービス提供元とサブスクリプションを用意していることを前提に説明します。対応デバイスとシステム要件はApp Storeの表示をご確認ください。

サブスクリプションの更新は、サーバー情報を取得して解析するためのものです。すべてのサーバーに接続できるかを検証するものではありません。Homeに項目がまったく表示されない場合と、一覧には表示されるものの接続がタイムアウトする場合では、原因が異なります。前者ではサブスクリプションURLと応答内容を確認し、後者ではサーバーアドレス、ポート、認証情報、ネットワークへの到達性を調べます。

サブスクリプションURLを読み込むネットワークリクエストを送信する応答を受信するサーバー項目を解析するノード一覧を表示する

処理フローのどこかで問題が起きると、更新エラーや一覧に項目が追加されない状態になります。HTTPリクエストが成功しても、サーバーから解析可能なサブスクリプションが返されたとは限りません。逆に、以前の項目が残っていても、今回の更新が成功した証拠にはなりません。

初回追加時から空の場合：貼り付けたURL、サブスクリプション形式、サービス提供元から実際に返された項目数を重点的に確認します。
以前は使えていたのに更新後に問題が起きた場合：認証情報のリセット、サブスクリプションの利用資格の変更、サービス提供元のAPIメンテナンスを確認します。
項目は表示されるが接続できない場合：更新を繰り返さず、該当サーバーの接続エラーを確認します。

2. URLが完全か確認し、エンコードを手動で変更しない

Shadowrocketで使うサブスクリプションURLは、自分のサービス提供元のアカウントページからコピーしてください。アカウントのトップページ、注文ページ、ボタンに表示された短い名称をコピーしないでください。サブスクリプションURLには認証情報が含まれることが多く、見た目が似たURLでも、一方はアカウントページ、もう一方はサーバーデータを返すなど、用途が異なる場合があります。

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

上記は使用できない形式の例です。実際のURLを確認する際は、https://から末尾まで欠けていないか、特に?以降のクエリパラメーターを確認します。チャットで転送すると、末尾の句読点や改行が混入したり、URLが途中で切れたりすることがあります。記憶を頼りに補うのではなく、元のページからコピーし直してください。

空白を確認：URLの前後にスペースがなく、途中に実際の改行が含まれていないことを確認します。テキスト欄で自動的に折り返されても、URLに改行が挿入されたとは限りません。
大文字・小文字を保持：ドメイン以外のパス、パラメーター名、認証情報は大文字と小文字を区別する場合があります。一律に変換しないでください。
エンコードを保持：%2B、%2F、%3Dは認証情報の一部である可能性があります。手動でデコードしたり、再度エンコードしたりしないでください。
HTMLエスケープに注意：ウェブページのソースにある&は、そのまま貼り付けるパラメーター区切り文字ではありません。サービス提供元のコピー機能を使ってください。
URLの種類を区別：個別サーバーの共有情報とサブスクリプションURLは別の入力形式です。すべての情報をSubscribeとして追加しないでください。

3. 画面の手順に沿ってインポートを再確認する

Shadowrocketでは、Homeでサーバーを確認・管理し、Configで設定ファイルを扱い、Settingsでアプリを設定します。サブスクリプションURLはHomeでSubscribeとして追加してください。Configファイルとして読み込んでも、サーバーサブスクリプションの解析の代わりにはなりません。確認を始める前に、既存サブスクリプションの名前、現在の項目数、エラーメッセージを記録し、すべての内容を削除しないでください。

既存の項目を残す

Homeで、元のサブスクリプションと既存の項目が残っていることを確認します。現在の接続がこれらの項目に依存している場合は、まず現状を維持し、削除して作り直すことから始めないでください。
Subscribeを選択する

Homeを開き、右上の「+」をタップして、TypeでSubscribeを選択します。見分けやすい名前を入力し、自分でコピーした完全なサブスクリプションURLをURL欄に貼り付けます。
保存して更新する

保存後にHomeへ戻り、画面を下に引いて更新を実行し、リクエストが完了するまで待ちます。成功・失敗や項目数の変化を記録し、リクエストの処理中に続けて更新しないでください。
一覧の表示を確認する

Homeの検索条件を解除し、該当するサブスクリプショングループを展開して、フィルターや折りたたみが原因で一覧が空に見えていないか確認します。名前に変化がない場合も、項目数を照らし合わせてください。
次の段階の問題を切り分ける

サーバー項目が表示された場合、サブスクリプションの解析で結果を取得できています。次は接続を個別に確認し、接続タイムアウトを「サブスクリプションが空」と混同しないようにします。

サービス提供元によって既存のサブスクリプションURLがリセットされた場合は、同じ名前のグループを複数残すのではなく、該当するサブスクリプションに保存されたURLを変更してください。並行してテストする必要がある場合は、テスト用の項目に分かりやすい名前を付け、終了後に整理します。古い一覧を新しい結果と取り違えないためです。

4. HTTPステータスと応答内容から原因を特定する

リクエストの詳細を確認できる場合は、まずステータスコードを記録し、次に応答内容を確認します。以下は一般的なHTTPステータスの説明であり、Shadowrocketがあらゆる状況で同じ文言を表示するとは限りません。実際のエラー詳細やサービス提供元の記録に該当するステータスがある場合に限り、その項目に沿って対応してください。ステータスコードを調べるために、完全な認証情報を第三者のウェブサイトに送信しないでください。

200

HTTPリクエストが成功していても、本文の形式を確認する

401 / 403

認証情報とアクセス権を優先して確認する

429

リクエストが制限された場合は、更新を繰り返さない

HTTP 401 Unauthorized

原因：有効な認証情報がない、またはサブスクリプションの認証情報が無効になっています。対処：利用中のサービス提供元のアカウントページで現在のURLを確認し、必要に応じて認証情報を再発行してから、保存済みのURLを更新します。

HTTP 403 Forbidden

原因：サーバーが現在のリクエストを拒否しています。アカウント権限やアクセス制限が関係している可能性があります。対処：利用中のサービス提供元に、リクエストの時刻を伝えて拒否理由を確認してください。403をすべて有効期限切れと決めつけないでください。

HTTP 404 Not Found

原因：リクエスト先のパスが存在しない可能性があります。URLの欠落やAPIパスの変更が考えられます。対処：現在使用しているサブスクリプションURLをコピーし直し、パスとクエリパラメーターを確認してください。API名を推測して入力しないでください。

HTTP 429 Too Many Requests

原因：サーバーがリクエスト頻度を制限しています。対処：画面を下に引いて更新する操作を繰り返さないでください。応答にRetry-Afterが含まれる場合は指定時間を待ち、含まれない場合は利用中のサービス提供元に復旧時刻を確認します。

判断のポイント：200でもサブスクリプションが有効とは限らない

サービス提供元から、応答がログインページ、認証ページ、エラー説明のいずれかだと確認できた場合は、アクセス先と権限を先に修正してからサブスクリプションを更新します。この場合、サーバーのプロトコル設定を何度変更しても解析エラーは解決しません。

本文が空でなくても、案内文だけ、空のデータセット、または現在の入力先が対応していない形式の可能性があります。Base64は単なるエンコード方式であり、有効なサーバー情報が含まれているとは限りません。本文全体に文字を追加したり、何度もデコードしたり、プロトコルのプレフィックスをつなげたりしないでください。応答形式と実際に有効な項目数をサービス提供元に確認してください。

5. 利用中のサービス提供元に資格と応答形式を確認する

アカウントにログインできても、サブスクリプションのAPIが現在サーバー情報を返すとは限りません。利用資格、データ通信量の状態、有効期限、メンテナンス、認証情報のリセットなどが応答に影響する可能性があります。支払い後や更新後も、何度も更新するのではなく、まずアカウントに反映されていることを確認してください。

利用資格を確認：該当サービスがアカウントで有効か、通信量の制限や一時停止がないか、状態の同期が完了しているかを確認します。
認証情報を確認：最近サブスクリプションURLをリセットしていないか、Homeに古いtokenが保存されたままではないか確認します。
応答本文を確認：APIがサーバーデータを返しているのか、ログインページ、認証ページ、エラー説明、または項目数が0の結果を返しているのか確認します。
形式を確認：Shadowrocketで使える現在のサブスクリプション形式を取得してください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロトコル名です。名前だけを変更しても形式変換が完了したことにはなりません。
変更内容を確認：APIのドメイン、パス、証明書、応答形式に変更があったか、サービス提供元側で生成結果の修正が必要かを確認します。

問い合わせる際は、エラーの原文、発生日時とタイムゾーン、使用したネットワーク、初回追加かどうかに加え、「既存の項目が残っているか、更新前後で項目数が変化したか」を伝えてください。「使えない」とだけ伝えるより原因を特定しやすくなります。スクリーンショットを撮る前に、サブスクリプションURL全体、token、サーバーパスワード、その他の認証情報を隠してください。アカウントの確認が必要な場合は、利用中のサービス提供元の非公開サポート窓口を使います。

6. ネットワークと更新タイミングの影響を除外して、最後に再確認する

サブスクリプションの取得にもネットワークが必要です。ドメインの名前解決エラー、TLS証明書の異常、接続タイムアウト、ログインが必要なWi-Fiなどによって、応答本文を取得できないことがあります。まずデバイスの日付と時刻が正しいこと、現在のネットワークで必要なログインが済んでいることを確認してから、一度更新してください。証明書エラーが発生した場合はデバイスの時刻を確認し、サービス提供元に証明書を調べてもらいます。セキュリティ検証を無効にして解決しようとしないでください。

Global Routingは接続トラフィックの処理方法を決める機能であり、誤ったサブスクリプション形式を修正するものではありません。Settings → On Demandはオンデマンド接続の動作を制御するもので、サブスクリプション更新のスイッチではありません。テストのために接続を一時停止する場合は、先に元の設定を記録し、On Demandによって接続が再開されないか確認してください。トラブルシューティング後は元の状態に戻します。

入力条件を固定：確認済みの同じサブスクリプションURLを使い、現在の時刻とHomeの項目数を記録します。
リクエストを一度完了：現在のネットワークで一度更新し、結果が確定するまで待ちます。URL、接続設定、ネットワークを同時に変更すると、どの変更が影響したのか判断しにくくなります。
ネットワークだけを変更：可能であれば、Wi-Fiからモバイル通信へ、またはその逆に切り替えてもう一度テストします。特定のネットワークだけで失敗する場合は、まずそのネットワークの名前解決とアクセス条件を確認してください。
頻度制限を回避：リクエスト制限やメンテナンスの通知が表示された場合は、サービス提供元が案内する時刻まで待ってから再試行し、短い間隔での自動更新は設定しないでください。
結果を確認：サブスクリプショングループに想定した項目が表示されることを確認してから、サーバー接続を個別にテストします。引き続き空の場合は、2回のテスト時刻とエラー結果を添えて利用中のサービス提供元に問い合わせてください。

原因を絞り込むには、条件を一度に一つだけ変更する

URLを変えずにネットワークだけ切り替えて成功した場合は、まずネットワーク経路を調べます。どちらのネットワークでも同じ認証エラーが返る場合は、アカウントと認証情報を確認します。有効な一覧を取得できても接続できない場合は、サーバー接続のトラブルシューティングに進みます。

最終的に、問題を「URLの欠落」「リクエスト未到達」「アクセス拒否」「本文形式の不一致」「サーバー接続エラー」のいずれかに切り分けます。この順番で対応すれば、まだ使える設定を残しつつ、サービス提供元から返された内容の問題をアプリのインストール問題と取り違えずに済みます。