HTTP/3 connections to websites on a Plesk server fail intermittently: sendmsg() failed (90: Message too long) while sending frames

Gilson Siqueira

Updated September 15, 2026 15:06

kb: bug kb: technical kb: ai-created kb: ai-edited

Applicable to:

Plesk for Linux

Symptoms

Visitors report intermittent connection issues when opening websites hosted on the server, while the same websites open normally for other visitors. The affected clients are on connections with a reduced path MTU, most often mobile carrier networks, and also fixed-line connections such as DSL/PPPoE with an MTU of 1492 bytes. Both IPv4 and IPv6 clients are affected.
HTTP/3 is enabled and QUIC listeners are present in the nginx configuration.
The following error is logged in the website's nginx error log /var/www/vhosts/system/example.com/logs/proxy_error_log, or in /var/log/nginx/error.log:

CONFIG_TEXT: 2026/01/01 12:13:48 [alert] 2824623#0: *620764 sendmsg() failed (90: Message too long) while sending frames, client: 203.0.113.2, server: 203.0.113.3:443

Cause

nginx determines the QUIC datagram size separately for each client path and does not measure it again when the path MTU becomes smaller, including when a client's port changes while its address stays the same and the size measured on the previous path is carried over. Sending then fails and the affected HTTP/3 connection is closed, while connections over HTTP/2 and TCP are unaffected.

This is a Plesk bug with ID PPPM-15525.

Resolution

This will be fixed in a future version of Plesk.

Note: please click the Follow button to stay informed, you will receive an update via email when the bug is fixed.

As a workaround, disable HTTP/3 for the affected websites, or for the whole server:

Solution 1

Disable HTTP/3 for a single website in Plesk. This requires Plesk Obsidian 18.0.71 or later.

Log in to Plesk.
Go to Websites & Domains > the domain > the Hosting & DNS tab > Apache & nginx.
Clear the HTTP/3 support checkbox and click OK.

Solution 2

Disable HTTP/3 for the whole server over SSH.

Connect to the server via SSH.
Warning: The following step regenerates the web server configuration files and reloads nginx, which causes a brief service interruption.

Disable HTTP/3:

# plesk bin http3_pref --disable
Confirm that HTTP/3 is now disabled:

# plesk bin http3_pref --status

Note: HTTP/3 and QUIC support in nginx is an experimental feature. See Does Plesk support HTTP/3 (QUIC) protocol? for details.

Diagnostic notes for engineers:

Reproduced on a test server and confirmed as a bug under PPS-19332, which raised PPPM-15525.
The [alert] level identifies this as a real data-carrying datagram rather than a path MTU probe. Probes suppress EMSGSIZE logging, so they never produce an [alert] entry. The while sending frames log action belongs to the QUIC output path.
The QUIC datagram size for a path starts at 1200 bytes, the RFC 9000 minimum, and is raised only when the client acknowledges a larger probe. When only the peer's port changes and the address stays the same, which is what a NAT rebinding on a mobile or DSL/PPPoE connection looks like, the new path inherits the previously validated size without probing again.
Mobile networks are the most common source. LTE and 5G bearers carry GTP-U tunnel overhead, so the usable path MTU is typically around 1400 bytes, and cell handovers and idle-to-active transitions produce the port-only client address change described above several times per session.
Header overhead is 28 bytes over IPv4 and 48 bytes over IPv6, so on a 1492-byte link the usable QUIC payload is 1464 and 1444 bytes respectively, and 1404 bytes for a client behind a DS-Lite or 6rd tunnel. Dual-stacked websites are therefore most likely to be affected over IPv6.
Servers whose network interface uses jumbo frames are more exposed, because oversized datagrams are not rejected locally while the path size is being measured.
Keep quic_gso disabled, which is the nginx default. With batched sending, a single oversized datagram costs a whole batch of segments instead of one.
Observed frequency on the reporting server was 47 occurrences over four days, roughly a dozen a day, spread across six carrier networks and both address families. To measure it on another server, count the occurrences across the website logs and read the client addresses from the matching lines.