How we survived the March 2026 TCP RST wave in Russia
A breakdown of the filtering patterns and what we changed in the adaptive strategy in 36 hours.
What happened
On March 22 at 14:10 MSK Grafana lit up red: the share of successful TLS handshakes dropped on nodes in Moscow and Saint-Petersburg. Very characteristic pattern — connections reached TLS ServerHello and were RST'd from both sides 1–2 seconds later. Classic signature-based block.
Traffic triage
We spent the first 30 minutes just staring at captures. The picture came together fast:
- RST only fires for sessions with a specific cipher-suite set in the TLS ClientHello.
- SNI values don't matter — we deliberately rotated through front-domains, the RST still came.
- Right after the RST a new DNS lookup appears on the client — filtering happens at L4/L7 packet inspection, not at route-level.
Net: DPI learned to classify our connections by fingerprint. Rotating SNI wasn't going to save us.
What we changed
Three shipments in 36 hours:
- New ClientHello fingerprint set — prioritising Chrome 119/120 and Firefox 121 with the correct extension order and SupportedVersions values.
- Mandatory hello-retry path — added an automatic QUIC retry into the adaptive strategy when the TLS handshake gets cut in the first second.
- Domain fronting as the default for RF regions — Russian clients now try CDN fronting first, with TLS direct falling back.
Outcome
By March 24 01:40 MSK the p95 handshake-success rate was back to 98.4%. We were reminded, again, that the adaptive strategy matters more than any individual transport — when one stops working, you need to switch in seconds, not days.
What's next
We're fast-tracking an already-in-dev feature: automatic fingerprint rotation every 6 hours. It costs a little CPU but makes signature-based filtering substantially harder to keep up with.