Having looked into this, the issue appears to be in your application code or configuration rather than the Railway platform itself, which puts it outside what Railway support can resolve directly.

This is exactly the kind of problem the Railway community is good at, so we'd like to open your thread as a community bounty. Railway pays a bounty to the community member who solves it, and threads like this usually get picked up quickly.

Opening it makes this entire thread public, including everything already posted. Nothing becomes public until you decide. Use the buttons below.

• Open to the community - Before you click, take a moment to edit or remove anything you'd rather not share. The thread becomes publicly visible right away.
• Keep it private and close the thread - Nothing becomes public and the thread closes.

Please escalate this to a human networking engineer. We’re asking about Railway’s ingress contract, not application debugging: which client-IP header is guaranteed to be overwritten, how applications should authenticate the proxy when stable CIDRs aren’t published, and whether private-network requests can bypass that boundary. We need this information to configure ASP.NET Core safely.

The community is still the best next step here. The buttons below are still live: open the thread up as a public bounty after editing out anything sensitive, or keep it private and close it.

You can use the X-Real-IP to get the client's IP address. That header is written at the edge, so clients can't spoof it.

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

Thanks—our live tests confirmed that Railway overwrites X-Real-IP at the public edge. Direct private-network requests can preserve a forged value, though, and we observed multiple edge peer addresses. What supported ASP.NET Core configuration should we use to trust Railway’s edge while rejecting headers from private callers?

There isn't a stable CIDR range for trusting Railway's proxies.

Thanks for confirming. Without stable proxy CIDRs, what supported mechanism distinguishes Railway edge requests from direct private-network requests carrying a forged X-Real-IP? Is there a supported way to restrict ingress to the edge?

Outside users can’t make requests over the private network. Private networking is only available to services within the environment.

Under that trust model, is Railway’s supported recommendation to accept X-Real-IP from any immediate peer, trusting all services within the environment, provided no TCP proxy exposes the API?