進階設定 預計閱讀 12 分鐘

GeoIP 與 GeoSite 資料庫如何更新？mihomo 地理規則使用詳解

說明 GeoIP、GeoSite 資料庫在規則比對中的作用、mihomo 核心下 geodata 模式與 MMDB 的差異，以及自動更新、手動替換資料來源與 GEOIP/GEOSITE 規則的比對順序。

先分清 GeoIP、GeoSite 與規則本身

GeoIP 和 GeoSite 都是供規則引擎查詢的資料集，但兩者處理的對象不同。GeoIP 依據目標 IP 位址判斷國家、地區或區域網路範圍；GeoSite 則依據網域判斷其所屬的網站集合。設定中的 GEOIP、GEOSITE 只是查詢指令，真正的分類內容來自本機資料庫檔案。

以一次連線為例，當請求目標是網域時，mihomo 可以先使用網域規則或 GeoSite 分類進行比對；如果前面的規則沒有命中，後續 GEOIP 規則可能觸發 DNS 解析，再利用解析結果查詢 IP 資料庫。最終使用哪個策略群組，取決於規則清單中第一條命中的規則。資料庫只會回答「這個網域或 IP 屬於哪個集合」，不會自行決定直連、代理或拒絕。

資料類型 比對對象 常見檔案 典型用途
GeoSite 網域 geosite.dat 依網站類別、服務商或地區網域集合進行分流
GeoIP Dat IPv4、IPv6 位址 geoip.dat 在 geodata 模式下進行國家與地區 IP 比對
MMDB IPv4、IPv6 位址 country.mmdb 在 MMDB 模式下為 GEOIP 規則提供位置資料
ASN MMDB IP 所屬自治系統 GeoLite2-ASN.mmdb 供 ASN 類規則或相關查詢功能使用

GeoSite 不是頂級網域清單。例如 GEOSITE,cn 查詢的是資料來源維護者整理的網域集合，並不等同於只比對以 .cn 結尾的位址。使用 .com 的中國大陸服務也可能被納入該集合，分類結果取決於目前的資料庫版本。

geodata 模式與 MMDB 模式的差異

啟用 geodata-mode 時會發生什麼

設定 geodata-mode: true 後，mihomo 會使用 geoip.dat 處理 GEOIP 分類，並使用 geosite.dat 處理 GEOSITE 分類。Dat 檔案可以容納多個標籤集合，規則中常見的 CN、LAN 或特定 GeoSite 標籤，會對應到檔案內部的項目。

geodata-mode: true
geodata-loader: memconservative

geodata-loader 控制 geodata 資料的載入方式。standard 傾向預先載入，連續比對時的負擔較穩定，但會占用較多記憶體；memconservative 則偏向按需載入，適合記憶體較少的路由器或容器。以約 100 MB 可用記憶體的裝置為例，應先選用 memconservative，觀察規則載入與首次比對所需時間後，再決定是否調整。

關閉 geodata-mode 時會發生什麼

設定 geodata-mode: false 時，GEOIP 查詢通常會改用 country.mmdb。MMDB 是針對 IP 查詢的資料庫格式，無法取代 GeoSite 的網域分類，因此當設定中存在 GEOSITE 規則時，geosite.dat 仍須保持可用。

geodata-mode: false

兩種模式沒有適用於所有裝置的統一速度結論。資料庫大小、規則數量、磁碟效能和載入器設定都會影響結果。桌面系統通常更應關注資料來源的涵蓋範圍與維護頻率；低記憶體裝置則需要同時觀察 mihomo 啟動後的常駐記憶體。切換模式後應完整重新啟動核心，而不是只在介面中重新載入設定。

  • 規則大量使用 GEOSITE 與 Dat 標籤時，可優先採用 geodata 模式。
  • 現有規則主要是 GEOIP,CN，且資料來源只提供 MMDB 時，可以繼續使用 MMDB 模式。
  • 不要將 geoip.dat 重新命名為 country.mmdb，副檔名不同代表內部格式不同。
  • 切換模式前保留原始資料庫檔案，方便在分類異常或啟動報錯時還原。

設定資料庫自動更新

mihomo 可以依指定網址取得 GeoIP、GeoSite、MMDB 與 ASN 資料。核心欄位是 geo-auto-update、geo-update-interval 和 geox-url。更新間隔的單位是小時，設定為 24 表示每 24 小時檢查一次。地理分類通常不需要每分鐘更新，每天一次已能涵蓋多數桌面與家庭閘道情境。

