V2Ray 路由规则实战:geosite 与 geoip 分流、直连与代理规则写法

路由分流：先确认请求是否进入内核

v2rayN 是桌面图形客户端，v2rayNG 是使用 Xray 内核的 Android 客户端。界面负责管理节点与设置，实际匹配路由规则的是内核。VMess、VLESS 等协议决定代理连接如何建立，并不直接决定某个网站应该直连还是代理。

系统代理只影响遵循该设置的应用；TUN 或 Android 的 VPN 接管方式能覆盖更多流量，但仍受应用排除项、路由设置和系统权限影响。如果浏览器根本没有把连接交给客户端，修改十条 geosite 规则也不会改变访问路径。

• 系统代理场景：先确认浏览器使用了本机代理地址，再观察日志中是否出现目标域名。
• TUN 场景：先检查虚拟网卡是否启动、目标应用是否被排除，再讨论内核分流。
• Android 场景：确认 v2rayNG 已连接，目标应用包含在接管范围内，没有被应用分流设置排除。

geosite 与 geoip：一个匹配域名，一个匹配 IP

geosite.dat 保存按标签组织的域名集合，geoip.dat 保存按标签组织的 IP 网段集合。规则中的 geosite:cn 与 geoip:cn 是集合引用，不是联网查询命令，也不代表客户端会自动下载最新列表。

直接写域名时，full:example.com 仅匹配这个完整域名；domain:example.com 同时覆盖它及其子域名。没有前缀的普通字符串通常按子串匹配，容易把不相关域名也纳入，因此精确例外优先使用 full: 或 domain:。

规则资源缺失时，日志可能出现无法加载 geosite、geoip 或找不到标签的错误。应通过当前客户端提供的资源更新入口更新，并确认运行内核实际读取的资源位置。不要只把文件复制进任意下载目录，也不要把 geosite:某标签 当成所有数据集都支持的固定语法内容。

规则顺序：首条命中生效，默认出口另行确认

常规路由规则按数组顺序从上到下检查，第一条匹配成功的规则决定出站。后面的规则不会再把结果覆盖回去。同一条规则中，多个不同条件字段通常需要同时成立；同一个 domain 数组中的多个域名项则是任选一项命中即可。

1. 明确的站点例外：例如某个站点必须代理，放在广泛的直连集合之前。
2. 局域网与私有地址：让路由器、局域网服务等请求走直连；实际覆盖范围由所用私有地址集合决定。
3. 常见域名集合：例如将 geosite:cn 指向直连。
4. IP 归属规则：例如将 geoip:cn 指向直连，并结合域名策略理解其生效条件。
5. 未命中处理：原生配置没有匹配规则时使用第一个出站；客户端也可能生成额外的兜底规则。

不要把“所有 TCP、UDP 都代理”的兜底规则放在最前面。它会先匹配普通连接，使后面的直连规则没有机会执行。更隐蔽的问题是：使用 IPIfNonMatch 时，一条已经匹配成功的宽泛兜底规则，也会阻止“未命中后解析域名”的流程发生。

domainStrategy：决定路由阶段是否解析域名

这里讨论的是 routing.domainStrategy。它控制路由匹配时如何处理域名，不等同于直连出站内部的同名设置，也不能单独保证 DNS 请求从哪个出口发出。

假设一个域名没有出现在任何域名集合中，但解析得到的地址属于 geoip:cn。在没有其他规则提前命中的前提下，IPIfNonMatch 可以让它在解析后命中直连规则；AsIs 则不会为这个域名主动进行这一步转换。

DNS 返回结果会影响 IP 规则。不同解析器可能返回不同 CDN 地址；IPv4 和 IPv6 的归属也可能不同。出现“同一个网站有时直连、有时代理”时，应一起检查实际目标地址、DNS 配置和命中的规则，而不是直接认定 geosite 失效。

