2026-10-28 · 协议选型 · 约 10 分钟

Xray 路由规则优先级与 domainStrategy 深度配置指南

从匹配顺序到 domainStrategy 的域名解析行为，逐步讲清 Xray 路由引擎如何决定流量出口。附可直接修改使用的 JSON 示例，并覆盖 DNS、IP 规则组合与误匹配排障，适合希望精细控制分流逻辑的进阶用户。

本文速览

Xray 路由按规则列表从上到下检查，通常由第一条匹配规则决定出站；domainStrategy 则影响路由阶段何时把域名解析为 IP，以便匹配 IP 规则。本文拆解规则优先级、三种域名策略和 DNS 的职责边界，并给出可合并到现有配置的 JSON 片段、验证步骤与误匹配排查方法。适合已经能启动 Xray、希望精细控制直连与代理分流的用户。

路由规则优先级：从上到下，命中即停

Xray 的路由器会依次检查 routing.rules 中的规则。某条规则的条件全部满足时，请求被分配给该规则的 outboundTag；默认情况下，后面的规则不会再覆盖这个决定。因此，规则列表的顺序不是展示顺序，而是分流逻辑的一部分。把范围很大的规则放在前面，可能会让后面更具体的例外永远没有机会生效。

一条规则可根据 domain、ip、port、network、protocol、inboundTag 等条件进行匹配。同一条规则中同时填写多个条件时，通常需要这些条件同时成立；同一条件字段中的多个值则按该字段支持的匹配方式判断。理解这一点很重要：域名规则与 IP 规则写在同一条规则里，并不等于“域名或 IP 任意命中即可”。

应用请求进入 获取目标信息 按序检查规则 选定出站标签 建立目标连接

例如，规则一把 domain:example.cn 指向 direct，规则二把 geoip:cn 指向 direct，末尾再把其余流量交给 proxy。域名已被第一条规则匹配时，就会直连；即使该域名解析出的 IP 还符合后面的规则，后面的规则也不会重新选择出站。若希望某个特殊域名走代理，应把它放在更宽泛的直连域名规则之前。

结论：宽规则越靠前，越要确认它不会吞掉例外

新增规则前先找到它会命中的目标，再检查它前面是否已有更宽泛的匹配。排查时从日志里的目标地址和出站标签反推第一条命中规则，比不断调整 DNS 更有效。

domainStrategy：决定何时用 IP 参与路由

domainStrategy 配置在 routing 对象中，控制路由器面对域名目标时如何处理 IP 规则。它不会改变域名规则的书写顺序，也不负责把所有应用的 DNS 请求强制改走某个服务器。常用值是 AsIs、IPIfNonMatch 与 IPOnDemand；大小写应按配置示例准确填写。

AsIs

域名处理
保留域名形式进行路由匹配
IP 规则
不因该策略主动解析域名以匹配 IP 规则
适用情况
主要依靠域名规则分流
注意事项
域名未命中时，不能期待仅凭 geoip 规则完成域名目标分流

适合规则明确以域名为主、希望避免路由阶段按需解析的场景。

IPIfNonMatch 与 IPOnDemand

IPIfNonMatch
域名规则未能匹配时，解析目标域名并尝试 IP 规则
IPOnDemand
路由检查到 IP 条件时，按需解析域名以供匹配
适用情况
规则需要结合域名和 IP 分类
注意事项
解析结果和 DNS 可用性会影响 IP 规则判断

两者都可能让 IP 规则参与域名目标的分流，但触发时机不同。

IPIfNonMatch 的关键是先尝试现有规则；域名匹配成功时，不需要为了后续 IP 规则再解析一次。没有规则匹配时，路由器才解析域名并尝试 IP 匹配。IPOnDemand 则侧重在路由检查遇到 IP 条件时按需解析。它可能让 IP 分类更早参与判断，但也意味着路由结果依赖解析是否成功。

