The reverse proxy is a server that sits in front of your cluster and receives client connections in its place, so your main and load balancers never expose their real IPs to the outside. It does not host content: every request it takes goes to one of your real servers.

You install a reverse proxy the same way you install a load balancer — see Add a Load Balancer Server — but you pick Add reverse proxy in the panel. Once at least one proxy is online, this page is where you decide how the cluster uses it.

Requirements

  • The engine on the main server must be 2.3.0 or newer. Older versions don't render the Reverse Proxy section in Settings at all.
  • At least one server with role proxy must be installed and reporting.
  • For the Main only mode, the main server needs a domain configured.
  • For the Full mode, every load balancer that is currently online must be updated to 2.3.0 or newer. If any online LB is still on an older version, the panel disables the Full option in the mode selector and shows the name of the LB that is holding it back.

The three modes

The section lives at Settings → Reverse Proxy. The mode selector auto-saves the moment you change it. Propagation across the fleet takes about a minute.

Off (default)

The reverse proxy is inactive. Playlists, redirects and streaming URLs contain the real IPs of your main and your load balancers, exactly like a setup with no proxy at all. Use this if you installed proxy servers but you don't want to route traffic through them yet.

flowchart LR
    C1((Client)) --> M["Main (real IP)"]
    C2((Client)) --> L1["LB 1 (real IP)"]
    C3((Client)) --> L2["LB 2 (real IP)"]

Main only

The proxy takes over the main server's public address. Your load balancers keep serving streams under their own IPs. This is the right choice when the priority is to keep the main out of direct reach from the outside, and you don't mind the LBs staying visible.

flowchart LR
    C1((Client)) --> P[Proxy]
    P --> M["Main (hidden)"]
    C2((Client)) --> L1["LB 1 (real IP)"]
    C3((Client)) --> L2["LB 2 (real IP)"]

Full

Every client connection — panel, API, playlists, live streams, VOD, widgets — enters through a proxy. The load balancers still do the work of serving the content, but the client never learns their addresses. This is the "hidden cluster" mode.

flowchart LR
    C((Client)) --> P[Proxy]
    P --> M["Main (hidden)"]
    P --> L1["LB 1 (hidden)"]
    P --> L2["LB 2 (hidden)"]

If you have several proxies, each of them can front the full cluster on its own; the extra options below decide how clients are spread across them.

Balancing (Full mode only)

When Full is on, the balance selector chooses how clients are distributed across your proxies.

  • DNS (default) — each client enters through the proxy that its DNS lookup resolves to and stays there for the session. You spread the load by publishing several A records for your domain, or by using the DNS list on the main with one entry per proxy domain. Simple and cache-friendly, but a single client always talks to the same proxy.
  • Load — on every redirect (a channel switch, a new VOD, a new session), the main picks the proxy with the lowest outgoing traffic at that moment, still honoring each proxy's GeoIP rules. This spreads load more evenly across proxies but requires a domain configured on every proxy. Any proxy without a domain automatically falls back to DNS balancing for its share of traffic.
flowchart LR
    subgraph DNS ["DNS balance"]
        direction LR
        A1((Client A)) --> P1[Proxy 1]
        A2((Client B)) --> P2[Proxy 2]
        A3((Client C)) --> P1
    end
    subgraph Load ["Load balance"]
        direction LR
        B1((Client)) --> LP["Proxy with lowest outgoing traffic"]
    end

DNS picks the proxy once, per resolver lookup, and the client stays on it. Load re-picks on every redirect.

Strict origins (Full mode only)

Strict origins is an on/off switch that lives right below Balancing. It's the setting that actually enforces the hidden-cluster promise.

  • With strict off: your main and load balancers keep accepting direct connections on their streaming ports. A client that already knows a real IP — from a leaked playlist, a competitor's scraper, an old bookmark — can still reach them. Full mode hides the IPs from new clients, strict off does not lock the door behind them.
  • With strict on: the real servers refuse connections that don't come through the proxies. Anyone with an old IP is turned away.
flowchart TB
    subgraph OFF ["Strict OFF"]
        direction TB
        S1["Client with leaked IP"] -->|connects| M1[Main]
        PX1[Proxy] --> M1
    end
    subgraph ON ["Strict ON"]
        direction TB
        S2["Client with leaked IP"] -.->|dropped| M2[Main]
        PX2[Proxy] --> M2
    end

What Strict changes for the rest of your stack

Two things stop working when strict is on. Both are consequences of the origin refusing direct connections, not bugs:

  • Domain certificates move to the proxy. Let's Encrypt validates a domain by hitting port 80 of the server that answers for it. With strict on the main no longer accepts that check, so the certificate for your domain has to be issued on the proxy — TLS terminates there and the proxy re-encrypts (or plain-forwards) to the main internally. If you were used to running certbot on the main server, you'll run it on the proxy from now on.
  • Anything pointing at a real IP stops reaching your servers. External monitoring that pings the main's IP, restreamers that were given a raw IP address, third-party dashboards using an old hostname that resolves to the origin — none of them will get through. Repoint them to the proxy address and they'll work again. The Xtream AI panel itself is not affected: it's on the allowlist.

Automatic fail-open

If every proxy stops reporting for a few minutes, the origin lifts the restriction on its own and starts accepting direct connections again. This prevents an outage on the proxy layer from taking your service down: the moment strict can't be enforced safely, it steps out of the way. As soon as a proxy comes back, strict is re-applied automatically.

Working with the UI

  • The Reverse proxy mode selector auto-saves. If your click is rejected — for example, you try to switch to Full while an online LB is still on an older engine — the panel reverts the selector to its previous value and shows the reason on a toast.
  • Balancing and Strict origins only make sense in Full mode:
    • Balancing is shown only when the mode is Full.
    • Strict origins is always visible so you can see the switch and its description, but it stays disabled until the mode is Full. Its status line reads Available in Full mode in that state.
  • Changes propagate to the whole fleet in about a minute.

Troubleshooting

If a mode or option is not doing what you expect, check these in order:

  1. The proxy shows as online in the Servers list. A proxy that isn't reporting is treated as absent.
  2. The main is on 2.3.0 or newer. The Reverse Proxy section doesn't appear at all otherwise.
  3. For Full mode, every online load balancer is on 2.3.0 or newer. The panel names the outdated LB when it blocks the mode change.
  4. For Main only mode, the main server has a domain configured.
  5. After enabling Strict, direct-IP tests will fail on purpose. If a monitoring probe or a restreamer stops working right after you turned Strict on, that's the feature doing its job — repoint the probe or restreamer to the proxy address.