GeoIP 與 GeoSite 資料庫更新指南：分流規則失效時先檢查這兩個檔案

節點連線正常，但原本應直連的網站突然經過代理，或某個網域沒有套用預期規則，這類問題不一定來自訂閱、VMess、VLESS 或節點本身。只要路由規則引用了 geoip: 或 geosite:，實際匹配結果就取決於本機載入的資料檔案。

先釐清 geoip.dat 與 geosite.dat 的匹配對象

geosite.dat 儲存的是網域分類集合。規則中的 geosite:cn、geosite:category-ads-all 等寫法，並不是向網路查詢即時服務，而是讓核心讀取本機檔案中的分類項目。網域新增、遷移或用途變更後，若本機資料長期未更新，就可能仍被歸入舊分類。

geoip.dat 儲存的是 IP 位址段分類。規則中的 geoip:cn 會將目標 IP 與資料庫內的位址範圍比對。網站使用的解析位址調整、雲端服務重新分配位址段，或新位址段尚未納入舊資料庫時，IP 規則就可能無法匹配。

判斷分流異常是否由資料庫過舊造成

不要看到一次分流錯誤就直接替換檔案。先確認核心確實正常執行，再排除規則順序、DNS 結果與出站標籤錯誤。路由系統通常依規則順序匹配，前面的寬泛規則可能提前攔截流量，讓後面的 geosite:cn 或 geoip:cn 根本沒有執行機會。

10808 與 10809 是 v2rayN 常見的預設值，不是所有安裝環境的固定值。實際連接埠應在「設定」→「參數設定」中確認；測試瀏覽器代理時，連接埠必須與目前的本機入站一致。連接埠填錯會表現為完全無法存取，不屬於 Geo 資料誤判。

1. 檢查節點：切換兩個可用節點分別測試。如果所有節點都能連線，但同一批網域始終走錯出站，路由資料或規則設定就更值得懷疑。
2. 檢查規則順序：逐項核對精確網域、GeoSite、GeoIP 與最終兜底規則。最終兜底規則必須位於分類規則之後。
3. 檢查日誌：在 v2rayN 中開啟執行日誌，重新存取測試網域，觀察命中的 outboundTag。日誌層級過低時，可在「設定」→「參數設定」中暫時調整，然後重新啟動核心。
4. 檢查檔案日期：定位目前核心實際使用的資源目錄，查看 geoip.dat 與 geosite.dat 的修改時間。不要只查看下載目錄中的副本。
5. 建立對照：記錄更新前至少三個測試目標，包括一個明確應直連的網域、一個預期經過代理的網域，以及一個直接使用 IP 的請求。

在 v2rayN 中更新 GeoIP 與 GeoSite

較新的 v2rayN 通常會在頂部選單提供 Geo 檔案更新入口。先連線至能穩定存取更新來源的節點，再開啟「檢查更新」→「Geo files」。部分版本會將此項顯示為 GeoIP/GeoSite 更新，名稱略有不同，但操作對象仍是目前核心目錄中的兩個資料檔案。

更新過程中不要退出用戶端，也不要同時手動覆蓋同名檔案。選單提示完成後，應執行一次「重新啟動服務」，或退出並重新啟動 v2rayN，確保 Xray 或 V2Ray 核心釋放舊檔案並重新載入。只關閉主視窗但讓用戶端繼續在背景執行，可能不會觸發完整重新載入。

如果用戶端內建更新失敗，可以手動替換，但重點不是把檔案放進 v2rayN 根目錄，而是找到目前所選核心的資源目錄。不同 v2rayN 版本、桌面版與 WPF 版的目錄結構可能不同；常見安裝環境中可看到依核心名稱劃分的 bin 子目錄。最穩妥的方法是先從執行日誌確認核心可執行檔路徑，再在相鄰的資源目錄中尋找現有的兩個同名檔案。

Android 端的 v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心。若目前版本的選單提供「更新 Geo 檔案」入口，應在網路可用時執行並重新啟動核心；如果沒有該入口，則應隨用戶端版本更新相應資源。路由測試仍要進入「設定」→「路由設定」確認目前啟用的規則集，不能只看訂閱是否更新。

