進階技巧 · 預計閱讀 9 分鐘

GeoIP 與 GeoSite 資料庫更新方法：分流規則失準的排查與修復

分流突然把台灣網站也走了代理，或者境外服務被判定成了直連？多數情況下不是規則寫錯了，而是本地的 GeoIP/GeoSite 資料庫過舊。本文梳理這兩類地理資料庫的作用機制、手動與自動更新方式，以及更新後規則依舊不生效時的排查順序。

GeoIP 與 GeoSite 到底是什麼

Clash 系設定檔裡常見這樣的規則寫法：

rules:
  - GEOIP,CN,DIRECT
  - GEOSITE,google,Proxy
  - GEOSITE,cn,DIRECT
  - MATCH,Proxy

這裡的 GEOIP,CN 和 GEOSITE,google 並不是核心自己判斷出來的，而是查表得到的結果。查的表就是兩份預先編譯好的地理資料庫：

  • GeoIP 資料庫（常見檔名 Country.mmdb 或 geoip.dat）：把全球 IP 段劃分到對應國家/地區代碼，核心收到一個目標 IP 後先查這張表，得到類似 CN、US、HK 這樣的歸屬地，再對照規則決定直連還是走代理。
  • GeoSite 資料庫（常見檔名 geosite.dat 或 geosite.db）：把常見網域或網域尾碼歸類到預設分組，例如 cn、google、github、netflix，命中分組即觸發對應策略。

這兩份資料庫都是社群維護的靜態檔案，跟隨上游專案（如 Loyalsoldier 的規則集、v2fly 的 domain-list-community）定期重新編譯發布，本身不會隨核心升級自動更新，也不會因為你換了訂閱就刷新。它們更像是一份「字典」，字典印刷的時間點決定了查得到還是查不到。

資料庫過舊為什麼會讓分流「失準」

網際網路的 IP 段分配和網域歸屬並不是一成不變的：雲端服務商的 IP 池會擴容或遷移，CDN 節點會在不同地區之間調度，新上線的網域短期內根本不在任何分組裡。如果本地資料庫停留在幾個月甚至一兩年前的版本，就會出現兩種典型症狀：

  • 該直連的走了代理：台灣本地網站換用了新的 IP 段或接入了新 CDN，舊版 GeoIP 庫裡查不到歸屬為 CN 或當地代碼，規則判定失敗後落到預設策略（通常是代理），表現為存取明顯變慢、偶爾連接失敗。
  • 該代理的卻被直連：某個境外服務更換了網域或增加了新的子網域，舊版 GeoSite 分組裡沒有收錄，規則比對不到對應分組，最終被 MATCH,DIRECT 之類的兜底規則接管，直接暴露在沒有代理的網路環境下。

注意：規則檔案本身沒有任何改動，只是底層查詢用的資料庫過期，這種問題往往被誤判為「訂閱出問題了」或「規則寫錯了」，排查方向一旦錯了會浪費大量時間。

先確認目前資料庫版本與更新時間

動手更新前，先確認問題確實出在資料庫上。不同用戶端查看方式略有差異，但思路一致：找到資料庫檔案的最後修改時間，對比上游發布記錄。

  1. 在用戶端的「核心/規則」設定頁面，通常能看到 GeoIP、GeoSite 檔案的本地路徑與最後更新時間戳；部分用戶端會直接標註版本號或提交雜湊前幾位。
  2. 若用戶端介面沒有暴露這個資訊，可以進入設定目錄直接查看 Country.mmdb、geosite.dat 檔案的修改日期，安卓端一般在應用程式私有目錄下的 data 或 geo 子目錄。
  3. 對照上游倉庫的發布日期（GeoIP 庫和 GeoSite 庫通常按週或按雙週更新一次），如果本地檔案的時間落後超過一個月，基本可以確定需要手動刷新。

另一個更直接的驗證方法：暫時在設定裡加一條明確的網域或 IP 規則，指向一個你懷疑分流出錯的目標，觀察是否命中兜底策略而不是預期分組——如果精確規則生效但 Geo 規則不生效，問題基本鎖定在資料庫本身。

手動更新資料庫的步驟

