Clash GeoIP 與 GeoSite 資料庫更新教學:下載來源選擇、手動替換與自動更新設定

GeoIP 與 GeoSite 在分流規則裡到底做什麼

Clash 的分流規則裡經常能看到 GEOIP,CN,DIRECT 或 GEOSITE,google,PROXY 這類寫法。這兩條規則背後依賴的是兩份資料檔:GeoIP 資料庫把 IP 位址段對應到國家或地區代碼,GeoSite 資料庫把網域歸類到預設的分組(例如 google、github、netflix)。規則引擎在比對流量時,不需要逐條硬編碼網域或 IP 段,只要引用資料庫裡的分組名稱,就能一次涵蓋成千上萬條記錄。

這種設計把「規則邏輯」和「規則資料」拆開了。規則邏輯寫在 rules 欄位裡,基本上不用改;規則資料放在獨立的二進位檔案裡,可以單獨下載、單獨更新。資料庫本身不含判斷邏輯,只是一份索引表,類似把網域和 IP 歸檔進不同的資料夾。當某個網站換了 IP 段,或新增了一批網域,只要資料庫更新及時,規則的判斷結果就能跟著變化,不需要使用者手動改設定檔裡的規則條目。

反過來說,如果資料庫長期不更新,規則的準確率會慢慢下降:新註冊的網域可能落不到該落的分組裡,某個 CDN 換用的新 IP 段也可能被誤判到境外分組。這也是為什麼資料庫版本與更新頻率值得單獨關注,而不是設定檔寫完就一勞永逸。

常見資料庫發行版對比

市面上流傳的資料庫檔名和格式並不統一,容易混淆,先按客戶端核心分兩條線說清楚。

Clash 原版與 Clash Meta(mihomo)的差異

早期 Clash 原版核心使用的是 Country.mmdb,這是 MaxMind 格式的 GeoIP 資料庫,只做 IP 到國家代碼的對應,不含 GeoSite 網域分組功能,原版核心的 GEOSITE 規則支援也有限。Clash Meta 及其持續維護的分支 mihomo,則採用自己的資料格式:GeoIP 部分是 geoip.dat 或更新的 geoip.metadb,GeoSite 部分是 geosite.dat。.metadb 是 mihomo 團隊後續切換到的自有格式,體積更小、查詢更快,和舊的 .dat 格式不能混用。

資料來源:V2Ray/Xray 系與 MaxMind 系

geoip.dat 與 geosite.dat 的命名和結構最初來自 V2Ray/Xray 生態,後來被 Clash Meta 直接借用,所以兩邊的資料檔格式高度相容,分組名稱(例如 cn、category-ads-all)也基本對齊。這類資料庫通常由社群專案定期編譯發布,常見的發行倉庫會持續跟進 IP 段與網域清單的變化。MaxMind 的 GeoLite2-Country.mmdb 則是另一條線,資料結構更偏向傳統 IP 地理位置庫,主要給只認 .mmdb 格式的舊核心使用。

實際選擇時記住一個原則:先確認自己用的核心是哪個分支(Clash 原版、Clash Meta 還是 mihomo),再確認它認哪種資料檔格式,兩者對不上,替換了也不會生效,甚至會導致規則引擎報錯啟動失敗。

手動替換檔案的完整步驟

手動更新適合不想改設定檔、只想臨時刷新一次資料的場景。核心思路是:下載新的資料庫檔案,放到客戶端能讀取到的目錄,覆蓋舊檔案,重啟核心。

1. 確認客戶端的資料目錄

   不同客戶端存放 GeoIP/GeoSite 檔案的目錄不同,常見的是設定檔同層目錄,或客戶端安裝目錄下的 data、resources 子目錄。可以先在客戶端的設定管理介面裡查看目前生效的設定檔路徑,資料庫檔案通常就在同一目錄或其上層目錄下。

