Как мы обошли новую волну TCP RST в марте 2026
Анализ паттернов фильтрации и что мы поменяли в adaptive-стратегии за 36 часов.
Что произошло
22 марта в 14:10 MSK оповещения Grafana засветились красным: на нодах в Москве и Санкт-Петербурге упала доля успешных handshakes на TLS-транспорте. Очень характерный паттерн — соединения доходили до TLS ServerHello и через 1–2 секунды получали TCP RST с обеих сторон. Классический signature-based block.
Разбор трафика
Первые 30 минут мы просто смотрели дампы. Картина собралась быстро:
- RST летит только в сессиях с определённым набором cipher suites в TLS ClientHello.
- SNI значения не важны — мы специально подсовывали разные front-домены, RST приходил всё равно.
- После RST сразу виден повторный DNS-lookup со стороны клиента, то есть фильтрация происходит на L4/L7 пакетной инспекции, а не на route-level.
Итого — DPI научился классифицировать наши соединения по fingerprint'у. Менять SNI было бесполезно.
Что поменяли
Мы выкатили три вещи в течение 36 часов:
- Новый набор ClientHello fingerprint'ов — с приоритетом на те, что имитируют Chrome 119/120 и Firefox 121, включая правильный порядок extensions и SupportedVersions.
- Обязательный hello_retry path — добавили в adaptive-стратегию автоматический retry через QUIC если TLS handshake обрывается в первую секунду.
- Domain fronting как дефолтный путь для РФ-регионов — клиенты из РФ теперь изначально пробуют CDN-фронтинг, а TLS direct остаётся backup'ом.
Итоги
К 24 марта в 01:40 MSK доля успешных handshakes вернулась к 98.4% (p95). В процессе мы ещё раз убедились, что adaptive-стратегия важнее любого конкретного транспорта — когда один перестаёт работать, нужно уметь переключиться за секунды, а не дни.
Что впереди
Мы ускоряем релиз уже работающей в dev-ветке фичи автоматической ротации fingerprint'ов каждые 6 часов. Это будет стоить нам небольшого overhead'а на CPU, но существенно усложнит signature-based фильтрацию в будущем.