Clashのサブスクリプション更新に失敗したら？よくある原因と自動更新間隔の設定

まず、どの段階で失敗したかを確認する

Clashクライアントがサブスクリプションを更新するときは、まずURLへアクセスしてサーバーのレスポンスを受け取り、その内容を設定ファイルとして解析します。プロキシノード、ルール、DNS設定の読み込みは最後の段階です。画面に同じ「更新失敗」と表示されても、接続タイムアウト、HTTPステータス異常、レスポンス内容のエラー、YAML解析失敗など、原因は異なります。

確認作業では、いきなり現在の設定を削除しないでください。まだ使える設定のコピーを残し、更新メッセージと実行ログを確認します。クライアントによってはダウンロードエラーがサブスクリプションカードの横に表示されますが、完全な原因はログにしか記録されない場合もあります。よくある操作経路は「サブスクリプション」→「設定カード」→「更新」です。ログは通常、「設定」→「ログ」または「ログ」→「カーネルログ」から開けます。

画面またはログの表示	通常該当する段階	優先して確認する項目
timeout、deadline exceeded	接続確立またはレスポンス待ちがタイムアウト	ネットワーク経路、システムプロキシ、DNS、サーバー負荷
404 Not Found	サブスクリプションのパスが存在しない	URLが完全か、トークンが失効していないか、プランがリセットされていないか
401 または 403	認証が拒否された	トークン、アカウント状態、リクエスト頻度、アクセス元の制限
unexpected end、EOF	レスポンスが途中で切れた、またはファイルが不完全	ネットワークの揺らぎ、ゲートウェイ制限、サーバー側の生成処理
yaml、parse、unmarshal	設定の解析に失敗	レスポンス形式、インデント、フィールド型、クライアントとの互換性
更新は成功したがノード数が0	内容は有効だが読み込めるプロキシがない	サブスクリプション形式、アカウントで利用可能なノード、変換テンプレート

サブスクリプション取得タイムアウトを段階的に確認する

ステップ1：サブスクリプションのドメインに到達できるか確認する

タイムアウトは、ノードが使えないことを意味しません。サブスクリプションのダウンロードとプロキシノードへの接続は別の経路です。前者はサブスクリプションサービスのドメインへアクセスし、後者は設定内のプロキシサーバーへ接続します。現在のノードでWebページを開けても、DNS、ルーティング、サーバー障害が原因でサブスクリプションのドメインに接続できない場合があります。

失敗した時刻を記録し、60秒空けて手動更新を2回続けて実行し、一時的な通信の揺らぎを切り分けます。
家庭の固定回線からモバイルホットスポットへ切り替えるなど、ネットワークを一度変更して再更新します。
システムプロキシを無効にした状態と、現在のプロキシを維持した状態をそれぞれテストします。サブスクリプションのドメインへ直接接続する必要がある環境もあれば、既存のプロキシ経由でアクセスする必要がある環境もあります。
端末の日付、時刻、タイムゾーンを確認します。時刻が大きくずれていると、ダウンロード前にTLS接続が終了することがあります。
ログで対象ドメインとエラーが発生した段階を確認します。DNSクエリのタイムアウトとTCP接続のタイムアウトは分けて対処してください。

システムプロキシを無効にすると更新できる場合は、サブスクリプションのドメインが誤って利用できないノードへ割り当てられていないか確認します。ルールでそのドメインを直結にするか、更新中だけDIRECTを選択できます。プロキシを有効にした場合だけ更新できるなら、安定した設定を更新経路として残し、新しい設定の検証が終わる前に上書きしないでください。

ステップ2：DNSタイムアウトと接続タイムアウトを区別する

ログに「no such host」「DNS lookup failed」「i/o timeout」と表示され、DNSを指している場合は、まずClashのDNSモジュールを確認します。mihomoカーネルを使っている場合は、nameserver、proxy-server-nameserver、nameserver-policyの役割分担にも注意してください。プロキシサーバーのドメインを解決できないと、サブスクリプションの取得とノード接続の両方に影響する可能性があります。

