規則資料 預計閱讀 12 分鐘

Clash GeoIP 與 GeoSite 使用方法：資料庫更新與規則引用

說明 GeoIP 與 GeoSite 的用途、規則寫法、更新流程及常見載入問題。

GeoIP 與 GeoSite 分別解決哪些問題

GeoIP 和 GeoSite 都能減少在設定檔中逐條維護規則的工作量，但兩者判斷連線的依據不同。GeoIP 會根據目標 IP 位址所屬的國家、地區或網路集合進行比對；GeoSite 則根據目標網域所屬的網站分類進行比對。前者處理的是 IP，後者處理的是網域，不能將兩個名稱理解為同一份資料庫的不同寫法。

當應用程式連線至某個網域時，Clash 或 Mihomo 通常會先取得連線中繼資料，再依規則清單由上到下進行比對。如果規則中存在合適的網域條件，GeoSite 可以在網域階段直接決定策略；如果前面的網域規則沒有命中，核心可能繼續解析目標位址，再交由 GeoIP 規則判斷。實際行為還會受到 DNS 模式、嗅探、規則順序，以及是否加入 no-resolve 的影響。

目標 IP 分類

GEOIP

根據目標 IP 所屬集合比對連線，常用於地區分流和最後階段的網路歸類。

目標網域分類

GEOSITE

根據網域類別比對連線，可表達網站、服務類型及組合分類等規則集合。

GeoIP 的優點是能處理直接連線至 IP 的請求，也能涵蓋網域解析後的位址。不過，雲端服務和內容傳遞網路可能讓同一個網站使用不同地區的節點，IP 註冊地也不一定等同於業務所在地。因此，GeoIP 適合作為分流依據之一，而不是判斷網站身分的唯一標準。

GeoSite 的分類更接近「這個網域屬於哪一類服務」。例如，某個集合可以包含主網域、API 網域、靜態資源網域和內容傳遞網域。它通常比只寫一條 DOMAIN-SUFFIX 更完整，但分類結果取決於資料庫專案的維護方式；新網域出現後，只有在資料庫更新並由用戶端重新載入後，規則才能涵蓋該網域。

Clash GeoIP 與 GeoSite 規則寫法

規則放在設定檔的 rules 區段中，並依照出現順序進行比對。命中一條規則後，連線會交由該規則指定的策略群組或內建動作處理，後續規則不再處理這次連線。因此，具體的網域分類通常應放在寬泛的地區 IP 規則之前，最後再使用 MATCH 處理尚未命中的流量。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

第一項是規則類型，第二項是資料庫中的分類代碼，第三項是策略名稱或動作。上例先處理廣告網域分類，再讓常見的中國大陸網域直連，接著以 GeoIP 處理先前未命中的中國大陸目標位址，最後將其餘連線交給名為「節點選擇」的策略群組。設定中的策略名稱必須與 proxy-groups 中定義的名稱完全一致，包括大小寫、空格和標點符號。

何時使用 no-resolve

GeoIP 規則可以加入 no-resolve 參數，常見寫法如下：

rules:
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,節點選擇

no-resolve 表示不要為了執行這條規則而主動將網域解析成 IP。如果目前連線已帶有目標 IP，GeoIP 仍然可以進行比對；如果只有網域，且先前沒有取得可用於判斷的位址，這條規則就會被跳過。這個參數適合用來控制額外的 DNS 查詢，以及避免某些解析鏈路，但也會降低 GeoIP 對純網域請求的涵蓋率。

是否加入這個參數不能只看現成設定。使用 Fake-IP、Redir-Host、TUN 模式或網域嗅探時，核心能取得的連線資訊不完全相同。修改後應查看連線詳細資料中的目標主機、規則類型和最終命中項目，確認實際流量是否依預期分流。

資料庫檔案、核心版本與相容性界線

