The IP addresses on Fly are more for incoming connections at this point, I don’t think believe it’s possible to control which IP address connections go out from.
Let me double check with the team and get back to you, but the default use of IP addresses on Fly is to route requests into your app. Your app might run on any one of the many Fly servers internally, so it’s harder to control that IP address.
From what I gather from answers given in this post by Thomas, UDP packets attempt to take the same route out from which they came in, and only in one exceptional case (where the app-worker loses routing state), are they DSRd (direct server return).
TCP (and http/1 | http/2) connections are statefully proxied e2e, so route-deviation isn’t possible unless the proxies themselves are truly distributed and capable of handling connection migrations (unlikely).
The incoming IPs are load balancer IPs. There’s almost no way to connect out over a load balancer IP (this is true of most clouds). Do you need to connect out from the exact same IPs that receive traffic, or just connect out from IPs that don’t change?
I need to connect out from the exact same IPs that receive traffic, so that a peer that receives my connection on IP A, can connect back to me on IP A. The allowed_public_ports feature would work but unfortunately I need IPv4 support.
I was trying to stand up a Stellar validator across a few regions.
(Stellar is a blockchain, but the validator software is not a miner and receives no incentives from running.)