Introduction

A Reverse Proxy is best described as a server that transfers data to and from the backend server on behalf of the client. To facilitate this the proxy server maintains a connection to the backend and the connecting client to the filtering server.

Types

TCP Reverse Proxy

For every received connection a connection is made to the backend server. When available data is transferred to the intended recipient.

UDP Reverse Proxy

For every packet received a packet is sent to the backend server. Unique port mappings (remote endpoints) are maintained for session compatibility.

HTTP(s) Reverse Proxy

Every request made is parsed, processed and made through a pool of connections that are kept alive to the backend server. GZIP, SSL and other features can all be performed on the filtering server for maximum flexibility and performance. Layer 7 HTTP filtering is also performed at this stage.

Origin protection and exposure checks

Using a reverse proxy does not, by itself, prove that a backend server cannot be reached directly. The reverse proxy protects traffic sent to the configured public service, while the backend remains a separate system under your control. Review how your backend is exposed whenever you add a service, change a hostname, or move a backend.

This is a verification checklist only. It does not change your firewall, access-control lists, or backend configuration.

  1. Review the public DNS names and hostnames you operate. Confirm that records intended for the protected service point to the protected service, and identify any record that intentionally points directly to a backend.
  2. From an authorised test location, check the behaviour of a known backend address without submitting credentials, changing data, or testing systems you do not control. Record only whether the expected public application is reachable.
  3. Review application-generated links, redirects, emails, response headers, and error pages for backend hostnames or addresses that should not be public.
  4. Review the services listening on the backend and any separate management, monitoring, or development endpoint. Make sure their exposure is intentional and documented by the system owner.
  5. Use the current Backend Communication IP Addresses shown for the service in the Dashboard when you need to identify the X4B connection sources used for that backend. Do not rely on copied addresses from an old configuration or another service; dashboard addresses can change during a backend-address migration.

If a check identifies an unexpected direct route, gather the affected hostname or service, the time of the observation, and non-sensitive evidence for the administrator responsible for the backend. X4B support can help with the X4B service configuration, but does not manage customer backend systems.

Obtaining the connecting clients IP

With HTTP(s) reverse proxies it is possible to obtain the clients Real IP through an additional header. The header name defaults to X-Real-IP and can be changed in the HTTP Options for the port.

This header is an HTTP(S) feature. TCP and UDP reverse proxies do not provide a client-address header; use tunneling backend methods when preserving the client IP for those protocols is required.