Get client IP
Guys, I'm trying to make a log on my system and add the IP of the user who performed the action, but I'm not able to get it, I can only get ips like 192.168.0.2. What can I do to resolve this?
19 Replies
when deployed to railway your app sits behind a proxy, what you are seeing is the proxy ip's, to get the client ip's you would have to use some kind of real ip or trust proxy middleware in your code
https://utilities.up.railway.app/raw
as you can see from this the client IP is available in the
X-Forwarded-For header, you'd just need middleware to trust that header as the actual client IPGot it, thanks for the feedback
no prob 🙂
I believe
X-Envoy-External-Address is also going to give you the real client IP. I assume this comes from the Railway edge gateway / load balancer.
You can pass that through to your app and it will persist through multiple proxies. This may not be an issue for you but it can be treated as a custom header.bro brody knows all these lil kinks and knooks
i swear
he is gpt
x-envoy-external-address will only retain the last client ip address as it goes through the proxy layers, this is likely not wanted for this usecase, x-forwarded-for will retain all the client ip's throughout the proxy layers
Thoughts on what luna mentioned? Perhaps it would accumulate through multiple proxy
envoy layers?
It is a common case where a service wants to perform analytics based on the origin client’s IP address. Per the lengthy discussion on XFF, this can get quite complicated, so Envoy simplifies this by settingx-envoy-external-addressto the trusted client address if the request is from an external client.x-envoy-external-addressis not set or overwritten for internal requests. This header can be safely forwarded between internal services for analytics purposes without having to deal with the complexities of XFF.
the envoy header will only contain the last client ip in the chain, forwarded for will contain all client ip's in the chain split by a comma, the first ip being the original client ip, that's why I'm recommending the forwarded for header as the first ip in the list would be the client's (users) ip who accessed the site
Actually the opposite should be true. Envoy should set that to the true client ip. X forwarded for has multiple issues with going through multiple proxies.
For example I’ve seen school environments completely mess the x forwarded for header.
here's proof 🙂
https://utilities.overr.net/raw
🤔 from the docs that sounds backwards
In general, use_remote_address should be set to true when Envoy is deployed as an edge node (aka a front proxy), whereas it may need to be set to false when Envoy is used as an internal service node in a mesh deployment.This probably isn’t enabled when it should be.
makes sense, but hey I'm just saying how it be 🙂
yeah all good, im just going off the docs 😅
@Brody so interesting thing. checking my applications on railway im not seeing the same result.
the overr.net is going through fastly which railway doesnt do by default right?
right, that's something I setup way back to test for a way around the accidental http 2 throttling
I don't have any railway apps behind a cloudflare proxy, so I wonder if the same thing would happen with the chain of client ips
It “shouldn’t” as the client ip should be the last ip seen before it goes through the proxy layer. 🤔
🤷♂️
Gotta love proxies. 😅
true that