sing-box路由规则中route-options动作的定位分析

在sing-box项目的路由规则配置中，动作(action)分为最终动作(Final Actions)和非最终动作(Non-final Actions)两类。近期社区对route-options动作的分类提出了疑问，认为其当前被归类为最终动作可能存在不妥之处。

路由动作的基本分类

在sing-box的路由系统中，动作的最终性决定了路由匹配的终止条件：

• 最终动作：如proxy、block等，会明确指定连接的最终去向或处理方式，匹配到这类规则后路由查找即终止
• 非最终动作：如log、set-system-proxy等，执行某些操作但不终止路由查找，系统会继续检查后续规则

route-options动作的特性分析

route-options动作允许用户为当前连接设置特定的路由选项，包括：

• 是否检查域名系统(DNS)查询结果
• 是否启用IPv6
• 是否启用IPv4
• 是否启用IPv6优先
• 是否启用UDP
• 是否启用TCP

这些选项会影响后续的路由决策，但关键点在于：它本身并不指定连接的最终出站(outbound)。这与典型的最终动作(如直接指定出站代理)有本质区别。

技术实现验证

通过分析sing-box的源代码可以发现，在处理route-options动作时：

1. 系统只是修改当前连接的路由选项结构体
2. 不会设置outbound字段
3. 不会触发路由查找的终止逻辑
4. 会继续执行后续的路由规则匹配

这种行为模式完全符合非最终动作的特征。

配置示例对比

典型的最终动作配置示例：

{
  "action": "proxy",
  "outbound": "my-proxy"
}

而route-options的配置示例：

{
  "action": "route-options",
  "ipv6": false,
  "udp": true
}

可以看到后者缺少决定连接去向的关键字段。

对实际路由行为的影响

将route-options误归类为最终动作可能导致用户产生以下误解：

1. 认为设置路由选项后会立即终止路由查找
2. 错误地期待后续规则不会被执行
3. 不理解为什么在route-options后还需要其他规则来指定出站

实际上，route-options更像是为后续路由决策提供上下文环境，而非做出最终路由决定。

最佳实践建议

基于以上分析，建议用户：

1. 将route-options视为路由条件修饰符而非终点
2. 通常在规则链的前段设置路由选项
3. 确保后续有适当的最终动作规则
4. 理解路由选项会影响所有后续规则的行为

这种分类的修正有助于用户更准确地理解sing-box的路由决策流程，编写出更符合预期的规则配置。