v2rayN 路由规则实战:geosite 与 geoip 分流场景配置

一、路由前提：流量进入内核，规则才会匹配

v2rayN 负责配置管理，Xray 内核负责处理进入代理入站的连接。浏览器使用系统代理时，相关请求才会交给本地代理端口；某个程序绕过系统代理直接联网，修改 Xray 路由通常不会影响它。桌面 TUN 属于另一种接管方式，是否启用及其权限要求，应按当前平台和客户端功能确认。

本文使用 Xray 的 JSON 字段。v2rayN 可以管理不同内核，但不同内核的规则格式不能直接混用。Android 上的 v2rayNG 使用 Xray，v2flyNG 使用 V2Fly；即使概念相近，界面入口、生成配置和数据文件版本也不应照搬桌面设置。

1. 确认当前内核

   打开「设置」→「参数设置」，检查当前协议对应的内核选择；部分版本将该项标为「Core 类型」。再看启动日志中的内核名称，确认实际运行的是 Xray，而不是只根据节点协议判断。

2. 备份路由方案

   进入「设置」→「路由设置」，先记录当前选中的方案和规则顺序。编辑前备份现有方案；若当前版本提供导出入口，导出后再修改，避免覆盖仍在使用的自定义规则。

3. 检查代理入口

   在「设置」→「参数设置」中核对本地监听端口，再确认浏览器或系统代理使用了同一地址与端口。不要把远端节点端口填成本地代理端口。

4. 应用并看日志

   保存后在主界面的路由选择项切换到目标方案，按当前版本提示应用或重启内核。菜单位置可能随版本调整，以生成配置与启动日志为准。

二、geosite、geoip 与 outboundTag 的职责

geosite 是域名集合，geoip 是 IP 网段集合。它们不是联网查询服务，而是内核读取的数据内容。geosite:cn 表示当前数据文件中的 cn 域名集合，不等同于所有以特定后缀结尾的域名；geoip:cn 则匹配当前数据中的中国大陆 IP 网段。

outboundTag 只负责指向已有出站，不负责创建出站。本文约定 direct 对应直连出站，proxy 对应已配置的代理出站。这些标签不是 Xray 的保留名称；若生成配置使用了其他标签，必须同步替换。把规则写成 proxy，却没有同名出站，不能得到有效的代理路径。

• 同一规则的 domain 数组中，多个域名条件是“任一满足”。
• 同一规则的 ip 数组中，多个 IP 条件也是“任一满足”。
• 同一规则同时设置 domain、ip、port 等不同字段时，需要同时满足所设置的条件，不是任选一个。
• 规则按顺序匹配，前面的规则已命中时，后面的规则不会再替该连接重新选择出站。

三、基础方案：局域网与中国大陆直连，其余代理

常用顺序是“局域网例外 → 自定义例外 → 中国大陆域名 → 中国大陆 IP → 兜底代理”。下面先给出不含自定义例外的基础片段。它是一个包含 routing 的局部对象，不含 inbounds、outbounds 和节点认证参数，不能单独作为完整客户端配置启动。

