mihomo GeoIP、GeoSite 資料庫更新與規則設定教學

GeoIP、GeoSite 與規則集的差異

mihomo 分流時，規則決定比對順序，資料庫則提供比對所需的分類資料。更新資料庫不會自動改變規則順序，也不會替換訂閱節點。若網站連線被導向錯誤的代理群組，應分別檢查目前設定、資料庫內容，以及連線實際命中的規則。

geodata-mode 選擇的是 GEOIP 資料後端，不代表停用後就無法使用 GEOSITE。GeoSite 會比對連線提供或核心取得的網域；GeoIP 則依目標 IP 位址比對。網域分類無法說明伺服器的實際所在地，IP 歸屬也不能保證某項服務應該直連。

rule-providers 是另一套機制，通常由 RULE-SET 引用，使用 YAML、文字或 MRS 等格式的規則集檔案，並有各自的更新設定。只更新 geosite.dat，不會一併更新所有規則提供者。

確認核心、資料來源與工作目錄

本文設定適用於 mihomo。舊版 Clash 用戶端可能搭載不同核心，不能只看介面名稱判斷是否相容。請先從用戶端的核心資訊或啟動記錄確認目前執行的是 mihomo；若以命令列部署，請執行下方指令記下實際版本，再檢查設定。

mihomo -v
mihomo -h

選擇與規則分類相符的資料來源

常見來源包括 MetaCubeX 的 meta-rules-dat 發行檔，以及 Loyalsoldier 相關的規則資料專案。不同專案可能採用不同上游、裁切方式與分類名稱。檔名相同，不代表內容一定包含相同的 cn、github 或廣告分類。

• 請先在資料專案的發行頁確認檔案格式，再複製實際下載連結。請勿將網頁網址存成資料庫檔案。
• GeoIP 的 DAT 與 MMDB 檔案格式不同，不能只改副檔名互換。
• 精簡版可減少儲存空間與載入負擔，但可能不包含既有規則引用的分類。
• 先備份可正常運作的設定與資料，再切換資料來源，避免一次引入多項變因。

確認核心實際讀取的位置

直接執行核心時，-d 用來指定工作目錄，-f 用來指定設定檔。若由 Clash 用戶端啟動，請查看核心啟動記錄或用戶端提供的資料目錄入口。用戶端安裝目錄、訂閱儲存目錄與核心執行目錄可能各不相同。

mihomo -d /srv/mihomo -f /srv/mihomo/config.yaml

以上為 Linux 路徑範例。此部署方式通常需要在 /srv/mihomo 管理資料庫；Windows 與 macOS 請使用記錄中顯示的實際路徑。Linux 檔名有大小寫之分，手動替換 MMDB 時尤其要確認 Country.mmdb 拼寫正確。

設定 geodata 自動更新

以下範例使用 MetaCubeX 發行的資料庫，並選擇 DAT 作為 GEOIP 後端。請將這些欄位合併至設定檔最上層，不要縮排到 dns、tun 或任何代理群組內。如果已有 geox-url，請直接修改原有區段，避免重複設定鍵。

geodata-mode: true
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"

• geo-auto-update: true：啟用核心的地理資料庫自動更新。
• geo-update-interval: 24：更新間隔為 24 小時，不是 24 秒。
• geox-url.geoip：DAT 格式的 GEOIP 資料來源。
• geox-url.geosite：GeoSite 資料來源。
• geox-url.mmdb：MMDB 資料來源；切換至 MMDB 後端時使用。

設定中列出下載網址，不代表每次啟動都會強制重新下載所有檔案。實際載入與更新狀況請以目前核心的記錄為準。儲存後先驗證設定，再透過用戶端重新載入；若用戶端另有地理資料庫管理機制，也請確認是否會覆蓋這些欄位。

首次啟動時若缺少資料庫，核心可能必須先下載資料才能完成規則載入。若下載所需的網路連線又依賴尚未啟動的代理，就會形成啟動依賴。可先透過可用網路準備本機檔案，待啟動完成後再確認自動更新流程。

手動替換 GeoIP 與 GeoSite 檔案

遇到下載受限、裝置儲存空間不足，或需要還原資料庫時，手動更新較容易掌控。請勿直接寫入核心正在使用的目標檔案，也不要只憑檔名判斷下載是否成功。

