Shadowrocketのサブスクリプションを追加できない・一覧が空になる場合の確認方法

この記事の概要

この記事は、自分で契約したサービスとサブスクリプションがあり、Shadowrocketで追加できない、または更新後にサーバーが表示されない場合の確認手順を説明します。URLの状態、リクエスト結果、応答内容、再登録の順に切り分けます。まず既存の設定を残し、比較できる形で一度更新して、アクセス失敗・応答内容が空・接続失敗を混同しないようにしましょう。

追加失敗・一覧が空・接続失敗を切り分ける

Subscribeは指定したURLからデータを取得し、認識できるサーバー設定を一覧に追加する機能です。サブスクリプション項目を保存できても、有効なデータを取得できたとは限りません。一覧にサーバーが表示されても、接続できるとは限りません。まずどの段階で止まっているかを見極めてから該当する設定を確認すると、一覧を何度も削除するより原因を追いやすくなります。

URLを読み取るリクエストを送信データを取得設定を解析一覧に表示

保存時に先へ進めない：TypeがSubscribeになっているか、URLが完全か、ページタイトルまでURL欄に貼り付けていないかを確認します。
更新時に失敗する：ネットワーク、ドメイン名の解決、HTTPS証明書、サーバーの応答を確認します。この段階では、まずサーバーのポートやプロトコルを変更しないでください。
更新は完了したが一覧が空：応答に現在利用できるサーバー設定が実際に含まれているか確認し、サブスクリプションのグループが折りたたまれていないか、一覧の絞り込みが有効になっていないかも確認します。
サーバーは表示されるが接続できない：サブスクリプションの解析段階は通過しています。サーバーの設定値、利用可能な状態かどうか、実際の接続ログを確認してください。

Homeではサーバーと接続状態を確認し、Configでは構成ファイルを管理し、Settingsではアプリの設定を行います。Subscribeのリクエスト失敗を直すために、先にConfigを空にしないでください。対象が異なります。また、Global Routingの変更を一般的な解決策として扱うこともできません。サブスクリプション更新の通信経路は、関連設定や現在のネットワーク環境にも左右されます。

SubscribeのURLを確認し、元の文字列を保つ

サブスクリプションURLには、通常ドメイン名、パス、クエリパラメータが含まれます。クエリパラメータ内のtokenはアクセス認証情報にあたるため、1文字欠けるだけで別のリクエストになる場合があります。契約先のサブスクリプションページから直接コピーしてください。チャットのプレビューや画像からの文字認識、途中が省略されたアドレス欄の表示をもとに組み立てないでください。

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

以下は実際の接続には使えない例です。形式の説明にのみ使用しています。https://はアクセス方式、example.comは例示用ドメイン、/subは例示用パス、token=xxxxは例示用パラメータです。実際のURLではパスやパラメータ名が異なる場合があります。契約先が提供する文字列をそのまま使用し、例に合わせて実際のURLを書き換えないでください。

443

HTTPSでポート番号を明示しない場合に使われる既定のポート

URLのパスとクエリを区切る記号

クエリ内の複数のパラメータを区切る一般的な記号

先頭や末尾に空白、改行、日本語の引用符、説明文が含まれていないか確認します。URL内部の大文字・小文字やエンコードは変更しないでください。
クエリパラメータ内の&を削除しないでください。また、%2Fなどのパーセントエンコードを手動でデコードしないでください。認証情報の照合に使われている場合があります。
通常のログインページ、アカウント管理ページ、サブスクリプション用のエンドポイントは、それぞれ別のURLです。ウェブページを開けても、そのページにアクセスできたことしか確認できません。
単一サーバーのURIとSubscribe用URLも別物です。コピーしたものがサブスクリプションの入口であり、個別サーバーの共有情報ではないことを確認してください。

要点：URLをコピーし直して比較する

URLが途中で切れている可能性がある場合は、自分のアカウントから完全なURLをコピーし直し、古い項目を残して比較します。記憶を頼りにtokenを補完したり、完全なURLを公開の掲示板やオンライン診断ツールに送信したりしないでください。

リクエスト結果からネットワークとサーバーの問題を切り分ける

HTTPエラー応答を受け取った場合と、応答そのものが届かない場合では、対処が異なります。以下には標準的なHTTPステータスの説明を掲載しています。診断情報やサービス提供元の応答記録と照合するためのものです。Shadowrocket上の表示は異なる場合があり、画面に英語の文言が完全一致で表示されるとは限りません。ステータスコードがない場合は、認証情報の期限切れと決めつけず、アプリに実際に表示されたメッセージを記録してください。

