Clash サブスクリプション管理：更新失敗・認証・ヘルスチェックのトラブルシューティング
サブスクリプションが突然更新に失敗し、ノードが全部グレーアウトしてしまった？本記事ではサブスクリプションの基礎的な仕組みから解説し、よくある失敗原因、ヘルスチェックの設定、ノード絞り込みの書き方を一気に解説します。
サブスクリプションとは何か、問題が起きたら何を見るべきか
普段「サブスクリプションをインポートする」と言っているものは、設定ファイルのレベルでは実際には proxy-providers フィールドに対応しています。クライアントは定期的にある URL にアクセスし、返ってきたノードリストを取得してノードとして解析し、対応するプロキシグループに追加します。この仕組みを理解しておけば、「サブスクリプションの更新に失敗した」ときにどの方向を調査すべきかが分かります。
proxy-providers: my-sub: type: http url: "https://example.com/sub?token=xxx" interval: 3600 # 3600秒ごとに自動更新 health-check: enable: true url: https://www.gstatic.com/generate_204 interval: 300
多くの GUI クライアントは、この大きな設定を「サブスクリプションをインポート」の入力欄の裏に隠しています。入力するリンクが url フィールドに対応し、画面上の「更新間隔」が interval に対応しています。本質的には違いはありません。
サブスクリプション更新が失敗するよくある原因
-
「異常なクライアント」と判定されアクセスを拒否される一部のサブスクリプションサービスはリクエストの
User-Agentを検査し、一般的でないクライアントのリクエストをブロックします。headerフィールドで一般的な UA 文字列を手動指定して偽装できます。 -
サブスクリプションリンクに認証が必要サブスクリプションアドレスにアクセスするために
Authorizationヘッダーが必要な場合（自前パネルのサブスクリプションインターフェースでよくあります）、同様にheaderフィールドで付与します。トークンを URL に埋め込むのではなく（一部のサービスは両方の方式に対応していますが、header を使う方がより適切です）。 -
サブスクリプションの取得自体にプロキシが必要サブスクリプションサーバー自体が海外にあり、海外のウェブサイトにアクセスするにはまず使用可能なノードが必要な場合、「使えるノードがないためサブスクリプションを取得できず、サブスクリプションが取得できないためノードがない」という循環に陥ります。この場合は
proxyフィールドで、サブスクリプション更新専用の固定ノードを指定できます。 -
サブスクリプションファイルのサイズが上限を超えている
size-limitフィールドはデフォルトでは無制限ですが、クライアントやパネル側でより保守的な制限が設定されている場合、大きすぎるサブスクリプションファイルは直接拒否されます。この制限を緩めるか解除することで対応できます。
proxy-providers: my-sub: type: http url: "https://example.com/sub" proxy: 直接接続用ノード # サブスクリプション更新専用の固定出口 header: User-Agent: - clash-verge/v2.0.0 Authorization: - Bearer your-token-here
クライアントの GUI に header オプションが直接表示されていない場合、通常は「サブスクリプションオーバーライド/カスタムパラメータ」といった高度な設定から入力する必要があります。具体的な入り口はクライアントによって異なるため、見つからない場合は該当クライアントの公式ドキュメントを参照してください。
health-check で使えなくなったノードを見つける
サブスクリプションのノードを長く使っていると、サーバーがオフラインになる、速度制限される、ブロックされるといったことは日常的に起こります。ヘルスチェックを行わないと、プロキシグループの中に接続できない「ゾンビノード」が混在し、自動測速/自動選択の体感が悪くなります。health-check はこの問題を解決するための機能です：
対応する proxy-providers の項目の下に health-check を追加し、安定した検証用アドレス（https://www.gstatic.com/generate_204 または https://cp.cloudflare.com を推奨）を指定すると、クライアントは設定した間隔で各ノードに定期的に検証リクエストを送信します。
enable：ヘルスチェックを有効にするかどうかで、常時有効にしておくことを推奨します。interval：検証間隔（秒単位）。短く設定する必要はなく、300～600秒で十分です。lazy：デフォルトはtrueで、ノードが実際に使われていないときは検証を行わずリソースを節約します。パネルに常に正確な遅延データを表示させたい場合は無効にできますが、バックグラウンドの通信量が少し増えます。
プロキシグループのタイプが url-test（自動測速）や fallback（自動フェイルオーバー）の場合、ヘルスチェックの結果が自動選択のロジックに直接影響します——使えなくなったノードは自動的にスキップされ、手動での対応は不要です。
サブスクリプションのノードが多すぎて雑然としている？filter で絞り込む
サブスクリプションによっては一度に数百のノードを提供することがあり、それらを全部1つのプロキシグループに入れると選びにくく見た目も悪くなります。filter / exclude-filter を使うと、キーワードや正規表現でノードを絞り込み/除外でき、同じ地域や同じ用途のノードを個別のプロキシグループに分けられます。
proxy-providers: hk-only: type: http url: "https://example.com/sub" filter: "(?i)港|hk|hongkong" no-relay: type: http url: "https://example.com/sub" exclude-filter: "(?i)中转|relay"
同じサブスクリプションアドレスを複数の proxy-providers 項目として設定し、それぞれ異なる filter で「香港のみ」「日本のみ」「中継ノードを除外」といったサブセットに分割し、それぞれ個別のプロキシグループを作ることができます。数百ノードもある大きなリストから探すよりはるかに便利です。
よくある質問
手動で「サブスクリプションを更新」するのと自動更新を待つのは何か違いがありますか？
本質的な違いはありません。手動更新は、本来 interval に従って定期的に実行される取得処理を今すぐ1回実行するだけで、効果は完全に同じです。サブスクリプション提供元でプランやノードを変更した直後であれば、手動で1回更新すればすぐに反映され、次の自動更新サイクルを待つ必要はありません。
サブスクリプションアドレスはブラウザでは開けるのに、クライアントでの取得に失敗するのはなぜですか？
ブラウザとクライアントがリクエストを送る際の User-Agent やリクエストヘッダーは異なり、一部のサブスクリプションサービスは特定のクライアントの UA からのアクセスしか許可していません。前述の方法で header にクライアントで一般的な UA を手動指定して試してみてください。
新しいサブスクリプションリンクに変更したのに、古いノードがプロキシグループに残ってしまう場合はどうすればいいですか？
通常はローカルにキャッシュされたサブスクリプションファイルが置き換わっていないことが原因です。path フィールドで指定されたキャッシュファイルのパスを確認し、古いキャッシュファイルを手動で削除してから再度サブスクリプション更新をトリガーしてください。あるいは proxy-providers のこの項目名自体を新しい名前に変更し、新旧のコンテンツが同じキャッシュファイルで混在しないようにする方法もあります。
学び終えたら、Clash をインストールして試してみましょう
全プラットフォームのインストーラーを1か所で入手できます。おすすめタグに沿って選べば間違いなく、数分で使い始められます。