Client IP Address: The IP address the Fly Proxy accepted a connection from. This will be the client making the initial request and as such, will also appear at the start of the X-Forwarded-For addresses.
We’ve found “will also appear at the start of the X-Forwarded-For addresses” to be mostly true, but occasionally the first entry in X-Forwarded-For is a private IP like 192.168.X.X and the address from Fly-Client-IP is the second entry in the list (seemingly for certain VPN users). We’ll be switching to Fly-Client-IP for our use-case, but an update to the docs might help future users avoid the same mistake we did.
Hi, in general one should not trust all entries (or entries at a specific position from the start) in X-Forwarded-For completely; rather, it should be parsed in reverse order until an “untrusted” address is hit (MDN docs). In the context of Fly, the edge IP (the IP that your app domain resolves to) should always show up as the last entry, and should be trusted, but everything before which is not a known proxy to you should be treated as untrusted, discarding all entries that come further before.
I do agree that the docs could use some update to point out this specific gotcha.
Yes, if you aren’t using any other proxy (for example, Cloudflare) in front of Fly, then Fly-Client-IP would be the best header to use to identify the original requester. However, if there is any of these proxies in front, one would have to use X-Forwarded-For and parse the header as prescribed by MDN (because Fly-Client-IP will point to the proxy in this case, as we don’t know which proxies we are supposed to trust not to spoof the source IP when we parse X-Forwarded-For to set Fly-Client-IP).
@PeterCxy i also found a problem with the docs…
could you share your email or some other contact.
i emailed support@fly.io but its unmonitored, also emailed billing@fly.io but no response for a month