I’m trying to convince my organisation to use fly.io for some of its internal services but have run into challenges with the UDP features (specifically UDP traffic doesn’t seem to be getting to fly instances).
To troubleshoot, I tried running https://github.com/fly-apps/udp-echo- on fly.io. It runs successfully on a recently acquired public fly IPv4 address. Connecting via TCP using nc 137.66.21.20 5000 correctly echoes each entered line. However, using UDP via nc -u 137.66.21.20 5000 does not. I have tried from multiple Linux and Windows clients and have confirmed through tcpdump or Wireshark that the UDP packets aren’t being blocked by any firewall. I have also tried clients from various networks including home, work and mobile phone hotspot.
I have tried in both SYD and ORD regions with no luck getting UDP working. TCP works everywhere.
Am I missing something obvious or do you have any ideas for next steps to troubleshoot?
Thanks @dyc. Yes, I had used that article to find their sample TCP/UDP echo app, which is failing for UDP in the same way my more complex app was.
If by “opt in” you mean that the UDP server needs to bind to the fly-global-services IP, then yes, their sample app opts in, which I’m running on a public dedicated IPv4 address that I purchased because of fly’s requirement to have a non-shared IP for UDP servers.
I would double check to make sure the app actually accepts udp by checking from the machine itself. You can fly ssh console into the machine and apt install netcat to try it there. If that works, try it via a wireguard connection and/or by using fly proxy. That should narrow down where the source of the problem is.
I’m not sure if it’s related, but my service is currently also not working over UDP. From the machine itself (fly ssh console) it works fine (tested fly-global-services address with the port I specified), but externally I cannot connect.
I’m pretty sure this exact same app/config was working a few days ago, so maybe there is an issue on fly.io’s end?