X-Real-IP and X-Forwarded-For is overwritten by Railway at the edge.

For proxies, it’s 100.0.0.0/8. (https://docs.railway.com/guides/spa-routing-configuration#option-1-caddy-recommended)

Thank you. I found the official Caddy example with trusted_proxies static private_ranges 100.0.0.0/8. To clarify the remaining part of the original question: is 100.0.0.0/8 an authoritative, stable range for the proxies that directly connect to application containers, and are those peers exclusive to Railway ingress (rather than reachable by other customer workloads)? Also, when both headers are overwritten, does X-Forwarded-For contain only the original client's address or a documented proxy chain? This is for validating the immediate TCP peer before trusting the client-IP header; no service-specific details are needed.

I ran an isolated staging test that appears to contradict the claim that X-Real-IP is always overwritten.

The application used one process and disabled automatic proxy-header rewriting. Eleven rapid login requests with a different caller-supplied X-Real-IP on every request all passed the per-client limiter. After allowing the fixed window to clear, the same test without a caller-supplied header correctly returned 429 on request 11.

This indicates that the caller-supplied X-Real-IP affected the application’s limiter identity, while Railway’s normal header provided a stable identity.

Could someone from Railway confirm:

Whether X-Real-IP and X-Forwarded-For are guaranteed to be overwritten at the edge;

Whether the Caddy example’s private_ranges 100.0.0.0/8 is an authoritative and exclusive ingress-proxy trust boundary;

Which header and trust configuration Railway recommends for non-Caddy applications such as FastAPI/Uvicorn???

100.0.0.0/8 is not guaranteed to be stable.