HTTP 401 Unauthorized

原因と対処：サーバーが現在の認証情報を受け付けていません。URLが完全か、認証情報がリセットされていないか確認し、自分のアカウントから現在有効なサブスクリプションURLをコピーし直してください。

HTTP 403 Forbidden

原因と対処：サーバーが今回のアクセスを拒否しましたが、ステータスコードだけで原因は特定できません。アカウントの権限、アクセス制限、セキュリティによるブロックについて契約先に確認し、認証情報を伏せたエラー記録を伝えてください。

HTTP 404 Not Found

原因と対処：リクエスト先のパスが見つかりません。サーバーがリソースの存在を隠すためにこの応答を返す場合もあります。まずドメイン名とパスを照合し、サブスクリプション用エンドポイントが変更されていないか確認してください。tokenだけを差し替えて試し続けないでください。

HTTP 429 Too Many Requests

原因と対処：リクエスト回数の制限に達しています。連続して更新するのはやめてください。応答にRetry-Afterが含まれていれば、指定された時間または間隔に従って再試行します。記載がない場合は、契約先の案内に従って待ってください。

HTTP 503 Service Unavailable

原因と対処：サーバーが一時的にリクエストを処理できません。既存の設定を残し、サーバーの状態と復旧予定を確認してください。サブスクリプションを何度削除して作り直しても、サーバー側の障害は解消しません。

タイムアウト、ドメイン名の解決失敗、TLSの検証エラーが発生する場合は、まずiPhoneまたはiPadの現在のネットワークで通常のHTTPS通信ができることを確認します。その後、Wi-Fiとモバイル通信を個別に切り替えて比較してください。変更するのは一度にネットワークだけにし、結果を記録します。証明書エラーが出た場合は、システムの日付と時刻も確認してください。証明書の検証を無効にして回避しないでください。

成功応答なのに空の場合は、ステータスだけでなく内容を確認

HTTP 200はHTTPレベルでリクエストが成功したことを示しますが、本文がShadowrocketで読み取れるサブスクリプション形式であることまでは保証しません。ログインページ、期限切れの案内、安全確認ページもHTTP 200を返すことがあります。これらはウェブページのテキストであり、そのまま読み込めるサーバー一覧ではありません。ブラウザにページが表示されても、サブスクリプションが正常だとは判断できません。

確認できた結果	問題が起きている可能性のある段階	次の手順
ログインページまたは安全確認ページが返る	期待するサブスクリプションの本文を取得できていない	サブスクリプション専用のエンドポイントを使っているか確認し、アクセス要件を契約先に確認する
応答本文に内容がない	サーバーがサーバー設定を出力していない	アカウントの状態と、現在のサブスクリプションに項目が含まれる想定かを確認する
内容はあるが形式が一致しない	返された形式と読み込み画面が一致していない	契約先がShadowrocketに対応したサブスクリプション形式を提供しているか確認する
項目はあるがメイン一覧が展開されていない	一覧の表示状態	Homeで該当するグループを展開し、絞り込み条件を確認する

アカウントの期限切れ、権限の変更、サーバーメンテナンス、サブスクリプションの生成未完了などが応答内容に影響する場合があります。しかし、一覧が空というだけでは原因を特定できません。自分のアカウントページで状態を確認し、このURLから現時点で有効な設定が何件返される想定か、契約先に問い合わせてください。アカウントページに表示されたプラン名だけでは、有効なサブスクリプションが生成済みとは判断できません。

プロトコル名とサブスクリプションの形式は分けて考えてください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続設定に関係するプロトコルまたはトンネル方式です。これらの名称を含むテキストなら何でもSubscribeで解析できる、という意味ではありません。エンコードされた内容を書き換えたり、プロトコルの項目を自分で組み合わせたりしないでください。パラメータの手入力が必要な場合は、該当する画面で必要な値をすべて入力してください。

要点：HTTP 200と有効な項目は別々に確認する

リクエストは成功したのに項目がない場合は、まずサーバーが認識可能な内容を実際に返しているか確認し、その後でアプリの一覧表示を確認します。この場合、DOMAIN-SUFFIXやFINALなどのルールを変更しても、空の本文がサーバー設定に変わることはありません。

現在の設定を残して、手順に沿って一度だけ再登録する

