Clash Verge Rev の購読自動更新間隔を Mihomo Profile YAML に揃える

ユーザーが本当に確認したいこと

「購読の自動更新間隔」と入力してデスクトップ版へ辿り着く場合、欲しい答えはだいたい二重になっています。一つはClash Verge Rev のどの画面で何分にするかという操作論。もう一つは、保存またはエクスポートされた Profile の YAML において proxy-providers 以下に書かれた update-interval が、いまコアが実行しているファイルと同じかという実効確認です。Android 向け稿が「間隔」と「OS のバックグラウンド制約」を並べるのに対し、デスクトップでは後者は比較的穏やかでも、アクティブな Profile の取り違えや手編集した下書きとの競合が同様に起きます。ここを切り分けないと「間隔を変えたのに反映されない」という体感だけが残りやすいので、本稿では YAML の語彙まで含めて一本道にします。

• subscription レガシーブロックの話ではなく、Mihomo で広く使う proxy-providers と update-interval に焦点を当てます。
• rule-providers の更新周期は別物です。ノード取得とルール取得を混同するとログの読み方が破綻します。ルール側の詳細は rule-providers の取得と更新間隔を参照してください。
• 初回導線は OS ごとに Windows 11 への Verge Rev と macOS での Verge Rev 初回設定に分かれます。権限とコア選択が済んでいる前提で読み進めてください。

Mihomo における購読 YAML の置き場所

Mihomo コアは、実行中の Profile（単一の合成済み YAML）を真実のソースとして扱います。Clash Verge Rev は購読 URL を GUI で登録し、マージや上書きルールを含めた結果をその Profile に書き出します。したがって「購読の自動更新」を語るとき、最終的に注目すべきは proxy-providers: セクションに落ち着きます。各エントリには通常 type: http と取得先 url、そして周期を秒で表す update-interval が並びます。GUI が「毎十二時間」などと表示している場合でも、実ファイルでは秒に正規化されていることが多く、表示桁とファイル桁が一見ずれるように見えても倍数関係で一致しているケースがあります。逆に桁が合わないのに倍数関係にもならないときは、別 Profile を見ているか、外部ツールが横から同じ path に別内容を書いている疑いが先に立ちます。

第一段：GUI で間隔と有効 Profile を固定する

購読一覧またはプロファイル詳細で、対象 URL の自動更新をオンにし、分・時間ベースの間隔を置きます。ここで重要なのは同時に有効化している Profile 名です。新しい購読を取り込んだ直後に一覧の別行が光っていても、アクティブが古いままだとコアは以前の YAML を読み続けます。Profile・購読・モードの整理稿でも述べているとおり、視覚的な「取り込み成功」と「今まさにそのファイルが選ばれている」は別イベントです。間隔をいじる前に、メニューまたはダッシュボードで現在有効な構成が意図どおりかを一度クリックで確定させてください。

Windows と macOS で文言は多少違っても、上の三条件の意味は変わりません。macOS 側でシステムプロキシや TUN の権限ダイアログに時間を取られているあいだに、別の空 Profile が選ばれたままになる事故もあるので、間隔調整のたびに有効行のハイライトを癖にすると安全です。

第二段：生成された Profile で proxy-providers を読む

第一段が済んだら、Clash Verge Rev が書き出した Profile をテキストとして開き、当該プロバイダ名のブロックを検索します。典型的には次のような並びです（実名と URL は読者環境で置き換えてください）。

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/subscription-token"
    path: ./providers/my-sub.yaml
    interval: 86400
    health-check:
      enable: true
      # ...

バージョンやテンプレートによってキー名が interval ではなく文脈上 update-interval と記述されるドキュメントもありますが、いずれにせよ数値ベースの周期がブロック内に存在し、GUI で触れた購読と一致しているかを見ます。ここで陥りやすいのは、手元のエディタで別ファイルを開いている状態です。必ずアプリが「現在の YAML」として表示または export するパネルからコピーしてください。マージプラグインやサンドボックス化された作業ディレクトリを挟む構成では、エクスプローラや Finder で見えているパスと実行時パスがズレることがあるため、GUI 由来のテキストを真だと決め打ちする方が早いです。

第三段：手動更新と振る舞いで実効を証明する

数値が一致しても、スケジューラが動いていなければ意味がありません。購読行の手動更新を一度実行し、HTTP エラーなく完了したことを確認します。その直後にノード数やチェックサムが変わるか、UI に最終取得成功時刻が出るかをメモしてください。間隔を極端に短くしたテストでは、すぐに次のフェッチがキューに載るはずです。逆に長めにしたテストでは、待ち時間を越えるまでログが静かなのが正常です。コア側のログに provider フェッチの失敗が連発していれば、間隔以前に TLS か DNS かレート制限を疑います。Android 稿がワークマネージャーを並べるのに相当するのは、デスクトップでは「別プロセスの古いコアが残っていないか」「ポート競合で再起動が失敗していないか」といった観点になります。

ここまで三段が通れば、検索意図の「購読の自動更新をデスクトップで決め、Mihomo の Profile と突き合わせた」状態になっています。以降は安定運用の話であり、プロバイダ側のリスト lifetime に合わせて購読の自動更新を伸ばしたり、ピーク時だけ一時的に短くしたりと調整します。

Windows と macOS での運用上の差

Windows 11 ではユーザーアカウント制御や企業ポリシーにより、アプリのデータディレクトリがリダイレクトされていることがあります。macOS では Gatekeeper 通過後も、ヘルパーや TUN を別途入れる構成で再起動が挟まると、間隔を変えたタイミングとコアのロード順が一度ずれるように見えることがあります。いずれも「権限と再起動のあとにもう一度 Profile を開き直す」で多くは収束します。バッテリー制約の話は Clash for Android の購読間隔稿のほうが近いですが、ノート PC の省電スリープで長時間ネットワークが切れる環境では、デスクトップでもスケジュールが後ろに押し出される点は意識しておくと観測がブレません。

よくある境界質問

画面では短いのに YAML は長い間隔のまま

キャッシュ表示のみ更新され、ディスク上の Profile が古いケースと、別名の YAML を見ているケースが典型です。いったんアプリ内からテキストを再エクスポートし、検索で当該 provider 名を一意に引っ掛けてください。

health-check と混ぜて間隔が伸びたように見える

死活監視の周期とフェッチ周期は別パラメータです。ログの文言を読み分けないと「自動更新が遅い」と誤認しがちです。

Mixin や外部スニペットを足している

マージ結果のどこに proxy-providers が現れるかは順序ルール次第です。最終合成物を一度だけ取りに行き、そこで update-interval を確認する癖をつけると混乱が減ります。

最終チェックリスト

構成の透明性と Clash へ自然に繋げるなら

GUI だけで済ませたい一方で、バックエンドの YAML がブラックボックスだと、間隔やプロバイダ名の不一致に気づくのが遅れがちです。単発プロキシ填め込み型のツールは手早い反面、長期運用では「どのファイルが真か」を追いにくいこともあります。購読の自動更新と Profile の関係が読めないと、レート制限かルールかノードかの切り分けも難しくなります。

Clash 系は合成された Mihomo YAML を一つの画面から追いやすいクライアントが多く、proxy-providers と update-interval のようなパラメータを、GUI 操作とテキストの両方で照合しやすい設計に寄せられています。こうした透明性は、自作ルールやリモート RULE-SET を足していくほど効いてきます。

デスクトップで購読間隔を現実的に揃え、生成 Profile が信頼できる参照になっている状態を試したい場合は、 ダウンロードページ から Clash を入手し、自分のワークフローに静かに載せ替えてみる価値があるでしょう。