GeoIP 與 GeoSite分別解決哪些問題
mihomo 讀取代理規則時，需要逐條比對網域名稱、IP 位址或其他連線屬性。GeoIP 與 GeoSite 都是規則判斷所需的資料，但處理的對象不同。資料庫未更新，不代表所有代理連線都會中斷；更常見的情況是地區判斷過時、新網域未被命中，或啟動時直接提示資料檔案遺失。
GeoIP 依目標 IP 所屬地區分類
GeoIP 資料記錄 IP 位址區段與國家、地區等資訊的對應關係。設定中的 GEOIP,CN,DIRECT 表示：連線取得目標 IP 後，若該位址屬於 CN 分類，就採用 DIRECT 策略。常見檔案包括 Country.mmdb、geoip.dat，實際讀取哪一個取決於 mihomo 設定、用戶端版本與資料模式。
GeoIP 的判斷發生在 IP 層。若網域先解析到錯誤位址、DNS 回應遭到污染，或前面的網域規則已經命中，後續 GEOIP 規則都不會改變已完成的比對。因此，看到「中國大陸網站走代理」時，不能只檢查資料庫日期，也要確認規則順序與 DNS 結果。
GeoSite 依網域名稱集合分類
GeoSite 儲存的是整理過的網域名稱集合。例如 GEOSITE,cn,DIRECT 用來比對 cn 分類中的網域，GEOSITE,category-ads-all,REJECT 則可處理相應分類。常見資料檔名為 geosite.dat。GeoSite 不負責判斷伺服器 IP 屬於哪個國家，而是直接處理請求中的網域名稱。
網域服務新增入口、調整 CDN 網域或更換 API 後，舊版 GeoSite 可能沒有相應記錄。此時連線通常會繼續套用後續規則，例如 MATCH，而不是跳出「資料庫已過期」提示。這也是 GeoSite 問題經常被誤判為節點或訂閱故障的原因。
| 資料類型 | 主要輸入 | 典型規則 | 常見檔案 |
|---|---|---|---|
| GeoIP | 目標 IP 位址 | GEOIP,CN,DIRECT |
Country.mmdb、geoip.dat |
| GeoSite | 請求網域 | GEOSITE,cn,DIRECT |
geosite.dat |
| Rule Provider | 外部規則項目 | RULE-SET,private,DIRECT |
YAML、文字或二進位規則集 |
更新前確認核心、模式與實際資料目錄
同一個桌面用戶端可能先後使用過 Clash Premium、Clash Meta 或 mihomo 核心。舊設定目錄中也可能同時保留多個同名檔案。手動替換前，先在用戶端的「關於」、「核心」或「執行日誌」頁面確認目前使用的核心。建議使用仍在維護中的 mihomo 穩定版，並記錄更新前的核心版本與資料檔案修改時間。
從執行參數確認目錄
mihomo 的資料目錄通常由啟動參數 -d 指定。例如啟動指令中出現 mihomo -d /home/user/.config/mihomo，資料庫就應放在該目錄，而不是可執行檔所在的目錄。桌面用戶端會替使用者傳入自己的資料目錄，因此不能只依作業系統猜測路徑。
- 優先使用用戶端內的「設定」→「設定目錄」或「開啟資料目錄」入口。
- 如果介面沒有入口，可在執行日誌開頭尋找
configuration directory、home directory或-d後面的路徑。 - Windows 可在工作管理員的處理程序詳細資料中確認可執行檔，再從用戶端日誌查看啟動參數。
- macOS 用戶端的資料通常位於使用者資料庫內，但不同應用程式使用的容器目錄不同，應以日誌和介面入口為準。
- Linux 服務由 systemd 啟動時，可使用
systemctl cat mihomo查看ExecStart中的-d參數。
確認目前使用 MMDB 還是 DAT
mihomo 支援不同的地理資料格式。設定啟用 geodata-mode: true 時，通常會搭配 geoip.dat 與 geosite.dat；未啟用此模式的設定，可能使用 Country.mmdb 進行 GEOIP 判斷。不同版本的預設行為可能有所調整，因此應同時查看設定與啟動日誌，不要只根據檔案是否存在來推斷。
geodata-mode: true
geodata-loader: memconservative
geo-auto-update: true
geo-update-interval: 24geo-update-interval 的單位是小時。設定為 24 表示核心每隔一天檢查資料更新。若用戶端會產生執行設定，直接修改產生的檔案，可能在下次啟動或切換訂閱後被覆蓋；應在用戶端的覆寫、Mixin 或全域擴充設定中加入這些鍵。
優先使用用戶端內建更新
支援 mihomo 的用戶端通常會提供 GeoData 或地理資料更新入口。介面名稱會隨版本變化，常見位置是「設定」→「Clash 設定」→「GeoData」，或「設定」→「核心」→「更新地理資料」。操作時不要連續點擊；單次下載可能包含數十 MB 的資料，網路速度較慢時需要等待日誌顯示完成。
- 先更新並啟用目前的設定，確認核心能正常啟動。
- 開啟「設定」中的 GeoData、地理資料或核心資料頁面。
- 分別執行 GeoIP、GeoSite 或全部更新。
- 等待介面顯示完成，再檢查日誌中是否出現
download、unmarshal、permission denied等資訊。 - 重新載入設定；如果用戶端沒有重新載入按鈕，就完全結束應用程式後重新啟動。
- 在連線記錄中觀察一個已知網域實際命中了哪一條規則。
內建更新的優點是用戶端知道自己的資料目錄，也能在下載後以正確檔名寫入。對啟用服務模式或管理員輔助程序的桌面用戶端而言，這種方式還能避免一般使用者程序沒有目錄寫入權限的問題。
啟用 mihomo 自動更新
需要長時間運作的路由器、伺服器或桌面裝置，可以由 mihomo 定期更新。除了開啟 geo-auto-update，也可透過 geox-url 指定各類檔案的網址。網址必須直接回傳對應的二進位檔案，不能回傳發布頁面或需要瀏覽器確認的 HTML 頁面。
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"如果裝置必須透過代理才能存取下載網址，需先確保核心啟動後能建立對外連線。首次啟動時資料庫尚不存在，而規則又依賴 GeoSite，可能形成「沒有資料庫就無法啟動，核心不啟動又無法下載」的循環。此時先手動放入可讀取的資料檔案，再啟用自動更新會更穩妥。
手動替換 GeoIP 與 GeoSite 檔案
用戶端內建更新失敗、離線裝置需要維護，或目前網路無法存取資料來源時，可以手動替換。正確流程不是直接覆蓋正在讀取的檔案，而是先下載到暫存檔名，停止核心，完成替換後再啟動。這樣可降低下載中斷留下半個檔案的機率。
通用替換步驟
- 在用戶端中停止系統代理與 TUN，再結束應用程式；服務模式還要停止對應的背景服務。
- 開啟前文確認的資料目錄，記錄原檔案的大小與修改時間。
- 將舊檔案重新命名為
geoip.dat.bak、geosite.dat.bak或Country.mmdb.bak。 - 將新檔案複製到同一個目錄，並保留核心要求的正確檔名。
- 確認目前使用者或服務帳戶具有讀取權限。
- 啟動用戶端並查看最早一段日誌；確認設定載入完成後，再開啟系統代理或 TUN。
- 保留備份直到驗證結束，確認常用網域規則正常後再刪除。
Linux 或 macOS 環境可以先寫入暫存檔，再使用同一檔案系統內的重新命名完成替換。以下指令需要在 mihomo 實際資料目錄中執行：
curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geoip.dat" -o geoip.dat.new
curl -L "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat" -o geosite.dat.new
mv geoip.dat geoip.dat.bak
mv geosite.dat geosite.dat.bak
mv geoip.dat.new geoip.dat
mv geosite.dat.new geosite.datWindows 手動替換時，如果檔案總管提示檔案正在使用中，表示關閉用戶端視窗後，核心程序或服務仍在執行。應先在用戶端停止服務，或在「工作管理員」→「詳細資料」中確認 mihomo 程序已結束。不要透過反覆覆蓋來繞過檔案佔用提示。
容器與路由器的額外檢查
Docker 部署需要確認資料庫目錄確實透過 volume 掛載到容器使用的 -d 路徑。只替換主機上一個未掛載的目錄，容器內部不會有任何變化。更新後可重新啟動容器，並從日誌確認讀取路徑。OpenWrt 類型的空間有限裝置還要檢查可用容量；下載暫存檔與保留備份時，瞬間使用量可能接近兩到三份資料檔案的大小。
下載失敗與啟動錯誤如何處理
context deadline exceeded 或 TLS 逾時
這類訊息通常表示下載網址未能在逾時期限內完成連線或傳輸。先使用瀏覽器或 curl -I -L 測試同一網址是否能跟隨重新導向，再檢查 DNS、系統時間與對外連線策略。系統時間相差幾分鐘，就可能導致 TLS 驗證失敗。若連線必須經過代理，請確認更新請求實際使用的是可用策略，而不是被 GEOIP 或 MATCH 規則送往失效節點。
回傳 403、404 或下載到 HTML
404 通常表示檔名、發布路徑或資料來源結構已經變更。403 常見原因包括存取頻率限制、網路出口限制，或網址需要額外授權。另一種情況是 URL 指向發布介紹頁，下載結果其實是 HTML。mihomo 隨後會回報解析失敗、格式無效或無法載入資料庫。應改用直接檔案網址，並確認重新導向後的回應類型與檔案大小合理。
permission denied 或檔案無法寫入
先確認錯誤路徑就是目前的資料目錄。Windows 服務模式下，介面程序與背景服務可能使用不同帳戶；Linux systemd 服務也可能透過 User= 指定受限帳戶。目錄必須允許該服務帳戶建立暫存檔、重新命名檔案並讀取更新結果。只替單一舊檔案增加寫入權限，仍可能因目錄不可寫入而失敗。
no such file、MMDB 無法開啟或 GeoSite 載入失敗
這類錯誤應優先檢查檔名大小寫、設定模式與目錄。Linux 會區分 GeoSite.dat 與 geosite.dat。如果設定啟用了 geodata 模式，卻只放入 Country.mmdb，GeoSite 規則仍無法運作；反過來，依賴 MMDB 的設定只有 geoip.dat 也不夠。恢復備份後能啟動，通常表示新檔案不完整、格式不符，或來源與目前核心不相容。
資料庫已更新，規則為什麼仍未生效
規則引擎會依設定中的順序由上而下進行比對，命中後通常不會繼續尋找「更合適」的規則。更新資料庫只會改變 GEOIP 或 GEOSITE 可查詢的資料，不會自動調整規則順序。因此，排查時要在連線記錄中找到目標請求，查看網域、目標 IP、命中規則與最終策略。
前置規則已攔截請求
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT,no-resolve
- MATCH,Proxy在這份設定中，即使 example.com 已被 GeoSite 的 cn 分類收錄，第一條 DOMAIN-SUFFIX 仍會先命中 Proxy。更新 GeoSite 不會覆蓋前置規則。暫時將特定規則移到適當位置，重新載入後再次測試，才能確認是否為順序問題。
no-resolve 改變了 GEOIP 的適用條件
GEOIP,CN,DIRECT,no-resolve 的作用之一，是避免規則為了進行比對而主動觸發額外的 DNS 解析。如果目前連線只有網域、尚未取得可用於判斷的目標 IP，這條規則可能無法產生預期結果。設定中已有 GEOSITE 網域規則時，通常先依網域分類，再用 GEOIP 處理剩餘的 IP 連線，邏輯會更清楚。
DNS 模式與嗅探結果會影響可見網域
TUN 模式下，應用程式可能直接連線至 IP，也可能透過 QUIC、加密 DNS 或內建解析器發起請求。若 mihomo 沒有取得網域名稱，GeoSite 就沒有可供比對的輸入。啟用網域嗅探可以涵蓋部分情境，但不應將嗅探視為所有連線都能還原網域的保證。排查時可比較系統代理模式與 TUN 模式下的連線詳細資料，確認記錄中是否出現完整網域。
編輯的是訂閱原始檔，不是執行設定
桌面用戶端經常會將訂閱、覆寫內容與全域設定合併為暫時的執行設定。直接修改快取中的訂閱 YAML，下次更新訂閱就會還原；直接修改執行設定，下次切換設定也會消失。應在用戶端的「設定」→「覆寫」或「設定」→「全域擴充」中儲存自訂項目，再透過日誌或設定檢查功能確認最終結果。
Rule Provider 沒有隨 GeoData 更新
RULE-SET 引用的外部規則集由 rule-providers 管理，擁有自己的 URL、快取路徑與更新間隔。更新 geoip.dat 與 geosite.dat 不會重新整理這些 Provider。若實際命中的是 RULE-SET，應在用戶端的規則集頁面執行更新，或檢查對應 Provider 的 interval 與下載日誌。
一份可重複執行的維護清單
一般桌面裝置不必每天手動替換資料庫。更實用的做法是讓用戶端或 mihomo 每 24 小時檢查一次，並在分類異常時依固定步驟定位。伺服器與路由器則應將資料目錄、備份及服務帳戶權限一併納入維護。
- 確認目前使用 mihomo 核心，並記錄版本號。
- 從啟動參數或日誌確認實際資料目錄。
- 檢查設定使用 DAT 模式還是 MMDB 模式。
- 優先透過用戶端內建入口更新一次。
- 查看日誌，確認下載、寫入與重新載入都已完成。
- 手動替換時先停止核心，保留一份可還原的舊檔案。
- 利用連線記錄驗證網域、目標 IP、命中規則與最終策略。
- 分別檢查 GeoData、訂閱規則與 Rule Provider，不要將三者視為同一項更新。
- 如果結果仍不正常，依序排查規則順序、DNS、TUN、嗅探與執行設定。
判斷維護是否成功，不能只看按鈕顯示「更新完成」。至少應分別測試一個 GeoSite 網域規則、一個 GEOIP 位址規則與一個 Rule Provider 規則。連線記錄中能看到預期的規則名稱與策略，且重新啟動用戶端後結果仍維持一致，才表示檔案路徑、設定模式與更新機制已正確銜接。