Constant MAX_INITIAL_MTU 

pub const MAX_INITIAL_MTU: u16 = 1452;

The largest initial_mtu this server accepts, in bytes.

A UDP payload size rather than an IP packet size, which is what makes the ceiling 1452 and not 1500: quinn documents initial_mtu as “the initial value to be used as the maximum UDP payload size before running MTU discovery”, and Ethernet’s 1500-byte MTU leaves 1472 bytes of payload over IPv4 (20-byte header + 8-byte UDP) and 1452 over IPv6 (40 + 8). The ceiling stays at the both-families value even though mtu_upper_bound may claim IPv4’s extra 20 bytes: discovery earns a size by probing it and loses only the probe when wrong, while this value is sent blind in the handshake — see the next paragraph for what wrong costs here.

There is no floor to fall back to if this is wrong: quinn applies the value with a max() against the 1200-byte minimum and no min() above it, so the handshake flight goes out in packets the path drops and the server is simply unreachable. Its black-hole detector is no help either – that runs inside an established connection, and with this wrong there is never one. A reload applies the value to connections accepted from then on, which is what makes the mistake worth rejecting rather than tolerating: a SIGHUP with a typo here turns a running server into one that still answers systemctl status and nothing else (audit 2026-08-23).