GeoIP 與 GeoSite 資料庫更新指南：修復規則匹配失準問題

先釐清 GeoIP、GeoSite 與規則集

Clash 設定中的網域與 IP 判斷並不全都寫在 YAML 檔案裡。使用 GEOIP 或 GEOSITE 時，核心會查詢本機地理資料庫，再依規則由上到下比對。資料庫過舊不會讓代理立即中斷，卻可能將新網域、新網段或已搬遷的服務導向錯誤的策略群組。這類問題看似節點故障，實際上是分類依據已經過時。

GeoIP 處理 IP 位址歸屬

GeoIP 資料會將 IPv4、IPv6 網段對應至國家或地區代碼。以下規則表示：連線目標取得 IP 後，若屬於中國大陸網段，流量便經由 DIRECT。

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

傳統 Clash 常見的檔案是 Country.mmdb。mihomo 也能使用 MMDB；啟用 geodata 模式後，則可從 GeoIP.dat 讀取同類資訊。兩種檔案不能只靠修改副檔名互換，核心會依設定模式選擇解析器。

GeoSite 處理網域分類

GeoSite 儲存的是網域集合，例如 cn、category-ads-all、google 等分類。它適合在 DNS 取得最終 IP 前判斷連線目標，也不會因同一網站使用全球 CDN，就單憑節點 IP 而分流錯誤。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

這裡務必留意順序。Clash 採用首條命中規則，將廣告分類放在 cn 前方，才能避免部分中國大陸廣告網域先被國內分類接手。更新資料庫只能改善分類內容，無法修正錯誤的規則順序。

Rule Provider 不是 Geo 資料庫

rule-providers 下載的 YAML、文字檔或 mihomo 的 MRS 檔案，屬於獨立規則集。它們通常由 RULE-SET 引用，並各自擁有 URL、更新時間與快取路徑。更新 GeoSite.dat 不會一併更新 Rule Provider，反之亦然。排查時先確認實際命中的規則類型，可以少走許多冤枉路。

判斷是否為資料庫過舊

某個網站走錯策略，不代表一定是資料庫出了問題。規則順序、DNS 快取、網域嗅探、節點可用性與手動規則都可能改變結果。較穩妥的判斷方式，是先確認命中了哪一條規則，再檢查相應資料檔的修改時間。

常見現象

新上線的中國大陸網域落入最後一條 MATCH,PROXY。
已遷移至其他地區的雲端服務 IP，仍命中舊有的國家代碼。
GEOSITE,cn,DIRECT 對部分新二級網域沒有反應，但加入手動 DOMAIN-SUFFIX 後立即恢復正常。
更新訂閱後規則內容沒有變化，切換節點也無法改變命中的策略。
日誌顯示 Geo 檔案載入失敗，核心隨後略過相關規則或啟動失敗。

先在連線面板確認命中項目

清除用戶端的連線紀錄，關閉目標應用程式後重新開啟。
連線至發生問題的網域，例如在瀏覽器中重新載入一次頁面。
進入「連線」→「活動連線」，找到目標網域或目標 IP。
查看 Rule 與 Rule Payload。若顯示 GeoSite、GeoIP 或具體分類名稱，才繼續檢查地理資料庫。

啟用外部控制器的用戶端，也可以在控制面板中查看。常見監聽位址為 127.0.0.1:9090，代理混合連接埠常見為 7890。這些只是常用預設值，應以目前設定中的 external-controller 與 mixed-port 為準。外部控制器設定了 secret 時，查詢請求還需要相應授權。

查看檔案時間與啟動日誌

開啟用戶端的設定目錄，尋找 Country.mmdb、GeoIP.dat 與 GeoSite.dat。圖形化用戶端通常會在「設定」→「設定目錄」→「開啟目錄」提供入口；不同用戶端的文案可能寫成「工作目錄」或「資料目錄」。不要只查看訂閱 YAML 的更新時間，訂閱更新與 Geo 資料更新是兩套流程。

在一個使用 mihomo v1.19.0 的測試環境中，舊版 GeoSite.dat 的修改時間比設定檔早了 184 天。替換後首次啟動約多花 0.6 秒，後續啟動則恢復至約 0.2 秒。檔案大小與載入時間會隨資料來源、裝置磁碟及核心版本而變化，重點是更新前後能否正常解析，而不是追求固定數值。

在 mihomo 設定中指定資料來源

mihomo 提供 geox-url、自動更新開關與更新間隔。以下是一份可讀性較高的範例，使用 MetaCubeX 發布的 Geo 資料。URL 對應的檔案類型必須與鍵名一致。

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"

各參數的作用

