Xray 的路由规则不是把“国内直连、国外代理”自动变成网络事实，而是按规则顺序检查连接信息，并将命中的请求交给指定出站。配置分流时，最容易混淆的是域名匹配、IP 匹配和 DNS 查询：它们有关联，却不是同一件事。尤其是 domainStrategy，它决定路由器何时尝试把域名解析成 IP 以便匹配 IP 规则，不负责单独定义 DNS 服务器，也不会替代路由规则本身。
本文拆解 Xray 路由的先后顺序、AsIs、IPIfNonMatch 与 IPOnDemand 的差异，并给出可合并到现有配置中的 JSON 片段。适合已经能启动 Xray、希望控制域名与 IP 分流的用户；读完可以按规则意图选择策略，再用日志和显式代理请求检查命中结果。
路由如何匹配：规则顺序决定优先级
Xray 收到连接后，会根据连接携带的信息依次检查 routing.rules。规则可以按域名、目标 IP、端口、网络类型、来源地址或协议等条件匹配；匹配成功后，通常由 outboundTag 指定要使用的出站。比如目标域名命中某条规则，就可能被交给 proxy；命中 IP 规则时，也可能交给 direct。标签必须与现有 outbounds 中的标签一致。
实际配置应先写范围明确、优先级高的规则，再写较宽泛的规则。若目标同时满足多条规则，前面的匹配可能已经决定出站，后面的规则就不会按预想生效。不要只检查规则有没有写，还要确认规则是否排在会提前匹配的条目之前。
| 匹配条件 | 常见用途 | 检查重点 |
|---|---|---|
domain | 按域名、域名后缀或规则集分流 | 连接进入 Xray 时是否仍带有域名；规则集是否可用 |
ip | 按目标 IP、私有网段或 IP 规则集分流 | 路由是否已取得目标 IP；CIDR 或 geoip 条目是否正确 |
port、network | 按目标端口或 TCP、UDP 等网络类型筛选 | 实际连接属性是否符合条件，且规则顺序没有被提前匹配截断 |
outboundTag | 指定命中后交给哪个出站 | 标签与 outbounds 定义逐字一致 |
域名规则常用 domain:、full: 或内置规则集等写法，具体匹配范围要按规则类型理解。比如 full:example.com 用于精确匹配该域名，而 domain:example.com 可用于匹配该域名及其子域。规则集写法依赖相应数据文件和内核支持；配置能通过 JSON 解析，不代表所引用的数据文件一定存在。
domainStrategy 的三种策略：解析时机不同
domainStrategy 位于 routing 配置中，影响的是路由判断过程中何时尝试将域名解析为 IP。它不表示“走代理 DNS”或“走直连 DNS”，也不等于 DNS 服务器的选择策略。若只有域名规则，通常可以先按域名直接判断；当规则需要目标 IP 时，是否解析、何时解析便会影响命中结果。
| 策略 | 大致行为 | 适合的配置思路 | 需要留意 |
|---|---|---|---|
AsIs | 保留域名进行路由判断，不主动为 IP 规则补做域名解析 | 主要依靠域名规则分流，希望减少路由阶段解析 | 仅有 IP 规则时，不能假定域名目标一定会被解析后命中 |
IPIfNonMatch | 域名规则未匹配时，尝试解析，再继续匹配 IP 规则 | 域名规则优先，同时需要 IP 规则作为补充 | 解析结果受 DNS 配置、解析可达性和目标地址影响 |
IPOnDemand | 路由判断遇到 IP 条件时，才尝试取得目标 IP | 配置中确有 IP 条件，并希望在需要时才解析 | 要结合规则排列和具体连接路径验证，不应只按名称推断效果 |
一般分流配置可以先从 IPIfNonMatch 开始理解：有域名规则时先看域名规则，域名规则没有决定出站时，再看能否通过解析结果匹配 IP 规则。它并不会保证所有域名都能解析成功，也不会把 DNS 查询失败自动改写成直连或代理。若规则只按 IP 判断，或客户端传入的是已经解析好的 IP，行为也可能与“域名先命中”的设想不同。
结论：先决定规则看什么，再选解析策略
若分流依据主要是域名，先把域名规则写清楚；若还要用 IP 段兜底，再选能够在路由阶段取得 IP 的策略。不要用更激进的解析选项掩盖规则顺序或 DNS 配置错误。
DNS 与路由分开设计：避免把两个策略混为一谈
Xray 的 DNS 配置决定解析请求可使用哪些 DNS 服务器及相关查询行为；路由的 domainStrategy 则影响路由判断是否需要域名对应的 IP。两者配合工作，但一个不替代另一个。即使设置了可用的 DNS 服务器，也要确认目标连接经过的客户端和内核确实使用这套解析路径；浏览器的安全 DNS、操作系统缓存或其他网络组件可能让实际查询方式不同。
下面是路由部分的示例片段。它假设现有配置已经定义了 proxy 和 direct 两个出站标签；请把片段合并到原有配置，而不是直接覆盖完整文件。geosite:cn 与 geoip:cn 依赖相应规则数据文件，文件缺失时应先补齐数据或换成自己明确维护的规则。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"domain": ["full:example.com"],
"outboundTag": "proxy"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"ip": ["geoip:cn"],
"outboundTag": "direct"
}
]
}
}这段规则中，精确域名规则放在较宽的规则之前；后续规则再分别处理规则集域名和 IP。若目标没有命中任何规则，实际去向还会受到配置中默认出站顺序等因素影响，因此应明确检查未命中时会使用哪个出站。不要为了“补全”示例而随意添加不存在的标签，也不要把 DNS 服务器地址写进 domainStrategy。
两层配置：先让域名解析可用，再让路由规则可解释
DNS 层
- 确认 Xray 当前使用的 DNS 配置及服务器可达性。
- 按需要设置查询策略，不将其当作出站分流规则。
- 检查缓存或客户端自带解析是否影响测试结果。
路由层
- 先列出需要按域名判断的目标。
- 再补充需要按 IP 判断的范围。
- 确认规则顺序与出站标签都能对应现有配置。
DNS 决定解析路径，路由决定连接去向；逐层验证，比同时更换 DNS 和规则更容易定位问题。
动手验证：从配置检查到请求命中
修改前先备份正在使用的配置，并确认 Xray 实际读取的是哪一个文件。客户端管理的节点列表、订阅内容和内核运行配置可能不是同一份 JSON；直接改错文件，即使配置语法正确，运行中的路由也不会改变。以下步骤适用于能够查看或管理 Xray 配置的桌面环境，界面入口因客户端版本而异。
- 核对规则标签。在配置的
outbounds中查找规则引用的标签，例如proxy、direct。大小写和拼写必须一致；同时确认默认出站的预期行为。 - 检查规则顺序。把精确域名规则放到宽泛规则前，再查看是否有更早的端口、协议或域名规则会先命中。一次只改一类规则，便于比较修改前后的日志。
- 检查数据文件。若用了
geosite:或geoip:条目，确认运行环境中存在内核需要的规则数据。启动日志里的加载错误应先处理，不能仅凭配置文本推断规则集有效。 - 验证配置并重启内核。使用客户端提供的配置检查功能，或按当前部署方式运行 Xray 的配置校验命令。确认检查通过后重启内核，并查看启动日志是否提示未知字段、无效规则或数据文件缺失。
- 发起显式代理请求。若本机 SOCKS 入站监听在
127.0.0.1:10808，可在终端执行下面的请求；若实际端口不同，先替换端口。使用socks5h将域名交给代理端处理，更适合检查 Xray 收到域名后的路由行为。 - 结合日志确认出站。临时提高 Xray 日志详细程度并检查请求对应的目标与出站结果。验证完成后恢复常用日志级别，避免长期记录过多连接信息。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com/这条请求只示范测试方式，不保证目标站点在每个网络中都可达，也不代表示例域名应被分到某个特定出站。要验证规则，应挑选自己控制或能够确认预期结果的目标；对比请求日志、出站标签和实际连接结果。若使用普通 socks5 而非 socks5h，客户端可能先在本机解析域名，再把 IP 交给代理，测试重点就不再是 Xray 对域名的解析与路由过程。
常见故障：规则没命中时逐层缩小范围
排查时先回答三个问题：Xray 收到的是域名还是 IP？解析是否发生在预期的位置？最终选择了哪个出站？把这三项分开，可以避免把“DNS 解析失败”“路由未命中”和“出站连接失败”混成一种故障。下列现象尤其容易造成误判。
- 域名规则生效，IP 规则不生效：检查
domainStrategy是否允许路由阶段取得 IP，并确认 DNS 解析结果能被后续规则使用。若目标请求到达 Xray 时已经是 IP，域名规则自然无法按原设想匹配。 - 部分域名被送到错误出站：检查更靠前的宽泛规则、域名规则集覆盖范围和规则排列。特别是同时存在明确域名规则与大范围 IP 规则时，不要假设它们会按“最具体者优先”自动排序。
- 配置启动正常，但规则集没有作用：检查启动日志是否加载了 geosite 或 geoip 数据，核对文件路径及规则条目。JSON 语法通过只说明文本结构可解析，不等于外部数据已经加载。
- 路由看似正确，网页仍无法访问：先确认命中的出站是否能连接目标，再检查 DNS、证书、节点参数和目标服务状态。路由只负责选择处理路径，不保证所选路径一定可用。
设了 IPIfNonMatch，为什么 IP 规则还是不命中？
检查域名是否先命中了前面的规则、解析是否成功，以及 IP 条目和规则数据是否有效。逐项查看启动与请求日志，不要只通过网页是否打开来判断路由命中。
换了 DNS 服务器，出站就会跟着改变吗？
不一定。DNS 改变的是解析结果或查询路径；出站仍由路由规则决定。分别确认解析得到的地址和请求最终对应的出站标签。
能打开网站，怎么确认走的是哪条规则？
通过显式代理发起新请求，并结合 Xray 日志查看目标和出站。浏览器缓存、长连接或自身 DNS 设置可能使单次打开结果不足以说明路由命中情况。
维护复杂分流时，建议给每条规则写清目标范围、出站标签和验证方法，并保留一份可回滚的配置。新增规则后先做语法检查，再用少量已知目标验证；确认有效后再扩大规则范围。若需要调整默认出站，也应单独验证未命中规则的连接，避免把未知流量误送到预期之外的路径。