Follow-up to Assigning an egress IP defaults to a wrong region, which auto-closed in October — I hit the same issue today (July 2026), so it doesn’t appear resolved.
I allocated a dedicated egress IP on a fra machine; the allocation reported fra, but the IPv4 (209.71.106.25, since released) geolocates to the United States (ipinfo.io: Colorado, AS40509). My app calls an external API that restricts by IP geolocation and requires a static-IP allowlist, so the egress IP was unusable and I rolled back to the shared pool — which geolocates to Germany correctly, but isn’t static, so it can’t go on an allowlist.
One gotcha for others: the release only took effect after restarting the machine.
In the closed topic, @PeterCxy mentioned (Sep 2025) that a geofeed server was running and would be exposed to GeoIP databases. Ten months later this range still resolves to the US — did the geofeed ship, and does it cover the dedicated egress ranges? Is a MaxMind correction still pending on their side?
And if the geofeed route is stalled: is there any way to get an egress IP allocated from an EU-registered range (ideally DE, matching fra)? Happy to share the machine ID privately and to release/re-allocate as needed.
For those on mobile who might not want to type in the October (/ late September) thread’s ID manually, that’s:
https://community.fly.io/t/26025
Personally, I think the following newer post from June makes for a better reference:
https://community.fly.io/t/new-egress-ip-alert-from-brevo/28164/4
(The forum unfortunately doesn’t have #geo-ip or #egress-ip tags, so it’s not super-easy to find all these.)
thanks for flagging this! To confirm, we shipped our geofeed and distributed it to several geolocation providers. It does cover our static egress IP ranges and your report helped us realize 209.71.106.0/24 is missing from it. We’re reconciling this on our side.
In the meantime, I’ve submitted a data correction to IPinfo and MaxMind which should be reflected in their databases within the next week.
We do have other /24s in fra and IPinfo has the right location for these. If you haven’t already, try assigning a new static egress IP in the region. As long as your new IP belongs to one of our other ranges, you should be fine to allowlist it.
Confirmed working — thanks for the quick turnaround.
I released and re-allocated, and the new egress IP landed in a different /24 (209.71.90.0/24). That one geolocates to Frankfurt correctly across IPinfo, ip-api and db-ip, and more importantly the API I was blocked on now accepts it on every endpoint I need. So your read was right: it was the single uncovered range, not the dedicated egress ranges in general.
Two notes for anyone else who lands here:
- Allocation takes effect immediately and reroutes all egress from the machine, not just the traffic you care about. If the IP turns out to be geo-blocked, everything outbound breaks at once — unauthenticated requests went down right alongside the authenticated ones. Verify with a real request from inside the machine before putting the IP on any allowlist. A geo-DB lookup isn’t sufficient on its own, since whoever is doing the blocking may use their own data.
- Releasing an egress IP only takes effect after a machine restart. That cost me an hour on the first attempt, wondering why the rollback hadn’t helped.
I also ran fly machine egress-ip promote to move it to app-scoped, so the address survives machine recreation instead of dying with the machine — worth doing before pinning it in a third-party allowlist.
Probably still worth finishing the 209.71.106.0/24 reconciliation on your side, since the next person to draw from that range will hit exactly what I did.