Clash Meta でリモート規則セットが取得できない？path と更新間隔を順に直す
分流シナリオや DNS の記事は多い一方、rule-providers そのものが落ちない・古いままという症状は地味に困ります。YAML に RULE-SET を書いたのにログにエラーが出る、初回だけ失敗して空ファイルのまま、interval を短くしても更新されない——多くは URL・保存先 path・作業ディレクトリ・プロキシ経路・キャッシュ のどれかが噛み合っていません。本記事では Clash Meta（Mihomo） 前提で、リモート規則の取得と自動更新を上から順に切り分けます。
rule-providers で何が起きているか
rule-providers は、コアが HTTP(S) などから規則ファイル（またはバイナリ形式のルールセット）を取りに行き、ローカルの path に保存してから rules 側の RULE-SET 行で参照する仕組みです。つまり「設定に名前が載っている」ことと「実体ファイルが健全に存在する」ことは別問題です。取得に失敗すると、古いキャッシュが残る・空ファイルになる・そもそもマッチしなくなる、といった二次障害が出ます。
- type: http：リモート URL から定期取得。トラブルの主戦場。
- type: file：ローカルファイル直読み。ダウンロード処理は走りません。
- behavior：
classical/domain/ipcidrなど。URL 側の形式と一致させます。
手順 1：URL をブラウザと同じ条件で開けるか
まず コアが見ている URL を、可能なら 同じマシンのブラウザまたは curl で開いてください。リダイレクト連鎖、認証付き URL の期限切れ、403 / 429（レート制限）、証明書チェーンの欠損は、GUI では「たまに失敗」に見えますが原因はシンプルです。
プロキシの逆説
規則セットのホストを誤ってプロキシ側のルールでブロックしていないか確認してください。コア自身の outbound がループしたり、更新用 GET が別ポリシーに落ちて失敗することがあります。切り分けでは一時的に該当ドメインを DIRECT 側へ寄せる、GLOBAL で短時間試す、などが有効です。
手順 2：path の「相対」の基準ディレクトリ
path は「設定ファイルの場所」ではなく、多くの場合 コアの作業ディレクトリ（ホーム／プロファイルディレクトリ）からの相対パスとして解釈されます。GUI ラッパーはインストール場所ごとにこの基準が変わるため、./ruleset/foo.yaml が想定と別のフォルダに書き込まれていることがよくあります。
- Windows / macOS GUI：アプリのデータディレクトリ配下に
pathが展開されることが多い。実ファイルをエクスプローラー／Finder で探す。 - Linux の systemd 常駐：
WorkingDirectoryとpathの関係を揃える。Linux・systemd の記事と合わせて読むと早いです。 - Docker：
pathはコンテナ内パス。ホストとボリュームをマウントしないと、再起動で消えたり、ホスト側でファイルが見つからない、という齟齬が出ます。Docker Compose 記事のボリューム設計を参照してください。
書き込み権限
path の親ディレクトリが存在しない、または権限がないと、初回取得が静かに失敗します。深いサブディレクトリを指定する場合は、あらかじめフォルダを作成するか、浅い path に変えて検証してください。
手順 3：更新間隔 interval（秒）の解釈
Clash Meta 系では、リモートプロバイダの更新周期は多くの場合 interval（秒）で指定します。GUI によっては「更新間隔」と表示され、分や時間に換算して入力欄が出ることもあります。ここで起きがちな誤解は次のとおりです。
- 短すぎる：公開ルールセット側のレート制限に当たり、しばらく 403 や空応答が続く。
- 長すぎる：技術的には動いているが、ユーザーから見ると「ずっと更新されない」。
- 0 や未指定：実装・GUI によっては「自動更新しない」「既定値にフォールバック」など挙動が異なる。迷ったらログで実際に GET が走ったタイミングを見る。
手動で確実に引き直したい場合は、外部コントローラ API のプロバイダ更新（クライアントの「規則更新」ボタン）や、該当ファイル削除後の再起動・リロードも選択肢です。運用では 86400（24 時間）前後から始め、公開側の推奨や失敗率に合わせて調整するのが無難です。
動く形の YAML 例（イメージ）
名前と rules 側の RULE-SET,provider_name,... を一致させます。以下は説明用の骨格です。
# Illustrative — adjust provider name, behavior, and paths for your profile
rule-providers:
example-rules:
type: http
behavior: classical
url: "https://example.com/ruleset.yaml"
path: ./ruleset/example.yaml
interval: 86400
rules:
- RULE-SET,example-rules,PROXY
- MATCH,DIRECT
手順 4：壊れたキャッシュと空ファイル
一度でも不完全な応答を書き込むと、そのファイルが残り「更新ボタンを押しても中身がおかしい」状態が続くことがあります。取得エラーを直したあとで改善しないときは、該当 path のファイルを削除し、コアをリロードして再取得させてください。Docker ならコンテナ内の実パスを確認し、ボリューム越しに削除できるかを検証します。
キャッシュ切り分けの順序
- ログで HTTP ステータスと TLS エラーを確認する。
path実体のサイズ・更新時刻を見る（0 バイトや古いままなら疑う）。- ファイルを退避または削除し、再取得を一度だけ手動トリガーする。
- 成功後に
intervalを本番向けに戻す。
手順 5：ログに何を探すか
ログレベルを上げ、provider 名・URL・TLS・DNS の行を追います。システム時刻が大きくずれていると HTTPS 検証が失敗するため、ルータや VPS では NTP も忘れずに。DNS 周りで挙動が変な場合は、DNS / fake-ip の記事で変数を切り分けてから rule-providers に戻ると早いです。
「規則が古い」が分流や DNS のせいに見えるとき
リモートセットが更新されていても、上位の RULE-SET より先により具体的なドメイン行がマッチすると、期待した出口に乗りません。これは取得失敗ではなくルール順の問題です。本記事の対象はあくまでプロバイダのダウンロードと周期更新ですが、症状が似るため、ログで「ファイル更新時刻」と「実際にマッチしたルール行」を分けて考えてください。
よくある質問
GUI は成功と出るのに分流がおかしい
別のプロファイルがアクティブだったり、マージ結果の path が想定と違うことがあります。実際に動いている設定ファイルと、ディスク上の規則ファイルのパスを突き合わせてください。
特定のプロバイダだけ失敗する
その URL だけ証明書・リダイレクト・User-Agent 制限があるパターンです。curl -v でレスポンスヘッダを確認し、必要ならミラーを使うか、自前ホストに置き換えます。
ルータの OpenClash でも同じ？
概念は同じで、生成 YAML の path とルータ上のディスク配置、更新ボタンが触る API がポイントです。詳細は OpenClash の記事を参照してください。
チェックリスト
type: httpの URL が単体で取得できるか確認する。- コアの作業ディレクトリ基準で
pathを解釈し直す（GUI / Docker / systemd）。 intervalを現実的な秒数にし、レート制限を避ける。- 失敗後はキャッシュファイルのサイズと更新時刻を疑う。
- ログで TLS・DNS・プロキシループを確認する。
まずクライアントを揃える
規則の取得はコアの仕事ですが、日々触るのは GUI です。ログが読みやすく、プロバイダ更新が明示されているクライアントほどトラブルが短く済みます。