Clash Meta の rule-providers と GEOIP 更新が失敗？mihomo ログでパスと権限を切り分ける（2026）

1. よくある症状と「更新が失敗」の見え方

rule-providers は、リモートのルールセット（多くは yaml や圧縮済みのリスト）を定期的に取得し、ローカルにキャッシュしてルール評価へ載せる仕組みです。GEOIP や類似の位置情報データベース（.mmdb など）は、GEOIP,CN のような行が古い国コード判定を返す原因にもなります。ユーザー側の体感では「設定はしたのにルールが効かない」「国内サイトが誤ってプロキシ側へ行く」「更新ボタンを押しても終わらない」などに現れ、GUI のトーストやステータスだけでは足りないことが多いです。

ここで重要なのは、「ルールの書き方が悪い」のか「データが最新でない／取り込めていない」のかを早い段階で分けることです。後者なら、mihomo のログに HTTP エラーやファイル I/O エラーが残っているはずです。前者は ルールの並びと種別の話に寄りますが、本稿は更新パイプラインに限定します。

2. rule-providers と GEOIP をログ上で区別する

まず log-level: debug（または情報量が十分な info）に上げ、更新を一度だけ手動トリガーするか、定期更新のタイミングに合わせてログを切り出します。見分けの軸はシンプルで、rule-providers ならプロバイダ名・URL・保存先パスがセットで出やすく、GEOIP／mmdb 系なら geoip ファイル名・ミラー URL・バージョン文字列が近くに出ます。実装や GUI によって文言は違っても、「fetch / download / save / open」のどこで止まったかは追えるはずです。

購読（subscription）更新だけが不安定な場合は、TLS や DNS の切り分けが中心になります。Windows 向けの購読ログ稿と重なる部分もありますが、rule-providers は別の HTTP クライアント経路・別の保存ディレクトリを使うことが多く、混同しないでください。HTTPS のホスト名解決や SNIが絡む挙動全般は、Sniffer・SNI の稿と補完関係です。

# config.yaml fragment — raise log level while debugging providers / geoip (revert after)
log-level: debug

3. ネットワーク層：URL・TLS・403・タイムアウト

ログに TLS handshake failed、certificate、x509 などが出る場合は、まずルールプロバイダの URL が生きているかをブラウザや curl で確認します。次に、システムプロキシや別のローカルプロキシが mihomo の外向き HTTP を潰していないか。典型は、コア自身がプロキシ配下にいて自己参照ループになっているケースです。購読更新稿で触れた mixed-port とシステムプロキシの噛み合わせは、rule-providers にもそのまま効きます。

403 / 404 / 429 は「パスは合っているがサーバ側が拒否」のサインです。公開ルールセットの URL がレート制限やUser-Agent 依存になっていると、ブラウザでは開けるのにコアだけ失敗します。対策は更新間隔を伸ばす、ミラー URL に切り替える、プロバイダ定義の header を確認するの三つが現場向きです。タイムアウトばかりなら、DNS が遅い・経路が不安定・IPv6 優先が裏目、など名前解決とルーティングを疑ってください。

次の断片は構造イメージ用です。キー名は利用中のテンプレートに合わせて読み替えてください。

# Example — rule-providers (structure only)
rule-providers:
  my-rules:
    type: http
    url: "https://example.com/ruleset.yaml"
    path: ./rules/my-rules.yaml
    interval: 86400

4. パス層：home-dir・相対パス・実ファイルの所在

path: が相対パスのとき、実際の絶対パスは home-dir（作業ディレクトリ）基準で解決されます。GUI ランチャーだと「想定より深い階層にプロファイルがある」「ポータブル版とインストール版で home が違う」など、ユーザーが見ているフォルダとコアの cwd が一致しないことがあります。ログに no such file や cannot create が出たら、まずその絶対パスをエクスプローラやターミナルで実在確認してください。