不同核心分支和用戶端使用的地理資料檔案不完全相同。常見檔案包括用於 IP 判斷的 Country.mmdb、GeoIP 資料檔案，以及用於網域分類的 GeoSite.dat。Mihomo 也提供地理資料載入模式、自動更新週期和資料位址等設定功能。具體檔名、預設目錄與可用欄位，應以核心版本和用戶端文件為準。

經典 Clash 核心、Clash Meta 的後續分支 Mihomo，以及整合 Mihomo 的圖形化用戶端，支援範圍各有差異。某份設定能識別 GEOIP，不代表一定支援相同的 GEOSITE 分類、載入器選項或新格式資料庫。遇到「不支援規則類型」時，首先應確認用戶端實際使用的核心，而不是只看用戶端介面名稱。

查看實際核心與資料目錄

  1. 在用戶端的關於、核心設定或日誌頁面確認核心名稱與版本。
  2. 檢查用戶端的設定目錄，而不是安裝程式所在的目錄。可攜版和系統安裝版的位置可能不同。
  3. 在啟動日誌中搜尋 GeoIP、GeoSite、mmdb 或 geodata，確認核心最後讀取了哪個檔案。
  4. 如果用戶端提供「更新地理資料」功能，請記錄更新完成後的檔案時間和下一次啟動日誌。

不要將規則提供者與地理資料庫混為一談。rule-providers 通常會載入獨立的規則集合，再透過 RULE-SET 引用；GeoIP 和 GeoSite 則由核心依對應的規則類型查詢地理資料。兩者可以同時存在於同一份設定中，但更新入口、快取檔案和錯誤訊息通常不同。

GeoIP 與 GeoSite 資料庫更新流程

更新資料庫並不是將檔案下載到任意目錄即可。核心只會讀取設定指定的位置或用戶端約定的資料目錄，更新後的檔案也必須在重新載入設定或重啟核心後才會生效。如果圖形化用戶端內建更新按鈕，優先使用該入口，因為它通常會處理下載位置、暫存檔替換和核心重新載入。

用戶端內建更新

  1. 先確認目前設定能正常啟動，並匯出或複製一份可還原的設定。
  2. 進入核心、設定或資料管理頁面，找到地理資料更新功能。
  3. 等待 GeoIP 與 GeoSite 兩類資料分別完成更新，不要在寫入過程中強制結束用戶端。
  4. 重新載入設定或重啟核心，查看日誌是否出現資料庫載入成功的訊息。
  5. 使用連線清單檢查一個已知網域和一個已知地區 IP 的命中規則。

手動替換資料庫

只有在用戶端沒有更新入口，或需要固定資料版本時，才建議手動替換。操作前先完全停止核心，確認舊檔名、目錄和設定引用，再以用途相同的新檔案替換。不要只憑副檔名判斷檔案是否可以互換：MMDB、DAT 和其他精簡規則格式採用不同的資料組織方式，必須與目前核心的載入方式相符。

如果用戶端啟用了自動更新，也應檢查更新週期和資料來源設定。自動更新成功只代表檔案已取得並儲存完成，最終是否生效仍要查看後續載入日誌。裝置長時間休眠、用戶端未執行、系統時間異常或網路策略阻止更新連線，都可能導致排程工作未依預期執行。

如何決定更新頻率

地理資料不需要在每次連線前更新。對一般個人設定而言，依用戶端預設週期更新通常已足夠；如果規則專案變更頻繁，或近期出現無法分類的新網域，可以主動執行一次更新。企業網路或固定環境更應先測試新資料，避免分類調整導致大量連線的策略改變。

資料庫版本和設定規則應作為一組變更記錄。更新後若出現分流變化，至少需要知道更新日期、核心版本、設定版本和命中的分類代碼，才能判斷問題來自資料內容、規則順序還是核心行為。

載入失敗與規則未命中的排查順序

