Headers populated by your environment ingress
Behavior across setups
Different fronting setups leave these headers populated differently:
In the first two setups, both headers resolve to the real client and either is safe to use.
In the third setup — when a CDN like Cloudflare, Fastly, or CloudFront sits in front of your service — your
environment ingress sees the CDN edge IP on the connection.
X-Real-IP will reflect that edge IP, not the real
client. The real client IP shows up as the left-most entry in X-Forwarded-For, which the CDN populates before
forwarding the request.
Recommendation
If you are not behind a CDN,X-Real-IP is the simplest and safest header to read.
Examples
Node.js (Express)
Python (FastAPI)
Python (FastAPI)
Go (net/http)
Go (net/http)
Java (Spring Boot)
Java (Spring Boot)
.NET (ASP.NET Core)
.NET (ASP.NET Core)
Erlang / Elixir (Phoenix / Plug)
Erlang / Elixir (Phoenix / Plug)
Spoofing and trust
X-Forwarded-For is a request header — any client can set it. Your environment ingress strips and rewrites it
on the hop it controls, so for traffic arriving directly from the public internet to your service the header
is trustworthy.
When a CDN is in front, the CDN appends the original client IP to X-Forwarded-For before forwarding. The
left-most entry is the real client only if every upstream hop between the client and your ingress is trusted.
If you accept arbitrary X-Forwarded-For values from untrusted upstreams, attackers can spoof the client IP
for rate-limiting, audit logs, or geo-IP checks.
Configuration of environment-specific trusted CDN CIDR ranges is on the roadmap. Once available, you will
be able to list your CDN’s published IP ranges so that
X-Real-IP also resolves to the real client when
traffic arrives from those ranges. Until then, CDN customers should prefer X-Forwarded-For[0] or the
CDN’s own header.