The perils of the “real” client IP is a must-read on this topic. Recently posted on hacker news.

Its summary says:

• When deriving the “real client IP address” from the X-Forwarded-For header, use the rightmost IP in the list.
• The leftmost IP in the XFF header is commonly considered to be “closest to the client” and “most real”, but it’s trivially spoofable. Don’t use it for anything even close to security-related.
• When choosing the rightmost XFF IP, make sure to use the last instance of that header.
• Using special “true client IPs” set by reverse proxies (like X-Real-IP, True-Client-IP, etc.) can be good, but it depends on the a) how the reverse proxy actually sets it, b) whether the reverse proxy sets it if it’s already present/spoofed, and c) how you’ve configured the reverse proxy (sometimes).
• Any header not specifically set by your reverse proxy cannot be trusted. For example, you must not check the X-Real-IP header if you’re not behind Nginx or something else that always sets it, because you’ll be reading a spoofed value.
• A lot of rate limiter implementations are using spoofable IPs and are vulnerable to rate limiter escape and memory exhaustion attacks.

I was thinking of writing a plug to do this but found remote_ip the appears to adhere very closely to the considerations above. Thanks to @ajvondrak !

for me it’s inside the x_headers: [{"x-forwarded-for", "x.y.z.external-ip-here"}]. (in some networks you’ll see multiple IPs comma separated)

It matters if your app has a load balancer in front of it and in which way it’s configured, sometimes you have to explicitly configure it to forward the client’s IP address. So take caution you’re not only seeing internal IPs that belong to your load balancer/forwarder.

Here’s a cross reference to an earlier reply: Phoenix socket/channels security / IP identification - #4 by arjan