GeoIP 或 GeoSite 問題通常分為三類：設定無法啟動、資料庫載入報錯，以及設定可以執行但連線沒有命中預期規則。三類問題的檢查重點不同，應先從日誌確認屬於哪一類，再修改設定。

一、提示找不到資料庫檔案

先核對日誌中的完整路徑，確認執行核心的帳戶具有目錄讀取權限。多個用戶端共存時，很容易將檔案放進另一個用戶端的設定目錄。也應檢查檔名大小寫；在區分大小寫的檔案系統中，GeoSite.dat 與 geosite.dat 可能會被視為不同檔案。

二、提示格式無效或載入失敗

這通常表示資料檔案與載入器不相容、檔案下載不完整，或核心版本無法識別該格式。還原舊檔案後若能正常啟動，便可進一步確認新檔案的來源類型和目標核心要求。不要透過反覆修改規則名稱來處理底層檔案格式錯誤，因為規則尚未進入比對階段。

三、GeoSite 分類未命中

  • 確認日誌沒有回報未知規則類型或未知分類代碼。
  • 檢查該網域是否確實收錄在目前資料庫版本的目標分類中。
  • 檢查前面是否已有 DOMAIN、DOMAIN-SUFFIX、RULE-SET 或其他 GeoSite 規則提前命中。
  • 查看連線詳細資料中是否保留目標網域；只有 IP 資訊時，便無法完成網域分類判斷。
  • 重新載入設定，避免介面雖已儲存 YAML，但執行中的核心仍在使用舊設定。

四、GeoIP 地區判斷與預期不一致

先確認連線詳細資料顯示的是最終目標 IP，而不是本地 Fake-IP、代理節點位址或 DNS 伺服器位址。內容傳遞網路會將同一項服務調度至不同地區，資料庫中的網路歸屬也可能與實際機房位置不同。如果特定業務必須穩定使用某個策略，優先採用明確的網域規則或維護範圍可控的規則集，再將 GeoIP 作為後續兜底。

五、TUN 模式下結果發生變化

TUN 模式能接管更多不遵循系統代理設定的流量，因此連線數量、協定類型和可見目標都可能改變。啟用 TUN 後出現不同的命中結果，不一定表示資料庫損壞。應同時檢查 DNS 劫持、Fake-IP 範圍、網域嗅探和路由排除項目。先用同一個目標分別記錄一般系統代理與 TUN 模式下的連線詳細資料，再比較目標網域、目標 IP 和命中規則。

更新後的驗證方法

驗證不能只看用戶端是否顯示「更新完成」。完整檢查應涵蓋檔案載入、規則解析和實際連線命中三個層次。第一步查看啟動日誌，確認資料庫已由目前核心讀取；第二步檢查設定解析結果，確認 GeoIP、GeoSite 分類與策略群組名稱有效；第三步產生測試流量，並在連線清單中查看最終規則和策略。

建議選擇幾類目標進行對照：一個應由明確 GeoSite 分類處理的網域、一個直接存取 IP 的連線，以及一個不會命中特定分類的一般網域。測試期間暫時停用瀏覽器本身的代理擴充功能和安全 DNS，減少額外鏈路對結果的干擾。終端機測試還要確認是否設定了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，這些變數會改變請求進入 Clash 的方式。

如果規則結果與預期不同，可以在設定副本中暫時將待測規則移到更前面的位置。若移動後能夠命中，問題多半出在順序或覆蓋關係；若仍未命中，再檢查分類內容、目標資訊和資料庫載入狀態。定位完成後應恢復合理順序，避免為了單一網域讓寬泛規則長期佔據最高優先級。

GeoIP 與 GeoSite 的穩定使用取決於四個條件：核心支援對應的規則類型、資料庫格式與載入方式一致、規則順序符合分流目標，以及更新後的資料已由執行中的核心重新載入。依這四個層次逐項檢查，比反覆更換資料庫或複製整套設定更容易找出原因。

下載Clash