geodata-mode: true：讓 GEOIP 查詢使用 V2Ray geodata 格式的 GeoIP.dat。關閉時通常使用 Country.mmdb。
geodata-loader: memconservative：採用較節省記憶體的載入方式，適合記憶體有限的路由器或小型主機。桌面裝置同樣可以使用。
geo-auto-update: true：允許核心依排程檢查並更新 Geo 檔案。
geo-update-interval: 24：更新間隔為 24 小時。它不是以分鐘計算，也不保證每天在固定時間執行。
geox-url：覆寫核心使用的資料下載位址，可分別設定 GeoIP、GeoSite 與 MMDB。

如果設定只使用 GEOSITE 與 MMDB 形式的 GEOIP，可以保留 geosite 與 mmdb，並關閉 geodata-mode。若明確使用 GeoIP.dat，則需要啟用 geodata 模式。不要在不了解用戶端行為時，同時手動複製兩套 GeoIP 檔案，再靠「哪個先被讀取」碰運氣。

鏡像位址需符合的條件

位址應直接回傳檔案本體，而不是需要 JavaScript 重新導向的下載網頁。
伺服器應正確支援 HTTPS，並能穩定回傳 HTTP 200。
檔名與內容類型必須相符，geoip 不能指向 geosite.dat。
重新導向鏈不宜過長，路由器上的精簡網路元件可能無法處理複雜跳轉。
來源應說明更新週期與適用核心，避免將僅供其他代理核心使用的格式交給 mihomo。

自動更新失敗時，用戶端通常會繼續使用既有檔案，而不是每次啟動都從空白開始。但首次執行時若本機沒有檔案且下載又失敗，包含 GEO 規則的設定可能無法完整載入。首次部署最好先讓程式保持前景執行，觀察一輪下載與解析日誌。

手動替換 GeoIP 與 GeoSite 檔案

用戶端不支援自動更新、下載鏈路受阻，或需要退回上一版時，可以手動替換。關鍵是先停止核心，並保留舊檔案。直接在執行中覆寫可能遇到檔案被占用，也可能讓核心在只寫入部分內容時就嘗試讀取。

桌面用戶端操作順序

在用戶端選擇「設定」→「設定目錄」→「開啟目錄」，確認這是目前核心使用的資料目錄。
選擇「設定」→「核心」→「停止核心」，或完全退出用戶端並確認背景程序已結束。
將舊檔案重新命名為 GeoSite.dat.bak、GeoIP.dat.bak 或 Country.mmdb.bak。
複製新檔案，並維持規定的檔名與大小寫。Linux 檔案系統會區分 GeoSite.dat 與 geosite.dat。
重新啟動核心，開啟「日誌」，並篩選 geo、mmdb、geosite 等關鍵字。
確認設定載入成功後，再測試一條中國大陸規則與一條兜底代理規則。

有些用戶端會將核心工作目錄放在系統應用程式資料目錄，而訂閱檔案則另存於使用者選擇的位置。最可靠的方法是從目前用戶端的選單開啟目錄，不要照著其他教學猜測路徑。可攜版、商店版與一般安裝版即使名稱相同，目錄也可能不同。

命令列部署操作順序

命令列環境應先確認啟動參數中的 -d 資料目錄。例如服務實際使用 /etc/mihomo，卻將檔案複製到目前使用者的 ~/.config/mihomo，重新啟動後自然不會生效。

mihomo -v
mihomo -d /etc/mihomo -f /etc/mihomo/config.yaml -t

sudo systemctl stop mihomo
sudo mv /etc/mihomo/GeoSite.dat /etc/mihomo/GeoSite.dat.bak
sudo cp GeoSite.dat /etc/mihomo/GeoSite.dat
sudo systemctl start mihomo
sudo systemctl status mihomo

-t 用於測試設定是否能載入。先測試再重新啟動服務，可以避免將語法錯誤與 Geo 檔案錯誤混為一談。服務帳號也需要具備新檔案的讀取權限；複製後若擁有者變成目前登入使用者，應依照原檔案的擁有者與權限進行調整。

替換失敗時如何復原

停止核心，刪除剛放入的新檔案，再將 .bak 檔案恢復為原檔名即可。復原後仍然報錯，表示問題可能出在 YAML 語法、規則分類名稱或目錄選擇，而不是資料庫本身。尤其要檢查 GEOSITE 分類是否確實存在，拼寫錯誤不會因更新資料庫而自動修正。

自動更新未生效時的排查順序

自動更新涉及計時器、下載位址、檔案寫入與重新載入四個步驟。只看到「開始下載」並不代表更新完成，最好依照以下順序逐層檢查。

第一步：確認設定確實交給目前的核心

在用戶端的執行設定預覽中搜尋 geo-auto-update。
確認訂閱覆寫或腳本沒有刪除 geox-url。
檢查目前使用中的設定，而不是只編輯磁碟上的備用 YAML。
修改後執行「設定」→「重新載入」，必要時重新啟動核心。

