V2Ray 路由规则配置实战:国内直连与国外代理的分流写法

分流的核心：为每类请求选择出站

V2Ray 路由不是另一种代理协议，而是内核处理请求时使用的一组判断条件。应用请求进入本地 SOCKS、HTTP 或透明代理入口后，内核读取目标域名、目标 IP、端口和网络类型，再从 routing.rules 顶部开始逐条匹配。第一条命中的规则决定请求使用哪个 outboundTag，后面的规则不再执行。

常见配置会准备三个出站标签：proxy 连接订阅节点，direct 直接访问目标，block 拒绝连接。路由规则本身不保存节点地址，也不改变 VMess、VLESS 等节点参数；它只把流量送往已经存在的出站。因此，从客户端导出配置后，应先确认实际标签名称，再复制规则。

“国内直连、其他流量代理”通常由三层条件完成：私有地址直连、国内域名与国内 IP 直连、剩余 TCP 和 UDP 请求交给代理。最后一条是兜底规则，必须放在规则列表底部。如果把兜底代理放在最前面，所有请求都会立即命中，后面的国内直连规则等于没有执行。

routing 配置：geosite、geoip 与兜底规则

geosite 是域名分类数据，geoip 是 IP 地址段分类数据。域名请求可以先按 geosite:cn 判断；没有命中域名规则时，domainStrategy 设置为 IPIfNonMatch 会尝试解析目标地址，再交给 IP 规则判断。这种写法兼顾域名访问与直接连接 IP 的程序。

下面的片段只包含 routing 对象，应合并进现有的完整配置，而不是作为独立配置文件启动。广告分类规则依赖 block 出站；如果当前配置没有该出站，可以先删除第一条规则，保留直连和代理分流。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "domainMatcher": "hybrid",
    "rules": [
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "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"
      }
    ]
  }
}

domainMatcher: hybrid 用于域名规则匹配；部分旧内核不识别该字段时，可以删除这一行并使用默认匹配器。分类数据也需要与内核版本配套。如果日志出现数据集不存在，而配置拼写正确，应更新客户端所使用的内核与规则数据，不要把该错误当成节点失效。

在 v2rayN 中落地：从订阅到自定义路由

v2rayN 负责保存订阅、选择活动节点并生成内核配置。通过图形界面维护路由时，客户端会在启动内核前组合节点出站与规则集，比反复修改临时生成的 config.json 更稳定。临时文件可能在切换节点、更新订阅或重启客户端后被重新生成。

1. 确认节点连通。更新订阅并选择一个节点，先使用“测试服务器真连接延迟”确认连接可以建立。路由只能分配流量，不能修复节点地址、端口或认证参数。
2. 打开路由设置。在 v2rayN 7.12.7 中进入「设置」→「路由设置」，新建一个规则集，并把它设为当前使用的路由配置。不同小版本的按钮位置可能调整，但路由入口名称保持一致。
3. 添加精确规则。依次建立广告拦截、私有 IP 直连、国内域名直连、国内 IP 直连规则。填写出站标签时选择客户端现有的 block、direct 或 proxy，不要输入节点备注名。
4. 添加最终代理规则。将网络类型设为 TCP 与 UDP，出站设为 proxy，并把该规则移动到最底部。没有最终兜底时，未命中的请求会按内核默认行为处理，结果不够直观。
5. 保存并重启内核。保存规则后执行一次重启服务，再打开日志窗口确认配置加载成功。只关闭设置窗口而不重启时，正在运行的内核可能仍使用旧配置。

v2rayNG 与 v2flyNG 也提供路由设置，但两者使用的内核线不同。v2rayNG 通常搭配 Xray 内核，v2flyNG 对应 V2Fly 内核。基础的 field、domain、ip、network 与 outboundTag 逻辑一致，但可用的扩展字段可能不同。跨客户端迁移时，应先保留基础规则，再逐项验证内核专属能力。

规则优先级：具体条件放前，宽泛条件放后

路由规则采用自上而下的首次命中机制，不会把多条规则合并后再计算最佳结果。一个域名如果同时属于自定义代理列表和 geosite:cn，最终走向取决于哪条规则排在前面。设计顺序时，可以按“手动例外、特殊类别、私有地址、区域分类、最终兜底”排列。

需要让某个域名始终代理时，应把自定义规则放在 geosite:cn 之前。域名匹配形式也有区别：full: 只匹配完整主机名，domain: 可以匹配该域名及其子域名，regexp: 使用正则表达式。常规分流优先使用 full 或 domain，只有确实需要模式判断时再使用正则。

{
  "type": "field",
  "domain": [
    "full:status.example.net",
    "domain:service.example.net"
  ],
  "outboundTag": "proxy"
}

反过来，如果某个下载站需要始终直连，也应建立单独的 direct 规则并放在最终代理规则之前。不要为了一个例外删除整组 geosite 或 geoip 规则，否则会把局部问题扩大成全局分流变化。

DNS 与域名识别：为什么规则正确仍可能走错

