Clash GeoIP 與 GeoSite 資料更新：規則引用、更新週期與異常處理

先區分 GeoIP、GeoSite 與規則集

先說結論：GeoIP 依目標 IP 位址分類，GeoSite 依網域分類，兩者不能互相取代。設定中寫入 GEOIP 或 GEOSITE，只代表規則引擎會查詢對應資料庫；最終採用直連、代理或拒絕，仍由規則末端指定的策略決定。資料庫本身不負責建立代理連線，也不會自動改變目前的代理模式。

GeoIP 資料會將 IP 網段對應至國家、地區或其他可識別分類。常見規則 GEOIP,CN,DIRECT 的意思是：當連線的目標 IP 被資料庫歸類為 CN 時，交由 DIRECT 策略處理。不同核心可能使用 MMDB、專用 GeoIP 資料檔或轉換後的內部格式，檔名與載入方式不一定相同，因此不能只看副檔名判斷目前核心是否正在使用該資料庫。

GeoSite 資料會儲存網域集合與分類標籤，例如地區網域、常用服務或廣告網域分類。規則 GEOSITE,cn,DIRECT 會比對連線中的網域集合。它適合在 DNS 解析前完成網域分流，也能避免只依賴 IP 歸屬時，因 CDN、全球調度與共用位址造成誤判。

規則集通常是由 rule-providers 提供的外部規則檔。它可以載入網域、IP-CIDR 或傳統規則項目，再透過 RULE-SET 引用。規則集與 GeoSite 都能儲存網域分類，但下載位址、更新週期、行為類型與設定入口各不相同。更新某個規則集，不代表 GeoSite 資料也會同步更新；反之亦然。

設定如何引用 GeoIP 與 GeoSite

規則會由上到下檢查，命中後便停止繼續比對。即使資料庫更新成功，如果相關規則排在更寬泛的規則之後，流量仍不會套用新規則。排查「資料庫更新了但分流沒有變化」時，規則順序通常比重複下載檔案更值得優先檢查。

以下是一段適用於支援 GEOSITE 的 Mihomo 設定思路。策略組名稱必須與本機設定一致；範例中的 節點選擇 是策略名稱，不是固定關鍵字。

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

第一條先處理廣告網域分類，第二條處理 CN 網域，第三條在已取得目標 IP 時執行 CN 位址比對，最後一條接管先前未命中的連線。如果將 MATCH 放在開頭，後續資料庫規則將永遠沒有比對機會。如果在 GEOSITE,cn,DIRECT 前放置涵蓋範圍更大的網域規則，也可能提前攔截原本應直連的網域。

no-resolve 通常用於 IP 類規則，作用是避免規則引擎為執行該項比對而額外觸發網域解析。它不表示略過已存在的目標 IP，也不會關閉 DNS 模組。對於直接以 IP 建立的連線，GeoIP 仍可進行比對；對於當時只有網域、尚未取得真實目標 IP 的連線，該規則可能無法命中，流量會繼續檢查後續規則。

網域規則與 IP 規則應同時保留嗎？

多數依地區分流的設定會同時保留。網域仍可見時，GeoSite 會先進行判斷；GeoIP 則可補充直接連線至 IP、缺少網域資訊或未被網域規則涵蓋的連線。由於 CDN 節點可能位於不同地區，服務所屬網域與目標 IP 所在地區不一定一致。需要穩定進行服務層級分流時，應將明確的網域或 GeoSite 分類放在前面，再由 GeoIP 處理剩餘連線。

TUN 與 Fake-IP 模式下的判斷位置

TUN 模式負責接管更多系統流量，不會自動提升規則資料庫的準確度。啟用 Fake-IP DNS 後，用戶端回傳給應用程式的是內部映射位址，核心會盡量還原原始網域並執行網域規則；後續建立真實連線時仍可能取得目標 IP。若某個應用程式直接連線至硬編碼 IP、使用自身的解析機制，或流量缺少可還原的網域資訊，GeoSite 不一定會參與，此時 IP 規則與最終兜底策略更為重要。