TUNモードを一時的に無効にして再試行し、通信がTUN、システムプロキシ、ローカルDNSの間でループしていないか確認します。
ローカルのリスニングポートが競合していないか確認します。mixed-portは7890、HTTPポートは7890、SOCKSポートは7891が一般的ですが、実際の値は現在の設定に従ってください。
パケットキャプチャーツール、別のプロキシクライアント、VPNを同時に動かしている場合は、いずれか一つを完全に終了してからClashカーネルを再起動します。
DNS設定を変更した後は、カーネルを一度再起動します。プロキシグループを切り替えるだけでは、DNSの状態がすべて再構築されないことがあります。

ステップ3：ダウンロードの待機時間を適切に調整する

クライアントにサブスクリプションのタイムアウト設定がある場合は、検証のため10秒から一時的に30秒へ延長します。30秒を超えても失敗が続くなら、数分まで延ばしても経路障害の解決にはつながりません。テストでは、接続待機10秒、ダウンロード全体30秒を目安にし、HTTPリダイレクトにも対応させます。

デスクトップでは、コマンドでレスポンスの状態を確認できます。まずターミナルで read -s SUB_URL を実行してサブスクリプションURLを貼り付け、Enterキーを押してから、次のコマンドを実行します。これにより、トークンがコマンド履歴に直接残る可能性を減らせます。

curl -L \
  --connect-timeout 10 \
  --max-time 30 \
  -D headers.txt \
  -o profile.yaml \
  "$SUB_URL"

wc -c profile.yaml
head -n 8 headers.txt

終了コード0は、ダウンロード処理が完了したことを示すだけで、内容がClash設定であることまでは保証しません。HTTPステータス、ファイルサイズ、Content-Typeを続けて確認してください。正常な設定には通常、proxies、proxy-providers、proxy-groups、rulesのいずれかが含まれます。

404、401、403が返る場合の対処法

404：URLのパスまたはサブスクリプショントークンが変更された

404は、サーバーには接続できたものの、現在のパスが存在しないことを示します。よくある原因は、コピー時にクエリパラメータが抜けた、サブスクリプショントークンがリセットされた、古いURLの提供が終了した、URL内の特殊文字がチャットアプリで切り詰められた、といったものです。ドメインだけを比べず、プロトコルの先頭から最後の1文字まで完全に比較してください。

サブスクリプションサービスの管理パネルに戻り、ClashまたはClash Metaに対応したURLを再度コピーします。
クライアントの失敗した項目を削除してから貼り直し、古い項目がキャッシュされたURLを参照し続けないようにします。
URLの前後にスペース、改行、全角引用符がないことを確認します。
サーバー側でトークンをリセットした直後なら、古いURLは無効と考え、すべての端末で更新します。
2～5分待ってから再試行します。サービスによっては設定の再生成やエッジキャッシュの同期に時間がかかります。

ブラウザーでURLを開いてダウンロードできても、クライアントで成功するとは限りません。サービスによってはUser-Agentに応じて形式を変えたり、特定のリクエストヘッダーを要求したりします。逆に、ブラウザーにWebページが表示されても、サブスクリプションが無効とは限りません。通常のブラウザーからのリクエストを説明ページへ転送するサーバーもあるためです。クライアントログのステータスコードと実際のレスポンス内容を基準に判断してください。

401と403：認証またはアクセス方針による拒否

401は通常、トークンが無効または欠落していることを示し、403はアカウント状態、アクセス元、リクエスト頻度、サーバー側の方針によって現在のリクエストが拒否された可能性を示します。まずサービスの管理画面にログインし、アカウントとサブスクリプションの状態を確認してからURLを再生成します。短時間に数十回も更新をクリックすると、サーバーのレート制限にかかることがあります。その場合は10～30分間リクエストを停止してください。

ダウンロードは成功したが、内容が空または解析できない

まず、返ってきた内容がYAML、Base64、HTMLのどれかを確認する

クライアントがHTTP 200を受け取っても、更新に失敗することがあります。サーバーがログインページ、エラー説明、空ファイル、汎用的なBase64ノード一覧、または現在のクライアントが対応していないフィールドを返している可能性があります。ダウンロードしたファイルが数十バイトしかない、または先頭に <!DOCTYPE html> や <html> が現れる場合、設定ファイルではありません。

