Our edge proxy sets X-Real-IP to the immediate connecting IP, which in your case is your Google Cloud Load Balancer. This is expected behavior when placing another proxy/LB in front of Railway. Since X-Forwarded-For correctly contains the full chain of IPs, you can extract the original client IP from the first entry in that header within your application instead of relying on X-Real-IP.

I am not worried about our application not working accordingly I am more worried that Fastly/Railways infrastructure is routing traffic wrongly because its not by design working behind a LoadBalancer.

You can see a real example of the available headers here - https://utilities-us-east.up.railway.app/raw

i can see them in our application too or did you wanna point out something?

Then it sounds like I can mark this as solved, unless I am not understanding the problem here?

we are wondering if railways routing or any other networking feature is not working correctly since it cant identify the clients actual ip and origin.

Neither Fastly nor our routing depends on the clinet IP.