Cloudflare ERR_TIMED_OUT on Windows: A TCP Timestamps Fix

Note: This post was written by Claude Opus 5.5. The following is a synthesis of Cloudflare’s incident updates, published standards and vendor documentation, and troubleshooting on one affected corporate network.

On Tuesday morning, October 27, some Cloudflare-hosted websites stopped loading on Windows PCs behind corporate firewalls. Chrome and Edge waited, then gave up with ERR_TIMED_OUT. On one affected network, Linux machines, iPhones and Android phones reached the same sites without trouble. So did curl.exe and PowerShell on the failing PCs, and www.cloudflare.com itself loaded in the browser. One Windows setting got the browsers working again:

netsh int tcp set global timestamps=enabled (run from an elevated prompt)

The command turns on TCP timestamps for the connections Windows opens, something Linux, Android, macOS and iOS already do by default.

Cloudflare’s October 27 incident and its changing explanation

Cloudflare tracked the problem as incident dk2obcyw2aew from 12:28 to 15:12 UTC (8:28 to 11:12 a.m. Eastern), under the title “ERR_TIMED_OUT and ERR_EMPTY_RESPONSE being observed by Cloudflare Customers.” Customers whose traffic passes through “an external vendor firewall,” it said, may see ERR_TIMED_OUT on ordinary HTTPS sites and ERR_EMPTY_RESPONSE on other ports such as 8443.

As first posted, the notice blamed those firewalls “after recent firmware upgrades” and said only changes to the third-party software’s configuration could resolve the failures. That didn’t fit the timing. Companies install firewall firmware on their own schedules, yet these failures arrived together, on one morning. A simultaneous start points to a single change, whether at Cloudflare or in an update a firewall maker pushed to all its devices at once.

By 14:32 UTC the firmware wording was gone, and Cloudflare said it was “investigating to confirm the root cause and possible fixes.” At 14:52 UTC it moved the incident to Monitoring: “A fix has been implemented and we are monitoring the results.” Minutes later it deleted its earlier statement that “Cloudflare’s network and edge are functioning normally.” The 15:12 UTC resolution notice read, in full, “This incident has been resolved.” Cloudflare still hasn’t said what the fix was, who made it, or where.

X25519MLKEM768 and the split ClientHello

The trigger, engineers on the affected network found, was the size of the browser’s opening TLS message, the ClientHello. Chrome and Edge have included a hybrid post-quantum key share, X25519MLKEM768, by default since version 131, and RFC 10024 sizes it at 1,216 bytes on its own. Chrome’s ClientHellos on that network ran from 1,916 to 2,012 bytes, too big for one TCP segment, so each went out in two.

TCP connected within milliseconds and the ClientHello left the PC, but the reply, the ServerHello, never arrived. A packet capture showed the far end acknowledging every byte and then going silent. Test handshakes with OpenSSL tracked size, not cryptography: a classical-only hello of 314 bytes connected, while the same message padded with extra application-protocol (ALPN) entries to 1,538 bytes failed. The cutoff fell between 1,363 and 1,413 bytes, the point where the message no longer fits in a single segment. Full-size 1,500-byte pings with fragmentation disallowed went through, ruling out a path that can’t carry large packets.

Split ClientHellos are a known failure. tldr.fail, a reference site on the problem, describes servers that assume the whole message arrives in one read. In May, Cloudflare’s Radar post-quantum checker added a “Split ClientHello” test for connections that fail only when the message is fragmented, a fault it says is “typically caused by middleboxes or firewalls that cannot reassemble split TLS messages.” Browsers have sent handshakes this large since 2024, though, so size alone doesn’t explain why the failures began on Tuesday.

Why only Windows: TCP timestamps and RFC 7323

What separated the failing PCs from everything else was a TCP option Windows doesn’t request. Timestamps, defined in RFC 7323, let both ends measure round-trip time and reject stale duplicate segments, and only the side that opens a connection can propose them, in its first SYN packet. Microsoft’s netsh reference gives the Windows default as allowed, which “enables timestamps for incoming connections if the peer supports it”; only enabled “negotiates timestamps for outgoing connections.” Linux and Android turn them on by default, as Apple’s kernel does for macOS and iOS.

On the affected PCs, switching timestamps on made the large handshakes connect, and setting them back to allowed broke them again. Why a firewall would pass a split ClientHello with timestamps but not without them hasn’t been explained publicly. Nor did the engineers confirm which device dropped the traffic: the network’s own firewall or one farther upstream.

Rolling out netsh int tcp set global timestamps=enabled

The change applies to new connections immediately, needs no reboot and survives restarts; netsh int tcp show global lists the current value under “RFC 1323 Timestamps.” Afterward, Chrome and Edge loaded the failing sites, and the large OpenSSL handshakes connected, negotiating X25519MLKEM768. IT teams can push it through endpoint-management tools, with a Group Policy startup script for machines that were off. To reverse it, set the value back to what netsh showed beforehand; on the affected PCs that was allowed (netsh int tcp set global timestamps=allowed).

Leaving it on matches what Linux, macOS, iOS and Android do. The affected network hasn’t yet retried a PC at the Windows default since Cloudflare marked the incident resolved, so there’s no reason to rush to undo the change.

What’s still unknown

Cloudflare hasn’t named the firewall vendor or the firmware involved.

The scope is unclear too. W3Techs counts Cloudflare in front of 28.1% of all websites, an 86.0% share among reverse proxy services. Not every Cloudflare site failed, though: www.cloudflare.com loaded throughout on the affected network, so the 28.1% is a ceiling, not a count. Whatever the fix was, firewalls that mishandle split ClientHellos will keep turning post-quantum handshakes into timeouts; on this network, one missing TCP option decided which PCs failed.

Cloudflare’s October 27 incident and its changing explanation

X25519MLKEM768 and the split ClientHello

Why only Windows: TCP timestamps and RFC 7323

Rolling out netsh int tcp set global timestamps=enabled

What’s still unknown

Sources

Security Scorecard