V2Ray GeoIP 与 GeoSite 规则库更新方法及分流规则写法

GeoIP 与 GeoSite：匹配对象不同

geosite.dat 保存按标签组织的域名集合，geoip.dat 保存按标签组织的 IP 地址段集合。它们是路由匹配的依据，不是节点订阅，也不负责建立 VMess 或 VLESS 连接。更新规则库不会增加服务器，更不会改变订阅里的认证信息。

geosite:cn 通常用于匹配数据源收录的中国相关域名；geoip:cn 则匹配相应的 IP 网段。二者不是互相替代的写法：一个域名可能使用跨地区 CDN，同一 IP 也可能承载多个域名。域名规则与 IP 规则需要分别设置。

规则库只是第三个环节的数据。若应用没有接入系统代理或 TUN，即使文件更新成功，该应用的连接也不会自动进入路由流程。若连接只有 IP、没有域名，GeoSite 规则也无法直接识别网站名称；嗅探能否补足域名，还取决于流量协议与客户端设置。

更新前：确认内核、来源与备份

v2rayN 是客户端，V2Ray/Xray 是负责处理连接的内核。本文讨论的是这些内核使用的 DAT 规则库。切换到使用其他规则格式的配置时，不能把文件名相似当作兼容依据。先查看当前配置使用的内核和启动日志，再确定要更新的文件。

1. 记录现状。记下 v2rayN 版本、当前路由预设、域名解析策略，以及内核日志显示的资源路径；不要只记录软件快捷方式所在位置。
2. 备份路由。在「设置」→「路由设置」中记录启用的规则与顺序，尤其是自定义直连、拦截和代理规则。
3. 备份数据。找到实际加载的 geoip.dat 与 geosite.dat，复制到独立备份目录。不要把备份继续命名为正在使用的文件。
4. 核对来源。优先沿用客户端配置的规则库来源。更换来源前，检查其文档是否包含现有规则引用的全部标签。

更新订阅、更新客户端、更新内核和更新规则库是四件不同的事。订阅更新主要刷新节点信息；客户端升级可能附带资源，但不能据此认定当前规则库已经更新。定位问题时一次只改一类内容，避免无法判断是节点、规则还是数据源发生了变化。

规则库更新：客户端入口与手动替换

优先使用 v2rayN 的内置更新入口。常见桌面界面在「检查更新」中提供「更新 Geo 文件」；菜单文字会随版本和界面类型调整。如果当前版本没有这一项，先查看版本对应说明，不要把「更新订阅」当作同一个操作。

1. 确认当前网络能够访问已配置的资源下载地址；若更新选项提供通过代理下载，先保证当前节点可用，再选择相应方式。
2. 执行 Geo 文件更新，查看日志中的下载结果。一次操作涉及多个文件时，应分别确认成功状态，而不是只看最后一条提示。
3. 更新完成后重启内核；不确定如何单独重启时，正常退出并重新打开 v2rayN。仅关闭到托盘不等于重启。
4. 重新连接并查看启动日志，确认没有文件读取失败、标签缺失或路由初始化错误，再验证分流结果。

手动替换时，先找实际资源目录

手动更新适合内置下载失败或需要固定数据源的情况。停止内核后，从可信的规则数据发布来源取得 DAT 文件，将其放入内核实际读取的资源目录，并保持文件名为 geoip.dat、geosite.dat。压缩包需要先解压；网页内容即使被保存为 DAT 扩展名，也不能作为规则库使用。

• 不要猜固定路径：便携版、安装版以及不同平台的数据目录可能不同，同一机器还可能保留多个客户端副本。
• 独立运行内核时检查环境：Xray 可通过 XRAY_LOCATION_ASSET 指定资源目录，V2Ray 可通过 V2RAY_LOCATION_ASSET 指定。由客户端启动时，应以其启动环境为准。
• 保留回退条件：如果两个文件都更新了，出现异常时先恢复同一批备份，再重启内核，避免混合不同来源造成判断困难。