geodata-mode: true
geodata-loader: memconservative
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"
  asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"

即使目前已啟用 geodata 模式，也可以保留 MMDB 網址，方便日後切換；不過實際由目前規則路徑使用的檔案，仍取決於模式與規則類型。若用戶端透過覆寫功能合併設定，應將這些欄位放在頂層，不可縮排到 dns、rules 或 proxy-groups 下。

更新請求走直連還是代理

資料庫下載能否成功，取決於核心執行期間是否能連線至資料網址。部分用戶端會在核心啟動初期下載檔案，此時代理策略可能尚未完全可用；另一些用戶端則會讓更新請求經過目前規則。若日誌持續出現逾時，可先在瀏覽器中確認網址可連線，再檢查 DNS、系統時間、出站規則，以及用戶端是否對核心程序設定了繞過。

排查時開啟「日誌」→「日誌層級」→「資訊」或「除錯」，然後重新啟動核心。正常流程通常會出現地理資料下載、寫入或載入紀錄。若 30 秒後仍顯示連線逾時，不要連續點擊更新按鈕；先確認資料網域命中了哪個策略群組，並檢查該策略群組目前的節點是否可用。

手動替換 GeoIP 與 GeoSite 檔案

自動更新失敗、裝置無法直接連線至資料來源，或需要固定某個資料版本時，可以手動替換檔案。關鍵是找到 mihomo 實際使用的工作目錄。命令列預設目錄常見於 Linux 與 macOS 的 ~/.config/mihomo/，Windows 則常見於 %USERPROFILE%\.config\mihomo\；如果啟動命令使用了 -d，則以 -d 後面的目錄為準。

圖形化用戶端往往使用自己的應用程式資料目錄，不一定會讀取上述預設路徑。應從用戶端的「設定」→「設定檔目錄」或「設定」→「應用程式目錄」開啟實際位置，再根據日誌中的資料庫路徑確認。不要只在檔案管理器中搜尋同名檔案，因為舊版目錄和目前執行目錄可能同時存在。

  1. 記錄目前的核心版本、geodata-mode 設定和工作目錄。
  2. 停止 mihomo 核心，避免替換過程中仍有檔案控制代碼被占用。
  3. 將原始檔案重新命名保存，例如將 geosite.dat 改為 geosite.dat.bak。
  4. 複製新檔案，並保留核心預期的名稱：geoip.dat、geosite.dat、country.mmdb 或 GeoLite2-ASN.mmdb。
  5. 重新啟動核心，查看日誌中是否出現格式不支援、標籤缺失或檔案讀取失敗。
  6. 使用一條明確的測試規則驗證比對結果，而不是只觀察用戶端是否顯示「執行中」。

替換後若出現 load GeoSite failed、invalid database 或指定標籤不存在，應先還原備份檔案，再核對資料格式與設定模式。檔案能夠下載並不代表一定適合目前核心；某些資料來源可能使用不同的標籤命名，導致 GEOSITE,cn 可用，而更細的分類標籤不可用。

GEOIP 與 GEOSITE 規則怎麼寫

一組易讀的基本順序

mihomo 會由上到下比對規則，命中後停止繼續檢查。因此更具體的規則應放在較寬泛的地理規則之前，最後使用 MATCH 作為兜底。下面的 節點選擇、中國大陸直連 必須對應設定中實際存在的策略群組名稱。

rules:
  - DOMAIN,api.example.org,節點選擇
  - DOMAIN-SUFFIX,example.org,節點選擇
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,中國大陸直連
  - GEOIP,LAN,DIRECT,no-resolve
  - GEOIP,CN,中國大陸直連
  - MATCH,節點選擇

第一條精確網域規則的優先級最高。第二條涵蓋該網域及其子網域。接著才會進行 GeoSite 分類和 GeoIP 判斷。如果把 GEOSITE,cn,中國大陸直連 放在需要特殊處理的中國大陸網站規則之前，特殊規則可能永遠沒有機會命中。

