Our HTTP edge overwrites X-Real-IP, X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Host on every request it forwards. Copies supplied by the caller are replaced, not appended to or kept. This applies to Railway-generated .up.railway.app domains and custom domains. For a client IP the caller can't pick through the edge, use X-Real-IP. X-Forwarded-For is rewritten too, but we don't guarantee how many entries it has or a fixed hop topology, so don't depend on the position of a value or a one-hop limit. Don't treat the RFC Forwarded header as something the edge sets or cleans.

We don't publish a range for the socket peer your container sees. The 100.64.0.0/10 addresses you observed aren't stable or limited to the edge, and they can change, so they aren't suitable for KnownProxies or KnownNetworks. There's no signed header or edge-only identity your app could check either.

Requests over private networking (*.railway.internal) skip the edge and its header cleanup. Any service in the same project environment can reach your listening port and send its own forwarding headers, including X-Real-IP. Traffic through a TCP proxy also skips HTTP header handling. If you put Cloudflare in front, we set X-Real-IP from CF-Connecting-IP only when the connection comes from Cloudflare's published IPv4 ranges.

In short, X-Real-IP is trustworthy only on the public edge path, and only if nothing else in that environment can reach the listener. The public networking specs list the header meanings and note they can change.

Thank you. This explains the remaining blocker: private-network callers can reach the same listener and supply X-Real-IP, while the application has no stable ingress peer allowlist or authenticated edge identity.

Could a Railway team member confirm these limitations and identify a supported way to restrict the application listener to public HTTP edge traffic, while preserving Railway health checks?

If no such mechanism exists, please confirm that header configuration alone cannot establish a spoof-resistant client-IP trust boundary when private callers can reach the listener. We need this distinction before enabling forwarding.

We can confirm these limitations. There's no supported setting that limits your listener to traffic from our public HTTP edge. The container gets no authenticated edge identity, such as a signed header or mTLS. The socket peer addresses it sees aren't a published or stable range. Edge Rules only filter requests arriving on your public domains, so they don't control private-network callers.

So header configuration alone can't create a spoof-resistant client-IP trust boundary while other services can reach the listener over private networking. A private caller can send its own X-Real-IP, and nothing in the request shows whether it passed through the edge.

Private networks are isolated between projects and environments. The effective trust boundary is therefore every service in that project environment, plus any TCP proxy you expose. Trusting X-Real-IP is sound only when every path to the listener is trusted.

Thank you. This clarifies the platform limitation. We will keep application forwarding disabled until we explicitly establish and verify trust across every path to the listener. Please provide an authoritative documentation reference or Railway team confirmation so we can cite this limitation in our security decision record.

We confirm the limitations in our earlier replies. There is no supported way to restrict a listener to traffic from our public HTTP edge. The container gets no authenticated edge identity, and the socket peer addresses it sees are not a published or stable range. Requests over private networking do not pass through the edge or its header overwriting, so any service in the same project environment can reach the listener and send its own X-Real-IP. Header configuration alone therefore cannot create a spoof-resistant client-IP trust boundary while other callers can reach the listener.

For your record, the public networking technical specifications list the edge-set headers and their meanings, and note that this information can change. The private networking architecture page describes how services within an environment share one private network that is isolated from other projects and environments. You can cite this thread as our written confirmation of the listener-restriction and socket-peer limitations.