#GeoIP 與 GeoSite 資料庫更新方法:存放路徑、自動更新設定與常見報錯處理

##GeoIP 與 GeoSite 分別解決什麼問題

寫過分流規則的人大概都見過這兩條:

GEOIP,CN,DIRECT
RULE-SET,geosite-cn,DIRECT

第一條靠 IP 位址判斷所屬地區,第二條靠網域列表判斷站點歸屬。這兩條規則背後分別對應兩個不同的資料檔案,理解它們的差異是排查規則不生效的前提。

geoip.metadb 是一份 IP 位址段到國家代碼的對照表,採用 MMDB 二進位格式儲存。當規則寫成 GEOIP,CN,DIRECT 時,mihomo 核心會拿連線目標的 IP 去這張表裡查一次,查到國家代碼是 CN 就命中直連。這張表涵蓋的是 IPv4 與 IPv6 的位址段劃分,和網域本身沒有直接關係——同一個網域解析出的 IP 可能今天在中國大陸,明天就換到境外節點,這也是純 IP 判斷偶爾會「飄」的原因之一。

geosite.dat 則是按分類整理的網域列表,採用 Protobuf 格式壓縮儲存,常見分類有 cn、google、netflix、category-ads-all 等。規則集寫法通常是先在 rule-providers 裡宣告一個基於 geosite 的規則集,再在 rules 裡引用它,或者部分核心也支援直接用 GEOSITE,cn,DIRECT 這種簡寫語法。網域比對發生在 DNS 解析或請求送出之前,判斷依據是網域字串本身而非解析結果,所以對於會隨時切換 IP 的 CDN 站點,geosite 往往比 geoip 判斷更穩定。

兩者搭配使用是常見做法:網域能比對到的用 geosite 判斷,網域比對不到的兜底流量再用 geoip 按目標 IP 所屬地區分流。任何一個檔案缺失或過期,都會導致對應類型的規則整體失效,而不是報錯提示——這也是這類問題不容易被第一時間發現的地方。

##資料庫檔案的存放路徑與目錄結構

mihomo 核心在啟動時會按固定順序查找這兩個檔案,理解查找邏輯比死記一個路徑更有用。

1. 核心工作目錄(Home Dir)優先。多數圖形化用戶端會給核心指定一個專屬的工作目錄,geoip.metadb、geosite.dat、country.mmdb(部分版本用這個檔名代替 geoip.metadb)會被下載到這個目錄的根層級,和 config.yaml 平級存放,不會散落進子資料夾。
2. 設定檔所在目錄次之。如果沒有單獨指定工作目錄,核心會退回到目前設定檔所在的資料夾去找這兩個檔案,找不到才會觸發首次下載。
3. 系統級預設目錄作為兜底。Linux 下常見於 ~/.config/clash/ 或 ~/.config/mihomo/,Windows 下常見於用戶端安裝目錄內的 data 子目錄,macOS 下常見於用戶端的 Application Support 目錄。不同用戶端對這個兜底目錄的命名不完全統一,遇到找不到檔案的情況,先去用戶端「設定」或「關於」頁面確認工作目錄的實際路徑,比在檔案系統裡盲找更快。

確認路徑後,直接查看檔案屬性裡的修改時間,是判斷資料庫是否「很久沒更新」最直接的辦法——比反覆重啟用戶端去猜測靠譜得多。

##geodata-mode 與 geo-auto-update 設定寫法

是否啟用地理資料庫、多久自動檢查一次更新,都由 config.yaml 裡的幾個欄位控制。一份典型寫法如下:

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/geoip.metadb"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/latest/download/country.mmdb"

各欄位含義:

• geodata-mode:是否啟用基於地理資料庫的比對。為 false 時 GEOIP、geosite 相關規則不會載入,規則檔案裡寫了也等於空規則,建議除非明確不需要地理規則,否則保持 true。
• geodata-loader:資料庫載入策略,standard 全量載入進記憶體,查詢速度快但佔用略高;部分版本提供 memconservative 之類的低記憶體模式,適合資源緊張的路由器裝置。
• geo-auto-update:是否在核心運行期間自動檢查資料庫更新,預設關閉或預設開啟因用戶端版本而異,建議手動確認一次目前的值。
• geo-update-interval:自動檢查更新的間隔,單位小時。設定過短會增加不必要的網路請求,一般 24~72 小時是合理區間。
• geox-url:三份檔案各自的下載來源網址。如果預設來源在你的網路環境下存取緩慢,可以替換成同專案的鏡像網址,但要確保檔案內容與格式版本對應,混用不同專案的規則資料庫容易導致解析失敗。