Clashの設定は通常YAML形式です。ノードは proxies の下に直接記述することも、proxy-providers でリモートプロバイダーを参照することもできます。他のクライアント形式のリンクだけを含むテキストは、完全なClash設定として直接読み込めません。サーバー側のパネルにクライアント形式の選択肢がある場合は、カーネルに合ったClashまたはmihomo形式を選択してください。

YAMLのインデントとフィールド型を確認する

YAMLではスペースで階層を表し、同じ階層でタブとスペースを混在させることはできません。よくあるミスには、ポートを数字以外の文字列で記述する、プロキシグループが存在しないノードを参照する、プロバイダーにbehaviorがない、古いカーネルが新しいフィールドを認識できない、といったものがあります。クライアントとmihomoカーネルを更新してから再読み込みすると、バージョンが古いことによる互換性問題を切り分けられます。

proxy-providers:
  remote-main:
    type: http
    url: "https://sub.example.net/client/REDACTED"
    path: ./providers/remote-main.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

上の例にある interval: 21600 は、プロバイダーを21600秒ごと、つまり6時間ごとに更新する設定です。ヘルスチェックの interval: 600 は、10分ごとにノードの可用性をテストする設定です。用途は異なります。ヘルスチェックはサブスクリプションを再ダウンロードせず、サブスクリプション更新も継続的なノード検査の代わりにはなりません。

更新は成功したがノード数が0

ノードが0の場合は、まず元のレスポンスを確認し、サーバーが本当にプロキシ項目を返しているか確認します。アカウントの有効期限切れ、通信量の超過、地域フィルターで結果が空、変換テンプレートの誤りなどにより、構造は正しくてもノードのない設定が生成されることがあります。設定にルールとプロキシグループしかなく、proxies または利用可能な proxy-providers がない場合、クライアントがノードを自動生成することはできません。

プロキシグループの参照関係も確認してください。設定にノードがあっても、プロキシグループの use が誤ったprovider名を指していると、画面上は空のグループとして表示されることがあります。名前は大文字と小文字を区別します。たとえば remote-main と Remote-Main は別の識別子です。

自動更新間隔はどのくらいに設定すべきか

自動更新は頻繁にするほど良いわけではありません。サブスクリプションの内容は通常、数分単位では変わらないため、高頻度のリクエストはサーバーの負荷を増やし、レート制限も招きやすくなります。個人の端末なら、6～24時間が安定しやすい範囲です。サーバーの復旧を待つ間は、周期を60秒に変更するのではなく、手動更新を1回実行してください。

利用シーン	推奨間隔	秒数
ノードの変化が多い日常用端末	6時間	21600
一般的なデスクトップとスマートフォン	12時間	43200
長期間安定して使う家庭用端末	24時間	86400
一時的なトラブル対応	自動再試行を無効にし、必要なときだけ手動更新	該当なし

GUIクライアントでの設定場所

クライアントによって「設定」と「サブスクリプション」の呼び方は統一されていません。よくある操作経路は「サブスクリプション」→「設定を選択」→「編集」→「更新間隔」、または「設定」→「サブスクリプションカードのメニュー」→「自動更新」です。時間単位で入力するクライアントでは6が6時間を意味しますが、分単位の場合、6時間は360と入力します。保存する前に、入力欄の後ろにある単位を必ず確認してください。

Clash Verge Revのようなmihomo対応GUIクライアントでは、リモート設定を通常「サブスクリプション」ページにまとめています。更新間隔を変更したら、まずサブスクリプション設定を保存し、手動更新を1回実行して更新時刻を確認します。旧版のClash for Windowsは新しいクライアントとメニュー名が異なるため、Profilesページでリモート設定項目と更新オプションを確認してください。画面に間隔設定がない場合、バックグラウンドで自動更新されると決めつけないでください。

mihomo設定にある2つのinterval

設定ファイルを手書きするときに最も混同しやすいのが、プロバイダーの更新周期とヘルスチェックの周期です。proxy-providers 項目直下の interval はリモートファイルを再ダウンロードする間隔を制御し、health-check の下にある interval は接続テストの間隔を制御します。前者は21600～86400秒、後者は300～900秒が一般的です。

