GeoIP 與 GeoSite 資料庫過期怎麼辦:更新方式與規則比對原理

GeoIP 與 GeoSite 資料庫究竟是什麼

打開一份典型的 Clash 或 mihomo 設定檔,規則區塊裡常能看到 GEOIP,CN,DIRECT 或 GEOSITE,netflix,Proxy 這類寫法。這兩條規則背後依賴的,正是 GeoIP 資料庫與 GeoSite 資料庫。它們並不是設定檔的一部分,而是獨立打包、需要另外下載與更新的二進位資源檔,通常命名為 geoip.dat(或 geoip.metadb)與 geosite.dat,後者在 mihomo 核心裡也常以 Country.mmdb 之類的 MaxMind 資料庫格式出現。

GeoIP 資料庫記錄的是「IP 位址段屬於哪個國家或地區」的對應關係,例如某一段 IPv4/IPv6 網段被標註為 CN(中國大陸)、US(美國)、JP(日本)等。GeoSite 資料庫記錄的則是「網域或網域後綴屬於哪個分類」,例如 geolocation-cn 分類收錄了大量中國大陸常用網站的網域規則,netflix、google、telegram 等分類則對應特定服務商的網域集合。兩者共同構成規則型代理設定裡最基礎的判斷依據:客戶端在收到一次連線請求後,先判斷目標是網域還是 IP,再到對應的資料庫裡查表,確定它屬於哪個分類,最後依設定裡的規則決定走直連、走代理,還是拒絕。

規則比對是怎麼用上這兩個資料庫的

理解比對流程,有助於判斷資料庫過期時問題出在哪一環。以一組常見規則為例:

rules:
  - GEOSITE,geolocation-cn,DIRECT
  - GEOSITE,netflix,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

當客戶端要存取某個網域時,核心會先嘗試依網域規則比對——查 GeoSite 資料庫裡 geolocation-cn 分類是否包含該網域(或其父網域、萬用後綴),命中就直連;不命中則接著比對 netflix 分類,命中就走代理群組 Proxy。若網域規則全部未命中,核心會先完成 DNS 解析取得 IP 位址,再用 GeoIP 資料庫查這個 IP 屬於哪個國家,命中 CN 就直連,否則落到最後的 MATCH 兜底規則走代理。

這個流程說明一件事:GeoSite 負責網域維度的分類,GeoIP 負責 IP 維度的分類,兩者是互補關係而非替代關係。很多用戶遇到「明明設定裡寫了走代理的規則,存取某個網站卻還是直連」,或反過來的情況,根源往往不是規則寫錯,而是資料庫裡缺少這個網域或 IP 段的最新記錄——資料庫沒跟上服務商實際使用的基礎設施變化。

提示GeoIP/GeoSite 資料庫是社群持續維護的開源規則集,更新頻率通常介於每天到每週不等,取決於所選規則集的來源倉庫,和客戶端軟體本身的版本更新週期沒有必然關係。

資料庫過舊會帶來哪些常見情況

由於網際網路服務商經常更換或擴充所用的 IP 段與網域(尤其是 CDN 節點、雲端服務出口 IP),而 GeoIP/GeoSite 資料庫需要人工或自動化腳本定期抓取、校驗、打包發布,兩者之間天然存在延遲窗口。資料庫過舊時,常見症狀包括:

該直連的網站卻走了代理:某個中國大陸常用網站換了一批伺服器 IP,舊資料庫裡該 IP 段仍歸類為境外或未分類,導致本該走 DIRECT 的流量被兜底規則送進代理群組,增加不必要的延遲。
該代理的服務卻被直連:反過來,某些串流或社群平台調整了網域結構或新增子網域,舊版 GeoSite 分類沒有收錄這些新網域,導致請求比對不到對應規則,落到預設直連,結果存取失敗或出現區域限制提示。
分流規則整體「變鈍」:隨著時間推移,越來越多連線比對不到任何精確規則,全部靠最後的 MATCH 兜底處理,規則集本身形同虛設,代理群組的負載與延遲表現都會變差。
區域網路或內網服務異常:若自訂了私有網段規則卻依賴舊版 GeoIP 資料比對,某些內部服務的判斷也可能出現偏差,尤其是在啟用 TUN 模式做全域接管的情境下更容易暴露問題。

這些情況單獨出現時容易被誤判成「訂閱節點品質差」或「客戶端有 bug」,但如果同時伴隨「以前正常、最近變慢或變得不準」的時間線,基本可以把嫌疑鎖定在資料庫版本上。

三種更新方式比較

