[Feature request] DNS 规则增加 ECS（Client Subnet）相关匹配条件

操作系统

其他

系统版本

全部

安装类型

sing-box 原始命令行程序

如果您使用图形客户端程序，请提供该程序版本。

No response

版本

描述

目前 sing-box 已经支持在 DNS 查询中添加 client_subnet（ECS），并且上游 DNS 服务器可以正常处理 ECS 信息。

但是，当前 DNS rule 无法根据客户端 DNS 请求是否携带 ECS进行匹配。

例如，服务端运行 sing-box DNS 时，可能同时处理两类请求：

1.普通 DNS 请求：

客户端
  ↓
sing-box DNS
  ↓
Google / Cloudflare / AdGuard 竞速

2.带 ECS 的 DNS 请求：

客户端（携带 ECS）
  ↓
sing-box DNS
  ↓
支持 ECS 的 DNS（例如 Google）

目前 DNS rule 无法区分这两类请求。

当前 workaround

目前只能通过其他条件间接区分，例如：

• 不同 inbound
• 不同用户（auth_user）
• 不同端口

例如：

用户 ecs
    ↓
Google DNS

普通用户
    ↓
DNS race

但这需要额外配置，并且用户身份只是一个间接标识，实际上 DNS 请求本身已经包含 ECS 信息。

建议增加

希望 DNS rule 增加 ECS 相关匹配条件，例如：

判断是否存在 ECS：

{
  "has_client_subnet": true,
  "server": "Google"
}

或者支持更细粒度匹配：

{
  "client_subnet": "114.114.114.0/24",
  "server": "Google"
}

可能包括：

• 是否存在 ECS
• ECS subnet
• ECS prefix length

具体字段名称和实现方式可以由作者设计。

使用场景

服务端 DNS Relay 场景非常需要这个能力：

例如：

客户端 A
发送 ECS
        ↓
sing-box DNS
        ↓
Google DNS

而：

客户端 B
没有 ECS
        ↓
sing-box DNS
        ↓
Google / Cloudflare / AdGuard race

可以直接通过 DNS rule 完成分流。

预期收益

增加 ECS matcher 后，可以提升：

• 服务端 DNS Relay 灵活性
• 多用户 DNS 策略管理能力
• ECS/CDN 优化场景支持
• 不同客户端 DNS 策略隔离能力

同时不会影响现有配置，只是增加新的匹配条件。

重现方式

无

日志

支持我们

• 我已经 赞助

完整性要求

• 我保证阅读了文档，了解所有我编写的配置文件项的含义，而不是大量堆砌看似有用的选项或默认值。
• 我保证提供了可以在本地重现该问题的服务器、客户端配置文件与流程，而不是一个脱敏的复杂客户端配置文件。
• 我保证提供了可用于重现我报告的错误的最简配置，而不是依赖远程服务器、TUN、图形界面客户端或者其他闭源软件。
• 我保证提供了完整的配置文件与日志，而不是出于对自身智力的自信而仅提供了部分认为有用的部分。

The issue does not name files or tests. Start by tracing the existing DNS rule matching and client_subnet ECS handling, then determine how presence, subnet, and prefix length should be represented in rules. Done means DNS requests with and without ECS can be routed differently, with the proposed matching behavior covered by appropriate tests and configuration documentation.