GeoIP、GeoSite 資料庫更新教學：geodata 模式、下載來源與規則設定

1. 先分清 GeoIP、GeoSite 與訂閱更新

GeoIP 和 GeoSite 是分流規則會參照的資料，不是代理節點。更新訂閱通常是取得節點、策略群組或整份設定；更新地理資料庫則會改變規則可比對的 IP 網段或網域集合。兩者由不同機制維護，按一次「更新訂閱」，不代表資料庫也已更新。

GeoIP 的國家或地區分類，不代表網站營運者所在地，也不保證反映使用者連線時的實際服務位置。CDN、跨區域部署，以及資料來源收錄差異，都可能造成「網域應直連」與「解析出的 IP 被歸類到某地區」結果不一致。因此，網域規則通常會排在 IP 規則前面。

2. geodata-mode 的用途與檔案存放位置

啟用後會變更 GeoIP 資料格式

在 mihomo 中，geodata-mode: true 會讓 GeoIP 使用 DAT 資料；設為 false 則使用 MMDB 資料。這個開關不是「啟用所有地理分流」的總開關，也不會建立任何規則。GeoSite 仍需要對應的資料檔案和 GEOSITE 規則。

• geox-url.geoip：GeoIP DAT 的下載來源。
• geox-url.mmdb：GeoIP MMDB 的下載來源。
• geox-url.geosite：GeoSite DAT 的下載來源。
• geodata-loader：DAT 資料的載入方式，常見值為 standard 和 memconservative；此欄位不會決定規則的目標策略。

檔案通常由核心存放在工作目錄中，常見檔名包括 GeoIP.dat、GeoSite.dat 和 country.mmdb。不同用戶端可能使用各自的執行目錄，安裝程式所在資料夾不一定是資料目錄。大小寫也可能影響 Linux 辨識檔案，請以核心日誌、實際檔案和用戶端說明為準。

從執行參數確認位置，避免改錯副本

1. 請在用戶端提供的設定目錄或工作目錄入口中尋找資料庫檔案；「設定目錄」和「應用程式日誌目錄」可能不是同一個位置。
2. 查看核心啟動參數：-d 指定工作目錄，-f 指定設定檔。設定檔所在目錄不一定就是工作目錄。
3. 如果自行執行核心，可明確指定 mihomo -d ./mihomo-data -f ./config.yaml，讓工作目錄位置一目瞭然。
4. 使用容器時，請檢查目錄掛載設定；容器內的工作目錄與主機上的檔案儲存位置可能不同。

修改前請先備份目前的設定和資料庫。若用戶端提供覆寫、合併或擴充設定功能，請透過這些可保留設定的入口寫入全域欄位；直接修改自動產生的執行設定，可能在下次更新訂閱時遭到覆蓋。

3. 設定下載來源與每 24 小時自動更新

以下範例可合併至 mihomo 設定檔的最上層。資料來源為 MetaCubeX 的 meta-rules-dat 發佈資源；geo-update-interval 的單位是小時，數值 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"

• 這些欄位與 rules、dns 同層，不要縮排到 proxy-groups 或 profile 底下。
• 如果已有 geox-url，請合併原有對應項目，不要重複新增同名的最上層鍵。
• 改用 geodata-mode: false 後，請特別確認 MMDB 來源是否可用；只更新 DAT 無法取代目前使用的 MMDB。
• 設定自動更新不代表儲存設定後就會立即下載。套用設定或重新啟動核心後，請查看更新日誌，確認排程是否已啟用。

來源專案可在 MetaCubeX/meta-rules-dat 查閱，欄位說明則可參考 mihomo 一般設定文件。發佈資源可能隨專案維護而變動；連結失效時請先確認發佈頁，不要只憑檔名改用不熟悉的下載來源。

4. GEOIP、GEOSITE 與規則順序

Clash 系列會依序比對規則，符合前面的規則後就採用其目標策略。以下範例將網域集合排在 IP 規則前，最後以 MATCH 作為預設規則。範例建立了「出站選擇」策略群組，但群組內只有 DIRECT，僅用來展示可解析的結構；實際使用時應加入現有的代理節點或策略群組，不能將此範例當成可直接使用的代理連線。

proxy-groups:
  - name: 出站選擇
    type: select
    proxies:
      - DIRECT

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,出站選擇

no-resolve 不會停用 DNS

