UDP service defined with a port range never receives packets

Questions / Help
1

Hi, I have an app where inbound UDP has never reached the Machine since the dedicated IPv4 was allocated, while TCP services on the same Machine work fine. I have checked everything I can from inside the guest and I am now fairly sure the packets are not being forwarded by the edge. Could someone check whether the UDP routing entry for this app exists?

App / setup

  • App aisdr-dev-seat (org personal), region nrt, single Machine 1857656ef0ee08 (created 2026-09-01). Dedicated IPv4 149.248.211.72 and dedicated IPv6, both allocated 2026-08-31.
  • Services as shown by fly machine status --display-config:
    • tcp 443 (tls, http) → 8000
    • tcp 7881 → 7881
    • tcp 5349 (tls) → 5349
    • udp internal_port 50000, ports [{ start_port: 50000, end_port: 50999 }]
    • all with autostop off / autostart false; the Machine is started during all tests.
  • The app is a self-hosted LiveKit SFU (v1.13.6) listening on UDP 50000-50999 bound to fly-global-services; but everything below was reproduced with a plain Python UDP listener, no LiveKit involved.

Symptom

  • UDP sent from the Internet (IPv4) to 149.248.211.72:50000, :50500 (inside the declared range) and :40000 (outside) never arrives. TCP 7881 and 443 to the same Machine work.

What I verified inside the guest (2026-09-26)

  • getent hosts fly-global-services → 172.19.2.83; eth0 has 172.19.2.82 and 172.19.2.83.
  • A Python listener bound to fly-global-services:50000 receives nothing. Also tried 172.19.2.82:50005 and 0.0.0.0:50990, nothing.
  • Passive AF_PACKET capture on eth0 while sending (two runs, 34 s each): zero UDP packets from any external source. In the same capture, TCP SYNs to 7881 arrive from 172.16.2.82 at the exact times I connected (positive control).
  • /proc/net/snmp Udp: NoPorts and InErrors do not change during the sends, so no unmatched external UDP reaches the kernel either. eth0 rx_dropped = 0. No iptables in the guest, rp_filter = 0.
  • Sending from inside the guest to 172.19.2.83:50000 is received, so the listener/bind is fine.
  • The sender opened a new socket per packet (118 distinct source ports, 59 packets per port) to rule out per-edge-host hashing. The sender’s outbound UDP works (STUN to Google answers in 7 ms).
  • Timeline: IPv4 allocated 2026-08-31, Machine created 2026-09-01, 56 releases since, all containing the UDP service. It has never worked, so this is not a propagation delay.

Possibly related

  • fly services list -a aisdr-dev-seat (flyctl v0.4.107) panics with a nil pointer dereference. It looks like internal/command/services/list.go:72 dereferences port.Port, which is nil for a start_port/end_port entry.

Questions

  1. Is there a UDP routing entry for 149.248.211.72 (50000-50999) on the nrt edges? This looks similar to the March 2024 report where new UDP services were not being registered (“Fly’s sample echo app not working with UDP”).
  2. Are UDP services declared with start_port/end_port supported, or should UDP be declared with single port entries only? The docs examples only show a single port for UDP.

If a single-port definition is the supported shape I am happy to redeploy that way. Thanks!

2

(post deleted by author)