サブスクリプションを解析できないときの対処法：リンク切れ・形式不一致・ネットワークの確認

ダウンロード失敗と解析失敗を切り分ける

サブスクリプションのインポートは通常、リンクへのリクエスト、応答の受信、設定の解析、設定の読み込みという4段階で進みます。画面に表示される「更新失敗」は、どの段階でも起こり得ます。失敗した段階を特定して初めて、リンクの更新、リクエスト方法の変更、設定構造の確認のどれが必要か判断できます。

まず現在使える設定を残し、失敗したサブスクリプションを手動で一度更新します。クライアントの「ログ」画面を開き、操作時刻、HTTPステータスコード、最初のエラーを記録してください。メニュー名はクライアントによって異なります。接続速度の測定結果ではなく、サブスクリプション更新のログを確認することが重要です。

ログの内容	該当する段階	優先して確認する項目
`no such host`	ドメイン名の解決	サブスクリプションのドメイン名が正しいか、現在のDNSが利用できるか
`timeout` または `connection refused`	接続の確立または応答の読み込み	ネットワーク経路、プロキシポート、サーバーへの接続可否
HTTP 401、403、404、410	サーバーの応答	認証、アクセス制限、リンクが差し替えられていないか
`yaml:` と行番号	応答内容の解析	応答が設定ファイルかどうか、インデントとデータ型
`proxy not found`	設定内の参照関係	プロキシグループ、ノード、ルールの参照先の名前が一致しているか

リンクの期限切れとアカウントの状態

サブスクリプションURLをコピーし直す

サービス提供元のアカウントページから、Mihomo用のサブスクリプションURLをコピーし直してください。アカウントのログインページ、購入ページ、ブラウザーのアドレス欄に表示された管理画面のURLを、サブスクリプションURLと取り違えないようにします。コピー後、空白、改行、日本語の句読点が混入していないか確認し、? 以降のパラメーターがチャットアプリで途切れていないかも確かめてください。

401：通常、有効な認証情報がありません。リンクのトークンとアカウントの状態を確認してください。
403：認証拒否のほか、リクエストヘッダー、地域、IP、セキュリティ制限などが原因の可能性もあります。ステータスコードだけでサブスクリプションの期限切れとは判断できません。
404 または 410：接続先の移転、リンクの無効化、リソースの削除が考えられます。アカウントページで確認してください。
429：リクエストが多すぎる状態です。応答にある Retry-After などに従って待ち、更新ボタンを連続して押さないでください。
5xx：まずサーバー側の状態を確認し、時間をおいて再試行してください。ローカル設定を大幅に変更するのはその後にしましょう。

通信量の上限到達、プランの期限切れ、トークンの無効化はそれぞれ別の状態です。サービスによっては、401を返さず空の一覧や説明文を返すこともあります。「リクエスト成功」と表示されるだけで判断せず、応答本文とアカウントの状態をあわせて確認してください。

ブラウザーで確認する際の注意点

信頼できる端末でサブスクリプションリンクを直接開くと、ログイン画面、エラー画面、ファイルのダウンロードなどを確認できます。ただし、ブラウザーはログインCookieを送信する場合があり、クライアントとは異なるUser-Agentを使うこともあります。ブラウザーでダウンロードできても、クライアントが同じ内容を取得できるとは限りません。ブラウザー上で文字化けしていても、設定ファイルが壊れているとは限りません。

リンクを開くとログインフォームや認証画面が表示される場合は、専用のサブスクリプションURLをコピーしたか確認してください。ページを .yaml として保存してインポートするのは避けましょう。ブラウザーでの確認は閲覧履歴に残るため、共有端末では特に注意してください。

HTTP応答と実際の本文を確認する

拡張子だけでは内容を判断できません。config.yaml という名前でも、応答本文がHTMLの場合があります。HTTP 200でも「サブスクリプションは無効です」というメッセージが返ることがあります。ステータスコード、リダイレクト、本文の冒頭をあわせて確認してください。

curlで比較用の結果を保存する

以下のコマンドは、curlをインストールしたmacOSまたはLinuxのBash端末で使えます。リンクを入力しても画面には表示されず、コマンド履歴にも直接記録されません。ただし、リクエストの実行中は、展開されたURLを適切な権限を持つローカルプロセスから確認できる場合があります。出力ファイルにも認証情報が含まれる可能性があるため、ローカルにのみ保存してください。

read -r -s -p 'サブスクリプションURL：' SUB_URL
printf '\n'
curl --location --max-redirs 5 \
  --connect-timeout 10 --max-time 30 \
  --dump-header subscription-headers.txt \
  --output subscription-response.txt \
  --write-out 'HTTP %{http_code}\n' \
  "$SUB_URL"
