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 的基本匹配职责。