Which client-address headers does the Railway edge set, and are caller copies replaced?

Question

Hello Railway team. Our API service serves a custom domain proxied by Cloudflare. In your HTTP logs, srcIp shows the real visitor, while our application's socket peer is always an address in 100.64.0.0/10. We want to identify visitors reliably and would like to confirm:

1. Which of these headers does your edge set or overwrite before the request reaches the container: X-Real-IP, X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, Forwarded, X-Envoy-External-Address?
2. Does it discard caller-supplied copies of X-Real-IP and X-Forwarded-For, or append to them?
3. When the connecting party is a Cloudflare edge, does X-Real-IP carry the Cloudflare address or the visitor from CF-Connecting-IP? What produces srcIp in your HTTP logs in that case?
4. Is CF-Connecting-IP forwarded to the container unchanged?
5. Which addresses can the container's socket peer have? Is 100.64.0.0/10 stable and documented, and can the peer be IPv6 (for example in fd12::/16)?
6. Is this behaviour documented and treated as a stable contract?

Thank you.

0x5b62656e5d · Accepted Answer

1. `X-Real-IP`, `X-Forwarded-For`, `X-Forwarded-Proto`, `X-Forwarded-Host` are all overwritten at Railway's edge.
2. Answered above (yes, it's overwritten at the edge).
3. You can still get the client’s IP from `X-Real-IP` even if you have Cloudflare’s proxy in front of your service.
4. Yes, unless you have a separate proxy that modifies headers.
5. There are no documented ranges for Railway's proxies.
6. What is the "behavior" in question 6? If you mean Railway's proxy CIDR range, then no, `100.64.0.0/10` is not a stable range. It may change at any time.

https://docs.railway.com/networking/public-networking/specs-and-limits#technical-specifications