若開啟 TUN 後規則表現不同，不應直接判定資料庫損壞。先比較該連線在一般系統代理與 TUN 下是否保留網域，再檢查 DNS 模式、嗅探設定、Fake-IP 過濾項目與規則順序。資料庫只提供比對資料，連線情境則由核心的接管方式決定。

選擇可回復的資料更新方式

更新方式大致分為用戶端託管、核心自動更新與手動替換三類。優先使用用戶端或核心提供的更新入口，因為它們通常知道資料目錄、檔名與重新載入流程。手動下載適合需要固定版本、內網分發或定位更新故障的情境，但替換前必須確認檔案格式與目前核心相容。

用戶端託管更新

部分桌面與行動用戶端會在設定頁提供 GeoIP、GeoSite 或規則資料更新按鈕。按下後，用戶端會負責下載並放入自己的執行目錄；有些實作會自動重新啟動核心，有些則要等到下次載入設定時才生效。操作後應查看更新結果、檔案日期與核心日誌，不要只依按鈕狀態判斷是否成功。

Mihomo 核心自動更新

支援 Geo 資料自動更新的 Mihomo 版本，可透過設定控制是否更新及更新間隔。不同版本對欄位、資料格式與預設位址的處理方式可能有所調整，因此應以目前核心文件與用戶端產生的設定為準。常見設定結構如下：

geo-auto-update: true
geo-update-interval: 24

geo-update-interval 通常以小時為單位。24 小時適合一般使用，不需要將更新間隔縮短至幾分鐘。Geo 資料不是即時路由表，過於頻繁地發出請求，只會增加啟動失敗、網路逾時與檔案寫入衝突的機會。對穩定性要求較高的裝置，可以採用每週一次，或配合用戶端維護時段更新，再透過日誌確認結果。

如果設定還定義了 geox-url，核心會依相應位址取得 GeoIP、GeoSite 或 MMDB 資料。資料來源必須提供目前核心能辨識的內容；填入網頁位址、壓縮檔下載頁或其他格式的檔案時，即使請求成功，也可能在載入階段失敗。若由訂閱轉換服務產生設定，還要確認遠端更新不會覆蓋本機的自動更新欄位。

手動替換資料庫

1. 在用戶端中停止核心，避免資料庫讀取期間被覆寫。
2. 找到用戶端實際使用的資料目錄，而不是安裝包解壓縮目錄或瀏覽器下載目錄。
3. 備份目前可用的檔案，並記錄核心版本與原始檔案的修改時間。
4. 放入格式相符的新檔案，保留用戶端要求的檔名與存取權限。
5. 重新啟動核心並載入設定，檢查日誌中是否出現解析、開啟或權限錯誤。
6. 使用具體網域與 IP 測試規則命中情況，不要以「檔案變大了」作為更新成功的依據。

更新失敗或規則未生效時逐層檢查

排查時應將「下載失敗」、「檔案載入失敗」、「規則沒有引用」與「規則命中但策略結果不符預期」分開處理。它們在介面上都可能表現為網站走錯線路，但處理方法完全不同。建議依資料下載、核心載入、設定解析、規則命中、策略執行五個層面檢查。

第一層：資料是否完成下載

• 查看日誌中的請求狀態、逾時、DNS 解析與連線錯誤。
• 確認更新流量本身能夠存取資料來源；啟動階段尚未建立代理時，下載可能只能使用直連網路。
• 檢查系統時間。時間明顯錯誤可能導致 TLS 連線無法建立。
• 確認儲存空間與目錄寫入權限；行動裝置還要注意系統是否回收應用程式資料，或限制背景網路。
• 檢查用戶端是否將下載結果寫入另一個設定實例的資料目錄。

第二層：核心是否成功載入檔案

下載完成不等於可以載入。若日誌出現資料庫格式無效、標籤不存在、檔案開啟失敗或解析異常，應先回復到先前可用的資料檔。常見原因包括檔案內容實際上是錯誤頁面、資料格式與核心不相容、下載中斷留下不完整檔案，以及檔名或目錄與用戶端約定不一致。

如果是在更換核心後才開始報錯，也要同時檢查用戶端是否仍保留舊核心的資料選項。例如某些用戶端允許在 MMDB 與其他 Geo 資料載入方式之間切換，若切換核心卻未同步調整模式，就可能出現檔案存在但未被讀取的情況。