• 应用只提供 IP 时，内核未必知道原始域名，域名规则不一定能匹配。
• 流量嗅探可能帮助获得部分连接的域名，但效果取决于协议、加密方式及当前设置。
• 需要固定某个站点出口时，优先确认内核能看到域名，再添加明确的域名例外。

原生配置示例：域名优先，IP 规则补充

下面仅展示 routing 片段，供阅读生成配置或编辑原生配置时参考。前提是配置已经存在 proxy 与 direct 两个出站，并且第一个出站为 proxy。示例中的 example.com 与 example.org 是文档示例域名，不代表它们实际需要特定出口。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["full:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

这个片段不包含节点凭据、监听入站、DNS 或完整出站定义，不能直接替换整份客户端配置。图形界面的“路由规则导入”也可能使用自己的数据结构，不能因为内容是 JSON 就直接粘贴进去。

• domain:example.com 是高优先级代理例外，即使解析结果落在直连地址集合中，也先按域名规则代理。
• full:example.org 只直连完整域名，不自动覆盖其子域名。
• 域名请求首轮完全未命中时，才由 IPIfNonMatch 尝试解析并重新匹配。
• 没有额外兜底规则时，最终未命中的连接使用第一个出站，因此必须检查出站排列。

v2rayN 与 v2rayNG：在界面中落地规则

不同版本的菜单名称可能带有“设置”或“自定义”等后缀。下面给出常见中文界面的入口与操作顺序；如果名称不同，应按功能定位，不要把桌面端导出的路由文件直接当作 Android 端的通用格式。

v2rayN：先复制方案，再编辑优先级

1. 打开「设置」→「路由设置」，先保留当前可用方案，再复制或新建一个测试方案。
2. 在规则编辑器中选择域名或 IP 条件，填写 domain:example.com、geosite:cn 或 geoip:cn 等条目；出站使用界面实际提供的代理、直连选项。
3. 把明确的域名例外移动到广泛集合之前。若界面有域名策略选项，再检查它对应的路由行为。
4. 保存并在主界面的路由选择区域启用该方案。只保存而没有选中方案，通常不会改变当前连接。
5. 重新建立测试连接，在日志或生成配置查看功能中确认规则顺序、默认出口与实际标签。

v2rayNG：区分内核路由与应用分流

1. 打开侧边菜单「设置」→「路由设置」，查看当前路由模式、域名策略，以及代理、直连、阻止规则入口。
2. 在相应的自定义规则输入区添加域名条目。是否支持完整 geosite 引用、规则排序或 JSON 编辑，以当前版本界面为准。
3. 若目标应用没有进入 VPN 接管范围，先到应用分流相关设置中调整；它与 geosite 域名分流不是同一层设置。
4. 保存后断开并重新连接，再发起新的访问。已经建立的长连接可能继续沿用原来的出口。

如果需要细粒度的逐条排序，而当前版本只提供按类别填写的文本框，应检查它最终生成的规则顺序。界面中分开的“代理域名”和“直连域名”并不能说明冲突时谁先匹配。

验证分流：用日志确认出口，不只看网页能否打开

网页能打开，只能说明连接完成，不能证明它使用了预期出口。建议选三个测试对象：局域网地址、明确写入的域名例外、没有命中集合的普通域名。每次只修改一项，重新发起连接，再记录目标与出站。

上面的 10808 是测试示例，不保证等于当前客户端监听端口。先检查实际监听设置。如果系统已提供 curl，可在桌面终端执行下面的请求，明确让目标域名经 SOCKS 入口交给内核，减少应用提前解析带来的差异。

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

socks5h 与只传递已解析 IP 的测试方式不同，它会把域名交给代理处理。测试的目的不是比较速度，而是让日志中的目标与规则输入一致。日志详细程度不足时，可临时提高日志级别；完成后恢复，分享日志前删去订阅地址、节点凭据与个人访问记录。

常见问题：规则保存后仍然没有按预期分流