Our HTTP edge overwrites X-Real-IP, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host on every request, including copies the caller sends. Incoming values are replaced, not appended or kept, so a client-sent X-Forwarded-For: 203.0.113.7 never reaches your app. Use X-Real-IP for rate limiting. Our public networking specs document it as the client's remote IP. How Forwarded is handled is not documented, so do not rely on it.

With Cloudflare in front, X-Real-IP comes from CF-Connecting-IP only when the connection reaching us is from Cloudflare's published IPv4 ranges and that header is present. It is then the end user's IP. Direct requests to *.up.railway.app also go through our edge, and a forged CF-Connecting-IP from any other source does not become X-Real-IP. We have not confirmed this for Cloudflare over IPv6. CF-Connecting-IP reaches your container unchanged, so do not read it directly.

We do not publish proxy CIDRs or a signed ingress header. Observed 100.x peer addresses are not a stable contract. Express trust proxy builds req.ip from the socket peer and X-Forwarded-For, not X-Real-IP, and the hop count is not fixed.

Requests over *.railway.internal skip the edge and its header sanitization. Any service in the same environment can send its own X-Real-IP, so do not trust forwarded headers on that path. These specs may change.

Thank you. This is very helpful and answers most of the security question.

Before we use this as the basis for a production security boundary, could a Railway staff member please confirm the following points?

1. Is the statement that Railway HTTP ingress overwrites caller-supplied X-Real-IP and X-Forwarded-For a supported/current platform guarantee for both custom domains and generated *.up.railway.app domains?

2. Can we safely treat X-Real-IP, after Railway public HTTP ingress, as caller-unspoofable for application rate limiting?

3. For Cloudflare → Railway traffic over IPv6, does Railway also validate Cloudflare provenance and derive the end-user IP into X-Real-IP, or can X-Real-IP become the Cloudflare edge address?

4. Please confirm that requests over *.railway.internal bypass this sanitization and that applications should therefore not trust X-Real-IP as end-user identity on private-network requests.

5. Is your recommended application design to avoid Express req.ip / trust proxy for this purpose and instead validate and consume the Railway-generated X-Real-IP only on public HTTP-ingress requests?

A staff confirmation of these guarantees would let us close our security review and implement the rate-limiting fix.

Thank you.

1. Yes. Our HTTP edge overwrites caller-supplied X-Real-IP and X-Forwarded-For on every request it handles. That applies the same way to custom domains and to generated *.up.railway.app domains, because both go through the edge. It is current behavior. Our public networking specs say this information can change at any time, so it is not a versioned contractual guarantee.

2. Yes, with one limit. A caller cannot set X-Real-IP by sending a forged copy through the public edge. It is still an IP address and not a persistent identity, so a client can change it by switching networks or using a VPN.

3. We have only confirmed the Cloudflare derivation for connections from Cloudflare's published IPv4 ranges. We cannot confirm what X-Real-IP contains when Cloudflare reaches us over IPv6, so do not assume it holds the end user's address on that path.

4. Confirmed. Requests over *.railway.internal do not pass through the public edge and do not get its header sanitization. Any service in the same environment can send its own X-Real-IP, so it is not end-user identity on private-network requests.

5. Yes. Express req.ip comes from the socket peer and X-Forwarded-For under trust proxy, not from X-Real-IP. The hop count is not fixed and we do not publish proxy CIDRs. For public-ingress requests, use the X-Real-IP value we set. Treat private-network requests separately. Any visitor IP a frontend relays over the private network is your application's own metadata, not something we assert. See the public networking specs.