多个 rule set 的合并行为异常

Operating system

macOS

System version

macOS 26

Installation type

Original sing-box Command Line

If you are using a graphical client, please provide the version of the client.

No response

Version

sing-box version 1.12.12-87eb1935

Environment: go1.25.1 darwin/arm64
Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_utls,with_acme,with_clash_api,with_tailscale,with_ccm,badlinkname,tfogo_checklinkname0
Revision: 87eb193522f9b1894d3abe1931327921e291ef93
CGO: enabled

Description

问题描述:

我想匹配来自 192.168.1.20 访问 qq.com 的流量，使用了两个 rule set，但当前行为似乎是对 rule set 进行 OR 而不是 AND 操作。

rule set 定义:

"rule_set": [
  {
    "tag": "geosite-qq",
    "rules": [
      {
        "domain_suffix": "qq.com"
      }
    ]
  },
  {
    "tag": "source-ip",
    "rules": [
      {
        "source_ip_cidr": "192.168.1.20/32"
      }
    ]
  }
]

预期行为:
根据文档说明："Additionally, included rule-sets can be considered merged rather than as a single rule sub-item."

我预期这条规则应该在两个条件同时满足时才匹配（源 IP 是 192.168.1.20 且域名是 qq.com）：

{
  "rule_set": ["source-ip", "geosite-qq"],
  "outbound": "设备20"
}

实际行为:
这条规则会匹配任意源 IP（比如 192.168.1.10、192.168.1.20 等）访问 qq.com 的流量。

测试方法:

all_proxy=socks5h://192.168.1.5:1080 curl -v http://www.qq.com

可以正常工作的替代方案:

1. 使用内联规则（仅匹配 192.168.1.20）：

{
  "domain_suffix": "qq.com",
  "source_ip_cidr": "192.168.1.20/32",
  "outbound": "设备20"
}

2. 使用 logical 规则（仅匹配 192.168.1.20）：

{
  "type": "logical",
  "mode": "and",
  "rules": [
    { "rule_set": "source-ip" },
    { "rule_set": "geosite-qq" }
  ],
  "outbound": "设备20"
}

问题:
这是预期的行为吗？还是说同一条规则中的多个 rule set 应该按照文档说明进行 AND 操作？

Reproduction

完整配置:

{
  "log": {
    "level": "trace",
    "timestamp": true
  },
  "dns": {
    "servers": [
      {
        "type": "udp",
        "tag": "dns_direct",
        "server": "223.5.5.5"
      }
    ]
  },
  "inbounds": [
    {
      "type": "mixed",
      "listen": "0.0.0.0",
      "listen_port": 1080
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "直连"
    },
    {
      "type": "direct",
      "tag": "设备20"
    }
  ],
  "route": {
    "rules": [
      {
        "action": "sniff"
      },
      {
        "rule_set": ["source-ip", "geosite-qq"],
        "outbound": "设备20"
      }
    ],
    "rule_set": [
      {
        "tag": "geosite-qq",
        "rules": [
          {
            "domain_suffix": "qq.com"
          }
        ]
      },
      {
        "tag": "source-ip",
        "rules": [
          {
            "source_ip_cidr": "192.168.1.20/32"
          }
        ]
      }
    ],
    "final": "直连"
  }
}

Logs

+0800 2025-11-12 02:19:44 INFO [1674866349 0ms] inbound/mixed[0]: inbound connection from 127.0.0.1:64828
+0800 2025-11-12 02:19:44 INFO [1674866349 0ms] inbound/mixed[0]: inbound connection to www.qq.com:80
+0800 2025-11-12 02:19:44 DEBUG [1674866349 0ms] router: match[0] => sniff
+0800 2025-11-12 02:19:44 DEBUG [1674866349 0ms] router: sniffed protocol: http, domain: www.qq.com
+0800 2025-11-12 02:19:44 DEBUG [1674866349 0ms] router: match[1] rule_set=[source-ip geosite-qq] => route(设备20)
+0800 2025-11-12 02:19:44 INFO [1674866349 0ms] outbound/direct[设备20]: outbound connection to www.qq.com:80

Supporter

• I am a sponsor

Integrity requirements

• I confirm that I have read the documentation, understand the meaning of all the configuration items I wrote, and did not pile up seemingly useful options or default values.
• I confirm that I have provided the server and client configuration files and process that can be reproduced locally, instead of a complicated client configuration file that has been stripped of sensitive data.
• I confirm that I have provided the simplest configuration that can be used to reproduce the error I reported, instead of depending on remote servers, TUN, graphical interface clients, or other closed-source software.
• I confirm that I have provided the complete configuration files and logs, rather than just providing parts I think are useful out of confidence in my own intelligence.

Start by reproducing the behavior with the complete configuration, the two rule sets, and the provided curl command, then compare the documented rule_set semantics with the routing behavior shown in the logs. Done means determining whether multiple rule sets are intended to use OR or AND semantics and documenting or correcting the behavior, with a reproducible test for the reported case.