目前主流 Clash / Clash Meta(mihomo)客戶端支援的更新方式大致分三類,各有適用情境。

方式一:客戶端內建更新按鈕

大多數圖形化客戶端(如 Clash Verge Rev、FlClash 等)在設定頁裡提供「更新 GeoIP/GeoSite 資料庫」或「更新核心資源」的按鈕,點擊後會從內建的預設來源抓取最新打包檔並覆蓋本機快取。這是最省心的方式,不需要理解檔案結構,適合絕大多數日常使用者。缺點是更新來源通常固定為軟體作者選定的倉庫鏡像,若該鏡像在特定網路環境下連線不穩定,更新可能失敗或很慢,此時需要手動介入。

方式二:手動下載檔案替換

對於命令行或不提供圖形按鈕的部署方式,可以直接從規則集的發布倉庫下載對應的 geoip.dat、geosite.dat(或 mihomo 對應的 .metadb/.mmdb 檔案),替換掉客戶端設定目錄下的同名舊檔,再重新啟動核心或觸發設定重載即可生效。這種方式的優勢是可控性強,可以精確選擇某個規則集版本;需要注意的是檔案命名與放置路徑必須與客戶端期望的一致,放錯目錄會導致更新後依舊讀取舊快取。

方式三:設定檔欄位指定更新來源

mihomo 核心支援在設定檔裡透過專屬欄位宣告地理資料庫的下載位址與自動更新策略,常見欄位包括:

geodata-mode: true
geodata-loader: standard
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://例如-你信任的鏡像位址/geoip.dat"
  geosite: "https://例如-你信任的鏡像位址/geosite.dat"

geo-auto-update 開啟後,核心會依 geo-update-interval(單位小時)設定的週期自動檢查並下載新版本,geox-url 則允許把預設來源換成自選的鏡像位址,適合搭配自建鏡像或對存取速度有特殊要求的情境。這種方式最靈活,但也最依賴使用者對設定欄位語義的準確理解,填錯欄位名稱或格式會導致核心啟動報錯,建議變更前先備份原設定。

更新方式	操作難度	適用人群	可控程度
客戶端內建按鈕	低	日常使用者	低
手動替換檔案	中	熟悉檔案目錄結構的用戶	中
設定欄位指定來源	高	自建設定 / 長期維護者	高

更新後如何驗證是否生效

更新動作完成不代表規則一定已經生效,建議依下面的順序做一次簡單驗證:

查看客戶端的日誌面板或執行紀錄,確認出現類似「geoip database loaded」「geosite updated」的提示,而不是靜默失敗。
選一個已知近期變更過 IP 或網域的網站作為測試對象,清除瀏覽器 DNS 快取後重新存取,觀察連線實際走的是哪個代理群組(多數客戶端的連線面板會即時顯示每條連線命中的規則名稱)。
如果客戶端支援規則測試或「查詢規則」功能,直接輸入網域/IP 查看比對結果,比反覆試錯存取網頁更直接。
確認系統或應用層的 DNS 快取、連線快取也已清除,避免舊的解析結果掩蓋了資料庫更新的效果。

如果驗證後發現規則依舊不準,大機率是設定檔裡規則集版本號或 URL 指向了舊位址,而不是資料庫本身沒更新成功,這時回頭檢查 geox-url 或客戶端設定裡的鏡像位址是否正確,往往比重複點更新按鈕更有效。

常見問題與排查思路

更新後規則反而「全亂了」怎麼辦不同規則集發布方對分類命名與收錄範圍會有差異,若在設定裡混用了兩個來源不同的規則集檔案,可能出現同一分類名稱定義不一致的情況。排查時先確認 rule-providers 或 geox-url 裡引用的倉庫來源是否統一,避免新舊版本混用。

另一個容易被忽略的細節是:部分客戶端會對資料庫檔案做本機快取校驗,若替換檔案後沒有清除快取目錄裡的舊索引,重新啟動後仍可能讀到舊資料。遇到「檔案明明換了,行為卻沒變」的情況,可以嘗試完全結束客戶端行程(而不僅是重載設定),再重新啟動一次,讓核心重新初始化資料庫索引。

長期使用建議把「地理資料庫更新」當作和「訂閱連結更新」同等重要的日常維護動作——訂閱決定了有哪些節點可用,資料庫決定了流量該不該走這些節點,兩者任何一個滯後都會拖累整體的分流準確度。對大多數用戶而言,打開客戶端設定裡的自動更新開關,並定期查看一次更新紀錄,已足以應付絕大多數情境;只有在自建設定或對更新來源有特殊要求時,才需要深入到設定欄位這一層去手動管理。