2. 確認核心認的檔案格式

   打開客戶端的核心版本資訊,確認是 Clash 原版、Clash Meta 還是 mihomo。mihomo 較新版本預設認 geoip.metadb,較舊版本和 Clash Meta 認 geoip.dat 與 geosite.dat。下載前先核對檔名後綴,避免下錯格式。

3. 從對應發行來源下載最新檔案

   選定一個維護活躍的社群發行來源,下載與自己核心相符的檔案版本。下載完成後不要直接覆蓋,先在原檔案所在目錄做一份備份,方便替換後出問題時快速回滾。

4. 停止核心後再替換檔案

   資料庫檔案通常在核心啟動時被載入記憶體,運行中直接覆蓋檔案可能不會立即生效,甚至在某些系統上會因為檔案被佔用而替換失敗。建議先在客戶端裡停止代理服務或退出客戶端,再進行檔案替換。

5. 重啟核心並檢查日誌

   替換完成後重新啟動客戶端或代理服務,查看核心日誌裡是否有資料庫載入失敗、格式不符之類的錯誤訊息。如果日誌正常且沒有報錯,說明新資料庫已經生效,可以用一個歸屬明確的網域或 IP 測試分流結果做二次確認。

在設定檔裡開啟定時自動更新

手動替換需要人工介入,長期來看容易忘記更新。Clash Meta 與 mihomo 支援在設定檔裡宣告資料庫來源與更新週期,由核心自行定時拉取新版本,不需要人工干預。核心欄位集中在設定檔頂層的 geox-url 與更新週期相關設定裡,典型寫法如下:

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24

geox-url:
  geoip: "https://example.com/geoip.metadb"
  geosite: "https://example.com/geosite.dat"
  mmdb: "https://example.com/Country.mmdb"

幾個欄位的作用分別是:geodata-mode 打開後,GEOSITE 規則才會真正按網域分組比對,而不是被核心忽略;geo-auto-update 決定是否啟用自動更新;geo-update-interval 以小時為單位設定更新間隔,範例裡的 24 表示每天檢查一次;geox-url 下的三個鍵分別指定 GeoIP、GeoSite 與 MaxMind 格式資料庫的下載位址,核心會按這個位址週期性拉取。不同版本的核心對欄位名稱的支援略有出入,升級客戶端後建議對照目前版本的更新日誌核實欄位名稱是否有變化,避免用了舊欄位導致自動更新靜默失效。

如果訂閱本身由機場提供,機場的訂閱轉換服務有時會自帶一份預設的 geox-url,這種情況下自己手寫的欄位可能會被訂閱內容覆蓋。遇到自動更新不生效,先檢查最終生效的設定檔裡這幾個欄位是不是被訂閱內容重寫過。

更新後常見問題排查

資料庫更新之後規則表現異常,大多集中在以下幾類原因。

• 格式不符:下載了 .dat 格式卻讓只認 .metadb 的新版核心載入,核心通常會在日誌裡報解析失敗,規則引擎會回退到「未匹配」狀態,大量流量落入預設策略組。
• 分組名稱對不上:不同發行來源對同一類網站的分組命名可能有差異,例如有的叫 netflix,有的拆分成更細的子分組。規則裡寫的分組名稱要和資料庫實際收錄的分組名稱完全一致,大小寫和拼寫都要核對。
• 自動更新位址不可達:geox-url 指向的位址如果連線不穩定或需要代理才能存取,而更新動作發生在代理鏈路建立之前,就會出現更新總是失敗的情況。這類位址建議選用連線路徑簡單、穩定的發行來源。
• 快取未刷新:少數客戶端在圖形介面上會對規則做額外快取,資料庫檔案已經更新但介面顯示的比對結果沒變化,重啟一次客戶端通常能解決。

排查思路建議按「檔案是否放對目錄 → 格式是否符合核心 → 設定欄位是否被覆蓋 → 網路能否存取更新位址」的順序逐項確認,大部分資料庫相關的分流異常都能在這幾步裡定位到原因。