Clash Meta GeoIP／GeoSite 離線庫路徑怎麼設定？手動更新與驗證逐步教學（2026）

為什麼「離線庫路徑」值得你單獨花一輪心思？

多數使用者第一次碰到 Clash Meta／Mihomo，多半先在rules:裡看到GEOIP、GEOSITE這類關鍵字，接著把心力放在規則由上而下的順序與策略群組怎麼挑節點。這條路沒錯，但若底层的國別資料庫或網域標籤資料版本過舊，甚至被放到核心根本讀不到的路徑，再漂亮的規則也只會在錯誤的輸入上算出「看起來合理」的答案。

典型現象包括：明明是常被標為國內出口的 CDN，卻在GEOIP規則裡被判成境外；或是GEOSITE規則永遠對不上預期標籤，迫使你把一切都推進最後的MATCH兜底代理，結果延遲與電費一起上升。這類問題與「規則行序錯置」不同：前者是資料與載入路徑問題，後者是 YAML 邏輯問題。若你想優先處理後者，建議另讀站內國內流量誤走代理時的 GEOIP CN 與規則優先序排錯；本篇則專注離線 Geo 資料放哪、怎麼換、換完如何驗證。

合規提醒：請僅從可信上游取得 Geo 資料與規則集；請勿將來路不明的二進位檔塞進核心目錄，也不要把本文用作規避法律義務或服務條款的指引。

先搞懂：geodata-mode、.dat與.mmdb各自扮演什麼角色

在 Mihomo 的全域設定裡，geodata-mode可以視為「GEOIP 規則要靠哪一種檔案家族來吃資料」的總開關之一。根據 MetaCubeX 官方 Wiki 說明，將此項設為true時，核心會偏向使用.dat格式的 GeoIP 資料；設為false時則偏向使用.mmdb（例如常見的country.mmdb）。實務上你會發現：GEOIP 規則會跟著這個開關切換載入邏輯，但 GEOSITE 規則往往仍依賴geosite.dat這類離線清單。因此在檢查「我到底該換哪些檔」時，請永遠先看現用設定檔寫了什麼，而不是只看論壇截圖。

geodata-loader則決定核心如何把巨大離線檔塞進記憶體：standard較接近一般桌面環境的載入方式；memconservative則為記憶體吃緊裝置優化（Wiki 亦標示後者常為預設）。若你在路由器或輕量 NAS 上更新 Geo 檔後發現啟動時間暴長，可先確認是否誤用了不適合硬體的載入模式，再來怪罪檔案大小。

至於檔名與精簡版：上游 Release 常同時提供完整版與-lite變體，換檔前請對照訂閱作者是否有特別要求「必須含 ASN／細緻分區」等情境。別只看檔案較小就換 lite，否則後續規則若引用較細標籤，可能出現命中稀疏或行為與作者預設組態不一致。

設定檔裡真正會動到「下載與更新」的關鍵欄位

即使你最後選擇完全手動維護離線檔，仍建議在config.yaml（或圖形介面 mixin 合併後的最終文本）裡，搞清楚這三組與 Geo 資產最相關的區塊：

  • geo-auto-update／geo-update-interval：前者決定是否讓核心依排程自行向網路抓取；後者則以小時為單位設定間隔。若你正要人工覆寫本地檔案測試特定版本，卻忘了關閉自動更新，可能發生「凌晨又被線上鏡像蓋回」的挫折。
  • geox-url：用來覆寫預設的geoip、geosite、mmdb，必要時還可包含asn這類延伸資料來源。它的語意是告訴核心去哪裡下載，不等於「告訴核心去哪裡讀既有本地檔」——本地路徑多半仍由工作目錄與預設檔名規則決定。
  • etag-support／global-ua：這兩項會影響自動更新時是否善用快取驗證與下載身分標頭；若你在企業網路裡遇到特定鏡像總是 403，可以把調整 UA、換鏡像與改走離線手動更新放在同一張排查表上。

下列為教學用的結構示意，網址請視環境替換為你可連線、且願意信任維護者簽章與發行流程的來源：

