進階設定 預計閱讀 12 分鐘

GeoIP 與 GeoSite 資料庫如何更新：mihomo 規則資料維護與常見錯誤

說明 GeoIP／GeoSite 資料庫的用途、儲存路徑與更新方式，涵蓋用戶端內建更新、手動替換及下載失敗的處理，並提供規則比對未生效的排查方向。

GeoIP 與 GeoSite分別解決哪些問題

mihomo 讀取代理規則時，需要逐條比對網域名稱、IP 位址或其他連線屬性。GeoIP 與 GeoSite 都是規則判斷所需的資料，但處理的對象不同。資料庫未更新，不代表所有代理連線都會中斷；更常見的情況是地區判斷過時、新網域未被命中，或啟動時直接提示資料檔案遺失。

GeoIP 依目標 IP 所屬地區分類

GeoIP 資料記錄 IP 位址區段與國家、地區等資訊的對應關係。設定中的 GEOIP,CN,DIRECT 表示：連線取得目標 IP 後，若該位址屬於 CN 分類，就採用 DIRECT 策略。常見檔案包括 Country.mmdb、geoip.dat，實際讀取哪一個取決於 mihomo 設定、用戶端版本與資料模式。

GeoIP 的判斷發生在 IP 層。若網域先解析到錯誤位址、DNS 回應遭到污染，或前面的網域規則已經命中，後續 GEOIP 規則都不會改變已完成的比對。因此，看到「中國大陸網站走代理」時，不能只檢查資料庫日期，也要確認規則順序與 DNS 結果。

GeoSite 依網域名稱集合分類

GeoSite 儲存的是整理過的網域名稱集合。例如 GEOSITE,cn,DIRECT 用來比對 cn 分類中的網域，GEOSITE,category-ads-all,REJECT 則可處理相應分類。常見資料檔名為 geosite.dat。GeoSite 不負責判斷伺服器 IP 屬於哪個國家，而是直接處理請求中的網域名稱。

網域服務新增入口、調整 CDN 網域或更換 API 後，舊版 GeoSite 可能沒有相應記錄。此時連線通常會繼續套用後續規則，例如 MATCH，而不是跳出「資料庫已過期」提示。這也是 GeoSite 問題經常被誤判為節點或訂閱故障的原因。

資料類型 主要輸入 典型規則 常見檔案
GeoIP 目標 IP 位址 GEOIP,CN,DIRECT Country.mmdb、geoip.dat
GeoSite 請求網域 GEOSITE,cn,DIRECT geosite.dat
Rule Provider 外部規則項目 RULE-SET,private,DIRECT YAML、文字或二進位規則集

更新前確認核心、模式與實際資料目錄

同一個桌面用戶端可能先後使用過 Clash Premium、Clash Meta 或 mihomo 核心。舊設定目錄中也可能同時保留多個同名檔案。手動替換前，先在用戶端的「關於」、「核心」或「執行日誌」頁面確認目前使用的核心。建議使用仍在維護中的 mihomo 穩定版，並記錄更新前的核心版本與資料檔案修改時間。

從執行參數確認目錄

mihomo 的資料目錄通常由啟動參數 -d 指定。例如啟動指令中出現 mihomo -d /home/user/.config/mihomo，資料庫就應放在該目錄，而不是可執行檔所在的目錄。桌面用戶端會替使用者傳入自己的資料目錄，因此不能只依作業系統猜測路徑。

  • 優先使用用戶端內的「設定」→「設定目錄」或「開啟資料目錄」入口。
  • 如果介面沒有入口，可在執行日誌開頭尋找 configuration directory、home directory 或 -d 後面的路徑。
  • Windows 可在工作管理員的處理程序詳細資料中確認可執行檔，再從用戶端日誌查看啟動參數。
  • macOS 用戶端的資料通常位於使用者資料庫內，但不同應用程式使用的容器目錄不同，應以日誌和介面入口為準。
  • Linux 服務由 systemd 啟動時，可使用 systemctl cat mihomo 查看 ExecStart 中的 -d 參數。

確認目前使用 MMDB 還是 DAT

mihomo 支援不同的地理資料格式。設定啟用 geodata-mode: true 時，通常會搭配 geoip.dat 與 geosite.dat；未啟用此模式的設定，可能使用 Country.mmdb 進行 GEOIP 判斷。不同版本的預設行為可能有所調整，因此應同時查看設定與啟動日誌，不要只根據檔案是否存在來推斷。

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

geo-update-interval 的單位是小時。設定為 24 表示核心每隔一天檢查資料更新。若用戶端會產生執行設定，直接修改產生的檔案，可能在下次啟動或切換訂閱後被覆蓋；應在用戶端的覆寫、Mixin 或全域擴充設定中加入這些鍵。

優先使用用戶端內建更新

