V2Ray 自定义路由规则写法:domain、ip、geosite 匹配语法与优先级

1. 路由规则：决定请求从哪个出站离开

订阅提供节点连接参数，路由决定哪些请求使用这些节点。VMess、VLESS 等协议属于节点连接方式，不是路由匹配前缀。把节点改成 VLESS，并不会自动改变某个网站的直连或代理选择。

在 V2Ray、Xray 的常见路由结构中，routing.rules 是有序数组。每条规则读取目标域名、目标 IP、端口或入站标签等条件，命中后用 outboundTag 指向已定义的出站。标签只是配置中的名称，proxy、direct 并不是自动存在的内置出口。

• 域名请求：核心拿到 www.example.com 时，可以直接检查域名规则。
• IP 请求：核心只拿到目标地址时，域名规则未必有可匹配的输入；是否能补回域名取决于入站、嗅探和 DNS 配置。
• 出站引用：规则中的 outboundTag 必须与实际 outbounds 中某个 tag 一致，大小写也应保持一致。

2. domain、full、regexp：按匹配范围选前缀

domain 既是规则中的字段名，也可能是字段值里的匹配前缀。下面表格中的字符串都放在 "domain": [...] 数组内。不要把网址的协议头、路径或查询参数写进去，路由域名匹配不是浏览器地址栏匹配。

只让一个主机走代理，用 full:。希望整个站点及其子域名统一处理，用 domain:。普通裸字符串适合明确需要包含匹配的场景，不宜当作精确域名的简写。也不要写成 domain:*.example.com：这里不是通配符语法。

{
  "type": "field",
  "domain": [
    "full:login.example.com",
    "domain:example.net",
    "regexp:^api[0-9]+[.]example[.]com$"
  ],
  "outboundTag": "proxy"
}

上面的三个数组项是“或”关系，满足其中任意一个域名条件即可。正则用 [.] 表示字面量点，避免 JSON 反斜杠转义带来的混淆。如果改用正则的 \.，在 JSON 字符串里必须写成 \\.。开头的 ^ 和结尾的 $ 用来限定完整匹配范围。

3. ip、geoip、geosite：地址集合与域名集合分开写

ip 字段接收 IP 地址、CIDR 网段或 geoip: 集合；domain 字段接收域名匹配项及 geosite: 集合。两种集合不能互换。geoip:cn 表示地址归属集合，不代表所有中文网站；geosite:cn 是域名清单，也不保证这些域名始终解析到同一地区的地址。

{
  "type": "field",
  "ip": [
    "192.168.0.0/16",
    "10.0.0.0/8",
    "geoip:private"
  ],
  "outboundTag": "direct"
}

这个片段演示私网目标直连。前两个网段与 geoip:private 可能重叠，实际配置通常选择明确网段或集合即可。若需要同时按国内域名和国内地址直连，建议拆成两条规则：一条写 domain，另一条写 ip。不要把两个字段塞进一条规则，却期待它们是“或”关系。

• 同一字段内通常是或：一个 ip 数组可以列多个网段，命中其中一个即可。
• 同一规则的不同条件字段通常是且：例如 domain 配合 port，要求域名与目标端口同时满足。
• 集合依赖本地资源：常见配置读取 geosite.dat 与 geoip.dat。标签不存在、资源路径不对或文件缺失，都可能让核心加载失败。
• 集合内容会变化：更新资源后，某个域名或地址的归类可能变化。排查时记录资源更新日期，不要只看客户端版本。

4. 首条命中：例外在前，宽泛规则在后

规则按数组顺序检查，首条命中后就确定路由。更精确的规则不会因为“更具体”自动获得更高优先级。若先写 domain:example.com 直连，再写 full:api.example.com 代理，后者会被前者覆盖。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["full:api.example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

这段配置先保留单个主机的代理例外，再处理整个域名的直连，最后让剩余 TCP、UDP 请求走代理。它只展示 routing，需要已有名为 proxy 和 direct 的出站才能使用。若核心没有任何规则命中，常见行为是使用第一个出站；不要凭标签名称猜默认路径。

1. 列出明确例外。例如登录接口、内部服务，或者必须使用固定出口的域名。
2. 放入集合规则。再加入经确认的 geosite、geoip 分类。
3. 确定兜底行为。核对最后的通用规则或第一出站，避免遗漏请求意外直连。
4. 检查生成顺序。客户端可能同时生成预置规则与自定义规则，界面列表不一定就是最终完整数组。

端口条件同样会改变命中范围。例如在域名规则中加入 "port": "443"，只会处理目标端口为 443 的请求，同域名的 80 端口连接不会命中。若目标是整个站点统一走代理，不要无意加入端口限制。

5. domainStrategy：何时把域名解析为 IP

域名规则写对了，IP 规则仍可能不命中，原因常在解析时机。routing.domainStrategy 控制路由匹配过程中是否把域名解析成地址，不负责承诺 DNS 查询一定通过代理。核心 DNS、出站解析和客户端 DNS 设置还需要分别核对。

另一个常见值是 IPOnDemand：匹配过程中遇到需要 IP 的规则时，可触发目标域名解析。因此，把 IP 规则放得很靠前，可能提前引入 DNS 请求。选择策略时先确定“域名分类优先”还是“地址分类优先”，再调整顺序，不要把策略切换当成万能修复。

• 域名优先：先用 full:、domain:、geosite: 表达需求。
• 地址补充：确需按解析地址判断时，再检查策略是否允许解析，以及 DNS 返回了什么结果。
• 注意兜底：IPIfNonMatch 配合最后一条全匹配规则时，域名请求可能直接命中兜底，不再进行 IP 二次匹配。

6. v2rayN 验证：看生成配置，再看连接日志

先备份当前路由方案，再打开 v2rayN 的路由设置编辑规则。不同桌面界面的入口名称可能不同；应以当前版本可见的“路由设置”及规则编辑界面为准。本文 JSON 展示的是 V2Ray/Xray 核心字段，不应原样粘贴到只接收域名列表的输入框。

这些数字是端口含义，不是测速结果。端口 443 也不等于“所有网页流量”，端口 53 更不涵盖所有加密 DNS。按端口分流时，必须同时考虑实际传输方式，不能仅凭端口推断应用用途。

1. 检查输入格式。JSON 使用英文双引号，不带注释和末尾逗号；核心字段名保持原样。
2. 核对运行核心。确认当前选择的是预期核心，以及客户端最终生成的规则语法。不要把其他配置格式的字段混入。
3. 核对标签与资源。检查 outboundTag 是否存在，集合标签是否可加载；先解决核心启动错误，再测试分流。
4. 重新建立连接。保存并应用路由后，关闭测试应用的旧连接，再发起新请求。已有长连接不会因为列表变化而自动换出口。
5. 对照访问日志。在可用的日志详情中检查目标域名或 IP、目标端口、入站与出站标签。必要时临时提高日志级别，测试结束后恢复。

做域名规则验证时，至少准备三组输入：精确例外 api.example.com、同域其他主机 www.example.com、不属于该域的目标。前两项用于区分 full: 与 domain:，第三项确认兜底。示例域名仅用于展示边界；连接测试请换成自己有权限使用且确实提供服务的域名。

7. 常见问题：从覆盖、地址输入和集合错误查起

稳定的调整顺序是：先用单个精确域名验证出口，再扩大到子域名或集合，最后添加 IP 补充与兜底。每次只改变一类条件，并保留可回退的路由方案。更多基础概念可查看概念速查，需要继续排查 DNS 与分流联动时可查看配置进阶。