手動更新的核心思路是：從可信的規則集倉庫下載最新編譯好的資料庫檔案，替換掉用戶端設定目錄下的舊檔案，再重啟核心或重新載入設定。

  1. 確認用戶端使用的核心版本：Clash 原版、Clash Meta、mihomo 三者對資料庫檔案的格式要求不完全一致，mihomo 在部分版本上支援更細粒度的規則集格式，替換前先確認目前核心能讀取的檔案類型（.mmdb / .dat / .db）。
  2. 取得最新資料庫檔案：從對應上游規則集專案的發布頁面下載最新版本，檔名與用戶端設定中 geodata-url、geoip-url 或本地路徑要保持一致，避免下載後檔名不符導致用戶端仍讀取舊檔案。
  3. 替換本地檔案：將下載好的檔案放入用戶端設定目錄中原檔案所在位置，建議先備份舊檔案再覆蓋，防止新檔案本身損壞時無法回退。
  4. 重啟核心或重新載入設定：多數用戶端在替換檔案後需要重啟代理服務才能重新載入資料庫，僅刷新訂閱或切換節點通常不會觸發資料庫重新讀取。
  5. 驗證生效：重啟後存取此前判定錯誤的網站，或查看用戶端連線日誌中該請求命中的規則名稱，確認已經落在預期分組下。
# 以 mihomo 核心命令列為例，手動替換後重新載入設定的典型操作
# 1. 停止正在運行的服務
systemctl stop mihomo
# 2. 用新檔案覆蓋舊的 GeoIP / GeoSite 資料庫
cp Country.mmdb /etc/mihomo/Country.mmdb
cp geosite.dat /etc/mihomo/geosite.dat
# 3. 重新啟動
systemctl start mihomo

設定自動更新，避免重複過期

手動更新能解決一次性問題，但過一段時間資料庫又會重新過期。更可靠的做法是在設定檔裡宣告資料庫的遠端位址和更新週期，讓用戶端在啟動或定時任務中自動拉取最新版本。

以支援該欄位的核心為例，設定檔中通常會有類似結構：

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: "https://example.com/Country.mmdb"
  geosite: "https://example.com/geosite.dat"
  • geo-auto-update：是否允許核心在背景自動檢查並下載新版本資料庫。
  • geo-update-interval：自動檢查的間隔（單位小時），設定過短會增加不必要的網路請求，一般 24 小時一次已經足夠跟上上游發布節奏。
  • geox-url：指定資料庫的下載來源位址，如果預設來源在你的網路環境下存取緩慢，可以替換為鏡像位址，但要確認鏡像同步的時效性，否則等於換了個地方繼續用舊資料。

不是所有用戶端圖形介面都暴露了這幾個欄位的設定入口，如果介面上沒有對應開關，可以在「編輯設定檔」或「進階設定」裡直接以文字方式加入上述欄位，儲存後重啟服務生效。

更新後規則依舊不生效怎麼排查

如果已經確認下載的是最新資料庫，替換後問題依舊存在，按下面的順序逐項排查，通常能定位到具體環節。

  1. 確認檔案確實被替換了：查看檔案的修改時間與大小是否發生變化，有些用戶端會把資料庫快取在多個位置（如安裝目錄與使用者設定目錄並存），替換錯了位置等於沒替換。
  2. 確認核心真正重新載入了檔案：部分用戶端的「重啟」按鈕只重啟介面程序，不會重啟底層核心服務，需要在系統層面徹底停止再啟動對應程序或服務。
  3. 檢查規則順序是否被更靠前的規則攔截：Clash 規則是自上而下按順序比對的，如果 GEOSITE,cn,DIRECT 之前存在一條覆蓋範圍過寬的規則（例如某個寬泛的 DOMAIN-SUFFIX 或 IP-CIDR），會導致目標請求提前命中，根本走不到 Geo 規則那一步。
  4. 檢查訂閱是否覆蓋了本地規則集設定：如果使用的是「訂閱轉換」服務生成的設定，某些轉換規則會在生成階段就寫入了自己的 Geo 資料來源位址，本地手動替換的檔案可能根本沒有被引用到。
  5. 查看連線日誌確認實際比對到的規則名：多數用戶端提供即時日誌或連線面板，能看到每條請求具體命中了哪一條規則，這是判斷問題出在資料庫還是規則順序上最直接的方式。

建議：排查時優先打開連線日誌逐條比對，比反覆猜測規則寫法效率高得多，大多數「分流不準」的問題都能在日誌裡直接看到命中的是哪一條規則。

建立長期維護習慣

Geo 資料庫的過期是持續性問題，不是修一次就永久解決的。建議養成以下習慣，減少後續再次踩坑的機率：

  • 啟用自動更新欄位後，每隔一段時間人工確認一次資料庫的實際更新時間，避免自動更新任務因網路問題靜默失敗而毫無察覺。
  • 更換訂閱或規則集來源時，留意其中是否內建了自己的 Geo 資料來源位址，防止和本地手動維護的設定產生衝突。
  • 規則檔案改動較大時，先在測試環境或獨立的設定分組裡驗證，再合併進日常使用的主設定，避免線上分流大範圍異常。
  • 關注上游規則集專案的更新日誌，尤其是台灣或當地常用服務大規模遷移 IP 段或網域結構調整的時期，及時手動刷新一次資料庫比等待自動更新週期更穩妥。
下載用戶端