relay is a special group type: traffic passes through every member in order, forming a forwarding chain. The classic motive: a low-latency "transit" node relaying to a clean-IP "landing" node - speed and exit quality at once.

Configuration

proxy-groups:
  - name: "Chain"
    type: relay
    proxies:
      - "Transit-Nearby"   # first hop: close to you
      - "Landing-US"       # last hop: determines the exit IP

rules:
  - DOMAIN-SUFFIX,target-site.com,Chain

Order is path: you → Transit-Nearby → Landing-US → destination. The destination sees the landing node's IP.

Facts to weigh before using it

  • Latency adds up: chain latency ≈ sum of hops. Two hops is the practical ceiling.
  • Fragility multiplies: any dead hop kills the chain; relay groups do no health checking or failover.
  • Every hop must be able to forward: members must be concrete nodes (no url-test groups), and UDP requires UDP support on every hop.
  • Provider nodes labeled "transit/tunnel" already relay internally - you normally do not stack relay on top. Manual relay is mostly for self-hosted node combinations.

Typical scenarios

  1. Protecting a landing box: the self-hosted landing IP is never exposed to your local network - a transit hop fronts it.
  2. Route optimization: when the direct path to the landing node is lossy, a transit node with a premium line is faster overall.
  3. Stable exit for business needs: services requiring one clean fixed IP (verification codes, strict risk control) - rotate the front, keep the landing fixed.

Verifying the chain

With the chain active, an IP-echo site should report the last hop's IP; the Connections page shows Chain in the Chains column. To prove the middle hop is used, watch connections on the transit box (self-hosted case).

Tip: relay is a know-exactly-what-you-want feature. If you just want reliability, a fallback group costs far less than maintaining a chain.