先釐清：IP 位址歸屬、網域分類與分流規則
遇到台灣網站走代理，或某項服務未依預期分流時，先別直接認定是「資料庫太舊」。mihomo 判斷規則時會涉及三件事：連線保留了哪些網域或目標 IP、資料庫將目標歸入哪個集合，以及設定中的哪條規則先符合。更新資料庫只會改變第二項，不會自動調整規則順序或策略組選擇。
本文設定適用於 mihomo，也就是 Clash Meta 後續採用的核心名稱。桌面用戶端只是管理設定與核心的介面；名稱中有 Clash，不代表支援相同欄位。套用前，請先在用戶端的「關於」、核心資訊或啟動記錄中確認實際執行的是 mihomo，再備份目前的設定。
| 資料或設定 | 比對對象 | 主要用途 |
|---|---|---|
| GeoIP | IPv4、IPv6 位址所屬的網路集合 | 依國家、地區或特定位址集合分流 |
| GeoSite | 網域及其分類項目 | 依網站類別、服務或地區網域集合分流 |
| rules | 由上而下排列的判斷條件 | 將符合條件的連線交由 DIRECT、REJECT 或策略組處理 |
| rule-providers | 獨立規則集檔案 | 依各規則集的 URL 與週期更新，不由 geox-url 管理 |
例如，GEOSITE,cn,DIRECT 使用網域集合；GEOIP,CN,DIRECT 使用目標位址的歸屬集合。兩者不是同一份「中國網站清單」。網站可能使用海外 CDN，也可能讓不同地區的網域共用同一個位址，因此不能只靠 GeoIP 判斷網站服務的地理歸屬。
資料檔與來源：先確認要載入哪種格式
GeoIP 的 DAT 與 MMDB 使用方式
mihomo 可用不同格式處理 GeoIP。設定 geodata-mode: true 時，GeoIP 會使用 geoip.dat；關閉此模式時，常見做法是使用 Country.mmdb。GeoSite 則使用 geosite.dat。因此，只更換 MMDB 檔案，不會更新 DAT 模式下實際用於比對的 GeoIP 資料。
geox-url 中的鍵也必須符合資料格式：geoip 指向 GeoIP DAT，geosite 指向 GeoSite DAT，mmdb 指向對應的 MMDB 資料。不要將文字網域清單的網址填入 geosite，也不要把 MMDB 檔案改名為 geoip.dat 後使用。
常見資料來源與選擇方式
- Loyalsoldier/v2ray-rules-dat：提供 GeoIP、GeoSite DAT 發行檔，適合需要常見地區與網域分類的設定。下文固定採用此來源，方便排查變因。
- MetaCubeX/meta-rules-dat：提供適用於相關核心生態系的資料產物。選用時請核對儲存庫說明、發行分支與實際檔案格式，不要混用不同產物的下載網址。
- 用戶端預載資料：適合首次啟動使用，但預載檔案的日期不等於安裝日期；之後如何更新，取決於用戶端與核心設定。
不同來源可能使用相同的分類名稱，收錄項目卻不一樣。尤其是 private、geolocation-!cn 和含屬性的網域分類，應以所選資料來源的說明為準。某個類別存在於一份 GeoSite 資料中，不代表所有發行檔都有提供。
自動更新設定：geox-url 與 24 小時更新週期
以下片段可合併至現有設定的頂層，採用 DAT 模式，更新間隔為 24 小時。這不是完整的訂閱檔案，不包含節點、連接埠與策略組。若原設定已有同名鍵，請修改原有項目，不要在檔案末尾再新增一組重複欄位。
geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
geoip: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
geosite: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"geodata-mode: true：讓 GeoIP 使用 DAT；這不是「同時啟用所有分流」的開關。geo-auto-update: true：啟用核心的 Geo 資料自動更新。geo-update-interval: 24：單位是小時，不是秒，也不代表每天固定在午夜更新。geox-url：指定資料下載來源；不會同步更新訂閱節點，也不會改寫rules。
此範例未設定 mmdb，因為採用的是 DAT 模式。若現有設定另有 MMDB 來源，可以保留，但不要將 MMDB 的更新時間當成目前 GeoIP DAT 已更新的證據。AS 號資料庫用途不同，使用 GEOIP 與 GEOSITE 時不必一併啟用。
應該在哪裡修改用戶端設定
- 先匯出或複製目前使用的設定，並記下設定名稱。
- 找到用戶端提供的「覆寫」、「合併設定」或設定編輯功能，將上述欄位套用至最終設定。不同用戶端的選單各不相同，不應把某一種選單路徑視為 mihomo 的通用入口。
- 重新載入設定；若用戶端提示相關全域參數需要重新啟動核心，請重新啟動核心並檢查啟動記錄。
- 查看最終執行的設定，確認三個頂層欄位與兩個資料 URL 沒有被訂閱內容或全域設定覆蓋。
直接修改訂閱下載後的快取檔案，通常會在下次更新訂閱時被覆蓋。需要長期保留的本機設定，應放在用戶端支援的持久化覆寫層。訂閱更新週期、Geo 資料更新週期和規則提供者的 interval 是三套獨立機制。
GEOIP 與 GEOSITE 規則寫法：先比對網域，再以位址兜底
以下範例假設現有設定已定義名為「節點選擇」的策略組。名稱必須與實際組名完全一致；若實際名稱是「代理」，請相應修改規則目標。範例涵蓋區域網路、境內網域、境內位址與最後兜底四個層次，不包含廣告攔截等其他分類。
rules:
- GEOSITE,private,DIRECT
- GEOIP,private,DIRECT,no-resolve
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,節點選擇依序理解五條規則
GEOSITE,private,DIRECT：比對所選 GeoSite 資料中定義的私人網域集合。這不保證涵蓋所有企業內部網域，自訂內部網域仍須另外新增規則。GEOIP,private,DIRECT,no-resolve：嘗試比對現有目標 IP 與私人位址集合，避免只為這條規則主動解析網域。GEOSITE,cn,DIRECT：優先依網域分類處理，避免完全仰賴位址歸屬來判斷網域。GEOIP,CN,DIRECT,no-resolve：目標 IP 已知時，以境內位址集合兜底。MATCH,節點選擇：將前面所有規則都未符合的連線交由指定策略組處理。
no-resolve 的意思是「不為這條 IP 規則主動觸發網域解析」，不是「這條連線永遠不使用 DNS」。如果連線本身已有實際目標 IP，仍可套用 IP 規則；若沒有可用的 IP，這條規則可能不會符合，連線便會繼續往下比對。是否保留此參數，應依 DNS 設定、連線方式與分流目標決定。
mihomo 會依序比對規則。較前面的寬鬆規則一旦符合，後面的細項分類就不會接手。若將 MATCH 放在前面，後續規則便形同失效；若較早的分類已將所有境外服務交給同一策略，也可能攔截後面的單一網域例外。例外規則通常應放在相應的寬鬆規則之前。
如何確認更新成功：分別檢查下載、載入與規則命中
「檔案下載完成」只代表更新流程完成其中一步。完整驗證還要確認核心已成功解析資料，而且目標連線確實符合預期規則。建議依照以下三個層次逐項檢查，不要只看檔案日期或網站能否開啟。
第一層：確認實際使用的檔案
從用戶端的「開啟設定目錄」功能或核心啟動參數確認工作目錄。不要假設它一定是下載資料夾或應用程式安裝目錄。DAT 模式請優先檢查 geoip.dat 與 geosite.dat；MMDB 模式則確認實際載入的 MMDB 檔案。作業系統可能會隱藏副檔名，請避免產生 geosite.dat.dat 這類檔名。
第二層：確認設定與資料都能解析
使用獨立的 mihomo 命令列時，可在複製好的測試目錄中執行以下設定檢查。範例目錄 ./geo-check 須事先建立，並放入要測試的設定與資料檔；不要直接用測試指令覆寫正在執行的目錄。
mihomo -t -d ./geo-check -f ./geo-check/config.yaml檢查失敗時，先閱讀第一個錯誤訊息。YAML 縮排錯誤、策略組不存在、GeoSite 類別缺少與資料解析失敗，必須分別處理。設定檢查通過也不代表所有流量都會依預期分流；這只是接下來驗證連線的前提。
第三層：重新建立連線並檢查規則
- 切換至規則模式，確認目前不是全域模式或直連模式。
- 關閉目標網站的舊連線，再開啟目標頁面；必要時關閉該應用程式後重新啟動。
- 在用戶端的連線面板中查看網域、目標 IP、命中規則與最終策略鏈。
- 分別測試一個預期直連的目標，以及一個預期使用「節點選擇」的目標，並記錄兩組結果。
例如，連線面板若顯示符合 GeoSite(cn)，策略為 DIRECT，才符合境內網域規則的預期。各用戶端顯示格式不同，不必要求記錄中出現完全相同的字串。既有的長連線不會因資料庫更新而自動依新規則重新建立，驗證時請使用新連線。
更新失敗或分流異常：依現象排查
| 現象 | 優先檢查 | 處理方式 |
|---|---|---|
| 下載連線逾時 | 資料來源網域是否可連線、DNS 與目前網路狀態 | 先恢復下載連線，保留原本可用的資料，不要急著清空目錄 |
| 提示分類不存在 | 分類拼寫、資料來源與實際載入的檔案 | 確認來源提供的分類，或改用該來源實際支援的規則 |
| 提示資料解析失敗 | 是否誤下載網頁，以及檔案格式是否相符 | 重新取得正確的發行檔，避免以儲存庫網頁網址代替檔案網址 |
| 檔案已更新，分流結果卻沒變 | 規則順序、最終設定與舊連線 | 重新載入後建立新連線，檢查實際符合的規則，不要只看出口 IP |
| 每次更新訂閱後設定就消失 | 修改是否只套用在訂閱快取中 | 將長期設定移至用戶端支援的持久化覆寫層 |
首次啟動時無法下載，怎麼辦？
如果設定必須依賴 Geo 資料才能啟動，而目前網路又無法連線至資料來源，就可能形成初始化依賴。可在能連線至來源的網路中取得相應檔案，放入核心實際使用的工作目錄，再重新啟動。手動替換前請先停止核心並備份舊檔；檔案成功載入後，再處理後續的自動更新連線。
不要為了讓核心順利啟動，就直接刪除所有 GEOIP、GEOSITE 規則，卻不檢查原本的兜底行為。刪除規則可能使原本直連的連線全部改走代理組，也可能讓例外服務失去分流。即使只是暫時調整，也應記錄變更，還原後重新驗證。
啟用 TUN 後，需要改用另一套資料庫嗎？
不需要。TUN 改變的是流量接管方式，不會自動改用另一套 GeoIP、GeoSite 資料。同一個核心通常仍會讀取相同工作目錄中的資料。啟用 TUN 後結果不同，請優先檢查網域是否保留、DNS 請求的路徑、Fake-IP 對應與目標連線資訊，不要先急著下載另一份資料庫。
只有 IP 的連線沒有可供 GeoSite 比對的網域；在部分通訊協定與條件下，嗅探可能補上網域，但無法保證對所有流量都有效。想進一步了解流量接管、DNS 與規則之間的關係，可參閱技術參考，或在術語表中確認 Fake-IP 與 TUN 的定義。
維護順序：固定資料來源、保留回復方式、驗證新連線
- 固定資料來源：記錄所選的資料儲存庫、格式與設定欄位，不要只記下一個鏡像網址。
- 設定合理週期：日常可先採用 24 小時；資料通常不需要每隔幾分鐘輪詢一次。電腦休眠或核心停止時，也不會持續執行更新。
- 保留回復方式：切換來源或手動替換前，先保存目前的設定與可用資料，遇到問題時一併還原。
- 確認實際結果：更新後至少確認一次載入狀態，並以新連線核對網域、命中規則與策略鏈。
維護 Geo 資料的重點，不是讓檔案日期盡可能新，而是確保資料格式、分類名稱與規則目標相符。先確認核心與載入模式，再設定更新來源，最後透過連線面板驗證，通常比反覆更換資料庫更容易找出問題。