支援 mihomo 的用戶端通常會提供 GeoData 或地理資料更新入口。介面名稱會隨版本變化，常見位置是「設定」→「Clash 設定」→「GeoData」，或「設定」→「核心」→「更新地理資料」。操作時不要連續點擊；單次下載可能包含數十 MB 的資料，網路速度較慢時需要等待日誌顯示完成。

  1. 先更新並啟用目前的設定，確認核心能正常啟動。
  2. 開啟「設定」中的 GeoData、地理資料或核心資料頁面。
  3. 分別執行 GeoIP、GeoSite 或全部更新。
  4. 等待介面顯示完成，再檢查日誌中是否出現 download、unmarshal、permission denied 等資訊。
  5. 重新載入設定；如果用戶端沒有重新載入按鈕，就完全結束應用程式後重新啟動。
  6. 在連線記錄中觀察一個已知網域實際命中了哪一條規則。

內建更新的優點是用戶端知道自己的資料目錄，也能在下載後以正確檔名寫入。對啟用服務模式或管理員輔助程序的桌面用戶端而言，這種方式還能避免一般使用者程序沒有目錄寫入權限的問題。

啟用 mihomo 自動更新

需要長時間運作的路由器、伺服器或桌面裝置，可以由 mihomo 定期更新。除了開啟 geo-auto-update，也可透過 geox-url 指定各類檔案的網址。網址必須直接回傳對應的二進位檔案，不能回傳發布頁面或需要瀏覽器確認的 HTML 頁面。

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

geox-url:
  geoip: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat"
  geosite: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat"
  mmdb: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/country.mmdb"

如果裝置必須透過代理才能存取下載網址，需先確保核心啟動後能建立對外連線。首次啟動時資料庫尚不存在，而規則又依賴 GeoSite，可能形成「沒有資料庫就無法啟動，核心不啟動又無法下載」的循環。此時先手動放入可讀取的資料檔案，再啟用自動更新會更穩妥。

手動替換 GeoIP 與 GeoSite 檔案

用戶端內建更新失敗、離線裝置需要維護，或目前網路無法存取資料來源時，可以手動替換。正確流程不是直接覆蓋正在讀取的檔案，而是先下載到暫存檔名，停止核心，完成替換後再啟動。這樣可降低下載中斷留下半個檔案的機率。

通用替換步驟

  1. 在用戶端中停止系統代理與 TUN，再結束應用程式；服務模式還要停止對應的背景服務。
  2. 開啟前文確認的資料目錄，記錄原檔案的大小與修改時間。
  3. 將舊檔案重新命名為 geoip.dat.bak、geosite.dat.bak 或 Country.mmdb.bak。
  4. 將新檔案複製到同一個目錄，並保留核心要求的正確檔名。
  5. 確認目前使用者或服務帳戶具有讀取權限。
  6. 啟動用戶端並查看最早一段日誌；確認設定載入完成後，再開啟系統代理或 TUN。
  7. 保留備份直到驗證結束，確認常用網域規則正常後再刪除。

Linux 或 macOS 環境可以先寫入暫存檔，再使用同一檔案系統內的重新命名完成替換。以下指令需要在 mihomo 實際資料目錄中執行：

curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" -o geoip.dat.new
curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" -o geosite.dat.new

mv geoip.dat geoip.dat.bak
mv geosite.dat geosite.dat.bak
mv geoip.dat.new geoip.dat
mv geosite.dat.new geosite.dat

Windows 手動替換時，如果檔案總管提示檔案正在使用中，表示關閉用戶端視窗後，核心程序或服務仍在執行。應先在用戶端停止服務，或在「工作管理員」→「詳細資料」中確認 mihomo 程序已結束。不要透過反覆覆蓋來繞過檔案佔用提示。

容器與路由器的額外檢查

Docker 部署需要確認資料庫目錄確實透過 volume 掛載到容器使用的 -d 路徑。只替換主機上一個未掛載的目錄，容器內部不會有任何變化。更新後可重新啟動容器，並從日誌確認讀取路徑。OpenWrt 類型的空間有限裝置還要檢查可用容量；下載暫存檔與保留備份時，瞬間使用量可能接近兩到三份資料檔案的大小。

下載失敗與啟動錯誤如何處理

context deadline exceeded 或 TLS 逾時

這類訊息通常表示下載網址未能在逾時期限內完成連線或傳輸。先使用瀏覽器或 curl -I -L 測試同一網址是否能跟隨重新導向，再檢查 DNS、系統時間與對外連線策略。系統時間相差幾分鐘，就可能導致 TLS 驗證失敗。若連線必須經過代理，請確認更新請求實際使用的是可用策略，而不是被 GEOIP 或 MATCH 規則送往失效節點。

回傳 403、404 或下載到 HTML

404 通常表示檔名、發布路徑或資料來源結構已經變更。403 常見原因包括存取頻率限制、網路出口限制，或網址需要額外授權。另一種情況是 URL 指向發布介紹頁，下載結果其實是 HTML。mihomo 隨後會回報解析失敗、格式無效或無法載入資料庫。應改用直接檔案網址，並確認重新導向後的回應類型與檔案大小合理。

