Hi Railway team,

I'm running a Laravel app on Railway and I'm seeing the X-Forwarded-For header report the IP of what appears to be your edge/CDN layer instead of the real client IP. I'd like help confirming this and, if possible, getting it fixed or pointed to the correct header to use.

Service: helpdesk-api-production-0f64.up.railway.app

What I'm seeing:

Requests coming from completely different clients (different devices, different ISPs, different countries — one from a phone on mobile data, one from a desktop on a separate home network in Cartagena, Colombia) are all logged by my app with the same (or near-same) IP in X-Forwarded-For:

• 152.233.23.193
• 152.233.23.194

Both resolve via WHOIS/ipinfo.io to:

• Org: AS60068 Datacamp Limited
• Location: Miami, FL, US
• Hostname: unn-152-233-23-194.datapacket.com

What the real client IPs should have been:

• 190.242.54.173 (Cartagena, Colombia — confirmed via ipify.org/ifconfig.me/icanhazip.com run directly from that client's machine at the same time)
• A different mobile carrier IP for the phone test (different network entirely)

What I've ruled out on my side:

• No proxy configured in Windows (netsh winhttp show proxy → direct).
• No VPN adapter/process running on the client machine.
• No suspicious browser extension rewriting headers (and the same IP also appeared on an Android phone on mobile data, which shares no browser/extension state with the desktop — ruling out a client-side cause entirely).
• DNS and hosts file on the client machine are clean.

What I've confirmed on the Railway side:

I opened a shell into my running container (railway shell / container terminal) and ran:

curl -s https://ifconfig.me

This returned 152.55.177.11, which resolves to AS400940 "Railway" itself (Santa Clara, CA) — i.e., my container's own egress IP, on Railway's own network. This is a different IP/ASN than the 152.233.23.x (Datacamp Limited, Miami) seen on inbound requests, which tells me the inbound edge/CDN layer that terminates client connections is on different infrastructure than the egress path, and that edge layer appears to be substituting its own IP for the client's in the forwarded headers.

My app-side config (for context):

Laravel's trustProxies is configured to trust all proxies and read X-Forwarded-For (standard recommended approach per your own support thread: https://station.railway.com/questions/which-header-should-i-rely-on-for-real-c-d78a6f96, which says to use the leftmost IP in X-Forwarded-For). I'm already doing exactly that, and still getting the edge IP instead of the client IP.

I also found this related/likely-duplicate report on your Help Station describing the same kind of issue with X-Real-IP showing the CDN edge IP instead of the true client IP: https://station.railway.com/questions/edge-proxy-x-forwarded-for-and-x-real-ip-c5a50049

Questions:

1. Is there a known issue with the edge/CDN layer not correctly chaining/preserving the original client IP in X-Forwarded-For for some regions/routes (e.g., Miami / Datacamp Limited PoP)?
2. Is there a more reliable header I should be using instead (similar to Fastly-Client-IP, if applicable to my deployment)?
3. Is this related to the X-Real-IP bug already being tracked, or is it a separate issue specific to X-Forwarded-For?

Happy to provide further request logs, headers dumps, or timestamps of the affected logins if useful for debugging on your end.

Thanks!