{
  "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"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

第一条让已知的私有目标地址直连，适合访问路由器、局域网文件服务和内网设备。第二条使用域名数据优先判断。第三条处理直接访问 IP 的连接，以及需要按解析结果判断的域名连接。最后一条显式接管剩余 TCP、UDP 流量，避免依赖完整配置中首个出站的默认行为。

域名为主的日常分流，可以把 geosite:cn 作为主要依据，geoip:cn 补充处理 IP 目标。若内网服务使用企业自定义域名，建议把明确的域名后缀加入直连规则，不要假定私有 IP 规则一定会替所有内网域名触发解析。

四、域名解析策略：AsIs 与 IPOnDemand 怎么选

routing.domainStrategy 决定路由匹配何时需要 IP，不等同于 DNS 模块的服务器列表，也不同于直连出站的同名设置。是否能获得正确地址，还取决于 DNS 配置、网络环境及请求是否保留域名。仅改一个策略字段，不能同时解决解析污染、DNS 请求走向和所有应用的接管问题。

若改用 IPOnDemand 且希望指定域名始终代理，应把这些域名规则移到宽泛 IP 规则之前。否则，域名先解析出一个满足直连条件的地址，就可能提前命中直连规则。规则优先级与 DNS 结果必须放在一起检查。

五、自定义规则：域名例外、端口条件与本地集合

自定义规则先从少量明确域名开始。下面两条分别表达“指定主机代理”和“整个示例域及其子域直连”。示例域名仅用于说明语法，应替换成实际要管理的域名；不要把 URL 的 https://、路径或查询参数写入域名条件。

[
  {
    "type": "field",
    "domain": ["full:api.example.com"],
    "outboundTag": "proxy"
  },
  {
    "type": "field",
    "domain": ["domain:example.com"],
    "outboundTag": "direct"
  }
]

这两条应插在可能覆盖它们的宽泛规则之前，并保留更具体的 api.example.com 在前。若顺序反过来，子域会先命中整域直连，后面的精确代理规则就失去作用。若还涉及内网地址，应明确是安全访问边界优先，还是域名例外优先，不要机械套用同一顺序。

端口条件指目标端口。例如，把 "port": "443" 与域名条件放在同一规则中，含义是“该域名并且目标端口为 443”，不是所有访问该域名的连接。只写端口 53 的代理规则，也不能覆盖使用其他传输方式的全部 DNS 流量，更不能替代 DNS 模块配置。

自定义集合的两种维护方式

• 少量域名：直接维护 domain 数组，每项使用 full: 或 domain: 明确范围。这样不依赖额外集合文件，修改后也容易核对。
• 大量域名：准备符合内核数据格式的集合文件。例如 ext:custom.dat:office 表示从自定义数据文件中读取 office 集合；它不是普通文本文件名加标签，也不是任意远程规则地址。
• 更新数据：检查当前内核使用的资源目录、文件读取权限与实际集合名。现有 geosite 数据中没有的标签，不能通过改写规则名称自动创建。

六、全局代理：保留局域网还是全部交给节点

“全局代理”需要先定义边界。v2rayN 的路由方案控制已经进入内核的流量，不代表所有系统进程都自动被接管。系统代理未覆盖的程序，仍可能自行联网；而 UDP 是否可用，还取决于入站方式、节点协议和服务端能力。

如果只是临时排查某个站点，不必立即删除全部分流规则。先增加一条精确域名代理规则，放在覆盖它的规则之前，验证站点的主域名与接口域名。一个网页可能同时访问登录、静态资源和下载域名，只修改地址栏里的主机名不一定覆盖完整请求链。

修改节点协议也不能代替路由排查。VMess、VLESS 描述的是代理连接方式；outboundTag 决定当前连接交给哪个已配置出站。只要代理节点本身可用，规则匹配问题应先检查条件与顺序，而不是反复更换协议字段。

七、验证顺序：从接管、命中到出口逐层检查

出口地址只能说明某次测试请求的路径，不能证明所有程序都按同一规则运行。验证应固定测试对象，每改一项配置就建立新连接；已有浏览器连接可能继续复用之前的出站，必要时关闭相关页面、结束旧连接或重启测试程序。

1. 验证流量接管

   打开一个目标页面，同时查看客户端日志是否出现对应连接。没有记录时，先检查系统代理、本地监听端口和程序自身代理设置，不要急着调整 geosite。

2. 验证局域网

   使用实际路由器或文件服务的 IP 测试，例如确认存在的 192.168.1.1。该地址只是常见示例，应以本地网络为准，再单独测试对应内网域名。

3. 验证域名例外

   对新增的精确域名建立新请求，检查日志中的目标地址及出站标签。日志格式随内核配置变化；没有显示完整规则编号时，不要仅凭一行连接成功推断命中了哪条规则。

4. 验证兜底路径

   选择一个不在自定义例外中的公网目标，检查是否使用代理出站。临时调整日志级别只用于排查，结束后恢复，分享日志前移除订阅地址和节点认证信息。

常见现象与修正方向

• 域名按预期直连，直接输入 IP 却走代理：检查 IP 是否实际属于目标集合，并核对 geoip 文件是否加载成功。域名分类与服务器地址归属不是同一判断。
• 加了规则仍走旧路径：检查方案是否已选中、内核是否应用配置，以及是否存在更靠前的宽泛规则。随后关闭旧连接再测试。
• 启动提示集合不存在：核对数据文件、集合名称与资源目录。先用一条明确的 full: 规则验证路由链，再处理集合加载问题。
• 日志命中代理但页面仍失败：继续检查节点连通性、DNS 结果和服务端访问限制。匹配成功只证明选中了出站，不证明后续连接已经完成。

稳定的分流方案应能解释每条规则的目的：哪些地址必须直连，哪些域名明确代理，哪些条件依赖解析，最后由谁兜底。先用少量可验证规则建立基线，再扩展数据集合，比一次导入大量重叠规则更容易维护。