permission denied 或檔案無法寫入

先確認錯誤路徑就是目前的資料目錄。Windows 服務模式下，介面程序與背景服務可能使用不同帳戶；Linux systemd 服務也可能透過 User= 指定受限帳戶。目錄必須允許該服務帳戶建立暫存檔、重新命名檔案並讀取更新結果。只替單一舊檔案增加寫入權限，仍可能因目錄不可寫入而失敗。

no such file、MMDB 無法開啟或 GeoSite 載入失敗

這類錯誤應優先檢查檔名大小寫、設定模式與目錄。Linux 會區分 GeoSite.dat 與 geosite.dat。如果設定啟用了 geodata 模式，卻只放入 Country.mmdb，GeoSite 規則仍無法運作；反過來，依賴 MMDB 的設定只有 geoip.dat 也不夠。恢復備份後能啟動，通常表示新檔案不完整、格式不符，或來源與目前核心不相容。

資料庫已更新，規則為什麼仍未生效

規則引擎會依設定中的順序由上而下進行比對，命中後通常不會繼續尋找「更合適」的規則。更新資料庫只會改變 GEOIP 或 GEOSITE 可查詢的資料，不會自動調整規則順序。因此，排查時要在連線記錄中找到目標請求，查看網域、目標 IP、命中規則與最終策略。

前置規則已攔截請求

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

在這份設定中，即使 example.com 已被 GeoSite 的 cn 分類收錄，第一條 DOMAIN-SUFFIX 仍會先命中 Proxy。更新 GeoSite 不會覆蓋前置規則。暫時將特定規則移到適當位置，重新載入後再次測試，才能確認是否為順序問題。

no-resolve 改變了 GEOIP 的適用條件

GEOIP,CN,DIRECT,no-resolve 的作用之一，是避免規則為了進行比對而主動觸發額外的 DNS 解析。如果目前連線只有網域、尚未取得可用於判斷的目標 IP，這條規則可能無法產生預期結果。設定中已有 GEOSITE 網域規則時，通常先依網域分類，再用 GEOIP 處理剩餘的 IP 連線，邏輯會更清楚。

DNS 模式與嗅探結果會影響可見網域

TUN 模式下，應用程式可能直接連線至 IP，也可能透過 QUIC、加密 DNS 或內建解析器發起請求。若 mihomo 沒有取得網域名稱，GeoSite 就沒有可供比對的輸入。啟用網域嗅探可以涵蓋部分情境，但不應將嗅探視為所有連線都能還原網域的保證。排查時可比較系統代理模式與 TUN 模式下的連線詳細資料，確認記錄中是否出現完整網域。

編輯的是訂閱原始檔，不是執行設定

桌面用戶端經常會將訂閱、覆寫內容與全域設定合併為暫時的執行設定。直接修改快取中的訂閱 YAML，下次更新訂閱就會還原；直接修改執行設定，下次切換設定也會消失。應在用戶端的「設定」→「覆寫」或「設定」→「全域擴充」中儲存自訂項目，再透過日誌或設定檢查功能確認最終結果。

Rule Provider 沒有隨 GeoData 更新

RULE-SET 引用的外部規則集由 rule-providers 管理，擁有自己的 URL、快取路徑與更新間隔。更新 geoip.dat 與 geosite.dat 不會重新整理這些 Provider。若實際命中的是 RULE-SET，應在用戶端的規則集頁面執行更新，或檢查對應 Provider 的 interval 與下載日誌。

一份可重複執行的維護清單

一般桌面裝置不必每天手動替換資料庫。更實用的做法是讓用戶端或 mihomo 每 24 小時檢查一次，並在分類異常時依固定步驟定位。伺服器與路由器則應將資料目錄、備份及服務帳戶權限一併納入維護。

  • 確認目前使用 mihomo 核心，並記錄版本號。
  • 從啟動參數或日誌確認實際資料目錄。
  • 檢查設定使用 DAT 模式還是 MMDB 模式。
  • 優先透過用戶端內建入口更新一次。
  • 查看日誌，確認下載、寫入與重新載入都已完成。
  • 手動替換時先停止核心，保留一份可還原的舊檔案。
  • 利用連線記錄驗證網域、目標 IP、命中規則與最終策略。
  • 分別檢查 GeoData、訂閱規則與 Rule Provider，不要將三者視為同一項更新。
  • 如果結果仍不正常，依序排查規則順序、DNS、TUN、嗅探與執行設定。

判斷維護是否成功，不能只看按鈕顯示「更新完成」。至少應分別測試一個 GeoSite 網域規則、一個 GEOIP 位址規則與一個 Rule Provider 規則。連線記錄中能看到預期的規則名稱與策略，且重新啟動用戶端後結果仍維持一致，才表示檔案路徑、設定模式與更新機制已正確銜接。

Clash 最新版下載