Clash Meta 規則集與 GEOIP 更新失敗？對照 mihomo 日誌修正路徑與權限

1. 規則集更新與 GEOIP 更新：先分清楚兩條任務

在 mihomo 的世界裡，「規則集」通常指你在設定檔中透過 rule-providers 引用、由遠端下載並快取在本機的文字規則（或轉成內部結構前的來源檔）。它會影響你最後的 rules 命中結果，但它的更新節奏與儲存位置跟節點訂閱（proxy-providers／proxy-groups）是兩套流程。

另一條任務是 GEOIP／GeoSite 這類地理與網域資料庫（常見為 .mmdb 或專案定義的資料格式）。當你使用 GEOIP、GEOSITE 這類規則條目，核心需要一份「夠新且能讀取」的本機檔案；若自動更新關閉、下載失敗、或檔案寫到錯的目錄，就會出現「規則寫了但永遠對不上」的體感。

因此排查的第一步永遠是：你現在要解的是 rule-providers 拉不下來，還是 GEOIP 資料庫沒更新／讀不到，或是兩者同時發生但日誌其實指向同一個根因（例如本機目錄無法寫入）。先分類，就不會把 DNS、TLS 全鍋丟給節點供應商。

2. 常見症狀：下載失敗、路徑錯、規則不生效、資料庫過期

使用者最常看到的表面現象包括：圖形介面顯示規則集「更新失敗」、日誌出現 permission denied 或無法建立檔案、或是更新顯示成功但規則命中與預期不符。GEOIP 相關則常見「分流規則看起來永遠像舊版」或特定國家／ASN 判斷異常；這不一定是規則寫錯，而是資料庫檔案本身過舊或載入失敗回退到預設行為。

另一個典型落差是：你在瀏覽器能開規則集或資料庫的下載網址，但核心更新卻失敗。這與訂閱更新非常像——客戶端走的 DNS、TLS 校驗與出站路由，未必與瀏覽器完全一致。若你需要先把「HTTPS 下載鏈路」補齊，建議搭配閱讀 Windows 訂閱更新與 TLS／DNS 日誌排查 的方法論；本篇則把焦點放在 規則集與 GEOIP 資源的落地位置與權限。

3. 從日誌定位：URL、HTTP 狀態、TLS、DNS 與重試

請在客戶端開啟核心日誌（或寫入檔案），對準你按下「更新規則集／更新 GEO」的時間點，向前後各抓一段完整輸出。對 rule-providers，你通常會看到與提供者名稱、下載網址、HTTP 回應、以及寫入快取相關的行；對 GEOIP／GeoSite，則會看到資料庫檔名、下載來源、校驗或解壓過程（依版本與設定而異）。

建議先用關鍵字快速分桶：timeout、i/o timeout、TLS、handshake、x509、certificate 偏向傳輸與憑證；lookup、no such host、NXDOMAIN 偏向 DNS；403、429、404 偏向 URL 或來源站限制；permission、denied、no such file、mkdir 則幾乎可以直接指向本機路徑或權限。

若日誌顯示 HTTP 200 但後續立刻報錯，請特別注意是不是寫入階段失敗（例如防毒軟體鎖檔、磁碟滿了、或目錄不存在）。這種情況若只看 UI「下載成功」很容易誤判；文字日誌通常會更誠實。

Example: rule-provider block shape (keys vary by version)
rule-providers:
  my-rules:
    type: http
    url: "https://example.com/rules.yaml"
    path: ./rules/my-rules.yaml
    interval: 86400

上例的重點不是背語法，而是理解：path 最終會相對於誰的工作目錄解析，以及 interval 決定了「多久才願意再試一次」，會影響你以為的「怎麼一直不更新」。

4. 路徑與工作目錄：相對路徑、home-dir、圖形客戶端資料夾

規則集與 GEOIP 檔案最忌諱模糊相對路徑：同一份設定檔在不同啟動方式下，工作目錄可能不同。若你使用圖形客戶端（例如各種基於 mihomo 的桌面版），常見做法是讓核心以「設定檔所在資料夾」或「應用程式資料目錄」為基準；若你是 命令列直接啟動核心，則可能以你執行指令時的目前目錄為基準。兩者一旦不一致，就會出現「我明明看到檔案存在，但核心說找不到」的現象——其實是兩個不同資料夾。

實務上建議：為 rule-providers 的 path 選一個穩定位置（例如與設定檔同層的 ./rules/），並在日誌確認實際寫入的完整路徑。若你的客戶端支援指定 home 目錄／工作目錄，請把它納入變因清單：升級客戶端、切換 portable 模式、或從服務改為手動啟動，都可能改變預設目錄。

另一個常見錯誤是把遠端規則檔下載到唯讀位置（例如某些同步碟、或受控資料夾），導致更新週期一到就失敗。若你使用雲端同步資料夾放設定，請確認該資料夾對「代理核心行程」是否可寫入，而不是只有檔案總管手動新增檔案可寫。