第三層：目前設定是否真的引用資料庫

在實際執行的設定中搜尋 GEOIP、GEOSITE 或相關 RULE-SET。訂閱頁面顯示的原始 YAML 不一定等於核心最終載入的設定，用戶端可能會合併或覆寫規則、腳本及本機修補內容。應優先查看用戶端匯出的執行設定，確認規則名稱、策略組名稱與縮排都正確。

GeoSite 分類名稱必須存在於目前資料中。更新資料來源後，分類可能增加、拆分或調整；如果設定引用了資料中不存在的標籤，核心可能在載入時直接報錯，也可能導致該規則無法達到預期。分類名稱應與資料來源說明一致，不能自行根據顯示文字推測。

第四層：規則是否有機會命中

開啟連線日誌或用戶端的連線詳細資訊，觀察目標主機、規則類型、規則內容與最終策略。若顯示命中 MATCH，通常表示前面的 Geo 規則沒有匹配，或根本沒有執行。若顯示命中另一條 DOMAIN-SUFFIX、IP-CIDR 或 RULE-SET，就應調整規則順序，而不是繼續更換資料庫。

測試 GeoIP 時還要確認目標位址。一個網域可能回傳多個 IPv4 或 IPv6 位址，並因地區、網路與時間而變化。瀏覽器既有連線、DNS 快取與 QUIC 工作階段，也可能讓測試繼續使用舊位址。修改設定後，可重新啟動對應應用程式或清除連線，再進行一次新的存取測試。

第五層：命中後策略是否可用

規則命中只決定將連線交給哪個策略。若策略組目前選取了不可用節點、延遲測試尚未完成，或直連網路本身無法到達目標，最終連線仍會失敗。此時日誌可能明確顯示規則已正確命中。應繼續檢查策略組目前的選取項目、節點狀態、DNS 結果與系統代理接管範圍，不要將故障歸因於 Geo 資料。

用規則命中記錄驗證更新結果

可靠的驗證至少包含設定載入、典型網域、目標 IP 與兜底流量四項。先確認核心啟動日誌沒有 Geo 資料錯誤，再選擇一個明確屬於目標分類的網域，觀察是否命中 GEOSITE；接著選擇一個已知 IP，確認 GEOIP 的分類結果；最後測試不屬於上述分類的連線，確保它落到預期的 MATCH 或其他兜底規則。

如果用戶端支援規則測試或連線詳細資訊，應記錄「目標、命中規則、策略組、實際出口」四個欄位。僅看到網頁能夠開啟，無法證明分流正確，因為直連與代理都可能存取成功。相反地，網頁無法開啟也不一定表示規則錯誤，策略節點、DNS、IPv6 與應用程式快取都可能影響結果。

建議的更新週期

• 一般個人裝置：每週或每月檢查一次即可，出現明顯歸屬變化時再手動更新。
• 經常切換設定的裝置：讓用戶端託管更新，並在每次核心升級後檢查資料載入日誌。
• 長期運作的路由器裝置：設定穩定的自動更新時段，保留上一個可用檔案，並避免更新與裝置重新啟動同時進行。
• 固定規則環境：鎖定經過驗證的資料版本，在計畫維護時統一更新，減少分類變化造成的分流波動。

更新後的最小檢查清單

1. 目前核心支援設定中使用的 Geo 規則類型。
2. 資料檔位於實際執行實例讀取的目錄。
3. 啟動日誌沒有下載、解析、權限或分類名稱錯誤。
4. 執行設定包含預期的 GEOIP 與 GEOSITE 規則。
5. 規則順序中沒有提前接管全部流量的寬泛項目。
6. 連線詳細資訊顯示命中了預期規則與策略。
7. 修改後重新建立連線，避免舊 DNS 與工作階段快取干擾判斷。

GeoIP 與 GeoSite 的維護重點不是追求最高更新頻率，而是確保資料格式、核心能力、設定引用與規則順序保持一致。更新完成後，只要沿著「檔案已下載、核心已載入、規則已引用、連線已命中、策略可執行」的鏈路逐項確認，就能將大多數異常定位到明確層級。