ClashのサブスクリプションURLが使えないときの対処法：解析失敗・更新エラーの確認手順

まず障害が発生している層を切り分ける

Clashクライアントがサブスクリプションを更新するときは、URLへの接続、リダイレクトの追跡、レスポンスのダウンロード、設定形式の判別、YAMLの解析、そしてプロキシノードとグループのローカル設定への保存を順番に行います。画面に表示される短い「更新失敗」というメッセージは、このどの段階でも表示される可能性があります。更新ボタンを何度も押すより、まず発生箇所を切り分けるほうが効果的です。

確認を始める前に、エラーが発生した正確な時刻、クライアントに表示された完全なエラーメッセージ、現在のネットワーク環境の3点を記録してください。可能であれば、自宅の固定回線からスマートフォンのテザリングへ切り替えるなど、ネットワークも一度変更します。最初からDNS、システムプロキシ、TUN、サブスクリプションURLを同時に変更すると、復旧してもどの操作が有効だったのか分からなくなります。

よくある症状と確認ポイント

画面に表示される症状	優先して確認する項目	主な原因
HTTP 401 または 403	サブスクリプションの権限、リクエストヘッダー	トークンの失効、サーバーが要求するUser-Agentとの不一致
HTTP 404 または 410	サブスクリプションURL	URLの取り消し、プラン変更後に旧URLが無効化
HTTP 429	更新頻度	短時間にリクエストを送りすぎてサーバーのレート制限にかかった
接続タイムアウト	ネットワーク、DNS、プロキシのループ	ドメインに接続できない、更新リクエストが無効なプロキシ経由になっている
YAMLの解析に失敗	レスポンス本文、形式	Webページ、JSON形式のエラー情報、またはインデントが崩れた設定をダウンロードしている
更新は成功したがノードが0件	サブスクリプションの内容、フィルター条件	空の設定、非対応形式、クライアントのフィルターですべてのノードを除外

サブスクリプションURL、ステータスコード、レスポンス内容を確認する

サブスクリプションURLには、アクセス用トークンが含まれていることがよくあります。トークンは、サブスクリプションのリセット、アカウント情報の変更、サービスの有効期限切れ、管理画面のセキュリティ設定などで変わる場合があります。URLをコピーするときに、空白や改行、チャットアプリが付けた句読点まで混ざることもあります。サービス提供元の管理画面から完全なURLをコピーし直し、プレーンテキストエディターに貼り付けて確認してください。

ブラウザーで開けても、クライアントで更新できるとは限らない

ブラウザーはCookie、ログイン状態、リダイレクトの一部を自動処理しますが、Clashクライアントが送るのは通常のHTTPリクエストヘッダーだけです。URLを開いてログインページ、認証ページ、プラン案内、HTMLが表示される場合、クライアントが受け取るのもプロキシ設定ではなくそれらのページである可能性があります。正常なレスポンスは通常、YAMLテキスト、Base64エンコードされたテキスト、またはクライアントが対応するサブスクリプション形式です。

macOS、Linux、またはcurlをインストール済みのWindows環境では、まずレスポンスヘッダーを確認できます。以下では例示用のドメインを使用しています。実際のサブスクリプショントークンを公開チャットやスクリーンショットに載せないでください。

curl -I -L --max-redirs 5 "https://sub.example.net/api/client/abc123"

-I はレスポンスヘッダーだけを取得し、-L はリダイレクトを追跡、--max-redirs 5 はリダイレクト回数を5回に制限します。最終ステータスコード、content-type、リダイレクトループの有無を確認してください。サブスクリプションサービスで正常なことが多いステータスは200です。301、302、307、308は移転に伴う正常な応答の場合もありますが、最終的には200に到達する必要があります。

ステータスコード別の対処法

