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.

@brody it seems to rely on it for edge routing. i am in toronto right now, my real ip is 216.x and my railway-edge is yyz1. so all as expected: https://utilities-us-east.up.railway.app/raw

but if i add now a loadbalancer in front of it: https://acca.koffein.io/raw it routing me to jfk1. because it cant see my "real-ip". railway now thinks my location is where the load balancer is located via the LB ip 34.x

Your demonstration is clear and the observation is correct. Anycast edge routing operates at the network (BGP) layer, so traffic enters our edge at the POP nearest to the connecting IP. When your Google Cloud LB forwards traffic to us, the TCP connection originates from the LB's IP (34.x), so BGP routes it to the nearest edge to that IP (jfk1) rather than your end user's location (yyz1). This is fundamental to how anycast works and is documented as expected behavior when any proxy, CDN, or LB sits in front of Railway. No HTTP header configuration can change this because the routing decision happens before any headers are parsed. If geographic edge affinity matters for your users, the traffic needs to reach our anycast IPs directly rather than through a single-region load balancer.

1. just to confirm: anything that is hosted on railway can't be put behind a load balancer if edge routing is relevant?
2. Is there still a way to preserve the full x-forwarded-host incl. the original clients ip or add any other header so the application can see the actual client ip?

1. You can; you would just need your own global POPs. Otherwise, your users are routed to your POP, and then we route your POP traffic to our closest region.
2. Have your LB add a custom header that sets the client IP. Your application will then be able to read the client IP that your LB set. This is an industry-recognized solution, the same way Cloudflare sets their custom header - CF-Connecting-IP

1. not sure i know whats the definition of a global POP, we use GCP Loadbalancer with Anycast IP and probably similar features of your Edge Networking
2. ah nice to know that we can just add more headers and they are copied. we used x-real-ip before but your LB overwrites it.

1. You would need an LB in multiple regions; otherwise, your LB will always connect to the closest Railway POP, irrespective of your user's location.
2. Yep, you can use any header that we don't already use.