2 months ago
Dear Railway,
We have been using the 'x-real-ip' header to obtain the client IP address. However these IPs have now been replaced by something that is presumably part of your infrastructure, largely but not exclusively centred on the 157.52.x.x range.
I noticed a thread from six days ago that claimed this was resolved but that's not the case for our project.
When can we expect this to return to its originally documented behaviour?
Thank you,
Giles Burdett
11 Replies
2 months ago
Seems accurate to me - https://utilities-us-east.up.railway.app/raw
What do you see as your X-Real-Ip?
Status changed to Awaiting User Response Railway • about 2 months ago
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
See "clientAddress"
2 months ago
That would leave me to believe you are using the rightmost value from the X-Forwarded-For header, instead of either the leftmost value, or the value from X-Real-Ip
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
https://docs.railway.com/networking/public-networking/specs-and-limits#technical-specifications
"X-Real-IP for identifying client's remote IP."
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
Yep, and that is accurate - https://utilities-us-east.up.railway.app/raw
I see my home IP address here under the X-Real-Ip header.
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
Well that's what I'm saying, our code hasn't changed but the values it's getting from that header, has.
Status changed to Awaiting Railway Response Railway • about 2 months ago
Status changed to Awaiting User Response Railway • about 2 months ago
2 months ago
Our logs are showing that most of our customers appear to be from 157.52.x.x and sometimes 140.248.x.x however
- our customers are all over the country
- the hardware of one customer will skip across several IP addresses in these blocks over the course of a few days
It never used to be this way. The IP addresses would be varied and largely stable. Now when I want to isolate the logs of a device, I have to look at several connection IDs (these are generated by our server, you might know them as a ray ID or a correlation ID) to build up a picture of one device's activity because its (alleged) IP now hops around so much.
Status changed to Awaiting Railway Response Railway • about 2 months ago
2 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • about 2 months ago
2 months ago
Thanks for raising this. Based on Railway’s current behavior, this appears to be related to their edge proxy rather than our application.
At the moment, X-Real-IP is returning Railway infrastructure IPs in some cases, while the first IP in X-Forwarded-For appears to be the reliable client IP. Railway community guidance indicates this is a known issue with X-Real-IP, although their public docs still describe the original behavior.
For now, we will switch to X-Forwarded-For[0] as the source of client IP and share request samples, X-Railway-Edge, and traceroute details with Railway support. I have not found a public ETA yet for a full fix.
a month ago
Deployed this and found that x-forwarded-for is the same IP as x-real-ip, both of which remain in the edge proxy address ranges.
Looking forward to Railway engineers responsible for their current implementation providing clarity on this issue.