パスに全角スペースや権限の厳しい場所（Program Files 直下など）を選んでいないかも見ます。macOS ではアプリのサンドボックス配下に書き込もうとして失敗する例、Linux では systemd の WorkingDirectory と設定ファイルの置き場がズレる例があります。Docker なら ボリュームマウント漏れでコンテナ内の ./rules がホストと共有されていない、というパターンが定番です。

5. 権限層：書き込み不可・サンドボックス・Docker

ネットワークが成功しているのに保存で落ちるときは、ディレクトリの書き込み権限を疑います。Windows では「管理者として実行」したプロセスと通常ユーザーでホームが違う、ウイルス対策が一時ファイルをロックする、などがあります。Linux では chmod と所有者、macOS では Full Disk Access やプライバシー設定が絡むことがあります。読み取り専用メディアや同期フォルダ（クラウドドライブ）上にキャッシュだけ置く構成も、ロック競合で更新が不安定になりがちです。

コンテナ運用では、非 root ユーザーで動かすイメージに対し、ホスト側のディレクトリが root 所有のまま、というミスマッチが起きやすいです。ログに permission denied が一度でも出たら、その UID/GID とマウント先の所有者を揃えるのが先です。セキュリティソフトの「隔離実行」で書き込みが黙殺されるケースも、見落としポイントです。

6. GEOIP（mmdb）専用のチェック

GEOIP データは、プロファイル内の geoip: や geodata-mode、ファイルパス指定とセットで読み込まれます。更新が別チャネル（専用 URL・内蔵ダウンローダ）の実装であれば、ログのキーワードも rule-providers と異なります。ファイルは取れたが古い場合は、更新間隔・ミラー・手動配置のどれかが原因です。ルールはあるのに GEOIP 行だけ挙動がおかしいときは、まず mmdb の更新日時とサイズを実ファイルで確認し、次にログで読み込みエラーを探してください。

GEOIP ルールが意図せず勝つ／負ける問題の多くは、データ鮮度以前に ルール順の話です。ただし本稿の主題は鮮度と取得失敗なので、データが最新かつ読み込めていることをログとファイルで固めたうえで、ルール順の調整に進むのが安全です。

7. キャッシュ破損と手動リセット

ダウンロード途中でプロセスが落ちたり、ディスクが一杯になったりすると、半端なファイルがキャッシュに残り、以降の更新が異常終了し続けることがあります。対策は該当プロバイダのキャッシュファイルを削除して再取得、が基本です。GUI に「キャッシュ消去」があればそれを使い、なければログに出たパスを頼りに手で消します。消す前にバックアップを取り、他のプロファイルと共有しているファイルを誤って消さないよう注意してください。

GEOIP も同様で、mmdb を一度退避してから起動し直し、再ダウンロードを促すのが手堅いです。クラウド同期フォルダ上にあると、同期のたびにファイルがロックされて更新に失敗する、という報告もあります。キャッシュはローカル専用ディレクトリに寄せるのが安定しやすいです。

8. チェックリスト

現場では次の表を上から順に潰すと迷いが減ります。ログの一行単位で事実を固定してから設定を変えてください。

9. まとめ

Clash Meta／mihomo で rule-providers と GEOIP の自動更新が絡むトラブルは、見た目はバラバラでも、ログでは「取れない」「書けない」「古い」に集約できます。HTTP/TLS の失敗ならネットワークと URL、保存で落ちるならパスと権限、データが古いだけなら取得経路とキャッシュ——層を混ぜないのが早道です。ルール本文の調整は、データが揃ってからで十分です。

全体の流れのおさらいは チュートリアルにまとまっています。同種のクライアントのなかでも、Clash 系はログと設定の対応関係を追いやすく、再現性のある運用に向きます。

まずは一度だけログを丁寧に取り、ボトルネックを一つに絞ってから直してください。クライアントの入手と各 OS 向け一覧は → 無料で Clash をダウンロードし、快適な接続体験を試す からどうぞ。