路由能否按域名匹配，取决于内核是否取得原始目标域名。浏览器通过本地 SOCKS5 传递域名时，内核可以直接匹配 geosite；如果上游只交给内核一个已经解析好的 IP，域名规则无法参与，只能依赖 geoip。透明代理场景还可能通过流量探测恢复 HTTP 主机名或 TLS Server Name。

• AsIs：按请求原始形式匹配。目标是域名时检查域名规则，目标只有 IP 时不会主动为路由解析域名。
• IPIfNonMatch：先尝试域名规则；域名规则没有命中时解析 IP，再检查 IP 规则。适合本文的区域分流结构。
• IPOnDemand：遇到需要 IP 判断的规则时可能提前解析。规则很多或 DNS 路径复杂时，应先在测试环境确认行为。
• 流量探测：入口的 sniffing 可从 HTTP 或 TLS 流量中识别目标域名。只应启用配置所需的目标覆盖类型，并观察内核日志是否识别成功。

DNS 查询本身走哪个出口也是独立问题。若系统 DNS 可以正常解析国内域名，而代理节点负责连接其他目标，基础分流通常已经够用。若出现解析污染、内外结果不同或 UDP 查询超时，则需要进一步配置内核 DNS，并明确 DNS 服务器地址、查询域名范围和查询流量的出站。

使用 IPIfNonMatch 不表示所有域名都会先解析。已经命中 geosite:cn 或自定义域名规则的请求可以直接选择出站；只有域名条件没有结果、后面还存在 IP 规则时，才需要解析并继续判断。这也是它比无条件依赖 IP 判断更适合常规配置的原因。

日志排错：从配置加载到规则命中

分流失败应先区分“内核没有启动”和“内核启动但走错出站”。前者通常在启动后的数秒内出现 error 或 failed，常见原因包括 JSON 逗号错误、字段放错层级、出站标签不存在和规则数据文件缺失。后者则需要提高日志级别，观察目标地址和最终出站。

1. 检查 JSON 结构。routing 应与 inbounds、outbounds 处在配置根层级。复制片段时，多余逗号和重复的大括号是高发错误。
2. 核对标签拼写。outboundTag 区分字符内容，必须与 outbounds 数组中的 tag 完全一致。proxy 节点备注不能替代出站标签。
3. 检查规则数据。日志若指出 geosite 或 geoip 条目无法加载，应确认数据文件存在且当前内核支持该分类名称。
4. 临时提高日志级别。把 loglevel 从 warning 调整为 info，重启内核后访问一个国内域名和一个需要代理的域名，再查看连接记录。排查结束后可以恢复 warning，减少日常日志量。
5. 缩小规则集合。先保留 private、cn 与最终 proxy 三组基础规则。基础分流正常后，再逐条恢复广告分类、自定义域名和端口规则。

{
  "log": {
    "loglevel": "info"
  }
}

如果国内域名仍走代理，先检查最终 proxy 规则是否排在 geosite 规则之前，再确认请求是否只携带 IP。若请求只有 IP，检查 geoip:cn 是否加载成功。若某个境外服务走了 direct，检查它是否被自定义直连规则或区域数据误命中，并通过日志确认实际目标域名。

UDP 请求异常时，应确认当前节点协议与传输配置是否允许 UDP，同时检查最终兜底规则的 network 是否包含 udp。只写 tcp 会让网页看起来基本正常，但依赖 UDP 的 DNS、实时通信或部分网络检测出现超时。路由允许 UDP 并不代表节点端必然接受 UDP，两端能力需要同时成立。

验证结果：用一组固定目标完成回归测试

保存规则后不要只测试一个网页。浏览器缓存、连接复用和 DNS 缓存都可能保留旧结果。建议重启内核、关闭已有连接，再用固定测试清单分别覆盖局域网地址、国内域名、直接 IP、境外域名、TCP 与 UDP。每次修改规则后重复同一清单，结果才有可比性。

• 访问路由器管理地址或本地服务，确认 geoip:private 命中 direct，局域网连接未进入代理。
• 选择 5 个常用国内域名，清理连接后逐一访问，确认日志中的出站为 direct。
• 选择 5 个需要代理的域名，确认最终命中 proxy，而不是被宽泛的直连规则提前截获。
• 使用配置中的 SOCKS 端口 10808 与 HTTP 端口 10809 分别发起测试，确认应用没有连接到旧端口。
• 测试一个 UDP 请求，并检查节点端是否支持对应转发；失败时单独记录 UDP 结果，不与 TCP 网页访问混为一类。
• 切换一次订阅节点并重启内核，确认自定义路由仍被选中，规则没有随临时配置刷新而丢失。

一个可维护的基础方案通常只有少量规则：私有地址直连、国内域名直连、国内 IP 直连、明确例外和最终代理。规则越多，分类交叉与顺序冲突越难排查。新增规则前先说明它解决哪个具体目标，并记录应放在现有哪条规则之前。

geosite 与 geoip 数据会随网络资源变化而更新，区域分类不可能永久覆盖每个域名和地址段。遇到少数误分流时，优先添加精确例外并保持在区域规则上方；只有大量目标同时异常时，才需要检查规则数据版本、内核兼容性与 DNS 路径。