GEOIP,CN,DIRECT,no-resolve 表示這條規則不會主動觸發網域解析來取得比對目標。如果連線資訊中已有目標 IP，仍可進行 IP 比對；若沒有可用的 IP，則可能繼續檢查後續規則。這個參數不會停用整個用戶端的 DNS，也不會阻止應用程式在其他階段進行解析。

規則能比對哪些內容，取決於連線資訊

GeoSite 需要網域資訊。應用程式直接連線至 IP、網域對應資訊遺失，或流量接管方式變更時，無法保證每條連線都能比對到網域分類。TUN 是一種流量接管方式，並非更新 GeoSite 的必要條件；啟用 TUN 本身也不會自動補齊所有連線的網域資訊。使用 fake-ip 時，DNS 對應關係同樣會影響核心能否還原相應網域。

若要固定某個網站的連線走向，可在分類規則前加入具體規則，例如 DOMAIN-SUFFIX,example.com,DIRECT。這是調整規則順序，不需要為單一網域重新製作資料庫。正式規則請填入實際要處理的網域，並在連線詳細資訊中確認命中結果。

5. 無法自動下載時的手動替換流程

常見問題包括下載逾時、重新導向後的目標無法連線，以及代理出站本身依賴尚未成功載入的設定。瀏覽器能開啟 GitHub 首頁，不代表核心也能下載發佈附件；兩者可能使用不同的代理設定和網路路徑。

1. 記錄錯誤：保存日誌中的資源網址、錯誤類型和目標檔案位置，分辨連線逾時、HTTP 錯誤與資料解析失敗。
2. 取得對應資源：從設定中指定的發佈來源下載實際的二進位檔案，確認下載結果不是網頁、登入頁面或錯誤訊息。
3. 停止核心：使用用戶端的停止功能；若關閉視窗後用戶端仍留在系統匣，請明確停止背景核心，避免檔案持續被占用。
4. 備份並替換：將原檔移至備份資料夾，再把新檔放入已確認的工作目錄，並沿用核心要求的本機檔名。
5. 重新啟動：檢查資料載入日誌與設定解析結果；若出現分類不存在或解析錯誤，請先還原備份，再檢查資料來源與格式。

不要把 MMDB 檔案改名為 DAT 來嘗試轉換格式，也不要把 GeoSite 資料放進 GeoIP 檔案的位置。副檔名不是轉換工具，核心讀取的是檔案內部結構。在 Linux 或以服務方式執行時，也要確認執行核心的帳戶具備目錄讀取權限；啟用自動更新則需要相應的寫入權限。

6. 更新後透過日誌與連線詳細資訊交叉驗證

「檔案時間變了」只代表檔案曾經寫入；「設定能啟動」也不代表測試流量命中了預期規則。建議將更新流程與實際分流分成兩組檢查並逐項記錄，不要只看網頁是否能開啟。

測試前請先關閉既有的長連線，再重新發出請求。已建立的連線通常不會因資料庫更新而重新執行完整的路由判斷；瀏覽器重複使用連線也可能讓結果看起來沒有變化。若需暫時提高日誌詳細程度，請在排查完成後恢復原設定，並避免對外分享含有節點憑證、訂閱網址或個人瀏覽紀錄的完整日誌。

7. 常見錯誤與調整範圍

出現「分類不存在」或 GeoSite 載入失敗

先確認規則中的分類名稱是否由目前的資料來源提供，再確認下載內容確實是 GeoSite DAT。改用精簡資料來源後，部分分類可能已被移除；改回相容的資料來源，或刪除不再支援的規則，通常比反覆重新啟動更有效。

資料庫已更新，但某個網站仍套用錯誤策略

檢查是否有排在前面的 DOMAIN、DOMAIN-SUFFIX 或 RULE-SET 優先命中；接著確認 DNS 回傳的位址與連線詳細資訊中的目標 IP。更新資料庫不會調整規則順序，也不會清除所有 DNS 快取。確認實際比對路徑後，再決定要修正规則、清除快取，或回報資料來源的收錄問題。

已使用 rule-providers，還需要更新 GeoSite 嗎？

取決於設定是否仍引用地理資料。RULE-SET 對應的規則提供者會依照自己的 url、path 和 interval 更新；地理資料庫的自動更新不會取代這套機制。如果設定仍使用 GEOSITE、GEOIP，或 DNS 設定引用了相關分類，就仍須維護對應資料。