Reverse

The reverse block sets up reverse-tunnel hops — a Bridge on the destination side waits for control connections from a Portal at the ingress side, then routes user traffic through the established tunnel.

Top-level

Field	Type	Default	Allowed values	Description
bridges	[]BridgeConfig	[]	Bridge	Bridges placed at the destination side of a reverse-proxy tunnel.
portals	[]PortalConfig	[]	Portal	Portals placed at the entry side of a reverse-proxy tunnel.

Source: infra/conf/reverse.go:32-35 · pinned at v26.6.1 (94ffd50)

Bridge

Field	Type	Default	Allowed values	Description
tag	string	(required)	<tag>	Routing tag for this bridge.
domain	string	(required)	<domain>	Shared domain used to match the matching portal at the other end.

Source: infra/conf/reverse.go:8-11 · pinned at v26.6.1 (94ffd50)

Portal

Field	Type	Default	Allowed values	Description
tag	string	(required)	<tag>	Routing tag for this portal.
domain	string	(required)	<domain>	Shared domain used to bind to the matching bridge.

Source: infra/conf/reverse.go:20-23 · pinned at v26.6.1 (94ffd50)

Example sketch

// On the destination-side server (the one that can reach the internal target):
{
  "reverse": {
    "bridges": [{ "tag": "bridge", "domain": "tunnel.example.com" }]
  },
  "outbounds": [
    { "tag": "tunnel", "protocol": "freedom" }
  ]
}

// On the ingress server (the one users connect to):
{
  "reverse": {
    "portals": [{ "tag": "portal", "domain": "tunnel.example.com" }]
  },
  "outbounds": [
    { "tag": "portal-out", "protocol": "vless", "settings": { /* ... */ } }
  ]
}

Notes

• The domain value on a bridge and its matching portal must be byte-for- byte identical. Xray uses it as an internal "rendezvous name" — it is never resolved over DNS.
• Reverse tunnels are pairs of routing tags; the routing rules on each side decide which traffic enters or leaves the tunnel.

Source: infra/conf/reverse.go:8-35 · v26.6.1 (94ffd50)