一、GeoIP 與 GeoSite 分別管什麼
把分流規則想像成一道分類例題：每來一條連線，核心要回答兩個問題——這個目標 IP 屬於哪個國家或地區？這個目標網域屬於哪一類站點？前一個問題查 GeoIP 資料庫，後一個問題查 GeoSite 資料庫。兩份檔案各司其職、互不替代，缺了哪一份，對應的規則就查不到答案。
GeoIP：IP 對應國家地區的對照表
GeoIP 資料庫存的是 IP 位址段與國家/地區代碼的對照。規則裡寫 GEOIP,CN,DIRECT，核心拿到連線的目標 IP 後去庫裡查，命中 CN 段就走直連。mihomo（Clash Meta）核心預設讀取 country.mmdb，首次載入時會產生一份自用的 geoip.metadb 快取；把 geodata-mode 設為 true 後，GEOIP 規則改為讀取 v2ray 格式的 geoip.dat。另外還有一份可選的 ASN 資料庫 GeoLite2-ASN.mmdb，供 IP-ASN 規則按自治網域編號分流。這些名詞在名詞解釋頁都有對應條目，卡關時可以回查。
GeoSite：網域對應站點分類的對照表
GeoSite 資料庫來自社群的 domain-list-community 專案：維護者把海量網域按服務、廠商、地區整理成分類清單，再編譯成一份 geosite.dat。規則裡寫 GEOSITE,google，核心就把目標網域與 google 分類下的條目逐條比對。分類支援屬性修飾，例如 google@cn 只命中 google 分類裡被標記為中國大陸屬性的條目，顆粒度比整個分類更細。
| 對比項 | GeoIP | GeoSite |
|---|---|---|
| 預設檔案 | country.mmdb / geoip.metadb | geosite.dat |
| 回答的問題 | 這個 IP 屬於哪個國家/地區 | 這個網域屬於哪一類站點 |
| 對應規則 | GEOIP,CN,DIRECT | GEOSITE,cn,DIRECT |
| 資料內容 | IP 段與國家代碼的對照 | 網域與分類標籤的對照 |
| 常見來源 | meta-rules-dat 倉庫 | meta-rules-dat 倉庫 |
二、為什麼這兩份資料庫要定期更新
兩份資料庫都是活資料。雲端廠商每月都在擴容，IP 段會在地區之間重新劃分；新服務上線、舊網域易主，站點分類也隨之變化。資料庫停在半年前，分流判斷就按半年前的世界運作，常見的後果有三類：
- 該直連的走了代理：新劃入 CN 的 IP 段在舊庫裡沒有記錄，被兜底規則送去代理，存取台灣本地站點反而繞路。
- 該代理的走了直連：新上線的境外服務網域還沒進 geosite 分類，被 GEOIP 或兜底規則放行直連，表現為打不開或時好時壞。
- 規則命中率下降：分類條目變動後，原先依賴的分類名可能拆分或改名，舊規則形同虛設。
一般使用強度下，每一到四週更新一次已經足夠；如果規則對時效敏感，例如需要第一時間識別新上線的服務，可以把自動更新間隔壓到 24 小時，代價只是每天多拉取一次幾 MB 的檔案。
三、更新資料庫的三種方法
方法一：用戶端介面按鈕（最省事）
圖形用戶端把更新做成了按鈕。以 Clash Verge Rev 為例，設定頁裡有 GeoIP、GeoSite 等外部資源條目，點更新即可拉取最新檔案；FlClash 等用戶端也有類似的資源更新入口。更新完成後重載一次設定或重啟核心，讓新庫真正生效。這一步適合所有人，先講做法再講原理：按鈕背後執行的，正是方法三裡手動做的那套下載替換。
方法二：在設定檔裡開啟自動更新
mihomo 核心自帶自動更新開關，寫進 config.yaml 頂層即可：
# Geo 資料庫自動更新
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"
asn: "https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/GeoLite2-ASN.mmdb"三個要點：geo-update-interval 的單位是小時，不是秒；geox-url 的四個鍵分別對應 geoip.dat、geosite.dat、country.mmdb 與 ASN 庫，用不到的鍵可以不寫；GitHub 直連不穩的網路環境，把網址換成可存取的鏡像即可，檔案內容一致。
方法三：手動下載替換檔案（最可控）
介面更新失敗，或想精確控制檔案版本時，手動替換最可靠：
- 開啟下載來源用瀏覽器造訪 meta-rules-dat 倉庫的 Release 頁，找到 geoip.dat、geosite.dat、country.mmdb、GeoLite2-ASN.mmdb 四個檔案。
- 下載到本機逐個點開下載；命令列環境也可以用 curl 一次拉取單個檔案。
- 找到設定目錄mihomo 的設定目錄與 config.yaml 同層；Clash Verge Rev 可在設定裡一鍵開啟設定目錄。
- 替換並重啟用新檔案覆蓋舊檔案，重啟核心或重載設定，讓核心重新讀庫。
curl -L -o geosite.dat https://github.com/MetaCubeX/meta-rules-dat/releases/download/latest/geosite.dat替換前先停核心
部分系統下檔案被佔用會導致覆蓋失敗，替換前先退出或暫停核心；替換後看一下執行日誌，確認 geo 檔案載入沒有出錯再收尾。
四、在分流規則裡引用 geoip 與 geosite
資料庫就位後，規則才有查詢的對象。一段典型的分流收尾長這樣：
rules:
- GEOSITE,category-ads-all,REJECT # 廣告網域，直接封鎖
- GEOSITE,google,節點選擇 # Google 系服務走代理
- GEOSITE,cn,DIRECT # 台灣及中國大陸站點直連
- GEOIP,CN,DIRECT,no-resolve # 目標 IP 位於中國大陸則直連
- MATCH,節點選擇 # 其餘全部走代理逐條推演順序：連線進來先比對網域分類，GEOSITE 三條把能按網域判斷的都處理完；輪到 GEOIP 時，目標若是 IP 直接查庫，若是網域則取決於 no-resolve——不加時核心先做 DNS 解析再查庫，判斷更全但多一次解析；加上 no-resolve 則只對 IP 形態的連線生效，省掉解析開銷，代價是網域形態的連線會漏過這條規則。上面這段設定把 GEOSITE,cn 放在前面兜住了本地網域，所以 GEOIP 加 no-resolve 也不會放過它們。
常用 geosite 分類速查：
| 分類名 | 涵蓋內容 |
|---|---|
| category-ads-all | 廣告與追蹤網域合集 |
| cn | 中國大陸站點網域 |
| geolocation-!cn | 中國大陸以外的站點 |
| google / youtube | Google 系服務與 YouTube |
| telegram | Telegram 全系網域 |
| github | GitHub 主站與資源網域 |
| apple / microsoft | 蘋果與微軟的服務網域 |
| gfw | 常見被封鎖站點合集 |
兩點書寫慣例：分類名一律按官方清單的小寫形式書寫，寫錯不會出錯訊息、只會靜靜不命中；需要更細顆粒度時用 @ 屬性，例如 GEOSITE,google@cn,DIRECT 把 Google 在中國大陸可達的網域單獨放行，GEOSITE,geolocation-!cn,節點選擇 則等同於「境外站點統一走代理」。
五、更新與引用的常見問題
更新按鈕一直失敗
九成是下載來源無法連線。GitHub Release 在部分網路環境下直連困難，把 geox-url 換成鏡像網址，或先讓用戶端自身走上代理再點更新；也可以直接用方法三手動替換，繞開用戶端的下載邏輯。
規則寫了卻不生效
按順序查三處：一看規則順序，GEOSITE/GEOIP 是否被前面的寬泛規則（如位置靠前的 MATCH 或大段 IP-CIDR）截走；二看是否重載，改完設定要重載或重啟核心才會重新讀庫；三看分類名拼寫，寫錯的分類名不會跳出錯誤，只會靜靜地漏判。
低記憶體裝置載入吃力
路由器等低規格裝置可以把 geodata-loader 設為 memconservative，用載入速度換記憶體佔用；一般 PC 保持預設的 standard 即可。
把更新頻率交給 geo-auto-update，把分流判斷交給順序合理的規則，這兩份資料庫就能長期安靜地運作。如果規則分流的整體架構還沒搭起來，先回使用指南補齊基礎，再回來調整這份進階設定，順序不要顛倒。