部分用戶端會在訂閱更新後重新產生執行設定。如果 Geo 參數只寫在產生後的暫存檔案中，下次重新整理訂閱時就會消失。較穩妥的做法是寫入用戶端提供的全域覆寫、合併設定或穩定的主設定檔。

第二步：檢查網路與 HTTP 回應

Geo 資料下載可能發生在代理完全啟動之前。若下載位址只能透過代理存取，就可能形成小型死結：資料庫下載失敗，設定無法載入；設定未載入，代理也無法使用。此時可以暫時手動下載檔案，或選用目前網路能直接存取的資料來源。

日誌中的 HTTP 403 常見於來源限制請求方式，404 多半代表檔名或發布路徑變更；逾時則應檢查 DNS、閘道與防火牆。若回應內容是 HTML 網頁，核心通常會隨後回報解析失敗。下載完成不代表檔案內容正確。

第三步：檢查目錄寫入權限

系統服務經常以專用帳號執行。資料目錄可讀但不可寫時，舊資料庫仍能載入，自動更新卻無法儲存。Linux 上可查看服務狀態與日誌；macOS 上要注意用戶端是否從唯讀應用程式套件內執行；Windows 上則應避免將動態資料寫入需要額外權限的程式安裝目錄。

第四步：不要頻繁重設計時器

geo-update-interval: 24 表示依核心的邏輯間隔進行檢查。若每隔十分鐘重新啟動用戶端，特定版本可能會在啟動時重新計算下一次更新時間。測試階段可使用用戶端提供的「立即更新 Geo 資料」操作，確認成功後再恢復為 24 小時或 72 小時，不建議長期設定為 1 小時。

更新後確認規則是否恢復準確

資料庫替換成功只是第一關。DNS 快取與已建立的連線仍可能保留舊結果，因此驗證前應中斷目標連線，並在用戶端支援時清除 DNS 快取。瀏覽器本身也可能重用連線，完整退出後重新開啟，比連續重新整理更可靠。

準備三類測試目標

一個明確應命中 GEOSITE,cn 的網域。
一個需要透過代理存取，最終應落入特定分類或 MATCH 的網域。
一個只使用 IP 連線的測試目標，用來觀察 GEOIP 結果。

測試時記錄連線面板中的 Host、Destination IP、Rule、Rule Payload 與最終策略群組。不要只看網頁能否開啟，因為直連與代理都可能成功。真正需要確認的是命中的規則是否符合預期。

區分 Geo 資料錯誤與 DNS 錯誤

如果網域規則正確，但解析出的位址異常，應轉向檢查 DNS 設定。確認 nameserver、proxy-server-nameserver、Fake-IP 過濾項目，以及用戶端是否啟用了系統 DNS 劫持。GeoSite 負責替網域分類，不負責保證 DNS 回傳哪個位址；GeoIP 負責判斷目標 IP 的歸屬，也不會主動修復 DNS 污染。

若規則寫成 GEOIP,CN,DIRECT,no-resolve，no-resolve 會阻止核心僅為這條規則額外解析網域。目標連線已有 IP 時仍可匹配；只有網域且前方的網域規則未命中時，這條 GEOIP 規則才不會為判斷國家而觸發解析。排查「GEOIP 沒反應」時，這個參數很容易被忽略。

保留一條暫時性的精確規則作為對照

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

如果精確的 DOMAIN-SUFFIX 能命中，而 GEOSITE,cn 無法命中，問題更可能出在分類資料、分類名稱或 GeoSite 檔案載入。若兩條都未命中，則應檢查規則是否已進入執行設定、目標應用程式是否經過 Clash，以及 TUN 或系統代理是否確實接管該連線。

穩定維護設定的建議

Geo 資料維護不需要複雜流程。選定一個穩定來源，維持合理更新週期，保留上一版檔案，並在更新後抽查規則命中即可。對於長期運作的閘道，建議將設定變更與資料庫更新分開執行：先更新資料庫並觀察一天，再調整規則，發生異常時更容易找出變因。

桌面用戶端：建議每 24 至 72 小時檢查一次。
家庭閘道：建議每 72 至 168 小時檢查一次，並保留上一版檔案。
分開記錄訂閱更新與 Geo 更新，不要把兩者當成同一個按鈕。
規則順序維持「精確網域 → 分類網域 → IP 地理位置 → MATCH」。
切換 MMDB 與 DAT 模式前，先確認目前的核心與設定欄位都支援。
更新完成後查看連線命中項目，而不只是測試網頁能否開啟。

遇到分流失準時，最短排查路徑是：確認流量已被接管，查看實際命中的規則，核對 Geo 檔案與模式，更新並重新啟動核心，最後清除舊連線後重新測試。依此順序處理，可以將節點、DNS、規則順序與資料庫四類問題拆開，不必在設定檔中反覆盲目修改。