ヘルスチェックを頻繁に実行すると、追加の接続が発生します。ノード数が多い場合、30秒ごとの検査は瞬間的な同時接続数とバッテリー消費を増やす可能性があります。モバイル端末ではヘルスチェックを600秒以上に設定し、実際に使うproviderだけで有効にするのがおすすめです。サブスクリプションの更新失敗は、ヘルスチェック間隔を変更しても解決しません。

TUNモード、システムプロキシ、サブスクリプション更新の関係

TUNを有効にすると、クライアントはより多くのシステム通信を引き受けられますが、サブスクリプションのリクエストはGUIプロセスまたはカーネルから送信される場合があります。実装はクライアントごとに異なり、リクエストが現在のプロキシグループに従うとは限りません。「ブラウザーは開けるのに、クライアントの更新はタイムアウトする」場合は、GUIプロセスがシステムプロキシを経由しているか、サブスクリプションのドメインがルールに一致しているか、TUNルートがループしていないかを重点的に確認します。

TUNを無効にし、システムプロキシを残して更新を1回テストします。
システムプロキシを無効にし、TUNだけを残して更新を1回テストします。
両方を無効にし、サブスクリプションのリクエストを直接接続にして更新を1回テストします。
元の設定に戻してからカーネルを再起動し、ログにポート競合やルート設定の失敗がないことを確認します。

上記のテストでは、毎回1つの変数だけを変更してください。DNS、プロキシモード、TUN、サブスクリプションURLを同時に変更すると、更新できるようになっても本当の原因を特定できません。テスト中はルールモードを維持し、サブスクリプションのドメインだけDIRECTまたは安定したプロキシグループに指定できます。

再現可能なトラブル対応の手順

古い設定を残す：まだ使える設定を先にエクスポートし、直接上書きしない。
完全なエラーを確認：ステータスコード、対象ドメイン、発生時刻、ログのキーワードを記録する。
URLを確認：サブスクリプションURLを再コピーし、空白、欠落、期限切れのトークンを除外する。
ネットワークを切り替える：現在のネットワークとモバイルホットスポットでそれぞれテストする。
リクエスト経路を切り替える：直結、システムプロキシ、TUNの状態を順番にテストする。
レスポンスを確認：HTTPステータス、ファイルサイズ、YAML形式かどうかを確認する。
設定を検証する：proxies、proxy-providers、プロキシグループの参照、YAMLのインデントを確認する。
カーネルを確認する：クライアントが対応するmihomoカーネルのバージョンへ更新してから再読み込みする。
適切な周期を設定する：日常利用では6、12、24時間のいずれかにし、分単位の更新は避ける。
最後にサーバーへ問い合わせる：失敗時刻、ステータスコード、マスキング済みログを伝え、完全なサブスクリプショントークンは送らない。

更新が復旧した後に確認すること

サブスクリプションの更新成功が表示されたら、まず更新時刻、ノード数、プロキシグループが想定どおりか確認してから新しい設定へ切り替えます。ノードを1つ選んで遅延テストを行い、続いて普段使うサイトへアクセスしてルールによる振り分けを確認します。ノードは存在するのにすべての接続が失敗する場合、問題は「サブスクリプションのダウンロード」から「ノード接続」へ移っています。更新を繰り返すのではなく、接続ログを確認してください。

最後に自動更新周期を適切な値へ戻します。トラブル対応中に設定した短い周期は早めに解除し、バックグラウンドでリクエストが続かないようにしてください。デスクトップクライアントでは、24時間以内に予定どおり1回更新されるか確認できます。モバイルOSではバックグラウンド処理が制限される場合があるため、自動更新時刻は省電力設定やシステムのスケジューリングに左右されます。必要に応じてクライアントを開いた後に手動更新してください。

確認すべき流れは、URLが有効、ネットワークに到達可能、レスポンス内容が正しい、設定を解析できる、プロキシグループの参照が有効、ノードに接続できる、の6段階です。この順に確認するほうが、クライアントを何度も削除したり更新を連打したりするより、問題を特定しやすくなります。