Chute Devs | Rule Engine 2.0: AND, OR, NOT

Rule Engine 2.0: AND, OR, NOT — Routing Grows Up

2026/04/25

Hello everyone.

Chute’s rule engine has always been Surge-compatible — DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, and FINAL. This covers 90% of use cases. But power users kept asking for more: what if I want to route traffic through a proxy only when both the domain matches AND the source IP is from a specific subnet? What if I want to exclude a particular domain from an otherwise broad rule? What if I want different behavior based on the AS number of the destination IP?

Today we are introducing Rule Engine 2.0, which answers all of these questions.

Logical Rules: AND, OR, NOT

The biggest addition is support for boolean logic. You can now combine rules with AND, OR, and NOT operators:

1
2
3

AND,((DOMAIN,example.com),(SRC-IP,192.168.1.0/24)),Proxy
OR,((DOMAIN-SUFFIX,google.com),(DOMAIN-SUFFIX,youtube.com)),Direct
NOT,((DOMAIN-SUFFIX,ads.example.com)),Reject

The AND rule applies only when both conditions match — for instance, routing example.com through a specific proxy only when the request comes from a particular subnet. The OR rule matches when any of its subconditions match, which is useful for grouping related domains. NOT inverts a match, making it easy to carve out exceptions.

Sub-rules can be nested. An AND can contain an OR, which can contain a NOT. The engine handles arbitrary nesting depths, though in practice most configurations rarely go beyond two levels.

IP-ASN Matching

Autonomous System Numbers identify which organization owns a block of IP addresses. With IP-ASN rules, you can route traffic based on the ASN of the destination:

1	IP-ASN,13335,Direct

This routes all traffic to Cloudflare’s network (AS13335) directly. ASN matching is useful for identifying traffic to major CDNs, cloud providers, or specific ISPs — without maintaining long lists of IP ranges.

We integrate with a local ASN database that is periodically updated. The lookup is an O(log n) binary search, so ASN rules add negligible overhead.

SUBNET Rules

SUBNET rules match the current network environment. If you connect your device to different Wi-Fi networks — home, office, café — you can now write rules that change behavior based on which network you are on:

1	SUBNET,192.168.1.0/24,Direct

This means: on the 192.168.1.x network, route everything directly. Combine it with AND to create complex policies:

1	AND,((SUBNET,10.0.0.0/8),(DOMAIN-SUFFIX,internal.corp.com)),Direct

Load-Balance Policy Groups

Policy groups previously supported three strategies: select (manual), url-test (fastest response), and fallback (primary + backup). We now add a fourth: load-balance.

Load-balance distributes connections across multiple proxies using one of three strategies:

Round-robin: cycles through proxies sequentially
Consistent-hash: routes the same source IP to the same proxy, useful for session affinity
Sticky-sessions: keeps a connection tied to its initial proxy until the session ends

Each strategy has configurable parameters — maximum failed attempts before removing a proxy from rotation, expected HTTP status codes for health checks, and retry behavior.

Pre-Matching Rules

Some rules need to run before the main rule chain. PROCESS-PATH, PROCESS-NAME-REGEX, PROTOCOL, and HOSTNAME-TYPE are now classified as pre-matching rules: they are evaluated first, and their results can influence the rest of the matching pipeline. This is especially useful for the new protocol sniffing feature — if the TUN layer detects that a connection is QUIC, a pre-matching PROTOCOL,QUIC rule can block or route it before any domain or IP rules are even consulted.

Performance

The rule engine now uses SQLite-indexed domain-set rules and LRU result caching. For a typical configuration with 20,000 rules, the caching layer reduces the average match time from ~0.5ms to under 0.02ms for repeat connections. The rule engine’s memory footprint has been reduced by roughly 40% through a trie-based domain index and a CIDR binary tree for IP rules.

Rule Engine 2.0 turns Chute’s routing from a flat list into a programmable policy engine. Boolean logic, network environment awareness, load-balancing, and pre-matching rules give you fine-grained control over how traffic flows through your proxy stack.

Thanks.

Chute Devs