1 前提：subscription の自動取得が走る層
多くの構成で、リモートの購読は proxy-providers ブロックにぶら下がります。type: http と url:、ローカルへの path: をセットし、コアは設定ロード後に（または遅延設定に応じて）HTTPS で本文を取得し、パースしたノードを proxy-groups の use: から引きます。ここでの 自動更新とは、バックグラウンドで定期的に同じ url へ再度 GET し、path 先のキャッシュを差し替える挙動を指します。手元の単一ファイル config.yaml だけを編集している場合でも、path に展開されるプロバイダ断片は別ファイルとして更新される点が、初見では分かりにくいことがあります。
一方、ルールや GeoIP 用のリストは rule-providers に似た interval を持ちます。本稿の主役は proxy-providers ですが、「購読以外のリモートリストも同じ用語で周期が決まる」と頭の片隅に置くと、全体の YAML が読み解けます。また Linux 向けの Mihomo 起動パターンでは -d でホームディレクトリを渡すため、path の相対位置はそのディレクトリ基準で解決されます。クライアントによってプリセットの providers/ サブフォルダが自動作成される場合もあるので、実際の保存場所は一度エクスプローラや ls で確認してください。
2 interval：購読リンクを何秒おきに引くか
interval は、プロバイダごとのリモート取得周期（一般的には秒）です。値が小さいほどノード変更に追随しやすい反面、プロバイダや前段の CDN が意図しない高頻度アクセスとみなしてレート制限や一時的なエラーへ寄ることがあります。逆に大きくしすぎると、メンテナンス直後などに死んだノードが UI に残り続け、手動更新ボタンに頼る時間が増えます。モバイル回線やバッテリー駆動の端末では、通信のムダを減らす意味でも「本当にその周期が要るか」を見直す価値があります。
実務的には、プロバイダの案内に推奨間隔があればそれを優先し、なければ数十分〜数時間レンジを出発点にして様子を見る構成が無難です。社内で複数プロファイルを配布している場合でも、全員が極端に短い interval を踏むと出口 IP が偏り、同じ制限にまとめて当たることがあります。チーム運用なら「代表端末だけ短く、ほかは控えめ」などに落とし込むと安心です。
3 lazy：いわゆる「静かな」初回取得（オンデマンド）
lazy: true をプロバイダに付けると、起動直後ですべての subscription を一斉に取りに行かず、実際にそのプロバイダを参照するプロキシグループが使われる段階まで初回フェッチを遅らせる、という動きになります。ノード数が非常に多いマルチプロバイダ構成では、待ち時間とログノイズ、無意味な検出リクエストを減らせる一方、初めてそのグループを選んだ瞬間にのみダウンロードが走るため、その時点の待ち時間は伸びることがあります。バックグラウンドでの定期 interval 更新が完全に消えるわけではなく、読み込まれた後は周期に従って再取得が続く、という理解が重要です。
日本語圏の検索では「静默拉取」のニュアンスで lazy が語られることがありますが、厳密には「通知を抑制する OS 機能」ではなくコア内部の取得スケジューリングの話です。GUI が購読更新完了をトーストするかどうかは別レイヤーなので、後述のセクションでも触れます。lazy を使わない既定に戻したい場合は、キーを外すか false を明示して挙動を比較すると差が掴みやすいです。
proxy-groups の url-test や fallback にも lazy がありますが、そちらは「戦略グループがルールに命中するまで積極的に測らない」という文脈です。url-test／fallback の記事と役割が近い語でも、設定位置が違えば効き目の対象も変わります。
4 health-check.interval：購読取得とは別の周期
proxy-providers 直下に health-check: ブロックがある場合、その中の interval はすでにローカルに展開されたノードに対する死活・遅延プローブの周期です。subscription の本文をサーバから引き直す周期とは独立しているので、両方を短くすると「取得もプローブも忙しい」構成になり、片方だけを攻めた構成にしたいときは数値を分けてください。enable: false にすればプローブ自体を止められますが、選択 UI の遅延表示や自動選択系グループの材料が減るトレードオフがあります。
つまり整理すると、① 遠隔 YAML／Base64 をダウンロードする周期（proxy-providers.interval）、② 手元のノードに対する健康診断の周期（health-check.interval）、③ 初回を遅らせるか（lazy）、の三本柱です。この三分割を意識すると、「更新ボタンを押さなくてもノードは fresh なのに遅延表示だけ古い」といった報告も、どのダイヤルを回すべきかがすぐに見えます。
5 YAML 例：定期取得を強めた構成と lazy 寄りの構成
以下は教育用のスケルトンです。URL やファイル名は環境に合わせて差し替えてください。secret や external-controller など全体の骨格は、既存プロファイルにマージする想定で読んでください。
例 A：interval を中程度にし、起動直後から取りに行く
proxy-providers:
airport-main:
type: http
url: "https://example.com/your-subscription"
interval: 3600
path: ./providers/airport-main.yaml
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600
proxy-groups:
- name: Proxy
type: select
use:
- airport-main例 B：lazy で初回を遅延し、取得間隔はやや長め
proxy-providers:
airport-backup:
type: http
url: "https://example.com/backup-subscription"
interval: 43200
path: ./providers/airport-backup.yaml
lazy: true
health-check:
enable: true
url: http://cp.cloudflare.com/generate_204
interval: 900
proxy-groups:
- name: Backup
type: select
use:
- airport-backup
例 B のようにサブのプロバイダへ lazy: true を寄せておくと、普段はメイングループだけを触る用法ではバックアップ側への HTTP アクセスが抑えられます。フェイルオーバーで実際にそのグループが必要になったタイミングで初回取得が走る、という運用と相性がよいです。逆に、起動後すぐ全ノードの遅延を並べたい・自動選択グループを最初からフル稼働させたい、という目的なら lazy を外すか false に寄せてください。
6 実測検証：ログ・キャッシュ・API で「効いたか」を見る
ステップ 1： 変更前に log-level を debug またはプロバイダ周りが追えるレベルへ一時的に上げ、コンソール・journal・GUI のログビューを開いた状態で設定をリロードします。ステップ 2： path で指定したファイルの更新タイムスタンプを OS 上で監視し、interval 経過後に実際に書き換わるかを見ます。期待どおり動いていれば、mtime が周期に沿って進むはずです。ステップ 3： lazy: true を初めて入れた場合は、起動直後ではなく「該当グループを初めて選んだ直後」に mtime が動くパターンを確認すると理解が一気に進みます。
CLI でホームディレクトリを固定しているなら mihomo -t -d /path/to/home のように文法検査だけ先に回し、YAML 破損でリロードに失敗していないかも切り分けます。さらに External Controller と Yacd など REST 越しにプロバイダ一覧を見られる場合、取得エラーの理由が UI に出るので、403 系はHTTP 層の切り分け記事へ橋渡しできます。検証が終わったら log-level は info など運用レベルへ戻し、ディスクと目の負担を減らしてください。
path の親ディレクトリが存在し権限がある ③ プロバイダ名と use: の綴りが一致 ④ 期待したタイミングで mtime が動く──この四つが揃えば、interval／lazy の効きは概ね良好です。
7 GUI 利用者へ：画面の「更新間隔」と YAML の対応
Clash Verge Rev などのデスクトップクライアントは、プロファイル編集画面や高度な設定で proxy-providers の JSON／YAML をエディタに同期的に反映します。画面上のスライダや分表示が秒に丸められて見えることもあるので、最終的な真実はエクスポートした YAML を見て確認するのが確実です。またトースト通知やバadge の点滅はクライアント実装依存であり、コア側の lazy だけでは「静かに」ならない場面もあります。通知がうるさい場合は OS の通知設定とクライアント設定の両方を覗きます。
変更を試すときは、まずステージング用の短い interval で挙動を観測し、問題なければ本番値へ戻すとミスが減ります。チームで共有するなら Git などにマスク済みのスニペットを残し、誰がどの値を変えたかを追えるようにしておくと、後から「急に 403 が増えた」といった事故の原因が特定しやすいです。
8 よくある質問
Q. interval を 60 未満にしてもいい？
技術的には可能な場合もありますが、プロバイダポリシーと帯域・コストの双方を確認してください。短すぎると逆に不安定になりやすいです。
Q. lazy を付け忘れたせいで通信が減らないように見える
参照されている全グループが起動直後からアクティブだと、結局すぐにフェッチが走ります。プロファイルのルールと実際のトラフィックを見て、本当にそのプロバイダへ到達するシナリオが稀かどうかを評価してください。
Q. rule-providers も同じ考え方？
周期制御という意味では近似ですが、対象はルールファイルでありノードではあります。自動更新の干渉を避けるなら、購読・ルール・GeoIP で interval を故意的にズラすとデバッグがしやすいです。
9 まとめ
Mihomo の proxy-providers では、interval でリモート subscription の取得周期を決め、lazy で初回取得を実利用に寄せて無駄な GET を減らせます。health-check.interval は別物なので三つを混ぜないこと。変更後はログと path の更新時刻で実測確認すると安心です。
コア単体では、interval や lazy を変えるたびにログとキャッシュを手で追いがちです。Clash Verge Rev のように YAML と UI が一画面にまとまるクライアントなら試行が速く、更新通知の煩わしさも抑えやすくなります。負担を減らしたいときは、本サイトのダウンロードから自分の OS 向けを試すのが素直な次の一歩です。