文件修改时间只能作为辅助线索，不能证明新数据已被加载。若更新后行为完全不变，先检查是否替换了另一个副本，再检查内核是否确实重启。不要连续下载多个来源覆盖同一目录，这会丢失排查依据。

v2rayN 路由设置：字段与顺序

进入「设置」→「路由设置」，选中准备使用的路由配置，再编辑或添加规则。常见规则编辑界面包含「域名」「IP」与出站选择；具体布局以当前版本为准。geosite:cn 填在域名项，geoip:cn、geoip:private 填在 IP 项，不能把三行全部粘贴进域名输入框。

V2Ray/Xray 按规则顺序匹配，先命中的规则决定出站。需要优先处理的精确例外应放在宽泛集合之前。例如，某个域名虽然属于直连集合，但你希望它走代理，就把该域名的专用代理规则放到集合直连规则前。表中的 example.com 是保留的文档示例域名，仅用于说明精确匹配语法。

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

同一条规则里同时填写域名和 IP 等不同条件，通常要求这些条件同时满足，不表示“域名或 IP 任一命中”。因此，按域名直连与按 IP 直连应拆成两条规则。另一个常见误区是把 domain:example.com 与 full:example.com 混用：前者包括该域名及其子域名，后者只匹配指定的完整域名。

域名解析策略：GeoIP 何时参与匹配

domainStrategy 控制路由阶段如何处理域名目标，不等同于 DNS 服务器地址设置。请求原本就以 IP 为目标时，可以直接参与 IP 规则匹配；请求携带域名时，是否为 IP 规则额外解析，要看所选策略。

• AsIs：路由不为匹配 IP 规则而主动解析域名。适合主要依靠域名规则分流的配置，但域名请求不会仅因存在 geoip:cn 就自动触发解析。
• IPIfNonMatch：域名未匹配到规则时，再尝试解析并使用 IP 进行匹配。上面的摘录使用此策略，目的是先利用域名集合，再考虑地址归属。
• IPOnDemand：匹配过程中遇到需要 IP 的条件时即可触发解析。解析发生得更早，规则顺序和 DNS 返回结果对行为的影响需要一起检查。

如果在 IPIfNonMatch 配置末尾提前加入一个能匹配全部请求的兜底规则，域名阶段可能已经命中，后续就不会按预期触发“未匹配后解析”。因此，不能只看策略名称判断 GeoIP 一定执行，还要检查完整规则列表。DNS 返回的 CDN 地址变化，也可能让同一域名在不同网络下命中不同 IP 集合。

这些地址段是理解 geoip:private 的具体参照，不是该集合的完整清单。集合可能还包含其他特殊用途地址。局域网服务是否可访问，也受 TUN 路由、系统防火墙和目标设备权限影响，不能把所有失败都归因于 GeoIP。

验证与排错：先看命中，再改规则

验证时分别选择一个预期直连的域名、一个预期代理的目标，以及一个有权访问的局域网服务。让测试应用确实进入客户端代理链路，再结合连接日志观察目标与出站标签。延迟降低或网页打开成功，都不能单独证明规则命中正确。

1. 保存并启用修改后的路由配置，确认没有选回原来的预设。
2. 重建测试连接；浏览器已有的长连接可能继续沿用先前出站，可关闭测试页面后重新打开。
3. 按需临时提高日志级别，查看目标域名、IP 和出站；记录完成后恢复常用级别，避免长期积累详细访问记录。
4. 每次只修改一个变量，例如先改规则顺序，再改解析策略，最后才考虑更换规则数据源。

稳定配置的关键是可追踪：记录数据来源、更新时间、规则顺序与解析策略。规则库保持更新能补充集合内容，但不会修正错误的出站选择，也不会替代 DNS 与系统代理检查。关于客户端基础配置，可继续查看快速上手；需要理解路由与 DNS 名词时，可查阅术语表。