Limits behind another proxy

Ferry does not trust a proxy in front of it, thus your apps see the address of that proxy.

The reverse proxy adds X-Forwarded headers and sends the request to Ferry.

1 / 3

Ferry expects to be the edge of the server. It has no setting to trust a proxy in front of it.

The three limits

Limit	What to do
Ferry drops the `X-Forwarded-*`, `Forwarded` and `X-Real-IP` headers that it receives. Your apps see `X-Forwarded-Proto: http`. They see the address of the reverse proxy as the client IP (`X-Forwarded-For`, `X-Real-IP`).	Some apps make absolute URLs or enforce HTTPS from these headers. Give such an app its public URL in its own configuration, for example in an environment variable.
The URLs that Ferry prints start with `http://`, because its own HTTPS is off.	Make the reverse proxy redirect HTTP to HTTPS.
Automatic HTTPS is not available. Let’s Encrypt must reach Ferry on port 80 of the public address, and the reverse proxy now owns this port.	The reverse proxy must hold the certificates.

Configure the reverse proxy

The reverse proxy sends each app hostname to the Ferry proxy and keeps the Host header.

Back up your data

Ferry makes no backup for you. Three places hold your data, and each has its own method.