Browse our guides
Today's browsers open TLS connections with a bigger initial handshake message. On certain Windows servers, a flaw in network card offload processing quietly fails roughly half of these handshakes. This guide covers how to spot the problem, what causes it, and two ways to resolve it.
Explore our Windows VPS plans — billed hourly, GST invoice included, ready in under a minute.
The complaint
A typical report sounds like this: the page opens without trouble on a laptop, but a phone shows "This site can't be reached." The server itself looks fine — no errors in the web server logs, CPU load is normal, and the firewall isn't blocking anything. Refreshing a few times sometimes gets the page to load.
Symptoms
These signs together point to this specific fault:
- Browser errors appear on and off: ERR_CONNECTION_RESET, ERR_CONNECTION_TIMED_OUT, ERR_CONNECTION_ABORTED, or a generic "Check your internet connection" message.
- Mobile devices hit the issue first, while desktop browsers seem unaffected.
- Nothing shows up in web server logs for the broken attempts, since those requests never reach the application.
- Testing with curl, or forcing TLS 1.2, from inside your own network succeeds every time.
- CDN and DDoS protection dashboards report no dropped traffic.
- The affected machine is Windows Server with Receive Segment Coalescing (RSC) turned on for its network adapter.
What is actually happening
- A bigger handshake message.
Chrome, Edge and Firefox now include a post-quantum key exchange method called X25519MLKEM768 in every TLS 1.3 handshake. This adds more than a kilobyte to the ClientHello message, so it no longer fits inside a single TCP packet and splits into two segments.
- A faulty merge by the card.
RSC allows the network card to join consecutive segments before passing them to Windows. On the hardware involved — an NVIDIA/Mellanox ConnectX-4 Lx card running WinOF-2 driver version 2.42 — the combined segment arrived with the highest bit of its TCP timestamp set to zero.
- Windows discards the second half.
TCP's PAWS mechanism rejects any segment whose timestamp looks older than the previous one it accepted. Because that bit got cleared, the remaining part of the ClientHello appears to come from the past, so it gets dropped on every retry, and the handshake never finishes.
- Why roughly half of attempts fail.
Each client picks a random starting value for its TCP timestamp, so that high bit happens to be set on about half of all connections — and those are exactly the ones that break.
- Why phones seem to be the problem.
The fault has nothing to do with phones specifically. Desktop browsers usually keep an existing connection alive, whereas mobile devices constantly open new ones as their radios go idle or switch networks. Older browser versions send a smaller hello that still fits in one packet.
Confirming it in two minutes
Run this check from a Linux machine outside your network, using OpenSSL version 3.5 or later. Connect several times with a large key share:
openssl s_client -connect YOUR_IP:443 -tls1_3 -groups X25519MLKEM768
Then repeat several times with a small key share:
openssl s_client -connect YOUR_IP:443 -tls1_3 -groups x25519
If the large-key-share attempts fail intermittently while the small-key-share attempts always succeed, you have this bug. A packet capture on the server will show the second segment being dropped, with its timestamp sitting exactly 2^31 away from what the client sent.
Fix 1: on the server
Turn off RSC on the Windows server. The change applies right away, with no need to reset the network adapter:
netsh int tcp set global rsc=disabled
Also check with your network card's vendor for an updated driver or firmware version.
In our testing, this took mobile-style handshakes from failing roughly half the time to a clean 20 out of 20 successful attempts.
Fix 2: at the network edge
Fixing one machine is simple, but finding every vulnerable server across a data centre is harder. For that reason, our edge routers strip the TCP timestamp option out of incoming SYN packets. Once a connection starts without timestamps, it never uses them — leaving nothing for the card to corrupt and nothing for PAWS to reject.
On a Linux router running nftables, a single rule in the forward chain does the job:
tcp flags syn / syn,ack,rst tcp option timestamp exists reset tcp option timestamp
- Strip only SYN packets, never SYN-ACK replies. If traffic flows asymmetrically and only the reply got stripped, the two sides would end up disagreeing on timestamps — a worse outcome than the original fault.
- The trade-off is minor: you lose the timestamp option's finer round-trip measurement and its safeguard for very fast individual connections. On a heavily loaded edge router, the extra CPU cost was too small to measure.
The takeaway
When some users can't connect yet nothing shows up in the logs, test the connection the way your users actually make it — a current browser, a brand-new connection, and a post-quantum key share. As more of the internet moves to handshakes that need two packets, older offload bugs that had gone unnoticed are surfacing again.
If you host with NABHCLOUD, this fix already runs across our network, so there's nothing you need to change on your end. Reach out to our support team if you have questions.
Questions on this guide
Why does my site load on a laptop but not on a phone?
A frequent cause nowadays is that mobile browsers keep opening brand-new connections, each carrying a large post-quantum TLS hello that spans two packets. A receive-offload flaw present in some Windows server network cards breaks roughly half of these handshakes.
How can I test whether my server has this RSC timestamp issue?
From outside your network, run openssl s_client several times with -groups X25519MLKEM768, then repeat with -groups x25519. If only the first set fails occasionally, your server is affected.
Is disabling RSC on Windows Server risky?
No, it's a safe change. Running netsh int tcp set global rsc=disabled switches off receive coalescing without resetting the network adapter. The web server will use marginally more CPU to process incoming traffic, which is usually not noticeable.
Does stripping TCP timestamps affect performance?
Barely, for typical hosting traffic. The main loss is more precise round-trip measurement and a safeguard that only matters for extremely fast individual connections.
Do NABHCLOUD customers need to take any action?
No action is needed. The fix operates at our network edge and protects every server behind it.