选择策略时应看规则结构，而不是简单认定某个值“更精准”。如果分流主要依赖域名列表，AsIs 可以避免把解析结果当作必要条件；若需要用 geoip:cn 等 IP 条件处理域名目标，通常应考虑 IPIfNonMatch 或 IPOnDemand，并配合可用的 DNS 配置和清晰的规则顺序。

JSON 示例：组合域名规则、IP 规则与兜底出口

下面是一个可移入现有配置的 routing 片段，不是完整的可启动配置。示例假设现有 outbounds 已定义 proxy 和 direct 两个标签；如果标签名称不同，必须同步修改规则中的 outboundTag。示例先处理特定域名，再处理私有地址和中国大陆 IP，最后将未命中流量交给代理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:internal.example",
          "full:portal.example.net"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": [
          "geoip:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

示例中的 block 标签也必须在现有出站中定义，否则配置无法按预期工作；如果不需要拦截规则，可删除对应规则。示例把广告域名规则放在末尾兜底之前，表示命中时交给拦截出站。若某个特定域名需要绕过广告分类，应将其例外规则放在分类规则前面。geosite: 与 geoip: 的匹配依赖 Xray 可读取的规则数据文件，分类名称和数据版本应以实际部署为准。

这段配置不是“所有国内域名直连”的完整保证。域名规则和 IP 规则覆盖的对象并不完全相同：有的应用只提供 IP 目标，无法按原始域名匹配；有的域名解析到境外 CDN 地址，也可能不符合 geoip:cn。如果需要让某条连接按域名分流，应先确认 Xray 收到的是域名，而不是已经被应用解析并直连的 IP。

DNS 与路由的边界：解析服务器不等于分流规则

DNS 配置回答“域名如何解析、向谁查询”；路由配置回答“已经进入内核的连接交给哪个出站”。两者会在需要 IP 匹配时发生关联，但不能互相替代。把 DNS 服务器改成某个地址，不会自动创建直连或代理规则；设置 IPIfNonMatch 也不等于所有应用的 DNS 查询都会通过代理服务器发出。

Xray 可以根据配置处理 DNS 请求，也可能从其他 DNS 行为中获得解析结果。实际使用时，应一起核对 dns.servers、路由规则、内核日志和客户端入口方式。若启用了嗅探，应用协议中识别出的域名还可能影响后续路由；但嗅探不应被当作所有连接都能还原域名的保证。应用若直接向外部 DNS 查询，或连接本身只携带 IP，观察到的结果可能与预期不同。

观察现象 先检查 判断重点
域名规则生效，geoip 规则似乎无效 domainStrategy 是否为 AsIs 若希望域名目标进一步按 IP 分类，检查是否需要解析策略
规则更改后仍走旧出口 规则顺序、客户端生成的最终配置、旧连接 域名是否已在前面的规则命中；测试时重建连接
域名目标未命中 IP 分类 DNS 解析结果、可用 DNS、IP 数据文件 结果地址是否属于预期网段，分类数据是否可用
只有一个应用分流异常 应用是否使用系统代理、TUN 或自有 DNS 该连接是否实际进入 Xray，以及内核拿到的是域名还是 IP

不要只凭“网页能打开”推断 DNS 和路由都正确。可先选一个域名规则明确的目标，再选一个需要 IP 分类的目标，分别观察日志中的目标地址、匹配规则和出站标签。若日志没有给出足够信息，先缩减规则到一条域名规则和一条兜底规则，确认基础行为后再逐条加回。

动手配置与验证：每次只改一项

