Which header should I rely on for real client IP?

ikumasudo

PROOP

2 months ago

I use client IP for access control in my Railway app. Since around February 2026, Railway has been alternating between two routing patterns every 1–2 weeks without notice:

With Fastly:

X-Forwarded-For: ,

X-Real-Ip: ← broken: Fastly's IP, not the client's

Fastly-Client-Ip:

Without Fastly:

X-Forwarded-For:

X-Real-Ip: ← correct

When Fastly is in the path, X-Real-Ip gets overwritten with Fastly's edge IP, breaking my access control.

My questions:

1. Why does this keep switching? Is it intentional?

2. Which header is the officially recommended way to get the real client IP on Railway?

3. Is X-Forwarded-For[0] safe to rely on, or can it be spoofed?

I'd like to build on something Railway guarantees won't change silently.

Solved

2 Replies

sam-a

EMPLOYEE

2 months ago

Good questions. You're right that the behavior is changing, and here's the context:

We're in the process of rolling out CDN infrastructure, which is why the routing path has been shifting. When traffic passes through the CDN layer, X-Real-Ip currently gets set to the CDN edge IP rather than the true client IP. This is a bug on our side that we're tracking to fix.

In the meantime, here's the breakdown:

X-Forwarded-For (first/leftmost IP) is the most reliable option right now. Our proxy controls this header, so it accurately reflects the real client IP regardless of which routing path your traffic takes. It's safe to rely on -- clients can send a spoofed X-Forwarded-For, but the real client IP will always be the leftmost entry since our edge proxy appends to the chain.
X-Real-Ip will be fixed to always reflect the true client IP regardless of routing path. Right now it's broken when the CDN is active.
Fastly-Client-Ip works when the CDN is in the path, but won't be present when it's not, so it's not a stable option to build on.

Recommendation: Use X-Forwarded-For and take the first IP. This will work consistently across both routing paths.

Status changed to Awaiting User Response Railway • 2 months ago

ikumasudo

PROOP

2 months ago

Thank you for the detailed response!

Good to know that X-Forwarded-For[0] is the reliable option for now, and that the X-Real-Ip behavior is a known bug being fixed. I'll switch to X-Forwarded-For in the meantime.

Status changed to Awaiting Railway Response Railway • 2 months ago

Status changed to Solved ikumasudo • 2 months ago

Welcome!