再登録は、URLのコピー間違いや、保存済みURLが無効になっていないかを確認するために行います。失敗するたびに最初に行う操作ではありません。始める前に、元のサブスクリプション名と項目数を記録してください。利用できる設定がある場合は残し、Homeの一覧全体を削除しないでください。画面レイアウトには多少の違いがある場合があるため、同じ英語の項目名を目印に操作します。

現在の状態を記録する

Homeで元のサブスクリプショングループを確認し、表示されているサーバー数と直近の更新結果を記録します。元の項目を残し、確認中にConfigやサーバー設定を同時に変更しないでください。
URLをコピーする

契約先のアカウントページから、完全なサブスクリプションURLをコピーし直します。認証情報をリセットした直後なら、新しいURLを使い、古いURLが無効になっているかも確認してください。
種類を選ぶ

Home → 右上の「+」→ Type → Subscribeの順に開きます。追加画面に戻ったら、URL欄にリンクを貼り付けます。今回のテストと元の項目を区別できる名前を付けてください。
保存して更新する

保存したらHomeに戻り、下に引っ張って更新を開始します。今回のリクエストが完了するまで待ち、実際に表示されたメッセージを記録してください。処理中に何度も更新しないでください。サブスクリプションが複数ある場合は、どの項目が失敗したかを確認します。
一覧を確認する

新しいサブスクリプショングループを展開し、サーバーが表示されるか、何件あるかを確認します。新しい項目の動作が確認できてから重複を整理してください。新旧の項目がどちらも失敗する場合は、エラー記録を残してネットワークまたはサーバーを調べます。

新しいURLでは読み込めて古いURLでは失敗する場合は、保存されたURLと認証情報の状態を優先して比較します。どちらの項目にもサーバーが表示されるのに接続できない場合は、サブスクリプションの確認を切り上げ、選択中のサーバーを別途調べてください。遅延テストの失敗を、Subscribeの解析失敗として記録しないでください。

更新のタイミングと結果の記録

サブスクリプションを更新するとサーバーに再度リクエストを送信しますが、期限切れのアカウント権限が回復したり、リクエスト回数の制限がすぐ解除されたりするわけではありません。認証情報のリセット、権限の回復、内容の変更後は、サーバー側で反映が完了したことを確認してから手動で一度更新してください。自動更新の有効状態や実行タイミングは、設定とシステムの動作条件に左右されます。アプリを開いたからといって、更新が成功したとは限りません。

アカウントの状態が変わった直後：契約先にサブスクリプションの内容が生成済みか確認してから、もう一度更新します。数分待てば必ず反映されると決めつけないでください。
ネットワークを切り替えた直後：ネットワーク接続が確立してから再試行します。Wi-Fiとモバイル通信それぞれの結果を記録し、URLとネットワークを同時に変更して比較できなくなるのを避けてください。
リクエスト制限に達した場合：頻繁な再試行をやめ、Retry-Afterまたは契約先が案内する待機時間に従ってください。
更新後に項目数が減った場合：まずサーバー側で返される項目が変更されたか確認し、古い記録を残すか判断します。すぐにアプリがデータを失ったと決めつけないでください。

問い合わせ時に伝える情報

有効な問い合わせには、操作を再現できる情報と認証情報の保護が必要です。発生時刻、使用したネットワーク、読み込みに使った画面、更新前後の項目数、実際に表示されたエラー文を契約先に伝えてください。記録に完全なURLが含まれる場合は、token、アカウント識別情報、その他の認証パラメータを隠してください。サブスクリプションの本文、サーバーのパスワード、QRコードは送らないでください。

入口：Home → + → Type → Subscribe
操作：保存してHomeに戻り、下に引っ張って一度更新
状況：元の項目は残っているが、新しいサブスクリプショングループにサーバーが表示されない
比較：Wi-Fiとモバイル通信での更新結果をそれぞれ記録
エラー：実際に表示されたメッセージを記録し、状況からステータスコードを推測しない
プライバシー：問い合わせ資料からURLの認証情報とアカウント情報を隠す

最後に、結果を3段階で整理します。リクエストが完了しない場合はネットワークとエンドポイントを確認します。リクエストは完了したが有効な項目がない場合は、応答内容とアカウントの状態を確認します。項目が表示されても接続できない場合は、サーバー設定と接続過程を確認します。一度に一つの段階を調べることで、設定の誤削除を防ぎ、次の問い合わせにも明確な根拠を残せます。