1. 記錄執行參數。確認核心版本、工作目錄、設定檔路徑，以及目前的 geodata-mode 值。
2. 備份舊檔。將目前可用的 geoip.dat、geosite.dat 或 Country.mmdb 複製到備份目錄。
3. 下載至暫存位置。確認 HTTP 下載成功，且檔案大小合理。若下載內容是登入頁或錯誤頁，請重新取得正確檔案。
4. 停止核心後再替換。結束用戶端核心或停止對應服務，再將新檔案放入實際工作目錄；保留原檔名並確認讀取權限正確。
5. 測試後重新啟動。使用相同工作目錄驗證設定，啟動後檢查資料庫載入記錄，以及新連線的比對結果。

mihomo -t -d /srv/mihomo -f /srv/mihomo/config.yaml

-t 用於測試設定，不代表已實際連線瀏覽網站。若測試所需資料不存在，也可能觸發下載或錯誤。以 Linux 部署服務時，還要確認執行測試的帳號與服務帳號是否具有相同的目錄存取權限。

替換檔案不保證執行中的核心會立即重新讀取。先停止核心再替換，接著重新啟動，是較明確的操作流程。若新資料導致分類缺失或載入失敗，請還原備份檔與原設定後重新啟動驗證；不要同時更換核心、訂閱與資料庫，再回頭排查原因。

GEOIP 與 GEOSITE 規則寫法

以下範例假設設定中已有名為 PROXY 的策略群組。DIRECT 是內建的直連策略。若實際代理群組名稱是「節點選擇」，請將範例中的 PROXY 替換成該名稱；策略名稱必須與設定一致。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOSITE,github,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

由上而下比對，採用第一條符合的規則

DOMAIN-SUFFIX 可設定明確的網域例外；GEOSITE,github,PROXY 會比對資料庫中的 GitHub 分類；GEOSITE,cn,DIRECT 會比對該資料來源定義的 cn 網域集合；接著由 GEOIP,CN,DIRECT,no-resolve 檢查目標 IP；最後由 MATCH 處理其餘連線。

若將 MATCH 放在最前面，後續規則就不會有比對機會。範圍廣泛的分類若排在精確例外之前，也可能使例外失效。網域規則通常應排在需要依 IP 判斷的規則之前，但實際順序仍須符合使用需求。

no-resolve 控制解析行為，不代表略過 IP 比對

no-resolve 表示不會只為了檢查這條 IP 規則，就主動解析目標網域。如果連線原本已有可用的目標 IP，仍可進行 GEOIP 比對。這不會關閉全域 DNS，也不是防止 DNS 洩漏的獨立開關。

例如，尚未解析的網域若未命中前面的 GEOSITE 規則，遇到帶有 no-resolve 的 GEOIP 規則時，可能會直接繼續比對後續規則。若要讓該網域一律直連，新增精確的網域規則，通常比單純移除 no-resolve 更容易掌控。

更新後仍未生效：排查順序

使用新連線驗證，不要只重新整理頁面

先確認目前使用規則模式，再開啟用戶端的連線記錄，查看目標網域、目標 IP、命中規則與策略鏈。在全域模式下，不能只根據最後的代理出口判斷 GEOIP 或 GEOSITE 是否依預期參與分流。

瀏覽器可能會沿用既有的 HTTP/2 或 QUIC 連線。變更規則或資料後，請關閉舊連線並發出新請求；只重新整理同一個分頁，不一定會重新建立連線。驗證時至少記錄一個應直連的網域、一個應走代理的網域，以及一個已知 IP 目標的結果。

區分 DNS 問題與資料庫問題

CDN、DNS 快取與不同解析器可能讓同一網域解析出不同 IP，因此 GEOIP 結果改變不一定代表資料更新失敗。使用 TUN 或 fake-ip 時，也要檢查核心識別出的網域與實際目標資訊；不要把應用程式看到的合成位址，直接當成公網 IP 歸屬地址。

建議依序維護：先確認目前使用的檔案與核心，再驗證規則分類，最後檢查實際連線。更新資料庫只會刷新分類依據；DNS、規則順序與代理群組選擇仍須分別設定。更多基礎概念請參閱概念速查，部署步驟可參考全平台指南。