Domains and subnets are matched in order.
Full domains, domain suffixes, and IPv4 subnets are supported, and the first matching rule determines the path. A directly connected Gateway with native rule pack support can also use system rule packs.
The business egress has changed. No need to reconfigure the router.
Hand domain and IPv4 rules to the Gateway or Connector, adjust business paths centrally, and devices keep their existing connection settings.
Learn about ingress policiesChoose the path in one place — at the ingress.
Enable direct Gateway mode and bind the terminal profiles that need handling to node policies. Company services use a designated Relay, while all other traffic follows the default action.
Even without a match, you can specify the egress.
The Gateway default action can select a local direct connection, or a valid standard Relay in the same account that is associated with this Gateway.
Endpoint bindings and inbound traffic, each with its own scope.
WireGuard, RouterOS and IPsec configurations require a policy to be selected and bound. Authorized SOCKS5 and AnyTLS inbound traffic on a Gateway automatically uses the published policy; RouterOS handles only traffic sent into the tunnel.
At the egress,
you can still choose the next hop.
Enable split-routing Connector mode to handle existing member ingress. Designated services can connect directly from this machine or be handed off to another standard Connector in the same team; traffic that does not match still connects directly from this machine.
The next hop first establishes a node link, confirms that the tunnels and machine identities at both ends are ready, and only then is enabled and used in rules.
Learn about Connector →After publishing, track node progress.
The executing node needs firmware that supports split routing, a healthy heartbeat, and the corresponding mode enabled. Draft changes do not alter the current path; after publishing, the node downloads and applies the configuration, and the publishing progress shows binding, delivery, and application status.
If the egress point specified by a node rule, or the Relay selected by default by the Gateway, is unavailable, the corresponding access is blocked and does not automatically fall back to a direct connection. After resolving the egress failure or explicitly changing the egress point, continue to check the verification and application results.
Learn about node firmware →Frequently asked questions.
Does saving successfully mean the node has already taken effect?
Saving means the rule has entered a draft or policy version. After publishing, the node still needs to download, apply, and return a receipt; the publishing page distinguishes between waiting for binding, waiting for application, and already in effect. Once you confirm the node has applied the changes, access the service from the device to verify the actual connection.
Can domain rules identify all access and also support IPv6?
Node split routing uses IPv4, and IPv6 access is blocked. Domain rules handle connections that pass through the node's DNS or whose domain the node can identify; DoH, ECH, or caching may prevent domain identification, and such access is handled by IPv4 rules or the default action.
If the terminal is already bound to Cloud Pulse, can it still be bound to a node policy?
Clear the endpoint’s individual Cloud Pulse binding before selecting a node policy. When Gateway rules use Cloud Pulse, each executing Gateway must separately associate and verify the egress; Connector policies select other Connectors through next-hop links.