核對 routing 寫法與 domainStrategy

資料庫已完成更新但結果沒有變化，下一步應檢查設定引用是否正確。GeoSite 項目放在規則的 domain 陣列中，GeoIP 項目放在 ip 陣列中；兩者不能互換。規則還必須指向實際存在的 outboundTag，否則核心會報錯，或無法按預期選擇出站。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn",
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

上面的順序會先檢查網域，再檢查 IP，最後將其餘 TCP 與 UDP 流量送往 proxy。其中 direct 與 proxy 必須與 outbounds 中的 tag 完全一致，包括大小寫。若設定實際使用 direct-out，路由也必須寫成同一個名稱。

• AsIs：優先依請求中的原始網域匹配，不會為了 IP 規則主動解析網域。目標以網域形式出現時，後續 GeoIP 規則可能不會參與。
• IPIfNonMatch：網域規則未命中時解析目標位址，再嘗試套用 IP 規則。適合同時使用 GeoSite 與 GeoIP 的常見分流結構。
• IPOnDemand：遇到需要 IP 的規則時，可能會更早觸發解析。這會改變 DNS 查詢時機，啟用前應確認 DNS 設定符合預期。

如果某個程式直接連線至 IP 位址，GeoSite 無法從該位址反推出原始網域，此時主要依賴 GeoIP。相反地，目標經過遠端 DNS、內建 DNS 或特殊轉送後，核心能看到的資訊也可能改變。因此，同一個網站在瀏覽器與命令列工具中的分流結果不一致，不一定代表資料庫損壞。

使用日誌與對照請求驗證更新結果

驗證不應只看網頁能否開啟，因為直連與代理都可能成功。真正需要確認的是：更新後的目標是否命中預期規則、是否選擇預期出站，以及重新啟動後結果能否穩定重現。每次測試前先清除瀏覽器連線或等待舊連線結束，避免重用連線影響判斷。

1. 記錄目前版本狀態：記下兩個資料檔案的修改時間、目前核心類型與目前的路由設定名稱。
2. 重新啟動核心：在 v2rayN 中執行重新啟動服務；Android 用戶端則停止目前連線後重新啟動。
3. 逐一傳送請求：先測試明確應命中 GeoSite 的網域，再測試可直接輸入的 IP，最後測試兜底代理目標。
4. 讀取日誌：查看目標位址、規則匹配結果與最終出站標籤，不要只看連線是否建立成功。
5. 重複三輪：間隔重新建立連線，確認結果不是 DNS 快取或長連線造成的偶然現象。

建立可回復的更新習慣

GeoIP 與 GeoSite 不需要在每次啟動時更新，但長期不更新會逐漸放大分類偏差。適合的做法是在發現一批可穩定重現的誤判、更新用戶端核心或調整大型路由規則集時檢查一次，而不是每次網路波動後就立即替換檔案。

• 保留上一版 geoip.dat 與 geosite.dat，將備份檔案放在核心不會自動掃描的獨立目錄中。
• 兩個檔案應按同一輪更新處理，記錄替換日期與目前核心類型。
• 保留三個固定測試目標，分別涵蓋網域直連、IP 直連與代理兜底。
• 將規則修改與資料更新分開進行，避免無法判斷是哪個步驟改變了結果。
• 更新失敗時先還原完整備份，再處理網路或目錄權限問題。

當某個網域確實需要立即修正，而資料庫尚未涵蓋時，可以在 GeoSite 規則之前加入精確網域規則。例如使用 full:example.com 匹配單一完整網域，或使用 domain:example.com 匹配該網域及其子網域。精確規則的數量應維持在可控範圍內，並在資料庫之後涵蓋該網域時重新檢視，避免臨時規則永久累積。

完整的排查順序可以固定為：確認節點與本機連接埠、查看規則順序、檢查 Geo 檔案日期、執行更新、重新啟動核心、讀取日誌、重複對照請求。這個順序同樣適用於 Xray 與 v2fly 核心，差別只在資源目錄與用戶端選單位置，不在 GeoIP、GeoSite 的基本匹配職責。