GeoIP 與 GeoSite 資料庫更新指南:分流規則失準的根源與解決
解釋 GeoIP、GeoSite 資料庫在規則匹配中的角色,示範手動替換與設定內自動更新兩種方式,並分析資料庫過舊導致分流錯誤的典型表現與驗證方法。
Clash 與 mihomo 核心的分流規則並不完全依賴手寫的網域或 IP 段,大量常用規則實際引用了兩類離線資料庫:GeoIP 與 GeoSite。它們把海量 IP 段和網域歸類打包,規則檔案只需要寫一行 GEOIP,CN 或引用一個規則集,就能覆蓋成千上萬條實際位址。這帶來了設定上的簡潔,但也埋了一個容易被忽視的隱患——資料庫本身是有時效性的,過舊的資料庫會讓原本正確的規則悄悄失準。
GeoIP 與 GeoSite 到底存了什麼
這兩類資料庫解決的是同一個問題的兩個維度:一個按 IP 歸類,一個按網域歸類。理解它們的差異,是排查分流異常的前提。
| 維度 | GeoIP | GeoSite |
|---|---|---|
| 儲存內容 | IP 位址段與所屬國家/地區代碼的對應 | 網域與業務分類標籤的對應 |
| 常見檔案 | Country.mmdb / geoip.metadb | geosite.dat / GeoSite.dat |
| 典型規則寫法 | GEOIP,CN,DIRECT | RULE-SET,geosite-google,PROXY |
| 更新觸發原因 | IP 段重新分配、雲端廠商機房遷移 | 新網域上線、CDN 網域變更 |
mihomo 核心在啟動時會把這兩類資料庫載入記憶體,之後每一次連線比對規則,都會去查表——查一個 IP 屬於哪個國家,或者一個網域歸屬哪個分類。資料庫裡沒有的內容,自然無法命中對應規則,只能繼續往下比對,通常會落到規則表最後的 MATCH 兜底策略上,而這往往和期望的出口不一致。
資料庫過舊會帶來哪些具體症狀
資料庫老化不會報錯,也不會在介面上提示「請更新」,它是一種沉默的偏差,只能透過分流結果的異常反推出來。以下是幾種高頻表現:
- 新上線的服務被誤判為台灣本地位址:某些雲端服務商會把新申請的 IP 段劃歸特定地區,如果 GeoIP 資料庫沒有及時收錄這次劃分,新服務的連線可能被地區判定規則錯誤地判定為本地 IP,走了直連,導致連線超時或存取失敗。
- 規則集寫對了但完全不命中:引用某個分類的 GeoSite 規則集(例如按串流媒體或社交應用分類),如果該分類近期新增了網域而資料庫未更新,新增網域會繞過規則集,落到預設策略,表現為「同一個應用,部分功能走代理,部分直連」。
- 本地網站偶發性走代理:反過來,如果某個 IP 段被雲端廠商收回或轉讓給境外主體,舊資料庫仍標記為本地,會導致本該直連的網站被錯誤地推入代理出口,速度明顯變慢。
- 延遲測試正常但實際存取異常:節點延遲測試走的是固定測速位址,不經過完整的網域/IP 分流判斷,所以資料庫過舊引發的問題往往在節點測速階段完全不可見,只有真實存取業務網域時才會暴露。
如果最近沒有改動過任何規則或訂閱,但某些網站突然分流異常,先懷疑 GeoIP/GeoSite 資料庫版本,而不是急著重寫規則——多數情況下規則本身沒有問題。
手動替換資料庫檔案
手動替換是最直接、最可控的方式,適合排查階段確認問題,或是對自動更新機制不放心的情境。核心步驟只有三步:找到核心的資料目錄、下載最新資料庫檔案、重新啟動核心使其重新載入。
- 確認資料目錄位置:mihomo 核心預設會在其工作目錄下尋找
Country.mmdb與geosite.dat(或對應的.metadb格式)。桌面端一般在設定目錄同層,iOS 用戶端通常在應用內的規則/資料管理頁面單獨列出這兩項,不需要手動定位檔案系統路徑。 - 取得最新資料庫:資料庫隨 mihomo 相關開源專案的規則集儲存庫持續維護並發布更新,發布節奏通常是數週一次,遇到 IP 段大範圍調整或熱門網域遷移時會有針對性的修補版本。
- 替換並重新啟動:用新檔案覆蓋舊檔案後,必須完整重新啟動核心(重新載入設定通常不會重新載入資料庫檔案),否則記憶體中仍是舊版本的對應表,替換動作不會生效。
如果用戶端提供了圖形化的「更新 GeoIP/GeoSite」按鈕,優先使用該入口,它會自動處理檔案驗證與重新啟動流程,比手動操作檔案系統更不容易出錯。
設定內自動更新的兩種方式
手動替換終究是被動的,更推薦的是在設定裡開啟自動更新,讓核心按週期自查。mihomo 提供了兩層可以分別設定的更新機制。
第一層:核心級 GeoIP/GeoSite 自動更新
這一層控制的是核心內建的地理資料庫本身,在設定檔頂層設定:
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://example-mirror.invalid/country.mmdb"
geosite: "https://example-mirror.invalid/geosite.dat"geo-update-interval 的單位是小時,決定核心每隔多久檢查一次遠端是否有新版本;geox-url 可以指向自建或第三方鏡像位址,加速下載或規避存取不穩定的問題。開啟後無需人工干預,核心會在背景靜默完成更新。
第二層:規則集(rule-providers)的獨立更新
如果分流規則用的是外部規則集而不是核心內建的 GeoSite 分類,更新週期要單獨在每個 rule-provider 裡宣告:
rule-providers:
reject-list:
type: http
behavior: domain
url: "https://example-mirror.invalid/reject.txt"
path: ./rules/reject.yaml
interval: 86400interval 單位是秒,86400 即一天一次。規則集與核心自帶的 GeoIP/GeoSite 是兩套獨立的更新通道,只開啟一邊並不能覆蓋另一邊,這也是「更新了資料庫但規則仍然不準」的常見原因之一。
自動更新依賴用戶端在背景保持執行或按計畫喚醒,長期不啟動用戶端的裝置,建議搭配手動更新入口定期檢查一次。
更新後如何驗證生效
替換檔案或改完設定之後,不要憑感覺判斷「應該好了」,而是走一套可重現的驗證流程。
- 查看啟動日誌:核心重新啟動時會列印資料庫載入資訊,包括檔案路徑與記錄筆數,如果日誌裡出現下載失敗或檔案驗證異常的提示,說明更新並未真正落地,規則仍在用舊資料。
- 用已知邊界位址測試:挑選一個最近確認發生過歸屬變化的網域或 IP,分別在更新前後測試其分流結果,如果出口策略發生了預期中的變化,說明新資料庫確實被載入並參與了比對。
- 核對規則集項目數:部分用戶端的規則管理介面會顯示每個規則集目前包含的網域或 IP 筆數,更新前後筆數明顯變化,是資料庫確實刷新的直接證據。
- 清空連線快取後重測:一些核心會對已建立的連線結果做短時快取,驗證前先斷開重連或重新啟動用戶端,避免被舊快取結果干擾判斷。
驗證環節看似繁瑣,但比「更新完就當結束」更能避免反覆排查同一個問題——資料庫相關的分流異常往往隱蔽且滯後,提前建立一套驗證習慣,能省下大量後續的日誌翻查時間。
規劃一個可持續的更新節奏
對絕大多數使用情境而言,開啟核心級自動更新並設定 12~24 小時的檢查間隔已經足夠,沒有必要追求分鐘級的即時同步,GeoIP 與 GeoSite 資料庫的上游發布節奏本身也不支援這種頻率。如果觀察到分流問題反覆出現在同一類服務上,更值得做的是針對性地檢查該分類對應的規則集來源是否仍在維護,而不是無限縮短更新間隔。資料庫更新只是分流準確性的其中一環,搭配定期查看執行日誌、留意規則比對結果,才能把偶發的分流偏差控制在最小範圍。