YAML（片段）geodata-mode: false
geodata-loader: memconservative

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

geox-url:
  geoip: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geoip.dat"
  geosite: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/geosite.dat"
  mmdb: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@release/country.mmdb"
  asn: "https://github.com/xishang0128/geoip/releases/download/latest/GeoLite2-ASN.mmdb"

小提示：若你使用 GUI 用戶端（例如各種 Verge 類 fork），實際生效文本可能是訂閱模板＋本機 mixin合併結果；改檔時請確認「編輯的是會被核心載入的那一份」，避免只在暫存緩衝區修改。

離線檔「實際會落在哪」：工作目錄與圖形介面的對齊方式

Mihomo 並不像某些資料庫伺服器會在設定檔裡為每一個資料檔都提供完整絕對路徑欄位；多數發行版會把geoip.dat、geosite.dat、country.mmdb放在核心的工作目錄底下，並沿用約定俗成的檔名。桌面環境裡，這個目錄通常能用「開啟設定資料夾」「開啟程式資料目錄」或選單中的對應按鈕找到；Linux 服務則常見於.config/mihomo或 systemdWorkingDirectory所指位置。

若你不確定目前這台機器上的真實路徑，建議用以下順序交叉驗證：(1)先看圖形介面是否揭示資料根目錄；(2)再在該目錄底下搜尋上述標準檔名與最近修改時間；(3)最後對照啟動日誌是否仍報「無法載入 Geo 資料」——若有，十之八九是你換錯資料夾或檔名大小寫在區分大小寫的檔案系統上不吻合。

對OpenWrt／路由器映像來說，請格外留意 overlay／tmpfs：有些映像在重開機後會還原成出廠目錄，離線檔若要長存需寫入持久化分割區或調整開機指令。不要在路由仍在線轉發時硬拔 USB，以免檔案半寫入。

手動更新與替換：建議依序執行的操作骨架

下面這組步驟刻意寫得偏保守：寧可多停核心一分鐘，也不要換到一半留下截斷檔。你可以視環境刪減，但不要省略「備份」與「確認載入」兩件事。

  1. 開啟現用設定檔，記錄geodata-mode與是否啟用geo-auto-update；若接下來要以人工檔案為準，建議暫時關閉自動更新或縮短測試窗口，避免排程覆寫。
  2. 在檔案總管或cp指令下備份目前資料目錄中的geoip.dat、geosite.dat、country.mmdb與（若有使用的）ASN 相關mmdb；順便記下檔案大小與日期以利換檔後比對。
  3. 透過瀏覽器或curl自上游 Release取得新版本二進位檔；若環境無法直連 GitHub，可改用你在geox-url已驗證可用的鏡像；下載完成後若頁面提供雜湊值，應隨手核對。
  4. 完整結束Mihomo 核心行程：包含 tray 常駐、後台服務或 systemd unit；確認工作管理員或ps列表裡沒有殘留同名行程後再換檔。
  5. 將新檔覆寫到上一節確認過的工作目錄，維持約定檔名；避免改成自創檔名卻未同步調整任何載入設定（多數情境下核心並未暴露對應 YAML 欄位）。
  6. 檢查檔案權限與擁有者：NAS／Linux 上若核心以非 root 使用者執行，離線檔也需該使用者可讀；Windows 上若先前曾用系統管理員寫入，記得別讓一般使用者模式的核心反而讀不到。
  7. 重新啟動核心後，先把log-level拉到debug或維持info但開啟檔案日誌，搜尋是否有 Geo 載入失敗、格式不符或路徑錯誤字樣。
  8. 開啟連線紀錄面板，挑一個已知國別／已知 GEOSITE 標籤的測試目標（不要用過度敏感的個資網域），觀察命中規則類型與結果是否符合預期；必要時暫時把規則簡化到只剩少數GEOIP／GEOSITE行以利對照。