unset SUB_URL

接続タイムアウトを10秒、リクエスト全体の上限を30秒、リダイレクトの追跡回数を最大5回に設定しています。これらは調査用の値であり、サービスの性能を測定した結果ではありません。証明書の検証を無効にする -k や、認証情報をリダイレクト先にも送る --location-trusted は使わないでください。

端末に表示されたcurlのエラーと、最終的なHTTPステータスを確認します。HTTP応答を受信する前に接続が失敗すると、000 と表示されることがあります。これはサーバーのステータスコードではありません。
subscription-headers.txt を確認してください。リダイレクトを追跡した場合、ファイルに複数のレスポンスヘッダーが含まれることがあります。最後のヘッダーを確認します。
ローカルのテキストエディターで subscription-response.txt を開き、冒頭が設定項目、エンコードされたノード一覧、HTML、エラーメッセージのどれか確認してください。
リダイレクト先のドメインがサービス提供元の指定したものか確認してください。Cookieやトークン付きURLが含まれる可能性があるため、レスポンスヘッダーを公開しないでください。

Content-Type は手がかりであり、最終的な判定基準ではありません。YAMLが text/plain として返されても、正常に使えるサービスがあります。一方、レスポンスヘッダーにYAMLと記載されていても、本文の構文や構造が正しいとは限りません。

完全な設定、ノード一覧、エンコード済みサブスクリプションを見分ける

「応答がYAML形式である」ことを確認しただけでは、チェックは半分しか終わっていません。Mihomoの完全な設定、proxy-providers で使うノード一覧、URIやBase64形式のノードサブスクリプションは、それぞれ異なる入力です。こうした内容をクライアントが変換できるかどうかは実装によって異なり、すべてのクライアントが自動変換に対応しているわけではありません。

内容の特徴	一般的な用途	よくある誤用
プロキシの情報、プロキシグループ、ルールを含む	完全な設定として読み込む	存在しないノードやプロキシグループを参照する
`proxies:` を中心としたノード一覧	`proxy-providers` から参照する	すべてのプロキシグループとルールが含まれていると思い込む
`ss://`、`vmess://` などの複数行リンク、またはそのエンコード文字列	対応形式を扱えるインポーターで変換する	そのままコアのYAML設定として読み込む
`<!DOCTYPE html>` または `<html>`	Webページまたはアクセス制限の応答	拡張子をYAMLに変えて直そうとする

YAMLの行番号とフィールドの型

ログに18行目と表示されても、原因が18行目そのものにあるとは限りません。前の行のコロンが抜けていたり、引用符が閉じていなかったりすると、次の行でエラーになることがあります。エラー行の前後を少なくとも3行確認し、インデントにはスペースを使ってTabが混ざらないようにしてください。

# 構造の例。ネットワークに接続できる完全な設定ではありません
proxies: []
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選択

この例はリストとインデントの構造を確認するためのもので、プロキシノードは含みません。実際の設定では、ルールの参照先、プロキシグループ名、ノード名が完全に一致している必要があります。日本語の句読点、末尾の空白、大文字と小文字の違いでも、参照先が見つからないことがあります。

構文エラーとコアの対応状況を切り分ける

YAMLの構文が正しくても、現在のコアがそのプロトコル、通信方式、フィールドに対応しているとは限りません。まずクライアントの「バージョン情報」またはコア情報の画面で、実際のコアのバージョンを確認し、そのバージョンの対応範囲と照らし合わせてください。クライアントのバージョンとコアのバージョンは別のものです。

さらに詳しく調べるには、アクセスを制限したディレクトリに設定全体を保存し、ローカルのMihomoで mihomo -t -f config.yaml を実行して設定をテストできます。この操作は、ネットワークへの接続可否を確認するものではありません。外部リソースを使う場合は、リソース読み込みのログも確認してください。内容を確認していない設定で、いきなりサービスを起動しないでください。

User-Agentとサブスクリプションの応答形式

サブスクリプションサービスによっては、User-Agentに応じて返す設定を切り替えます。同じURLでも、ブラウザーには説明ページ、クライアントにはYAMLが返る場合や、その逆の場合があります。まずサービス提供元がMihomo用として案内しているサブスクリプションURLを使いましょう。リクエストヘッダーを手当たり次第に変更するのは避けてください。

