1 症狀：為什麼會懷疑「地理庫過舊」
規則引擎在 rule 模式下，會依序比對 IP、網域、GEOIP、GEOSITE、Rule Provider 等條件。當您使用諸如 GEOIP,US,PROXY-US 或 GEOIP,CN,DIRECT 這類依國別路由的寫法時，核心必須查表：目標 IP 落在哪個國家／地區。若底層 mmdb 或 geoip.dat 中的對照仍是數年前的資料，CDN 邊緣節點、雲端任播前緣、或新劃分的位址區塊就可能被判到錯誤的地理標籤，結果就是流量被送到非預期的策略組。
GEOSITE 則依賴 geosite.dat（或等價的內建／外掛資料）把網域名稱對應到社群維護的「網站分類」集合。串流、雲端服務、內容網路經常調整子網域與分流策略；列表若長期未更新，會出現「某站明明應在類別 A，卻沒被收進去」或「舊條目仍指向已下線的網域集合」等情況，外觀上同樣像規則誤判。因此，在大幅改寫 YAML 之前，先確認地理庫版本，往往是最省時間的排查方向。
一句話：GEOIP／GEOSITE 規則的「真值」來自本機資料檔，不是來自訂閱裡的文字；檔案過舊時，再漂亮的規則也會算錯。
2 Country.mmdb、geoip.dat、geosite.dat 分別是什麼
Country.mmdb（MaxMind DB 格式）
多數 Mihomo／Meta 系核心預設使用 MaxMind GeoLite2 風格的 Country.mmdb（檔名可能依發行版略有不同，但概念相同）。此格式查詢效率高，適合即時對 IP 做國別標註。若您的設定或圖形介面顯示「GeoIP 資料庫」卻未見 geoip.dat，很可能就是走這一路徑。
geoip.dat（二進位地理 IP 庫）
較早期或部分工具鏈仍習慣使用名為 geoip.dat 的專用二進位檔，內容同樣是 IP 與地理／路由資訊的對照，與 GEOIP 規則搭配。不同發行版可能只採用其中一種（mmdb 或 dat），請以您所用核心的說明為準，避免兩種都下載卻放錯檔名導致讀不到。
geosite.dat（網域分類庫）
geosite.dat 承載大量網域與標籤（如 cn、google、各類媒體標籤等），供 GEOSITE 規則與部分 DNS 策略（例如 nameserver-policy 搭配 geosite 鍵）使用。沒有載入對應資料時，相關規則可能直接跳過或行為與預期不符，這也是許多使用者覺得「分流不生效」的來源之一。
geosite.dat 則是另一套二進位索引。兩者都會影響命中結果，排查時不要混在一起假設「訂閱更新了，geosite 就一定新」。
3 下載來源：建議優先跟著「核心／GUI 官方釋出」
社群上有多個專案會定期編譯 geoip.dat、geosite.dat 與相容的 Country.mmdb，並附在 Release 或規則套件中。實務上最穩妥的做法是：先查您正在使用的核心版本與圖形前端是否內建「一鍵更新地理資源」或指定官方鏡像；若有，優先用內建流程，可減少路徑與檔名不一致的問題。
若必須手動替換，請從您信任的專案 Release 頁取得與核心版本相容的構建產物，並核對檔名是否與設定檔中的 geodata-mode、geo-auto-update 等選項（若存在）一致。下載後建議校驗檔案大小與修改日期，避免下載不完整。關於開源倉庫與構建說明，可在需要時自行查閱對應專案的 README；安裝套件與圖形用戶端仍建議透過本站下載頁取得，與教學與更新節奏較容易對齊。
- 同一台機器只保留一份「生效中」的庫：重複目錄或舊檔未刪除，可能讓 GUI 顯示已更新、核心卻仍讀舊路徑。
- 行動裝置與桌面路徑不同：沙盒與權限會影響實際寫入位置，替換後務必在該平台上重啟 App。
4 放置路徑：Home 目錄與設定檔中的指向
Clash Meta 系通常以「Home 目錄」為基準載入地理檔案：常見配置會與 config.yaml、快取、ruleset 下載檔放在同一層或子目錄。圖形前端（如 Verge 類）往往會在設定裡顯示資源路徑，或提供將檔案同步到 Home 的按鈕。手動複製時，請將 Country.mmdb、geoip.dat、geosite.dat 放到核心實際讀取的位置，檔名需與預設或您在設定中覆寫的名稱完全一致（大小寫在部分系統上有差別）。
若設定檔內有自訂路徑鍵（依版本而異），請以官方 Wiki 為準；複製教學範例前，先確認自己的核心版本是否仍支援該鍵名。對於同時使用 TUN 與多份設定檔的使用者，注意不同 Profile 可能指向不同的 Home，更新時要對準正在執行的那一份。
# Example keys — names vary by Mihomo / Meta version; check your release docs
geodata-mode: true
# geo-auto-update, geo-update-interval, etc. may exist in some builds5 重啟、重載與 Rule Provider 快取
替換 geoip.dat、geosite.dat 或 Country.mmdb 後，多數情境需要重啟核心程序或在前端執行「重載設定／重啟服務」，才能確保記憶體內的索引重新載入。僅在檔案總管覆寫而沒有重啟，可能仍沿用啟動時對應的舊對照表，外觀就像更新無效。
若您同時使用 Rule Provider 遠端規則，建議在重大除錯時一併清理過期快取或手動觸發更新，避免「地理庫已新、但規則集仍舊」的組合誤導判斷。本站另文說明 ACL4SSR 與 Rule Provider 的實務用法，可與本文搭配閱讀：Clash Rule Provider 與 ACL4SSR 規則集。
6 驗證：用日誌確認「真的命中 GEOIP／GEOSITE」
更新完成後，請開啟核心的除錯日誌（等級依前端而定），造訪一兩個您關心的目標站，檢查連線紀錄中的規則名稱與策略組是否符合預期。若日誌顯示命中的是某條寬鬆的 IP-CIDR 或 MATCH，而不是 GEOIP／GEOSITE，則問題可能出在規則順序，而非地理庫本身。
另一個常見情境是：HTTPS 連線在嗅探前只有 IP，導致網域規則來不及參與首包決策，而 GEOIP 先依 IP 判國別——若 CDN IP 的地理標註與您心證不符，就會誤入錯誤出口。此時除了更新 mmdb，還應檢視 Clash Meta Sniffer 與 TLS SNI 是否已正確開啟並搭配 override-destination，讓網域規則有機會優先於過寬的 IP 規則。
- 對照測試：更新前後各存一份日誌片段，比對同一 URL 的命中規則是否改變。
- DNS 一併看：錯誤的解析會讓連線落到意料之外的 IP，進而觸發錯誤的
GEOIP分支；可參考Meta 核心 DNS 與 FakeIP整理的全局設定。
7 更新地理庫後仍走錯：下一步檢查清單
若已確認檔案為新、核心已重啟，但串流或特定網站仍走錯節點，請依序收斂：① 規則順序是否讓更細的 DOMAIN-SUFFIX／Rule Provider 置於寬鬆 GEOIP 之前；② FakeIP 與 DNS 是否導致「看到的 IP」與真實出口不一致；③ 是否為 QUIC／HTTP3 路徑未納入嗅探；④ 訂閱是否覆寫了本機關於 geodata 的設定。將範圍縮小後，再決定要改規則還是改資料，可避免無效的重灌與重下訂閱。
8 總結
Clash Meta／Mihomo 的 GEOIP、GEOSITE 規則高度依賴本機的 geoip.dat、geosite.dat 與 Country.mmdb（mmdb）。當依國家／地區分流或媒體類規則突然失準時，優先執行「確認來源 → 正確路徑替換 → 重啟核心 → 用日誌驗證命中」這一條路徑，通常比盲目堆疊規則更有效。若仍異常，再與 Sniffer、DNS、Rule Provider 與規則順序一併排查，就能把規則誤判收斂到可重現的原因上。
相比只在圖形介面反覆切換節點，先把地理庫與規則資料維持在合理更新節奏，長期使用體驗會穩定得多。若您希望取得與本站教學一致、內建 Meta 能力的跨平台用戶端，可從本站下載頁選擇適合的作業系統版本，再依本文步驟檢查資源檔是否已同步為最新。