規則 輸入 是否可能觸發解析 適合位置
DOMAIN 完整網域 否 最具體的規則區域
DOMAIN-SUFFIX 網域後綴 否 具體服務分類之前
GEOSITE 網域分類 否 一般網域規則之後
GEOIP 目標 IP 目標為網域時可能觸發 網域規則之後、兜底之前
MATCH 所有剩餘連線 否 最後一條

理解 no-resolve 的適用界線

no-resolve 表示這條 IP 類規則不要為了比對而主動解析網域。它適合 GEOIP,LAN,DIRECT,no-resolve 這類主要處理已知目標 IP 的規則，可以減少額外的 DNS 查詢。但如果連線目標仍是網域，且前面沒有規則命中，這條 GEOIP 規則可能因取得不到目標 IP 而被跳過。

因此不應機械式地為每條 GEOIP 規則都加上 no-resolve。如果依賴 GEOIP,CN 作為中國大陸流量的重要兜底，就需要結合 DNS 模式、嗅探結果和實際連線類型進行測試。啟用 TUN 模式後，mihomo 接收的流量範圍更廣，但規則順序與資料庫查詢邏輯不會因此改變。

如何確認資料庫和規則確實生效

驗證時應同時檢查「檔案已載入」和「請求命中正確規則」。只看到資料庫更新時間變化，不能說明規則順序正確；只看到連線成功，也不能證明流量經過預期的策略群組。

測試一條 GeoSite 規則

  1. 暫時將目標分類指向容易辨認的策略群組，例如 中國大陸直連。
  2. 在「日誌」→「日誌層級」中選擇「資訊」或「除錯」。
  3. 清除瀏覽器現有連線，重新造訪測試網域。
  4. 檢查日誌中的規則類型、命中標籤和最終策略群組。
  5. 測試結束後還原正式設定，避免臨時規則長期保留。

測試 GEOIP 時避免快取干擾

瀏覽器可能會重用 HTTP/2 或 HTTP/3 連線，DNS 結果也可能來自系統、瀏覽器或 mihomo 快取。修改規則後，先在用戶端執行「設定」→「重新載入」，再關閉相關分頁並等待舊連線結束。必要時重新啟動瀏覽器或核心，然後使用新的連線觀察日誌。

若同一網域回傳多個 IP，GeoIP 分類結果可能隨解析結果變化。CDN 服務尤其常見：不同網路、DNS 伺服器和時段可能取得不同地區的位址。這類服務更適合優先使用 DOMAIN、DOMAIN-SUFFIX 或 GEOSITE 規則，而不是完全依賴 GEOIP。

常見故障與處理順序

提示找不到 GeoSite 標籤

先確認 geosite.dat 已由目前工作目錄中的核心讀取，再確認標籤拼寫。標籤由資料來源定義，不能根據服務名稱任意推測。若日誌只針對某個標籤報錯，通常表示目前資料集沒有該分類；若所有 GEOSITE 規則都失敗，則更可能是檔案路徑、檔案格式或載入過程存在問題。

更新成功但規則結果沒有變化

部分用戶端下載新檔案後，需要重新啟動核心才會重新載入。先執行「設定」→「核心」→「重新啟動核心」，再觀察啟動日誌中的資料檔案路徑。如果日誌仍指向另一個目錄，應檢查啟動參數中的 -d，以及用戶端是否將訂閱設定檔執行於獨立目錄。

設定解析時顯示欄位錯誤

這通常表示核心版本較舊，或用戶端實際啟動的不是預期的 mihomo 檔案。執行 mihomo -v，再對照用戶端「設定」→「核心」顯示的版本。升級核心前先確認用戶端支援對應的核心介面；如果暫時無法升級，應刪除舊版本不認識的欄位，而不是將它們移到其他 YAML 層級。

TUN 模式下部分應用程式仍未依地理規則分流

先檢查該連線是否進入 mihomo，再檢查網域是否可見。只有目標 IP 而沒有網域時，GEOSITE 無法直接比對；此時可能需要依賴嗅探還原網域，或由 GEOIP 規則處理。還應檢查程序規則、IP-CIDR 規則是否位於地理規則之前，因為更早命中的規則會直接結束比對。

完整排查順序可以固定為：確認核心版本，確認工作目錄，確認資料庫載入日誌，確認規則順序，確認 DNS 或嗅探結果，最後檢查策略群組出口。依照這個順序處理，就能將「資料庫沒有更新」和「規則沒有命中」拆分成兩個獨立問題。

Clash下載