401 Unauthorized：トークンが無効、またはURLに追加の認証情報が必要です。サブスクリプションURLを再生成し、古いURLを繰り返し試さないでください。
403 Forbidden：サーバーが現在のリクエストを拒否しています。クライアントの種類、アクセス元地域、リクエスト頻度が制限されている可能性があるため、User-Agentとアカウント状態を確認してください。
404 Not Found：パスが存在しません。コピー漏れ、URLの途中切れ、管理画面でのAPI変更がよくある原因です。
410 Gone：リソースが明示的に取り消されています。通常はURLを再生成してください。
429 Too Many Requests：リクエストが集中しています。10〜30分待ってから手動で一度だけ更新し、1分単位の自動更新は設定しないでください。
500、502、503、504：サーバーまたは上流ゲートウェイに問題があります。ネットワークの変更は原因の切り分けには使えますが、通常はサービスの復旧を待つ必要があります。

レスポンス本文を少量だけ確認したい場合は、ダウンロードサイズを制限して、ノード情報全体が端末の履歴に残らないようにしてください。より安全なのは、自分だけがアクセスできる一時ファイルに保存し、先頭部分を確認する方法です。

curl -L --max-time 20 \
  -A "Clash.Meta" \
  "https://sub.example.net/api/client/abc123" \
  -o subscription-check.txt

head -n 12 subscription-check.txt

先頭に <!doctype html>、<html>、認証ページの文言、またはJSON形式のエラーオブジェクトがある場合、ダウンロードしたものはClash設定ではありません。本文が英字、数字、プラス、スラッシュ、イコールだけで構成された長い1行なら、Base64形式のサブスクリプションである可能性があり、対応クライアントや変換処理が必要です。

User-Agentと形式の不一致を確認する

サブスクリプションAPIの中には、User-Agentに応じて異なる形式を返すものがあります。同じURLでも、ブラウザーにはWebページ、ClashにはYAML、別のクライアントには異なるエンコード形式を返す場合があります。クライアントのアップデート、mihomoコアへの移行、GUIの変更後にリクエストヘッダーが変わり、「旧クライアントでは更新できるのに新クライアントではエラーになる」ことがあります。

まずサービス提供元が指定するクライアント種別を使う

サブスクリプション管理画面にClash、Clash Meta、Mihomoなどのエクスポート項目がある場合は、対応する形式のURLを再生成するのが先決です。エクスポート項目によってはUser-Agentだけでなく、プロキシグループ、ノードのフィールド、ルール構造も変わります。クライアント側で名前だけを手動変更しても、サブスクリプション形式を選び直したことにはならない場合があります。

一部のクライアントでは、サブスクリプション編集画面からUser-Agentを設定できます。メニュー名はソフトによって異なりますが、一般的には「サブスクリプション」→「編集」→「上級設定」→「User-Agent」、または「設定」→「パラメータ設定」→「サブスクリプションリクエストヘッダー」です。サービス提供元が明示的に対応している値を、次のように順番に試してください。

Clash
Clash.Meta
mihomo

複数の値を一度に入力したり、根拠なくブラウザーのCookieを追加したりしないでください。変更後は保存して、手動で一度だけ更新します。サーバーが403を返していた状態から、サービス提供元指定のUser-Agentに変更して200へ戻ったなら、原因はほぼリクエストヘッダーの判定にあると考えられます。

Clash設定には完全な構造が必要

標準的な完全設定には、通常プロキシ、プロキシグループ、ルールなどが含まれます。最小構成は次のようになります。

mixed-port: 7890
mode: rule

proxies:
  - name: Example
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example
      - DIRECT

rules:
  - MATCH,PROXY

ダウンロードした内容が ss://、vmess:// などの共有リンクだけなら、それは汎用ノードサブスクリプションです。Clash YAMLだけを受け付けるインポート画面では、直接読み込めない場合があります。逆に、proxy-providers を含む完全設定を、単一のプロバイダーファイルとしてそのまま使うこともできません。インポート前に、入口が必要としているのが「完全設定」「ノードサブスクリプション」「プロキシコレクション」のどれかを確認してください。

YAML解析エラーで注意したい点

YAMLのインデントにはスペースを使います。Tabは解析エラーの原因になることがあります。
コロンの後には通常スペースが必要です。例：mode: rule。
ノード名にコロン、シャープ記号、特殊記号が含まれる場合、サーバー側で正しく引用符を付ける必要があります。
proxy-groups が参照するノード名は、proxies に記載された名前と一致していなければなりません。
旧版Clashが認識しないmihomo拡張フィールドは、フィールド検証エラーを引き起こす場合があります。クライアントを更新するか、互換性のあるエクスポート形式を選んでください。