5. 權限與沙盒：為何「看起來有資料夾」卻寫不進去

在 Windows 上，使用者帳戶控制與防毒即時掃描，常會讓「非瀏覽器行程」寫入特定目錄變慢或被拒絕；若核心以不同身分執行（例如服務模式與使用者模式混用），也會出現權限不一致。看到 Access is denied 類訊息時，請優先確認：目錄是否被設成唯讀、是否需要在系統管理員權限下首次建立子資料夾、或是否應把資料改放到使用者家目錄下專用資料夾。

在 macOS，請留意沙盒化 App 的可寫入範圍：圖形客戶端若只能寫入容器目錄，你把 path 指到使用者文件夾外的某個自訂路徑，可能會在系統層被拒絕。此時最穩的做法是遵循客戶端預設的設定與資源目錄，而不是硬指定一個「看起來很乾淨」的路徑。

在 Linux（含部分 NAS 或伺服器環境），請檢查 systemd 服務的 User、WorkingDirectory 與檔案系統掛載參數（noexec、ro）。這類問題會讓 GEOIP 檔案「永遠無法原子替換」，表現成更新失敗或版本卡死。

6. GEOIP／GeoSite：mmdb、geodata 模式與過期判斷

GEOIP 規則依賴地理資料庫把 IP 對應到國家或區域；若資料庫過舊，最容易出現「同一節點看似正常，但某站分流永遠怪」的錯覺。多數使用者會在設定裡看到與 geodata、mmdb、或下載網址相關的欄位（實際鍵名依版本與文件為準）；核心重啟後也會重新載入檔案，因此「更新成功但沒重載」有時只是你少做了一步。

建議你把 GEOIP／GeoSite 的排查拆成三段：第一，日誌是否顯示下載成功並寫入預期路徑；第二，檔案時間戳是否更新；第三，規則條目是否確實走到 GEOIP／GEOSITE 分支（可用更上層的規則暫時驗證）。若你同時在調 HTTPS 網域分流，請記得別和 Sniffer／SNI 的命中問題混在一起；兩者日誌長得很像，但根因不同。

自動更新與來源可信度

自行指定第三方 GEOIP／GeoSite 下載網址時，請把「可用性」與「完整性」放進風險評估：CDN 阻擋、憑證鏈不完整、或檔案被替換，都會讓更新流程失敗或引入不一致資料。若你必須走公司網路，也要把 MITM 憑證與 TLS 失敗納入同一套日誌判讀，而不是只改規則。

7. 下載成功卻「規則不生效」：快取、interval 與規則順序

當遠端規則檔確實更新到本機，但你的分流結果仍不符合預期，請優先檢查三件事：第一，規則順序是否讓更上方的規則先命中；第二，規則集是否被正確引用到最終 rules；第三，interval 是否讓你以為「沒更新」其實只是尚未到下一次拉取。若客戶端提供強制更新或清除快取選項，請在變更 URL 或切換鏡像後使用，避免舊檔殘留。

另一個常見誤解是把「訂閱節點更新」與「規則集更新」綁在同一個心理頻率：節點可能每小時變，規則集卻可能是日更或週更。當你在除錯網站分流時，請先確認規則集版本與命中網域是否一致，再回去調策略組與節點品質。

8. 可複製檢查清單（依序做）

步驟 A：固定變因。暫停多餘 VPN、系統級攔截、以及會改寫系統 Proxy 的加速軟體，避免同一時間改三個層級。

步驟 B：從日誌分類。先判斷是 DNS、TLS、HTTP 來源限制，還是本機路徑／權限；不要先改規則順序。

步驟 C：確認工作目錄。用客戶端顯示的設定檔路徑與日誌中的寫入路徑交叉比對，避免相對路徑踩雷。

步驟 D：驗證檔案真的更新。看檔案修改時間與大小變化；若完全不變，優先處理下載與寫入失敗。

步驟 E：處理 GEOIP／GeoSite。確認資料庫檔案存在且被載入；必要時重啟核心並再次觀察日誌。

步驟 F：回到規則邏輯。確認規則集已接入、順序合理，再進入更進階的網域／SNI 排查。

9. 開源資訊與回報習慣

想了解核心行為、提交 Issue 或閱讀更新日誌，可參考上游 MetaCubeX／mihomo 公開資訊。回報時請附上去除敏感資訊後的設定片段、完整錯誤堆疊、客戶端與核心版本，以及作業系統環境；避免只截圖「更新失敗」。若你需要安裝包與入門流程，建議優先使用本站 下載頁，再依 使用教學總覽 串起匯入與分流觀念；訂閱匯入基礎可參考 節點訂閱匯入教學。

例行升級客戶端前建議備份設定與規則集資料夾；若升級後才開始出現寫入失敗，請優先比對新版本對預設目錄與權限模型的變更，而不是立刻重灌系統。