在 v2rayN 中，客户端界面会根据所选内核生成运行配置。自定义路由入口和菜单名称可能随版本调整，常见流程是从主界面打开「设置」→「路由设置」或路由规则管理界面；应以当前版本实际显示为准。若界面提供路由预设，先确认预设是否会覆盖自定义规则，再决定在客户端中修改还是编辑独立配置。

  1. 备份当前配置

    记录 v2rayN 版本、Xray-core 版本、当前路由模式和出站标签，并复制现有配置文件。不要在测试时同时更换节点、升级内核和改 DNS，否则很难定位变化来源。

  2. 确认运行入口

    在「设置」→「参数设置」检查本地代理端口。常见示例是 127.0.0.1:10808，但端口和入口类型必须以当前配置或启动日志为准。确保待测应用确实连接到该入口，或确认 TUN 已接管该流量。

  3. 整理规则顺序

    把特定域名例外放在分类规则之前，确认私有 IP、国内 IP 与兜底规则的先后关系。检查 domainStrategy 的值，并确认每个目标出站标签已定义。

  4. 启动并查看日志

    保存后让客户端重新生成并启动配置。检查 Xray 启动日志是否有 JSON 解析失败、规则数据加载失败或出站标签不存在等报错；出现启动错误时先恢复备份，不要继续叠加修改。

  5. 逐个目标复测

    分别测试一个明确命中的域名、一个预期由 IP 分类处理的域名，以及一个兜底目标。每次关闭旧连接并重新访问，记录目标、预期规则和日志显示的出站标签。

例如，测试记录可以写成：“目标 portal.example.net，预期规则为第一条域名规则，预期出站 direct，日志实际出站 direct”。如果目标解析到 IP 后仍走代理，先确认它是否在域名规则之前被其他规则命中，以及 Xray 实际收到的是域名还是 IP。示例记录用于说明记录方式，不是本站实测结果。

检查监听端口时，避免把本机入口端口与远端节点端口混为一谈。端口 10808 只是常见配置示例；改成其他数值不会改变路由规则本身。遇到“连接被拒绝”先确认对应入口是否监听，再检查应用代理设置；遇到“出站标签不存在”则回到配置中的 outboundTag 和 outbounds.tag 核对拼写。

误匹配排障：从日志定位第一条命中规则

路由结果与预期不同时，先不要立刻交换所有规则。采用固定顺序检查：确认流量已进入 Xray，读取日志中的目标地址和出站标签，再按规则列表从上到下验证条件。域名规则没有命中时，检查目标是否以域名形式到达、域名表达式类型是否正确，以及是否被更早的规则处理；IP 规则没有命中时，再检查解析结果和 IP 分类数据。

报错：outbound not found

原因与解法：outboundTag 指向的标签没有对应出站，或大小写不一致。逐项对照 routing.rules 与 outbounds 中的 tag，修正后重新启动内核。

现象：国内目标仍然走代理

原因与解法：可能是域名在前面的代理规则已命中、解析结果不属于预期 IP 分类，或流量未携带可识别域名。查看目标形式与出站日志，再调整具体规则顺序并逐条复测。

现象：自定义规则保存后没有效果

原因与解法：客户端可能重新生成配置，或当前启用的是另一组路由预设。确认运行中的最终配置包含修改内容，并检查重启后加载的内核日志，而不是只检查编辑器中的文本。

把 domainStrategy 改成 IPIfNonMatch 后，所有域名都会按 IP 分流吗？

不会。它只在域名规则未匹配时尝试解析并匹配 IP 规则；若前面的规则已经命中，后续 IP 规则不会再覆盖结果。检查规则顺序和日志中的目标形式。

规则里有 geoip:cn，为什么某个国内网站还走代理？

先确认域名是否解析到中国大陆 IP、IP 规则是否位于已命中规则之后，以及对应数据文件是否加载。CDN 地址可能不属于预期分类，不能只根据网站运营方所在地推断 IP 归属。

改了 DNS，路由结果却没变化，正常吗？

可能正常。DNS 服务器选择与规则命中是不同配置环节，且域名规则可能在需要 IP 匹配前已经命中。对照日志里的目标地址、解析结果和出站标签，再判断是否需要调整解析策略。

建立一份简短的规则说明也有助于长期维护：每条规则注明匹配对象、预期出站和放置位置；更新规则数据后，重新抽查一个域名目标和一个 IP 分类目标。需要进一步核对配置字段时，可查看 JSON 手册；需要客户端安装入口时，可前往下载。

下载v2rayN