ネットワークによるブロック、DNS、プロキシループを確認する

接続タイムアウト、TLSハンドシェイク失敗、ドメイン解決失敗が表示される場合、問題は通常、設定のダウンロード前に発生しています。YAMLを調整し続けても意味がないため、まずサブスクリプションドメインを解決できるか、HTTPS接続を確立できるか確認してください。

2つのネットワークで比較テストする

現在のWi-FiでClashのシステムプロキシとTUNを無効にし、直接一度更新します。
スマートフォンのテザリングに切り替え、もう一度更新します。
テザリングでは正常で元のネットワークだけ失敗する場合は、元のネットワークのDNS、ゲートウェイフィルター、IPv6経路を重点的に確認してください。
2つのネットワークで同じ403または404が返る場合、問題はローカルネットワークよりもURLまたはサーバー側にある可能性が高いです。

ドメイン解決を確認するときは、OS標準のツールを使えます。一般的なドメインは解決できるのにサブスクリプションドメインだけ失敗する場合は、ネットワーク環境で安定して使えるDNSサーバーに一時的に変更して再試行してください。変更前に元の値を記録し、テスト後に戻すか判断します。

nslookup sub.example.net

curl -v --connect-timeout 10 \
  "https://sub.example.net/api/client/abc123" \
  -o subscription-check.txt

curl -v は解決されたIP、TCP接続、TLSの過程を表示しますが、リクエストパスが出力されることもあるため、ログを公開転送しないでください。ドメイン解決で止まるならDNS、接続で止まるならネットワーク経路を確認します。TLSで証明書のドメイン不一致や期限切れが報告された場合は更新を中止してサーバー側の修正を待ち、クライアントで証明書検証を長期的に無効化しないでください。

サブスクリプション更新が無効なプロキシ経由にならないようにする

一部のクライアントでは、サブスクリプションのダウンロードに「プロキシを使用」できます。現在のノードがすでに使えないのに更新リクエストまでそのノード経由に固定されると、更新したいのに旧ノードが必要になる循環状態が発生します。サブスクリプション設定で「プロキシ経由で更新」を無効にするか、システムプロキシを一時的に終了して直接更新してください。

ローカルでよく使われる待受ポートには、HTTPポート7890、SOCKSポート7891、混合ポート7890、外部コントロールポート9090があります。ただし、これらはユーザーが変更できます。ターミナル環境に HTTP_PROXY、HTTPS_PROXY、ALL_PROXY が設定されていると、クライアント画面でシステムプロキシを無効にしても、curlがローカルポート経由で接続し続ける場合があります。

env | grep -i proxy

curl --noproxy "*" -I -L \
  "https://sub.example.net/api/client/abc123"

通常のcurlは失敗するのに --noproxy "*" を付けると成功する場合、問題はサブスクリプションURLではなくプロキシ経路にあります。Windows PowerShellでは、現在のセッションのプロキシ環境変数に加えて、「設定」→「ネットワークとインターネット」→「プロキシ」に手動プロキシが残っていないかも確認してください。

ローカルキャッシュを削除し、サブスクリプション記録を再構築する

URLとネットワークに問題がないのに、クライアントが古いノード、空の一覧、または決まった時刻のエラーを表示する場合、ローカルキャッシュの置き換えに失敗している可能性があります。設定ファイルが使用中、ディスク権限に問題がある、クライアントのクラッシュ後に書きかけのファイルが残っている、サブスクリプション記録に古いリクエストヘッダーが保存されている、といった原因が考えられます。

元に戻せる手順で処理する

現在使える設定をエクスポートし、カスタムルール、オーバーライド設定、プロキシグループの選択を記録します。
クライアントを完全に終了し、メニューバー、システムトレイ、バックグラウンドプロセスもすべて終了していることを確認します。
クライアントを再起動し、通常の方法で手動更新を一度行います。
それでも失敗する場合は、旧記録を上書きせず新しいサブスクリプション記録を作成し、再生成したURLを貼り付けます。
新しい記録の更新に成功したら、カスタムオーバーライドを移行してから旧記録を削除します。

