FerryDocs
ConceptsNetworking, domains & TLS

The headers that your app gets

The proxy removes the address headers that a client sends and sets its own, thus your app can trust them.

Edit on GitHub
Clientfalse headerProxyedge of the serverYour app

A client sends a request with a false header: X-Forwarded-For: 1.2.3.4.

1 / 4

The is the edge of your server. It removes these of the client: Forwarded, each X-Forwarded-*, X-Real-IP, X-Client-IP and similar headers. Then it sets its own.

The headers that the proxy sets

HeaderValue
HostThe host that the client asked for, with the port.
X-Forwarded-ForThe of the client only (no chain).
X-Real-IPThe IP address of the client.
X-Forwarded-Protohttp or https.
X-Forwarded-HostSame as Host.
X-Forwarded-PortThe port in the URL that the client used, else 80 or 443.
ForwardedThe same facts in RFC 7239 form: for=…;host=…;proto=….
X-Request-IdA random id, unless the request has one.

Try it

Terminal
curl -H 'X-Forwarded-For: 1.2.3.4' http://echo.localhost:8080/

The app does not get the false header:

Headers seen by the app
{
  "host": "echo.localhost:8080",
  "x-forwarded-for": "127.0.0.1",
  "x-forwarded-proto": "http",
  "x-forwarded-host": "echo.localhost:8080",
  "x-forwarded-port": "8080",
  "x-real-ip": "127.0.0.1",
  "forwarded": "for=127.0.0.1;host=\"echo.localhost:8080\";proto=http",
  "x-request-id": "59f1d9afbc7b4c7f9dda561433c3ab9b"
}

The life of a certificate

Ferry requests, renews and tries again each certificate with no action from you.

WebSockets, SSE and HTTP/2

The proxy passes WebSockets and streamed answers. It always uses HTTP/1.1 with your app.

On this page

The headers that the proxy setsTry it