Node groups, egress paths, and relay nodes

This guide separates three decisions that are often mixed together: which device traffic matches a rule, which node or group is selected, and which interface or relay carries that node's outbound traffic.

What you should confirm

• A group contains the nodes you expect.
• A routing rule points to the intended group or single node.
• The node's outbound interface and relay are compatible with the desired path.
• The final public IP is verified from a test device.

Three concepts

1. Assign group names to nodes

Use a stable naming scheme such as hk, us, or studio-a. Keep a node in one logical group unless you have a documented reason to duplicate its role. After renaming, check rules that reference the old name.

2. Enable group scheduling

Open the node-group policy and choose the strategy that matches the workload:

• Health or latency preference for a small pool where the best node should be selected.
• Failover when continuity is more important than distribution.
• Load balancing when several healthy nodes should share traffic.
• Average allocation when an even assignment is preferred.

Set a latency or health threshold only after observing normal measurements. A threshold that is too strict can make a healthy group appear empty.

3. Select a node or group in a rule

Use a node name for a fixed path or Group_<name> for scheduling. Verify the rule with one test device before assigning a large subnet. Use DIRECT, REJECT, or Interface:<ifname> only when the routing behavior is intentional.

4. Choose an outbound interface

Set the node's outbound interface to a WAN, PPPoE, L2TP, or PPTP line that has the required connectivity. Use the system interface list to confirm the exact name. An enabled VPN line can still be offline; check both is_enabled and is_online.

5. Add a relay node or relay group

Choose a relay when the final node must be reached through a specific upstream path. Confirm that the relay itself is healthy and that its outbound interface is correct. Do not use a relay simply to hide an unhealthy final node; diagnose the final node first.

6. Check the actual path

Run a node diagnostic, then query the public IP from the test device. Repeat after changing the group member, interface, or relay. The result should change only when the selected path changes.

Common problems

The group is missing from routing targets

Confirm that at least one node has the exact group name and that the group is not empty after an import. Use the Group_ prefix in the rule target.

The device always uses one node

Inspect the group scheduling policy, health state, and stickiness behavior. A group with one healthy member cannot distribute traffic.

The outbound IP did not change

Check the node's outbound interface, the VPN line's online state, and the test device's matching rule. A browser or application may also cache a connection; repeat with a new connection.

A relay makes the node fail

Test the final node without the relay, then test the relay alone. Confirm that the relay protocol and outbound interface support the final path.