注意：有些桌面用戶端會在 UI 裡提供「一鍵更新 Geo 資料」按鈕；若你同時手動換檔又頻繁按更新，可能難以判斷目前生效版本究竟來自哪個動作。測試期間建議固定單一路徑並記錄時間戳。

怎麼「驗證我真的換到新庫」而不是心理安慰？

最務實的判準永遠是行為面＋證據面並行：行為面看某條規則是否開始把特定目標導向你期待的策略；證據面看檔案時間戳、檔案大小與啟動日誌是否一致支持該結論。僅憑「感覺變快」並不可靠，因為延遲同時受節點負載、DNS、TCP 並發與應用程式本身快取影響。

若你在geodata-mode: false路線上使用country.mmdb，建議額外記錄一次換檔前後的文件修改時間；若在true路線上使用geoip.dat，則除了時間戳外也可留意啟動耗時是否顯著變化——過大的離線檔在小記憶體裝置可能拖長 ready 時間，這反過來也是「你真的載入了更大的資料」的旁證。

對GEOSITE規則而言，若命中結果長期呈現「永遠落在兜底」，請同步檢查規則集提供者是否真的能拉到遠端 YAML，別把所有問題都怪到geosite.dat——但若提供者仰賴內建標籤對照表，離線庫過舊確實會讓標籤對不上／對太慢。分流規則語意總覽可與站內規則分流架構教學搭配閱讀，先把「規則說了什麼」弄清楚，再回頭查資料庫版本。

常見問題（精簡版）

geodata-mode設為 true 或 false 時要準備哪些檔案？設為true時核心較常搭配geoip.dat與geosite.dat來服務 GEOIP 與 GEOSITE 規則；設為false時 GEOIP 規則多半依賴country.mmdb這類 MMDB。實際對應請以所用 Mihomo 版本的官方 Wiki 為準，並與訂閱規則集中是否引用 GEOSITE 標籤一併考量。

覆寫離線檔後規則看起來仍舊，最常見原因是什麼？多半是核心行程未完全結束導致舊檔仍在記憶體中，或覆寫路徑與實際工作目錄不一致；少數情況是用戶端在下一次啟動時又從網路自動拉回舊版快取。請確認結束程序、路徑正確，並視需要暫時關閉geo-auto-update以便人工檔案優先生效。

geox-url與手動放本地檔案會不會互相打架？geox-url決定自動更新時下載的來源網址；本地檔案則是核心實際載入的實體檔。若geo-auto-update為true，核心可能在排程時間再度覆寫您的手動檔案。若要以離線檔長期固定版本，可關閉自動更新或改用您信任的鏡像網址。

這篇文章與 GEOIP CN 規則優先序教學有什麼不同？GEOIP CN 規則優先序多半談rules:區塊行序、MATCH兜底與 DNS／fake-ip 對匹配的影響；本篇則專注離線資料庫檔放在哪、如何手動更新與驗證核心是否真的載入新 Geo 資料。兩者可並讀：先確保資料新鮮，再回到規則順序排錯。

結語

離線 Geo 資料這件事，表面上只是在資料夾裡換幾個二進位檔，實際上卻牽涉模式開關、自動更新排程、工作目錄與圖形介面包裝層等多個環節。市面上不少「懶人包」把規則寫得很炫，卻沒交代資料來源與更新策略；使用者一旦碰上國別判定異常，往往只能在論壇四散片段裡猜測，缺少可依序操作的檢查路徑。

ClashSource把這類單點但高頻的設定拆開撰文，讓你能對照官方 Wiki 與本站流程一步步做完：先對齊檔案類型與模式，再改對資料夾，最後用日誌與連線紀錄收尾驗證。若你希望在同一個入口整理好用戶端取得方式並銜接後續教學，亦可先閱讀Clash Meta 升級與 Mihomo 核心遷移指南建立共同語彙。相較依賴來路不明的整合包，跟著可信上游與可驗證流程維護離線庫，長期穩定度通常更好；若你尚未準備好用戶端環境，不妨免費下載 ClashSource整理過的方案試用，再套用本文的離線庫更新節奏。