アプリのデータディレクトリ全体を直接削除することはおすすめしません。多くのGUIクライアントは、サブスクリプションキャッシュ、実行設定、ログ、オーバーライドスクリプト、画面設定を同じ場所に保存しています。一括削除すると復旧の負担が大きくなります。まずはクライアントにある「設定」→「サブスクリプション」→「キャッシュを削除」または「設定を再構築」機能を使うのが安全です。その項目がない場合は、クライアントのドキュメントに従って該当するサブスクリプションキャッシュファイルだけを特定してください。

更新に成功したのにノードが表示されない

まず画面に表示された更新時刻が実際に変わっていることを確認し、次にサブスクリプション本文にノードが含まれているか確認します。元のレスポンスにはノードがあるのにクライアントが0件と表示する場合は、次の設定を確認してください。

ノード名フィルターの包含条件が狭すぎないか。
除外正規表現がすべてのノードに誤マッチしていないか。たとえば .* のように広すぎるパターンです。
サブスクリプションのオーバーライドが proxies を削除したり、プロキシグループを置き換えたりしていないか。
クライアントがプロバイダーだけを読み込み、メイン設定がそのプロバイダーを参照していない状態ではないか。
設定の切り替え先が、更新した新しい設定ではなく旧ファイルのままになっていないか。

mihomoのプロバイダー設定は、プロキシグループから参照する必要があります。proxy-providers を定義していても、どのプロキシグループにも対応する use が記述されていなければ、そのノードはグループに表示されません。

proxy-providers:
  airport:
    type: http
    url: "https://sub.example.net/provider.yaml"
    interval: 3600
    path: ./providers/airport.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport
    proxies:
      - DIRECT

interval: 3600 は3600秒ごとに確認する設定です。実際の更新間隔はサーバー側の制限に合わせて設定し、通常は数分おきに更新する必要はありません。更新頻度を上げてもノードが早く使えるようになるわけではなく、429のレート制限にもかかりやすくなります。

手順に沿って一度すべて確認する

エラー内容がはっきりしない場合は、次の固定手順で確認してください。各手順では変更する項目を1つだけにし、結果を記録します。最終的にサービス提供元へ問い合わせる場合も、十分に明確な情報を伝えられます。

旧設定を保存：まだ動作する設定とカスタムルールをエクスポートします。
URLをコピーし直す：アカウント管理画面からClashまたはmihomo用のサブスクリプションを生成します。
HTTPステータスを確認：最終レスポンスが200であり、ログインページ、エラーページ、リダイレクトループではないことを確認します。
レスポンス形式を確認：完全なYAML、プロバイダーファイル、Base64テキスト、Webページの内容を区別します。
User-Agentを調整：サービス提供元が明示的に対応しているClash、Clash.Meta、mihomoの識別子を使います。
旧プロキシを回避：「プロキシ経由で更新」を無効にし、7890、7891などのローカルポートと環境変数を確認します。
ネットワークを変更してテスト：スマートフォンのテザリングで、ローカルネットワークの障害とサーバー側の障害を切り分けます。
新しいサブスクリプション記録を作成：古いキャッシュ、リクエストヘッダー、オーバーライドの影響を避けます。
フィルターと参照を確認：ノードが正規表現で除外されておらず、プロバイダーがプロキシグループから参照されていることを確認します。
更新頻度を抑える：429が発生したらリクエストを停止し、自動更新は1時間単位に設定するのがおすすめです。

サービス提供元へ報告する場合は、発生時刻、最終HTTPステータスコード、クライアント名とバージョン、使用したUser-Agent、他のネットワークでも再現するかどうかを添えるとよいでしょう。サブスクリプションURLはドメイン名とAPIの種類だけを残し、トークン部分は隠してください。明確な情報があれば、「Clashを更新できない」とだけ伝えるよりも有効な対応を受けやすくなります。