同じURL、同じネットワーク、近い時間帯でテストし、User-Agentだけを変更してください。複数の条件を同時に変えないようにします。
まずクライアントのログで確認できるリクエスト情報を記録し、サービス提供元のドキュメントで指定されたUser-Agentを調べてください。
curlの --user-agent で条件を比較します。2回の結果をそれぞれ保存し、ステータスコードと本文の構造を比べてください。
結果を確認したうえで、クライアントにサブスクリプションのリクエスト専用ヘッダーを設定できるか確認してください。ブラウザーの設定だけを変更しても解決しません。

サービス提供元がその識別子に対応していると明記している場合は、たとえば --user-agent 'clash.meta' を試せます。これはすべてのサブスクリプションサービスで使える解決策ではなく、現在のコアに対応した設定が返る保証もありません。ログイン画面や403が返り続ける場合は、識別子を変え続けるのではなく、認証とネットワークの制限を確認してください。

ネットワーク、DNS、プロキシ経由の更新経路

ブラウザーでは開けるのにクライアントがタイムアウトする

まず、リクエストが同じ経路を通っているか確認してください。ブラウザーはシステムプロキシを使っていても、サブスクリプション更新機能は直接接続、内蔵プロキシ、個別設定されたダウンロード経路を使う場合があります。システムプロキシを有効にしても、すべてのプロセスが自動で利用するとは限りません。

クライアントに「プロキシ経由でサブスクリプションを更新」などの設定がある場合は、まず現在のプロキシが使えるか確認してください。サブスクリプションが無効でノードにも接続できない状態で、古いノード経由の更新を強制すると、依存関係が循環することがあります。復元できる設定を残し、サービス提供元がサポートする方法で別のネットワーク経路を試してください。

DNS：no such host が出たら、ドメイン名の綴りとシステムの名前解決を確認してください。変動する可能性のあるサービスのIPアドレスを固定で設定するのは避けましょう。
プロキシポート：ローカルHTTPプロキシに 127.0.0.1:7890 を設定している場合、クライアントが実際にそのポートで待ち受けているか確認してください。7890は例であり、すべてのクライアントの既定値ではありません。
TUN：TUNを有効にすると、プロセスの通信経路が変わることがありますが、誤ったYAMLは修正できません。切り替える前に現在の設定を記録し、テスト後は元に戻して、異なる原因を混同しないようにしてください。
TLS：証明書エラーが出る場合は、システムの日付と時刻、タイムゾーン、サブスクリプションのドメイン名、ネットワークの認証ページを確認してください。証明書の検証を無効にしないでください。

別のネットワークでも比較する

可能であれば、スマートフォンのテザリングと元のネットワークで、それぞれ一度リクエストしてください。リンクとUser-Agentは変えないでください。一方のネットワークでだけHTMLのブロック画面や接続タイムアウトが発生するなら、ネットワーク経路を重点的に調べます。両方で同じ形式エラーが安定して返るなら、サブスクリプションの内容とクライアントの互換性に戻って確認してください。

curlの --noproxy '*' はcurlで明示的に指定したプロキシを使わないようにできますが、システムのTUN、ルーティングルール、ネットワーク出口の機器は回避できません。このオプションを使っても失敗するからといって、直接接続の経路に問題があるとは限りません。

インポートを復旧し、問い合わせに必要な情報を整理する

変更後は手動で一度更新し、設定の解析が完了したことを確認してから、新しい設定で接続をテストしてください。サブスクリプションの更新成功は、内容を受信して処理できたことを示すだけです。すべてのノードが使えることや、DNS、システムプロキシ、ルールによる振り分けの設定が完了していることを意味しません。

サブスクリプションの更新日時、ノード数、想定したプロキシグループがあるかを確認します。
読み込みログを確認し、未対応のノード種別、プロバイダーのダウンロード失敗、ルールの参照先不足などのエラーがないか調べます。
接続可能と分かっているテスト先にアクセスし、接続ログで適用されたルール、プロキシグループ、通信の出口を確認します。
以前の設定に戻せる状態を保ち、新しい設定が安定してから一時的な応答ファイルを削除してください。

解決しない場合に共有する情報

クライアントの開発者やサブスクリプションの提供元に問い合わせる際は、OS、クライアントのバージョン、コアのバージョン、失敗した時刻、HTTPステータスコード、機密情報を伏せた最初のエラー、直接接続とプロキシ経由の更新結果を添えてください。形式の問題なら、インデントを保った最小限の設定例を共有できます。サブスクリプションURL全体やノードの認証情報は送らないでください。

確認は、まずリンクと認証情報、次に応答本文、その後に形式とコアの対応状況、最後にリクエストヘッダーとネットワーク経路の順に進めます。一度に変更する条件は一つに絞ってください。「たまたま成功した」という誤判断を減らせるうえ、次回の更新時にも同じ問題を再現して対処しやすくなります。