Feature/loopback proxy rematch rules

[Medium1992]

Summary

This PR introduces a new outbound type: loopback.

The design is conceptually similar to Xray's outbound loopback routing, allowing a connection to re-enter the routing engine instead of immediately establishing an outbound connection.

The implementation was developed with the help of Codex based on the routing behavior described in the issue and refined through local testing.

The primary goal is to reduce proxy group complexity while preserving routing flexibility.

Without loopback, users often need large proxy groups containing many routing-specific choices. With loopback, a user can expose only a small number of high-level selections while still applying arbitrary routing logic afterwards. This makes it possible to build a single convenient proxy group with minimal UI buttons while retaining full rule-based routing capabilities.

loopback is a virtual outbound that does not establish a network connection. Instead, when selected, it sends the connection back for another rule matching pass.

During rematching, it can optionally:

• override IN-NAME;
• use a specific sub-rule set.

As a result, selecting an item inside a proxy group no longer has to determine the final outbound. It can instead switch routing context and let rules decide the final path.

Motivation

Currently, when traffic is routed to a proxy group and the user selects an item inside that group, the selected proxy becomes the final outbound.

This limits the ability to create compact user-facing proxy groups while keeping sophisticated routing policies underneath.

loopback allows a proxy group selection to act as a routing context switch rather than a final outbound, enabling:

• simpler proxy group layouts;
• fewer user-facing selections;
• reusable routing policies;
• additional rule evaluation after proxy selection.

Example

proxy-groups:
  - name: GLOBAL
    type: select
    proxies:
      - LB
      - DIRECT

proxies:
  - name: LB
    type: loopback
    in-name: LB_TEST

rules:
  - IN-NAME,LB_TEST,SPECIAL_GROUP
  - IN-NAME,mixed-in,GLOBAL
  - MATCH,DIRECT

Flow:

1. Traffic enters through mixed-in.
2. Rules route it to GLOBAL.
3. User selects LB.
4. LB rematches the connection with IN-NAME=LB_TEST.
5. Rules are evaluated again and determine the final outbound.

Configuration

in-name

Overrides metadata.InName before rematching.

sub-rule

Uses the specified sub-rule set for the second routing pass.

in-name + sub-rule

Both options can be used together.

Validation

A loopback outbound must define at least one of:

• in-name
• sub-rule

Otherwise it is considered invalid.

If a referenced sub-rule does not exist:

• when in-name is present, the configuration falls back to the main rule set and logs a warning;
• when in-name is absent, the loopback outbound is disabled and logs an error.

Loop Protection

Only one loopback rematch is allowed per connection.

If rematching selects another loopback outbound, the connection is rejected and a warning is logged, preventing infinite routing loops.

Health Check

loopback supports health checks and url-test by applying the same rematching logic before establishing the actual outbound connection.

Connection Chain

The loopback step is appended to the connection chain, allowing UIs to display the complete routing path.