需要注意,geo-auto-update 只在核心持續運行的情況下才有意義——如果用戶端每次退出都會關閉核心程序,下次啟動時是否重新檢查更新,取決於用戶端自身的啟動流程,不完全等同於這個欄位的行為。

##手動更新的具體操作步驟

大多數圖形化用戶端不需要手動碰設定檔,更新入口通常在設定頁裡,常見形態是一個「更新 GeoIP 資料庫」或「更新地理資料」按鈕,點擊後用戶端會呼叫核心暴露的 API 觸發下載,幾秒到幾十秒完成,取決於網路狀況。

如果用戶端沒有提供圖形化入口,或者想確認更新是否真的生效,可以走以下步驟:

1. 確認核心的 RESTful API 埠號與金鑰(通常在 config.yaml 的 external-controller 與 secret 欄位裡),這兩項是呼叫核心介面的前提。
2. 透過介面觸發更新,典型請求形態是向核心的 /configs/geo(不同版本路徑可能略有差異)發送更新指令,具體路徑以你所用核心版本的介面文件為準。
3. 更新完成後查看用戶端日誌或核心日誌,確認出現類似「GeoIP database update completed」或明確的下載成功提示,而不是僅憑頁面沒報錯就判斷成功。
4. 手動重啟核心或用戶端一次,讓規則重新載入已更新的資料庫檔案,部分場景下更新完成但規則比對器沒有熱重載,重啟是最穩妥的做法。

如果實在找不到自動化入口,直接手動下載檔案替換也是可行的:去資料庫來源儲存庫的 Releases 頁面下載最新的 geoip.metadb 和 geosite.dat,替換掉工作目錄裡的舊檔案,再重啟核心。替換前建議先備份舊檔案,一旦新檔案損壞或格式不符,可以立刻回退。

##常見報錯與規則不生效的排查思路

這部分問題大多不會直接彈出醒目的錯誤提示,而是表現為「規則好像沒生效」,排查時按下面的順序逐項確認,效率會明顯高於隨機試錯。

下載失敗或逾時

日誌裡出現類似連線逾時、TLS 交握失敗的字樣,通常是網路路徑問題——如果此時代理尚未建立,核心直連存取下載來源本身就可能被網路環境限制。可以先臨時切換 geox-url 裡的位址到鏡像來源,或者在代理已經建立好之後再手動觸發一次更新。

檔案已下載但規則仍不比對

先確認 geodata-mode 是否為 true,這是最容易被忽略的一項;再確認規則裡寫的地區代碼或分類名稱是否存在於目前版本的資料庫裡,比如 geosite-cn 這類分類名稱在不同版本的規則集專案裡可能改名或拆分,直接抄舊設定容易踩到這個坑。

規則集載入報錯「rule provider not found」或格式錯誤

這類報錯常見於 rule-providers 裡的 behavior 欄位與實際檔案格式不符。geosite 類規則集要寫 behavior: domain,基於 IP 段的規則集要寫 behavior: ipcidr,寫反會導致核心無法正確解析檔案內容,進而報格式錯誤。

rule-providers:
  geosite-cn:
    type: http
    behavior: domain
    url: "https://example.com/geosite-cn.txt"
    path: ./rule-providers/geosite-cn.yaml
    interval: 86400

更新後行為沒有變化

確認更新是否真的替換了正確路徑下的檔案——如果用戶端設定檔所在目錄和核心實際使用的工作目錄不是同一個,更新腳本寫入的位置和核心讀取的位置可能對不上,表現就是「更新了但沒變化」。回到第二節確認路徑優先順序,通常能定位到問題所在。

把這幾類問題按順序過一遍,基本能定位到是網路、設定欄位、檔案路徑還是規則集格式四類原因中的哪一種,再針對性處理即可,不需要重裝用戶端或重寫整份設定檔。