We run a QUIC server (quinn 0.11) on a dedicated IPv4, bound to fly-global-services:443, in iad. For about a week, QUIC connections from Europe either fail to handshake or stop receiving data after 1–5 minutes. TCP to the same machine is fine.
To isolate it we deployed a minimal test app: iad, shared-cpu-1x, dedicated IPv4, UDP services bound to fly-global-services. It answers a request datagram with N reply datagrams of size S, sent individually or as one GSO batch. Results from one client in Poland (Liberty Global/UPC, NAT’d IPv4), 2026-10-27 22:59–23:08 UTC:
- Every request datagram reached the app, and every reply send returned OK.
- 22:59: all 264 replies arrived (200–1252 bytes, single and GSO alike).
- 23:02–23:03: no replies arrived for any size or mode, from new source ports.
- 23:04: of 20 sockets opened at once, replies arrived on 2 only, and one of those stopped receiving about 1s later.
- A flow that worked kept working for 3+ minutes, with 4s and 20s gaps.
- Size and GSO make no difference: 600-byte replies were lost just like 1200-byte ones.
- From the same client, HTTP/3 to cloudflare-quic.com and google.com works, and 1280-byte ICMP to the app’s IP works.
- QUIC handshakes: the client’s Initials are ACKed (the small ACK datagrams arrive), but the server’s handshake flight usually never does.
Our production app shows the same pattern for clients in Poland, Germany and Canada. Is there a known problem with the UDP return path for dedicated IPv4s, for example an edge host that drops replies for the flows hashed to it? We can share app and machine IDs and exact timestamps privately.